7

大規模なデータベースまたは SQL サーバー上のデータベースのコレクションのバックアップと復元のプロセスは、障害と復旧の目的で非常に重要です。ただし、プロセス全体が可能な限り効率的で、100% の信頼性があり、複数のサーバー間で簡単に保守および構成できることを保証する堅牢なソリューションは見つかりませんでした。

Microsoft のメンテナンス プランは十分ではないようです。私が使用した最善の解決策は、ソース サーバー (バックアップ) と宛先サーバー (復元) で実行されているデータベースごとに多くのステップを含む多くのジョブを使用して手動で作成したものです。ジョブはストアド プロシージャを使用して、バックアップ、コピー、および復元を行います。これは 1 日に 1 回 (フル バックアップ/復元) 実行され、日中は 5 分ごとに実行されます (トランザクション ログの配布)。

私の現在のプロセスは機能し、電子メールでジョブの失敗を報告しますが、プロセス全体の信頼性は高くなく、プロセスに関する深い知識がなければ、DBA 以外の人がすべてのサーバーで簡単に保守/構成できないことはわかっています。

他の人がこれと同じバックアップ/復元プロセスを持っているかどうか、他の人がこの問題をどのように克服したかを知りたい.

4

3 に答える 3

3

私は同様の手順を使用して、開発者とQA担当者が使用できるように、開発/テスト/QAデータベースを毎晩「ゼロステップ」に保ちました。

文書化が鍵となります-スコット・ハンゼルマンが「バスファクター」と呼んでいるものを削除したい場合（つまり、システムの作成者がバスにぶつかってすべてが吸い込まれ始める危険性）。

とはいえ、通常のデータベースバックアップと障害復旧計画の場合、SQLServerメンテナンス計画は非常にうまく機能することがわかりました。以下を含める限り：1）適切なドキュメント2）定期的なテスト。

これを実行する方法のいくつかを概説しました（災害復旧計画の作成方法の例を探しているこの質問に惹かれる人のために）：
SQL Serverバックアップのベストプラクティス（無料のチュートリアル/ビデオ）

于 2008-09-16T22:27:22.590 に答える
3

あなたの質問の重要な部分は、非 DBA がバックアップ ソリューションを管理できることです。バックアップ スクリプトは T-SQL の知識を必要とするため、バックアップ スクリプトのようなネイティブ SQL Server の回答はそのニーズを満たしていません。

そのため、Mitch Wheat が言及したようなサードパーティのソリューションを検討する必要があります。私は Quest (LiteSpeed のメーカー) で働いているので、もちろん私は Quest の一部です。非 DBA に簡単に見せることができます。前の会社を辞める前に、LiteSpeed コンソールがどのように機能するかをシステム管理者と開発者に説明する 10 分間のセッションがありました。それ以来、彼らは電話していません。

もう 1 つのアプローチは、ショップの残りの部分が使用しているのと同じバックアップ ソフトウェアを使用することです。TSM、Veritas、Backup Exec、および Microsoft DPM にはすべて、Windows 管理者がさまざまな程度の使いやすさでバックアップ プロセスを管理できるようにする SQL Server エージェントがあります。本当に DBA 以外の人に管理してもらいたい場合は、SQL 固有のバックアップ ツールが提供する多くのパフォーマンスを犠牲にすることになりますが、おそらくこれが最も簡単な方法です。

于 2008-10-19T00:53:09.227 に答える
0

私はまったく同じことをしており、このプロセスでも半定期的にさまざまな問題を抱えています。

サーバー A からサーバー B にファイルをコピーしてから、サーバー B でトランザクション バックアップを復元するまでの間隔をどのように処理しますか。

時々、トランザクションのバックアップが通常より大きくなり、コピーに時間がかかります。その後、復元ジョブは、ファイルが使用中であるというオペレーティング システム エラーを受け取ります。

次回はファイルが自動的に適用されるため、これはそれほど大きな問題ではありませんが、一般的にはより洗練された解決策と、この問題を具体的に修正する解決策を用意することをお勧めします。

于 2008-09-16T21:55:54.960 に答える