none
データベースを別名でコピーできない RRS feed

  • 質問

  • お世話になります。

    環境は以下の通りです。
     Windows Server 2016 Standard
     SQL Server 2017
     SSMS v17.9.1

    上記環境において、SSMSで[データベースのコピー]を以下手順で実行したところ、エラーとなりコピーできませんでした。

    1.対象のデータベースを右クリック、[タスク]-[データベースのコピー]を選択。
      (データベースコピーウィザード起動)
    2.転送元サーバーと転送先サーバーを同一にして次へ。(両方共にWindows認証)
    3.転送方法の選択において[SQL管理オブジェクトの方法を使用する]を選択。
    4.データベースの選択において、対象のデータベースの[コピー]をチェック。
    5.転送先データベースの構成において、転送先データベースを「~_bk」に変更。
      「また、転送先サーバーに存在する同じ名前のすべてのデータベースを削除し、~上書きする」を選択。
    6.パッケージの構成において、パッケージ名を「test」に変更。(ログオプションはイベントログのみ)
    7.パッケージのスケジュール設定において、[すぐに実行する]を選択。
    8.ウィザードの完了において以下の表示。
    ▼▼▼▼▼▼▼▼▼▼
    次のアクションを実行するには、[完了] をクリックします:

    ソース: SFDB その他の SQL Server バージョン、Microsoft SQL Server Standard Edition (64-bit) 、Build 1000、Microsoft Windows NT 6.3 (14393) NT x64
    復元先: SFDB その他の SQL Server バージョン、Microsoft SQL Server Standard Edition (64-bit) 、Build 1000、Microsoft Windows NT 6.3 (14393) NT x64
    SMO オンライン転送を使用する
    以下のデータベースをコピーまたは移動:

    コピー:test_test
    転送先ファイルが作成されます: C:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\DATA\test_test_bk.mdf
    転送先ファイルが作成されます: C:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\DATA\test_test_bk_log.ldf
    既存のデータベースを削除して転送を続行

    パッケージの実行スケジュール: 今すぐ
    ▲▲▲▲▲▲▲▲▲▲

    完了ボタンを押すとパッケージを作成しますが、[SQL Server エージェント ジョブの実行]でエラーとなります。
    イベントログには以下のメッセージが出力されています。
    ▼▼▼▼▼▼▼▼▼▼
      Event Name: OnError
     Message: データベース '[test_test]' にはプロパティ HasMemoryOptimizedObjects は使用できません。このオブジェクトにこのプロパティが存在しないか、十分なアクセス権がないためにこのプロパティを取得できない可能性があります。
    StackTrace:    場所 Microsoft.SqlServer.Management.Smo.PropertyCollection.HandleNullValue(Int32 index)
       場所 Microsoft.SqlServer.Management.Smo.Database.get_HasMemoryOptimizedObjects()
       場所 Microsoft.SqlServer.Dts.Tasks.TransferObjectsTask.TransferObjectsTask.TransferDatabasesUsingSMOTransfer()
     Operator: NT Service\SQLSERVERAGENT
     Source Name: SFDB_SFDB_Transfer Objects Task
     Source ID: {02ACA9AF-87ED-4910-A562-984C13FC1789}
     Execution ID: {2C744F31-C2E1-42A9-92BC-C3488C1871AC}
     Start Time: 2019/03/14 14:58:40
     End Time: 2019/03/14 14:58:40
     Data Code: 0
    ▲▲▲▲▲▲▲▲▲▲

    SQL Server 2008(SP1)では上記手順で正常に動作しましたが、2017(SSMSv17.9.1?)では同じDBを別名でコピーすることはできないのでしょうか。

    以上、よろしくお願い致します。
    2019年3月14日 6:52

