Oracle备份恢复 – 第35页

块修改跟踪特性(Block Change Tracking)

有一服务器有1T左右的数据，备份策略是(1+2)*2（1全备，2增量备份，备份保留2周期）的备份策略，随便增量备份减少了备份的体积，但是增量备份的时间，基本上和全备无差别，都是要近6小时（包括压缩）。这里没有完全体现出增量备份的强大之处，因为没有开启块修改跟踪，无论是增量备份还是全备都需要扫描所有的数据块。虽然网上说开启块修改跟踪可能会会触发一些bug，但是我找了下，10.2.0.4以后块修改跟踪还是比较稳定的，所以决定开启块修改跟踪功能，节约增量备份时间，提高系统性能。

一、开启块修改跟踪

[oracle@node1 bdump]$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.5.0 – Production on Thu Nov 3 11:13:54 2011

Connected to:

Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 – 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> alter database enable block change tracking using file

2 '/opt/oracle/oradata/ecp/Oracle_change.trace';

Database altered.

SQL> set long 200

SQL> col filename for a50

SQL> SELECT * FROM v$block_change_tracking;

STATUS FILENAME BYTES

———- ————————————————– ———-

ENABLED /opt/oracle/oradata/ecp/Oracle_change.trace 11599872

SQL> !/opt/oracle/oradata/ecp/Oracle_change.trace

/bin/bash: /opt/oracle/oradata/ecp/Oracle_change.trace: 权限不够

SQL> !

[oracle@node1 ~]$ ll /opt/oracle/oradata/ecp/Oracle_change.trace

-rw-r—– 1 oracle oinstall 11600384 11-03 11:05 /opt/oracle/oradata/ecp/Oracle_change.trace

[oracle@node1 ~]$ ps -ef|grep ctwr|grep -v grep

oracle 2771 1 0 11:05 ? 00:00:00 ora_ctwr_ecp

[oracle@node1 bdump]$ tail -11 /opt/oracle/admin/ecp/bdump/alert_ecp.log

Thu Nov 03 11:05:47 CST 2011

alter database enable block change tracking using file

'/opt/oracle/oradata/ecp/Oracle_change.trace'

Thu Nov 03 11:05:47 CST 2011

Block change tracking file is current.

Starting background process CTWR

CTWR started with pid=18, OS id=2771

Block change tracking service is active.

Thu Nov 03 11:05:48 CST 2011

Completed: alter database enable block change tracking using file

'/opt/oracle/oradata/ecp/Oracle_change.trace'

通过这些都可以看出来，开启块修改跟踪功能，会启动CTWR进程，并且修改的块号会被记录到指定文件中

二、关闭块改变跟踪

SQL> alter database disable block change tracking;

Database altered.

SQL> col filename for a50

SQL> SELECT * FROM v$block_change_tracking;

STATUS FILENAME BYTES

———- ————————————————– ———-

DISABLED

SQL> !

[oracle@node1 bdump]$ ll /opt/oracle/oradata/ecp/Oracle_change.trace

ls: /opt/oracle/oradata/ecp/Oracle_change.trace: 没有那个文件或目录

[oracle@node1 bdump]$ ps -ef|grep ctwr|grep -v grep

[oracle@node1 bdump]$ tail -8 /opt/oracle/admin/ecp/bdump/alert_ecp.log

Thu Nov 03 11:14:06 CST 2011

alter database disable block change tracking

Thu Nov 03 11:14:07 CST 2011

Block change tracking service stopping.

Thu Nov 03 11:14:07 CST 2011

Stopping background process CTWR

Deleted file /opt/oracle/oradata/ecp/Oracle_change.trace

Completed: alter database disable block change tracking

通过这些都可以看出来，关闭块修改跟踪功能，会关闭CTWR进程，并且删除跟踪文件（Linux系统会删除，Window不会）

三、块修改跟踪文件重命名

SQL> SELECT * FROM v$block_change_tracking;

STATUS FILENAME BYTES

———- ————————————————– ———-

ENABLED /opt/oracle/oradata/ecp/Oracle_change.trace 11599872

SQL> alter database rename file '/opt/oracle/oradata/ecp/Oracle_change.trace'

2 to '/opt/oracle/oradata/ecp/Oracle_change.trace_new';

alter database rename file '/opt/oracle/oradata/ecp/Oracle_change.trace'

ERROR at line 1:

ORA-01511: error in renaming log/data files

ORA-19771: cannot rename change tracking file while database is open

SQL> shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> startup mount;

ORACLE instance started.

Total System Global Area 1610612736 bytes

Fixed Size 2096632 bytes

Variable Size 385876488 bytes

Database Buffers 1207959552 bytes

Redo Buffers 14680064 bytes

Database mounted.

SQL> alter database rename file '/opt/oracle/oradata/ecp/Oracle_change.trace'

2 to '/opt/oracle/oradata/ecp/Oracle_change.trace_new';

Database altered.

SQL> alter database open;

Database altered.

SQL> SELECT * FROM v$block_change_tracking;

STATUS FILENAME BYTES

———- ————————————————– ———-

ENABLED /opt/oracle/oradata/ecp/Oracle_change.trace_new 11599872

[oracle@node1 bdump]$ tail -100 /opt/oracle/admin/ecp/bdump/alert_ecp.log |more

Thu Nov 03 11:22:34 CST 2011

alter database rename file '/opt/oracle/oradata/ecp/Oracle_change.trace'

to '/opt/oracle/oradata/ecp/Oracle_change.trace_new'

Completed: alter database rename file '/opt/oracle/oradata/ecp/Oracle_change.trace'

to '/opt/oracle/oradata/ecp/Oracle_change.trace_new'

Thu Nov 03 11:22:40 CST 2011

alter database open

Thu Nov 03 11:22:40 CST 2011

CHANGE TRACKING is enabled for this database, but the

change tracking file can not be found. Recreating the file.

Change tracking file recreated.

