tablespace备份

rejoice999

这个试验我做了一下：
1。alter database archivelog;
2。create tablespace ts_test
datafile 'c:\temp\ts_test1.dbf' size 64k;
3。alter tablespace ts_test begin backup;
4。create table t_test (c1 char(2000)) [B]tablespace ts_test[/B];
--原来没把指定表空间的子句写出来，想不到有人误解了，加上
     insert into t_test values ('aaaaaaaaaaaaaaaaaaaaaaaa');
     insert into t_test values ('aaaaaaaaaaaaaaaaaaaaaaaa');
     insert into t_test values ('aaaaaaaaaaaaaaaaaaaaaaaa');
     insert into t_test values ('aaaaaaaaaaaaaaaaaaaaaaaa');
     insert into t_test values ('aaaaaaaaaaaaaaaaaaaaaaaa');
     insert into t_test values ('aaaaaaaaaaaaaaaaaaaaaaaa');
     insert into t_test values ('aaaaaaaaaaaaaaaaaaaaaaaa');
     insert into t_test values ('aaaaaaaaaaaaaaaaaaaaaaaa');
     insert into t_test values ('aaaaaaaaaaaaaaaaaaaaaaaa');
     commit;
5。ocopy ts_test1.dbf bk1.dbf
6。truncate table t_test;
     insert into t_test values ('bbbbbbbbbbbbbbbbbbbbbbb');
     insert into t_test values ('bbbbbbbbbbbbbbbbbbbbbbb');
     insert into t_test values ('bbbbbbbbbbbbbbbbbbbbbbb');
     insert into t_test values ('bbbbbbbbbbbbbbbbbbbbbbb');
     insert into t_test values ('bbbbbbbbbbbbbbbbbbbbbbb');
     insert into t_test values ('bbbbbbbbbbbbbbbbbbbbbbb');
     commit;
7。ocopy ts_test1.dbf bk2.dbf
8。alter tablespace ts_test end backup;
     drop tablespace ts_test including contents;
9。 把bk1.dbf用winzip压成bk1.zip，CRC=597b06c0
10。把bk2.dbf用winzip压成bk2.zip，CRC=772225b0
11。结论：在BACKUP状态时，DBWn是写数据文件的。

最初由 rejoice999 发布
[B]这个试验很好做。
1。DATABASE置为ARCHIVELOG模式
2。建一个表空间ts_test，大小1M或更小
3。alter tablespace ts_test begin backup;
4。用OCOPY把数据文件备一份bk1.dbf
5。在这个表空间上建一个表，insert一些数据，越多越好。
6。可选，alter system switch logfile;
7。用OCOPY把数据文件再备一份bk2.dbf
8。alter tablespace ts_test end backup;
9。比较文件bk1.dbf和bk2.dbf，看是否相同。可以不用按字节比，把它们用winzip压一下，看看CRC是否相同就可以了。 [/B]

bluekey

有一个疑问。既然backup状态下，要写datafile，备出来的文件是不一致的，recover时用archived log 前滚。那么为什么要先switch logfile，写检查点，alter tablespace ...begin backup，直接ocopy即可，文件不一致，recover时可以用archived log 前滚。

rejoice999

不是太明白你在说什么，是不是作ONLINE BACKUP的步骤？
如果是，你说的在alter ....begin...之前作什么switch logfile并不是
必须的啊，相反在end backup之后倒是应该作switch logfile，使
当前的日志立刻归档，因为这个日志是恢复所需要的，以免万一在
归档前坏掉。

最初由 bluekey 发布
[B]有一个疑问。既然backup状态下，要写datafile，备出来的文件是不一致的，recover时用archived log 前滚。那么为什么要先switch logfile，写检查点，alter tablespace ...begin backup，直接ocopy即可，文件不一致，recover时可以用archived log 前滚。 [/B]

bluekey

我的意思是，既然置backup状态后，照样写datafile，ocopy出的datafile照样是不一致的，那么热备份时为什么要先置为backup状态，不置backup状态直接ocopy即可，反正recover时可以用archived log前滚。

biti_rainy

这个时候不会写数据文件的

所有的相关内容全部写入日志文件
所以这个操作应该在数据库比较空闲的时候做
否则会产生大量的日志而严重影响数据库性能

当结束backup状态后
数据库自动把记录进日志中的东西应用到数据文件

这个问题在 backup  and  recovery  部分有很仔细的描述的
这也是为什么只能在归档模式下做热备的原因

如果不是归档模式，数据库无法保障在这个过程中的操作能记录在日志里面

bluekey

可是又怎么解释rejoice999的实验，他的实验确实证明了在backup状态下，datafile同样也发生了变化。

freewill

发现不能尽信书，书上很多地方都有矛盾

rejoice999

我怎么说还是不能令人相信，还是转贴两篇吧。
===========================

Subject: What Happens During a Hot Backup

The BEGIN BACKUP command checkpoints the datafiles and advances the datafile
header checkpoints to the begin backup checkpoint SCN. Until the END BACKUP
command is executed, checkpoints will cease to update the datafile headers.
It starts the logging of block images.

