ここでは、データベーススペシャリスト試験の対策として、『バックアップ』についての問題を扱った過去問の解説を紹介します。対象は、平成28年度午後1問2の問題となります。
出題趣旨
・バックアップ、回復を実行する際には、対象を見極め、業務への影響を理解・整理し、その結果を適切にバックアップ・回復計画に反映させることが求められる。
・データベースのバックアップ・回復機能についての理解
・システムの環境条件、運用状況に応じた適切なバックアップ・回復手順の設計能力
設問1ー（1）
設問は次となっている。
下記の〔バックアップ及び回復の方針〕と表1、表2を読み、整理していく。
| マスタ更新登録 | 商品 | 仕入先 | 販売先 | 受注 | 出荷指図 | 出荷 | 在庫 | 発注対象データ | 需要予測 | 日別販売実績 | 月別販売実績 | 分析用データ | |
| T1 | ○ | ||||||||||||
| T2 | ○ | ○ | ○ | ○ | ○ | ||||||||
| T3 | ○ | ○ | |||||||||||
| T4 | ○ | ○ | |||||||||||
| T5 | ○ | ○ | ○ |
【マスタ更新登録】表1のオンラインの「取引先管理」「商品情報管理」で「C：作成」されるので、〔仕様〕からオンラインプログラムで更新され得るテーブルは、オンライン時間帯直後にバックアップ採取するので、『T1』となる。
【商品】表1のマスタ更新登録で作成・更新されるので、表2の実行スケジュールを確認し、〔仕様〕からパッチプログラムの直前でバックアップ採取するので、『T5』となる。
【仕入先】表1のマスタ更新登録で作成・更新されるので、表2の実行スケジュールを確認し、〔仕様〕からパッチプログラムの直前でバックアップ採取するので、『T5』となる。
【販売先】表1のマスタ更新登録で作成・更新されるので、表2の実行スケジュールを確認し、〔仕様〕からパッチプログラムの直前でバックアップ採取するので、『T5』となる。
【受注】表1のオンラインの「出荷処理」で「C：作成」されるので、〔仕様〕からオンラインプログラムで更新され得るテーブルは、オンライン時間帯直後にバックアップ採取するので、『T1』となる。
【出荷指図】表1のオンラインの「受注管理」で「C：作成」されるので、〔仕様〕からオンラインプログラムで更新され得るテーブルは、オンライン時間帯直後にバックアップ採取するので、『T1』となる。
【出荷】表1の「出荷計上」で「C：作成」されるので、表2の実行スケジュールを確認し、〔仕様〕からパッチプログラムの直前でバックアップ採取するので、『T1』となる。
【在庫】表1のオンラインの「受注管理」「発注処理」で「C：作成、U：更新」されるので、〔仕様〕からオンラインプログラムで更新され得るテーブルは、オンライン時間帯直後にバックアップ採取するので、『T1』となる。
【発注対象データ】表1の「発注対象データ」で「C：作成」されるので、表2の実行スケジュールを確認し、〔仕様〕からパッチプログラムの直前でバックアップ採取するので、『T4』となる。
【需要予測】表1の「需要予測」で「C：作成」されるので、表2の実行スケジュールを確認し、〔仕様〕からパッチプログラムの直前でバックアップ採取するので、『T3』となる。
【日別販売実績】表1の「販売実績日時集計」で「C：作成」されるので、表2の実行スケジュールを確認し、〔仕様〕からパッチプログラムの直前でバックアップ採取するので、『T2』となる。
【月別販売実績】表1の「販売実績月次集計」で「C：作成、U：更新」されるので、表2の実行スケジュールを確認し、〔仕様〕からパッチプログラムの直前でバックアップ採取するので、『T3』となる。
【分析用データ】表1の「分析用データ作成」で「C：作成、U：更新」されるので、表2の実行スケジュールを確認し、〔仕様〕からパッチプログラムの直前でバックアップ採取するので、『T4』となる。
設問1ー（2）
設問は次となっている。
各行の障害発生時に並行して処理しているパッチプログラムの処理方法は次の2パターンとなる。
①影響がある場合→再実行
②影響がない場合→継続処理
【2行目】
＜状況＞
パッチプログラムの「販売実績日次集計」の参照する「出荷」テーブルが障害を受け、処理に影響が出ている。
＜対応＞
・”出荷”テーブルの復元を行う。
・”出荷計上”が正しく処理された状態にする。
＜方法1＞再実行
＜方法2＞更新ログによるロールフォワード処理
【3行目】
＜状況＞
マスタ更新反映と関係のあるテーブルは下記の4つ。
①マスタ更新登録
②商品
③仕入先
④販売先
このうち、②商品で障害が発生。
3行目①では、復元処理を行なっており、「マスタ更新反映」を実行するために、関係するテーブルを正常な状態にしなければならない。
したがって、①マスタ更新登録は参照のみのため除いた、②商品、③仕入先、④販売先が、空欄（ｂ）（ｃ）（ｄ）（順不同）となる。
また、復元後は、『再実行（空欄（e））』することで、正常に完了する。
3行目②では、”分析用データ作成”の処理について問われている。
表1の「分析用データ作成」から今回障害が発生した”商品”とは関係ないことが分かり、「分析用データ作成」は影響を受けない。したがって、処理を『継続』する。
設問2
設問2ー（1）
【在庫テーブル】
「毎日頻繁に変更される」という記載から、更新の方が多いと考えられる。
差分バックアップの場合、全体バックアップと全体バックアップ後に更新された全てのページののバックアップになる。更新お方が多い場合、全体と最新日の差分バックアップになる。
増分バックの場合、全体バックアップと変更されたページのバックアップになる。更新の方が多い場合、全体と日毎（毎日）の変更ページのバックアップになる。
したがって、”在庫”テーブルのバックアップの種類は『差分』となり、
選択根拠は、『容量』
理由は、
『変更されるページが特定範囲に局所化されているから』
『増分バックアップでは、特定範囲のページが繰り返し含まれるから』
となる。
【出荷テーブル】
「毎日、約400,000行が追加される」とあるように、更新よりも追加が多い。
追加が多い場合は、『増分』バックアップが良い。
増分バックアップの場合、全体と毎日の増えた分のページのバックアップになる。
差分バックアップの場合、全体と変更されたページになる。この時、挿入される行の位置が重要になる。新しいページに次々と追加されるされる場合は変わらないが、全体バックアップ時にあるページに追加されていく場合、「変更されたページ」となるので、仮に全ページに対して行が挿入された場合は、全体と全ページのバックアップが必要になる。
したがって、”出荷”テーブルのバックアップの種類は『増分』となり、
選択根拠は、『時間』
理由は、
『その日の追加ページ分だけのバックアップで済むから』
『差分バックアップでは、毎日ページ数が増えていくから』
となる。
ポイント
＜ポイント＞
【増分バックアップのメリット】
・日々のバックアップ取得時間が短い。
・日々のバックアップ容量は、増分も差分も変わらない。
・復元の時間もテーブル交換等の物理作業がなければ、変わらない。
🔹バックアップ方式の要点整理
| 種類 | 内容 | 特徴 | 適するケース |
|---|---|---|---|
| 全体バックアップ | 全データを毎回保存 | 最も単純だが時間・容量が大 | 変更頻度が少ないテーブル |
| 差分バックアップ | 最後の全体バックアップ以降の変更ページすべて | 時間・容量が日々増加 | 変更が局所的な場合 |
| 増分バックアップ | 前回のバックアップ以降の変更ページのみ | 毎日のバック容量が小さい | 追加が多い場合（変更範囲が広がりにくい） |
設問2ー（2）
〔プログラムとテーブルの関係〕から、「再作成可能」であることが分かる。したがって、バックアップを月初のみにしても、”販売実績”から再作成可能であり、影響は少ないと考えられるので、『”分析用データ”テーブル』となる。
設問2ー（3）
〔プログラムとテーブルの関係〕から、『”分析用データ”テーブルは、〜蓄積されている販売実績を基に、再作成することも可能である』と記載があるように、これが答えになる。
設問3ー（1）
まずは、表1を確認し、状況を整理する。
＜関係あり＞
パッチ；出荷計上
テーブル；商品、出荷指図、出荷、【在庫】←問題発生！
【在庫】の問題発生により影響があるパッチは、
・需要予測
・発注対象データ作成
したがって、この2つは、プログラムの不良を修正後、再実行しなければ正常な値を得ることができない。
図1から、「需要予測」→「発注対象データ作成」の順にパッチプログラムを実行するので、
（ア）需要予測
（イ）需要予測
（ウ）発注対象データ
（エ）発注対象データ作成
となる。
設問3ー（2）
その他のパッチプログラムは、図1から下記の3つである。
・販売実績日次集計
・販売実績月次集計
・分析用データ作成
これらについて、関係のあるテーブルを表1から整理すると、下記のようになる。
・販売実績日次集計；商品、販売先、出荷、日別販売実績
・販売実績月次集計；日別販売実績、月別販売実績
・分析用データ作成；日別販売実績、月別販売実績、分析用データ
よって、今回問題が発生した”在庫”テーブルは参照していないので、これらのパッチプログラムは正常に終了しているので、再実行する必要はない。
したがって、回答としては下記のようになる。
・『”在庫”テーブルとそのデータを反映したテーブルを参照しないから』
・『”在庫”テーブルの不正な内容の影響を受けるテーブルを参照しないから』
・『”在庫”、”需要予測”、”発注対象データ”の各テーブルを参照しないから』
以上。
ポイント
障害発生時のパッチ処理と回復手順（設問2・3）
| 項目 | ポイントとなる知識/技能 |
| パッチ処理の判断 | 論理障害が発生したテーブルに対し、並行して実行中のパッチプログラムが参照または更新しているかをデータフロー（図1）と仕様（表1）から確認する。影響があれば再実行、なければ継続とする。 |
| 復旧時の再実行判断 | あるテーブルの論理障害（データ不正）を回復（復元）した場合、その不正なデータを参照して処理を進めたパッチプログラムは、正しい結果を得るために必ず再実行が必要となる。 |
| 影響連鎖の把握 | 図1のデータフローから、障害発生元のテーブルを参照するプログラムだけでなく、その不正な結果を参照して後続の処理を行った連鎖的なパッチプログラム（例：「在庫」→「需要予測」→「発注対象データ作成」）もすべて再実行が必要となることを把握する。 |
| 再実行の不要な理由 | 影響のないパッチプログラムについて、「なぜ再実行が不要か」を論理的に説明する。解答の要点は「障害の影響を受けたテーブル（とそれを反映したテーブル）を参照していないから」となる。 |
設問2ー（2）
設問2ー（3）
ポイント
業務特性に応じたバックアップ計画（設問1・2）
| 項目 | ポイントとなる知識/技能 |
| バックアップタイミング | データ更新の特性（オンライン処理かバッチ処理か）と参照の整合性を理解し、**RPO（目標復旧時点）**を考慮してバックアップ時刻（T1～T5）を決定する。 |
| バックアップの種類 | テーブルごとのデータ変化特性（更新頻度、追加頻度）に基づき、「差分」と「増分」のどちらが容量と時間の面で最適か判断する。特に「在庫」と「出荷」のケースは、更新と追加の特性を理解する良い訓練となる。 |
| 「差分」と「増分」の比較 | 差分は復旧時間が短い（フル＋最新差分）が、取得容量と時間が日を追うごとに増大する。増分は取得容量と時間が安定するが、復旧時に全増分を適用するため復旧時間が長くなる。 |
障害発生時のパッチ処理と回復手順（設問2・3）
| 項目 | ポイントとなる知識/技能 |
| パッチ処理の判断 | 論理障害が発生したテーブルに対し、並行して実行中のパッチプログラムが参照または更新しているかをデータフロー（図1）と仕様（表1）から確認する。影響があれば再実行、なければ継続とする。 |
| 復旧時の再実行判断 | あるテーブルの論理障害（データ不正）を回復（復元）した場合、その不正なデータを参照して処理を進めたパッチプログラムは、正しい結果を得るために必ず再実行が必要となる。 |
| 影響連鎖の把握 | 図1のデータフローから、障害発生元のテーブルを参照するプログラムだけでなく、その不正な結果を参照して後続の処理を行った連鎖的なパッチプログラム（例：「在庫」→「需要予測」→「発注対象データ作成」）もすべて再実行が必要となることを把握する。 |
| 再実行の不要な理由 | 影響のないパッチプログラムについて、「なぜ再実行が不要か」を論理的に説明する。解答の要点は「障害の影響を受けたテーブル（とそれを反映したテーブル）を参照していないから」となる。 |
