Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved


Chapter 8 Recovery Procedures : Recovering From Non-Page Data Set Failures

Recovering From Non-Page Data Set Failures
While journal and backup information can be used to recover page data sets, you must also be prepared to recover from other failures you encounter. Other data sets that can fail include the journals, redolog, CACHE1 and CACHE2 data sets, and the contingency log. Each situation is described in the following sections.
Recovering From Redolog Failure
If the redolog data set becomes damaged, it is possible that you cannot automatically recover the system.
Recovering With a Duplex Data Set
If the Data Object Broker fails due to either the redolog or its duplex becoming damaged, restart the Data Object Broker using a copy of the good data set as the redolog.
Procedure
1.
2.
Run the S6BTLFRL (Format Redolog) utility to re-initialize the redolog data set and copy the contents of the good data set into the new redolog.
Refer to TIBCO Object Service Broker for z/OS Utilities.
3.
IDCAMS cannot be used to back up or copy TIBCO Object Service Broker redolog data sets because it changes the placement of records within the VSAM control interval.
Recovering With No Duplex Data Set
If no duplex exists, you must delete, redefine, and re-initialize it. Loss of the redolog with no duplex causes the loss of commits received by the Data Object Broker since the last successful checkpoint.
Procedure
1.
2.
The following illustrates these steps:
3.
You do this so as to have this data still available, if needed. This is necessary because, at restart, TIBCO Object Service Broker sees that you re-initialized the redolog and overwrites the existing journal data.
4.
5.
Reply “G” to message S6BKR098, which should appear, along with message S6BKR011, because you have both a reformatted redolog and a cache data set available at this time.
If you have segments online when the Data Object Broker fails, and error messages S6BKX067 and S6BKX022 appear, modify the DBDGEN to include the segment shown in S6BKX067 as online at initialization.
Recovering From Contingency Log Failure
To recover from contingency log failure:
1.
Use the S6BTLFCL (Format Contingency Log) utility to delete, redefine, and re-initialize the contingency log data set (REDOLOG.PENDING).
Loss of the contingency log could result in data inconsistency in a distributed data environment. For more information about the role of the contingency log in distributed data environments, refer to Chapter 3, Understanding Fail Safe Processing.
2.
Recovering From Cache Failure
The CACHE1 and CACHE2 data sets are used to record checkpoint information quickly prior to actual segment updates. Loss of either of these data sets is detected during checkpoint processing.
If a cache data set fails, you must delete and redefine it. Information is not lost because all information is recoverable from the redolog. Pending update information is reconstructed from the redolog data set when the Data Object Broker is restarted.
Procedure
To create new cache data sets:
1.
Check the report to see the status of checkpoints. For more information on S6BTLDBR, refer to TIBCO Object Service Broker for z/OS Utilities.
2.
If all checkpoints are complete, that is, all checkpoint starts have a corresponding checkpoint end, run IEFBR14 to delete and reallocate both cache data sets, run the S6BTLFCA (Format Cache Data Sets) utility to re-initialize the cache data sets, and restart the Data Object Broker.
3.
If a checkpoint is outstanding and its data is in the good cache, that is, the checkpoint number in the cache header for the good cache matches the number of an incomplete checkpoint in the redolog information, run IEFBR14 to delete and reallocate the bad data set, run the S6BTLFCA (Format Cache Data Sets) utility to re-initialize this data set, and restart the Data Object Broker, replying G (go) to the S6BKR098A message.
4.
Recovering From Journal Failures
The journal data sets provide an audit trail of changed physical pages.
Recovering Journals
If one of your journal data sets fails, you are not able to recover to the point of failure for subsequent page data set failures. For this reason, you should immediately reset the continuous backup process with a new master backup.
After the Data Object Broker is started, you can use subsequent journal images, along with your backup, to recover any page data set failures up to the time of failure. Although the page images contained within the failing journal are lost, your repository and other control data sets are still intact. The steps for recovery are:
1.
2.
3.
4.
The following illustrates these steps:

Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved