相关疑难解决方法(0)

这个问题在大多数论坛和整个网络中似乎是一个常见问题，这里以多种格式提出，通常听起来像这样：

在 SQL Server 中 -

• 事务日志变得如此之大的一些原因是什么？
• 为什么我的日志文件这么大？
• 有什么方法可以防止这个问题的发生？
• 当我找到根本原因并希望将我的事务日志文件调整到正常大小时，我该怎么办？

管理不善的数据库表已经变得非常庞大。48+演出孤儿唱片。我正在尝试清理它并将我危险的满硬盘驱动器恢复到正常状态。我将从该表中删除大约 4 亿条记录。这是在我输入时运行。我注意到我的硬盘空间没有任何下降，但我看到系统表查询的内存下降，我正在运行以获取表大小。数据库正在使用“简单恢复模型”。

有很多与此类似的问题，回答说您需要缩小数据库。但是他们继续解释由于数据碎片等原因，这样做有多糟糕/可怕。

1. 由于数据库不应该是这个大小。缩小它对我来说还是不好的吗？
2. 这是一个生产数据库。如果我缩小它会导致停机或锁定数据库吗？
3. 在 SQL Server Management Studio 中，您有两个选项用于收缩、数据库或文件。鉴于我的情况，最好的选择是什么？
4. 是否有关于数据库应具有的可用空间百分比的规则？

甚至阅读shrink 的标签描述也让我不想这样做。还有其他方法吗？

我们已经从两位数 TB 大小的数据库中删除了大部分数据，现在想将一些空间释放回操作系统。数据库目前大约有 80% 的未使用空间。它永远不会再达到以前的大小（负载已转移到其他地方）。

我们尝试在单独服务器（非生产）上的数据库副本上运行 SHRINKDATABASE。运行 2 天（在我们的硬件上）它能够释放空间。

我假设生产中的数据库需要更长的时间，因为它被大量使用（尽管现在主要用于查询，插入较少）。

在生产系统上，只能接受数小时的停机时间（一次）。一些性能在长时间内下降也是可以接受的。

关于如何释放大量未使用空间，而不会造成过多停机时间或在此过程中导致严重性能下降的任何想法？

序言：总的来说，这是一个很大的禁忌，但相信我，在真正需要空间的情况下，这种情况很少见。例如 Express Edition 限制为 10GB。想象一下，您发现通过数据类型转换（blob 列）可以释放大量空间。但在那之后，DB 文件的大小仍然和我们知道的一样，10GB 的限制也没有神奇地改变。所以需要某种收缩。那是一个例子。

在我的测试环境中，我执行了：

DBCC SHRINKFILE (DBFile, NOTRUNCATE)
DBCC SHRINKFILE (DBFile, TRUNCATEONLY)

这确实有效（我知道这会最大限度地减少可用空间，在现实世界中我会留下可用空间）。花了很多小时才完成。正如我们所知，它是一个单线程进程奇怪的行为 DBCC Shrinkfile，“它作为一系列非常小的系统事务工作，因此没有什么可回滚的。” - 保罗兰达尔http://www.sqlservercentral.com/Forums/Topic241295-5-1.aspx。我们也知道它搞乱了索引碎片时间http://www.mssqltips.com/sqlservertip/2055/issues-with-running-dbcc-shrinkfile-on-your-sql-server-data-files/和我可以确认。尽管在http://www.karaszi.com/SQLServer/info_dont_shrink.asp 中有描述，但我没有遇到日志文件增长

我发布了一些INDEX REBUILD，REORGANIZE而那些在几秒钟内就完成了。

我的问题：

