我还在有限的空间里使用一张这种大小的大桌子。有几种方法可以解决它。但是您必须小心,您可能会因为物理空间不足而遇到错误,这可能会导致 SQL 崩溃。执行这些操作时,请密切注意磁盘可用空间和日志文件大小及其增长速度。取消任何可能导致磁盘用尽的操作(最好在您越过不归路之前,因为取消过程也需要时间)。我要检查的第一件事是,您的数据库恢复模型设置为完整还是简单?设置为 Simple 有助于减少日志记录和使用宝贵的临时空间。
当您处理非常有限的空间时,您当然需要注意数据库和日志文件的大小。我知道我要提出的建议通常不受欢迎,但有时这是不可避免的。在尝试下一个解决方案时,尝试使用 DBCC SHRINKFILE() 使 DB 和日志文件尽可能低。确保正确计算 DB 实际使用了多少空间,并留出一点填充空间。
--Check free space in a file
USE DMS_DataCompare;
SELECT name ,size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS int)/128.0 AS AvailableSpaceInMB
FROM sys.database_files;
USE tempdb
DBCC SHRINKFILE (tempdev,1)
DBCC SHRINKFILE (templog,1)
USE Master;
DBCC SHRINKFILE (N'MASTER',10000)
DBCC SHRINKFILE (N'MASTER_log',NOTRUNCATE)
解决此问题的一种方法是逐列。可以删除之前数据表的任何部分吗?如果是这样,您可以添加与您尝试迁移到的架构具有相同规格的列,然后使用 UPDATE 将数据从旧列复制到新列,然后删除旧列,然后执行收缩文件。冲洗并重复。
要尝试的另一件事是,是否有任何数据列包含您不需要的数据?你可以将它们清空,做一个收缩文件,这将恢复一些宝贵的移动空间。
另一种方式是评论者发布的内容,设置视图以强制数据通过您需要的数据类型和大小。我认为你应该先试试这个,因为它使整个过程只读,所以你不会弄乱文件大小和日志记录。您还可以编写一个类似于视图的过程,该过程接受两个参数,启动和停止,可用于指定要拉取的范围。然后可以在导出步骤中使用它。
正如 user1443098 发布的那样,批量导出,不是作为一个过程,而是作为一个简单的脚本。但这可能很难跟踪,尤其是在尝试导出平面文件时,因为您可能很快就会迷失在哪个文件中包含的确切范围,可能会根据它所包含的范围命名您的文件。如果您的数据当前处于活动状态且不断变化,则此选项可能无用。
另一种选择是备份数据库并将其恢复到有空间的机器上。通过备份压缩后,数据库备份的大小可以是正常大小的 1/10(如果您有支持此功能的 SQL 版本)。
另一个是上述两种情况的组合。使用目标规范创建一个表,然后编写一个脚本以从旧表插入到新表中,但要分批。在每批之后,从旧表中删除相同的范围,然后做一个收缩文件。确保首先验证所有数据已成功复制到新表中!不过,这个过程可能会非常漫长,因为所涉及的每个步骤都需要时间。
希望这有帮助,祝你好运!