ORA-00600[4194]故障解决

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

标题:ORA-00600[4194]故障解决

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

朋友数据库因为断电,导致数据库正常启动片刻之后,自动down掉
一、alert日志

Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 2
Autotune of undo retention is turned on.
IMODE=BR
ILAT =18
LICENSE_MAX_USERS = 0
SYS auditing is disabled
ksdpec: called for event 13740 prior to event group initialization
Starting up ORACLE RDBMS Version: 10.2.0.1.0.
System parameters with non-default values:
  processes                = 150
  __shared_pool_size       = 58720256
  __large_pool_size        = 4194304
  __java_pool_size         = 4194304
  __streams_pool_size      = 4194304
  nls_date_format          = yyyy-mm-dd hh24:mi:ss
  sga_target               = 335544320
  control_files            = /u02/ezhou/control01.ctl
  db_block_size            = 8192
  compatible               = 10.2.0.1.0
  log_archive_dest         = /u02/arch
  log_archive_max_processes= 10
  db_file_multiblock_read_count= 16
  fast_start_mttr_target   = 300
  undo_management          = AUTO
  undo_tablespace          = UNDOTBS1
  remote_login_passwordfile= EXCLUSIVE
  db_domain                =
  dispatchers              = (PROTOCOL=TCP) (SERVICE=ezhouXDB)
  job_queue_processes      = 10
  background_dump_dest     = /u01/pp/oracle/admin/ezhou/bdump
  user_dump_dest           = /u01/pp/oracle/admin/ezhou/udump
  core_dump_dest           = /u01/pp/oracle/admin/ezhou/cdump
  audit_file_dest          = /u01/pp/oracle/admin/ezhou/adump
  db_name                  = ezhou
  open_cursors             = 400
  sql_trace                = TRUE
  pga_aggregate_target     = 94371840
MMAN started with pid=4, OS id=5539
PMON started with pid=2, OS id=5535
DBW0 started with pid=5, OS id=5541
LGWR started with pid=6, OS id=5543
SMON started with pid=8, OS id=5547
CJQ0 started with pid=10, OS id=5577
RECO started with pid=9, OS id=5575
Sat Dec 10 17:15:40 2011
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'
MMNL started with pid=12, OS id=5581
MMON started with pid=11, OS id=5579
Sat Dec 10 17:15:40 2011
starting up 1 shared server(s) ...
PSP0 started with pid=3, OS id=5537
CKPT started with pid=7, OS id=5545
Sat Dec 10 17:15:42 2011
ALTER DATABASE   MOUNT
Sat Dec 10 17:15:46 2011
Setting recovery target incarnation to 3
Sat Dec 10 17:15:47 2011
Successful mount of redo thread 1, with mount id 4055654398
Sat Dec 10 17:15:47 2011
Database mounted in Exclusive Mode
Completed: ALTER DATABASE   MOUNT
Sat Dec 10 17:15:47 2011
ALTER DATABASE OPEN
Sat Dec 10 17:15:47 2011
Beginning crash recovery of 1 threads
Sat Dec 10 17:15:47 2011
Started redo scan
Sat Dec 10 17:15:48 2011
Completed redo scan
 319 redo blocks read, 98 data blocks need recovery
Sat Dec 10 17:15:50 2011
Started redo application at
 Thread 1: logseq 24, block 3
Sat Dec 10 17:15:50 2011
Recovery of Online Redo Log: Thread 1 Group 3 Seq 24 Reading mem 0
  Mem# 0 errs 0: /u02/ezhou/redo03.log
Sat Dec 10 17:15:50 2011
Completed redo application
Sat Dec 10 17:15:51 2011
Completed crash recovery at
 Thread 1: logseq 24, block 322, scn 6168722
 98 data blocks read, 98 data blocks written, 319 redo blocks read
