ITPub博客

一. 问题描述在一次数据库恢复工作后,因为恢复工作中遇到一些问题,恢复后结合oracle官方文档,仔细研究rman的工作原理.将数据库启动到mount状态后,想看一下v$backup_archivelog_details视图的内容,结果报了ORA-00904的错误,描述如下:SQL> desc v$backup_archivelog_details;ERROR:ORA-00604: error occurred at recursive SQL level 3ORA-00904: "SYS"."DBMS_RCVMAN"."SV_GETSESSIONUNTILTIMERANGE": invalid identifier[@more@]二. 问题分析这个数据库是前几天做过数据库恢复,恢复的时间点为2013-06-26日

一.问题描述：一个本来可以正常备份的netbakckup客户端，在进行正常的备份任务时，失败，错误描述如下:the backup failed to back up the requested files(6).检查netbackup客户端的数据库备份日志文件，显示的错误信息如下：using target database control file instead of recovery catalogRMAN-00571: ===========================================================RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============RMAN-00571: ===========================================================RMAN-03009: fail

一.问题描述在一个linux 6.3 x86_64+oracle 10.2.0.5的数据库服务器上安装netbackup client和netbakckup db for oracle 后,在netbackup server上配置备份策略.进行手工备份时发生错误代码为59的错误,错误描述如下:2012-10-24 11:40:37 - Info nbjm(pid=3436) starting backup job (jobid=269562) for client zhjkdb, policy ORA-ZHJKDB, schedule fullbackup 2012-10-24 11:40:37 - Info nbjm(pid=3436) requesting MEDIA_SERVER_WITH_ATTRIBUTES resources from RB for backup job (jobid=269562, request id:{E2ADD91E-3307-4F69-8D2C-7

一. 问题描述 在日常的rman备份工作中,发现rman在备份归档日志的时候,不成功,不能自动删除归档日志,而且controlfile的备份也没有成功. 检查rman备份的日志文件,发现在备份过程中报ora-00230的错误.如下:Starting Control File and SPFILE Autobackup at 26-4鏈?-12released channel: ch00RMAN-00571: ===========================================================RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============RMAN-00571: ===========================================================RMAN-03009: fa

因为数据库的数据文件所在的磁盘发生了故障(突然间不可访问和不可见),重新启动操作系统时发现scsi阵列卡已经无法识别数据磁盘,数据磁盘的状态为foreign.在BIOS中进行操作和设置,调整了数据磁盘的状态;然后进入操作系统可以正常识别数据磁盘,数据库也可以启动到open状态. 数据库启动后,发现有部分数据文件的状态为recover,需要进行数据库的恢复. 下面是数据库恢复的步骤:[@more@]1.恢复前状态:SQL>select file#,name,status,checkpoint_change# from v$datafile FILE# NAME STATUS

1.5 实验总结: 场景二,场景三都是正常的恢复方式. 场景一有点特别,控制文件是旧的,并且全备份的scn与两个归档日志文件的SCN交叉.在进行RECOVER的时候,选择auto和cancel两种方式都不能正常recover,一定需要输入第2个归档日志的文件名,系统才正常进行recover,这个是以前没有遇到的问题。[@more@]另外通过本次的实验,知道了,恢复时报文件需要重新RESTORE 的问题时,可以不去理这个错误,更加不需要重新restore database,而是从全备份的SCN,归档日志的SCN,控制文件的SCN等几个方面进行考虑。 SCN的查询方法 RMAN>LIST BACKUP

1.4 场景三:使用全备份后产生的控制文件进行备份恢复 1.4.1 模拟灾难发生 SQL> shutdown abort; [oracle@restoretest gcwz_web]$ rm *[@more@]1.4.2 恢复控制文件 [oracle@restoretest gcwz_web]$ sqlplus / as sysdba SQL> startup nomount [oracle@restoretest gcwz_web]$ rman target / RMAN> restore controlfile from '/rman/control_73'; output filename=/oradata/gcwz_web/control01.ctl output filename=/oradata/gcwz_web/control02.ctl output filename=/oradata/gcwz_web/

1.3 场景二:使用全备份时产生的控制文件进行备份恢复 1.3.1 模拟灾难发生 [oracle@restoretest ~]$ sqlplus / as sysdba SQL> shutdown abort; $ cd /oradata/gcwz_web/ [oracle@restoretest gcwz_web]$ rm *[@more@]1.3.2 恢复控制文件 RMAN> restore controlfile from '/rman/full_72_709900586_1'; output filename=/oradata/gcwz_web/control01.ctl output filename=/oradata/gcwz_web/control02.ctl output filename=/oradata/gcwz_web/control03.ctl Finished restore at 02-FEB-10

1.2 场景一:使用旧的控制文件进行备份恢复 1.2.1 模拟灾难发生 异常停止数据库: Sqlplus / as sysdba Sql>shutdown abort; 删除所有数据库文件: $Rm –rf /oradata/gcwz_web/*[@more@]1.2.2 恢复控制文件 以旧的控制文件为模板恢复控制文件。 本案例如果没有旧的控制文件，可以使用附件二的方法，创建全新的控制文件，恢复的方法与本案例完全相同。 Sqlplus / as sysdba Startup nomount 或者startup nomount pfile=’ /oracle/product/10.2.0/db_1/dbs/initgcwz_web.ora’; Rman target /

1.1 案例环境描述 本文主要描述分别使用不同阶段产生的控制文件进行rman恢复。 1.1.1 操作系统环境 基本环境描述: OS: Linux restoretest 2.6.18-128.el5 #1 SMP Wed Dec 17 11:41:38 EST 2008 x86_64 x86_64 x86_64 GNU/Linux[@more@]1.1.2数据库环境 DB: oracle 10.2.0.4 SQL> select name from v$datafile; /oradata/gcwz_web/system01.dbf /oradata/gcwz_web/undotbs01.dbf /oradata/gcwz_web/sysaux01.dbf /oradata/gcwz_web/users01.dbf /oradata/gcwz_web/test01.dbf SQL> select

  本文主要就使用netbackup服务器上的rman的备份集,在异机进行数据库恢复进行详细的操作说明. 环境描述 1.1 源数据库信息 Hostname: sstydbOracle_sid:sstydbOracle_version:10.2.0.4...

更新hosts文件,定义IP与主机名对应关系1.1 在客户端需要定义netbackup的所有服务器的信息(包括media server),本机信息也要定义15.216.18.125#more /etc/hosts15.216.18.125 kefdb15.217.12.89 netbackup15.217.12.40 netbackup-ms1.2 在服务器端定义客户端计算机的信息本例netbackup是安装在windows上的,所以需要编辑C:WINDOWSsystem32driversetchosts文件,内容如下:15.216.18.125 kefdb如果netbackup服务器不只一个,需要在每一个netbackup服务器hosts文件里定义客户机的信息如果在netbackup的服务器hosts里没有定义客户端的信息,在执行备

<接使用RMAN备份集和过时的控制文件进行数据库的恢复(1/2),网址:http://djb1008.itpub.net/post/42280/505466> 3.2.12 查询最新的数据库SCN号 然后我们查询一下最新的数据库的SCN 和数据文件的SCN,都是最新的SCN,而且具有相同值。 SQL> select ts#,file#,name,checkpoint_change#,sysdate from v$datafile order by ts#,file# FILE# NAME CHECKPOINT_CHANGE# SYSDATE---------- ------------------------------ ------------------ -------------------1 C:ORADATAAIDUSYSTEM01.DBF 1224188 2006-06-23 16:18:462 C:ORADAT

环境描述数据库的软件安装在服务器本地存储上，归档日志也保存在服务器的本地存储上，数据库的数据文件,控制文件,REDO LOG文件，密码文件，SPFILE都保存在磁盘存储阵列上。数据库使用RMAN进行备份，备份集保存在磁盘存储阵列上，每天两次将RMAN备份集拷贝到异地。RMAN 备份的元数据(METADATA)信息保存在数据库控制文件中,没有使用CATALOG库进行登记管理，保留的时间参数(control_file_record_keep_time)设定为缺省的7天。RMAN的备份设置中，没有打开控制文件的自动备份。由于磁盘存储阵列的突然崩溃，所有存储在磁盘阵列上的数据都无法恢复

  简述    当数据库的多个表空间的文件都遭到不同程度的损坏，我们直接在数据库级进行恢复。本试验测试是丢失数据文件，控制文件、REDO文件等其他文件没有受到破坏。    本...

简述当数据库的多个表空间的文件都遭到不同程度的损坏，我们直接在数据库级进行恢复。本试验测试是丢失数据文件，控制文件、REDO文件等其他文件没有受到破坏。本试验中删除绝大部分的数据文件，模拟该大部分数据文件物理破坏或者丢失的情况发生，也就是说，如果一个数据库的绝大部分的数据文件丢失了，可以参照下面的操作步骤进行数据库库的恢复工作。[@more@]建立测试环境2.1在测试表空间上创建表SQL> CREATE TABLE AIDU.TEST_FOR_RECOVERY_DB(ID NUMBER NOT NULL,NAME VARCHAR2(200),PRIMARY KEY(ID)) TABLESPACE USER02;表已创建。2

简述 当个别数据库的数据文件丢失或者损坏，则需要首先恢复该文件的备份复本，然后运用归档日志和REDO文件进行完整恢复，使得最后丢失或者损坏的数据文件的SCN等于当前的SCN,这样数据库可以正常打开，数据没有丢失。[@more@] 建立测试环境 2.1 创建测试表空间SQL>CREATE TABLESPACE "USER02" DATAFILE 'C:ORADATAAIDUUSER02.DBF' SIZE 20M REUSE LOGGING EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO;2.2 在测试表空间上创建数据库表SQL>create table aidu.test_for_recovery(id number not null,name

REDO文件的功能描述REDO文件存储所有数据库的变更内容和每一次变更所需的重做脚本，是数据库不可缺少的一部分，如果REDO GROUP中只有一个REDO文件，同时这个REDO文件被损坏，则系统切换到这个REDO GROUP时，数据库...