データベースのコピーに「データベースコピーウィザード」なるものを使ってみた。（SQLServer2012）
本番のデータ移行ではmdfを直接コピーすることになると思うが、テスト的にデータを使ってみたかったのでオンラインでのコピーがしたかった。
SQLServerのウィザードなら素人にも使えるのかと思ったが、さにあらず。
それほど人にやさしいツールでは無かったので使い方をメモしておく。
- 「SQLServer Management Studio」を起動
- 「データベース」ツリーを展開し適当なデータベース上で右クリックし、コンテキストメニューから「タスク」「データベースのコピー」を選択
（なぜにコンテキストメニューではなく通常のメニューに存在しないか疑問、コピー先インスタンスで操作する場合対象のDBが存在しないでしょうが・・・） - 「次へ」
- 転送元のサーバー名を指定（Domain環境ならWindows認証が簡単か・・・）
- 転送先のサーバーを指定
- 転送方法の選択で「SQL管理オブジェクトの方法を使用する」を選択（デタッチするくらいなら手作業でやった方が確実）
- 「データベースの選択」画面でDBの一覧が表示されるので対象のDBをチェック
- 「転送先データーベース構成」画面で上書きの可否を設定
- 「サーバーオブジェクトの選択」画面で追加オブジェクトが必要であれば指定（今回は指定しない）
- 「パッケージ構成」画面で「パッケージ名」とログオプションを指定（エラーが起きる可能性が大なのでテキストの出力しておいたほうが見やすいと思われ）
- 「パッケージのスケジュール設定」画面で「即時実行」か「スケジュール実行」かを指定する。「Integration Serviceプロキシアカウント」を選択するようになっているが「SQL Server エージェントサービスのアカウント」以外に選択肢がない・・・
- 「完了」ボタンをクリックすると実行される
これでうまくいけば万々歳なのだが、素人がやるとまずうまくいかないだろう。
まずはこの処理自体は「SQL Server エージェント」サービスが担うようなので、このサービスが上がっていないといけない。（デフォルトで上がっているものでは無かったような気がする）
サービスが上がっていても今度はログインできないといったエラーが発生する。
ログを見ると、「ドメイン名\サーバー名」のようなありもしないユーザー名でアクセスしに行っているようだ。
良くは判らないが、サービスの実行ユーザーが宜しくないのだろう。
まぁ、しかしウィザード自体はちゃんとログオンできて相手先のテーブル名まで表示できているのだからいかようにでも出来るだろうに・・・。
少なくともウィザード実行時点でエージェントジョブがログインできない事は確認できるはず・・・。
ユーザーをドメインユーザーに変更して再実行。
今度は時間がかかっているので何やらうまくいきそう。
ありゃ、またエラー(><)
なんだかな～。
しかもログを見ても単に失敗したとしか出ていない。
あれ、いくつかのDBはコピーされているなぁ・・・。
一つだけ失敗だ。
何でしょう。
良く判らないのでログの出力先をテキストにして失敗したDBだけ再実行。
ありゃりゃ。成功だ。
タイミング？
なんかあまり信用できるツールでは無さそう。
試しに、SQLServer認証でもやってみたところ、ログイン自体は出来ているようだが、なにやら権限不足だと怒られている。
みのりがなさそうなのでここまで。
こんなツールが「ウィザード」を名乗っちゃだめだなぁ・・・。
0 件のコメント:
コメントを投稿