ASM丢失disk header导致ORA-15032、ORA-15040、ORA-15042 Diskgroup无法mount

本文档详细介绍了在Oracle 11g环境中遇到ASM(Automatic Storage Management)磁盘组无法挂载的问题,具体表现为ORA-15032、ORA-15040和ORA-15042错误。通过使用kfed工具进行检查和修复,包括验证disk header、手动恢复disk header等步骤,最终成功挂载diskgroup。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

SQL> select * from v$version;
BANNER
——————————————————————————–
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 – 64bit Production
PL/SQL Release 11.2.0.3.0 – Production
CORE 11.2.0.3.0 Production
TNS for Linux: Version 11.2.0.3.0 – Production
NLSRTL Version 11.2.0.3.0 – Production
SQL> alter diskgroup datadg mount;
alter diskgroup datadg mount
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15040: diskgroup is incomplete
ORA-15042: ASM disk “5” is missing from group number “1”
ERROR: alter diskgroup datadg mount
Wed Mar 13 07:42:03 2013
SQL> alter diskgroup datadg mount 
NOTE: cache registered group DATADG number=1 incarn=0xccb845cd
NOTE: cache began mount (first) of group DATADG number=1 incarn=0xccb845cd
NOTE: Assigning number (1,2) to disk (/dev/asm-diskg)
NOTE: Assigning number (1,1) to disk (/dev/asm-diskf)
NOTE: Assigning number (1,0) to disk (/dev/asm-diske)
Wed Mar 13 16:42:09 2013
NOTE: GMON heartbeating for grp 1
GMON querying group 1 at 20 for pid 27, osid 5439
NOTE: Assigning number (1,5) to disk ()
GMON querying group 1 at 21 for pid 27, osid 5439
NOTE: cache dismounting (clean) group 1/0xCCB845CD (DATADG) 
NOTE: messaging CKPT to quiesce pins Unix process pid: 5439, image: oracle@vmac1 (TNS V1-V3)
NOTE: dbwr not being msg’d to dismount
NOTE: lgwr not being msg’d to dismount
NOTE: cache dismounted group 1/0xCCB845CD (DATADG) 
NOTE: cache ending mount (fail) of group DATADG number=1 incarn=0xccb845cd
NOTE: cache deleting context for group DATADG 1/0xccb845cd
GMON dismounting group 1 at 22 for pid 27, osid 5439
NOTE: Disk in mode 0x8 marked for de-assignment
NOTE: Disk in mode 0x8 marked for de-assignment
NOTE: Disk in mode 0x8 marked for de-assignment
NOTE: Disk in mode 0x8 marked for de-assignment
ERROR: diskgroup DATADG was not mounted
ORA-15032: not all alterations performed
ORA-15040: diskgroup is incomplete
ORA-15042: ASM disk “5” is missing from group number “1” 
ERROR: alter diskgroup datadg mount
Wed Mar 13 16:42:10 2013
ASM Health Checker found 1 new failures
 
[grid@vmac1 ~]$ kfed read /dev/asm-diskh
kfbh.endian: 0 ; 0x000: 0x00
kfbh.hard: 0 ; 0x001: 0x00
kfbh.type: 0 ; 0x002: KFBTYP_INVALID
kfbh.datfmt: 0 ; 0x003: 0x00
kfbh.block.blk: 0 ; 0x004: blk=0
kfbh.block.obj: 0 ; 0x008: file=0
kfbh.check: 0 ; 0x00c: 0x00000000
kfbh.fcn.base: 0 ; 0x010: 0x00000000
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
7FA1DA233400 00000000 00000000 00000000 00000000 [................]
Repeat 255 times
KFED-00322: Invalid content encountered during block traversal: [kfbtTraverseBlock][Invalid OSM block type][][0]
col path for a20
set linesize 200 pagesize 1400
select path,header_status,state from v$asm_disk;
PATH HEADER_STATUS STATE
——————– ———————————— ————————
/dev/asm-diskh CANDIDATE NORMAL
/dev/asm-diskg MEMBER NORMAL
/dev/asm-diskf MEMBER NORMAL
/dev/asm-diske MEMBER NORMAL
/dev/asm-diskc MEMBER NORMAL
/dev/asm-diskd MEMBER NORMAL
/dev/asm-diskb MEMBER NORMAL
7 rows selected.
[grid@vmac1 ~]$ kfed repair /dev/asm-diskh
KFED-00320: Invalid block num1 = [0], num2 = [1], error = [endian_kfbh]
 
[grid@vmac1 ~]$ kfed repair /dev/asm-diskh ausz=1048576
KFED-00320: Invalid block num1 = [0], num2 = [1], error = [endian_kfbh]
 
