Oracle SQL Plus The Definitive Guide- P39 ppt

< previous page page_347 next page > Page 347 Figure 10-4. A database in archive log mode 6. Open the database for use. 7. Start the automatic archival process. The ALTER DATABASE command has a number of options. The specific form used to put a database into archive log mode is: ALTER DATABASE ARCHIVELOG; In order to issue this command, you must be connected either as INTERNAL or SYSDBA. The following example shows how you would start a database using the MOUNT option, put it into archivelog mode, and then open the database: SQL> CONNECT INTERNAL Connected. < previous page page_347 next page > < previous page page_348 next page > Page 348 SQL> STARTUP MOUNT ORACLE instance started. Total System Global Area 5138580 bytes Fixed Size 47252 bytes Variable Size 4608000 bytes Database Buffers 409600 bytes Redo Buffers 73728 bytes Database mounted. SQL> ALTER DATABASE ARCHIVELOG; Statement processed. SQL> ALTER DATABASE OPEN; Statement processed. SQL> Once you've put the database into archive log mode, you will want to start the archive log process. Starting the archive log process The archive log process is an optional Oracle process that automates the task of archiving the redo log files. On most systems, the name of this process will be ARCH, or something close to that, and the Oracle documentation frequently refers to it by that name. ARCH runs in the background, and as each redo log file is filled, ARCH copies it to the archive log destination. ARCH also marks each file when it is copied so that Oracle knows it can be reused again. Strictly speaking, ARCH is an optional process, but it's usually considered necessary when the database is in archive log mode. The alternative is for you to manually archive each redo log file as it fills, but that requires constant monitoring and attentionsomething most people don't have time for. Use the ARCHIVE LOG command to start the archive log process. The ARCH process will be started, and redo logs will begin to be archived. You may optionally specify a destination for the archived files. Here is the syntax to use: ARCHIVE LOG START [TO destination] where: destination Is an operating-system-specific path pointing to the directory or device where you want the archived log files written. This is an optional parameter. If you don't supply it, the archive log destination is taken from the LOG_ARCHIVE_DEST parameter in your database's initialization file. You can start the archive process when the database is up and running, but you have to be connected in one of the administrative modes. The following example shows the archive log process being started: < previous page page_348 next page > < previous page page_349 next page > Page 349 SQL> CONNECT INTERNAL Connected. SQL> ARCHIVE LOG START Statement processed. SQL> In this case, since no destination was supplied in the command itself, the location specified by the LOG_ARCHIVE_DEST initialization parameter will be used. After starting the archive log process, you should check the LOG_ARCHIVE_START parameter in your database's initialization file. Setting it to TRUE will ensure that the archive log process is automatically started. You should also be familiar with the value for the LOG_ARCHIVE_DEST parameter, which points to the destination directory, so you can find the log files in case you need to recover the database. Displaying the archive log status Once archive log mode has been enabled, you can view the current status with the ARCHIVE LOG LIST command, as shown in the following example: SQL> ARCHIVE LOG LIST Database log mode Archive Mode Automatic archival Enabled Archive destination C:\ORAWIN95\RDBMS80\ Oldest online log sequence 34 Next log sequence to archive 35 Current log sequence 35 SQL> In fact, you can even view the archive log status when archiving is off. The output from ARCHIVE LOG LIST may be interpreted as follows: Database log mode Tells you whether or not the database is in archive mode. When archive mode is on, redo log files must be archived before they can be reused. Whether that is happening automatically or not depends on the next piece of output. Automatic archival Tells you whether automatic archival is enabled or disabled. If enabled, the ARCH process will be running. If disabled, you must manually archive log files as they are filled. Archive destination Tells you where the archive log files are going. This will be a directory path or a device name. In this example, the log files are being archived to C:\ORAWIN95\RDBMS80. Oldest online log sequence Redo log files are numbered sequentially. This tells you the number of the oldest file that has not yet been archived. The number itself has no meaning; it just increments forever. < previous page page_349 next page > < previous page page_350 next page > Page 350 Next log sequence to archive This is the sequence number of the next log file to be archived. When you first enable automatic archiving, this will be the same as the current log sequence. When Oracle switches to the next log file, this one will be archived. Current log sequence This is the sequence number of the log file currently being used. When the archive log process archives a redo log file by copying it to the archive destination, it gives the resulting file a new and unique name. The name usually includes the SID and the log sequence number, but the exact format is controlled by the LOG_ARCHIVE_FORMAT initialization parameter. See the Oracle8 Server Reference manual for detailed information on that and other initialization parameters. Manually archiving a log file If you have automatic archiving turned off, you can use the ARCHIVE LOG command to manually archive a redo log file. The syntax to use is: ARCHIVE LOG { [NEXT ¦ ALL ¦ integer] } where: Next Archives the next redo log file in sequence. All Catches you up by archiving all filled redo log files that haven't yet been archived. integer Archives a specific redo log file. The number supplied must be a valid log file sequence number, and that log file must still be online. The following example shows the NEXT option being used to manually archive the next log file in the sequence: SQL> ARCHIVE LOG NEXT 1 log archived. SQL> Stopping the archive log process You can stop the archive process by issuing the ARCHIVE LOG STOP command. For example: SQL> ARCHIVE LOG STOP Statement processed. < previous page page_350 next page > < previous page page_351 next page > Page 351 Stopping the archive process does not take the database out of archive log mode. Oracle will continue to fill redo log files, and these files must be archived before they can be reused. Because you've stopped the archive log process, you will need to manually archive these files. Fail to keep up, and Oracle will come to a complete stop when the last redo log file is filled. Turning off archive log mode To take the database out of archive log mode, you follow much the same process as you do when you put it into archive log mode. You should first shut down the database and take a cold backup. Even when turning archive log mode off, a backup is necessary because backups taken while archive log mode is on are not restorable without a complete set of archive logs. Once you've taken a cold backup, start the instance, mount the database, and issue the ALTER DATABASE NOARCHIVELOG command as shown in the following example: SQL> CONNECT INTERNAL Connected. SQL> STARTUP MOUNT ORACLE instance started. Total System Global Area 5138580 bytes Fixed Size 47252 bytes Variable Size 4608000 bytes Database Buffers 409600 bytes Redo Buffers 73728 bytes Database mounted. SQL> ALTER DATABASE NOARCHIVELOG; Statement processed. SQL> ALTER DATABASE OPEN; Statement processed. SQL> Once you've taken the database out of archive log mode, Oracle will cycle through and reuse the redo log files without waiting for them to be archived. You will no longer be able to perform point-in-time recovery of the database. The best you will be able to do if a disk failure occurs will be to restore the most recent full backup. Recovery Recovery is the process of restoring a database from backups and replaying all the transactions from the archived redo log files in order to bring the database up to date. Running a database in archive log mode gives you a great deal of flexibility in what you recover and how you do it. In a worst-case scenario, you can restore and recover the entire database. If you have only lost part of the database, you can perform recovery on either a tablespace or datafile basis. When recovering < previous page page_351 next page > < previous page page_352 next page > Page 352 specific tablespaces or datafiles, you may even be able to keep the rest of the database online and available. The recovery process generally consists of the following six steps: 1. Restore the data files from the most recent backup. 2. Make sure the necessary archive logs are available in the archive log destination directory. 3. Start up the instance, mount the database exclusively, but do not open it. 4. Use the SQL*Plus RECOVER command to reapply updates based on information in the archived log files. 5. Shut down the database. 6. Restart the instance, mount the database normally, and open it. The SQL*Plus RECOVER command is used in step 4 to reapply changes based on information in the redo log files. The next few sections explain how to use the RECOVER command when restoring the entire database, and when restoring just one tablespace or datafile. The examples in this book assume that the required database files have been restored, and that the archive log files are in the archive log destination directory. Full database recovery In order to restore and recover an entire database, you must first shut it down, then restore all the data files from the most recent backup. Do not restore the control file, and do not restore any redo log files. These should be multiplexed so you don't lose them in the event of a disk failure. It is possible to deal with extreme failures, such as losing all copies of your control file, but that information is well outside the scope of this book. The example here represents one of the simplest recovery scenarios, and is presented only to help explain the concepts behind the process. The next step in the recovery process is to restart the instance and mount the database in exclusive mode. Do not open the database, just mount it. Here's how: C:\Oracle\Ora81>SQLPLUS /NOLOG SQL*Plus: Release 8.1.3.0.0 - Beta on Tue Oct 20 20:05:48 1998 (c) Copyright 1998 Oracle Corporation. All rights reserved. < previous page page_352 next page > < previous page page_353 next page > Page 353 SQL> CONNECT INTERNAL Connected to an idle instance. SQL> STARTUP MOUNT ORACLE instance started. Total System Global Area 5355764 bytes Fixed Size 63732 bytes Variable Size 5013504 bytes Database Buffers 204800 bytes Redo Buffers 73728 bytes Database mounted. Once the database has been mounted, it's time to issue the appropriate RECOVER command, which is RECOVER DATABASE in this case. Here is an example: SQL> RECOVER DATABASE ORA-00279: change 15447 generated at 11/29/98 15:31:37 needed for thread 1 ORA-00289: suggestion : C:\ORAWIN95\DATABASE\ARCHIVE\ARC26.1 ORA-00280: change 15447 for thread 1 is in sequence #26 Specify log: {<RET>=suggested ¦ filename ¦ AUTO ¦ CANCEL} When you issue the RECOVER DATABASE command, Oracle will prompt you for the name of the first archive log file to apply. Part of this prompt will be a default path and filename, which is based on the current archive log settings in your database initialization file. Unless you have changed things or moved log files around, this default path and filename should be correct. If the log files are where Oracle expects them to be, all you have to do is press ENTER or RETURN. Otherwise, type in the correct path and filename, then press ENTER. Oracle will read changes from that log file and reapply those changes to the database. As Oracle finishes reading each log file, you will be prompted for the path and filename of the next file in the sequence. If all the log files are online and in the correct directory, you have an easy task ahead of you. Just press ENTER in response to each prompt. To make things even easier, you can take advantage of the autorecovery feature. Autorecovery is described in the section titled Autorecovery, later in this chapter. When all the log files have been read and all the updates reapplied to the database, you will get a message telling you that recovery is complete. You are now ready to open the database for general use. You can do that with the ALTER DATABASE command shown in the following example: SQL> ALTER DATABASE OPEN; Database altered. Tablespace and datafile recovery Running in archive log mode gives you the flexibility to recover a specific datafile or tablespace when it becomes damaged. This is faster than recovering the entire < previous page page_353 next page > < previous page page_354 next page > Page 354 database, and, as long as the SYSTEM tablespace is not lost, you can even perform the recovery while the rest of the database is up and running. As an example, let's say that you lose the disk containing one of the datafiles in the USER_DATA tablespace. The first thing you should do is take the tablespace offline. You can do that with the following command: ALTER TABLESPACE USER_DATA OFFLINE; Next, you need to restore the damaged datafile from the most recent backup. Since you will most likely need to put this file in a new location, you will need to issue the following command to update the database control file: ALTER TABLESPACE USER_DATA RENAME DATAFILE G:\ORACLE\INSTANCES\ORCL\USER_DATA_1. DAT TO H:\ORACLE\INSTANCES\ORCL\USER_DATA_1.DAT; Now you are ready to begin the recovery process. Make certain you have the required archive log files online. You will need all the log files generated since the backup of the datafile. Issue the following command from SQL*Plus: RECOVER TABLESPACE From this point forward, the recovery process works the same as when you are recovering the full database. You will be prompted for the name and location of each log file until the process is complete, at which time the tablespace will be back the way it was before you lost the disk. The last thing you need to do is bring the tablespace online again. The following command will do this: ALTER TABLESPACE USER_DATA ONLINE; Recovering a datafile can be done the same way as recovering a tablespace; the only difference is that you use the RECOVER DATAFILE command instead of RECOVER TABLESPACE. Autorecovery When you are recovering a database, if there are a lot of redo logs to apply, being prompted for each file quickly becomes tiresome. The autorecovery feature can help with this. It's normally off, but you can turn it on with the following SQL*Plus command: SET AUTORECOVERY ON With autorecovery on, you can issue the RECOVER command, and Oracle won't prompt you for the name of each log file. If you have already started recovering log files, you can kick the process into autorecovery mode by responding to one of the prompts with the keyword AUTO. The following example shows this: SQL> RECOVER DATABASE ORA-00279: change 340672 generated at 01/06/99 14:43:22 needed for thread 1 < previous page page_354 next page > < previous page page_355 next page > Page 355 ORA-00289: suggestion : C:\ORACLE\ORADATA\ORCL\ARCHIVE\%ORCL%T001S00568.ARC ORA-00280: change 340672 for thread 1 is in sequence #568 Specify log: {<RET>=suggested ¦ filename ¦ AUTO ¦ CANCEL} AUTO ORA-00279: change 340721 generated at 01/06/99 16:52:34 needed for thread 1 ORA-00289: suggestion : C:\ORACLE\ORADATA\ORCL\ARCHIVE\%ORCL%T001S00569.ARC ORA-00280: change 340721 for thread 1 is in sequence #569 ORA-00278: log file C:\ORACLE\ORADATA\ORCL\ARCHIVE\%ORCL%T001S00568. ARC no longer needed for this recovery ORA-00279: change 340723 generated at 01/06/99 16:52:41 needed for thread 1 ORA-00289: suggestion : C:\ORACLE\ORADATA\ORCL\ARCHIVE\%ORCL%T001S00570.ARC ORA-00280: change 340723 for thread 1 is in sequence #570 ORA-00278: log file C:\ORACLE\ORADATA\ORCL\ARCHIVE\%ORCL%T001S00569. ARC no longer needed for this recovery ORA-00279: change 340725 generated at 01/06/99 16:52:50 needed for thread 1 ORA-00289: suggestion : C: \ORACLE\ORADATA\ORCL\ARCHIVE\%ORCL%T001S00571.ARC ORA-00280: change 340725 for thread 1 is in sequence #571 ORA-00278: log file C:\ORACLE\ORADATA\ORCL\ARCHIVE\%ORCL%T001S00570. ARC no longer needed for this recovery Log applied. Media recovery complete. After responding with AUTO, you won't be prompted for any more file names. Autorecovery works only if all the needed log files are where Oracle expects. This is the same location you see when you issue the ARCHIVE LOG LIST command. If Oracle looks for a file and can't find it, you will be prompted once again. Other Things You Need to Know There are a lot of other permutations to backup and recovery than are covered in this chapter. The information in this chapter highlights the role SQL*Plus can play in a backup and recovery plan, but there are other tools you can use. Oracle's Recovery Manager, or RMAN, is one of them. RMAN can be used instead of operating-system commands to back up datafiles. RMAN can also be used instead of SQL*Plus to initiate the recovery process. The examples in this chapter show you how to restore a full database or a tablespace. There are other things you could lose that would require a different recovery strategy. You could, for example, lose one of the disks containing your redo log files. Recovering from that requires a different procedure from that used by the examples in this chapter. When running in archive log mode, you don't necessarily need to back up your entire database at any one time. You can back up one tablespace today, another tomorrow, and so forth. There is even one situation where you can perform point-in- time recovery on a database that is not in archive log mode. < previous page page_355 next page > . need all the log files generated since the backup of the datafile. Issue the following command from SQL* Plus: RECOVER TABLESPACE From this point forward, the recovery process works the same as. and unique name. The name usually includes the SID and the log sequence number, but the exact format is controlled by the LOG_ARCHIVE_FORMAT initialization parameter. See the Oracle8 Server Reference. be online. The following example shows the NEXT option being used to manually archive the next log file in the sequence: SQL& gt; ARCHIVE LOG NEXT 1 log archived. SQL& gt; Stopping the archive