Tài liệu ORACLE8i- P12 pptx

Backup and Recovery in NOARCHIVELOG Mode With the database in NOARCHIVELOG mode, the online redo logs are overwrittenwithout regard to recoverability of the database.. Performing Cold Ba

Shut down and remount the database. This is required to put thedatabase in ARCHIVELOG mode Once the database is shut down, proceed tomount it again After you remount it, the ARCH process should be running.

Put the database in ARCHIVELOG mode and open it. At thispoint, you can put the database in ARCHIVELOG mode by using the ALTERDATABASE ARCHIVELOG command Then open the database by issuing theALTER DATABASE OPEN command

Next, you will want to test the configuration of the ARCH process Why? Well, ifyou incorrectly set up ARCH so that it is writing to a directory that doesn’t exist,guess what will happen soon: The database will come to a screeching halt This hap-pens because Oracle will not allow you to overwrite the online redo log file untilARCH can write out the archived redo logs successfully If you are trying to archive to

a destination that doesn’t exist, these attempts to create the archived redo logs willfail To test your configuration, issue an ALTER DATABASE SWITCH LOGFILE com-mand Then check the archived log destinations a few moments later You should see

an archived redo log file created in those directories If these files are created, you are

in good shape

After you put the database in ARCHIVELOG mode and test your configuration, youshould proceed to perform a hot backup as quickly as possible Then you will be able

to recover your database using the archived redo logs, if necessary

Considering Online Redo Log Groups

In NOARCHIVELOG mode, there is only one basic rule that Oracle follows in relation

to redo log switches: Before an online redo log can be used, the changes representedwithin the redo it contains from its last use must have been written to the databasedatafiles Thus, Oracle will not reuse a redo log if its previous contents have not beenwritten to the database datafiles This rule is in place to facilitate crash and instancerecovery of the database

In ARCHIVELOG mode, things get a bit more complicated When a log switchoccurs, Oracle will first update the control file, indicating that the redo log needs to

be archived It will then signal the ARCH process, indicating that it has a redo log toprocess The ARCH process will wake up (assuming it’s not processing another onlineredo log file already) and begin to copy that online redo log to the archived redo log

directory defined in the init.ora file (by the ARCHIVE_LOG_DEST_n parameter).

During the ARCH copy process, Oracle will proceed to the next available online redolog and continue database activity as normal

If Oracle proceeds through the remaining redo log groups and returns to the redolog group you are archiving, it will not reuse that online redo log until the archivingprocess has completed successfully for that online redo log file If Oracle cannot usethat online redo log, it will look for another available online redo log If no onlineredo log is available, then the Oracle database will be suspended until the ARCHprocess has completed its moves Once ARCH completes the move of the online redolog, it will update the control file, indicating that the online redo log has beenarchived At that point, LGWR will be able to open and use the online redo log.

The log switch process in ARCHIVELOG can pose a problem if you don’t haveenough online redo log files (and/or if they are too small), because Oracle may not beable to write out the archived redo logs fast enough to keep up with the redo creationwithin the online redo logs Thus, you may find that your database activity becomessuspended quite often—not a condition that users or managers desire

Something else to consider is the number of archive log destinations you will have

Adding a destination will increase the time it takes to archive your online redo logs Ifyou add a network destination, that will further erode the performance of the archiv-ing process There are several possible solutions to this problem:

• Add enough log file groups of sufficient size to reduce contention with thearchiving process

• Reduce the number of archiving destinations

• Carefully tune the I/O Try to separate the archived logs onto their own disks toreduce the I/O contention that ARCH might incur

Backup and Recovery in NOARCHIVELOG Mode

With the database in NOARCHIVELOG mode, the online redo logs are overwrittenwithout regard to recoverability of the database Thus, the only backup option is a

cold backup A cold backup of a database is a backup that takes place while the

data-base is shut down Thus, during the period that the cold backup takes place, users willhave no access to the database or the data within it

When you perform a cold backup in NOARCHIVELOG mode, you simply back upthe entire physical structure of the database A cold backup in NOARCHIVELOGmode includes backups of the following:

• All database datafiles

• All database control files

Oracle Database Administration

P A R T

II

• All online database redo logs

• Other required database files such as init.ora The following sections describe the procedures for backing up and recovering a database in NOARCHIVE mode

Performing Cold Backups in NOARCHIVELOG Mode

