企业官网建设流程全解析

1. 先认识这个报错：ORA-01654到底在说什么

1.1 报错现场还原

先说个最常见的场景：下午四点半，开发同事甩过来一张截图，说报表跑不出来了，日志里躺着一行红字——

ORA-01654: unable to extend index USR_ORDER_IDX by 128 in tablespace TBS_DATA

第一次碰到的朋友很容易慌，以为是索引坏了，或者表坏了。其实都不是。这行报错翻译成人话就是：TBS_DATA 这个表空间已经没有足够的空闲空间来继续分配给索引 USR_ORDER_IDX 了。这里的 128 单位是数据块（Oracle Block），意思是系统想再给这个索引段分配 128 个块的空间，结果发现表空间里挤不出来了。

这类报错在 Oracle 日常运维里出现频率非常高。不管是 11g、12c 还是 19c，只要表空间规划没跟上数据增长速度，迟早都会撞上它。适合谁看？主要是初、中级 DBA，以及那些需要自己维护 Oracle 库的开发人员。看完之后你能知道怎么快速定位是哪个表空间满了、怎么应急处理、怎么避免下次再犯。

1.2 段、表空间与区间的存储机制

要真正处理这个报错，得先搞明白 Oracle 的存储层级。Oracle 的逻辑存储结构依次是：表空间（Tablespace）→ 段（Segment）→ 区间（Extent）→ 数据块（Block）。

表、索引、回滚段这些对象，在 Oracle 里统称为"段"。每个段刚开始只有几个区间，数据不断写入后，段就需要申请更多区间来容纳新数据。每次申请区间时，Oracle 会去所在表空间的空闲空间列表中找足够大的空间块。如果找来找去都凑不出一个区间所需的连续空间，就会报 ORA-01654。

这里有个容易误解的点："表空间满了"不等于"磁盘满了"。表空间是由一个或多个数据文件组成的。虽然服务器磁盘还剩好多 GB，但如果表空间里的数据文件已经涨到了上限（MAXSIZE），或者数据文件关闭了自动扩展，那这个表空间对 Oracle 来说就是"满了"。就像你的手机存储卡还有 64G，但某个 App 被设置了 2G 的使用配额，配额用完就提示"空间不足"，其实卡里还有大把地方。

另外一个关键概念是"连续空间"。如果你在表空间里看到空闲总量有 300MB，但每个空闲碎片只有不到 1MB，恰好你要分配的区间需要 8MB 连续块，Oracle 依然会给你报错。这个问题放到后面"避坑实录"部分细说。

1.3 别搞混：ORA-01650 到 ORA-01656 这一家子

ORA-01654 不是孤立的，它周边有一大堆类似的报错，基本上一家人整整齐齐。我列个表，方便你一眼对应上：

注意的是，上面这些报错在处理思路上一脉相承，都是"表空间空间分配失败"。区别只是段类型不同。本文重点讲 ORA-01654，但后面给出的排查 SQL 和解决办法，这套思路可以原封不动套到 ORA-01653 甚至临时表空间的 ORA-01652 上。

2. 排查定位：别急着加文件，先搞清楚是谁满了

2.1 从报错信息里读出关键字段

ORA-01654 报错信息里其实包含了三个关键信息：段名、扩展块数、表空间名。

ORA-01654: unable to extend index USR_ORDER_IDX by 128 in tablespace TBS_DATA

逐词拆解一下：

• index USR_ORDER_IDX：出问题的段类型是索引，名字叫 USR_ORDER_IDX。
• by 128：想继续扩展 128 个数据块。
• tablespace TBS_DATA：这个索引所在的表空间叫 TBS_DATA。

拿到这三条信息就可以动手查了。千万别跳过这一步直接加数据文件，因为有些时候表空间的空闲量其实是够的，真正的问题是编号规则、块大小或碎片导致的分配失败，直接加文件也能解决，但会掩盖真实问题。

2.2 查表空间使用率

第一件事，确认 TBS_DATA 的整体使用情况。我最常用的查询是这个：

