1. Oracle 11G用户表大小统计脚本的价值与应用场景
在Oracle数据库日常运维中，表空间使用情况监控是DBA最基础也最重要的工作之一。我管理过多个TB级Oracle生产环境，深刻体会到定期获取用户表大小统计数据对容量规划、性能调优和资源分配的关键作用。这个脚本正是为解决这个痛点而生——它能自动生成包含存储占用明细的统计报告，省去手动查询的繁琐。
典型使用场景包括：
- 每月存储容量审计时快速定位"空间大户"
- 迁移升级前评估各业务表的数据量级
- 排查性能问题时识别异常增长的表对象
- 向业务部门提供数据存储成本分摊依据
2. 脚本核心功能设计解析
2.1 统计维度设计
脚本输出包含三个关键统计层级：
- 全局汇总：用户下所有表的计数、总大小（MB/GB）
- 表空间级：按表空间分组的存储分布
- 单表明细：按大小降序排列的具体表清单
这种结构既满足宏观趋势把握，又支持微观问题定位。例如当某个表空间使用率超过90%时，可立即查看该表空间内哪些表占用最多。
2.2 关键技术实现
核心查询基于Oracle数据字典视图：
sql复制SELECT
tablespace_name,
table_name,
ROUND(bytes/1024/1024,2) MB
FROM
user_segments
WHERE
segment_type = 'TABLE'
ORDER BY
bytes DESC;
通过user_segments获取物理存储信息比user_tables更准确，因为前者包含实际分配的区(extent)大小。
3. 完整脚本代码与注解
sql复制-- Oracle 11G用户表大小统计脚本
SET PAGESIZE 50000
SET LINESIZE 200
SET FEEDBACK OFF
COLUMN tablespace_name FORMAT A20
COLUMN table_name FORMAT A30
COLUMN MB FORMAT 999,999.99
SPOOL table_size_report.log
PROMPT ========== 用户表存储汇总 ==========
SELECT
COUNT(*) as table_count,
ROUND(SUM(bytes)/1024/1024,2) as total_mb,
ROUND(SUM(bytes)/1024/1024/1024,2) as total_gb
FROM
user_segments
WHERE
segment_type = 'TABLE';
PROMPT
PROMPT ========== 按表空间统计 ==========
SELECT
tablespace_name,
COUNT(*) as table_count,
ROUND(SUM(bytes)/1024/1024,2) total_mb
FROM
user_segments
WHERE
segment_type = 'TABLE'
GROUP BY
tablespace_name
ORDER BY
total_mb DESC;
PROMPT
PROMPT ========== 单表大小TOP 50 ==========
SELECT
tablespace_name,
table_name,
ROUND(bytes/1024/1024,2) MB
FROM
user_segments
WHERE
segment_type = 'TABLE'
ORDER BY
bytes DESC
FETCH FIRST 50 ROWS ONLY;
SPOOL OFF
关键优化点：
- 使用
FETCH FIRST 50 ROWS替代旧版的WHERE ROWNUM <=50，这是Oracle 12c+语法但11g也支持 - 输出格式设置确保报表可读性（数值千分位、列宽控制）
- 结果重定向到日志文件便于后续分析
4. 高级应用与定制技巧
4.1 定期自动执行方案
通过DBMS_SCHEDULER创建定时任务：
sql复制BEGIN
DBMS_SCHEDULER.CREATE_JOB (
job_name => 'GENERATE_TABLE_SIZE_REPORT',
job_type => 'PLSQL_BLOCK',
job_action => 'BEGIN
-- 此处插入脚本内容
END;',
start_date => SYSTIMESTAMP,
repeat_interval => 'FREQ=WEEKLY; BYDAY=MON',
enabled => TRUE);
END;
4.2 历史趋势分析
修改脚本将结果存入历史表：
sql复制CREATE TABLE table_size_history AS
SELECT
SYSDATE as check_date,
tablespace_name,
table_name,
bytes
FROM
user_segments
WHERE 1=0;
-- 在脚本末尾追加
INSERT INTO table_size_history
SELECT
SYSDATE,
tablespace_name,
table_name,
bytes
FROM
user_segments
WHERE
segment_type = 'TABLE';
5. 常见问题排查指南
5.1 权限不足问题
若报错"ORA-00942: 表或视图不存在"，需确保执行用户有：
sql复制GRANT SELECT ON dba_segments TO your_user; -- 查看所有段
或
GRANT SELECT ON user_segments TO your_user; -- 仅查看自己段
5.2 结果不准确情况
检查特殊表类型的处理：
- 分区表：单个分区可能被统计为独立段
- 压缩表：实际物理大小可能小于逻辑大小
- 索引组织表(IOT)：存储方式与普通堆表不同
建议添加过滤条件：
sql复制WHERE segment_type = 'TABLE'
AND segment_name NOT LIKE 'BIN$%' -- 排除回收站对象
5.3 性能优化建议
当用户表超过1万时：
- 添加并行查询提示：
sql复制SELECT /*+ PARALLEL(4) */ ...
- 采样统计代替全量扫描：
sql复制WHERE MOD(ABS(ORA_HASH(table_name)),100) = 0 -- 1%采样
6. 脚本扩展方向
6.1 可视化输出
使用SQL*Plus的HTML输出功能生成网页报表：
sql复制SET MARKUP HTML ON
SPOOL report.html
-- 原查询语句
SPOOL OFF
6.2 与监控系统集成
通过Shell脚本调用并解析结果：
bash复制#!/bin/bash
sqlplus -s user/pass <<EOF >/tmp/output.log
@table_size_script.sql
EOF
# 提取关键指标
total_gb=$(grep "total_gb" /tmp/output.log | awk '{print $2}')
alert_threshold=100
if (( $(echo "$total_gb > $alert_threshold" | bc -l) )); then
echo "警告：总存储超过${alert_threshold}GB" | mail -s "存储警报" dba@example.com
fi
我在某电商平台数据库上实际使用此脚本时，曾发现一个日志表在两周内从50GB暴涨到300GB，及时排查发现是应用程序循环写入BUG。这个案例让我更加坚信定期存储分析的价值——它不仅是容量管理工具，更是系统健康监测的重要手段。