Previous Table of Contents Next


Log Writer

Recall from Chapter 2 that Oracle writes every committed transaction in two places to promote its capability of recovering in case a data file is completely destroyed. The first location, the data file itself, was written to by the Database Writer process covered in the previous section. This section deals with writing the other record of a transaction from the redo log buffer to the redo log files. This function is performed by the Log Writer background process (LGWR).

The general concept of the Log Writer is simple. Every transaction made to the database is recorded in the Log Buffer. This buffer operates on a first-in, first-out basis. There are multiple redo logs in the system and the Log Writer writes to them in a cyclical manner. A slight complication to consider is the fact that users can enter transactions on the system and wait for a while until they commit them. Until the user (or the software package) issues a commit statement, these records are not official and can be backed out without any changes to the data files. Normally, commits occur frequently and you do not have a large number of uncommitted transactions hanging around. Sometimes you do have a lot of uncommitted transactions. LGWR is designed to deal with this situation and makes special exceptions for handling commit statements received. Therefore, the processing rules for the Log Writer process are the following:

  LGWR wakes up and performs a write when a commit statement is received from a user process.
  LGWR wakes up and writes redo log buffers every three seconds. The processes that read the logs on a recovery are smart enough not to record changes in the data files until that commit statement is received for that particular transaction.
  LGWR writes redo log buffers when the redo log buffer becomes one-third full.
  Finally, when the Database Writer process writes records in the database buffer to disk, LGWR ensures that the corresponding redo log buffers are written to the redo logs.

Of course there are some fine points to this process. For example, if there are a lot of commits occurring in your database, Oracle may choose to transfer groups of commit records to the log files for efficiency. Recall also that you can actually have several identical members in a group of redo log files. That way, if one of the members of the group is not available (say the disk is busy with other input/output operations), the writes can occur to an available member of that group. Finally, under normal circumstances where there is not a separate checkpoint process, the Log Writer is responsible for writing records to the database buffer that records the latest system change number (SCN) applied to the database in the headers of all data files. DBWR then transfers these records from the database buffer to the disk files.

Optional Processes

In addition to the main processes described previously, Oracle8 gives you several processing options you may want to implement. Many of these are designed to meet special needs that do not apply to all databases. The following sections describe these processes.

Archiver

The Archiver (ARCH) is a conceptually simple process. When the Log Writer finishes filling up one of the online redo log files, it signals ARCH to copy it to the next archive log file in the sequence. ARCH sends the copy of the online redo log file to either a new file on a disk drive or to a tape you have designated. Of course. it can do its job only if there is room available on the tape or the file system on which you tell it to write the archive log file. The Archiver process is started by the Log Writer only when the database is operated in archivelog mode (that is, the DBA issues an ALTER SYSTEM ARCHIVE LOG START command, or you start your instance with LOG_ARCHIVE_START = true in the initialization file).

Recoverer

Another process that is present only when you use an optional database mode is the Recoverer (RECO). This process provides service when you have chosen to implement a distributed database (discussed in Chapter 4, “Oracle8 Servers and Options”). The purpose RECO is to deal with problems that occur during distributed transactions. There are special rules that have to be applied when you are trying to deal with replicated data tables or other remote tables. Many problems can occur when wide area networks are used. The basic transaction writing processes are trained to yell immediately if there is a problem writing to the local disk drives. Oracle has designed RECO to be a lot more tolerant of such problems. It waits until connection is reestablished with the remote database and then goes over the transactions it’s not sure were recorded in the remote system. It resolves whether there were any updates made from other remote systems (you can link many different computers with different Oracle instances via the distributed option).

Lock Writer

The next specialist process is the Lock Writer (LCK). This process is present only when the parallel server option is being used. In this situation, you cannot use the single instance locking mechanisms provided by the Oracle memory areas of your instance. Instead, these special Lock Writer processes (you can have up to 10) talk to one another and ensure that records are properly locked for shared databases. Again, the logic for splitting out this function is that you do not want to weigh down your existing background processes with the burden of negotiating between instances. This is a much slower process because the messaging is not occurring through the fast shared memory area mechanisms of a single instance.

Dedicated Server Processes

These processes serve as the interface between a user process that is sending requests to the database and the memory areas and disks of the Oracle instance. They provide all the intelligence as to who to talk to for what service and where to find things. They have been used in Oracle since its beginning to provide this connectivity. The key to remember is that all users get a Dedicated Server process when they connect to the Oracle instance and it needs to remain available until they disconnect from the instance.


Previous Table of Contents Next