标签: shrink

我在 SQL Server 数据库中有一个包含 70 多万条记录的表，我删除了该表（一次性的事情）以释放磁盘空间，但看起来大小没有太大变化。我确实看到我可以将数据库缩小到最低限度。

这是这样做的方式吗？

上次我使用 SQL Server Management Studio 进行收缩时，花了几个小时才完成。有没有更快的方法？

好的，首先，我在创建数据库时搞砸了，使用的创建脚本大致如下：（用于包装目的的人工换行符和名称/路径）

CREATE DATABASE [EXAMPLE] ON  PRIMARY 
( NAME = N'EXAMPLE_Data', FILENAME = N'J:\SQLServer2008\MSSQL.INSTANCE\EXAMPLE.mdf', 
    SIZE = 446046KB , MAXSIZE = UNLIMITED, FILEGROWTH = 10%)
 LOG ON 
( NAME = N'EXAMPLE_Log', FILENAME = N'J:\SQLServer2008\MSSQL.INSTANCE\EXAMPLE.ldf', 
    SIZE = 664505KB , MAXSIZE = 2048GB , FILEGROWTH = 10%)
GO

因为我从现有的开发数据库中编写了它的脚本，我只是想让一些事情发生。当我没有将大小更改为合理的大小（例如4096KB）时，我搞砸了，所以现在我无法将日志文件缩小到大约 600MB 以下。

我知道我哪里出错了，但是如何轻松修复它？

每个人都警告不要缩小数据库，例如 SQLAuthority

但在我的情况下它会是一个有效的选择吗？数据库最初超过 1 GB，但是从其中删除了一个表（移动到另一个数据库），当我备份它时，数据库现在是 100 MB，而 MDF 仍然超过 1 GB。

如果我缩小数据库，然后重建所有索引怎么办？这一切还是禁忌吗？

我有一个需要维护的数据库。

可悲的是，该数据库的设置和使用我无法改变，很多（感谢一些内部政治）。

它在 SQL Server 2008r2 上运行。

它只存在了 5 天，并且在那段时间从 20GB 增长到了 120GB 以上。（基本上大部分数据都被删除然后导入，但就像我说的那样我无法控制那方面的事情）

我很想运行夜间作业来缩小数据库并重新组织索引，但我知道这离最佳实践还有很长的路要走，并且可能会导致比我已经遇到的更多问题！

问题

• 处理大小迅速增加的数据库的最佳方法是什么？
• 我应该考虑移动文件组以减小磁盘上的物理大小吗？
• 有没有办法在一个月内阻止服务器空间不足？

我们确实为 SQL Server 2008 r2 express 制定了一些维护计划。如果任何表的页数超过 50 并且平均碎片超过 20，我们每个月都会对数据库进行碎片整理。

如果数据库日志大小>2MB，则恢复模式为简单，收缩，恢复模式重新设置为FULL。如果 Page_count>50 且 avg_fragmentation_in_percent > 30，则索引为 REBUILD。

如果 Page_count>50 且 avg_fragmentation_in_percent > 5 且 <30，则索引为 REORGANIZE。

这就是我们目前正在做的事情。但是我们发现自增长事件是资源密集型的，不应重复发生。现在，对于所有数据库，mdf 文件的自动增长设置为 MB，ldf 文件设置为 10%，这是创建新数据库时的默认值。我们计划根据每天变大的数据库数量来增加数据库的自动增长值。但是我想知道有多少自动增长事件对数据库来说是理想的。我应该设置自动增长以便它每天、每周或每月等只发生一次吗？所以请帮助我为我的数据库设置自动增长值。还有另一个问题，如果我每月对数据库进行碎片整理，那么它就会缩小。因此，在此之后，对于所有我确实收缩过的数据库，在写入新数据时都会发生一次自动增长。所以会有很多自动增长事件。那么会不会有问题呢？请告诉我一个解决方案。

我在生产中有一个数据库，它不断地填充日志文件，它是一个数据仓库，并且有许多作业/查询正在运行。下面是我得到的错误

Msg 9002, Level 17, State 4, Line 7
The transaction log for database  is full due to 'ACTIVE_TRANSACTION'. 

现在这是有道理的，我明白 SQL 无法执行操作，因为它的日志文件已满。我有两个日志文件

• 启用无限制增长和自动增长的 D 盘 [D 盘大小 180 GB]
• E盘静态大小[E盘120GB，日志文件大小：20GB]

我对这个问题做了一些研究，并找到了可能的解决方案：来源

• 备份日志。
• 释放磁盘空间，以便日志可以自动增长。
• 将日志文件移动到具有足够空间的磁盘驱动器。
• 增加日志文件的大小。
• 在不同的磁盘上添加日志文件。
• 完成或终止长时间运行的事务。

