使用begin backup備份資料庫

myownstars發表於2012-04-13

10g可以進行database級別的hot backup,此之前只能以tablespace為單位,個人感覺rmanbackup 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
  
  
  


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.

Applies to:

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.

Goal

This document explains in detail about what happens when a tablespace/datafile is kept in hot backup/begin backup mode.

Solution

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部落格 ” ,連結:http://blog.itpub.net/15480802/viewspace-721096/,如需轉載,請註明出處,否則將追究法律責任。

相關文章