我用以下办法验证冷备份 / 恢复，但没有意想的效果。connect /as sysdbashutdown immediate把oracle/oradata/下的数据文件复制出来startup备份完成
再把数据库增加表、增加记录shutdown immediate把刚才备份的文件替换回去startup现在我看到刚才增加的表还在，说明没有起到还原的效果。为什么会这样？
再把数据库增加表、增加记录shutdown immediate把刚才备份的文件替换回去startup现在我看到刚才增加的表还在，说明没有起到还原的效果。为什么会这样？
楼主覆盖成功了没，你的操作是没问题。 备份
1. shutdown database
2. oracle/oradata/下的数据文件复制出来 恢复
1. shutdown database
2. 用备份的文件覆盖oracle/oradata/建议楼主在覆盖之前，把oradate下的文件全部删了，再覆盖一次看看..
2. oracle/oradata/下的数据文件复制出来冷备份需要数据文件，控制文件和联机日志
如果你的操作再多一点,达到切换你所有的log后,你再进行相同的操作,你会发现你的库会报错,并且恢复不了了.
总之,你只备份数据文件的方式是不对的,冷备不是这么备的
楼主备份的是oradata 目录下的所有文件还是只有数据文件？冷备要把oracle/oradata/的所有文件都要备份。 包括数据文件， 控制文件，redo log 文件.
SQL> select checkpoint_change# from v$datafile; CHECKPOINT_CHANGE#
------------------
533106
533106
533106
533106SQL> select checkpoint_change# from v$datafile_header; CHECKPOINT_CHANGE#
------------------
533106
533106
533106
533106
SQL> select name from v$datafile; NAME
------------------------------------------------------------------------------------------------------------------------
/database/oracle/oradata/toms/system01.dbf
/database/oracle/oradata/toms/undotbs01.dbf
/database/oracle/oradata/toms/sysaux01.dbf
/database/oracle/oradata/toms/users01.dbfSQL> shutdown immediate
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> host cp /database/oracle/oradata/toms/*.dbf /backupSQL> startup
ORACLE 例程已经启动。Total System Global Area 167772160 bytes
Fixed Size 1218316 bytes
Variable Size 83888372 bytes
Database Buffers 79691776 bytes
Redo Buffers 2973696 bytes
数据库装载完毕。
数据库已经打开。
SQL> conn scott/tiger
已连接。
SQL> show user
USER 为 "SCOTT"
SQL> create table test100 ( id number )
2 tablespace users; 表已创建。SQL> insert into test100 values (1); 已创建 1 行。SQL> insert into test100 values (2); 已创建 1 行。SQL> insert into test100 values (3); 已创建 1 行。SQL> commit; 提交完成。SQL> select count(*) from test100; COUNT(*)
----------
3SQL> conn /as sysdba
已连接。
SQL> shutdown immediate
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> host cp -f /backup/*.dbf /database/oracle/oradata/toms SQL> host ls -l /database/oracle/oradata/toms/
total 1159072
-rw-r----- 1 oracle dba 7061504 Oct 21 13:40 control01.ctl
-rw-r----- 1 oracle dba 7061504 Oct 21 13:40 control02.ctl
-rw-r----- 1 oracle dba 7061504 Oct 21 13:40 control03.ctl
-rw-r----- 1 oracle dba 52429312 Oct 21 13:38 redo01.log
-rw-r----- 1 oracle dba 52429312 Oct 21 13:40 redo02.log
-rw-r----- 1 oracle dba 52429312 Oct 21 13:38 redo03.log
-rw-r----- 1 oracle dba 262152192 Oct 21 13:41 sysaux01.dbf
-rw-r----- 1 oracle dba 503324672 Oct 21 13:41 system01.dbf
-rw-r----- 1 oracle dba 28319744 Oct 21 13:41 temp01.dbf
-rw-r----- 1 oracle dba 209723392 Oct 21 13:41 undotbs01.dbf
-rw-r----- 1 oracle dba 5251072 Oct 21 13:41 users01.dbf
SQL> startup
ORACLE 例程已经启动。Total System Global Area 167772160 bytes
Fixed Size 1218316 bytes
Variable Size 83888372 bytes
Database Buffers 79691776 bytes
Redo Buffers 2973696 bytes
数据库装载完毕。
ORA-01113: 文件 1 需要介质恢复
ORA-01110: 数据文件 1: '/database/oracle/oradata/toms/system01.dbf'
SQL> recover database;
完成介质恢复。
SQL> alter database open; 数据库已更改。SQL> conn scott/tiger
已连接。
SQL> show user
USER 为 "SCOTT"
SQL> select count(*) from test100; COUNT(*)
----------
3
看下alert文件
Allocated 3981204 bytes in shared pool for flashback generation buffer
Starting background process RVWR
RVWR started with pid=16, OS id=3630
Wed Oct 21 13:42:30 2009
Database mounted in Exclusive Mode
Completed: ALTER DATABASE MOUNT
Wed Oct 21 13:42:31 2009
ALTER DATABASE OPEN
Block change tracking file is current.
ORA-1113 signalled during: ALTER DATABASE OPEN...
Wed Oct 21 13:42:58 2009
ALTER DATABASE RECOVER database
Wed Oct 21 13:42:58 2009
Media Recovery Start
Wed Oct 21 13:42:58 2009
Recovery of Online Redo Log: Thread 1 Group 2 Seq 35 Reading mem 0
Mem# 0 errs 0: /database/oracle/oradata/toms/redo02.log
Wed Oct 21 13:42:59 2009
Media Recovery Complete (toms)
Completed: ALTER DATABASE RECOVER database
Wed Oct 21 13:43:03 2009
alter database openinthirties说的没错,是我分析错了,自己试一下发现oracle还没那么智能
楼主只备份数据文件是没意义的
当数据库启动时，主要分为两步检查：一、Oracle 先检查控制文件中的每个Datafile Checkpoint SCN和数据文件中的Start SCN是否相同，这个时候如果不同，则需要进行介质恢复。如果相同，则进行第二步检查。二、再检查每个Datafile Checkpoint SCN和Stop SCN是否相同。如果发现有不同，就从Redo Log中找到丢失的SCN，重新写入数据文件中进行实例恢复。
1、先说说楼主遇到的那种情况
因为做的操作比较少，所以SCN变化不大，当把前面复制出去的那些数据文件复制回原来的地方覆盖了现有数据文件，当启动的时候首先经过上述第一步的检查，也就是“控制文件中的每个Datafile Checkpoint SCN和数据文件中的Start SCN是否相同”，此时检查结果是相同的，就进行第二步检查，此时发现每个Datafile Checkpoint SCN和Stop SCN不同，所以ORACLE自动进行了实例恢复，这也就是为什么楼主没有像jinxino_o那样遇到提示说需要介质恢复。2、再说一下jinxino_o的实验情况吧
我们可以看到的是jinxino_o也并没有COPY出数据文件，REDO LOG和控制文件。他也仅仅是COPY出去了数据文件而已，可是他在把数据文件拷贝回原路径，并重新启动数据库的时候却收到了ORACLE的提示说需要介质恢复。这也是他的实验和楼主所做的差别所在。我个人感觉这是因为当jinxino_o拷回数据文件并启动数据库的时候，控制文件中的每个Datafile Checkpoint SCN和他拷贝出去的数据文件头中的START SCN已经不一致了，所以此时提示需要介质恢复。就像inthirties说的那样,“操作很少，时间很短”。因为如果操作很多或者时间过久（记得每过3秒系统就会自动增长一次SCN），SCN号就会增长，这个时候就会造成控制文件中的每个Datafile Checkpoint SCN和他拷贝出去的数据文件头中的START SCN不一致。
个人的理解，不知道对不对，如果有错误欢迎大家指出。
分析的很细致，详细的启动恢复过程可以见http://www.inthirties.com/thread-83-1-1.html
正是因为两次shutdown immediate，所以至少发生了两次CHECKPOINT。而Datafile Checkpoint SCN也就不可能再和Start SCN相同了，你是这个意思吗？2、
听楼主那口气好像他并没有像你做的实验那样遇到ORACLE提示说需要介质恢复。所以我才在前面回帖中的第一种情况里猜测说楼主遇到的情况是ORACLE进行了自动的实例恢复。呵呵 当然 这只是我个人猜测 到底有没有进行介质恢复只有楼主自己知道
也许楼主也进行recovery操作了 只是在这里没说而已
SQL> startup mount
ORACLE 例程已经启动。Total System Global Area 167772160 bytes
Fixed Size 1218316 bytes
Variable Size 88082676 bytes
Database Buffers 75497472 bytes
Redo Buffers 2973696 bytes
数据库装载完毕。
SQL> select checkpoint_change# from v$datafile; CHECKPOINT_CHANGE#
------------------
569028
569028
569028
569028SQL> select checkpoint_change# from v$datafile_header; CHECKPOINT_CHANGE#
------------------
569028
569028
569028
569028SQL> alter session set events 'immediate trace name controlf level 12'; 会话已更改。SQL> alter database open; 数据库已更改。SQL> shutdown immediate
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> startup mount
ORACLE 例程已经启动。Total System Global Area 167772160 bytes
Fixed Size 1218316 bytes
Variable Size 88082676 bytes
Database Buffers 75497472 bytes
Redo Buffers 2973696 bytes
数据库装载完毕。
SQL> select checkpoint_change# from v$datafile; CHECKPOINT_CHANGE#
------------------
569297
569297
569297
569297SQL> select checkpoint_change# from v$datafile_header; CHECKPOINT_CHANGE#
------------------
569297
569297
569297
569297SQL> alter session set events 'immediate trace name controlf level 12'; 会话已更改。SQL> alter database open; 数据库已更改。SQL> shutdow immediate;
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
[oracle@test udump]$ pwd
/database/oracle/admin/toms/udump
[oracle@test udump]$ ls -lt
total 372
-rw-r----- 1 oracle dba 57356 Oct 23 15:20 toms_ora_5637.trc
-rw-r----- 1 oracle dba 651 Oct 23 15:19 toms_ora_5634.trc
-rw-r----- 1 oracle dba 594 Oct 23 15:19 toms_ora_5607.trc
-rw-r----- 1 oracle dba 57357 Oct 23 15:19 toms_ora_5583.trc
-rw-r----- 1 oracle dba 651 Oct 23 15:17 toms_ora_5580.trc
-rw-r----- 1 oracle dba 594 Oct 23 15:17 toms_ora_5553.trc
-rw-r----- 1 oracle dba 779 Oct 23 15:17 toms_ora_5552.trc我们分别看看15：20和15：19跟踪到了什么信息（我把最关键的信息发上来，其他省略了）：[oracle@test udump]$ more toms_ora_5583.trc
***************************************************************************
DATABASE ENTRY
***************************************************************************
(size = 316, compat size = 316, section max = 1, section in-use = 1,
last-recid= 0, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 1, numrecs = 1)
08/25/2009 10:02:12
DB Name "TOMS"
Database flags = 0x00404001 0x00001000
Controlfile Creation Timestamp 08/25/2009 10:02:13
Incmplt recovery scn: 0x0000.00000000
Resetlogs scn: 0x0000.00000001 Resetlogs Timestamp 08/25/2009 10:02:12
Prior resetlogs scn: 0x0000.00000000 Prior resetlogs Timestamp 01/01/1988 00:00:00
Redo Version: compatible=0xa200100
#Data files = 4, #Online files = 4
Database checkpoint: Thread=1 scn: 0x0000.0008aec4
Threads: #Enabled=1, #Open=0, Head=0, Tail=0
[oracle@test udump]$ more toms_ora_5637.trc
***************************************************************************
DATABASE ENTRY
***************************************************************************
(size = 316, compat size = 316, section max = 1, section in-use = 1,
last-recid= 0, old-recno = 0, last-recno = 0)
(extent = 1, blkno = 1, numrecs = 1)
08/25/2009 10:02:12
DB Name "TOMS"
Database flags = 0x00404001 0x00001000
Controlfile Creation Timestamp 08/25/2009 10:02:13
Incmplt recovery scn: 0x0000.00000000
Resetlogs scn: 0x0000.00000001 Resetlogs Timestamp 08/25/2009 10:02:12
Prior resetlogs scn: 0x0000.00000000 Prior resetlogs Timestamp 01/01/1988 00:00:00
Redo Version: compatible=0xa200100
#Data files = 4, #Online files = 4
Database checkpoint: Thread=1 scn: 0x0000.0008afd1
Threads: #Enabled=1, #Open=0, Head=0, Tail=0看到我用红色标记的信息了吧，就算你对库没进行其他操作，但只要你shutdown immediate，那么checkpoint scn就会变化.版主经验很丰富,就是不给解释呢......还的我自己来
Database checkpoint: Thread=1 scn: 0x0000.0008aec4Database checkpoint: Thread=1 scn: 0x0000.0008afd1
呵呵 版主这不是促使我们自己动手实验嘛不过你好像并没有回答我刚才在27#向你提出的那两个问题哦（第一个问题勉强算回答了 呵呵 ）你刚才说我在前面说的第一种情况出现不了
我现在想知道的就是假如没有两次shutdown immediate
那么我在#22说的那个第一种情况有没有可能出现
即便只有一次正常关闭也是会发生CHECKPOINT的
SQL> select checkpoint_change# from v$datafile;CHECKPOINT_CHANGE#
------------------
3964521
3964521
3964521
3964521
3964521SQL> select checkpoint_change# from v$datafile_header;CHECKPOINT_CHANGE#
------------------
3964521
3964521
3964521
3964521
3964521SQL> shutdown immediate
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> startup mount
ORACLE 例程已经启动。Total System Global Area 176160768 bytes
Fixed Size 1247948 bytes
Variable Size 79693108 bytes
Database Buffers 92274688 bytes
Redo Buffers 2945024 bytes
数据库装载完毕。
SQL> select checkpoint_change# from v$datafile;CHECKPOINT_CHANGE#
------------------
3980038
3980038
3980038
3980038
3980038SQL> select checkpoint_change# from v$datafile_header;CHECKPOINT_CHANGE#
------------------
3980038
3980038
3980038
3980038
3980038SQL>
我试了下 结果是SCN也变化了可是我现在手动操作是要花时间的
SCN每3秒会自动更新一次
而CHECKPOINT好像并不会使SCN增加 只是同步各个SCN而已
所以我在想
如果操作速度足够快的话 呵呵 有没有可能SCN会保持不变
根据你们的描述和实验，也可以看的出来，你们的功力，也是非常的深入的。完全可以根据方向找到答案的。(*^__^*) 嘻嘻……。不过，你要做个检查点的变化的实验，不需要做这么复杂的实验，很多方式都可以看到的
比如
V$database, V$datafile都可以看到的。