Block change tracking file is current.

[oracle@node1 bdump]$ ll /opt/oracle/oradata/ecp/Oracle_change.trace*

-rw-r—– 1 oracle oinstall 11600384 11-03 11:22 /opt/oracle/oradata/ecp/Oracle_change.trace

-rw-r—– 1 oracle oinstall 11600384 11-03 12:05 /opt/oracle/oradata/ecp/Oracle_change.trace_new

数据库在open状态下不能修改，所以必须把数据库重启至mount状态才能够修改，如果库不能重启，那么可以先关闭原块修改跟踪功能，再开启块修改跟踪功能。
两种方法比较：
1、都会重新建立一个跟踪文件
2、如果是重命名，老的跟踪文件不会自动被删除，需要人工删除
3、推荐使用关闭跟踪功能，然后在重新制定跟踪文件开启跟踪功能

清除离线数据文件记录

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：清除离线数据文件记录

测试前提：数据文件离线，系统上删除了该文件，需要删除在数据字典中，关于这条离线数据文件记录

SQL> archive log list;
Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            /opt/oracle/oradata/test/archivelog
Oldest online log sequence     210
Next log sequence to archive   212
Current log sequence           212
--数据库是归档模式
SQL> col file_name for a40
SQL>  select file_id,file_name,bytes from dba_data_files order by 1;
   FILE_ID FILE_NAME                                     BYTES
---------- ---------------------------------------- ----------
         1 /opt/oracle/oradata/test/system01.dbf     524288000
         2 /opt/oracle/oradata/test/undotbs01.dbf   1289748480
         3 /opt/oracle/oradata/test/sysaux01.dbf     377487360
         4 /opt/oracle/oradata/test/users01.dbf        5242880
         5 /opt/oracle/oradata/test/user32g.dbf       10485760
         6 /opt/oracle/oradata/test/xifenfei01.dbf    20971520
         7 /opt/oracle/oradata/test/user02.dbf        10485760
         8 /opt/oracle/oradata/test/odu02.dbf       1.1283E+10
         9 /opt/oracle/oradata/test/odu01.dbf        104857600
        10 /opt/oracle/oradata/test/odu03.chf
10 rows selected.
SQL> col error for a20
SQL>  select file#,ONLINE_STATUS,ERROR,CHANGE# from V$RECOVER_FILE order by 1;
     FILE# ONLINE_ ERROR                   CHANGE#
---------- ------- -------------------- ----------
        10 OFFLINE FILE NOT FOUND                0
SQL> !ls /opt/oracle/oradata/test/odu03.chf
ls: /opt/oracle/oradata/test/odu03.chf: No such file or directory
--说明该数据文件已经从硬盘上删除
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup nomount
ORACLE instance started.
Total System Global Area  209715200 bytes
Fixed Size                  2082784 bytes
Variable Size             130025504 bytes
Database Buffers           71303168 bytes
Redo Buffers                6303744 bytes
SQL> CREATE CONTROLFILE REUSE DATABASE "TEST" NORESETLOGS  ARCHIVELOG
  2      MAXLOGFILES 16
  3      MAXLOGMEMBERS 3
  4      MAXDATAFILES 100
  5      MAXINSTANCES 8
  6      MAXLOGHISTORY 292
  7  LOGFILE
  8    GROUP 1 '/opt/oracle/oradata/test/redo01.log'  SIZE 50M,
  9    GROUP 2 '/opt/oracle/oradata/test/redo02.log'  SIZE 50M,
 10    GROUP 3 '/opt/oracle/oradata/test/redo03.log'  SIZE 50M
 11  DATAFILE
 12    '/opt/oracle/oradata/test/system01.dbf',
 13    '/opt/oracle/oradata/test/undotbs01.dbf',
 14    '/opt/oracle/oradata/test/sysaux01.dbf',
 15    '/opt/oracle/oradata/test/users01.dbf',
 16    '/opt/oracle/oradata/test/user32g.dbf',
 17    '/opt/oracle/oradata/test/xifenfei01.dbf',
 18    '/opt/oracle/oradata/test/user02.dbf',
 19    '/opt/oracle/oradata/test/odu02.dbf',
 20    '/opt/oracle/oradata/test/odu01.dbf'
        ,'/opt/oracle/oradata/test/odu03.chf'     --文件不存在，创建控制文件这条记录需要除掉
 21  CHARACTER SET ZHS16GBK
 22  ;
Control file created.
SQL> alter database open;
Database altered.
SQL> select file_id,file_name,bytes from dba_data_files order by 1;
   FILE_ID FILE_NAME                                     BYTES
---------- ---------------------------------------- ----------
         1 /opt/oracle/oradata/test/system01.dbf     524288000
         2 /opt/oracle/oradata/test/undotbs01.dbf   1289748480
         3 /opt/oracle/oradata/test/sysaux01.dbf     377487360
         4 /opt/oracle/oradata/test/users01.dbf        5242880
         5 /opt/oracle/oradata/test/user32g.dbf       10485760
         6 /opt/oracle/oradata/test/xifenfei01.dbf    20971520
         7 /opt/oracle/oradata/test/user02.dbf        10485760
         8 /opt/oracle/oradata/test/odu02.dbf       1.1283E+10
         9 /opt/oracle/oradata/test/odu01.dbf        104857600
        10 /opt/oracle/product/10.2.0/db_1/dbs/MISSING00010     --系统默认创建了自定义的数据文件名称
10 rows selected.
SQL> select file#,ONLINE_STATUS,ERROR,CHANGE# from V$RECOVER_FILE order by 1;
     FILE# ONLINE_ ERROR                   CHANGE#
---------- ------- -------------------- ----------
        10 OFFLINE FILE MISSING                  0
--提示该文件是离线状态，需要恢复，结果同开始时候状态
SQL> select file#,STATUS$,TS#,RELFILE# from file$ order by 1;
     FILE#    STATUS$        TS#   RELFILE#
