SQL Serverデータベースの同期

Question

問題の定義

私たちのユーザーは、ほとんどが最新のデータベースにクエリを実行する機能を必要としています。データは最大24時間古くなる可能性があり、それは許容範囲です。プロダクションコピーで2番目のデータベースを最新の状態に保ち、維持するための最低コストのアプローチは何でしょうか。私が考えていないアプローチはありますか？

ワークロード

株式取引活動の監視に使用するサードパーティのアプリケーションがあります。日中、さまざまなワークフローの一部として多くの小さな変化が発生します（そうです、この取引は有効でした。いいえ、これは疑わしいなどです）。夜には、大規模なセットベースの操作を実行します（前日の取引を読み込みます）。

現在の解決策と問題

データベーススナップショットを使用します。午後10時スナップショットをドロップして再作成します。次に、ETL処理が開始されます。これは明らかにディスクに負担をかけますが、ユーザーはデータベースをロックせずにデータベースにクエリを実行できます（Accessフロントエンドを使用します）。彼らはそれを夜遅くから朝早く使用するため、ダウンタイムに気づくでしょう。

このアプローチの問題は2つあります。 1つ目は、夜間の処理が失敗し、それがそれほど珍しいことではない場合、データベースを復元して、スナップショットが削除されることです。もう1つの問題は、処理時間がSLAを超えていることです。私たちは、不十分に記述されたクエリとインデックスの欠如を特定した後、ベンダーと協力してこれに対処しようとしています。データベーススナップショットは、存在する場合とない場合の速度の違いによって示されるように、この速度低下の原因でもあります。

検討したアプローチ

クラスタリング

データベースのクラスタリングをオンにしましたが、これはデータを利用可能にする必要性に対応しておらず、一般的に管理者の生活を複雑にしていました。それ以降はオフになっています。

SQL Serverレプリケーション

先週レプリケーションの調査を始めました。私たちの理論では、2つ目のカタログを立ち上げ、本番データベースと同期させることができます。 ETLを開始する前に、接続を切断し、ETLプロセスが完了した後にのみ再度有効にします。

管理者はスナップショットレプリケーションで開始しましたが、スナップショットと必要なディスク消費量を生成するためにCPU使用率が数日かかることに懸念を抱いています。彼は、加入者に出荷する前にすべてのデータを物理ファイルに書き出すように見えるため、.6TBデータベースのストレージコストは1.8TBになると述べています。また、スナップの生成に数日かかる場合は、目的のSLAに適合しません。

良い記事を読んだ後、スナップショットはサブスクライバーを初期化する方法のように思われるかもしれませんが、それから Transactional Replication に切り替えて、その後同期を維持したいと思います。トランザクションレプリケーションをオン/オフにしても、完全な再初期化は強制されないと思いますか？そうでなければ、私たちは時間枠を吹き飛ばします

データベースミラーリング

私たちのデータベースは完全復旧モードにあるため、データベースミラーリングはオプションですが、レプリケーションよりもそれについてはあまり知りません。「データベースミラーリングではデータに直接アクセスできないため、ミラーリングされたデータにはデータベーススナップショットからのみアクセスできます。」という SO回答が見つかりました。

ログ配送

log shipping もオプションのようですが、これは私が何も知らないことの1つです。それは何よりも低コストのソリューション（実装と保守）になるでしょうか？ Remusの comment に基づいています。「ログシッピングはレプリカコピーへの読み取り専用アクセスを許可しますが、受信した次のバックアップログを適用するとすべてのユーザーを切断します（例：15-30分ごと）。」そのダウンタイムがどれだけ長くなるかわからないので、ユーザーを不安にさせるかもしれません。

MS Sync

私は Sync の使用について今週末だけ聞いており、まだ調査していません。この問題のように視認性の高いものに新しいテクノロジーを導入したくないのですが、それが最善のアプローチであるなら、そうしてください。

SSIS

