SQL Server 数据库有非常小的备份

Question

我有一个 216 GB 的数据库。75% 被数据使用，剩下的被索引和日志使用。当我检查数据库文件中的可用空间时，我得到大约 300 MB 的值。数据库分为 3 个数据文件。当我在没有压缩的情况下进行完整备份时，我得到了 38 GB 的备份。

谁能解释一下？我可以从数据库中恢复任何磁盘空间吗？

更新：如果我尝试恢复备份，它需要超过 200 GB 的磁盘空间。

Update2：我通过运行获得了这些值：

select Name,
(convert(float,size)) * (8192.0/1048576) File_Size,
(convert(float,fileproperty(name,'SpaceUsed'))) * (8192.0/1048576) MB_Used,
((convert(float,size)) * (8192.0/1048576) - (convert(float,fileproperty(name,'SpaceUsed'))) * (8192.0/1048576)) MB_Free
from sysfiles
order by fileproperty(name,'IsLogFile')

结果是：

QASDATA1    74124   73383,75    740,25
QASDATA2    69548   69114   434
QASDATA3    72288   71972,6875  315,3125
QASLOG1 374,8203125 112,1015625 262,71875

更新 3：以下是有关备份本身的更多信息，查询如下：

QAS x:\sql\SQL42\QAS\QAS_log_20121030.BAK   51 MB   160 MB  7 Seconds   2012-10-30 01:00:00.000 16269000022730200001    16271000002874600001    Transaction Log SQL42   FULL
QAS x:\sql\SQL42\QAS\QAS_data_20121025.BAK  38820 MB    224903 MB   3458 Seconds    2012-10-25 09:55:16.000 16265000012013400138    16265000012581700001    Full    SQL42   FULL

Answer 1

正如保罗·兰德尔在他的MCM塔内的备份说明/还原为SQL Server，备份文件并没有要求在数据库中的空的空间在备份，但是在恢复备份时它确实需要它。备份文件基本上会指向在还原过程中重建空白空间时需要重新填充的位置。

数据库压缩与从备份中删除空白空间的工作方式不同。它使用更接近于 winzip 算法的东西。如果您要使用最大压缩率来 winzip/winrar/7zip 备份您的备份，您将获得与 SQL Server 本机压缩非常相似的空间使用情况。在 SQL Server 中使用它本机的好处之一是它需要更少的空间来写入磁盘，因此假设您的 CPU 没有固定，它会更快。

丹尼先生也是正确的，所以这可能是其中的一部分，因此我投票支持它。

Paul Randal 的 MCM 视频列表，包括提到的备份/恢复：http : //www.sqlskills.com/T_MCMVideos.asp

编辑： 重新阅读您的答案后，我想澄清一些差异，但上述信息仍然相关。

您有一个数据库，当您右键单击 DB、属性和使用的空间时，您会看到：可用空间：300MB SP_HELPDB 显示：216GB

运行：dbcc sqlperf('logspace')。对于与此 DB 相关的日志寿命，您会得到什么？请张贴你的发现。

请验证并回复我们。

/*
10/29/2012 Edit after posting findings & using block comment code to drive Buck Woody crazy:


Next, please run this, it will tell us everything about your backup right when SQL Server took it.  This modified script originally from Pinal will help us validate if something after the backup happened to the file, or if SQL Server really just spit out a small backup:
*/

USE [DatabaseName]

GO

SELECT TOP 100

s.database_name,

m.physical_device_name,

CAST(CAST(s.compressed_backup_size / 1000000 AS INT) AS VARCHAR(14)) + ' ' + 'MB' AS CompBkSize,

CAST(CAST(s.backup_size / 1000000 AS INT) AS VARCHAR(14)) + ' ' + 'MB' AS bkSize,

CAST(DATEDIFF(second, s.backup_start_date,

s.backup_finish_date) AS VARCHAR(4)) + ' ' + 'Seconds' TimeTaken,

s.backup_start_date,

CAST(s.first_lsn AS VARCHAR(50)) AS first_lsn,

CAST(s.last_lsn AS VARCHAR(50)) AS last_lsn,

CASE s.[type]

WHEN 'D' THEN 'Full'

WHEN 'I' THEN 'Differential'

WHEN 'L' THEN 'Transaction Log'

END AS BackupType,

s.server_name,

s.recovery_model

FROM msdb.dbo.backupset s

INNER JOIN msdb.dbo.backupmediafamily m ON s.media_set_id = m.media_set_id

WHERE s.database_name = DB_NAME() -- Remove this line for all the database

ORDER BY s.backup_start_date DESC, s.backup_finish_date

GO

发布最终结果后编辑：正如所料，您的备份已启用压缩。正如您在查询中看到的，压缩备份大小显示 38GB，而“备份大小”显示 228GB。查看您的备份脚本，您会在其中找到“WITH COMPRESSION”。

请记住影响备份大小的因素： -事务日志文件与 SQL Server 备份文件一起备份。这是用于恢复部分期间的重做/撤消操作。

- 数据页、GAM、SGAM 等都是备份文件。数据库中的空白空间被删除，只放置指针，因此如果您有大量可用空间，您的备份将保持很小。但是，当您恢复时将需要它。

- 压缩通常在 SQL Server 数据库中扮演一个巨大的工厂。最大的影响因素之一。

- 将备份文件分解为多个较小的文件显然也会影响大小。

如果您有任何问题，请告诉我们，但您最初关于小备份大小的问题已解决。