Informix技术知识库

收集整理来自于IBM Informix的技术知识库(http://www-900.ibm.com/cn/support/

1. 通过onstat -k信息发现锁的级别

在IBM Informix数据库维护时,有时知道上了锁,但并不知道锁的级别即是锁了整个表?还是锁了相关的页,还是某一行?下面的例子将解答这个问题。注释:tblsnum 0x100002 是数据库database tablespace,是informix数据库的内部结构,在onstat -k输出中可以忽略相关内容:

Locksaddress wtlist owner lklist type tblsnum rowid key#/bsiz
4409ad50 0 44d5bac0 0 S 00002 303 0
4409ada8 0 44d5bac0 4409ad50 HDR+IX 1003ba 0 0
4409ae00 0 44d5bac0 4409afb8 HDR+X 1003bb 101 K- 1
4409ae58 0 44d5bac0 4409ae00 HDR+X 1003bb 201 K- 1
4409aeb0 0 44d5bac0 4409ae58 HDR+X 1003bc 101 K- 1
4409af08 0 44d5bac0 4409aeb0 HDR+X 1003bc 201 K- 1
4409af60 0 44d5bac0 4409ada8 HDR+X 1003ba 101 0
4409afb8 0 44d5bac0 4409af60 HDR+X 1003ba 201 0
440b0510 0 44d5a878 0 HDR+S 100002 303 0
440b0568 0 44d5a878 440b0510 HDR+IX 1003b8 0 0
440b05c0 0 44d5a878 440b0568 HDR+X 1003b8 300 0
440b0720 0 44d5c0d8 0 S 100002 303 0
440b0778 0 44d5c0d8 440b0720 HDR+X 1003c2 0 0

1、绿色的字显示的是在表0x1003c2上的表级别锁
2、蓝色字显示的是在表0x1003b8第三个页(0x3)的页级锁
3、红色的字显示在表0x1003ba,第二页(0x2)第一个槽的行级锁
4、紫色的字显示的是在表0x1003bb,第一页第一个槽,第二页第一个槽索引(K- 1)上的锁

如果想要知道是哪一个索引引起了锁,可以通过oncheck -pT <0xtblsnum> 查找
$oncheck -pT 0x1003bb | grep “Index Usage Report”
Index Usage Report for index 101_3 on stores_demo:informix.orders
Index Usage Report for index 101_70 on stores_demo:informix.orders

2. 如何通过逻辑日志监控Informix数据库操作?

如何通过逻辑日志监控Informix数据库操作?

有时在没有数据库审计的情况下,也需要对数据库的某些操作进行监控或审计,此时一般只能通过对逻辑日志的分析来实现,下面我们将举一个通过逻辑日志监控alter table的例子假设怀疑数据库“stores7”中的表“state”,在2003年9月29日16:00到18:00被恶意的修改了,我们需要查出谁在什么时间发起了这个alter操作。

1、在online.log 中,通过CKPT完成的时间来确认相关的“logical logs”

Mon Sep 29 17:20:06 2003
17:20:38 Checkpoint loguniq 287, logpos 0xd2018
17:23:34 Checkpoint loguniq 287, logpos 0xd5018
17:26:22 Logical Log 287 Complete.
17:26:26 Checkpoint loguniq 288, logpos 0x18
17:47:05 Checkpoint loguniq 288, logpos 0x1018
17:52:06 Checkpoint loguniq 288, logpos 0x2018
通过上边的日志信息,我们可以猜测修改操作大概发生在逻辑日志 287 或 288。

2、确认这些被选中的逻辑日志的状态和位置

(有没有被备份,在磁带中还是在磁盘上),通过onstat -l我们发现逻辑日志287和288还没有被备份,依然在磁盘上
flags uniqid
U—— 287
U—C-L 288

3、找到state表的partnum

$ dbaccess stores7 –
Database selected.
> select hex(partnum) from systables where tabname=’state’;
(expression)
0x001001FC
1 row(s) retrieved.

4、查找相关操作记录

4.1、使用onlog命令找出关于表state在相应时间段的所有记录

$ onlog -n 287 -l -t 0x001001FC > onlog-287.out
$ onlog -n 288 -l -t 0x001001FC > onlog-288.out

4.2、在相应的记录输出中,查找相应的ALTER关键字

$ grep ALT onlog288.out

308c 52 PTALTER 04 0 3040 1001fc 0 1130 1131 1 1 -20

4.3、分析整个记录确认所需事物信息

addr len type xid id link
308c 52 PTALTER 104 0 3040 1001fc 0 1130 1131 1 1 -20
34000000 00005d00 10000000 68000000 4…..]. ….h…
40300000 e3858800 00000000 fc011000 @0…… ……..
01000100 00000000 6a040000 6b040000 …….. j…k…
ecff0000 ….

Transaction id: xid = 104

