0049-0052

Previous Table of Contents Next

Page 49

Oracle Files

There are three major sets of files on disk that compose a database:

  • Database files
  • Control files
  • Redo logs

The most important of these are the database files, in which the actual data resides. The control files and the redo logs support the functioning of the architecture itself.

All three sets of files must be present, open, and available to Oracle for any data on the database to be useable. Without these files, you cannot access the database, and the database administrator might have to recover some or all of the database using a backup, if there is one! All the files are binary.

System and User Processes

For the database files to be useable, you must have the Oracle system processes and one or more user processes running on the machine. The Oracle system processes, also known as Oracle background processes, provide functions for the user processes ”functions that would otherwise be done by the user processes themselves . There are many background processes that you can initiate, but as a minimum, only the PMON, SMON, DBWR, and LGWR (all described later in the chapter) must be up and running for the database to be useable. Other background processes support optional additions to the way the database runs.

In addition to the Oracle background processes, there is one user process per connection to the database in its simplest setup. The user must make a connection to the database before he can access any of the objects. If one user logs in to Oracle using SQL*Plus, another user chooses Oracle Forms, and yet another user employs the Excel spreadsheet; then, you have three user processes against the database ”one for each connection.

Memory

Oracle uses the memory (either real or virtual) of the system to run the user processes and the system software itself and to cache data objects. There are two major memory areas used by Oracle: memory that is shared and used by all processes running against the database and memory that is local to each individual user process.

System Memory

Oracle database-wide system memory is known as the SGA, the system global area or shared global area. The data and control structures in the SGA are shareable, and all the Oracle background processes and user processes can use them.

Page 50

NOTE
The combination of the SGA and the Oracle background processes is known as an Oracle instance, a term that you'll encounter often with Oracle. Although there is typically one instance for each database, it is common to find many instances (running on different processors or even on different machines) all running against the same set of database files.

User Process Memory

For each connection to the database, Oracle allocates a PGA (process global area or program global area) in the machine's memory. Oracle also allocates a PGA for the background processes. This memory area contains data and control information for one process and is not shareable between processes.

Network Software and SQL*Net

A simple configuration for an Oracle database has the database files, memory structures, and Oracle background and user processes all running on the same machine without any networking involved. However, much more common is the configuration that implements the database on a server machine and the Oracle tools on a different machine (such as a PC with Microsoft Windows). For this type of client/server configuration, the machines are connected with some non-Oracle networking software that enables the two machines to communicate. Also, you might want two databases running on different machines to talk to each other ”perhaps you're accessing tables from both databases in the same transaction or even in the same SQL statements. Again, the two machines need some non-Oracle networking software to communicate.

Whatever type of networking software and protocols you use to connect the machines (such as TCP/IP) for either the client/server or server/server setup mentioned previously, you must have the Oracle SQL*Net product to enable Oracle to interface with the networking protocol. SQL*Net supports most of the major networking protocols for both PC LANs (such as IPX/SPX) and the largest mainframes (such as SNA). Essentially, SQL*Net provides the software layer between Oracle and the networking software, providing seamless communication between an Oracle client machine (running SQL*Plus) and the database server or from one database server to another.

You must install the SQL*Net software on both machines on top of the underlying networking software for both sides to talk to each other. SQL*Net software options enable a client machine supporting one networking protocol to communicate with another supporting a different protocol.

Page 51

You do not need to change the application system software itself if the networking protocols or underlying networking software changes. You can make the changes transparently with the Database Administrator, installing a different version of SQL*Net for the new network protocol.

Figure 4.3 shows the role of SQL*Net in a client/server environment with two server database machines.

Figure 4.3.
SQL*Net diagram in a
client/server environ-
ment with two server
databases.

Oracle Files

In this section, I discuss the different types of files that Oracle uses on the hard disk drive of any machine.

Page 52

Database Files

The database files hold the actual data and are typically the largest in size (from a few megabytes to many gigabytes). The other files (control files and redo logs) support the rest of the architecture. Depending on their sizes, the tables (and other objects) for all the user accounts can obviously go in one database file ”but that's not an ideal situation because it does not make the database structure very flexible for controlling access to storage for different Oracle users, putting the database on different disk drives , or backing up and restoring just part of the database.

You must have at least one database file (adequate for a small or testing database), but usually you have many more than one. In terms of accessing and using the data in the tables and other objects, the number (or location) of the files is immaterial.

Database files, by default, will remain at the size specified when they were created. However, using the AUTOEXTEND and RESIZE options of the ALTER DATABASE SQL command, they can be grown or shrunk.

Control Files

Any database must have at least one control file, although you typically have more than one to guard against loss. The control file records the name of the database, the date and time it was created, the location of the database and redo logs, and the synchronization information to ensure that all three sets of files are always in step. Every time you add a new database or redo log file to the database, the information is recorded in the control files.

Redo Logs

Any database must have at least two redo logs. These are the journals for the database; the redo logs record all changes to the user objects or system objects. If any type of failure occurs, such as loss of one or more database files, you can use the changes recorded in the redo logs to bring the database to a consistent state without losing any committed transactions. In the case of non-data loss failure, such as a machine crash, Oracle can apply the information in the redo logs automatically without intervention from the database administrator (DBA). The SMON background process automatically reapplies the committed changes in the redo logs to the database files.

The redo log files are fixed in size and never grow from the size at which they were created.

Online Redo Logs

The online redo logs are the two or more redo log files that are always in use while the Oracle instance is up and running. Changes you make are recorded to each of the redo logs in turn . When one is full, the other is written to; when that becomes full, the first is overwritten and the cycle continues.

Previous Table of Contents Next


Oracle Unleashed
Oracle Development Unleashed (3rd Edition)
ISBN: 0672315750
EAN: 2147483647
Year: 1997
Pages: 391

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net