Sat Dec 10 17:15:51 2011
LGWR: STARTING ARCH PROCESSES
ARC1 started with pid=17, OS id=5645
ARC0 started with pid=16, OS id=5643
ARC3 started with pid=19, OS id=5649
ARC4 started with pid=20, OS id=5651
ARC2 started with pid=18, OS id=5647
ARC6 started with pid=22, OS id=5655
ARC7 started with pid=23, OS id=5657
ARC5 started with pid=21, OS id=5653
ARC8 started with pid=24, OS id=5659
Sat Dec 10 17:15:52 2011
ARC0: Archival started
ARC1: Archival started
ARC2: Archival started
ARC3: Archival started
ARC4: Archival started
ARC5: Archival started
ARC6: Archival started
ARC7: Archival started
ARC8: Archival started
ARC9: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE
ARC9 started with pid=25, OS id=5661
Sat Dec 10 17:15:52 2011
Thread 1 advanced to log sequence 25
Sat Dec 10 17:15:53 2011
ARC2: STARTING ARCH PROCESSES
Sat Dec 10 17:15:53 2011
ARC6: Becoming the 'no FAL' ARCH
ARC6: Becoming the 'no SRL' ARCH
Sat Dec 10 17:15:53 2011
ARC3: Becoming the heartbeat ARCH
Sat Dec 10 17:15:53 2011
Thread 1 opened at log sequence 25
  Current log# 1 seq# 25 mem# 0: /u02/ezhou/redo01.log
  Current log# 1 seq# 25 mem# 1: /u02/ezhou/redo01a.rdo
Successful open of redo thread 1
Sat Dec 10 17:15:53 2011
SMON: enabling cache recovery
Sat Dec 10 17:15:54 2011
ARCa: Archival started
ARC2: STARTING ARCH PROCESSES COMPLETE
ARCa started with pid=26, OS id=5663
Sat Dec 10 17:15:57 2011
Successfully onlined Undo Tablespace 1.
Sat Dec 10 17:15:57 2011
SMON: enabling tx recovery
Sat Dec 10 17:15:57 2011
Database Characterset is AL32UTF8
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
QMNC started with pid=27, OS id=5666
Sat Dec 10 17:16:13 2011
Errors in file /u01/pp/oracle/admin/ezhou/bdump/ezhou_smon_5547.trc:
ORA-00600: internal error code, arguments: [4194], [30], [27], [], [], [], [], []
Sat Dec 10 17:16:17 2011
Completed: ALTER DATABASE OPEN
Sat Dec 10 17:16:27 2011
Doing block recovery for file 2 block 4124
Block recovery from logseq 25, block 68 to scn 6168829
Sat Dec 10 17:16:27 2011
Recovery of Online Redo Log: Thread 1 Group 1 Seq 25 Reading mem 0
  Mem# 0 errs 0: /u02/ezhou/redo01.log
  Mem# 1 errs 0: /u02/ezhou/redo01a.rdo
Block recovery stopped at EOT rba 25.126.16
Block recovery completed at rba 25.126.16, scn 0.6168829
Doing block recovery for file 2 block 73
Block recovery from logseq 25, block 68 to scn 6168786
Sat Dec 10 17:16:28 2011
Recovery of Online Redo Log: Thread 1 Group 1 Seq 25 Reading mem 0
  Mem# 0 errs 0: /u02/ezhou/redo01.log
  Mem# 1 errs 0: /u02/ezhou/redo01a.rdo
Block recovery completed at rba 25.69.16, scn 0.6168789
Sat Dec 10 17:16:28 2011
Errors in file /u01/pp/oracle/admin/ezhou/bdump/ezhou_smon_5547.trc:
ORA-01595: error freeing extent (2) of rollback segment (5))
ORA-00607: Internal error occurred while making a change to a data block
ORA-00600: internal error code, arguments: [4194], [30], [27], [], [], [], [], []
Sat Dec 10 17:16:30 2011
Errors in file /u01/pp/oracle/admin/ezhou/bdump/ezhou_j002_5690.trc:
ORA-00600: internal error code, arguments: [4194], [30], [27], [], [], [], [], []
Sat Dec 10 17:16:37 2011
Doing block recovery for file 2 block 4124
Block recovery from logseq 25, block 68 to scn 6168829
Sat Dec 10 17:16:37 2011
Recovery of Online Redo Log: Thread 1 Group 1 Seq 25 Reading mem 0
  Mem# 0 errs 0: /u02/ezhou/redo01.log
  Mem# 1 errs 0: /u02/ezhou/redo01a.rdo