SELECT d.tablespace_name, ROUND(SUM(d.bytes) / 1024 / 1024 / 1024, 2) AS total_gb, ROUND(SUM(d.bytes - NVL(f.bytes, 0)) / 1024 / 1024 / 1024, 2) AS used_gb, ROUND(NVL(SUM(f.bytes), 0) / 1024 / 1024 / 1024, 2) AS free_gb, ROUND((1 - NVL(SUM(f.bytes), 0) / SUM(d.bytes)) * 100, 2) AS used_pct FROM dba_data_files d LEFT JOIN (SELECT tablespace_name, SUM(bytes) bytes FROM dba_free_space GROUP BY tablespace_name) f ON d.tablespace_name = f.tablespace_name WHERE d.tablespace_name = 'TBS_DATA' GROUP BY d.tablespace_name;

执行之后的结果一般能一眼看出问题：如果 used_pct 超过 97%，那基本就是空间耗尽；如果 used_pct 只有 70%，free_gb 也有好几个 G，那就得换个角度查，看是不是数据文件的可扩展上限问题。

2.3 查数据文件状态和自动扩展配置

表空间使用率高时，数据文件很可能已经膨胀到了上限。这条 SQL 看每个数据文件的当前大小、最大大小和是否开启自动扩展：

SELECT FILE_ID, FILE_NAME, TABLESPACE_NAME, ROUND(BYTES / 1024 / 1024, 2) AS size_mb, ROUND(MAXBYTES / 1024 / 1024, 2) AS max_mb, AUTOEXTENSIBLE, INCREMENT_BY FROM dba_data_files WHERE TABLESPACE_NAME = 'TBS_DATA' ORDER BY FILE_ID;

重点看 AUTOEXTENSIBLE 这一列：

• 如果是NO，那数据文件大小是固定的，用满就报 ORA-01654。
• 如果是YES，但当前大小已经等于 MAXBYTES，说明到达了自动扩展上限，同样报错。
• 如果是YES，还没到上限，那就要考虑是不是磁盘本身满了，或者数据文件数量已经超出了某个限制。

这里补一句：单数据文件并不是无限大的。Oracle smallfile 表空间下，单个数据文件的块数上限是 4,194,304（2 的 22 次方）个块。如果数据库块是 8KB，那单文件最大就是 32GB；如果是 16KB 块，单文件最大 64GB。所以很多上了规模的生产库，表空间里都会挂七八个甚至十几个数据文件，而不是靠一个文件无限涨。

2.4 顺着报错找到具体对象

拿到索引名字后，最好再确认一下它属于哪张表，以及它的表空间有没有被不小心改过：

SELECT OWNER, TABLE_NAME, TABLESPACE_NAME, STATUS FROM dba_indexes WHERE INDEX_NAME = 'USR_ORDER_IDX';

如果索引在 TBS_DATA，但它的父表在另一个表空间，这也是很常见的规划方式，没关系。但如果索引和表混在同一个正在膨胀的表空间里，建议顺便查一下父表占了多少空间，心里好有个数：

SELECT OWNER, SEGMENT_NAME, SEGMENT_TYPE, ROUND(BYTES / 1024 / 1024 / 1024, 2) AS size_gb FROM dba_segments WHERE TABLESPACE_NAME = 'TBS_DATA' ORDER BY BYTES DESC FETCH FIRST 10 ROWS ONLY;

这样就可以确认：这个表空间里到底谁吃了大头。说不定真正占空间的是几张日志表，而那个索引只是被连累的"受害者"。

3. 五种解决方案：从应急到彻底解决

3.1 方案一：直接扩展数据文件（resize）

如果数据文件还没到单文件上限，而且服务器磁盘还有空间，resize 是最快的处理方式：

ALTER DATABASE DATAFILE '/u01/oradata/TSDB/tbs_data01.dbf' RESIZE 32G;

注意文件名要跟 dba_data_files 里查出来的完全一致，路径写错会报 ORA-01157 找不到文件。另外，resize 只能往大了调不能瞎调小，调小后如果文件尾部还有数据，会报 ORA-03297，这个后面单独说。

实际操作中我一般分两步走：先看当前文件大小，再决定能调多大。比如当前是 16G，磁盘剩余 200G，那就先调到 32G 观察一下，不必一步到位，免得空间规划失控。

3.2 方案二：开启或调大自动扩展

如果这个库是开发库、测试库，平时没人做严格的容量管理，直接把自动扩展打开是最省心的：

