1. 概要 SQL Server ログ出荷
1.1とは SQL Server ログシッピング?
SQL Server ログ配布は、運用データベースのウォームスタンバイコピーを維持する自動化された災害復旧ソリューションです。このテクノロジーは、プライマリサーバーインスタンス上のプライマリデータベースから、別のセカンダリサーバーインスタンス上の1つ以上のセカンダリデータベースにトランザクションログのバックアップを転送します。これにより、セカンダリデータベースがプライマリデータベースと常に同期された状態が維持され、データ損失やサーバー障害から保護されます。
1.2 ログシッピングの目的と利点
ログ配布は、データベース管理において複数の重要な目的を果たします。
- その主な役割は災害復旧であり、信頼性の高いフェイルオーバーを提供することです。 tarハードウェア障害、ソフトウェア破損、またはデータ センターに影響を与える壊滅的なイベントによりプライマリ サーバーが利用できなくなった場合に取得します。
- それはまたacですost-効果的 高可用性ソリューション高価なライセンスを必要とするエンタープライズグレードの機能とは異なり、ログシッピングは SQL Server 標準エディションなので、予算が制限されている組織でも利用できます。
- スタンバイモードのセカンダリデータベースは、災害復旧以外にも付加価値を提供します。データベース管理者は、セカンダリデータベースを読み取り専用レポート作成に使用し、本番サーバーからクエリワークロードをオフロードできます。
- 遅延復元機能は、偶発的なデータ変更から保護します。復元の遅延を設定することで、破壊的な変更がセカンダリデータベースに到達する前に、ユーザーエラーから回復するための時間枠を確保できます。
2. SQL Server ログシッピングのコンポーネントとワークフロー
ログ配布は次のコンポーネントで構成されます。
- プライマリサーバーとプライマリデータベース:プライマリサーバーは本番環境を表します。 SQL Server プライマリ データベースを実行しているインスタンス。
- バックアップ共有: トランザクション ログのバックアップをプライマリ サーバーからセカンダリ サーバーに保存および転送する中間の場所です。
- セカンダリサーバーとセカンダリデータベース:セカンダリサーバーはost プライマリ データベースのウォーム スタンバイ コピー。
- 監視サーバー (オプション): このサーバーは、ログ配布トポロジ全体のすべてのバックアップ、コピー、および復元操作の履歴とステータスを追跡します。
- エージェント ジョブ: バックアップ、コピー、復元、アラート ジョブが含まれ、ログ配布プロセス全体が自動化されます。
自動化ワークフローは次のとおりです。
- バックアップ ジョブはプライマリ サーバー上で実行され、バックアップ共有上にプライマリ データベースのトランザクション ログ バックアップを作成します。
- コピー ジョブは各セカンダリ サーバーで実行され、ログ バックアップ ファイルをバックアップ共有からセカンダリ サーバーに転送します。
- 復元ジョブは各セカンダリ サーバーで実行され、コピーされたトランザクション ログ バックアップをセカンダリ データベースに適用します。
- アラート ジョブは監視サーバー上で実行され、バックアップおよび復元操作が許容可能な時間枠内に完了したかどうかを確認します。
3. 前提条件と要件
3.1 SQL Server バージョン要件
ログシッピングは、 SQL Server 2000以降のすべてのバージョンでもサポートされています。 SQL Server 2005 年から 2025 年まで。この長期にわたるサポートは、テクノロジの安定性と継続的な関連性を証明しています。
3.2 SQL Server エディション要件
ログ配布は、Standard、Workgroup、Enterprise、Developerの各エディションで動作します。 SQL Serverこの幅広いエディションのサポートにより、次のような機能とは異なり、Enterprise Editionライセンスを持たない組織でもログ配布を利用できるようになります。 Always On 可用性グループ エンタープライズ エディションまたは評価版が必要です。
注意: Express Edition はログ配布をサポートしていません。
3.3 データベース復旧モデルの要件
ログ配布では、プライマリデータベースで完全復旧モデルまたは一括ログ復旧モデルを使用する必要があります。単純復旧モデルはサポートされていません。 SQL Server トランザクション ログを自動的に切り捨て、ログ シッピングに必要な連続したログ チェーンを切断します。
リカバリモデルの詳細については、 包括的なガイド SQL Server バックアップ.
4. SSMS を使用したログ配布の構成
ログ配布を構成する前に、トランザクション ログ バックアップが保存および転送されるバックアップ共有フォルダーを準備します。
- プライマリサーバーまたは専用ファイルサーバーで、フォルダーを作成します（例： C:\バックアップ)
- フォルダを右クリックして選択 特性
- クリック 分担 タブ
- 詳しくはこちら 高度な共有
- チェック このフォルダを共有します
- 詳しくはこちら 権限 そして助成金を与える フルコントロール 許可する SQL Server サービスアカウント NT サービス\MSSQLSERVER。
- 詳しくはこちら OK 適用します。
- ネットワークパス（UNC）を文書化します（例： \\サーバー名\バックアップ)
4.2 ログシッピングの有効化と構成
- プライマリデータベースを右クリックし、 特性.
- データベースのプロパティ ダイアログで、 トランザクションログの配布 左側のパネルのページ。
- チェック ログ配布構成でプライマリデータベースとしてこれを有効にする ログ配布を有効にします。
- このプロパティページでは、バックアップ設定、セカンダリサーバー、監視サーバーを設定できます。これらについては、以下のサブセクションで説明します。
4.2.1 バックアップ設定を構成する
- クリック バックアップ設定 (Comma Separated Values) ボタンをクリックして、各々のジョブ実行の詳細（開始/停止時間、変数値など）のCSVファイルをダウンロードします。
- トランザクションログのバックアップ設定 ダイアログ バックアップフォルダへのネットワークパス フィールドにUNCパスを入力します（例： \\サーバー名\バックアップ)
- バックアップフォルダがプライマリサーバー上にある場合は、ローカルパスを入力します（例： C:\バックアップ)
- バックアップ保持期間、アラートしきい値、バックアップ ジョブ、圧縮などのその他の設定を構成します。
- 詳しくはこちら OK 設定を確認してダイアログを閉じます。
4.2.2 セカンダリサーバーインスタンスとデータベースの構成
- 詳しくはこちら 追加 下 セカンダリ サーバー インスタンスとデータベース
- セカンダリデータベースの設定 ダイアログ、クリック つながり、 セカンダリ サーバー インスタンスに接続します。
- セカンダリデータベース ドロップダウンで既存のデータベースを選択するか、新しいデータベース名を入力します
- セカンダリデータベースの初期化 タブ、選択 はい、プライマリ データベースの完全バックアップを生成し、それをセカンダリ データベースに復元します (セカンダリ データベースが存在しない場合は作成します)
- クリック ファイルをコピーする タブ
- コピーされたファイルの保存先フォルダ（このフォルダは通常セカンダリサーバーにあります）、セカンダリ サーバー上の宛先フォルダーのローカル パスを入力します。
- フォルダが存在することを確認し、 SQL Server サービスアカウントには書き込み権限があります
- 詳しくはこちら OK 設定を確認してダイアログを閉じます。
4.2.3 監視サーバーの設定
- チェック モニターサーバーインスタンスを使用する
- 詳しくはこちら 設定
- 詳しくはこちら つながり、 監視サーバーインスタンスに接続する
- 作成セッションプロセスで 履歴を削除 保存期間を時間単位で指定する
- 詳しくはこちら OK 設定を確認してダイアログを閉じます。
4.2.4 構成の確認と完了
- すべての設定を確認する トランザクションログの配布 ページ
- バックアップ設定、セカンダリサーバーの構成、監視設定を確認する
- 詳しくはこちら OK 設定を適用する
- ウィザードはプライマリ、セカンダリ、および監視サーバーに必要なすべてのジョブを作成します。
- 詳しくはこちら 閉じる 設定が完了すると
5. 丸太輸送のメリットとデメリット
5.1つのメリット SQL Server ログ出荷
- Cost-効果的な解決策: で動作します SQL Server Standard Editionは、高額なEnterprise Editionのライセンス要件を排除します。これにより、予算が限られている組織でも信頼性の高いディザスタリカバリが可能になります。
- 構成と保守が簡単: 設定ウィザードは、明確なオプションを使用して管理者にセットアップをガイドします。Most 特別なトレーニングなしで、15 ～ 30 分以内にデータベースを構成できます。
- 複数のセカンダリサーバーのサポート: アーキテクチャ上の制限なく、多数のセカンダリサーバーをサポートします。1台はローカルの災害復旧用、もう1台はリモート、そして3台目はレポート作成用に展開できます。
- プライマリサーバーへの影響は最小限: 非同期で動作するため、プライマリサーバーでの同期オーバーヘッドが排除されます。トランザクションのコミット時間には影響しません。
- 既存のトランザクション ログ バックアップを使用します。 ログ シッピング バックアップは、ログ シッピングとは無関係にポイントインタイム リカバリに使用できる標準のトランザクション ログ バックアップです。
- 遅延復元オプション: 復元遅延機能は、次のような偶発的なデータ変更に対する保護を提供します。 リアルタイムレプリケーションソリューション.
- 共有ストレージは不要: 各サーバーで独立したストレージを使用するため、共有ストレージの要件と関連するcが排除されます。osts.
- クロスプラットフォームのサポート： WindowsとLinuxの両方で同じように動作します SQL Server 展開。
- ドメイン間で動作します: ドメイン信頼関係や Active Directory 統合は必要ありません。
5.2 ログシッピングの欠点と制限
- 自動フェイルオーバーなし: 主な制限は、手動フェイルオーバーの必要性です。管理者は、サービスを再開する前に複数の手順を実行する必要があります。
- データ同期の遅れ: セカンダリ データベースは、バックアップと復元の頻度によって常にプライマリ データベースより遅れます。
- データベースレベルの構成のみ: インスタンスレベルではなくデータベースレベルで設定します。50個のデータベースを保護するには、50個の個別の設定が必要です。
- 手動による接続文字列の変更: アプリケーションは、フェールオーバー後にセカンダリ サーバーを指すように接続文字列を更新する必要があります。
- セカンダリ データベースの中断: スタンバイ モードのセカンダリ データベースは、復元操作中にユーザーを切断します。
- 個別のデータベース管理: 各データベース構成は、調整された管理機能なしで個別に管理する必要があります。
6. ベストプラクティスとユースケース
6.1 ログシッピングを使用する場合
- 低予算の災害復旧: acとして優れているostエンタープライズエディションのライセンスを正当化できない組織向けの効果的な災害復旧ソリューションosts.
- 中程度のRPO/RTO要件: 15 ～ 30 分のデータ損失と 30 ～ 60 分のダウンタイムを許容するアプリケーションは、その機能と完全に一致します。
- 読み取り専用レポート サーバー: 定期的な切断を許容するレポートワークロード用の読み取り専用コピーを作成します。
- 標準エディション環境: 標準化された組織 SQL Server Standard Edition では Always On 可用性グループにアクセスできないため、ログ配布が最適なオプションになります。
- サーバー移行プロジェクト: 移行期間中に同期されたコピーを維持することで、サーバーの移行を容易にします。
- 遅延データ要件: コンプライアンスまたは監査の目的で、データベースを過去の固定ポイントに維持するために復元遅延を構成します。
6.2 ログシッピングを使用しない場合
- ほぼゼロのダウンタイム要件: RTO 要件が 15 分未満のアプリケーションでは、手動フェイルオーバーに依存できません。
- 自動フェイルオーバーが必要: ビジネス要件により管理者の介入なしに自動フェイルオーバーが要求される場合は不適切です。
- リアルタイム同期が必要: セカンダリ サーバー上でリアルタイムまたはほぼリアルタイムのデータを必要とするアプリケーションは、ログ シッピングの固有の遅延を受け入れることができません。
- 最小限のデータ損失許容度: RPO が数秒単位で測定される組織、またはデータ損失ゼロを要求する組織には、同期ソリューションが必要です。
6.3つのベストプラクティス
- バックアップ頻度の最適化: バックアップ頻度とシステムオーバーヘッドおよびリカバリ目標のバランスをとる。Star15 分間隔で実行し、実際の要件に基づいて調整します。
- ネットワークパスの考慮事項: バックアップ先には、マップされたドライブではなくUNCパスを使用してください。バックアップ共有は、信頼性の高いネットワークインフラストラクチャ上に配置してください。
- 監視とアラートの設定: ログ配布のセットアップが完了したらすぐに、バックアップ、コピー、および復元ジョブの失敗に関するアラートを構成します。
- 定期テストスケジュール: 手順を検証し、管理者の準備を維持するために、四半期ごとまたは半年ごとのフェールオーバー テストをスケジュールします。
- ドキュメントのメンテナンス: 構成の詳細、フェールオーバー手順、トラブルシューティング手順を文書化した詳細なランブックを維持します。
- セキュリティに関する考慮事項: 必要最小限の権限を持つ専用のサービスアカウントを使用してください。ネットワーク共有の権限を適切に制限してください。
- ディスク容量の管理: バックアップ先のディスク容量を継続的に監視します。容量が20%を下回った場合にアラートを設定します。
- 保持ポリシーの構成: バックアップ保持期間を、許容可能な最大同期遅延よりも長く設定します。
- 保護のための復元遅延: 偶発的な変更に対する保護のために同期の遅延を増やす必要がある場合は、復元の遅延を構成します。
7. 一般的な問題のトラブルシューティング
7.1 バックアップジョブの失敗
- ディスク容量不足: ジョブ履歴でディスク容量エラーがないか確認してください。古いバックアップを削除するか、圧縮を有効にして、使用可能な容量と空き容量を確認してください。
- 権限の問題: その SQL Server サービス アカウントには、ローカル フォルダーとネットワーク共有の両方に対するフル コントロール権限があります。
- データベースが完全に回復していない: 完全復旧モデルに戻して、res の完全バックアップを取得します。tarトランザクション ログ チェーン。
7.2 コピージョブの失敗
- ネットワーク パスにアクセスできません: ネットワーク パスを手動でマッピングして、セカンダリ サーバーからの接続をテストします。
- 認証の問題: サーバーが異なるドメインにある場合は、ネットワーク共有アクセス用の明示的な資格情報を構成します。
- ファイルロックの問題: ファイルのロックを防ぐために、バックアップ フォルダーをウイルス対策のリアルタイム スキャンから除外します。
7.3 復元ジョブの失敗
- バックアップファイルが見つかりません: 宛先フォルダーにファイルが存在することを確認し、コピージョブの履歴を確認します。
- 復元シーケンスエラー: 不足しているトランザクション ログ バックアップを識別し、それらを順番に復元してログ チェーンを修復します。
- データベースの状態が間違っています: 誰かがデータベースを回復した場合は、NORECOVERY で完全バックアップを復元してログ配布を再初期化します。
- データベースファイルの破損: 正しい手順と設定にもかかわらず復元に失敗する場合は、データベースファイル自体が破損している可能性があります。そのような場合は、専用のツールを使用する必要があります。 SQLリカバリツール ログ配布の再初期化を試みる前に、破損した .MDF ファイルと .NDF ファイルからデータを抽出します。
7.4 同期の遅れの問題
- ネットワーク帯域幅の制限: バックアップ圧縮を有効にすると、ファイル サイズと帯域幅の要件が削減されます。
- 高い取引量: より小さく、管理しやすいバックアップ ファイルを作成するには、バックアップ頻度を増やすことを検討してください。
- 不十分な復元頻度: 復元ジョブの頻度を増やしてバックアップ頻度に近づけ、遅延を最小限に抑えます。
7.5 サーバー接続の問題を監視する (SQL 2025)
- OLE DB プロバイダー エラー: SQL Server 2025 のデフォルトの強制暗号化は、適切な暗号化構成がない古いインスタンスと競合します。
- 暗号化構成の不一致: 監視サーバー上のリンク サーバー構成を確認し、暗号化設定をチェックします。
- 回避策: TLS 1.3パラメータを使用してログシッピングを削除して再作成するか、すべてのインスタンスをアップグレードしてください。 SQL Server 2025.
7.6 SQL Server エージェントサービスの問題
- サービスSではないtarテッド： エージェントのサービスステータスを確認し、sに設定しますtar自動的には行われません。
- ジョブスケジュールが無効: ジョブ スケジュールのステータスを確認し、無効なスケジュールを有効にします。
- ジョブステップの失敗: ジョブ履歴を確認して、失敗した手順と具体的なエラー メッセージを特定します。
8. よくある質問 (FAQ)
Q: Express Edition でログ配布を使用できますか?
A：いいえ、 SQL Server Express Editionはログ配布をサポートしていません。 SQL Server エージェント。
Q: ログ バックアップはどのくらいの頻度でスケジュールする必要がありますか?
A: デフォルトの15分間隔で十分なバランスが取れています。目標復旧時点に応じて調整してください。
Q: セカンダリ データベースをレポートに使用できますか?
A: はい、スタンバイ モードで構成されたセカンダリ データベースでは、復元操作間で読み取り専用アクセスが許可されます。
Q: プライマリ サーバーに障害が発生するとどうなりますか?
A: 手動フェイルオーバーを実行してセカンダリデータベースをオンラインにします。データ損失は、障害発生時の同期遅延と同額になります。
Q: セカンダリサーバーを複数持つことはできますか?
A: はい、ログ配布は独立した構成を持つ無制限のセカンダリ サーバーをサポートします。
Q: 同期ラグはどのように計算しますか?
A: ログ配布監視テーブルを使用して、最後に復元されたトランザクション ログのタイムスタンプを現在の時刻と比較します。
Q: ログ配布は異なるドメイン間で機能しますか?
A: はい、信頼関係を必要とせずに、異なるドメイン間またはワークグループ環境でも動作します。
Q: ノーリカバリモードとスタンバイモードの違いは何ですか?
A: リカバリモードではデータベースにアクセスできなくなります。スタンバイモードでは、復元間の読み取り専用クエリが許可されます。
Q: ログの配送テンポを一時停止できますか？rarイリー？
A: はい、バックアップ、コピー、および復元ジョブを無効にして、構成を保持しながら同期を一時停止します。
Q: ログ配布構成を削除するにはどうすればよいですか?
A： トランザクションログの配布 プロパティページ:
- チェックしない ログ配布構成でプライマリデータベースとしてこれを有効にする
- 詳しくはこちら OK 構成を削除し、ジョブを削除します。
Q: セカンダリ データベースを読み取り/書き込みモードに切り替えることはできますか?
A: はい、RESTORE DATABASE WITH RECOVERY を実行しますが、これによりログ配布チェーンが中断されます。
Q: 復元に設定できる最大遅延はどれくらいですか?
A: 厳格な制限はありません。保護要件に応じて、数分から数日までの遅延時間を設定できます。
Q: ログ配布はバックアップ戦略にどのような影響を与えますか?
A: ログ配布とポイントインタイムリカバリの両方に使用できるトランザクション ログ バックアップを作成します。
Q: サーバーの移行にログ配布を使用できますか?
A: はい、新しいサーバーへのログ配布を構成し、同期してから、メンテナンス中に古いサーバーの計画されたフェイルオーバーを実行します。
Q: ログ シッピングで動作する監視ツールは何ですか?
A: SQL Server Management Studioには組み込みレポートが含まれています。SQL MonitorやSolarWindsなどのサードパーティツールは、強化された監視機能を提供します。
9. 結論と推奨事項
9.1 重要なポイントのまとめ
SQL Server ログシッピングは信頼性の高いcを提供しますost自動化されたトランザクションログのバックアップと復元操作による、効果的な災害復旧を実現します。このテクノロジーはStandard Editionで動作し、最小限のインフラストラクチャで複数のセカンダリサーバーをサポートします。
ログ配布は、手動フェイルオーバーが許容される中程度の復旧目標に最適です。主な制限事項としては、手動フェイルオーバーの必要性、同期の遅延、データベースレベルの構成範囲などがあります。
このテクノロジーは既存のバックアップ戦略と適切に統合され、スタンバイ モードによる読み取り専用レポートをサポートし、偶発的な変更に対する遅延復元保護を提供します。
9.2 環境に適した選択をする
実装前に、ログシッピングを特定の要件に照らして評価してください。復旧ポイント目標、復旧時間目標、予算制約、運用の複雑さの許容範囲を考慮してください。
使用している組織 SQL Server 中程度のリカバリ要件を持つStandard Editionでは、ログ配布を強く検討する必要があります。RTOが15分未満の厳しいエンタープライズでは、Always On可用性グループを検討することをお勧めします。
ログシッピングと他の技術を組み合わせたハイブリッドアプローチを検討するost 多様な要件を満たしながら最適化します。
9.3 次のステップと追加リソース
小規模なパイロット実装から始めて経験を積み、構成の詳細、フェイルオーバー手順、トラブルシューティングガイドなどを含む包括的なドキュメントを作成します。
定期的なフェイルオーバーテストをスケジュールして手順を検証し、管理者の準備態勢を維持します。 SQL Server アップデートと機能強化。
参考情報
- Microsoft 公式ドキュメント: ログシッピングについて（SQL Server)
- Microsoft 公式ドキュメント: ログ配布を構成する（SQL Server)
著者について
袁勝 10年以上の経験を持つ上級データベース管理者（DBA）です。 SQL Server 環境およびエンタープライズデータベース管理に精通しており、金融サービス、医療、製造業など、様々な組織において数百件のデータベース復旧シナリオを解決してきました。
ユアンの専門は SQL Server データベースの復旧、高可用性ソリューション、パフォーマンス最適化など、幅広い分野に精通しています。彼は、マルチテラバイト規模のデータベースの管理、Always On可用性グループの実装、ミッションクリティカルなビジネスシステム向けの自動バックアップおよび復旧戦略の開発など、豊富な実務経験を有しています。
Yuanは、技術的な専門知識と実践的なアプローチを通じて、データベース管理者やITプロフェッショナルが複雑な問題を解決するのに役立つ包括的なガイドの作成に重点を置いています。 SQL Server 効率的に課題に取り組みます。常に最新の SQL Server リリースと Microsoft の進化するデータベース テクノロジを活用し、定期的にリカバリ シナリオをテストして、推奨事項が実際のベスト プラクティスを反映していることを確認します。
について質問があります SQL Server 回復または追加のデータベーストラブルシューティングガイダンスが必要ですか？Yuanは歓迎します フィードバックと提案 これらの技術リソースを改善するためです。