データベーススペシャリスト試験 2016年 午後1 問02

1. 模範解答に至るキーワード・論点整理

2. 具体的な導出手順と根拠の説明

2.1 まずオンライン終了直後（T1）

2.2 「出荷計上」開始直前も T1

2.3 T2（「受注明細書送信」「販売実績日次集計」開始直前）

2.4 「販売実績月次集計」開始直前（T3）

2.5 「需要予測」および 「発注対象データ作成」開始直前（T4）

2.6 T5（「分析用データ作成」「マスタ更新反映」開始直前）

3. 受験者が迷いやすいポイント

4. 試験対策まとめ

1. バックアップ運用の典型パターン
   • オンライン終了直後：オンライン更新テーブルを一括取得
   • 以降は バッチ開始直前 にそのバッチが更新するテーブルだけ
   • 同じ日に二度取得する必要はない
2. “更新”判定
   • C（新規行追加）も U（既存行更新）もどちらも更新対象
   • R はバックアップ不要
3. 表1 の読み取りコツ
   • 行＝プログラム，列＝テーブル
   • C/U/R を素早く拾う訓練をしておく
4. スケジュール図の矢線
   • 縦線（T1～）が契機，右側の矩形が“その契機で起動するバッチ”
   • 矢線は 依存関係（先完了→後起動）を示す
5. 本問以外でも出題されやすいキーワード
   • 全体／増分／差分バックアップの違い
   • ロールフォワード（更新ログ回復）とロールバック
   • ページ単位 I/O と表の行数・行サイズ計算

1. 論点整理（キーワード・核心事項）

2. 各空欄の解答理由

（a） 更新ログによる回復機能／更新ログを用いたロールフォワード処理

• 【問題文】
  「(2) 更新ログによる回復に要する時間は,更新ログの量に比例する。」
  「(1) バックアップを用いて復元した後, 更新ログを用いたロールフォワード処理によって指定の時刻の状態に回復できる。」
• 論理
  “販売実績日次集計” 実行中に “出荷” テーブルへの I/O で障害が起きた場合、まずバックアップで「出荷」テーブルを当初の状態に戻し、続いて障害検知前までの更新内容を復元するために 「更新ログによる回復機能」 （別名 「更新ログを用いたロールフォワード処理」）を用います。

（b）、（c）、（d） “商品”／“仕入先”／“販売先”

• 【問題文】
  「(1) “商品”テーブル, “仕入先” テーブル及び “販売先” テーブルの追加、変更の要求は, ‘マスタ更新登録’ テーブルに登録され, バッチプログラムで 1件ずつコミットしながら反映される。」
• 論理
  “マスタ更新反映” プログラムがアクセスするのは、この３つのマスタテーブルです。障害発生後、これらを当日のオンライン時間帯直後の状態に戻すため、 “商品”、“仕入先”、“販売先” の順序は不問ですが、すべて復元対象となります。

（e） 再実行

• 【問題文】
  障害検知後の第１段階～第４段階の手順では、
  • 「第１段階 … バッチプログラム ‘出荷計上’ を再実行」
  • 「第２段階 … バッチプログラム ‘（イ）’ を再実行」
• 論理
  失敗したバッチを正常に完了させるには、当初の先頭からもう一度動かす 「再実行」 が必要です。“マスタ更新反映” も同様に 再実行 します。

（f） 継続

• 【問題文】
  「第４段階 バッチプログラム ‘マスタ更新反映’ を実行する。」
  「バッチプログラム ‘分析用データ作成’ を継続する。」
• 論理
  “分析用データ作成” はマスタ反映後に続行されるバッチです。障害前に起動していた分を途中から止めずに 「継続」 します。

3. 解答一覧

4. 誤りやすいポイント

• バックアップと復元の混同
  増分／差分バックアップと「更新ログによる回復」は別物です。バックアップは「過去のイメージ」を保持し、ロールフォワードは「ログから最新状態を再構築」します。
• 再実行と継続の使い分け
  一度も処理されなかったバッチは「再実行」、途中で止まっていたバッチは「継続」。これを逆に使うと、二重実行や未処理状態のままになる恐れがあります。
• マスタテーブルの範囲
  マスタ更新反映が対象とするテーブルは必ず問題文記載の３つのみ。“日別販売実績”や“在庫”などを含めない点に注意。

5. 試験対策として押さえておくべき知識

1. バックアップ種類の特徴と取得コスト
2. 復元単位と復元手順（データベース単位 vs テーブル単位）
3. 更新ログ（リカバリログ）を用いたロールフォワード処理の概要
4. バッチ障害発生時の復旧手順における「再実行」と「継続」の違い
5. マスタデータ更新フローと、バッチ実行スケジュールの依存関係の読み取り

キーワードと論点整理

• バックアップの種類
  • 全体バックアップ：全ページを取得
  • 増分バックアップ：前回の全体／増分バックアップ以降に変更されたページを取得
  • 差分バックアップ：前回の全体バックアップ以降に変更された全てのページを取得
