加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 百科 > 正文

Using Flashback Database and Restore Points

发布时间:2020-12-15 17:25:31 所属栏目:百科 来源:网络整理
导读:? ? ?Using Flashback Database and Restore Points This chapter explains Flashback Database,restore points. This chapter discusses configuring,monitoring,and maintaining these features as part of an overall data protection strategy. ? 这一章

? ? ?Using Flashback Database and Restore Points

This chapter explains Flashback Database,restore points. This chapter discusses configuring,monitoring,and maintaining these features as part of an overall data protection strategy. ?>>>>这一章,解释闪回数据库,还原点。讨论,作为整个数据保护策略一部分的闪回数据库,闪回等特性的配置,监控和管理

This chapter contains the following topics: ?>>>>该章节包括如下内容:

  • Understanding Flashback Database,Restore Points and Guaranteed Restore Points

  • Logging for Flashback Database and Guaranteed Restore Points

  • Prerequisites for Flashback Database and Guaranteed Restore Points

  • Using Normal and Guaranteed Restore Points

  • Using Flashback Database

See Also:

Detailed information on recovery scenarios that use Flashback Database and normal and guaranteed restore points can be found in? Chapter 18,"Performing Flashback and Database Point-in-Time Recovery".

Understanding Flashback Database,Restore Points and Guaranteed Restore Points ?

Oracle Flashback Database?and restore points are related data protection features that enable you to rewind data back in time to correct any problems caused by logical data corruption or user errors within a designated time window. These features provide a more efficient alternative to point-in-time recovery and does not require a backup of the database to be restored first. The effects are similar to?database point-in-time recovery (DBPITR). Flashback Database and restore points are not only effective in traditional database recovery situations but can also be useful during database upgrades,application deployments and testing scenarios when test databases must be quickly created and re-created. Flashback Database also provides an efficient alternative to rebuilding a failed primary database after a Data Guard failover. ?>>>>

oracle闪回数据库和还原点是用来保护数据的功能,使你能够在设定的时间窗口内,把据逻辑损坏和用户错误引起的数据问题,回退到之前正常的时间点。数据库的这些功能为我们提供了一种更高效的数据库基于时间点恢复的方法,并且在恢复之前不需要先restore做数据库的备份文件。此种方法恢复的效果同DBPITR恢复的效果类似。数据库闪回和还原点不仅可以用于传统的数据库恢复情形,而且可以用于数据库升级,应用部署和一些测试场景(需要测试的环境能够被快速的创建和重建)。闪回数据库还提供了一种有效的,在Data Guardfailover时重建失败的主库的方法。

See Also:

Oracle Data Guard Concepts and Administration

Restore points provide capabilities related to Flashback Database and other media recovery operations. In particular,a guaranteed restore point created at a system change number (SCN) ensures that you can use Flashback Database to rewind the database to this SCN. You can use restore points and Flashback Database independently or together.

Flashback Database is accessible through the RMAN command?FLASHBACK?DATABASE?or the SQL statement?DATABASE. You can use either command to quickly recover the database from logical data corruption or user errors. The following examples return the database to a specified SCN or restore point: ?>>>>我们可以在rman或者sqlplus命令行中调用 flashback database命令。flashback database可以用来快速的恢复逻辑数据损坏,也可以用来快速恢复用户的误操作。下面是把数据库恢复到指定的还原点和scn的例子:

FLASHBACK DATABASE TO RESTORE POINT 'before_upgrade';
FLASHBACK DATABASE TO SCN 202381;

Flashback Database

Flashback Database is accessible through the?RMAN command and SQL statement?FLASHBACK DATABASE. You can use either command to quickly recover the database from logical data corruptions or user errors. ?>>>>们可以在rman或者sqlplus命令行中调用 flashback database命令。flashback database可以用来快速的恢复逻辑数据损坏,也可以用来快速恢复用户的误操作。

Flashback Database is similar to conventional point-in-time recovery in its effects. It enables you to return a database to its state at a time in the recent past. Flashback Database is much faster than point-in-time recovery because it does not require restoring datafiles from backup and requires applying fewer changes from the archived redo logs. ?>>>>闪回数据库和传统的DBPITR效果类似。闪回数据库能够让你把数据库恢复到其过去的某个时间点的状态。因为闪回数据库不需要从备份中restore数据文件,并且从归档日志中应用更少的变化(这与闪回数据库的日志记录方式有关),所以使用闪回数据库来做恢复比传统的PITR更快。

You can use Flashback Database to reverse most unwanted changes to a database if the data files are intact. You can return a database to its state in a previous?incarnation,and undo the effects of an?ALTER DATABASE OPEN RESETLOGS?statement.?"Rewinding a Database with Flashback Database"explains how to use the?DATABASE?command to reverse database changes. ?>>>>如果数据文件是完整的,你可以使用闪回数据库回滚掉大多数的你不想要的数据库变更。你可以用数据库闪回把数据库恢复到之前的incarnation状态,同时回滚掉alter database open?resetlogs语句对数据的影响

Flashback Database uses its own logging mechanism,creating?flashback logs?and storing them in the?fast recovery area. You can only use Flashback Database if flashback logs are available. To take advantage of this feature,you must set up your database in advance to create flashback logs. ?>>>>闪回数据库有自己的日志记录机制,闪回日志被创建和存储在fast recoveryarea。只有在闪回日志可用的情况下,你才能够使用闪回数据库。要利用此功能,你必须先打开数据库的flashback功能(alterdatabase flashback on;)

To enable Flashback Database,you configure a fast recovery area and set a?flashback retention target. This retention target specifies how far back you can rewind a database with Flashback Database. ?>>>>flashback retention target是指你可以使用闪回数据库功能,把你的数据库恢复到多久之前的状态的时间间隔。

