数据库的日志剩余空间竟比分配的日志空间大（已解决）
日志剩余空间竟比分配的日志空间大，彻底晕倒了数据库库为awsdyndb，分配的日志空间为12G，由于最近要删除数据，所以就每天dump一次，免得
日志不够使用，但是每次dump之后日志空间就比分配该库的日志空间大一次。。。。
(1 row affected)
device_fragments size usage created free kbytes
------------------------------ ------------- -------------------- ------------------- ----------------
awsdyndb_dev 32000.0 MB data only Feb 15 20063:04AM 6260528
awsdyndb_log 10000.0 MB log only Feb 15 20063:04AM not applicable
awsdyndb_dev2 32000.0 MB data only Sep 27 2007 10:20AM 445600
phsdb06_dev 2048.0 MB log only Jun1 2008 11:23PM not applicable
-----------------------------------------------------------------------------------------------------------------
log only free kbytes = 15600608
看日志空间为12G，剩余却是15.6G。。。这是dump后的结果。
再看第三次dump后的结果
device_fragments size usage created free kbytes
------------------------------ ------------- -------------------- ------------------- ----------------
awsdyndb_dev 32000.0 MB data only Feb 15 20063:04AM 7063760
awsdyndb_log 10000.0 MB log only Feb 15 20063:04AM not applicable
awsdyndb_dev2 32000.0 MB data only Sep 27 2007 10:20AM 445600
phsdb06_dev 2048.0 MB log only Jun1 2008 11:23PM not applicable
-----------------------------------------------------------------------------------------------------------------
log only free kbytes = 73953192
(return status = 0)
日志空间为12G，dump之后居然 log only free kbytes 为73个G。。汗整个数据才只有76G。数据分的是64，为什么这里显示的结果越来越多呢？:em17:
[ 本帖最后由 回族四少 于 2008-7-19 00:08 编辑 ] dbcc checktable(syslogs)检查空间看看
利用该方法成功解决
重新计算日志空间的方法如下：以库latn为例：1、正常shutdown server。
2、在RUN文件中加入-T7408，启动server。启动过程中可查看到“Forcing server to scan allocation pages to find free log space count for database 7”。Server会重新计算每个数据库的free log space。
3、启动后用sp_helpdb latn查看log free的情况，仍可能是错误的。
isql -U -P -S
>use latn
>go
>create table dummy_table_aaa (c1 int,c2 char(2))
>go
>insert into dummy_table_aaa values(1,”1”)
>go 200
>checkpoint （必须手工执行）
>go
>sp_helpdb latn
>go
显示latn的log free space为正常，修复成功。
>drop table dummy_table_aaa
>go
:em20:
页:
[1]