Question

我们已经将大量数据库的日志发送大约6个月，目前大小在20-60GB之间。我们每5分钟发货一次，保留3天。这些日志每5分钟从大约18KB到5MB不等（在较小的一端更多）。

我们注意到MSDBData数据库变得非常大（30GB）。这是正常的吗？

当我们前几天删除（测试）日志发送数据库时，花了30多分钟，似乎试图删除日志传送历史记录。当启用日志传送任务时，我们现在看到非常高的IO。

我们尝试过运行sp_cleanup_log_shipping_history。目前尚不清楚我们是否应该安排这个或它是否自动运行（？）但是它造成了大量的IO几个小时但没有减小MSDB的大小（查看表大小而不是磁盘上使用的物理空间），尽管它似乎确实删除了一些行。

据我所知，登录所需的时间主要是调用此SP导致问题。

目前，log_shipping_monitor_error_detail表有15293932行，log_shipping_monitor_history_detail有15350276行。这些错误是由于之后删除日志的权限不足造成的。

有没有人对我们如何进一步诊断这一点有什么建议，应该采取什么样的“正常”行为，以及我们可以编写什么作为维护任务的脚本来保持这种情况再次发生？

（不确定这是最好的贴在这里或ServerFault，但这里有更多的日志传送问题！）

Answer 1

如果您经常在这段时间内进行日志传送，则30GB位于正确的球场内。

我会看看哪些表是最严重的违规者 - 这将暗示从何处开始清理。这个SQL可以很好地分析哪些表占用了哪个空间：

create table #RawData (name varchar(100), rows varchar(20), reservedKB varchar(20), dataKB varchar(20), index_sizeKB varchar(18), unusedKB varchar(18))
create table #Data (name varchar(100), rows int, reserved float, data float, index_size float, unused float)
exec sp_msforeachtable 'insert into #RawData exec sp_spaceused ''?'''
INSERT INTO #Data
SELECT name, rows, 
CONVERT(float, REPLACE(reservedKB, ' KB', ''))/1024, 
CONVERT(float, REPLACE(dataKB, ' KB', ''))/1024, 
CONVERT(float, REPLACE(index_sizeKB, ' KB', ''))/1024, 
CONVERT(float, REPLACE(unusedKB, ' KB', ''))/1024 
FROM #RawData
select *, data+index_size as used from #Data order by data+index_size desc
drop table #RawData
drop table #Data

日志传送 - 高IO和30GB MSDB

1 个答案: