数据库收缩，备份，然后恢复
我理解为什么收缩
是不可取的
我只是为了避免陷入那次谈话..。所以，我有1.4tb数据库。大约700 is是免费的。这是因为人们一直在不负责任地复制数据，从来没有清理过。换句话说，这是应该回收的空间。
在某些情况下，由于正在进行的许多并发开发工作，我需要在同一服务器上恢复这个数据库的3-4个副本。在这种情况下，700 4x的垃圾乘以3x-4倍。因此，我一直在将数据库还原到DBA服务器，然后收缩，然后备份要分发到较低环境的文件。但是，一旦恢复了700 to的数据库，它就会将备份扩展到1.4tb。我想，也许文件的“初始大小”就是这样做的，但是当进行备份时，初始文件大小是很小的。
作为一种解决办法，我们正在删除文件并进行整合。有7个数据文件，我们要删除其中的2个。我宁愿避免这种情况，并试图弄清楚为什么数据文件正在膨胀。
回答 3
Database Administration用户
发布于 2020-09-11 18:58:25
还原的数据库将具有与生成备份时相同的文件大小。
我有时称这些文件为“容器”。同样数量的容器和相同的尺寸。但是，它们不必位于相同的位置(还原命令的MOVE选项)。
我不知道你所指的“初始”是什么，但不管它是什么，它可能会误导你--它也不会改变我上面提到的事实。:-)
因此，如果您备份一个有100 GB文件的数据库，那么在还原该备份时，该文件将是100 GB。如果你看到了其他的东西，那么你可能是在一个平行的宇宙中。或者你需要非常具体，所以我们会百分之百地关注正在发生的事情。这里有一件事是有用的:恢复HEADERONLY和恢复FILELISTONLY。后者将告诉您还原时文件的大小。
Database Administration用户
发布于 2020-09-11 20:48:22
有时，由于高fragmentation.Check (每个数据文件中的空闲空间)，数据库可能很大，如果您认为您有更多的免费space..you，则可以用于缩小数据库(这根本不是一个最佳实践)。但是，如果您执行so..make操作，则确保您正在运行重建索引并更新统计作业，以便将您从任何与性能相关的问题中拯救出来。
Database Administration用户
发布于 2020-09-11 21:13:32
但是，一旦恢复了700 to的数据库，它就会将备份扩展到1.4tb。
将700 see的数据库还原到目标环境后，限制文件的增长并查看发生了什么破坏。
还要评估列存储索引和SQL 2014的升级。在SQL 2016及更高版本中，列存储与非聚集、唯一和非唯一索引兼容，而非聚集列存储索引是可更新的。
https://dba.stackexchange.com/questions/275389
复制相似问题
腾讯云开发者
