在论坛看到收缩主数据库在Mirror上没有效果的问题。以前我也认为在主数据库上执行的DBCC Shirnkfile命令会在Mirror数据库上重做,所以收缩主数据库可以导致Mirror数据库跟着收缩。事实不是。从MS网站找到的资料:
CAUSE:Database mirroring will change the physical file sizes only after a checkpoint.
在主数据库上执行DBCC SHRINKDATABASE或者DBCC SHRINKFILE的命令,收缩的操作不会在Mirror数据库上重做。原因是:Mirror数据库只在checkpoint动作后才会修改物理文件的大小。
有几个办法可以解决这个问题:
1. 在Master数据库执行下面的命令创建存储过程,在主数据库上运行创建的存储过程。
usemaster
go
if object_id('sp_shrink_mirrored_database','P')isnot null
drop procsp_shrink_mirrored_database
go
create proceduresp_shrink_mirrored_database@dbnamesysname,@target_percentint=null
as
begin
declare@filenamesysname
declare@filesizeint
declare@sqlnvarchar(4000)
if @target_percentis null
dbccshrinkdatabase(@dbname)
else
dbccshrinkdatabase(@dbname,@target_percent)
declareccursorfor
select[name],[size]fromsys.master_fileswheretype=0anddatabase_id= db_id(@dbname)
open c
fetch nextfromcinto@filename,@filesize
while @@fetch_status=0
begin
set @filesize=(@filesize+1)*8
set @sql='alter database ['+@dbname+ '] modify file ( name='
+ @filename+', size='+cast(@filesizeasnvarchar)+'kb )'
executesp_executesql@sql
fetchnextfromcinto @filename,@filesize
end
close c
deallocatec
end
go
2. 在主数据库上执行收缩命令之后手动允许checkpoint命令。
3. 可以考虑做Failover将辅助的直接变成主的,执行收缩命令。
另外建议经常对数据库进行日志备份,如果发现日志文件增长的快可以考虑增加备份的频率,这样可以导致日志空间重用,从而减少日志文件的增长。
另外在2008版本上测试不会有这个问题,收缩的命令可以成功在Mirror上面起作用,所以这个现象可能只限于2005的版本。
本文转自 lzf328 51CTO博客,原文链接:http://blog.51cto.com/lzf328/1252921