回答

  • Norihiro Omoriさん、こんにちは。フォーラムオペレーターのHarukaです。
    ご返信頂きありがとうございます。

    >SQL Serverエージェントアカウントの権限および資格情報を確認する方法はあるのでしょうか?
    コントロールパネルのユーザーアカウントの管理には「NT Service\SQLSERVERAGENT」は存在しませんでした。
    →最初にSSISサブシステム用のエージェントプロキシを作成する必要があります。 
    存在しない場合、ソースデータベースはソースサーバーに再アタッチされず、すべてのNTFSセキュリティアクセス許可はデータファイルとログファイルから削除されます。 
    Create a SQL Server Agent Proxyを参考にしてください。

    >業務的には、前日分のデータベースを自動でコピーして、お客様が前日分を常に見られる状態にしておきたかったのですが、これはSSMSの問題のため修正されるのを待つしかないのでしょうか。
    データベースをバックアップして新しい名前で復元するエージェントジョブを作成できます。 
    その後、毎日実行するようにジョブをスケジュールします。 
    使うことができるOla Hallengrenからのいいバックアップスクリプトがあります。

    データベースコピーウィザードに関する問題については、以前投稿したフィードバックスレッドに投票できます。

    上記の情報は役に立てば幸いです。

    どうぞよろしくお願いします。


    MSDN/ TechNet Community Support Haruka

    ~参考になった投稿には「回答としてマーク」をご設定ください。なかった場合は「回答としてマークされていない」も設定できます。同じ問題で後から参照した方が、情報を見つけやすくなりますので、
    ご協力くださいますようお願いいたします。また、MSDNサポートに賛辞や苦情がある場合は、MSDNFSF@microsoft.comまでお気軽にお問い合わせください。~

    2019年3月28日 7:07
    モデレータ

すべての返信

  • Norihiro Omoriさん、こんにちは。フォーラムオペレーターのHarukaです。
    MSDNフォーラムにご投稿くださいましてありがとうございます。

    同じ問題がこちらで再現できました。 
    SQL Serverのフィードバックに以下のスレッドを見つけました。 
    それは既知の問題のようです。
    https://feedback.azure.com/forums/908035-sql-server/suggestions/32898043-cdw-from-2016-to-2017-ends-with-property-hasmemor

    データベースを移動またはコピーするには、デタッチとアタッチの方法を選択してみてください。

    上記の情報は役に立てば幸いです。

    どうぞよろしくお願いします。


    MSDN/ TechNet Community Support Haruka

    ~参考になった投稿には「回答としてマーク」をご設定ください。なかった場合は「回答としてマークされていない」も設定できます。同じ問題で後から参照した方が、情報を見つけやすくなりますので、
    ご協力くださいますようお願いいたします。また、MSDNサポートに賛辞や苦情がある場合は、MSDNFSF@microsoft.comまでお気軽にお問い合わせください。~
    2019年3月19日 7:51
    モデレータ
  • Haruka6002さん

    返信ありがとうございます。

    ご教示頂いたスレッドを拝見しました。

    私のつたない英語力で理解しようとしたところ、デタッチとアタッチの方法で解決した人がいるようですが、SSMSがv17.9.1では解決していないように読めます。

    実際にこちらの環境でデタッチとアタッチの方法でデータベースコピーをウィザードで実行してみましたが、別のエラーが発生しました。
    ▼▼▼▼▼▼▼▼▼▼
      Event Name: OnError
     Message: オブジェクト参照がオブジェクト インスタンスに設定されていません。
    StackTrace:    場所 Microsoft.SqlServer.Dts.Tasks.TransferObjectsTask.TransferObjectsTask.CopyFile(String sourceFileName, String destinationFileName, Boolean overwriteOnExist)
     Operator: NT Service\SQLSERVERAGENT
     Source Name: SFDB_SFDB_Transfer Objects Task
     Source ID: {8E5F16BF-136A-4450-BB2D-21430B41975D}
     Execution ID: {BE2A29E7-A494-4B2C-A349-EBEC6C9D4D7C}
     Start Time: 2019/03/25 11:16:28
     End Time: 2019/03/25 11:16:28
     Data Code: 0
    ▲▲▲▲▲▲▲▲▲▲

    上記エラーはデタッチまで成功した後、以下のログの直後に出力されているため、コピーで失敗しているようです。
    ▼▼▼▼▼▼▼▼▼▼
      Event Name: OnInformation
     Message: ファイル C:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\DATA\test.mdf を C:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\DATA\test_new.mdf にコピーしています。上書きオプションは False に設定されています
     Operator: NT Service\SQLSERVERAGENT
     Source Name: noritest10
     Source ID: {7B09452A-7E8A-451D-BE7F-19280D1262C1}
     Execution ID: {BE2A29E7-A494-4B2C-A349-EBEC6C9D4D7C}
     Start Time: 2019/03/25 11:16:28
     End Time: 2019/03/25 11:16:28
     Data Code: 0
    ▲▲▲▲▲▲▲▲▲▲

    その後、対象DBがSSMSのペインから消えたため、[アタッチ]を実行したところ(1)のエラーとなり、[データベースの復元]を実行したところ(2)のエラーとなりました。

    ▼▼▼▼▼(1)▼▼▼▼▼
    タイトル: Microsoft SQL Server Management Studio
    ------------------------------

    この要求のデータを取得できませんでした。 (Microsoft.SqlServer.Management.Sdk.Sfc)

    ヘルプを表示するには http://go.microsoft.com/fwlink?ProdName=Microsoft%20SQL%20Server&LinkId=20476 をクリック

    ------------------------------
    ADDITIONAL INFORMATION:

    Transact-SQL ステートメントまたはバッチの実行中に例外が発生しました。 (Microsoft.SqlServer.ConnectionInfo)

    ------------------------------

    物理ファイル 'C:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\DATA\test.mdf' を開くとき、または作成中に CREATE FILE でオペレーティング システム エラー 5(アクセスが拒否されました。) が発生しました。 (Microsoft SQL Server、エラー: 5123)

    ヘルプを表示するには http://go.microsoft.com/fwlink?ProdName=Microsoft%20SQL%20Server&ProdVer=14.00.1000&EvtSrc=MSSQLServer&EvtID=5123&LinkId=20476 をクリック
    ▲▲▲▲▲(1)▲▲▲▲▲

    ▼▼▼▼▼(2)▼▼▼▼▼
    TITLEMicrosoft SQL Server Management Studio
    ------------------------------

    データベース 'test_test' の復元に失敗しました。 (Microsoft.SqlServer.Management.RelationalEngineTasks)

    ------------------------------
    ADDITIONAL INFORMATION:

    System.Data.SqlClient.SqlError: 'C:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\DATA\test.mdf' で 'RestoreContainer::ValidateTargetForCreation' を試行中に、オペレーティング システムからエラー '5(アクセスが拒否されました。)' が返されました。 (Microsoft.SqlServer.SmoExtended)

    ヘルプを表示するには http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=14.0.17289.0+((SSMS_Rel_17_4).181117-0805)&LinkId=20476 をクリック
    ▲▲▲▲▲(2)▲▲▲▲▲

    これはSSMSの問題で、v17.9.1以降では修正されるの待つしかないのでしょうか。

    以上、宜しくお願い致します。

    2019年3月25日 4:45
  • Norihiro Omoriさん、こんにちは。フォーラムオペレーターのHarukaです。
    ご返信頂きありがとうございます。

    >その後、対象DBがSSMSのペインから消えたため、[アタッチ]を実行したところ(1)のエラーとなり、[データベースの復元]を実行したところ(2)のエラーとなりました。
    →データベースはまだ存在しています。データベースを手動でアタッチする必要があります。
    SSMS で、[データベース] を右クリックし、[アタッチ] を選択します。
    .mdf ファイルと .ldf ファイルを保存する場所を見つけます。

    >物理ファイル 'C:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\DATA\test.mdf' を開くとき、または作成中に CREATE FILE でオペレーティング システム エラー 5(アクセスが拒否されました。) が発生しました。 (Microsoft SQL Server、エラー: 5123)
    →エラーログによると、SQL Serverエージェントアカウントにはファイルを開くまたは作成する権限がありません。 
    デタッチとアタッチ方法を使用するには、SSISサブシステム用のSQL Serverエージェントプロキシが、移行元サーバーと移行先サーバーの両方のファイルシステムにアクセスできる資格情報を持ち、移行先サーバーに存在する必要があります。

    回避策として、同じサーバー上にデータベースを「コピー」したい場合は、データベースを単純にバックアップしてから新しい名前で復元することができます。

    上記の情報は役に立てば幸いです。

    どうぞよろしくお願いします。


    MSDN/ TechNet Community Support Haruka

    ~参考になった投稿には「回答としてマーク」をご設定ください。なかった場合は「回答としてマークされていない」も設定できます。同じ問題で後から参照した方が、情報を見つけやすくなりますので、
    ご協力くださいますようお願いいたします。また、MSDNサポートに賛辞や苦情がある場合は、MSDNFSF@microsoft.comまでお気軽にお問い合わせください。~

    2019年3月27日 1:11
    モデレータ
  • Haruka6002さん

    返信ありがとうございます。

    >→エラーログによると、SQL Serverエージェントアカウントにはファイルを開くまたは作成する権限がありません。 
    >デタッチとアタッチ方法を使用するには、SSISサブシステム用のSQL Serverエージェントプロキシが、移行元サーバーと移行先サーバーの両方のファイルシステムにアクセスできる資格情報を持ち、移行先サーバーに存在する必要があります。

    →SQL Serverエージェントアカウントの権限および資格情報を確認する方法はあるのでしょうか?
    コントロールパネルのユーザーアカウントの管理には「NT Service\SQLSERVERAGENT」は存在しませんでしたので、ご教示いただければ幸いです。
    なお、移行元サーバーと移行先サーバーは同じです。
    また、関係ないかもしれませんが、[セキュリティ]-[ログイン]の下に存在する「NT SERVICE\SQLSERVERAGENT」のサーバーロールではpublicとsysadminがチェックされていました。

    ちなみに、アクセスが拒否されてアタッチできなかった事象は以下の手順で解消できました。
    1.ファイルエクスプローラーでファイル(mdfファイルとldfファイル)のプロパティを開く。
    2.セキュリティタブの[編集]で一度すべてのグループおよびユーザーを削除。
    3.所有者にローカルの「Administrators」を設定。(既に設定されていれば不要)
    4.ローカルの「Administrators」と「NT Service\MSSQLSERVER」を追加。
    上記をmdfファイルとldfファイルの両方に行えば、SSMSから[アタッチ]ができるようになりました。

    回避策のご提示についてはありがとうございました。
    バックアップファイルから、転送先データベース名と復元先ファイル名を手動で変更することによって、コピーができることを確認できました。

    業務的には、前日分のデータベースを自動でコピーして、お客様が前日分を常に見られる状態にしておきたかったのですが、これはSSMSの問題のため修正されるのを待つしかないのでしょうか。

    お手数だとは思いますが、ご回答いただけますと幸いです。

    以上、宜しくお願い致します。

    2019年3月27日 11:00
  • Norihiro Omoriさん、こんにちは。フォーラムオペレーターのHarukaです。
    ご返信頂きありがとうございます。

    >SQL Serverエージェントアカウントの権限および資格情報を確認する方法はあるのでしょうか?
    コントロールパネルのユーザーアカウントの管理には「NT Service\SQLSERVERAGENT」は存在しませんでした。
    →最初にSSISサブシステム用のエージェントプロキシを作成する必要があります。 
    存在しない場合、ソースデータベースはソースサーバーに再アタッチされず、すべてのNTFSセキュリティアクセス許可はデータファイルとログファイルから削除されます。 
    Create a SQL Server Agent Proxyを参考にしてください。

    >業務的には、前日分のデータベースを自動でコピーして、お客様が前日分を常に見られる状態にしておきたかったのですが、これはSSMSの問題のため修正されるのを待つしかないのでしょうか。
    データベースをバックアップして新しい名前で復元するエージェントジョブを作成できます。 
    その後、毎日実行するようにジョブをスケジュールします。 
    使うことができるOla Hallengrenからのいいバックアップスクリプトがあります。

    データベースコピーウィザードに関する問題については、以前投稿したフィードバックスレッドに投票できます。

    上記の情報は役に立てば幸いです。

    どうぞよろしくお願いします。


    MSDN/ TechNet Community Support Haruka

    ~参考になった投稿には「回答としてマーク」をご設定ください。なかった場合は「回答としてマークされていない」も設定できます。同じ問題で後から参照した方が、情報を見つけやすくなりますので、
    ご協力くださいますようお願いいたします。また、MSDNサポートに賛辞や苦情がある場合は、MSDNFSF@microsoft.comまでお気軽にお問い合わせください。~

    2019年3月28日 7:07
    モデレータ
  • Haruka6002さん

    ご回答ありがとうございます。

    ご教示頂いた内容は知りませんでしたが、非常に有用な情報でした。これを機に勉強します。

    また、エージェントジョブについては導入する方向で検討します。

    色々とご対応頂きありがとうございました。

    2019年3月29日 4:07