To perform a cold backup, you simply identify the database files to be backed up, shut down the database, and back up the physical files to the backup medium Then you can start the database again

You might wonder why you need to shut down the database for a cold backup if you can ensure that nobody will make any changes to the database while it is up As explained in Chapter 5, one method that Oracle uses to determine that the database

is in a consistent state is by virtue of a fuzzy file flag maintained in each database datafile If the fuzzy datafile flag is set when the database starts, the database will con-sider the datafile to be fuzzy Thus, if you recover a datafile that was backed up while the database was running, even if the database had no activity, that backup is not usable for recovery purposes This is because the fuzzy flag will have been set in the open position There are some ways to force the database open in these cases (as you will learn later in this chapter), but these methods are not recommended

Identifying the Files to Back Up

To locate the database datafiles, control files, and online redo logs to back up, you can use some data dictionary queries Use the DBA_DATA_FILES data dictionary view to find the database datafiles, as in this example:

SELECT tablespace_name, file_name, file_id FROM dba_data_files

ORDER BY tablespace_name, file_name;

TABLESPACE_NAME FILE_NAME FILE_ID

- -

-IDX D:\ORACLE\ORADATA\RECOVER\RECOVER_ -IDX_01.DBF 4

RBS D:\ORACLE\ORADATA\RECOVER\RECOVER_RBS_01.DBF 2

SYSTEM D:\ORACLE\ORADATA\RECOVER\SYSTEM01.DBF 1

TEMP D:\ORACLE\ORADATA\RECOVER\RECOVER_TEMP_01.DBF 5

USERS D:\ORACLE\ORADATA\RECOVER\RECOVER_USERS_01.DBF 3

To find the database control files, query the V$CONTROL_FILE data dictionary view:

SQL> SELECT * FROM v$controlfile;

STATUS NAME - -

D:\ORACLE\ORADATA\RECOVER\CONTROL01.CTLD:\ORACLE\ORADATA\RECOVER\CONTROL02.CTLD:\ORACLE\ORADATA\RECOVER\CONTROL03.CTL

Finally, use a query to the V$LOGFILE data dictionary view to locate the databaseonline redo log files:

SQL> SELECT * FROM v$logfile;

GROUP# STATUS MEMBER - - -

1 D:\ORACLE\ORADATA\RECOVER\REDO01.LOG

2 STALE D:\ORACLE\ORADATA\RECOVER\REDO02.LOG

3 D:\ORACLE\ORADATA\RECOVER\REDO03.LOG

Running the Backup

After you’ve identified the database files, you’re ready to perform a cold backup To do

so, you must first shut down the database When shutting down the database for acold backup, it is strongly recommended that you use either the normal SHUTDOWN

command or the SHUTDOWN IMMEDIATE command This will cause DBWn to flush

all dirty buffers to the database datafiles As long as you have issued either a DOWN or SHUTDOWN IMMEDIATE command, you will not need to recover (or backup) the online redo log files for the database

SHUT-Now, you can proceed to back up the physical database files that you identified Toshorten the time of the overall outage required to back up the database, you may wish

to back up the datafiles to disk, open the database, and then back up the other files toslower backup medium, such as tape It is often advisable to include in your finalbackup image a copy of a backup control file (aside from the backup of the current

control file) A backup control file is a backup of the control file that can be used to

recover the control file in the event that it is lost We will discuss the creation of abackup control file later in this chapter, in the “Control File Backups” section Whenyou’re finished backing up the database, you can open the database again Listing 10.1shows an example or running a cold backup in NOARCHIVELOG mode

NOTE All of the examples in this chapter were done on Windows NT The principles arethe same, regardless of the operating system Only the operating system commands (such

as copy, cp, tar, or tape backup) are different

Oracle Database Administration

P A R T

II

Listing 10.1: Performing a Cold Backup in NOARCHIVELOG Mode

D:\ORACLE\ORA816\DATABASE>sqlplus “sys/robert as sysdba”

SQL> SHUTDOWN IMMEDIATEDatabase closed

Database dismounted

ORACLE instance shut down

Now we are going to back up the database Note that we have a pretty poorly set up database here, because everything is on one drive We did that mostly just to keep the example easy and to save page space

SQL> HOST MKDIR d:\backup_oracleSQL> HOST COPY d:\oracle\oradata\recover\*.* d:\backup_oracle\*.*d:\oracle\oradata\recover\CONTROL01.CTL