---------- ---------- ---------- ----------
         1          2          0          1
         2          2          1          2
         3          2          2          3
         4          2          4          4
         5          2          4          5
         6          2          6          6
         7          2          4          7
         8          2          7          9
         9          2          7          6
        10          2          7         10
        11          1
11 rows selected.
SQL> delete from file$ where file#=10;    ---重要的就是这个操作
1 row deleted.
SQL> select file#,STATUS$,TS#,RELFILE# from file$ order by 1;
     FILE#    STATUS$        TS#   RELFILE#
---------- ---------- ---------- ----------
         1          2          0          1
         2          2          1          2
         3          2          2          3
         4          2          4          4
         5          2          4          5
         6          2          6          6
         7          2          4          7
         8          2          7          9
         9          2          7          6
        11          1
10 rows selected.
SQL> col name for a40
SQL> select * from v$dbfile order by 1;
     FILE# NAME
---------- ----------------------------------------
         1 /opt/oracle/oradata/test/system01.dbf
         2 /opt/oracle/oradata/test/undotbs01.dbf
         3 /opt/oracle/oradata/test/sysaux01.dbf
         4 /opt/oracle/oradata/test/users01.dbf
         5 /opt/oracle/oradata/test/user32g.dbf
         6 /opt/oracle/oradata/test/xifenfei01.dbf
         7 /opt/oracle/oradata/test/user02.dbf
         8 /opt/oracle/oradata/test/odu02.dbf
         9 /opt/oracle/oradata/test/odu01.dbf
        10 /opt/oracle/product/10.2.0/db_1/dbs/MISSING00010
10 rows selected.
--需要重建控制文件，删除不存在的数据文件
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> STARTUP NOMOUNT
ORACLE instance started.
Total System Global Area  209715200 bytes
Fixed Size                  2082784 bytes
Variable Size             130025504 bytes
Database Buffers           71303168 bytes
Redo Buffers                6303744 bytes
SQL> CREATE CONTROLFILE REUSE DATABASE "TEST" NORESETLOGS  ARCHIVELOG
  2      MAXLOGFILES 16
  3      MAXLOGMEMBERS 3
  4      MAXDATAFILES 100
  5      MAXINSTANCES 8
  6      MAXLOGHISTORY 292
  7  LOGFILE
  8    GROUP 1 '/opt/oracle/oradata/test/redo01.log'  SIZE 50M,
  9    GROUP 2 '/opt/oracle/oradata/test/redo02.log'  SIZE 50M,
 10    GROUP 3 '/opt/oracle/oradata/test/redo03.log'  SIZE 50M
 11  DATAFILE
 12    '/opt/oracle/oradata/test/system01.dbf',
 13    '/opt/oracle/oradata/test/undotbs01.dbf',
 14    '/opt/oracle/oradata/test/sysaux01.dbf',
 15    '/opt/oracle/oradata/test/users01.dbf',
 16    '/opt/oracle/oradata/test/user32g.dbf',
 17    '/opt/oracle/oradata/test/xifenfei01.dbf',
 18    '/opt/oracle/oradata/test/user02.dbf',
 19    '/opt/oracle/oradata/test/odu02.dbf',
 20    '/opt/oracle/oradata/test/odu01.dbf'
 21  CHARACTER SET ZHS16GBK
 22  ;
Control file created.
SQL> alter database open;
Database altered.
SQL> select file_id,file_name,bytes from dba_data_files order by 1;
   FILE_ID FILE_NAME                                     BYTES
---------- ---------------------------------------- ----------
         1 /opt/oracle/oradata/test/system01.dbf     524288000
         2 /opt/oracle/oradata/test/undotbs01.dbf   1289748480
         3 /opt/oracle/oradata/test/sysaux01.dbf     377487360
         4 /opt/oracle/oradata/test/users01.dbf        5242880
         5 /opt/oracle/oradata/test/user32g.dbf       10485760
         6 /opt/oracle/oradata/test/xifenfei01.dbf    20971520
         7 /opt/oracle/oradata/test/user02.dbf        10485760
         8 /opt/oracle/oradata/test/odu02.dbf       1.1283E+10
         9 /opt/oracle/oradata/test/odu01.dbf        104857600
9 rows selected.
SQL> select * from v$dbfile order by 1;
     FILE# NAME
---------- ----------------------------------------
         1 /opt/oracle/oradata/test/system01.dbf
         2 /opt/oracle/oradata/test/undotbs01.dbf
         3 /opt/oracle/oradata/test/sysaux01.dbf
         4 /opt/oracle/oradata/test/users01.dbf
         5 /opt/oracle/oradata/test/user32g.dbf
         6 /opt/oracle/oradata/test/xifenfei01.dbf
         7 /opt/oracle/oradata/test/user02.dbf
         8 /opt/oracle/oradata/test/odu02.dbf
         9 /opt/oracle/oradata/test/odu01.dbf
9 rows selected.

补充说明：非归档模式下，NOARCHIVELOG创建控制文件，其他无太大区别
测试来源：itpub:数据文件物理性删除相关问题疑惑?
参考blog：roger:如何彻底删除已经不存在的数据文件？

rman中关于archivelog操作

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：rman中关于archivelog操作