From that time onwards,at regular intervals,the database copies images of each altered block in every data file into the flashback logs. These block images can later be reused to reconstruct the data file contents for any moment at which logs were captured. ?>>>>从开启闪回数据库功能后,每隔固定的时间间隔,数据库复制每一个在这个时间间隔内产生变化的数据块到闪回日志中。闪回日志中的数据块镜像,可以用来恢复数据文件到这些数据块被复制的任意时刻(这样就完成了,flashback?的第一步,第二步就是应用归档及在线日志)

When you use Flashback Database to rewind a database to a past target time,the command determines which blocks changed after the target time and restores them from the flashback logs. The database restores the version of each block that is immediately before the target time. The database then uses redo logs to reapply changes that were made after these blocks were written to the flashback logs. ?>>>>当你使用flashback database来恢复你的数据库到之前的某一目标时刻,这个命令判断在目标时刻之后哪些数据块发生了变化,然后从flashback log中恢复这些数据块在目标时刻之前的并且最接近目标时刻的镜像。再完成变化的数据块恢复以后,数据库利用redo日志来重新应用数据块镜像产生时刻(也就是数据块镜像被复制进入flashback log的时刻)与目标时刻之间的数据库变化。

Redo logs on disk or tape must be available for the entire time period spanned by the flashback logs. For example,if the flashback retention target is 1 week,then you must ensure that online and archived redo logs that contain all changes for the past week are accessible. In practice,redo logs are typically needed much longer than the flashback retention target to support point-in-time recovery. ?>>>>flashback log的整个时间周期内,磁盘或者磁带上的redo logs必须是可用的。例如,如果flashback retention目标是一周,那么你必须保证最近一周的onlinearchived redo logs必须是可以访问的。事实上为了保证能够完成flashbackretention target指定时间的point-in-time数据库恢复,redo logs(包括 archived logs)通常需要保留的比flashback retention target所指定的时间更长的时间间隔

Flashback Database Window

The range of SCNs for which there is currently enough flashback log data to support the?DATABASE?command is called the?flashback database window. The flashback database window cannot extend further back than the earliest SCN in the available flashback logs.

Note:

Some database operations,such as dropping a tablespace or shrinking a data file,cannot be reversed with Flashback Database. See "Limitations of Flashback Database"?for details. ?>>>>

注意:一些数据库操作,如drop a database或者shrinking a data file 不能使用flashbackdatabase进行闪回。

You cannot back up flashback logs to locations outside the fast recovery area. To increase the likelihood that enough flashback logs are retained to meet the flashback database window,you can increase the space in your fast recovery area (see?"Initialization Parameters for the Fast Recovery Area"). ?>>>>你不能把flashback logs备份到fast recovery area以外的其他任何地方。你可以通过增加fast recoveryarea,来增加flashback database window

If the fast recovery area is not large enough to hold the flashback logs and files such as archived redo logs and other backups needed for the retention policy,then the database may delete flashback logs from the earliest SCNs forward to make room for other files. Consequently,the flashback database window can be shorter than the flashback retention target,depending on the size of the fast recovery area,other backups that must be retained,and how much flashback logging data is needed. The flashback retention target is a target,not a guarantee that Flashback Database is available. ?>>>>如果fast recovery area被用来存放flashback logsarchived redo logs以及一些其他的为了保持flashback retention target所需要的备份文件,并且空间不足时,数据库会删除一些最早的falshbacklogs为其他文件空出空间。这样的话我们的flashbackretention target可能就会缩短。上面一段话的描述我们可以看出,flashback retention target只是我们期望的一个目标,这个间隔并不能得到强制的保证。

If you cannot use?FLASHBACK DATABASE?because the flashback database window is not long enough,then you can use database point-in-time recovery (DBPITR) in most cases to achieve a similar result. Guaranteed restore points are the only way to ensure that you can use Flashback Database to return to a specific point in time or guarantee the size of the flashback window. ?>>>>如果因为闪回窗口太短,不能使用flashback database来闪回数据库的话,在多数情况下你可以使用DBPITR实现相同的目的。能够保证你把数据库闪回到一个指定时间点或者保证闪回窗口大小的唯一方法就是使用Guaranteed restore points

See Also:

  • "Rewinding a Database with Flashback Database"?to learn about Flashback Database

  • "Performing Database Point-in-Time Recovery"?to learn about DBPITR

Limitations of Flashback Database

