简介面向企业级数据库架构师与数据库管理员的技术白皮书围绕高端存储系统VMAX3与Oracle 12c RAC数据库整合方案展开。内容聚焦多租户可插拔数据库的部署流程、存储服务级别目标的一键式配置以及针对数据库工作负载的备份恢复与安全合规设计适合在数据中心整合、资源弹性调配和业务连续性场景下参考。资源为单个PDF文档压缩包整体约1.35MB目前已有141人浏览学习。文中从业务挑战到关键结论逐步拆解既介绍了存储与数据库联合架构的总体设计也说明了性能提升、成本节省、运维简化等推荐措施并附带术语表与目录导航便于按需查阅。读者可借此理解高端存储与多租户数据库特性的配合方式为规划或优化自身数据库平台提供落地参考。1. EMC VMAX 与 Oracle 12c RAC技术平台白皮书到底在划分什么很多 DBA 拿到“EMC VMAX 与 Oracle 12c RAC 技术平台白皮书”时第一反应是翻到最佳实践章节找现成配置。但这个标题真正讨论的其实是数据库与存储两个团队在边界上怎么对齐参数。VMAX 有 FastPath、FAST VP、SRDF 这类复杂调度机制Oracle 12c RAC 又有 cache fusion 和 ASM 两条独立的 IO 路径它们各自运行可靠合在一起时任何一侧的不透明都会变成等待事件。白皮书要解决的是这类跨界问题redo 日志组该有多少存储带宽、Voting 文件要不要独立存储组、ASM AU_SIZE 应不应该跟着 VMAX 的 RAID 类型选。适合读它的人是既要写 SQL 也要调多路径策略的 DBA以及需要从数据库等待事件反查存储队列的存储工程师。它不是补产品知识是给一张可验收的契约。2. 从 12c RAC 的 IO 模型看 VMAX 为什么值得单独成册RAC 在 IO 层面有一个明显区别于单机数据库的特征同一个数据块可能以三种不同路径穿过系统。第一种是会话发起的常规读写经过 ASM 磁盘组再到 VMAX 前端端口第二种是 DBWR 后台写脏块目标是数据文件第三种是 cache fusion 的网络传输块本身不一定落盘但等待链却与存储的写完成时间纠缠在一起。Oracle 12c RAC 对每种路径的延迟预算并不相同因此不能只靠“这台阵列很快”来保证质量。这一章先从这些路径拆解再对应 VMAX 的存储能力最后落到一张职责边界表上。2.1 cache fusion 给存储阵列划出的硬约束cache fusion 是 RAC 节点之间传递数据块的机制。节点 A 在本地缓存中修改了一个块但未提交节点 B 要读它时A 必须通过网络把该块的最新版本发给 B。在这个过程里存储似乎没有参与但 A 的 redo 日志必须先完成一次同步写才能把块标记为可传递因此 VMAX 上 redo 日志的写延迟会直接影响 cache fusion 的响应时间。如果 VMAX 因为缓存繁忙或磁盘热点导致 redo 写从 1ms 涨到 5msAWR 里就可能出现大量gc cr block send time和log file sync。另一个容易忽略的硬约束是 Voting 文件。12c RAC 的节点健康检测在 IO 抖动时会把设备读延迟视为心跳异常触发驱逐。Voting 文件写很小但读频率很高存储团队若把它和数据文件放在同一个没有 QoS 保证的存储组里一次全表扫描就能让节点误判。这就是为什么技术平台白皮书通常会明确要求 Voting 文件所在存储组独立设置最高优先级。ASM 元数据的 IO 频率也容易被忽略。ASM 在创建磁盘组时会在每块成员盘上写入 1MB 的元数据区并在运行期更新 partners 和 failgroup 信息。这些元数据写虽然不大但任何一次都要求存储返回写完成。VMAX 如果开启了写缓存镜像写完成时间通常很低但如果对应存储组使用了 write-through 或绕过缓存策略ASM 元数据写就会拖慢磁盘组 mount 和 rebalance。这类问题很难从 AWR 直接看到往往表现为asm rebalance异常慢。2.2 VMAX 的 FastPath、SRDF、QoS 怎么回应这些约束VMAX 不是一台简单的磁盘柜它对上述约束有原生回应。FastPath 让所有前端端口都可以访问所有 LUN数据库实例跑到哪个节点都能走最短路径FAST VP 则把热数据在闪存层与磁盘层之间自动迁移适合数据文件但不太适合延迟敏感且大小固定的 redo 日志SRDF 用于跨阵列容灾在平台设计中控制故障域QoS 则是限速工具可以把某个存储组的最大带宽限制住不让批量任务抢占关键路径。这些能力放进 Oracle 12c RAC 时要考虑参数的相互作用。比如 FAST VP 对 redo 日志做分级是危险的因为日志写入没有局部性可言它会在不同层之间震荡反而增加写放大。所以平台化设计通常会把 redo 日志固定在高速层并用 QoS 加一个低延迟保证把数据文件交给 FAST VP 自动分层。这套组合拳不是存储单方面能做主的需要知道数据库每个文件写入模式才能定。2.3 白皮书里的“平台边界”用一张表定清职责一个常见的设计思路是把 RAC 的每个组件映射到 VMAX 的一个特性和一个验证指标上。存储团队和 DBA 各管一段出现异常时根据表格检查自己的部分。下面的表格是我在平台设计时会先搭建的简化版RAC 组件主要风险VMAX 对应能力上线前验证Voting 文件误判脑裂高优先级存储组 / QoScrsctl query css votedisk观察延迟OCR配置不一致SRDF 一致性组ocrcheck输出时间redo 日志log file sync飙高FastPath 前端端口带宽日志切换耗时数据文件脏块刷盘慢FAST VP 分层AWR 中write complete waits这张表里的每一项最后都会变成可执行检查。比如 Voting 文件的验证不能只看df能挂上而要连续读取上百次观察延迟分布是否稳定。VMAX 的 QoS 如果给 Voting 文件所在存储组留了最低带宽保证那么即使数据文件在做全表扫描Voting 的读延迟也不会被挤爆。除了存储RAC 的 cache fusion 还依赖私网质量所以拿到一个 VMAX 平台的白皮书时不要只盯着阵列参数先用最简单的命令确认网络基线ping -i 0.2 -c 200 192.168.10.11 | tail -2-i 0.2表示每隔 0.2 秒发一个 ICMP 包-c 200一共发 200 个tail -2显示统计行。如果平均往返延迟超过 1ms或者出现丢包先解决网络再谈存储。因为 cache fusion 对网络延迟的敏感度远高于存储一个高延迟的私网会让任何存储优化都被两个差距吞没。3. 在 EMC VMAX 上搭 Oracle 12c RAC最小可复现命令与参数这一章以“已经能看到设备”为起点。存储团队在 Unisphere for VMAX 上建好存储组并映射给主机后系统里会出现一批sd设备。你要做的第一件事不是急着给 ASM 分区而是把设备名固定下来避免重启后磁盘路径变化导致挂载错误。这个阶段有两种主流方案EMC PowerPath 和 Linux 原生 multipath。在 VMAX 环境里前者更常见因为 PowerPath 能识别 VMAX 的虚拟 WWN、preferred path 和 ALUA 状态。3.1 PowerPath 多路径配置先把设备名做成一致变量powermt config powermt display devallpowermt config让 PowerPath 重新扫描所有总线并检查已有映射。执行之后powermt display devall会列出每个emcpower设备对应的底层 sd 设备、阵列名和路径状态。你需要确认State里所有路径都是alive。如果出现dead要看 zoning 或 HBA 端口不能带着坏路径继续因为 ASM 会接受这个设备但性能波动无法预期。很多环境还会用powermt set policy...调整路径选择策略这会影响 RAC 节点最终走哪个前端端口。策略选择要和 VMAX 的端口配置配合不能照抄其他存储的经验。比如同样叫多路径VMAX 的 preferred path 会优先走归属 director如果数据库节点与存储端口跨了太远的线路还是应该先调整 storage group 的端口分配。配置完成后还要用powermt save把映射保存到启动环境中否则重启后 PowerPath 会丢失路径策略。这个命令不会输出太多但执行后应检查/etc/emc/powermt.custom的时间戳是否更新。现在大部分 Linux 发行版用 Dracut 或 initramfs 启动多路径别忘记在重建 initramfs 之后再重启。3.2 创建 ASM 磁盘组时与 VMAX 对齐的三组参数RAC 的存储落地通常是 ASM。ASM 与 VMAX 之间存在两层映射需要手动对齐冗余策略和 AU 粒度。VMAX 在后端已经做了 RAID 保护所以 ASM 组可以选EXTERNAL REDUNDANCY避免 ASM 镜像再写一倍数据。AU_SIZE 更讲究VMAX 内部条带通常在 512KB 到 1MB如果 ASM AU 太小数据分布会比较碎如果太大AWR 里容易出现单次 IO 时间被放大。我一般会在数据文件组上设 4MB AUredo 日志组用 8MB。下面这段 SQL 是创建一个典型 DATA 磁盘组的语句可以直接替换设备名执行CREATE DISKGROUP DATA EXTERNAL REDUNDANCY DISK /dev/emcpowera NAME DATA1, /dev/emcpowerb NAME DATA2, /dev/emcpowerc NAME DATA3 ATTRIBUTE COMPATIBLE.ASM 12.1.0.2, COMPATIBLE.RDBMS 12.1.0.2, AU_SIZE 4M;COMPATIBLE.ASM决定 ASM 实例能启用的内部功能COMPATIBLE.RDBMS限制可挂载该磁盘组的数据库最低版本通常与当前补丁版本一致或略低。AU_SIZE是分配单元大小创建后不能修改因此必须在这条语句里定好。另一个需要确认的参数是SECTOR_SIZE如果 VMAX 的 LUN 是 4K 扇区格式ASM 默认按 512 字节处理会导致空间利用率偏差。下面是我为三类文件准备的参数参考实际部署时可以根据 VMAX 存储组配置调整磁盘组用途ASM 冗余AU_SIZE建议存储层DATA数据文件EXTERNAL4MFAST VP 自动分层RECO归档/闪回EXTERNAL8M大容量层VOTEOCR/VotingEXTERNAL1M高性能层固定补充一点OCR 和 Voting 在 12c 里默认可以使用独立的VOTE磁盘组不要为了图省事把它们塞进 DATA。Voting 文件大量小块读1M AU 能减少 I/O 放大redo 和归档则通常放在 DBA 手工规划好的RECO组里避免自动分层引发写放大。3.3 用 asmcmd 核对 VMAX 设备与 ASM 的逻辑映射建完磁盘组后不要急着建数据库先用 ASM 命令确认映射没有错位。asmcmd lsdsk -G DATA --statistics这条命令列出DATA磁盘组里每块盘的状态、路径、读时间和写时间。重点看READ_ERRS和WRITE_ERRS是否为零以及读平均延迟是否基本一致。如果某一块盘延迟明显高于同组其他盘说明它可能落在了 VMAX 的不同后端引擎上或在 FAST 分层里处于冷层。这时候应回到存储侧查看该 LUN 的存储组分配而不是继续调整 SQL。映射核对在更换存储端口或扩容后也要重复执行。经常有管理员扩容后把新盘加错存储组导致 ASM 均衡时把热数据写到低性能层问题到一周后才在 AWR 里暴露。asmcmd lsdsk --statistics提供的延迟分布可以提前暴露这类错误。4. 从 AWR 到清理现场VMAX 与 Oracle 12c RAC 的排障路径实际运维中VMAX 上的 RAC 出现故障时第一信号通常不是存储报警而是数据库等待事件。要快速定位需要把 AWR、asmcmd、crsctl串成一条排障链。按照“数据库层判断方向、存储层确认真因、集群层清理残留”的顺序来能少走很多弯路。4.1 用 AWR 反向定位 VMAX 的延迟指标如果用户报告“数据库突然变慢”我一般会先取最近两个快照之间的dba_hist_system_event汇总而不是直接看 VMAX 控制台。下面这条 SQL 可以筛出最关键的几个等待事件SELECT snap_id, event, total_waits, ROUND(time_waited_micro/total_waits/1000, 2) avg_ms FROM dba_hist_system_event WHERE event IN (log file sync,write complete waits, gc cr multi block request,db file sequential read) AND snap_id BETWEEN 10000 AND 10010 ORDER BY snap_id, avg_ms DESC;snap_id范围要换成你环境里的实际值。log file sync高时第一嫌疑是 redo 日志所在 VMAX 存储组的写延迟write complete waits长则说明脏块写盘跟不上要去查存储队列深度或 FAST VP 分层gc cr multi block request主要由集群私网延迟决定但它也会与存储延迟一起上涨。注意 AWR 里记录的是数据库会话排队的时间不是存储端物理时间所以判断时还必须结合 VMAX 的延迟曲线。除了上述事件cell single block physical read是多用于 Exadata 的不要在 VMAX 上做无谓区分。VMAX 对接的是db file sequential read和db file scattered read如果这两个事件平均延迟超过 10ms通常说明 LUN 所在的存储层性能不足或队列拥塞。此时再从 Unisphere for VMAX 里看 FA 端口繁忙度基本能确认是路径数量不够还是存储层本身的问题。4.2 FAST VP 分层后的容量与性能取舍VMAX 的 FAST VP 会在不同介质间自动迁移数据这让“容量规划”变成了“性能预算”。如果数据文件全部放在高性能层容量通常不够如果全部放在容量层db file sequential read延迟会飙升。做法是对数据文件做一次段级热度分析或直接用 VMAX 的存储组性能报告把虚拟卷的繁忙程度排个序。一个常见取舍是把 ASM 磁盘组按用途拆成高优先级和普通优先级两个存储组数据文件的初始层设为“自动分层”但保证高性能层至少有 20% 余量给突然升温的日志和索引段。这时候不要只看 VMAX 的缓存命中率还要看 ASM 层的读延迟分布。若延迟分布呈双峰说明有部分区段正在冷热层之间来回迁移需要调整存储组的层分配策略而不是继续扩盘。要量化热度可以查询dba_hist_seg_stat找出近一个月的logical reads与physical reads比值。对于物理读远高于其他段的表考虑把它单独挪到高性能存储组而不是整体依赖 FAST VP。这个动作可以用alter tablespace或在线重定义完成但要注意 12c 的默认文件操作可能会触发数据文件的重新均衡尽量放在维护窗口做。4.3 12c 删除不干净留下的幽灵实例清理 ASM 与集群资源Oracle 12c 的一个典型问题是卸载数据库时dbca -deleteDatabase执行后未必把集群资源全部清干净。删除不干净会让crsctl stat res -t里残留ora.orcl.db甚至 ASM 磁盘组的目录里留下孤儿数据文件。这类残留最早可能在重启集群后变成新实例的“幽灵”导致监听端口或 SPFILE 被误引用。清理顺序应当是先停库再删资源最后清 ASM 元数据不能反过来sqlplus / as sysdba EOF shutdown abort; EOF srvctl remove database -d orcl -f crsctl stat res -t | grep -i orcl asmcmd ls -l DATA/ORCL/DATAFILEshutdown abort用于实例已经不响应的情况正常环境应该先shutdown immediate。srvctl remove database -f会把集群里的资源配置一并删除。然后用crsctl stat res -t确认没有任何带orcl的资源名称残留。最后用asmcmd ls查看磁盘组里是否还有旧数据目录如有再用asmcmd rm -rf DATA/ORCL/DATAFILE清理。如果crsctl删完后还有资源检查 GPNP 配置gpnptool get看看是否保存了旧集群资源信息。4.4 最小化切断验证平台验证里最重要的一项是故障切换。不需要拉数据库 crash只要隔离掉一个集群节点即可。常见的做法是临时停掉节点间的心跳网卡观察 12c RAC 是否在misscount时间内将实例驱逐并交给存活节点。ifdown eth1 crsctl status resource -t | grep -A2 ora.orcl.db如果节点被正确驱逐ora.orcl.db会显示在另一个节点上变成 ONLINEVoting 文件没有因为存储路径抖动而扩大误判。验证完记得ifup eth1把网卡恢复并重新加回节点。这里要留意ifdown影响的是 CSR 还是公共网卡要根据实际心跳端口名调整操作前先和网络团队确认。5. 把验证动作固化给 EMC VMAX 与 Oracle 12c RAC 建一张延迟预算清单到这里平台已经能跑起来。最后一个建议是不要记住零散命令而是用一张“延迟预算清单”把这套 VMAX 与 Oracle 12c RAC 的边界管起来。清单的每一行都应该有目标值和阈值超过阈值时按固定动作找证据。指标目标值超限处理redo 写延迟VMAX 前端2ms查存储组 QoS 与 FA 端口负载Voting 读延迟5ms检查 VMAX 后端磁盘热点gc cr block receive time平均1ms查私网丢包和 VMAX 高延迟ASM 读错误计数0查链路和 HBA 固件采集不能靠偶尔用top随机看而要留一个可复跑的脚本。我通常把下面的 SQL 存成platform_check.sql每月执行一次SELECT stat_name, value/1000 ms FROM v$sysstat WHERE stat_name IN (redo synch time, gc cr block receive time);把输出追加到一个带时间戳的文件连同 VMAX 的 Unisphere 性能快照放一起。这样当某天性能劣化时可以快速画出一条“数据库延迟升高是否伴随存储延迟升高”的时间线避免两个团队在没人认领指标时互相甩锅。目标值不要照搬别人你环境里的存储网络、服务器型号和 RAC 节点数都会改变基数先观察两周正常负载取 95 分位延迟作为自己的预算值。为了让脚本更有用还可以在采集时记录节点名和快照时间比如sqlplus -S / as sysdba platform_check.sql /var/log/vmax_rac_budget.log date /var/log/vmax_rac_budget.log这样每次执行都会留下时间戳配合 VMAX 的监控能比对分钟级趋势。白皮书的意义最终不是读完而是把这张预算表填满并长期维护。你环境里的数字可能和上面的目标值不同但清单结构可以直接照搬。本文还有配套的精品资源点击获取