楼主: oradbHome

表记录不多, 却占用很大的空间,从哪里可以知道原因导致的.

[复制链接]
论坛徽章:
97
ITPUB元老
日期:2008-06-30 12:48:39暖羊羊
日期:2015-03-04 14:50:372015年新春福章
日期:2015-03-06 11:57:312010数据库技术大会纪念徽章
日期:2015-04-23 10:33:192011数据库大会纪念章
日期:2015-04-23 10:33:192012数据库大会纪念章
日期:2015-04-23 10:33:192013数据库大会纪念章
日期:2015-04-23 10:33:192014数据库大会纪念章
日期:2015-04-23 10:33:19林肯
日期:2013-10-31 12:31:382013年新春福章
日期:2013-02-25 14:51:24
11#
 楼主| 发表于 2009-5-10 12:35 | 只看该作者
dbms_space_admin.segment_dump

[ 本帖最后由 oradbHome 于 2009-5-10 12:36 编辑 ]

dump.rar

62.67 KB, 下载次数: 8

使用道具 举报

回复
论坛徽章:
2
CTO参与奖
日期:2009-02-12 11:45:482011新春纪念徽章
日期:2011-02-18 11:43:35
12#
发表于 2009-5-12 13:02 | 只看该作者
关注,顶一下

使用道具 举报

回复
论坛徽章:
97
ITPUB元老
日期:2008-06-30 12:48:39暖羊羊
日期:2015-03-04 14:50:372015年新春福章
日期:2015-03-06 11:57:312010数据库技术大会纪念徽章
日期:2015-04-23 10:33:192011数据库大会纪念章
日期:2015-04-23 10:33:192012数据库大会纪念章
日期:2015-04-23 10:33:192013数据库大会纪念章
日期:2015-04-23 10:33:192014数据库大会纪念章
日期:2015-04-23 10:33:19林肯
日期:2013-10-31 12:31:382013年新春福章
日期:2013-02-25 14:51:24
13#
 楼主| 发表于 2009-5-12 20:58 | 只看该作者
基本确认是个bug
Bug 5987262 Abstract : TABLESPACE IS ABNORMALLY INCREASED BY UNFORMATTED BLOCKS.
Bug 5890312 - A spin / hang / space leak can occur with ASSM segments

[ 本帖最后由 oradbHome 于 2009-5-12 21:07 编辑 ]

使用道具 举报

回复
论坛徽章:
47
蒙奇·D·路飞
日期:2017-03-27 08:04:23马上有车
日期:2014-02-18 16:41:112014年新春福章
日期:2014-02-18 16:41:11一汽
日期:2013-09-01 20:46:27复活蛋
日期:2013-03-13 07:55:232013年新春福章
日期:2013-02-25 14:51:24ITPUB 11周年纪念徽章
日期:2012-10-09 18:03:322012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:20
14#
发表于 2009-5-13 04:30 | 只看该作者
We're having the same problem with one of our databases right now. But we can't reproduce on two other databases. Here's a comparison:

DB-1: 8-node RAC, 10.2.0.4, RHEL 4, ASSM auto allocate, 8k block size
DB-2: single node, 10.2.0.4, RHEL 4, ASSM auto allocate, 8k block size
DB-3: 2-node RAC, 10.2.0.4, RHEL 5, ASSM auto allocate, 8k block size

The same data load always creates this space wastage problem on DB-1 and always works fine on -2 and -3. We can't find any solution and have to allocate huge space to -1 and shrink table after data load.

There's really no significant difference between them. DB-1 has db_writer_processes set to 2 and -2 and -3 have no such setting (default 1). Even that should be irrelevant.

Can you reproduce your problem on another same-version database?

Yong Huang

使用道具 举报

回复
论坛徽章:
97
ITPUB元老
日期:2008-06-30 12:48:39暖羊羊
日期:2015-03-04 14:50:372015年新春福章
日期:2015-03-06 11:57:312010数据库技术大会纪念徽章
日期:2015-04-23 10:33:192011数据库大会纪念章
日期:2015-04-23 10:33:192012数据库大会纪念章
日期:2015-04-23 10:33:192013数据库大会纪念章
日期:2015-04-23 10:33:192014数据库大会纪念章
日期:2015-04-23 10:33:19林肯
日期:2013-10-31 12:31:382013年新春福章
日期:2013-02-25 14:51:24
15#
 楼主| 发表于 2009-5-13 12:52 | 只看该作者
原帖由 Yong Huang 于 2009-5-13 04:30 发表
We're having the same problem with one of our databases right now. But we can't reproduce on two other databases. Here's a comparison:

DB-1: 8-node RAC, 10.2.0.4, RHEL 4, ASSM auto allocate, 8k block size
DB-2: single node, 10.2.0.4, RHEL 4, ASSM auto allocate, 8k block size
DB-3: 2-node RAC, 10.2.0.4, RHEL 5, ASSM auto allocate, 8k block size

The same data load always creates this space wastage problem on DB-1 and always works fine on -2 and -3. We can't find any solution and have to allocate huge space to -1 and shrink table after data load.

There's really no significant difference between them. DB-1 has db_writer_processes set to 2 and -2 and -3 have no such setting (default 1). Even that should be irrelevant.

Can you reproduce your problem on another same-version database?

Yong Huang


Doc ID:         729149.1
Subject:         Table Growth Is Far More Than Expected
可以参考729149.1 是否存在过多的unformated blocks.

这个问题在我这里只有这一个表存在这个问题. 其它的数据库上没有发现.