Because Flashback Database works by undoing changes to the data files that exist at the moment when you run the command,it has the following limitations: ?>>>>因为flashback database 的作用是回滚命令执行时数据库中所有数据文件的数据变化,所以flashbackdatabase有如下限制

  • Flashback Database can only undo changes to a data file made by Oracle Database. It cannot be used to repair media failures,or to recover from accidental deletion of data files. ?>>>>flashback database只能回退数据库产生的变化(比如deleteupdateinsert),不能用来恢复介质损坏或者数据文件的误删除

  • You cannot use Flashback Database to undo a shrink data file operation. However,you can take the shrunken file offline,flash back the rest of the database,and then later restore and recover the shrunken data file. ?>>>>flashback database 不能回退datafile shrink操作。然而,你可以把被shrink的数据文件offlineflashback 数据剩余的部分,然后再restorerecovershrink的数据文件

  • You cannot use Flashback Database alone to retrieve a dropped data file. If you flash back a database to a time when a dropped data file existed in the database,only the data file entry is added to the control file. You can only recover the dropped data file by using RMAN to fully restore and recover the data file. ?>>>>你无法只用flashback database恢复被删除的数据文件。如果你使用flashback database把数据库恢复到数据文件被删除之前(这里指的删除不是操作系统级别删除),仅仅是在控制文件中重新添加了数据文件记录,但是实际上数据文件并未被恢复出来。想要恢复被删除的控制文件,你只能通过rman使用restorerecover

  • If the database control file is restored from backup or re-created,all accumulated flashback log information is discarded. You cannot useFLASHBACK DATABASE?to return to a point in time before the restore or re-creation of a control file. ?>>>>如果数据库的控制文件是从备份中restore或者重建的,之前所有的闪回日志都无效。无法使用flashback database把数据库恢复到控制文件restore或者re-create之前的某个时刻

  • When using Flashback Database with a target time at which a?NOLOGGING?operation was in progress,block corruption is likely in the database objects and datafiles affected by the?NOLOGGING?operation. For example,if you perform a direct-path?INSERT?operation in?NOLOGGING?mode,and that operation runs from 9:00 to 9:15 on April 3,2005,and you later use Flashback Database to return to the target time 09:07 on that date,the objects and datafiles updated by the direct-path?INSERT?may be left with block corruption after the Flashback Database operation completes.

    If possible,avoid using Flashback Database with a target time or SCN that coincides with a?NOLOGGING?operation. Also,perform a full or incremental backup of the affected data files immediately after any?NOLOGGING?operation to ensure recoverability to points in time after the operation. If you expect to use Flashback Database to return to a point in time during an operation such as a direct-path?INSERT,consider performing the operation in?LOGGING?mode. ?>>>>flashback database遇到nologing操作就可能会产生逻辑坏块。例如,如果你对某个对象执行了nologging模式的direct-path插入,这个操作9:00 to 9:15 on April 3,2005,之后你使用flashback database 恢复数据库到9:07,那么在完成flashback database后,当时被nologging direct-insert模式插入的对象可能会有逻辑坏块产生

    See Also:

    LOGGING_CLAUSE?in? Oracle Database SQL Reference?for more information about operations that support? NOLOGGING?mode.

Normal Restore Points

Creating a?normal restore point?assigns a restore point name to an SCN or specific point in time. Thus,a restore point functions as a bookmark or alias for this SCN. Before performing any operation that you may have to reverse,you can create a normal restore point. The control file stores the name of the restore point and the SCN. ?>>>>创建一个普通还原点就是把还原点名称同一个scn或者指定的时刻联系起来。因此还原点作用就相当于一个书签或者scn的别名。在做任何可能需要回滚的操作之前,你可以先创建一个普通的还原点。控制文件中存储着还原点的名称和其所对应的scn

If you use flashback features or point-in-time recovery,then you can use the name of the restore point instead of a time or SCN. The following commands support this use of restore points:

  • The?RECOVER DATABASE?and?FLASHBACK DATABASE?commands in RMAN

  • The?FLASHBACK TABLE?statement in SQL

Creating a normal restore point eliminates manually recording an SCN in advance or determine the correct SCN after the fact by using features such as Flashback Query. ?>>>>使用普通还原点我们就省去了手动记录scn和在使用如flashback query功能时判断正确scn的工作了

Normal restore points are lightweight. The control file can maintain a record of thousands of normal restore points with no significant effect on database performance. Normal restore points eventually age out of the control file if not manually deleted,so they require no ongoing maintenance. ?>>>>普通的还原点是轻量的。控制文件维护成千上万的普通还原点记录都不会对数据库性能产生显著的影响。如果普通还原点没有被认为删除,那么最后它会因过期被清除,所以对于普通还原点不需要我们维护

See Also:

Oracle Database Advanced Application Developer's Guide?to learn how to use Flashback Query

Guaranteed Restore Points

Like a normal restore point,a?guaranteed restore point?serves as an alias for an SCN in recovery operations. A principal difference is that guaranteed restore points never age out of the control file and must be explicitly dropped. In general,you can use a guaranteed restore point as an alias for an SCN with any command that works with a normal restore point. Except as noted,the information about where and how to use normal restore points applies to guaranteed restore points as well. ?>>>>就像普通还原点一个,保证还原点也是作为scn的别名在恢复操作中使用。两种还原点的一个主要区别就是,保证还原点永远不会从控制文件中过期被自动删除,必须人为的删除。通常普通还原点和保证还原点的用法是一样的,除非另有说明。

A guaranteed restore point ensures that you can use Flashback Database to rewind a database to its state at the restore point SCN,even if the generation of?flashback logs?is disabled. If flashback logging is enabled,then a guaranteed restore point enforces the retention of flashback logs required for Flashback Database to any SCN after the earliest guaranteed restore point. Thus,if flashback logging is enabled,you can rewind the database to any SCN in the continuum rather than to a single SCN only. ?>>>>即使flashback logs被禁用,flashback database使用保证还原点也能确保数据库被还原到保证还原点所指定的scn如果flashback logs可用,那么保证还原点会强制保留能使数据flashbackdatabase到最早的guaranteedrestore point所需的flashbacklogs。因此,如果flashback logging可用,那么你就能把数据库恢复到当前到最早的guaranteedrestore point间的任意一个时间点。

Caution:

If flashback logging is disabled,then you? cannot? FLASHBACK? DATABASE?directly to SCNs between the guaranteed restore points and the current time. You can,however,flashback to the guaranteed restore point first and then recover to SCNs between the guaranteed restore point and current time. ?>>>>如果flashback logging没有启用,那么你无法使用flashback database直接把数据库恢复到guaranteed restore point和current time之间的某一个时刻。然而你可以先使用flashbackdatabase把数据库恢复到guaranteedrestore point,然后再通过recover命令把数据库恢复到需要的scn

