Questions tagged «shrink»

您几乎可以对SQL Server数据库做的最坏的事情。简而言之：它牺牲性能来获得空间。

4
为什么事务日志持续增长或空间不足？
在大多数论坛和整个网络中，这似乎是一个常见问题，在这里以多种格式询问，通常听起来像这样： 在SQL Server中- 事务日志变得如此之大的一些原因是什么？ 为什么我的日志文件这么大？ 有什么方法可以防止出现此问题？ 当我使自己的潜在原因步入正轨并希望将事务日志文件调整为正常大小时，该怎么办？
8
如何快速缩小所有数据库的所有文件？
在SQL Server（在本例中为2008）中，如何快速缩小实例上所有数据库的所有文件（日志和数据）？我可以遍历SSMS，然后右键单击每个，然后选择“任务”->“收缩”，但是我正在寻找更快的东西。 我编写了一些“创建数据库”脚本的脚本，但忘记了它们具有默认值的膨胀大小，并且在此项目中不需要为这些文件保留太多的空间。
5
什么时候可以收缩数据库？
我知道收缩是魔鬼：它会颠倒页面顺序，并导致皮肤癌，数据碎片和全球变暖。清单还在继续……也就是说，我有一个100 GB的数据库，我删除了50 GB的数据-不是在一个表上，而是在数据库范围内对旧数据进行一般修剪，覆盖了90％的数据。表-这是否构成缩小数据库的合适用例？ 如果不是，那么从数据库中删除如此高的数据百分比后，应采取哪些适当的步骤来清理房屋？我可以想到两个：重建索引和更新统计信息。还有什么？
4
我需要缩小数据库-我刚刚释放了很多空间
这里以各种形式提出了这个问题，但问题归结为： 我知道缩小数据库是有风险的。在这种情况下，我已经删除了太多数据，并且永远不会再使用它。 如何缩小数据库？我可以缩小哪些文件？ 这样做时我应该考虑什么？ 之后我应该做什么？ 如果是大型数据库怎么办？我可以缩小一点吗？
1
在生产环境中收缩Tempdb的最佳实践
此问题是从Stack Overflow 迁移而来的，因为可以在Database Administrators Stack Exchange上回答。 迁移 5年前。 在SQL Server 2008中收缩Temporary db时，最佳做法是什么？ 使用以下内容有风险吗？ use tempdb GO DBCC FREEPROCCACHE -- clean cache DBCC DROPCLEANBUFFERS -- clean buffers DBCC FREESYSTEMCACHE ('ALL') -- clean system cache DBCC FREESESSIONCACHE -- clean session cache DBCC SHRINKDATABASE(tempdb, 10); -- shrink tempdb dbcc shrinkfile ('tempdev') -- shrink …
6
缩小日志文件不会减小大小
我有一个数据库，该数据库具有350 MB数据文件（.mdf）和4.9 GB日志文件（.ldf）。恢复模型设置为FULL。 当我尝试收缩日志文件时，它没有收缩。 我知道收缩数据库是不好的，不应该这样做。但是我仍然在尝试缩小日志文件。 我跑的时候 DBCC SQLPerf(logspace) 我发现日志大小为4932 MB，使用的日志空间为98.76％！ 然后我尝试了这个命令 USE <databasename>; DBCC loginfo; 现在几乎所有的VLF均为“状态2”，这意味着所有VLF都在使用中。 我尝试进行日志备份，然后缩小日志文件。缩小并没有减小尺寸。 我将恢复模型更改为SIMPLE并尝试再次缩小，但这也无济于事。 我检查了未结交易 DBCC opentran (database); 并发现现在没有任何交易打开。 是什么阻止了我缩小日志文件？我该如何解决？
2
使用AlwaysOn可用性组时缩小事务日志
我们正在使用AlwaysOn Availability GroupSQL Server 2012的功能。每天在辅助数据库上进行常规的完整数据库备份和事务日志备份。 我在这里已经阅读了在主副本或辅助副本上执行事务日志备份的操作，会将这两个副本的事务日志标记为可重用。无论如何，事务日志备份的大小很大，可以使用收缩文件来减小它： 我已在本地还原数据库并执行收缩操作。日志文件大小减少到160 MB。 我的问题是我应该在哪个数据库上对事务日志文件（主，次或两者）执行收缩操作？ 我猜过去几年没有备份日志文件，因此它是如此之大。执行中，DBCC SQLPERF (LOGSPACE)我可以看到仅使用0.06%了该文件-对于我而言，保留如此大的日志文件毫无意义。在[sys].[database_files]我检查其max_size设置为-1与growth对65536，所以我想，当它需要更多的空间，它会得到。无论如何，为了防止将来的增长，我可以将其缩小到例如5％。我试图找到一些确认，我认为这样做不是一个坏主意。 实际上，备份（在数据库和日志文件上）仅在辅助数据库上执行，因此对它们执行收缩文件会更容易，但是主日志文件的大小也会减少吗？
4
删除表字段后声明磁盘空间
我正在运行sql 2008 r2，并且数据库在过去3年中运行良好且运行迅速，直到大约3个月前，我们在非常活跃和使用过的表上添加了ntext字段。现在，由于此表的巨大扩展空间，我们开始摆脱服务器空间。 我读到收缩，我们不想失去db的索引，因为它的工作速度已经快了很多年了，我们也不想让碎片化花费。 我们决定删除该字段及其所有值： 是否可以删除ntext字段及其所有值并释放空间，而又不删除索引，不缩小索引，不降低数据库性能？ 我附上数据库大小查询输出，以显示最近5个月的大小扩展。
1
SHRINKFILE失败-为什么增加文件大小可以解决？
我正在运行一些SHRINKFILE操作来清理文件组中的一堆微小的不必要文件。对于其中一种收缩，以下命令将导致错误： DBCC SHRINKFILE (N'myfile' , EMPTYFILE)' 无法缩小数据库ID x的文件ID x，因为它正在被另一个进程缩小或为空 它不是空的也不是收缩的。它正在除我以外的任何人当前未使用的数据库上运行。自动收缩功能未启用，也从未启用过。但是，如果真的很重要，在我开始使用该数据库之前，会定期对其进行手动收缩。 在SQLServerCentral上，十年前的一个线程建议在文件中添加一些MB，因为“重新设置内部计数器或开关会告诉它现在不在收缩中”。 这很有效-很棒。但是，谁能更详细地说明SQL Server内部的工作原理/原因？
3
数据库大小-MDF太大？
我正在维护一个SQL Server 2005数据库，该数据库承载大约2.9Tb的数据（2 x 1.45Tb-我具有RAW架构和Analysis架构，因此基本上是摄取的数据的两个副本）。恢复模型为SIMPLE，恢复模型为.ldf6Gb。 无论出于什么原因，它.mdf都是7.5Tb。现在，在Analysis表中可能只有2-3个附加列，NVARCHAR(MAX)而从我（可能是误解-如果我错了，请纠正我）可能导致额外的空间分配的列不多。那是在紧缩数据库之后-在此之前大约是9Tb。有什么想法吗？ 并且，如果您还有其他问题，请告诉我-我是数据库管理和优化工作的新手（我通常不做这方面的工作：）。 非常感谢！ 安德里亚
10
将数据库缩小到其初始大小以下
我有一个SQL Server 2005开发数据库，​​它是实时的30GB副本。我们删除了一些dev中不需要的数据，这使使用的数据文件空间减少到20GB。因此，我们约有33％的未使用。 我需要回收空间，这将允许我们在服务器上拥有第二个开发数据库（基于缩减版本）；但是，我无法回收空间，我做了以下工作： 文件的初始大小SMS2_Data为30GB。 DBCC SHRINKFILE (N'SMS2_Data' , 0, TRUNCATEONLY) 其次是 DBCC SHRINKFILE (N'SMS2_Data' , 19500) 不开心 我尝试进行备份，创建一个初始大小较小的新数据库，然后还原，但由于初始大小被覆盖而感到不高兴。也尝试过： ALTER DATABASE SMS2HazSub MODIFY FILE (NAME = 'SMS2_Data', SIZE = 20000) 这是错误的，说： 修改文件失败。指定的大小小于当前大小。 我尝试了20800，然后一直提高到29000（29GB），但仍然不允许我更改它。 完成收缩后，将恢复模式从更改FULL为SIMPLE，然后再次更改。不开心 我认为这与某些TEXT领域有关。我们整个系统中大约有6个。因此，作为测试，我将它们全部删除，然后缩小了文件，但仍然没有变化。 剩下的唯一选择是将数据重新导入到另一个数据库。这是不切实际的，因为必须在实时数据库上进行，因为这样做会带来很大的风险。我们半定期地获取实时数据库的副本并覆盖dev / test。我们有大约500张桌子。我想要一种不会将数据导出到新数据库的风险的方法。 我尝试将数据移动到另一个文件，它复制了除5％之外的所有数据。这就是导致我尝试删除所有文本列的原因。 服务器处于兼容模式90，但为SP2。我现在做了以下3次：重新索引所有表，备份数据库，收缩文件，收缩数据库。仍然没有喜悦。 EXECUTE sp_spaceused 返回： database_name database_size unallocated space SMS2Tests 31453.94 MB …
3
获取MS SQL Server释放磁盘空间
管理不善的数据库表已经变得非常庞大。48个以上的孤儿记录。我正在尝试清理它并将危险的满硬盘驱动器恢复到正常状态。我将从该表中删除大约4亿条记录。当我键入时，它正在运行。我注意到我的硬盘驱动器空间没有减少，但是系统表查询的内存减少了，我正在运行以获取表大小。该数据库正在使用“简单恢复模型”。 有许多与此类似的问题，有答复说您需要缩小数据库。但是他们继续解释由于数据等的分散，这样做是多么的糟糕/可怕。 由于数据库不应该具有此大小。缩小它仍然对我有害吗？ 这是一个生产数据库。如果缩小，会导致停机或锁定数据库吗？ 在SQL Server Management Studio中，您有两个选项用于收缩，数据库或文件。根据我的情况，最好的选择是什么？ 数据库应具有的可用空间百分比是否有规定？ 即使阅读了shrink的标签说明，我也不想这样做。还有另一种方法吗？
2
TempDB不会收缩。没有公开交易
我在SQL 2008上有一个TempDB，它已经变得很大（> 40gb），我想缩小它。我已经通过Management Studio使用了dbcc收缩数据库，dbcc收缩文件和收缩命令。 我收到以下错误： 页面1：4573184无法移动，因为它是工作表页面。 我已经能够通过运行DBCC FREEPROCCACHE并重新运行其中一个收缩例程来回收一些空间，使我摆脱危险，但是显然这不是理想的选择，可能只会给我带来一点时间。 我已经运行过DBCC OpenTran，那里没有东西挂。 我在Internet上阅读的所有内容都归结为回收SQL Server ...肯定有更好的方法...有人吗？ 谢谢， 汤姆
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.