1. 磁盘排序在Oracle数据库中的核心作用

作为一名Oracle DBA，我经常遇到这样的场景：开发团队抱怨某个报表查询突然变慢，而当我检查AWR报告时，发现"disk sorts"指标明显上升。磁盘排序（Disk Sorts）是Oracle数据库中一个关键的性能指标，它直接反映了SQL操作对临时表空间的使用情况。

当Oracle需要在内存中执行排序操作（如ORDER BY、GROUP BY、DISTINCT等）但内存不足时，就会将中间结果写入临时表空间进行磁盘排序。与内存排序相比，磁盘排序的I/O开销要高几个数量级。根据我的实测数据，同样的排序操作，磁盘排序的耗时可能是内存排序的10-100倍。

在Oracle 12c环境中，磁盘排序主要发生在以下场景：

• 大型报表查询需要对数百万行数据排序
• 复杂分析函数（如窗口函数）处理大数据集
• 临时表空间配置不合理导致频繁换出
• 内存参数（如SORT_AREA_SIZE）设置过小

提示：在Oracle 12c多租户环境中，磁盘排序问题可能集中在特定PDB上，需要结合CON_ID字段进行针对性分析

2. 磁盘排序巡检SQL脚本解析

2.1 基础巡检脚本

以下是经过实战验证的基础磁盘排序检查脚本，我通常在每月巡检和性能问题排查时使用：

SELECT TO_CHAR(BEGIN_TIME, 'YYYY-MM-DD HH24:MI') AS SAMPLE_TIME, INSTANCE_NUMBER, ROUND(DISK_SORTS/MEMORY_SORTS*100,2) AS DISK_SORT_RATIO, DISK_SORTS, MEMORY_SORTS, SORT_ROWS, SORT_LIMIT FROM GV$SYSSTAT WHERE NAME IN ('sorts (disk)', 'sorts (memory)') AND BEGIN_TIME >= SYSDATE - 7 ORDER BY BEGIN_TIME DESC;

这个脚本的关键价值在于：

• 显示磁盘排序与内存排序的比例（DISK_SORT_RATIO）
• 提供7天内的历史趋势数据
• 适用于RAC环境（通过GV$视图）

2.2 进阶诊断脚本

当发现磁盘排序比例过高时，我会使用这个进阶脚本定位具体问题会话：

SELECT s.sid, s.serial#, s.username, s.program, s.module, s.sql_id, t.blocks*ts.block_size/1024/1024 AS temp_mb, t.tablespace, st.value AS disk_sorts FROM v$session s, v$sesstat st, v$statname sn, v$tempseg_usage t WHERE s.sid = st.sid AND st.statistic# = sn.statistic# AND sn.name = 'sorts (disk)' AND st.value > 0 AND s.saddr = t.session_addr ORDER BY temp_mb DESC;

这个脚本的亮点在于：

• 关联会话信息与临时段使用情况
• 显示每个会话占用的临时空间大小
• 可识别高负载SQL（通过sql_id）

3. 磁盘排序的优化实战策略

3.1 内存参数调优

在Oracle 12c中，影响排序性能的关键参数包括：

调整方法示例：

-- 会话级调整 ALTER SESSION SET SORT_AREA_SIZE=4194304; -- 系统级调整 ALTER SYSTEM SET PGA_AGGREGATE_TARGET=8G SCOPE=BOTH;

注意：在CDB环境中调整PGA参数时，需要连接到root容器执行

3.2 SQL优化技巧

通过多年实践，我总结了这些减少磁盘排序的SQL写法：

1. 减少排序数据量：

-- 反例：全表排序 SELECT * FROM large_table ORDER BY create_date; -- 正例：先过滤再排序 SELECT * FROM large_table WHERE create_date > SYSDATE - 30 ORDER BY create_date;

2. 利用索引避免排序：

-- 创建支持排序的索引 CREATE INDEX idx_emp_dept_hire ON employees(department_id, hire_date); -- 索引排序查询 SELECT employee_id, last_name FROM employees WHERE department_id = 10 ORDER BY hire_date; -- 使用索引而非排序

3. 分页查询优化：

-- 低效写法 SELECT * FROM ( SELECT a.*, ROWNUM rn FROM (SELECT * FROM large_table ORDER BY create_date) a ) WHERE rn BETWEEN 10001 AND 10100; -- 高效写法（12c新特性） SELECT * FROM large_table ORDER BY create_date OFFSET 10000 ROWS FETCH NEXT 100 ROWS ONLY;

4. 临时表空间的最佳实践

4.1 配置建议

对于频繁出现磁盘排序的系统，我的临时表空间配置方案：

1. 多临时表空间：

-- 创建专用临时表空间 CREATE TEMPORARY TABLESPACE temp_high_sort TEMPFILE '/u01/oradata/temp_high_sort01.dbf' SIZE 10G AUTOEXTEND ON NEXT 1G MAXSIZE 32G EXTENT MANAGEMENT LOCAL UNIFORM SIZE 16M;

2. 临时表空间组（12c新特性）：

-- 创建临时表空间组 ALTER TABLESPACE temp_high_sort TABLESPACE GROUP high_sort_group; -- 分配用户使用临时表空间组 ALTER USER report_user TEMPORARY TABLESPACE GROUP high_sort_group;

4.2 监控与维护

我常用的临时表空间监控脚本：

SELECT ts.name AS tablespace, df.name AS tempfile, df.bytes/1024/1024 AS size_mb, (df.bytes - NVL(fs.bytes,0))/1024/1024 AS used_mb, ROUND((df.bytes - NVL(fs.bytes,0))/df.bytes*100) AS pct_used FROM v$tempfile df, v$tablespace ts, (SELECT file_id, SUM(bytes) bytes FROM v$temp_space_header GROUP BY file_id) fs WHERE df.ts# = ts.ts# AND df.file# = fs.file_id(+) ORDER BY pct_used DESC;

维护建议：

• 每月检查临时文件碎片情况
• 对使用率持续超过80%的临时表空间进行扩容
• 考虑为季节性业务创建单独的临时表空间

5. 真实案例：电商大促期间的排序优化

去年双十一期间，我们遇到一个典型问题：订单查询页面在高峰时段响应时间从2秒飙升到20秒。通过AWR报告发现磁盘排序比例达到35%。以下是解决过程：

1. 问题定位：

-- 发现高磁盘排序SQL SELECT sql_id, disk_sorts, memory_sorts FROM dba_hist_sqlstat WHERE disk_sorts > 1000 ORDER BY disk_sorts DESC;

2. SQL优化：

-- 原SQL（简化版） SELECT customer_id, order_date, amount FROM orders WHERE status = 'PAID' ORDER BY order_date DESC; -- 优化后（添加索引提示） SELECT /*+ INDEX(orders idx_order_status_date) */ customer_id, order_date, amount FROM orders WHERE status = 'PAID' ORDER BY order_date DESC;

3. 临时调整：

-- 临时增大PGA ALTER SYSTEM SET PGA_AGGREGATE_TARGET=16G SCOPE=MEMORY; -- 为报表用户分配专用临时表空间 ALTER USER report_user TEMPORARY TABLESPACE temp_high_sort;

最终效果：

• 磁盘排序比例降至5%以下
• 查询响应时间回归到3秒内
• 临时表空间I/O负载降低60%

这个案例让我深刻体会到：磁盘排序问题需要结合SQL优化、参数调整和存储配置综合治理。在之后的618大促中，我们提前部署了这些优化措施，平稳度过了流量高峰。