简介这份《Oracle云基础架构平台解决方案》PDF面向售前技术人员、培训人员、合作伙伴及对Oracle云计算感兴趣的读者系统梳理了Oracle云基础架构的整体架构与落地思路可帮助读者理解企业构建私有云、公有云或混合云环境时的关键设计要点。资源包内仅含1个PDF文件大小约3.72MB内容涵盖计算、存储、网络、云安全、运营子系统、应用云子系统、软硬件配置清单、API与集成、合作伙伴关系及售后服务支持等模块并附有版本修订记录与阅读对象说明便于按章节查阅。目前已有99人学习下载。读者可从中获取云平台分层架构的完整描述、各子系统职责划分、软硬件选型参考以及跨云集成与运维自动化的基本思路适合作为方案规划与架构学习的参考资料。1. Oracle 云基础架构平台解决方案从一台数据库到一套可交付的云底座很多团队第一次接触「Oracle 云基础架构平台解决方案」这个词是在一份几十页的 PDF 里——里面画满了区域、可用域、虚拟云网络、块存储、负载均衡的架构图看完觉得都对合上文档却不知道明天该敲哪条命令。我当年也是这样把方案文档当科普读物翻了三遍直到真正要在一周内把一套 Oracle 数据库迁到云上才发现文档里没写的东西才是要命的网络怎么切、存储怎么选、监听怎么配、备份怎么验证。这篇笔记不讲空泛的架构愿景只讲一件事如果你手上有一份 Oracle 云基础架构平台解决方案或者你正准备自己搭一套从零到能跑业务中间那些必须落地的步骤、参数和坑我按自己踩过的顺序讲一遍。适合两类人一类是要把本地 Oracle 数据库往云上搬的 DBA 和运维另一类是需要在云上从零规划一套 Oracle 基础架构的架构师。新手能照着命令走熟手能直接跳到参数和边界那几节。2. 先想清楚Oracle 云基础架构到底由哪几层拼起来2.1 计算、存储、网络三件套的对应关系Oracle 云基础架构OCI的底座说穿了就是三样东西计算实例、块存储、虚拟云网络。方案文档里那些花哨的名字落到操作层面就是这三样在组合。计算实例对应你原来机房里的物理机或虚拟机块存储对应你挂在服务器上的盘虚拟云网络对应你机房里的交换机和防火墙策略。理解这个对应关系很重要因为迁移时你脑子里要做的映射是原来数据库跑在哪台机器上、数据放在哪个盘、应用怎么连过来。这三件事想清楚了云上的架构自然就出来了。我一般会先画一张表把本地的机器、磁盘、网段列出来再逐个映射到云上的资源类型映射不上的地方就是后面要重点验证的风险点。本地资源云上对应关键差异物理服务器计算实例灵活配置规格可在线调整但调整需重启本地磁盘 / SAN块存储卷性能按 VPU 计费需预估 IOPS交换机 / 防火墙虚拟云网络 安全列表规则默认拒绝需显式放行负载均衡设备负载均衡器后端集健康检查要单独配这张表不是让你照抄而是让你在动手前把「哪些是等价替换、哪些是行为差异」分清楚。等价替换的部分可以放心搬行为差异的部分必须实测。2.2 区域与可用域容灾不是勾选项是网络设计题方案里一定会提区域和可用域很多人把它当成容灾开关勾上就以为高可用做完了。实际上可用域的选择直接决定你的网络怎么划、存储怎么放、延迟是多少。同一个区域内的不同可用域之间延迟通常在个位数毫秒跨区域就是几十毫秒起步这个差距对数据库主备同步是致命的。我的做法是主库和备库放在同一区域的不同可用域应用服务器跟主库放同一可用域跨区域只做备份归档不做实时同步。这样既拿到了可用域级别的容灾又不会让同步延迟拖垮业务。方案文档里如果只写了「建议跨可用域部署」而没写延迟数据那这段就是给你留的作业得自己测。2.3 从方案文档到可执行清单的拆解方法拿到一份解决方案 PDF不要从头读到尾。我的习惯是先翻到架构图那一页把图上的每个方框抄下来变成一个资源清单然后翻到参数配置章节把每个方框对应的规格、数量、网段填进去最后翻到实施步骤对照清单看有没有遗漏。拆完之后你会得到一张类似这样的清单几个计算实例、每个实例什么规格、挂几块盘、每块盘多大、在哪个子网、开放哪些端口、备份策略是什么。这张清单才是你真正要执行的东西PDF 本身只是参考。清单里任何一项写不出具体数字就说明方案在这一块是模糊的需要你自己补决策。3. 把 Oracle 数据库搬上云实例、存储与网络的最小落地路径3.1 计算实例规格怎么选才不浪费也不翻车选规格这件事新手最容易犯的错是照着本地服务器的配置往上套。本地是 16 核 64G云上也买个差不多的结果发现云上的核和本地的核不是一回事性能对不上。Oracle 数据库对 CPU 和内存的比例很敏感OLTP 场景一般内存是 CPU 核数的 4 到 8 倍比较稳OLAP 场景内存可以再高一些。我一般会先按现有数据库的 AWR 报告估算看 DB CPU 和 DB Time 的比例看每秒逻辑读再折算到云上的规格。如果拿不到 AWR就按经验值起步然后压测调整。起步配置宁可小一点云上扩容比缩容容易而且扩容只需要重启不会丢数据。# 查看当前数据库的 CPU 和内存使用基线在源库执行 sqlplus / as sysdba EOF -- 查看实例启动以来的 CPU 时间 SELECT name, value FROM v\$sysstat WHERE name IN (CPU used by this session, parse time cpu); -- 查看 SGA 和 PGA 配置 SHOW PARAMETER sga_target; SHOW PARAMETER pga_aggregate_target; -- 查看逻辑读用于估算 IOPS 需求 SELECT name, value FROM v\$sysstat WHERE name session logical reads; EOF这段脚本的作用是拿到源库的资源基线。CPU used by this session是累计 CPU 消耗配合实例启动时间能算出平均 CPU 使用率session logical reads是逻辑读总量除以运行秒数就是每秒逻辑读再乘以块大小通常 8K就是每秒 IO 量级用来反推块存储的 VPU 需求。参数上sga_target和pga_aggregate_target决定了内存规格的下限云上实例内存不能低于这两个值之和再加操作系统开销。3.2 块存储的 VPU 与 IOPS别等业务卡了才回头加盘块存储是云上最容易低估的一块。本地磁盘你买回来性能是固定的云上块存储的性能跟容量和 VPU 挂钩选小了业务一压就卡。Oracle 数据库的 redo 日志对写延迟极其敏感数据文件对吞吐敏感这两类盘要分开考虑。我的做法是redo 日志单独挂一块盘选高 VPU 低容量数据文件挂一块大容量盘VPU 按每秒逻辑读折算归档和备份再挂一块普通盘。三块盘分开既方便调优也方便出问题时定位是哪一类 IO 拖后腿。# 在云主机上确认块存储挂载和 IO 调度器 lsblk -o NAME,SIZE,TYPE,MOUNTPOINT # 查看每块盘的调度器数据库盘建议用 none 或 mq-deadline cat /sys/block/sdb/queue/scheduler # 临时调整调度器重启失效需写进 udev 规则 echo mq-deadline /sys/block/sdb/queue/scheduler # 用 fio 做一次写延迟基线测试注意不要在生产盘上跑 fio --namerandwrite --ioenginelibaio --iodepth32 --rwrandwrite \ --bs8k --direct1 --size1G --runtime60 --filename/data/testfilelsblk确认盘挂上了没有scheduler决定 IO 请求怎么排队数据库盘用mq-deadline或none比默认的cfq更稳。fio那段是写延迟基线重点看lat (usec)那一行的 p99 值如果 p99 超过 1msredo 日志放这块盘上就要谨慎。注意--filename指向测试文件别指向真实数据文件跑之前确认路径。3.3 虚拟云网络与安全列表监听器起不来的头号原因网络这块方案文档通常画得很清楚但落地时最常卡在安全列表上。Oracle 监听默认走 1521 端口云上的安全列表默认拒绝所有入站你不显式放行监听起得来但连不上。这个坑我踩过不止一次现象是lsnrctl status显示正常客户端就是ORA-12518: 监听程序无法分发。排查顺序是先在云主机上tnsping自己通了说明监听没问题再从客户端tnsping不通就是网络或安全列表最后看安全列表的入站规则有没有放行 1521 和客户端所在网段。# 在数据库主机上确认监听状态和端口 lsnrctl status netstat -tlnp | grep 1521 # 从客户端测试连通性 tnsping 数据库主机IP:1521/服务名 # 如果超时检查安全列表入站规则是否放行源网段到 1521lsnrctl status看监听是否 READYnetstat确认 1521 在监听。tnsping是最直接的连通性测试超时基本就是网络层被拦了。安全列表规则要写清楚源 CIDR不要图省事写0.0.0.0/0数据库端口暴露到公网是等保检查的重点项方案里如果没提这条实施时一定要补上。4. 上线前必须过的验证关备份、恢复与性能基线4.1 备份策略能恢复才算备份不能恢复只是占地方云上的备份比本地方便但方便不等于可靠。我见过太多团队开了自动备份就以为万事大吉真出事的时候发现备份文件在恢复脚本跑不通。备份策略要回答三个问题备份频率、保留周期、恢复演练频率。前两个方案文档里一般有第三个通常没人写。我的习惯是上线前做一次完整恢复演练从备份里恢复一个实例跑一遍应用连接测试确认数据一致。演练不通过备份策略就不算完成。这一步花半天时间能省掉出事时几天的救火。# 用 RMAN 做一次全库备份到云块存储 rman target / EOF CONFIGURE BACKUP OPTIMIZATION ON; CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS; BACKUP AS COMPRESSED BACKUPSET DATABASE PLUS ARCHIVELOG; -- 校验备份集完整性 VALIDATE BACKUPSET ALL; EOFRETENTION POLICY决定保留窗口7 天是常见起步值按业务合规要求调整。BACKUP AS COMPRESSED BACKUPSET压缩备份集省存储但增加 CPU 开销CPU 紧张的库可以去掉压缩。VALIDATE BACKUPSET是关键一步它校验备份文件是否可读、块是否完整不做这步你永远不知道备份是不是坏的。4.2 恢复演练把「应该能恢复」变成「确实恢复过」恢复演练不是把备份还原回去就完事要验证的是恢复出来的库能不能被应用正常使用。步骤是起一个临时实例恢复数据文件和控制文件做一次不完全恢复或完全恢复然后让应用连上去跑核心查询。# 在临时实例上做恢复演练 rman target / EOF STARTUP NOMOUNT; RESTORE CONTROLFILE FROM 备份控制文件路径; ALTER DATABASE MOUNT; RESTORE DATABASE; RECOVER DATABASE; ALTER DATABASE OPEN RESETLOGS; EOF # 恢复后验证数据一致性 sqlplus / as sysdba EOF SELECT COUNT(*) FROM 核心业务表; SELECT MAX(created_date) FROM 核心业务表; EOFRESTORE CONTROLFILE先恢复控制文件因为控制文件里记录了数据文件的位置和备份信息。RECOVER DATABASE应用归档日志到一致点。OPEN RESETLOGS打开数据库这一步之后原备份链就断了所以演练要在隔离环境做。最后两条查询是验证数据到没到预期时间点MAX(created_date)能看出恢复到了哪个时刻。4.3 性能基线上线前不测上线后就是玄学性能基线是很多人跳过的一步觉得业务还没上测了也没意义。实际上基线的作用是给你一个参照系业务上线后变慢了你能判断是业务量涨了还是系统退化了。基线要测三类CPU 密集查询、IO 密集查询、并发连接。# 用 swingbench 或类似工具做并发基线测试 # 这里用简单的并发查询模拟 for i in $(seq 1 50); do sqlplus -s user/pass//主机:1521/服务名 EOF SELECT /* FULL(t) */ COUNT(*) FROM 大表 t; EXIT; EOF done wait # 测试期间在数据库端观察等待事件 sqlplus / as sysdba EOF SELECT event, total_waits, time_waited FROM v\$system_event WHERE wait_class ! Idle ORDER BY time_waited DESC FETCH FIRST 10 ROWS ONLY; EOF并发查询模拟的是多用户同时访问的场景让查询后台并行wait等全部结束。数据库端的v$system_event看等待事件如果db file sequential read排前面说明 IO 是瓶颈latch: shared pool排前面说明共享池有争用。基线数据记下来上线后对比差异超过 20% 就要查原因。5. 避坑与排查那些方案文档不会写的翻车现场5.1 监听服务无法启动先看日志再看权限现象lsnrctl start卡住或报错lsnrctl status显示监听未启动。原因通常是监听日志文件满了或者权限不对。Oracle 监听日志默认在$ORACLE_HOME/network/log/下长期不清理会涨到几个 G写不进去就起不来。解决清理监听日志确认listener.ora和日志目录的属主是 oracle 用户。# 查看监听日志大小 ls -lh $ORACLE_HOME/network/log/listener.log # 清理日志先备份再清空 cp $ORACLE_HOME/network/log/listener.log /tmp/listener.log.bak $ORACLE_HOME/network/log/listener.log # 确认权限 ls -l $ORACLE_HOME/network/log/5.2 ORA-12518 监听程序无法分发连接数打满了现象客户端报ORA-12518: 监听程序无法分发但监听状态正常。原因是数据库的processes或sessions参数达到上限新连接分不出去。解决查当前连接数调大processes和sessions重启生效。-- 查看当前连接数和参数上限 SELECT COUNT(*) FROM v$session; SHOW PARAMETER processes; SHOW PARAMETER sessions; -- 调大参数需重启 ALTER SYSTEM SET processes500 SCOPESPFILE; ALTER SYSTEM SET sessions555 SCOPESPFILE;5.3 12c 删除不干净导致重装失败注册表和残留文件现象卸载 Oracle 12c 后重装报各种奇怪的错误比如端口被占、实例名冲突。原因是卸载没清干净注册表项、环境变量、/etc/oratab、/etc/oraInst.loc都有残留。解决手动清理这些位置重启后再装。# 清理残留文件 rm -f /etc/oratab /etc/oraInst.loc rm -rf /u01/app/oracle /u01/app/oraInventory # 清理环境变量检查 ~/.bash_profile 里的 ORACLE_HOME 等 grep -i oracle ~/.bash_profile # 确认没有残留进程 ps -ef | grep -i oracle | grep -v grep5.4 等保检查项默认配置过不了现象等保测评时被指出数据库存在弱口令、端口暴露、审计未开启等问题。原因是默认安装的配置不符合等保要求。解决改口令策略、限制监听端口访问来源、开启审计、关闭不必要的服务。-- 开启数据库审计 ALTER SYSTEM SET audit_trailDB,EXTENDED SCOPESPFILE; -- 查看当前口令策略 SELECT * FROM dba_profiles WHERE resource_name LIKE PASSWORD%; -- 修改口令有效期和复杂度 ALTER PROFILE DEFAULT LIMIT PASSWORD_LIFE_TIME 90; ALTER PROFILE DEFAULT LIMIT FAILED_LOGIN_ATTEMPTS 5;5.5 跨可用域延迟导致主备同步慢先测再定架构现象主备库跨可用域部署后备库延迟持续增长。原因是跨可用域的网络延迟比预期高redo 传输跟不上。解决先测实际延迟如果超过 5ms考虑把备库放到同可用域或者改用异步同步。# 测试两台主机之间的网络延迟 ping -c 100 备库IP | tail -1 # 用 iperf3 测带宽 iperf3 -c 备库IP -t 306. 进阶技巧用脚本把重复的巡检和验证自动化做到这里一套 Oracle 云基础架构基本能跑了。但真正让这套东西可持续的是把日常巡检和上线前验证自动化。我自己的习惯是写一个巡检脚本每天定时跑把关键指标落库出问题的时候有历史数据可查。#!/bin/bash # oracle_daily_check.sh - 每日巡检脚本 LOG/var/log/oracle_check_$(date %Y%m%d).log { echo 巡检时间: $(date) # 实例状态 sqlplus -s / as sysdba EOF SELECT instance_name, status FROM v\$instance; SELECT name, open_mode FROM v\$database; -- 表空间使用率 SELECT tablespace_name, ROUND(used_percent,2) FROM dba_tablespace_usage_metrics; -- 等待事件 TOP5 SELECT event, time_waited FROM v\$system_event WHERE wait_class ! Idle ORDER BY time_waited DESC FETCH FIRST 5 ROWS ONLY; -- 无效对象 SELECT COUNT(*) FROM dba_objects WHERE statusINVALID; EXIT; EOF # 监听状态 lsnrctl status | grep -E READY|BLOCKED # 磁盘使用率 df -h | grep -E /u01|/data } $LOG 21 # 保留最近 30 天日志 find /var/log -name oracle_check_*.log -mtime 30 -delete这个脚本把实例状态、表空间、等待事件、无效对象、监听、磁盘六项串起来输出到按日期命名的日志文件。dba_tablespace_usage_metrics直接给出使用率百分比比手算方便。FETCH FIRST 5 ROWS ONLY是 12c 以上语法11g 要换成ROWNUM 5。最后一行清理 30 天前的日志避免日志把盘占满——这个坑我踩过巡检脚本自己把盘写满了。脚本跑起来之后配合云上的监控告警基本能做到问题早发现。但脚本不是万能的它只能告诉你「哪里不对」不能告诉你「为什么不对」。真正出问题时还是要回到前面几节的排查思路从现象倒推原因。我自己的教训是别等出事了才写巡检脚本也别指望一个脚本覆盖所有场景。先跑起来再根据实际报警慢慢加检查项比一开始就追求大而全要靠谱得多。希望帮到你。本文还有配套的精品资源点击获取 Oracle云基础架构平台解决方案：从零搭建到上线的落地实践
简介这份《Oracle云基础架构平台解决方案》PDF面向售前技术人员、培训人员、合作伙伴及对Oracle云计算感兴趣的读者系统梳理了Oracle云基础架构的整体架构与落地思路可帮助读者理解企业构建私有云、公有云或混合云环境时的关键设计要点。资源包内仅含1个PDF文件大小约3.72MB内容涵盖计算、存储、网络、云安全、运营子系统、应用云子系统、软硬件配置清单、API与集成、合作伙伴关系及售后服务支持等模块并附有版本修订记录与阅读对象说明便于按章节查阅。目前已有99人学习下载。读者可从中获取云平台分层架构的完整描述、各子系统职责划分、软硬件选型参考以及跨云集成与运维自动化的基本思路适合作为方案规划与架构学习的参考资料。1. Oracle 云基础架构平台解决方案从一台数据库到一套可交付的云底座很多团队第一次接触「Oracle 云基础架构平台解决方案」这个词是在一份几十页的 PDF 里——里面画满了区域、可用域、虚拟云网络、块存储、负载均衡的架构图看完觉得都对合上文档却不知道明天该敲哪条命令。我当年也是这样把方案文档当科普读物翻了三遍直到真正要在一周内把一套 Oracle 数据库迁到云上才发现文档里没写的东西才是要命的网络怎么切、存储怎么选、监听怎么配、备份怎么验证。这篇笔记不讲空泛的架构愿景只讲一件事如果你手上有一份 Oracle 云基础架构平台解决方案或者你正准备自己搭一套从零到能跑业务中间那些必须落地的步骤、参数和坑我按自己踩过的顺序讲一遍。适合两类人一类是要把本地 Oracle 数据库往云上搬的 DBA 和运维另一类是需要在云上从零规划一套 Oracle 基础架构的架构师。新手能照着命令走熟手能直接跳到参数和边界那几节。2. 先想清楚Oracle 云基础架构到底由哪几层拼起来2.1 计算、存储、网络三件套的对应关系Oracle 云基础架构OCI的底座说穿了就是三样东西计算实例、块存储、虚拟云网络。方案文档里那些花哨的名字落到操作层面就是这三样在组合。计算实例对应你原来机房里的物理机或虚拟机块存储对应你挂在服务器上的盘虚拟云网络对应你机房里的交换机和防火墙策略。理解这个对应关系很重要因为迁移时你脑子里要做的映射是原来数据库跑在哪台机器上、数据放在哪个盘、应用怎么连过来。这三件事想清楚了云上的架构自然就出来了。我一般会先画一张表把本地的机器、磁盘、网段列出来再逐个映射到云上的资源类型映射不上的地方就是后面要重点验证的风险点。本地资源云上对应关键差异物理服务器计算实例灵活配置规格可在线调整但调整需重启本地磁盘 / SAN块存储卷性能按 VPU 计费需预估 IOPS交换机 / 防火墙虚拟云网络 安全列表规则默认拒绝需显式放行负载均衡设备负载均衡器后端集健康检查要单独配这张表不是让你照抄而是让你在动手前把「哪些是等价替换、哪些是行为差异」分清楚。等价替换的部分可以放心搬行为差异的部分必须实测。2.2 区域与可用域容灾不是勾选项是网络设计题方案里一定会提区域和可用域很多人把它当成容灾开关勾上就以为高可用做完了。实际上可用域的选择直接决定你的网络怎么划、存储怎么放、延迟是多少。同一个区域内的不同可用域之间延迟通常在个位数毫秒跨区域就是几十毫秒起步这个差距对数据库主备同步是致命的。我的做法是主库和备库放在同一区域的不同可用域应用服务器跟主库放同一可用域跨区域只做备份归档不做实时同步。这样既拿到了可用域级别的容灾又不会让同步延迟拖垮业务。方案文档里如果只写了「建议跨可用域部署」而没写延迟数据那这段就是给你留的作业得自己测。2.3 从方案文档到可执行清单的拆解方法拿到一份解决方案 PDF不要从头读到尾。我的习惯是先翻到架构图那一页把图上的每个方框抄下来变成一个资源清单然后翻到参数配置章节把每个方框对应的规格、数量、网段填进去最后翻到实施步骤对照清单看有没有遗漏。拆完之后你会得到一张类似这样的清单几个计算实例、每个实例什么规格、挂几块盘、每块盘多大、在哪个子网、开放哪些端口、备份策略是什么。这张清单才是你真正要执行的东西PDF 本身只是参考。清单里任何一项写不出具体数字就说明方案在这一块是模糊的需要你自己补决策。3. 把 Oracle 数据库搬上云实例、存储与网络的最小落地路径3.1 计算实例规格怎么选才不浪费也不翻车选规格这件事新手最容易犯的错是照着本地服务器的配置往上套。本地是 16 核 64G云上也买个差不多的结果发现云上的核和本地的核不是一回事性能对不上。Oracle 数据库对 CPU 和内存的比例很敏感OLTP 场景一般内存是 CPU 核数的 4 到 8 倍比较稳OLAP 场景内存可以再高一些。我一般会先按现有数据库的 AWR 报告估算看 DB CPU 和 DB Time 的比例看每秒逻辑读再折算到云上的规格。如果拿不到 AWR就按经验值起步然后压测调整。起步配置宁可小一点云上扩容比缩容容易而且扩容只需要重启不会丢数据。# 查看当前数据库的 CPU 和内存使用基线在源库执行 sqlplus / as sysdba EOF -- 查看实例启动以来的 CPU 时间 SELECT name, value FROM v\$sysstat WHERE name IN (CPU used by this session, parse time cpu); -- 查看 SGA 和 PGA 配置 SHOW PARAMETER sga_target; SHOW PARAMETER pga_aggregate_target; -- 查看逻辑读用于估算 IOPS 需求 SELECT name, value FROM v\$sysstat WHERE name session logical reads; EOF这段脚本的作用是拿到源库的资源基线。CPU used by this session是累计 CPU 消耗配合实例启动时间能算出平均 CPU 使用率session logical reads是逻辑读总量除以运行秒数就是每秒逻辑读再乘以块大小通常 8K就是每秒 IO 量级用来反推块存储的 VPU 需求。参数上sga_target和pga_aggregate_target决定了内存规格的下限云上实例内存不能低于这两个值之和再加操作系统开销。3.2 块存储的 VPU 与 IOPS别等业务卡了才回头加盘块存储是云上最容易低估的一块。本地磁盘你买回来性能是固定的云上块存储的性能跟容量和 VPU 挂钩选小了业务一压就卡。Oracle 数据库的 redo 日志对写延迟极其敏感数据文件对吞吐敏感这两类盘要分开考虑。我的做法是redo 日志单独挂一块盘选高 VPU 低容量数据文件挂一块大容量盘VPU 按每秒逻辑读折算归档和备份再挂一块普通盘。三块盘分开既方便调优也方便出问题时定位是哪一类 IO 拖后腿。# 在云主机上确认块存储挂载和 IO 调度器 lsblk -o NAME,SIZE,TYPE,MOUNTPOINT # 查看每块盘的调度器数据库盘建议用 none 或 mq-deadline cat /sys/block/sdb/queue/scheduler # 临时调整调度器重启失效需写进 udev 规则 echo mq-deadline /sys/block/sdb/queue/scheduler # 用 fio 做一次写延迟基线测试注意不要在生产盘上跑 fio --namerandwrite --ioenginelibaio --iodepth32 --rwrandwrite \ --bs8k --direct1 --size1G --runtime60 --filename/data/testfilelsblk确认盘挂上了没有scheduler决定 IO 请求怎么排队数据库盘用mq-deadline或none比默认的cfq更稳。fio那段是写延迟基线重点看lat (usec)那一行的 p99 值如果 p99 超过 1msredo 日志放这块盘上就要谨慎。注意--filename指向测试文件别指向真实数据文件跑之前确认路径。3.3 虚拟云网络与安全列表监听器起不来的头号原因网络这块方案文档通常画得很清楚但落地时最常卡在安全列表上。Oracle 监听默认走 1521 端口云上的安全列表默认拒绝所有入站你不显式放行监听起得来但连不上。这个坑我踩过不止一次现象是lsnrctl status显示正常客户端就是ORA-12518: 监听程序无法分发。排查顺序是先在云主机上tnsping自己通了说明监听没问题再从客户端tnsping不通就是网络或安全列表最后看安全列表的入站规则有没有放行 1521 和客户端所在网段。# 在数据库主机上确认监听状态和端口 lsnrctl status netstat -tlnp | grep 1521 # 从客户端测试连通性 tnsping 数据库主机IP:1521/服务名 # 如果超时检查安全列表入站规则是否放行源网段到 1521lsnrctl status看监听是否 READYnetstat确认 1521 在监听。tnsping是最直接的连通性测试超时基本就是网络层被拦了。安全列表规则要写清楚源 CIDR不要图省事写0.0.0.0/0数据库端口暴露到公网是等保检查的重点项方案里如果没提这条实施时一定要补上。4. 上线前必须过的验证关备份、恢复与性能基线4.1 备份策略能恢复才算备份不能恢复只是占地方云上的备份比本地方便但方便不等于可靠。我见过太多团队开了自动备份就以为万事大吉真出事的时候发现备份文件在恢复脚本跑不通。备份策略要回答三个问题备份频率、保留周期、恢复演练频率。前两个方案文档里一般有第三个通常没人写。我的习惯是上线前做一次完整恢复演练从备份里恢复一个实例跑一遍应用连接测试确认数据一致。演练不通过备份策略就不算完成。这一步花半天时间能省掉出事时几天的救火。# 用 RMAN 做一次全库备份到云块存储 rman target / EOF CONFIGURE BACKUP OPTIMIZATION ON; CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS; BACKUP AS COMPRESSED BACKUPSET DATABASE PLUS ARCHIVELOG; -- 校验备份集完整性 VALIDATE BACKUPSET ALL; EOFRETENTION POLICY决定保留窗口7 天是常见起步值按业务合规要求调整。BACKUP AS COMPRESSED BACKUPSET压缩备份集省存储但增加 CPU 开销CPU 紧张的库可以去掉压缩。VALIDATE BACKUPSET是关键一步它校验备份文件是否可读、块是否完整不做这步你永远不知道备份是不是坏的。4.2 恢复演练把「应该能恢复」变成「确实恢复过」恢复演练不是把备份还原回去就完事要验证的是恢复出来的库能不能被应用正常使用。步骤是起一个临时实例恢复数据文件和控制文件做一次不完全恢复或完全恢复然后让应用连上去跑核心查询。# 在临时实例上做恢复演练 rman target / EOF STARTUP NOMOUNT; RESTORE CONTROLFILE FROM 备份控制文件路径; ALTER DATABASE MOUNT; RESTORE DATABASE; RECOVER DATABASE; ALTER DATABASE OPEN RESETLOGS; EOF # 恢复后验证数据一致性 sqlplus / as sysdba EOF SELECT COUNT(*) FROM 核心业务表; SELECT MAX(created_date) FROM 核心业务表; EOFRESTORE CONTROLFILE先恢复控制文件因为控制文件里记录了数据文件的位置和备份信息。RECOVER DATABASE应用归档日志到一致点。OPEN RESETLOGS打开数据库这一步之后原备份链就断了所以演练要在隔离环境做。最后两条查询是验证数据到没到预期时间点MAX(created_date)能看出恢复到了哪个时刻。4.3 性能基线上线前不测上线后就是玄学性能基线是很多人跳过的一步觉得业务还没上测了也没意义。实际上基线的作用是给你一个参照系业务上线后变慢了你能判断是业务量涨了还是系统退化了。基线要测三类CPU 密集查询、IO 密集查询、并发连接。# 用 swingbench 或类似工具做并发基线测试 # 这里用简单的并发查询模拟 for i in $(seq 1 50); do sqlplus -s user/pass//主机:1521/服务名 EOF SELECT /* FULL(t) */ COUNT(*) FROM 大表 t; EXIT; EOF done wait # 测试期间在数据库端观察等待事件 sqlplus / as sysdba EOF SELECT event, total_waits, time_waited FROM v\$system_event WHERE wait_class ! Idle ORDER BY time_waited DESC FETCH FIRST 10 ROWS ONLY; EOF并发查询模拟的是多用户同时访问的场景让查询后台并行wait等全部结束。数据库端的v$system_event看等待事件如果db file sequential read排前面说明 IO 是瓶颈latch: shared pool排前面说明共享池有争用。基线数据记下来上线后对比差异超过 20% 就要查原因。5. 避坑与排查那些方案文档不会写的翻车现场5.1 监听服务无法启动先看日志再看权限现象lsnrctl start卡住或报错lsnrctl status显示监听未启动。原因通常是监听日志文件满了或者权限不对。Oracle 监听日志默认在$ORACLE_HOME/network/log/下长期不清理会涨到几个 G写不进去就起不来。解决清理监听日志确认listener.ora和日志目录的属主是 oracle 用户。# 查看监听日志大小 ls -lh $ORACLE_HOME/network/log/listener.log # 清理日志先备份再清空 cp $ORACLE_HOME/network/log/listener.log /tmp/listener.log.bak $ORACLE_HOME/network/log/listener.log # 确认权限 ls -l $ORACLE_HOME/network/log/5.2 ORA-12518 监听程序无法分发连接数打满了现象客户端报ORA-12518: 监听程序无法分发但监听状态正常。原因是数据库的processes或sessions参数达到上限新连接分不出去。解决查当前连接数调大processes和sessions重启生效。-- 查看当前连接数和参数上限 SELECT COUNT(*) FROM v$session; SHOW PARAMETER processes; SHOW PARAMETER sessions; -- 调大参数需重启 ALTER SYSTEM SET processes500 SCOPESPFILE; ALTER SYSTEM SET sessions555 SCOPESPFILE;5.3 12c 删除不干净导致重装失败注册表和残留文件现象卸载 Oracle 12c 后重装报各种奇怪的错误比如端口被占、实例名冲突。原因是卸载没清干净注册表项、环境变量、/etc/oratab、/etc/oraInst.loc都有残留。解决手动清理这些位置重启后再装。# 清理残留文件 rm -f /etc/oratab /etc/oraInst.loc rm -rf /u01/app/oracle /u01/app/oraInventory # 清理环境变量检查 ~/.bash_profile 里的 ORACLE_HOME 等 grep -i oracle ~/.bash_profile # 确认没有残留进程 ps -ef | grep -i oracle | grep -v grep5.4 等保检查项默认配置过不了现象等保测评时被指出数据库存在弱口令、端口暴露、审计未开启等问题。原因是默认安装的配置不符合等保要求。解决改口令策略、限制监听端口访问来源、开启审计、关闭不必要的服务。-- 开启数据库审计 ALTER SYSTEM SET audit_trailDB,EXTENDED SCOPESPFILE; -- 查看当前口令策略 SELECT * FROM dba_profiles WHERE resource_name LIKE PASSWORD%; -- 修改口令有效期和复杂度 ALTER PROFILE DEFAULT LIMIT PASSWORD_LIFE_TIME 90; ALTER PROFILE DEFAULT LIMIT FAILED_LOGIN_ATTEMPTS 5;5.5 跨可用域延迟导致主备同步慢先测再定架构现象主备库跨可用域部署后备库延迟持续增长。原因是跨可用域的网络延迟比预期高redo 传输跟不上。解决先测实际延迟如果超过 5ms考虑把备库放到同可用域或者改用异步同步。# 测试两台主机之间的网络延迟 ping -c 100 备库IP | tail -1 # 用 iperf3 测带宽 iperf3 -c 备库IP -t 306. 进阶技巧用脚本把重复的巡检和验证自动化做到这里一套 Oracle 云基础架构基本能跑了。但真正让这套东西可持续的是把日常巡检和上线前验证自动化。我自己的习惯是写一个巡检脚本每天定时跑把关键指标落库出问题的时候有历史数据可查。#!/bin/bash # oracle_daily_check.sh - 每日巡检脚本 LOG/var/log/oracle_check_$(date %Y%m%d).log { echo 巡检时间: $(date) # 实例状态 sqlplus -s / as sysdba EOF SELECT instance_name, status FROM v\$instance; SELECT name, open_mode FROM v\$database; -- 表空间使用率 SELECT tablespace_name, ROUND(used_percent,2) FROM dba_tablespace_usage_metrics; -- 等待事件 TOP5 SELECT event, time_waited FROM v\$system_event WHERE wait_class ! Idle ORDER BY time_waited DESC FETCH FIRST 5 ROWS ONLY; -- 无效对象 SELECT COUNT(*) FROM dba_objects WHERE statusINVALID; EXIT; EOF # 监听状态 lsnrctl status | grep -E READY|BLOCKED # 磁盘使用率 df -h | grep -E /u01|/data } $LOG 21 # 保留最近 30 天日志 find /var/log -name oracle_check_*.log -mtime 30 -delete这个脚本把实例状态、表空间、等待事件、无效对象、监听、磁盘六项串起来输出到按日期命名的日志文件。dba_tablespace_usage_metrics直接给出使用率百分比比手算方便。FETCH FIRST 5 ROWS ONLY是 12c 以上语法11g 要换成ROWNUM 5。最后一行清理 30 天前的日志避免日志把盘占满——这个坑我踩过巡检脚本自己把盘写满了。脚本跑起来之后配合云上的监控告警基本能做到问题早发现。但脚本不是万能的它只能告诉你「哪里不对」不能告诉你「为什么不对」。真正出问题时还是要回到前面几节的排查思路从现象倒推原因。我自己的教训是别等出事了才写巡检脚本也别指望一个脚本覆盖所有场景。先跑起来再根据实际报警慢慢加检查项比一开始就追求大而全要靠谱得多。希望帮到你。本文还有配套的精品资源点击获取