RMAN> list backup of archivelog all;
列出所有archive log 备份
RMAN> list backup of archivelog from logseq 100 until logseq 120;
列出archive log 从100到120
RMAN> list backup of archivelog sequence between 100 and 110;
列出archive log 从100到120
–说明:between……and只能使用sequence，而不能使用logseq
RMAN> list backup of archivelog from logseq 100;
列出seq大于等于100的archive log
RMAN> list backup of archivelog low logseq 120;
列出seq大于等于120的archive log
RMAN> list backup of archivelog sequence 100;
列出seq为100的archive log
–说明:在对于rman中关于archivelog的操作中logseq与sequence作用相同，但是建议尽量使用sequence
RMAN> list backup of archivelog logseq 85;
列出seq为85的archive log
RMAN> list backup of archivelog until logseq 85;
列出seq小于等于85的archive log
RMAN> list backup of archivelog high logseq 40;
列出seq小于等于40的archive log
RMAN> list backup of archivelog from time ‘sysdate-7’;
列出7天以前的archive log
RMAN> run {
2> set archivelog destination to ‘/opt/oracle/oradata/test/newlog’;
3> restore archivelog low logseq 40;
4> }
从seq为40开始，恢复到/opt/oracle/oradata/test/newlog中
–说明:list backup of archivelog中限定日志的位置也适合restore archivelog
RMAN> backup archivelog sequence between 100 and 110 format ‘/tmp/text_test.rman’ delete input;
备份seq为100至110的archive log
–说明:list backup of archivelog中限定日志的位置也适合backup archivelog
RMAN>DELETE ARCHIVELOG ALL COMPLETED BEFORE ‘SYSDATE-7’;
删除7天前archive log
RMAN>DELETE ARCHIVELOG low logseq 40;
删除seq大于等于40的archive log
RMAN> crosscheck archivelog all;
RMAN> delete expired archivelog all;
删除无效archive log
–说明:DELETE ARCHIVELOG中限定日志的位置也适合restore archivelog

假坏块引起恐慌

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：假坏块引起恐慌

alert文件出现如下日志
Fri Sep 16 02:58:25 2011
Hex dump of (file 19, block 1444767) in trace file /opt/oracle/admin/ora9i/udump/ora9i_ora_24702.trc
Corrupt block relative dba: 0x04d60b9f (file 19, block 1444767)
Fractured block found during backing up datafile
Data in bad block:
type: 6 format: 2 rdba: 0x04d60b9f
last change scn: 0x0abf.56961827 seq: 0x1 flg: 0x04
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0x7c340601
check value in block header: 0xba17
computed block checksum: 0x6413
Reread of blocknum=1444767, file=/opt/oracle/oradata/ora9i/TS_INDX_Base.005.dbf. found valid data
因为这个是我们比较重要的业务服务器，如果出现坏块，不能及时处理，后果将不堪设想，因此我马上检查
先查看是什么对象：(结果是一个分区表的index，担心减少一半，index大不了重建，无大事)

SELECT OWNER, SEGMENT_NAME, SEGMENT_TYPE, TABLESPACE_NAME, A.PARTITION_NAME
  FROM DBA_EXTENTS A
 WHERE FILE_ID = &FILE_ID
   AND &BLOCK_ID BETWEEN BLOCK_ID AND BLOCK_ID + BLOCKS - 1;

然后检查是否真的坏块
方法一：dbv

[oracle@DB1 bdump]$ dbv file=/opt/oracle/oradata/ora9i/TS_INDX_Base.005.dbf blocksize=8192
DBVERIFY: Release 10.2.0.4.0 - Production on Fri Sep 16 09:15:11 2011
Copyright (c) 1982, 2007, Oracle.  All rights reserved.
DBVERIFY - Verification starting : FILE = /opt/oracle/oradata/ora9i/TS_INDX_Base.005.dbf
DBVERIFY - Verification complete
Total Pages Examined         : 2207744
Total Pages Processed (Data) : 0
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 2201581
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 3271
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 2892
Total Pages Marked Corrupt   : 0
Total Pages Influx           : 0
Highest block SCN            : 1454468581 (2751.1454468581)

结论无坏块
方法二：bbed

[oracle@DB1 lib]$ bbed
Password:
BBED: Release 2.0.0.0.0 - Limited Production on Fri Sep 16 10:01:26 2011
Copyright (c) 1982, 2007, Oracle.  All rights reserved.
************* !!! For Oracle Internal Use only !!! ***************
BBED> set filename '/opt/oracle/oradata/ora9i/TS_INDX_Base.005.dbf'
        FILENAME        /opt/oracle/oradata/ora9i/TS_INDX_Base.005.dbf
BBED> set block 1444767
        BLOCK#          1444767
BBED> VERIFY
DBVERIFY - Verification starting
FILE = /opt/oracle/oradata/ora9i/TS_INDX_Base.005.dbf
BLOCK = 1444767
DBVERIFY - Verification complete
Total Blocks Examined         : 1
Total Blocks Processed (Data) : 0
Total Blocks Failing   (Data) : 0
Total Blocks Processed (Index): 1
Total Blocks Failing   (Index): 0
Total Blocks Empty            : 0
Total Blocks Marked Corrupt   : 0
Total Blocks Influx           : 0

再次证明无坏块
方法三：rman
RMAN> backup validate datafile 19;
结果查询V$BACKUP_CORRUPTION也无坏块
方法四：使用index查询
结果也正常，没报错，alert中无错误记录
发现alert报错，但是实际没有错误，查询相关资料发现
从日志中可以看到，提示Corrupt的block对应的dba为0x04d60b9f (file 19, block 1444767)，data block的类型为6（6为trans data，所有的data和index blocks都是该类型）。Oracle发现block有可能corrupt后，进行了reread，结果为found valid data，说明数据块未损坏。Fractured block found，表示rman发现这个数据块正在被使用，这时rman会进行重新读取，如果再次失败，才认为是坏块。如果第二次尝试读取时成功，则表示数据完好，不会产生影响。此类信息在IO负载较高的情况下进行rman备份时比较容易出现。
查询系统发现，正好该时间段是系统io负载最高的时候

ORA-01244/ORA-01110解决

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：ORA-01244/ORA-01110解决

rman 恢复过程中出现以下错误

