Following internal operations happened with immediate effect after triggering begin backup for tablespace
1. Partial check point (for all blocks part of the subjected tablespace)
2. Headers of datafiles would be freeze while datafile blocks would be available for normal access
3. 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 change vector. Normally only the changed bytes (a change vector) are written. In hot backup mode, the entire block is logged the first time (successive updates against that block would be logged as usual change vector only). This is because you can get into a situation where the process copying the datafile and DBWR are working on the same block simultaneously.
4. 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.
5. Once you end backup the datafile headers would be unfreeze and synced with current SCN from control file.
let's confirm that the datafile header freeze during hot backup
SQL> alter database begin backup;
alter database begin backup
*
ERROR at line 1:
ORA-01123: cannot start online backup; media recovery not enabled
Alter database begin backup ;
!cp /home/oracle/10.2.0/product/oradata/orcl/users01.dbf /home/oracle/backup/users01.dbf
!cp /home/oracle/10.2.0/product/oradata/orcl/sysaux01.dbf /home/oracle/backup/sysaux01.dbf
!cp /home/oracle/10.2.0/product/oradata/orcl/undotbs01.dbf /home/oracle/backup/undotbs01.dbf
!cp /home/oracle/10.2.0/product/oradata/orcl/system01.dbf /home/oracle/backup/system01.dbf
!cp /home/oracle/10.2.0/product/oradata/orcl/example01.dbf /home/oracle/backup/example01.dbf
!cp /home/oracle/10.2.0/product/oradata/orcl/mytbs.dbf /home/oracle/backup/mytbs.dbf
Can check datafile backup status using below view
SQL> select file#,status from v$backup;
FILE# STATUS
---------- ------------------
1 ACTIVE
2 ACTIVE
3 ACTIVE
4 ACTIVE
5 ACTIVE
6 ACTIVE
6 rows selected.
Now we connect to the user and run insert statement
SQL> conn scott/tiger
Connected.
SQL> insert into abc select * from abc;
809232 rows created.
SQL> commit;
check the CHECKPOINT_CHANGE# from v$datafile_header
SQL> select CREATION_CHANGE#, RESETLOGS_CHANGE#,CHECKPOINT_CHANGE# from v$datafile_header;
CREATION_CHANGE# RESETLOGS_CHANGE# CHECKPOINT_CHANGE#
---------------- ----------------- ------------------
8 525876 1730264
523586 525876 1730264
6294 525876 1730264
10169 525876 1730264
547523 525876 1730264
1720920 525876 1730264
6 rows selected.
SQL> alter system checkpoint;
System altered.
Check the CHECKPOINT_CHANGE# from v$datafile_header after fired checkpoint manually but it's still same.
SQL> select CREATION_CHANGE#, RESETLOGS_CHANGE#,CHECKPOINT_CHANGE# from v$datafile_header;
CREATION_CHANGE# RESETLOGS_CHANGE# CHECKPOINT_CHANGE#
---------------- ----------------- ------------------
8 525876 1730264
523586 525876 1730264
6294 525876 1730264
10169 525876 1730264
547523 525876 1730264
1720920 525876 1730264
6 rows selected.
SQL> alter system switch logfile;
System altered.
SQL> alter system checkpoint;
System altered.
SQL> select CREATION_CHANGE#, RESETLOGS_CHANGE#,CHECKPOINT_CHANGE# from v$datafile_header;
CREATION_CHANGE# RESETLOGS_CHANGE# CHECKPOINT_CHANGE#
---------------- ----------------- ------------------
8 525876 1730264
523586 525876 1730264
6294 525876 1730264
10169 525876 1730264
547523 525876 1730264
1720920 525876 1730264
6 rows selected.
SQL> alter system checkpoint;
System altered.
Again we verified the CHECKPOINT_CHANGE# after fire checkpoint manually but there is no change .
SQL> select CREATION_CHANGE#, RESETLOGS_CHANGE#,CHECKPOINT_CHANGE# from v$datafile_header;
CREATION_CHANGE# RESETLOGS_CHANGE# CHECKPOINT_CHANGE#
---------------- ----------------- ------------------
8 525876 1730264
523586 525876 1730264
6294 525876 1730264
10169 525876 1730264
547523 525876 1730264
1720920 525876 1730264
6 rows selected.
After end backup when I chek again now CREATION_CHANGE# has been changed .
SQL> select CREATION_CHANGE#, RESETLOGS_CHANGE#,CHECKPOINT_CHANGE# from v$datafile_header;
CREATION_CHANGE# RESETLOGS_CHANGE# CHECKPOINT_CHANGE#
---------------- ----------------- ------------------
8 525876 1736138
523586 525876 1736138
6294 525876 1736138
10169 525876 1736138
547523 525876 1736138
1720920 525876 1736138
6 rows selected.
Following internal operations happened with immediate effect after triggering begin backup for tablespace
1. Partial check point (for all blocks part of the subjected tablespace)
2. Headers of datafiles would be freeze while datafile blocks would be available for normal access
3. 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 change vector. Normally only the changed bytes (a change vector) are written. In hot backup mode, the entire block is logged the first time (successive updates against that block would be logged as usual change vector only). This is because you can get into a situation where the process copying the datafile and DBWR are working on the same block simultaneously.
4. 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.
5. Once you end backup the datafile headers would be unfreeze and synced with current SCN from control file.
let's confirm that the datafile header freeze during hot backup
Can check datafile backup status using below view
Now we connect to the user and run insert statement
check the CHECKPOINT_CHANGE# from v$datafile_header
Check the CHECKPOINT_CHANGE# from v$datafile_header after fired checkpoint manually but it's still same.
SQL> alter system switch logfile;
Again we verified the CHECKPOINT_CHANGE# after fire checkpoint manually but there is no change .
1. Partial check point (for all blocks part of the subjected tablespace)
2. Headers of datafiles would be freeze while datafile blocks would be available for normal access
3. 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 change vector. Normally only the changed bytes (a change vector) are written. In hot backup mode, the entire block is logged the first time (successive updates against that block would be logged as usual change vector only). This is because you can get into a situation where the process copying the datafile and DBWR are working on the same block simultaneously.
4. 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.
5. Once you end backup the datafile headers would be unfreeze and synced with current SCN from control file.
let's confirm that the datafile header freeze during hot backup
SQL> alter database begin backup;
alter database begin backup
*
ERROR at line 1:
ORA-01123: cannot start online backup; media recovery not enabled
Alter database begin backup ;
!cp /home/oracle/10.2.0/product/oradata/orcl/users01.dbf /home/oracle/backup/users01.dbf
!cp /home/oracle/10.2.0/product/oradata/orcl/sysaux01.dbf /home/oracle/backup/sysaux01.dbf
!cp /home/oracle/10.2.0/product/oradata/orcl/undotbs01.dbf /home/oracle/backup/undotbs01.dbf
!cp /home/oracle/10.2.0/product/oradata/orcl/system01.dbf /home/oracle/backup/system01.dbf
!cp /home/oracle/10.2.0/product/oradata/orcl/example01.dbf /home/oracle/backup/example01.dbf
!cp /home/oracle/10.2.0/product/oradata/orcl/mytbs.dbf /home/oracle/backup/mytbs.dbf
SQL> select file#,status from v$backup;
FILE# STATUS
---------- ------------------
1 ACTIVE
2 ACTIVE
3 ACTIVE
4 ACTIVE
5 ACTIVE
6 ACTIVE
6 rows selected.
SQL> conn scott/tiger
Connected.
SQL> insert into abc select * from abc;
809232 rows created.
SQL> commit;
SQL> select CREATION_CHANGE#, RESETLOGS_CHANGE#,CHECKPOINT_CHANGE# from v$datafile_header;
CREATION_CHANGE# RESETLOGS_CHANGE# CHECKPOINT_CHANGE#
---------------- ----------------- ------------------
8 525876 1730264
523586 525876 1730264
6294 525876 1730264
10169 525876 1730264
547523 525876 1730264
1720920 525876 1730264
6 rows selected.
SQL> alter system checkpoint;
System altered.
SQL> select CREATION_CHANGE#, RESETLOGS_CHANGE#,CHECKPOINT_CHANGE# from v$datafile_header;
CREATION_CHANGE# RESETLOGS_CHANGE# CHECKPOINT_CHANGE#
---------------- ----------------- ------------------
8 525876 1730264
523586 525876 1730264
6294 525876 1730264
10169 525876 1730264
547523 525876 1730264
1720920 525876 1730264
6 rows selected.
System altered.
SQL> alter system checkpoint;
System altered.
SQL> select CREATION_CHANGE#, RESETLOGS_CHANGE#,CHECKPOINT_CHANGE# from v$datafile_header;
CREATION_CHANGE# RESETLOGS_CHANGE# CHECKPOINT_CHANGE#
---------------- ----------------- ------------------
8 525876 1730264
523586 525876 1730264
6294 525876 1730264
10169 525876 1730264
547523 525876 1730264
1720920 525876 1730264
6 rows selected.
SQL> alter system checkpoint;
System altered.
Again we verified the CHECKPOINT_CHANGE# after fire checkpoint manually but there is no change .
SQL> select CREATION_CHANGE#, RESETLOGS_CHANGE#,CHECKPOINT_CHANGE# from v$datafile_header;
CREATION_CHANGE# RESETLOGS_CHANGE# CHECKPOINT_CHANGE#
---------------- ----------------- ------------------
8 525876 1730264
523586 525876 1730264
6294 525876 1730264
10169 525876 1730264
547523 525876 1730264
1720920 525876 1730264
6 rows selected.
After end backup when I chek again now CREATION_CHANGE# has been changed .
SQL> select CREATION_CHANGE#, RESETLOGS_CHANGE#,CHECKPOINT_CHANGE# from v$datafile_header;
CREATION_CHANGE# RESETLOGS_CHANGE# CHECKPOINT_CHANGE#
---------------- ----------------- ------------------
8 525876 1736138
523586 525876 1736138
6294 525876 1736138
10169 525876 1736138
547523 525876 1736138
1720920 525876 1736138
6 rows selected.
No comments:
Post a Comment