5837人阅读
Oracle 备份恢复（16）
&&&&&&& Oracle 11g中对于归档日志的删除，除了遵循RMAN保留策略外，也可以通过RMAN来配置归档日志的删除策略，也就是归档日志何时可以被删除。归档日志删除策略适用于所有归档位置(使用快速闪回区FRA/不使用FRA)。本文主要描述归档日志删除策略并给出了具体的演示。&1、关于归档日志删除策略&&&&& 也就是哪些归档日志符合删除策略能够被删除，如前所述，归档位置适用于所有归档位置(使用/不使用FRA)&&&&& 当启用该策略后，如归档日志存在于FRA中，则Oracle会尽可能根据保留他们，一旦FRA空间告急，则Oracle会根据归档日志删除策略自动删除&&&&& 对于不在FRA中的归档日志，需要手动使用delete obsolete或delete archivelog方式来删除日志&&&&& 无论归档日志存在于FRA内或外，都可以通过BACKUP ... DELETE INPUT or DELETE ARCHIVELOG方式来删除&&&&& 该策略不适用于使用LogMiner方式从主数据库传送到逻辑standby生成的外部归档日志文件，因为这些日志文件不能够在逻辑standy上备份或恢复&&2、配置归档日志删除策略&&&& 使用下面的方式来配置归档日志删除策略&&&&&&&& configure archivelog deletion policy to backed up 2&&&&&&&&&configure archivelog deletion policy to backed up 1 times&&&&&&&& configure archivelog deletion policy t&&&&&&&& configure archivelog deletion policy t&&&&&&&& configure archivelog d&&& 对于Oracle 10g没有该特性，但有一个类似的用于配置归档日志被备份次数，如下；&&&&&&&& configure archivelog backup copies for device type disk to ${archiveretention};&&&&3、禁用归档日志删除策略&&&&& 缺省情况下，该策略被设置为none。也就是说根据RMAN备份保留策略，对于FRA中的归档日志，被备份过一次(到磁盘或磁带)即符合条件被删除&&&& 如果Oracle不再需要当前的归档日志用于保证数据库时点恢复或数据库闪回，则RMAN备份保留策略认为当前日志为obsolete&&&& 在SYSDATE-'DB_FLASHBACK_RETENTION_TARGET'之后创建的归档日志是需要被保留的4、启用归档日志删除策略&&&& 一旦启用该策略，则指定的归档日志被备份数量达到设定值后，这些归档日志能够被删除&&&& BACKUP ARCHIVELOG 会在未超出指定备份数的情况下(比如设置为2)备份归档日志到指定位置，如超出2次，则RMAN会跳过这些备份过2次的归档日志&&&& 对于上述的情形，可以为BACKUP ARCHIVELOG适用force选项来强制备份归档日志&&&& 如果启用该策略且配置为APPLIED ON STANDBY子句，则所有强制standby位置被apply后，这些归档日志会被RMAN删除 &&&& 如果启用该策略且配置为SHIPPED ON STANDBY子句，则所有强制standby位置被成功传送后，这些归档日志会被RMAN删除 &&5、演示归档日志删除策略[oracle@linux1 ~]$ rman target /
Recovery Manager: Release 11.2.0.1.0 - Production on Tue Nov 12 15:10:17 2013
--查看当前数据库保留策略
RMAN configuration parameters for database with db_unique_name USBO are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
--查看当前数据库保归档日志留策略
RMAN& show archiv
RMAN configuration parameters for database with db_unique_name USBO are:
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
--查看过时的备份
RMAN retention policy will be applied to the command
RMAN retention policy is set to redundancy 1
no obsolete backups found
--列出copy副本
specification does not match any datafile copy in the repository
specification does not match any control file copy in the repository
List of Archived Log Copies for database with db_unique_name USBO
=====================================================================
S Low Time
------- ---- ------- - -------------------
Name: /u03/database/usbo/fr_area/USBO/archivelog//o1_mf_1_121_983pm3gp_.arc
--当前的归档日志
--修改当前的归档日志保留策略为2个备份副本
RMAN& configure archivelog deletion policy to backed up 2 times
new RMAN configuration parameters:
CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 2 TIMES TO DISK;
new RMAN configuration parameters are successfully stored
--备份归档日志，并删除已经备份的归档日志
RMAN& backup archive
Starting backup at
current log archived
using channel ORA_DISK_1
channel ORA_DISK_1: starting archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=121 RECID=124 STAMP=
input archived log thread=1 sequence=122 RECID=125 STAMP=
channel ORA_DISK_1: starting piece 1 at
channel ORA_DISK_1: finished piece 1 at
piece handle=/u03/database/usbo/fr_area/USBO/backupset//o1_mf_annnn_TAG726_983pop3p_.bkp
tag=TAG726 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
channel ORA_DISK_1: deleting archived log(s)
RMAN-08138: WARNING: archived log not deleted - must create more backups ---&出现警告提示，日志当前不能被删除，更多的备份需要创建
archived log file name=/u03/database/usbo/fr_area/USBO/archivelog//o1_mf_1_121_983pm3gp_.arc thread=1 sequence=121
RMAN-08138: WARNING: archived log not deleted - must create more backups
archived log file name=/u03/database/usbo/fr_area/USBO/archivelog//o1_mf_1_122_983pooxb_.arc thread=1 sequence=122
Finished backup at
--从os层面查看归档日志，当前已备份的两个归档日志没有删除
sys@USBO& ho ls -hltr /u03/database/usbo/fr_area/USBO/archivelog//*
-rw-r----- 1 oracle asmadmin 3.0K Nov 12 15:36 /u03/database/usbo/fr_area/USBO/archivelog//o1_mf_1_121_983pm3gp_.arc
-rw-r----- 1 oracle asmadmin 4.5K Nov 12 15:37 /u03/database/usbo/fr_area/USBO/archivelog//o1_mf_1_122_983pooxb_.arc
--从视图查询也可以获得其状态
sys@USBO& select name,status from v$archived_log where STATUS='A';
-------------------------------------------------------------------------------- ---
/u03/database/usbo/fr_area/USBO/archivelog//o1_mf_1_121_983pm3gp_.arc
/u03/database/usbo/fr_area/USBO/archivelog//o1_mf_1_122_983pooxb_.arc
--第二次备份归档日志
-- Author : Leshami
: http://blog.csdn.net/leshami
RMAN& backup archivelog all delete input tag=arc_2
Starting backup at
current log archived
using channel ORA_DISK_1
channel ORA_DISK_1: starting archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=121 RECID=124 STAMP=
--sequence 121与122依旧被备份
input archived log thread=1 sequence=122 RECID=125 STAMP=
input archived log thread=1 sequence=123 RECID=126 STAMP=
channel ORA_DISK_1: starting piece 1 at
channel ORA_DISK_1: finished piece 1 at
piece handle=/u03/database/usbo/fr_area/USBO/backupset//o1_mf_annnn_ARC_2ND_983py6mv_.bkp tag=ARC_2ND comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
channel ORA_DISK_1: deleting archived log(s)
--sequence 121与122被删除
archived log file name=/u03/database/usbo/fr_area/USBO/archivelog//o1_mf_1_121_983pm3gp_.arc RECID=124 STAMP=
archived log file name=/u03/database/usbo/fr_area/USBO/archivelog//o1_mf_1_122_983pooxb_.arc RECID=125 STAMP=
RMAN-08138: WARNING: archived log not deleted - must create more backups ---&出现警告提示，日志123不能被删除，更多的备份需要创建
archived log file name=/u03/database/usbo/fr_area/USBO/archivelog//o1_mf_1_123_983py6gh_.arc thread=1 sequence=123
--再次查看，只有sequence 123存在，121与122已经被删除
specification does not match any datafile copy in the repository
specification does not match any control file copy in the repository
List of Archived Log Copies for database with db_unique_name USBO
=====================================================================
S Low Time
------- ---- ------- - -------------------
Name: /u03/database/usbo/fr_area/USBO/archivelog//o1_mf_1_123_983py6gh_.arc
Finished backup at
--配置新的归档日志删除策略
RMAN& configure archivelog deletion policy to backed up 1 times
old RMAN configuration parameters:
CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 2 TIMES TO DISK;
new RMAN configuration parameters:
CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO DISK;
new RMAN configuration parameters are successfully stored
--第三次备份归档日志
RMAN& backup archivelog all tag=arc_3
Starting backup at
current log archived
using channel ORA_DISK_1
--下面是skip的提示信息，因为根据新的策略，sequence 123已经被备份过一次了
skipping archived log file /u03/database/usbo/fr_area/USBO/archivelog//o1_mf_1_123_983py6gh_. already backed up 1 time(s)
channel ORA_DISK_1: starting archived log backup set
channel ORA_DISK_1: specifying archived log(s) in backup set
input archived log thread=1 sequence=124 RECID=127 STAMP=
channel ORA_DISK_1: starting piece 1 at
channel ORA_DISK_1: finished piece 1 at
piece handle=/u03/database/usbo/fr_area/USBO/backupset//o1_mf_annnn_ARC_3RD_983q2d34_.bkp tag=ARC_3RD comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at
--清除策略
RMAN& configure archivelog d
old RMAN configuration parameters:
CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO DISK;
RMAN configuration parameters are successfully reset to default value
--列出所有归档日志的备份信息
RMAN& list back
List of Backup Sets
===================
Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ -------------------
BP Key: 24
Status: AVAILABLE
Compressed: NO
Tag: TAG726
Piece Name: /u03/database/usbo/fr_area/USBO/backupset//o1_mf_annnn_TAG726_983pop3p_.bkp
List of Archived Logs in backup set 24
---- ------- ---------- ------------------- ---------- ---------
15:34:15 3090507
15:36:03 3090591
Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ -------------------
BP Key: 25
Status: AVAILABLE
Compressed: NO
Tag: ARC_2ND
Piece Name: /u03/database/usbo/fr_area/USBO/backupset//o1_mf_annnn_ARC_2ND_983py6mv_.bkp
List of Archived Logs in backup set 25
---- ------- ---------- ------------------- ---------- ---------
15:34:15 3090507
15:36:03 3090591
15:37:25 3090746
Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ -------------------
BP Key: 26
Status: AVAILABLE
Compressed: NO
Tag: ARC_3RD
Piece Name: /u03/database/usbo/fr_area/USBO/backupset//o1_mf_annnn_ARC_3RD_983q2d34_.bkp
List of Archived Logs in backup set 26
---- ------- ---------- ------------------- ---------- ---------
15:41:58 3090839
&&&&相关参考&&& &&&&&&& &&& &&& &&&&&&&&&&&&&&& &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：3646426次
积分：38984
积分：38984
排名：第63名
原创：538篇
评论：658条
QQ： & & &
数据库论坛：&
数据库服务：&
博客转载请以链接注明出处
(1)(6)(5)(2)(2)(1)(4)(8)(11)(3)(4)(1)(5)(14)(3)(7)(6)(16)(4)(19)(11)(4)(4)(4)(7)(10)(3)(4)(5)(5)(8)(7)(11)(13)(13)(9)(13)(14)(15)(9)(7)(18)(9)(12)(7)(4)(1)(1)(7)(7)(8)(2)(6)(4)(8)(9)(3)(3)(9)(6)(7)(2)(4)(6)(8)(20)(11)(7)(2)(7)(12)(5)(10)(10)(6)(2)(1)(3)(3)Oracle 闪回区_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
Oracle 闪回区
上传于||文档简介
&&详​细​介​绍​了​o​r​a​c​l​e​ ​闪​回​区​的​功​能​和​日​常​的​管​理
阅读已结束，如果下载本文需要使用1下载券
想免费下载本文？
你可能喜欢<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
您的访问请求被拒绝 403 Forbidden - ITeye技术社区
您的访问请求被拒绝
亲爱的会员，您的IP地址所在网段被ITeye拒绝服务，这可能是以下两种情况导致：
一、您所在的网段内有网络爬虫大量抓取ITeye网页，为保证其他人流畅的访问ITeye，该网段被ITeye拒绝
二、您通过某个代理服务器访问ITeye网站，该代理服务器被网络爬虫利用，大量抓取ITeye网页
请您点击按钮解除封锁&您当前的位置：&&&&&正文
Oracle引入Flashback 获得高可用性
简介 Flashback数据库是一种时点(PIT)数据库恢复的方式。这种不完全的恢复策略可以用于恢复由于人为错误导致逻辑损坏的数据库。在10g中引入之后，它的设计目标就是以缩减恢复时间而获得最大的可用性。这篇文章将会探索Flashback数据库，将其与传统的恢复方法相比较，并且演示一下如何配置和执行重现恢复。 传统恢复vs.重现数据库 导致停机的第一个原因就是人为错误导致的逻辑损坏，这一点已经被广泛承认。关于逻辑损坏的例子，从用户不正确的更新数据和截取表，到批处理任务错误运行2次或者打乱顺序，比比皆是。结果都是相同的――数据库损坏，并且范围广阔且难以辨认。Oracle通过了两种策略来将数据库返回到先前的某个时点上:传统恢复和重现数据库。 不完全的恢复是数据库恢复到先前某个状态的恢复。这个过程有两个步骤:重新存储数据，并向前恢复事务活动到某个你想要的时间。传统恢复和重现数据库之间的主要区别就是，传统恢复从重新存储所有的数据文件开始，然后才恢复到某个想要的恢复时间，而重现数据库则是在损坏之后通过重新存储被改变的块来向后操作。从这个角度考虑问题的话，让我们想想在一个10TB的数据库上，有1MB的数据损坏了。传统的恢复从开始重新存储10TB的应用程序数据开始，而重现数据库则是取回这1MB的应用程序数据，从而达到损坏前的那个点。现在我们分别看看每一种策略。 传统恢复 在Oracle 10g之前，将由于人为错误导致问题的数据库恢复到先前某个时点的唯一选项就是传统恢复。这个策略包括了从备份中取出并重新存储所有的数据库数据文件，然后再执行向前恢复到某个想要的时间点。媒体恢复可以基于服务器(RMAN)，也可以基于用户(操作系统工具)。 下图演示了这个复杂的、成本高昂的、效率极低的多步骤恢复策略。 现在我们看一下用户执行了SQL并且损坏了数据库的情况。用户通知了命令中心并且报告了错误。系统分析师通过与公司不同部门的另外一些人协商管理这次事件。恢复通过从备份中重新存储所有的数据文件并且向前回滚redo日志到希望的时间点而完成。恢复时间与数据库的规模成正比，而不是需要恢复的更改的数量。这就意味着恢复时间(MTTR)实际上随着数据库的规模增长而不断增加。 重现数据库 在Oracle 10g中，一项新的重现技术特性，称为Flashback Database(重现数据库)的，作为传统恢复的替代品引入了。重现数据库可以让你快速恢复整个数据库到先前的某个时间点，而不需要从备份中重新存储数据库。在数据库中经常被描述为倒转按钮，它只是将那些被修改的数据块恢复到你希望的恢复时间之前。然后应用Redo更改记录来达到希望的恢复时间点。这个被修改的数据块就叫做重现日志。 重现数据库提供了相对于传统数据库非常明显的优势。对于分析型数据库则没有这么明显的优势。在数据仓库中，块的操作通常是以不记录日志的模式执行的。在重现数据库中，只要数据库运行的是文档日志模式，它就可以返回到块操作之前的某个状态，因为被修改的块可以通过恢复而撤销执行的操作。 注意:虽然重现数据库是集成到数据库中的，但是它在Oracle的 Express Edition (XE)中是不可用的。 这里我们看一下用户执行了SQL并且损坏了数据库的情况。用户通知了应用程序数据库管理员，他执行了重现数据库命令，数据库自动恢复到损坏之前的某个点。重现数据库很快，使因为它只针对被修改的数据进行操作。重现的时间与犯错误的数量有关，而与数据库的规模无关。配置重现数据库 以下的例子演示了命令行配置。这也可以用企业管理器来完成。 在我们配置重现数据库之前，我们需要照顾以下一些先决条件。 Flash Recovery Area 首先，我们需要配置一个Flash Recovery Area (FRA)。在10g中，这是个新东西，FRA只不过是一个恢复相关文件的磁盘定位。对于重现数据库，一个新的后台进程，名为Recovery Writer (RVWR)，在来自SGA的数据库重现缓存的映像之前，阶段性地写入磁盘，作为FRA中的重现日志。重现日志是在FRA中由Oracle数据库自动管理的。 重现日志的成本是以空间和性能来衡量的。空间是数据库写密度的一个因素。一个24小时运行的，以5%的数据块写入作为重现日志的方式必然会导致磁盘整体空间的5%的增长。因为块是以规律的间隔写入的，而不是事务的一部分，所以对性能的影响是可以忽略不计的。 要配置FRA，你需要设置如下的初始化参数: alter system set db_recovery_file_dest=
'C:\oracle\product\10.2.0\flash_recovery_area' scope=alter system set db_recovery_file_dest_size = 10G scope=存档 接下来，我们需要配置存档。再一次，我们需要使用FRA作为我们的文档日志目的地。与传统恢复类似，重现数据库需要存档以向前恢复提交的事务，在重现日志重新存储了希望时间之前的时点之后。 要最小化配置存档，执行如下的命令，按照顺序: SQL& startup mountORACLE instance started....Database mounted.SQL& alterDatabase altered.SQL&Database altered.SQL& archive log listDatabase log mode
Archive ModeAutomatic archival
EnabledArchive destination
USE_DB_RECOVERY_FILE_DESTOldest online log sequence
2Next log sequence to archive
4Current log sequence
4重现数据库 配置了这些先决条件之后，我们准备好配置重现数据库了。 首先，我们需要设置重现保持目标。这个初始化参数，以分钟来计算，代表我们可以把数据库返回到多长时间之前。它的值决定了FRA中重现日志的数量和时间段。下面我们的例子将其设置为24小时。要理解这个保持时间段并不是保证是非常重要的。如果FRA需要空间，重现日志将会自动删除目标保持时间点之前的记录。稍后我们会看到，我们保证重现日志的方式在FRA中进行维护。有了保持时间段设置，重现数据库可以激活。 SQL&ORACLE instance started....Database mounted.SQL& alter system set db_flashback_retention_target = 1440 scope=System altered.SQL& alter dDatabase altered.SQL&Database altered.SQL& select flashback_on from v$FLASHBACK_ON------------------YES重现数据库示例 下面的例子用于演示，它想要描述单个表之外的损坏。 45. 监控FRA46. select name,space_limit,space_used, space_reclaimable from v$recovery_file_47. 48. NAME
SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE49. -------------------------------------------- 50. C:\oracle\product\10.2.0/flash_recovery_area
051. 52. 53. select * from v$flash_recovery_area_54. 55. FILE_TYPE
PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES56. ------------ ------------------ ------------------------- ---------------57. CONTROLFILE
058. ONLINELOG
059. ARCHIVELOG
2960. BACKUPPIECE
061. IMAGECOPY
062. FLASHBACKLOG
163. 在表的映像之前显示64. select c1, ora_rowscn from my_65. 66.
C1 ORA_ROWSCN67. ---------- ----------68.
132095469. 判断数据库的时间点在10gR1中，你有两种选择来捕捉你的数据库的PIT:时间戳和系统修改号码(SCN)。这个信息是作为重现操作的一部分要求的。 捕捉到提交的SCN或者稍后的非常重要，而不是数据管理语言操作。Oracle提供了一种比较笨拙的方式来捕捉提交的SCN，通过userenv('commitscn')函数。我们的示例在发生损坏的数据管理语言操作之前捕捉到了这个信息。select current_scn from v$ CURRENT_SCN-----------
1321065or select to_char(sysdate,'YYYY-MM-DD:HH24:MI:SS')
"Recover Time" from v$Recover Time-------------------:20:13:48在10gR2中，Oracle通过重新存储点简化了这个过程。一个重新存储点就是一个用户定义的与数据库PIT相关连的名字，可以在时间戳或者SCN中使用。可以认为重新存储点是一个redo历史的参考标记。重新存储点保留在控制文件中，直到重新存储点被删除或者重现日志被删除。第二个例子保证了重现数据库对于恢复是可用的。 create restore point my_restore_Operation 206 succeeded.或者创建重新存储点my_restrore_point来保证重现数据库; 注意：重新存储点并不会保证所有的事务都在那个时间点上提交。它不应该与DB2的关系型数据库管理系统中的静默点混淆了。 模拟数据库损坏 70. 模拟数据库损坏71. insert into my_table values (2);72. 73. 1 row created.74. 75.76. 77. 提交完成78. 判断数据库是否由于人为错误导致逻辑损坏。79. select c1, ora_rowscn from my_80. 81.
C1 ORA_ROWSCN82. ---------- ----------83.
132095484.
1321231注意：在默认情况下，Oracle在时钟级别上检索SCN。当然，时钟当中的所有行都有一样的SCN。激活行级别的SCN检索，可以在CREATE TABLE命令中使用ROWDEPENDENCIES关键字。 检验重现数据库是可能的。 判断你可以重现的最早的时间。 SELECT OLDEST_FLASHBACK_SCN
,to_char(OLDEST_FLASHBACK_TIME,'YYYY-MM-DD:HH24:MI:SS')
"OLDEST_FLASHBACK_TIME"
FROM V$FLASHBACK_DATABASE_LOG;OLDEST_FLASHBACK_SCN OLDEST_FLASHBACK_TI-------------------- -------------------
6-09-23:19:51:56判断你是否有重新存储点。 select name, scn, time from v$restore_NAME
SCN TIME---------------- ---------- ----------------------------MY_RESTORE_POINT -SEP-06 08.16.24. PM这里是一些你感兴趣的视图。 重现数据库 你可以在SQL*Plus 或者 RMAN中执行重现数据库。重现数据库可以是基于修改和重新存储点的时间。RMAN提供了额外的基于选项的日志顺序。 使用先前创建的重新存储点来重现数据库。 SQL&Database closed.Database dismounted.ORACLE instance shut down.SQL& startup mountORACLE instance started....Database mounted.SQL& flashback database to restore point my_restore_Flashback complete.在警告日志中检查重现数据库消息 ...Sat Sep 23 20:38:11 2006flashback database to restore point my_restore_pointSat Sep 23 20:38:12 2006Flashback Restore StartFlashback Restore CompleteFlashback Media Recovery Start parallel recovery started with 2 processesSat Sep 23 20:38:14 2006Recovery of Online Redo Log: Thread 1 Group 2 Seq 33 Reading mem 0
Mem# 0 errs 0: C:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02.LOGSat Sep 23 20:38:16 2006Incomplete Recovery applied until change 1321137Flashback Media Recovery CompleteCompleted: flashback database to restore point my_restore_point验证你的数据库恢复到你想要的状态如果你不满意，你可以再次重现，把数据库向前恢复，直到或者执行了完全恢复:recover database.注意:重现数据库可以通过RESETLOGS执行。 SQL& alter datDatabase altered.SQL& select c1, ora_rowscn from my_
C1 ORA_ROWSCN---------- ----------
1321002为一般用途打开数据库 对我们的恢复满意了之后，为了一般用途打开数据库。 SQL&Database closed.Database dismounted.ORACLE instance shut down.SQL&ORACLE instance started....Database mounted.SQL& alter datDatabase altered.结论 重现数据库将会成为我最喜欢的Oracle10g特性之一。无论你是否纠正了用户的错误，只是看看先前的数据库状态，或者在衰退测试之后回到测试环境中，这个特性都是减少恢复时间的最好策略。我们看到这项技术很容易使用，比传统的恢复更快，并且最好的是，它是免费的!我希望你也会认为重现数据库是可用性体系结构中的一项主要组件。 (责任编辑：铭铭
TEL：（010）)--博才网
下页更精彩：
微信查看最新信息微信扫一扫或用微信搜索微信号：hbrc-com
安卓手机客户端更省流量手机扫描下载或者直接
猜你还喜欢的文章
热点文章排行榜
&#8226; 版权所有 Copyright 2011 All rights reserved.