10g可以进行database级别的hot backup,此之前只能以tablespace为单位,个人感觉rman的backup as copy命令更方便。
使用此方法备份需要注意以下两点
1
产生大量的日志,备份过程中block若被修改,整个block image都会被写入redo log
2
备份期间数据文件头的SCN保持不变,以便recover时定位需要使用的归档日志
V$backup查看处于backup状态的datafile
SQL> select * from V$BACKUP;
FILE# STATUS CHANGE# TIME
--------- ---------------- ------------ -----------
1 NOT ACTIVE 0
2 NOT ACTIVE 0
3 ACTIVE 15021 12-NOV-97
http://space.itpub.net/15480802/viewspace-687334
|
What Happens When A Tablespace/Database Is Kept In Begin Backup Mode [ID 469950.1] |
||
|
|
||
|
|
Modified 11-MAR-2011 Type HOWTO Status MODERATED |
|
In
this Document
Goal
Solution
References
Platforms: 1-914CU;
|
This document is being delivered to you via Oracle Support's Rapid Visibility (RaV) process and therefore has not been subject to an independent technical review. |
Oracle
Server - Enterprise Edition - Version: 8.1.7.4 to 11.1.0.6 - Release: 8.1.7 to
11.1
Information in this document applies to any platform.
This document explains in detail about what happens when a tablespace/datafile is kept in hot backup/begin backup mode.
To perform. online/hot backup we have to put the
tablespace in begin backup mode followed by copying the datafiles and then
putting the tablespace to end backup.
In 8i, 9i we have to put each tablespace individually in begin/end backup mode
to perform. the online backup. From 10g onwards the entire database can be put
in begin/end backup mode.
Make sure that the database is in archivelog mode
Example :
Performing a single
tablespace backup
+ sql>alter tablespace system begin backup;
+ Copy the corresponding
datafiles using appropriate O/S commands.
+ sql>alter
tablespace system end backup;
Performing a full
database backup (starting from 10g)
+ sql> alter database begin backup;
+ Copy all the datafiles
using appropriate O/S commands.
+ sql> alter database
end backup;
One danger in making online
backups is the possibility of inconsistent data within a block. For example,
assume that you are backing up block 100 in datafile users.dbf. Also, assume
that the copy utility reads the entire block while DBWR is in the middle of
updating the block. In this case, the copy utility may read the old data in the
top half of the block and the new data in the bottom top half of the block. The
result is called a fractured block, meaning that the data contained in this
block is not consistent. at a given SCN.
Therefore oracle
internally manages the consistency as below :
1. The first time a block is changed in a datafile that is in hot backup
mode, the entire block is written to the redo log files, not just the changed
bytes. Normally only the changed bytes (a redo vector) is written. In hot
backup mode, the entire block is logged the first time. This is because you can
get into a situation where the process copying the datafile and DBWR are
working on the same block simultaneously.
Lets say they are and the OS blocking read factor is 512bytes (the OS reads 512 bytes from disk at a time). The backup program goes to read an 8k Oracle block. The OS gives it 4k. Meanwhile -- DBWR has asked to rewrite this block. the OS schedules the DBWR write to occur right now. The entire 8k block is rewritten. The backup program starts running again (multi-tasking OS here) and reads the last 4k of the block. The backup program has now gotten an fractured block -- the head and tail are from two points in time.
We cannot deal with that during recovery. Hence, we log the entire block image so that during recovery, this block is totally rewritten from redo and is consistent with itself atleast. We can recover it from there.
2. The datafile headers which contain the SCN of the last completed
checkpoint are not updated while a file is in hot backup mode. This lets the
recovery process understand what archive redo log files might be needed to
fully recover this file.
To limit the effect of this additional logging, you should ensure you only
place one tablepspace at a time in backup mode and bring the tablespace out of
backup mode as soon as you have backed it up. This will reduce the number of
blocks that may have to be logged to the minimum possible.
Try to take the hot/online backups when there is less / no load on the database, so that less redo will be generated.
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/15480802/viewspace-721096/ ,如需转载,请注明出处,否则将追究法律责任。