If the recovery area has enough disk space to store the needed logs,then you can use a guaranteed restore point to rewind a whole database to a known good state days or weeks ago. As with Flashback Database,even the effects of?NOLOGGING?operations like direct load inserts can be reversed with guaranteed restore points.

Note:

Limitations that apply to Flashback Database also apply to guaranteed restore points. For example,shrinking a data file or dropping a tablespace can prevent flashing back the affected data files to the guaranteed restore point. See? "Limitations of Flashback Database"?for details. In addition,when there are guaranteed restore points in the database,the database compatibility parameter cannot be set to a higher database version. An attempt to do so results in an error. This restriction exists because flashback database is currently unable to reverse the effects of increasing the database version with the compatibility initialization parameter. ?>>>>对于flashbackdatabase的使用的限制,同样适用于guaranteed restore point。另外,当数据库中存在guaranteedrestore points时,数据库的compatible不能被设置为更高的数据库版本,这样的尝试会报错。这个限制的存在是因为flashbackdatabase 当前还无法回滚因为把compatible参数提高到更高的版本,对数据库产生的影响

Guaranteed Restore Points versus Storage Snapshots

In?practice,guaranteed restore points provide a useful alternative to storage snapshots. Storage snapshots are often used to protect a database before risky operations such as large-scale database updates or application patches or upgrades. Rather than creating a snapshot or?duplicate database?to test the operation,you can create a guaranteed restore point on a primary or?physical standby database. You can then perform the risky operation with the certainty that the required flashback logs are retained. ?>>>>在实践中,保证还原点为存储快照提供了一个有效的替代。存储快照经常在对数据库作一些有风险的操作之前使用,用来保护数据库。相较于创建一个快照或者复制一个数据库用来测试,你可以选择在主库或者备库上创建一个guaranteed restorepoint

Logging for Flashback Database and Guaranteed Restore Points

Logging for Flashback Database and guaranteed restore points involves capturing images of data file blocks before changes are applied. TheDATABASE?command can use these images to return the data files to their previous state. ?>>>>flashback databaseguaranteed restore points日志记录的是数据块变化之前的镜像。flashback database 命令可以使用这些数据块的镜像把数据文件恢复到某个时刻之前的状态。

The chief differences between normal flashback logging and logging for guaranteed restore points are related to when blocks are logged and whether the logs can be deleted in response to space pressure in the fast recovery area. These differences affect space usage for logs and database performance. ?>>>>普通还原点的日志和保证还原点日志主要的区别有两个方面,第一点是blocks的镜像什么时候被复制进flashback log,第二点是如果在fast recovery area空间不足的时候flashback logs能否被删除。这些区别会对fast recovery area空间的使用以及数据库的性能产生不同的影响。

Your recoverability goals partially determine whether to enable logging for flashback database,or use guaranteed restore points,or both. The implications in performance and in space usage for these features,separately and when used together,should also factor into your decision. ?>>>>你的恢复目标帮助你决定是启用闪回日志,或者是使用guaranteedrestore point,或者这两者同时使用。当然在选择是单独使用上面的某一个或者两者结合使用时,你也应该考虑你的选择可能会对fast recovery area使用及数据库性能产生的影响

Guaranteed Restore Points and Fast Recovery Area Space Usage

The following rules govern creating,retaining,overwriting and deleting of flashback logs in the fast recovery area: ?>>>>下面给出的是flashback logsfast recovery area中创建,保留,重用和删除的策略

  • If the fast recovery area has enough space,then a flashback log is created whenever necessary to satisfy the flashback retention target. ?>>>>

    如果fast recovery area空间足够,那么新的flashback log会被创建,无论是否满足flashback retention target

  • If a flashback log is old enough that it is no longer needed to satisfy the flashback retention target,then a flashback log is reused. ?>>>>

    如果flashback log足够旧,超出了满足flashback retention target的需要,那么这些flashback log可以被重用

  • If the database must create a flashback log and the fast recovery area is full or there is no disk space,then the oldest flashback log is reused instead. ?>>>>如果数据库需要产生flashback log但是fast recover area空间不足,那么最旧的flashback log会被重用

    Note:

    Reusing the oldest flashback log shortens the flashback database window. If enough flashback logs are reused due to a lack of disk space,then the flashback retention target may not be satisfied. ?>>>> 注意因为 fast recovery area 空间不足,导致最旧的 flashback log 被重用,可能会缩短我们的 flashbackdatabase 窗口,那样的话我们的 flashbackretention target 可能就无法被满足
  • If the fast recovery area is full,then an archived redo log that is reclaimable according to the fast recovery area rules may be automatically deleted by the fast recovery area to make space for other files. In this case,any flashback logs that would require the use of that redo log file for the use ofDATABASE?are also deleted. ?>>>>如果fast recovery area已经使用完,那么根据fast recovery area规则那些可以被回收的归档日志会被自动删除,为其他文件腾出可用空间。在归档日志被删除的同时,那些flashback database时需要用到这些归档的flashback log也会被删除。

    Note:

    According to fast recovery area rules,a file is reclaimable when one of the following criteria is true:
    • The file is reported as obsolete and not needed by the flashback database. For example,the file is outside theDB_FLASHBACK_RETENTION_TARGET?parameters. The file is backed up to tape. ?>>>>oracle根据一些规则确定fast recovery area中哪些文件是可以被重用的,这个规则就是这些文件不是满足DB_FLASHBACK_RETENTION_TARGET所需要的,或者这个文件被备份到了存储设备上

  • No file in the fast recovery area is eligible for deletion if it is required to satisfy a guaranteed restore point. However,archived redo logs required to satisfy a guaranteed restore point may be deleted after they are backed up to disk or tape. When you use the?RMAN FLASHBACK DATABASEcommand,if the archived redo logs required to satisfy a specified guaranteed restore point are not available in the fast recovery area,then they are restored from the backups. ?>>>>如果fast recovery area里的文件是为了恢复guaranteed restore point所需要使用的,那么这些文件是不能被删除的。如果某些归档日志是恢复到guaranteedrestore point所需要使用的,但是它们已经被备份到磁盘或者带库,那么它们也是可以被删除的。如果你在rman中使用flashbackdatabase把数据库恢复到某个guaranteedrestore point时,需要使用的归档日志在fast recoveryarea中已经被删除,那么数据库会从备份文件中restore这些归档到fast recovery area

    Retention of flashback logs and other files required to satisfy the guaranteed restore point,in addition to files required to satisfy the backup retention policy,can cause the fast recovery area to fill completely. Consult?"Responding to a Full Fast Recovery Area"?if your fast recovery area becomes full.

