2.1 What's in the Files?
The physical components of an Oracle database system consist of the basic, delivered Oracle software and various storage files for each database. The storage files contain different forms of information. Those most relevant to security are:
- Tablespace datafiles
These datafiles can contain data, indexes, rollback segments, or temporary segments. Rollback segments and temporary segments are explained here. Data and indexes will be explained in Chapter 3.
- Rollback segments
These segments are used to keep track of the way the data looked before it was changed. During recovery, any uncommitted (saved) transactions still in the rollback segments are used to "roll back" these changes to restore the database to the last stable state.
- Temporary segments
These segments are allocated by Oracle when a user session requires an area in which a sort operation must be performed. Temporary segments are used by the RDBMS as a "scratch pad" to build temporary tables in order to do work requested by the user. These segments are created in the tablespace that has been designated the TEMPORARY tablespace.
- Control file
A form of binary storage file used to keep track of the status of the physical structure of a database. This file enables the database to start up and is used for database recovery. It records several critical maximum values and tracks the archive log numbers as well as the location and status of each tablespace datafile in the database.
- Redo log files
Another set of binary storage files that keep track of all changes made to the database. There must be at least two online redo logs associated with each database. The online redo logs are written to and reused in a circular fashion.
- Archive log files
These are companion files to the redo log files. If archivelog mode is enabled for your database, after each redo log file is filled, an archive log file is created with a copy of the filled redo log file. The archive log file is placed in an alternate storage area whose location you have designated in the INIT.ORA file for the database. The archive log files within this alternate storage area are sequentially numbered so that the new file will not overwrite an older file.
- Initialization file
This is the startup parameter file. As we've mentioned, we refer to this file as the INIT.ORA file, though it will usually be named in your system as INIT<DATABASE SID>.ORA . It is used to modify the default initialization parameters used by Oracle when you start a database.
- Configuration file
This file, CONFIG.ORA , contains configuration information. It can include information about the locations of control files and the database name . Other information, like the location of dump files, can be included in the configuration file. Although this file is optional, we mention it here because many sites choose to use a configuration file as well as an initialization parameter file. Some Oracle installers automatically create a configuration file as an include file for the initialization parameter file. Configuration files are recommended by Oracle Corporation for use with the parallel server option. The creation of the configuration file during the software installation is platform-specific, so not all installations have a configuration file.
- System Global Area (SGA)
This is a "file in memory," a set of memory-resident structures. When the database is started, the initialization parameters are read, the detached Oracle processes are created and started, and a section of memory is reserved for the System Global Area. Although it is not actually a physical file, the SGA is included here because of its tight coupling with the control file and the tablespace datafiles.
The idea of differentiating Oracle system files (external components) and Oracle database objects (internal components) for an Oracle RDBMS might at first seem strange , since we speak of the database as an entity in and of itself. In reality, the "database" is comprised of many different parts that are generally viewed as a whole system. This chapter and Chapter 3 together describe the parts from a security perspective.