关于checkpoint事件的疑问

ccsnmoracle

以下是备份操作前后的比对

SQL> select file#,checkpoint_change# from v$datafile;

     FILE# CHECKPOINT_CHANGE#
---------- ------------------
         1             629019
         2             629042
         3             629021
         4             629050
         5             629039
         6             629047


SQL> select file#,checkpoint_change# from v$datafile;

     FILE# CHECKPOINT_CHANGE#
---------- ------------------
         1             630694
         2             630801
         3             630711
         4             630801
         5             630711
         6             630801

从结果上看，rman的确触发了checkpoint事件？？？？？

zergduan

是的rman在开始备份数据文件的时候会发生checkpoint，把这个数据文件的scn写入controflile~s

我模拟了一下你的情况，每个数据文件在controfile中的scn不同可以通过
rman
backup database filesperset 1;
来实现~

但是似乎这样的checkpoint没法被log_checkpoints_to_alert追踪到...

ccsnmoracle

万分感谢您的回答！

当checkpoint事件触发时，控制文件自己的SCN与各个数据文件分别作SCN同步，并将所同步的数据文件的SCN值记录下来。
这样理解正确吗？



可为什么每个piece中的数据文件的SCN不同呢？即使是在不同PIECE中的相同的数据文件。

一个数据文件被分散保存到不同的piece中， 但相同数据文件的SCN值应该一直呀！？？？

您能给讲解一下不？？？

zergduan

原帖由 ccsnmoracle 于 2010-1-22 16:45 发表
万分感谢您的回答！

当checkpoint事件触发时，控制文件自己的SCN与各个数据文件分别作SCN同步，并将所同步的数据文件的SCN值记录下来。
这样理解正确吗？



可为什么每个piece中的数据文件的SCN不同呢？即使是在不同PIECE中的相同的数据文件。

一个数据文件被分散保存到不同的piece中， 但相同数据文件的SCN值应该一直呀！？？？

您能给讲解一下不？？？

控制文件自己的SCN与各个数据文件分别作SCN同步 --不是'控制文件自己的SCN'是controfile中记录的数据文件的scn

可为什么每个piece中的数据文件的SCN不同呢？即使是在不同PIECE中的相同的数据文件。--我猜你想说的是backupset,我的实验表明，在同一个backupset的datafile在开始做备份的时候是同时发生的checkopoint，他们在v$datafile（也就是controlfile）记录的checkpoint_change# scn是一致的~

如果你想要所有的数据文件都不一致，只能让每个数据文件备份到不同的backupset中，也就是filesperset 1

ccsnmoracle

我糊涂了！还想请您再给讲讲。

在控制文件中记录着每一个数据文件的SCN，当checkpoint发生时，控制文件中数据文件的SCN和数据文件中的SCN被同步。（理解的对吗？）

可是，在数据库进行recover操作时，数据库的恢复终点，不也是参考控制文件中的SCN吗？

比如刚刚restore的数据文件的SCN均为10，而现在使用的控制文件是15。那么在接下来的recover操作中，数据文件要依照日志文件的内容，
将SCN推进到15，甚至更远些。（这种理解对吗？）

backupset是相对于copy的一种备份形式。由于文件容量和IO分散的考虑，一次backup操作，会产生多个PIECE，被备份的数据文件就被分散保存在这些PIECE中。我说的分散保存，也是指单独的一个文件被分散在多个piece里。（理解的对吗？)

可我的实验结果是

BS Key  Type LV Size       Device Type Elapsed Time 終了時間
------- ---- -- ---------- ----------- ------------ --------
6587    Full    358.65M    DISK        00:00:38     10-01-18
        BPキー: 6595   ステータス: AVAILABLE  圧縮: NO  タグ: TAG20100118T045933
        ピース名: /export/home/oracle/backup/MYTEST/backupset/2010_01_18/o1_mf_nnndf_TAG20100118T045933_5o6v160g_.bkp
  バックアップ・セット6587のデータファイルのリスト
  File LV Type Ckp SCN    Ckp時間  Name
  ---- -- ---- ---------- -------- ----
  1       Full 630694     10-01-18 /export/home/oracle/app/oracle/oradata/mytest/system01.dbf
  4       Full 630694     10-01-18 /export/home/oracle/app/oracle/oradata/mytest/users01.dbf
  6       Full 630694     10-01-18 /export/home/oracle/app/oracle/oradata/mytest/myspace01.dbf

BS Key  Type LV Size       Device Type Elapsed Time 終了時間
------- ---- -- ---------- ----------- ------------ --------
6588    Full    571.45M    DISK        00:02:13     10-01-18
        BPキー: 6596   ステータス: AVAILABLE  圧縮: NO  タグ: TAG20100118T045933
        ピース名: /export/home/oracle/backup/MYTEST/backupset/2010_01_18/o1_mf_nnndf_TAG20100118T045933_5o6v15xh_.bkp
  バックアップ・セット6588のデータファイルのリスト
  File LV Type Ckp SCN    Ckp時間  Name
  ---- -- ---- ---------- -------- ----
  1       Full 630692     10-01-18 /export/home/oracle/app/oracle/oradata/mytest/system01.dbf
  3       Full 630692     10-01-18 /export/home/oracle/app/oracle/oradata/mytest/sysaux01.dbf
  5       Full 630692     10-01-18 /export/home/oracle/app/oracle/oradata/mytest/example01.dbf

