|
|
|
The logging system keeps track of all database transactions automatically. It is comprised of the following facilities and processes:
|
|
|
Each installation has an installation-wide transaction log file that keeps track of all transactions for all users. The log file can be distributed among up to sixteen partitions (locations), although Ingres treats the files as one logical file.
With dual logging enabled, the installation has an alternate log file. With dual logging, a media failure on one of the logs does not result in the loss of data or the interruption of service. If one of the log file disks fail, the logging system automatically switches over to access the other log without interrupting the application.
When log files are properly configured, the use of dual logging has a negligible impact on system performance.
Note: If your system is configured for Ingres Cluster Solution, each node in the Ingres cluster maintains a separate Archiver and Recovery error log. Each log is distinguished by having _nodename appended to the base log name, where nodename is the Ingres node name for the host machine as returned by iipmhost. Dual logging is also provided on clusters.
|
|
|
During normal online processing, space is reserved in the transaction log file for possible use during recovery when it is rolling back transactions. The reserved space is used to write Compensation Log Records (CLRs), which describe the work performed during the rollback.
Generally, the logging system reserves approximately as much log file space to perform the rollback as was required to log the original operation. Exceptions are insert and update operations, which require less reserved space than the original log.
In the Log File page in the Performance Monitor window, you can see a close approximation of the log file space required for both normal log writes and for CLRs. Also displayed is the number of log file blocks reserved for use by the recovery system at any point in time.
To access the Log File page, you click on the Log Information branch in the Performance Monitor window, and click the Log File tab in the Properties pane.
You can also accomplish these tasks using the sysmod command and the set log_trace statement. For more information on the sysmod command, see the Command Reference Guide. For more information on the set log_trace statement, see Set Log_Trace Statement and the SQL Reference Guide.
|
|
|
The recovery process (dmfrcp) handles online recovery from server and system failures. The logging system writes consistency points into the transaction log file to ensure that all databases are consistent up to that mark and to allow online recovery to take place when a problem is detected. While a transaction is being rolled back, users can continue working in the database.
The recovery process is a multi-threaded server process, similar to a normal DBMS server. However, the recovery process does not support user connections. The process must remain active whenever the installation is active.
|
|
|
The archiver process (dmfacp) removes completed transactions from the transaction log file and, for journaled tables, writes them to the corresponding journal files for the database. Each database has its own journal files, which contain a record of all the changes made to the database after the last checkpoint was taken. The archiver process "sleeps" until sufficient portions of the transaction log file are ready to be archived or until the last user exits from a database.