When you create a guaranteed restore point,with or without enabling full flashback database logging,you must monitor the space available in your fast recovery area.?"Managing Space for Flashback Logs in the Fast Recovery Area"?explains how to monitor fast recovery area disk space usage. ?>>>>无论是否启用了flashback database logging,当你创建了guaranteed restore point以后,你都要注意监控fast recovery area的使用情况。

Caution:

If no files are eligible for deletion from the fast recovery area because of the requirements imposed by your retention policy and the guaranteed restore point,then the database performs as if it has encountered a disk full condition. In many circumstances,this causes your database to halt. See? "Responding to a Full Fast Recovery Area". ?>>>>注意:注意fast recoveryarea的使用情况,可以因为你的保留策略和使用了guaranteed restore point,造成你的fast recovery area空间不足,从而使你的数据库hung住

Logging for Guaranteed Restore Points with Flashback Logging Disabled

Assume that you create a guaranteed restore point when logging for Flashback Database is disabled. In this case,the first time a data file block is modified after the time of the guaranteed restore point,the database stores an image of the block before the modification in the flashback logs. Thus,the flashback logs preserve the contents of every changed data block at the time that the guaranteed restore point was created. Later modifications to the same block do not cause the contents to be logged again unless another guaranteed restore point was created after the block was last modified. ?>>>>假设你在没有开启flashback database logging的情况下,创建了一个guaranteed restore point这种情况下,在guaranteed restore point创建以后,数据块在第一次被修改之前,数据库会把数据块未修改之前的镜像储存在flashback logs中。因此,flashbacklogs保存了每个数据块在guaranteed restore point被创建时的内容。除非又一个新的guaranteed restore point被创建了,否则数据块在guaranteed restore point创建后只会被在flashback log中记录一次,而不论你对数据块做了多少次修改。

This method of logging has the following important consequences: ?>>>>这样的日志记录方案有如下的重要性:

  • DATABASE?can re-create the data file contents at the time of a guaranteed restore point by using the block images. ?>>>>

    我们可以使用flashback database把数据库恢复到guaranteed restore point创建的时间点

  • For workloads that repeatedly modify the same data,disk space usage can be less than normal flashback logging. Less space is needed because each changed block is only logged once. Applications with low volume inserts may benefit from this disk space saving. This advantage is less likely for applications with high volume inserts or large batch inserts. The performance overhead of logging for a guaranteed restore point without flashback database logging enabled can also be lower. ?>>>>对于那种重复修改相同数据的工作环境,这种日志记录方式可以比普通的flashbacklogging记录方式更节省空间。这种日志记录方式更节省空间是因为每一个数据块的镜像最多只会在flashback log中记录一次。如果应用中只有少量的 insert这样会更节省空间。没有启用flashbackdatabase loggingguaranteedrestore point日志记录方式,对数据库的性能影响比较小。

Assume that your primary goal is the ability to return your database to the time at which the guaranteed restore point was created. In this case,it is usually more efficient to turn off flashback logging and use only guaranteed restore points. For example,suppose that you are performing an application upgrade on a database host over a weekend. You could create a guaranteed restore point at the start of the upgrade. If the upgrade fails,then reverse the changes with the?DATABASE?command. ?>>>>如果你的主要目的是能把你的数据库恢复到guaranteedrestore point创建时的状态,那么我们关闭flashbacklogging单独使用guaranteed restore points更有效率。例如,你要在一个周末进行应用升级,那么你可以在升级之前先创建一个guaranteed restore point,如果升级失败了,就使用flashback database 命令回退你的数据库到升级之前的状态

Logging for Flashback Database with Guaranteed Restore Points Defined

If you enable Flashback Database and define one or more guaranteed restore points,then the database performs normal flashback logging. In this case,the recovery area retains the flashback logs required to flash back to any arbitrary time between the present and the earliest currently defined guaranteed restore point. Flashback logs are not deleted in response to space pressure if they are required to satisfy the guarantee. ?>>>>如果你开启了flashback database并且创建了guaranteed restore point,那么数据库采用普通的flashback logging方法记录日志。这样的话,fast recovery area中会保存着把数据库从当前恢复到最早的guaranteedrestore point之间任何时刻所需要的任何flashbacklogs。如果flashback logs是满足guaranteed restore point所需要的,那么即使在fast recovery area空间不足的时候,这些flashback logs 也不会被删除。

Flashback logging causes some performance overhead. Depending upon the pattern of activity on your database,it can also cause significant space pressure in the fast recovery area. Thus,you should monitor space used in the fast recovery area. ?>>>>这种情况下记录flashback log会对数据库性能有一定的影响。此种日志记录方式,根据你数据库的活跃程度不同,可能会给fast recovery area空间的使用带来压力,因此你需要监控你的fast recovery area的使用情况。