• バックアップ時間は「取得するページ数に比例」
• テーブルの変更規模（1ページあたり40行）
  • “在庫”テーブル：毎日約1,000行変更 ⇒ 約25ページ変更
  • “出荷”テーブル：毎日約400,000行追加 ⇒ 約10,000ページ追加

解答例

なぜこの解答になるか

“在庫”テーブル：増分 × 容量

1. 問題文より
   “在庫”テーブルは「約 1,000 行が毎日頻繁に変更される」。
2. ページ数換算
   1,000 行 ÷ 40 行/ページ = 約 25 ページ
3. 増分 vs 差分
   • 増分バックアップ：前回のバックアップ以降に変更された約 25 ページのみ取得
   • 差分バックアップ：前回の 全体 バックアップ以降の変更ページすべて（累積）を取得 → 日を追うごとにサイズ増大
4. 結論
   取得ページ数が少ない増分バックアップを選び、「容量」を基準とする

“出荷”テーブル：増分 × 時間

1. 問題文より
   “出荷”テーブルには「毎日, 約 400,000 行が追加される」。
2. ページ数換算
   400,000 行 ÷ 40 行/ページ = 10,000 ページ
3. 増分 vs 差分
   • 増分バックアップ：当日の追加ページ 10,000 ページのみ取得
   • 差分バックアップ：全体バックアップ以降の追加 ページが累積 → 日ごとに増大
4. 結論
   バックアップ時間 ∝ 取得ページ数 なので、増分バックアップを選び、「時間」を基準とする

受験者が誤りやすいポイント

• 「増分」と「差分」の定義を取り違えない
  • 増分：直前のバックアップ以降の変更分
  • 差分：前回の 全体 バックアップ以降の全変更分
• バックアップ取得時間は「ページ数」に比例することを必ず確認
• 問われている基準（容量／時間）を正しく区別する

試験対策として覚えておくポイント

1. 増分／差分バックアップの特徴を整理
2. データ量を実数値でページ換算し、大きい・小さいを判断
3. 取得時間は「バックアップページ数 × 定数」
4. 設問の「どちらを選ぶか」「容量か時間か」を問題文の条件に即して明示的に回答する

1. 模範解答のキーワード・論点整理

• 答え：“分析用データ”テーブル
• 論点：
  • 再作成可能であること
  • 日々のバックアップを省略しても，必要時にバッチ処理で復元できること

2. なぜ“分析用データ”テーブルか

(5) “分析用データ” テーブルは, 販売分析で使用する。 当日分の販売実績が,前日に作成された“分析用データ” テーブルに反映され, 直近3年分の分析結果となるように維持されている。
“分析用データ” テーブルは, バッチプログラム “分析用データ作成” を用いて,蓄積されている販売実績を基に, 再作成することも可能である。

• 再作成可能という性質があるため，万一日々のバックアップを取得していなくても，
  バッチプログラム「分析用データ作成」を実行すれば，テーブルを最新状態に再構築できる。
• 他のテーブル（在庫テーブルや出荷テーブル，日別／月別販売実績テーブルなど）は，
  バックアップがなければその日の更新分を取り戻せないため，日々のバックアップが必須となる。

3. 受験者が誤りやすいポイント

• 「再作成可能」かどうかを問題文から正確に読み取ることがポイントです。
• 「再作成できる」と明示されているテーブルは極めて少ないため，そこに注意しましょう。

4. 試験対策：覚えておくべきポイント

1. 再作成可能なデータは日次バックアップを省略できる
   • 問題文で「再作成することも可能である」と書かれているかを探す。
2. バックアップの種類と単位
   • 全体／増分／差分バックアップの特徴を整理する。
3. 復元運用の優先順位
   • 業務への影響度（受注・出荷・発注・在庫管理）を基準に優先度付け。
4. バッチ処理の再実行可否
   • 依存関係図や説明文から，どのテーブルがバッチで再構築可能かを見抜く。

キーワードと論点整理

• 対象テーブル：問題文の（2）で指すのは「分析用データ」テーブル
• 再作成可能性：「分析用データ」テーブルはバッチ処理で再作成可能
• 再作成手段：バッチプログラム「分析用データ作成」を用いる
• 基データ：直近3年分の「日別販売実績」「月別販売実績」などに蓄積された販売実績

解答の論理的根拠

“分析用データ” テーブルは, 販売分析で使用する。 当日分の販売実績が,前日に作成された“分析用データ” テーブルに反映され, 直近3年分の分析結果となるように維持されている。“分析用データ” テーブルは, バッチプログラム “分析用データ作成” を用いて,蓄積されている販売実績を基に, 再作成することも可能である。

誤りやすいポイント