关闭ASM实例
 
 
优先备份 问题ASM的header
dd if=<bad disk> of=<file> bs=4096 count=1
 
 
3. 检查现有磁盘找出拥有file 1 block 1的
[grid@vmac1 ~]$ kfed read /dev/asm-diske |grep f1b1
kfdhdb.f1b1locn: 2 ; 0x0d4: 0x00000002
[grid@vmac1 ~]$ 
[grid@vmac1 ~]$ kfed read /dev/asm-diskf |grep f1b1 
kfdhdb.f1b1locn: 0 ; 0x0d4: 0x00000000
[grid@vmac1 ~]$ kfed read /dev/asm-diskg |grep f1b1 
kfdhdb.f1b1locn: 0 ; 0x0d4: 0x00000000
 
这里asm-diske上出现了f1b1非零值,则其拥有file 1 block 1,可以通过检查第二个au的类型是否是KFBTYP_LISTHEAD来确认
[grid@vmac1 ~]$ kfed read /dev/asm-diske aun=2|grep kfbh.type
kfbh.type: 5 ; 0x002: KFBTYP_LISTHEAD
 
 
若丢失的磁盘包含了”file 1 block 1 F1B1″则扫描 该磁盘上所有的 AU直到找到KFBTYP_LISTHEAD , 如果找不到LISTHEAD 那么别无选择只能重建diskgroup。
 
从版本11.1.0.7开始(10g是从10.2.0.5开始,所以尽量别用10.2.0.5之前的版本上的ASM),当每一个I/O写提交向ASM disk header(AU 0 blocknum 0),都会复制到 AU 1中,最后第二个块。基于不同的AU size,该块的位置不同
Allocation Unit Size Block Number on AU 1
1048576 254
4194304 1022
8388608 2046
16777216 4094
 
