当前联机日志损坏恢复

联系:手机/微信(+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.

重建控制文件

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

标题:重建控制文件

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

#  使用alter database backup controlfile to trace;产生控制文件的trace file
-- Below are two sets of SQL statements, each of which creates a new
-- control file and uses it to open the database. The first set opens
-- the database with the NORESETLOGS option and should be used only if
-- the current versions of all online logs are available. The second
-- set opens the database with the RESETLOGS option and should be used
-- if online logs are unavailable.
-- The appropriate set of statements can be copied from the trace into
-- a script file, edited as necessary, and executed when there is a
-- need to re-create the control file.
#  需要重建控制文件的话, 如果online redo 是可用的, 使用NORESETLOGS 创建新控制文件打开数据库
#  如果online redo是不可用的, 那么需要使用RESETLOGS 创建新控制文件打开数据库,
#  联机日志被重置,数据有可能丢失
--
--     Set #1. NORESETLOGS case
--
-- The following commands will create a new control file and use it
-- to open the database.
-- Data used by Recovery Manager will be lost.
-- Additional logs may be required for media recovery of offline
-- Use this only if the current versions of all online logs are
-- available.
-- After mounting the created controlfile, the following SQL
-- statement will place the database in the appropriate
-- protection mode:
--  ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE
#   下面的命令用来创建一个新的控制文件来开启数据库。 用于RMAN的数据将会丢失。
#   对于offline datafiles 可能需要额外的归档日志用来做介质恢复,
#   当当前版本的所有online redo log都没有问题的情况下使用noresetlogs。
STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "XIENFEI" NORESETLOGS FORCE LOGGING ARCHIVELOG
    MAXLOGFILES 16
    MAXLOGMEMBERS 3
    MAXDATAFILES 100
    MAXINSTANCES 8
    MAXLOGHISTORY 2921
LOGFILE
  GROUP 1 '/u01/oradata/xienfei/redo01.log'  SIZE 5M,
  GROUP 2 '/u01/oradata/xienfei/redo02.log'  SIZE 5M,
  GROUP 3 '/u01/oradata/xienfei/redo03.log'  SIZE 5M
-- STANDBY LOGFILE
DATAFILE
  '/u01/oradata/xienfei/system01.dbf',
  '/u01/oradata/xienfei/undotbs01.dbf',
  '/u01/oradata/xienfei/sysaux01.dbf',
  '/u01/oradata/xienfei/users01.dbf',
  '/u01/oradata/xienfei/example01.dbf',
  '/u01/oradata/xienfei/xff01.dbf',
  '/u01/oradata/xienfei/cf01.dbf',
  '/u01/oradata/xienfei/cfxff01.dbf'
CHARACTER SET ZHS16GBK
;
-- Commands to re-create incarnation table
-- Below log names MUST be changed to existing filenames on
-- disk. Any one log file from each branch can be used to
-- re-create incarnation records.
-- ALTER DATABASE REGISTER LOGFILE '/u01/archive/1_1_756837539.arc';
#  有些时候可能需要先注册归档日志,再才能够恢复
-- Recovery is required if any of the datafiles are restored backups,
-- or if the last shutdown was not normal or immediate.
#  恢复数据库
RECOVER DATABASE
-- All logs need archiving and a log switch is needed.
#  归档所有日志
ALTER SYSTEM ARCHIVE LOG ALL;
-- Database can now be opened normally.
#  打开数据库
ALTER DATABASE OPEN;
-- Commands to add tempfiles to temporary tablespaces.
-- Online tempfiles have complete space information.
-- Other tempfiles may require adjustment.
#  添加临时表空间
ALTER TABLESPACE TEMP ADD TEMPFILE '/u01/oradata/xienfei/temp01.dbf'
     SIZE 32505856  REUSE AUTOEXTEND ON NEXT 655360  MAXSIZE 32767M;
-- End of tempfile additions.
##    下面的RESETLOGS 重建语句, online redo log 中的内容都会丢失,所有的备份将无效
##    仅仅在online log 损坏的情况下使用 resetlogs 创建控制文件开启数据库。
##    resetlog创建控制文件后的开启步骤与noresetlog有一些不一样,请注意下面步骤
--     Set #2. RESETLOGS case
--
-- The following commands will create a new control file and use it
-- to open the database.
-- Data used by Recovery Manager will be lost.
-- The contents of online logs will be lost and all backups will
-- be invalidated. Use this only if online logs are damaged.
-- After mounting the created controlfile, the following SQL
-- statement will place the database in the appropriate
-- protection mode:
--  ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE
STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "XIENFEI" RESETLOGS FORCE LOGGING ARCHIVELOG
    MAXLOGFILES 16
    MAXLOGMEMBERS 3
    MAXDATAFILES 100
    MAXINSTANCES 8
    MAXLOGHISTORY 2921
LOGFILE
  GROUP 1 '/u01/oradata/xienfei/redo01.log'  SIZE 5M,
  GROUP 2 '/u01/oradata/xienfei/redo02.log'  SIZE 5M,
  GROUP 3 '/u01/oradata/xienfei/redo03.log'  SIZE 5M
-- STANDBY LOGFILE
DATAFILE
  '/u01/oradata/xienfei/system01.dbf',
  '/u01/oradata/xienfei/undotbs01.dbf',
  '/u01/oradata/xienfei/sysaux01.dbf',
  '/u01/oradata/xienfei/users01.dbf',
  '/u01/oradata/xienfei/example01.dbf',
  '/u01/oradata/xienfei/xff01.dbf',
  '/u01/oradata/xienfei/cf01.dbf',
  '/u01/oradata/xienfei/cfxff01.dbf'
CHARACTER SET ZHS16GBK
;
-- Commands to re-create incarnation table
-- Below log names MUST be changed to existing filenames on
-- disk. Any one log file from each branch can be used to
-- re-create incarnation records.
#  注册归档日志
-- ALTER DATABASE REGISTER LOGFILE '/u01/archive/1_1_756837539.arc';
-- Recovery is required if any of the datafiles are restored backups,
-- or if the last shutdown was not normal or immediate.
#  使用历史控制文件恢复数据库(因为redo log是新建,所以对于redo 而言,控制文件是新建的)
RECOVER DATABASE USING BACKUP CONTROLFILE
-- Database can now be opened zeroing the online logs.
#  使用RESETLOGS方式打开数据库
ALTER DATABASE OPEN RESETLOGS;
-- Commands to add tempfiles to temporary tablespaces.
-- Online tempfiles have complete space information.
-- Other tempfiles may require adjustment.
#  添加临时表空间
ALTER TABLESPACE TEMP ADD TEMPFILE '/u01/oradata/xienfei/temp01.dbf'
     SIZE 32505856  REUSE AUTOEXTEND ON NEXT 655360  MAXSIZE 32767M;
-- End of tempfile additions.

ORA-01578坏块解决(2)

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

标题:ORA-01578坏块解决(2)

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

ORA-01578坏块解决(1)续集
如果在坏块之前,有rman备份,可以使用rman的备份来进行恢复,确保数据不会被丢失
1、使用rman进行恢复
[oracle@ECP-UC-DB1 ~]$ $ORACLE_HOME/bin/rman target /
Recovery Manager: Release 10.2.0.4.0 – Production on Sun Aug 14 22:21:13 2011
Copyright (c) 1982, 2007, Oracle. All rights reserved.
connected to target database: TEST (DBID=2056006906)
RMAN> blockrecover datafile 6 block 1477;
Starting blockrecover at 2011-08-14 22:21:16
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=145 devtype=DISK
channel ORA_DISK_1: restoring block(s)
channel ORA_DISK_1: specifying block(s) to restore from backup set
restoring blocks of datafile 00006
channel ORA_DISK_1: reading from backup piece /tmp/0fmk0ii5_1_1
channel ORA_DISK_1: restored block(s) from backup piece 1
piece handle=/tmp/0fmk0ii5_1_1 tag=TAG20110814T213357
channel ORA_DISK_1: block restore complete, elapsed time: 00:00:02
starting media recovery
media recovery complete, elapsed time: 00:00:03
Finished blockrecover at 2011-08-14 22:21:23
2、检查坏块是否被恢复
RMAN> backup check logical validate datafile 6;
Starting backup at 2011-08-14 22:22:11
using channel ORA_DISK_1
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00006 name=/opt/oracle/oradata/test/xifenfei01.dbf
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 2011-08-14 22:22:12
RMAN> exit
Recovery Manager complete.
[oracle@ECP-UC-DB1 ~]$ sqlplus / as sysdba
SQL*Plus: Release 10.2.0.4.0 – Production on Sun Aug 14 22:22:17 2011
Copyright (c) 1982, 2007, Oracle. All Rights Reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 – 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> select file#,block#,blocks from v$database_block_corruption;
no rows selected
SQL> exit
Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 – 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
[oracle@ECP-UC-DB1 ~]$ dbv file =/opt/oracle/oradata/test/xifenfei01.dbf
DBVERIFY: Release 10.2.0.4.0 – Production on Sun Aug 14 22:22:38 2011
Copyright (c) 1982, 2007, Oracle. All rights reserved.
DBVERIFY – Verification starting : FILE = /opt/oracle/oradata/test/xifenfei01.dbf
DBVERIFY – Verification complete
Total Pages Examined : 2560
Total Pages Processed (Data) : 1372
Total Pages Failing (Data) : 0
Total Pages Processed (Index): 0
Total Pages Failing (Index): 0
Total Pages Processed (Other): 48
Total Pages Processed (Seg) : 0
Total Pages Failing (Seg) : 0
Total Pages Empty : 1140
Total Pages Marked Corrupt : 0
Total Pages Influx : 0
Highest block SCN : 1256690 (0.1256690)
3、验证数据是否正确
[oracle@ECP-UC-DB1 ~]$ sqlplus / as sysdba
SQL*Plus: Release 10.2.0.4.0 – Production on Sun Aug 14 22:34:18 2011
Copyright (c) 1982, 2007, Oracle. All Rights Reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 – 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> select count(*) from t_rep;
COUNT(*)
———-
49857
ORA-01578坏块解决(1)中的模拟环境比较,数据恢复正确,坏块问题解决

ORA-01578坏块解决(1)

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

标题:ORA-01578坏块解决(1)

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

一、创建测试表
SQL> create table t_rep as
2  select * from all_objects;
Table created.
SQL> select count(*) from  t_rep;
COUNT(*)
———-
49857
二、使用bbed修改数据块
三、错误现象
1、sqlplus窗口
SQL> select count(*) from  t_rep;
select count(*) from  t_rep
*
ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 6, block # 1477)
ORA-01110: data file 6: ‘/opt/oracle/oradata/test/xifenfei01.dbf’
2、alert.log文件中
Sun Aug 14 22:01:14 2011
Hex dump of (file 6, block 1477) in trace file /opt/oracle/admin/test/udump/test_ora_10785.trc
Corrupt block relative dba: 0x018005c5 (file 6, block 1477)
Bad check value found during buffer read
Data in bad block:
type: 6 format: 2 rdba: 0x018005c5
last change scn: 0x0000.001328ef seq: 0x2 flg: 0x04
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0x28ef0602
check value in block header: 0x493
computed block checksum: 0x44b9
Reread of rdba: 0x018005c5 (file 6, block 1477) found same corrupted data
Sun Aug 14 22:01:15 2011
Corrupt Block Found
TSN = 6, TSNAME = XFF
RFN = 6, BLK = 1477, RDBA = 25167301
OBJN = 52727, OBJD = 52728, OBJECT = T_REP, SUBOBJECT =
SEGMENT OWNER = SYS, SEGMENT TYPE = Table Segment
四、验证是否真的坏块
1、dbv验证
[oracle@ECP-UC-DB1 ~]$ dbv file =/opt/oracle/oradata/test/xifenfei01.dbf
DBVERIFY: Release 10.2.0.4.0 – Production on Sun Aug 14 22:08:37 2011
Copyright (c) 1982, 2007, Oracle.  All rights reserved.
DBVERIFY – Verification starting : FILE = /opt/oracle/oradata/test/xifenfei01.dbf
Page 1477 is marked corrupt
Corrupt block relative dba: 0x018005c5 (file 6, block 1477)
Bad check value found during dbv:
Data in bad block:
type: 6 format: 2 rdba: 0x018005c5
last change scn: 0x0000.001328ef seq: 0x2 flg: 0x04
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0x28ef0602
check value in block header: 0x493
computed block checksum: 0x44b9
DBVERIFY – Verification complete
Total Pages Examined         : 2560
Total Pages Processed (Data) : 1371
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 0
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 48
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 1140
Total Pages Marked Corrupt   : 1
Total Pages Influx           : 0
Highest block SCN            : 1256043 (0.1256043)
2、rman验证
RMAN> backup check logical validate datafile 6;
Starting backup at 2011-08-14 22:09:51
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=157 devtype=DISK
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00006 name=/opt/oracle/oradata/test/xifenfei01.dbf
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 2011-08-14 22:09:53
RMAN> exit
Recovery Manager complete.
[oracle@ECP-UC-DB1 ~]$ sqlplus / as sysdba
SQL*Plus: Release 10.2.0.4.0 – Production on Sun Aug 14 22:10:00 2011
Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 – 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL>  select file#,block#,blocks from v$database_block_corruption;SQL> exec dbms_repair.skip_corrupt_blocks(‘SYS’,’T_REP’);
FILE#     BLOCK#     BLOCKS
———- ———- ———-
6       1477          1
五、跳过坏块读取其他数据
SQL> exec dbms_repair.skip_corrupt_blocks(‘SYS’,’T_REP’);
PL/SQL procedure successfully completed.
SQL> select skip_corrupt from dba_tables where table_name=’T_REP’;
SKIP_COR
——–
ENABLED
SQL> select count(*) from t_rep;
COUNT(*)
———-
49794
说明:数据发生丢失6号文件的1477块中的数据丢失

oracle 10g flashback

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

标题:oracle 10g flashback

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

一、oracle falshback drop
利用flashback drop oracle10g可以对DDL操作进行恢复,oracla提供类似回收站的recyclebin来收集被删除的对象,其实对象在删除的时候oracle把对象写到一个数据字典表中,当用户不需要该对象的时候,可以利用purge命令来从回收站进行清除
select object_name,droptime,dropscn,purge_object,ORIGINAL_NAME from recyclebin;
flashback table f_drop to before drop;
清空回收站:
1)清空一张表:purge table “BIN$N+i42FTvSSemvMrH6frCQg==$0″/table_name;
2)清空一个index:purge index index_name;
2)清空所有对象:PURGE recyclebin;
二、oracle falshback table
对于误drop的table此可以使用本操作,还原drop的table
select t_odu.*,ora_rowscn from a;–查询每条记录对应scn
select dbms_flashback.get_system_change_number from dual;–系统当前scn
alter table t_odu enable row movement;–table row movement
flashback table t_odu to scn 1831189;–基于scn恢复
flashback table t_odu to timestamp to_timestamp(‘2011-6-27 11:45:20′,’yyyy-mm-dd hh24:mi:ss’);–基于时间点
scn补充:
可以通过select ora_rowscn from table 得到每一条结果集当前的SCN,timestamp_to_scn()将scn转换到stmestamp;scn_to_timestamp()将timestamp转换到scn。
三、oracle falshback version query
racle10g falshback 能将所有做了提交的行进行记录,就类似于审计的功能,通过falshback可以查询什么时候执行了什么操作,非常方便,包括闪回版本的查询和审计等
select COUNT(*) from t_query as of scn 1831544;
SELECT COUNT(*) FROM t_query as of timestamp to_timestamp(‘2011-07-21 14:58:00′,’yyyy-mm-dd hh24:mi:ss’);
四、oracle falshback transaction query
回闪事务功能提供对过去某段时间内所完成的事务的查询和撤销
SELECT * FROM flashback_transaction_query a WHERE a.table_name=’T_QUERY’;
补充:
UNDO_SQL 就是当时对表T_QUERY的逆向操作语句