d:\oracle\oradata\recover\CONTROL02.CTLd:\oracle\oradata\recover\CONTROL03.CTLd:\oracle\oradata\recover\REDO01.LOGd:\oracle\oradata\recover\REDO02.LOGd:\oracle\oradata\recover\REDO03.LOGd:\oracle\oradata\recover\SYSTEM01.DBFd:\oracle\oradata\recover\RECOVER_RBS_01.DBFd:\oracle\oradata\recover\RECOVER_USERS_01.DBFd:\oracle\oradata\recover\RECOVER_TEMP_01.DBFd:\oracle\oradata\recover\afiedt.buf

d:\oracle\oradata\recover\recover_idx_01.dbf.backupd:\oracle\oradata\recover\RECOVER_IDX_01.DBF

13 file(s) copied

Backup is complete, restart the database

SQL> STARTUPORACLE instance started

Total System Global Area 92280076 bytesFixed Size 70924 bytesVariable Size 87937024 bytesDatabase Buffers 4194304 bytesRedo Buffers 77824 bytesDatabase mounted

Database opened

NOTE Listing 10.1 and many other examples start SQL*Plus or connect to the databaseusing the ”/ as sysdba” or “sys/robert as sysdba” string This is done for two reasons First,Oracle will be dropping support for CONNECT INTERNAL in Oracle9i, so we are trying toprepare for that eventuality Second, with Oracle release 8.1.6, we are forced to put theusername and password on the command line This is due to a bug in 8.1.6 that was fixed

in 8.1.7 If you are running 8.1.7, you can use “system as sysdba” with SQL*Plus, and thenrespond to the password prompt that follows

Recovering Cold Backups in NOARCHIVELOG Mode

Recovering a database from a cold backup taken in NOARCHIVELOG mode is fairlysimple Issue a SHUTDOWN ABORT command on the database instance to make surethat all the database processes are stopped and all operating system locks on files thatmight remain are released Then recover all of the database files to their original loca-tions, if possible If this is not possible, record the new location of the database filesfor later use If any of the files were recovered to a different location, you will need toreset the location as follows:

• If the control files were recovered to a different location, edit the database eter file to reflect the new location for the control files Change any other direc-tory paths that might have changed as a result of the recovery process

param-• If the database datafiles or the redo logs were recovered to another location, youwill need to mount the database by issuing a STARTUP MOUNT command

Issue the ALTER DATABASE RENAME FILE command for each datafile that wasrecovered to another location

• If the online redo logs were recovered to another location, issue the ALTERDATABASE RENAME FILE command to reset the location of the database onlineredo logs

When all of the database files have been recovered, issue the STARTUP command,and the database should open normally Listing 10.2 provides an example of recover-ing a database that was backed up in NOARCHIVELOG mode (Note that due to bookpage line-length restrictions, some code is broken into multiple lines.)

Listing 10.2: Performing a Cold Backup Recovery in NOARCHIVELOG Mode

D:\ORACLE\oradata\RECOVER>sqlplus “sys/robert as sysdba”

SQL> STARTUP

Oracle Database Administration

P A R T

II

ORACLE instance started.

Total System Global Area 92280076 bytesFixed Size 70924 bytesVariable Size 87937024 bytesDatabase Buffers 4194304 bytesRedo Buffers 77824 bytesDatabase mounted

ORA-01157: cannot identify/lock datafile 4 - see DBWR trace fileORA-01110: datafile 4: ‘D:\ORACLE\ORADATA\RECOVER\RECOVER_IDX_01.DBF’SQL> SHUTDOWN ABORT

ORACLE instance shut down

Recover the database from the backup we made earlier

SQL> HOST COPY d:\backup_oracle\*.*

d:\oracle\oradata\recover\recover_idx_01.dbfd:\backup_oracle\CONTROL01.CTL

d:\backup_oracle\CONTROL02.CTLd:\backup_oracle\CONTROL03.CTLd:\backup_oracle\REDO01.LOGd:\backup_oracle\REDO02.LOGd:\backup_oracle\REDO03.LOGd:\backup_oracle\SYSTEM01.DBFd:\backup_oracle\RECOVER_RBS_01.DBFd:\backup_oracle\RECOVER_USERS_01.DBFd:\backup_oracle\RECOVER_TEMP_01.DBFd:\backup_oracle\afiedt.buf

