< previous page page_337 next page > Page 337 that weren't committed. The end result is the same as if you had done a SHUTDOWN IMMEDIATE. Looking at Your Database The SHOW command may be used to review information regarding the current state of your database. Use SHOW SGA to see the information about the size of your System Global Area, or SGA. With SHOW PARAMETER, you can look at the current settings for the database initialization parameters. SHOW LOGSOURCE and SHOW AUTORECOVERY give you information about archive logging and recovery. Remember that the SHOW command options described in this chapter are new with release 8.1 of SQL*Plus, which was shipped with Oracle8i. In previous versions of Oracle, these SHOW commands were implemented only in Server Manager. Looking at the SGA The SHOW SGA command may be used to display information regarding the size of the System Global Area. The SGA is shared by all Oracle processes and contains the database buffer cache, the redo log buffer, shared SQL statements, and a number of other items. Here is an example of SHOW SGA being used: SQL> SHOW SGA Total System Global Area 5508612 bytes Fixed Size 45584 bytes Variable Size 4529140 bytes Database Buffers 409600 bytes Redo Buffers 524288 bytes The values returned by SHOW SGA are as follows: Total System Global Area The total maximum size of the SGA. Fixed Size This is the minimum size of the SGA, and is the size used when the SGA is first allocated. Variable Size This is the amount by which the SGA may expand. < previous page page_337 next page > < previous page page_338 next page > Page 338 Database Buffers The number of bytes allocated for buffering of data blocks from the data files. Oracle tries to keep the most recently used data in memory, in case it is needed again. Redo Buffers The number of bytes allocated for buffering of redo log data. The log writer (LGWR) process reads these buffers and writes the information they contain to the redo log files. For more information about the SGA, the structures within it, and the purpose of each of those structures, see Chapter 7 of the Oracle8 Concepts manual. Looking at Initialization Parameters Each Oracle database has a number of initialization parameters that control its behavior. These parameters control a wide range of things, such as the number of job queue processes to run, the database block size, the shared pool size, and more. When an Oracle database starts, the initial settings for these parameters are read from an initialization file. Some of these parameters may be changed dynamically, while the database is up and running. Others may only be changed while the instance is shut down. Still others, such as the database block size, may never be changed at all. The SHOW PARAMETERS command may be used to display the value of one or more selected parameters, or of all parameters. SHOW PARAMETERS with no arguments will get you a listing of everything, as shown in the following example: SQL> SHOW PARAMETERS NAME TYPE VALUE 07_DICTIONARY_ACCESSIBILITY boolean TRUE allow_partial_sn_results boolean FALSE always_anti_join string NESTED_LOOPS aq_tm_processes integer 0 arch_io_slaves integer 0 audit_trail string NONE b_tree_bitmap_plans boolean FALSE background_dump_dest string %RDBMS80%\trace backup_disk_io_slaves integer 0 backup_tape_io_slaves boolean FALSE bitmap_merge_area_size integer 1048576 blank_trimming boolean FALSE buffer_pool_keep string buffer_pool_recycle string cache_size_threshold integer 20 cleanup_rollback_entries integer 20 < previous page page_338 next page > < previous page page_339 next page > Page 339 You can narrow down the results by using a specific parameter name as an argument, for example: SQL> SHOW PARAMETERS log_checkpoint_interval NAME TYPE VALUE log_checkpoint_interval integer 10000 A useful variation on this theme is that you may specify any string you like as an argument to SHOW PARAMETERS, and SQL*Plus will display all the parameters whose names contain that string. The following example shows all the LOG related parameters, plus a few others containing the string LOG: SVRMGR> SHOW PARAMETERS log NAME TYPE VALUE dblink_encrypt_login boolean FALSE delayed_logging_block_cleanouts boolean TRUE log_archive_buffer_size integer 127 log_archive_buffers integer 4 log_archive_dest string %RDBMS80%\ log_archive_duplex_dest string log_archive_format string ARC%s. %t log_archive_min_succeed_dest integer 1 log_archive_start boolean FALSE log_block_checksum boolean FALSE log_buffer integer 8192 log_checkpoint_interval integer 10000 log_checkpoint_timeout integer 0 log_checkpoints_to_alert boolean FALSE log_file_name_convert string log_files integer 255 log_simultaneous_copies integer 0 log_small_entry_max_size integer 80 mts_rate_log_size string remote_login_passwordfile string SHARED Looking at Archive and Recovery Information SQL*Plus implements three commands that let you view information about archive logging and recovery. The SHOW LOGSOURCE command may be used to find out what directory your database's archive log files are being written to. Here's an example: SQL> SHOW LOGSOURCE Logsource G:\INSTANCES\PLUM\LOGS If you want to see more information about the status of archive logging, use the ARCHIVE LOG LIST command as shown in this example: SQL> ARCHIVE LOG LIST Database log mode Archive Mode < previous page page_339 next page > < previous page page_340 next page > Page 340 Automatic archival Enabled Archive destination G:\INSTANCES\PLUM\LOGS Oldest online log sequence 35 Next log sequence to archive 36 Current log sequence 36 The output from ARCHIVE LOG LIST is as follows: Database log mode Tells you whether or not your database is running in archive mode. The value will be either Archive Mode or NOArchive Mode. Automatic archival Tells you whether or not redo logs are automatically being archived. If automatic archival is enabled, that means you have an archiver process (ARCH) running, and your redo logs are automatically being copied to another device as each one is closed. Archive destination Tells you the archive destination. This is the same information you get from the SHOW LOGSOURCE command. Oldest online log sequence Tells you the sequence number of the oldest redo log group that hasn't been archived yet. Oracle increments this sequence each time a log switch occurs. Next log sequence to archive Tells you the sequence number of the next group of log files to be archived. If automatic archiving is disabled, this line won't be displayed. This value will always be less than the current log sequence. Current log sequence Tells you the sequence number of the redo log group currently in use. You can get an idea of how well the archiving process, which is named ARCH, is keeping up by looking at the values for the next log sequence archive and the current log sequence. A large difference between these two values indicates that the ARCH process is falling behind. If the archiver falls too far behind, the log writer process won't be able to open another group, and database users will have to wait for one to be archived. If this happens frequently, you may be able to resolve the situation by creating more redo log groups, making your existing groups larger, or starting more archive processes. Database Backup and Recovery Beginning with version 8.1, SQL*Plus implements commands to manage the archiving of redo log files and to perform point-in-time recovery of a database. In order to understand how these commands work, and to place them in their proper < previous page page_340 next page > < previous page page_341 next page > Page 341 context, you need to understand something of how backup and recovery work in an Oracle environment. This section explains the two fundamental approaches to backing up an Oracle database, and shows you how SQL*Plus may fit into your backup process. Archive logging will be explained, and you will see how SQL*Plus can be used to start, stop, and monitor that process. Finally, you will see how the SQL*Plus RECOVER command can be used to apply archive logs to a restored database in order to get up-to-the-minute recovery. If you are responsible for backing up an Oracle database, please do not depend on just this one chapter to show you how to do that properly. There are several excellent books on the subject. One you should become very familiar with is the Oracle8 Backup and Recovery Guideit's one of the manuals in the Oracle documentation set. Another book worth looking at is the Oracle8 Backup and Recovery Handbook, by Rama Velpuri and Anand Adkoli (Oracle Press, 1998). In addition, Oracle offers the three-day-long Oracle8 Backup and Recovery Workshop. Of all the things that a database administrator is responsible for, protecting the data is probably first on the list. The discussion of backup and recovery in this chapter is very high-level. The recovery scenario used as an example represents just one of many possibilities. It's a common scenario, and serves well to illustrate the use of the RECOVERY command, but there are a number of other possible scenarios you have to know how to handle in order to be confident that you can recover from a disaster. Backups There are two fundamental approaches to backing up an Oracle database. The first and easiest approach is to shut down the database and copy the files to a backup medium such as a tape. This is referred to as making a cold backup, because the database is closed, or cold, when you make it. Cold backups carry with them one major disadvantageyou must shut down the database. In a 24x7 shop, this may not be an option. With cold backups, you have to decide whether or not you need point-in-time recovery in the case of a failure. Enabling archive log mode gives you the ability to restore a cold backup and then reapply all committed transactions up to the point in time at which the failure occurred. Archiving is discussed in detail later in < previous page page_341 next page > < previous page page_342 next page > Page 342 this chapter. Cold backups are the easiest to implement, and are often used for small databases. Oracle provides a second approach to backing up a database that avoids the need for a shutdown. This involves copying the files while the database is open and being used, and is known as making a hot backup. You must have archive logging enabled in order to make a hot backup, so point-in-time recovery capabilities are automatically included. Cold backups Making a cold backup of your database is a relatively painless process. You simply follow these three steps: 1. Shut down the database normally, so that you have a consistent set of database files. This must be done with the SHUTDOWN, SHUTDOWN IMMEDIATE, or SHUTDOWN TRANSACTIONAL command. 2. Copy all the database files to backup media, such as a tape. This copying can be done manually, or it can be done by whatever backup software you employ. 3. Restart the database using the STARTUP command. To restore a database from a cold backup, you shut down the instance, copy the files from the backup media back to their original locations, then restart the instance. Your database will be restored to the way it was when you first took the backup. It is possible, when restoring a database from a cold backup, to place the datafiles somewhere other than their original locations. This may be necessary if you have lost a disk drive. If you do this, you will need to use the ALTER DATABASE RENAME DATAFILE command before opening your database. If you aren't sure which files to back up, you can find out by querying the data dictionary. The V$DATAFILE view returns information about each datafile used by the database, while V$LOGFILE tells you about the redo log files. The following query will return a list of all data and log files: SELECT name FROM v$datafile UNION SELECT member FROM v$logfile; < previous page page_342 next page > < previous page page_343 next page > Page 343 The only other files you need to worry about are the control files and the initialization file. You can get a list of control files by looking at the CONTROL_FILES entry in the initialization file, or by issuing the following command from SQL*Plus: SHOW PARAMETERS control_files The initialization file is the one used with the PFILE parameter on the STARTUP command. You should know where this is. Oracle won't keep track of it for you. Cold backups are often done as part of a nightly backup process that makes a copy of all files on your system. At some point prior to making the backup, the database is shut down. The backup job then runs, copying all files on the system to tape. When the backup job is complete, the database is restarted. Generate a listing of all datafiles, log files, and control files associated with the database each night. You will need it when it comes time to restore. If you are making cold backups as part of a nightly operating-system backup, you probably don't worry too much about which files are database files, since everything is being backed up anyway. You should worry. Knowing where your database files are is important when it comes time to restore, and for two reasons. First, if you need to restore your database, you will need to know which files to pull off the backup tape. You will also need to know where to place them. Second, you may be restoring the files to a different location, maybe to a different disk. If this is the case, you will need to issue ALTER DATABASE RENAME DATAFILE commands to tell Oracle the new location of the files. In order to do that, you will need to supply the old location as well. Hot backups Hot backups allow you to back up the database while it is open and being used, avoiding the major disadvantage of the cold backup approach. Also, with a hot backup, you automatically get point-in-time recovery. In the event of a disk failure, this allows you to restore the database and recover all transactions up to the time of failure. Because the files are open when you make a hot backup, they may not be consistent with one another. Consider, for example, a transaction that affects records stored in different datafiles. It isn't likely that the changes to both datafiles will be written to disk at exactly the same time. Thus, one datafile could be up-to-date, while changes to the second datafile could still be buffered in memory. If you take your hot backup at this moment, the two datafiles you copy won't be consistent in < previous page page_343 next page > < previous page page_344 next page > Page 344 regard to a single point in time. Look at Figure 10-2 to see a simplistic representation of how this works. Assume that you have just added a new employee to your database and assigned him to a department. Figure 10-2 shows the database in a state where the employee record has been written to a datafile, but the department record has not. Figure 10-2. Databasefiles in an inconsistent state You can see from Figure 10-2 that the new employee record has been written to a database file. The updated department record, however, with its count of active employees, still remains buffered in memory. The dotted line in Figure 10-2 shows what you would get if you copied the files at this point in time. In order to restore a database from this type of backup, Oracle needs to know what changes to make to the department data file in order to bring it up to date with the rest of the database. Oracle can get this information from the redo logs, but in order to do that you must be saving these log files somewhere. You do that by running the database in archive log mode, which is described in the section titled Archiving. When taking a hot backup, you must use the ALTER TABLESPACE BEGIN BACKUP and ALTER TABLESPACE END BACKUP commands before and after copying each tablespace's datafiles. See the Oracle8 Backup and Recovery Guide for detailed information on performing a hot backup. When restoring a database from a hot backup, you first shut down the database, then copy the data files back from tape. Finally, you go through a process called recovery. Recovery allows you to reapply transactions to the data files, bringing them up to date so they are consistent with one another and reflect the results of the last successful transaction prior to the failure. This is known as point-in-time < previous page page_344 next page > < previous page page_345 next page > Page 345 recovery, because you can restore the database to the exact point of time that the failure occurred. See the section titled Recovery, later in this chapter, for detailed information on the recovery process. Archiving. Archiving, in the Oracle world, is the process of saving redo log files for later use in a recovery process. Look at Figure 10-3. It's the same as Figure 10-2, except it also shows the redo log files. Whenever you change data in an Oracle database, the changes are written to a log file. This write occurs very quickly because it's a sequential writethe data is just appended to the end of the current log. This writing of the log file can lag somewhat behind your actual changes, but Oracle always catches up whenever you issue a COMMIT command. Transaction numbers are written with each log file record, so Oracle can keep track of which changes have been committed and which have not. Figure 10-3. Changes written to the redo log files These redo logs protect the database against a sudden interruption in the running of the software, such as you might get by kicking the computer's plug out of the wall. When you restart Oracle after a power failure, Oracle will immediately read through the redo log files to pick up any changes that weren't written to the database files before the crash. The database files are then updated with these changes, restoring things to the way they should have been had the crash not occurred. This process is known as crash recovery, and protects the database < previous page page_345 next page > < previous page page_346 next page > Page 346 against any sudden interruptions that do not result in damage to the disks containing the database files. To enable crash recovery, the logs only need to remain long enough for the same data to be written to the actual data files. Once that has happened, Oracle will reuse the log file for the next set of changes. In a running database, Oracle will continually cycle through a set of log files, moving from one to the next to the next as fast as each one is filled with data, saving only enough information to recover from an instance crash. It stands to reason that if Oracle can use the log files to recover from an instance crash, it ought to be able to use the same log files to recover from a disk failure. Indeed it can; the only difference is in the number of log files you need to keep around. Saving all redo logs since the time of the most recent backup allows you to fully recover the database when files are lost or damaged. You recover the database by restoring the database files from the backup and reapplying subsequent changes from the log files. Not everyone will have enough disk space to keep all redo log files online for a long period of time. This was particularly true years ago when the cost of the media was relatively high. This is where archiving comes in. Oracle provides the capability to archive redo log files to tape or some other media as they are being made. This gives you the scenario shown in Figure 10-4. In many cases today, people just archive the redo logs to a separate disk, maybe a slower and cheaper disk than the one used for the redo log files. Whatever the case, running a database in archive log mode is fundamental to any backup strategy where point-in-time recovery is required. Turning on archive log mode The ALTER DATABASE command can be used to put a database into archive log mode. It's important to remember that archive logs are useless for recovery without a full backup to use as a starting point, so before you turn archive log mode on, you should take a complete backup of your database. Generally, you should follow these steps: 1. Shut down the instance, closing the database. 2. Take a cold backup of the database. 3. Edit the initialization file. Check to make sure there is a LOG_ARCHIVE_DEST parameter, that it is uncommented, and that it is pointing to a valid directory. 4. Start the instance and mount, but don't open, the database. Use the STARTUP MOUNT command for this purpose. 5. Turn archive log mode on using the ALTER DATABASE command. < previous page page_346 next page > . down the instance, copy the files from the backup media back to their original locations, then restart the instance. Your database will be restored to the way it was when you first took the. issuing the following command from SQL* Plus: SHOW PARAMETERS control_files The initialization file is the one used with the PFILE parameter on the STARTUP command. You should know where this is. Oracle. writer (LGWR) process reads these buffers and writes the information they contain to the redo log files. For more information about the SGA, the structures within it, and the purpose of each of those