Block recovery completed at rba 25.126.16, scn 0.6168830
Doing block recovery for file 2 block 73
Block recovery from logseq 25, block 68 to scn 6168841
Sat Dec 10 17:16:37 2011
Recovery of Online Redo Log: Thread 1 Group 1 Seq 25 Reading mem 0
  Mem# 0 errs 0: /u02/ezhou/redo01.log
  Mem# 1 errs 0: /u02/ezhou/redo01a.rdo
Block recovery completed at rba 25.149.16, scn 0.6168843
Sat Dec 10 17:16:37 2011
Errors in file /u01/pp/oracle/admin/ezhou/bdump/ezhou_j002_5690.trc:
ORA-12012: error on auto execute of job 8886
ORA-00607: Internal error occurred while making a change to a data block
Sat Dec 10 17:16:41 2011
Errors in file /u01/pp/oracle/admin/ezhou/bdump/ezhou_j003_5692.trc:
ORA-00600: internal error code, arguments: [4194], [30], [27], [], [], [], [], []
Sat Dec 10 17:16:42 2011
DEBUG: Replaying xcb 0x32a2b17c, pmd 0x32bdbd24 for failed op 8
Doing block recovery for file 2 block 4124
Block recovery from logseq 25, block 68 to scn 6168829
Sat Dec 10 17:16:42 2011
Recovery of Online Redo Log: Thread 1 Group 1 Seq 25 Reading mem 0
  Mem# 0 errs 0: /u02/ezhou/redo01.log
  Mem# 1 errs 0: /u02/ezhou/redo01a.rdo
Block recovery completed at rba 25.126.16, scn 0.6168830
Sat Dec 10 17:16:43 2011
Errors in file /u01/pp/oracle/admin/ezhou/bdump/ezhou_j003_5692.trc:
ORA-00600: internal error code, arguments: [4194], [30], [27], [], [], [], [], []
ORA-00600: internal error code, arguments: [4194], [30], [27], [], [], [], [], []
Sat Dec 10 17:16:46 2011
Errors in file /u01/pp/oracle/admin/ezhou/bdump/ezhou_j003_5692.trc:
ORA-00600: internal error code, arguments: [4194], [30], [27], [], [], [], [], []
ORA-00600: internal error code, arguments: [4194], [30], [27], [], [], [], [], []
Sat Dec 10 17:17:46 2011
DEBUG: Replaying xcb 0x32a2b17c, pmd 0x32bdbd24 for failed op 8
Doing block recovery for file 2 block 4124
Block recovery from logseq 25, block 68 to scn 6168829
Sat Dec 10 17:17:46 2011
Recovery of Online Redo Log: Thread 1 Group 1 Seq 25 Reading mem 0
  Mem# 0 errs 0: /u02/ezhou/redo01.log
  Mem# 1 errs 0: /u02/ezhou/redo01a.rdo
Block recovery completed at rba 25.126.16, scn 0.6168830
Sat Dec 10 17:17:48 2011
Errors in file /u01/pp/oracle/admin/ezhou/bdump/ezhou_pmon_5535.trc:
ORA-00600: internal error code, arguments: [4194], [30], [27], [], [], [], [], []
Sat Dec 10 17:17:49 2011
Errors in file /u01/pp/oracle/admin/ezhou/bdump/ezhou_pmon_5535.trc:
ORA-00600: internal error code, arguments: [4194], [30], [27], [], [], [], [], []
PMON: terminating instance due to error 472
Instance terminated by PMON, pid = 5535

二、MOS记录

ERROR:
  ORA-600 [4194] [a] [b]
VERSIONS:
  versions 6.0 to 10.1
DESCRIPTION:
  A mismatch has been detected between Redo records and rollback (Undo)
  records.
  We are validating the Undo record number relating to the change being
  applied against the maximum undo record number recorded in the undo block.
  This error is reported when the validation fails.
ARGUMENTS:
  Arg [a] Maximum Undo record number in Undo block
  Arg [b] Undo record number from Redo block

三、解决办法
1、修改参数
undo_management= MANUAL
undo_tablespace= SYSTEM
2、打开数据库,删除当前undo空间,重建新undo空间
3、修改参数
undo_management= AUTO
undo_tablespace= UNDOTBSNEW
4、重新启动数据库

异常断电导致current redo损坏处理

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