d:\backup_oracle\recover_idx_01.dbf.backupd:\backup_oracle\RECOVER_IDX_01.DBF

1 file(s) copied

SQL> STARTUPORACLE instance started

Total System Global Area 92280076 bytesFixed Size 70924 bytesVariable Size 87937024 bytesDatabase Buffers 4194304 bytesRedo Buffers 77824 bytesDatabase mounted

Database opened

If you were not able to recover the online redo logs from the backup medium, youcan still recover the database in many cases First, if you were able to recover at least onemember of each redo log group, you can create a copy of that online redo log, naming itwith the name of the missing online redo log If none of the online redo logs are avail-able, as long as you shut down your database normally (or with the IMMEDIATEoption), all you need to do is open the database with the following command:

ALTER DATABASE OPEN RESETLOGS;

We will discuss the RESETLOGS command in more detail later in this chapter, inthe “RESETLOGS and Recovery” section For now, suffice it to say that issuing thiscommand will cause the database to create new redo logs Also, if the control file ismissing, you can recover using the backup control file, as described in the “ControlFile Backups” section later in this chapter

Backups in ARCHIVELOG Mode

The principle difference between NOARCHIVELOG mode and ARCHIVELOG mode isthe creation of archived redo logs, and associated with that, the ability to back up thedatabase while it is still running and recover the database to point of failure, or somepoint prior to that failure It is this functionality and reliability that make Oracle themost popular database in the world

Performing Cold Backups in ARCHIVELOG Mode

Cold backups in ARCHIVELOG mode are much the same as those in NOARCHIVELOGmode, except that you don’t need to back up the online redo logs or the control files

It is best not to back up online redo logs during backups in ARCHIVELOG mode(unless you are not saving the archived redo logs), because you do not want to acciden-tally recover them over existing online redo logs during a recovery Also, overwritingthe existing control file will hamper your ability to recover the database to the point offailure Instead, create a backup control file, as discussed later in this chapter in the

“Control File Backups” section

The steps for performing a cold backup in ARCHIVELOG mode are as follows:

1 Identify the database datafiles to be backed up.

2 Shut down the database.

3 Back up the physical datafiles to the backup medium.

4 Start the database.

Oracle Database Administration

P A R T

II

5 Back up the existing archived redo log (This is not really a requirement at this

point if you shut down the database normally, but it’s good practice.)

6 Back up the archived redo logs on a regular basis.

All of these steps, except the last two, are the same as those for a cold backup inNOARCHIVE mode Steps 5 and 6 pertain to backing up archived redo logs, which iscovered in the next section

Backing Up Archived Redo Logs

When you are doing any backup in ARCHIVELOG mode, it is assumed (and in thecase of hot backups, required) that the archived redo logs created during the time ofthe backup are themselves backed up It is the backup of these logs (and subsequentbackups of newly created archived redo logs) that allows an Oracle database inARCHIVELOG mode to be recovered

When recovering from hot backups, all of the archived redo logs generated duringthe hot backup are required during the recovery process In addition, if you wish torecover the database to a point beyond the point of recovery, you will need all of thegenerated archived redo logs as well As explained earlier in this chapter, the location

of the archived redo logs is defined in the init.ora file using the LOG_ARCHIVE_

DEST_n parameter You can query the V$ARCHIVE_DEST data dictionary view to

determine the current location of the archived log directories, as follows:

SELECT destination FROM v$archive_dest;

DESTINATION -D:\Oracle\oradata\Recover\archive

NOTE The V$ARCHIVE_DEST data dictionary view contains a row for each destination,even if the destination is not defined

How often should archived redo logs be backed up? The answer to the question isreally another question: How much data loss can you tolerate? Since the archivedredo logs are typically stored on the same system as the database that generated them,there is some risk of loss of these files When configuring your database, you shouldgive careful consideration to using alternative storage locations, such as networkappliances or other options, to reduce the risk of datafile loss

Also keep in mind the performance implications of your archived redo log rations The more archived redo log destinations you configure, the longer the ARCHprocess will take to copy each archived redo log If you are copying these over the net-work (to a standby database in Net8), this may even further impact the overall perfor-mance of the ARCH process Remember that Oracle will not be able to reuse an onlineredo log until all required copies to archive locations are complete.

