前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >ORA-01658创建表或索引报错分析

ORA-01658创建表或索引报错分析

原创
作者头像
雪人
发布2024-07-29 16:10:04
1120
发布2024-07-29 16:10:04
举报
文章被收录于专栏:DataOps

一、报错信息

某项目最近在 SQL Loader 导数据时偶尔会报错,类似如下:

代码语言:shell
复制
SQL loader ORA-01658 unable to creale INITIAL extent for segment in tablespace ADS5GP2P_1

这个报错的意思是,没有足够的连续空间为表或索引创建 INITIAL extent:

代码语言:shell
复制
[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 情况:

代码语言:shell
复制
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,如下:

代码语言:shell
复制
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 给应用使用,从而报错。

以下进一步确认这些碎片的具体大小:

代码语言:shell
复制
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。这个只能在业务闲时操作,确保操作的表不要引起其他问题,比如先备份表。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 一、报错信息
  • 二、报错分析
  • 三、解决方案
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档