Oracle 12c RAC on VMAX3：基于SLO的PDB存储分层与性能调优实践

简介企业级IT架构师、数据库管理员和存储运维人员可借助这份白皮书系统掌握EMC VMAX3与Oracle Database 12c的集成方法以解决大规模数据库负载整合与多租户管理的核心难题。资源包仅包含1个PDF文件大小约1.35MB全文围绕VMAX3在Oracle 12c RAC环境下的方案架构展开从总体设计、创新备份与恢复机制到服务级别目标SLO一键配置、多租户可插拔数据库PDBs及Unisphere管理平台的应用均有详细阐述。目前已有141人学习下载适合正在评估存储升级或12c优化路径的团队参阅。读者不仅能理解VMAX3如何以高性能、高密度存储支撑整合类Oracle负载还能从白皮书列出的关键结果中获得性能提升、成本节省与运维简化的量化参考同时了解安全合规与备份恢复的最佳实践以及针对12c多租户架构的PDB部署建议。对寻求提升数据库服务可靠性与运营效率的技术决策者而言这是一份信息密度较高、可直接指导后续架构设计的参考资料。1. 当 Oracle 12c 的瓶颈不在 SQL 而在存储层先从一个我参与过的故障说起一套 Oracle 12c RAC四个节点跑着两百多个 schema白天 10:30 开始业务量一上来AWR 里全是db file sequential read和log file syncDBA 一遍遍优化 SQL、拆热点块效果都撑不过三天。最后检查存储端才发现同一批 ASM 磁盘里的热数据全部落在 7.2K 大容量盘上FAST VP 分层策略根本没跟上数据热度变化。这个问题的本质不是 SQL 写得差而是存储资源没有跟着数据热度走。EMC VMAX3 与 Oracle Database 12c 的组合恰好在设计上对齐了这个需求VMAX3 的 SLOService Level Objective把存储性能调优改成对存储组声明等级而 Oracle 12c 的 PDB 让每个业务模块有了独立的资源边界两者叠在一起便能针对一个 PDB 单独调整存储优先级。下面从原理、部署、运维到备份逐层拆开。2. VMAX3 的 SLO 与 FAST从 LUN 分层到服务等级声明2.1 HYPERMAX OS 与动态虚拟矩阵为什么服务等级能取代手动分层传统存储调优的核心是“分层”数据落到哪一层DBA 就要关心 RAID 组、LUN、Pool 的排布。VMAX3 改变了这个思路把调优入口从磁盘层抬高到了服务等级层。硬件上VMAX 100K/200K/400K 采用 Dynamic Virtual Matrix 架构多引擎可以横向扩展全部资源由 HYPERMAX OS 抽象成一个统一的存储资源池SRP。管理员只需要在 SRP 上定义 Diamond、Platinum、Gold 等多个服务级别并把卷放进对应的服务级别接下来数据放哪一层、什么时候迁移都由系统自己决定。这套机制解决了 Oracle 数据库部署中的一个大麻烦RAC 环境动辄几十个 LUN、多个节点共享卷手动划盘时只要一个卷的组合策略不同就很容易出现节点间 I/O 路径不一致。VMAX3 的存储组抽象让“卷集合”成为一个整体存储组绑定服务级别后同一组内所有 LUN 的介质策略是一致的。对部署 Oracle 12c RAC 这种多节点、多卷、强一致性的场景这个特性比过去手动管理 Pool 的方式可靠得多。服务级别典型介质组合适合的 Oracle 场景Diamond全闪存或高比例闪存OLTP 核心库的 datafile、redo 卷、OCR/Voting 盘Platinum闪存 高转速 SAS高并发 OLTP 数据文件、索引热点GoldSAS / 混合盘历史分区、批处理、报表中间层Silver / Bronze大容量 NL-SAS归档日志、备份集、冷数据表空间2.2 FAST 的调度逻辑与工作负载参数FASTFully Automated Storage Tiering是执行服务级别调度的引擎。它不只是简单区分“热数据放闪存、冷数据放大盘”而是用容量和性能两个维度做全局寻优。在 VMAX3 中FAST 的行为模型继承自 FAST VP但策略来源变了VMAX3 的 FAST 策略直接从服务级别推演DBA 给存储组设定 SLO 后FAST 会自动在 SRP 内部调整数据分布不需要管理员另外定义一个独立的分层策略再挂接。真正影响 FAST 评估结果的两个参数是服务级别和工作负载类型。工作负载类型决定 FAST 以哪一组 I/O 特征做评估OLTP 模型偏重随机读延迟与 IOPSDSS 模型偏重顺序吞吐。同一条容量相同的 Gold 策略OLTP 与 DSS 下最终的数据摆放位置完全不同。我在生产环境里的惯例是Oracle 在线交易库全部选 OLTP数据仓库选 DSS混合负载拆存储组避免 FAST 同时服务两种目标而互相牵制。查看 SRP 内的服务级别容量状态可使用 SYMCLIsymsrp -sid 1972 -srp SRP_1 list如果发现某个存储组的卷没有按预期分布例如 Diamond 存储组里有大量低活跃数据占着闪存可以手动触发一轮 FAST 评估symfast -sid 1972 -srp SRP_1 start -tier 0-3-sid指定阵列编号-srp指定存储资源池-tier 0-3表示把所有磁盘层纳入评估0 对应最高性能层3 对应大容量层。此命令只负责启动一次评估调度具体迁移由系统控制。注意FAST 评估和数据搬移会占用存储端 CPU 和后端端口带宽所以大批量迁移尽量放在业务低峰必要时可以用策略限制并发迁移速率避免在白天高峰期叠加额外负载。2.3 与 Oracle 12c 多租户的衔接点Oracle Database 12c 引入 CDB/PDB 后一个数据库实例可以承载多个隔离的业务单元。VMAX3 SLO 与多租户的组合价值在于可以按 PDB 分配存储优先级。业务高峰期交易类 PDB 需要更高吞吐而历史归档类 PDB 则可以容忍等待。传统做法是手动把对应 LUN 在不同层之间搬动风险大且耗时而现在只需要调整存储组的服务级别参数FAST 会在后台完成数据重排PDB 实例全程不中断。这里有一个前置条件要让存储端能细分到 PDB数据库端的数据文件必须落在不同的 ASM 磁盘组或挂载点上不能所有 PDB 混在同一组卷里。后续章节会具体演示如何用FILE_NAME_CONVERT隔离 PDB 数据文件让存储组与 PDB 形成可调度的映射关系。3. 在 VMAX3 上部署 Oracle 12c RAC 与 PDB从存储组到 ASM3.1 架构规划与资源分层Oracle 12c RAC on VMAX3 的部署架构可以划分为四层数据库主机层、FC 链路层、VMAX3 存储层和 Data Domain 备份层。主机层建议使用双端口 FC 连接 VMAX3 前端并部署 EMC PowerPath 或原生多路径软件存储层按功能拆分存储组Redo/Undo、OCR 等对延迟敏感的卷绑定 Diamond普通数据文件按业务模型绑定 Platinum 或 Gold。软件层面Oracle Grid Infrastructure 负责集群和 ASMVMAX3 的 Solutions Enabler 负责卷管理。部署前注意三件事。第一RAC 多主机的启动器Initiator必须分组清晰review 主机 WWN 与前端端口 zone 的对应关系避免把卷掩蔽给错误主机。第二ASM 磁盘大小策略要和 VMAX3 分层单元匹配AU 设为 4M 或 8M避免 AU 过大导致 FAST 迁移时粒度不可控。第三asm_diskstring 要统一指向多路径设备名常见配置是/dev/mapper/asm*或裸设备绑定避免因节点间设备名差异导致 ASM 磁盘组识别不一致。下面是一个卷类型规划的参考表卷类型VMAX3 服务级别ASM AU_SIZE说明ORACLE_RAC_REDODiamond4Mredo log、undo 表空间延迟敏感ORACLE_RAC_DATADiamond / Platinum8M核心数据文件兼顾随机与顺序ORACLE_RAC_ARCHSilver1M归档日志顺序写容量优先3.2 使用 SYMCLI 创建存储组并完成 RAC 掩蔽下面演示用 SYMCLI 在本场景下创建存储组、添加 LUN、并掩蔽到四个 RAC 节点。假设阵列编号为 1972# 创建存储组绑定 Diamond 服务级别和 OLTP 工作负载 symsg -sid 1972 create -name ORACLE_RAC_DATA -srp SRP_1 -sl Diamond -workload OLTP -nop # 向存储组加入设备 0115 到 0120每卷容量 128GB symsg -sid 1972 add -name ORACLE_RAC_DATA -devs 0115:0120 -cap 128 -nop # 将存储组掩蔽给四个 RAC 数据库节点按集群方式统一映射 symaccess -sid 1972 create -type storage -name ORACLE_RAC_DATA \ -hosts oradb1,oradb2,oradb3,oradb4 -clustered -nop逻辑说明第一步定义存储组的存储属性-srp指定资源池-sl指定服务级别-workload指定 I/O 模型第二步把物理 LUN 划入存储组第三步把存储组映射到主机。-clustered参数至关重要它会为 RAC 所有节点生成一致的卷视图避免每个节点拿到不同的 LUN 枚举顺序。掩蔽完成后用symaccess -sid 1972 list -type storage -name ORACLE_RAC_DATA -detail确认四台主机的 masked 信息一致。3.3 ASM 磁盘组与 CDB 创建LUN 映射到主机后在各节点用multipath -ll检查认到的设备并通过 udev 规则统一成/dev/asmdata01之类名称。随后创建 ASM 磁盘组sqlplus / as sysasm EOF CREATE DISKGROUP DATA EXTERNAL REDUNDANCY DISK /dev/asmdata01,/dev/asmdata02,/dev/asmdata03 ATTRIBUTE compatible.asm12.1.0.2.0, au_size8M; CREATE DISKGROUP RECO EXTERNAL REDUNDANCY DISK /dev/asmredo01,/dev/asmredo02 ATTRIBUTE compatible.asm12.1.0.2.0, au_size4M; EOFEXTERNAL REDUNDANCY表示把数据冗余交给 VMAX3 的 RAID 保护ASM 不再镜像可省一半容量au_size的取值与前面表里的策略一致redo 卷用小 AU 减少锁竞争data 卷用大 AU 提升并行扫描带宽。compatible.asm要高于数据库版本要求否则 12c 的 PDB 特性可能无法使用。ASM 就绪后用 DBCA 创建容器数据库并预建两个 PDBdbca -silent -createDatabase \ -templateName New_Database.dbt \ -gdbname CDB1 -sid CDB1 -sysPassword Oracle_1 \ -systemPassword Oracle_1 -emConfiguration NONE \ -datafileDestination DATA \ -recoveryAreaDestination RECO \ -totalMemory 4096 \ -nodeInfo oradb1,oradb2 \ -databaseType MULTIPURPOSE \ -createAsContainerDatabase true \ -numberOfPDBs 2 \ -pdbName pdb1,pdb2 \ -useLocalUndoForPDBs true这里的-createAsContainerDatabase true指定 CDB 模式-numberOfPDBs 2与-pdbName决定初始 PDB 数量-useLocalUndoForPDBs true为每个 PDB 创建独立 undo 表空间这个选项在 RAC 上很关键因为独立 undo 决定了 PDB 能否在故障时独立接管事务。使用 ASM 时DBCA 会自动识别DATA与RECO目标。3.4 手工创建 PDB 并隔离数据文件如果你希望 PDB 的存储落在不同的服务级别下建 PDB 时不要把数据文件全部放到同一个 ASM 磁盘组而是按业务目标分别映射CREATE PLUGGABLE DATABASE pdb_trade ADMIN USER adm_trade IDENTIFIED BY Tmp_1234 FILE_NAME_CONVERT(DATA/CDB1/pdbseed, DATA/CDB1/pdb_trade) STORAGE ( MAXSIZE 512G ) DEFAULT TABLESPACE users_trade DATAFILE DATA/CDB1/pdb_trade/users_trade01.dbf SIZE 1G AUTOEXTEND ON NEXT 128M MAXSIZE 32G;STORAGE (MAXSIZE 512G)用于约束 PDB 整体容量避免无界增长把共享磁盘组写满。FILE_NAME_CONVERT把 seed 模板文件转换到目标目录如果想让不同 PDB 落在不同存储组只要把DATA换成对应的 ASM 磁盘组名即可。配合前面存储组的创建流程PDB 数据文件所在磁盘组对应的 VMAX3 存储组就是后续调整服务级别的作用对象。4. 按 SLO 调整负载与 Oracle 12c 删除不干净的存储残留清理4.1 调整 PDB 对应的服务级别上线后如果业务策略发生变化VMAX3 端调整一个 PDB 的优先级只需修改存储组symsg -sid 1972 modify -name ORACLE_RAC_DATA -sl Platinum -nop该命令将存储组ORACLE_RAC_DATA的服务级别从 Diamond 降到 Platinum或者反过来升到 Diamond。改动后 FAST 会自动评估该存储组内所有卷的数据分布并逐步把数据迁到对应介质。数据库端不需要重启也不需要调整 ASM 或者表空间。这里需要强调一点不是所有业务都适合用提高服务级别来解决问题。如果 PDB 的瓶颈在应用 SQL 或锁等待存储端提升到 Diamond 也只是浪费闪存。调级前我会先看 DSADatabase Storage Analyzer的 Response Time 和 IOPS 分布确认存储服务时间确实占了大头再做变更。4.2 验证服务级别调整的效果调整后不能只看存储端的迁移报告还要从数据库侧验证。VMAX3 的 Database Storage Analyzer 提供 Dashboard、Performance、Analytics、Administration 四个标签页Dashboard 可以直接按 PDB 维度看到 IOPS 和服务时间变化。命令行环境则可以用 iostat 做快速验证iostat -x 5 10 | awk { if ($1 ~ /^asm/ $1020) print $1, $10, $11, $12 }iostat -x输出的$10是await表示单次 I/O 平均等待毫秒数$11是svctm$12是util。这里用$1020做为阈值筛选出延迟偏高的 ASM 盘。如果调整 SLO 后这些盘的 await 明显下降同时数据库侧db file sequential read不再排在 TOP 事件说明存储层已经生效。这些数据也是后续是否需要进一步迁移 PDB 的重要依据。4.3 12c 删除不干净三层残留与清理步骤很多 DBA 搜索“12c 删除不干净”实际遇到的场景是删掉一个 PDB 后存储端和集群侧仍然残留大量配置。删除一个 PDB 不只是DROP PLUGGABLE DATABASE一条命令的事在 RAC 与 VMAX3 组合环境中残留会分布在三层残留位置典型症状主要清理手段Oracle 数据字典v$pdbs存在 DROPPING 状态容器目录下有陈旧对象执行 CLOSE DROP INCLUDING DATAFILESASM 磁盘组asmcmd ls仍能看到被删 PDB 的目录和文件使用asmcmd rm -rf清除文件Clusterware / 存储层srvctl config service有残留服务存储组仍映射旧 LUN用srvctl remove service、symsg remove清理先查数据库层状态select con_id, name, open_mode, restricted from v$pdbs; select pdb_name, status from cdb_pdbs;如果 PDB 处于 DROPPING说明删除操作因会话占用而未完成需要先关闭并再次删除ALTER PLUGGABLE DATABASE pdb_trade CLOSE IMMEDIATE; DROP PLUGGABLE DATABASE pdb_trade INCLUDING DATAFILES;INCLUDING DATAFILES是最容易漏掉的关键字。漏掉后 ASM 中的数据文件不会自动删除但 ASM 元数据又显示目录已不存在形成“半删除”状态。这时候到 ASM 实例里手工清理asmcmd -p ls -l DATA/CDB1/pdb_trade rm -rf DATA/CDB1/pdb_tradeasmcmd rm -rf可以直接删除目录树比rm单个文件更稳妥。接下来检查 Clusterware 服务srvctl config service -db CDB1如果残留 PDB 服务不要直接跳过因为监听可能仍然通告旧服务然后报 ORA-12514。用lsnrctl services确认后执行srvctl remove service -db CDB1 -service pdb_trade_svc -force最后是存储层。VMAX3 上被删除 PDB 对应的 LUN 如果没有从存储组移除会继续占用容量甚至成为后续克隆操作的干扰项。清理前先确认 LUN 不再被 ASM 引用然后从存储组移除# 查看存储组内设备 symsg -sid 1972 list -name ORACLE_RAC_DATA -devices -detail # 从存储组中移除已废弃 LUN symsg -sid 1972 remove -name ORACLE_RAC_DATA -devs 0118:0120 -nop如果这些 LUN 没有被任何主机映射再执行设备删除。顺序绝不能乱数据库层 → ASM 层 → 集群服务 → 存储组 → 物理设备。我曾经遇到过因为先删存储端 LUN而 ASM 磁盘组还在正常挂载导致整个磁盘组 force dismount 的事故所以这个顺序要作为操作手册固定下来。4.4 自动化残留检查脚本把上述逻辑做成一个检查脚本每次删除 PDB 后自动扫描#!/bin/bash # 删除 PDB 后检查残留 DBCDB1 # 1. 检查集群服务残留 srvctl config service -db $DB | grep -E ^Service name || echo cluster service clean # 2. 检查 ASM 中是否存在除官方目录外的遗留 PDB 目录 asmcmd ls DATA/$DB | grep -E ^PDB || echo asm clean # 3. 检查监听是否还通告旧服务 lsnrctl services | grep -i old_pdb || echo listener clean脚本里每条检查都带|| echo ...避免在非零返回时中断后续检查。这套检查在真实环境中帮我抓到过一次问题删除 PDB 后集群服务状态已经是 OFFLINE但监听仍通告旧服务应用重连时被路由到已删除的 PDB 上报 ORA-12514。所以最后一条lsnrctl services务必保留而不仅仅看srvctl status。5. 用 ProtectPoint 做全备份RTO/RPO 与恢复验证ProtectPoint 的价值在于“用增量备份的成本拿到全备份的结果”。VMAX3 和 Data Domain 集成后Oracle 备份流程变成 RMAN 只做元数据记录实际数据由 VMAX3 以快照形式获取随后阵列把变更块异步推送到 Data Domain。DBA 看到的是一次 RMAN 备份脚本但底层传输由存储端完成备份速度和空间占用都优于传统全量备份。RMAN 端需要指定 Data Domain 的 SBT 库和连接参数核心命令如下RMAN target / CONFIGURE CHANNEL DEVICE TYPE SBT_TAPE PARMS SBT_LIBRARYlibddobk.so, ENV(BACKUP_HOSTddve01,BACKUP_USERoracle12c); BACKUP INCREMENTAL LEVEL 0 DATABASE FORMAT /oracle12c/backups/%U;BACKUP INCREMENTAL LEVEL 0在 ProtectPoint 场景下并不是传统的增量全库扫描而是触发存储端快照快照完成后由 VMAX3 后台把数据变化量传到 Data Domain所以备份窗口很短。恢复时可以直接把快照作为数据源恢复RMAN target / RESTORE DATABASE; RECOVER DATABASE; ALTER DATABASE OPEN RESETLOGS;恢复后如果要在 RAC 环境重新承接业务第一步不是打开应用连接而是先做最小化启动验证确认集群服务和数据文件状态srvctl start database -db CDB1 sqlplus / as sysdba EOF select inst_id from gv$instance; select count(*) from v$datafile; EOF如果日志里出现 ORA-00313、ORA-01157绝大多数情况是恢复时引用了旧的 ASM 路径或旧的 LUN 关系。此时不要依赖 RMAN 自动探测建议用SET NEWNAME明确把数据文件指到新路径SET NEWNAME FOR DATAFILE 209 TO DATA/CDB1/pdb_trade/users_trade01.dbf;最后再强调一个和“删除不干净”呼应的细节如果之前删 PDB 时没有清干净 ASM 目录恢复时命中同名文件冲突RMAN 会直接中止。清理工作越彻底恢复环节越省事。VMAX3 的 TimeFinder SnapVX 可以提供本地分钟级回滚适合在恢复前先拍一个当前状态ProtectPoint 则负责远端容灾两者组合能让 12c 多租户环境的备份策略从“每个 PDB 单独写脚本”变成“存储端统一策略数据库端按需校验”。本文还有配套的精品资源点击获取