Rman的format格式中的%s参数说明

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

标题:Rman的format格式中的%s参数说明

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

%c 备份片的拷贝数
%d 数据库名称
%D 位于该月中的第几天 (DD)
%M 位于该年中的第几月 (MM)
%F 一个基于DBID唯一的名称,这个格式的形式为c-IIIIIIIIII-YYYYMMDD-QQ,其中IIIIIIIIII为该数据库的DBID,YYYYMMDD为日期,QQ是一个1-256的序列
%n 数据库名称,向右填补到最大八个字符
%u 一个八个字符的名称代表备份集与创建时间
%p 该备份集中的备份片号,从1开始到创建的文件数
%U 一个唯一的文件名,代表%u_%p_%c
%s 备份集的号
%t 备份集时间戳
%T 年月日格式(YYYYMMDD)

ORA-38760: 此数据库实例无法启用闪回数据库

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

标题:ORA-38760: 此数据库实例无法启用闪回数据库

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

SQL> startup
ORACLE 例程已经启动。
Total System Global Area 368263168 bytes
Fixed Size 1374668 bytes
Variable Size 276825652 bytes
Database Buffers 83886080 bytes
Redo Buffers 6176768 bytes
数据库装载完毕。
ORA-38760: 此数据库实例无法启用闪回数据库
SQL> alter database flashback off;
数据库已更改。
SQL> alter database open;
数据库已更改。
SQL> alter database flashback on;
数据库已更改。
说明:如果出现以下错误,处理如下
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-38760: This database instance failed to turn on flashback database
SQL> select name from v$restore_point;
If so, drop them:
SQL> drop restore point ;
SQL> alter database flashback off;
.

