首页 > 学技术 > 技术网文 > Informix > 正文

[原创] 自己写的检查数据库中表的extents数及相应处理的shell


来源 chinaunix.net 酷勤网整理

平时经常要监测数据库中各表的情况,于是写了两个shell,用起来蛮方便。。。

一、检查数据库中所有的表的extents数并输出到文件中。输出的文件中,表是按extents数目大小倒序排列。
>;cat check_extents.sh

today=`date +%Y%m%d%H%M%S`
dbaccess - <<EOF >; sql_tab_ext_${today}.txt
database sysmaster;
select dbsname,tabname,
count(*) num_of_extents,
sum( pe_size ) total_size
from systabnames,sysptnext
where partnum = pe_partnum
group by 1, 2
order by 3 desc,4 desc;
EOF


二、如发现表的extents过大,可采取下列步骤
0。dbschema 导出表结构
1。rename 原表名
2。以原结构新建表,但增大extents和next size
3。unload出原表数据
4。dbload 数据到新表

例如发现表t_prox_pb_log的extents过大,可以这样:
0.dbschema -t t_prox_pb_log -d dbname -ss t_prox_pb_log.sql
1-4步可以写成pblog.sh如下:
>;cat pblog.sh 
(表结构用第0步生产的结构即可)

dbaccess  << -- 2>;>;pblog.err
!
database dbname;
rename table t_prox_pb_log to t_pb_log_bak;

create table t_prox_pb_log
  (
    oper_kind char(3) not null ,
    oper_detail char(6) not null ,
    trn_mode char(1) not null ,
    user_no1 char(20) not null ,
    cust_name char(40) not null ,
    trn_amt float,
    cert_no integer,
    cert_num integer,
    trn_code char(4),
    trn_date char(8),
    trn_time char(6),
    trn_bank char(4),
    oper_no char(4),
    seq_no smallint,
    trn_stat char(1),
    primary key (trn_date,trn_bank,oper_no,seq_no)
  ) extent size 2048 next size 1024 lock mode row;
revoke all on t_prox_pb_log from "public";

create index i_prox_pb_log2 on t_prox_pb_log (user_no1);


unload to "t_pb_log.txt" select * from t_pb_log_bak;
!
--
dbload -d dbname -c load_log -l dbload_errlog -n 1000  -k


控制文件load_log如下:
>; cat load_log
FILE t_pb_log.txt DELIMITER '|' 15;
INSERT INTO t_prox_pb_log;



 czw1413_cn 回复于:2004-09-06 12:08:41

不错
不过表的 extent应该是在数据库设计的时候就规划的


 cruelsun 回复于:2004-09-09 16:10:31

前几天从尚洋的一位工程师手里看到这篇文章,原来是楼主写的,总结的不错哦!
补充两句,官方finderr里建议重建表的时候,把初始extents设成整个表那么大,也就是一个extent就放进整个表。然后next extents设成初始extents的1/4 ~ 1/16。
大家试试~


 cruelsun 回复于:2004-09-09 16:17:10

引用:原帖由 "czw1413_cn" 发表:
不错
不过表的 extent应该是在数据库设计的时候就规划的



理论上是这样,可惜我们都太懒了,开发人员设计表的时候没有注意,数据库管理员创建表的时候也没有理睬,结果数据库里面都是默认的extent设置。
我决定下次重建数据库好好整一下,呵呵~


 carefen 回复于:2004-09-09 22:40:27

不错啊。。学习ing 。。


 lmtok 回复于:2004-09-10 11:40:36

引用:原帖由 "cruelsun" 发表:


理论上是这样,可惜我们都太懒了,开发人员设计表的时候没有注意,数据库管理员创建表的时候也没有理睬,结果数据库里面都是默认的extent设置。
我决定下次重建数据库好好整一下,呵呵~



我们有一个版本的数据库,这方面做得很差,性能不好,
后来重新搞这个东西费了我好大的劲啊,吃力不讨好。 :em06: 
下一个版本的时候,在上线前花的大工夫彻底整了一遍
库表的分片和存储管理,这下子就好多了。
各位DBA这方面的工夫还可真是不能省....  :em11: .


 lianyong 回复于:2004-09-10 15:21:34

