別のサーバーにDBのセカンダリ読み取り専用コピーを作成する
弊社の製品データベース（主にODBC MS-Accessを介して）をクエリして通関レポートを作成するユーザーがいます。データを2番目のサーバーにコピーします（複製/ログ配布/ ??? ）したがって、製品DBの負荷は少なくなります。製品DBの多くのテーブルには主キーがなく、SQL Server 2005です。ターゲットDBはSQL Server 2012 Standardです（ただし、次の場合は宛先サーバーをダウングレードできます）するべき）。
どうすればそれを達成できますか？レプリケーションを試みましたが、主キーがないために失敗しました。ログ配布も試しましたが、SQLのバージョンが異なるため、2番目のDBをオンラインにできません。
ありがとう、ジム
データベースを1日に1回だけ更新する必要がある場合は、SQL Serverエージェントジョブを使用して、バックアップを運用データベースからセカンダリコンピューターに毎晩復元しないのはなぜですか。
セットアップが簡単で、バックアップを検証する便利な方法を提供します。
リアルタイムのデータフィードが必要な場合は、テーブルとレプリケーションを修正するか、SSISパッケージとしてセットアップして、必要なデータを2番目のサーバーにコピーする必要があります。
1日に1回のコピーが必要な場合、スナップショットレプリケーションは正常に機能し、テーブルを変更する必要はありません。
SQL 2012インスタンスをSQL 2005にダウングレードする場合は、ミラーリングまたはログ配布を使用できます。ミラーリングの場合は、1日に1回のスナップショット（または多くの場合、必要な場合があります）を取得するだけで、ユーザーはそれを報告できます。ログ配布の場合は、ログをロールフォワードするだけですが、1日に何回も必要です。ミラーリングとログ配布では、スナップショットが削除されて（ミラーリングで）再作成されると、ユーザーがスナップショットから開始されることに注意してください。ログがロールフォワードされると（ログ配布を使用）、ユーザーはデータベースから削除されます。
弊社の製品データベース（主にODBC MS-Access経由））をクエリして、税関レポートを作成するユーザーがいます。
いくつかの選択肢があります（テーブルに主キーがないため）。
- スナップショットレプリケーションを使用し、レポートに必要なテーブルのみをレプリケートします。 190GBデータベースのスナップショットを作成するには、かなりの時間がかかります。私の回答 トランザクションレプリケーション-スナップショットメトリック を参照して、所要時間の大まかなETAを取得してください。
- テーブルのセットにBCP OutとBCP INを使用します。私のスクリプト here を参照できます。 SQLエージェントジョブを使用して自動化することもできます。
- @mrdennyがSSISを使用するか、レプリケートするテーブルに主キーを作成すると述べたように、データベース全体（190GB）だけをレプリケートしないでください。そうすることで、リアルタイムに近いトランザクションレプリケーションを実装できるという利点があります。
- 最後のオプションとして、Log-shppingを実装することもできます-スタンバイモードでセカンダリを構成しますが、ログを取る頻度に注意する必要があります-プライマリでバックアップを作成してから、セカンダリでコピーして復元します。セカンダリで復元する場合は、復元を数時間遅らせる必要があるため、ユーザーがレポートを実行しているときに接続が切断されることはありません。
SQL 2012では、ログ配布のスタンバイを読み取り専用で実行できます。
唯一の問題は、接続されているユーザーがいる場合、スタンバイデータベースに新しいログファイルを復元できないことです。私の理解によれば、MS-ACCESSを使用したレポートデータベースになります。したがって、ユーザーがプルデータを入力してログアウトすると想定します。したがって、既存のセッションを強制終了してログを復元するのは簡単です。トランスポートの問題が発生した場合、ユーザーは再接続して新しいデータを再度プルすることができます。