configu-NOTE Besides being useful for recovery, archived redo logs can also be run through theOracle8i utility called LogMiner, which we will cover in Chapter 14 LogMiner allows you toreview the archived redo logs for security audits and other purposes Archived redo logsare also used to keep standby databases current, as explained in Chapter 26, which dis-cusses high-availability options

Performing Hot Backups in ARCHIVELOG Mode

Now we reach the big time—hot backups in ARCHIVELOG mode When you ment hot backups in your database, you enter a whole new world of recovery options

imple-When doing hot backups, you simply do not back up control files and online redologs What you do is put tablespaces in hot backup mode These tablespaces are asso-ciated with the datafiles that you have chosen to back up

When you put tablespaces in hot backup mode, Oracle generates block-level redo tothe online redo logs, as opposed to the normal atomic redo records that are createdwhen the tablespaces are not in hot backup mode This means that all redo generatedfor the tablespace is generated as an image of the entire block, rather than as just redorecords Thus, redo generation is substantially increased during hot backup operations(however, this is not true with RMAN hot backups, which are discussed in Chapter 13)

Block images are recorded in the redo logs to avoid problems with operating tem block splitting Since Oracle continues to write to database datafiles during hotbackups, there is a possibility that the backed up image of the datafile will containfractured blocks This is because the operating system write batch size may be smallerthan the block size of the database, so the backup image of a given datafile may con-tain a block that is of two different versions The generation of block images in theonline redo logs solves this problem by allowing the block to be restored during thebackup process

sys-Oracle Database Administration

P A R T

II

TI P Because of the increased level of redo generation during hot backups, as well asthe general performance impacts associated with moving large amounts of data (such ascopying database datafiles to tape), you should try to schedule database backups duringlow-usage hours.

Performing hot backups is not a complicated task Here are the basic steps:

1 Identify the database datafiles to be backed up You also need to identify the

associated tablespace names

2 Determine the current log sequence number.

3 For each tablespace that is associated with the datafiles to be backed up, put that

tablespace in hot backup mode

4 Back up the physical database datafiles that are associated with the tablespace

put in hot backup mode

5 As each tablespace backup is complete (or you have completed backups for all

the datafiles of a given tablespace), take that tablespace out of hot backup mode

6 Once the backups are complete and all tablespaces are out of hot backup mode,

force a log switch

7 Back up all of the archived redo logs

8 Create backup control files

9 Back up the archived redo logs on a regular basis.

Let’s look at these steps in a bit more detail

Identifying the Database Files and Associated Tablespaces

Since you need to put the tablespaces of the database datafiles in hot backup mode,you need to know not only the location of the database datafiles, but also the table-spaces they are associated with You can find this information via a query to theDBA_DATA_FILES data dictionary view (as shown in Listing 10.3, a bit later in thischapter)

Hot backups allow you to selectively back up different tablespaces at differenttimes Therefore, if you wanted to back up the DATA tablespace tonight, and theINDEX tablespace tomorrow night, you could—although good arguments could bemade not to do this In fact, you don’t even need to back up every datafile of a giventablespace Again, this isn’t good practice, because it becomes a lot more difficult tomanage backups created this way and can lead to situations where the database may

be unrecoverable

For example, suppose that you backed up one datafile belonging to the DATAtablespace two weeks ago and the other two datafiles a week ago Now suppose thatyour database crashes, and you lose all three datafiles You would need to recover theone datafile from two weeks ago and the two other datafiles from a week ago Also,you would need to recover the archived redo logs to apply recovery If you couldn’tget the one datafile off the tape from two weeks ago, you would be in bad shape andwould probably be unable to recover the database Thus, it is normally good practice

to back up all associated datafiles with a given tablespace during a backup

Determining the Current Log Sequence Number

Before starting the backup, you should determine the current log sequence number

You will need to make sure that you back up this log sequence number, along with alllogs generated during the backup, after the backup has completed Use the ARCHIVELOG LIST command to get this information (see Listing 10.3)

Putting Tablespaces in Hot Backup Mode

The hot backup bit is set in the database datafiles when you issue the ALTER SPACE BEGIN BACKUP command:

TABLE-ALTER TABLESPACE idx BEGIN BACKUP;

This command places the tablespace in hot backup mode, flipping the fuzzy backup bit

