Oracle SQL Plus The Definitive Guide- P39 ppt

SQL> Once you've put the database into archive log mode, you will want to start the archive log process.. Displaying the archive log status Once archive log mode has been enabled, you ca

Trang 1

< 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

Trang 2

SQL> CONNECT INTERNAL

Connected

Trang 3

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:

Trang 4

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

Trang 5

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

Trang 6

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:

Connected

SQL> STARTUP MOUNT

Database mounted

SQL> ALTER DATABASE NOARCHIVELOG;

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

Trang 7

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

Trang 8

Connected to an idle instance

SQL> STARTUP MOUNT

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:

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

Trang 9

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

Trang 10

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-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

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

Định dạng
Số trang	10
Dung lượng	166,78 KB