标题:异常断电导致current redo损坏处理

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

一、数据库启动异常
网友因异常断电导致数据库不能正常启动,处理过程记录
1、sqlplus中提示

C:\Documents and Settings\Administrator>sqlplus "/as sysdba"
SQL*Plus: Release 11.1.0.6.0 - Production on 星期三 12月 7 12:57:02 2011
Copyright (c) 1982, 2007, Oracle.  All rights reserved.
已连接到空闲例程。
SQL> startup
ORACLE 例程已经启动。
Total System Global Area 1581916160 bytes
Fixed Size                  1336060 bytes
Variable Size             964693252 bytes
Database Buffers          603979776 bytes
Redo Buffers               11907072 bytes
数据库装载完毕。
ORA-00368: 重做日志块中的校验和错误
ORA-00353: 日志损坏接近块 12014 更改 9743799889 时间 12/05/2011 09:21:11
ORA-00312: 联机日志 3 线程 1: 'R:\ORADATA\HZYL\REDO03.LOG'

2、alert日志文件

ALTER DATABASE OPEN
Beginning crash recovery of 1 threads
 parallel recovery started with 7 processes
Started redo scan
Errors in file d:\app\administrator\diag\rdbms\hzyl\hzyl\trace\hzyl_ora_2960.trc  (incident=214262):
ORA-00353: 日志损坏接近块 12014 更改 9743799889 时间 12/05/2011 09:21:11
ORA-00312: 联机日志 3 线程 1: 'R:\ORADATA\HZYL\REDO03.LOG'
Incident details in: d:\app\administrator\diag\rdbms\hzyl\hzyl\incident\incdir_214262\hzyl_ora_2960_i214262.trc
Aborting crash recovery due to error 368
Errors in file d:\app\administrator\diag\rdbms\hzyl\hzyl\trace\hzyl_ora_2960.trc:
ORA-00368: 重做日志块中的校验和错误
ORA-00353: 日志损坏接近块 12014 更改 9743799889 时间 12/05/2011 09:21:11
ORA-00312: 联机日志 3 线程 1: 'R:\ORADATA\HZYL\REDO03.LOG'
ORA-368 signalled during: ALTER DATABASE OPEN...
Wed Dec 07 12:57:17 2011
Trace dumping is performing id=[cdmp_20111207125717]
Wed Dec 07 12:57:17 2011
Sweep Incident[214262]: completed
Errors in file d:\app\administrator\diag\rdbms\hzyl\hzyl\trace\hzyl_m000_2400.trc  (incident=214326):
ORA-00353: log corruption near block 12014 change 9743799889 time 12/05/2011 09:21:11
ORA-00312: online log 3 thread 1: 'R:\ORADATA\HZYL\REDO03.LOG'
Incident details in: d:\app\administrator\diag\rdbms\hzyl\hzyl\incident\incdir_214326\hzyl_m000_2400_i214326.trc
Trace dumping is performing id=[cdmp_20111207125718]

二、查询是损坏日志组

SQL> col member for a35
SQL> select a.group#,a.status,b.member from v$log a,v$logfile b
   2 where a.group#=b.group#;
    GROUP# STATUS           MEMBER
---------- ---------------- -----------------------------------
         3 CURRENT          R:\ORADATA\HZYL\REDO03.LOG
         2 INACTIVE         R:\ORADATA\HZYL\REDO02.LOG
         1 INACTIVE         R:\ORADATA\HZYL\REDO01.LOG

确定是因为断电导致当前redo 损坏,需要使用隐含参数+不完全恢复处理(经验)

三、不完全恢复