RMAN> recover database;
Starting recover at 20-AUG-11
using channel ORA_DISK_1
starting media recovery
archive log filename=/opt/oracle/product/9.2.0/db_1/dbs/arch1_13.dbf thread=1 sequence=13
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 08/20/2011 03:54:30
ORA-00283: recovery session canceled due to errors
RMAN-11003: failure during parse/execution of SQL statement: alter database recover logfile '/opt/oracle/product/9.2.0/db_1/dbs/arch1_13.dbf'
ORA-00283: recovery session canceled due to errors
ORA-01244: unnamed datafile(s) added to controlfile by media recovery
ORA-01110: data file 2: '/opt/oracle/oradata/xifenfei/xff01.dbf'

错误原因分析
在rman备份后，添加了数据文件，使用的是备份的控制文件进行恢复数据库导致（不能识别新的数据文件）
解决方法
通过sqlplus创建数据文件
SQL> alter database create datafile 2 as ‘/opt/oracle/oradata/xifenfei/xff01.dbf’;
Database altered.
然后继续在rman中执行恢复数据库操作
该情况说明
此中情况只有在oracle 9i中出现；在10g中，rman恢复过程会自动的创建新添加文件，见oracle 10g rman自动创建数据文件

undo异常处理步骤（9i）

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：undo异常处理步骤（9i）

1、启动数据库，发现错误
startup
2、查看是否是undo文件损坏引起，并查看是否是当前undo，不是当前undo直接offline，然后open数据库，再删除掉该数据该undo即可
select a.ts#,a.name,b.name from v$datafile a,v$tablespace b where a.ts#=b.ts#;
show parameter undo_tablespace;
3、损坏undo离线，创建pfile文件
alter database datafile n offline drop;
create pfile=’/tmp/pfile’ from spfile;
4、打开数据库,如果打开失败，请继续5，如果成功按照undo异常处理步骤（10g）方法处理
alter database open;
5、如果数据库不能正常打开，而是提示，如下错误：
ERROR at line 1:
ORA-01092: ORACLE instance terminated. Disconnection forced
6、检查日志文件，发现如下：
SMON: about to recover undo segment 21
SMON: mark undo segment 21 as needs recovery
SMON: about to recover undo segment 22
SMON: mark undo segment 22 as needs recovery
SMON: about to recover undo segment 23
SMON: mark undo segment 23 as needs recovery
SMON: about to recover undo segment 24
SMON: mark undo segment 24 as needs recovery
SMON: about to recover undo segment 25
SMON: mark undo segment 25 as needs recovery
SMON: about to recover undo segment 26
SMON: mark undo segment 26 as needs recovery
SMON: about to recover undo segment 27
SMON: mark undo segment 27 as needs recovery
SMON: about to recover undo segment 28
SMON: mark undo segment 28 as needs recovery
SMON: about to recover undo segment 29
SMON: mark undo segment 29 as needs recovery
SMON: about to recover undo segment 30
SMON: mark undo segment 30 as needs recovery
7、编辑pfile文件，内容为
*.undo_management=’MANUAL’
*._allow_resetlogs_corruption=true
*._corrupted_rollback_segments=(_SYSSMU21$,_SYSSMU22$,_SYSSMU23$,_SYSSMU24$,
_SYSSMU25$,_SYSSMU26$,_SYSSMU27$,_SYSSMU28$,_SYSSMU29$,_SYSSMU30$)
*.undo_tablespace=’SYSTEM’
8、退出当前sqlplus，重新登录，利用pfile启动数据库
startup
9、创建新undo表空间
CREATE UNDO TABLESPACE UNDOTBSNEW DATAFILE
‘/opt/oracle/oradata/xifenfei/UNDOTBS01.dbf
SIZE 50M autoextend on next 10m maxsize 30G;
10、查询回滚段信息，为下面删除损坏undo的回滚段做到心中有底
select segment_name,status from dba_rollback_segs;
11、删除损坏undo
drop tablespace UNDOTBSOLD including contents and datafiles;
12、查看回滚段状态
select segment_name,status from dba_rollback_segs;
13、如果有损坏表空间回滚段还存在，手工删除
drop rollback segment “_SYSSMUx$”;
14、修改pfile内容
*.undo_management=’AUTO’
#*._allow_resetlogs_corruption=true
#*._corrupted_rollback_segments=(_SYSSMU21$,_SYSSMU22$,_SYSSMU23$,_SYSSMU24$,
_SYSSMU25$,_SYSSMU26$,_SYSSMU27$,_SYSSMU28$,_SYSSMU29$,_SYSSMU30$)
*.undo_tablespace=’UNDOTBSNEW’
15、重启数据库
shutdown immediate
startup
说明：可以先删除需要恢复的回滚段，再删除损坏的undo表空间

undo异常处理步骤（10g）

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：undo异常处理步骤（10g）

1、启动数据库，发现错误
startup
2、查看是否是undo文件损坏引起
select a.ts#,a.name,b.name from v$datafile a,v$tablespace b where a.ts#=b.ts#;
3、损坏undo离线
alter database datafile n offline drop;
4、打开数据库
alter database open;
5、查看当前undo表空间，并确认是否是当前undo损坏，如果不是当前undo，直接执行8，否则继续
show parameter undo_tablespace;
6、创建新undo表空间
CREATE UNDO TABLESPACE UNDOTBSNEW DATAFILE
‘/opt/oracle/oradata/xifenfei/UNDOTBS01.dbf
SIZE 50M autoextend on next 10m maxsize 30G;
7、修改默认undo为新创建表空间
alter system set undo_tablespace=’UNDOTBSNEW’;
8、查询回滚段信息，为下面删除损坏undo的回滚段做到心中有底
select segment_name,status from dba_rollback_segs;
9、删除损坏undo，如果报ORA-01548错误，继续下面操作，否则跳到14
drop tablespace UNDOTBSOLD including contents and datafiles;
10、创建pfile文件
create pfile=’/tmp/pfile’ from spfile;
11、修改pfile文件，添加隐含参数
*._allow_resetlogs_corruption=true
*._corrupted_rollback_segments=(_SYSSMU1$,_SYSSMU2$,_SYSSMU3$,_SYSSMU4$,_SYSSMU5$,
_SYSSMU6$,_SYSSMU7$,_SYSSMU8$,_SYSSMU9$,_SYSSMU10$)
12、使用pfile启动数据库
startup pfile=’/tmp/pfile’
13、删除损坏undo
drop tablespace UNDOTBSOLD including contents and datafiles;
14、查看回滚段状态
select segment_name,status from dba_rollback_segs;
15、如果有损坏表空间回滚段还存在，手工删除
drop rollback segment “_SYSSMUx$”;
16、重启数据库
shutdown immediate
startup

