0

大约 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，但这里有更多的日志传送问题！）

4

1 回答 1

0

如果您在那段时间内经常进行日志运输，那么 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
于 2013-09-12T12:41:28.587 回答