Oracle云性能问题源于配置与资源模型错配：OCI虚拟机需调优I/O参数、禁用directio；Exadata须更新统计信息并避免隐式转换；跨云连接需启用TCP keepalive。
Oracle数据库在OCI上性能没变，但对比x86物理机明显变慢
这不是OCI“性能差”，而是默认配置和底层资源模型不匹配导致的。OCI的VM.Standard.E4.Flex或BM.DenseIO.E4.Flex实例虽标称vCPU数相同，但实际调度策略、NUMA拓扑暴露方式、I/O队列深度与本地Exadata或物理机完全不同。尤其当你的Oracle实例仍沿用物理机时代的db_cache_size、sga_target、filesystemio_options等参数时，极易触发内存页换入换出、异步I/O降级为同步、甚至控制文件争用。
- 先确认是否启用了
filesystemio_options = SETALL：OCI块存储（如BootVolume）不支持directio语义，设成SETALL反而强制绕过OS缓存，放大延迟；应改为ASYNCH并确保disk_asynch_io=TRUE - 检查
v$osstat中PHYSICAL_MEMORY_BYTES与MEMORY_TARGET是否接近——OCI虚拟机内存超配常见，若宿主机内存压力大，Oracle SGA可能被内核swap，表现为DB CPU低但latch: cache buffers chains等待飙升 - 运行
iotop -oPa观察oracle进程的I/O wait占比；若持续高于30%，说明存储吞吐已达瓶颈，需切换到BM.DenseIO裸金属实例或启用Block Volume多路径（mpathconf）
Exadata Database Service上SQL执行计划突变、响应时间翻倍
Exadata云服务默认启用CELL_OFFLOAD_PROCESSING=TRUE，但它的智能扫描（Smart Scan）依赖准确的统计信息和谓词下推能力。一旦你迁移后未刷新统计信息、或SQL里混用绑定变量+字面量（如WHERE status = :b1 AND created_date > '2025-01-01'），Cell节点就无法过滤，全量数据回传给DB节点，网络+CPU双重开销直接拉垮性能。
- 执行
SELECT * FROM v$sql WHERE sql_text LIKE '%your_sql%' AND is_bind_sensitive = 'Y'，确认是否因绑定变量窥探（bind peeking）导致计划固化错误 - 对关键表立即运行
DBMS_STATS.GATHER_TABLE_STATS，且必须指定method_opt => 'FOR ALL COLUMNS SIZE AUTO'，否则Exadata的cell offload优化器无法识别高基数列 - 禁用隐式类型转换：
WHERE id = '123'（id是NUMBER）会阻止Smart Scan；统一改为WHERE id = 123
跨云厂商（AWS/Azure）部署Oracle DB时出现连接超时、TNS-12535
这不是Oracle监听器问题，而是云厂商安全组/NACL默认限制了1521端口的长连接保活行为。AWS的ALB、Azure的Load Balancer会在空闲90秒后主动断开TCP连接，而Oracle客户端（尤其是JDBC thin driver）默认oracle.net.CONNECT_TIMEOUT为0（无限等待），结果就是应用层发一个包，等几秒才收到RST，表现为随机超时。
- 在
sqlnet.ora中强制启用TCP keepalive：SQLNET.EXPIRE_TIME = 10（单位分钟），让Oracle网络栈每10分钟发一次探测包 - 调整JDBC连接串，显式设置
tcpKeepAlive=true&connectTimeout=15000&socketTimeout=60000 - 禁止在云负载均衡器前挂Oracle RAC SCAN VIP——SCAN依赖UDP广播发现节点，跨云LB基本无法透传，改用单实例VIP或DNS轮询
真正卡住人的地方，往往不是参数调优本身，而是你不知道OCI/Exadata的“默认”和你本地环境的“默认”根本不是一回事。比如optimizer_adaptive_features在19c OCI上默认ON，但在23ai Exadata上默认OFF；又比如_exadata_feature_on这个隐藏参数，在非Exadata环境设为TRUE反而引发解析错误。这些细节不会写在文档首页，只藏在ORACLE_HOME/rdbms/admin/catexa.sql的注释里。