If you want to determine if a database datafile is in hot backup mode, you canquery the V$BACKUP view The STATUS column in this view will indicate the valueACTIVE if the tablespace is in hot backup mode (see Listing 10.3)

If the database should crash or you issue a SHUTDOWN ABORT command while atablespace is in hot backup mode, you will need to reset the datafiles associated withthe tablespace so that they are no longer in hot backup mode To do this, you use the

ALTER DATABASE DATAFILE filename END BACKUP command Here is an example:

SQL> ALTER TABLESPACE idx BEGIN BACKUP;

Tablespace altered

SQL> SHUTDOWN ABORTORACLE instance shut down

SQL> STARTUPORACLE instance started

Total System Global Area 92280076 bytesFixed Size 70924 bytesVariable Size 87937024 bytesDatabase Buffers 4194304 bytesRedo Buffers 77824 bytes

Oracle Database Administration

P A R T

II

Database mounted.

ORA-01113: file 4 needs media recoveryORA-01110: datafile 4: ‘D:\ORACLE\ORADATA\RECOVER\RECOVER_IDX_01.DBF’SQL> ALTER DATABASE DATAFILE 4 END BACKUP;

Backing Up the Datafiles

You can use any standard copy facility (cp, copy, tar, gzip, and so on) to copy thedatabase files to the backup media that you wish to use As mentioned earlier, it’sprobably a good idea to back up all of the associated datafiles, but this is not required.All that is required for recovery is the presence of all the associated datafiles (backed

up with the database in hot backup mode or the current database datafiles) and thearchived redo logs to make those files consistent

Completing the Backup

Once you have completed backing up the datafiles for a given tablespace, take thattablespace out of hot backup mode, using the ALTER TABLESPACE END BACKUPcommand (see Listing 10.3)

Your next step is to force a redo log switch This is because you will need all of theredo generated during the hot backup (and since the database is open to users during

a hot backup, you will be generating redo) to recover the database datafiles you havebacked up After forcing a log switch, back up all archived redo logs generated duringthe backup, as well as the archived redo log generated by the log switch

To force the redo log switch after you have taken each tablespace out of hot backupmode, issue the ALTER SYSTEM SWITCH LOGFILE command You can determinewhich log sequence numbers you need to make sure are backed up by issuing theARCHIVE LOG LIST command from either Server Manager or SQL*Plus when con-nected as INTERNAL Run this command both before the hot backups (finding thecurrent log sequence number) and before issuing the ALTER SYSTEM SWITCH LOG-FILE command (again finding the current log sequence number) This will tell you thelow and high log sequence numbers that you must back up in order to recover thehot backup you just made

Listing 10.3 provides an example of a complete hot backup In this example, thedatabase files reside in d:\oracle\oradata\recover These datafiles are backed up tod:\oracle_backup\hot, and the archived redo logs are backed up to d:\oracle_

backup\hot\archive

Listing 10.3: Running a Hot Backup

First, get the tablespace names and filenames and locations

SQL> SELECT tablespace_name, file_name, file_idFROM dba_data_files

ORDER BY tablespace_name, file_name;

TABLESPACE_NAME FILE_NAME FILE_ID - -IDX D:\ORACLE\ORADATA\RECOVER\RECOVER_IDX_01.DBF 4RBS D:\ORACLE\ORADATA\RECOVER\RECOVER_RBS_01.DBF 2SYSTEM D:\ORACLE\ORADATA\RECOVER\SYSTEM01.DBF 1TEMP D:\ORACLE\ORADATA\RECOVER\RECOVER_TEMP_01.DBF 5USERS D:\ORACLE\ORADATA\RECOVER\RECOVER_USERS_01.DBF 3

Get the current log sequence numberSQL> ARCHIVE LOG LIST

Database log mode Archive ModeAutomatic archival EnabledArchive destination D:\Oracle\oradata\Recover\archiveOldest online log sequence 216

Next log sequence to archive 218Current log sequence 218

Now, put the tablespaces in hot backup mode

Note that if we wanted to just back up a specific tablespace, we would execute this statement only for that tablespace

SQL> ALTER TABLESPACE idx BEGIN BACKUP;

SQL> ALTER TABLESPACE users BEGIN BACKUP;

Tablespace altered

Check the status of all the database datafiles

SQL> SELECT * FROM v$backup;

FILE# STATUS CHANGE# TIME - - - -

