cleanerwzw 发表于 2009-12-01 09:17

onstat -d看到有chunk剩余空间为负值

下面的chunk “/dev/vx/rdsk/scpdatadg/lvworkdbs109” 大小为-124827, 请问这个表示什么呢？






<2 UVC1 :/tellin/scu/log>onstat -d

IBM Informix Dynamic Server Version 9.40.FC7W4   -- On-Line -- Up 65 days 21:14:03 -- 1369088 Kbytes

Dbspaces
address          number   flags      fchunk   nchunksflags    owner    name
128982e78      1      0x1      1      1      N      informix rootdbs
129d679b8      2      0x1      2      1      N      informix logdbs
129d67b58      3      0x1      3      1      N      informix phydbs
129d67cf8      4      0x2001   4      4      N T      informix tempdbs
129d69028      5      0x1      5      149      N      informix workdbs
...
...
115 active, 2047 maximum

Chunks
address          chunk/dbsoffset   size       free       bpages   flags pathname


...
...
129d591c0      222   5    20         1000000    39997               PO--/dev/vx/rdsk/scpdatadg/lvworkdbs106
129d59358      223   5    20         1000000    39997               PO--/dev/vx/rdsk/scpdatadg/lvworkdbs107
129d594f0      224   5    20         1000000    2701                  PO--/dev/vx/rdsk/scpdatadg/lvworkdbs108
129d59688      225   5    20         1000000    -124827               PO--/dev/vx/rdsk/scpdatadg/lvworkdbs109
129d59820      226   5    20         1000000    5701                  PO--/dev/vx/rdsk/scpdatadg/lvworkdbs110
129d599b8      227   5    20         1000000    46336               PO--/dev/vx/rdsk/scpdatadg/lvworkdbs111


...
...
129d67820      266   5    20         1000000    999997                PO--/dev/vx/rdsk/scpdatadg/lvworkdbs150
266 active, 2047 maximum

liaosnet 发表于 2009-12-01 09:22

oncheck -pe workdbs 看那个chunk里的分布情况..

cleanerwzw 发表于 2009-12-01 09:32

呃，多谢回复。。。不过我现在没法直接登陆执行命令，本来是想问问有没有类似案例的。
我试试看联系人查看一下。

3sane 发表于 2009-12-01 13:03

回复 #1 cleanerwzw 的帖子

这种情况碰到过，而且早在V7版就有，一般是保留页数据的问题，哪怕正数也有合不拢的时候，不过用下来好像也没有什么问题，类似于select count(*) 加和没有加where 1=1，查询结果有时候不同一样（不过这是update statistics没更新的原因）。如果真要修正除了改保留页就只能重建这个DBS了:mrgreen:

cleanerwzw 发表于 2009-12-01 14:26

多谢答复，这个dbs现在肯定没法重建。。。太大了。排号都到150了。

你说的意思是这个负值可能只是个显示上的错误结果吧，感觉你说的有道理，真要有大问题应该不是显示在这个地方。而且现在也没有什么明显的问题，关键是现在怎么修复这个显示错误。你说的那个修改保留页是怎么回事？

cleanerwzw 发表于 2009-12-03 09:01

oncheck -pe workdbs结果如下（只截109这一部分），看实际占用都是对的，应该只是个显示问题，只能先这样了，我也不敢动它。

Chunk Pathname                                       Size      Used      Free

   225 /dev/vx/rdsk/scpdatadg/lvworkdbs109         1000000   1124827   -124827



Description                                                   Offset   Size

------------------------------------------------------------- -------- --------

RESERVED PAGES                                                       0      2

CHUNK FREELIST PAGE                                                2      1

scpdb:'scu'.u_uvc_manlog_bak091001                                 3   512000

scpdb:'scu'.u_uvc_manlog1017_old                              512003   256000

scpdb:'scu'.u_uvc_supply03                                    768003   128000

scpdb:'scu'. 1774_9701                                          896003    50412

scpdb:'scu'. 1775_9702                                          946415    50412

FREE                                                            996827   3173



Total Used:   996827

Total Free:   3173

liaosnet 发表于 2009-12-03 09:42

回复 #6 cleanerwzw 的帖子

那就确定是保留页的记录有问题~:mrgreen:

3sane 发表于 2009-12-03 15:02

回复 #5 cleanerwzw 的帖子

如果想改保留页，只能通过二进制的方式修改。但是保留页里除了页信息以外，还有其他数据在里面，所以需要了解保留页的数据结构了，否则万一改错了，可能导致数据库校验错误，起不来！这个问题之前很多是备份恢复后产生，确认为BUG，但是其他情况就未确定。

BUG#idsdb00048278:
ONSTAT -D SHOWS NEGATIVE SIZE(-1) FOR CHUNK FREE COLUMN FOR SBSPACE IF SERVER IS BROUGHT DOWN DURING LOG RESTORE & RESTARTABLE RESTORE IS STARTED.

[ 本帖最后由 3sane 于 2009-12-3 15:03 编辑 ]
页: [1]
查看完整版本: onstat -d看到有chunk剩余空间为负值