Prerequisites for Flashback Database and Guaranteed Restore Points

To ensure successful operation of Flashback Database and guaranteed restore points,you must first set several key database options. ?>>>>

为了保证能够成功的使用flashback databaseguaranteed restore points,你必须先对数据库作出如下几项关键设置

Flashback Database

Configure the following database settings before enabling Flashback Database: ?>>>>

在启用flashback database之前对数据库作如下配置

  • Your database must be running in?ARCHIVELOG?mode,because archived logs are used in the Flashback Database operation. ?>>>>

    使数据库处于归档模式下(flashback database 需要使用flashback logsredo)

  • You must have a fast recovery area enabled,because flashback logs can only be stored in the fast recovery area. ?>>>>

    必须设置fast recovery area(注意在设置db_recovery_file_dest之前要先设置db_recovery_file_dest_size,否则会报ORA-19802)

  • For Oracle Real Application Clusters (Oracle RAC) databases,the fast recovery area must be in a clustered file system or in ASM. ?>>>> ? ? ? ? ?对于RAC 数据库,fast recovery area必须放在共享文件系统,或者asm

Guaranteed Restore Points

To use guaranteed restore points,the database must satisfy the following additional prerequisite: the?COMPATIBLE?initialization parameter must be set to 10.2.0 or greater ?>>>>

要使用guaranteed restore point功能,数据库的初始化参数COMPATIBLE?必须大于10.2.0

Note:

There are no special prerequisites to set before using normal restore points. ?>>>>

除了COMPATIBLE?参数需要满足大于10.2.0以外在我们使用guaranteedrestore points之前不需要对数据库作其他配置

Using Normal and Guaranteed Restore Points

This section describes the various commands and monitoring capabilities you use with normal and guaranteed restore points.

Creating Normal and Guaranteed Restore Points

To create normal or guaranteed restore points,use the?CREATE RESTORE POINT?SQL statement,providing a name for the restore point and specifying whether it is to be a guaranteed restore point or a normal one (the default). ?>>>>可以使用create restore point “point_name”;语句来创建restore point,默认创建的是normal restore point,如果需要创建guaranteed restore point,需要在语句后指定。

To create a restore point:

  1. Connect SQL*Plus to a target database.

    See Also:

    Oracle Database Administrator's Guide?for using SQL*Plus to?connect to a database
  2. Ensure that the database is open or mounted. If the database is mounted,then it must have been shut down cleanly (unless it is a physical standby database). ?>>>>

    保证数据库处于open或者mounted状态,如果数据处于mounted状态,那么要确保它在mount之前已经被干净的关闭(除非它是DG中的备库)

  3. Run the?CREATE RESTORE POINT?statement.

    The following example shows how to create a normal restore point in SQL*Plus:

    SQL> CREATE RESTORE POINT before_upgrade;  >>>>
         
         

    创建一个普通restore point

    This example shows how to create a guaranteed restore point:

    SQL> CREATE RESTORE POINT before_upgrade GUARANTEE FLASHBACK DATABASE;  >>>>
         
         

    创建一个guaranteed restore point

See Also:

  • Oracle Database SQL Language Reference?for reference information about the SQL?CREATE RESTORE POINT?statement

  • "Listing Restore Points"?to learn how to list restore point

  • "Dropping Restore Points"?to learn how to delete restore points

Listing Restore Points

You can use the?LIST?command to list either a specific restore point or all restore points known to the RMAN repository. The variations of the command are as follows: ?>>>>

你可以在rman中使用list命令列出rman注册信息中保存的某一个,或者所有的restore point。例子如下:

LIST RESTORE POINT restore_point_name;
LIST RESTORE POINT ALL;

RMAN indicates the SCN and time of the restore point,the type of restore point,and the name of the restore point. The following example shows sample output:

RMAN> LIST RESTORE POINT ALL;
 
using target database control file instead of recovery catalog
SCN              RSP Time  Type       Time      Name
---------------- --------- ---------- --------- ----
341859           28-JUL-06            28-JUL-06 NORMAL_RS
343690           28-JUL-06 GUARANTEED 28-JUL-06 GUARANTEED_RS

To see a list of all currently defined restore points (normal and guaranteed),use the?V$RESTORE_POINT?control file view with the following query: ?>>>>

我们也可以在v$restore_point视图中查看到我们所有的restore point(这些信息保存在控制文件中)

SQL> SELECT NAME,SCN,TIME,DATABASE_INCARNATION#,GUARANTEE_FLASHBACK_DATABASE,STORAGE_SIZE
        FROM V$RESTORE_POINT;

The output from the view:

  • Name of each restore point (guaranteed and normal)

  • SCN

  • Time and database incarnation number when the restore points were created

  • Type of restore point (normal or guaranteed)

  • Amount of space in the fast recovery area being used to support information needed for Flashback Database operations for that restore point

For normal restore points,?STORAGE_SIZE?is zero. For guaranteed restore points,251); border:none; padding:2px; margin-bottom:1em; word-wrap:normal!important; white-space:pre!important">STORAGE_SIZE?indicates the amount of disk space in the fast recovery area used to retain logs required to guarantee?DATABASE?to that restore point. ?>>>>

v$restore_pointnormal restore pointSTORAGE_SIZE0,对于guaranteed restore pointSTORAGE_SIZE表示保证把数据库恢复到该guaranteedrestore point所需的flashbacklogsfast recovery area所占用的空间

See Also:

  • Oracle Database Reference?for information about?V$RESTORE_POINT

  • "Rewinding a Database with Flashback Database"

Dropping Restore Points

When you are satisfied that you do not need an existing restore point,or when you want to create a restore point with the name of an existing restore point,you can drop the restore point,using the?DROP RESTORE POINT?SQL*Plus statement. For example: ?>>>>