5 file(s) copied

Now, end the backup status of the tablespaces

SQL> ALTER TABLESPACE idx END BACKUP;

Check the status of all the database datafiles

They should all now show not active

SQL> SELECT * FROM v$backup;

FILE# STATUS CHANGE# TIME - - - -

1 NOT ACTIVE 176503 28-APR-01

2 NOT ACTIVE 176502 28-APR-01

3 NOT ACTIVE 176505 28-APR-01

4 NOT ACTIVE 176501 28-APR-01

5 NOT ACTIVE 176504 28-APR-01

Find out what the active online redo log sequence number is We need to make sure this one gets backed up We want to make sure we back up from log sequence number 218 to 219

SQL> ARCHIVE LOG LIST;

Database log mode Archive ModeAutomatic archival EnabledArchive destination D:\Oracle\oradata\Recover\archiveOldest online log sequence 217

Next log sequence to archive 219Current log sequence 219

Now, force a log switch

SQL> ALTER SYSTEM SWITCH LOGFILE;

System altered

Now, back up the archived redo logs generated during the backup

Optionally, you can delete the archived redo logs once they are backed up to save space

SQL> HOST COPY d:\oracle\oradata\recover\archive\*.*

d:\oracle_backup\hot\archive\*.*

d:\oracle\oradata\recover\archive\RECOVERT001S00215.ARCd:\oracle\oradata\recover\archive\RECOVERT001S00216.ARCd:\oracle\oradata\recover\archive\RECOVERT001S00217.ARCd:\oracle\oradata\recover\archive\RECOVERT001S00218.ARCd:\oracle\oradata\recover\archive\RECOVERT001S00219.ARC

3 file(s) copied

The backup is complete The database is recoverable

Oracle Database Administration

P A R T

II

Ongoing Backups of Archived Redo Logs

The Achilles heel of hot backups is their dependence on archived redo logs for ery You simply must have all of the logs in order to recover the database completely

recov-If you have a gap in the redo log sequence numbers, recovery to the point of the crashwill not be possible (although you should be able to do an incomplete recovery,unless you don’t have all the archived redo log files generated during a backup).Because the archived redo logs are so important, you need to have a good backupstrategy to make sure that they are protected In some environments, disk space tostore archived redo logs is limited as well Again, a good backup strategy in such a sit-uation is critical A full archive log directory will eventually cause the database tostall, because ARCH will not be able to process archived redo logs, and therefore it willnot be able to release online redo logs for the database to use

Recoveries in ARCHIVELOG Mode

One of the huge advantages of using ARCHIVELOG mode is that it offers a wealth ofrecovery options You can perform complete or incomplete recoveries Completerecoveries include recovery of datafiles, tablespaces, or the entire database The threekinds of incomplete recoveries that Oracle provides are time-based, change-based, andcancel-based

Preparing for Recovery

You generally know when you have a problem—the users start calling and your toring system starts sending out panic e-mail messages It’s time for you to don yourcape and earn your keep When presented with a recovery situation, you first need tofigure out what the problem is This is where understanding the internals of the Oracledatabase comes in handy Sometimes that experience and understanding can make thedifference between a 30-second outage and having the system down for days

moni-When presented with a problem, you need to proceed through a mental checklist.Start your checklist with the easiest things to fix and the most likely things to gowrong, and work your way down to the unlikely Has the whole database crashed? Arethe users getting any error messages? Has the database really crashed or is it juststalled? Check the alert log for any messages that might be helpful Have the userssend you any messages they may be getting (though applications frequently trapthese messages, so the users never send them)

TIP When presented with a database that will not come up (say, after a power outage

or an aborted shutdown) and says it needs media recovery, your first response shouldalways be to issue a RECOVER DATABASE command Just because the database says itneeds media recovery doesn’t mean you need to recover database datafiles

When your database is troubled, the V$ views are frequently of great help Table 10.3lists the V$ views that can be handy to use during backup and recovery operations

Generally, many of these views become available as the database startup process ceeds For example, when the database is mounted, you have access to the V$DATAFILEview This view provides you with a wealth of information on the status of the databasedatafiles This same view will let you know if a database datafile has gone AWOL, byindicating a status of OFFLINE for that datafile Also, mismatches between the controlfile and the FILE$ data dictionary table will be reported in this view If you see a file

pro-named MISSINGxxx in this view, that’s the problem We will talk more about this later