使用道具 举报

回复
论坛徽章:
47
蒙奇·D·路飞
日期:2017-03-27 08:04:23马上有车
日期:2014-02-18 16:41:112014年新春福章
日期:2014-02-18 16:41:11一汽
日期:2013-09-01 20:46:27复活蛋
日期:2013-03-13 07:55:232013年新春福章
日期:2013-02-25 14:51:24ITPUB 11周年纪念徽章
日期:2012-10-09 18:03:322012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:20
16#
发表于 2009-5-14 05:52 | 只看该作者
原帖由 oradbHome 于 2009-5-12 22:52 发表

Doc ID:         729149.1
Subject:         Table Growth Is Far More Than Expected
可以参考729149.1 是否存在过多的unformated blocks.

这个问题在我这里只有这一个表存在这个问题. 其它的数据库上没有发现.


Thanks for that note. Is it possible you apply that patch to see if the problem goes away?

We opened an SR with Oracle and the analyst suggested we apply patch 5890312. We haven't done it, but have run dbms_repair.segment_fix_status on all tables and indexes in the schema. Next time when we load data, we'll see if this procedure worked or not. We can't load data whenever we want. Have to wait till the beginning of each month.

Can you try segment_fix_status (see PL/SQL Reference in documentation or Bug 4660718)?

Yong Huang

[ 本帖最后由 Yong Huang 于 2009-5-14 09:39 编辑 ]

使用道具 举报

回复
论坛徽章:
97
ITPUB元老
日期:2008-06-30 12:48:39暖羊羊
日期:2015-03-04 14:50:372015年新春福章
日期:2015-03-06 11:57:312010数据库技术大会纪念徽章
日期:2015-04-23 10:33:192011数据库大会纪念章
日期:2015-04-23 10:33:192012数据库大会纪念章
日期:2015-04-23 10:33:192013数据库大会纪念章
日期:2015-04-23 10:33:192014数据库大会纪念章
日期:2015-04-23 10:33:19林肯
日期:2013-10-31 12:31:382013年新春福章
日期:2013-02-25 14:51:24
17#
 楼主| 发表于 2009-5-15 11:49 | 只看该作者

回复 #16 Yong Huang 的帖子

我昨天已经打了patch 5890312

到现在那个表也没有扩展extent , 我想是patch 启作用了.因为在前天还扩展了20几个32M 的extents .

使用道具 举报

回复
论坛徽章:
47
蒙奇·D·路飞
日期:2017-03-27 08:04:23马上有车
日期:2014-02-18 16:41:112014年新春福章
日期:2014-02-18 16:41:11一汽
日期:2013-09-01 20:46:27复活蛋
日期:2013-03-13 07:55:232013年新春福章
日期:2013-02-25 14:51:24ITPUB 11周年纪念徽章
日期:2012-10-09 18:03:322012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:20
18#
发表于 2009-7-6 01:06 | 只看该作者
原帖由 Yong Huang 于 2009-5-13 15:52 发表

We opened an SR with Oracle and the analyst suggested we apply patch 5890312. We haven't done it, but have run dbms_repair.segment_fix_status on all tables and indexes in the schema. Next time when we load data, we'll see if this procedure worked or not. We can't load data whenever we want. Have to wait till the beginning of each month.

Can you try segment_fix_status (see PL/SQL Reference in documentation or Bug 4660718)?

Yong Huang


At the beginning of both June and July, we ran our data load on the database we had this problem on. We no longer have this problem. The only significant change we made was that at the end of May, we ran the procedure segment_fix_status (Ref: http://download.oracle.com/docs/ ... pair.htm#sthref4784). So we didn't have to apply the patch.

Yong Huang

使用道具 举报

回复
论坛徽章:
6
生肖徽章2007版:蛇
日期:2008-11-27 22:43:26CTO参与奖
日期:2009-01-15 11:42:46生肖徽章2007版:兔
日期:2009-03-05 14:45:05生肖徽章2007版:虎
日期:2009-04-29 16:03:372011新春纪念徽章
日期:2011-02-18 11:43:362012新春纪念徽章
日期:2012-01-04 11:51:22
19#
发表于 2011-12-27 10:29 | 只看该作者
执行DBMS_REPAIR.SEGMENT_FIX_STATUS 查询表hang住

使用道具 举报

回复
论坛徽章:
47
蒙奇·D·路飞
日期:2017-03-27 08:04:23马上有车
日期:2014-02-18 16:41:112014年新春福章
日期:2014-02-18 16:41:11一汽
日期:2013-09-01 20:46:27复活蛋
日期:2013-03-13 07:55:232013年新春福章
日期:2013-02-25 14:51:24ITPUB 11周年纪念徽章
日期:2012-10-09 18:03:322012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:202012新春纪念徽章
日期:2012-02-13 15:13:20
20#
发表于 2012-1-1 12:25 | 只看该作者
> 执行DBMS_REPAIR.SEGMENT_FIX_STATUS 查询表hang住

Whenever you have a hang, the first thing you do is check the session's wait event.

Yong Huang

使用道具 举报

回复

您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

TOP技术积分榜 社区积分榜 徽章 团队 统计 知识索引树 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档
  ChinaUnix | ChinaUnix博客 | ChinaUnix论坛
CopyRight 1999-2011 itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有 联系我们 未成年人举报专区 
京ICP备16024965号-8  北京市公安局海淀分局网监中心备案编号:11010802021510 广播电视节目制作经营许可证:编号(京)字第1149号
  
快速回复 返回顶部 返回列表