5、使用onlog和BEGIN关键字得到关于事物104的详细信息

onlog -n 288 -l -x 104 > onlog288-104.out

log number: 288.

addr len type xid id link
3018 40 BEGIN 104 288 0 09/29/2003 17:55:26 13 Administrator
28000000 20010100 00000000 68000000 (… … ….h…
00000000 e1858800 00000000 4eaa783f …….. ….N.x?
06000000 0d000000 ……..

逻辑日志的记录我们可以看出”Administrator”用户,在09/29/2003 17:55:26发起了相应的alter table操作

 

3. 如何监控、维护Informix数据库空间?

本文对如何监控、维护Informix数据库空间的方法及注意事项作了一个简单的小结,以方便广大Informix DBA在日常工作中处理Informix数据库空间的问题。

1、如何监控Informix数据库空间的异常离线?

1.1、在相关的chunk进行I/O操作时如果相应的Chunk有问题,数据库会报相应的I/O错误,并将CHUNK置为“PD”;另外当数据库启动或是进行数据库备份时,Informix数据库会对所有空间进行例行的健康检查“sanity check”, 如果相应的chunk有错误,Informix数据Informix online.log中输出如下的错误信息:

08:39:58 IBM Informix Dynamic Server Version 9.40.FC4
08:39:58 Who: Session(1, informix@HBDB84_1, 0, c000000000b63028)
Thread(15, main_loop(), c000000000b21028, 3)
File: rspartn.c Line: 7747
08:39:58 Results: Chunk 117 is being taken OFFLINE.
08:39:58 Action: Restore chunk from archive.
08:39:58 stack trace for pid 9747 written to /tmp/af.3f7f15e
08:39:58 See Also: /tmp/af.3f7f15e
08:39:59 chunk failed sanity check
08:39:59 I/O error, Primary Chunk ‘/opt/informix/chunks/npmhis2008
_data/npmdb_npmchk_07′ — Offline (sanity)

1.2、“Oncheck –pr ” 输出
当数据库停止后,数据库的所有状态信息都会写到相应的Informix保留页中,此时离线状态下运行oncheck -pr可以准确的看到相关已经被置为”offline”的信息
“oncheck -pr |grep offline” 的输出:

Chunk number 73
Flags 0x10020 Chunk is offline
Chunk path /opt/informix/chknew/npm/hpmchk1_b
Chunk offset 5 (p)
Chunk size 10000000 (p)
Number of free pages 6723197
DBspace number 38

1.3、“Onstat –d ” 输出
当Chunk 离线后,“onstat -d”输出的”free”栏中的值通常是0,有时会被误认为是空间满而导致不可用了,其实是chunk异常PD后导致。

“onstat -d |grep PD” 的输出:
Chunks
address chunk/dbs offset size free bpages flags pathname
c00000020a8434f0 73 38 5 10000000 0 PD-B /opt/informix/chknew/npm/hpmchk1_b

1.4、相应的堆栈函数中我们可以看到“sane_chopen”,“afwarn_interface ”函数,表示对chunk进行sanity check,发现了错误

相应的堆栈输出:
( 0) legacy_hp_afstack
( 1) afstack
( 2) afhandler
( 3) afwarn_interface
( 4) sane_chopen
( 5) chopen_util
( 6) chopen
( 7) rscon
( 8) aud_iscon
( 9) chgstat
(10) onspace
(11) startup
(12) resume

2、如何检查确认空间离线的原因?

Chunk/Dbspace离线的原因多种多样,在数据库DBA寻找Informix 技术支持工程之前,应该排除诸如:物理磁盘设备损坏、硬件设备状态异常、操作系统异常导致的Informix 空间异常的情况。

2.1、检查相应的硬件日志、操作系统日志看是否有磁盘或硬件报错的信息;
2.2、对相应的磁盘物理设备进行硬件级检查,排除磁盘物理损坏的可能;
2.3、使用操作系统命令对相应的磁盘设备进行I/O读取检查

例如:dd if=/opt/informix/chknew/npm/hpmchk1_b of=/dev/null count=20000

2.4、检查相应物理磁盘设备的属组是否为”informix:informix 660“

例如:ls -lt /opt/informix/chknew/npm/hpmchk1_b

通过上述步骤的逐一排查,将会定位空间离线的原因,根据不同的原因我们将采取不同的方法进行修复

3、如何解决、修复空间离线问题

3.1、如果是磁盘物理损坏导致了数据丢失或损坏,最终导致的Informix数据库空间异常离线,需通过磁盘修复和数据库恢复进行修复或是强行将坏掉的空间从数据库删除修复;

3.2、如果是LV切换或是LV状态异常导致的Informix数据库空间离线,而磁盘硬件未有任何的损坏,则DBA可以通过如下命令自行修复离线的空间;

例如:onspaces -s <spacename> -p <path> -o <offset> -O -y

3.3、如果是相关的属组权限的问题,修改为正确的属组和权限(客户在进行相应的磁盘维护和划分时,有时会改变 相应磁盘空间的属组和权限导致Informix数据库的离线);

例如:
chown informix:informix /opt/informix/chknew/npm/hpmchk1_b
chmod 660 /opt/informix/chknew/npm/hpmchk1_b

3.4、如果磁盘修复后,数据并未损坏,DD操作也没有报错,备份恢复时间过长,此时可以考虑需求Informix技术支持使用内部工具尝试修复,但前提是内部工具存在风险
,客户一定要有备份,以备不时之需;

4、删除废弃空间的方法

Informix 空间(Chunk/Dbspace)里边存放着客户重要的生产数据和索引,非到万不得已,不建议进行空间删除操作,关键的数据库空间例如“rootdbspace”、“physical log dbspace” 和“logical log dbspace” 不能删除。进行删除操作前最好做好相关的备份,以便需要时进行恢复。

4.1、Informix不允许删除非空的数据库空间,所谓的非空并不是指什么信息都没有,而是指除了系统所需的53页外不允许有其他的页被使用,如果数据库空间(rootdbspace除外)仅有53页被使用,则认为是“空”可以通过“onspaces -d”删除;

例如:
/home/informix/940:oncheck -pe testdbs
DBspace Usage Report: testdbs Owner: informix Created: 10/13/2009
Chunk Pathname Size Used Free
2 ./dsk/gydbs 1000 53 947

Description Offset Size
————————————————————- ——– ——–
RESERVED PAGES 0 2
CHUNK FREELIST PAGE 2 1
testdbs:’informix’.TBLSpace 3 50
FREE 53 947
Total Used: 53
Total Free: 947

4.2、临时表空间可以直接通过“onspaces -d”删除;

4. 过分使用PDQ功能将给数据库的性能带来不利影响 
问题:
当有大量数据操作同时出现时,数据库服务器的性能急剧下降

现象:
所有数据操作的执行时间变得越来越长

原因:
对PDQ功能的不正确使用

问题分析:
发现大量会话使用PDQ功能,并堆积在PDQ队列中
onstat -g mgm

IBM Informix Dynamic Server Version 11.50.FC4 — On-Line — Up 18:04:23 — 16821136 Kbytes

Memory Grant Manager (MGM)
————————–

MAX_PDQPRIORITY: 50
DS_MAX_QUERIES: 32000
DS_MAX_SCANS: 1048576
DS_NONPDQ_QUERY_MEM: 1024 KB
DS_TOTAL_MEMORY: 4096000 KB

Queries: Active Ready Maximum
205 42 32000

Memory: Total Free Quantum
(KB) 4096000 0 128

Scans: Total Free Quantum
1048576 1048374 1

Load Control: (Memory) (Scans) (Priority) (Max Queries) (Reinit)
Gate 1 Gate 2 Gate 3 Gate 4 Gate 5
(Queue Length) 1 0 41 0 0

Active Queries:
—————
Session Query Priority Thread Memory Scans Gate
22 700000228709438 25 700000227c24028 0/0 1/1 –
42 70000022804fbf8 25 700000227ff5970 0/0 1/1 –
43 700000228a9fbf8 25 7000002280a7a30 0/0 1/1 –
44 700000228b53bf8 25 700000228b09028 0/0 1/1 –
45 700000228c08bf8 25 700000228bbd028 0/0 1/1 –
46 700000228cbcbf8 25 700000228c60310 0/0 1/1 –
47 700000228d70bf8 25 700000228d145b0 0/0 1/1 –
48 700000228e24bf8 25 700000228dc8850 0/0 1/1 –
49 700000228ed8bf8 25 700000228e7cb38 0/0 1/1 –
50 700000228f8cbf8 25 700000228eebd70 0/0 1/1 –
51 700000229041bf8 25 700000228ff6028 0/0 1/1 –
52 7000002290f5bf8 25 700000229099280 0/0 1/1 –
53 7000002291a9bf8 25 700000229151610 0/0 1/1 –
54 700000229205bf8 25 7000002291bb028 0/0 1/1 –
55 70000022930dbf8 25 70000022926f028 0/0 1/1 –
57 700000229422bf8 25 7000002293c6280 0/0 1/1 –
58 7000002294d6bf8 25 70000022947a460 0/0 1/1 –
59 70000022958abf8 25 70000022952e658 0/0 1/1 –
60 70000022963ebf8 25 7000002295e2850 0/0 1/1 –
……

解决问题:
1、将PDQPRIORITY设置在较低水平,特别是在联机事务处理环境中
2、如果无法对应用进行修改,我们可以通过将onconfig中的配置参数MAX_PDQPRIORITY设置为0来关闭PDQ功能,或使用onmode -D 0在线关闭该功能

5.  如何重整数据库表空间使之运行效率更高 
问题:
如果数据库表拥有过多的extent,将会带来以下问题:
1、影响访问该表的效率。当数据存储过于分散时,数据的访问使用将是低效的。
2、达到数据存储的上限,导致数据将不能被插入到数据库表中。

因此,我们在以下情况下需要该功能:
1、重整那些拥有过多extent的数据库表,并释放部分空间
2、从一个大表中删除大部分数据
3、改变一个大表的结构

答案:
1、在IDS 7.31中您可以使用oncheck -me来实现
2、在IDS 9.x 或 IDS 10.x,您可以通过:
2.1 创建一个与源表同结构的raw表
2.2 使用”insert into … select * from …”语句来传输数据
2.3 改变表的模式为正常模式,重命名或删除原表,然后将新表更名为原表名
2.4 重新创建所需的索引或约束
例如,我们需重构customer表,该表拥有一个索引和一个主键:

create raw table customer_new  
(  
customer_num serial not null ,  
fname char(15),  
lname char(15),  
company char(20),  
address1 char(20),  
address2 char(20),  
city char(15),  
state char(2),  
zipcode char(5),  
phone char(18)  
) extent size 16 next size 16 lock mode page;  
 
insert into customer_new select * from customer;  
 
alter table customer_new type (standard);  
 
drop table customer;  
 
rename table customer_new to customer;  
 
set pdqpriority high;  
alter table customer add constraint primary key (customer_num) constraint pk_customer;  
create index zip_ix on customer (zipcode) ; 

3、在IDS 11.5上我们可以利用repack和shrink命令来重构表
例如,我们需对表customer_new进行重构,并释放空间
3.1 重构前
# oncheck -pt stores:customer_new

TBLspace Report for stores:informix.customer_new

Physical Address 2:536
Creation date 11/11/2009 12:11:21
TBLspace Flags 801 Page Locking
TBLspace use 4 bit bit-maps
Maximum row size 134
Number of special columns 0
Number of keys 0
Number of extents 40
Current serial value 962567
Current SERIAL8 value 1
Current BIGSERIAL value 1
Current REFID value 1
Pagesize (k) 2
First extent size 8
Next extent size 32
Number of pages allocated 3776
Number of pages used 3761
Number of data pages 3760
Number of rows 52632
Partition partnum 2097237
Partition lockid 2097237

Extents
Logical Page Physical Page Size Physical Pages
0 2:1438 8 8
8 2:1454 152 152
160 2:1610 40 40
200 2:1654 48 48
248 2:1706 40 40
288 2:1750 48 48
336 2:1802 40 40
376 2:1846 48 48
424 2:1898 40 40
464 2:1942 48 48
512 2:1994 40 40
552 2:2038 48 48
600 2:2090 40 40
640 2:2134 48 48
688 2:2190 88 88
776 2:2286 88 88
864 2:2382 96 96
960 2:2486 80 80
1040 2:2574 96 96
1136 2:2678 80 80
1216 2:2766 96 96
1312 2:2870 80 80
1392 2:2958 96 96
1488 2:3062 80 80
1568 2:3150 96 96
1664 2:3254 80 80
1744 2:3342 64 64
1808 2:3414 96 96
1904 2:3518 80 80
1984 2:3606 96 96
2080 2:3718 176 176
2256 2:3910 176 176
2432 2:4102 192 192
2624 2:4310 160 160
2784 2:4486 160 160
2944 2:4662 192 192
3136 2:4870 160 160
3296 2:5046 192 192
3488 2:5254 160 160
3648 2:5430 128 128
该表共分配3776个数据页,拥有52632条记录

3.2 删除部分数据
dbaccess stores <<!
delete from customer_new where customer_num > 1000;
!

Database selected.

52590 row(s) deleted.

Database closed.

oncheck -pt stores:customer_new

TBLspace Report for stores:informix.customer_new

Physical Address 2:536
Creation date 11/11/2009 12:11:21
TBLspace Flags 801 Page Locking
TBLspace use 4 bit bit-maps
Maximum row size 134
Number of special columns 0
Number of keys 0
Number of extents 40
Current serial value 962567
Current SERIAL8 value 1
Current BIGSERIAL value 1
Current REFID value 1
Pagesize (k) 2
First extent size 8
Next extent size 32
Number of pages allocated 3776
Number of pages used 3761
Number of data pages 3
Number of rows 42
Partition partnum 2097237
Partition lockid 2097237

Extents
Logical Page Physical Page Size Physical Pages
0 2:1438 8 8
8 2:1454 152 152
160 2:1610 40 40
200 2:1654 48 48
248 2:1706 40 40
288 2:1750 48 48
336 2:1802 40 40
376 2:1846 48 48
424 2:1898 40 40
464 2:1942 48 48
512 2:1994 40 40
552 2:2038 48 48
600 2:2090 40 40
640 2:2134 48 48
688 2:2190 88 88
776 2:2286 88 88
864 2:2382 96 96
960 2:2486 80 80
1040 2:2574 96 96
1136 2:2678 80 80
1216 2:2766 96 96
1312 2:2870 80 80
1392 2:2958 96 96
1488 2:3062 80 80
1568 2:3150 96 96
1664 2:3254 80 80
1744 2:3342 64 64
1808 2:3414 96 96
1904 2:3518 80 80
1984 2:3606 96 96
2080 2:3718 176 176
2256 2:3910 176 176
2432 2:4102 192 192
2624 2:4310 160 160
2784 2:4486 160 160
2944 2:4662 192 192
3136 2:4870 160 160
3296 2:5046 192 192
3488 2:5254 160 160
3648 2:5430 128 128
我们可以看到,虽然数据已经被删除,但其占据的空间并没有被释放

3.3 使用Repack 和 Shrink命令
dbaccess sysadmin <<!
> execute function task(“table repack shrink”, “customer_new”, “stores”);
> !

Database selected.

(expression) Succeeded: table repack shrink stores:informix.customer_new

1 row(s) retrieved.

Database closed.

3.4 再检查
oncheck -pt stores:customer_new

TBLspace Report for stores:informix.customer_new

Physical Address 2:536
Creation date 11/11/2009 12:11:21
TBLspace Flags 801 Page Locking
TBLspace use 4 bit bit-maps
Maximum row size 134
Number of special columns 0
Number of keys 0
Number of extents 1
Current serial value 962567
Current SERIAL8 value 1
Current BIGSERIAL value 1
Current REFID value 1
Pagesize (k) 2
First extent size 8
Next extent size 32
Number of pages allocated 8
Number of pages used 8
Number of data pages 3
Number of rows 42
Partition partnum 2097237
Partition lockid 2097237

Extents
Logical Page Physical Page Size Physical Pages
0 2:1438 8 8
这时我们可以发现,已经删除数据的空间被释放出来了,表的extent个数也降下来了。

6. 如何使用oncheck重整表空间

问题:
在IDS 7.31.xD1或其以上的其他IDS 7.31版本可以使用oncheck -me来重整表空间

答案:
从IDS 7.31.xD1开始oncheck引入了一个新功能。它可以使你的数据库表减少extent的个数。

设置环境变量RASHELP:
在启动数据库之前设置环境变量RASHELP为1
例如:
使用 ksh 或 bash:
export RASHELP=1
oninit
使用 csh:
setenv RASHELP 1
oninit

查看oncheck的新使用方法:
oncheck —

ONCHECK
Usage: oncheck {-cCheckOption | -pPrintOption | -mMergeOption}
[-y | -n] [-q]
[ { database[:[owner.]table[,fragdbs|#index]] | TBLspace number
| Chunk number }
{ rowid | page number | target number of extents } ]

oncheck —

ONCHECK
Usage: oncheck {-cCheckOption | -pPrintOption | -mMergeOption}
[-y | -n] [-q]
[ { database[:[owner.]table[,fragdbs|#index]] | TBLspace number
| Chunk number }
{ rowid | page number | target number of extents } ]

获得partnum:
1)执行命令oncheck -pt database:tablename
2)查找数据值Partition partnum
例如:
oncheck -pt stores:customer

Partition partnum 2097183


1)从相关数据库中查询系统表获得:
例如:
select tabname, partnum from systables where tabname=”customer”
tabname partnum

customer 2097183

如何使用oncheck重整数据表:
例如:
我们发现表t1有2个extent,现在我们想把它重整为只有一个extent
oncheck -pt dbname:t1

TBLspace Report for dbname:informix.t1

Physical Address 103103
Creation date 07/07/2003 15:50:08
TBLspace Flags 801 Page Locking
TBLspace use 4 bit bit-maps
Maximum row size 2000
Number of special columns 0
Number of keys 0
Number of extents 2
Current serial value 1
First extent size 4
Next extent size 4
Number of pages allocated 8
Number of pages used 6
Number of data pages 5
Number of rows 5
Partition partnum 1048744
Partition lockid 1048744

Extents
Logical Page Physical Page Size
0 1031bb 4
4 1031c3 4
$ oncheck -me 1048744 1

TBLspace merge extents report for TBLspace 0x1000a8

Number of extents
Original 2
Target 1

Current 1
Freed 2

$ oncheck -pt dbname:t1

TBLspace Report for dbname:informix.t1

Physical Address 103103
Creation date 07/07/2003 15:50:08
TBLspace Flags 801 Page Locking
TBLspace use 4 bit bit-maps
Maximum row size 2000
Number of special columns 0
Number of keys 0
Number of extents 1
Current serial value 1
First extent size 4
Next extent size 4
Number of pages allocated 8
Number of pages used 6
Number of data pages 5
Number of rows 5
Partition partnum 1048744
Partition lockid 1048744

Extents
Logical Page Physical Page Size
0 1031c7 8

 

7. 因备份失败导致Informix逻辑日志满,应如何处理 

环境:(IDS 11.5)
问题描述: 在使用onbar进行逻辑日志自动备份的过程中,由于没有人为参与,当硬件或者软件的故障,造成备份失败的情况下,用户很可能没有察觉错误的发生,而造成Informix的逻辑日志没有进行备份并引发数据库服务器online.log中出现,”Logical Logs are Full — Backup is Needed” 同时数据库服务器实例进入CKPT-REQ状态。

解答:这是由于数据库服务器激活检查点(checkpoint)后,因检查点记录要写入逻辑日志,而所有逻辑日志因没有备份进而导致无法重用。从而导致整个数据库服务器挂起。可以尝试使用下列三种方法之一进行处理。

1. 将$ONCONFIG配置文件中参数LTAPEDEV指向某一无用文件,并使用ontape -a进行一次日志备份操作以释放逻辑日志。
2. 使用onparams -a -d -s -i在当前逻辑日志后增加一个新的逻辑日志,使得数据库可以脱离CKPT-REQ状态。然后再进行进一步处理。
3. 如果上述方法因数据库服务器锁死严重(虽然使用onstat -观察数据库都是CKPT-REQ,但是实际上数据库内部仍会有不同)无效。可以将$ONCONFIG配置文件中参数LTAPEDEV指向/dev/null。然后重启数据库服务器。

注意:由于数据库服务器已经锁定,onmode -ky很可能无效。如果使用kill命令直接关闭数据库服务器,因为检查点没有完成,重启数据库存在失败的可能。因此,建议在拥有数据备份且情况紧急时使用。

 

8. 常见导致Informix PD的原因及处理方式 

环境: IDS 11.5 UIX

问题描述:在实际生产环境中,当客户使用双机时,存在一个问题。当数据库实例在主机运行过程中,用户在主机中增加了链接文件并使用这些文件向实例中添加了chunk。而在备机里忘记增加对应的链接文件。此后如果执行双机切换操作,数据库服务器在备机启动过程中,数据库服务器将这些新chunk标志为PD(Primary Down)。即使将实例切换回备机运行,chunk仍然是PD.

解答: 这是由于这些链接文件在备机不存在,导致数据库启动时无法读取对应chunk的内容。因此数据库服务器将他们标识为PD。此后,切换回主机问题仍然存在的原因是Informix chunk的状态信息保存在rootchunk内的保留页中。当在备机数据库实例启动时chunk的标志位已经被置为PD(Primary Down),切换回主机后,数据库不会自动改写这些标志位。

处理方法是在添加好相应的链接文件后,使用onspaces -s -p -o -O命令将标志位修改为PD(Primary Online)
-s 要修改chunk所属dbspaces 名字
-p 要修改chunk的全路径
-o 要修改chunk的偏移量
-O (无附加参数)

9. 如何区分Informix不同种类的长事务? 

有些Informix客户经常会遇到长事务的情况,通常在online.log会发现有不同的关于长事务的警告信息,如何区分这些不同的长事务类型,从而采取不同的方法去处理

通常在online.log会有两种不同的关于“long transaction”的信息提示:

第一种:
在online.log中有如下信息提示:“Continuing Long Transaction (for COMMIT): tx 0xc0000000b28f5338 username: fisp uid: 107” 在这种情况下,事务使用逻辑日志的量已经超过了长事务高水位值(LTXHWM),但此时的事务自己已经进入了“commit”或“roll back”阶段,此时数据库引擎将允许事务继续使用逻辑日志,而不会强行回滚该事物,所以上述类型的长事务不会阻塞数据库,并且系统会自动等待事务自行处理完毕。

第二种:
在online.log中有如下信息提示:“Aborting Long Transaction: tx 0xc0000000b8d20c18 username: fisp uid: 107” 这种情况的长事务已经超过了长事务高水位值(LTXHWM)并且没有自动进入到“commit”或“roll back”阶段,此时数据库会开始主动回滚该长事务在这种情况下,客户需要监控事务的回滚状态,必要时需要采取一定的措施防止该长事务阻塞数据库,影响生产。

10. dbimport / dbexport BLOB数据时,系统磁盘写操作频繁 

环 境: Informix ,HP-UX or AIX

问题描述:

当执行导入或导出操作时,如果表中含有 TEXT 或 BYTE 字段,操作系统所在磁盘I/O会非常繁忙。

系统tmp目录下很多临时文件产生, 例如 /tmp/dbx319512_6 . 这些文件都由informix用户创建, 并最终自动删除。

解 答:

有两个方法可以解决这个问题:

1) 设置 DBTEMP 环境变量到其他的非系统盘上
2) 设置 DBSPACETEMP 环境变量到已存在的临时DBSPACE上

