同じサーバーではなく新しいデータベースにbakファイルを復元できないようです。別のコンピューターで実行すると、正常に動作します。 SSMSを介してSQL Server 2012を使用しています。実行するたびに、存在しない宛先データベースであるにもかかわらず、データベースが使用中であるために排他的アクセスを取得できなかったと表示されます。
手順は次のとおりです。
これはエラーメッセージです。
データベース「DELVIPROD_JUNE」の復元に失敗しました。 (Microsoft.SqlServer.Management.RelationalEngineTasks)
追加情報:
データベースが使用中のため、System.Data.SqlClient.SqlError:排他アクセスを取得できませんでした。 (Microsoft.SqlServer.SmoExtended)
Management Studioの右側にあるすべてのタブを閉じて、再試行してください。データベースをクリックして、右側のいくつかのタブがデータベースにアクセスしている可能性があります。
または、このsqlを使用することもできます(ファイル名とパスを置き換えます)
USE master;
GO
ALTER DATABASE DELVIPROD_JUNE SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
restore database DELVIPROD_JUNE FROM DISK = 'C:\temp\db.bak' WITH replace
ALTER DATABASE DELVIPROD_JUNE SET MULTI_USER;
データベースのコピーを作成する場合は、これが役立つ場合があります https://serverfault.com/questions/62590/how-to-duplicate-mssql-database-on-the-same-or-another-サーバー
次のスクリプトの例は、ステップを繰り返して、[〜#〜] ok [〜#〜]をクリックする代わりに、generateスクリプトアイコン、新しいクエリウィンドウに送信:
USE [master]
RESTORE DATABASE [DELVIPROD_JUNE]
FROM DISK = N'F:\SQL\BACKUP\SRV1\StackExchange\FULL\SRV1_StackExchange_FULL_20170624_223003.bak'
WITH FILE = 1,
-- important bit here is the move
-- SQL Server will move the logical file name to a new file location
-- MOVE <logical_name> TO <physical_location>
MOVE N'StackExchange' TO N'D:\SQL\SQL_DATA\StackExchangeNew.mdf',
MOVE N'StackExchange_log' TO N'E:\SQL\SQL_LOGS\StackExchangeNew_log.ldf',
NOUNLOAD,
STATS = 5
GO
重要なビットはMOVE
オプションです。新しいデータベース名を使用していて、ファイルの場所を変更したとすると、Filesセクションの復元ダイアログに2つの列が表示されます。 '元のファイル名'という名前の1つと、追加の'Restore As'列があり、データベースファイルのパスとnewのファイル名を変更できますデータベース。
新しいデータベースを復元しているため、データベースがまだ存在しないため、WITH_REPLACE
オプションを指定する必要はありません。
ただし、スクリプトを実行する前、または[〜#〜] ok [〜#〜]をクリックしてダイアログを終了する前に、Restore Asにリストしたファイルを確認してください。部分はファイルシステムに存在しません。
ファイルが存在する場合は、次のステートメントを実行して、ファイルを使用しているデータベースを確認します。
SELECT DB_NAME(database_id), FILE_ID, physical_name, state_desc FROM sys.master_files
これにより、問題を特定できます。
あなたが見ているエラーメッセージに関しては:ファイルが使用中の場合、誰かまたは何らかのシステムがそれらを使用しています。上記のスクリプトを使用して、データベースファイルが別のデータベースで使用されているかどうかを確認します。
一部のSQLサーバーでもこの問題が発生しました。私が排他的にアクセスする必要があると思うときでも、それは私にはないと私に伝えます。排他的にアクセスできると確信している場合は、Management Studioのある種の愚かな非直感的なワークフローが原因である可能性があります。この場合、復元しようとしているデータベースではない別のデータベースにUIフォーカスを置く必要があります。
最初に確認すること
DBに接続している他のものが実行されていないことを確認してください(Webサーバーなどを含む...つまり、接続している可能性のあるIISのものとそれに接続している可能性のある他のサーバーを停止します)
MSSQLサービスを再起動して、ハングアップしている接続をすべてドロップしたことを確認します
Management StudentのSQLサーバーログインに、開くときに接続するデフォルトのデータベースとしてターゲットデータベースがないことを確認してください。ログインウィンドウの>オプション>接続プロパティでデフォルトのエントリを確認してください。
だからここに本当の非直感的なキッカーがあります。接続したら、復元するデータベースではないである別のデータベースを右クリックします。コンテキストメニューから[タスク]に移動し、必要なすべての値を復元して、実際に復元するデータベースを復元します。
何らかの理由でデータベースを右クリックするだけで接続されます。
この奇妙さは、SQL ServerまたはManagement Studioの一部のバージョンでのみ発生すると思います。これが、一部のサーバーでのみ発生する理由です。これは、SQL Studioの中で最も気の遠くなるようなイライラする機能の1つであり、私は何年にもわたって理解する必要がありました。
データベースを復元するには、データベースへの排他的アクセス権が必要です。したがって、復元する前に、データベースへの接続があるかどうかを確認し、それらのセッションを強制終了する必要があります。
データベースを制限モードで作成し、sp_who2を確認した後、すべてのアクティブなセッションを強制終了します。データベースを復元すると、問題なく動作するはずです。