现在有一个 ASE12.5 for AIX4.3.3 ，在上面建有一个用户库 db目前已经使用了210G空间了。但是挂接在这个db上的device还剩下约20G空间是没有用的。但是现在要insert的时候，却总是报错说无法为table xxx在segment 'default'上分配空间……
我就赶紧去看 sp_helpsegment ，发现这个'default' segment也还剩有约20G的free space未用。这个库的 log空间也几乎全空……
汗……哪位朋友知道如何解决的，请尽速告知，不胜感激。
chenfeng825 回复于：2003-08-20 12:33:42
你的sybase有没有补丁过。sybase有个207254的bug会产生你说的那种情况。
什么用途数据库，12.5也就2年挺大的
Eisen 回复于：2003-08-20 12:54:57
哦……看了一下—— 果然，没有打过补丁的，还是SWR……
晕死——我就出了趟差，怎么装出来的就是这样的……
气死我了。
多谢chenfeng825老兄。
Eisen 回复于：2003-08-20 17:42:26
[quote:58d98111af="chenfeng825"]你的sybase有没有补丁过。sybase有个207254的bug会产生你说的那种情况。
什么用途数据库，12.5也就2年挺大的[/quote:58d98111af]
刚才看了一下最新的AIX EBF for ASE12.5，发现没有针对这个bug的补丁啊……
难道………………
//不敢想象。
chenfeng825 回复于：2003-08-21 08:44:33
我的感觉是sybase补丁如果不上的话什么问题都可能发生的。曾经在12.0几了还碰到过11.0的bug，没有说明，反正是有问题就给补了一个比较新的解决了。试试看，补丁也没危害的
Kangoo 回复于：2003-08-21 08:54:52
作一下DBCC
Eisen 回复于：2003-08-21 10:09:15
是啊。我以前用12.0也遇上过11.9上的bug。呵呵。
Eisen 回复于：2003-08-22 12:02:25
不行……
如今打上了最新的EBF补丁，问题还是照样……
难道这个bug就是没有解决的遗留bug?
Blackrose 回复于：2003-08-22 12:08:48
除了这个表，其他的表数据增加有问题吗？？
最好做DBCC检查，我觉得不太可能
chenfeng825 回复于：2003-08-22 12:46:27
补丁以后还不行就要小心了，看看分配页有没有问题？
Eisen 回复于：2003-08-22 13:37:49
对的。其他所有表都有这个分配不了空间的问题了。偶现在就是挑几个巨大的表来truncate掉，才能让系统继续运行下去了。
现在还不能做dbcc……系统不能停下来啊，而不停应用的时候如果checkdb的话，两边都会慢得很。不过，我抽了几个这样的table作了checktable，都是完好的。看样子也不会是page分配的问题。
现在在sybase的news group上也没人回答——真急啊。
RS9000 回复于：2003-08-22 13:53:53
咨询过SYBASE公司没有，会不会是SYBASE的限制呢？？
既然DROP表的空间可以用，看起来应该没有什么问题呀
chenfeng825 回复于：2003-08-22 13:54:28
有没有阀值之类的选项?
Eisen 回复于：2003-08-22 14:32:53
当然不会有阈值这样的限制啦。
Eisen 回复于：2003-08-27 10:25:56
ft...
如今这个东西已经发展到了不能容忍的地步了……
现在就连syslogs也就是log都不能分配新空间了……
可是sybase网站上的submit bug居然还不允许提交ASE的bug……
晕死……现在真的要喊"救命"啦……
chenfeng825 回复于：2003-08-27 12:14:57
syslogs不能分配空间？你的log segment应该是独立的，怎么会这样？
Eisen 回复于：2003-08-27 12:53:42
我哪里知道阿？
sp_helpdb看，用sp_helpsegment看，都是一样的结果
data剩余30G，log剩余10G……
呜呼啊……
dooloob 回复于：2003-09-01 14:45:15
如果是truncate些大表后，能够正常的话，你不防向数据库中添加一个小设备后，会不会恢复正常
期待。。。。。。。。。
Eisen 回复于：2003-09-01 17:55:29
问题已经解决了——用 -T7408参数，用单用户模式重起Server，重新计算一遍data段的剩余可用空间就好了。
chenfeng825 回复于：2003-09-01 21:16:30
已经加精，烦请写出详细做法和过程
Eisen 回复于：2003-09-01 21:43:17
ok...版主这么努力，我们要是还偷懒的话，就太对不起版主了。 
ASE12.5 for AIX4.3.3的早期版本在内部计算设备可用剩余空间的算法上有误，有可能造成当数据容量超过某一值后如果某次未能扩充设备空间的话，将使剩余空间点一直保持不动，也就是说哪怕扩展了很多设备空间依然无法为table分配空间。
解决办法:
1. 先给ASE打上最新的ebf补丁，具体步骤和方法参见各EBF内部的COVER。
2. 将ASE shutdown掉。修改启动script文件RUN_xxxx最后添加
"-T7409 -m"后，重起一次，等待大约30分钟(如果log段大，那么再等长一些时间)这段时间没有提示，全凭感觉走，我的log有12G大，我等了大约40分钟。
3. 将ASE 再次shutdown掉。修改启动script文件RUN_xxxx，将刚才添加的最后那两个参数改为
"-T7408 -m"后，重起一次。这次不用多等，显示启动好了，就可以用sa登录进去操作了。
首先 sp_helpdb查看那个出问题的database的dbid(假设为7)
然后执行命令 dbcc gam(7,0,0,'fix')
等到结束。
4.再次shutdown，将刚才的"-T7408 -m"去掉。重起数据库，就可以恢复正常了。
chenfeng825 回复于：2003-09-02 10:14:48
你这个问题看起来和log space看起来不准确的很相似。dbcc gam和dbcc usedextents都是修复空间不准的问题的。只是traceflag 7409和7408倒是不明白做什么用，没见过!
Eisen 回复于：2003-09-02 11:29:16
这两个flag就是启动之后重新计算log段和dat段空间标志位的一个点。加上这两个之后，用sp_helpdb看到的全都是负数了，就是因为它在移动那个标志位所至。
pengxb 回复于：2003-09-03 17:20:48
问题如果解决了告诉我们一下！
pengxb 回复于：2003-09-03 17:23:16
我有一个解决方法不知可不可以：
在RUN文件中加－T7409，然后重启server，下一次启动server之前别忘了再把trace去掉！
|
