備份 SQL 2008 數據庫，然後進行恢復，得到一個 SQL 2005（兼容級別 90）數據庫

我們在 SQL Server 2008（不是 SP2 - 不要問我為什麼）數據庫伺服器上有四個不同的數據庫，它們有一個奇怪的問題。

從 sys.databases 中列出時，這些數據庫報告它們的兼容性為 SQL Server 2008/R2（兼容性級別 100），如下面的這三個 DB 所示：

MyDB_Name               100 SQL Server 2008/R2
MyDB_Name_MirrorTables  100 SQL Server 2008/R2
MyDB_Name_Reporting     100 SQL Server 2008/R2

作為此查詢的輸出：

select 
   name, compatibility_level , version_name = 
   case compatibility_level
       when 90  then 'SQL Server 2005'
       when 100 then 'SQL Server 2008/R2'
       when 110 then 'SQL Server 2012'
       else 'unknown - ' + convert(varchar(10), compatibility_level)
   end
from sys.databases

從伺服器上其他使用者 DB 的備份中恢復時，將正確恢復為兼容級別 100。但是，從備份中恢復這四個 DB 時，將恢復為兼容級別 90 (SQL Server 2005)。只有這四個數據庫似乎有這個問題。

為了測試這一點，我手動備份了其中一個數據庫，只INIT, SKIP指定了選項。然後我將此備份恢復到 SQL Server 2012 伺服器。恢復後，數據庫經歷了從版本 655 到 706 的升級過程。沒有發生異常情況。

但是，在查看 SQL Server 2012 上的兼容性級別時，使用與上面相同的程式碼，資訊顯示為：

bwh_MyDB_Name_MirrorTables  90  SQL Server 2005

此外，當恢復到使用不同名稱的原始 SQL Server 2008 數據庫伺服器時，數據庫仍會返回數據庫版本的 SQL Server 2005（兼容級別 90），即使它與兼容級別 100 備份在同一台伺服器上。

最後，雖然數據庫報告為 SQL Server 2008，但當從 DB2 連結伺服器返回日期列時，查詢返回一個datetime（時間為 00:00:00.000）。在 SQL Server 2012 中執行查詢，該值作為Date數據類型返回，這與在 SQL Server 2008/R2 數據庫中應該返回的一樣。

在我最後的測試中，我向包含一個date和一個time欄位的數據庫添加了一個測試表，並插入了一行數據。然後我再次備份並恢復了數據庫。儘管兼容級別為 90，但該表工作正常。我還創建了一個沒有問題的表，其中包含date、time和datetime2欄位。

我不知道下一步該往哪裡看。日期/日期時間問題是查看此問題的最初觸發因素，但它已成為一個更大的難題。顯然，我可以簡單地將傳入的數據轉換為日期值（這確實有效，很奇怪），但這並不能解釋 RESTORE 將數據庫返回到兼容級別 90，或者 DB2 查詢返回日期時間而不是日期連結伺服器。任何建議都會很樂意接受。

免責聲明

此資訊按原樣提供。它可能會幫助您找到根本問題。

雖然我沒有解決為什麼您的數據庫在還原期間轉換回某個級別的原因，但我可能能夠闡明為什麼還原可能認為它必須重置兼容級別。

DBCC 數據庫資訊

你可能想看看這個DBCC DBINFO命令。

DBCC DBINFO('<Your_DB_Name>') WITH TABLERESULTS

看看以下幾行：

ParentObject      | Object                     | Field             | VALUE
------------------+----------------------------+-------------------+--------
DBINFO STRUCTURE: | DBINFO @0x000000003609D5E0 | dbi_version       |  782
DBINFO STRUCTURE: | DBINFO @0x000000003609D5E0 | dbi_createVersion |  705
DBINFO STRUCTURE: | DBINFO @0x000000003609D5E0 | dbi_cmptlevel     |  110

雖然您的數據庫可能看起來處於某個級別，但在內部它可能仍在培養較低級別，這可能是還原設置較低兼容性級別的原因。

DBCC 頁面

DBCC DBINFO您可以使用同樣未記錄的DBCC PAGE命令，而不是使用：

DBCC TRACEON(3604)
DBCC PAGE('<Your_DB_Name>',1,9,3)

語法在哪裡

DBCC PAGE('DATABASE_NAME' | DB_ID, <FILE_ID>, <PAGE>, <LEVEL_OF_DETAILS>)

向下滾動一點，你會發現：

...
dbi_version = 782                   dbi_createVersion = 705             dbi_SEVersion = 0
dbi_dvSplitPoint = 0:0:0 (0x00000000:00000000:0000)                      
dbi_dbbackupLSN = 96:512:1 (0x00000060:00000200:0001)                    
dbi_LastLogBackupTime = 2018-11-22 09:15:01.473                          
dbi_nextseqnum = 1900-01-01 00:00:00.000                                 dbi_status = 0x00010000
dbi_crdate = 2012-03-14 13:14:18.510dbi_dbname = AdventureWorks2012     dbi_dbid = 9
dbi_cmptlevel = 110                 dbi_masterfixups = 0                dbi_maxDbTimestamp = 10000

驗證數據庫備份版本

現在由於某種原因，您的系統可能正在創建較低級別的備份。您可以使用以下命令驗證您的備份：

RESTORE HEADERONLY FROM DISK='B:\BACKUP\DATABASE_BACKUP.bak' 

這將返回備份文件的數據庫版本：

數據庫版本 | 兼容性等級 | 軟體版本專業 | 軟體版本次要 | 軟體版本建構
----------------+--------------------+----------------------+----------------------+----------------------
782 | 110 | 12 | 0 | 5590

資訊輸出已縮短

數據庫備份是否與執行的 SQL Server 版本處於同一級別？

要問自己的問題

• 我們是否使用第三方備份工具？
• 我們是否使用不同的伺服器來創建備份？
• 我們是否在使用其他可能會干擾備份的工具？

結論

您可能剛剛遇到了您正在使用的 SQL Server 版本的錯誤以及dbi_version與dbi_createVersion資訊有關的數據庫內部問題，這導致兼容性級別設置低於您的預期。

-或者-

您可能會遇到使用低級兼容性級別創建的數據庫備份文件的問題，因為…

• 一些第三方問題

• 備份中的dbi_version和/或dbi_createVersion不同的，因為，….

  • 一個錯誤
  • 第三方問題

我們發現了一種解決方法，可以提供有效的答案，儘管它無法回答問題的原因。

問題 TL;DR

1. 備份數據庫（兼容級別 100，在 SQL Server 2008 伺服器上）
2. 還原數據庫（到任何伺服器 - 2008、20012，包括備份的同一台伺服器。）
3. 檢查兼容級別，顯示為兼容級別 90（例如 SQL 2005）

解決方案 TL；DR

1. 備份數據庫
2. 將數據庫還原到 SQL Server 2008 伺服器（同一伺服器上的新名稱）
3. 將恢復的數據庫的兼容級別設置為 100 (SQL 2008)
4. 備份最近恢復的數據庫
5. 從新數據庫恢復新備份
6. 瞧 - 恢復的數據庫處於兼容級別 100

注意：我們嘗試重置原始數據庫的兼容級別，但沒有效果 - 重置為 2005 (90)，退出，重新進入，重置為 2008，退出，重新進入，備份，恢復。恢復的 DB 以兼容性 90 的形式出現。開始拔毛。

引用自：https://dba.stackexchange.com/questions/222389