标签云
asm 恢复 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 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)
- 操作系统 (100)
- 数据库 (1,598)
- DB2 (22)
- MySQL (70)
- Oracle (1,463)
- Data Guard (49)
- EXADATA (7)
- GoldenGate (21)
- ORA-xxxxx (158)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (13)
- ORACLE 21C (3)
- Oracle ASM (65)
- Oracle Bug (7)
- Oracle RAC (47)
- Oracle 安全 (6)
- Oracle 开发 (27)
- Oracle 监听 (27)
- Oracle备份恢复 (530)
- Oracle安装升级 (84)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (75)
- PostgreSQL (18)
- PostgreSQL恢复 (6)
- SQL Server (27)
- SQL Server恢复 (8)
- TimesTen (7)
- 达梦数据库 (2)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (36)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (19)
-
最近发表
- PostgreSQL解析wal日志之—walminer
- Oracle 19c/21c最新patch信息-202404
- PostgreSQL恢复系列:pg_filedump批量处理
- PostgreSQL部分主要字典信息
- PostgreSQL恢复系列:pg_filedump恢复字典构造
- PostgreSQL 16 源码安装
- ORA-00742 ORA-00312 恢复
- 数据库open成功后报ORA-00353 ORA-00354错误引起的一系列问题(本质ntfs文件系统异常)
- ORA-600 ktsiseginfo1故障
- ORA-00600: internal error code, arguments: [16703], [1403], [4] 原因
- 最近遇到几起ORA-600 16703故障(tab$被清空),请引起重视
- ORA-600 2662快速恢复之Patch scn工具
- TNS-12518: TNS:listener could not hand off client connection
- ora.storage无法启动报ORA-12514故障处理
- 断电引起文件scn异常数据库恢复
- ORA-16188: LOG_ARCHIVE_CONFIG settings inconsistent with previously started instance
- .[hudsonL@cock.li].mkp勒索加密数据库完美恢复
- 模拟带库实现rman远程备份
- 又一例:ORA-600 kclchkblk_4和2662故障
- Oracle误删除数据文件恢复
月归档:五月 2018
使用_unnest_subquery优化sql
一个复杂的sql查询,使用了大量EXISTS和NOT EXISTS 关联导致sql执行效率低下,这里挑选出来最核心的部分进行演示
SQL> explain plan for select 2 a.aab034, a.aac001 3 from si_dp.ac01_ac02 a 4 where exists (select 1 5 from ic40 6 where aac001 = a.aac001 7 and aae045 <= '201803' 8 and aae120 = '0') 9 and not exists (select 1 10 from ic15 11 where aac001 = a.aac001 12 and aae002 <= '201803') 13 and not EXISTS (select aab001 14 from ab01 15 where aab019 in ('91', '93') 16 AND aab001 = a.aab001) 17 and exists (select 1 18 from ac13 19 where aac001 = a.aac001 20 and aae140 = '11' 21 and aae114 in ('0', '1') 22 and aae002 <= '201803') 23 AND EXISTS (SELECT 1 24 FROM AC13 25 WHERE AAC001 = A.AAC001 26 and aae140 = '11' 27 AND AAE143 = '02' 28 AND AAE003 < '201707' 29 AND AAE002 BETWEEN '201801' AND '201803' 30 and aae114 = '1') 31 AND not EXISTS (SELECT 1 32 FROM AC13 33 WHERE AAC001 = A.AAC001 34 and aae140 = '11' 35 AND AAE002 < '201801') 36 AND not EXISTS (SELECT 1 37 FROM ac02 38 WHERE AAC001 = A.AAC001 39 and aae140 = '11' 40 AND AAE036 < date '2018-1-1'); Explained. Elapsed: 00:00:00.36 SQL> select * from table (dbms_xplan.display); PLAN_TABLE_OUTPUT -------------------------------------------------------------------------------------------------------- ----------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| ----------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 202 | | 11172 (2)| | 1 | NESTED LOOPS SEMI | | 1 | 202 | | 11172 (2)| | 2 | NESTED LOOPS ANTI | | 1 | 175 | | 11168 (2)| | 3 | NESTED LOOPS SEMI | | 1 | 150 | | 11164 (2)| | 4 | NESTED LOOPS ANTI | | 1 | 126 | | 11160 (2)| | 5 | NESTED LOOPS SEMI | | 1 | 104 | | 11158 (2)| | 6 | NESTED LOOPS ANTI | | 1 | 67 | | 11145 (2)| | 7 | HASH JOIN ANTI | | 1 | 50 | 8640K| 11143 (2)| | 8 | TABLE ACCESS FULL | AC01_AC02 | 245K| 5755K| | 356 (2)| | 9 | TABLE ACCESS FULL | AC02 | 559K| 13M| | 9346 (2)| | 10 | TABLE ACCESS BY INDEX ROWID| AB01 | 2 | 34 | | 2 (0)| | 11 | INDEX UNIQUE SCAN | PK_AB01 | 1 | | | 1 (0)| | 12 | TABLE ACCESS BY INDEX ROWID | AC13 | 325K| 11M| | 13 (0)| | 13 | INDEX RANGE SCAN | I_AC13_AAE143 | 446 | | | 4 (0)| | 14 | INDEX RANGE SCAN | PK_IC15 | 1771K| 37M| | 2 (0)| | 15 | TABLE ACCESS BY INDEX ROWID | IC40 | 17M| 395M| | 4 (0)| | 16 | INDEX RANGE SCAN | PK_IC40 | 1 | | | 3 (0)| | 17 | TABLE ACCESS BY INDEX ROWID | AC13 | 51M| 1236M| | 4 (0)| | 18 | INDEX RANGE SCAN | RELATION_233112_FK | 3 | | | 3 (0)| | 19 | TABLE ACCESS BY INDEX ROWID | AC13 | 52M| 1350M| | 4 (0)| | 20 | INDEX RANGE SCAN | RELATION_233112_FK | 3 | | | 3 (0)| -----------------------------------------------------------------------------------------------------
这条sql,在一个10.2.0.3的系统中执行了十几个小时无法出结果,开发商反馈,该大部分客户的11.2的环境中,大概十几分钟出结果.从来没有遇到此类情况.让我们给他优化sql.看到这个sql,第一反应就是很可能大量的NESTED LOOPS效率低下,怀疑统计信息错误,结果收集完统计信息之后,执行计划依旧,我就在思考怎么调整sql,让其不这样大量嵌套执行.想起来的_unnest_subquery是控制子查询嵌套转换的,从9i开始默认为true,尝试设置为false测试.
SQL> alter session set "_unnest_subquery"=false; Session altered. Elapsed: 00:00:00.00 SQL> explain plan for select 2 a.aab034, a.aac001 3 from si_dp.ac01_ac02 a 4 where exists (select 1 5 from ic40 6 where aac001 = a.aac001 7 and aae045 <= '201803' 8 and aae120 = '0') 9 and not exists (select 1 10 from ic15 11 where aac001 = a.aac001 12 and aae002 <= '201803') 13 and not EXISTS (select aab001 14 from ab01 15 where aab019 in ('91', '93') 16 AND aab001 = a.aab001) 17 and exists (select 1 18 from ac13 19 where aac001 = a.aac001 20 and aae140 = '11' 21 and aae114 in ('0', '1') 22 and aae002 <= '201803') 23 AND EXISTS (SELECT 1 24 FROM AC13 25 WHERE AAC001 = A.AAC001 26 and aae140 = '11' 27 AND AAE143 = '02' 28 AND AAE003 < '201707' 29 AND AAE002 BETWEEN '201801' AND '201803' 30 and aae114 = '1') 31 AND not EXISTS (SELECT 1 32 FROM AC13 33 WHERE AAC001 = A.AAC001 34 and aae140 = '11' 35 AND AAE002 < '201801') 36 AND not EXISTS (SELECT 1 37 FROM ac02 38 WHERE AAC001 = A.AAC001 39 and aae140 = '11' 40 AND AAE036 < date '2018-1-1'); Explained. Elapsed: 00:00:00.07 SQL> select * from table (dbms_xplan.display); PLAN_TABLE_OUTPUT ----------------------------------------------------------------------------------------------- ----------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| ----------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 185K| 19M| | 2991K (2)| | 1 | FILTER | | | | | | | 2 | HASH JOIN RIGHT SEMI | | 185K| 19M| 16M| 758K (3)| | 3 | TABLE ACCESS BY INDEX ROWID| AC13 | 353K| 12M| | 4556 (1)| | 4 | INDEX SKIP SCAN | I_AC13_AAB001 | 23608 | | | 2287 (1)| | 5 | HASH JOIN SEMI | | 201K| 14M| 11M| 751K (3)| | 6 | HASH JOIN SEMI | | 201K| 9452K| 8640K| 123K (3)| | 7 | TABLE ACCESS FULL | AC01_AC02 | 245K| 5755K| | 357 (2)| | 8 | TABLE ACCESS FULL | IC40 | 21M| 481M| | 86122 (3)| | 9 | TABLE ACCESS FULL | AC13 | 52M| 1350M| | 530K (3)| | 10 | INDEX RANGE SCAN | PK_IC15 | 2 | 44 | | 3 (0)| | 11 | VIEW | index$_join$_009 | 1 | 17 | | 3 (34)| | 12 | HASH JOIN | | | | | | | 13 | INDEX RANGE SCAN | PK_AB01 | 1 | 17 | | 2 (0)| | 14 | INLIST ITERATOR | | | | | | | 15 | INDEX RANGE SCAN | IDX_AB01_AAB019 | 1 | 17 | | 8 (0)| | 16 | TABLE ACCESS BY INDEX ROWID | AC13 | 2 | 50 | | 5 (0)| | 17 | INDEX RANGE SCAN | I_AC13_SEARCH | 152 | | | 4 (0)| | 18 | TABLE ACCESS BY INDEX ROWID | AC02 | 1 | 26 | | 4 (0)| | 19 | INDEX RANGE SCAN | PK_AC02 | 1 | | | 3 (0)| -----------------------------------------------------------------------------------------------
让开发设置该参数,然后执行sql,结果3分钟不到出结果,非常圆满完成任务.该sql还有进一步优化空间,但是考虑到已经满足要求,不再折腾.
ORA-19821故障分析
数据库报错
数据库启动报ORA-00283和ORA-19821错
SQL> recover database; ORA-00283: recovery session canceled due to errors ORA-19821: an intentionally corrupt log file was found SQL> recover datafile 1; ORA-00283: recovery session canceled due to errors ORA-19821: an intentionally corrupt log file was found
Thu May 03 12:06:51 2018 Recovery of Online Redo Log: Thread 1 Group 1 Seq 1 Reading mem 0 Mem# 0: D:\APP\SOHTDB\ORADATA\xifenfei\REDO01.LOG Media Recovery failed with error 19821 Errors in file d:\app\sohtdb\diag\rdbms\xifenfei\xifenfei\trace\xifenfei_pr00_660.trc: ORA-00283: recovery session canceled due to errors ORA-19821: an intentionally corrupt log file was found Slave exiting with ORA-283 exception Errors in file d:\app\sohtdb\diag\rdbms\xifenfei\xifenfei\trace\xifenfei_pr00_660.trc: ORA-00283: recovery session canceled due to errors ORA-19821: an intentionally corrupt log file was found ORA-283 signalled during: ALTER DATABASE RECOVER database ...
ORA-19821报错原因
这个错误相对比较少见,查询mos,由于设置了_disable_logging = TRUE导致该问题
检查alert日志,_disable_logging参数确实被认为设置为true了.
解决方法
根据官方的描述,这样的情况无法常规恢复,但是我们知道设置这个参数是为了不产生日志,因此出现这种情况,只能通过隐含参数,禁止数据库进行实例恢复,强制打开数据库.在这样的过程中非常容易遭遇类似ORA-600 2662的错误.
设置这个参数是为了不产生日志,当数据库非干净关闭(主机断电,数据库crash,shutdown abort等),就非常可能导致数据库无法正常启动.***千不可万不能在生产环境中设置_disable_logging = TRUE***
参考文档:Ora-19821 during the recovery (Doc ID 1217143.1)
Init.ora Parameter “_DISABLE_LOGGING” [Hidden] Reference Note (Doc ID 29552.1)
Oracle 数据文件大小为0kb或者文件丢失恢复
接到一个朋友恢复请求,由于rose频繁切换导致文件系统部分数据文件变化为0kb和文件丢失.
故障现象
部分数据文件变化为0kb和文件丢失.
这里比较明显,数据库的users03变为了0kb和users04丢失.数据库alert日志报错信息如下:
Completed: alter database mount exclusive alter database open Errors in file E:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\trace\orcl_dbw0_12008.trc: ORA-01157: ????/?????? 7 - ??? DBWR ???? ORA-01110: ???? 7: 'E:\APP\ADMINISTRATOR\ORADATA\ORCL\USERS03.DBF' ORA-27047: ?????????? OSD-04006: ReadFile() 失败, 无法读取文件 O/S-Error: (OS 38) 已到文件结尾。 Errors in file E:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\trace\orcl_dbw0_12008.trc: ORA-01157: ????/?????? 8 - ??? DBWR ???? ORA-01110: ???? 8: 'E:\APP\ADMINISTRATOR\ORADATA\ORCL\USERS04.DBF' ORA-27041: ?????? OSD-04002: 无法打开文件 O/S-Error: (OS 2) 系统找不到指定的文件。 Errors in file E:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\trace\orcl_ora_12040.trc: ORA-01157: ????/?????? 7 - ??? DBWR ???? ORA-01110: ???? 7: 'E:\APP\ADMINISTRATOR\ORADATA\ORCL\USERS03.DBF' ORA-1157 signalled during: alter database open... Fri May 04 09:35:10 2018 Checker run found 2 new persistent data failures
alert日志的报错也比较明显,users03是文件超过了大小(大小为0kb,读取之后肯定超过大小),users04提示无法打开文件(文件在文件系统层面已经丢失).现在问题比较明显由于文件系统故障导致文件大小为0和丢失
碎片扫描恢复
常规的方法肯定无法恢复,比较好的方法只能是底层碎片扫描重组,结合多种扫描工具,最后发现一个做底层恢复的朋友的工具效果不错,扫描结果如下
通过工具分析坏块情况
C:\Users\Administrator>dbv FiLe=D:\0504\ORCL_TS.4_FILE.7_10.ora DBVERIFY: Release 11.2.0.4.0 - Production on 星期六 5月 5 08:52:53 2018 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. DBVERIFY - 开始验证: FILE = D:\0504\ORCL_TS.4_FILE.7_10.ora ……………… 页 382565 标记为损坏 Corrupt block relative dba: 0x01c5d665 (file 7, block 382565) Completely zero block found during dbv: 页 382566 标记为损坏 Corrupt block relative dba: 0x01c5d666 (file 7, block 382566) Completely zero block found during dbv: 页 382567 标记为损坏 Corrupt block relative dba: 0x01c5d667 (file 7, block 382567) Completely zero block found during dbv: DBVERIFY - 验证完成 检查的页总数: 1374720 处理的页总数 (数据): 27582 失败的页总数 (数据): 0 处理的页总数 (索引): 20114 失败的页总数 (索引): 0 处理的页总数 (其他): 1319752 处理的总页数 (段) : 0 失败的总页数 (段) : 0 空的页总数: 1 标记为损坏的总页数: 7271 流入的页总数: 0 加密的总页数 : 0 最高块 SCN : 228271996 (0.228271996) C:\Users\Administrator>dbv FiLe=D:\0504\ORCL_TS.4_FILE.8_8.ora DBVERIFY: Release 11.2.0.4.0 - Production on 星期六 5月 5 08:52:53 2018 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. DBVERIFY - 开始验证: FILE = D:\0504\ORCL_TS.4_FILE.8_8.ora DBVERIFY - 验证完成 检查的页总数: 1136896 处理的页总数 (数据): 36639 失败的页总数 (数据): 0 处理的页总数 (索引): 57038 失败的页总数 (索引): 0 处理的页总数 (其他): 1043218 处理的总页数 (段) : 0 失败的总页数 (段) : 0 空的页总数: 1 标记为损坏的总页数: 0 流入的页总数: 0 加密的总页数 : 0 最高块 SCN : 228271997 (0.228271997) C:\Users\Administrator>
这里通过分析恢复的两个文件总的block数量2511618,其中连续损坏7271个block损坏,由于出现问题之后,数据库被offline这两个文件继续启动运行了几个小时,导致少量block被覆盖,恢复软件直接置空.后续的恢复比较顺利,正常open数据库,然后处理坏块对象(正好不是业务核心表的lob字段,所有部分丢失影响不是非常大).
温馨提醒:
1. 数据文件和备份不要放在同一个阵列上,更不能是同一个分区(卷)上
2. 出现此类问题之后,应当理解停止对该分区的任何写操作,方式丢失或者大小为0KB的文件被覆盖.
如果需要专业ORACLE数据库恢复技术支持,请联系我们
Phone:17813235971 Q Q:107644445 E-Mail:dba@xifenfei.com
发表在 非常规恢复
标签为 dbf 0kb, dbf 0字节, O/S-Error: (OS 2), O/S-Error: (OS 38), oracle 0kb, oracle 0字节, 文件丢失恢复, 文件大小为0, 碎片扫描, 碎片重组
评论关闭