INFORMIX数据库维护指南(一)

INFORMIX数据库维护指南

（一）

日常维护操作规程

目录

一保存好INFORMIX 的系统信息 (2)

二监控数据空间以及逻辑日志空间的使用情况 (3)

三数据的备份 (4)

四数据的卸出与装载 (5)

五 INFORMIX 性能的调整 (6)

六对用户的监控 (6)

七对IFNORMIX IDS 内存的监控 (10)

八对IFNORMIX IDS 锁的监控 (11)

九用于查询机数据同步的备份操作规程 (12)

十系统的监控方法的汇总 (13)

一保存好INFORMIX的系统信息

请保存好 INFORMIX 如下五类信息：

1．ONCONFIG 文件；

2．INFORMIX 用户的 .profile文件

3. INFORMIX 逻辑日志信息（可用 onstat –l 获得）

4．所有Dbspace 以及每个Dbspace 的所有 Chunk 的信息：

1）. 所有Dbspace 的名字；

2）. 每个Dbspace 的所有 Chunk 的 path,offset,size.

INFORMIX 极力推荐 Chunk 的 Path 使用 Link,这使得真正存放数据的设备或文

件具有重新定位的可能性。

在使用 Link 情况下，请保存每个 Link 所指向的设备或文件的信息。可用：

ls –l 列出各个 Link 所指向的设备或文件。

用” onstat –d > file “可在 file 中保存所有Dbspace 以及每个Dbspace 的所有 Chunk 的信息( size 是以 page 为单位，而建立 Chunk 时是以 K为单位)，但请

注意，在使用 Link 情况下，onstat –d 不含有每个 Link 所指向的设备或文件的信

息。

5．所有Database 以及所含的Table的信息。可使用 dbschema 获得该信息：

例：dbschema -d stores7 –ss

其中的–ss 指定把lock modes, and extent sizes 信息也包含进来；

如上信息为INFORMIX 系统的恢复提供了条件。下面例举三种典型情况：

典型情况 1 ：

存放某个 dbspace 的设备或文件坏掉了。这时候只要将该 dbspace 的 Path 重新

Link 到好的设备或文件上，然后用 ontape 把数据及逻辑日志备份恢复上去就可以

了。如果Chunk 的 Path 用的是设备或文件处理起来就复杂的多。

典型情况 2:

INFORMIX 的运行代码坏掉了但数据完好无损。这时的处理步骤为：

1). 从新安装 INFORMIX IDS ;

2). 把保存的INFORMIX 用户的 .profile文件 copy 到informix user home 下，

把保存的ONCONFIG 文件copy 到 $INFORMIXDIR/etc 下，并把环境变量

ONCONFIG 指向该 ONCONFIG 文件；

3). 重新启动 IDS 即可 ( 注意：在启动 IDS 时,如果使用 oninit 千万不能加

-iy 参数，这样一来反而会破坏原来完好的数据）。

典型情况 3 ：

INFORMIX 的运行代码和数据都坏掉了。这时的处理步骤为：

1). 从新安装 INFORMIX IDS ;

2). 把保存的INFORMIX 用户的 .profile文件 copy 到 informix user home 下，

把保存的ONCONFIG 文件copy 到 $INFORMIXDIR/etc 下，并把环境变量

ONCONFIG 指向该 ONCONFIG 文件；

这里要注意 LOGFILES，LOGSIZE 这俩个参数，要改小到 rootdbs 能放下

所有指定的逻辑日志;

3). 根据保存的所有Dbspace 以及每个Dbspace 的所有 Chunk 的信息重建

除 rootdbs 以外的所有Dbspace（rootdbs 的信息含在 ONCONFIG 文件中）.

这里要注意在重建Dbspace 时，每一个Dbspace和每一个Chunk要严格按照原来 onstat –d 的信息标出的顺序来建(onstat –d 信息中的Dbspace 的

“number“ 与 Chunk 的“chk/dbs”)：

4). 根据保存的INFORMIX 逻辑日志信息重建逻辑日志；

5). 用 ontape 把数据及逻辑日志备份恢复上去。

二监控数据空间以及逻辑日志空间的使用情况

用” onstat –d”来监控数据空间的使用情况。主要是查看有没有足够的空间以适于数据插入的需求，如下图所示：

如果空间不足，则需要加 Chunk (加 Chunk 的命令在下面叙述)。

用 onstat –l来监控逻辑日志的使用情况。如下图所示：

当标有“U”（但后不跟“B”）和标有“C”的 log 的个数多于50%时，请备份逻辑日

志。

三数据的备份

