Was this helpful?
Automatic Recovery
Ingres automatically handles the transaction failures that cause most database inconsistencies.
Recovery During Normal Operation
If a user program exits or a transaction is aborted for some other reason, the DBMS Server automatically handles transaction rollback. This does not cause an inconsistent database.
Recovery at Shutdown
At shutdown, all users must have exited their sessions; therefore, all transactions are committed. If users exited their sessions abnormally, the DBMS Server aborts any open transactions associated with the aborted sessions. Very long transactions take time to roll back and cause ingstop to seem to hang. The DBMS Server process cannot exit normally until it finishes recovering the aborted transactions.
If transactions are being rolled back on shutdown, allow the DBMS Server to finish this task before shutting down. If you do not, longer delays occur at startup time while the recovery process is performing rollback.
Recovery at Startup
If transactions have been aborted and were not recovered by a normal shutdown, upon restart the recovery process performs recovery. This occurs, for example, if:
Processes are forcibly killed from the operating system
The machine is rebooted
Power to the system is interrupted
The recovery process performs the following steps upon startup:
1. Reads the transaction log file. If there has not been a normal shutdown, the recovery process detects that databases are inconsistent—that is, that Ingres previously exited without completing all the transactions required for system and database consistency.
2. Proceeds through the transaction log file to back out uncommitted transactions and complete committed fast-commit transactions until the databases are again in a consistent state. While recovery is proceeding, no user interfaces can connect to a database.
Recovery actions are logged in the file $II_SYSTEM/ingres/files/iircp.log.
Note:  When configured for the Ingres Cluster Solution, the log name has _nodename appended to the base log name. When the recovery process is complete, the message “Completed aborting transactions” is written to the RCP log file. Restart Ingres with the ingstart command. Users can reconnect to the databases.
Recovery Process Monitoring
If you are monitoring Ingres startup after a machine reboot, the following messages are displayed:
Starting Ingres Name Server...
Starting Ingres Communications Server...
Starting Ingres Recovery Process...
If the transaction log contained uncommitted transactions when the machine failure occurred, the startup script pauses while the recovery process recovers transactions from the transaction log file. No messages are printed to the screen.
If you are in doubt as to whether recovery is taking place during startup, or to monitor the recovery process, use the following procedure.
Display the recovery process log file by typing the following command at the operating system prompt:
Windows:
%II_SYSTEM%\ingres\files\iircp.log
UNIX:
tail -f iircp.log
VMS:
II_SYSTEM:[INGRES.FILES]IIRCP.LOG_nodename
If the system is recovering, the recovery actions are logged to the IIRCP.LOG file. This indicates that Ingres is automatically recovering from possible inconsistencies.
Messages are printed to the log file during recovery:
The message at the beginning of recovering transactions indicates that transaction recovery has begun.
Intermediate messages track recovery progress. As recovery proceeds, progress messages (for example, “Recovered 31 of 130 transactions”) are displayed.
When done, the following message is printed:
Recovery complete.
You can also use an operating system command to determine whether the recovery process is recovering transactions by checking to see if it is accumulating CPU time.
VMS:
You can issue the following command at the operating system prompt several times:
show process/cont/id=xxxx
where:
xxxx is the process ID of the recovery process.
If the CPU time and disk I/O count taken by the process is increasing, the recovery process is most likely recovering transactions from the log file.
UNIX:
On UNIX, you can also monitor the files in the database directory of the database you suspect of being the target of the updates that are being backed out. The following command entered at the operating system prompt shows whether data files are being updated:
ls -lt
The file most recently updated is listed first along with the time of last update.
If any of the monitoring techniques above indicate that transaction recovery is taking place, continue to monitor the recovery process until recovery has completed. When the recovery process is complete, CPU time is not accumulated.
After the recovery process has finished, restart the installation with the ingstart command. The ingstart utility first shuts down and brings up all required installation processes. Programs can connect to the databases.
Last modified date: 08/29/2024