简介这是一份关于Oracle一体机Oracle Database Appliance的专题介绍PPT发布于2021年3月适合数据库管理员、系统架构师及企业IT决策者快速了解其产品定位与核心价值。内容围绕ODA的设计思想、架构演进、技术特性、性能优势与典型应用场景展开清晰梳理了从X3-2到X8-2各代产品的规格变化并给出与传统x86方案在部署时间、维护成本及事务处理能力等方面的实测对比数据可作为数据库一体化选型评估和内部培训的基础参考。资源包大小为6.66MB仅含1个pptx演示文稿内容组织紧凑便于直接阅读或二次编辑。目前已有472人学习浏览适合需要快速建立Oracle一体机整体认知、关注数据库一体化交付方案的技术人员下载研读。1. 一体机不是一台机器先用一句话说清它是什么很多人第一次听到“Oracle一体机”这个名字下意识以为是一台配置特别高的服务器。实际上它是一整套软硬件深度集成的数据库平台行业里更习惯叫它 Exadata。2021 年初的那次更新也就是标题里那个 202103 对应的版本节点核心是把数据库计算节点、智能存储节点和 InfiniBand 内部网络打包成一个交付单元你拿到的不是一台机器而是一整个机柜。这套东西解决的核心问题很直接当数据库的 SQL 扫描量从 GB 级涨到 TB 级时传统架构里存储和数据库之间的流量会成为瓶颈而 Exadata 把过滤、压缩、索引这些活下推到存储节点去做让数据在到达数据库之前就已经被“瘦身”过一遍。适合谁用两类人最值得看——被大查询和 IO 延迟折磨得想换架构的 DBA以及正在做数据库选型、需要在普通服务器方案和一体机方案之间做成本对比的技术负责人。这篇文章不聊厂商 PPT 里的宣传指标只讲它到底怎么工作、部署时怎么做、哪些参数必须调、以及那些只有上了生产环境才会发现的坑。2. 为什么 Exadata 跑大查询快存储端干了数据库的活2.1 智能扫描不是缓存是把 WHERE 下推给了磁盘传统数据库架构里一条SELECT COUNT(*) FROM orders WHERE statusP的语句数据库进程会把整张表的数据块从存储读到 Buffer Cache再在数据库层面逐行过滤。表越大磁盘到数据库之间的流量越大数据库 CPU 越忙。Exadata 的做法完全不同它把过滤条件直接下发到存储节点存储节点上的 CELLSRV 进程在读取数据块时顺手就把不满足条件的数据丢弃只把命中的行返回给数据库。这个机制叫 Smart Scan智能扫描但它不是缓存——缓存是热数据的重复命中Smart Scan 是让每一份被读出来的数据都变“轻”。你在 SQL 的执行计划里看到TABLE ACCESS STORAGE FULL而不是普通的TABLE ACCESS FULL说明扫描已经被下推到存储层了。判断智能扫描是否真正生效不能只看执行计划还要看 Exadata 的统计视图或者cellcli里的响应时间分解这一步后面避坑章节会细说。2.2 存储索引和 HCC 压缩两个容易被低估的加速器除了 Smart Scan一体机上还有两个特性在日常查询里贡献巨大。第一个是存储索引它不占额外空间只是在存储节点内存里维护每个存储区域1MB 粒度的最小值和最大值。当查询条件里有等值或范围过滤时存储节点能直接跳过那些值不在范围内的区域。比如按订单日期查最近一天的数据如果日期列有存储索引扫描量可能直接从几 TB 降到几十 GB而且完全不用你建任何数据库索引。第二个是 HCC混合列压缩。它和普通压缩的最大区别是压缩比高得离谱尤其适合数仓里只读的归档表。一张 1TB 的事实表用 HCC Query High 压缩后可能只剩 150GB 左右而且因为数据块变小全表扫描需要读的 IO 也变少了。但 HCC 有个代价数据块在插入后不支持直接 UPDATE 和 DELETE任何修改都会触发解压重写性能会断崖式下跌。所以生产环境里HCC 只用在分区表的历史分区或者只读表上OLTP 表千万不能碰。2.3 一体机的性能公式CPU 内存 IO 路径一起变快Exadata 性能好不是某一个部件强而是整条数据路径没有短板。计算节点跑的是 Oracle 数据库软件和普通服务器上的数据库没有任何区别但存储节点上的 Exadata 软件把扫描、解压、加密、过滤全都卸载到了存储端。数据库节点的 CPU 不再消耗在大表扫描上而是专注做复杂连接和排序存储节点的 CPU 专门处理数据筛选。配合 InfiniBand 内部网络把传统的 SCSI 存储协议换成了类 RDMA 的消息传递单次 IO 的延迟更低并发吞吐更高。所以你要评估一体机适不适合自己的业务核心问题不是“它快不快”而是“我的负载是不是 IO 敏感型”。如果跑的是银行核心交易每次查询都是走索引取几十行那 Exadata 的优势发挥不出来如果跑的是数仓报表、日志分析、批量加工SQL 动不动就全表扫描几亿行那才是它真正的主场。3. 从拆箱到跑业务部署一体机的完整路径与参数设置3.1 规划配置先算存储再算计算最后算网络拿到一台 Exadata X 系列X7、X8M、X9M 这些代际之前先做容量规划。常见做法是先根据数据量定存储节点数量再根据并发和 CPU 需求定数据库节点数量最后看一眼 InfiniBand 网络的端口规划。数据库节点会跑操作系统和 Oracle Grid Infrastructure存储节点跑 Exadata 存储软件两者之间通过内部 IB 网络互通外部应用通过客户端网络一般是万兆以太网访问数据库服务。这里有个新手容易困惑的点存储节点上的磁盘不是直接格式化成文件系统给数据库用的。它要先划分成CELLDISK然后在CELLDISK上建GRIDDISK多块GRIDDISK组成 ASM 磁盘组数据库文件最终落在 ASM 里。所以你规划磁盘时要想清楚哪些盘给 DATA 磁盘组哪些给 RECO 磁盘组哪些留给闪存。我一般会把容量最大的盘放 DATARECO 至少留 20% 到 30% 容量闪存盘优先分给FLASHCACHE剩余空间做FLASHLOG。3.2 初始化存储节点用 cellcli 完成底层配置部署的第一步是给存储节点装 Exadata 存储软件出厂预装一般不用手动装然后逐台执行cellcli命令完成配置。以下是在存储节点上执行的操作代表“从裸机状态到可以使用的存储池”的完整步骤。# 查看当前存储节点的 cell 名称和状态 cellcli -e LIST CELL ATTRIBUTES name, status # 启动 cell 服务如果状态不是 online 则需要手工拉起 cellcli -e ALTER CELL STARTUP SERVICES # 列出所有物理磁盘确认磁盘类型和大小 cellcli -e LIST PHYSICALDISK # 将所有 3TB 的磁盘创建为 cell disk cellcli -e CREATE CELLDISK ALL # 查看创建的 cell disk 列表确认大小正确 cellcli -e LIST CELLDISK # 在 cell disk 上创建 grid diskassign 给所在计算节点 cellcli -e CREATE GRIDDISK ALL # 确认 grid disk 状态active 表示可以正常使用 cellcli -e LIST GRIDDISK每个命令的逻辑LIST CELL ATTRIBUTES是基础体检确认存储节点自身健康ALTER CELL STARTUP SERVICES拉起存储服务这一步如果失败后续所有命令都跑不了CREATE CELLDISK ALL把物理磁盘转成 Exadata 可管理的存储单元相当于给磁盘做了格式化CREATE GRIDDISK ALL是在 cell disk 之上创建 ASM 能识别的卷。参数层面CREATE GRIDDISK默认会按配置把所有空间分配给 grid disk但如果你闪存盘要留空间给FLASHCACHE需要先用以下命令预留。# 给闪存盘配置 flashcache 和 flashlog 大小 cellcli -e ALTER CELL FLASHCACHE MODEWRITEBACK # 查看 flashcache 状态确认 writeback 模式生效 cellcli -e LIST FLASHCACHE DETAIL闪存盘在这里扮演的角色是临时加速层FLASHCACHE用 writeback 模式缓存频繁读取的数据块FLASHLOG缓存重做日志的写入等磁盘空闲再刷下去。生产环境我推荐把闪存盘的 80% 分给FLASHCACHE20% 分给FLASHLOG因为重做日志写入往往是 OLTP 型业务的性能瓶颈这部分空间不能省。3.3 在计算节点上创建 ASM 磁盘组并安装数据库软件存储节点配好后回到计算节点操作。计算节点上已经装好了 Oracle Grid Infrastructure 和数据库软件你需要做的是把 3.2 里创建的 grid disk 注册到 ASM 实例然后建磁盘组。以下操作在计算节点上执行使用asmcmd和sqlplus两个工具。# 以 grid 用户登录启动 ASM 实例 su - grid sqlplus / as sysasm -- 查看 ASM 实例当前识别到的候选磁盘 SELECT path, name, header_status FROM v$asm_disk; -- 创建 DATA 磁盘组normal redundancy使用 DATA 前缀的 grid disk CREATE DISKGROUP DATA NORMAL REDUNDANCY DISK /dev/oracleasm/disks/DATA* ATTRIBUTE compatible.asm19.0.0.0.0, compatible.rdbms19.0.0.0.0; -- 创建 RECO 磁盘组normal redundancy用于快速恢复区和归档 CREATE DISKGROUP RECO NORMAL REDUNDANCY DISK /dev/oracleasm/disks/RECO* ATTRIBUTE compatible.asm19.0.0.0.0, compatible.rdbms19.0.0.0.0; -- 检查磁盘组状态和数据分布 SELECT name, state, type, total_mb, free_mb FROM v$asm_diskgroup;上述 SQL 的逻辑v$asm_disk用来确认 grid disk 是否被 ASM 正确识别header_status必须是CANDIDATE或FORMER才能被建组。CREATE DISKGROUP里NORMAL REDUNDANCY意味着每份数据有两份拷贝能容忍一个盘故障这是在性能和容错之间的平衡点compatible参数必须和数据库版本匹配如果用 19c就设成 19.0.0.0.0默认值在新版本里已经够用但手动指定能避免后续升级时出现兼容性告警。磁盘组建好之后数据库软件和实例的创建就和你在一台普通 Linux 服务器上装单实例数据库没有区别了用dbcaDatabase Configuration Assistant静默模式或者图形界面一步步走完即可。区别只在于所有的数据文件、控制文件、在线日志都要指定到DATA和RECO这两个磁盘组千万不要再写本地路径。如果项目里原本就有一套数据库要迁移过来这一步就是选好迁移工具Data Guard、EXPDP 或云迁移把数据“搬”进 ASM。3.4 数据库参数和初始化几个必须动手改的默认值数据库创建完成后有一套参数在一体机环境下建议立即调整。下面这段 SQL 是在 19c 单实例数据库上执行的参数调整脚本每一条都对应一个具体的资源策略。-- 以 sysdba 身份执行 ALTER SYSTEM SET db_cache_adviceON; ALTER SYSTEM SET result_cache_modeMANUAL; ALTER SYSTEM SET parallel_degree_policyAUTO; ALTER SYSTEM SET parallel_servers_target64; ALTER SYSTEM SET db_files2000 SCOPEBOTH; ALTER SYSTEM SET open_cursors2000 SCOPEBOTH; ALTER SYSTEM SET processes2000 SCOPESPFILE; ALTER SYSTEM SET sessions2200 SCOPESPFILE; ALTER SYSTEM SET sga_max_size32G SCOPESPFILE; ALTER SYSTEM SET sga_target32G; ALTER SYSTEM SET pga_aggregate_target16G; ALTER SYSTEM SET optimizer_adaptive_cursor_sharingFALSE; ALTER SYSTEM SET optimizer_adaptive_plansTRUE; ALTER SYSTEM SET _flashback_verbose_redoFALSE;这些参数里parallel_degree_policyAUTO和parallel_servers_target64和一体机最相关——Exadata 的智能扫描天然依赖并行查询并行度设太低会导致存储端没有足够的扫描进程设太高又会让计算节点 CPU 爆掉processes和sessions是基础的连接容量生产环境默认 150 绝对不够sga_max_size要和机器物理内存对应一体机数据库节点往往有 384GB 或 768GB 内存SGA 只给 8GB 属于暴殄天物。这些参数改完后需要重启数据库实例才能让SCOPESPFILE的那几个生效。4. 日常运维是一体机最值钱的部分监控命令和备份恢复路径4.1 存储节点健康检查celcli 里最常用的三组命令一体机的存储节点是一个跑 Linux 的独立计算单元通过celcli命令行管理。日常巡检时我一般会先在每个 cell 上执行三件事看存储服务状态、看磁盘闪存健康、看最近有没有硬件告警。下面这套命令可以固化成一个运维脚本每周跑一次。# 1. 检查所有存储节点的服务状态 cellcli -e LIST CELL SERVICES # 2. 检查物理磁盘状态Normal 表示健康Predictive Failure 表示预警 cellcli -e LIST PHYSICALDISK ATTRIBUTES name, status, errcount # 3. 检查闪存设备是否有磨损或故障 cellcli -e LIST FLASHDEVICE ATTRIBUTES name, status, errcount # 4. 查看 cell 是否有硬件告警事件 cellcli -e LIST ALERT HISTORY # 5. 查看闪存缓存命中率判断 flashcache 是否正常工作 cellcli -e LIST METRICDEF FLASH_CACHE_HIT_RATIO这套命令的价值在于它能让你在业务出现性能问题之前就发现隐患。ERROOUNT字段如果持续增长说明磁盘正在频繁重试即便 SMART 状态还没报故障也离坏不远了LIST ALERT HISTORY会显示过去一段时间内的硬件事件比如某个 InfiniBand 端口的链路抖动这种问题在传统架构里要等业务感知到才能发现在一体机上存储节点会直接记日志。4.2 备份恢复RMAN 和 Data Guard 谁负责什么一体机最大的风险是硬件故障时数据不可用所以在部署规划阶段就要把备份策略想清楚。RMAN 负责备份到外部存储或磁盘Data Guard 负责实时同步一份数据到备库两者不是替代关系而是互补关系。RMAN 解决的是“数据被人为删了或逻辑损坏”的问题Data Guard 解决的是“物理存储整个挂掉”的问题。备份配置的核心工作是设置快速恢复区并启动自动备份策略。以下 SQL 在数据库里配置 RMAN 备份策略备份目标指向 RECO 磁盘组-- 设置快速恢复区位置和大小 ALTER SYSTEM SET db_recovery_file_destRECO; ALTER SYSTEM SET db_recovery_file_dest_size1000G SCOPEBOTH; -- 控制文件自动备份开启防止丢控制文件后无法恢复 ALTER SYSTEM SET controlfile_autobackupON; -- 开启归档模式如果还没开启 SHUTDOWN IMMEDIATE; STARTUP MOUNT; ALTER DATABASE ARCHIVELOG; ALTER DATABASE OPEN; -- 使用 RMAN 配置自动备份策略 RMAN TARGET /; CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS; CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO DISK; CONFIGURE CONTROLFILE AUTOBACKUP ON; CONFIGURE BACKUP OPTIMIZATION ON; BACKUP DATABASE PLUS ARCHIVELOG TAG weekly_full;这里的RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS意味着数据库可以恢复到 7 天内的任意时间点ARCHIVELOG DELETION POLICY TO BACKED UP 1 TIMES TO DISK表示归档日志只要备份过一次就可以从磁盘删除避免 RECO 空间被归档撑爆。每周一次全备加每天一次归档备份是大多数项目的基础配置如果数据量特别大可以在两者之间加增量备份。4.3 高可用架构从单机到 RAC 的升级路径很多项目最初部署一体机时只买了两个数据库节点但只跑了一个单实例。这种情况下数据库节点挂了存储节点还在但数据库服务中断业务不可用。正确的做法是利用一体机自带的两个数据库节点做 Oracle RAC两个节点同时对外提供服务任何一个节点宕机另一个节点接管所有连接和会话实现秒级切换。RAC 的搭建在 Exadata 上比普通服务器简单得多——因为 Grid Infrastructure 的安装包已经预置ASM 磁盘组也已经建好只需要用asmca添加集群件、配置节点间互信、再用dbca创建 RAC 数据库即可。以下几个命令和参数是建 RAC 时必须注意的# 在两个节点上分别验证节点间互信 su - grid ssh equinox1 hostname ssh equinox2 hostname # 验证 SCAN 地址的 DNS 解析 nslookup scan-cluster.example.com # 给集群件配置扫描地址 /sbin/ipaddr add 192.168.1.100/24 dev bond0 # 查看集群服务状态确保 css 和 crs 进程在线 crsctl status resource -tRAC 部署里最常翻车的点是SCAN地址的解析每台客户端机器都必须能把 SCAN 名字解析到三个 IP如果配置了三个 SCAN IP且不能和任何节点 IP 冲突。数据库节点上的/etc/hosts需要同时包含两个节点名和三个 SCAN 名缺一个都会导致集群件在启动阶段报CRS-0184或ORA-00603。如果 DNS 环境不熟悉最简单的做法是把 SCAN 的记录也写进两台节点的/etc/hosts虽然不够“标准”但稳定可靠。5. 常见问题与避坑部署和运维中反复出现的 5 个坑5.1 Smart Scan 没有生效SQL 还是走全表扫描并拖垮 IO现象SQL 执行计划里明明显示TABLE ACCESS STORAGE FULL但存储节点的读取量没有下降数据库节点 CPU 仍被打满。原因Exadata 的智能扫描只在满足特定条件下才启用——例如查询里不能用DECODE这类隐式转换函数包裹过滤列也不能有TRUNC(date_col)这类对索引列做函数的过滤更常见的原因是数据库参数cell_offload_processing被人为设成了 FALSE。解决先确认参数再逐条排查 SQL 写法。-- 检查是否启用了 cell offload SHOW PARAMETER cell_offload_processing; -- 如果 FALSE立即改回来 ALTER SYSTEM SET cell_offload_processingTRUE SCOPEBOTH; -- 查看 SQL 执行计划里是否出现 STORAGE 关键字 EXPLAIN PLAN FOR SELECT /* OPT_PARAM(cell_offload_processing true) */ COUNT(*) FROM sales WHERE channel_idR;另一个隐蔽原因是索引问题即便 Smart Scan 理论上不需要数据库索引但当查询走了普通索引访问路径时Offload 会被禁用。解决方法是让 CBO 放弃索引路径改用全表扫描并配合存储索引。这种“看起来是倒车实际是超车”的优化在一体机上很多见。碰到 SQL 慢第一反应不是加索引而是确认它是否走了STORAGE FULL。5.2 HCC 压缩表上的 DML 让性能瞬间崩塌现象一张 HCC 压缩的表平时SELECT很快但偶尔一次UPDATE一个字段数据库就像是卡死了会话长时间阻塞业务大面积超时。原因HCC 的一个块里压缩了成百上千行任意一行修改Oracle 都要把整个块解压、修改、重新压缩期间还会触发行迁移和块重组锁竞争被无限放大。这也是很多从传统数据库迁移到一体机的团队最容易翻车的地方。解决对 HCC 表做约束——只允许在维护窗口做 DML平时只读。做法是把 HCC 用于分区表的历史分区而不用于主表。比如订单表按月份分区最近三个月用普通 OLTP 存储更早的分区定期转换成 HCC-- 把一个分区从普通堆表压缩转为 HCC Query High 压缩 ALTER TABLE orders MOVE PARTITION p2020q4 TABLESPACE DATA COMPRESS FOR QUERY HIGH;如果业务实在需要更新 HCC 表至少要在更新前先把受影响的分区解压ALTER TABLE ... MOVE PARTITION ... NOCOMPRESS更新完成后再转回 HCC。把这个流程写进变更脚本形成标准操作别让开发在正常业务里直接UPDATEHCC 表。5.3 磁盘组空间告警但 ASM 显示磁盘还有很多空闲现象v$asm_diskgroup显示FREE_MB还有 30%但数据库报ORA-1699: cannot allocate extent无法扩展数据文件。原因ASM 磁盘组是区组Extent Map分配粒度较粗的单位——当磁盘组里每个磁盘的可用空间分布不均时ASM 无法在某个特定磁盘上找到足够大的连续区域分配给扩展的数据文件。解决登录 ASM 实例查磁盘组的可用空间分布然后对表空间做空间重平衡-- 查看每个磁盘的可用空间 SELECT d.name, d.free_mb, d.total_mb, d.state FROM v$asm_disk d WHERE d.group_number1 ORDER BY d.name; -- 如果某块盘 free_mb 明显偏少触发一次重新平衡 ALTER DISKGROUP DATA REBALANCE POWER 5;这个坑在 Exadata 上尤其容易踩因为 grid disk 是按固定大小创建的一块物理盘故障替换后新盘的容量可能和旧盘不同时间一长各个盘的占用率会出现明显倾斜。预防手段是在创建磁盘组时就使用HIGH或NORMAL冗余并定期检查各盘占用偏差超过 15% 就做一次 rebalance。别等业务报错再去救火那会儿往往已经晚了。5.4 重启数据库节点后存储节点上的连接全部卡住现象计算节点一次计划内重启重启后应用连库一切正常但过了一段时间后存储节点的cellcli命令开始超时比如LIST GRIDDISK要十几秒才返回。原因一体机的计算节点和存储节点之间靠 InfiniBand 通信重启计算节点时 IB 链路会断开再重连部分存储节点上的服务进程在处理断连时没有正确释放资源导致连接堆积、后续请求排长队。解决不要在业务高峰期重启数据库节点。如果一定要重启按顺序操作——先crsctl stop crs停掉数据库节点上的集群件等两个节点的clusterware都停稳后再对存储节点做健康检查重启后不要立刻做大量 IO 操作先观察cellcli -e LIST CELL SERVICES的连接数是否恢复正常。另外给所有服务器的 IB 网卡驱动和固件保持在同一个补丁基线内固件版本不一致也会导致链路重建时出现诡异的握手失败。5.512c 删除不干净与Oracle 等保命令引出的话题软件打补丁的正确姿势现象有人在一体机上装过 12c 的数据库软件卸载不干净注册表、文件系统残留了一堆东西之后再装 19c 时总报环境检查不通过。原因Oracle 的安装程序OUI卸载功能只删除软件本身不清理oraInventory里的注册信息也不删/u01/app/oracle下的残留目录。解决手工清理再重装步骤比想象的繁琐但必须每一步都做# 以 root 用户清理软件目录 rm -rf /u01/app/oracle/product/19.0.0/dbhome_1 rm -rf /u01/app/grid/product/19.0.0/gridhome_1 rm -rf /u01/app/grid/crsdata rm -rf /u01/app/oracle/diag rm -rf /u01/app/oraInventory # 清理动态库和内核参数残留 rm -rf /etc/oraInst.loc rm -rf /etc/oracle sed -i /ORACLE_HOME/d /etc/profile sed -i /ORACLE_BASE/d /etc/profile在 Exadata 上补丁和软件安装统一用opatchauto管理它会把数据库节点和存储节点的补丁统一打到同一版本。一体机环境里最忌讳的就是在数据库节点上手动rpm -ivh安装补丁包这会破坏整套软件的一致性。你只需要执行opatchauto apply /path/to/patch它会自动把补丁应用到所有节点。等保场景里要求的安全加固命令也建议在一体机上通过opatchauto写入基线脚本而不是在每个节点上手工操作这样既满足合规要求又不会引入配置漂移。6. 验证一体机投入价值一套可以复制的性能基线测试法买了这么贵的设备如何向老板证明钱花得值光靠业务报表“感觉变快了”是不够的要在上线前做一轮标准性能基线测试留下数据后续容量规划和性能优化才有据可依。我的做法是用swingbench或者 Oracle 自带的sh工具在一体机上跑一套标准的 TPC-C 型负载同时采集数据库节点 CPU、存储节点 IO、Smart Scan 命中率、SQL 响应时间四组数据。具体步骤是先构建一张 10 亿行的大表然后跑几条典型的聚合查询和关联查询分别记录开启和关闭 Smart Scan 时的响应时间差距。以下 SQL 可以快速制造一个测试场景-- 创建一张 5 亿行测试表空间换时间 CREATE TABLE big_test AS SELECT ROWNUM id, MOD(ROWNUM,1000) channel_id, SYSDATE - ROWNUM/1000 create_date, DBMS_RANDOM.STRING(A,100) payload FROM DUAL CONNECT BY LEVEL 500000000; -- 收集统计信息避免 CBO 猜错基数 EXEC DBMS_STATS.GATHER_TABLE_STATS(NULL,BIG_TEST); -- 测试聚合扫描预期走 STORAGE FULL响应时间应在秒级 SELECT channel_id, COUNT(*) FROM big_test WHERE create_date BETWEEN SYSDATE-30 AND SYSDATE GROUP BY channel_id;测试时把cell_offload_processing临时设为FALSE再跑一遍同样的 SQL对比两次的时间差。如果时间差在 5 倍以上说明智能扫描的效果明显如果在 1.2 倍以内说明你的查询根本没有触发大规模扫描一体机的价值就不在查询加速上而在于它的 IO 延迟和并发处理能力需要换用小事务型测试负载重新验证。我的最后一条习惯是测试完之后立刻把参数改回TRUE并把测试表的数据清掉别留在生产环境占用磁盘空间。踩过的坑是有人把测试表漏删结果容量规划时多出 500GB 数据磁盘组告警又折腾了两天。所有性能验证的结果、参数截图、执行计划、测试时间都归档到运维文档里作为后续版本升级、业务扩容时的基准参照。多花半小时做这轮验证后面谈预算、谈扩容、谈架构调整每一回都用得上。希望帮到你。本文还有配套的精品资源点击获取