11. 如何清理hung住的分布式事务 
环境:
IDS 分布式数据库,遵循两阶段提交协议
问题描述:
重启IDS后仍然不能清理一些XA事务
解答:
通过onstat -G可以获得所有XA分布式事务的信息,如下所示:

onstat -x:
============
Transactions
address flags userthread locks beginlg curlog logposit isol retrys coord
cd18018 A—- cce7018 0 0 41 0xc0018 COMMIT 0
cd181f8 A—- cce7630 0 0 0 0x0 COMMIT 0
cd183d8 A—- cce7c48 0 0 0 0x0 COMMIT 0
cd185b8 A—- cce8260 0 0 0 0x0 COMMIT 0
cd18798 -LX-G 0 13 41 41 0x2b5758 COMMIT 0
cd18978 A—- cce94a8 0 0 0 0x0 COMMIT 0
cd18b58 A—- cce8e90 0 0 0 0x0 COMMIT 0
7 active, 128 total, 8 maximum concurrent

onstat -G:
==============
Global Transaction Identifiers
address flags isol timeout fID gtl bql data
cd18798 -LX-G COMMIT 0 4478019 16 48 30313233343536373839616263646566303132333435363738396162636465663031323334353637383961626364656630303030303030303030303030303031
1 active, 128 total

