|
|
|
The logging and locking systems coordinate the locking, recovery, and journaling of databases. The system is composed of the following components:
|
|
|
The locking component controls concurrent access to a database. Shared memory is allocated to components initially during the installation procedure. The amount of shared memory that your installation requires depends on the logging and DBMS server parameters that you select during the procedure.
UNIX: In UNIX, the lock manager component makes use of the shared memory segments and semaphore resources that you install when you configure the UNIX kernel.
|
|
|
The logging facility implements a circular "write-ahead" transaction log file for the management of transactions within the installation. It ensures that log records are written in a way that makes them accessible to the recovery and archiver processes.
|
|
|
The logging facility maintains in-memory log buffers. For every in-memory log buffer, there is a corresponding disk log file. Memory log buffers and disk log file blocks are the same length. The number of log buffers is configurable, set according to the performance requirements of the system. The logging system manages multiple asynchronous writes of log buffers to the log file.
The number of disk log file blocks corresponds to the size of the log file, and is specified when the log file is created. In a properly tuned system, most log file buffers are completely full of log records when they are written to the log file. However, as all log records associated with a transaction must be forced to the log file at certain times, principally at end transaction time, a small percentage of log file blocks may contain unused space. Server group commit logic is designed to minimize the frequency of log force operations and increase log file space use.
|
|
|
All servers in the Ingres installation, as well as the recovery and archiver processes, share the logging facility. Log records written by different servers, or written by several threads in the same server, can be combined with log records written by other servers or threads. The Logging Facility performs the following actions:
|
|
|
The recovery process performs recovery in the event of a server or system failure. The recovery process maintains a history of important actions in its own message log file, iircp.log.
|
|
|
Each installation of Ingres has a dmfrcp (data manipulation facility recovery process) that is assigned recovery responsibilities. In normal circumstances, transaction commit and rollback processing are handled within each DBMS server. In the event of a server or system failure, however, the recovery process performs the required recovery, including backing out uncommitted transactions and ensuring that committed transactions are properly reflected on disk.
|
|
|
The recovery process operates in the following modes:
|
|
|
Online recovery is performed when a server stops abnormally. In this case, users connected to other servers are generally unaffected by the recovery.
|
|
|
Offline recovery is performed when the installation is brought back up after it has stopped abnormally. In this case, the installation remains unavailable until the recovery process completes all required recovery.
|
|
|
The archiver process (dmfacp) is responsible for copying the history of operations performed on journaled databases from the transaction log file to the journal files. The archiver process maintains a history of important actions in its own message log file, iiacp.log.
The archiver process removes completed transactions from the transaction log file. For journaled tables, the archiver writes any completed transaction to the journal files for the database. Each database has its own journal files, which contain a record of all the changes made to the database since 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.
|
|
|
Each installation has a single archiver process called the dmfacp (data manipulation facility archiver process). The archiver process is responsible for copying the history of operations performed on journaled databases from the transaction log file to the journal files. Journal files contain the subset of transaction log file information associated with a specific database.
The name of the DMFACP process depends on the installation code. For Ingres installations with installation code II, the process name is DMFACP. For installation codes other than II, the DMFACP process name is DMFACPxx where xx is the installation code.
|
|
|
Journal files contain the subset of transaction log file information associated with a specific database. Journal files are created (and optionally destroyed) during a checkpoint operation. In the event of a disaster, the database can be rebuilt by restoring the latest checkpoint and applying journal file information.
|
|
|
Disaster recovery operations are coordinated by the rollforwarddb command.
|
|
|
Transaction recovery involves the transaction log file that is used as a write-ahead log, plus journal files maintained on a per-database basis. Log files contain short-term recovery information regarding active databases, while the journal files contain long-term information used for auditing and disaster recovery. While the log file is circular and wraps around, journal files are of configurable length and are retained indefinitely.
Ingres employs a page-oriented recovery scheme, where changes to pages are reflected in the transaction log file.
|
|
|
Recovery information is divided into two types:
Ingres performs both online and offline recovery, as described in Recovery Modes.
|
|
|
Undo or transaction backout recovery is performed by the DBMS Server. For example, when a transaction is aborted, transaction log file information is used to roll back all related updates. The DBMS Server writes the Compensation Log Records (CLRs) to record a history of the actions taken during undo operations.
|
|
|
A Redo recovery operation is database-oriented. Redo recovery is performed after a server or an installation fails. Its main purpose is to recover the contents of the DMF cached data pages that are lost when a fast-commit server fails. Redo recovery is performed by the recovery process. Redo recovery precedes undo recovery.
|
|
|
In a Linux cluster environment, or any other Ingres cluster environment where all nodes are active, the local recovery server performs transaction redo/undo for a failed DBMS server on its node, just like in the non-cluster case. The difference in a cluster installation is that if the recovery process (RCP) dies on one node, either because of an Ingres failure, or a general failure of the hardware, an RCP on another node will take responsibility for cleaning up transactions for the failed nodes.
|
|
|
Ingres maintains several log files to which it writes information about the installation activities. The various log files are:
|
|
|
Each installation has a transaction log file, and an optional dual log file. The transaction log file holds information about all open transactions and is used to recover active databases after a system failure. You have the option to change its size and number of partitions at startup.
UNIX: The UNIX log file can be created as a raw partition or as a number of raw partitions. For details, see the Installation Guide.
|
|
|
The Error Log (errlog.log) file is the main log file. It is a readable text file that you can use for troubleshooting. Messages about the installation are appended to this log with the date and time at which the error occurred. This is generally the first place to look when troubleshooting a problem. The error log contains the following information:
The system administrator maintains the error log file. This file continues to grow until manually truncated. The installation must be shut down before truncating or removing the errlog.log file.
The error log file is located at the $II_SYSTEM/ingres/files/ directory.
|
|
|
The archiver log (iiacp.log) contains information about the current archiver process. This file is appended to when the archiver process starts. The log contains the following information:
The archiver log is located at $II_SYSTEM/ingres/files/ directory.
|
|
|
The recovery log (iircp.log) contains information about the current recovery process. This file is appended to when the recovery process starts. The log contains the following information:
Note: The recovery log must be monitored if you are unable to connect to Ingres and suspect that the DBMS Server is in recovery mode.
The recovery log is located at the $II_SYSTEM/ingres/files/ directory.
|
|
|
Ingres maintains transcripts of various configuration operations. The primary configuration log files that Ingres uses are as follows:
The config.log file contains a log of the changes made with the Configuration Manager or Configuration-By-Forms (cbf) utility.
The rcpconfig.log file contains log and error information of the last time rcpconfig was run. For details of the rcpconfig command, see the Command Reference Guide.
The primary configuration log files are located in the $II_SYSTEM/ingres/files/ directory.
|
|
|
Ingres provides optional configuration log files. Configuration log files contain a log of messages that are generated every time configuration specific commands are executed. Ingres provides the following configuration log files:
The iilink.log file contains a log of the last time the iilink command was run. For details of the iilink command, see the Command Reference Guide.
The iivdb.log file contains a transcript of the last time the verifydb command was run. This file is created the first time when the verifydb command is run. For more information on the verifydb command see Command Reference Guide.
The lartool.log file contains a transcript of the last time the lartool command was run. This file is created the first time lartool is run. For more information on the lartool command see Command Reference Guide.
These files are present in the II_CONFIG directory of the Ingres installation.
Note: In UNIX, the II_CONFIG file must always be $II_SYSTEM/ingres/files.
|
|
|
Ingres provides various optional log files. These log files can be used for troubleshooting purposes. Ingres provides optional log files for:
|
|
|
Process logs can be set up for the following processes to isolate the error messages relating to that process:
|
|
|
Logging can be specified for a specific Ingres facility. The following optional log and trace log files can be established by setting the associated Ingres variables.
The DBMS Server error log is optionally defined as a separate file. This log file is established by setting the Ingres variable II_DBMS_LOG to a user-defined file name.
Note: By default, all logged messages are sent to the errlog.log file. If you define separate error logs, all messages are sent to both that error log file and errlog.log.
The GCC error log is used for installations using Ingres Net. This is in a user-defined file. This log file is established by setting the environment variable II_GCC_LOG to the full name of a file. The error logging level is specified by II_GCC_LOG_LVL.
The GCC trace log is set up for specific troubleshooting efforts. You set II_GCA_LOG to a user file name. The associated Ingres environment variable II_GCC_TRACE defines the level of tracing.
The Star error log is optionally defined as a separate file. This log file is established by setting the Ingres variable II_STAR_LOG to a user file name.
Note: All Ingres Distributed Option errors and messages are sent to errlog.log by default.
For more information about these log files, see the chapter "Setting Environment Variables and Logicals" and the appendix "Environment Variables and Logicals."