背景：某客户Oracle 10.2.0.4数据库运行在RHEL5.2系统上，配置4颗4核Intel Xeon E7430 CPU和32GB内存。系统出现CPU占用率持续接近100%，最终触发Linux保护性自动重启，业务操作完全无响应。
诊断：通过top命令确认内存管理为瓶颈，Linux默认内存分页机制（4KB页面）在处理大SGA（如32GB）时，易导致内存碎片化，增加内存访问延迟，进而加剧CPU负载。
优化措施：启用Linux大内存页技术（HugePages），将内存页面大小调整为2MB（或更大），减少页面表项数量，提升内存访问效率；同时关闭Transparent Huge Pages（THP，避免动态内存合并的开销）。
效果：优化后，SGA内存访问延迟降低约40%，CPU占用率稳定在60%以下，系统未再出现因内存管理问题导致的崩溃。
背景：某业务系统执行SELECT查询时，响应时间长达1.2秒，影响用户体验。通过AWR报告分析，发现SQL执行计划存在严重问题：CIF_XXX表进行了全表扫描，尽管ch_xxx_name列有索引，但因使用了双边模糊匹配（%xxx%）导致索引失效；同时，iss_country和xxx_no列的单列索引引发了索引哈希连接，增加了额外的I/O开销。
优化措施：
ch_xxx_name列走全索引扫描（该列可选择率高，回表消耗小）；iss_country和xxx_no列创建组合索引，避免两次索引快速全扫描和哈希连接。背景：某Oracle数据库服务器CPU占用率突然飙升至100%，导致业务中断。通过top命令发现Oracle进程（如ora_pmon、ora_dbw0）占用大量CPU，但无法快速定位具体是哪条SQL语句导致的问题。
优化措施：
top命令找到高CPU的Oracle PID（如2166）；execute sys.dbms_system.set_ev(152,213,10046,1,'')开启跟踪；execute sys.dbms_system.set_ev(152,213,10046,0,'')关闭跟踪；udump目录获取.trc文件（如ora_2166.trc），用tkprof工具转换为可读文本（如ora_2166.sql）。tkprof输出，发现某条UPDATE语句占用了80%的CPU时间，其执行计划选择了全表扫描而非索引扫描。UPDATE语句的目标表添加合适索引后，CPU占用率降至30%以下，业务恢复正常。背景：某电商系统Oracle数据库运行在Linux服务器上，随着业务增长，出现磁盘I/O延迟高（await时间达50ms）、查询性能下降的问题。
诊断：通过iostat命令分析，发现磁盘吞吐量达到上限（SATA SSD的IOPS约为500），且操作系统内核参数vm.swappiness设置为60（默认值），导致频繁使用交换空间（swap），加剧了I/O负载。
优化措施：
/etc/sysctl.conf文件，调整以下参数： vm.swappiness=10（减少交换空间使用，优先使用物理内存）；vm.dirty_background_ratio=10、vm.dirty_ratio=20（优化脏页刷新机制，减少磁盘写压力）；net.core.rmem_default=262144、net.core.rmem_max=262144（增大套接字接收缓冲区，提升网络传输效率）。await时间降至5ms以下，IOPS提升至2000以上，数据库查询性能提升约60%，系统稳定性显著增强。背景：某企业Oracle数据库运行在Linux平台上，随着数据量增长（从100GB增至1TB），出现内存不足、SQL执行慢的问题。通过AWR报告分析，发现SGA命中率仅为85%（低于90%的阈值），且存在大量硬解析（每秒约50次）。
诊断：
sga_target设置为2GB，无法满足大内存需求；sga_target增大至8GB（根据服务器内存大小调整），pga_aggregate_target设置为2GB（满足排序、哈希操作需求）；:name代替硬编码的值），减少SQL解析次数；DBMS_STATS.GATHER_SCHEMA_STATS收集统计信息，确保优化器生成最优执行计划；每月执行ALTER TABLE ... SHRINK SPACE整理表碎片。
