Administration Tools - oocleanup

Printer-friendly version
Lists the active transactions for a federated database or autonomous partition; recovers some or all of the abnormally terminated transactions.
oocleanup
[-local [-process pId] | -transaction tId [-deadowner]
| -deadhost hostName]
[-resetlock]
[-force]
[-standalone]
[-allpart | -onepart]
[-notitle]
[-help]
[bootFilePath]
Options
-local
Recovers all transactions started by processes that are no longer active, provided oocleanup can verify the status of these processes. Transactions are skipped if they belong to processes that are still active or whose status cannot be verified; see the -process option.
In general, oocleanup can directly verify the status of all local processes. However, the status of a remote process cannot be verified if either the remote host or its network link has failed. oocleanup with the -local option therefore recovers only those transactions belonging to inactive local processes or to remote processes that disconnected from the lock server due to application failure.
If the lock server has failed (and the -standalone option is used), only transactions from local processes are recovered.
-process pId
Used with the -local option; permits recovery of all transactions started by a specific process, regardless of the status of that process. You specify a process using the process identifier assigned to it by the operating system. The -process option enables you to recover the transactions of any process that -local skipped.
For safety, oocleanup checks the status of the process with the specified process identifier. If the process is no longer active, all its incomplete transactions are recovered; otherwise, if the process is active, oocleanup displays a prompt asking you whether recovery should continue. You will not receive this prompt if this option is used with the -force or -deadowner option.
Warning: Before using -force or -deadowner, verify that there are no process identifiers associated with active Objectivity/DB processes; otherwise, unintentional cleanup of an active process may result.
-transaction tId
Transaction identifier of a specific transaction to be recovered.
For safety, oocleanup checks the status of the process that started the specified transaction. If the process is no longer active, the transaction is recovered; otherwise, if the process is active or its status cannot be determined, oocleanup reports an error and terminates. (See also the -deadowner option.)
-deadowner
Used with the -transaction option; permits recovery of the specified transaction regardless of the status of the process that started it.
For safety, oocleanup checks the status of the process that started the specified transaction. If the process is no longer active, the transaction is recovered; otherwise, if the process is active or if its status cannot be determined, oocleanup displays a prompt asking you whether recovery should continue.
Warning: You can corrupt the federated database by recovering a transaction that belongs to an active process.
-deadhost hostName
Recovers transactions started by processes on the specified host, provided the host is “dead” (has failed or lost its network link), so its processes are no longer active.
For safety, oocleanup attempts to contact the specified host to verify that it is dead. If the host responds instead of timing out, oocleanup displays a prompt asking you whether recovery should continue.
Warning: Do not rely solely on this safety check to determine whether the specified host is dead. You can corrupt the federated database by recovering transactions that belong to active processes.
-resetlock
Resets the recovery lock before recovering transactions. The -resetlock option is required if a previous invocation of oocleanup terminated abnormally while recovering the transaction. A prompt is displayed asking you to confirm that the recovery lock should be reset.
Warning: You can corrupt the federated database by using this option when a recovery lock belongs to a cleanup process that is still active.
-force
Used with the -deadowner, -deadhost, or -resetlock option; recovers the requested transaction(s) without prompting for confirmation.
Warning: You can corrupt the federated database by recovering a transaction that belongs to an active process.
Because this option suppresses the display of any warning prompts, it is useful when invoking the tool from a script or application.
-standalone
Nonconcurrent mode. Use this option only if the lock server for the specified federated database or autonomous partition is stopped. If the lock server is running, the tool reports an error and terminates.
-allpart
(HA) Inspects the journal files of all accessible autonomous partitions in a federated database to identify the transactions to be recovered:
n
When used with the -local or -deadhost option, -allpart attempts the recovery of all incomplete transactions against the entire federation.
n
When used with the -transaction option, -allpart permits the recovery of any incomplete transaction against the federation.
Inspecting all journal files is time-consuming; if you know that only a small subset of partitions require recovery, you can save time by using the -onepart option to clean up each partition individually.
-onepart
(HA) Inspects just the journal files of the autonomous partition specified by bootFilePath to identify the transactions to be recovered:
n
When used with the -local or -deadhost option, -onepart causes the recovery of just the incomplete transactions listed in the inspected journal files.
n
When used with the -transaction option, -onepart permits the specified transaction to be recovered only if it is among those listed in the inspected journal files.
Recovery may still affect other partitions—specifically, if a transaction had updated multiple partitions, the transaction’s changes are rolled back in every affected partition. However, the journal files of other partitions are not inspected for transactions to be recovered, so transactions requiring recovery could exist elsewhere in the federated database.
If you know that only a small subset of partitions require recovery, you can use this option to clean up each partition individually. This is faster than using -allpart to clean up transactions in all partitions; however, you must determine which partitions require recovery and ensure that they are recovered.
-notitle
Suppresses the copyright notice and program title banner. Useful when invoking the tool from another tool or product.
-help
Prints the tool syntax and definition to the screen.
bootFilePath
Path to the boot file of the federated database or autonomous partition whose transactions are to be listed or recovered. If you are recovering a transaction that holds locks in multiple autonomous partitions, you can specify the boot file of any of these partitions. You can omit this argument if you set the OO_FD_BOOT environment variable to the correct path.
Discussion
You can use oocleanup to accomplish these tasks:
n
To display a list of active update transactions on a particular federated database or autonomous partition, specify just the bootFilePath argument.
n
To recover all incomplete transactions started by local processes that are no longer active, use the -local option. (This option also recovers transactions started by remote processes, but only if the status of these processes can be verified.) To recover all incomplete transactions started by a process that has been skipped by -local, run oocleanup with the -process and -local options.
(HA) For a partitioned federated database, you can further control the scope of recovery by adding either the -allpart or the -onepart option. If you cannot access a particular host computer (for example, if it fails to reboot) and you know that the processes on it have terminated, run oocleanup with the -deadhost option on any host.
n
To recover a specific transaction, use the -transaction option, possibly with the -deadowner option.
n
To recover transactions while the lock server for bootFilePath is stopped, use the -standalone option along with any other required oocleanup options. Do not use -standalone while the lock server is running.
When the oocleanup tool recovers a transaction, it rolls back the transaction’s uncommitted changes, restoring the federated database to the logical state it was in before the transaction started. (HA) If a transaction left uncommitted changes in multiple autonomous partitions, the changes are rolled back in all of the accessible partitions. In particular, if the transaction left uncommitted changes in the quorum images of a replicated database, the changes are rolled back in all of the quorum images that are still accessible.
The oocleanup tool uses the journal files of the specified federated database or autonomous partition to identify the transactions to be listed or recovered. When just the bootFilePath argument is specified, the oocleanup tool lists all active update transactions, including:
n
Transactions started by local processes (local to the host on which you are running oocleanup).
n
Transactions started by remote processes (running on a host other than the host on which you are running oocleanup).
From this list of transactions, oocleanup with the -local option recovers all transactions started by processes that are no longer running, provided that their status can be verified by oocleanup. (The status of a remote process cannot be verified if either the remote host or its network link has failed.)
(HA) By default, oocleanup inspects the journal files of all accessible partitions listed in the most recently recorded quorum of partitions. You can specify -onepart if you want oocleanup to inspect just the journal files of the autonomous partition specified by bootFilePath. You can specify -allpart if you want oocleanup to inspect the journal files of all accessible partitions, including any that might not be listed in the current quorum. (An error is reported for each inaccessible partition.)
If the lock server for the specified federated database or autonomous partition is still running, oocleanup causes it to release all locks held by the recovered transaction. If the lock server has stopped—or stopped and restarted—the transaction’s locks are lost, so oocleanup just rolls back changes.
By default, oocleanup acquires a recovery lock to make sure that no recovery is being performed by another oocleanup process. If oocleanup fails to acquire a recovery lock, it reports an error.

Date: 
Tuesday, October 30, 2012
Product: 
Objectivity/DB
Version: 
10.2.1
10.2
10.1.4
10.1.2
9.4.1