SQL> recover database until cancel;
ORA-00279: 更改 9743796718 (在 12/05/2011 09:07:40 生成) 对于线程 1 是必需的
ORA-00289: 建议: S:\ORAFLASH\HZYL\ARCHIVELOG\2011_12_07\O1_MF_1_15114_%U_.ARC
ORA-00280: 更改 9743796718 (用于线程 1) 在序列 #15114 中
指定日志: {<RET>=suggested | filename | AUTO | CANCEL}
auto
ORA-00308: 无法打开归档日志
'S:\ORAFLASH\HZYL\ARCHIVELOG\2011_12_07\O1_MF_1_15114_%U_.ARC'
ORA-27041: 无法打开文件
OSD-04002: 无法打开文件
O/S-Error: (OS 2) 系统找不到指定的文件。
ORA-00308: 无法打开归档日志
'S:\ORAFLASH\HZYL\ARCHIVELOG\2011_12_07\O1_MF_1_15114_%U_.ARC'
ORA-27041: 无法打开文件
OSD-04002: 无法打开文件
O/S-Error: (OS 2) 系统找不到指定的文件。
ORA-01547: 警告: RECOVER 成功但 OPEN RESETLOGS 将出现如下错误
ORA-01194: 文件 1 需要更多的恢复来保持一致性
ORA-01110: 数据文件 1: 'R:\ORADATA\HZYL\SYSTEM01.DBF'

四、启用隐含参数,尝试打开数据库

SQL> create pfile='d:/1.txt' from spfile;
文件已创建。
#############添加隐含参数##################
*._allow_resetlogs_corruption=TRUE
*._allow_error_simulation=TRUE
##########################################
SQL> shutdown immediate
ORA-01109: 数据库未打开
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> startup pfile ='d:\1.txt';
ORACLE 例程已经启动。
Total System Global Area 1581916160 bytes
Fixed Size                  1336060 bytes
Variable Size             964693252 bytes
Database Buffers          603979776 bytes
Redo Buffers               11907072 bytes
数据库装载完毕。
ORA-01589: 要打开数据库则必须使用 RESETLOGS 或 NORESETLOGS 选项
SQL> alter database open resetlogs;
alter database open resetlogs
*
第 1 行出现错误:
ORA-00603: ORACLE 服务器会话因致命错误而终止
进程 ID: 3388
会话 ID: 335 序列号: 5

五、查看alert日志