Each time the block is read into cache an image of the whole block before the
first change is logged.

The END BACKUP command creates a redo record containing the begin backup
checkpoint SCN. It stops the logging of block images and causes the datafile
checkpoints to be advanced to the database checkpoint.
[B]
Datafile updates by DBWR go on as usual during the time the backup is being
copied[/B] so the backup gets a "fuzzy" copy of the datafile: some blocks may be
ahead in time versus other blocks and some may contain updates by transactions
that are later rolled back. The "fuzzy" backup copy is unusable without the
"focusing" via the redo log that occurs when the backup is restored and
undergoes media recovery. Media recovery applies redo (from all threads) from
the checkpoint SCN that was captured at BEGIN BACKUP time through the
end-point of the recovery operation.

Once redo application is finished, uncommited transactions are rolled back to
leave a transaction-consistent "focussed" version of the datafile.

--------------------------------------------------------------------------------
Copyright (c) 1995,2000 Oracle Corporation. All Rights Reserved. Legal Notices and Terms of Use.

rejoice999

Oracle Server Enterprise Edition Technical Forum

Thread Status: Closed

From: Casey Bowden 13-Aug-01 23:01
Subject: Hot Backup Order

RDBMS Version: 8.1.5
Operating System and Version: Win NT 4. SP5
Error Number (if applicable):
Product (i.e. SQL*Loader, Import, etc.):
Product Version:

Hot Backup Order

Which is better, to put a tablespace in backup mode and copy off all datafiles then end backup on said tablespace. OR Put the tablespace in backup mode, copy off one datafile, end backup on said tablesapce and repeat for all datafiles? Please explain how the System Change Numbers are used in the header of the datafile and what is the Oracle recommendendation. And how each situation uses them differntely.
Thanks
Casey


--------------------------------------------------------------------------------

From: Vinod Menon 14-Aug-01 15:40
Subject: Re : Hot Backup Order


Basically this depends on situations. Say you have large # of datafiles under a single tablespace. In that case it is better to copy some of the datafiles, then switch modes and continue.

The reason is on taking a tablespace in backup mode the headers r updated immediately through forced check points - which gurantees that the datafiles are latest. On crash you might need lesser recovery time this case.


--------------------------------------------------------------------------------

From: Oracle, Helen Schoone 16-Aug-01 20:46
Subject: Re : Hot Backup Order


Hi. I see no reason to alter a tablespace into and out of hot backup mode for each datafile of the tablespace. Sounds like more of a possibility for errors. Also, each time you alter a tablespace into hot backup mode, a checkpoint will occur causing any modified blocks for all the files of that tablespace to be flushed to disk.

Each datafile header contains checkpoint information. The checkpoint SCN guarantees that all data associated with a change prior to that SCN have been flushed to disk. [B]When you alter a tablespace into hot backup mode, Oracle checkpoints, then stops checkpointing the file header of all datafiles in the tablespace while it is in hot backup mode, although DBWR continues to write changed blocks to the files, as applicable.[/B] If the file later needs to be restored and recovered, Oracle knows that recovery of that file needs to begin at the checkpoint SCN recorded in the file header when the tablespace was altered into backup mode. During the time the tablespace is in hot backup mode, extra information is written to redo for all changes made to the datafiles of the tablespace which facilitates recovery of the files since they can be copied while they are being written to.

Once you alter a tablespace out of hot backup mode, Oracle records the information in the redo, updates the checkpoint information in the file headers and normal processing resumes.

I hope this helps.


Regards,
Helen
Oracle Support Services

--------------------------------------------------------------------------------

Copyright (c) 1995,2000 Oracle Corporation. All Rights Reserved. Legal Notices and Terms of Use.

rejoice999

Rainy，

我不同意你的这个说法：
“这个时候不会写数据文件的，所有的相关内容全部写入日志文件，当结束backup状态后数据库自动把记录进日志中的东西应用到数据文件”
你可以看我上面转贴的来自ORACLE的文章，也可以实验证明：
alter tablespace ts_test begin backup；
产生大量insert, delete, update，使所有log group写满，也就是
要有至少一个log被归档后覆盖，这个archived log中包含有begin
backup兵的“相关内容”
归档后，把这个archived log挪到其它目录，Oracle应该找不到了，这时alter tablespace ts_test end backup；
如果照你的说法，数据库应该没法end backup了，完蛋了的说！

最初由 biti_rainy 发布
[B]这个时候不会写数据文件的

所有的相关内容全部写入日志文件
所以这个操作应该在数据库比较空闲的时候做
否则会产生大量的日志而严重影响数据库性能

当结束backup状态后
数据库自动把记录进日志中的东西应用到数据文件

这个问题在 backup  and  recovery  部分有很仔细的描述的
这也是为什么只能在归档模式下做热备的原因

如果不是归档模式，数据库无法保障在这个过程中的操作能记录在日志里面 [/B]