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


Chapter 7 Recovering From Errors : Recovering From Non-Page File Failures

Recovering From Non-Page File Failures
While journal and backup information can be used to recover page data files, you can encounter other failures from which you must be prepared to recover. Other files that can fail include: JOURNAL1, JOURNAL2, the redolog, or the contingency log. The following describes these situations.
Redolog Failure
If the redolog becomes damaged, delete and re-initialize it.
Windows: %OS_ROOT%\database\REDO\REDOLOG
Solaris: ${OS_ROOT}/database/REDO/REDOLOG
All committed changes made since the last checkpoint are lost in the event of the loss of the redolog.
Run hrntlfrl to re-initialize the redolog. When the redolog is re-initialized, restart the Data Object Broker.
Contingency Log Failure
If the contingency log becomes damaged, delete and re-initialize it using the hrntlfcl (Format Contingency Log) utility.
Windows: %OS_ROOT%\database\CLOG\CLOG
Solaris: ${OS_ROOT}/database/CLOG/CLOG
Loss of contingency log data can result in data inconsistency in a distributed data environment. If your contingency log fails, contact TIBCO Support for assistance.
Failure of the contingency log impacts the distributed network of which the node is a part. This can require manual intervention, using the Administration menu (hrntladm), on some or all of the other networked nodes.
Journal Failure
The journals provide an audit trail of all changed physical pages. If one of your journals fails, you are unable to recover for subsequent page file failures. For this reason, you should immediately reset the continuous backup process with a new master backup.
After the Data Object Broker is started, use subsequent journal images, along with your backup, to recover any page file failures up to the time of failure. Although the page images contained within the failing journal are lost, your repository and other control files are still intact.
Recovering a Journal
1.
This primes your continuous or discrete backup process.
2.
3.
4.
The journal has a two-fold function: as part of continuous backup, and as part of checkpoint processing. When acting as a part of continuous backup, the loss of the journal means that a new full system backup must be created. For checkpoint processing, the journal is performing a caching role; if it is damaged before the last checkpoint is fully propagated to the Pagestore, it can impact Pagestore integrity.
See Also
TIBCO Object Service Broker for Open Systems Utilities for information on the utilities.

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