web-dev-qa-db-ja.com

データベースバックアップを復元すると、ID列が再び1から始まります。

SSMS 2012でデータベースのバックアップを作成しました。すべてのデータを含むフルバックアップとしてTasks-> Backupを使用しました。

別のサーバー（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]
_

なぜこれが発生し、ID列が適切に復元されるようにすべてのデータを含めてデータベースを転送するにはどうすればよいですか？

バックアップファイルには、DataエントリとLogエントリの2つのセットのみが含まれています。

ソースサーバーでdbcc checkident('accounts', noreseed)を実行すると、_Checking identity information: current identity value '2816', current column value '2816'._が生成されます。ターゲットサーバーでは、現在の列の値として_1_が返されます。

sql-serversql-server-2012backuprestoreidentity
4
F.P

サーバー管理者とさらに掘り下げたところ、問題はSchemasであることが判明しました。ソースサーバーでは、すべてのテーブルが特別なスキーマ内にありました。それをCustomと呼びましょう。データの操作とバックアップの作成に使用したログインがこのスキーマに割り当てられ、デフォルトとして使用されました。

データベースをターゲットサーバーに転送すると、ユーザーは移動しましたが、ログイン（サーバーレベルで保存）は移動しませんでした。そのため、管理者はそれに沿って、ユーザーに一致する新しいログインを作成しました。ユーザーが既に存在し、SSMSが新しいログインを作成するときにデータベースにユーザーを作成しようとしたため、これは機能しませんでした。

そのため、彼はユーザーを削除し、新しいログインとともに作成しましたが、デフォルトのスキーマをCustomに設定していませんでした。

つまり、何らかの理由でそのログインを使用したクエリと接続では、テーブルの定義は確認できましたが、内部のデータは確認できませんでした。これには、ID列も含まれているようです。

そこで、新しいユーザーをCustomスキーマを使用するように切り替え、すべてが期待どおりに機能するようになりました。

2
F.P