Wed Dec 07 13:02:49 2011
SMON: enabling cache recovery
Errors in file d:\app\administrator\diag\rdbms\hzyl\hzyl\trace\hzyl_ora_3388.trc  (incident=216664):
ORA-00600: 内部错误代码, 参数: [2662], [2], [1153862134], [2], [1153864845], [12582921], [], []
Incident details in: d:\app\administrator\diag\rdbms\hzyl\hzyl\incident\incdir_216664\hzyl_ora_3388_i216664.trc
Errors in file d:\app\administrator\diag\rdbms\hzyl\hzyl\trace\hzyl_ora_3388.trc:
ORA-00600: 内部错误代码, 参数: [2662], [2], [1153862134], [2], [1153864845], [12582921], [], []
Error 600 happened during db open, shutting down database
USER (ospid: 3388): terminating the instance due to error 600
Wed Dec 07 13:02:50 2011
Errors in file d:\app\administrator\diag\rdbms\hzyl\hzyl\trace\hzyl_mmnl_3884.trc  (incident=216640):
ORA-00600: internal error code, arguments: [], [], [], [], [], [], [], []
Incident details in: d:\app\administrator\diag\rdbms\hzyl\hzyl\incident\incdir_216640\hzyl_mmnl_3884_i216640.trc
Wed Dec 07 13:02:50 2011
Errors in file d:\app\administrator\diag\rdbms\hzyl\hzyl\trace\hzyl_diag_4020.trc  (incident=216552):
ORA-00600: internal error code, arguments: [], [], [], [], [], [], [], []
Incident details in: d:\app\administrator\diag\rdbms\hzyl\hzyl\incident\incdir_216552\hzyl_diag_4020_i216552.trc
Wed Dec 07 13:02:50 2011
Errors in file d:\app\administrator\diag\rdbms\hzyl\hzyl\trace\hzyl_dia0_2896.trc  (incident=216584):
ORA-00600: internal error code, arguments: [], [], [], [], [], [], [], []
Incident details in: d:\app\administrator\diag\rdbms\hzyl\hzyl\incident\incdir_216584\hzyl_dia0_2896_i216584.trc
Wed Dec 07 13:02:51 2011
Errors in file d:\app\administrator\diag\rdbms\hzyl\hzyl\trace\hzyl_pmon_2964.trc  (incident=216536):
ORA-00600: internal error code, arguments: [], [], [], [], [], [], [], []
Incident details in: d:\app\administrator\diag\rdbms\hzyl\hzyl\incident\incdir_216536\hzyl_pmon_2964_i216536.trc
Wed Dec 07 13:02:51 2011
Errors in file d:\app\administrator\diag\rdbms\hzyl\hzyl\trace\hzyl_mmon_3764.trc  (incident=216632):
ORA-00600: internal error code, arguments: [], [], [], [], [], [], [], []
Incident details in: d:\app\administrator\diag\rdbms\hzyl\hzyl\incident\incdir_216632\hzyl_mmon_3764_i216632.trc
Wed Dec 07 13:02:51 2011
Errors in file d:\app\administrator\diag\rdbms\hzyl\hzyl\trace\hzyl_dbrm_2060.trc  (incident=216560):
ORA-00600: internal error code, arguments: [], [], [], [], [], [], [], []
Wed Dec 07 13:02:51 2011
Errors in file d:\app\administrator\diag\rdbms\hzyl\hzyl\trace\hzyl_psp0_1476.trc  (incident=216568):
ORA-00600: internal error code, arguments: [], [], [], [], [], [], [], []
Wed Dec 07 13:02:52 2011
Errors in file d:\app\administrator\diag\rdbms\hzyl\hzyl\trace\hzyl_mman_3040.trc  (incident=216576):
ORA-00600: internal error code, arguments: [], [], [], [], [], [], [], []
Wed Dec 07 13:02:52 2011
Errors in file d:\app\administrator\diag\rdbms\hzyl\hzyl\trace\hzyl_dbw0_2116.trc  (incident=216592):
ORA-00600: internal error code, arguments: [], [], [], [], [], [], [], []
Errors in file d:\app\administrator\diag\rdbms\hzyl\hzyl\trace\hzyl_lgwr_2624.trc  (incident=216600):
ORA-00600: internal error code, arguments: [], [], [], [], [], [], [], []
Errors in file d:\app\administrator\diag\rdbms\hzyl\hzyl\trace\hzyl_smon_592.trc  (incident=216616):
ORA-00600: internal error code, arguments: [], [], [], [], [], [], [], []
Errors in file d:\app\administrator\diag\rdbms\hzyl\hzyl\trace\hzyl_ckpt_3052.trc  (incident=216608):
ORA-00600: internal error code, arguments: [], [], [], [], [], [], [], []
Instance terminated by USER, pid = 3388
ORA-1092 signalled during: alter database open resetlogs...
Errors in file d:\app\administrator\diag\rdbms\hzyl\hzyl\trace\hzyl_ora_3388.trc  (incident=216665):
ORA-00600: 内部错误代码, 参数: [], [], [], [], [], [], [], []
ORA-01092: ORACLE 实例终止。强制断开连接
ORA-00600: 内部错误代码, 参数: [2662], [2], [1153862134], [2], [1153864845], [12582921], [], []
Errors in file d:\app\administrator\diag\rdbms\hzyl\hzyl\trace\hzyl_ora_3388.trc  (incident=216666):
ORA-00600: 内部错误代码, 参数: [], [], [], [], [], [], [], []
ORA-00600: 内部错误代码, 参数: [], [], [], [], [], [], [], []
ORA-01092: ORACLE 实例终止。强制断开连接
ORA-00600: 内部错误代码, 参数: [2662], [2], [1153862134], [2], [1153864845], [12582921], [], []
Errors in file d:\app\administrator\diag\rdbms\hzyl\hzyl\trace\hzyl_ora_3388.trc:
ORA-00600: 内部错误代码, 参数: [], [], [], [], [], [], [], []
ORA-00600: 内部错误代码, 参数: [], [], [], [], [], [], [], []
ORA-01092: ORACLE 实例终止。强制断开连接
ORA-00600: 内部错误代码, 参数: [2662], [2], [1153862134], [2], [1153864845], [12582921], [], []
Wed Dec 07 13:02:53 2011
Errors in file d:\app\administrator\diag\rdbms\hzyl\hzyl\trace\hzyl_ora_3388.trc  (incident=218920):
ORA-00603: ORACLE server session terminated by fatal error
ORA-00600: internal error code, arguments: [], [], [], [], [], [], [], []
ORA-00600: internal error code, arguments: [], [], [], [], [], [], [], []
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00600: internal error code, arguments: [2662], [2], [1153862134], [2], [1153864845], [12582921], [], []
Incident details in: d:\app\administrator\diag\rdbms\hzyl\hzyl\incident\incdir_218920\hzyl_ora_3388_i218920.trc
Errors in file d:\app\administrator\diag\rdbms\hzyl\hzyl\incident\incdir_218920\hzyl_ora_3388_i218920.trc:
ORA-00603: ORACLE server session terminated by fatal error
ORA-00600: internal error code, arguments: [], [], [], [], [], [], [], []
ORA-00600: internal error code, arguments: [], [], [], [], [], [], [], []
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00600: internal error code, arguments: [2662], [2], [1153862134], [2], [1153864845], [12582921], [], []

