How to move ASM spfile to a different disk group [ID 1082943.1]

本文介绍如何将Oracle ASM spfile从一个磁盘组移动到另一个磁盘组的方法,包括使用中间pfile的方式及使用'asmcmdspcopy'命令的步骤。

How to move ASM spfile to a different disk group [ID 1082943.1]


Goal
The goal is to move ASM spfile from one disk group to another.

During initial ASM setup the spfile might have been created in a default disk group (e.g. DATA). The requirement is now to move the ASM spfile to another disk group.

According to Oracle ASM documentation it should be possible to use 'asmcmd spmove' command to move ASM spfile:

Oracle Database Storage Administrator's Guide 11g Release 2 (11.2)
Section ASMCMD Instance Management Commands

spmove

Purpose: Moves an Oracle ASM SPFILE from source to destination and automatically updates the GPnP profile.

But an attempt to move the ASM spfile fails as follows:

$ asmcmd spmove +DATA/asm/asmparameterfile/REGISTRY.253.715881237 +PLAY/spfileASM.ora
ORA-15032: not all alterations performed
ORA-15028: ASM file '+DATA/asm/asmparameterfile/REGISTRY.253.715881237' not dropped; currently being accessed (DBD ERROR: OCIStmtExecute)


Solution

To move ASM spfile to another disk group, either make use of intermediate pfile:

1.Create intermediate pfile from the current spfile
2.Create spfile in a new disk group from the intermediate pfile
3.Restart the HA stack to verify that ASM starts up fine with moved spfile
4.Remove the original spfile

or use 'asmcmd spcopy' command

1.Copy spfile with -u option - to update GPnP profile in RAC environment
2.Restart the HA stack to verify that ASM starts up fine with copiedspfile
3.Remove the original spfile
This is an example of moving ASM spfile in a single instance environment, by making use intermediate pfile

1. Create intermediate pfile from the current spfile

$ sqlplus / as sysasm
SQL*Plus: Release 11.2.0.1.0 Production on <date>
Copyright (c) 1982, 2009, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Automatic Storage Management option

SQL> show parameter spfile

NAME TYPE VALUE
------- ------- --------------------------------------------------
spfile string +DATA/asm/asmparameterfile/registry.253.715881237

SQL> create pfile='/tmp/pfile+ASM.ora' from spfile;

File created.


2. Create spfile in a new disk group from the intermediate pfile

SQL> create spfile='+PLAY' from pfile='/tmp/pfile+ASM.ora';

File created.

SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Automatic Storage Management option


3. Restart the HA stack to verify that ASM starts up fine with moved spfile

$ crsctl stop has
CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on '<server>'
...
CRS-4133: Oracle High Availability Services has been stopped.

$ crsctl start has
CRS-4123: Oracle High Availability Services has been started.


Verify that the new spfile is being used

$ sqlplus / as sysasm

SQL*Plus: Release 11.2.0.1.0 Production on <date>
Copyright (c) 1982, 2009, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Automatic Storage Management option

SQL> show parameter spfile

NAME TYPE VALUE
------- ------- --------------------------------------------------
spfile string +PLAY/asm/asmparameterfile/registry.253.715963539

SQL> select name, state from v$asm_diskgroup;

NAME STATE
----- -----------
DATA MOUNTED
PLAY MOUNTED

SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Automatic Storage Management option
The use of new spfile can also be verified with asmcmd as follows:

$ asmcmd spget
+PLAY/asm/asmparameterfile/registry.253.715963539
4. Remove the original spfile

$ asmcmd rm +DATA/asm/asmparameterfile/registry.253.715881237

And this is an example of moving ASM spfile with 'asmcmd spcopy'

1. Copy spfile with -u option - to update GPnP profile in RAC environment

$ asmcmd spget
+DATA/asm/asmparameterfile/registry.253.722601213

$ asmcmd lsdg
State Type Rebal Sector Block AU Total_MB Free_MB Req_mir_free_MB Usable_file_MB Offline_disks Votin g_files Name
MOUNTED EXTERN N 512 4096 1048576 14658 9814 0 9814 0 N DATA/
MOUNTED EXTERN N 512 4096 1048576 9772 8507 0 8507 0 N PLAY/
MOUNTED EXTERN N 512 4096 1048576 9772 9212 0 9212 0 N RECO/

