简介这是一份2021年3月发布的《Oracle一体机介绍》PPT演示文稿聚焦甲骨文数据库一体机的设计思想、架构演进与性能优势面向数据库管理员、系统架构师和售前售后技术人员也可用于企业在技术选型前快速建立整体认知。内容完整梳理ODA从X3-2到X8-2各代产品的更新脉络重点讲解X8系列三款型号的硬件规格、高可用存储与磁盘组设计并通过与传统自建x86方案在部署时间、维护成本、事务处理能力上的对比展示一体机在简化IT环境、缩短部署周期、提升整体性能方面的价值PPT还列出OLTP与DSS工作负载、每秒事务数、IOPS及吞吐量等实测数据信息密度较高。资源包内共1个文件是6.66MB的PPTX格式课件图文编排完整可直接用于内部培训或自行整理学习笔记。目前已有472人浏览学习对希望系统了解Oracle一体机知识体系的读者有实用参考价值。1. Oracle一体机是什么先看清这是台数据库官配整机Oracle一体机不是一台高配服务器而是Oracle官方把数据库软件、计算节点、存储节点、网络交换和管理工具按固定规格打包好的整机方案。2021年3月那会儿很多从传统单机或虚拟化平台迁过来的团队都在评估它买之前问得最多的是我到底是买Exadata还是普通PC Server装Oracle。这个问题不先想清楚机器到货后往往只用上十分之一的能力存储智能卸载没用、RAC没发挥、补丁还在手工打性能还不如原来那台旧服务器。我按自己落地踩过坑的路径来讲先帮你看清要不要买、买哪条线再给部署命令、必调参数和排错清单适合正在做预算的DBA、运维负责人和刚接手机器的值班工程师。2. Exadata、ODA、PCA三条产品线选型错一环后面全是被动Oracle一体机这个名字背后其实有三条差别很大的产品线混在一起聊必然翻车。我见过最典型的翻车场景是一个日活不高、总数据量不到2TB的团队听销售讲完Exadata的智能存储多厉害就下单到货后才发现最值钱的存储卸载功能根本跑不满还要为每个CPU付昂贵的许可费。反过来也有核心系统明明扛不住大并发却买了一台小ODA硬撑业务一上量就只能扩机型。所以选型这一步花一天时间想清楚能省后面一年的运维钱。2.1 三条产品线的定位一张表看透谁在买、买来干嘛先把三条线放在同一张表里看后面所有参数、命令、坑都在这张表上对齐。产品线官方定位典型硬件形态适合业务许可模式Exadata数据库云服务器计算节点存储节点CellRoCE/InfiniBand网络核心交易、实时数仓、高并发OLTP/OLAP混合数据库许可按CPU单独算Exadata系统本身有底座许可ODA数据库一体机Database Appliance2U或4U机架式计算存储一体中小规模核心库、分支机构、单实例或双节点RAC软硬捆绑内置Oracle Database许可PCA私有云一体机多节点机架带虚拟化管理和云管平台私有云IaaS底座上面跑数据库、中间件、应用按CPU或按订阅数据库许可另算这张表是判断项目起点的地方新人最容易搞混的是ODA和Exadata。ODA的知识体系是一台服务器本地盘Linux/虚拟化DBA以前怎么管Linux服务器到ODA上还是那套Exadata多了存储节点、存储网络和cell服务它已经不是一台服务器而是一个小型数据中心值班工程师需要同时懂网络、存储和数据库。PCA就更偏云管方向如果诉求只是跑Oracle业务库我不会推荐PCA除非你已经明确要建整套私有云。一个很实际的选型参考标准是数据量和并发。总数据量在几TB到几十TB、并发连接几百以内、业务要求Oracle数据库完整能力ODA足够数据量大、SQL复杂、存储层的扫描和过滤压力明显Exadata的智能存储卸载才物有所值。很多团队在ODA上跑数仓跑不动不是硬件不行而是选了没有存储卸载能力的产品线SQL全压在数据库层算。2.2 为什么ODA是小团队首选许可、运维、扩展三个维度从预算角度ODA最有吸引力的地方是许可捆绑。传统模式下买X86服务器装OracleCPU许可要单独向Oracle买两路服务器两个物理CPU就要按核数核费。ODA把Oracle Database许可做进了整机报价里看起来首次采购比普通服务器贵不少但算上许可费、后续的Oracle技术支持服务往往三年总成本反而低。2021年3月前后我做的几个中型项目最后都是被这个账算过去的。从运维角度ODA有odacli命令体系补丁升级、固件更新、组件状态检查一条命令能看完这对值班团队极其友好。常见做法是# 查看ODA所有组件的补丁和版本 odacli describe-component # 查看已安装的数据库系统版本 odacli describe-dbsystem -i dbsystem1 # 查看最新可用的补丁包 odacli list-available-updatesodacli是ODA专用的管理工具不用再登录每个节点手工打数据库补丁。describe-component输出的是固件、驱动、操作系统、数据库软件分层版本list-available-updates拉的是ODA专用的季度补丁包比去每个产品页面找省力得多。小团队通常没有专职的系统工程师这套封装能把日常补丁工作压到半小时以内。从扩展维度ODA的短板也在这里。计算和存储在一个框里扩容要么换大机型要么通过外部存储扩展灵活性不如Exadata的计算和存储分离。所以选型时就要给未来两三年留出余量买小了后面没有后悔药。2.3 2021年3月这个时间点版本和补丁该盯什么标题里的202103落到具体操作上就是版本基线问题。2021年3月Oracle数据库的主流长稳版本是19c它也是当时最适合跑在一体机上的生产版本。RAC、ASM、Data Guard、分区这些都是成熟功能19c的补丁体系也很规律季度RU加安全补丁。21c在2021年初发布但那版定位是云优先很多特性还没经过一体机大规模生产验证我的做法是生产环境锁死19c21c只留给测试。一体机的补丁管理和普通服务器最大的区别是它不只是数据库补丁还有固件、驱动、ILOM管理控制器、存储固件一层叠着一层。Exadata有一套专门的补丁工具patchmgrODA就是前面的odacli。查询补丁的路径是通过My Oracle Support的补丁下载页按产品线和版本过滤千万不要在已经跑业务的机器上直接打数据库临时补丁一体机的硬件固件和数据库软件有严格的兼容矩阵。等保相关的安全配置也是这个阶段要做的事。等保测评要求的账号策略、口令复杂度、审计策略、最小权限在Oracle里都有对应的命令。比如开启统一审计ALTER SYSTEM SET audit_trail DB, EXTENDED SCOPE SPFILE; AUDIT SELECT, INSERT, UPDATE, DELETE ON hr.employees BY ACCESS;audit_trail设置为DB,EXTENDED是把审计记录写进数据库的审计表并记录绑定变量和SQL文本这是满足等保对数据库审计要求的基础动作。AUDIT语句按访问粒度记录指定对象的增删改查避免只记会话不记语句事后追查能定位到具体操作。如果一体机要过等保这类配置要写进初始化脚本而不是系统管理员手工一条条敲。选型定下来之后下一步就是落地部署。很多人觉得一体机送过来是开箱即用的黑匣子其实网络规划不对后面动不动就出问题。3. 部署落地从拆箱到生产库跑通的全链路开箱之后不是直接插电就能用。一体机出厂前厂商会做预配置但机房里的网络、磁盘组、数据库实例还是得自己落地。这一章按我完整的部署顺序写先定网络再建ASM磁盘组然后用dbca建库最后决定单实例还是RAC。3.1 网络规划管理、业务、存储三类网段的IP与MTU怎么定Oracle一体机的网络至少分三层ILOM管理网、业务数据网、存储内部网Exadata上是RoCE或InfiniBandODA内部走SAS。最常见的部署事故是把管理网和业务网混在一起平时看着没事一旦做固件升级或节点重启ILOM断连导致远程控制台失联值班的人只能跑机房。我的落地方案是三类网段物理分开至少用两种交换机或VLAN彻底隔离。管理网负责ILOM和硬件管理IP建议单独划一个/24网段不跑业务流量业务网给应用连数据库按应用网段规划并预留扩展存储网在Exadata上由内置交换机承担ODA没有外部存储网。MTU这里值得注意业务网如果不跑vxlan用标准1500没问题Exadata存储内部网MTU由一体机统一管理不要手工去改改错了存储节点互连会掉。配IP时把IP地址和用途写进资产表等保检查时也拿得出来。如果用的是ODA网络要简单很多。四块网口默认分管理口和业务口绑定方式和IP地址在首次配置向导里完成。这一步的坑是忘记预留备份和心跳网段RAC的私有互联网其实可以走一体机内部但备份软件需要单独VLAN等到排备份再补网络就麻烦。3.2 用ASM把磁盘组建出来进入asm的命令和初次配置一体机的存储最终都以ASM磁盘组的形式交给数据库使用。建磁盘组之前先确认磁盘已经被操作系统识别并被Oracle ASM识别。普通Linux服务器上常见用oracleasm工具或udev绑定ODA和Exadata上则用asmcmd来判断。# 用asmcmd查看本机的磁盘发现路径 asmcmd lsdsk --discovery # 查看当前已挂载的磁盘组 asmcmd lsdg # 列出候选磁盘路径 asmcmd lsdsk -p -t DATAlsdsk --discovery列出的是ASM实例能看到的候选磁盘路径如果输出为空问题出在操作系统层的磁盘权限或ASM磁盘绑定lsdg显示磁盘组名称、大小、空闲量和冗余模式这是部署时最常看的输出lsdsk -p -t DATA可以看某个磁盘组的候选盘。磁盘没找到时先检查设备属主是否为oracle用户和asmadmin组再查udev规则。确认磁盘可见之后用SQL创建磁盘组。生产环境的冗余模式建议用NORMAL至少两路镜像CREATE DISKGROUP DATA NORMAL REDUNDANCY DISK /dev/oracleasm/disks/DATA01, /dev/oracleasm/disks/DATA02, /dev/oracleasm/disks/DATA03, /dev/oracleasm/disks/DATA04 ATTRIBUTE au_size4M;au_size设置为4M是OLTP和OLAP混合负载的常用起点如果全是超大扫描的数仓可以设8M。NORMAL冗余下任意一块盘损坏ASM能利用镜像自动修复external redundancy没有这层保护万一磁盘坏了只能靠备份恢复。注意磁盘组创建后大小不能缩小所以第一次规划就按三年增长预期建不要一个月后看到空间紧张又要加盘。接下来把快闪日志区和归档区也建出来。常见做法是单独建一个RECO磁盘组放闪回日志和归档避免归档满把数据盘的IO拖死CREATE DISKGROUP RECO NORMAL REDUNDANCY DISK /dev/oracleasm/disks/RECO01, /dev/oracleasm/disks/RECO02, /dev/oracleasm/disks/RECO03 ATTRIBUTE au_size4M;3.3 用dbca静默建库参数抄作业与说明磁盘组建好后用dbca静默方式建库是效率最高的路径。图形界面点半天容易点错静默模式把参数写清楚直接跑不依赖X11转发适合远程部署。dbca -silent -createDatabase \ -templateName General_Purpose.dbc \ -gdbName PROD -sid PROD \ -sysPassword Sys_Admin_2021# \ -systemPassword System_Admin_2021# \ -emConfiguration NONE \ -storageType ASM \ -diskGroupName DATA \ -recoveryAreaDestination RECO \ -characterSet ZHS16GBK \ -memoryPercentage 40 \ -nodeInfo prod1,prod2-templateName用通用模板适合OLTP起步数据仓库可以换Data Warehouse模板。sysPassword和systemPassword在生产环境必须满足口令复杂度2021年后等保要求普遍严格别再用默认密码。storageType指定ASMdiskGroupName指向刚建的DATA组recoveryAreaDestination指到RECO组数据库的闪回区和快速恢复区就落在独立磁盘组上。characterSet设ZHS16GBK要注意数据库字符集建好后改非常麻烦先确认业务是纯中文和繁体需求再决定用AL32UTF8还是ZHS16GBK。memoryPercentage给到40是保守值如果物理内存足够大可以提到60但要保证操作系统的pagecache还有余量。dbca跑完以后第一件事不是马上连业务而是看alert日志有没有ORA错误。常见做法是跟踪$ORACLE_BASE/diag/rdbms/PROD/PROD/trace/alert_PROD.log确认数据库正常open再跑一遍健康检查。提示如果dbca中途失败先看日志再重跑不要反复执行脚本残留的实例和监听配置会让第二次建库更乱。3.4 单实例还是RAC19c单实例搭建DG是个好切入口如果团队以前只用过单机Oracle又被要求上高可用我一般会劝他们从单实例做起先把数据保护做扎实再做实例级高可用。一体机虽然出厂支持RAC但RAC上线意味着集群件CRS、VIP、scan listener、OCR、投票盘都要值班团队能扛住。2021年这个节点很多人接触一体机就是为了跑19c单实例搭建DG这个路径最适合先跑通。19c单实例搭建DG的要点是主备结构一致参数和日志传输配好-- 主库开启归档和强制日志 ALTER DATABASE ARCHIVELOG; ALTER DATABASE FORCE LOGGING; -- 配置DG broker简化日常切换 ALTER SYSTEM SET dg_broker_startTRUE; -- 备库上创建standby日志组规格和主库在线日志一致 ALTER DATABASE ADD STANDBY LOGFILE GROUP 11 SIZE 512M;第一条命令让数据库进入归档模式Data Guard必须基于归档和在线日志传输force logging保证即使有nologging操作也能传到备库避免备库丢数据。dg_broker_start打开Data Guard Broker之后用dgmgrl命令行执行failover或switchover比手工管理日志序列简单很多。standby日志组的大小和数量要和主库在线日志对齐不然切换时日志切换频繁会影响性能。单实例DG这套架构对中小团队已经能满足大多数高可用需求。RAC解决的是单实例算力不足和实例级故障如果你的瓶颈不在算力先把DG做扎实后面平滑演进到RAC也不迟。4. 性能与日常维护把一体机的智能存储真正用起来一体机买回来最痛的一点是DBA还拿它当普通服务器调优改buffer cache、改shared pool却忽略了存储节点上的智能卸载能力。Exadata值钱就在cellODA虽然没有cell但也有值得盯的参数和巡检点。我习惯从三个维度来看让查询在存储端先过滤、三处必调参数、日常巡检清单。4.1 cell_offload_processing让查询在存储端先过滤Exadata的每个存储节点上跑着cell服务能做条件过滤、行和列裁剪、布隆过滤。控制这个能力的开关是cell_offload_processing参数。很多系统跑着跑着变慢翻AWR发现某条SQL很大但cell那边一点没干活先查这个参数SELECT name, value FROM v$parameter WHERE name LIKE cell_offload%; ALTER SYSTEM SET cell_offload_processing TRUE; -- 看一条SQL到底有没有做storage offload SELECT sql_id, cell_offload_eligible, io_cell_offload_eligible_bytes, io_cell_offload_returned_bytes FROM v$sql WHERE sql_id sql_id;cell_offload_processing默认是TRUE但影响它的是查询条件、分区裁剪、函数使用。v$sql里io_cell_offload_eligible_bytes表示本来要扫到数据库层的字节数io_cell_offload_returned_bytes是存储节点过滤后真正返回的字节数两者差距越大说明卸载效果越好。如果你看到一个SQL的eligible_bytes大、returned_bytes也大说明cell没滤掉东西要往谓词上找原因。常用的卸载场景是全表扫描加where过滤比如一个大分区表按天滚动查询里带分区键和订单时间InCell过滤能直接跳过无关分区。反过来OLTP点位查询走索引本身就不需要全表扫卸载效果反而不明显。所以选型时如果业务全是主键等值查询Exadata的存储卸载优势不大这也是前面选型要提前想清楚的原因。4.2 三处必调参数内存、并行、日志归档数据库装好后有三个参数比默认值更值得调且直接影响一体机的发挥。参数默认表现建议适用场景memory_target/memory_max_target安装时定死物理内存60%左右留足系统缓存OLTP并发高的库parallel_max_servers偏保守按CPU核数调大但设上限有批处理或大查询log_buffer默认偏小8M-16M起步日志写入频繁的OLTPmemory_target调大后shared pool和buffer cache自动在SGA内部调配比手工固定db_cache_size少一些维护量但如果内存特别吃紧还是手工分更可预期。parallel_max_servers调大只能解决并行度不够真正常见的翻车是并行开得太大把DB CPU打满我一般从CPU核数的一半开始调观察AWR里Parallel Execution的等待。log_buffer过小表现为log file sync等待明显调大8M或16M通常能缓解核心还是减少commit频率让应用端批量提交。另一个容易忽略的点是控制文件自动备份和归档清理。一体机存储IO快但归档堆积会写满RECO磁盘组-- 开启控制文件自动备份 CONFIGURE CONTROLFILE AUTOBACKUP ON; -- 查看归档目录使用率 SELECT ROUND(SUM(blocks*block_size)/1024/1024) AS used_mb FROM v$archived_log WHERE deletedNO;CONFIGURE是RMAN的命令控制文件自动备份打开后数据库结构变更会自动备份控制文件否则等保或恢复演练时发现风险。v$archived_log的查询用来确认归档有没有正常删除到备份端如果备份没跑起来这里很快会把RECO组塞满数据库日志应用停摆。4.3 日常巡检清单等保命令、监听日志、ASM空间日常巡检不用每天都跑全套但下面这几条是我每周至少过一遍的。第一条是数据库层面看会话和等待事件确认没有异常互连和锁等待。第二条是监听日志一体机上最常见的监听服务无法启动有一半是listener.log文件太大把分区塞满还有一半是监听端口被占用或改动。# 查看监听日志路径和大小 ls -lh $ORACLE_HOME/network/log/listener.log # 查看当前注册到监听的实例服务 lsnrctl status # 检查ASM磁盘组空间 asmcmd lsdglsnrctl status能看到监听的服务名、主机名、端口和实例状态如果实例没有注册上去检查LREG进程和tnsnames.ora里的连接描述。asmcmd lsdg是检查磁盘组空间的主要命令USABLE_FILE_MB这列是真正可以给数据库用的空间别只看总大小还要留出rebalance和故障重建的余量。如果发现sqlplus登录数据库明显变慢优先怀疑监听日志过大和网络延迟先看listener.log的尾部时间戳。等保相关的巡检命令也要列入例行。比如检查数据库的审计策略是否还在重要用户的权限是否被改动同时看看有没有会话长期占用系统级锁SELECT username, account_status FROM dba_users; SELECT * FROM dba_audit_trail WHERE event_timestamp SYSDATE - 1; -- 查看当前阻塞会话的sid和SQL SELECT sid, serial#, event, blocking_session FROM v$session WHERE blocking_session IS NOT NULL;第一句看账号状态如果发现某个应用账号是OPEN状态且很久没用按最小权限原则锁掉第二句看统一审计记录里有没有异常访问第三句用v$session定位阻塞源拿到sid后再查v$sql对应的SQL文本。一体机的价值之一是性能强但那不意味着可以不做例行巡检机器越贵越要盯紧。5. 避坑一体机环境里最常见的5个翻车现场这里写我反复踩过的坑全按现象、原因、解决的顺序来方便直接对照。5.1 ASM扫不到盘磁盘组一直处于DISMOUNTED现象重启数据库节点后asmcmd lsdg看到磁盘组从MOUNTED变成DISMOUNTEDlsdsk --discovery结果为空应用连接全部失败。原因一体机存储节点或操作系统启动顺序变了ASM磁盘的udev绑定没有生效设备文件权属不对也可能是RAC环境下OCR和投票盘的磁盘组路径变化导致CRS资源起不来。解决先检查/dev/oracleasm/disks下有没有盘再用oracleasm listdisks确认ASM库认识哪些盘。如果是udev规则失效重新加载规则并让oracle用户对这些设备有读写权限。RAC环境里如果要用CRS清除不用的磁盘组先确认该磁盘组没有数据文件再通过crsctl或asmcmd卸载不要直接drop否则会连带OCR信息一起坏掉。第一次遇到时别急着动磁盘组先在操作系统层确认磁盘存在。5.2 补丁打到一半监听服务无法启动现象打完数据库季度补丁lsnrctl start报TNS-12541或TNS-01189应用连接直接失败sqlplus登录也变得缓慢。原因补丁升级过程中监听配置文件listener.ora被更新端口或监听位置变了也可能是监听日志文件过大导致启动超时或者监听端口被其他进程占用。解决先看$ORACLE_HOME/network/log/listener.log的报错常见做法是把listener.ora里的端口改回原值再手动重启监听。如果日志文件超过几百MB先改名备份再重启监听让监听生成新日志。修改默认监听端口后要同步更新tnsnames.ora和防火墙策略不要只改一边。补丁窗口一定要安排在业务低谷打完补丁先验证监听注册再放流量。5.3 SQL在普通服务器上快迁到Exadata反而慢了现象同样的SQL在旧机器上1秒迁到Exadata后执行计划变了跑了十几秒业务方开始质疑一体机的性能。原因Exadata上统计信息没收集CBO选错执行计划或者cell_offload没有生效SQL走了索引全扫描存储卸载没派上用场。解决迁移后第一件事是exec dbms_stats.gather_table_stats把统计信息收一遍再看执行计划是否合理。不要把旧库的执行计划手工hint带过来让CBO基于新统计信息重新决定。对比迁移前后AWR重点看Physical reads和cell等待事件如果cell等待时间异常大再查是不是SQL or pushdown被禁用。5.4 12c删除不干净新环境装到一半报ORA-12547现象以前的Oracle 12c卸载没删干净新一体机上安装19c时报ORA-12547TNS丢失连接安装进程反复回滚。原因残留的/etc/oratab、$ORACLE_HOME软链接、旧的监听进程和内核参数配置跟19c不兼容固件驱动也不匹配。解决装新库前把旧环境彻底清一遍包括删除/opt/ORCLfmap残留、清理/etc/oratab里失效条目、杀掉残留的tnslsnr和ora_pmon进程。一体机上装19c前先确认存储节点固件版本在Oracle支持矩阵里避免固件和驱动不匹配。不要用rm -rf硬删$ORACLE_BASE清理完还要检查/etc/oraInst.loc和/opt/ORCLusm这两处残留最容易导致新安装读错路径。5.5 磁盘坏块导致dbf文件损坏RMAN恢复时发现备份过期现象ASM磁盘组出现坏块某个dbf文件报ORA-01578执行RMAN恢复时提示备份文件已过期或备份片段缺失。原因备份策略里没有做增量备份的定期合并归档保留时间太短坏块发生后找不到可用的备份链RMAN恢复验证也没做备份坏了不知道。解决确认RMAN是否配置了控制文件自动备份并做一次全量加增量备份。出现坏块时先判断能不能通过块级恢复解决-- 先尝试恢复损坏的数据块 RECOVER DATAFILE dbfile; -- 不行就做时间点恢复前提是归档完整 RUN { SET UNTIL TIME TO_DATE(2021-03-01 02:00:00,YYYY-MM-DD HH24:MI:SS); RESTORE DATABASE; RECOVER DATABASE; } ALTER DATABASE OPEN RESETLOGS;RECOVER DATAFILE只恢复单个损坏文件前提是备份和归档都在SET UNTIL TIME做时间点恢复适合坏块影响范围大的情况。关键教训是一体机再稳也要每天验证备份的可恢复性不要等坏了才后悔。6. 验收新机到手先跑这三件事再决定上不上生产机器到货部署完不要急着把业务切过去。我习惯先做三件事。第一件是验证智能存储卸载是否真的生效找一张千万行以上的大表做全表扫描对比cell_offload_eligible_bytes和returned_bytes差距在10倍以上说明cell在工作差距很小就回头查统计信息和执行计划。第二件是验证高可用能力如果是RAC直接kill -9一个实例的PMON进程看会话能不能在几秒内迁移到另一个节点如果是单实例加DG做一次switchover再切回来记录切换时间和数据零丢失。第三件是打一组AWR基线把业务高峰时段的快照保存下来后面性能下降才有对比依据。这三件事做完再跟团队做一次复盘巡检清单谁来跑、补丁窗口怎么排、备份恢复演练多久一次。一体机的上限很高但下限也没有传说中那么低真正决定稳定性的还是接手的人是否熟悉这些命令和参数。这些年我带过的项目里翻车的从来不是机器而是把一体机当普通服务器用的人。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/3 15:47:24 · 阅读 1.2k Oracle一体机选型部署与避坑指南
简介这是一份2021年3月发布的《Oracle一体机介绍》PPT演示文稿聚焦甲骨文数据库一体机的设计思想、架构演进与性能优势面向数据库管理员、系统架构师和售前售后技术人员也可用于企业在技术选型前快速建立整体认知。内容完整梳理ODA从X3-2到X8-2各代产品的更新脉络重点讲解X8系列三款型号的硬件规格、高可用存储与磁盘组设计并通过与传统自建x86方案在部署时间、维护成本、事务处理能力上的对比展示一体机在简化IT环境、缩短部署周期、提升整体性能方面的价值PPT还列出OLTP与DSS工作负载、每秒事务数、IOPS及吞吐量等实测数据信息密度较高。资源包内共1个文件是6.66MB的PPTX格式课件图文编排完整可直接用于内部培训或自行整理学习笔记。目前已有472人浏览学习对希望系统了解Oracle一体机知识体系的读者有实用参考价值。1. Oracle一体机是什么先看清这是台数据库官配整机Oracle一体机不是一台高配服务器而是Oracle官方把数据库软件、计算节点、存储节点、网络交换和管理工具按固定规格打包好的整机方案。2021年3月那会儿很多从传统单机或虚拟化平台迁过来的团队都在评估它买之前问得最多的是我到底是买Exadata还是普通PC Server装Oracle。这个问题不先想清楚机器到货后往往只用上十分之一的能力存储智能卸载没用、RAC没发挥、补丁还在手工打性能还不如原来那台旧服务器。我按自己落地踩过坑的路径来讲先帮你看清要不要买、买哪条线再给部署命令、必调参数和排错清单适合正在做预算的DBA、运维负责人和刚接手机器的值班工程师。2. Exadata、ODA、PCA三条产品线选型错一环后面全是被动Oracle一体机这个名字背后其实有三条差别很大的产品线混在一起聊必然翻车。我见过最典型的翻车场景是一个日活不高、总数据量不到2TB的团队听销售讲完Exadata的智能存储多厉害就下单到货后才发现最值钱的存储卸载功能根本跑不满还要为每个CPU付昂贵的许可费。反过来也有核心系统明明扛不住大并发却买了一台小ODA硬撑业务一上量就只能扩机型。所以选型这一步花一天时间想清楚能省后面一年的运维钱。2.1 三条产品线的定位一张表看透谁在买、买来干嘛先把三条线放在同一张表里看后面所有参数、命令、坑都在这张表上对齐。产品线官方定位典型硬件形态适合业务许可模式Exadata数据库云服务器计算节点存储节点CellRoCE/InfiniBand网络核心交易、实时数仓、高并发OLTP/OLAP混合数据库许可按CPU单独算Exadata系统本身有底座许可ODA数据库一体机Database Appliance2U或4U机架式计算存储一体中小规模核心库、分支机构、单实例或双节点RAC软硬捆绑内置Oracle Database许可PCA私有云一体机多节点机架带虚拟化管理和云管平台私有云IaaS底座上面跑数据库、中间件、应用按CPU或按订阅数据库许可另算这张表是判断项目起点的地方新人最容易搞混的是ODA和Exadata。ODA的知识体系是一台服务器本地盘Linux/虚拟化DBA以前怎么管Linux服务器到ODA上还是那套Exadata多了存储节点、存储网络和cell服务它已经不是一台服务器而是一个小型数据中心值班工程师需要同时懂网络、存储和数据库。PCA就更偏云管方向如果诉求只是跑Oracle业务库我不会推荐PCA除非你已经明确要建整套私有云。一个很实际的选型参考标准是数据量和并发。总数据量在几TB到几十TB、并发连接几百以内、业务要求Oracle数据库完整能力ODA足够数据量大、SQL复杂、存储层的扫描和过滤压力明显Exadata的智能存储卸载才物有所值。很多团队在ODA上跑数仓跑不动不是硬件不行而是选了没有存储卸载能力的产品线SQL全压在数据库层算。2.2 为什么ODA是小团队首选许可、运维、扩展三个维度从预算角度ODA最有吸引力的地方是许可捆绑。传统模式下买X86服务器装OracleCPU许可要单独向Oracle买两路服务器两个物理CPU就要按核数核费。ODA把Oracle Database许可做进了整机报价里看起来首次采购比普通服务器贵不少但算上许可费、后续的Oracle技术支持服务往往三年总成本反而低。2021年3月前后我做的几个中型项目最后都是被这个账算过去的。从运维角度ODA有odacli命令体系补丁升级、固件更新、组件状态检查一条命令能看完这对值班团队极其友好。常见做法是# 查看ODA所有组件的补丁和版本 odacli describe-component # 查看已安装的数据库系统版本 odacli describe-dbsystem -i dbsystem1 # 查看最新可用的补丁包 odacli list-available-updatesodacli是ODA专用的管理工具不用再登录每个节点手工打数据库补丁。describe-component输出的是固件、驱动、操作系统、数据库软件分层版本list-available-updates拉的是ODA专用的季度补丁包比去每个产品页面找省力得多。小团队通常没有专职的系统工程师这套封装能把日常补丁工作压到半小时以内。从扩展维度ODA的短板也在这里。计算和存储在一个框里扩容要么换大机型要么通过外部存储扩展灵活性不如Exadata的计算和存储分离。所以选型时就要给未来两三年留出余量买小了后面没有后悔药。2.3 2021年3月这个时间点版本和补丁该盯什么标题里的202103落到具体操作上就是版本基线问题。2021年3月Oracle数据库的主流长稳版本是19c它也是当时最适合跑在一体机上的生产版本。RAC、ASM、Data Guard、分区这些都是成熟功能19c的补丁体系也很规律季度RU加安全补丁。21c在2021年初发布但那版定位是云优先很多特性还没经过一体机大规模生产验证我的做法是生产环境锁死19c21c只留给测试。一体机的补丁管理和普通服务器最大的区别是它不只是数据库补丁还有固件、驱动、ILOM管理控制器、存储固件一层叠着一层。Exadata有一套专门的补丁工具patchmgrODA就是前面的odacli。查询补丁的路径是通过My Oracle Support的补丁下载页按产品线和版本过滤千万不要在已经跑业务的机器上直接打数据库临时补丁一体机的硬件固件和数据库软件有严格的兼容矩阵。等保相关的安全配置也是这个阶段要做的事。等保测评要求的账号策略、口令复杂度、审计策略、最小权限在Oracle里都有对应的命令。比如开启统一审计ALTER SYSTEM SET audit_trail DB, EXTENDED SCOPE SPFILE; AUDIT SELECT, INSERT, UPDATE, DELETE ON hr.employees BY ACCESS;audit_trail设置为DB,EXTENDED是把审计记录写进数据库的审计表并记录绑定变量和SQL文本这是满足等保对数据库审计要求的基础动作。AUDIT语句按访问粒度记录指定对象的增删改查避免只记会话不记语句事后追查能定位到具体操作。如果一体机要过等保这类配置要写进初始化脚本而不是系统管理员手工一条条敲。选型定下来之后下一步就是落地部署。很多人觉得一体机送过来是开箱即用的黑匣子其实网络规划不对后面动不动就出问题。3. 部署落地从拆箱到生产库跑通的全链路开箱之后不是直接插电就能用。一体机出厂前厂商会做预配置但机房里的网络、磁盘组、数据库实例还是得自己落地。这一章按我完整的部署顺序写先定网络再建ASM磁盘组然后用dbca建库最后决定单实例还是RAC。3.1 网络规划管理、业务、存储三类网段的IP与MTU怎么定Oracle一体机的网络至少分三层ILOM管理网、业务数据网、存储内部网Exadata上是RoCE或InfiniBandODA内部走SAS。最常见的部署事故是把管理网和业务网混在一起平时看着没事一旦做固件升级或节点重启ILOM断连导致远程控制台失联值班的人只能跑机房。我的落地方案是三类网段物理分开至少用两种交换机或VLAN彻底隔离。管理网负责ILOM和硬件管理IP建议单独划一个/24网段不跑业务流量业务网给应用连数据库按应用网段规划并预留扩展存储网在Exadata上由内置交换机承担ODA没有外部存储网。MTU这里值得注意业务网如果不跑vxlan用标准1500没问题Exadata存储内部网MTU由一体机统一管理不要手工去改改错了存储节点互连会掉。配IP时把IP地址和用途写进资产表等保检查时也拿得出来。如果用的是ODA网络要简单很多。四块网口默认分管理口和业务口绑定方式和IP地址在首次配置向导里完成。这一步的坑是忘记预留备份和心跳网段RAC的私有互联网其实可以走一体机内部但备份软件需要单独VLAN等到排备份再补网络就麻烦。3.2 用ASM把磁盘组建出来进入asm的命令和初次配置一体机的存储最终都以ASM磁盘组的形式交给数据库使用。建磁盘组之前先确认磁盘已经被操作系统识别并被Oracle ASM识别。普通Linux服务器上常见用oracleasm工具或udev绑定ODA和Exadata上则用asmcmd来判断。# 用asmcmd查看本机的磁盘发现路径 asmcmd lsdsk --discovery # 查看当前已挂载的磁盘组 asmcmd lsdg # 列出候选磁盘路径 asmcmd lsdsk -p -t DATAlsdsk --discovery列出的是ASM实例能看到的候选磁盘路径如果输出为空问题出在操作系统层的磁盘权限或ASM磁盘绑定lsdg显示磁盘组名称、大小、空闲量和冗余模式这是部署时最常看的输出lsdsk -p -t DATA可以看某个磁盘组的候选盘。磁盘没找到时先检查设备属主是否为oracle用户和asmadmin组再查udev规则。确认磁盘可见之后用SQL创建磁盘组。生产环境的冗余模式建议用NORMAL至少两路镜像CREATE DISKGROUP DATA NORMAL REDUNDANCY DISK /dev/oracleasm/disks/DATA01, /dev/oracleasm/disks/DATA02, /dev/oracleasm/disks/DATA03, /dev/oracleasm/disks/DATA04 ATTRIBUTE au_size4M;au_size设置为4M是OLTP和OLAP混合负载的常用起点如果全是超大扫描的数仓可以设8M。NORMAL冗余下任意一块盘损坏ASM能利用镜像自动修复external redundancy没有这层保护万一磁盘坏了只能靠备份恢复。注意磁盘组创建后大小不能缩小所以第一次规划就按三年增长预期建不要一个月后看到空间紧张又要加盘。接下来把快闪日志区和归档区也建出来。常见做法是单独建一个RECO磁盘组放闪回日志和归档避免归档满把数据盘的IO拖死CREATE DISKGROUP RECO NORMAL REDUNDANCY DISK /dev/oracleasm/disks/RECO01, /dev/oracleasm/disks/RECO02, /dev/oracleasm/disks/RECO03 ATTRIBUTE au_size4M;3.3 用dbca静默建库参数抄作业与说明磁盘组建好后用dbca静默方式建库是效率最高的路径。图形界面点半天容易点错静默模式把参数写清楚直接跑不依赖X11转发适合远程部署。dbca -silent -createDatabase \ -templateName General_Purpose.dbc \ -gdbName PROD -sid PROD \ -sysPassword Sys_Admin_2021# \ -systemPassword System_Admin_2021# \ -emConfiguration NONE \ -storageType ASM \ -diskGroupName DATA \ -recoveryAreaDestination RECO \ -characterSet ZHS16GBK \ -memoryPercentage 40 \ -nodeInfo prod1,prod2-templateName用通用模板适合OLTP起步数据仓库可以换Data Warehouse模板。sysPassword和systemPassword在生产环境必须满足口令复杂度2021年后等保要求普遍严格别再用默认密码。storageType指定ASMdiskGroupName指向刚建的DATA组recoveryAreaDestination指到RECO组数据库的闪回区和快速恢复区就落在独立磁盘组上。characterSet设ZHS16GBK要注意数据库字符集建好后改非常麻烦先确认业务是纯中文和繁体需求再决定用AL32UTF8还是ZHS16GBK。memoryPercentage给到40是保守值如果物理内存足够大可以提到60但要保证操作系统的pagecache还有余量。dbca跑完以后第一件事不是马上连业务而是看alert日志有没有ORA错误。常见做法是跟踪$ORACLE_BASE/diag/rdbms/PROD/PROD/trace/alert_PROD.log确认数据库正常open再跑一遍健康检查。提示如果dbca中途失败先看日志再重跑不要反复执行脚本残留的实例和监听配置会让第二次建库更乱。3.4 单实例还是RAC19c单实例搭建DG是个好切入口如果团队以前只用过单机Oracle又被要求上高可用我一般会劝他们从单实例做起先把数据保护做扎实再做实例级高可用。一体机虽然出厂支持RAC但RAC上线意味着集群件CRS、VIP、scan listener、OCR、投票盘都要值班团队能扛住。2021年这个节点很多人接触一体机就是为了跑19c单实例搭建DG这个路径最适合先跑通。19c单实例搭建DG的要点是主备结构一致参数和日志传输配好-- 主库开启归档和强制日志 ALTER DATABASE ARCHIVELOG; ALTER DATABASE FORCE LOGGING; -- 配置DG broker简化日常切换 ALTER SYSTEM SET dg_broker_startTRUE; -- 备库上创建standby日志组规格和主库在线日志一致 ALTER DATABASE ADD STANDBY LOGFILE GROUP 11 SIZE 512M;第一条命令让数据库进入归档模式Data Guard必须基于归档和在线日志传输force logging保证即使有nologging操作也能传到备库避免备库丢数据。dg_broker_start打开Data Guard Broker之后用dgmgrl命令行执行failover或switchover比手工管理日志序列简单很多。standby日志组的大小和数量要和主库在线日志对齐不然切换时日志切换频繁会影响性能。单实例DG这套架构对中小团队已经能满足大多数高可用需求。RAC解决的是单实例算力不足和实例级故障如果你的瓶颈不在算力先把DG做扎实后面平滑演进到RAC也不迟。4. 性能与日常维护把一体机的智能存储真正用起来一体机买回来最痛的一点是DBA还拿它当普通服务器调优改buffer cache、改shared pool却忽略了存储节点上的智能卸载能力。Exadata值钱就在cellODA虽然没有cell但也有值得盯的参数和巡检点。我习惯从三个维度来看让查询在存储端先过滤、三处必调参数、日常巡检清单。4.1 cell_offload_processing让查询在存储端先过滤Exadata的每个存储节点上跑着cell服务能做条件过滤、行和列裁剪、布隆过滤。控制这个能力的开关是cell_offload_processing参数。很多系统跑着跑着变慢翻AWR发现某条SQL很大但cell那边一点没干活先查这个参数SELECT name, value FROM v$parameter WHERE name LIKE cell_offload%; ALTER SYSTEM SET cell_offload_processing TRUE; -- 看一条SQL到底有没有做storage offload SELECT sql_id, cell_offload_eligible, io_cell_offload_eligible_bytes, io_cell_offload_returned_bytes FROM v$sql WHERE sql_id sql_id;cell_offload_processing默认是TRUE但影响它的是查询条件、分区裁剪、函数使用。v$sql里io_cell_offload_eligible_bytes表示本来要扫到数据库层的字节数io_cell_offload_returned_bytes是存储节点过滤后真正返回的字节数两者差距越大说明卸载效果越好。如果你看到一个SQL的eligible_bytes大、returned_bytes也大说明cell没滤掉东西要往谓词上找原因。常用的卸载场景是全表扫描加where过滤比如一个大分区表按天滚动查询里带分区键和订单时间InCell过滤能直接跳过无关分区。反过来OLTP点位查询走索引本身就不需要全表扫卸载效果反而不明显。所以选型时如果业务全是主键等值查询Exadata的存储卸载优势不大这也是前面选型要提前想清楚的原因。4.2 三处必调参数内存、并行、日志归档数据库装好后有三个参数比默认值更值得调且直接影响一体机的发挥。参数默认表现建议适用场景memory_target/memory_max_target安装时定死物理内存60%左右留足系统缓存OLTP并发高的库parallel_max_servers偏保守按CPU核数调大但设上限有批处理或大查询log_buffer默认偏小8M-16M起步日志写入频繁的OLTPmemory_target调大后shared pool和buffer cache自动在SGA内部调配比手工固定db_cache_size少一些维护量但如果内存特别吃紧还是手工分更可预期。parallel_max_servers调大只能解决并行度不够真正常见的翻车是并行开得太大把DB CPU打满我一般从CPU核数的一半开始调观察AWR里Parallel Execution的等待。log_buffer过小表现为log file sync等待明显调大8M或16M通常能缓解核心还是减少commit频率让应用端批量提交。另一个容易忽略的点是控制文件自动备份和归档清理。一体机存储IO快但归档堆积会写满RECO磁盘组-- 开启控制文件自动备份 CONFIGURE CONTROLFILE AUTOBACKUP ON; -- 查看归档目录使用率 SELECT ROUND(SUM(blocks*block_size)/1024/1024) AS used_mb FROM v$archived_log WHERE deletedNO;CONFIGURE是RMAN的命令控制文件自动备份打开后数据库结构变更会自动备份控制文件否则等保或恢复演练时发现风险。v$archived_log的查询用来确认归档有没有正常删除到备份端如果备份没跑起来这里很快会把RECO组塞满数据库日志应用停摆。4.3 日常巡检清单等保命令、监听日志、ASM空间日常巡检不用每天都跑全套但下面这几条是我每周至少过一遍的。第一条是数据库层面看会话和等待事件确认没有异常互连和锁等待。第二条是监听日志一体机上最常见的监听服务无法启动有一半是listener.log文件太大把分区塞满还有一半是监听端口被占用或改动。# 查看监听日志路径和大小 ls -lh $ORACLE_HOME/network/log/listener.log # 查看当前注册到监听的实例服务 lsnrctl status # 检查ASM磁盘组空间 asmcmd lsdglsnrctl status能看到监听的服务名、主机名、端口和实例状态如果实例没有注册上去检查LREG进程和tnsnames.ora里的连接描述。asmcmd lsdg是检查磁盘组空间的主要命令USABLE_FILE_MB这列是真正可以给数据库用的空间别只看总大小还要留出rebalance和故障重建的余量。如果发现sqlplus登录数据库明显变慢优先怀疑监听日志过大和网络延迟先看listener.log的尾部时间戳。等保相关的巡检命令也要列入例行。比如检查数据库的审计策略是否还在重要用户的权限是否被改动同时看看有没有会话长期占用系统级锁SELECT username, account_status FROM dba_users; SELECT * FROM dba_audit_trail WHERE event_timestamp SYSDATE - 1; -- 查看当前阻塞会话的sid和SQL SELECT sid, serial#, event, blocking_session FROM v$session WHERE blocking_session IS NOT NULL;第一句看账号状态如果发现某个应用账号是OPEN状态且很久没用按最小权限原则锁掉第二句看统一审计记录里有没有异常访问第三句用v$session定位阻塞源拿到sid后再查v$sql对应的SQL文本。一体机的价值之一是性能强但那不意味着可以不做例行巡检机器越贵越要盯紧。5. 避坑一体机环境里最常见的5个翻车现场这里写我反复踩过的坑全按现象、原因、解决的顺序来方便直接对照。5.1 ASM扫不到盘磁盘组一直处于DISMOUNTED现象重启数据库节点后asmcmd lsdg看到磁盘组从MOUNTED变成DISMOUNTEDlsdsk --discovery结果为空应用连接全部失败。原因一体机存储节点或操作系统启动顺序变了ASM磁盘的udev绑定没有生效设备文件权属不对也可能是RAC环境下OCR和投票盘的磁盘组路径变化导致CRS资源起不来。解决先检查/dev/oracleasm/disks下有没有盘再用oracleasm listdisks确认ASM库认识哪些盘。如果是udev规则失效重新加载规则并让oracle用户对这些设备有读写权限。RAC环境里如果要用CRS清除不用的磁盘组先确认该磁盘组没有数据文件再通过crsctl或asmcmd卸载不要直接drop否则会连带OCR信息一起坏掉。第一次遇到时别急着动磁盘组先在操作系统层确认磁盘存在。5.2 补丁打到一半监听服务无法启动现象打完数据库季度补丁lsnrctl start报TNS-12541或TNS-01189应用连接直接失败sqlplus登录也变得缓慢。原因补丁升级过程中监听配置文件listener.ora被更新端口或监听位置变了也可能是监听日志文件过大导致启动超时或者监听端口被其他进程占用。解决先看$ORACLE_HOME/network/log/listener.log的报错常见做法是把listener.ora里的端口改回原值再手动重启监听。如果日志文件超过几百MB先改名备份再重启监听让监听生成新日志。修改默认监听端口后要同步更新tnsnames.ora和防火墙策略不要只改一边。补丁窗口一定要安排在业务低谷打完补丁先验证监听注册再放流量。5.3 SQL在普通服务器上快迁到Exadata反而慢了现象同样的SQL在旧机器上1秒迁到Exadata后执行计划变了跑了十几秒业务方开始质疑一体机的性能。原因Exadata上统计信息没收集CBO选错执行计划或者cell_offload没有生效SQL走了索引全扫描存储卸载没派上用场。解决迁移后第一件事是exec dbms_stats.gather_table_stats把统计信息收一遍再看执行计划是否合理。不要把旧库的执行计划手工hint带过来让CBO基于新统计信息重新决定。对比迁移前后AWR重点看Physical reads和cell等待事件如果cell等待时间异常大再查是不是SQL or pushdown被禁用。5.4 12c删除不干净新环境装到一半报ORA-12547现象以前的Oracle 12c卸载没删干净新一体机上安装19c时报ORA-12547TNS丢失连接安装进程反复回滚。原因残留的/etc/oratab、$ORACLE_HOME软链接、旧的监听进程和内核参数配置跟19c不兼容固件驱动也不匹配。解决装新库前把旧环境彻底清一遍包括删除/opt/ORCLfmap残留、清理/etc/oratab里失效条目、杀掉残留的tnslsnr和ora_pmon进程。一体机上装19c前先确认存储节点固件版本在Oracle支持矩阵里避免固件和驱动不匹配。不要用rm -rf硬删$ORACLE_BASE清理完还要检查/etc/oraInst.loc和/opt/ORCLusm这两处残留最容易导致新安装读错路径。5.5 磁盘坏块导致dbf文件损坏RMAN恢复时发现备份过期现象ASM磁盘组出现坏块某个dbf文件报ORA-01578执行RMAN恢复时提示备份文件已过期或备份片段缺失。原因备份策略里没有做增量备份的定期合并归档保留时间太短坏块发生后找不到可用的备份链RMAN恢复验证也没做备份坏了不知道。解决确认RMAN是否配置了控制文件自动备份并做一次全量加增量备份。出现坏块时先判断能不能通过块级恢复解决-- 先尝试恢复损坏的数据块 RECOVER DATAFILE dbfile; -- 不行就做时间点恢复前提是归档完整 RUN { SET UNTIL TIME TO_DATE(2021-03-01 02:00:00,YYYY-MM-DD HH24:MI:SS); RESTORE DATABASE; RECOVER DATABASE; } ALTER DATABASE OPEN RESETLOGS;RECOVER DATAFILE只恢复单个损坏文件前提是备份和归档都在SET UNTIL TIME做时间点恢复适合坏块影响范围大的情况。关键教训是一体机再稳也要每天验证备份的可恢复性不要等坏了才后悔。6. 验收新机到手先跑这三件事再决定上不上生产机器到货部署完不要急着把业务切过去。我习惯先做三件事。第一件是验证智能存储卸载是否真的生效找一张千万行以上的大表做全表扫描对比cell_offload_eligible_bytes和returned_bytes差距在10倍以上说明cell在工作差距很小就回头查统计信息和执行计划。第二件是验证高可用能力如果是RAC直接kill -9一个实例的PMON进程看会话能不能在几秒内迁移到另一个节点如果是单实例加DG做一次switchover再切回来记录切换时间和数据零丢失。第三件是打一组AWR基线把业务高峰时段的快照保存下来后面性能下降才有对比依据。这三件事做完再跟团队做一次复盘巡检清单谁来跑、补丁窗口怎么排、备份恢复演练多久一次。一体机的上限很高但下限也没有传说中那么低真正决定稳定性的还是接手的人是否熟悉这些命令和参数。这些年我带过的项目里翻车的从来不是机器而是把一体机当普通服务器用的人。希望帮到你。本文还有配套的精品资源点击获取