当你确认你已经不需要某个restore point或者你发现你想创建的restore point名已经存在,你可以通过drop restore point “point_name”;来删除某个restore point。例如:

SQL> DROP RESTORE POINT before_app_upgrade;
Restore point dropped.

The same statement is used to drop both normal and guaranteed restore points. ?>>>>

对于guaranteed restore point使用同样的方法删除

Note:

Normal restore points eventually age out of the control file,even if not explicitly dropped. The rules governing retention of restore points in the control file are: ?>>>>

就如前面文章中提到的,normal restorepoint会被自己删除,不需要我们主动维护。normal restore point在控制文件中的保留规则如下:

  • The most recent 2048 restore points are always kept in the control file,regardless of their age. ?>>>>

    不论时间长短,最近的2048normal restore point总是会被保存在控制文件中

  • Any restore point more recent than the value of?CONTROL_FILE_RECORD_KEEP_TIME?is retained,regardless of how many restore points are defined. ?>>>>control_file_record_keep_time指定时间以后的normal restore point总是会被保留,而不论控制文件中已经保留了多少个normalrestore point(即使控制文件中保留的normalrestore point已经超过2048个,但只要最早的保留时间还未超过control_file_record_keep_time,那么该normal? restore point也不会被删除)

Normal restore points that do not meet either of these conditions may age out of the control file. ?>>>>

这里说不符合上面任何一个条件的normal restore point都会被移出控制文件,我感觉是有问题的,上面明明说了只要在control_file_record_keep_time期限内,不论控制文件中记录了多少normal restore point,都不会被删除

Guaranteed restore points never age out of the control file. They remain until they are explicitly dropped. ?>>>>

guaranteed restore points永远不会被自动移出控制文件,会一直保留直到我们主动删除。

See also:

Oracle Database SQL Language Reference?for reference information about the SQL? DROP RESTORE POINT?statement

Using Flashback Database

This section describes the basic commands for Flashback Database. It also lists guidelines to ensure optimal performance of Flashback Database.

Enabling Flashback Database

Follow these are the steps to enable Flashback Database.

To enable flashback logging:

  1. Ensure the database instance is open or mounted. If the instance is mounted,then the database must be shut down cleanly unless it is a physical standby database. Other Oracle RAC instances can be in any mode.

  2. Optionally,set the?DB_FLASHBACK_RETENTION_TARGET?to the length of the desired flashback window in minutes:

    ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET=4320; # 3 days
    

    By default?DB_FLASHBACK_RETENTION_TARGET?is set to 1 day (1440 minutes).

  3. Enable the Flashback Database feature for the whole database:

    ALTER DATABASE FLASHBACK ON;
    
  4. Optionally,disable flashback logging for specific tablespaces. ?>>>>

    在数据库级启用了flashback logging后,你可以选择disable 某些表空间的flashback logging

    By default,flashback logs are generated for all permanent tablespaces. You can reduce overhead by disabling flashback logging for specific tablespaces as in the following example: ?>>>>默认情况下,启用flashback database logging会为所有的永久表空间产生flashback logs,但是为了降低对数据性能的影响,你可以disable某些表空间的flashback logging

    ALTER TABLESPACE tbs_3 FLASHBACK OFF;
    

    You can re-enable flashback logging for a tablespace later with this command:

    ALTER TABLESPACE tbs_3 FLASHBACK ON;
    

    If you disable Flashback Database for a tablespace,then you must take its datafiles offline before running?DATABASE. ?>>>>

    如果你disable 了某个表空间的flashback database,那么在使用flashback database前需要先把相应的表空间offline

When you enable Flashback Database while the database is open,there is a very small chance the command may not be able to obtain the memory it needs. If the command fails because of that reason,retry the command after a while or retry after a shutdown and restart of the instance. ?>>>>在数据库处于open的状态下,enable flashbackdatabase,我们有可能会碰到因为命令获得不了其需要申请的内存,虽然几率很小。如果因为上面的原因命令报错了,我们过一会再执行命令,或者重启数据库实例后再执行命令。

When you enable Flashback Database on a?physical standby database,you can flash back a standby database. Flashback Database of standby databases has some applications in the Data Guard environment. See?Oracle Data Guard Concepts and Administration?for details. ?>>>>

在备库上也可以使用flashback database(Snapshot StandbyDatabase使用的就是flashbackdatabase原理)


Disabling Flashback Database Logging ?>>>>

配置环境来优化闪回数据库的性能

On a database instances that is either in mount or open state,issue the following command:

ALTER DATABASE FLASHBACK OFF;

Configuring the Environment for Optimal Flashback Database Performance

Maintaining flashback logs imposes comparatively limited overhead on an database instance. Changed blocks are written from memory to the flashback logs at relatively infrequent,regular intervals,to limit processing and I/O overhead. ?>>>>

通过优化flashback logs来减少对数据库实例的性能影响。改变数据库从内存中被写入flashbacklogs的频率,时间间隔来限制I/O的开销。

To achieve good performance for large production databases with Flashback Database enabled,Oracle recommends the following: ?>>>>