首先使用kfed 验证该位置是否有正确的disk header,否则手动找到合适的header。 表1如参考:
[grid@vmac1 ~]$ kfed read /dev/asm-diske ausz=1048576 aun=1 blkn=254|less 
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 1 ; 0x002: KFBTYP_DISKHEAD
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 254 ; 0x004: blk=254
kfbh.block.obj: 2147483648 ; 0x008: disk=0
kfbh.check: 2086475720 ; 0x00c: 0x7c5d17c8
kfbh.fcn.base: 31322 ; 0x010: 0x00007
<think>我们正在处理一个Oracle ASM(自动存储管理)相关的问题,用户遇到了两个错误:ORA-15032ORA-15028。具体场景是在尝试删除ASM文件时,因为文件正在被访问而无法删除。根据引用[1]和引用[4]:-引用[1]提到在添加ASM磁盘时遇到ORA-15032ORA-15137,原因是ASM处于滚动(rolling)状态,或者可能由于补丁问题导致ASM状态异常。 -引用[4]展示了在尝试向磁盘组添加磁盘时遇到ORA-15032ORA-15411,原因是故障组中的磁盘数量不一致。但是用户当前的问题是在删除ASM文件时遇到的,所以我们需要针对文件删除操作进行分析。错误解释: -ORA-15032:表示操作无法执行(notall alterationsperformed),通常意味着ASM操作由于某种原因未能完成。 -ORA-15028:表示ASM文件删除失败,因为文件正在被使用(file isbeingaccessed)。因此,核心问题是在删除ASM文件时,该文件正被某个数据库实例或进程使用,导致删除失败。 解决方案步骤:1.**确认文件使用情况**:我们需要找出哪个数据库实例或进程正在使用该文件。可以通过查询`V$ASM_CLIENT`视图来查看哪些客户端(数据库实例)正在访问该ASM磁盘组。2.**停止使用文件的实例或进程**:如果可能,停止访问该文件的数据库实例或进程,然后重试删除操作。3.**强制删除**:如果无法停止使用,可以尝试使用`FORCE`选项进行删除,但需谨慎,因为可能导致数据库问题。4.**检查ASM磁盘组状态**:确保ASM磁盘组处于正常状态(MOUNTED),并且没有进行中的操作。具体操作: 步骤1:查询正在访问该文件的客户端```sqlSELECT group_number,file_number, client_name,statusFROMV$ASM_CLIENTWHERE file_number =<file_number>;--替换为要删除的文件号```或者,如果不知道文件号,可以通过文件名查询:```sqlSELECTg.name diskgroup, a.name file_name, c.client_name, c.statusFROM V$ASM_ALIASa,V$ASM_CLIENTc,V$ASM_DISKGROUPgWHERE a.name='<file_name>'--替换为要删除的文件名AND a.group_number= g.group_numberAND a.group_number= c.group_numberAND a.file_number= c.file_number; ```步骤2:如果发现客户端正在使用,尝试停止该客户端(如关闭数据库实例),然后删除文件。步骤3:使用`FORCE`选项删除文件(如果步骤2无法进行): ```sqlALTER DISKGROUP<diskgroup_name>DROP FILE'<file_name>'FORCE; ```注意:使用`FORCE`选项会强制删除文件,即使文件正在被访问。这可能导致数据库实例崩溃或数据损坏,因此只有在确定文件不再需要或无法停止客户端时才使用。步骤4:如果上述方法无效,检查ASM磁盘组状态: ```sqlSELECT name, stateFROM V$ASM_DISKGROUP;``` 确保磁盘组状态为`MOUNTED`,并且没有其他异常。另外,参考引用[3]提到的ORA-00600错误,如果问题与BUG相关,可能需要应用补丁。但当前错误是ORA-15028,通常与文件使用有关,所以先尝试上述步骤。 如果问题仍然存在,考虑重启ASM实例(作为最后手段),但需注意会影响所有依赖该ASM实例的数据库。 总结解决方案:1.识别并停止访问文件的客户端。2.尝试强制删除。3.检查磁盘组状态和ASM实例状态。4.如果怀疑是BUG,检查MOS(MyOracle Support)是否有相关补丁。生成相关问题: §§相关问题§§1.如何查询ASM中文件的使用情况? 2.强制删除ASM文件有什么风险?3.如何安全地重启ASM实例?4.在Oracle19c中,常见的ASM文件管理操作有哪些?5.ORA-15028错误的常见原因和解决方法有哪些?</think>### Oracle 19c 解决 ORA-15032ORA-15028 错误(ASM文件无法删除) 在Oracle 19c中删除ASM文件时遇到ORA-15032(操作未完全执行)和ORA-15028(文件正在被访问)错误,通常是由于文件被数据库进程占用导致。以下是系统化的解决方案: #### 1. **确认文件占用状态** 首先检查文件是否被数据库会话锁定: ```sql SELECT g.name AS diskgroup, a.name AS file_name, c.client_name, c.status FROM V$ASM_ALIAS a JOIN V$ASM_CLIENT c ON a.file_number = c.file_number JOIN V$ASM_DISKGROUP g ON a.group_number = g.group_number WHERE a.name = '&your_file_name'; -- 替换为实际文件名 ``` - 输出会显示访问该文件的数据库实例(`client_name`)和状态(`CONNECTED`表示正在使用)[^1][^4]。 #### 2. **终止占用会话** - **方案1:停止访问文件的数据库实例** ```sql ALTER SYSTEM KILL SESSION 'sid,serial#' IMMEDIATE; -- 替换为V$SESSION查到的SID和SERIAL# ``` - **方案2:重启占用实例**(谨慎操作): ```sql SHUTDOWN IMMEDIATE; STARTUP; ``` #### 3. **强制删除文件(高风险操作)** 如果无法终止会话,使用`FORCE`选项强制删除: ```sql ALTER DISKGROUP your_dg_name DROP FILE '+your_dg_name/your_file_path' FORCE; ``` > **警告**:强制删除可能导致数据库崩溃或数据损坏,仅在紧急情况下使用[^1][^4]。 #### 4. **检查ASM磁盘组状态** 磁盘组状态异常会引发ORA-15032: ```sql SELECT name, state FROM V$ASM_DISKGROUP; ``` - 若状态非`MOUNTED`,尝试重挂载: ```sql ALTER DISKGROUP your_dg_name DISMOUNT; ALTER DISKGROUP your_dg_name MOUNT; ``` #### 5. **验证补丁和BUG** ORA-15032可能与Oracle BUG相关: - 检查当前版本是否有已知BUG: ```sql SELECT * FROM V$VERSION; ``` - 参考MOS文档(如Doc ID 2795196.1)确认是否存在`kfmdPriRegRclient04`相关BUG[^3]。 - 若存在BUG,需应用补丁(如Bug 34345080的修复补丁)。 #### 6. **检查操作系统资源** ORA-15028可能伴随操作系统资源不足: - 检查内核缓冲区空间: ```shell # Linux系统检查 sysctl net.ipv4.tcp_mem free -m ``` - 若`No buffer space available`(引用[2]),需调整内核参数或释放内存。 > **最佳实践**:在非高峰时段执行删除操作,并提前确认文件无活跃访问。定期监控ASM磁盘组均衡性(避免触发ORA-15411故障组不匹配问题)[^4]。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值