暂无图片
返回问答列表
分享
三石
2023-01-04
Oracle 11GR2数据库集群报警ORA-12801 和 ORA-01658
暂无图片 10M
oracle11g

我们这边有一套Oracle 11GR2数据库集群，表空间大概是400G，每次都是表空间使用到47%左右报错，
ORA-12801: error signaled in parallel query server P003, instance : (1)
ORA-01658: unable to create INITIAL extent for segment in tablespace XXXX,
非常奇怪，首先是权限肯定没有问题，
alter user userName quota unlimited on tablespace1 ;
grant dba to userName ;
只能是扩容解决，但这样非常浪费空间，而且没法触发报警，已知开发那边用的是sqlloader工具，有什么能解决的吗？

收藏
分享
10条回答
默认
最新
杨卓

你这个问题比较奇怪：
MSCPDC - ODS Load Fails ORA-01658: Unable To Create Initial Extent For Segment (Doc ID 377391.1)
可能性：
1.有很多无效的索引占用了空间浪费了，建议删除重建失效的索引
Unusable indexes can also cause this issue
2.大概率，是不是表空间碎片比较严重，这种情况下就是建议对表空间里面的表mv到其它的表空间里面去。
建议表空间使用统一的extents

暂无图片 评论
暂无图片 有用 1
打赏 0
暂无图片
三石
题主
2023-01-04
开发那边的操作我听介绍是，创建一个表，然后大量插入，最后是truncate，判断无误后drop，我先去查查碎片再说
杨卓
答主
2023-01-04
补充： 第三个可能性： 你的报错是ORA-01658: unable to create INITIAL extent for segment in tablespace XXXX, 一般来说INITIAL 是初始分配的extents,如果是小表，第一个extents 是8个块，默认blocks=8k, 也就是第一个分区是64k的大小。 Oracle 11g有个新特性，在oracle11.2创建分区表,每个分区默认大小为8M,是由_partition_large_extents参数控制,可以算是11.2.0.2开始的一个新特性,为了减少extent数量,提高分区表性能,而设置的一个参数,默认为true，即分区表的每个extent为8M，和oracle10g相比，会导致同样的数据耗费更多的表空间。 1）如果你报错的表都是分区表，那么分区表新建默认extents的要申请8M 这个就非常大了，当你的表空间碎片比较严重很可能申请不到的； 2）建议你具体排查一下报错的表是分区表的创建，还是已有的分区表添加新的分区，另外就是你扩容表空间之后，这些对象的分配的第一个extents大小是多少； 3）简单粗暴猜测是这个问题，可以设置参数关闭这个功能看看有没有效果 为了避免类似情况，可以设置_partition_large_extents参数为false. SQL> alter system set "_partition_large_extents"=false;
三石
题主
2023-01-04
1、没有失效索引，已经查过了，只有两个无效的存储过程和一个视图 2、表碎片找到了几个夸张的存在，加起来超过204G，收缩的话应该能节省180G左右， 3、该业务用户不涉及使用分区表
光輝岁月

检查下v$asm_disk视图，特定情况下会出现单个磁盘free_mb过小的情况，asm没有触发rebalance特性，手动reblance下问题解决

暂无图片 评论
暂无图片 有用 0
打赏 0
三石
题主
2023-01-04
OS_MB/1024 TOTAL_MB/1024 FREE_MB/1024 NAME ---------- ------------- ------------ ------------------------------ 1800 1800 781.585938 DATA_0002 100 100 43.4150391 DATA_0000 100 100 43.4169922 DATA_0001
三石
题主
2023-01-04
这个应该没问题吧
lgs

感觉是回收站占用的空间清理不及时，导致无法继续使用空间

暂无图片 评论
暂无图片 有用 0
打赏 0
三石
题主
2023-01-04
没开回收站
粗嘢哥哥

就是表空间的碎片率太大了，你查下表空间是不是system还是uniform 

暂无图片 评论
暂无图片 有用 0
打赏 0
三石
题主
2023-01-04
不是，是在业务表空间，而不是system这样的系统表空间
粗嘢哥哥
答主
2023-01-04
是看表空间属性
szrsu
暂无图片

检查下v$asm_disk视图，特定情况下会出现单个磁盘free_mb过小的情况，asm没有触发rebalance特性，手动reblance下问题解决

暂无图片 评论
暂无图片 有用 0
打赏 0
鸿惊九天
2023-01-04
出现单个磁盘free_mb过小的情况。。。。。。。。。。
伊伊相印
2023-01-04
出现单个磁盘free_mb过小的情况。。。。。。。。。。
超越无限D
2023-01-04
出现单个磁盘free_mb过小的情况。。。。。。。。。。,.
展开全部评论(1条)
超越无限D

检查下v$asm_disk视图，特定情况下会出现单个磁盘free_mb过小的情况，asm没有触发rebalance特性，手动reblance下问题解决

暂无图片 评论
暂无图片 有用 0
打赏 0
三石
题主
2023-01-04
OS_MB/1024 TOTAL_MB/1024 FREE_MB/1024 NAME ---------- ------------- ------------ ------------------------------ 1800 1800 781.585938 DATA_0002 100 100 43.4150391 DATA_0000 100 100 43.4169922 DATA_0001
Thomas

比如表空间叫A，SQLLOADER处理的表叫B，A上只有B一个表？每次DROP掉B后，A的使用率是0？B表表结构能否贴出？SQLLOADER里是以append方式插入吗？既然每次到47%就报错，那么SQLLOADER时，会产生.dsc文件存储插入失败的记录吗？sqlloader有没有选项忽略错误以完成插入？我感觉，错在某条特殊记录上。

暂无图片 评论
暂无图片 有用 0
打赏 0
JiekeXu
暂无图片

这个就是个问题，三块磁盘大小不一样，你的 1800 也只能用 100。ASM 可用率要看 USABLE_FILE_MB。生产环境建议磁盘大小一致，另外你表空间是自动扩展的吗？如果是自动扩展也有可能是没法自动扩展导致的。

OS_MB/1024 TOTAL_MB/1024 FREE_MB/1024 NAME
---------- ------------- ------------ ------------------------------
      1800        1800   781.585938 DATA_0002
       100         100   43.4150391 DATA_0000
       100         100   43.4169922 DATA_0001
暂无图片 评论
暂无图片 有用 0
打赏 0
三石
题主
2023-01-04
SQL> select name,state,type,free_mb/1024,total_mb/1024,usable_file_mb/1024 from v$asm_diskgroup; NAME STATE TYPE FREE_MB/1024 TOTAL_MB/1024 USABLE_FILE_MB/1024 ------------------------------ ----------- ------ ------------ ------------- ------------------- DATA CONNECTED EXTERN 837.416016 2000 837.416016 FRA CONNECTED EXTERN 162.623047 200 162.623047 OCR MOUNTED NORMAL 14.0957031 15 4.54785156 REDO CONNECTED EXTERN 14.2939453 20 14.2939453
三石

我直接设置的31G，没有设置自动扩展
TABLESPACE_NAME sum G used G free G used%
XXXXX 744 274 470 36.87

暂无图片 评论
暂无图片 有用 0
打赏 0
三石
问题已关闭: 问题已经得到解决
暂无图片 评论
暂无图片 有用 0
打赏 0
回答交流
Markdown


请输入正文
提交
问题信息
请登录之后查看
邀请回答
暂无人订阅该标签，敬请期待~~
暂无图片墨值悬赏