一、报错信息
某项目最近在 SQL Loader 导数据时偶尔会报错，类似如下：
SQL loader ORA-01658 unable to creale INITIAL extent for segment in tablespace ADS5GP2P_1
这个报错的意思是，没有足够的连续空间为表或索引创建 INITIAL extent:
[oracle@node1:1 ~]$ oerr ora 1658
01658, 00000, "unable to create INITIAL extent for segment in tablespace %s"
// *Cause: Failed to find sufficient contiguous space to allocate INITIAL
// extent for segment being created.
// *Action: Use ALTER TABLESPACE ADD DATAFILE to add additional space to the
// tablespace or retry with a smaller value for INITIAL
二、报错分析
数据库版本是 Oracle 11G，实际查看该表空间仍有2T多的剩余空间，根据以往经验，最大的可能是这2T多的剩余空间大多是碎片，在业务忙时无法提供足够可用的连续空间，以下做验证。
DBA_FREE_SPACE describes the free extents in all tablespaces in the database.
数据字典 DBA_FREE_SPACE 描述了所有的可用 extent 情况：
select trunc(bytes/1048576) mb, count(*)
from dba_free_space
where tablespace_name = 'ADS5GP2P_1'
group by trunc(bytes/1048576)
order by 1;
0 2374933
1 61526
2 21622
3 13995
4 34797
5 5133
6 6851
7 3687
8 16463
9 2883
10 1785
11 1348
12 5552
13 742
14 666
15 615
16 6029
17 326
18 300
19 398
20 2553
21 94
22 62
23 49
24 82
25 41
26 21
27 9
28 26
29 15
30 12
......
以上可见空闲的空间里有大量的碎片，可能的原因是频繁、长时间的修改、导入数据逐步导致的。这些碎片的大小达到了 2T，如下：
select tablespace_name, sum(bytes/1048576) mb
from dba_free_space
where trunc(bytes/1048576) < 1
group by tablespace_name;
---
ADS5GP2P_1: 2162858.375
结论是：
虽然空闲空间很多，但是这些空闲空间大都是小于 1M 的小碎片，这些小碎片加起来达到了2T，导致可能有时没法及时分配 INITIAL extent 给应用使用，从而报错。
以下进一步确认这些碎片的具体大小：
select trunc(bytes/65536) k64, count(*)
from dba_free_space
where tablespace_name = 'ADS5GP2P_1'
group by trunc(bytes/65536)
order by 1;
1 31756
2 8567
3 6803
4 10116
5 3230
6 1748
7 2027
8 2492
9 11143
10 4988
11 1183
12 1875
13 21457
14 43512
15 2228918
16 1251
17 151
18 152
19 230
20 177
以上可见 15*65536=960k 的 extent 达到了 2228918，合计 2T 多。
可见这些小碎片大多是 960k 的小碎片，理论上对于大多数 64k 的 INITIAL extent 是可用、不会报错的。
三、解决方案
因此最终的解决方案是，修改报错表和索引的 INITIAL extent，让他们小于多数碎片的大小，即小于 960k。这个只能在业务闲时操作，确保操作的表不要引起其他问题，比如先备份表。