$ asmcmd spcopy -u +DATA/asm/asmparameterfile/registry.253.722601213 +PLAY/spfileASM.ora
2. Restart the HA stack to verify that ASM starts up fine with copiedspfile

$ crsctl stop has
CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on '<server>'
...
CRS-4133: Oracle High Availability Services has been stopped.

$ crsctl start has
CRS-4123: Oracle High Availability Services has been started.

$ asmcmd spget
+PLAY/spfileASM.ora
3. Remove the original spfile

$ asmcmd ls -l +DATA/asm/asmparameterfile
Type Redund Striped Time Sys Name
ASMPARAMETERFILE UNPROT COARSE JUN 25 10:00:00 Y REGISTRY.253.722601213

$ asmcmd rm +DATA/asm/asmparameterfile/registry.253.722601213
NOTE: The disk group that holds ASM spfile has to have COMPATIBLE.ASM value of 11.2 or higher.

References
Oracle Database Storage Administrator's Guide 11g Release 2 (11.2), Chapter 3 Administering Oracle ASM Instances, Section Initialization Parameter Files for an Oracle ASM Instance
Oracle Database Storage Administrator's Guide 11g Release 2 (11.2), Section ASMCMD Instance Management Commands

相关内容

--------------------------------------------------------------------------------
产品
--------------------------------------------------------------------------------

•Oracle Database Products > Oracle Database > Oracle Database > Oracle Server - Enterprise Edition
关键字
--------------------------------------------------------------------------------
ASM; AUTOMATIC STORAGE MANAGEMENT; DESTINATION; DISK GROUP; PFILE; SPFILE
错误
--------------------------------------------------------------------------------
ORA-15028; ORA-15032; CRS-2673; CRS-2791; CRS-2677; CRS-2793; CRS-4133; CRS-4123