当前联机日志损坏恢复

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：当前联机日志损坏恢复

环境模拟
删除状态为active的联机日志，然后强行关闭数据库
处理过程
SQL> startup
ORACLE instance started.
Total System Global Area 167772160 bytes
Fixed Size 1260720 bytes
Variable Size 142607184 bytes
Database Buffers 16777216 bytes
Redo Buffers 7127040 bytes
Database mounted.
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: ‘/u01/oradata/xienfei/redo01.log’
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
Alert.log 日志中错误
Wed Aug 24 00:26:33 2011
Errors in file /u01/admin/xienfei/udump/xff_ora_9186.trc:
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: ‘/u01/oradata/xienfei/redo01.log’
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
xff_ora_9186.trc文件中错误
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: ‘/u01/oradata/xienfei/redo01.log’
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
查询当前日志组状态
SQL> select a.group#,a.status,b.member from v$log a,v$logfile b where a.group#=b.group#;
GROUP# STATUS MEMBER
———- —————- ———————————————
1 CURRENT /u01/oradata/xienfei/redo01.log
3 INACTIVE /u01/oradata/xienfei/redo03.log
2 ACTIVE /u01/oradata/xienfei/redo02.log
尝试删除redo日志
SQL> alter database drop logfile group 1;
alter database drop logfile group 1
*
ERROR at line 1:
ORA-01623: log 1 is current log for instance xff (thread 1) – cannot drop
ORA-00312: online log 1 thread 1: ‘/u01/oradata/xienfei/redo01.log’
发现是当前日志不能被删除，尝试切换日志
SQL> alter system switch logfile;
alter system switch logfile
*
ERROR at line 1:
ORA-01109: database not open
在数据库未打开状态，不能切换日志，只能尝试清空日志
SQL> alter database clear unarchived logfile group 1;
alter database clear unarchived logfile group 1
*
ERROR at line 1:
ORA-01624: log 1 needed for crash recovery of instance xff (thread 1)
ORA-00312: online log 1 thread 1: ‘/u01/oradata/xienfei/redo01.log’
因为数据库恢复需要使用，不能被清空，尝试不完成恢复
SQL> recover database until cancel;
ORA-00279: change 1272687 generated at 08/24/2011 00:20:05 needed for thread 1
ORA-00289: suggestion : /u01/archive/1_27_756841839.arc
ORA-00280: change 1272687 for thread 1 is in sequence #27
Specify log: {=suggested | filename | AUTO | CANCEL}
auto
ORA-00279: change 1272903 generated at 08/24/2011 00:25:17 needed for thread 1
ORA-00289: suggestion : /u01/archive/1_28_756841839.arc
ORA-00280: change 1272903 for thread 1 is in sequence #28
ORA-00278: log file ‘/u01/archive/1_27_756841839.arc’ no longer needed for this
recovery
ORA-00308: cannot open archived log ‘/u01/archive/1_28_756841839.arc’
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: ‘/u01/oradata/xienfei/system01.dbf’
已经提示数据不一致，尝试着打开数据库
SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: ‘/u01/oradata/xienfei/system01.dbf’
创建pfile文件，添加隐含参数，使之不进行检查点一致性校验
SQL> create pfile=’/tmp/pfile’ from spfile;
File created.
修改pfile ，添加以下参数
*._allow_resetlogs_corruption=TRUE
*._allow_error_simulation=TRUE
SQL> shutdown abort
ORACLE instance shut down.
使用pfile打开数据库
SQL> startup pfile=’/tmp/pfile’
ORACLE instance started.
Total System Global Area 167772160 bytes
Fixed Size 1260720 bytes
Variable Size 150995792 bytes
Database Buffers 8388608 bytes
Redo Buffers 7127040 bytes
Database mounted.
ORA-38760: This database instance failed to turn on flashback database
发现flashback导致数据库不能被正常打开，尝试关闭它
SQL> alter database flashback off;
Database altered.
尝试直接open数据库
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open
根据提示，使用resetlogs打开数据库
SQL> alter database open resetlogs;
Database altered.
查询日志状态
SQL> select a.group#,a.status,b.member from v$log a,v$logfile b where a.group#=b.group#;
GROUP# STATUS MEMBER
———- —————- ———————————————
3 UNUSED /u01/oradata/xienfei/redo03.log
2 UNUSED /u01/oradata/xienfei/redo02.log
1 CURRENT /u01/oradata/xienfei/redo01.log
因为group1错误，而当前日志组在group 1上，所以切换日志组
SQL> alter system switch logfile;
System altered.
SQL> select a.group#,a.status,b.member from v$log a,v$logfile b where a.group#=b.group#;
GROUP# STATUS MEMBER
———- —————- ———————————————
3 UNUSED /u01/oradata/xienfei/redo03.log
2 CURRENT /u01/oradata/xienfei/redo02.log
1 ACTIVE /u01/oradata/xienfei/redo01.log
SQL> alter system checkpoint;
System altered.
SQL> select a.group#,a.status,b.member from v$log a,v$logfile b where a.group#=b.group#;
GROUP# STATUS MEMBER
———- —————- ———————————————
3 UNUSED /u01/oradata/xienfei/redo03.log
2 CURRENT /u01/oradata/xienfei/redo02.log
1 INACTIVE /u01/oradata/xienfei/redo01.log
删除有问题的group 1日志组
SQL> alter database drop logfile group 1;
Database altered.
SQL> alter system switch logfile;
System altered.
添加日志组并检查是否正确
SQL> select a.group#,a.status,b.member from v$log a,v$logfile b where a.group#=b.group#;
GROUP# STATUS MEMBER
———- —————- ———————————————
3 CURRENT /u01/oradata/xienfei/redo03.log
2 ACTIVE /u01/oradata/xienfei/redo02.log
SQL> alter database add logfile group 1 ‘/u01/oradata/xienfei/redo01.log’ size 50m reuse;
Database altered.
SQL> alter system switch logfile;
System altered.
SQL> select a.group#,a.status,b.member from v$log a,v$logfile b where a.group#=b.group#;
GROUP# STATUS MEMBER
———- —————- ———————————————
3 ACTIVE /u01/oradata/xienfei/redo03.log
2 ACTIVE /u01/oradata/xienfei/redo02.log
1 CURRENT /u01/oradata/xienfei/redo01.log
注意：根据oracle官方建议，使用oracle隐含参数运行数据库可能存在很多不稳定因素，建议立即导出数据库数据，然后新建库，重新导入数据

