标签云
asm恢复 bbed bootstrap$ dul kcbzib_kcrsds_1 kccpb_sanity_check_2 kcratr_nab_less_than_odr MySQL恢复 obet ORA-00312 ORA-00704 ORA-00742 ORA-01110 ORA-01200 ORA-01555 ORA-01578 ORA-01595 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-600 kcratr_nab_less_than_odr 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 比特币加密文章分类
- MongoDB (1)
- MongoDB恢复 (1)
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (112)
- 数据库 (1,879)
- DB2 (22)
- MySQL (82)
- Oracle (1,705)
- Data Guard (53)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (168)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (72)
- Oracle Bug (8)
- Oracle RAC (56)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (29)
- Oracle备份恢复 (659)
- Oracle安装升级 (108)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (91)
- PostgreSQL (37)
- pdu工具 (7)
- PostgreSQL恢复 (13)
- SQL Server (34)
- SQL Server恢复 (14)
- TimesTen (7)
- 达梦数据库 (5)
- 达梦恢复 (3)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (51)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (34)
- MongoDB (1)
-
最近发表
- Oracle 19c 202610补丁(RUs+OJVM)-19.33
- 由于con$.con#值达到极限,触发数据库增加约束报ORA-600 12807错误
- MongoDB 离线提取工具—mongoext
- .bres勒索病毒加密数据库dmp文件可恢复
- ORA-600 krsm_mrp_rebuild_lf_list.lno_mismatch
- 记录一次0丢失的ORA-00354: 损坏重做日志块标头故障恢复
- 不当数据库恢复操作导致一个月数据丢失
- obet快速修复oracle 位图损坏块
- 不太常见的10.2.0.1的oracle redo损坏恢复
- obet forcecopy功能抢救硬件故障中的数据文件
- kcratr_nab_less_than_odr和system坏块故障处理
- 通过obet 恢复system坏块,打开数据库
- obet dbv功能完整说明
- 分享一例运行在aix上的sap系统数据库恢复过程
- OBET-Oracle Block Editor Tool使用说明
- 几乎动用了所有手段的Oracle故障恢复
- Oracle Block Edit Tool (obet) 功能增强–2026.07
- Oracle 19c 202607补丁(RUs+OJVM)-19.32
- Patch_SCN快速修复ORA-01555数据库open故障
- 快速处理 ORA-01210: data file header is media corrupt 故障
分类目录归档:Oracle
RMAN SBT_TAPE备份无法被DISK通道识别
经过测试确认rman SBT_TAPE通道备份的rman备份集无法被DISK通道(文件系统方式备份)方式恢复,关于rman的SBT_TAPE通道(带库方式备份)备份参考:模拟带库实现rman远程备份
发起SBT_TAPE通道备份备份
[oracle@xifenfei ~]$ rman target / Recovery Manager: Release 11.2.0.4.0 - Production on Sun Jul 14 13:19:03 2024 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. connected to target database: XIFENFEI (DBID=1780931490) RMAN> CONFIGURE DEFAULT DEVICE TYPE TO SBT_TAPE; using target database control file instead of recovery catalog old RMAN configuration parameters: CONFIGURE DEFAULT DEVICE TYPE TO DISK; new RMAN configuration parameters: CONFIGURE DEFAULT DEVICE TYPE TO 'SBT_TAPE'; new RMAN configuration parameters are successfully stored RMAN> backup format 'ctl_%T_%U.rman' current controlfile; Starting backup at 14-JUL-24 allocated channel: ORA_SBT_TAPE_1 channel ORA_SBT_TAPE_1: SID=147 device type=SBT_TAPE channel ORA_SBT_TAPE_1: SBT/SSH2-SFTP channel ORA_SBT_TAPE_1: starting full datafile backup set channel ORA_SBT_TAPE_1: specifying datafile(s) in backup set including current control file in backup set channel ORA_SBT_TAPE_1: starting piece 1 at 14-JUL-24 channel ORA_SBT_TAPE_1: finished piece 1 at 14-JUL-24 piece handle=ctl_20240714_0r2vt3eh_1_1.rman tag=TAG20240714T131913 comment=API Version 2.0,MMS Version 1.0.9.0 channel ORA_SBT_TAPE_1: backup set complete, elapsed time: 00:00:01 Finished backup at 14-JUL-24
确认备份文件在文件系统中位置
[oracle@xifenfei ~]$ ls -l /tmp/rmanback/ctl_20240714_0r2vt3eh_1_1.rman -rw-r--r-- 1 root root 9961472 Jul 14 13:19 /tmp/rmanback/ctl_20240714_0r2vt3eh_1_1.rman
尝试DISK通道加载备份集,报RMAN-07519错误
RMAN> catalog start with '/tmp/rmanback/ctl_20240714_0r2vt3eh_1_1.rman'; using target database control file instead of recovery catalog searching for all files that match the pattern /tmp/rmanback/ctl_20240714_0r2vt3eh_1_1.rman List of Files Unknown to the Database ===================================== File Name: /tmp/rmanback/ctl_20240714_0r2vt3eh_1_1.rman Do you really want to catalog the above files (enter YES or NO)? yes cataloging files... no files cataloged List of Files Which Where Not Cataloged ======================================= File Name: /tmp/rmanback/ctl_20240714_0r2vt3eh_1_1.rman RMAN-07519: Reason: Error while cataloging. See alert.log.
查看alert日志信息报ORA-27048: skgfifi: file header information is invalid 等错误
Sun Jul 14 13:28:22 2024 Errors in file /u01/app/oracle/diag/rdbms/xifenfei/xifenfei/trace/xifenfei_ora_13260.trc: ORA-19624: operation failed, retry possible ORA-19870: error while restoring backup piece /tmp/rmanback/ctl_20240714_0r2vt3eh_1_1.rman ORA-19505: failed to identify file "/tmp/rmanback/ctl_20240714_0r2vt3eh_1_1.rman" ORA-27048: skgfifi: file header information is invalid Additional information: 8 ORA-27048: skgfifi: file header information is invalid Additional information: 8 ORA-27048: skgfifi: file header information is invalid Additional information: 8
通过分析备份文件发现在带库方式备份和文件系统方式备份的文件头信息明显不一样

