從 SQL Server 2012 Exterprise 遷移到 SQL Server 2012 Express 後，數據庫 BackupSize 已更改
我想說的是，在將 MS SQL Server 2012 Enterprise 遷移到 MS SQL Server 2012 Express 之後。我已經看到數據庫備份大小以及所有數據庫的**“LSN”存在一些細微的差異。**
讓我們從頭開始，我將一步一步地寫下來。我在從 MS SQL Server 2012 Enterprise 遷移到 MS SQL Server 2012 Express 的過程中做了什麼。
- 我已於 2015 年 12 月 23 日在 MS SQL Server 2012 Enterprise 中備份了所有 3 個審計數據庫。MS SQL Server 2012 企業版是
Microsoft SQL Server 2012 (SP1) - 11.0.3000.0 (X64) Oct 19 2012 13:38:57 Copyright (c) Microsoft Corporation Enterprise Edition (64-bit) on Windows NT 6.2 <X64> (Build 9200: ) (Hypervisor)
- 從 MS SQL Server 2012 Enterprise 成功遷移到 MS SQL Server 2012 Express 後。恢復了 MS SQL Server 2012 Express 中的所有 3 個數據庫。截至 2015 年 12 月 24 日，所有 3 個數據庫都已成功恢復。MS SQL Server 2012 Express 版本是
Microsoft SQL Server 2012 (SP1) - 11.0.3000.0 (X64) Oct 19 2012 13:38:57 Copyright (c) Microsoft Corporation Express Edition (64-bit) on Windows NT 6.2 <X64> (Build 9200: ) (Hypervisor)
- 經過幾天的工作，我已於 2015 年 12 月 31 日對 MS SQL Server 2012 Express 中的所有 3 個審核數據庫進行了完整備份。
4）我自己用“LSN”和DatabaseSize檢查數據庫的一致性。我瀏覽過很多 SQL 部落格以及 MSDN BOL。並找出鏈中缺少的事務日誌，可以跳過和http://blogs.msdn.com/b/sqlserverfaq/archive/2010/08/26/transaction-log-backup-and-restore-sequence-myths- amp-truths.aspx用於檢查日誌鏈的“LSN”一致性。
- FROM This TSQL to check ‘first LSN’ and ‘Last LSN’ and log swquence
Restore headeronly from disk =N'C:\Backup\AuditDatabase1_23122015.bak' Restore headeronly from disk =N'C:\Backup\AuditDatabase2_23122015.bak' Restore headeronly from disk =N'C:\Backup\AuditDatabase3_23122015.bak'– 以上 3 個數據庫備份已在 Enterprise 中進行（截至 2015 年 12 月 23 日）–
具體從數據庫 1 到 3 分別如下。
BackupSize FirstLSN LastLSN CheckpointLSN DatabaseBackupLSN 243532800 571000000388500000 571000000390600000 571000000388500000 571000000372500000 92480512 671000000080800000 671000000082900000 671000000080800000 671000000064900000 57824256 495000000001600000 495000000002600000 495000000001600000 494000000027300000並且還檢查了所有 3 個審計數據庫的 Express 完整備份，我在 2015 年 12 月 31 日進行了完整備份
Restore headeronly from disk =N'C:\Backup\AuditDatabase1_31122015.bak' Restore headeronly from disk =N'C:\Backup\AuditDatabase2_31122015.bak' Restore headeronly from disk =N'C:\Backup\AuditDatabase3_31122015.bak'具體從數據庫 1 到 3 分別如下。
BackupSize FirstLSN LastLSN CheckpointLSN DatabaseBackupLSN 243401728 571000000558800000 571000000560900000 571000000558800000 571000000478100000 91956224 674000000027800000 674000000029900000 674000000027800000 672000000043600000 57627648 498000000013500000 498000000016700000 498000000013500000 496000000028600000對於所有 3 個數據庫組合，我正在編寫詳細資訊。如下
Databases Backup in BackupSize FirstLSN LastLSN CheckpointLSN DatabaseBackupLSN (1 DB in Enterprise) 243532800 571000000388500000 571000000390600000 571000000388500000 571000000372500000 (1 DB in Express) 243401728 571000000558800000 571000000560900000 571000000558800000 571000000478100000 (2 in Enterprise) 92480512 671000000080800000 671000000082900000 671000000080800000 671000000064900000 (2 in Express) 91956224 674000000027800000 674000000029900000 674000000027800000 672000000043600000 (3 in Enterprise) 57824256 495000000001600000 495000000002600000 495000000001600000 494000000027300000 (3 in Express) 57627648 498000000013500000 498000000016700000 498000000013500000 496000000028600000在這裡，我採用了 TSQL 查詢結果的一些細節來了解 DatabaseSize 和**‘First LSN’** & ‘Last LSN’。在上表中有各自的數據庫比較結果，您可以在表中看到。
希望我清楚地理解你。我的意思是說關於所有 3 個數據庫的日誌序列號檢查。
我怎麼能理解我已經用一致的“LSN”恢復了我的數據庫。
任何建議將不勝感激。
假設遷移到 Express Edition 後數據量沒有發生重大變化，那麼最簡單的解釋就是備份壓縮。Express Edition 不支持備份壓縮。此外，如果預設啟用它，您可能已經在企業伺服器上使用它，甚至沒有註意到。
您報告的範例和數據不足以回答您的問題，但您可以考慮以下幾點：
- 執行備份時，您必須確定數據庫中保留的空間量。您可以執行以下操作獲得此大小：
使用 exampledb GO EXEC sp_spaceused @updateusage = ’true’
在命令的輸出中，您可以閱讀一個名為“reserved”的部分。這是您數據庫中數據的實際大小。您的備份 p 的大小將達到這個大小。
- 此外，您還必須考慮完整備份中包含的事務日誌記錄：數據庫備份中包含的日誌的起始 LSN 是以下各項中的最小值：最後一個檢查點的 LSN，最早的活動事務開始的 LSN，最舊的活動事務的 LSN最後複製的事務。這可以修改備份的大小。