恢復數據庫備份使標識列再次從 1 開始

我在 SSMS 2012 中創建了我們數據庫的備份，使用任務->備份作為完整備份，包括所有數據。

當我在另一台伺服器（2012 年）上恢復此備份時，所有identity列都重置為從 1 開始，這反過來又弄亂了應用程序使用的 ORM 庫（NHiberate）。

一個例子是accounts表格。在我恢復它並創建一個新帳戶後，該帳戶的 ID 以 1 開頭，雖然在我備份的生產系統上，ID 高達 2000 或什麼的。

CREATE TABLE [accounts](
   [id] [int] IDENTITY(1,1) NOT NULL,
   [name] [nvarchar](255) NULL,
   [password] [nvarchar](255) NULL,
   [passwordSalt] [nvarchar](255) NULL,
PRIMARY KEY CLUSTERED 
(
   [id] ASC
) WITH (PAD_INDEX = OFF,
   STATISTICS_NORECOMPUTE = OFF,
   IGNORE_DUP_KEY = OFF,
   ALLOW_ROW_LOCKS = ON,
   ALLOW_PAGE_LOCKS = ON,
   FILLFACTOR = 90) ON [PRIMARY],
UNIQUE NONCLUSTERED 
(
   [name] ASC
) WITH (PAD_INDEX = OFF,
   STATISTICS_NORECOMPUTE = OFF,
   IGNORE_DUP_KEY = OFF,
   ALLOW_ROW_LOCKS = ON,
   ALLOW_PAGE_LOCKS = ON,
   FILLFACTOR = 90) ON [PRIMARY]
) ON [PRIMARY]

為什麼會發生這種情況？如何傳輸數據庫，包括所有數據，以便正確恢復身份列？

備份文件只包含兩組，Data和Log條目。

dbcc checkident('accounts', noreseed)在源伺服器上執行產生Checking identity information: current identity value '2816', current column value '2816'.在目標伺服器上，它1作為目前列值返回。

與伺服器管理員進行的更多探勘發現問題出在Schemas上。在源伺服器上，所有表都在一個特殊的模式中，我們稱之為Custom。我用來操作數據和創建備份的登錄名已分配給此模式並用作預設值。

將數據庫傳輸到目標伺服器會帶來使用者，但不會帶來登錄名（儲存在伺服器級別）。所以管理員繼續創建了一個與使用者匹配的新登錄名。這不起作用，因為使用者已經存在並且 SSMS 在創建新登錄時嘗試在數據庫中創建使用者。

所以他刪除了使用者，將其與新登錄名一起創建，但沒有將預設模式設置為Custom。

這意味著出於某種原因使用該登錄名的任何查詢和連接都看到了表定義，但看不到其中的數據 - 顯然這也包括身份列。

因此，我們將新使用者切換為使用自定義模式，現在一切都按預期工作。

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