1. 如果我可以在收缩后几秒钟内修复索引碎片，那么收缩有什么大不了的？我不明白。在 DBA stackexchange 上，“收缩”主题 ( https://dba.stackexchange.com/tags/shrink/info ) 说“几乎是您可以对 SQL Server 数据库做的最糟糕的事情。简而言之：它牺牲了性能来获得空间。” plus 指的是另一篇关于它的流行文章。但是索引碎片是可以修复的。
2. 为什么我没有遇到任何日志文件增长？
3. 如果在空间释放操作后首先重建索引会怎样。可以代替第一个DBCC SHRINKFILE (DBFile, NOTRUNCATE)所以我只需要DBCC SHRINKFILE (DBFile, TRUNCATEONLY)吗？我有一种感觉，两者在不同的逻辑层面上工作，但我不得不问这个。

底线：我保证我不会定期收缩或做任何事情。但这是一个上限被击中并需要收缩的情况。

回答我的第二个问题：我没有遇到事务日志文件增长，因为我在开发人员测试环境中摆弄。事务日志文件会在生产环境中增长（假设完全恢复模型）。您也应该在您的测试环境中模仿它。tr 日志文件的增长实际上大于您可以在数据库文件中释放的空间。最后，您不仅要收缩数据库文件，还要收缩事务日志（如何以及何时这样做取决于恢复模型）。我看到的生产环境有如此严重的索引碎片，它可以变得更好。我的脚本重新索引每个碎片级别高于 30% 的索引。

为了应对增长，您可能必须在进行一生一次的转换时从完全恢复切换到简单。但这会破坏备份链。

回答我的第三个问题：在 DB 文件收缩后进行重新索引/索引重建，因为收缩会弄乱索引碎片。

我还没有试验过所有这些如何影响查询统计信息。

脚本重新索引：见实施例d的TechNet sys.dm_db_index_physical_stats（的Transact-SQL） 。一篇关于增量收缩的文章，会引出其他有价值的内容：http : //www.mssqltips.com/sqlservertip/3178/incrementally-shrinking-a-large-sql-server-data-file-using-powershell

我们有一个 SQL Server 2012 Enterprise 实时事务数据库，现在每月增长超过 1G，并且对我们来说已经成为一个大小问题。目前是23G。字符类型字段都是 Unicode，我已经计算出节省了 5G 的空间，将 2 个这样的字段平均每个 206 个字符转换为非 Unicode，如果我们将它们中的一些从 nchar 和 nvarchar 转换为 char 和几乎 10G 的空间varchar 类型。这些字段永远不需要保存不能在 SQL_Latin1_General_CP1_CI_AS 归类中的 Unicode 字符，因为它们最初是作为纯 ASCII 出现的，并且将始终按照协议标准这样做。

我是软件架构师和首席 C# 开发人员，尽管我只是一个 DBA 黑客，否则我不会将我们的数据库设计为具有用于大容量表的 Unicode 字段，而在 3 年前创建数据库时，这些字段不需要 Unicode。在我们最终转换到 AlwaysOn 环境以帮助解决各种性能和备份问题之前，我现在想纠正这个错误。

在缩小这两个或更多字段后，我们希望将数据库缩小一次，以利用节省的空间进行完整备份，并为 AlwaysOn 环境做种。

问题是——

1. 将列从 nchar/nvarchar 缩小到 char/varchar 类型的最安全和最有效的转换技术是什么？特别是 当同一个表中有多个字段需要转换时。我测试了我想从 nvarchar(max) 转换为 varchar(max) 的两个主要字段的“添加新列，设置新=旧，删除旧，重命名旧到新”，并且花了 81 分钟我们的测试服务器（4 个虚拟核心，8G 内存）在磁盘空间耗尽之前，即使磁盘上还剩下 8G，并且数据库设置了无限大小（无法为对象“dbo.abc”分配空间。“PK_xyz”在数据库 'xxx' 中，因为 'PRIMARY' 文件组已满）。在收到磁盘警告后，我确实在完成之前删除了一个旧数据库，所以它可能没有计算新空间。无论如何，它太慢了。这只是在这些列中最大的两列（12.6M 行）上，并且只运行 2% 到 3% 的 CPU 繁忙，因此看起来效率不高，并且如果我们甚至要转换这两个字段而不是任何附加字段，则表明停机时间是不可接受的。这两个字段的平均字段大小仅为 206 个字符或每个 412 个字节。我计划尝试的另一种技术是在新模式中创建新表 def，从旧表中选择它，然后在模式之间移动表并删除旧表。我在桌子上有一个 FK 和索引要处理。我计划尝试的另一种技术是在新模式中创建新表 def，从旧表中选择它，然后在模式之间移动表并删除旧表。我在桌子上有一个 …

我们有一个归档过程，其中我们对当前数据库进行备份并将其恢复为 xxx 归档数据库。现在这个数据库包含以前的数据，不会有任何插入/更新/删除。

由于此数据库仅用于报告，我们正在考虑缩小数据库。但是，这会增加索引碎片。我们正在考虑以下步骤：

1. 通过重新组织缩小数据库
2. 重新组织索引

这会影响数据库性能吗？我们还可以考虑哪些其他选择来恢复空间？

更新：在此过程中，我们将恢复模式改为simple，备份数据库，将数据库移出Pseudo-Simple状态，然后计划收缩数据库。

我们有一个 120GB 的数据库。有一个包含 60GB 数据的表，这是无用的，我们已经截断了它。

现在数据库大小为 120GB，可用空间为 60GB。数据库至少在 3 个月内不会增长到 60GB。所以我们可以缩小数据文件。

我知道碎片问题。我可以重建我的索引，因为我们的不是 24*7 的数据库。

请建议缩小MDF文件

我所在的团队开发使用多个 SQL Server 数据库的产品。其中一些大多是只读的。表不会更改，但作为配置应用程序的一种方式，某些视图和存储过程会更改。这些视图缺少索引。它们不是物化视图。对表的更改仅在升级期间发生，并且涉及向客户端发送附加的新 MDF。我应该执行哪些步骤来使这些数据库处于“发货就绪”状态？更新请注意，这些 MDF 中有大量可用空间，因此会收缩，然后重新索引。

我们目前正在做以下工作：

• 数据库处于简单恢复模式（我们通常建议保留 MDF 的原始副本作为备份）
• 我们将数据库归为 sa 并删除所有登录名（部署过程添加适当的登录名）
• 我们DBCC SHRINKDATABASE在数据库上运行

• 我们运行Ola Hallengren 的完整性和维护脚本：

  EXECUTE dbo.DatabaseIntegrityCheck
      @Databases = 'DB_IN_QUESTION',
      @CheckCommands = 'CHECKDB',
      @ExtendedLogicalChecks = 'Y',
      @TabLock = 'Y'
  GO
  
  EXECUTE dbo.IndexOptimize
      @Databases = 'DATABASE_IN_QUESTION',
      @FragmentationLow = NULL,
      @FragmentationMedium = 'INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
      @FragmentationHigh = 'INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
      @FragmentationLevel1 = 5,
      @FragmentationLevel2 = 30,
      @SortInTempdb = 'Y',
      @MaxDOP = 0
  GO
  

  Run Code Online (Sandbox Code Playgroud)

我们应该为 Ola 的脚本使用其他参数吗？我们是否应该采取任何其他措施？将数据库设为只读会很麻烦，因为视图和存储过程经常由最终用户修改。

我在 SQL Server 2008 R2 Express上运行一个相当大的数据库。最近我达到了 10GB 的限制，所以系统不允许我创建更多的对象，等等。

我已经归档了大量记录，大约是那里数据的四分之三。

数据库文件仍然在 10GB 左右，我想知道是否需要做任何事情来释放 SQL Server 中的可用空间。

我需要收缩 SQL Server 2012 中的数据文件。我在数据库任务中使用收缩文件选项，并使用“在释放未使用空间之前重新组织页面”选项。SQL Server 说我可以将文件缩小到 350000 MB 的最小大小。如果我尝试将其缩小到 300000 MB 会发生什么，这会从数据库中删除数据吗？简单来说，如果我缩小文件超过文件的最小大小，它是否会从文件中删除数据？

我正在使用 500 GB 的 SQL Server 数据库。在删除大量 (50%) 数据后，我需要减小数据库数据文件的大小。

我尝试重新建立索引，数据库已经碎片化了，这很好。但是数据库大小并没有减少。

我不准备使用收缩数据库。我已经尝试过压缩和 DBCC UpdateUsage 但没有增加空间。请告诉我任何其他减少数据库大小的方法。

我们的客户不允许我们将数据库脱机。缩小数据库可能需要 5 小时，然后重新索引将需要 3 小时，因此总共需要 8 小时的停机时间。我正在寻找一种无需停机的解决方案。

我的生产服务器的数据库意外增长，我几乎要创建一个作业来缩小每月运行一次的数据库。这是个好主意吗？

备份失败并且记录了大量事务的失败时间，这使数据库迅速增长。

我正在使用 SQL Server 2008 R2。

我是DB Administration 的新手。所以我对 SQL Server Management Studio (SMSS) 或通过 T-SQL 提供的“文件收缩”功能感到困惑。如果我可以简单地降低数据库的初始大小，为什么我需要使用“文件收缩”功能？

我试图（编辑）减少我的数据库的初始大小，它成功地减少了我的数据库物理文件。如果我使用“收缩”功能，这也将完全相同。