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

模範解答

解説

解答の論理構成

1. バックアップを取るタイミング
   【問題文】の“〔バックアップ及び回復の方針〕(3)”より「バッチプログラムを実行する直前」が原則。T1〜T5は図１の契機に相当します。
2. どのテーブルが更新されるか
   「〔プログラムとテーブルの関係〕」の表で該当バッチ行を確認する。更新操作は “C”，“U”，“CU” が付いている列。
3. 契機ごとの整理
   • T1：オンライン更新分をバックアップ → “マスタ更新登録”，“受注”，“出荷指図”，“出荷”，“在庫”。
   • T2：直後に走る “販売実績日次集計” は “日別販売実績” を更新 → ここだけ◯。
   • T3：並列で “需要予測” と “販売実績月次集計” が走る。前者は “需要予測”，後者は “月別販売実績” を更新 → ２箇所◯。
   • T4：次に “発注対象データ作成” と “分析用データ作成”。それぞれ “発注対象データ”，“分析用データ” を更新 → ２箇所◯。
   • T5：“マスタ更新反映” は “商品”，“仕入先”，“販売先” を更新 → ３箇所◯。
4. 「既取得テーブルは対象外」の確認
   方針(3)の但し書き「(2) バックアップを取得したテーブルは対象外」により，T2〜T4でT1対象のテーブルは再取得しない。

誤りやすいポイント

• “R” だけの列を更新対象に含めてしまう
  更新記号が付いていない場合はバックアップ不要です。
• T2，T3，T4 で「前段バッチが書き込んだテーブル」を選んでしまう
  取得するのは“これから書き込むテーブル”であって“書き込まれた直後のテーブル”ではありません。
• “マスタ更新登録”をT5でも◯にする
  “マスタ更新反映”は “マスタ更新登録” を読取専用（R）で参照するだけなので誤り。

FAQ

模範解答

解説

解答の論理構成

1. (a) の判断
   • 【問題文】「3. 更新ログによる回復機能 (1)…ロールフォワード処理によって指定の時刻の状態に回復できる。」
   • “出荷”テーブルをバックアップで復元した後に“バッチプログラム“出荷計上”終了時の状態”へ進めるにはロールフォワードが必須。ゆえに「更新ログによる回復機能」又は具体動作名「更新ログを用いたロールフォワード処理」を記入。
2. (b)(c)(d) の判断
   • 【問題文】「(1) “商品”テーブル, “仕入先” テーブル及び “販売先” テーブルの追加、変更の要求は,“マスタ更新登録” テーブルに登録され…“マスタ更新反映”を用いて反映される。」
   • 障害を検知したバッチが“マスタ更新反映”なので、影響を受ける三つのマスタを同時に過去時点へ戻す必要がある。従って (b)「商品」, (c)「仕入先」, (d)「販売先」。
3. (e) の判断
   • 障害で途中終了した“マスタ更新反映”を完結させるには再度走らせるしかない。「再実行」を記入。
4. (f) の判断
   • “分析用データ作成”は“販売実績月次集計”完了後に開始するバッチで【表1】にもマスタ三表との参照・更新関係なし。よって復元する必要はなく、そのまま「継続」。

誤りやすいポイント

• バックアップ復元だけで“出荷計上”終了時点へ戻せると勘違いし、更新ログによるロールフォワードを漏らす。
• “マスタ更新反映”が扱うテーブルを“マスタ更新登録”と誤読してしまう。
• 「再実行」と「継続」を混同し、影響のないバッチまで再実行して整合性を崩す。

FAQ

模範解答

解説

解答の論理構成

1. 変更量と更新パターンを整理
   • 在庫：同一ページが繰り返し更新【問題文 (2)】
   • 出荷：毎日新しいページが追加【問題文 (3)】
2. バックアップ仕様を適用
   • 差分は「前回の全体バックアップ取得後に変更された全てのページが含まれる」かつ「ファイルは置き換え」【バックアップ機能 1.(2)③, 1.(3)】
   • 増分は「直前のバックアップ以降に変更されたページを毎回新規ファイルに追加」【バックアップ機能 1.(2)②】
3. 容量評価
   • 在庫：差分なら固定Ｋページ×１ファイル，増分ならＫページ×日数ファイル → 差分が有利。
   • 出荷：差分は日を追うごとにページ数が累積，増分は１日ぶんのみ → 容量は同程度。
4. 時間評価
   • 出荷では容量が拮抗するので「時間が短い方」【小問説明】を優先。増分は１日ぶんだけ読み書きすれば済むので高速。
5. 結論を表形式に整理し，理由欄は 30 字以内の端的な文章で示す。

誤りやすいポイント

• 差分バックアップを「毎回蓄積される」と誤解し，容量計算を増分と同じにしてしまう。
• 在庫テーブルで「更新行＝変更ページ数」と短絡し，ページが毎日膨大に増えると誤認する。
• 「同程度」の解釈を曖昧にし，時間評価を後回しにしてしまう。

FAQ

模範解答

解説

解答の論理構成

1. バックアップ頻度を下げる対象の条件
   • テーブル単位での回復方針(1)～(3)では「業務に影響するテーブルを優先」とあります。したがって、対象は業務影響が小さいか、容易に再作成できるテーブルになります。
2. “分析用データ” テーブルの特性
   • 【問題文】(5)
     「“分析用データ” テーブルは, バッチプログラム “分析用データ作成” を用いて,蓄積されている販売実績を基に, 再作成することも可能である。」
   • 再作成可能＝バックアップなしでも復旧できる。