• 他テーブルと混同：日別/月別販売実績テーブルはバックアップが壊れていたら復元・ロールフォワードが必要だが、再作成はできない。
• バックアップ／ロールフォワード万能説：バックアップが壊れている場合、通常の差分・ログ適用では復旧できない点を見落としやすい。
• 全テーブル再実行案：出荷／在庫など全テーブルを一律に復元・再実行すると、時間も手間もかかるうえ、販売分析業務は不要な手順となる。

試験対策メモ

• 「再作成可能」か「バックアップ復元＋ログ適用」かをテーブルごとに区別できるように、問題文の記述を丁寧にチェックする。
• バックアップの種類（全体／増分／差分）と復元単位（データベース／テーブル）の関係を整理する。
• ロールフォワード処理の適用可否は、バックアップの状態（正否）に依存する点を押さえておく。
• 各バッチプログラムの役割と依存関係（図1参照）を理解し、再実行の影響範囲を把握する。

キーワード・論点整理

• 「バッチプログラムの実行スケジュール」
  出荷計上（T1） → 受注明細書送信・販売実績日次集計（T2） → 需要予測（T3） → 発注対象データ作成（T4） → … → マスタ更新反映（T5）
• 障害発生箇所
  「バッチプログラム“出荷計上”にプログラム不良があり, “在庫” テーブルの当日分の内容が不正」
  → これが原因で「バッチプログラム “発注対象データ作成” が中断した」
• 復旧手順のポイント
  1. 出荷計上 → 在庫・出荷を正しい状態に戻して再実行
  2. 中断の原因となった後続バッチ１：依存関係をもつ「需要予測」
  3. 中断の原因となった後続バッチ２：直接中断した「発注対象データ作成」
  4. 業務に影響しないバッチは省略し、最後にマスタ更新反映

解答が導かれる論理的説明

“プログラム不良があり, “在庫” テーブルの当日分の内容が不正になっていた。”

• 「発注対象データ作成」より前に実行される
• 「需要予測」プログラム実行時に参照・更新するテーブルは “需要予測” テーブル

ア：需要予測  
イ：需要予測  

ウ：発注対象データ  
エ：発注対象データ作成  

受験者が誤りやすいポイント

1. 依存順序を取り違える
   「発注対象データ作成」→「需要予測」の順序と誤解すると、ア・イ を逆に考えがちです。必ず実際のスケジュール（T1→T2→T3→T4…）を正確に押さえましょう。
2. 参照／更新テーブルの混同
   どのプログラムがどのテーブルを「読み込み(R)」／「作成・更新(CU)」するかを正しく把握できていないと、どのテーブルを復元すべきか迷います。問題文の「プログラムとテーブルの関係」は必ずチェックしましょう。
3. 不要なバッチまで再実行してしまう
   「中断した以降のすべてを再実行」と考えると時間がかかる想定が合いません。回復運用では「影響範囲だけ」を絞り込むことがポイントです。

試験対策ポイントまとめ

• バッチの依存関係を図から正確に読み取る
  実行順序を把握し、どの段階でどのテーブルが使われているかを整理する訓練をする。
• R/C/U の意味を必ず確認
  テーブルアクセスの種類（Read/Create/Update）は、復元すべきテーブルの特定に直結します。
• 回復運用では「最小限の再実行」にとどめる
  障害の影響範囲を限定し、該当テーブルと該当プログラムのみを復元・再実行する考え方を身につける。
• 問題文中の用語は必ず原文で覚える
  「需要予測」「発注対象データ作成」など，固有名詞は正確に把握することが肝要です。

キーワード・論点整理

• 対象となる不正データは，「在庫」テーブルの日次分
• 不正データを参照・反映するバッチのみ再実行が必要
• 他のバッチは「在庫」「需要予測」「発注対象データ」を参照しない

なぜ再実行不要か（論理的説明）

1. 問題文より

   「プログラム不良により“在庫”テーブルの当日分の内容が不正になっていた。
   これが原因でバッチプログラム “発注対象データ作成” が中断した。」
   とあるように，不正となったのは「在庫」テーブルの当日分だけ。

2. 再実行が必要なプログラム
   • “出荷計上” … 不正な在庫データを更新したため
   • （イ）＝“発注対象データ作成” … 不正な在庫を参照して中断
   • （エ）…（イ）の生成物を参照
   • “マスタ更新反映” … システム整合性確保のため
3. 表1（プログラムとテーブルの関係）から，その他のバッチプログラムは
   • 「在庫」テーブルを参照せず
   • 中断の原因となった「需要予測」「発注対象データ」テーブルも参照しない
     ため，影響を受けず再実行は不要

受験者の誤りやすいポイント

• 「C（Create）は参照に含まれない」ことを見落とし，参照関係と混同しがち
• プログラム－テーブル関係表を横断的にチェックせず，名前だけで判断する

試験対策としてのまとめ

• プログラムとテーブルの参照・更新関係を表1で正確に把握する
• 不正データの「発生源」と「参照先」を切り分け，影響範囲を特定する
• バッチの依存順序（図1）の理解と，ロールフォワード運用の流れをおさえること