这里看到熟悉的ora-600 [2662],处理方法增加scn,参考ORA-00600 [2662]

六、增加SCN,打开数据库

SQL> exit
从 Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options 断
开
C:\Documents and Settings\Administrator>sqlplus "/as sysdba"
SQL*Plus: Release 11.1.0.6.0 - Production on 星期三 12月 7 13:04:51 2011
Copyright (c) 1982, 2007, Oracle.  All rights reserved.
已连接到空闲例程。
SQL> startup pfile ='d:\1.txt' mount;
ORACLE 例程已经启动。
Total System Global Area 1581916160 bytes
Fixed Size                  1336060 bytes
Variable Size             964693252 bytes
Database Buffers          603979776 bytes
Redo Buffers               11907072 bytes
数据库装载完毕。
SQL> alter session set events '10015 trace name adjust_scn level 1';
会话已更改。
SQL> alter database open;
数据库已更改。
SQL> select status from v$instance;
STATUS
------------
OPEN

七、启动过程中,alert日志现ORA-00600[2256]

Completed: ALTER DATABASE   MOUNT
Wed Dec 07 13:06:07 2011
alter database open
Beginning crash recovery of 1 threads
 parallel recovery started with 7 processes
Started redo scan
Completed redo scan
 1 redo blocks read, 0 data blocks need recovery
Started redo application at
 Thread 1: logseq 1, block 2, scn 9743796722
Recovery of Online Redo Log: Thread 1 Group 1 Seq 1 Reading mem 0
  Mem# 0: R:\ORADATA\HZYL\REDO01.LOG
Completed redo application
Completed crash recovery at
 Thread 1: logseq 1, block 3, scn 9743816724
 0 data blocks read, 0 data blocks written, 1 redo blocks read
Wed Dec 07 13:06:08 2011
Thread 1 advanced to log sequence 2
Thread 1 opened at log sequence 2
  Current log# 2 seq# 2 mem# 0: R:\ORADATA\HZYL\REDO02.LOG
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Wed Dec 07 13:06:08 2011
SMON: enabling cache recovery
Errors in file d:\app\administrator\diag\rdbms\hzyl\hzyl\trace\hzyl_ora_3096.trc  (incident=219072):
ORA-00600: 内部错误代码, 参数: [2256], [0], [1073741824], [2], [1153882138], [], [], []
Incident details in: d:\app\administrator\diag\rdbms\hzyl\hzyl\incident\incdir_219072\hzyl_ora_3096_i219072.trc
Dictionary check beginning
Dictionary check complete
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Database Characterset is ZHS16GBK
Wed Dec 07 13:06:09 2011
Trace dumping is performing id=[cdmp_20111207130609]
Opening with internal Resource Manager plan
Wed Dec 07 13:06:10 2011
Sweep Incident[219072]: completed
Starting background process FBDA
Starting background process SMCO
Wed Dec 07 13:06:10 2011
FBDA started with pid=26, OS id=2436
Wed Dec 07 13:06:10 2011
SMCO started with pid=27, OS id=2876
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
Wed Dec 07 13:06:11 2011
QMNC started with pid=28, OS id=2812
LOGSTDBY: Validating controlfile with logical metadata
LOGSTDBY: Validation complete
Wed Dec 07 13:06:15 2011
db_recovery_file_dest_size of 10000 MB is 0.00% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
Wed Dec 07 13:06:25 2011
Completed: alter database open

打开过程中,出现ORA-00600[2256],但是数据库还是正常打开,具体原因待研究

使用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