标签云
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,768)
- DB2 (22)
- MySQL (77)
- Oracle (1,609)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (166)
- 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 监听 (29)
- Oracle备份恢复 (591)
- Oracle安装升级 (97)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (86)
- 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)
-
最近发表
- ORA-600 kokiasg1故障分析(obj$中核心字典序列全部被恶意删除)
- ORA-00756 ORA-10567故障数据0丢失恢复
- 数据库文件变成32k故障恢复
- tcp连接过多导致监听TNS-12532 TNS-12560 TNS-00502错误
- 文件系统格式化MySQL数据库恢复
- .sstop勒索加密数据库恢复
- 解决一次硬件恢复之后数据文件0kb的故障恢复case
- Error in invoking target ‘libasmclntsh19.ohso libasmperl19.ohso client_sharedlib’问题处理
- ORA-01171: datafile N going offline due to error advancing checkpoint
- linux环境oracle数据库被文件系统勒索加密为.babyk扩展名溯源
- ORA-600 ksvworkmsgalloc: bad reaper
- ORA-600 krccfl_chunk故障处理
- 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报错
分类目录归档:ORA-xxxxx
双机mount数据库出现ORA-00600[kccsbck_first]
一朋友的数据库在做数据库恢复的时候,数据库不能启动到mount状态,检查发现
alert日志错误如下
Mon Aug 27 10:00:18 2012 ALTER DATABASE MOUNT Mon Aug 27 10:00:23 2012 Errors in file /oracle/admin/wf2009/udump/orcl_ora_7042.trc: ORA-00600: internal error code, arguments: [kccsbck_first], [1], [1208656276], [], [], [], [], [] Mon Aug 27 10:00:23 2012 ORA-600 signalled during: ALTER DATABASE MOUNT...
查询mos发现解释
The ORA-600 [kccsbck_first] error occurs when Oracle detects that another instance has this database already mounted. For some reason, Oracle already sees a thread with a heartbeat. This could be the expected behaviour if running OPS. In such a case the parallel_server parameter needs to be set. In cases where Parallel Server is not linked in, this is not the expected behaviour.
在非集群环境中,当该数据库已经在一个节点启动,然后另外一个节点再尝试启动数据库可能出现该错误.
检查环境发现是使用roseha的双机环境,当关闭当前节点的数据库时候,另外一个节点认为oracle down掉了,然后自动在该节点去尝试启动数据库,而当前操作节点去尝试mount数据库的时候发生该错误,因为该数据库的另外一个节点已经mount了.出现这样的情况,和朋友的存储资源的配置也有不合理之处,在接管资源之前,应该先分析和处理存储的挂载情况,而不是不卸载这边,另外一遍直接挂载(也就是存储两边都挂载)
解决办法
这个问题的本质就是因为ha的两边都启动了数据库导致,关闭一边的roseha或者关闭主机就可以了
在做数据库恢复的时候,尽量排查掉其他因素的影响,比如:rac在一个节点上操作,ha关闭双机软件等
ORA-609 TNS-12537 and TNS-12547 in 11g Alert.log
数据库alert日志出现如下错误
Fatal NI connect error 12537, connecting to: (LOCAL=NO) VERSION INFORMATION: TNS for IBM/AIX RISC System/6000: Version 11.2.0.2.0 - Production TCP/IP NT Protocol Adapter for IBM/AIX RISC System/6000: Version 11.2.0.2.0 - Production Oracle Bequeath NT Protocol Adapter for IBM/AIX RISC System/6000: Version 11.2.0.2.0 - Production Time: 21-AUG-2012 09:50:15 Tracing not turned on. Tns error struct: ns main err code: 12537 TNS-12537: TNS:connection closed ns secondary err code: 12560 nt main err code: 0 nt secondary err code: 0 nt OS err code: 0 opiodr aborting process unknown ospid (15204768) as a result of ORA-609
错误的原因
The ORA-609 error is thrown when a client connection of any kind failed to complete or aborted the connection process before the connection/authentication process was complete. Very often, this connection abort is due to a timeout. Beginning with 10gR2, a default value for inbound connect timeout has been set at 60 seconds. This time limit is often inadequate for the entire connection process to complete. We have also discovered that the ORA-609 occurs frequently in installations where the database is monitored by DB Console and the Enterprise Manager agent (emagent). After the DB Console is started and as a matter of routine, the emagent will repeatedly try to connect to the target instances. We can see frequent emagent connections in the listener.log without error. However, on occasion it may have failed to complete the connection process at the database so an ORA-609 is thrown. The emagent will simply retry the connection and may be successful on the subsequent try. (Provided there is no real fault occurring at the listener or database). This temporary failure to connect will not be reported back to DB Console and there will be no indication, except for the ORA-609, that a fault occurred.
出现这个问题的主要原因是因为从10.2开始inbound connect timeout默认为60 seconds,而在很多建立连接过程可能超过这个时间从而出现类此错误,常见的诱因是DB Console 和 Enterprise Manager agent (emagent). EM会重复的尝试连接到数据库。其过程中会偶尔的出现连接超时的问题,但是接下来会继续尝试,并获得成功。这种临时的失败不会导致EM报错而只会以ora-609的形式记录在alert log中.
处理方法
For that reason, we often recommend increasing the values for INBOUND_CONNECT_TIMEOUT at both listener and server side sqlnet.ora file as a preventive measure. If the problem is due to connection timeouts, an increase in the following parameters should eliminate or reduce the occurrence of the ORA-609s. e.g. Sqlnet.ora: SQLNET.INBOUND_CONNECT_TIMEOUT=180 Listener.ora: INBOUND_CONNECT_TIMEOUT_listener_name=120 These settings are in seconds. Again, the default is 60.
问题跟踪方法
If the issue persists and inbound connect does not have any effect, the following steps are intended to help locate the client that may be causing the errors. 1) Suppress the TNS errors in the alert.log by setting the following listener.ora file parameter: DIAG_ADR_ENABLED_listener_name=OFF This will cause the TNS errors to be posted to the ORACLE_HOME/network/log/sqlnet.log file that is local to the database and may yield useful information about the client's address. For example, here's a snippet from a server side sqlnet.log where client address info was posted: Production Time: 15-FEB-2010 07:15:01 Fatal NI connect error 12537, connecting to: (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(Host=yourhost)(Port=1521))(CONNECT_DATA=(SID=PROD1DR) (CID=(PROGRAM=sqlplus)(HOST=client_host)(USER=client)))) Observe the PROGRAM and HOST fields on the last line. This is where the connection originated. Be sure to match timestamps in the sqlnet.log with the timestamps of the alert.log errors. Once you've located the offending client, you can enable client tracing to try and determine the cause: TRACE_LEVEL_CLIENT=16 TRACE_DIRECTORY_CLIENT=<dir location> TRACE_TIMESTAMP_CLIENT=TRUE DIAG_ADR_ENABLED=off <<<<<11g or newer client requirement If you need assistance with client or server tracing, please open an SR with Global Customer Support. 2) Check the listener.log for client connections that were logged at timestamps that match the ORA-609 timestamps as they appear in the alert.log. The client information is recorded in each listener.log entry. Since this error occurs AFTER the listener has handled the connection, do not expect to see errors in the listener.log. Here's an example snippet of an incoming client connection that was posted to the listener.log: 20-JAN-2009 17:08:45 (CONNECT_DATA=(SID=orcl)(CID= (PROGRAM=D:\oracle\product\10.1.0\Db_1\perl\5.6.1\bin\MSWin32-x86\perl.exe)(HOST=myclient) Note that the exact timestamp, program name and client host will often be recorded. Again, once you've located the offending client, enable tracing (see above) to try to capture the connection failure. 3) Enable server side Oracle Net tracing and capture the TNS error along with the incoming connection. Match the PID that accompanies the ORA-609 to the server trace label. e.g. ORA-609 : opiodr aborting process unknown ospid (4799_1) *Note the PID This PID would correspond to server trace labeled: svr_4799.trc. Check the server trace for either TNS error (the 609 will not appear) and try to locate the originating client address. If assistance is needed for this investigation, please open an SR with Oracle Support. See below for instuctions on enabling Oracle Net server tracing. The following details the discovery of the source of an ORA-609 for a real case: The alert.log reports the following messages intermittently but frequently: Mon Nov 16 22:39:22 2009 ORA-609 : opiodr aborting process unknown ospid (nnnn) Enabled Oracle Net server tracing: TRACE_LEVEL_SERVER=16 TRACE_DIRECTORY_SERVER=<dir location> TRACE_TIMESTAMP_SERVER=TRUE DIAG_ADR_ENABLED=off Reloaded listener and wait for error to appear again.: ORA-609 : opiodr aborting process unknown ospid (5233_1) Note that the server trace file set that corresponded to this event was named svr_5233*.trc. Of course the timestamps of the alert.log event and the server trace creation matched as well. A review of the server trace showed only an EOF failure and the TNS-12537 error: Read unexpected EOF ERROR nserror: nsres: id=0, op=68, ns=12537 In this particular case, there was no information about the client in the trace. This is atypical for a server trace. It may be that the client aborted before all the client information was posted to the file. However, there was post in the listener.log f or an emagent connection that was established at the same point in time. Here's an excerpt from a listener.log entry where an emagent establishes a connection: PROGRAM=D:\oracle\product\10.1.0\Db_1\bin\emagent.exe) Checked the EM Agent traces and logs and discovered the following entry: Fatal NI connect error 12547, connecting to: (LOCAL=NO) VERSION INFORMATION: TNS for Solaris: Version 11.1.0.7.0 - Production Oracle Bequeath NT Protocol Adapter for Solaris: Version 11.1.0.7.0 - Production TCP/IP NT Protocol Adapter for Solaris: Version 11.1.0.7.0 - Production Time: 16-NOV-2009 22:39:22 ****Tracing to file: /backup/sid_traces/sqlnetlog/svr_5233.trc Tns error struct: ns main err code: 12547 TNS-12547: TNS:lost contact ns secondary err code: 12560 nt main err code: 0 nt secondary err code: 0 nt OS err code: 0 ****Note the name of the server trace which contains the PID: svr_5233.trc Also, the timestamp of the agent event matches the timestamp of the alert.log error. Check the following locations for EM Agent traces. If working with support on this issue and the EM Agent is suspected, upload ALL files under: $ORACLE_HOME/sysman/log/emagent.trc < Single node agent trace location $ORACLE_HOME/host/sysman/log/emagent.trc < RAC agent trace location It was determined that in this case, the emagent was aborting the connection before it was complete and then simply reconnecting and succeeding on the subsequent try. No errors were reported in the listener log or listener trace. No errors were returned to the DB Console. There was no apparent outage of any kind. No action was taken to correct the ORA-609 in this case. It was decided that the message was informational and completely benign.
参考文档:
ORA-609 TNS-12537 and TNS-12547 in 11g Alert.log (Doc ID 1116960.1)
Troubleshooting Guide ORA-609 : Opiodr aborting process unknown ospid (Doc ID 1121357.1)
创建控制文件遭遇ORA-00600[3753]故障解决
一位网友的数据库正常关闭,然后控制文件意外丢失,需要通过trace中的信息重建控制文件,但是在重建的过程中,出现ORA-00600[3753]错误,远程帮忙处理,记录处理过程如下
1.启动数据库至nomount状态,然后尝试noresetlogs模式重建控制文件
SQL>@XFF_NORESETLOGS_CTL.sql CREATE CONTROLFILE REUSE DATABASE "ORA10G" NORESETLOGS ARCHIVELOG * 第 1 行出现错误: ORA-01503: CREATE CONTROLFILE 失败 ORA-00600: 内部错误代码, 参数: [3753], [3], [2], [], [], [], [], []
2.检查alert日志
Tue Aug 07 20:40:47 2012 WARNING: Default Temporary Tablespace not specified in CREATE DATABASE command Default Temporary Tablespace will be necessary for a locally managed database in future release Tue Aug 07 20:40:48 2012 Errors in file d:\oracle\product\10.2.0\db_1\admin\ora10g\udump\ora10g_ora_11596.trc: ORA-00600: 内部错误代码, 参数: [3753], [3], [2], [], [], [], [], [] Tue Aug 07 20:40:53 2012 Errors in file d:\oracle\product\10.2.0\db_1\admin\ora10g\udump\ora10g_ora_11596.trc: ORA-00600: 内部错误代码, 参数: [3753], [3], [2], [], [], [], [], [] ORA-1503 signalled during: CREATE CONTROLFILE REUSE DATABASE "ORA10G" NORESETLOGS ARCHIVELOG
3.分析trace文件
Tue Aug 07 20:40:48 2012 ORACLE V10.2.0.1.0 - Production vsnsta=0 vsnsql=14 vsnxtr=3 Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production With the Partitioning, OLAP and Data Mining options Windows NT Version V6.1 Service Pack 1 CPU : 2 - type 586, 2 Physical Cores Process Affinity : 0x00000000 Memory (Avail/Total): Ph:166M/1901M, Ph+PgF:619M/5536M, VA:812M/2047M Instance name: ora10g Redo thread mounted by this instance: 0 <none> Oracle process number: 16 Windows thread id: 11596, image: ORACLE.EXE (SHAD) *** SERVICE NAME:() 2012-08-07 20:40:48.413 *** SESSION ID:(158.7) 2012-08-07 20:40:48.413 *** 2012-08-07 20:40:48.413 ksedmp: internal or fatal error ORA-00600: 内部错误代码, 参数: [3753], [3], [2], [], [], [], [], [] Current SQL statement for this session: CREATE CONTROLFILE REUSE DATABASE "ORA10G" NORESETLOGS ARCHIVELOG ………… ----- Call Stack Trace ----- calling call entry argument values in hex location type point (? means dubious value) -------------------- -------- -------------------- ---------------------------- _ksedst+38 CALLrel _ksedst1+0 0 1 _ksedmp+898 CALLrel _ksedst+0 0 _ksfdmp+14 CALLrel _ksedmp+0 3 603A816A CALLreg 00000000 87CF110 3 603A83FF CALLrel 603A80D8 87CF110 8191090 EA9 2 8CCC438 _ksesic2+59 CALLrel _kgesiv+0 87CF110 8191090 EA9 2 8CCC438 EA9 2 8CCC438 __VInfreq__kctbce+1 CALLrel _ksesic2+0 EA9 0 3 0 0 2 0 63 _kcfccfl+356 CALLrel _kctbce+0 543414C 81DB8A8 _cdbdrv+1037 CALLrel _kcfccfl+0 543414C 1 8CCD060 8CCD04C 19000 3 _opiexe+11999 CALLrel _cdbdrv+0 1 _opiosq0+6088 CALLrel _opiexe+0 4 0 8CCD894 _kpooprx+232 CALLrel _opiosq0+0 3 E 8CCD9AC A4 _kpoal8+775 CALLrel _kpooprx+0 8CCF6CC 8196414 A16 1 0 A4 _opiodr+1099 CALLreg 00000000 5E 17 8CCF6C8 60FEFF8D CALLreg 00000000 5E 17 8CCF6C8 0 _opitsk+1017 CALL??? 00000000 _opiino+1087 CALLrel _opitsk+0 0 0 _opiodr+1099 CALLreg 00000000 3C 4 8CCFC60 _opidrv+819 CALLrel _opiodr+0 3C 4 8CCFC60 0 _sou2o+45 CALLrel _opidrv+0 3C 4 8CCFC60 _opimai_real+112 CALLrel _sou2o+0 8CCFC54 3C 4 8CCFC60 _opimai+92 CALLrel _opimai_real+0 2 8CCFC8C _OracleThreadStart@ CALLrel _opimai+0 4+708 __pRawDllMain+10931 CALLptr 00000000 2903 __pRawDllMain+12925 CALLreg 00000000 4809 __pRawDllMain+12925 CALLrel __pRawDllMain+12925 4761 4772 --------------------- Binary Stack Dump --------------------- ---------------------------------------- SO: 4FB3DF5C, type: 4, owner: 4FA4CBFC, flag: INIT/-/-/0x00 (session) sid: 158 trans: 4EBB8954, creator: 4FA4CBFC, flag: (41) USR/- BSY/-/-/-/-/- DID: 0000-0010-0000000A, short-term DID: 0000-0000-00000000 txn branch: 00000000 oct: 0, prv: 0, sql: 00000000, psql: 4F707298, user: 0/SYS O/S info: user: superv06-PC\superv06, term: SUPERV06-PC, ospid: 7788:11636, machine: WORKGROUP\SUPERV06-PC program: sqlplus.exe application name: sqlplus.exe, hash value=0 last wait for 'log file sequential read' blocking sess=0x00000000 seq=31 wait_time=159 seconds since wait started=0 log#=0, block#=1, blocks=1 Dumping Session Wait History for 'log file sequential read' count=1 wait_time=159 log#=0, block#=1, blocks=1 for 'log file sequential read' count=1 wait_time=502 log#=0, block#=1, blocks=1 for 'log file sequential read' count=1 wait_time=163 log#=0, block#=1, blocks=1 for 'db file sequential read' count=1 wait_time=18840 file#=ffffffff, block#=1, blocks=1 for 'db file sequential read' count=1 wait_time=254 file#=ffffffff, block#=1, blocks=1 for 'db file sequential read' count=1 wait_time=7654 file#=ffffffff, block#=1, blocks=1 for 'db file sequential read' count=1 wait_time=150 file#=ffffffff, block#=1, blocks=1 for 'db file sequential read' count=1 wait_time=102 file#=ffffffff, block#=1, blocks=1 for 'db file sequential read' count=1 wait_time=123 file#=ffffffff, block#=1, blocks=1 for 'db file sequential read' count=1 wait_time=14010 file#=ffffffff, block#=1, blocks=1
通过这里我们发现创建控制文件的进程在读取redo log的时候出现了等待比较多而且时间比较长,而对于ORA-00600[3753]错误互联网上没有任何更多的信息.通过对于创建控制文件时候因为使用noresetlogs的分析:这种模式下需要读取redo log,所以导致等待较多,从而出现ORA-00600[3753]错误使得创建控制文件失败.因为本库是shutdown immediate关闭,所以我们完全可以通过resetlogs模式来创建控制文件,从而避免读取redo log.
4.创建resetlogs控制文件
SQL>@XFF_RESETLOGS_CTL.sql Control file created.
5.然后不完全恢复使用resetlogs open数据库
这次的处理我也没有什么经验可以借鉴,MOS和互联网上没有该错误的任何信息,解决这个问题关键凭的是自己对于noresetlogs和resetlogs的理解.对于数据库原理的理解,对解决一些陌生问题帮助很大;在学习ORACLE过程中注重对原理的理解和消化