Getting Oracle to start writing archive logs is a somewhat more difficult subject. When you create a data file within a tablespace, Oracle writes to it automatically when users place data into that tablespace. Oracle automatically writes to the redo logs that are created when you create your instance. However, the DBA has to go through a somewhat redundant and extremely sensitive process to get Oracle to write archive logs:

1.  Go into the initialization files and set the LOG_ARCHIVE_START parameter to True. Don’t be fooled; this parameter doesn’t really start archive logging as you would expect. It sort of gives Oracle permission to start archive logging if all the other parameters are set up and only takes effect when you restart your Oracle instance.

2.  Tell it the format for the name of your archive log files. The exact syntax can be found in the SQL Language Reference, but you often can accept the default format.

3.  Tell Oracle where to stick the files and how to name what you are about to start archiving. This entails specifying a directory path and the first few characters of the archive log files themselves (it is not just a directory path). An example might be to have a series of archive log files that begins with the text string alog located in the /disk57/oracle/logs directory. Set the LOG_ARCHIVE_DEST parameter to the following:

LOG_ARCHIVE_DEST = /disk57/oracle/logs/alog

The second part of the archive filename is a variable string of characters that typically include sequential numbers. This format is specified by the LOG_ARCHIVE_FORMAT parameter. There are a number of options for this parameter, but the default usually works well and looks something like:

LOG_ARCHIVE_FORMAT = ‘%s.arc’

4.  Shut down (normally) your Oracle instance, perform a complete backup (for safety’s sake, please don’t skip this step), and bring up the instance with the database not open (that is, just give SQL*DBA the startup mount exclusive command). When the database has been started, enter the following command:

alter database archivelog;

5.  You can now open up the database. Be sure to verify that archive log files are actually being created. This is a very sensitive procedure and it is ripe with opportunities to make little mistakes in syntax that will cause you problems. You can verify that log files are being written by manually forcing a redo log file switch with this command:

alter system switch logfile

You may have guessed by now that archive log files have bedeviled me on several occasions. I usually wind up grousing when Oracle rejects my LOG_ARCHIVE_DEST parameter for some little syntax error. It is a tedious procedure. Once you have archive logging operational, you always have to be concerned with running out of space for archive log files and locking up Oracle’s capability of writing transactions to the database. However, you have the comfort of knowing that you can recover all data committed up to the point of failure of a disk drive.

Control Files

After that rather invigorating discussion of the archive log files, it is time to cool off a bit and discuss a relatively easy topic—the control files. If you are lucky, the only time that you have to bother with control files is when you create an Oracle instance. This is because control files are used by Oracle internally. You cannot manually edit them, you cannot control their size, and you can move them if you have to. Otherwise, the only time you will notice them is if one is missing. (Oracle will give you an error message indicating which control file is missing or damaged.) When this happens, you copy one of the other control files (they are identical to one another) into the location of the missing control file and restart the system.

Control files are a road map of the database as it is physically laid out on your computer system. They store such tidbits as the name of the database, the data files and redo log names, and a record of when they were created. You can add control files and delete existing ones if you want. One rule to remember when locating control files is that you always want at least one control file available so that you can re-create the others. You can re-create the control files manually in, but you do not want to have to try this. Therefore, spread your control files out over several disk drives whenever possible so that you always have one to start your instance.