BS Key  Type LV Size       Device Type Elapsed Time 終了時間
------- ---- -- ---------- ----------- ------------ --------
6590    Full    243.82M    DISK        00:02:20     10-01-18
        BPキー: 6598   ステータス: AVAILABLE  圧縮: NO  タグ: TAG20100118T045933
        ピース名: /export/home/oracle/backup/MYTEST/backupset/2010_01_18/o1_mf_nnndf_TAG20100118T045933_5o6v2thb_.bkp
  バックアップ・セット6590のデータファイルのリスト
  File LV Type Ckp SCN    Ckp時間  Name
  ---- -- ---- ---------- -------- ----
  2       Full 630711     10-01-18 /export/home/oracle/app/oracle/oradata/mytest/undotbs01.dbf
  3       Full 630711     10-01-18 /export/home/oracle/app/oracle/oradata/mytest/sysaux01.dbf
  5       Full 630711     10-01-18 /export/home/oracle/app/oracle/oradata/mytest/example01.dbf

比如sysaux01.dbf文件在不同的PIECE中的SCN就不同。630692和630711这是问什么呢？？

zergduan

原帖由 ccsnmoracle 于 2010-1-22 21:43 发表

BS Key  Type LV Size       Device Type Elapsed Time 終了時間
------- ---- -- ---------- ----------- ------------ --------
6588    Full    571.45M    DISK        00:02:13     10-01-18
        BPキー: 6596   ステータス: AVAILABLE  圧縮: NO  タグ: TAG20100118T045933
        ピース名: /export/home/oracle/backup/MYTEST/backupset/2010_01_18/o1_mf_nnndf_TAG20100118T045933_5o6v15xh_.bkp
  バックアップ・セット6588のデータファイルのリスト
  File LV Type Ckp SCN    Ckp時間  Name
  ---- -- ---- ---------- -------- ----
  1       Full 630692     10-01-18 /export/home/oracle/app/oracle/oradata/mytest/system01.dbf
  3       Full 630692     10-01-18 /export/home/oracle/app/oracle/oradata/mytest/sysaux01.dbf
  5       Full 630692     10-01-18 /export/home/oracle/app/oracle/oradata/mytest/example01.dbf

BS Key  Type LV Size       Device Type Elapsed Time 終了時間
------- ---- -- ---------- ----------- ------------ --------
6590    Full    243.82M    DISK        00:02:20     10-01-18
        BPキー: 6598   ステータス: AVAILABLE  圧縮: NO  タグ: TAG20100118T045933
        ピース名: /export/home/oracle/backup/MYTEST/backupset/2010_01_18/o1_mf_nnndf_TAG20100118T045933_5o6v2thb_.bkp
  バックアップ・セット6590のデータファイルのリスト
  File LV Type Ckp SCN    Ckp時間  Name
  ---- -- ---- ---------- -------- ----
  2       Full 630711     10-01-18 /export/home/oracle/app/oracle/oradata/mytest/undotbs01.dbf
  3       Full 630711     10-01-18 /export/home/oracle/app/oracle/oradata/mytest/sysaux01.dbf
  5       Full 630711     10-01-18 /export/home/oracle/app/oracle/oradata/mytest/example01.dbf

比如sysaux01.dbf文件在不同的PIECE中的SCN就不同。630692和630711这是问什么呢？？

。。。仔细看~ sysaux01.dbf 是因为在不同的backupset中，所以它有不同的scn (630692--> backupset 6588    ;630711--> backupset 6590) 。。。

ccsnmoracle

谢谢您！虽然还是不太理解， 我再自己想想。
我觉得，我的RMAN基础知识还是不足！
还得再麻烦您！

我现在觉得，在生成backupset时，就触发了checkpoint事件，
所以显示出的值，并不是最终备份文件的SCN的，而是阶段性的。
一句话，还是基础知识不足。。。。只能考猜了。。。。

zergduan

。。。 我们拿
backupset 6588 举例
datafile 1,3,5 都在这个backupset 中， 那么你用rman备份的时候，可能用的是backup datafile 1,3,5这样的命令~　
ｒｍａｎ开始备份的时候要确定这几个数据文件备份开始的ｓｃｎ，以后这个ｓｃｎ就是你restore后的结果 v$datafile_header可以看到。这个scn的作用是作为你recover的起点。

比如你resotre datafile 3 from TAG 20100118T045933; restore后可以通过v$datafile_header看到这个文件的scn就是630692。当你recover datafile 3的时候，rman就知道他要从scn 630692开始应用archivelog来进行恢复~

ccsnmoracle

万分感谢，问题已经解决！！
谢谢您了！

chaobin520

我的也是这样 正常吧