問題定義

ユーザーには、ほとんどが最新のデータベースを照会する機能が必要です。データは最大24時間古くなる可能性があり、許容範囲内です。本番コピーで2番目のデータベースを取得して最新の状態に保つための最低コストのアプローチは何でしょうか？私が考えていないアプローチはありますか？

仕事量

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

現在の解決策と問題

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

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

考慮されるアプローチ

クラスタリング

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

SQL Serverレプリケーション

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

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

すばらしい記事を読んだ後、Snapshotがサブスクライバを初期化する方法であるように思えますが、その後、トランザクションレプリケーションに切り替えて同期を維持したいと思います。トランザクションレプリケーションをオン/オフしても、完全な再初期化は強制されませんか？それ以外の場合は、時間枠を爆破します

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

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

ログ配布

ログ配布もオプションのように思えますが、これは私が何も知らないことの別のものです。他の何よりも低コストのソリューション（実装と保守）でしょうか？Remusのコメント「ログシッピングはレプリカコピーへの読み取り専用アクセスを許可しますが、受信した次のバックアップログを適用するときにすべてのユーザーを切断します（15分から30分ごとなど）。」そのダウンタイムがどれくらいの時間に変換されるかわからないので、ユーザーが不安を感じるかもしれません。

MS Sync

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

SSIS

ここでは多くのSSISを実行しているため、数百のSSISパッケージを生成してセカンダリの同期を維持することは、見苦しいとはいえ、オプションです。私はこれを行うのが好きではありません。それは多くのメンテナンスのオーバーヘッドであり、むしろ私のチームが引き受けないようにするためです。

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

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

バックアップと復元

週に1回フルバックアップを取り、夜間に差分を取り、15分ごとにtlogを取ります。ユーザーが完全な復元のために3〜4時間の停止に耐えることができる場合、これはアプローチであると思われます。

制約

Windows 2008 R2、SQL Server 2008 R2（Enterprise Edition）、VMWare v5 Enterprise Edition、vmdkファイルにマップされたドライブを備えたEMC SANストレージ、Commault処理バックアップ、およびソースカタログ内の.6TBのデータ。これは、社内でホストするサードパーティアプリケーションです。それらの構造を変更することは、一般的に嫌われています。ユーザーは、データベースにクエリを実行せずに進むことはできず、作業を行うために監視するテーブルを積極的に識別することによる制約を受けることを拒否します。

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

私は、法務の開発側にいるので、アプローチを提案することしかできず、物事の管理側に対処する必要はありませんでした。だから、管理者のサドルに時間がないので、あるアプローチが別のアプローチよりも優れていると言うのをためらっています。私が見ているように、それはDBの専門家として私をより価値あるものにするだけだからです。手押し車は持っていますが、ホロコーストマントはありません。

関連する質問

• /programming/525637/what-are-the-scenarios-for-using-mirroring-log-shipping-replication-and-cluste

• /programming/434982/mirroring-vs-replication

• /programming/4303020/sync-databases-mirroring-replication-log-shipping

• /programming/4303020/sync-databases-mirroring-replication-log-shipping

• http://nilebride.wordpress.com/2011/07/24/log-shipping-vs-mirroring-vs-replication/

編集

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

データ遅延の受け入れ

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

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

セカンダリへの接続

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

セカンダリインスタンスの要件を読む

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

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

アップタイム要件の明確な定義はありません。ユーザーはいつでも利用できることを望んでいますが、その代価を払っても構わないと思っています。現実的には、1日のうち23時間で十分です。

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

まれな変更。テーブルオブジェクトの場合は四半期ごとに1回。コードオブジェクトの場合は月に1回かもしれません。

セキュリティ

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

@darin strait

スナップショットに戻すことはオプションかもしれませんが、彼らがそれを追求しなかった何らかの理由があったと思います。管理者に確認します

@cfradenburg

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

要約

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

それらの構造を変更することは一般に眉をひそめます

レプリケーションはおそらくアウトであり、その前にSyncをスローします。（Sync Frameworkでの実生活の高度な経路横断的テストから）

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

ミラーリングに行ったり、2012エンタープライズにアップグレードしたりできない場合、それはありません。

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

実際、いくつかの質問に答えることに基づいて、選択肢が明確に絞り込まれます。

• データ遅延の受け入れ
• 所定の分、時、日のデータ変更量セカンダリへの接続
• セカンダリインスタンスの要件を読む
• セカンダリインスタンスの稼働時間
• 既存のスキーマとすべてのオブジェクトの変更
• セキュリティ

これは、最も効果的なものを見つけるために自分で試す必要があるものの1つになります。複製には注意が必要な場合があるため、直接的な金銭的費用はないかもしれませんが、複製を維持するための管理オーバーヘッドが発生します。

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

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

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

人々がトランザクションレプリケーションに夢中になっているのと同じくらい、それはあなたの状況にぴったりのように思えます。いくつかのメモ：

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