请经常备份数据。建议每天做一次零级备份。在每次系统做过调整后尤其是做过重大调整后，做一次零级备份。

监控逻辑日志的使用情况，根据其使用情况，及时做备份。

数据的备份可用两种方法：

1.ontape

2.dbexport

这两种方法的区别是

1). ontape 产生的是二进制流的数据，只能用于本系统的恢复或是二进制兼容的系统上的

恢复；dbexport 产生的是 ASCII 数据，可以用于非二进制兼容的系统上的恢复；

2).ontape 含有IDS 的系统信息，而 dbexport 不含有IDS 的系统信息，只含有数据库,表

及数据信息;

3).在数据量较大的情况下，ontape 比 dbimport 恢复较快；

4).dbexport 出来的文件的大小受到 OS 文件的大小的限制。32位的情况下，不能大于

2G。

1 ontape -s : 对数据的备份

按提示输入本次备份的级数(0级， 1级，2级)

0 级备份是整个ONLINE的备份

1 级备份是在0级基础上所有修改部分的内容的备份

2 级备份是在0级或1级的基础上所有修改部分的内容的备份

2 ontape -a : 对逻辑日志的备份 (自动方式)

ontape -c : 对逻辑日志的备份 ((连续方式)

3 ontape -r : 对备份的恢复

按提示依次恢复数据备份(0级，1级，2级)和逻辑日志备份

四数据的卸出与装载

1 卸出

dbexport 用于将整个数据库卸出至一个 ascii 文件

dbexport -t device -b blocksize -s tapesize database

-o directory

onunload 用于将数据库以二进制格式卸出至磁带

onunload -t device -b blocksize -s tapesize database

2 装载

dbimport 用于将一 ascii 文件装入一个数据库

dbimport -t device -b blocksize -s tapesize database -i directory

dbload 用于将一个或多个 ascii 文件装入一个或多个已存在的表

dbload -d database -c commandfile

onload 用于装载以onunload命令卸出的数据

onload database -t device -b blocksize -s tapesize

* dbexport 的一个常见错误的处理方法：

如果表中的数据含有非法字符，当 dbexport 在卸出该表时会往往断掉或挂起，可用如下方法处理：

1）用“dbschema -d 数据库名 -t 表名”卸出该表的定义；

2）用上面卸出该表的定义创建一个新表；

3）确认该新表与原表完全一致（包括 index, trigger, lockmode 等等）

4）用

“INSERT INTO 新表名 SELECT * FROM 原表名“

把数据倒到新表中；

5）确认该新表数据的与原表的数据完全一致；

6）DROP 原表；

7）RENAME TABLE新表名TO原表名;

8）再启动 dbexport。

五 INFORMIX 性能的调整

INFORMIX 的性能基本取决于应用程序的结构（作用70%）以及 INFORMIX IDS 的参数设置（作用30%）。在日常维护中请注意一下三点：

1．经常Updating Statistics:

UPDATE STATISTICS [LOW|MEDIUM|HIGH]

建议使用参数“hinh”,这会使查询效率大大提高。上面的语句是针对整个

Database 的，在数据量大时，做的时间较长。

另外的一个选择是针对重点的 Table 做UPDATE STATISTICS: UPDATE STATISTICS [LOW|MEDIUM|HIGH]

FOR TABLE [tabnam e];

2．在 INFORMIX IDS online 一段时间后，请 offline 然后再 online 一次。

这样一来可回收吊死的死进程所占用的内存，使得IDS 的性能提高。

3．对于经常做为查询条件的列，如果其上没有 Index,请为其建 Index。

六对用户的监控

1.使用 onstat –u 来查看用户线程的大致情况，其中包括系统设定的用户数，当前的

用户数和本次 IDS online 以来曾经达到的最多的用户数。

2．使用 onstat –g ses 查看用户线程的情况,如下图所示：

session id The session id of the session. This id is used in other

onstat options.

login The login name of the client application process.

tty The tty of the client application process.

pid The process id of the client application process. hostname The host name of the machine running the client

application process.

#RSAM threads The number of threads associated with the session.

Normally, only one thread is allocated per session, unless

a sort or index build is occurring.

total memory Memory allocated within server shared memory for the

session.

used memory Memory used within server shared memory for the

session.

3．使用 onstat –g ses session_id 查看某个用户线程的情况,如下图所示：

tid The thread id

name The thread name

rstcb The address of the rsam task control block for the thread. Flags Status information for the thread.

Position 1

S Waiting on a mutex

Y Waiting on a condition

L Waiting on a lock

B Waiting on a buffer

C Waiting on a checkpoint

X Long transaction cleanup

G Waiting on the log buffer write

T Waiting on a transaction

Position 2

* Transaction active while I/O failure occurred (related to

archive activities)

Position 3

A Archiving

B Begin work has been logged

P Coordinator or Subordinate prepared (distributed

transactions)

X XA prepared

C Committing

R Rolling back or rolled back

H Heuristically aborting

P osition 4

P Primary thread for a session

Position 5

R In read rsam call

X Process in critical section

Position 7

M Special monitor

D Special daemon thread

C Cleanup thread

F Special buffer flusher thread (page cleaner)

B Special btree cleaner thread

curstk Size of the stack for this thread.

status Current status of this thread.

Name, Free, Used The information in these columns are a breakdown of the

exact usage of the pools listed for the session.

Session Id The session id of the user executing the SQL statement.

You can find the user name by executing the onstat -g ses

command and finding the corresponding session id.

Stmt type The statement type such as SELECT, UPDATE,

DELETE, INSERT.

Current Database The name of the current database for the session. Isolation level The current isolation level (CR = committed read,

RR = repeatable read, CS = cursor stability,

DR = dirty read, NL = no logging).

Lock mode The current lock mode (Either Not Wait or Wait x, where

x = number of seconds to wait).

SQL ERR The last SQL error.

ISAM ERR The last ISAM error.

F.E. Vers The Informix version of the client application process.

4. 可用onmode -z sess-id 来杀掉某个用户线程。

七对IFNORMIX IDS 内存的监控

INFORMIX IDS 的内存分成下图的三部分：

1．使用 onstat –g seg 来查看这三大部分的状态：

onstat -g seg

Segment Summary:

(resident segments are not locked)

id key addr size ovhd class blkused blkfree

32 1381451777 800000 987136 372 R 117 4

33 1381451778 8f1000 4096000 252 V 333 167

34 1381451779 cd9000 1048576 204 M 106 22

其中的 Message Portion 是用于 Client 进程与 Server 的连接选用 Share Memory

方式时的通讯区,系统自己控制。

Resident Portion是Server 用于存放数据和锁的区域。它的大小取决于BUFFERS 和

LOCKS 这俩个参数大小的设置，在物理内存的 60 – 70 % 的上限之下原则上越大越

好。

这里重点要监控是 Virtual Portion ,既上面的 V 段。V 段是 Client 线程所占用的

的内存，它的大小完全取决于当前连接上来的应用的个数和类型。

由于受到 OS 参数的限制，V段的个数不能过多，V当段的个数过多时，请调大

SHMVIRTSIZE 和SHMADD 这两个参数。

2．用 onstat –g mem 来查看各个线程，进程的内存使用情况：

请重点注意那些“name”为数字且“totalsize”很大的用户线程，用

onstat –g ses session号

（这里session号既是 onstat –g mem 中的“name”）来查看该线程正在做什么。

3．用onmode –F 回收不用的内存。

八对IFNORMIX IDS 锁的监控

可用onstat –k 来监控锁的使用状态。

INFORMIXIDS 的 LOCK 是根据用户的线程的需要自动加载和解除的。在日常的维护中对 LOCK 产生关注往往是由于某个表被某个用户的线程锁住而别用户的线程不能存取该表。这时可用onstat –u 与 onstat –k 来查出谁锁住了该表。

例 :

这个例子是说用户 joeg 的程序由于在等待（wait）要存取的表老是被锁在那走不下去了，那么是谁锁了这个表呢？通过上面按箭头的查找发现是 lizg 的程序锁了该表，也许是 lizg

做 Update 做了一半既没有 commit 也没有 rollback 就去喝茶啦。这时可用

onstat –g ses 23 来看看 lizg 到底在干什么，通知 lizg 下来就行了。

九用于查询机数据同步的备份操作规程

备份要求：每日

备份方法：dbshema+shell(unload)

dbschema -d 数据库名 > db.sql --------- 把数据库中的所有表的定义放到 db.sql 文件中；

unload to 文件名 select * from 表名 ---- 把表中的数据倒到文件中；

( unload 的 shell 范例请见后面的附件)

查询机上的数据恢复要求：每日

查询机上的数据恢复方法：dbshema+shell(load)

dbaccess 数据库名db.sql ------ 在数据库中生成在上步中所倒出的所有表的定义；

load from 文件名insert into表名 ----- 把文件中的数据倒到表中

( load 的 shell 范例请见后面的附件)

十系统的监控方法的汇总

1．总体（GENERAL）性能监测

命令：onstat –p

说明：输出中的两个%cache，第一个是读的命中率，第二个是写的命中率，这两个值应分别在90%，80%以上，ovlock、 ovuserthread、ovbuff这三项一定要是0，否则相关的资源不够。

* 注：如果数据库都是 UNBUFFER 的，则上述的两个%cache 的值低不一定是性能低。

2. onstat –m

此命令报告数据库执行中的日志情况，要经常使用此命令观测数据库有无出错信息，并注意检查点的执行时间，如果执行时间持续在10秒以上，则需要进行相应的调整以减少检查点持续的时间。

3. onstat –D

观测数据库各dbspace的读写情况，对于使用磁盘阵列（采用RAID1+0或RAID5）的用户，此命令没有什么影响，但对于使用多个硬盘来配置数据库的用户来说，此项非常重要，根据此项的输出，调整各dbspace在硬盘上的分布，以求各硬盘的I/O大致相等，从而使的系统的I/O性能最优化。

4.检查数据的完整性

Check reserve pages ------------- oncheck -cr

Check extents ------------------- oncheck -ce

Check system catalog tables ----- oncheck -cc database_name

Check data ---------------------- oncheck -cD database_name

Check indexes ------------------- oncheck -cI database_name

5．查看系统状态

onstat - 查看当前ONLINE 状态

-l 查看日志状态

-u 查看用户线索

-m 查看 message log

-p 查看 profile

-z 清空 profile

-d 查看 DBspaces 和 Chunk

-F 查看磁盘的读写方式

-r n 每隔n秒重复一次查看操作

-g ath 查看所有的线索

-g glo 查看多线索的全局信息

-g seg 查看内存 segment 状态

-g mgm 查看内存管理信息

-g ioq 查看磁盘 I/O 队列

-g ses 查看 session 信息

-g sql 查看 sql 信息

6．修改系统参数

onmonitor -->Parameters

请注意使用初始化选项 initialize !

7 日志管理

日志管理中应常用 onmonitor --> Status 或 onstat -l 查看逻辑日志状态及时做逻辑日志备份

$onparams -a -d DBspace 增加一个逻辑日志

-d -l Logid 删除一个逻辑日志

-p -s size -d DBspace 修改物理日志的大小和位置

8 改变当前的ONLINE

$ onmode -ky : on-line --> off-line

$ oninit : off-line --> on-line

$ oninit -s : off-line --> quiescent

$ onmode -m : quiescent --> on-line

$ onmode -u : on-line --> quiescent, immediately shutdown -s : on-line --> quiescent, graceful shutdown

$ onmode -k : on-line --> quiescent

9 增加 dbspace 和 chunk :

以 informix 用户注册，执行onmonitor

--> Dbspace --> Create ( 增加 dbspace )

--> Dbspace --> Add_chunk (增加 chunk )

10 设置磁带机设备

onmonitor --> Archive 对其中的：

Tape Dev ------------ 指定磁带机设备名

Block Size --------- 指定磁带的块的尺寸

Total Tape Size ----- 指定磁带的总的容量

附件– unload 和load 的 shell 范例

un load 的 shell 范例 :

dbaccess datacenter - << EOF >>/tmp/datacenter.log 2>&1

!echo "unload database datacenter"

set isolation dirty read;

!echo "unload table charge"

unload to /u1/backup/datacenter/charge.txt select * from charge;

!echo "unload table vehinsu"

unload to /u1/backup/datacenter/vehinsu.txt select * from vehinsu;

!echo "unload table discount"

unload to /u1/backup/datacenter/discount.txt select * from discount;

!echo "unload table chargedeal"

unload to /u1/backup/datacenter/chargedeal.txt select * from chargedeal; !echo "unload table regcase"

unload to /u1/backup/datacenter/regcase.txt select * from regcase;

!

load 的 shell 范例 :

dbaccess hhold2000 - <

load from /u/ccx99/tmp/restore/hhold2000/policy_f.txt insert into policy_f;

load from /u/ccx99/tmp/restore/hhold2000/fhqd.txt insert into fhqd;

load from /u/ccx99/tmp/restore/hhold2000/individ.txt insert into individ;

load from /u/ccx99/tmp/restore/hhold2000/khjbr.txt insert into khjbr;

load from /u/ccx99/tmp/restore/hhold2000/p_list.txt insert into p_list;

load from /u/ccx99/tmp/restore/hhold2000/t_list.txt insert into t_list;

load from /u/ccx99/tmp/restore/hhold2000/g_plan.txt insert into g_plan;

load from /u/ccx99/tmp/restore/hhold2000/g_prem.txt insert into g_prem;

load from /u/ccx99/tmp/restore/hhold2000/indor_p.txt insert into indor_p;

!