数据库open状态下日志异常处理

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：数据库open状态下日志异常处理

一、环境模拟

删除INACTIVE状态redo日志的物理文件，然后进行大批量事务操作

二、出现现象

1、alert.log记录

Tue Aug 23 23:32:02 2011

Errors in file /u01/admin/xienfei/bdump/xff_arc1_8773.trc:

ORA-00313: Message 313 not found; No message file for product=RDBMS, facility=ORA; arguments: [3] [1]

ORA-00312: Message 312 not found; No message file for product=RDBMS, facility=ORA; arguments: [3] [1] [/u01/oradata/xienfei/redo03.log]

ORA-27037: Message 27037 not found; No message file for product=RDBMS, facility=ORA

Linux Error: 2: No such file or directory

Additional information: 3

2、xff_arc1_8773.trc文件中内容

*** 2011-07-18 18:35:32.071 59526 kcrr.c

kcrrfail: dest:2 err:12541 force:0 blast:1

ORA-00313: Message 313 not found; No message file for product=RDBMS, facility=ORA; arguments: [3] [1]

ORA-00312: Message 312 not found; No message file for product=RDBMS, facility=ORA; arguments: [3] [1] [/u01/oradata/xienfei/redo03.log]

ORA-27037: Message 27037 not found; No message file for product=RDBMS, facility=ORA

Linux Error: 2: No such file or directory

三、处理过程

1、由alert中的redo文件路径，查询group#

SQL> select group#,member from v$logfile;

GROUP# MEMBER

———- ———————————————

3 /u01/oradata/xienfei/redo03.log

2 /u01/oradata/xienfei/redo02.log

1 /u01/oradata/xienfei/redo01.log

SQL> select group#,sequence#,status from v$log;

GROUP# SEQUENCE# STATUS

———- ———- —————-

1 16 ACTIVE

2 17 CURRENT

3 15 INACTIVE

2、确定是inactive状态的redo日志，直接删除该日志组

SQL> alter database drop logfile group 3;

alter database drop logfile group 3

ERROR at line 1:

ORA-00350: log 3 of instance xff (thread 1) needs to be archived

ORA-00312: online log 3 thread 1: ‘/u01/oradata/xienfei/redo03.log’

3、删除失败，提示该日志需要归档，然后直接强行执行清空redo操作

SQL> alter database clear logfile group 3;

alter database clear logfile group 3

ERROR at line 1:

ORA-00350: log 3 of instance xff (thread 1) needs to be archived

ORA-00312: online log 3 thread 1: ‘/u01/oradata/xienfei/redo03.log’

4、还不行，加大力度，直接清空并不归档

SQL> ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 3;

Database altered.

5、再删除group 3

SQL> alter database drop logfile group 3;

alter database drop logfile group 3

ERROR at line 1:

ORA-01623: log 3 is current log for instance xff (thread 1) – cannot drop

ORA-00312: online log 3 thread 1: ‘/u01/oradata/xienfei/redo03.log’

6、还是失败，根据提示查看该日志组当前状态

SQL> select group#,sequence#,status from v$log;

GROUP# SEQUENCE# STATUS

———- ———- —————-

1 16 INACTIVE

2 17 ACTIVE

3 18 CURRENT

7、切换日志组

SQL> alter system switch logfile;

System altered.

8、查看状态，并处理置于INACTIVE状态

SQL> select group#,sequence#,status from v$log;

GROUP# SEQUENCE# STATUS

———- ———- —————-

1 19 CURRENT

2 17 ACTIVE

3 18 ACTIVE

SQL> alter system checkpoint;

System altered.

SQL> select group#,sequence#,status from v$log;

GROUP# SEQUENCE# STATUS

———- ———- —————-

1 19 CURRENT

2 17 INACTIVE

3 18 INACTIVE

9、再次删除归档group 3

SQL> alter database drop logfile group 3;

alter database drop logfile group 3

ERROR at line 1:

ORA-00350: log 3 of instance xff (thread 1) needs to be archived

ORA-00312: online log 3 thread 1: ‘/u01/oradata/xienfei/redo03.log’

10、再次清空日志并不归档

SQL> ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP 3;

Database altered.

11、查询状态

SQL> select group#,sequence#,status from v$log;

GROUP# SEQUENCE# STATUS

———- ———- —————-

1 19 CURRENT

2 17 INACTIVE

3 0 UNUSED

12、再次删除group 3

SQL> alter database drop logfile group 3;

Database altered.

SQL> select group#,sequence#,status from v$log;

GROUP# SEQUENCE# STATUS

———- ———- —————-

1 19 CURRENT

2 17 INACTIVE

13、删除丢失的group 3成功，需要添加一组日志

SQL> alter database add logfile group 3 ‘/u01/oradata/xienfei/redo03.log’ size 50m reuse;