ORA-27154 ORA-27300 ORA-27301 ORA-27302故障处理
根据经验对系统的内核参数做了一些调整,结果导致数据库启动失败提示报ORA-27154 ORA-27300 ORA-27301 ORA-27302错误
ORA-27154: post/wait create failed ORA-27300: OS system dependent operation:semget failed with status: 28 ORA-27301: OS failure message: No space left on device ORA-27302: failure occurred at: sskgpcreates
根据官方描述:Database Startup Fails with ORA-27300: OS system dependent operation:semget failed with status: 28 (Doc ID 949468.1),出现该问题原因可能是由于kernel.sem参数配置不合适当时,该库的processes配置为:20000,kernel.sem参数配置为:kernel.sem = 250 32000 100 128,参数说明:
kernel.sem = SEMMSL SEMMNS SEMOPM SEMMNI SEMMSL - max semaphores per array SEMMNS - max semaphores system wide SEMOPM - max ops per semop call SEMMNI - max number of arrays
理论上每个这样的配置最大值SEMMSL*SEMMNI=32000大于process的20000的设置,可是实际上控制每个信号集的信号数量没有达到250,而是只有156,通过ipcs命令可以看
[oracle@xifenfei ~]$ ipcs ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x00000000 32768 oracle 640 33554432 30 0x00000000 65537 oracle 640 4261412864 30 0xc2d167d0 98306 oracle 640 2097152 30 0x00000072 131075 root 444 1 1 ------ Semaphore Arrays -------- key semid owner perms nsems 0x450e15bd 0 root 666 1 0x0000cace 32769 root 666 1 0x358b172c 327683 oracle 660 104 0x9053d038 11075588 oracle 660 156 0x9053d039 11108357 oracle 660 156 0x9053d03a 11141126 oracle 660 156 0x9053d03b 11173895 oracle 660 156
从而使得SEMMSL*SEMMNI小于processes值,进而数据库启动报ORA-27154 ORA-27300 ORA-27301 ORA-27302,修改kernel.sem = 250 64000 128 256,数据库启动成功
awr创建snapshot等待library cache: mutex X
客户一个11.2.0.4的库,在准备收集awr的时候发现没有snap id

人工创建snapshot发现hang住了

