【问题标题】:SonarQube database using too much space (60+ GB)SonarQube 数据库使用太多空间 (60+ GB)
【发布时间】:2016-02-10 13:16:09
【问题描述】:

我目前正在扫描 70 个项目,总共大约 200 万行代码。一切都很顺利,直到几周前我被告知有几个项目失败了,因为我们用完了 SonarQube 服务器上的硬盘空间。根据硬件/软件要求,我确信我们有足够的空间。我读到重新启动 Sonarqube 服务器服务确实会清除临时文件,但是在这样做了几次之后,某些东西仍然占用了更多空间。罪魁祸首来自 SQL 服务器:

...\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\sonarqube_log.ldf

此文件的大小目前为 66.8 GB。有谁知道我是否可以截断其中的内容,知道任何减小此文件大小并在未来扫描期间减小大小的最佳做法?

【问题讨论】:

  • 你在用什么recovery model?如果是完整或批量记录,您多久备份一次事务日志?
  • 它使用的是“简单”,我认为也没有进行任何备份。
  • 简单恢复不需要事务日志备份。在 Full 或 Bulk Logged 上,日志仅在备份时刷新,但 Simple 应该定期刷新自身。 DBCC SQLPERF(logspace) 说的日志空间使用百分比是多少?我猜它要么非常高(95%+)要么非常低(select name, log_reuse_wait, log_reuse_wait_desc from sys.databases 的输出是什么?
  • DBCC SQLPERF(logspace);从 sys.databases 返回 94.48% 的选择名称、log_reuse_wait、log_reuse_wait_desc;返回 log_reuse_wait = 2, log_reuse_wait_desc = LOG_BACKUP
  • 糟糕,我在查看恢复模型时查看了错误的数据库,SonarQube 设置为“完整”。 doh 上面的查询是正确的。

标签: sql-server sonarqube sonarqube5.1


【解决方案1】:

好的,如果您的数据库恢复设置为完全并且您没有备份事务日志,那就是问题所在。

如果您需要帮助了解恢复模型之间的差异,请start here。简短的版本是完全恢复允许时间点(又称故障点)恢复,这意味着您可以将数据库恢复到问题发生之前的确切时刻。完全恢复的缺点是您必须备份您的事务日志,否则会发生这个确切的问题:日志无休止地增长。简单恢复消除了事务日志备份的需要(实际上,我认为您不能在简单数据库上进行事务日志备份),但限制您将数据库恢复到上次运行数据库备份时的状态。请注意,简单恢复仍然使用事务日志!系统只是定期刷新它们。

因此,您需要做以下两件事之一:使用完全恢复并定期备份您的事务日志(我见过对于高流量系统每小时甚至每 15 分钟执行一次的系统),或者切换到简单恢复。这些是你唯一真正的选择。

无论您做什么,切换到 Simple 或备份日志都会刷新事务日志。您可以使用DBCC SQLPERF(logspace) 进行验证。但是,您会注意到sonarqube_log.ldf 根本不会改变大小。它仍然是 66.8 GB。这是设计。在管理得当的系统中,事务日志将达到它们需要操作的大小,然后备份和简单刷新将保持大小不变​​。日志文件的大小适合运行系统,因此它永远不需要增长(代价高昂),也永远不会耗尽空间(这会导致所有事务失败)。

“那么,我该如何取回我的磁盘空间?”你问。 “我已经解决了这个问题,所以日志文件现在将浪费 95% 的空间。”

您需要做的是缩小日志文件。这是你经常会看到写的你不应该做的事情。而且,我同意,在一个管理得当的系统中,你永远不需要这样做。但是,您的系统运行不正常。日志文件失控。不过,一般来说,您永远不需要这样做。

首先,进行完整的数据库备份。我再说一遍:对您的数据库进行完整备份。这应该不会导致任何问题,但您不希望在没有新备份的情况下执行此类操作。

接下来,您需要找到相关数据库的日志文件的文件 ID。你可以这样做:

select d.name, mf.file_id
from sys.databases d
join sys.master_files mf
    on d.database_id = mf.database_id
where mf.type = 1
    and d.name = 'SonarQube'

mf.type = 1 仅返回事务日志文件。如果不是SonarQube,请使用您的数据库名称。

--Switch to the SonarQube database.  If you're not in the right context, you'll shrink the wrong file.
use [SonarQube]; 

--Do a checkpoint if you're on Simple recovery
checkpoint; 

--Do a log backup if you're on Full recovery
backup log ....

--Shrink logfile to 1 GB.  Replace @file_id with the id you got above.
dbcc shrinkfile ( @file_id, 1024 );

那里的大小是以MB为单位的大小。您必须根据您的数据库有多大以及您对系统进行了多少更改来进行猜测。对于大多数系统来说,介于数据库大小的 50% 和 100% 之间的东西是相当安全的。无论如何,我不会将日志压缩到 1 GB 以上。您需要监控日志空间以及日志是否继续增长。 SSMS 中的Disk Usage report 是一个很好的方法。

第一次运行此程序时,您可能根本看不到磁盘空间有多少增加。它可能会达到 66.0 GB 或 62 GB。这样做的原因是因为日志文件的当前尾部仍然位于事务日志文件的末尾。您应该做的是,如果系统处于活动状态,请等待几个小时,然后再次运行上述程序。这将使系统有时间将日志循环回日志文件的开头,并且您可以将其缩小。 Here 是一篇很好的文章,它详细介绍了缩小日志文件的实际工作原理,如果您有兴趣的话。

【讨论】:

  • 谢谢!昨晚我已将其切换为 Simple,并且能够使用您给我的同一站点上的说明释放空间!
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2020-05-19
  • 1970-01-01
  • 2016-10-21
  • 2019-01-28
  • 2012-05-15
相关资源
最近更新 更多