Rainbow Engine

IT技術を分かりやすく簡潔にまとめることによる学習の効率化、また日常の気付きを記録に残すことを目指します。

SQLServer

SQLServerの復旧モデルの「単純」と「完全」と「一括ログ」の違いについて

投稿日:2020年11月29日 更新日:

<目次>

(1) SQLServerの復旧モデルの「単純」と「完全」と「一括ログ」の違いについて
 (1-1) 復旧モデルの概要
 (1-2) 復旧モデルの比較表
 (1-3) トランザクションログが肥大化してしまった場合の対処

(1) SQLServerの復旧モデルの「単純」と「完全」と「一括ログ」の違いについて

(1-1) 復旧モデルの概要

SQL Serverの「復旧モデル」はバックアップの種類(完全/単純/一括ログ)を定義する設定値です。この設定に従って取得したトランザクションログを用いて、非常時にリストアをして復旧作業を行います。下表ではそれぞれの設定値の概要をまとめています。

(図111)「復旧モデル」のSSMSでの確認方法
SSMSのオブジェクトエクスプローラーにてDBを右クリック⇒プロパティ⇒プロパティ左メニュー「オプション」から見る事ができます。

(表1)各モデルの概要

単純モデル ・SQL Server Express Editionのデフォルト値。
・トランザクションログの領域はチェックポイントが発生すると、自動で再利用されます(拡張はせずに、既存の領域を再利用していく)
・トランザクションログは拡張せずに再利用されるため、トランザクションログのバックアップ取得が不可
・そのため、リカバリは最後にバックアップを取得した地点からのみ可能。
完全モデル ・SQL Server Standard Editionのデフォルト値
・バックアップまたはトランザクションログの圧縮を行わない限りはログが肥大化していきます。
・全ての取引(DDL+DML)がトランザクションログに記録され、単純モデルの様にチェックポイントが発行されてもログは切り捨てされません。
・トランザクションログのバックアップを取得する事で、初めてTRUNCATEが可能になります。
一括ログモデル ・基本的な挙動は「完全モデル」と非常に似ていますが、唯一の違いは、特定の一括オペレーションに対するトランザクションログへの書き込みを最小限にしている点です。
・これは一括オペレーション(バルクロードなど)のパフォーマンスを改善するために、そしてトランザクションログの肥大化を防ぐ目的の設定になります。

目次にもどる

(1-2) 復旧モデルの比較表

上記3つの復旧モデルについて、機能別に比較したのが次の表です。各モデル毎に「復旧」と「バックアップ」と「トランザクションログ」の3つの区分の機能について、その利用可否を○×付けています。

(表2)各モデルの機能別利用可否

カテゴリ 項目名 単純
復旧モデル
一括ログ
復旧モデル
完全
復旧モデル
復旧 最後のバックアップ地点へのリストア
(注1)
復旧 Point-in-Timeリカバリ ×
(注2)
復旧 ページリストア ×
復旧 ファイルリストア ×
(注3)

(注3)
バックアップ 全体バックアップ
バックアップ 差分バックアップ
バックアップ コピーのみのバックアップ
Copy-Only Backup
(注4)
×
バックアップ ファイルバックアップ
(注5)
×
バックアップ トランザクションログバックアップ ×
(注6)
トランザクションログ ログ容量 当初確保量から増えない TXNログのバックアップ取得まで増え続ける TXNログのバックアップ取得まで増え続ける

(注釈)

(注1) ・単純モードであっても、これは可能。
(注2) ・トランザクションログのバックアップが「一括ログ変更」を含む場合はPoint-in-Timeリカバリは不可。
(注3) ・「完全」と「一括ログ」の場合、リストアを行う前に「アクティブ状態」のトランザクションログ(ログの尻尾)のバックアップを取得する必要あり。
(注4) ・「コピーのみのバックアップ」は差分バックアップのベースとしては利用できません。
(注5) ・複数のデータファイルがある時など、別々のファイルにバックアップを取得する事ができます。
(注6) ・単純モードではトランザクションログは増えずにローテーションされるため、バックアップは不可。

目次にもどる

(1-3) トランザクションログが肥大化してしまった場合の対処

復旧モードが「完全」の場合など、トランザクションログのバックアップを取らずにいると、ストレージの限界まで肥大化(拡張)し続けて、ディスクを圧迫するケースがあります。こちらの対処法については長くなるので別途記載予定

目次にもどる

Adsense審査用広告コード


Adsense審査用広告コード


-SQLServer

執筆者:


comment

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

関連記事

SQL ServerのAlwaysOn可用性グループ(Availability Groups)とは?

  <目次> (1) SQL ServerのAlwaysOn可用性グループ(Availability Groups)とは?  (1-1) SQL ServerのAlwaysOnとは?  (1 …

OracleデータベースとSQL Serverを冗長性の機能面での比較検討

(0)目次 (1) 冗長性の機能(Oracle)  (1-1) Oracle RAC  (1-2) Oracle Fail Safe (2) 冗長性の機能(SQL Server)  (2-1) Alw …

SQL Serverで起きる「ハンドシェイクエラー」の原因について

<目次> (1) SQL Serverで起きる「ハンドシェイクエラー」の原因について  (1-1) 発生状況・エラーメッセージ  (1-2) 原因  (1-3) 参考:SSPIとは? (1) SQL …

SQLServerのExpressエディションをインストールする手順

<目次> (1) SQLServerのExpressエディションをインストールする手順  (1-1) SQLServerのExpress版インストール手順  (1-2) SSMSのインストール (1) …

SQLServerでクエリの履歴のトレースログを出力する方法

  <目次> (1) SQLServerでクエリの履歴のトレースログを出力する方法  (1-1) 概要  (1-2) 手順  (1-3) (参考)トレースの出力状況の確認方法  (1-4) …

  • English (United States)
  • 日本語
Top