方法:
(1)可以使用onmode -Z 0xcd18798,杀掉不能结束的全局事务。

(2)两阶段事务不能结束,可能是由于第二阶段提交事务由于某些原因不能接收到commit或者是rollback的命令,所以会hung住。所以我们需要手工发起一个commit或者rollback命令来让这个事务完成。 特殊情况下,需要联系IBM技术支持中心得到帮助。

12. 如何找到数据库的哪些用户具有DBA权限?

我们有时候需要找到数据库服务器中,哪些用户具有DBA权限,以便于有关安全与权限管理。
通常可以使用以下简单方法可以得到答案:

选择当前数据库, 执行SQL:

$ dbaccess test –

Database selected.

> select username,usertype from sysusers;
username usertype

informix D

1 row(s) retrieved.

>
在输出的结果中,有关usertype字段的含义如下,就可以找到相应的DBA权限的用户了。

D – DBA
C – CONNECT
R – RESOURCE

13. 多线程操作中,使用信号量与独占锁产生死锁的案例

环 境: informix

问题描述: 多线程操作中,使用信号量与独占锁产生死锁

解 答:

如果开发人员写下如下多线程工作的代码,应用将会遇到性能问题并且伴随有154的锁冲突错误。

下面的代码段含有逻辑陷阱, 所有的更新操作包含在一个事物当中,每一个更新语句将会有一个独占锁,直到整个事物完成。如果程序按如下顺序运行,如题的问题将会发生:

