标签云
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,882)
- DB2 (22)
- MySQL (82)
- Oracle (1,707)
- 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备份恢复 (661)
- 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)
-
最近发表
- 断电引起ORA-600 3005故障处理
- 记录一次云存储资源到期之后引起的数据库恢复
- Firebird 损坏数据库数据抢救工具—firebirdext
- 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
ORA-00600[kjhn_post_ha_alert0-862]原因分析
数据库版本和平台信息
数据库版本为10.2.0.1版本,而且是32位的win 2003 sp2之上
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 Server 2003 Version V5.2 Service Pack 2 CPU : 2 - type 586, 1 Physical Cores Process Affinity : 0x00000000 Memory (Avail/Total): Ph:2608M/3990M, Ph+PgF:4511M/5871M, VA:1242M/2047M Instance name: orcl
数据库报大量ORA-600[kjhn_post_ha_alert0-862]错误
数据库的mmon进程报大量ORA-00600: internal error code, arguments: [kjhn_post_ha_alert0-862], [], [], [], [], [], [], []错误
Wed Jun 03 21:50:40 2015 Restarting dead background process MMON MMON started with pid=11, OS id=3804 Wed Jun 03 21:50:43 2015 Errors in file e:\oracle\product\10.2.0\admin\orcl\bdump\orcl_mmon_3804.trc: ORA-00600: internal error code, arguments: [kjhn_post_ha_alert0-862], [], [], [], [], [], [], [] Wed Jun 03 21:50:49 2015 Errors in file e:\oracle\product\10.2.0\admin\orcl\bdump\orcl_mmon_3804.trc: ORA-00600: internal error code, arguments: [kjhn_post_ha_alert0-862], [], [], [], [], [], [], [] Wed Jun 03 21:55:44 2015 Errors in file e:\oracle\product\10.2.0\admin\orcl\bdump\orcl_mmon_3804.trc: ORA-00600: internal error code, arguments: [kjhn_post_ha_alert0-862], [], [], [], [], [], [], [] Wed Jun 03 21:55:49 2015 Errors in file e:\oracle\product\10.2.0\admin\orcl\bdump\orcl_mmon_3804.trc: ORA-00600: internal error code, arguments: [kjhn_post_ha_alert0-862], [], [], [], [], [], [], [] Wed Jun 03 22:00:40 2015 Thread 1 advanced to log sequence 476 Current log# 1 seq# 476 mem# 0: E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO01.LOG Wed Jun 03 22:00:44 2015 Errors in file e:\oracle\product\10.2.0\admin\orcl\bdump\orcl_mmon_3804.trc: ORA-00600: internal error code, arguments: [kjhn_post_ha_alert0-862], [], [], [], [], [], [], []
查询对应trace文件发现
ORA-00600: internal error code, arguments: [kjhn_post_ha_alert0-862], [], [], [] , [], [], [], [] Current SQL statement for this session: BEGIN :success := dbms_ha_alerts_prvt.check_ha_resources; END;
人工执行该过程
SQL> var success varchar2 SQL> begin 2 :success := sys.dbms_ha_alerts_prvt.check_ha_resources; 3 end; 4 / PL/SQL procedure successfully completed. SQL> print success SUCCESS -------------------------------- N
通过查询相关资料得到如下说明
@ This check is triggered with FAN enabled at this instance and it seems to be @ associated with a startup action. From the procedure itself which is called @ this is a run-once MMON (startup) action which supports instance down @ notification reliability. It does the folowing a) registers the current @ instance incarnation in recent_resource_incarnations$ if it's not already @ there b) deletes recent_resource_incarnations$ records that don't apply to @ this database. They may, e.g., have been copied from seed db or from a former @ DataGuard primary c) scans recent_resource_incarnations$ for instance @ incarnations that are no longer alive, and submits instance down alerts for @ them . If all is good then return 'Y' else 'N' (or error) if there is a @ failure. That failure is to get back to MMON, so that it may retry this @ action later. In the local instance I get a 'Y' but in the customer's system @ it fails with a 'N' which seems related to the ORA-600 assert. @ This function is kjhn_post_ha_alert0() which is internal and does the real work of @ posting HA alerts. It is used by both kjhn_post_ha_alert and @ kjn_post_ha_alert_plsql. Its parameters are basically the same as those of @ kjhn_post_ha_alert,other than the fact that it uses individual parameters @ rather than the more easily extensible structure. Also the parameters passed @ to it are the instance_name and the host_name which is the kernelized @ implementation for posting HA alerts. Without actually having the arguments @ the guess is that either the host_name or the instance_name raised in the @ assert is null which triggered it.
mmon进程尝试调用相关程序,然后无法得出正确值,返回N,然后会一直尝试,如果不能得到返回Y,就会一直报ORA-600,错误.通过上述的三种情况来说,都和recent_resource_incarnations$表有关系.
该故障原因是由于:mmon在调用kjhn_post_ha_alert0函数在执行的时候,如果发现参数host_name或者instance_name为null,就会报该错误出来.
处理方法
This problem has been documented as Bug 5173066 REPEATED ORA-600 [KJHN_POST_HA_ALERT0-862] FROM MMON PROCESS.
The bug is fixed in 11.1.0.6. A workaround is available for the problem.
该bug在11.1.0.6中得以修复
To implement the workaround, please execute the following steps as the SYS user:
1. Collect the following information and spool it to a file for your records.
a. output of select * from v$instance
b. show parameter instance_name
c. set pages 1000
d. select * from recent_resource_incarnations$
2. Create a backup table of recent_resource_incarnations$.
SQL> create table recent_resource_inc$bk as select * from recent_resource_incarnations$;
3. Truncate recent_resource_incarnations$. Be sure to do this while the instance is up and running.
Do not issue this statement if a shutdown is pending.
SQL> truncate table recent_resource_incarnations$;
4. Perform a clean shutdown, followed by a startup.
具体参考:
ORA-600 [kjhn_post_ha_alert0-862] Continuously Repeated in the Alert Log (Doc ID 401640.1)
Bug 5173066 : REPEATED ORA-600 [KJHN_POST_HA_ALERT0-862] FROM MMON PROCESS
记录解决一次Listener状态为Not All Endpoints Registered的故障
客户反馈系统异常无法正常访问,检查发现监听异常
C:\Users\Administrator>crsctl status res -t
--------------------------------------------------------------------------------
NAME TARGET STATE SERVER STATE_DETAILS
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.DATA.dg
ONLINE ONLINE rac2
ora.LISTENER.lsnr
ONLINE INTERMEDIATE rac2 Not All Endpoints R
egistered
ora.asm
ONLINE ONLINE rac2 Started
ora.gsd
OFFLINE OFFLINE rac2
ora.net1.network
ONLINE ONLINE rac2
ora.ons
ONLINE ONLINE rac2
ora.registry.acfs
ONLINE ONLINE rac2
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.LISTENER_SCAN1.lsnr
1 ONLINE INTERMEDIATE rac2 Not All Endpoints R
egistered
ora.cvu
1 ONLINE ONLINE rac2
ora.oc4j
1 ONLINE ONLINE rac2
ora.rac.db
1 ONLINE ONLINE rac2 Open
2 ONLINE OFFLINE
ora.rac1.vip
1 ONLINE OFFLINE
ora.rac2.vip
1 ONLINE OFFLINE
ora.scan1.vip
1 ONLINE OFFLINE
C:\Users\Administrator>lsnrctl status
LSNRCTL for 64-bit Windows: Version 11.2.0.3.0 - Production on 12-6月 -2015 15:50:43
Copyright (c) 1991, 2011, Oracle. All rights reserved.
正在连接到 (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
LISTENER 的 STATUS
------------------------
别名 LISTENER
版本 TNSLSNR for 64-bit Windows: Version 11.2.0.3.0 - Production
启动日期 12-6月 -2015 15:31:30
正常运行时间 0 天 0 小时 19 分 20 秒
跟踪级别 off
安全性 ON: Local OS Authentication
SNMP OFF
监听程序参数文件 D:\app\11.2.0\grid\network\admin\listener.ora
监听程序日志文件 D:\app\11.2.0\grid\log\diag\tnslsnr\rac2\listener\alert\log.xml
监听端点概要...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(PIPENAME=\\.\pipe\LISTENERipc)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=10.63.64.70)(PORT=1521)))
监听程序不支持服务
命令执行成功
通过这里可以看到LISTENER和LISTENER_SCAN1为Not All Endpoints Registered状态,而且这个RAC只有一个节点rac2,rac1节点未加入到集群中.进一步检查IP和hosts文件
C:\Users\Administrator>ipconfig -all
Windows IP 配置
主机名 . . . . . . . . . . . . . : rac2
主 DNS 后缀 . . . . . . . . . . . :
节点类型 . . . . . . . . . . . . : 混合
IP 路由已启用 . . . . . . . . . . : 否
WINS 代理已启用 . . . . . . . . . : 否
以太网适配器 pub:
连接特定的 DNS 后缀 . . . . . . . :
描述. . . . . . . . . . . . . . . : Intel(R) 82576 Gigabit Dual Port Network Connection #2
物理地址. . . . . . . . . . . . . : 00-25-90-5A-0F-47
DHCP 已启用 . . . . . . . . . . . : 否
自动配置已启用. . . . . . . . . . : 是
本地链接 IPv6 地址. . . . . . . . : fe80::c5ef:663f:7333:45f2%12(首选)
IPv4 地址 . . . . . . . . . . . . : 10.63.64.70(首选)
子网掩码 . . . . . . . . . . . . : 255.255.255.192
默认网关. . . . . . . . . . . . . : 10.63.64.126
DHCPv6 IAID . . . . . . . . . . . : 301999504
DHCPv6 客户端 DUID . . . . . . . : 00-01-00-01-1A-5C-19-A1-00-25-90-5A-0F-46
DNS 服务器 . . . . . . . . . . . : 218.30.19.40
TCPIP 上的 NetBIOS . . . . . . . : 已启用
以太网适配器 priv:
连接特定的 DNS 后缀 . . . . . . . :
描述. . . . . . . . . . . . . . . : Intel(R) 82576 Gigabit Dual Port Network Connection
物理地址. . . . . . . . . . . . . : 00-25-90-5A-0F-46
DHCP 已启用 . . . . . . . . . . . : 否
自动配置已启用. . . . . . . . . . : 是
本地链接 IPv6 地址. . . . . . . . : fe80::c88d:78ff:d2e8:bde1%11(首选)
IPv4 地址 . . . . . . . . . . . . : 10.10.1.2(首选)
子网掩码 . . . . . . . . . . . . : 255.255.255.0
默认网关. . . . . . . . . . . . . :
DHCPv6 IAID . . . . . . . . . . . : 234890640
DHCPv6 客户端 DUID . . . . . . . : 00-01-00-01-1A-5C-19-A1-00-25-90-5A-0F-46
DNS 服务器 . . . . . . . . . . . : fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
TCPIP 上的 NetBIOS . . . . . . . : 已启用
--hosts文件
10.63.64.69 rac1
10.63.64.70 rac2
10.63.64.71 rac1-vip
10.63.64.72 rac2-vip
10.63.64.73 scan-cluster
10.10.1.1 rac1-priv
10.10.1.2 rac2-priv
这里可以看到主机之上的pub网卡只有一个ip 10.63.64.70,不太符合我们对rac的理解(一般来说其上应该有vip,部分情况下甚至可能有scan ip),尝试ping vip和scan ip
C:\Users\Administrator>ping 10.63.64.72
正在 Ping 10.63.64.72 具有 32 字节的数据:
来自 10.63.64.72 的回复: 字节=32 时间<1ms TTL=128
来自 10.63.64.72 的回复: 字节=32 时间<1ms TTL=128
来自 10.63.64.72 的回复: 字节=32 时间<1ms TTL=128
10.63.64.72 的 Ping 统计信息:
数据包: 已发送 = 3,已接收 = 3,丢失 = 0 (0% 丢失),
往返行程的估计时间(以毫秒为单位):
最短 = 0ms,最长 = 0ms,平均 = 0ms
Control-C
^C
C:\Users\Administrator>ping 10.63.64.73
正在 Ping 10.63.64.73 具有 32 字节的数据:
来自 10.63.64.73 的回复: 字节=32 时间<1ms TTL=128
来自 10.63.64.73 的回复: 字节=32 时间<1ms TTL=128
来自 10.63.64.73 的回复: 字节=32 时间<1ms TTL=128
10.63.64.73 的 Ping 统计信息:
数据包: 已发送 = 3,已接收 = 3,丢失 = 0 (0% 丢失),
往返行程的估计时间(以毫秒为单位):
最短 = 0ms,最长 = 0ms,平均 = 0ms
这里发现一个异常问题:crs显示只有rac2在集群之中,而该主机ip中又不存在vip和scan ip属于异常情况,但是这两个ip又可以ping通,基于这样情况,我第一反应就是vip和scanip可能飘到rac1中了,而rac1又未正常加入到crs中(因为这个库以前处理过,由于rac1的hba卡有问题,数据库无法正常启动,crs起来也无法提供工作),检查rac1机器情况
C:\Users\Administrator>crsctl status res -t
CRS-4535: 无法与集群就绪服务通信
CRS-4000: 命令 Status 失败, 或已完成但出现错误。
C:\Users\Administrator>crsctl status res -t -init
--------------------------------------------------------------------------------
NAME TARGET STATE SERVER STATE_DETAILS
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.asm
1 ONLINE ONLINE rac1 Started
ora.crf
1 ONLINE ONLINE rac1
ora.crsd
1 ONLINE OFFLINE
ora.cssd
1 ONLINE ONLINE rac1
ora.cssdmonitor
1 ONLINE ONLINE rac1
ora.ctssd
1 ONLINE ONLINE rac1 OBSERVER
ora.drivers.acfs
1 ONLINE ONLINE rac1
ora.evmd
1 ONLINE ONLINE rac1
ora.gipcd
1 ONLINE ONLINE rac1
ora.gpnpd
1 ONLINE ONLINE rac1
ora.mdnsd
1 ONLINE ONLINE rac1
以太网适配器 pub:
连接特定的 DNS 后缀 . . . . . . . :
描述. . . . . . . . . . . . . . . : Intel(R) 82576 Gigabit Dual Port Network Connection
物理地址. . . . . . . . . . . . . : 00-25-90-5A-0E-E7
DHCP 已启用 . . . . . . . . . . . : 否
自动配置已启用. . . . . . . . . . : 是
本地链接 IPv6 地址. . . . . . . . : fe80::409d:8c2e:446b:af42%11(首选)
IPv4 地址 . . . . . . . . . . . . : 10.63.64.69(首选)
子网掩码 . . . . . . . . . . . . : 255.255.255.192
IPv4 地址 . . . . . . . . . . . . : 10.63.64.71(首选)
子网掩码 . . . . . . . . . . . . : 255.255.255.192
IPv4 地址 . . . . . . . . . . . . : 10.63.64.72(首选)
子网掩码 . . . . . . . . . . . . : 255.255.255.192
IPv4 地址 . . . . . . . . . . . . : 10.63.64.73(首选)
子网掩码 . . . . . . . . . . . . : 255.255.255.192
默认网关. . . . . . . . . . . . . : 10.63.64.126
DHCPv6 IAID . . . . . . . . . . . : 234890640
DHCPv6 客户端 DUID . . . . . . . : 00-01-00-01-1A-5C-19-0A-00-25-90-5A-0E-E7
DNS 服务器 . . . . . . . . . . . : 8.8.8.8
TCPIP 上的 NetBIOS . . . . . . . : 已启用
以太网适配器 priv:
连接特定的 DNS 后缀 . . . . . . . :
描述. . . . . . . . . . . . . . . : Intel(R) 82576 Gigabit Dual Port Network Connection #2
物理地址. . . . . . . . . . . . . : 00-25-90-5A-0E-E6
DHCP 已启用 . . . . . . . . . . . : 否
自动配置已启用. . . . . . . . . . : 是
本地链接 IPv6 地址. . . . . . . . : fe80::154:dad7:f9e3:bea3%13(首选)
IPv4 地址 . . . . . . . . . . . . : 10.10.1.1(首选)
子网掩码 . . . . . . . . . . . . : 255.255.255.0
默认网关. . . . . . . . . . . . . :
DHCPv6 IAID . . . . . . . . . . . : 301999504
DHCPv6 客户端 DUID . . . . . . . : 00-01-00-01-1A-5C-19-0A-00-25-90-5A-0E-E7
DNS 服务器 . . . . . . . . . . . : fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
TCPIP 上的 NetBIOS . . . . . . . : 已启用
果然这里rac2的vip和scan ip都漂到rac1中,但是crs状态属于不正常情况,由于rac1无法正常使用,关闭该主机,并重启rac2(由于rac2处于异常情况无法正常工作),后续rac2恢复正常
C:\Users\Administrator>crsctl status res -t
--------------------------------------------------------------------------------
NAME TARGET STATE SERVER STATE_DETAILS
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.DATA.dg
ONLINE ONLINE rac2
ora.LISTENER.lsnr
ONLINE ONLINE rac2
ora.asm
ONLINE ONLINE rac2 Started
ora.gsd
OFFLINE OFFLINE rac2
ora.net1.network
ONLINE ONLINE rac2
ora.ons
ONLINE ONLINE rac2
ora.registry.acfs
ONLINE ONLINE rac2
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.LISTENER_SCAN1.lsnr
1 ONLINE ONLINE rac2
ora.cvu
1 ONLINE ONLINE rac2
ora.oc4j
1 ONLINE ONLINE rac2
ora.rac.db
1 OFFLINE OFFLINE Instance Shutdown
2 ONLINE ONLINE rac2 Open
ora.rac1.vip
1 ONLINE INTERMEDIATE rac2 FAILED OVER
ora.rac2.vip
1 ONLINE ONLINE rac2
ora.scan1.vip
1 ONLINE ONLINE rac2
C:\Users\Administrator>lsnrctl status
LSNRCTL for 64-bit Windows: Version 11.2.0.3.0 - Production on 12-6月 -2015 17:02:46
Copyright (c) 1991, 2011, Oracle. All rights reserved.
正在连接到 (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
LISTENER 的 STATUS
------------------------
别名 LISTENER
版本 TNSLSNR for 64-bit Windows: Version 11.2.0.3.0 - Production
启动日期 12-6月 -2015 16:44:43
正常运行时间 0 天 0 小时 18 分 3 秒
跟踪级别 off
安全性 ON: Local OS Authentication
SNMP OFF
监听程序参数文件 D:\app\11.2.0\grid\network\admin\listener.ora
监听程序日志文件 D:\app\11.2.0\grid\log\diag\tnslsnr\rac2\listener\alert\log.xml
监听端点概要...
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(PIPENAME=\\.\pipe\LISTENERipc)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=10.63.64.70)(PORT=1521)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=10.63.64.72)(PORT=1521)))
服务摘要..
服务 "+ASM" 包含 1 个实例。
实例 "+asm2", 状态 READY, 包含此服务的 1 个处理程序...
服务 "rac" 包含 1 个实例。
实例 "rac2", 状态 READY, 包含此服务的 1 个处理程序...
服务 "racXDB" 包含 1 个实例。
实例 "rac2", 状态 READY, 包含此服务的 1 个处理程序...
命令执行成功
出现该问题的原因至此可以总结出来:由于rac1和rac2的集群处于异常状态,rac1持有了vip和scan ip,但是又未正常加入crs,导致rac2无法获得vip和scan ip,从而使得LISTENER和LISTENER_SCAN1为Not All Endpoints Registered状态.另外对于不能正常工作的集群节点,建议关闭crs,甚至可以考虑关闭主机,减少异常节点对正常节点的影响.关于该类问题的分析,可以从Scan Listener In INTERMEDIATE Mode Not All Endpoints Registered (Doc ID 1667873.1)中找到依据,证明是由于IP被占用导致.
ORA-00230: operation disallowed: snapshot control file enqueue unavailable
rman 备份控制文件报ORA-00230: operation disallowed: snapshot control file enqueue unavailable错误
db1:/home/oracle>$rman target / Recovery Manager: Release 10.2.0.3.0 - Production on Wed Jun 10 16:00:08 2015 Copyright (c) 1982, 2005, Oracle. All rights reserved. connected to target database: ORCL (DBID=1150889877) RMAN> backup current controlfile format '/tmp/xifenfei.ctl'; Starting backup at 10-JUN-15 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=628 instance=orcl1 devtype=DISK channel ORA_DISK_1: starting full datafile backupset channel ORA_DISK_1: specifying datafile(s) in backupset waiting for snapshot control file enqueue waiting for snapshot control file enqueue waiting for snapshot control file enqueue waiting for snapshot control file enqueue waiting for snapshot control file enqueue cannot make a snapshot control file RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03009: failure of backup command on ORA_DISK_1 channel at 06/10/2015 16:03:10 ORA-00230: operation disallowed: snapshot control file enqueue unavailable
查看持有CF enqueue会话
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning, Real Application Clusters, OLAP and Data Mining options
SQL> SELECT s.SID, USERNAME AS "User", PROGRAM, MODULE,
2 ACTION, LOGON_TIME "Logon"
3 FROM V$SESSION s, V$ENQUEUE_LOCK l
4 WHERE l.SID = s.SID
5 AND l.TYPE = 'CF'
6 AND l.ID1 = 0
7 AND l.ID2 = 2;
SID User
---------- ------------------------------
PROGRAM
------------------------------------------------
MODULE
------------------------------------------------
ACTION Logon
-------------------------------- ------------
648 SYS
rman@db1 (TNS V1-V3)
backup full datafile
0000152 STARTED111 03-JUN-15
kill相关session
SQL> select spid from v$process where addr in(select paddr from v$session where sid=648); SPID ------------ 40108238 SQL> !ps -ef|grep 40108238 oracle 39125244 65011720 0 15:59:27 pts/0 0:00 grep 40108238 oracle 40108238 1 0 Jun 03 - 1:18 oracleorcl1 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq))) db1:/home/oracle>$kill -9 40108238
再次测试备份控制文件–OK
db1:/home/oracle>$rman target / Recovery Manager: Release 10.2.0.3.0 - Production on Wed Jun 10 16:05:06 2015 Copyright (c) 1982, 2005, Oracle. All rights reserved. connected to target database: ORCL (DBID=1150889877) RMAN> backup current controlfile format '/tmp/xifenfei.ctl'; Starting backup at 10-JUN-15 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=632 instance=orcl1 devtype=DISK channel ORA_DISK_1: starting full datafile backupset channel ORA_DISK_1: specifying datafile(s) in backupset including current control file in backupset channel ORA_DISK_1: starting piece 1 at 10-JUN-15 channel ORA_DISK_1: finished piece 1 at 10-JUN-15 piece handle=/tmp/xifenfei.ctl tag=TAG20150610T160516 comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02 Finished backup at 10-JUN-15

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