ここでは十分なSSISを使用しているため、uglyとはいえ、セカンダリを同期化するために数百のSSISパッケージを生成することも選択肢の1つです。私はこれを行うのが好きではありません。それは、私のチームが引き受けないほうがいいメンテナンスのオーバーヘッドが多いためです。

SAN「マジック」スナップショット

以前、管理者がいくつかのSANテクノロジーを使用してディスク全体のインスタントバックアップを作成していると聞きました。おそらく、mdf/ldfのuberquickコピーを作成するために使用できるEMCの魔法があると思いますその後、ターゲットデータベースをデタッチ/アタッチできます。

バックアップと復元

フルバックアップは週に1回、差分は毎晩、tlogは15分ごとに取得すると思います。ユーザーが完全な復元のために3〜4時間の停止で耐えられる場合は、これがアプローチかもしれないと思います。

制約

Windows 2008 R2、SQL Server 2008 R2（Enterprise Edition）、VMWare v5 Enterprise Edition、EMC SAN vmdkファイルにマップされたドライブ、commvault処理のバックアップ、およびソースカタログの.6TBのデータのストレージ。これは社内でホストするサードパーティのアプリケーションです。通常、その構造の変更は好ましくありません。ユーザーはデータベースにクエリを実行せずにはいられず、作業を監視するテーブルを事前に特定することによって制約を受けることを拒否します。

現在、DBAは純粋に請負業者です。フルタイムの人々が出航し、私たちはまだ彼らを入れ替えていません。アプリケーション管理者はSQL Serverの問題に精通しておらず、この取り組みを支援または妨害できるストレージ/ VM管理者のチームがいます。現在、開発チームは関与していませんが、アプローチに基づいて参加できます。したがって、ソリューションの実装と保守がより簡単であることが望ましいでしょう。

私、私はホスーの開発側にいるので、アプローチを提案することしかできず、物事の管理側を扱う必要がありませんでした。したがって、管理サドルに時間がないため、1つのアプローチが別のアプローチよりも優れているとは言いがたい-論文によると、すべてが素晴らしいように見える。私が見ているように、DBの専門家としての価値が高まるだけなので、私はすべての方向性を実行する用意があります。手押し車はありますが、ホロコーストのクロークはありません。

編集

@onpntの質問に対処するには

データ待ち時間の受け入れ

ユーザーは現在、最大24時間遅れのデータを表示しています。データは2200の時点でのみ最新です

特定の分、時間、日におけるデータの変化量それを定量化する方法がわかりません。営業時間、おそらく1時間あたり数百の変更。毎晩の処理、1営業日あたり数百万行

セカンダリへの接続

内部ネットワーク、個別の仮想ホストと専用ストレージ

セカンダリインスタンスの要件を読み取る

Windowsグループには、セカンダリのすべてのテーブルへの読み取りアクセス権があります

セカンダリインスタンスの稼働時間

アップタイム要件の明確な定義はありません。ユーザーはいつでもそれを利用できることを望んでいますが、多分それほどではないでしょうが、彼らはそのためにお金を払っても構わないと思っています。現実的には、1日のうち23時間で十分だと思います。

既存のスキーマとすべてのオブジェクトへの変更

頻度の低い変更、おそらくテーブルオブジェクトの場合は四半期に1回。たぶん、コードオブジェクトの場合は月に1回。

安全保障

特別なセキュリティは必要ありません。生産許可はコピーの許可と一致します。私はそれについて考えていますが、ユーザーにprodへの読み取りアクセス権を取り消して、コピーの読み取りのみを許可することもできますが、必須ではありません。

@darin海峡

スナップショットに戻すこともできますが、追跡しなかった理由はいくつかあると思います。管理者に確認します

@cfradenburg

私の想定では、これらのアプローチの1つだけを使用することでしたが、それは、復元が「他の」同期テクノロジーを壊してしまう良い点です。彼らはEMCスナップショットマジックを使用して調査を行っています。管理者が説明したように、彼らは1900にスナップショットを取り、イメージをセカンダリのゾーンに移行しました。これは2200年までに完了するはずで、セカンダリデータベースのデタッチと再アタッチを実行します。

