|
|
随着银行业务的发展，其数据库也在飞速地增长。那么，有效地控制数据库大小，合理地组织表，就能够提高计算机运行效率，减少金融风险。
众所周知，数据库由表构成，实际运用中，表是动态变化的，并且有的表增长的很快。当一个表在dbspace中有大于8个交错区间时，就会影响其访问效率，随着交错区间的进一步增多，甚至会恶化成为访问数据库的瓶颈，经常出现系统颠簸现象。具体表现为运行响应时间减慢、备份时间延长，用onstat－giof命令、glance(UNIX)命令查看磁盘I/O常居高不下。
这里提供两个查看表分配情况的命令：oncheck－pe和oncheck－pc。前者产生dbspace的每个chunk中页面使用的详细清单；后者检查系统目录表的完整性，并对每个表的情况做汇总统计，包括创建时间、锁类别、区间总数、区间大小等。后者运行时间稍长。请仔细查看结果，特别是对那些经常做删除、插入、添加记录的表要注意，结果可能会让你大吃一惊。我曾经看到过一个表有460兆、67个区间，另一个430兆、57个区间，它们严重影响了系统的性能。对于小于兆级的表可不用理会。
通常，一个dbspace有多个chunk，用onstat－d可查看到。然而并非所有的chunk都得到合理分配，往往是有的chunk根本没用到(因为最初创建数据库时一般会分配充裕的空间)，有的chunk中却拥挤不堪、表严重交错。为了平衡I/O，提高访问效率，可以将增长较快的表放入单独的一个chunk中。但是很不幸，Informix－online却没有提供这样的命令。在此介绍个巧妙的方法，先来看看Createtable这个简单的命令，它后面可带extentsizeextent－size和nextsizenext－size两参数，前者指定创建表的初始区间大小，后者指定当初始区间充满后，扩展区间的大小，单位是KB。如下语句：
Create table test
(T1 char(10)
T2 char(20)
)
extent size 80000
next size 500
该语句建立表test的初始空间有80兆，如数据充满后每次再分配500K的空间。
lnformix中创建表时的空间分配策略是，先给表找一个连续的、足够大的空间。那么我们就可以利用这点，问题会很容易被解决。假设存在一个dbspace，它有两个chunk，第二个空闲。让我们来把一些增长较快的表放入第二个chunk中。第一步：备份数据库。第二步：删除增长较快的表中的无用记录，再把它unload出来。第三步：drop需要重建的表。第四步：用onstat－d查看chunk1中有多少个空闲页面，设为n个。第五步：创建一个表test，设置其extent－size稍小于n＊m，m为每页的大小，通常是2K、4K。第六步：用onstat－d查看chunk2是否仍旧空闲，即肯定上一步的test表创建在chunk1中，否则删除test表，分配一个更小的extent－size重建test表。第七步：创建你想要建的表设为Tb,请注意设定合理的extent－size值，它最好稍大于现在Tb表所占的总空间。此时Tb肯定是建在chunk2中了!因为Informix在chunk1中找不到合适的空间。最后记住删除test表。如果您的数据库只有一个chunk，那么第四、第五步不用做。这同样有助于减少表交错。
另外，创建此类表的索引时，在Createindex后可加上参数fillfactor10，它决定在建立索引时预留90％的空间，这对经常更新、增长速度快的表很有好处，它使得其索引在一定空间内连续存放，同样有助于提高访问效率。系统默认值是90。在创建表完成之后，load数据之前，最好关闭日志，这有助于缩短load数据的时间。
| bryanheqi 回复于：2004-02-10 15:35:35
| 不顶不行,
好兄弟
| | czw1413_cn 回复于：2004-02-10 19:17:04
| 楼主说的不错
但在实际的生产系统中很难考虑,我提个比较笼统的建议就是每个dbspaces少管理几个chunk,这样有可能在物理的I/O上处理的稍微好点
个人意见,仅做参考
| | doublesky 回复于：2004-02-11 13:23:46
| 在实际的生产系统中,你认为1个dbspaces管理多少个chunk为最佳？
:o
| | supermsh 回复于：2004-07-22 13:35:29
| 做一次dbimport不就行了嘛
| |
|