1) 当程序A 释放信号量
2) 程序 B 在程序 A 之前得到信号量

在此情况下,程序B将由于程序A的独占锁而不能更新。并等待deadlock timeout。程序A则在timeout的时间内不能做任何操作。

——————————————————

begin work

set lock mode to wait 10

Loop module start /*update the same row with table_1 many times*/
fetch a row data from table_1

get semaphore

update table_2

release semaphore

Loop module end

commit work

——————————————————

对上述代码做如下修改即可避免该问题:

——————————————————

begin work

set lock mode to wait 10

get semaphore

Loop module start /*update the same row with table_1 many times*/
fetch a row data from table_1

update table_2

Loop module end

release semaphore

commit work

——————————————————

注:informix的锁机制能完成上述功能,无需使用信号量辅助。

14. 如何使用onstat -p指标间关系评估实例基本情况 

环境:IDS 11.50

问题描述: 对于一个Informix实例onstat -p对于实例整体情况很有用处。onstat -p各个指标的解释很容易找到。而本文列出了几个主要指标间的比例关系,帮助评估一个实例的基本运行情况。

解答:
dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
1083 1653 193884 99.44 3860 14583 59454 93.51

isamtot open start read write rewrite delete commit rollbk
139364 21933 22499 36438 16624 1747 1445 1160 0