查询该会话等待事件为:library cache: mutex X,查看以前mmon的子进程m000/1的trace信息
Trace file /u01/app/oracle/diag/rdbms/xff/xff/trace/xff_m000_6241.trc
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1
System name: Linux
Node name: HIS
Release: 5.4.17-2102.201.3.el7uek.x86_64
Version: #2 SMP Fri Apr 23 09:05:55 PDT 2021
Machine: x86_64
VM name: VMWare Version: 6
Instance name: xff
Redo thread mounted by this instance: 1
Oracle process number: 5714
Unix process pid: 6241, image: oracle@HIS (M000)
*** 2024-06-19 11:44:39.483
*** SESSION ID:(8709.38013) 2024-06-19 11:44:39.483
*** CLIENT ID:() 2024-06-19 11:44:39.483
*** SERVICE NAME:(SYS$BACKGROUND) 2024-06-19 11:44:39.483
*** MODULE NAME:(MMON_SLAVE) 2024-06-19 11:44:39.483
*** ACTION NAME:(Auto-Flush Slave Action) 2024-06-19 11:44:39.483
DDE rules only execution for: ORA 12751
----- START Event Driven Actions Dump ----
---- END Event Driven Actions Dump ----
----- START DDE Actions Dump -----
Executing SYNC actions
Executing ASYNC actions
----- START DDE Action: 'ORA_12751_DUMP' (Sync) -----
Runtime exceeded 900 seconds
Time limit violation detected at:
ksedsts()+465<-kspol_12751_dump()+145<-dbgdaExecuteAction()+1065<-dbgerRunAction()+109<-dbgerRunActions()
+4134<-dbgexPhaseII()+1873<-dbgexProcessError()+2680<-dbgeExecuteForError()+88<-dbgePostErrorKGE()+2136<-
dbkePostKGE_kgsf()+71<-kgeselv()+276<-kgesecl0()+139<-kgxWait()+1412<-kgxExclusive()+447<-
kglGetMutex()+140<-kglGetHandleReference()+69<-kglic0()+319<-kksIterCursorStat()+330<-kewrrtsq_rank_topsql()
+240<-kewrbtsq_build_topsql()+128<-kewrftsq_flush_topsql()+679<-kewrft_flush_table()+397<-
kewrftec_flush_table_ehdlcx()+766<-kewrfat_flush_all_tables()+1406<-kewrfos_flush_onesnap()+170
<-kewrfsc_flush_snapshot_c()+623<-kewrafs_auto_flush_slave()+769<-kebm_slave_main()+586<-ksvrdp()+1766
<-opirip()+674<-opidrv()+603<-sou2o()+103<-opimai_real()+250<-ssthrdmain()+265<-main()+201
<-__libc_start_main()+245
Current Wait Stack:
0: waiting for 'library cache: mutex X'
idn=0x644e2de0, value=0xf3a00000000, where=0x7c
wait_id=1189 seq_num=1190 snap_id=1
wait times: snap=3 min 0 sec, exc=3 min 0 sec, total=3 min 0 sec
wait times: max=infinite, heur=15 min 3 sec
wait counts: calls=16376 os=16376
in_wait=1 iflags=0x15b2
There is at least one session blocking this session.
Dumping 1 direct blocker(s):
inst: 1, sid: 3898, ser: 47299
Dumping final blocker:
inst: 1, sid: 3898, ser: 47299
Wait State:
fixed_waits=0 flags=0x22 boundary=(nil)/-1
Session Wait History:
elapsed time of 0.000016 sec since current wait
0: waited for 'library cache: mutex X'
idn=0x644e2de0, value=0xf3a00000000, where=0x7c
wait_id=1188 seq_num=1189 snap_id=1
wait times: snap=12 min 2 sec, exc=12 min 2 sec, total=12 min 2 sec
wait times: max=infinite
wait counts: calls=65535 os=65535
occurred after 0.327543 sec of elapsed time
1: waited for 'db file sequential read'
file#=0x2, block#=0x1a5b, blocks=0x1
wait_id=1187 seq_num=1188 snap_id=1
wait times: snap=0.000420 sec, exc=0.000420 sec, total=0.000420 sec
wait times: max=infinite
wait counts: calls=0 os=0
occurred after 0.000251 sec of elapsed time
2: waited for 'db file sequential read'
file#=0x1, block#=0x82e6, blocks=0x1
wait_id=1186 seq_num=1187 snap_id=1
wait times: snap=0.000429 sec, exc=0.000429 sec, total=0.000429 sec
wait times: max=infinite
wait counts: calls=0 os=0
occurred after 0.001085 sec of elapsed time
3: waited for 'db file sequential read'
file#=0x2, block#=0x11344, blocks=0x1
wait_id=1185 seq_num=1186 snap_id=1
wait times: snap=0.000356 sec, exc=0.000356 sec, total=0.000356 sec
wait times: max=infinite
wait counts: calls=0 os=0
occurred after 0.000008 sec of elapsed time
4: waited for 'db file sequential read'
file#=0x2, block#=0x19eb, blocks=0x1
wait_id=1184 seq_num=1185 snap_id=1
wait times: snap=0.000397 sec, exc=0.000397 sec, total=0.000397 sec
wait times: max=infinite
wait counts: calls=0 os=0
occurred after 0.000044 sec of elapsed time
5: waited for 'db file sequential read'
file#=0x2, block#=0xb1659, blocks=0x1
wait_id=1183 seq_num=1184 snap_id=1
wait times: snap=0.000003 sec, exc=0.000003 sec, total=0.000003 sec
wait times: max=infinite
wait counts: calls=0 os=0
occurred after 0.000010 sec of elapsed time
6: waited for 'db file sequential read'
file#=0x2, block#=0xb1658, blocks=0x1
wait_id=1182 seq_num=1183 snap_id=1
wait times: snap=0.000453 sec, exc=0.000453 sec, total=0.000453 sec
wait times: max=infinite
wait counts: calls=0 os=0
occurred after 0.000009 sec of elapsed time
7: waited for 'db file sequential read'
file#=0x2, block#=0x19e1, blocks=0x1
wait_id=1181 seq_num=1182 snap_id=1
wait times: snap=0.000388 sec, exc=0.000388 sec, total=0.000388 sec
wait times: max=infinite
wait counts: calls=0 os=0
occurred after 0.000017 sec of elapsed time
8: waited for 'db file sequential read'
file#=0x2, block#=0x19e2, blocks=0x1
wait_id=1180 seq_num=1181 snap_id=1
wait times: snap=0.000415 sec, exc=0.000415 sec, total=0.000415 sec
wait times: max=infinite
wait counts: calls=0 os=0
occurred after 0.004826 sec of elapsed time
9: waited for 'db file sequential read'
file#=0x2, block#=0x2ffc0c, blocks=0x1
wait_id=1179 seq_num=1180 snap_id=1
wait times: snap=0.000404 sec, exc=0.000404 sec, total=0.000404 sec
wait times: max=infinite
wait counts: calls=0 os=0
occurred after 0.000007 sec of elapsed time
Sampled Session History of session 8709 serial 38013
---------------------------------------------------
The sampled session history is constructed by sampling
the target session every 1 second. The sampling process
captures at each sample if the session is in a non-idle wait,
an idle wait, or not in a wait. If the session is in a
non-idle wait then one interval is shown for all the samples
the session was in the same non-idle wait. If the
session is in an idle wait or not in a wait for
consecutive samples then one interval is shown for all
the consecutive samples. Though we display these consecutive
samples in a single interval the session may NOT be continuously
idle or not in a wait (the sampling process does not know).
The history is displayed in reverse chronological order.
sample interval: 1 sec, max history 120 sec
---------------------------------------------------
[118 samples, 11:42:39 - 11:44:39]
waited for 'library cache: mutex X', seq_num: 1190
p1: 'idn'=0x644e2de0
p2: 'value'=0xf3a00000000
p3: 'where'=0x7c
time_waited: >= 120 sec (still in wait)
[3 samples, 11:42:39 - 11:42:38]
idle wait at each sample
---------------------------------------------------
Sampled Session History Summary:
longest_non_idle_wait: 'library cache: mutex X'
[118 samples, 11:42:39 - 11:44:39]
time_waited: >= 120 sec (still in wait)
---------------------------------------------------
----- END DDE Action: 'ORA_12751_DUMP' (SUCCESS, 8 csec) -----
----- END DDE Actions Dump (total 8 csec) -----
KGX cleanup...
KGX Atomic Operation Log 0x1de44da670
Mutex 0x1d113cf7c8(8709, 0) idn 2de0 oper EXCL(6)
Library Cache uid 8709 efd 7 whr 49 slp 0
oper=0 pt1=(nil) pt2=(nil) pt3=(nil)
pt4=(nil) pt5=(nil) ub4=0
KGX cleanup...
KGX Atomic Operation Log 0x1de44da6c8
Mutex 0x1de9468550(3898, 0) idn 644e2de0 oper GET_EXCL(5)
Library Cache uid 8709 efd 7 whr 124 slp 16376
oper=0 pt1=0x1de9468410 pt2=(nil) pt3=(nil)
pt4=(nil) pt5=(nil) ub4=0
*** KEWRAFM1: Error=12751 encountered by kewrfteh
*** KEWRAFS: Error=12751 encountered by Auto Flush Slave.
KEBM: MMON slave action policy violation. kewrmafsa_; viol=1; err=12751
一般来说类似这样的系统自动任务被阻塞很可能是由于那种bug导致,找到相关mos文档: library cache: mutex x waits during AWR Flush High Cursor Scan (Doc ID 2382741.1),确认为:Bug 19294556 AWR Flush Waiting For Cursor Scan, Library Cache : Mutex X,目前没有好的workaround,而且在11.2.0.4基础版上没有对应的patch



加我微信(17813235971)
加我QQ(107644445)

