Next: Initialization Parameters Up: Files and Componants Previous: Files and Componants Contents

Database Files

When you create a database you'll get several things.

Control Files: Usually 3 named control01.ctl - control03.ctl
Data Files: The default dbca configuration is to create 5 datafiles: system01.dbf, undotbs01.dbf, sysaux01.dbf, users01.dbf and temp01.dbf.
Redo Logs: Typically 3, named redo01.log - redo03.log
Admin Files: A series of directories and files usually in $ORACLE_BASE/admin/SID.

A controlfile can be thought of as the Oracle equivelent to a DiskSuite State Database. It contains references and metadata pertaining to all the database files such as datafiles, redo logs, etc. Typically there are 3, or more, copies of the controlfile, similar to the way SDS uses multiple state databases. This guarrenties that even if 1 control file is lost or corrupt we still have another usable copy. Controlfiles supposedly can be rebuilt if they are lost or destroyed but it isn't easy. If there is a file you want to make sure your backing up, this is it. The datafiles contain the actual data. These are after refered to as tablespaces. Within the tablespace resides all the tables that make up your database. Users use the "users tablespace" which is in the users01.dbf datafile. Temp tables are written to the "temp tablespace" which is in the temp01.dbf datafile. So on and so forth. Redo logs are the database equivilent to a filesystem journal. When changes are made to the database the changes are written to the redo log. If data were log, we could recover the lost changes by replaying the redo logs just like we'd replay a VxFS journal on an inconsistant filesystem. Redo logging is enabled by default, but can be turned off if you choose by enabling the NOLOGGING parameter. There are typically 3 or more redo logs, which are written to in a round-robin fashion. Each one fills up untill all the logs are full and it begins overwritting the first again. On a related note that we won't go into depth about, redo logs can be archived. When a database is in ARCHIVELOG mode the redo logs can be written out to archive logs and stored elsewhere. The upside is that you could replay weeks of transactions back into the database if you wanted to. The downside is that if the, so called, archive log destination (directory where archived redo logs get stored) becomes full or unwrittable the instance will shutdown! Typically a cron or backup job is written to backup or move the archived redo logs to tape or a permanate storage location on a regular schedual to ensure the archive destination never fills up. Lets break down the admin files and directories.

bdump: Background Dump Directory (Alert Logs and Trace Files)
cdump: Core Dump Directory
udump: User Dump Directory
create: Creation Logs
pfile: Paramter File Directory

The bdump directory is an important directory because both trace files and alert logs are stored here. If you have a problem with your database the first place you'll want to look is in the alert log.

Next: Initialization Parameters Up: Files and Componants Previous: Files and Componants Contents

2005-02-10