ALTER DATABASE DATAFILE '/u01/oradata/TSDB/tbs_data01.dbf' AUTOEXTEND ON NEXT 512M MAXSIZE 32G;

这里 NEXT 参数意思是每次自动增长 512MB，不要设得太小。如果设成 1M，数据量一上来，文件会频繁触发扩容，产生不必要的空间分配开销，严重时能明显感觉到系统卡顿，告警日志里也会刷出一堆"Adding additional space to datafile"之类的信息。

生产环境我建议关掉自动扩展，改成手动管理。理由很简单：自动扩展容易掩盖空间增长趋势，等发现的时候表空间往往已经涨得不可控了，而且 maxsize 如果设了 unlimited，单个文件可能把磁盘撑爆，数据库直接 hang 住，比报 ORA-01654 要麻烦得多。

3.3 方案三：新增数据文件

当单个数据文件已经顶到上限（比如 8KB 块到 32G），resize 没空间可扩，那就在表空间里再添一个数据文件：

ALTER TABLESPACE TBS_DATA ADD DATAFILE '/u01/oradata/TSDB/tbs_data02.dbf' SIZE 8G AUTOEXTEND ON NEXT 512M MAXSIZE 32G;

新增数据文件比 resize 现有文件更灵活，而且能分散 I/O，尤其适合大表空间在多磁盘路径上的部署。注意别把所有数据文件放在同一块物理磁盘上，不然数据文件数量再多也白搭，读写全挤在一条道上。

加完文件之后，再跑一遍使用率查询，确认 TBS_DATA 的 free_gb 涨上来了。然后让业务重试刚才失败的 SQL，基本就能恢复正常。

3.4 方案四：清理无用数据并回收空间

加文件只是临时止血，如果表空间里全是历史垃圾数据，再多的磁盘也扛不住。清理空间要做两件事：清数据，和让段把空间吐出来。

先说清数据：

• 如果是日志表、临时中间表，可以直接 TRUNCATE。TRUNCATE 是 DDL 操作，会清空表数据但保留表结构，空间会完全释放给表空间。
• 如果是业务数据，按时间条件 DELETE 旧数据，这个属于 DML，可以加 WHERE 条件控制删多少，注意提交频率。

关键点来了：DELETE 之后，段的高水位线不会降。什么意思呢？你删掉了表里 80% 的行，但这个表段占用的数据块并没有全部释放，下次再插入数据时，Oracle 会优先重用那些"空了"的块。从段的视角看，空间确实富余了；但从表空间的视角看，这个段仍然圈着大把空间，空闲列表里可能仍然显示空间紧张。

想让 DELETE 之后的空间真正回到表空间层面，可以执行段收缩：

ALTER TABLE USR_ORDER LOGGING ENABLE ROW MOVEMENT; ALTER TABLE USR_ORDER SHRINK SPACE CASCADE;

SHRINK 需要开启行迁移，而且对正在被高频访问的大表会产生额外的 I/O 和锁竞争，建议在维护窗口执行。如果表太大，SHRINK 做不动，也可以考虑 MOVE 到新表空间再还回来，代价是相关的索引要重建。

索引本身如果碎片化严重，也可以重建：

ALTER INDEX USR_ORDER_IDX REBUILD;

REBUILD 之后索引段会重新紧凑排列，不仅缩小空间占用，还能提升查询效率。但要注意，重建索引期间 DML 会被阻塞，务必安排在低峰期。

3.5 方案五：段迁移与表空间重组

如果你的系统里存在多个表空间，而当前爆满的 TBS_DATA 里正好有对象其实没必要待在这，那就把它们挪出去，给紧急的表腾地方。比如把一张历史表移到 TBS_HISTORY：

ALTER TABLE USR_ORDER_LOG MOVE TABLESPACE TBS_HISTORY; ALTER INDEX USR_ORDER_LOG_IDX REBUILD TABLESPACE TBS_HISTORY;

这里要特别注意：表 MOVE 到新表空间之后，索引不会跟着动，所以复制的索引必须 REBUILD，否则会变成 UNUSABLE 状态，查询直接报 ORA-01502。这个坑我踩过不止一次，每次都要提醒自己 MOVE 表和 REBUILD 索引必须成对出现。