为了优化enable flashback database的大型生产库性能,oracle有如下建议:

  • Use a fast file system for your fast recovery area,preferably without operating system file caching. ?>>>>

    使用快速设备来作为fast recovery area,不使用操作系统cache的存储设备更适合(例如asm)

    Files that the database creates in the fast recovery area,including flashback logs,are typically large. Operating system file caching is typically not effective for these files,and may actually add CPU overhead for reading from and writing to these files. Thus,it is recommended to use a file system that avoids operating system file caching,such as ASM.

  • Configure enough disk spindles for the file system that holds the fast recovery area.

    For large production databases,multiple disk spindles may be needed to support the required disk throughput for the database to write the flashback logs effectively.

  • If the storage system used to hold the fast recovery area does not have nonvolatile RAM,then try to configure the file system on striped storage volumes.

    Use a relatively small stripe size such as 128 KB. This technique enables each write to the flashback logs to be spread across multiple spindles,improving performance.

  • For large databases,set the initialization parameter?LOG_BUFFER?to at least 8 MB. ?>>>>

    对于大型数据库,设置初始化参数log_buffer至少为8MB

The overhead of logging for Flashback Database depends on the mixture of reads and writes in the database workload. When you have a write-intensive workload,the Flashback Database logging overhead is high since it must log all those database changes. Queries do not change data and thus do not contribute to logging activity for Flashback Database. ?>>>>

flashback database 对数据库性能的影响,主要看数据库的读写情况。如果是写密集型数据库,那么因为要记录大量的flashback logs所以对数据性能的影响会比较显著。如果数据库没有什么数据变更,那么对数据库性能的影响就比较小

Monitoring the Effect of Flashback Database on Performance

The?Automatic Workload Repository (AWR) automates database statistics gathering by collecting,processing,and maintaining performance statistics for database problem detection and self-tuning. There are several data analysis methods for monitoring the Flashback Database workload on your system. For example,you can compare AWR reports from before and after the Flashback Database was turned on. You can also review AWR snapshots to pinpoint system usage caused by flashback logging. For example,if?flashback buf free by RVWR?is the top wait event,then you know that Oracle Database cannot write flashback logs very quickly. Therefore,you might want to tune the file system and storage used by the fast recovery area,possibly using a technique described in?"Configuring the Environment for Optimal Flashback Database Performance". ?>>>>AWR会自动收集和保存oracle数据库性能相关的统计信息,我们使用这些统计信息来进来问题检测和性能优化。我们有多种方法来监控flashback database的性能开销情况。例如,你可以对比enable flashback database前后数据库的AWR报告,你也可以查看AWRflashback buf free by PVWR是否为top wait event

The?V$FLASHBACK_DATABASE_STAT?view shows the bytes of flashback data logged by the database. Each row in the view shows the statistics accumulated (typically over the course of an hour). The?FLASHBACK_DATA?and?REDO_DATA?columns describe bytes of flashback data and redo data written respectively during the time interval,while the?DB_DATA?column describes bytes of data blocks read and written. The columnsREDO_DATA?correspond to sequential writes,whereas?DB_DATA?column corresponds to random reads and writes.

Because of the difference between sequential I/O and random I/O,a better indication of I/O overhead is the number of I/O operations issued for flashback logs.?V$SYSSTAT?statistics shown in?Table 7-1?can tell you the number of I/O operations that your instance has issued for various purposes.

Table 7-1 V$SYSSTAT Statistics

Column Name Column Meaning

Physical write I/O request

The number of write operations issued for writing data blocks

Physical read I/O request

The number of read operations issued for reading data blocks

Redo writes

The number of write operations issued for writing to the redo log

Flashback log writes

The number of write operations issued for writing to flashback logs

Flashback log write bytes

Total size in bytes of flashback database data written from this instance


See Also:

  • Oracle Database Reference?for more details on columns in the?V$SYSSTAT?view

  • Oracle Database Performance Tuning Guide?to learn about AWR

  • Oracle Database 2 Day + Performance Tuning Guide?for more information about AWR reports

Flashback Writer (RVWR) Behavior with I/O Errors

When flashback is enabled or when there are guaranteed restore points,the background process RVWR writes flashback data to flashback database logs in the fast recovery area. If RVWR encounters an I/O error,then the following behavior is expected: ?>>>>

flashback database 被启用,或者guaranteed restore points被创建,后台进程RVWR会把flashbak logs写入fast recoverarea. 如果RVWR遇到I/O错误,那么下面的情况可能会发生:

  • If there are any guaranteed restore points defined,then the instance fails when RVWR encounters I/O errors. ?>>>>

    如果数据库中创建了guaranteed restore point,如果RVWR遇到I/O错误,那么数据库实例会挂掉

  • If no guaranteed restore points are defined,then the instance remains unaffected when RVWR encounters I/O errors. Note the following cases: ?>>>>

    如果数据库中没有guaranteed restore point,那么如果RVWR遇到I/O错误,数据库实例不会受到影响,但如下的情况需要注意

    • On a primary database,Oracle Database automatically disables Flashback Database while the database is open. All existing transactions and queries proceed unaffected. This behavior is expected for both single-instance and Oracle RAC databases. ?>>>>

      Dg的主库在开启状态的话,会自动关闭flashback database(对于单实例和RAC来说都是这样)

    • On a physical or logical standby,RVWR appears to have stopped responding,retrying the I/O periodically. This may eventually cause the logical standby or the managed recovery of the physical standby to suspend. (Oracle Database does not cause the standby instance to fail because it does not want to cause the primary database to fail in maximum protection mode.) To resolve the issue,you can issue either a?SHUTDOWN?ABORTor an?ALTER?DATABASE?OFF?command. ?>>>>

      DG的逻辑备库或者物理备库上,如果RVWR进行遇到I/O错误,进行会停止响应,并周期性的重新请求I/O. 最终会导致逻辑备库或者物理备库的恢复管理被暂停(是暂停而不是直接宕掉备库实例,是为了避免造成最大保护模式下主库实例被影响)。我们可以通过shutdow abort或者alter database flashback off命令来解决这个问题

##http://docs.oracle.com/cd/E11882_01/backup.112/e10642/flashdb.htm#BRADV71000

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读