gp_read gp_write gp_rewrt gp_del gp_alloc gp_free gp_curs
41 15 147 0 4 0 4

ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes
0 0 0 24.07 2.87 7 17

bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans
0 1 54737 0 0 4 1623 690

ixda-RA idx-RA da-RA RA-pgsused lchwaits
0 0 0 0 349
bufreads和bufwrits: 经过对于OLTP系统的统计,bufreads和bufwrits的比例通常是10:1,通过这个比例可以看出系统I/O特性以及I/O性能调整的重点。请注意:不同系统的比例存在很大差异,10:1并不是评估指标。
commit和rollbk:rollbk的数量通常不超过commit数量1%。如果超过请核查导致大量交易不能提交的具体原因。可能是应用业务规则,锁冲突,锁粒度过大以及索引结构不合理等原因。
seqscans 和 isamtot: seqscans通常应该不超过isamtot数量的1%。如果一个实例中顺序扫描seqscans数量过大,应检查索引结构是否合理。

15. 插入操作报 -271 ISAM -136 错 

环境:Informix

问题描述:

插入操作报 -271 ISAM -136 错

解答:

informix 在存储上有以下限制,会造成存储空间不足的问题发生:

1) 达到单个表的extent上限
2) 达到单个表空间的物理页上限, 最大值为 16,775,134 页
3) 根空间即Rootdbs 满, sysmaster.sysextents 表不能插入新的记录
4) DBspaces没有剩余空间, 使用 onstat -d 命令可以查看
5) DBspaces中有剩余空间,但是连续的剩余空间大小都不足4K。使用oncheck -pe 命令可以查看空闲空间的大小。