ORA-01207/ORA-00338恢复

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

标题:ORA-01207/ORA-00338恢复

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

1、模拟环境
拷贝出来控制文件,然后对数据库进行一些操作,然后关闭数据库,使用拷贝出来的控制文件替换原控制文件,启动数据库
出现类此错误:
ORA-00338: 日志 2 (用于线程 1) 比控制文件更新
ORA-00312: 联机日志 2 线程 1: ‘E:\ORACLE\ORADATA\XFF\REDO02’
或者
ORA-01122: 数据库文件 1 验证失败
ORA-01110: 数据文件 1: ‘E:\ORACLE\ORADATA\XFF\SYSTEM01.DBF’
ORA-01207: 文件比控制文件更新 – 旧的控制文件
2、处理思路
1)创建控制文件
1.1)alter database backup controlfile to trace;
1.2)生成控制文件脚本

STARTUP NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "XFF" NORESETLOGS  ARCHIVELOG
    MAXLOGFILES 16
    MAXLOGMEMBERS 3
    MAXDATAFILES 100
    MAXINSTANCES 8
    MAXLOGHISTORY 584
LOGFILE
  GROUP 1 'E:\ORACLE\ORADATA\XFF\REDO01'  SIZE 10M BLOCKSIZE 512,
  GROUP 2 'E:\ORACLE\ORADATA\XFF\REDO02'  SIZE 10M BLOCKSIZE 512,
  GROUP 3 'E:\ORACLE\ORADATA\XFF\REDO03'  SIZE 10M BLOCKSIZE 512
DATAFILE
  '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',
  'E:\ORACLE\ORADATA\XFF\P301.DBF',
  'E:\ORACLE\ORADATA\XFF\OGG01.DBF',
  'E:\ORACLE\ORADATA\XFF\SPOT01.DBF'
CHARACTER SET ZHS16GBK
;

1.3)关闭数据库
shutdown abort;
1.4)删除现在的控制文件
1.5)执行生成控制文件脚本
2)恢复数据库
recover database;
3)打开数据库
alter database open;
4)添加临时文件
alter tablespace temp add tempfile
‘E:\ORACLE\ORADATA\XFF\TEMP01.DBF’ size 20m reuse;
说明:可以使用备份的控制文件进行恢复
1:startup mount;
2:recover database using backup controlfile until cancel;
然后根据情况,指定archive log和redo file。
3:alter database open resetlogs;