in this chapter in our discussion on control file recovery issues

TABLE 10.3: V$ VIEWS FOR BACKUP AND RECOVERY

V$DATAFILE Provides datafile information from the control file

V$ARCHIVE_DEST Provides various information on the archive log

destinations

V$ARCHIVED_LOG Provides information on archived redo logs

V$ARCHIVE_PROCESSES Provides information on the ARCH processes currently

running on the database

V$BACKUP Provides status information on database datafiles in hot

backup mode

V$DATABASE Provides various database information, such as if it is in

ARCHIVELOG mode or NOARCHIVELOG mode

V$INSTANCE_RECOVERY Provides various information on the different systems

used by Oracle to speed up recovery These differentrecovery processes are influenced by parameters such asfast_start_io, log_checkpoint_timeout, and log_check-point_interval

V$LOG Contains various information on the current redo logs

that comes from the control file

Oracle Database Administration

P A R T

II

TABLE 10.3: V$ VIEWS FOR BACKUP AND RECOVERY (CONTINUED)

V$LOGFILE Contains information on the current redo logs

V$LOG_HISTORY Contains information on the archived redo logs

gener-ated by the database

V$RECOVER_FILE Contains information on the recovery status of a datafile

After you’ve identified the problem, you need to determine what it will take to rect the problem Sometimes, you just need to get a system administrator to remount

cor-a file system thcor-at went cor-awcor-ay for some odd recor-ason Other times, it’s cor-a hcor-ardwcor-are issuethat needs to be resolved If it turns out to be a problem with lost database datafiles,recover only those datafiles that have problems There is no need to recover the entiredatabase, unless the whole database has problems

In general, determining what you need to recover requires the following steps:

1 Make sure that all hardware problems are corrected.

2 If the database is still running, recover only the datafiles or tablespaces that

were lost Check to ensure that you did not lose a redo log member or a controlfile copy

3 If the database has crashed, try to start the database If it says it needs media

recovery, issue the RECOVER DATABASE command Often, this will work

4 If the database instance will not start, check again for hardware problems,

par-ticularly memory and memory configuration issues

5 If the instance will start but the database complains that it cannot find the

con-trol file, you will need to use a backup concon-trol file to recover the database

6 Once the instance will mount, use the V$ views (see Table 10.3) to determine

which database datafiles need recovery

7 Proceed with the most expedient type of database recovery (datafile, tablespace,

or entire database) for your situation

Using the Recover Command

The RECOVER command is used to recover entire databases, specific tablespaces, orspecific datafiles, as well as for the three types of incomplete recoveries Table 10.4shows the most common parameters used with the RECOVER command The

RECOVER command should be issued from a database account that has DBA leges such as SYS or SYSTEM, or when connected to the database as INTERNAL

privi-TABLE 10.4: COMMONLY USED RECOVER COMMAND PARAMETERS

USING BACKUP CONTROLFILE Indicates that a backup control file is being used

dur-ing the recovery processUNTIL CANCEL Indicates a cancel-based recovery

UNTIL TIME <time string> Indicates a time-based recovery

UNTIL CHANGE <scn> Indicates a change-based recovery

FROM <location> Provides an alternate archived redo log location to

use during the recovery

AUTOMATIC Causes the RECOVER command to generate its own

list of suggested redo logs to apply, and will applythose logs without stopping for user interactionFROM Defines an alternate location for the archived redo

logs that are to be applied

PARALLEL [degree] NOPARALLEL Allows for parallel recovery processing or disabling of

parallel processing (this parameter overrides the ting of the RECOVERY_PARALLELISM parameter)

set-When the database starts its recovery exercise, it will start applying the archivedredo logs to the database datafiles to make them consistent As the recovery processcycles through each log file, it will prompt you for an action with a message thatlooks like this:

SQL> RECOVER DATAFILE 4ORA-00279: change 76361 generated at 04/25/2001 19:15:30 needed for thread 1

ORA-00289: suggestion :D:\ORACLE\ORADATA\RECOVER\ARCHIVE\RECOVERT001S00206.ARCORA-00280: change 76361 for thread 1 is in sequence #206Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

So, what is the meaning of this? Oracle says that it needs a particular log sequencenumber to start the recovery process Oracle will sit and wait for you to respond withsome form of input

Oracle Database Administration

P A R T

II