要約

2012-10-29 EMCのスナップショットマジックやその他のレプリケーションオプションを評価しましたが、DBAはミラーリングを最もよく理解できると判断しました。答えを支持してくれたので、答えを賛成しました。調査するための「宿題」だけでなく、たくさんの選択肢をくれました。

onpnt · Accepted Answer

それらの構造を変更することは一般に嫌われます

レプリケーションはかなり可能性が高く、その前にSyncをスローします。（Sync Frameworkでの実際の高トランザクションテストから）

3〜4時間がデータ遅延の例外である場合、ログ配布はおそらくここでの読み取り専用コピーでの最善の策になります。しかし、ログでどのくらいの変化が起こっていますか？それを監視して、どれだけ早く、どれだけプッシュする必要があるかを確認してください。

ミラーリングに移行できない場合、または2012エンタープライズにアップグレードできない場合は、それは不可能ですが、エンタープライズに移行できない場合は、これは適切な戦略になります。

SSISは、単にデータをダンプするだけのものではありませんが、それを行うことができます。ただし、ルックアップ変換の観点から見すぎているため、このタスクには時間とリソースがかかります。私が言ったように、それはそれを行うことができますが。

本当に、いくつかの質問への回答に基づいて、選択肢の明確な絞り込みがあります

データ待ち時間の受け入れ
指定された分、時間、日のデータ変更量セカンダリへの接続
セカンダリインスタンスの要件を読み取る
セカンダリインスタンスの稼働時間
既存のスキーマとすべてのオブジェクトへの変更
安全保障

cfradenburg · Answer

これは、最も効果的なものを見つけるために自分で試す必要があることの1つになります。レプリケーションは注意が必要です。そのため、直接的な金銭的コストはないかもしれませんが、それを維持するための管理オーバーヘッドが発生します。

ログ配布を拡張するには、15〜30分ごとにログを復元する必要はありません。必要に応じて、4時間ごとまたは1日に1回実行できます。私が実装したこれに似たソリューションは、毎週完全バックアップを実行し、レポートDBに復元することです（これにはしばらく時間がかかり、週末に発生する場合があります）。週の間に差分バックアップが取られ、それらは毎晩レポートデータベースに復元されます。ユーザーは復元の前に起動する必要がありますが、レポートDBは営業時間のアプリケーションであるため、問題はありません。データは1日前のものであり、要件に基づいて問題になることはありません。

このためにデータベースミラーリングを使用するには、まだEnterpriseを実行していない場合に、スナップショットを使用できるようにEnterpriseを購入する必要があります。また、スナップショットを削除する必要があるため（つまり、すべてのユーザーが外に出る必要がある）、新しいデータを取得するために再作成する必要があるため、データを100％最新の状態に保つこともできません。ただし、これは、ログの復元や上記で説明した方法よりも時間がかかりません。

SQL 2012へのアップグレードがオプションの場合は、プライマリデータベースで最新の状態に維持される読み取り専用のセカンダリを設定することができます。これが最もスムーズなソリューションである可能性が高いため、私はこれについてのみ説明します。

Ben Thul · Answer

トランザクションレプリケーションに不満を抱いているのと同じくらい、それはあなたの状況に適しているように思えます。いくつかのメモ：

スナップショットでサブスクライバーを初期化する必要はありません。パブリッシャーのバックアップを取り、それで初期化できます。
ディストリビューションジョブを停止するだけで、サブスクライバーへのコマンドの配信を一時停止できます（プッシュサブスクリプションとして設定したか、プルサブスクリプションとして設定したかに応じて、ディストリビューターまたはサブスクライバーでの通常のSQLエージェントジョブです）。あなたが追いつくことができるようにあなたの周りに十分な履歴を保持しているように、ディストリビューターでのあなたの保持に注意してください。
サブスクライバーでのインデックス付けを変更して、必要に応じてパブリッシャーからのインデックス付け（おそらくOLTPタイプ）を受け入れる代わりに、そこで行われるワークロード（おそらくレポートタイプ）に対応できます。