引用:原帖由 "cruelsun" 发表:
前几天从尚洋的一位工程师手里看到这篇文章,原来是楼主写的,总结的不错哦!
补充两句,官方finderr里建议重建表的时候,把初始extents设成整个表那么大,也就是一个extent就放进整个表。然后next extents设成初始..........


呵呵,一摸一样吗?那就巧了,我可不认识尚洋的工程师呢。。。


 fjtele 回复于:2004-09-12 17:22:48

不错,收藏!多发点这样的文章


 cruelsun 回复于:2004-09-13 11:48:00

引用:原帖由 "lianyong" 发表:

呵呵,一摸一样吗?那就巧了,我可不认识尚洋的工程师呢。。。



真的是一摸一样哦,可能是他来我们之前到CU恶补了一下,结果成了楼主的fans。。。


 cruelsun 回复于:2004-09-13 11:53:03

有个问题:
我将一张表重建了一次,初始extents设得比整张表都大,next extents设成原大小的1/10,为什么重建之后这张表占了6个extents呢?而表的大小比原来减少了。

占用extents的个数和表的大小是根据楼主的SQL语句。


 quicksand 回复于:2004-09-18 16:57:54

引用:原帖由 "cruelsun"]前几天从[size=18][color=red]尚洋[/color][/size 发表:
的一位工程师手里看到这篇文章,原来是楼主写的,总结的不错哦!
补充两句,官方finderr里建议重建表的时候,把初始extents设成整个表那么大,也就是一个extent就放进整个表。然后next extents设成初始..........




呵呵呵,有一个人就叫做[size=24][color=blue]尚洋[/color][/size]

不过他不是做技术的,是搞人力资源的


 livepower 回复于:2004-09-19 16:35:08

引用:原帖由 "cruelsun" 发表:
有个问题:
我将一张表重建了一次,初始extents设得比整张表都大,next extents设成原大小的1/10,为什么重建之后这张表占了6个extents呢?而表的大小比原来减少了。

占用extents的个数和表的大小是根据楼主的SQ..........


楼主写的这个SQL可能有些问题,他哪里找出来是这个表里实际数据用的数据空间页,而如果要初始化EXTENT的话应该到sysptnhdr表中找。里面有三个指标,一个是总的分配了多少,一个是使用了多少,另一个是数据空间是多少。所以你要找的应该是使用多少这个字段。具体你查一下就知道是哪个了。一般来讲一个表不但有数据空间,还是有索引空间,约束空间等等。


 livepower 回复于:2004-09-19 16:36:03

引用:原帖由 "cruelsun" 发表:
有个问题:
我将一张表重建了一次,初始extents设得比整张表都大,next extents设成原大小的1/10,为什么重建之后这张表占了6个extents呢?而表的大小比原来减少了。

占用extents的个数和表的大小是根据楼主的SQ..........


楼主写的这个SQL可能有些问题,他哪里找出来是这个表里实际数据用的数据空间页,而如果要初始化EXTENT的话应该到sysptnhdr表中找。里面有三个指标,一个是总的分配了多少,一个是使用了多少,另一个是数据空间是多少。所以你要找的应该是使用多少这个字段。具体你查一下就知道是哪个了。一般来讲一个表不但有数据空间,还是有索引空间,约束空间等等。


 winter0703 回复于:2005-10-21 14:25:39

2004年年底的时候发现了这个问题,当时还研究了2个多小时才摆平。不过当时确实已经没有退路,因为设定的扩展区的最大数字已经到了,只能drop重来了。至于搂住所说的问题似乎还没有必要这么夸张,实际上可以通过sql来修改表的next size的,还没到极限的时候没有必要drop,毕竟还是有风险的。


 狡兔 回复于:2006-01-08 00:28:37

rename表再重建表是很麻烦的,要考虑原来表上的:
索引
触发器
约束
视图
同义词
授权
等等等


 tcm290 回复于:2006-10-26 21:34:46

楼主说的有些不对吧
只是将原表改名,如果不删除原表索引,再建新表时就会有同索引了,这样索引是建不上去的吧,
应该是先要删除原表索引,再建新表


 petex 回复于:2006-10-29 22:06:09

好帖,学习:P

希望各位高手多分享一下磁盘管理的知识。

谢谢!




原文链接:http://bbs.chinaunix.net/viewthread.php?tid=399722
转载请注明作者名及原文出处



收藏本页到: