标签云
asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 kfed MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-01110 ORA-01555 ORA-01578 ORA-08103 ORA-600 2131 ORA-600 2662 ORA-600 2663 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 Oracle 恢复 ORACLE恢复 ORACLE数据库恢复 oracle 比特币 OSD-04016 YOUR FILES ARE ENCRYPTED 勒索恢复 比特币加密文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (102)
- 数据库 (1,682)
- DB2 (22)
- MySQL (73)
- Oracle (1,544)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (159)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (7)
- Oracle ASM (67)
- Oracle Bug (8)
- Oracle RAC (53)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (28)
- Oracle备份恢复 (565)
- Oracle安装升级 (92)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (79)
- PostgreSQL (18)
- PostgreSQL恢复 (6)
- SQL Server (27)
- SQL Server恢复 (8)
- TimesTen (7)
- 达梦数据库 (2)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (37)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (20)
-
最近发表
- 断电引起的ORA-08102: 未找到索引关键字, 对象号 39故障处理
- ORA-00227: corrupt block detected in control file
- 手工删除19c rac
- 解决oracle数据文件路径有回车故障
- .wstop扩展名勒索数据库恢复
- Oracle Recovery Tools工具一键解决ORA-00376 ORA-01110故障(文件offline)
- OGG-02771 Input trail file format RELEASE 19.1 is different from previous trail file form at RELEASE 11.2.
- OGG-02246 Source redo compatibility level 19.0.0 requires trail FORMAT 12.2 or higher
- GoldenGate 19安装和打patch
- dd破坏asm磁盘头恢复
- 删除asmlib磁盘导致磁盘组故障恢复
- Kylin Linux 安装19c
- ORA-600 krse_arc_complete.4
- Oracle 19c 202410补丁(RUs+OJVM)
- ntfs MFT损坏(ntfs文件系统故障)导致oracle异常恢复
- .mkp扩展名oracle数据文件加密恢复
- 清空redo,导致ORA-27048: skgfifi: file header information is invalid
- A_H_README_TO_RECOVER勒索恢复
- 通过alert日志分析客户自行对一个数据库恢复的来龙去脉和点评
- ORA-12514: TNS: 监听进程不能解析在连接描述符中给出的SERVICE_NAME
标签归档:kewrose_1
aix平台tab$被删除可能出现ORA-600 [16703], [1403], [28]错误
以前在恢复过程中遇到过ORA-00600: internal error code, arguments: [16703], [1403], [28]错误(10g数据库遭遇ORA-600 16703)以为是因为10g版本的tab$记录被删除的原因导致报错和最常见的ORA-00600: internal error code, arguments: [16703], [1403], [20]不完全一致(警告:互联网中有oracle介质被注入恶意程序导致—ORA-600 16703),最近又遇到一个ORA-600 16703 1403 28错误的case,而且数据库版本是11.2.0.4 for aix平台,进一步说明该问题不是由于10g和11g的tab$被删除的区别导致,更多可能是由于操作系统不一样,数据库启动基表访问顺序不一致导致,特此进行说明.
数据库启动成功后报错
Wed Apr 01 22:36:19 2020 Completed: ALTER DATABASE OPEN /* db agent *//* {2:54387:2} */ Wed Apr 01 22:36:19 2020 Starting background process CJQ0 Wed Apr 01 22:36:19 2020 CJQ0 started with pid=53, OS id=7078224 Wed Apr 01 22:36:21 2020 Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl2/trace/orcl2_ora_7668220.trc (incident=40337): ORA-00600: internal error code, arguments: [kzrini:!uprofile], [], [], [], [], [], [], [], [], [], [], [] Incident details in: /u01/app/oracle/diag/rdbms/orcl/orcl2/incident/incdir_40337/orcl2_ora_7668220_i40337.trc Wed Apr 01 22:36:21 2020 Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl2/trace/orcl2_ora_6881718.trc (incident=40369): ORA-00600: internal error code, arguments: [kzrini:!uprofile], [], [], [], [], [], [], [], [], [], [], [] Incident details in: /u01/app/oracle/diag/rdbms/orcl/orcl2/incident/incdir_40369/orcl2_ora_6881718_i40369.trc Setting Resource Manager plan SCHEDULER[0x32DB]:DEFAULT_MAINTENANCE_PLAN via scheduler window Setting Resource Manager plan DEFAULT_MAINTENANCE_PLAN via parameter Wed Apr 01 22:51:16 2020 Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl2/trace/orcl2_smon_7078802.trc: ORA-00604: error occurred at recursive SQL level 1 ORA-00957: duplicate column name Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl2/trace/orcl2_smon_7078802.trc: ORA-00604: error occurred at recursive SQL level 1 ORA-00957: duplicate column name Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl2/trace/orcl2_smon_7078802.trc: ORA-00604: error occurred at recursive SQL level 1 ORA-00957: duplicate column name Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl2/trace/orcl2_m000_4850312.trc (incident=48045): ORA-00600: internal error code, arguments: [kdfReserveSingle_1], [0], [65280], [], [], [], [], [], [], [], [], [] Incident details in: /u01/app/oracle/diag/rdbms/orcl/orcl2/incident/incdir_48045/orcl2_m000_4850312_i48045.trc Thu Apr 02 00:59:35 2020 Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl2/trace/orcl2_smon_7078802.trc: ORA-00604: error occurred at recursive SQL level 1 ORA-00957: duplicate column name Thu Apr 02 00:59:36 2020 DDE: Problem Key 'ORA 600 [kzrini:!uprofile]' was completely flood controlled (0x6) Further messages for this problem key will be suppressed for up to 10 minutes Thu Apr 02 00:59:37 2020 Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl2/trace/orcl2_m000_4850312.trc (incident=48046): ORA-00600: internal error code, arguments: [kewrose_1], [600], [ORA-00600: internal error code, arguments: [kdfReserveSingle_1], [0], [65280], [], [], [], []
数据库再次重启报错
Completed: ALTER DATABASE MOUNT /* db agent *//* {1:25340:2} */ ALTER DATABASE OPEN /* db agent *//* {1:25340:2} */ This instance was first to open Picked broadcast on commit scheme to generate SCNs Thu Apr 02 02:17:59 2020 Thread 2 opened at log sequence 13485 Current log# 3 seq# 13485 mem# 0: +DATA/orcl/onlinelog/group_3.265.1003137665 Current log# 3 seq# 13485 mem# 1: +FLASH/orcl/onlinelog/group_3.259.1003137677 Successful open of redo thread 2 MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set Thu Apr 02 02:17:59 2020 SMON: enabling cache recovery Instance recovery: looking for dead threads Instance recovery: lock domain invalid but no dead threads Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl2/trace/orcl2_ora_7799020.trc (incident=48395): ORA-00600: internal error code, arguments: [16703], [1403], [28], [], [], [], [], [], [], [], [], [] Incident details in: /u01/app/oracle/diag/rdbms/orcl/orcl2/incident/incdir_48395/orcl2_ora_7799020_i48395.trc Thu Apr 02 02:18:01 2020 Thu Apr 02 02:18:01 2020 Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl2/trace/orcl2_ora_7799020.trc: ORA-00704: bootstrap process failure ORA-00704: bootstrap process failure ORA-00600: internal error code, arguments: [16703], [1403], [28], [], [], [], [], [], [], [], [], [] Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl2/trace/orcl2_ora_7799020.trc: ORA-00704: bootstrap process failure ORA-00704: bootstrap process failure ORA-00600: internal error code, arguments: [16703], [1403], [28], [], [], [], [], [], [], [], [], [] Error 704 happened during db open, shutting down database USER (ospid: 7799020): terminating the instance due to error 704 Instance terminated by USER, pid = 7799020 ORA-1092 signalled during: ALTER DATABASE OPEN /* db agent *//* {1:25340:2} */...
对于此类问题,通过分析,确定也是由于DBMS_SUPPORT_DBMONITORP恶意脚本导致tab$记录被删除,导致数据库启动异常,处理方法基本上就是对tab$进行恢复,然后open数据库.
ORACLE异常恢复后awr异常处理
有一个通过非常规方法恢复过的客户数据库出现问题awr无法收集统计信息(几个月前非常规方法恢复的库,因为未重建库),不太方便跟踪数据库性能,让其帮忙分析跟踪问题.
人工收集统计信息报错RA-00001: 违反唯一约束条件 (SYS.WRM$_SNAPSHOT_PK)
SQL> execute dbms_workload_repository.create_snapshot(); BEGIN dbms_workload_repository.create_snapshot(); END; * 第 1 行出现错误: ORA-13509: 更新 AWR 表时出错 ORA-00001: 违反唯一约束条件 (ORA-00001: 违反唯一约束条件 (SYS.WRM$_SNAPSHOT_PK) .) ORA-06512: 在 "SYS.DBMS_WORKLOAD_REPOSITORY", line 99 ORA-06512: 在 "SYS.DBMS_WORKLOAD_REPOSITORY", line 122 ORA-06512: 在 line 1
通过分析trace文件问题如下
Trace file D:\APP\ADMINISTRATOR\diag\rdbms\rac\rac2\trace\rac2_m000_1628.trc Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production With the Partitioning, Real Application Clusters, Automatic Storage Management, Oracle Label Security, OLAP, Data Mining, Oracle Database Vault and Real Application Testing option Windows NT Version V6.1 Service Pack 1 CPU : 32 - type 8664, 32 Physical Cores Process Affinity : 0x0x0000000000000000 Memory (Avail/Total): Ph:83326M/131035M, Ph+PgF:214386M/262068M Instance name: rac2 Redo thread mounted by this instance: 2 Oracle process number: 61 Windows thread id: 1628, image: ORACLE.EXE (M000) *** 2015-08-28 11:39:51.967 *** SESSION ID:(2062.93) 2015-08-28 11:39:51.968 *** CLIENT ID:() 2015-08-28 11:39:51.968 *** SERVICE NAME:(SYS$BACKGROUND) 2015-08-28 11:39:51.968 *** MODULE NAME:(MMON_SLAVE) 2015-08-28 11:39:51.968 *** ACTION NAME:(Auto-Flush Slave Action) 2015-08-28 11:39:51.968 *** KEWROCISTMTEXEC - encountered error: (ORA-00001: 违反唯一约束条件 (SYS.WRM$_SNAPSHOT_PK) ) *** SQLSTR: total-len=342, dump-len=240, STR={insert into WRM$_SNAPSHOT (snap_id, dbid, instance_number, startup_time,begin_interval_time, end_interval_time, snap_level, status, error_count, bl_moved, snap_flag, snap_timezone) values (:snap_id, :dbid, :instance_number, :sta} *** KEWRAFS: Error=13509 encountered by Auto Flush Slave.
这里可以明确的定位到,由于insert WRM$_SNAPSHOT表之时出现主键冲突导致无法收集统计信息.因为awr的数据都是历史数据,可以全部清理,因此尝试删除掉awr相关数据看是否能够解决问题
对收集快照做10046 跟踪发现
SQL> oradebug setmypid 已处理的语句 SQL> alter session set events '10046 trace name context forever, level 12'; 会话已更改。 SQL> oradebug tracefile_name D:\APP\ADMINISTRATOR\diag\rdbms\rac\rac2\trace\rac2_ora_5944.trc SQL> execute dbms_workload_repository.create_snapshot(); BEGIN dbms_workload_repository.create_snapshot(); END; * 第 1 行出现错误: ORA-13509: 更新 AWR 表时出错 ORA-00001: 违反唯一约束条件 (ORA-00001: 违反唯一约束条件 (SYS.WRM$_SNAPSHOT_PK) .) ORA-06512: 在 "SYS.DBMS_WORKLOAD_REPOSITORY", line 99 ORA-06512: 在 "SYS.DBMS_WORKLOAD_REPOSITORY", line 122 ORA-06512: 在 line 1 --trace文件分析 PARSING IN CURSOR #1362260992 lid=0 tim=22781405124 hv=438921370 ad='148fd90590' sqlid='15rbgh4d2ku4u' insert into WRM$_SNAPSHOT(snap_id, dbid, instance_number, startup_time,begin_interval_time, end_interval_time, snap_level,status, error_count, bl_moved,snap_flag, snap_timezone)values(:snap_id, :dbid, :instance_number, :startup_time, :begin_interval_time, :end_interval_time, :snap_level, :status, 0, 0, :bind1, :bind2) END OF STMT PARSE #1362260992:c=0,e=474,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=1,plh=0,tim=22781405122 BINDS #1362260992: Bind#0 oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00 oacflg=00 fl2=0000 frm=00 csi=00 siz=208 off=0 kxsbbbfp=513a6bf8 bln=22 avl=03 flg=05 value=9277 Bind#1 oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00 oacflg=00 fl2=0000 frm=00 csi=00 siz=0 off=24 kxsbbbfp=513a6c10 bln=22 avl=06 flg=01 value=2429481020 Bind#2 oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00 oacflg=00 fl2=0000 frm=00 csi=00 siz=0 off=48 kxsbbbfp=513a6c28 bln=22 avl=02 flg=01 value=2 Bind#3 oacdty=180 mxl=11(11) mxlc=00 mal=00 scl=09 pre=00 oacflg=00 fl2=8000000 frm=00 csi=00 siz=0 off=72 kxsbbbfp=513a6c40 bln=11 avl=07 flg=01 value=28-8月 -15 10.06.53 上午 Bind#4 oacdty=180 mxl=11(11) mxlc=00 mal=00 scl=09 pre=00 oacflg=00 fl2=8000000 frm=00 csi=00 siz=0 off=88 kxsbbbfp=513a6c50 bln=11 avl=07 flg=01 value=28-8月 -15 10.06.53 上午 Bind#5 oacdty=180 mxl=11(11) mxlc=00 mal=00 scl=09 pre=00 oacflg=00 fl2=8000000 frm=00 csi=00 siz=0 off=104 kxsbbbfp=513a6c60 bln=11 avl=11 flg=01 value=28-8月 -15 04.11.40.017000000 下午 Bind#6 oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00 oacflg=00 fl2=0000 frm=00 csi=00 siz=0 off=120 kxsbbbfp=513a6c70 bln=22 avl=02 flg=01 value=1 Bind#7 oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00 oacflg=00 fl2=0000 frm=00 csi=00 siz=0 off=144 kxsbbbfp=513a6c88 bln=22 avl=02 flg=01 value=1 Bind#8 oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00 oacflg=00 fl2=0000 frm=00 csi=00 siz=0 off=168 kxsbbbfp=513a6ca0 bln=22 avl=02 flg=01 value=1 Bind#9 oacdty=183 mxl=11(11) mxlc=00 mal=00 scl=09 pre=09 oacflg=01 fl2=8000000 frm=00 csi=00 siz=0 off=192 kxsbbbfp=513a6cb8 bln=11 avl=11 flg=01 value=Unhandled datatype (183) found in kxsbndinf
这里可以明确定位到,awr在收集信息的时候就是插入的值和库中本身存在的记录冲突,从而出现此类问题
清理awr数据
SQL> select max(snap_id),min(snap_id) from WRM$_SNAPSHOT; MAX(SNAP_ID) MIN(SNAP_ID) ------------ ------------ 9277 9081 SQL> exec DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE(9081,9277); PL/SQL 过程已成功完成。 SQL> SQL> select max(snap_id),min(snap_id) from WRM$_SNAPSHOT; MAX(SNAP_ID) MIN(SNAP_ID) ------------ ------------ 9277 9277 SQL> exec DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE(9080,9278); PL/SQL 过程已成功完成。 SQL> select max(snap_id),min(snap_id) from WRM$_SNAPSHOT; MAX(SNAP_ID) MIN(SNAP_ID) ------------ ------------ 9277 9277 SQL> delete from WRM$_SNAPSHOT where snap_id=9277; delete from WRM$_SNAPSHOT where snap_id=9277 * 第 1 行出现错误: ORA-00600: 内部错误代码, 参数: [13011], [6653], [8456911], [2], [8456911], [3], [], [], [], [], [], [] SQL> delete /*+ RULE */ from WRM$_SNAPSHOT where snap_id=9277; 已删除0行。
这里有几分诡异,snap_id=9277的记录无法清理,而且正常删除报ORA-00600[13011].根据经验,出现该问题,很可能是由于表和index的记录问题
尝试rebuild index
SQL> analyze table WRM$_SNAPSHOT validate structure cascade; analyze table WRM$_SNAPSHOT validate structure cascade * 第 1 行出现错误: ORA-01499: 表/索引交叉引用失败 - 请参阅跟踪文件 SQL> select index_name from dba_indexes where table_name='WRM$_SNAPSHOT'; INDEX_NAME ------------------------------ WRM$_SNAPSHOT_PK SQL> alter index WRM$_SNAPSHOT_PK rebuild; 索引已更改。 SQL> select /*+ full(t) */ max(snap_id),min(snap_id) from WRM$_SNAPSHOT t; MAX(SNAP_ID) MIN(SNAP_ID) ------------ ------------ SQL> select max(snap_id),min(snap_id) from WRM$_SNAPSHOT; MAX(SNAP_ID) MIN(SNAP_ID) ------------ ------------ 9277 9277
这里很明确的定位了,由于表和index的记录不一致,而且通过rebuild,发现index依旧有问题
重建index
SQL> set linesize 180 SQL> set pages 999 SQL> set long 90000 SQL> select dbms_metadata.get_ddl('INDEX','WRM$_SNAPSHOT_PK','SYS') from dual; DBMS_METADATA.GET_DDL('INDEX','WRM$_SNAPSHOT_PK','SYS') -------------------------------------------------------------------------------- CREATE UNIQUE INDEX "SYS"."WRM$_SNAPSHOT_PK" ON "SYS"."WRM$_SNAPSHOT" ("DBID", "SNAP_ID", "INSTANCE_NUMBER") PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT) TABLESPACE "SYSAUX" SQL> DROP INDEX "SYS"."WRM$_SNAPSHOT_PK" ; DROP INDEX "SYS"."WRM$_SNAPSHOT_PK" * 第 1 行出现错误: ORA-02429: 无法删除用于强制唯一/主键的索引 SQL> alter table "SYS"."WRM$_SNAPSHOT" drop constraint "SYS"."WRM$_SNAPSHOT_PK"; alter table "SYS"."WRM$_SNAPSHOT" drop constraint "SYS"."WRM$_SNAPSHOT_PK" * 第 1 行出现错误: ORA-01735: 无效的 ALTER TABLE 选项 SQL> alter table "WRM$_SNAPSHOT" drop constraint "WRM$_SNAPSHOT_PK"; 表已更改。 SQL>alter table "WRM$_SNAPSHOT" add constraint "WRM$_SNAPSHOT_PK" primary key("DBID", "SNAP_ID", "INSTANCE_NUMBER"); 表已更改。
再次尝试做快照
SQL> execute dbms_workload_repository.create_snapshot(); BEGIN dbms_workload_repository.create_snapshot(); END; * 第 1 行出现错误: ORA-00600: 内部错误代码, 参数: [kewrose_1], [600], [ORA-00600: 内部错误代码, 参数: [6002], [6], [104], [4], [0], [], [], [], [], [], [], [], [], [], [], [], [], [], [], [], [] ORA-06512: 在 "SYS.DBMS_WORKLOAD_REPOSITORY", line 99 ORA-06512: 在 "SYS.DBMS_WORKLOAD_REPOSITORY", line 122 ORA-06512: 在 line 1
悲剧再次发生,收集快照之时遭遇悲催的ORA-00600[kewrose_1]/ORA-600[6002]的错误.范围awr的以前数据都不要了,也就采用最极端的处理方法,定位到表,然后处理之
继续10046跟踪
PARSING IN CURSOR #1495840456 tim=24328721585 hv=4050667988 ad='146f9948f8'sqlid='84qubbrsr0kfn' insert into wrh$_latch(snap_id, dbid, instance_number, latch_hash, level#, gets, misses, sleeps, immediate_gets,immediate_misses, spin_gets, sleep1, sleep2, sleep3, sleep4, wait_time) select :snap_id, :dbid, :instance_number, hash, level#, gets, misses, sleeps, immediate_gets, immediate_misses, spin_gets, sleep1, sleep2, sleep3, sleep4, wait_time from v$latch order by hash END OF STMT PARSE #1495840456:c=0,e=376,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=1,plh=0,tim=24328721584 BINDS #1495840456: Bind#0 oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00 oacflg=00 fl2=0000 frm=00 csi=00 siz=72 off=0 kxsbbbfp=60471350 bln=22 avl=03 flg=05 value=9280 Bind#1 oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00 oacflg=00 fl2=0000 frm=00 csi=00 siz=0 off=24 kxsbbbfp=60471368 bln=22 avl=06 flg=01 value=2429481020 Bind#2 oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00 oacflg=00 fl2=0000 frm=00 csi=00 siz=0 off=48 kxsbbbfp=60471380 bln=22 avl=02 flg=01 value=2 ORA-00600: 内部错误代码, 参数: [6002], [6], [104], [4], [0], [], [], [], [], [], [], []
通过这里可以定位到问题是发生在wrh$_latch表的insert操作之上
分析并truncate table
SQL> SELECT COUNT(*) FROM wrh$_latch; COUNT(*) -------- 0 SQL> truncate table wrh$_latch; 表被截断
再次收集快照信息
SQL> execute dbms_workload_repository.create_snapshot(); PL/SQL 过程已成功完成。 SQL> @?/rdbms/admin/awrrpt.sql --工作正常
经过一些列处理,终于让awr能够正常工作了,特别是在做过异常恢复之后,awr数据可能有各种问题导致工作不正常,可以考虑重建awr,也可以考虑类似我这样彻底清理awr数据,然后放手处理.当然对于使用非常规方法恢复的Oracle数据库,在条件允许的情况下,建议逻辑方式重建库.因为有数据字典不一致,有逻辑坏块,有表和index不一致等问题,在后续的使用中逐渐被显露出来,从而导致很多麻烦,重建库彻彻底底解决问题.