CHAPTER 5 • UNDERSTANDING ORACLE8i ARCHITECTURE 190 controllers, not only will you improve the performance of LGWR, but you will also protect your online redo logs from failure or human error. If one member of a redo log group becomes corrupted, that will not cause the rest of the database to fail. Rather, Oracle will simply close the log file, note an error in the LGWR trace file, and continue to write to the remaining log files. If all of the online redo logs become corrupted, LGWR will fail. Then you will need to shut down the data- base, investigate the cause of the problem, and probably recover the database. If Oracle cannot open an existing redo log file group, you will need to shut down the database, determine what the problem with the redo log file is, and then restart the database. Database recovery in the form of media recovery will likely not be required in this case. System Monitor (SMON) The SMON process is responsible for a variety of database operations, including the following: • Cleaning up temporary segments • Recovering from a database crash • Coalescing database free space • Running recovery transactions against unavailable datafiles • Recovering an instance of a failed Oracle Parallel Server (OPS) node • Registering instances with the listener • Cleaning up the OBJ$ table • Shrinking rollback segments back to their OPTIMAL size setting • Managing offline rollback segments in PENDING OFFLINE mode • Updating statistics if an object is set to monitoring Process Monitor (PMON) The PMON process is responsible for recovering failed user processes and cleaning up any resources that might have been allocated to that process. If you are running MTS, PMON is responsible for recovery of dispatcher and server processes. PMON also monitors background processes, restarting them if they fail or shutting down instances if required (though PMON shutdowns are not very gracious!). Also, PMON is responsible for registering the database with the Oracle listener. Checkpoint (CKPT) The CKPT process is responsible for updating certain structures in the database datafile headers, as well as in the control files of the database, so that these files are synchronized. Copyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 191 Every three seconds, CKPT will wake up and determine if there are checkpoint events to process. Also, CKPT is responsible for notifying DBWn to start checkpoint processing when a checkpoint event is raised. (Prior to Oracle8, if the CKPT process were not run- ning, this job would fall to the DBWn process, which would further burden it.) Optional Processes The following processes are optional, and their use depends on the setup of your database: • ARCH, the archiver process, is normally enabled when the database is in ARCHIVELOG mode. You can have it start automatically via the init.ora param- eter LOG_ARCHIVE_START, or you can start it from SQL via the ALTER SYSTEM command. •SNPn, the job queue (or Snapshot) processes, are associated with the Oracle Job Scheduler. • RECO, the Distributed Database Recovery process, is associated with distributed transaction processing in Oracle. It is responsible for recovering transactions that are left in a prepared state after the loss of a connection to a remote database. This process can be disabled by setting the parameter DISTRIBUTED_TRANSAC- TIONS to 0. •LCKn (Lock processes), LMON (Lock Manager), LMD (Lock Manager Daemon), and BSP (Block Server Process) are part of the Oracle Distributed Lock Manager (DLM) processes associated with OPS. •Dnnn, the MTS Dispatcher processes, are dispatcher processes that act as the liaison between the client sessions and the shared server processes in a Net8 configuration. •Snnn, the MTS Shared Server processes, read requests from the request queue, process them, and then forward the result set to the response queue. •Qnnn, the Queue Monitor processes, are associated with Oracle advanced queu- ing. This process is controlled with the init.ora parameter AQ_TM_PROCESS. • LISTENER, the Oracle TNS listener process, facilitates Net8 connections between the database server and the client. These processes are discussed in more detail in the chapters that describe the data- base functions with which they are associated. ORACLE PROCESSES Oracle Database Administration PART II Copyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 5 • UNDERSTANDING ORACLE8i ARCHITECTURE 192 Oracle Database Control Structures In this section, we will review the concepts and internals of the Oracle database that contribute to maintaining the integrity of the database. First, we will discuss the nature of transactions in Oracle and the structures associated with transactions and data durability: commits, rollbacks, and checkpoints. Next, we will look at Oracle’s internal numbering mechanism: the system change number (SCN). Then we will examine rollback segment generation in Oracle (also known as undo), database datafiles, control files, and Oracle redo logs. Transaction Commits and Rollbacks A transaction is at the heart of the Oracle database. Without transactions, the database data never changes—rows are never added, altered, or deleted—making the database pretty useless for the most part. A transaction is the life of a series of different Oracle DML statements. A transaction begins with an initial connection to the database by a user process or after a previous transaction has been completed. Transactions end successfully (the changes are saved to the database) at the imple- mentation of a commit. Commits can be forced through the use of the COMMIT command. Commits can also be implied through the use of certain DDL commands. Transactions end unsuccessfully (database data changes are not saved) with the issuance of a ROLLBACK command or if the user process encounters some sort of fatal failure. Once a transaction has been committed, it cannot be rolled back. In many cases, such as with the default behavior of SQL*Plus, if you exit the process normally, an implied commit is issued, causing the transactional changes to be committed. Even terminations of certain user processes that might seem abnormal (such as hit- ting Ctrl+C in SQL*Plus and having SQL*Plus terminate, as it does in some cases) will cause an implied commit of the data. Checkpoints Because one of the goals of Oracle is speed, the changes to datafiles are not written out to the datafiles when a commit occurs. Changes are only written to the online redo logs (which we will discuss a bit later in this chapter). Of course, the data is writ- ten out at some point. This occurs when a checkpoint is signaled. A checkpoint is an event that causes the database to become synchronized to a single point in time (this may not be to the current point in time, however). The DBWn process is responsible for processing checkpoint operations. During a checkpoint, the DBWn process fires up and starts writing data out to the database Copyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 193 datafiles. In concert with the DBWn process, the CKPT process is responsible for updating certain structures in the database datafile headers, as well as updating the control files of the database so that they are also synchronized. Checkpoints can be caused by a number of events, including the following: • Taking a datafile or tablespace offline • Issuing the ALTER TABLESPACE BEGIN BACKUP command • Issuing the ALTER SYSTEM CHECKPOINT command • Shutting down the database with a SHUTDOWN, SHUTDOWN NORMAL, or SHUTDOWN IMMEDIATE command TIP If you need to abort a shutdown, it’s a good idea to force the system to perform a checkpoint by issuing an ALTER SYSTEM CHECKPOINT command. This will cause your shut- down to take a little longer, but it will allow your database to come back up much faster. Checkpoint Processing Oracle8i has changed how it handles checkpoints from previous versions of the data- base. In Oracle8i, you can have multiple checkpoints called and ready to be processed by DBWn at the same time (though checkpoints themselves occur in serial fashion). Oracle creates a checkpoint queue. All dirty buffers in the database buffer caches are linked to this list. The buffers in this queue are ordered according to when the changes occurred by using the low redo value in that block (an SCN value that indi- cates when the buffer was first changed). When a checkpoint is signaled, the range of redo values that the specific check- point request is responsible for is sent. Once the last redo value has been processed, that checkpoint will be complete. Even though that particular checkpoint may be completed, DBWn may continue to process subsequently requested checkpoints. Each checkpoint is handled in the order requested, so the oldest dirty blocks are always written to disk first. Should a block change before it was written during the check- point, that dirty block will still be written by the original checkpoint. There are five different kinds of checkpoints in Oracle: Database All dirty blocks in memory that contain changes prior to the check- point SCN will be written to disk. Datafile All dirty blocks in memory that contain changes that belong to a spe- cific datafile will be written to that datafile. ORACLE DATABASE CONTROL STRUCTURES Oracle Database Administration PART II Copyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 5 • UNDERSTANDING ORACLE8i ARCHITECTURE 194 Incremental These checkpoints do not update datafile headers and are used to reduce recovery time. Incremental checkpoints are discussed in more detail in the next section. Mini-checkpoint These checkpoints are caused by certain types of DDL oper- ations, such as dropping a table. This checkpoint impacts only the blocks of those objects. Thread checkpoints These checkpoints are caused when an instance check- points in an OPS environment. Incremental Checkpoints In Oracle8i, the incremental checkpoint process limits the number of dirty buffers in the database buffer cache, in an effort to reduce the time required to restart the database in the event of a system failure. When an amount of redo equivalent to 90 percent of the size of the smallest log file is generated, an incremental checkpoint will be signaled. During normal database operations, the DBWn process constantly writes out small batches of changes to the database datafiles. In doing so, an incremental checkpoint counter is maintained in each datafile, as well as in the database control file. This counter represents the progress of the incremental checkpoints. Because dirty blocks are written to disk in a more frequent fashion (to reduce I/O con- tention), Oracle will need to apply less redo from the online redo logs to recover the database. (This particular requirement has some restrictions associated with the size of the redo log buffer.) You can set several parameters to control incremental checkpoints (each of these can be set in the init.ora database parameter file): FAST_START_IO_TARGET This parameter is available only in the Oracle8i Enterprise Edition of the database. It defines the upper bounds on recovery reads, and it is measured by the maximum number of database buffer cache blocks that you want to recover after a database failure. In other words, you define the maxi- mum number of I/Os that you want Oracle to process during recovery. Oracle will manage the incremental checkpoint process such that this target recovery figure will be maintained as best as possible. The smaller this number, the faster recov- ery will be (but there may be I/O and database performance impacts). LOG_CHECKPOINT_INTERVAL This parameter is measured in redo log blocks (which is generally different from the database block size). It defines the maximum number of dirty redo log buffer blocks that can exist, unwritten, in the database. If this number of blocks is exceeded, an incremental checkpoint is signaled. Copyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 195 LOG_CHECKPOINT_TIMEOUT This parameter, which is measured in sec- onds, indicates that the tail of the incremental checkpoint should be where the last redo log record was x seconds ago. Thus, this parameter attempts to control the checkpoint process by causing incremental checkpoints no more than a set number of seconds behind in the redo stream. LOG_CHECKPOINTS_TO_ALERT If you want to know how long it takes to complete a checkpoint (which can be a measure of overall database perfor- mance and a good trending tool), you can log the start and stop times of check- points to the alert log by using this parameter. NOTE The logging time of checkpoints in Oracle8i version 8.1.6.3 does not appear to be working correctly. If you set the init.ora parameter LOG_CHECKPOINTS_TO_ALERT to report checkpoint completions, the times being reported do not seem to match when the checkpoints actually appear to have been completed. This may be due to changes in incre- mental checkpointing in Oracle8i. You can see how the various parameters impact instance recovery by looking at the V$INSTANCE_RECOVERY view. If you want to know how many checkpoints have occurred on your system since it was started, you can query the V$SYSSTAT view and look for the statistic called DBWR Checkpoints. This value represents the number of checkpoint requests that have been completed. The System Change Number (SCN) The SCN is simply a counter that represents the state of the database at a given point in time. As an analogy, consider the counter on your VCR. As you record a movie on your videotape, the counter represents individual places on the tape. Thus, if you knew where the counter was when Neo says, “I know Kung-Fu” in The Matrix, you can always go back to that position and watch him strut his stuff. The SCN is some- what like the VCR counter. It is a continuously flowing timeline that identifies when things happened. The SCN is a 6-byte number that increases monotonically; that is, it goes from a small number (starting at 0) and moves up as transactions occur. Each database trans- action is committed at a given SCN. The SCN consists of two parts: the base value and the wrap value. The base value of the SCN is increased first. If the base value rolls over, then the wrap value is increased. A new SCN is assigned every time a transaction is committed. ORACLE DATABASE CONTROL STRUCTURES Oracle Database Administration PART II Copyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 5 • UNDERSTANDING ORACLE8i ARCHITECTURE 196 The SCN is central to several critical database operations, including providing read- consistent images, database consistency checks, and database recovery services. The role the SCN plays in these operations is described in the following sections. Read-Consistent Images Each committed change is associated with an SCN. That SCN is stored in the header of each block in the database, as well as in each rollback segment entry. As you know, if you start a report at 2 P . M ., you will only see the data in the database as it looked at 2 P . M . This consistency is facilitated through the SCN. When you start your report at 2 P . M ., the database will be at a given SCN. NOTE The database does not care what time you started your report; it only cares what the SCN was when you started your report. This is why it doesn’t matter if you change the system clock while the database is running. For example, suppose you start your report at SCN 1000. Oracle will process the blocks from the database buffer cache if they are present there, or it will extract the correct blocks from the database datafiles. When it does so, it will read the header of the block, which contains, among other things, the SCN of the last time the block was updated. Now, what happens if that block happens to have been updated at SCN 1010? Can Oracle then use that block? No, since the report was started at SCN 1000, Oracle can use the data blocks only if the last update SCN is 1000 or less. So, you have a problem, don’t you? The data block that contains the row(s) you need has been updated. What do you do? The solution is to use the rollback segments to generate a read-consistent image of the block as it existed at SCN 1000. Having determined that the SCN of the actual data block is too high, Oracle will scan through the rollback segments (using some internal pointers that make the process rather fast), looking for the first image of that block that has an SCN less than or equal to 1000. Oracle will then create a read-consistent image of the rows that are needed by taking the original block and, using the rollback segments, constructing an image consistent to the time needed by the report. Database Consistency Checks The SCN provides methods of ensuring that the database is in a consistent state when it is started. Oracle will cross-check the SCNs stored in each database datafile header against those stored in the control file. If Oracle finds that the SCNs match, then the Copyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 197 database is in a consistent state. If the SCNs do not match, then the database is not in a consistent state and some form of recovery will be required. When a database is shut down normally, the shutdown process will cause a check- point to occur, and all datafiles will be updated. This will cause the SCNs in the datafile headers to be synchronized. The database will then update the SCNs in the control files, so that those SCNs will also be consistent. When the database crashes, or a SHUTDOWN ABORT is executed, these synchronization processes do not occur. Since the database datafiles will be out of synch with each other and the database, they will be considered inconsistent, and Oracle will apply recovery when the data- base is restarted. Database Recovery Services The SCN is used during database recovery to ensure that all database datafiles are recovered to a consistent point in time. If, during the recovery process, a database datafile is not consistent with the remaining datafiles of the database, Oracle will sig- nal an error indicating that there is an inconsistent state in the database and that the database will not open. This means that all of your database datafiles must be recov- ered to the same point in time. For example, if you want to recover one tablespace (and the objects in it) as they looked at 3 P . M ., and the rest of the database as it looked at 4 P . M , you will need to con- sider some different options from a physical recovery of the data, such as performing a logical recovery or taking advantage of Oracle’s transportable tablespace feature. We will discuss each of these options in more detail in Chapters 11 and 12. Rollback Segments and Undo We have already discussed the role of rollback segments in providing a read-consistent image of changes made to the database. These changes are in the form of undo. Undo is simply the representation of the data that was changed as it existed before the change took place. Undo is what is stored in rollback segments and allows a block change to be undone. Different changes generate different levels of undo. Some changes, such as INSERT statements, generate minimal undo (since the undo for an INSERT operation is basi- cally a deletion of the row). Other changes, such as the results of UPDATE or DELETE statements, can generate a lot of undo. ORACLE DATABASE CONTROL STRUCTURES Oracle Database Administration PART II Copyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 5 • UNDERSTANDING ORACLE8i ARCHITECTURE 198 NOTE Don’t confuse undo with redo. They are two very different things. Redo is associ- ated with redo logs and represents atomic-level changes to the database, as explained in the “Redo Logs” section of this chapter. If you are interviewing for an Oracle DBA job, don’t be surprised if you are asked to explain the difference between undo and redo! More on Read Consistency Read consistency is one of the fundamental principles of any truly relational data- base. Read-consistency implies that any query you execute at time x will use the data in the database as it looked at time x. For example, suppose that you are going to query row number 1000, and the value in column B was 100. What happens if, before your query actually read column B, someone changed it to a value of 1010 and committed that change? Because you are using a read-consistent database, when your report gets to row number 1000, Oracle will know that the value 1010 is not consistent to the time you started the report. Oracle will then root around to find the rollback segment entries that were generated when the row value was changed from 1000 to 1010. Oracle will put this puzzle together and construct an image—a snapshot—of the row as it looked at time x, rather than as it currently looks. Thus, your report will get a row as it looked when the report started and not as it looked after the change. In providing read consistency, Oracle has accepted that there will be some, shall we say, “wrinkles” in the process from time to time. The wrinkle I refer to is the Oracle error, ORA-1550, Snapshot Too Old message. This error has served to confuse more than a few DBAs, so let’s discuss it in a bit more detail before continuing with the other architectural elements of Oracle. The ORA-1555 Snapshot Too Old Error As you just learned, when Oracle constructs a read-consistent image, it creates a con- sistent result set, or a snapshot; hence, the reference to “Snapshot” in the error ORA- 1550 message. The undo records (and the associated changed rows) for a given transaction are locked for as long as that transaction is active. So, there should be no problem finding the needed undo as long as the transaction is still churning away. However, a problem arises when a transaction commits its work. When this occurs, all the undo in the rollback segments associated with that transaction is unlocked, leaving those undo segment locations available to be reused by other transactions. Guess what happens if the undo segment location is reused and your report needs what was in that segment Copyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 199 to generate the read-consistent image? You guessed it: Oracle returns the ORA-01555 error. So, of course, your report dies, and you want to go smacking some heads together. There can be some other causes of the ORA-01555 besides missing rollback seg- ment information. It is possible that the rollback segment information is present, but that the transaction slot information is missing from the rollback segment header. A transaction slot is kind of a directory in the rollback segment header that points to the location of the transaction within the rollback segment (it contains additional infor- mation on the transaction as well). The information in the transaction slot might be missing due to a feature of Oracle called delayed block cleanout, which is designed to assist with performance. When a transaction is complete, to save time, Oracle does not clean out the rollback segment entries. Rather, Oracle waits for the next user process that needs the entries to clean out those entries later on. Sometimes, the transaction slots in the rollback segment header may be overwritten, but the actual undo will not. In some cases, Oracle can reconstruct the transaction slot, as long as the undo image in the rollback segment is still present. Otherwise, an ORA-1555 is signaled. PL/SQL programmers may run into ORA-1555 problems if they tend to perform large fetch-across-commit operations. This is because they end up overwriting their own session’s before-image views or rollback segment transaction slots. This is more likely to happen if the program uses the SET TRANSACTION USE ROLLBACK SEG- MENT command. So, what can be done to eliminate the “Snapshot Too Old” problem? Here are a few pointers: Make sure that your rollback segments are large enough. Just giving your rollback segments enough tablespace space to grow into is not suffi- cient. You need to allocate enough initial and growing space to make the extents of the segment big enough to handle the load you will be throwing at it. Remember that your rollback segments will not extend to avoid an ORA-1555 problem. Watch EXTENDS and SHRINKS. The effects of the OPTIMAL clause in a rollback segment can be devastating to transactions needing read consistency. Guess what happens if Oracle shrinks a rollback segment back to its OPTIMAL size and you need a block that used to be allocated to the rollback segment but is no more? That’s right, ORA-1555. This is one reason why Oracle tells you not to set OPTIMAL on the SYSTEM rollback segment during database migrations. Keep an eye on EXTENDS and SHRINKS. Rebuild rollback segments larger until EXTENDS are as near zero as possible. ORACLE DATABASE CONTROL STRUCTURES Oracle Database Administration PART II Copyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.