Database altered.

14、核实是否正常

SQL> alter system switch logfile;

System altered.

SQL> /

System altered.

SQL> /

System altered.

SQL> select group#,sequence#,status from v$log;

GROUP# SEQUENCE# STATUS

———- ———- —————-

1 22 CURRENT

2 21 ACTIVE

3 20 INACTIVE

ORA-00205问题处理

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：ORA-00205问题处理

1、启动数据库异常
SQL> startup
ORACLE instance started.
Total System Global Area 167772160 bytes
Fixed Size 1260720 bytes
Variable Size 142607184 bytes
Database Buffers 16777216 bytes
Redo Buffers 7127040 bytes
ORA-00205: error in identifying control file, check alert log for more info
alert.log日志中记录
ALTER DATABASE MOUNT
Mon Jul 18 17:32:58 2011
ORA-00202: Message 202 not found; No message file for product=RDBMS, facility=ORA; arguments: [/u01/oradata/xienfei/control01.ctl]
ORA-27037: Message 27037 not found; No message file for product=RDBMS, facility=ORA
Linux Error: 2: No such file or directory
2、根据提示缺少控制文件，第一步是看看有没有冗余的控制文件，然后修改pfile或者复制控制文件处理，如果没有利用备份控制文件恢复
RMAN> restore controlfile from ‘/tmp/rman_1kmhorc2_1_1’;
Starting restore at 18-JUL-11
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=156 devtype=DISK
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:04
output filename=/u01/oradata/xienfei/control01.ctl
Finished restore at 18-JUL-11
3、恢复控制文件后，数据库至于mount状态
RMAN> alter database mount;
database mounted
released channel: ORA_DISK_1
4、添加归档日志到控制文件
RMAN> catalog start with ‘/u01/archive’;
Starting implicit crosscheck backup at 18-JUL-11
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=156 devtype=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: sid=155 devtype=DISK
Crosschecked 29 objects
Crosschecked 12 objects
Finished implicit crosscheck backup at 18-JUL-11
Starting implicit crosscheck copy at 18-JUL-11
using channel ORA_DISK_1
using channel ORA_DISK_2
Crosschecked 1 objects
Finished implicit crosscheck copy at 18-JUL-11
searching for all files in the recovery area
cataloging files…
no files cataloged
searching for all files that match the pattern /u01/archive
List of Files Unknown to the Database
=====================================
…………
Do you really want to catalog the above files (enter YES or NO)? yes
cataloging files…
cataloging done
List of Cataloged Files
=======================
…………
RMAN> exit
[oracle@node2 tmp]$ sqlplus / as sysdba
SQL*Plus: Release 10.2.0.3.0 – Production on Mon Jul 18 17:43:47 2011
Copyright (c) 1982, 2006, Oracle. All Rights Reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 – Production
With the Partitioning, OLAP and Data Mining options
5、使用备份控制文件恢复
SQL> recover database using backup controlfile;
ORA-00283: recovery session canceled due to errors
ORA-01111: name for data file 8 is unknown – rename to correct file
ORA-01110: data file 8: ‘/u01/oracle/dbs/UNNAMED00008’
ORA-01157: cannot identify/lock data file 8 – see DBWR trace file
ORA-01111: name for data file 8 is unknown – rename to correct file
ORA-01110: data file 8: ‘/u01/oracle/dbs/UNNAMED00008’
6、发现控制文件后又新增数据文件，需要重命名控制文件中的新增数据文件
SQL> select file#,name from v$datafile where file#=8;
FILE# NAME
———- ———————————————-
8 /u01/oracle/dbs/UNNAMED00008
SQL> alter database rename file ‘/u01/oracle/dbs/UNNAMED00008’ to ‘/u01/oradata/xienfei/cfxff01.dbf’;
Database altered.
7、继续进行不完成恢复（利用归档日志）
SQL> recover database using backup controlfile;
ORA-00279: change 1158476 generated at 07/18/2011 16:43:27 needed for thread 1
ORA-00289: suggestion : /u01/archive/1_1_756837539.arc
ORA-00280: change 1158476 for thread 1 is in sequence #1
Specify log: {=suggested | filename | AUTO | CANCEL}
auto
ORA-00279: change 1158594 generated at 07/18/2011 16:44:01 needed for thread 1
ORA-00289: suggestion : /u01/archive/1_2_756837539.arc
ORA-00280: change 1158594 for thread 1 is in sequence #2
ORA-00278: log file ‘/u01/archive/1_1_756837539.arc’ no longer needed for this
recovery
…………
ORA-00308: cannot open archived log ‘/u01/archive/1_7_756837539.arc’
ORA-27037: unable to obtain file status
Linux Error: 2: No such file or directory
Additional information: 3
8、根据提示，应该是归档日志恢复完成，需要利用联机日志继续恢复
SQL> recover database using backup controlfile;
ORA-00279: change 1201601 generated at 07/18/2011 17:29:19 needed for thread 1
ORA-00289: suggestion : /u01/archive/1_7_756837539.arc
ORA-00280: change 1201601 for thread 1 is in sequence #7
Specify log: {=suggested | filename | AUTO | CANCEL}
/u01/oradata/xienfei/redo03.log
ORA-00310: archived log contains sequence 6; sequence 7 required
ORA-00334: archived log: ‘/u01/oradata/xienfei/redo03.log’
SQL> recover database using backup controlfile;
ORA-00279: change 1201601 generated at 07/18/2011 17:29:19 needed for thread 1
ORA-00289: suggestion : /u01/archive/1_7_756837539.arc
ORA-00280: change 1201601 for thread 1 is in sequence #7
Specify log: {=suggested | filename | AUTO | CANCEL}
/u01/oradata/xienfei/redo01.log
Log applied.
Media recovery complete.
9、resetlogs打开数据库
SQL> alter database open resetlogs;
Database altered.

分类目录归档：Oracle备份恢复