标签云
asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-00742 ORA-01110 ORA-01555 ORA-01578 ORA-01595 ORA-08103 ORA-600 2131 ORA-600 2662 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)
- 操作系统 (103)
- 数据库 (1,756)
- DB2 (22)
- MySQL (76)
- Oracle (1,598)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (163)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (69)
- Oracle Bug (8)
- Oracle RAC (54)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (28)
- Oracle备份恢复 (588)
- Oracle安装升级 (96)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (84)
- PostgreSQL (30)
- pdu工具 (6)
- PostgreSQL恢复 (9)
- SQL Server (32)
- SQL Server恢复 (13)
- TimesTen (7)
- 达梦数据库 (3)
- 达梦恢复 (1)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (39)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (22)
-
最近发表
- Oracle Recovery Tools恢复案例总结—202505
- ORA-600 kddummy_blkchk 数据库循环重启
- 记录一次asm disk加入到vg通过恢复直接open库的案例
- CHECKDB 发现了 N 个分配错误和 M 个一致性错误
- 达梦数据库dm.ctl文件异常恢复
- Oracle Recovery Tools修复ORA-00742、ORA-600 ktbair2: illegal inheritance故障
- 可能是 tempdb 空间用尽或某个系统表不一致故障处理
- 11.2.0.4库中遇到ORA-600 kcratr_nab_less_than_odr报错
- [MY-013183] [InnoDB] Assertion failure故障处理
- Oracle 19c 202504补丁(RUs+OJVM)-19.27
- Oracle Recovery Tools修复ORA-600 6101/kdxlin:psno out of range故障
- pdu完美支持金仓数据库恢复(KingbaseES)
- 虚拟机故障引起ORA-00310 ORA-00334故障处理
- pg创建gbk字符集库
- PostgreSQL运行日志管理
- ora-600 kdsgrp1 错误描述
- GAM、SGAM 或 PFS 页上存在页错误处理
- ORA-600 krhpfh_03-1208
- VMware勒索加密恢复(vmdk勒索恢复)
- ORA-39773: parse of metadata stream failed故障处理
分类目录归档:ORA-xxxxx
ORA-07445 opiaba—绑定变量超过65535导致实例crash
数据库异常报ORA-07445 opiaba,ORA-00600 17147错,导致实例crash
Wed Mar 15 09:48:06 2023 Exception [type: SIGSEGV, SI_KERNEL(general_protection)] [ADDR:0x0] [PC:0x187B953, opiaba()+639] [flags: 0x0, count: 1] Errors in file /u01/app/oracle/diag/rdbms/xifenfei/xifenfei3/trace/xifenfei3_ora_169909.trc (incident=446531): ORA-07445: 出现异常错误: 核心转储 [opiaba()+639] [SIGSEGV] [ADDR:0x0] [PC:0x187B953] [SI_KERNEL(general_protection)] [] Incident details in: /u01/app/oracle/diag/rdbms/xifenfei/xifenfei3/incident/incdir_446531/xifenfei3_ora_169909_i446531.trc Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. Wed Mar 15 09:48:07 2023 Dumping diagnostic data in directory=[cdmp_20230315094807], requested by (instance=3, osid=169909), summary=[incident=446531]. Wed Mar 15 09:48:08 2023 Sweep [inc][446531]: completed Sweep [inc2][446531]: completed Wed Mar 15 09:48:33 2023 Errors in file /u01/app/oracle/diag/rdbms/xifenfei/xifenfei3/trace/xifenfei3_pmon_161557.trc (incident=440035): ORA-00600: internal error code, arguments: [17147], [0x4AFC25D0C8], [], [], [], [], [], [], [], [], [], [] Incident details in: /u01/app/oracle/diag/rdbms/xifenfei/xifenfei3/incident/incdir_440035/xifenfei3_pmon_161557_i440035.trc Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. Wed Mar 15 09:48:33 2023 Dumping diagnostic data in directory=[cdmp_20230315094833], requested by (instance=3, osid=161557 (PMON)), summary=[incident=440035]. Errors in file /u01/app/oracle/diag/rdbms/xifenfei/xifenfei3/trace/xifenfei3_pmon_161557.trc: ORA-00600: internal error code, arguments: [17147], [0x4AFC25D0C8], [], [], [], [], [], [], [], [], [], [] PMON (ospid: 161557): terminating the instance due to error 472 Wed Mar 15 09:48:34 2023 opiodr aborting process unknown ospid (170089) as a result of ORA-1092
对应的trace文件信息
*** 2023-03-15 09:09:34.862 *** SESSION ID:(1858.63187) 2023-03-15 09:09:34.862 *** CLIENT ID:() 2023-03-15 09:09:34.862 *** SERVICE NAME:(xifenfei) 2023-03-15 09:09:34.862 *** MODULE NAME:(JDBC Thin Client) 2023-03-15 09:09:34.862 *** ACTION NAME:() 2023-03-15 09:09:34.862 Dump continued from file: /u01/app/oracle/diag/rdbms/xifenfei/xifenfei3/trace/xifenfei3_ora_116886.trc ORA-07445: 出现异常错误: 核心转储 [opiaba()+639] [SIGSEGV] [ADDR:0x0] [PC:0x187B953] [SI_KERNEL(general_protection)] [] ========= Dump for incident 326049 (ORA 7445 [opiaba()+639]) ======== ----- Beginning of Customized Incident Dump(s) ----- Exception [type: SIGSEGV, SI_KERNEL(general_protection)] [ADDR:0x0] [PC:0x187B953, opiaba()+639] [flags: 0x0, count: 1] Registers: %rax: 0x00000046fa212588 %rbx: 0x00000046762ee798 %rcx: 0x0000000000003200 %rdx: 0x0000000000000000 %rdi: 0x0000000000007340 %rsi: 0x0000000000007340 %rsp: 0x00007fffffff41d0 %rbp: 0x00007fffffff4240 %r8: 0x00000044a8599f00 %r9: 0x0000000000000099 %r10: 0x0000000000000b34 %r11: 0x00000046fa211720 %r12: 0x00000046fa5c7488 %r13: 0x0000000000000000 %r14: 0x0200000046fa2125 %r15: 0x0000000000000005 %rip: 0x000000000187b953 %efl: 0x0000000000010202 opiaba()+625 (0x187b945) jmp 0x187b982 opiaba()+627 (0x187b947) movzbl 0x2c(%rbx),%r15d opiaba()+632 (0x187b94c) mov %r14,-0x60(%rbp) opiaba()+636 (0x187b950) mov %rax,%r14 > opiaba()+639 (0x187b953) movswq 0xa(%r14),%rcx opiaba()+644 (0x187b958) cmp %ecx,%r15d opiaba()+647 (0x187b95b) jne 0x187b976 opiaba()+649 (0x187b95d) mov 0x18(%rbx),%rdi opiaba()+653 (0x187b961) lea 0xc(%r14),%rsi *** 2023-03-15 09:09:34.863 dbkedDefDump(): Starting a non-incident diagnostic dump (flags=0x3, level=3, mask=0x0) ----- Current SQL Statement for this session (sql_id=5cvg8vqsbr8j6) ----- BEGIN UPDATE t_xifenfei SET valid_param=:1 , comm_addr1 = :2 , password=:3 , customer_type = :4 , comm_no=:5 , date_grade_no = :6 , date_grade_flag=:7 , curve_config_no = :8 , curve_config_flag=:9 , baudrate = :10 , meas_order=:11 , meter_no = :12 , kind_no=:13 , tariff_count = :14 , meter_digits = :15 , import_user=:16 , readmeter_flag = :17 ,status_code=:18 WHERE meter_id = :19 ; ………… ; UPDATE t_xifenfei SET valid_param=:94982 , comm_addr1 = :94983 , password=:94984 , customer_type = :94985 , comm_no=:94986 , date_grade_no = :94987 , date_grade_flag=:94988 , curve_config_no = :94989 , curve_config_flag=:94990 , baudrate = :94991 , meas_order=:94992 , meter_no = :94993 , kind_no=:94994 , tariff_count = :94995 , meter_digits = :94996 , import_user=:94997 , readmeter_flag = :94998 ,status_code=:94999 WHERE meter_id = :95000 ;END;
写了一个begin end,里面对于同一个update语句进行多次绑定变量实现批量提交功能,绑定变量的数量达到95000个,远超oracle官方限制的65535的极限,触发类似Bug 12578873 ORA-7445 [opiaba] when using more than 65535 bind variables
处理方法减少绑定变量数量,不能超过65535个
ORA-00800: soft external error, arguments: [Set Priority Failed]
在一套19.14的linux 2节点rac库中,使用sqlplus启动数据库成功,但是alert日志中报ORA-00800: soft external error, arguments: [Set Priority Failed]错误.
2022-09-21T22:20:35.924251+08:00 Starting background process VKTM 2022-09-21T22:20:35.977936+08:00 Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl1/trace/orcl1_vktm_22653.trc (incident=880052): ORA-00800: soft external error, arguments: [Set Priority Failed], [VKTM], [Check traces and OS configuration], [Check Oracle document and MOS notes], [] Incident details in: /u01/app/oracle/diag/rdbms/orcl/orcl1/incident/incdir_880052/orcl1_vktm_22653_i880052.trc 2022-09-21T22:20:35.980555+08:00 Error attempting to elevate VKTM's priority: no further priority changes will be attempted for this process VKTM started with pid=6, OS id=22653 Starting background process LMHB 2022-09-21T22:20:36.467831+08:00 Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl1/trace/orcl1_lms0_22703_22708.trc (incident=920005): ORA-00800: soft external error, arguments: [Set Priority Failed], [LMS0], [Check traces and OS configuration], [Check Oracle document and MOS notes], [] Incident details in: /u01/app/oracle/diag/rdbms/orcl/orcl1/incident/incdir_920005/orcl1_lms0_22703_22708_i920005.trc 2022-09-21T22:20:36.470535+08:00 Error attempting to elevate LMS0's priority: no further priority changes will be attempted for this process
错误提示比较明显,提升进程的优先级失败,通过操作系统命令观察发现确实进程优先级没有提升
[root@oradb01 ~]# ps -eo pid,class,pri,nice,time,args|grep vktm|grep -v grep 5656 TS 19 0 00:00:00 ora_vktm_orcl1 30838 RR 41 - 13:08:36 ora_vktm_+ASM1
重新使用srvctl启动数据库,优先级提升正常,alert日志中也无类似警告
[root@oradb01 ~]# ps -eo pid,class,pri,nice,time,args|grep vktm|grep -v grep 5716 RR 41 0 00:00:00 ora_vktm_orcl1 30838 RR 41 - 13:18:46 ora_vktm_+ASM1
这个问题一直困惑了很久,今天无意中在mos上发现了相关mos文档,具体参考:(DB50) Clusterware Fails to Start Because CSSD Cannot Get Real-Time Priority (Doc ID 2903663.1),由于 bug 34286265 and bug 34318125(Bug 34649727 Linux: ORA-800 / Set Priority / DB Performance Merge Patch for 19.17 – 34286265 34318125)
尽量不要使用sqlplus去启动数据库,而是选择使用srvctl,避免在rac环境中导致数据库后台关键进程优先级无法提升问题.
ORA-00257: archiver error的另外一种原因
今天遇到一个相对特殊的案例,拿出来和大家分享,数据库报错为不能归档ORA-00257
SQL> conn system/xxxxxx ERROR: ORA-00257: archiver error. Connect internal only, until freed. SQL> archive log list; Database log mode Archive Mode Automatic archival Enabled Archive destination /oracle/PRD/oraarch Oldest online log sequence 11479 Current log sequence 11481
alert日志报错
sapprddb1:oraprd 73> tail -f alert_prd.log Master archival failure: 19502 Master archival failure: 19502 Master archival failure: 19502 Master archival failure: 19502 Wed Oct 12 09:27:41 2022 Master archival failure: 19502 Master archival failure: 19502 Master archival failure: 19502 Wed Oct 12 09:27:41 2022 Master archival failure: 19502
该错误的含义
sapprddb1:oraprd 74>oerr ora 19502 19502, 00000, "write error on file \"%s\", block number %s (block size=%s)" // *Cause: write error on output file // *Action: check the file
从报错初步看是由于归档目录空间满了导致,查看发现归档空间剩余很多
sapprddb1:/oracle/PRD/sapdata1 # df -h Filesystem Size Used Avail Use% Mounted on /dev/sda1 99G 25G 70G 26% / udev 253G 240K 253G 1% /dev tmpfs 426G 72K 426G 1% /dev/shm /dev/sda3 388G 12G 357G 4% /backup /dev/mapper/SAPVG-oraclelv 197G 22G 165G 12% /oracle /dev/mapper/SAPVG-mirrlogA 20G 773M 18G 5% /oracle/PRD/mirrlogA /dev/mapper/SAPVG-mirrlogBlv 20G 773M 18G 5% /oracle/PRD/mirrlogB /dev/mapper/SAPVG-oraarchlv 180G 2.2G 169G 2% /oracle/PRD/oraarch <----剩余很多 /dev/mapper/SAPVG-origlogAlv 20G 894M 18G 5% /oracle/PRD/origlogA /dev/mapper/SAPVG-origlogBlv 20G 894M 18G 5% /oracle/PRD/origlogB /dev/mapper/SAPVG-sapdata1lv 591G 561G 0 100% /oracle/PRD/sapdata1 /dev/mapper/SAPVG-sapdata2lv 1.4T 1.4T 0 100% /oracle/PRD/sapdata2 /dev/mapper/SAPVG-sapdata3lv 788G 748G 0 100% /oracle/PRD/sapdata3 /dev/mapper/SAPVG-sapdata4lv 788G 748G 0 100% /oracle/PRD/sapdata4 sapprd:/sapmnt/PRD 30G 12G 17G 42% /sapmnt/PRD sapprd:/usr/sap/trans 105G 1005M 99G 1% /usr/sap/trans /dev/mapper/VGSAP2-lvsapdata5 1.5T 340G 1.1T 25% /oracle/PRD/sapdata5 /dev/mapper/VGSAP2-lvsapdata6 1.5T 706G 696G 51% /oracle/PRD/sapdata6
尝试人工归档
SQL> alter system archive log current 2 / alter system archive log current * ERROR at line 1: ORA-19502: write error on file "/oracle/PRD/sapdata1/cntrl/cntrlPRD.dbf", block number 4837 (block size=16384) ORA-27061: waiting for async I/Os failed Linux-x86_64 Error: 28: No space left on device Additional information: -1 Additional information: 442368
到这里基本上明确了,由于控制文件所在的分区磁盘使用100%,导致归档的时候无法写如记录到控制文件从而导致数据库报ORA-00257错误,对/oracle/PRD/sapdata1中的某个文件进行稍微收缩,数据库恢复正常