Logging for Guaranteed Restore Points With Flashback Logging Disabled【每日一译】--20121121

If a guaranteed restore point is created when logging for Flashback Database is
disabled, then, the first time a datafile block is modified after the time of the
guaranteed restore point, an image of the block before the modification is stored in the
flashback logs. The flashback logs thus preserve the contents of every changed data
block at the time that the guaranteed restore point was created. However, subsequent
modifications to the same block do not cause the block contents to be logged again,
unless another guaranteed restore point has been created since the block was last

modified.

当闪回数据库的日志被禁止时，如果保证修复点创建，数据文件的数据块第一次被修改在

保证修复点之后，一个块的镜像在修改前将存储在闪回日志中。闪回日志预留了每次改变

数据块的内容在确保修复点被创建时。后续对于同一个块的修改将不会导致块的内容再次产生日志，

除非另一个保证修复点在这个块最后一次修改前被创建。

This method of logging has the following important consequences:
■ The available block images can be used to re-create the datafile contents at the
time of a guaranteed restore point using FLASHBACK DATABASE, but you cannot
use FLASHBACK DATABASE to reach points in time between the guaranteed restore
points and the current time, as is possible when logging for Flashback Database is
enabled. If you need to return the database to an intermediate point in time, your

only option is database point-in-time recovery.

这个日志的方法拥有以下重要的结果：

#可用块的镜像可用于重建数据文件的内容在使用闪回数据库确保修复点时，但你不能使用闪回

数据库到达保证修复点和当前时间之前的点，当对于闪回数据库的日志被允许时它是可能的。如果

你需要将数据库返回到一个中间的时间点时，你唯一的选择是采用数据库的基于时间点的还原。

■ Because each block that changes is only logged once, disk space usage for logging
for guaranteed restore points when flashback logging is disabled is generally
considerably less than normal flashback logging. You could maintain a guaranteed

restore point for days or even weeks without concern over the ongoing growth of

flashback logs that occurs if logging for Flashback Database is enabled. The
performance overhead of logging for a guaranteed restore point without flashback
database logging is generally lower as well.

#因为每次数据块的改变日志只产生一次，当闪回数据库日志关闭，对于保证修复点的日志的磁盘

使用空间一般远远少于正常的闪回日志。你可以维护一个保证修复点几天或者甚至几周，不用关注

闪回日志的继续增长，它发生于如果闪回数据库的日志被开启。对于确保修复点的日志性能消耗在

没有数据库日志时一般是比较低的。

If your primary need is to be able to return your database to the specific point in time
at which the guaranteed restore point was created, then it is generally more efficient
to turn off logging for Flashback Database and use only guaranteed restore points.
For example, in a scenario in which you are performing an application upgrade on a
production database server over a weekend, you could create a guaranteed restore
point at the start of the upgrade process and, if the process failed at the end, reverse
the changes using FLASHBACK DATABASE instead of restoring the database from
backups.

如果你主要需要是可以返回你的数据库到指定的时间点在保证修复点被创建时，那么它是一般

更有效的对于关闭闪回数据库日志并且仅使用保证修复点，比如，在一种场景中你执行一个

生产数据库的应用升级在一个周末，你可以创建一个保证修复点在更新进程开始时，如果最后过程

失败，返回改变使用闪回数据库来代替数据库从备份的修复 。