<think>嗯,用户这次的问题很具体,是关于Oracle 11g RAC环境中ASM日志警告"Waited 15 secs for write IO to PST disk"的排查。从日志内容看,这属于存储层I/O延迟导致的ASM元数据写入超时,属于比较严重的性能问题。 用户能提供具体的错误日志,说明ta应该是有一定Oracle运维经验的DBA。这个错误通常出现在高负载的生产环境,用户可能正在面临性能压力,需要快速解决方案。不过考虑到RAC环境的复杂性,我需要给出既全面又谨慎的建议。 首先想到三个核心方向:存储性能、ASM配置和集群状态。存储方面最容易出问题的是HBA卡队列深度不足或存储控制器过载,特别是使用传统SAN存储时。ASM配置方面要重点检查磁盘组冗余设置和PST文件分布。集群层面则要排除节点间网络延迟。 最关键的排查点是multipath.conf配置,很多案例都是因为缺省的path_checker设置不兼容存储阵列导致的。另外Oracle 11g的ASM对SSD支持不够完善,如果是全闪存配置可能需要调整磁盘组属性。 解决方案需要分层次:先检查存储基础配置,再调整ASM参数,最后考虑硬件升级。特别要注意的是,在调整disk_asynch_io参数前必须确认存储支持异步IO,否则可能适得其反。 用户可能还需要知道如何监控后续效果,所以补充了ADRCI工具的使用方法。考虑到生产环境的安全性,所有操作建议都标注了需要测试验证。最后列出的四个问题都是实际运维中必然遇到的衍生问题,特别是性能分析部分应该能帮用户建立系统化的排查思路。</think>好的,我们来分析 Oracle 11g RAC ASM 日志中 `WARNING: Waited 15 secs for write IO to PST disk 0 in group 1` 警告的可能原因及解决方法。 **核心问题:** ASM 实例在尝试向磁盘组 1 中的第 0 号磁盘(该磁盘存储了 **P**artner **S**tatus **T**able 信息)写入 I/O 时遇到了显著的延迟(15秒)。PST 是 ASM 元数据的关键组成部分,用于跟踪磁盘组中磁盘的成员状态和故障组信息。任何对 PST 的 I/O 延迟都直接影响 ASM 的正常运作和集群的稳定性。 ### 可能原因分析 1. **底层存储 I/O 性能问题 (最常见):** * **存储硬件瓶颈:** 存储控制器过载、后端磁盘 I/O 饱和(高队列深度、高延迟)、HBA 卡性能不足或配置问题(如队列深度设置过小)、光纤交换机拥塞或故障。 * **路径问题:** 多路径软件配置不当(如 `path_checker` 设置不匹配存储类型、`features` 参数缺失导致轮询模式效率低下)、某条物理路径故障导致 I/O 重试和延迟。 * **存储阵列端问题:** 缓存策略不理想、LUN 配置问题、微码 Bug、后台任务(如重建、扩容、快照)占用大量资源。 * **网络问题 (如果是 NAS/NFS):** 网络拥塞、丢包、交换机故障、MTU 不匹配。 2. **ASM 磁盘组配置与状态:** * **磁盘组冗余级别:** 外部冗余(`EXTERNAL`) 磁盘组对 PST 的写入只有一份副本。如果承载该 PST 的磁盘出现 I/O 问题,影响直接且显著。正常冗余(`NORMAL`) 或 高冗余(`HIGH`) 磁盘组的 PST 有多个副本,ASM 会尝试写入其他副本,但写入延迟仍然可能发生,只是不会立刻导致不可用。 * **PST 磁盘位置:** PST 块通常位于磁盘组的特定磁盘上。如果磁盘组 1 中的磁盘 0(或存储其 PST 副本的其他磁盘)本身存在性能问题或故障,就会触发此警告。 * **磁盘组不平衡:** 如果磁盘组内的磁盘大小、性能差异很大,I/O 负载可能集中在少数磁盘上(包括可能承载 PST 的磁盘),导致热点和延迟。 3. **操作系统/主机配置:** * **操作系统 I/O 调度器:** 不合适的 I/O 调度器策略可能影响 ASM 磁盘的 I/O 性能。 * **操作系统参数:** `filesystemio_options` 设置不当(对于块设备通常应为 `SETALL` 或至少 `ASYNCH`),`disk_asynch_io` 被禁用(应设置为 `TRUE`)。 * **资源争用:** 主机 CPU 饱和、内存压力(导致 I/O 等待增加)、其他进程或应用(包括数据库本身)产生的大量 I/O 与 ASM I/O 竞争同一存储资源。 4. **Oracle Clusterware/RAC 问题:** * **节点间通信延迟:** ASM 实例需要与其他 ASM 实例(在 RAC 中)通信以协调元数据更新。严重的网络延迟可能导致 I/O 协调超时,间接表现为写入等待。 * **集群资源争用:** 集群心跳或投票磁盘的 I/O 如果也遇到延迟,可能加剧问题或混淆诊断。 5. **Oracle Bug:** * 虽然相对较少见,但在特定版本的 Oracle 11gR1/R2 中,可能存在与 ASM I/O 处理或特定存储交互相关的 Bug。 ### 解决方法 (按优先级和常见性排序) **第一步:确认并诊断存储 I/O 性能 (最关键的步骤)** 1. **操作系统级 I/O 监控:** * 使用 `iostat -x 2` 或 `sar -d 2` 查看涉及 ASM 磁盘的设备(如 `emcpowera`, `sdc` 等)的指标: * `%util`: 接近 100% 表示设备饱和。 * `await`: 平均 I/O 等待时间(毫秒)。持续超过 20-50ms 通常表示有问题(具体阈值取决于存储类型,SSD 应非常低)。 * `svctm`: 设备处理 I/O 的平均服务时间(毫秒)。应与存储规格比较。 * `avgqu-sz`: 平均队列长度。持续高值表示设备无法跟上请求。 * 使用 `top` 或 `vmstat` 检查系统整体 CPU 使用率、I/O 等待 (`wa` 或 `w` 列)。高 `wa` 表示 CPU 在等待 I/O。 * **检查多路径:** 使用多路径工具(如 `multipath -ll`, `dmsetup table`)确认所有路径状态 (`[active]` vs `[faulty]`)。检查多路径配置文件 (`/etc/multipath.conf`): * 确认 `path_checker` 设置正确(例如 EMC PowerPath/Clariion 通常用 `tur`,HDS 用 `directio`)。 * 确认 `features` 包含 `"1 queue_if_no_path"`(对于支持 ALUA 的存储,这通常是必须的,避免路径故障时 I/O 挂起)。 * 确认 `no_path_retry` 设置合理(例如 `fail` 或 `queue`)。 * **重要:** 参考存储厂商和 Oracle 针对 11g RAC 的最佳实践文档配置多路径。不正确的 `path_checker` 是导致此类问题的常见原因[^1]。 * **存储阵列工具:** 使用存储管理工具(如 EMC Unisphere, HDS HDvM, NetApp OnCommand)查看 LUN 性能、控制器负载、缓存命中率、后端磁盘延迟。确认是否有硬件故障或配置瓶颈。 2. **ASM数据库级 I/O 监控:** * **查询 `V$ASM_DISK_STAT`, `V$ASM_DISKGROUP_STAT`:** 查看每个 ASM 磁盘和磁盘组的读写次数、时间、平衡状态。重点关注 `READ_TIME`, `WRITE_TIME`, `READS`, `WRITES`。计算平均读写延迟 (`READ_TIME/READS`, `WRITE_TIME/WRITES`),过高的值(例如 > 20ms)指示问题。 ```sql SELECT dg.GROUP_NUMBER, dg.NAME, dg.STATE, dg.TYPE, ds.DISK_NUMBER, ds.PATH, ds.READS, ds.READ_TIME, ds.WRITES, ds.WRITE_TIME, ROUND(ds.READ_TIME / DECODE(ds.READS, 0, 1, ds.READS), 2) AS avg_read_ms, ROUND(ds.WRITE_TIME / DECODE(ds.WRITES, 0, 1, ds.WRITES), 2) AS avg_write_ms FROM V$ASM_DISKGROUP_STAT dg JOIN V$ASM_DISK_STAT ds ON (dg.GROUP_NUMBER = ds.GROUP_NUMBER) WHERE dg.GROUP_NUMBER = 1; -- 替换为出问题的磁盘组号 ``` * **检查 `V$ASM_OPERATION`:** 是否有长时间运行的再平衡操作(`OPERATION` = 'REBAL')?这会产生大量 I/O。 * **检查数据库等待事件:** 在数据库实例层面,检查 `V$SYSTEM_EVENT`, `V$SESSION_WAIT` 是否有与 I/O 相关的高等待事件(如 `db file scattered read`, `db file sequential read`, `log file parallel write`, `free buffer waits`, `write complete waits`),特别是涉及 ASM 磁盘的等待。高 `gc` 等待也可能间接反映底层 I/O 问题。 **第二步:检查并优化 ASM 和主机配置** 3. **验证 ASM 实例参数:** * `disk_asynch_io`: 应设置为 `TRUE`(默认值)。禁用异步 I/O 会显著增加延迟。 ```sql SHOW PARAMETER disk_asynch_io ``` * `asm_power_limit`: 控制再平衡操作的并行度。如果正在进行再平衡且 I/O 压力大,可临时降低此值(如从 11 降到 1 或 2),但会延长再平衡时间。完成后需调回。 * `_asm_timeout` (隐藏参数): 极端情况下,可能需要调整(谨慎!需 Oracle Support 指导)。默认值通常是足够的。 4. **检查操作系统配置:** * **`filesystemio_options`:** 对于用于 ASM 的块设备,确保设置为 `SETALL` 或 `ASYNCH`。这启用异步 I/O 和直接 I/O。 ```sql SHOW PARAMETER filesystemio_options ``` * **I/O 调度器:** 对于大多数现代 Linux 和 SSD,`deadline` 或 `noop` 通常比 `cfq` 更适合数据库负载。确认 ASM 磁盘使用的调度器(例如查看 `/sys/block/sdX/queue/scheduler`)。更改需谨慎,并测试效果。 * **HBA 队列深度:** 检查 HBA 卡驱动设置的队列深度。过小的队列深度(如默认的 30)可能在高并发时成为瓶颈。根据存储厂商和 Oracle 建议调整(可能需要升级驱动和固件)。查看 `/sys/block/sdX/device/queue_depth`。 * **大页 / HugePages:** 确保已为 SGA 配置足够的大页,减少内存页转换开销(间接影响性能)。 5. **评估磁盘组配置:** * **冗余级别:** 如果使用的是 `EXTERNAL` 冗余,理解其单点故障风险。考虑迁移到 `NORMAL` 冗余以提供元数据冗余(需要额外磁盘)。 * **磁盘组平衡:** 使用 `V$ASM_DISK_STAT` 检查磁盘组内各磁盘的 I/O 分布是否均匀。严重不平衡可能需要手动再平衡(`ALTER DISKGROUP ... REBALANCE POWER N`)或添加/移除磁盘。 * **PST 位置:** 虽然不能直接移动 PST,但理解问题发生在磁盘组 1 的磁盘 0 上。如果该磁盘持续表现不佳,可能需要强制 ASM 将其下线(`ALTER DISKGROUP ... OFFLINE DISK ... DROP AFTER [timeout]`),前提是磁盘组有足够冗余(`NORMAL`/`HIGH`)。**这是高风险操作,务必在 Oracle Support 指导下进行,并确保有有效备份!** **第三步:检查集群和网络** 6. **验证集群网络:** * 使用 `ping` 和 `traceroute` 检查私网(Interconnect)节点间延迟和丢包。使用 `oifcfg getif` 确认私网配置正确。 * 使用集群诊断工具 `cluvfy` 检查网络配置: `cluvfy comp network -n all -verbose`。 * 检查操作系统网络统计信息(`netstat -i`, `ifconfig`)是否有错误或丢包。 7. **检查 Clusterware 状态:** * `crsctl check cluster -all` 检查整体集群健康状态。 * `crsctl stat res -t` 查看所有资源的详细状态。 * 检查 `crsd`, `cssd`, `evmd` 日志 (`$GRID_HOME/log/<nodename>`) 是否有错误或警告。 **第四步:联系 Oracle Support** 8. **收集诊断信息:** * 如果以上步骤无法定位和解决问题,或者怀疑是 Oracle Bug: * 收集 ASM 实例的 alert log 和 trace 文件(包含警告信息的时间段)。 * 收集数据库实例的 alert log。 * 收集 `crsd`, `cssd`, `evmd` 的日志。 * 收集操作系统级别的 I/O 监控数据(`iostat`, `sar`, `vmstat` 输出)。 * 收集多路径配置信息 (`multipath -ll`, `/etc/multipath.conf`)。 * 收集 `asmcmd lsdsk -k --suppressheader` 输出。 * 运行 `diagcollection.pl` 或 `osysmond`, `oratop` 等工具收集更全面的诊断包。 * 将收集到的信息提供给 Oracle Support,并详细描述问题现象、时间、已做的排查步骤。提及具体的警告信息 `WARNING: Waited 15 secs for write IO to PST disk 0 in group 1`。 ### 总结 `WARNING: Waited 15 secs for write IO to PST disk` 是一个严重警告,表明 ASM 在写入其关键元数据时遇到了不可接受的延迟。**根本原因几乎总是底层存储 I/O 子系统的问题**(硬件、配置、路径、性能)。诊断的核心在于: 1. **彻底排查存储 I/O 路径:** 使用 OS 工具 (`iostat`, `sar`, 多路径命令) 和存储阵列工具定位瓶颈点。特别注意多路径配置(`path_checker`, `features`)[^1]。 2. **监控 ASM 自身 I/O 指标:** 使用 `V$ASM_DISK_STAT`/`V$ASM_DISKGROUP_STAT` 确认延迟发生在 ASM 层面。 3. **检查关键配置:** `disk_asynch_io`, `filesystemio_options`, HBA 队列深度,I/O 调度器。 4. **评估磁盘组冗余和平衡:** 理解配置并检查状态。 5. **排除集群网络问题:** 检查私网延迟。 **务必优先解决存储 I/O 瓶颈。** 忽略此警告可能导致 ASM 实例驱逐、磁盘组卸载、甚至数据库实例崩溃,严重影响 RAC 的高可用性。在实施任何配置更改(尤其是涉及多路径、参数、磁盘组操作)之前,务必在测试环境验证并做好备份。 --- **
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值