16. IDS9.4版本升级至11.5过程中的注意事项

A、IDS9.4版本升级至11.5过程中的注意事项–升级前的准备工作

执行全面的数据库检查,包括:

1. 检查和准备足够的有效空间

a) 由于11版的sysmaster数据库较大,需确保rootdbs有足够空间,rootchunk至少有10%空余空间;对于2k大小的数据页,应保证在rootchunk中存在3000页以上的空闲数据页,即大约6M大小的剩余空间;且建议物理日志、逻辑日志的空间要求比较大;

b) 确保每个dbspace都有足够的空间用于迁移数据库,如果包含大量存储过程或索引将会需要更多的空间;存在于dbspace上的每个database都应该至少拥有2M的剩余空间用于转换

i.使用以下sql确定所需空间
SELECT partdbsnum(partnum) dbspace_num, trunc(count(*) * 2000) free_space_req FROM sysdatabases GROUP BY 1 ORDER BY 1

ii.使用以下sql确定所拥有的空间
SELECT dbsnum dbspace_num, sum(nfree) free_space_avail FROM syschunks GROUP BY 1 ORDER BY 1

c) 如果实际空闲空间低于所要求的标准,则应考虑迁移部分数据到其他存储空间或增加新的存储空间
2. 做数据索引检查,如果出现问题数据页、索引请提前修正。
oncheck –cD database_name
oncheck –cI database_name