现在，假设我的空间有限（即 180 GB + 20 GB），我认为这对于 SIMPLE RECOVERY MODE 中的数据库来说已经足够了。我怎么可能发现这个问题并在它发生之前进行纠正？

复制：

我试图通过使用以下设置创建新的示例数据库来复制此场景

和下面的查询以获取百万行并将它们插入表中

SET NOCOUNT ON;
DECLARE @SET_SIZE INT = 500000000;

CREATE TABLE dbo.Test500Million (N INT  PRIMARY KEY CLUSTERED NOT NULL);

;WITH T(N) AS (SELECT N FROM (VALUES (NULL),(NULL),(NULL),(NULL),(NULL),(NULL),(NULL),(NULL),(NULL),(NULL)) AS …

标准免责声明：我是一个“非自愿DBA”（在一个不错的那句我看到这篇文章），也做了很多和很多和大量的和大量的和大量的阅读关于这个问题，但我仍然困惑/关注...

我需要将几个 SQL Server 2014 生产数据库的恢复模型从完整更改为简单。

数据库目前设置为完全恢复，并且正在使用SqlBackupAndFTP进行备份，这将每天进行一次完整备份，每天进行 3 个差异备份和 20 个事务备份。这一直运行良好，直到我们与提供基于 FTP 的存储的公司发生了巨大的问题。

大约 3 个月前，我改用运行良好的Attix5 - 但是，我现在发现由于软件的工作方式，事务日志与数据文件一样大（在一种情况下，对于 13Gb 数据文件超过 14Gb ）。

我被建议将恢复模式切换为简单，这样事务日志就不会增长。

我知道使用 Simple Recovery 不会提供时间点恢复- 这绝对没问题，因为完整备份每小时进行一次，我们“很高兴丢失”之前 1-59 分钟内可能发生的任何事情。

我的理解是我应该将恢复模式设置为简单并让备份发生，这将在事务日志中设置一个检查点，允许重新使用空间。

但是，我确实需要将事务日志缩小到合理的大小（这样它就不会占用太多的备份空间），但我一直在读到缩小是一个坏主意。还是我拿错了棍子的一端？

如果我使用以下命令将事务日志缩小到大约 25Mb（对于单个每小时的事务集来说应该足够大），这是否足够？

DBCC SHRINKFILE('log file name',25)

（我真的很抱歉问一些之前似乎被问过无数次的问题，但这不是我可以出错的。）

有没有办法查看 SQL Server 2014 上过去几周/几个月的增长和收缩事件的完整历史记录？（要支持的新实例，从票务系统中注意到它们之前有“日志驱动器已满”的历史记录，因此希望在再次发生之前深入研究根本原因。）

这很有用：识别文件增长事件。想出了下面的查询，但它没有显示任何“手动”日志收缩事件，只显示“自动”事件。我是否以错误的方式这样做，还有其他地方可以查找过去的信息吗？

select
    te.name as event_name,
    tr.DatabaseName,
    tr.FileName,
    tr.IntegerData,
    tr.IntegerData2,
    tr.LoginName,
    tr.StartTime,
    tr.EndTime
--select * 
from 
sys.fn_trace_gettable(convert(nvarchar(255),(select value from sys.fn_trace_getinfo(0) where property=2)), 0) tr
inner join sys.trace_events te on tr.EventClass = te.trace_event_id
where 
tr.EventClass in (93, 95) --can't identify any other EventClass to add here
order by 
EndTime desc;

我有一个 302MB 的日志文件。

我做了一个日志备份，它使日志文件大部分都是免费的（我可以通过磁盘使用标准报告看到这一点）

如果我试着跑

DBCC SHRINKFILE (N'AdventureWorks2014_Log' , 0, TRUNCATEONLY)

或者

DBCC SHRINKFILE (N'AdventureWorks2014_Log' , 0)

该文件仍显示为 302MB。

我知道我可以将数据库更改为简单恢复，然后运行上述命令之一并设置回完全恢复（然后进行完全备份以确保数据库未处于伪简单恢复模式）

但是，为什么我不能在完全恢复模式下缩小文件？

我知道收缩不是你应该做的事情，但在我现实世界的数据库中，因为没有人备份过它已经增长到 30GB 的事务日志，现在已经实施了定期日志备份以防止这个级别的增长

我有一个增长到 20 GB 的数据库，在归档一些数据后，表的实际大小仅为 5GB。备份脚本会将备份副本保存到其他位置。移动 20GB 或 5Gb 确实有所不同，所以我想减小物理尺寸，但如果我不想影响性能，我读到的任何地方都不要缩小。

但是在这种（定期/每季度/每年）归档的情况下，是否仍然建议不要收缩？