HOT backup mode에서 왜 redo log에 추가 정보가 쓰일까요?
ALTER DATABASE BEGIN BACKUP과 ALTER TABLESPACE BEGIN BACKUP의 차이는?
아래 두개의 POST에 모든 답이 있네요..
Why is excessive redo generated during an Online/Hot Backup
There is not excessive redo generated, there is additional information logged into the online redo log during a hot backup the first time a block is modified in a tablespace that is in hot backup mode.
in hot backup mode only 2 things are different:
o 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 impossible 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 at least. We can recover it from there.
o 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.
Why is excessive redo generated during an Online/Hot Backup
What about ALTER DATABASE BEGIN BACKUP ?
That command put all database tablespaces in backup mode at the same time. As seen previously, it is a bad idea to put all tablespaces in backup mode, as it is better to do it one by one in order to minimize the supplemental redo logging overhead. Oracle introduces this ‘shortcut’ for one reason only: when doing backup with a mirror split (BCV, Flashcopy, etc), the copy gets all the datafiles at the same time, and the copy lasts only few seconds. In that case, it is easier to use that command to put all tablespaces in backup mode during the operation.
http://narashimreddy.wordpress.com/2009/09/11/oracle-backup-and-recovery-description-of-begin-backup-end-backup/
There is not excessive redo generated, there is additional information logged into the online redo log during a hot backup the first time a block is modified in a tablespace that is in hot backup mode.
in hot backup mode only 2 things are different:
o 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 impossible 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 at least. We can recover it from there.
o 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.
Why is excessive redo generated during an Online/Hot Backup
What about ALTER DATABASE BEGIN BACKUP ?
That command put all database tablespaces in backup mode at the same time. As seen previously, it is a bad idea to put all tablespaces in backup mode, as it is better to do it one by one in order to minimize the supplemental redo logging overhead. Oracle introduces this ‘shortcut’ for one reason only: when doing backup with a mirror split (BCV, Flashcopy, etc), the copy gets all the datafiles at the same time, and the copy lasts only few seconds. In that case, it is easier to use that command to put all tablespaces in backup mode during the operation.
http://narashimreddy.wordpress.com/2009/09/11/oracle-backup-and-recovery-description-of-begin-backup-end-backup/
'Oracle Database' 카테고리의 다른 글
| Oracle Global Temporary Table (0) | 2010.12.08 |
|---|---|
| 오라클 테스트 환경 만들기 (0) | 2010.11.29 |
| Oracle LOCAL INDEX DROP 하는 방법 (0) | 2010.11.23 |
| TRUSS 명령과 SQLNET tracing 설정 방법 (0) | 2010.11.04 |
| Oracle UTL_FILE을 이용한 데이터 loading의 간단한 예제 (0) | 2010.11.03 |