3. 他テーブルとの比較
   • “日別販売実績” や “月別販売実績” はオンライン分析だけでなく日次・月次集計処理の入力となるため、再作成には多段階のバッチが必要で時間が掛かります。
   • “出荷”・“在庫” などは業務系バッチで頻繁に参照・更新されるため、回復を遅らせると直接業務に支障を来します。
4. 結論
   • 再作成が容易で業務クリティカルではない “分析用データ” テーブルだけを月初バックアップとし、日次バックアップを省略するのが合理的です。

誤りやすいポイント

• 「再作成できる」という記述を見落とし、“日別販売実績” や “月別販売実績” を選んでしまう。
• バックアップを減らす＝アクセス頻度が低いテーブルと短絡的に判断し、“出荷” テーブルを選ぶミス。
• バッチ依存関係を考慮せず、復旧時に連鎖的再実行が必要になるテーブルを選んでしまう。

FAQ

模範解答

解説

解答の論理構成

1. 障害の状況整理
   • 問題条件で「（2）のテーブルに障害」「バックアップファイルが壊れていた」と指摘。
   • 更新ログを使った回復もバックアップに依存するため利用不可。
2. 代替策の探索
   • 【問題文】(5)
     「バッチプログラム “分析用データ作成” を用いて,蓄積されている販売実績を基に, 再作成することも可能」
   • 【問題文】(4)
     「これらのテーブルには, 直近3年分の販売実績が蓄積されている」
   • よって “分析用データ” テーブルはバックアップ不要で再生成可能。
3. 手順の決定
   • まず障害テーブル“分析用データ”を truncate などで空にするか，別名退避。
   • 続いてバッチプログラム“分析用データ作成”を実行し，３年分の実績をもとに全件再作成。
   • オンライン系・他バッチへの影響が最小で，求められる回復の迅速性を満たす。

誤りやすいポイント

• 「更新ログによる回復機能」で戻せると誤解し，バックアップ無しでは適用できない旨を見落とす。
• “分析用データ作成”が差分更新だと決めつけ，フル再生成が可能であることを読み飛ばす。
• 「販売実績は３年分」との記述を引用せずに説明し，根拠不十分となる。

FAQ

模範解答

解説

解答の論理構成

1. 不具合による影響範囲の特定
   • 【問題文】“バッチプログラム ‘出荷計上’ にプログラム不良があり, ‘在庫’ テーブルの当日分の内容が不正”
   • “出荷計上” が更新する “在庫” を参照する後続処理を確認する。
2. 依存関係の確認
   • “需要予測” 行では “在庫”(R) が指定されている（在庫を読んで予測値を算出）。
   • “発注対象データ作成” 行では “需要予測”(R) が指定されている（予測値を読んで発注量を決定）。
   • よって誤った在庫→誤った需要予測→誤った発注対象データ となる。
3. 回復手順の設計
   • 第1段階：指示どおり “出荷” と “在庫” を復元し “出荷計上” を再実行。
   • 第2段階：依存先① “需要予測” を復元し、正しい在庫を参照して “需要予測” バッチを再実行。
     【問題文】“第2段階 バックアップを用いて ‘（ア）’テーブル … バッチプログラム ‘（イ）’ を再実行する。”
   • 第3段階：依存先② “発注対象データ” を復元し、正しい予測を読んで “発注対象データ作成” を再実行。
     【問題文】“第3段階 バックアップを用いて ‘（ウ）’テーブル … バッチプログラム ‘（エ）’ を再実行する。”
4. 方針との整合
   • 【問題文】“回復は,受注，出荷, 発注, 在庫管理の業務に影響するテーブルを優先する。”
   • 在庫を先に直し、その影響を受ける予測→発注と段階的に復元する流れが方針と一致する。
5. したがって
   （ア）需要予測／（イ）需要予測／（ウ）発注対象データ／（エ）発注対象データ作成 が解答となる。

誤りやすいポイント

• “需要予測” プログラムは “在庫” を参照する事実を見落とし、先に “発注対象データ” だけを復元しようとしてしまう。
• “発注対象データ作成” が途中で中断した事実から「テーブルは壊れていない」と早合点し復元を省略してしまう。
• “差分バックアップではテーブル単位の復元ができない” と誤解し、回復手順の構築を諦めてしまう（【問題文】“復元の単位は,バックアップの単位と同一である。” を要確認）。

FAQ

模範解答

解説

解答の論理構成

1. 障害の範囲を確定
   “バッチプログラム“出荷計上”にプログラム不良があり, “在庫” テーブルの当日分の内容が不正” と明記されています。
2. 必要な回復対象を列挙
   復元手順では，
   “第1段階 … “在庫” テーブル … 再実行”
   “第2段階 … “需要予測” テーブル”
   “第3段階 … “発注対象データ” テーブル”
   と，障害テーブルと派生先のみを対象にしています。
3. 他バッチとの依存関係を確認
   表1より，残りのバッチ（例： “販売実績日次集計”, “販売実績月次集計”, “分析用データ作成” など）は “在庫”，“需要予測”，“発注対象データ” を参照しないことが読み取れます。
4. 結論
   したがって，当該テーブル群を使用しないバッチはデータ汚染の影響を受けず，再実行は不要になります。

誤りやすいポイント

• “在庫” と “出荷” を混同し，“出荷” を参照するバッチまで再実行しようとしてしまう
• “需要予測” と “分析用データ” の依存関係を誤解し，全バッチ再実行が必要と早合点する
• 表1で「R」のみの関係を軽視し，「更新がないなら影響なし」と思い込みがち

FAQ