Thông tin tài liệu
CHAPTER 10 • PHYSICAL BACKUP AND RECOVERY
434
Shut down and remount the database. This is required to put the
database in ARCHIVELOG mode. Once the database is shut down, proceed to
mount it again. After you remount it, the ARCH process should be running.
Put the database in ARCHIVELOG mode and open it. At this
point, you can put the database in ARCHIVELOG mode by using the ALTER
DATABASE ARCHIVELOG command. Then open the database by issuing the
ALTER DATABASE OPEN command.
Next, you will want to test the configuration of the ARCH process. Why? Well, if
you 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 until
ARCH 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 will
fail. 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, you
should 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 represented
within the redo it contains from its last use must have been written to the database
datafiles. Thus, Oracle will not reuse a redo log if its previous contents have not been
written to the database datafiles. This rule is in place to facilitate crash and instance
recovery of the database.
In ARCHIVELOG mode, things get a bit more complicated. When a log switch
occurs, 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 to
process. The ARCH process will wake up (assuming it’s not processing another online
redo 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 redo
log and continue database activity as normal.
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
435
If Oracle proceeds through the remaining redo log groups and returns to the redo
log group you are archiving, it will not reuse that online redo log until the archiving
process has completed successfully for that online redo log file. If Oracle cannot use
that online redo log, it will look for another available online redo log. If no online
redo log is available, then the Oracle database will be suspended until the ARCH
process has completed its moves. Once ARCH completes the move of the online redo
log, it will update the control file, indicating that the online redo log has been
archived. 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 have
enough online redo log files (and/or if they are too small), because Oracle may not be
able to write out the archived redo logs fast enough to keep up with the redo creation
within the online redo logs. Thus, you may find that your database activity becomes
suspended 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. If
you 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 the
archiving process.
• Reduce the number of archiving destinations.
• Carefully tune the I/O. Try to separate the archived logs onto their own disks to
reduce 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 overwritten
without 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 will
have no access to the database or the data within it.
When you perform a cold backup in NOARCHIVELOG mode, you simply back up
the entire physical structure of the database. A cold backup in NOARCHIVELOG
mode includes backups of the following:
• All database datafiles
• All database control files
BACKUP AND RECOVERY IN NOARCHIVELOG MODE
Oracle Database
Administration
PART
II
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 10 • PHYSICAL BACKUP AND RECOVERY
436
• 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;
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
437
STATUS NAME
D:\ORACLE\ORADATA\RECOVER\CONTROL01.CTL
D:\ORACLE\ORADATA\RECOVER\CONTROL02.CTL
D:\ORACLE\ORADATA\RECOVER\CONTROL03.CTL
Finally, use a query to the V$LOGFILE data dictionary view to locate the database
online 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 a
cold 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 SHUT-
DOWN or SHUTDOWN IMMEDIATE command, you will not need to recover (or back
up) the online redo log files for the database.
Now, you can proceed to back up the physical database files that you identified. To
shorten 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 to
slower backup medium, such as tape. It is often advisable to include in your final
backup 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 a
backup control file later in this chapter, in the “Control File Backups” section. When
you’re finished backing up the database, you can open the database again. Listing 10.1
shows 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 are
the same, regardless of the operating system. Only the operating system commands (such
as copy, cp, tar, or tape backup) are different.
BACKUP AND RECOVERY IN NOARCHIVELOG MODE
Oracle Database
Administration
PART
II
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 10 • PHYSICAL BACKUP AND RECOVERY
438
Listing 10.1: Performing a Cold Backup in NOARCHIVELOG Mode
D:\ORACLE\ORA816\DATABASE>sqlplus “sys/robert as sysdba”
SQL> SHUTDOWN IMMEDIATE
Database 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_oracle
SQL> HOST COPY d:\oracle\oradata\recover\*.* d:\backup_oracle\*.*
d:\oracle\oradata\recover\CONTROL01.CTL
d:\oracle\oradata\recover\CONTROL02.CTL
d:\oracle\oradata\recover\CONTROL03.CTL
d:\oracle\oradata\recover\REDO01.LOG
d:\oracle\oradata\recover\REDO02.LOG
d:\oracle\oradata\recover\REDO03.LOG
d:\oracle\oradata\recover\SYSTEM01.DBF
d:\oracle\oradata\recover\RECOVER_RBS_01.DBF
d:\oracle\oradata\recover\RECOVER_USERS_01.DBF
d:\oracle\oradata\recover\RECOVER_TEMP_01.DBF
d:\oracle\oradata\recover\afiedt.buf
d:\oracle\oradata\recover\recover_idx_01.dbf.backup
d:\oracle\oradata\recover\RECOVER_IDX_01.DBF
13 file(s) copied.
Backup is complete, restart the database.
SQL> STARTUP
ORACLE instance started.
Total System Global Area 92280076 bytes
Fixed Size 70924 bytes
Variable Size 87937024 bytes
Database Buffers 4194304 bytes
Redo Buffers 77824 bytes
Database mounted.
Database opened.
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
439
NOTE Listing 10.1 and many other examples start SQL*Plus or connect to the database
using 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 to
prepare for that eventuality. Second, with Oracle release 8.1.6, we are forced to put the
username 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 then
respond to the password prompt that follows.
Recovering Cold Backups in NOARCHIVELOG Mode
Recovering a database from a cold backup taken in NOARCHIVELOG mode is fairly
simple. Issue a SHUTDOWN ABORT command on the database instance to make sure
that all the database processes are stopped and all operating system locks on files that
might 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 files
for later use. If any of the files were recovered to a different location, you will need to
reset the location as follows:
• If the control files were recovered to a different location, edit the database param-
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.
• If the database datafiles or the redo logs were recovered to another location, you
will need to mount the database by issuing a STARTUP MOUNT command.
Issue the ALTER DATABASE RENAME FILE command for each datafile that was
recovered to another location.
• If the online redo logs were recovered to another location, issue the ALTER
DATABASE RENAME FILE command to reset the location of the database online
redo 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 book
page 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
BACKUP AND RECOVERY IN NOARCHIVELOG MODE
Oracle Database
Administration
PART
II
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 10 • PHYSICAL BACKUP AND RECOVERY
440
ORACLE instance started.
Total System Global Area 92280076 bytes
Fixed Size 70924 bytes
Variable Size 87937024 bytes
Database Buffers 4194304 bytes
Redo Buffers 77824 bytes
Database mounted.
ORA-01157: cannot identify/lock datafile 4 - see DBWR trace file
ORA-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.dbf
d:\backup_oracle\CONTROL01.CTL
d:\backup_oracle\CONTROL02.CTL
d:\backup_oracle\CONTROL03.CTL
d:\backup_oracle\REDO01.LOG
d:\backup_oracle\REDO02.LOG
d:\backup_oracle\REDO03.LOG
d:\backup_oracle\SYSTEM01.DBF
d:\backup_oracle\RECOVER_RBS_01.DBF
d:\backup_oracle\RECOVER_USERS_01.DBF
d:\backup_oracle\RECOVER_TEMP_01.DBF
d:\backup_oracle\afiedt.buf
d:\backup_oracle\recover_idx_01.dbf.backup
d:\backup_oracle\RECOVER_IDX_01.DBF
1 file(s) copied.
SQL> STARTUP
ORACLE instance started.
Total System Global Area 92280076 bytes
Fixed Size 70924 bytes
Variable Size 87937024 bytes
Database Buffers 4194304 bytes
Redo Buffers 77824 bytes
Database mounted.
Database opened.
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
441
If you were not able to recover the online redo logs from the backup medium, you
can still recover the database in many cases. First, if you were able to recover at least one
member of each redo log group, you can create a copy of that online redo log, naming it
with 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 IMMEDIATE
option), 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, in
the “RESETLOGS and Recovery” section. For now, suffice it to say that issuing this
command will cause the database to create new redo logs. Also, if the control file is
missing, you can recover using the backup control file, as described in the “Control
File Backups” section later in this chapter.
Backups in ARCHIVELOG Mode
The principle difference between NOARCHIVELOG mode and ARCHIVELOG mode is
the creation of archived redo logs, and associated with that, the ability to back up the
database while it is still running and recover the database to point of failure, or some
point prior to that failure. It is this functionality and reliability that make Oracle the
most popular database in the world.
Performing Cold Backups in ARCHIVELOG Mode
Cold backups in ARCHIVELOG mode are much the same as those in NOARCHIVELOG
mode, 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, overwriting
the existing control file will hamper your ability to recover the database to the point of
failure. 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.
BACKUPS IN ARCHIVELOG MODE
Oracle Database
Administration
PART
II
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 10 • PHYSICAL BACKUP AND RECOVERY
442
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 in
NOARCHIVE mode. Steps 5 and 6 pertain to backing up archived redo logs, which is
covered in the next section.
Backing Up Archived Redo Logs
When you are doing any backup in ARCHIVELOG mode, it is assumed (and in the
case of hot backups, required) that the archived redo logs created during the time of
the backup are themselves backed up. It is the backup of these logs (and subsequent
backups of newly created archived redo logs) that allows an Oracle database in
ARCHIVELOG mode to be recovered.
When recovering from hot backups, all of the archived redo logs generated during
the hot backup are required during the recovery process. In addition, if you wish to
recover the database to a point beyond the point of recovery, you will need all of the
generated 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 is
really another question: How much data loss can you tolerate? Since the archived
redo 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 should
give careful consideration to using alternative storage locations, such as network
appliances or other options, to reduce the risk of datafile loss.
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
443
Also keep in mind the performance implications of your archived redo log configu-
rations. The more archived redo log destinations you configure, the longer the ARCH
process 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 online
redo log until all required copies to archive locations are complete.
NOTE Besides being useful for recovery, archived redo logs can also be run through the
Oracle8i utility called LogMiner, which we will cover in Chapter 14. LogMiner allows you to
review the archived redo logs for security audits and other purposes. Archived redo logs
are 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 imple-
ment hot backups in your database, you enter a whole new world of recovery options.
When doing hot backups, you simply do not back up control files and online redo
logs. 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 to
the online redo logs, as opposed to the normal atomic redo records that are created
when the tablespaces are not in hot backup mode. This means that all redo generated
for the tablespace is generated as an image of the entire block, rather than as just redo
records. 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 sys-
tem block splitting. Since Oracle continues to write to database datafiles during hot
backups, there is a possibility that the backed up image of the datafile will contain
fractured blocks. This is because the operating system write batch size may be smaller
than 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 the
online redo logs solves this problem by allowing the block to be restored during the
backup process.
BACKUPS IN ARCHIVELOG MODE
Oracle Database
Administration
PART
II
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Ngày đăng: 22/01/2014, 00:20
Xem thêm: Tài liệu ORACLE8i- P12 pptx, Tài liệu ORACLE8i- P12 pptx, Migrating an Existing 7.1+ Database to Oracle8i