3. 检查数据库表Extent数,确保不会由于表Extent数达到限制导致升级错误;
SELECT dbsname, tabname, nextns
FROM systabnames t, sysptnhdr p
WHERE t.partnum = p.partnum
AND p.nextns > 200
ORDER BY 3 DESC;

4. 在进行数据库备份之前请使用oncheck检查数据完整性并解决遇到的问题,
使用select name from sysdatabases可以获得相关数据库名字的信息
oncheck –cr
oncheck –ce
oncheck –cc

在确保数据库数据完整一致的前提下,执行数据库备份,同时应考虑同时进行磁带备份与文本备份。

B、IDS9.4版本升级至11.5过程中的注意事项–升级过程中的注意事项

1. 关闭所有连接数据库的应用程序。

2. 用Informix登录,停止数据库服务。

3. 用informix用户登录,修改数据库实例名称和服务端口号,以保证不会再有应用连接数据库。

4. 重新启动数据库检查是否存在处于打开状态的事务。Informix登录;
a) 为确保没有处于打开状态的事务,请执行
oninit –sv
b) 在完成fast recovery进入静默状态以后,请检查数据库日志确认没有错误发生,特别注意是否有全局事物处于打开状态;检查数据库日志文件启动日志中是否看到以下内容:

0 Committed, 0 Rolled Back, 0 Open, 0 Bad Locks

c) 如果有事物提交、回滚,将数据库关闭重启,再检查;如果有Open事物,检查onstat –x是否有事务,用onmode -H清除这些事物,关闭重启数据库再检查;

d) 检查逻辑日志备份状态

5. 检查数据完整性
a) 在进行数据库备份之前请使用oncheck检查数据完整性并解决遇到的问题
oncheck –cr
oncheck –ce
oncheck –cc

6. 关闭数据库数据库并确认所有内存段及系统进程都正确释放。

a) 执行onstat –确认当前数据库处于静默状态,即quiescent状态
b) onmode –ky停止数据库
c) onstat –确认数据库offline;
shared memory not initialized for INFORMIXSERVER ‘ol_cash_bak’
ipcs| grep informix
ps -ef | grep oninit
7. 安装11.5版本的数据库,并确认版本

8. 修改相关配置文件,使之符合11.5版本的要求。

9. 切换至informix用户登录
启动实例,触发迁移、转换操作,注意,不要进行磁盘初始化,直接执行oninit -v即可。

发表回复