IC75546: UNABLE TO ONMODE -D PRIMARY <SECONDARY> AFTER PHYSICAL RESTORE OF ORIGINAL PRIMARY SERVER FROM SECONDARY BACKUP

APAR status

• Closed as documentation error.

Error description

• Simulating primary media failure on IDS 11.50.FC8 according to
  the steps mentioned in
  http://publib.boulder.ibm.com/infocenter/idshelp/v115/index.jsp?
  topic=/com.ibm.admin.doc/ids_admin_0975.htm
  
  After physical restore, getting the below error on the command
  prompt when issuing the onmode -d primary command on primary
  server.
  
  Error :
  DR: Unable to change server type
  
  onmode: Please check the message log for errors.
  
  Online.log :
  13:51:35  Physical Restore of logdbs Completed.
  13:51:35  Checkpoint Completed:  duration was 0 seconds.
  13:51:35  Fri Mar 18 - loguniq 109, logpos 0x35348, timestamp:
  0x1e1c94 Interval: 3021
  
  13:51:35  Maximum server connections 0
  13:52:07  This is not a valid command with the server in the
  current state. <== after issuing onmode -d primary command
  
  Reproduced problem in IDS 11.50.FC6, IDS 11.50.FC7 and IDS
  11.50.FC8W2.
  

Local fix

• No workaround to make the restored server primary again. One
  possible workaround is to promote the Secondary server to
  Primary and make the original primary server as Secondary HDR
  after physical restore. After HDR is synced up, then change the
  server type.
  

Problem summary

• ****************************************************************
  * USERS AFFECTED:                                              *
  * All users of Informix 11.50.xC8 and earlier versions         *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  * Information in the version 11.50.xC8 Administrator's Guide   *
  * topic "Critical media failure on the primary database        *
  * server" is incorrect.                                        *
  ****************************************************************
  * RECOMMENDATION:                                              *
  * Use the procedure in Problem Conclusion section.             *
  ****************************************************************
  

Problem conclusion

• The correct procedure to follow for a Critical media failure on
  the primary database server is as follows:
  
  You might be required to restart HDR after the primary database
  server suffers a critical media failure.
  
  For the following steps, assume that the configuration consists
  of a primary server named srv_A and an HDR secondary server
  named srv_B.
  
  To restart HDR after a critical media failure:
  
  1.     If the DRAUTO configuration parameter on srv_B (the
  original secondary database server) was set to 0, then you
  should convert the server to the primary server by running the
  onmode -d make primary command.
      If DRAUTO = 1 (RETAIN_TYPE), then convert the server to the
  primary server by running the onmode -d make primary command.
      If DRAUTO = 2 (REVERSE_TYPE), the secondary database server
  becomes a primary database server as soon as the connection ends
  when the old  primary server fails.
  
  2. Restore srv_A (the primary database server) from the
  last dbspace backup.
         a. Run the following command on srv_A if you are
  using ontape:
         ontape -p
         b. Run the following command on srv_A if you are
  using ON-Bar:
         onbar -r -p
  
  3. Use the onmode -d command to set srv_A to an HDR
  secondary database server and to start HDR.
         onmode -d secondary srv_B
  
         The onmode -d command starts a logical recovery from the
  logical-log files on srv_B. If logical recovery cannot complete
  because you backed up and freed logical-log files on srv_B, HDR
  does not start until you perform step 4.
  
  4. Apply the logical-log files from srv_B (the new primary
  database server), which were backed up to tape.
  
  a. Run the following command on srv_A if you are using
  ontape:
   ontape -l
  
  b. Run the following command on srv_A if you are using
  ON-Bar:
   onbar -r -l
  
  The HDR pair is now operational; however the roles of srv_A and
  srv_B are swapped. To swap srv_A and srv_B back to their
  original roles, follow the instructions starting with step 2 in
  the "Failover of the primary server to the HDR secondary
  server" topic.
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

Applicable component levels