3.6 五种方案的选择逻辑

把这五个方案摆一起看，选择顺序其实很清楚：

我的习惯是：先解决眼前报错，保证业务恢复；然后立刻把容量趋势查出来，决定是清理还是扩容；最后把监控和告警补上。

4. 防患于未然：表空间监控与容量规划

4.1 一套可以直接用的监控 SQL

ORA-01654 这种报错，最理想的情况是在它发生之前就通过监控发现。下面这个 SQL 我基本见库就执行一遍，把所有表空间的使用率一次列出来：

SELECT d.tablespace_name, ROUND(SUM(d.bytes) / 1024 / 1024 / 1024, 2) AS total_gb, ROUND(SUM(d.bytes - NVL(f.bytes, 0)) / 1024 / 1024 / 1024, 2) AS used_gb, ROUND(NVL(SUM(f.bytes), 0) / 1024 / 1024 / 1024, 2) AS free_gb, ROUND((1 - NVL(SUM(f.bytes), 0) / SUM(d.bytes)) * 100, 2) AS used_pct FROM dba_data_files d LEFT JOIN (SELECT tablespace_name, SUM(bytes) bytes FROM dba_free_space GROUP BY tablespace_name) f ON d.tablespace_name = f.tablespace_name GROUP BY d.tablespace_name ORDER BY used_pct DESC;

再配合一条查剩余空间碎片的 SQL：

SELECT TABLESPACE_NAME, COUNT(*) AS free_extents, ROUND(MAX(BYTES) / 1024 / 1024, 2) AS max_fragment_mb, ROUND(SUM(BYTES) / 1024 / 1024, 2) AS total_free_mb FROM dba_free_space GROUP BY TABLESPACE_NAME ORDER BY total_free_mb DESC;

如果 max_fragment_mb 远小于 total_free_mb，说明这个表空间碎片化严重，总有一天会出现"明明有空间但就是分配不出来"的情况。这种情况光看使用率是发现不了的，必须靠这条 SQL。

4.2 巡检节奏和告警阈值

空间巡检的节奏我建议至少一周一次，数据增长快的库每天一次。可以用 shell 的 crontab 把上面的 SQL 包装成一个脚本，超过阈值就往钉钉或邮件发消息，逻辑非常简单，效果比人肉巡检可靠得多。

阈值设置也不要一刀切。我说个经验值，仅供参考：

• 使用率超过 85% 时列入关注，开始评估未来两周的增长量。
• 超过 92% 时准备扩容方案，能扩的赶紧扩。
• 超过 97% 时立即处理，已经进入危险区。

这个阈值对核心生产库可以更保守，比如 80% 就开始动手规划。

4.3 容量规划建议

临时抱佛脚只能是应急，表空间规划应该在建表时就做好。几个建议：

• 业务表与索引分开表空间：这是最常见的做法，索引表空间单独规划，可以避免索引和表争抢空间。
• 按分区表管理大表：把历史数据按月份分区，旧分区可以单独移动到慢速存储表空间，甚至定期 DROP 老分区。
• UNDO 和 TEMP 单独预留：UNDO 表空间太小会导致 ORA-01555 和事务失败，TEMP 表空间太小会导致排序 SQL 报 ORA-01652，这俩都是独立的坑，不要和数据表空间混在一起算容量。
• 定期评估增长趋势：查询 dba_segments 按月统计每个表空间的增长量，对后续扩容很有参考价值。

5. 常见问题速查与避坑实录

5.1 resize 时碰到 ORA-03297 怎么办

ORA-03297 的意思是在你指定缩小到的目标位置之后，文件里还有数据占着块，所以不能收缩。比如你想把 32G 文件缩小到 20G，但文件在 20G 之后的地方仍有段在使用。

处理办法分两步：

1. 定位这个文件里靠后的段：

SELECT OWNER, SEGMENT_NAME, SEGMENT_TYPE, BLOCK_ID, BLOCKS FROM dba_extents WHERE FILE_ID = &file_id ORDER BY BLOCK_ID DESC;

2. 把这些段 MOVE 到其他表空间（或先导出再导入），腾出尾部的块，之后再重新 resize。

