使用flashback database找回被误删除表空间

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

标题:使用flashback database找回被误删除表空间

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

我个人不怎么推荐使用flashback database功能,因为在生产库中,谁能够承受得起整个库的回退(也许特别极端的情况下可能需要使用到),今天帮网友恢复了一个案例:删除表空间,然后尝试着flashback database功能把这个删除的表空间找回来,但是他在整个操作过程中思路比较混乱,最后导致数据库不能正常起来。因为网友有这个方面的需求,我做了一个flashback database 找回表空间操作的试验(官方建议:flashback database在不改变数据文件的情况下使用)

1、恢复过程

SQL> select * from v$version;
BANNER
-----------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
PL/SQL Release 11.2.0.1.0 - Production
CORE    11.2.0.1.0      Production
TNS for 32-bit Windows: Version 11.2.0.1.0 - Production
NLSRTL Version 11.2.0.1.0 - Production
SQL> select flashback_on from v$database;
FLASHBACK_ON
------------------
YES
SQL> create tablespace xff_test datafile 'E:\ORACLE\ORADATA\XFF\xff_test01.dbf'
size 10m autoextend on next 1m maxsize 20m;
表空间已创建。
SQL> select to_char(sysdate,'yyyy-mm-dd hh24:mi:ss') from dual;
TO_CHAR(SYSDATE,'YY
-------------------
2011-11-12 21:05:07
SQL> create table chf.t_flashback tablespace xff_test
  2  as
  3  select * from dba_objects;
表已创建。
SQL> select count(*) from chf.t_flashback;
  COUNT(*)
----------
     73211
SQL> select to_char(sysdate,'yyyy-mm-dd hh24:mi:ss') from dual;
TO_CHAR(SYSDATE,'YY
-------------------
2011-11-12 21:06:35
SQL> host dir E:\ORACLE\ORADATA\XFF\xff_test01.dbf
 驱动器 E 中的卷没有标签。
 卷的序列号是 38D0-2A35
 E:\ORACLE\ORADATA\XFF 的目录
2011/11/12  21:04        10,493,952 XFF_TEST01.DBF
               1 个文件     10,493,952 字节
               0 个目录 14,644,822,016 可用字节
SQL> drop tablespace xff_test including contents and datafiles;
表空间已删除。
SQL> host dir E:\ORACLE\ORADATA\XFF\xff_test01.dbf
 驱动器 E 中的卷没有标签。
 卷的序列号是 38D0-2A35
 E:\ORACLE\ORADATA\XFF 的目录
找不到文件
SQL> shutdown immediate
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> startup mount;
ORACLE 例程已经启动。
Total System Global Area  368263168 bytes
Fixed Size                  1374668 bytes
Variable Size             276825652 bytes
Database Buffers           83886080 bytes
Redo Buffers                6176768 bytes
数据库装载完毕。
SQL> flashback database to timestamp
2  to_timestamp('2011-11-12 21:06:35','yyyy-mm-dd hh24:mi:ss');
闪回完成。
SQL> alter database open resetlogs;
数据库已更改。
SQL> select name from v$datafile;
NAME
-------------------------------------------------------------
E:\ORACLE\ORADATA\XFF\SYSTEM01.DBF
E:\ORACLE\ORADATA\XFF\SYSAUX01.DBF
E:\ORACLE\ORADATA\XFF\UNDOTBS01.DBF
E:\ORACLE\ORADATA\XFF\USERS01.DBF
E:\ORACLE\ORADATA\XFF\EXAMPLE01.DBF
E:\ORACLE\ORADATA\XFF\O_ORACLE.DBF
E:\ORACLE\ORADATA\XFF\XIFENFEI01.DBF
E:\ORACLE\ORADATA\XFF\P_TEST01.DBF
E:\ORACLE\ORADATA\XFF\SYS_MG01.DBF
E:\ORACLE\ORADATA\XFF\P101.DBF
E:\ORACLE\ORADATA\XFF\P201.DBF
NAME
---------------------------------------------------------------
E:\ORACLE\ORADATA\XFF\P301.DBF
E:\ORACLE\11_2_0\DATABASE\UNNAMED00013
E:\ORACLE\ORADATA\XFF\OGG01.DBF
E:\ORACLE\ORADATA\XFF\SPOT01.DBF
已选择15行。
SQL> desc chf.t_flashback;
ERROR:
ORA-04043: 对象 chf.t_flashback 不存在
SQL> COL ERROR FOR A20
SQL> SELECT FILE#,ONLINE_STATUS,ERROR FROM V$RECOVER_FILE;
     FILE# ONLINE_ ERROR
---------- ------- --------------------
        13 OFFLINE FILE NOT FOUND
SQL> SELECT NAME FROM V$DATAFILE WHERE FILE#=13;
NAME
-----------------------------------------------------------------
E:\ORACLE\11_2_0\DATABASE\UNNAMED00013
SQL> HOST DIR E:\ORACLE\11_2_0\DATABASE\UNNAMED00013
 驱动器 E 中的卷没有标签。
 卷的序列号是 38D0-2A35
 E:\ORACLE\11_2_0\DATABASE 的目录
找不到文件
SQL> ALTER DATABASE CREATE DATAFILE 13
AS 'E:\ORACLE\ORADATA\XFF\xff_test01.dbf';
数据库已更改。
SQL> HOST DIR E:\ORACLE\ORADATA\XFF\xff_test01.dbf
 驱动器 E 中的卷没有标签。
 卷的序列号是 38D0-2A35
 E:\ORACLE\ORADATA\XFF 的目录
2011/11/12  21:25        10,493,952 XFF_TEST01.DBF
               1 个文件     10,493,952 字节
               0 个目录 14,640,848,896 可用字节
SQL> recover datafile 13;
ORA-00279: 更改 10903431152368 (在 11/12/2011 21:04:40 生成) 对于线程 1
是必需的
ORA-00289: 建议: E:\ORACLE\ARCHIVELOG\ARC0000000241_0753489409.0001
ORA-00280: 更改 10903431152368 (用于线程 1) 在序列 #241 中
指定日志: {<RET>=suggested | filename | AUTO | CANCEL}
auto
已应用的日志。
完成介质恢复。
SQL> alter database datafile 13 online;
数据库已更改。
SQL> select count(*) from chf.t_flashback;
  COUNT(*)
----------
     73211

2、alert中关键信息

Sat Nov 12 21:12:30 2011
flashback database to timestamp to_timestamp('2011-11-12 21:06:35','yyyy-mm-dd hh24:mi:ss')
Flashback Restore Start
Flashback: created tablespace #18: 'XFF_TEST' in the controlfile.
Flashback: created OFFLINE file 'UNNAMED00013' for tablespace #18 in the controlfile.
Filename was:
'E:\ORACLE\ORADATA\XFF\XFF_TEST01.DBF' when dropped.
File will have to be restored from a backup and recovered.
Flashback: deleted datafile #13 in tablespace #18 from control file.
Flashback: dropped tablespace #18: 'XFF_TEST' from the control file.
Flashback Restore Complete
Flashback Media Recovery Start
 started logmerger process
Parallel Media Recovery started with 2 slaves
Sat Nov 12 21:12:38 2011
Recovery of Online Redo Log: Thread 1 Group 1 Seq 241 Reading mem 0
  Mem# 0: E:\ORACLE\ORADATA\XFF\REDO01
Flashback recovery: Added file #13 to control file as OFFLINE and 'UNNAMED00013'
because it was dropped during the flashback interval
or it was added during flashback media recovery.
File was originally created as:
'E:\ORACLE\ORADATA\XFF\XFF_TEST01.DBF'
File will have to be restored from a backup or
recreated using ALTER DATABASE CREATE DATAFILE command,
and the file has to be onlined and recovered.
Incomplete Recovery applied until change 10903431152644 time 11/12/2011 21:05:11
Sat Nov 12 21:12:44 2011
Flashback Media Recovery Complete
Completed: flashback database to timestamp to_timestamp('2011-11-12 21:06:35','yyyy-mm-dd hh24:mi:ss')
--flashback database 操作过程
……
Sat Nov 12 21:25:29 2011
ALTER DATABASE CREATE DATAFILE 13 AS 'E:\ORACLE\ORADATA\XFF\xff_test01.dbf'
Completed: ALTER DATABASE CREATE DATAFILE 13 AS 'E:\ORACLE\ORADATA\XFF\xff_test01.dbf'
Sat Nov 12 21:25:59 2011
ALTER DATABASE RECOVER  datafile 13
Media Recovery Start
Serial Media Recovery started
Media Recovery start incarnation depth : 1, target inc# : 3, irscn : 10903431152644
ORA-279 signalled during: ALTER DATABASE RECOVER  datafile 13  ...
Sat Nov 12 21:28:27 2011
ALTER DATABASE RECOVER    CONTINUE DEFAULT
Media Recovery Log E:\ORACLE\ARCHIVELOG\ARC0000000241_0753489409.0001
Recovery of Online Redo Log: Thread 1 Group 1 Seq 1 Reading mem 0
  Mem# 0: E:\ORACLE\ORADATA\XFF\REDO01
Completed: ALTER DATABASE RECOVER    CONTINUE DEFAULT
Sat Nov 12 21:29:04 2011
alter database datafile 13 online
Completed: alter database datafile 13 online
--恢复被删除数据文件过程,flashbackup database会创建表空间,但是数据文件需要人工干预

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

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

标题:块修改跟踪特性(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
 
Copyright (c) 1982, 2010, Oracle.  All Rights Reserved.
 
 
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