不得不说，这个过程比较折腾。所以在生产环境，我通常只往大调，基本不做缩小操作。真到需要缩小空间的地步，说明表空间规划已经出大问题了，不如直接重建一个合理大小的新表空间，把数据迁过去。

5.2 清完数据还是报 ORA-01654

如果你执行了 DELETE，表空间使用率也确实降下来了，但第二天又报 ORA-01654，那大概率是高水位线的问题。我在 3.4 节已经提过，这里再强调一遍：DELETE 释放的空间还留在段的肚子里，没有还给表空间。只有 TRUNCATE 是直接把高水位线拉下来并释放全部空间；DELETE 则需要配合 SHRINK SPACE 才能让空间真正回归表空间。

另外还有一种可能：表空间里剩余的是零碎空间。比如 free_gb 显示有 6G，但最大连续空闲区只有 100MB，而你那个索引需要的区间大小恰好大于 100MB。这种情况下，加一个新的数据文件反而能立刻解决问题，因为新文件是连续的。

5.3 UNDO 表空间相关的 ORA-01654

重看报错信息，如果出问题的是 UNDO 表空间，比如：

ORA-01654: unable to extend index _SYSSMU1_4242123456$ by 64 in tablespace UNDOTBS1

这里扩展失败的是 UNDO 段。原因是 UNDO 表空间不足，事务需要回滚信息但没地方写了。处理办法是给 UNDO 表空间增加数据文件：

ALTER TABLESPACE UNDOTBS1 ADD DATAFILE '/u01/oradata/TSDB/undotbs02.dbf' SIZE 8G AUTOEXTEND ON NEXT 512M MAXSIZE 16G;

同时检查是不是有长时间未提交的大事务，或者 UNDO_RETENTION 配得过大导致 UNDO 被强制保留。如果业务上经常跑大批量 UPDATE 又没提交，UNDO 空间会像漏水的桶一样快速见底。

5.4 临时表空间满了怎么办

如果报错信息里出现 temp segment 或者 ORA-01652，那是临时表空间的问题，而不是数据表空间。排序、哈希连接、分组聚合这些操作都会临时占用 TEMP 表空间。处理方法：

ALTER TABLESPACE TEMP ADD TEMPFILE '/u01/oradata/TSDB/temp02.dbf' SIZE 4G AUTOEXTEND ON NEXT 512M MAXSIZE 16G;

如果是多个实例共用一个 TEMP 表空间，配置会有点讲究，但核心思路和 ORA-01654 一致：空间不够，就给它空间。临时表空间的空间不足，有时候重启实例也能清理掉一部分挂着的临时段，但这不是治本的办法，该扩还得扩。

5.5 索引所在表空间的碎片陷阱

前面提到过"总空闲够但连续空闲不够"的情况。在实际故障中，这类问题最让人迷惑，因为你跑使用率查询发现 free_gb 明明有 5G，但业务就是报错。

Oracle 分配区间时，如果表空间是本地管理且统一区大小（uniform size）模式，那么每个区间的大小是一样的。如果你建表空间时设了 UNIFORM SIZE 8M，而表空间里只剩下大量 1M、2M 的零星碎片，那 8M 的统一区间根本分配不出来。这种情况的解法要么加数据文件，要么用 AUTOALLOCATE 模式重建表空间。

所以创建表空间的时候，除了关注初始大小，一定要想清楚区间的分配方式。碰到 ORA-01654 且 free 空间不少时，也要主动去查一下 dba_free_space 的碎片分布，别被表面的使用率糊弄过去。

5.6 报错速查表

最后给一份速查表，方便以后直接对着排查：

6. 最后说几句大实话

ORA-01654 这个报错本身不难解决，难的是每次都在你最不想出问题的时候突然冒出来。我自己的体会是：绝大多数 ORA-01654 不是"突然"发生的，而是容量管理长期缺位后的必然结果。只要一开始就做好监控、规划好表空间、控制好自动扩展，这个报错基本可以完全避免。

最后分享一个小习惯：每次处理完这类报错，我都会把 alert 日志里当天的错误时间点、处理动作、最终效果记一笔。攒上几个月回看，你会发现哪些表空间是"常客"，哪些业务表是吞空间的黑洞，后续做扩容和优化就有据可依了，比每次当救火队员舒服得多。