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

解答の導き方

• 図1でT1～T2間に実行されるプログラム：オンライン処理（当日にオンラインで動くもの）と、バッチ「出荷計上」がT1～T2に実行される。したがってT1は「オンライン時間帯直後」かつ「出荷計上 実行直前」の時点と読みます。
• オンライン更新のバックアップ（方針(2)）：表1でオンラインプログラムが書き込むテーブルを確認します。具体例：
  • 「取引先管理」「商品情報管理」の行に「マスタ更新登録」に対して「C」があるので、マスタ更新登録はオンラインで作成され得ます → 「マスタ更新登録」をバックアップ。
  • 「受注管理」に「受注」への「CU」が付いているので、「受注」をバックアップ。
  • 「出荷処理」に「出荷指図」への「C」があるので、「出荷指図」をバックアップ。
• バッチ実行直前のバックアップ（方針(3)）：バッチ「出荷計上」がT1～T2に実行され、表1の該当行に書き込み記号（出荷・在庫などの更新）があるため、その更新対象を実行直前にバックアップします。よって「出荷」と（表1に更新記号があるため）「在庫」もバックアップします。
  → 結果（T1でバックアップするテーブル）: マスタ更新登録、受注、出荷指図、出荷、在庫。

• 図1でT2～T3に実行されるのは「販売実績日次集計」。
• 表1で「販売実績日次集計」行は「日別販売実績」に「C」を持っている（＝当日の販売実績を日次テーブルに作成する）ので、方針(3)に従い実行直前のT2に「日別販売実績」をバックアップします。
  → 結果（T2）: 日別販売実績。

• 図1でT3～T4に実行されるのは「需要予測」（上段）と「販売実績月次集計」（下段）。販売実績日次集計の結果がそれぞれの入力になっている（図1の矢印参照）。
• 表1を見ると「需要予測」「販売実績月次集計」はそれぞれ自らが更新するテーブル（需要予測テーブル、月別販売実績など）に書き込み記号を持つため、方針(3)に従って実行直前のT3にそれらをバックアップします。
  → 結果（T3）: 需要予測、月別販売実績。

• 図1でT4～T5に実行されるのは「発注対象データ作成」と「分析用データ作成」。
• 表1で「発注対象データ作成」は「発注対象データ」を、「分析用データ作成」は「分析用データ」を更新する（C, R, U等の記号あり）ので、方針(3)に従い実行直前のT4にそれぞれバックアップします。
  → 結果（T4）: 発注対象データ、分析用データ。

• 図1でT5付近に「マスタ更新反映」が実行される（図1のT5の説明参照）。
• 表1の「マスタ更新反映」行は「商品」「仕入先」「販売先」などに更新記号（CU等）を持つため、方針(3)に従って実行直前のT5にこれらのマスタテーブルをバックアップします。
  → 結果（T5）: 商品、仕入先、販売先。

• T1: マスタ更新登録、受注、出荷指図、出荷、在庫
• T2: 日別販売実績
• T3: 需要予測、月別販売実績
• T4: 発注対象データ、分析用データ
• T5: 商品、仕入先、販売先

誤りやすいポイント

• 更新判定でCRを見落とす／Rと混同する。CRはCを含むため「書き込み」とみなす必要があります。
• 方針(3)で「ただし、(2)でバックアップを取得したテーブルは対象外」とある点を忘れると、同じテーブルを重複して（不必要に）バックアップすべきと誤判断しやすいです。
• バックアップの単位と復元の単位を混同すること。問題文にあるように「復元の単位は、バックアップの単位と同一である」ため、データベース単位で取ったバックアップから特定テーブルだけを取り出して復元することはできません。
• 図の矢印や実行順序と「バックアップを取る契機」を読み違え、オンライン直後／バッチ直前のタイミングを誤認するミス。

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. 容量評価
   • 在庫：差分なら固定Ｋページ×1ファイル、増分ならＫページ×日数ファイル → 差分が有利。
   • 出荷：差分は日を追うごとにページ数が累積、増分は1日ぶんのみ → 容量は同程度。
4. 時間評価
   • 出荷では容量が拮抗するので「時間が短い方」【小問説明】を優先。増分は1日ぶんだけ読み書きすれば済むので高速。
5. 結論を表形式に整理し、理由欄は30字以内の端的な文章で示す。

誤りやすいポイント

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

FAQ

解答の導き方

1. 優先度の確認
   バックアップ及び回復の方針の(5)には「回復は、受注、出荷、 発注、在庫管理の業務に影響するテーブルを優先する。」とあります。したがって業務に直接影響するテーブルは日常的に確実に保護（＝日々のバックアップやすぐ復元できる体制）しておく必要があり、これらを対象に「月初めのみ」の扱いにするのは方針に反します。
2. 業務影響のあるテーブルの特定（除外理由）
   本文から、特に業務に直結して頻繁に更新されることが分かるテーブル例を確認します。例えば「在庫」については「在庫のうちの3割 (売れ筋商品) に相当する約1,000行が毎日頻繁に変更される」とあり、「出荷」については「毎日、 約400,000行が追加される」とあります。これらは運用上重要かつ更新量が多いため、日々のバックアップ（および即時復旧手段）が必要です。したがって「在庫」「出荷」「受注」「発注対象データ」などは月初めのみのバックアップ対象にしてはいけません。
3. 候補の絞込みと再作成可能性の確認
   候補となるのは業務の直接処理に使われず、万一消失しても他の永続データから復元・再作成できるテーブルです。本文は「分析用データ」について「当日分の販売実績が、前日に作成された“分析用データ”テーブルに反映され、直近3年分の分析結果となるように維持されている。」「“分析用データ” テーブルは、バッチプログラム “分析用データ作成” を用いて、蓄積されている販売実績を基に、再作成することも可能である」と明記しています。つまり「分析用データ」は派生データ（販売実績を原データとして再生成可能）であり、業務の当日運用を直接停止させる性質のデータではありません。
4. 結論の導出
   上記より、バックアップ方針(5)に照らして業務に影響しないかつ再作成可能なテーブルを月初めのみのバックアップ対象とするのが妥当です。本文の記述から該当するのは「分析用データ」テーブルであり、これを月初めのみバックアップして日々のテーブル単位バックアップを省くことが方針に矛盾しません。

誤りやすいポイント

• 「フルバックアップ（データベース単位）が毎日あるから個別テーブルの毎日バックアップは不要」と考える誤り。復元の単位はバックアップの単位と同一であり、データベース単位バックアップだけでは特定テーブルのみを迅速に復元できない点を見落としやすいです。
• 「更新頻度が高い＝毎日バックアップが必要」として、派生データである「分析用データ」を単純に除外できないと判断する誤り。再作成可能かどうかを確認することが重要です。
• 生データである「日別販売実績」「月別販売実績」などを軽視してしまう誤り。派生データを再作成するにはこれら原データが確実に保護されている必要があります。

FAQ

解答の論理構成

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

誤りやすいポイント

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

FAQ

解答の導き方

1. 問題の事実確認
   問題文に「バッチプログラム“出荷計上”にプログラム不良があり、 “在庫” テーブルの当日分の内容が不正になっていた。 これが原因でバッチプログラム “発注対象データ作成”が中断した。」とあります。まず「出荷計上」で在庫が不正になり、それが連鎖的に後続バッチの実行に影響したことが出発点です。第1段階で「出荷」と「在庫」を当日のオンライン時間帯直後の状態に復元し、「出荷計上」を再実行する、というのは既に提示された手順どおりです。
2. 影響の伝播経路を特定する
   図1の順序は「出荷計上→販売実績日次集計→需要予測→発注対象データ作成」です。したがって、出荷計上で生じた不正はこの順に下流へ伝播する可能性があります。次に表1で参照関係を確認すると、「需要予測」は「日別販売実績」を参照（R）しており、「発注対象データ作成」は「需要予測」を参照して「発注対象データ」を作成・更新することが分かります。つまり、発注処理を正しく再開するためには、発注処理の入力となる「需要予測」と、発注処理自体が作成する「発注対象データ」の整合性を保証する必要があります。
3. 復旧手順（第2・第3段階）の選択理由
   • 第2段階で何を復元・再実行するか：
     「需要予測」は「日別販売実績」を入力にして作成され、その結果が「発注対象データ作成」の入力になります。出荷系の不正が日別販売実績を通じて需要予測の結果に影響している可能性が高いため、発注処理を正しく行うには「需要予測」を正しい状態に戻すことが必要です。よって（ア）は 「需要予測」、（イ）はバッチ名としての「需要予測」です。
     なお、「日別販売実績」自体は直近3年分を保持する大きなテーブルであり、復元（または再集計）には時間がかかります。今回の方針では、下流の出力を再作成する（＝該当バッチを再実行する）ことで整合を取る方針になっているため、まずは「需要予測」を復元・再実行して下流の入力を正す方法が合理的です。
   • 第3段階で何を復元・再実行するか：
     「発注対象データ作成」が中断しているため、その出力である「発注対象データ」には途中までの不整合な書き込みが残っている可能性があります。部分書き込みが残ったまま再実行すると重複や不正な混在が起きるため、当日のオンライン時間帯直後の状態に戻してからバッチ「発注対象データ作成」を再実行する必要があります。したがって（ウ）は 「発注対象データ」、（エ）は「発注対象データ作成」です。
4. 順序のまとめ（復旧全体の論理）
   • 第1段階：既に示されたとおり「出荷」「在庫」を復元し、「出荷計上」を再実行（与件）。
   • 第2段階：まず「需要予測」を当日のオンライン時間帯直後の状態に復元し、バッチ「需要予測」を再実行して正しい予測値を作る。（ア＝需要予測、イ＝需要予測）
   • 第3段階：「発注対象データ」を当日のオンライン時間帯直後の状態に復元し、バッチ「発注対象データ作成」を再実行する。（ウ＝発注対象データ、エ＝発注対象データ作成）
   • 第4段階：最後に「マスタ更新反映」を実行して各処理の結果を反映する（与件）。

誤りやすいポイント

• 需要予測が在庫を参照すると誤解する点。表1を確認すると「需要予測」は「日別販売実績」を参照しているため、在庫参照を根拠に判断するのは誤りです。
• 中断したバッチの「入力」だけを復元すればよいと考える誤り。中断したバッチが途中まで出力を書き込んでいれば、その出力テーブルを復元してから再実行しないと二重化や不整合が起きます。
• 大きなテーブル（直近3年分の「日別販売実績」など）を不用意に復元して時間を浪費すること。表2のバックアップ方針・復元時間の性質（ページ数に比例）を踏まえて、最小限の復元＋バッチ再実行で済ませられるかを検討します。
• バックアップ単位と復元単位の混同。「復元の単位はバックアップの単位と同一である」ため、テーブル単位バックアップがない場合は個別テーブル復元ができない点に注意します。

FAQ

解答の導き方

誤りやすいポイント

• 図1の分岐を誤読して「分析用データ作成は需要予測経路に依存する」と考える点。実際は「販売実績月次集計」系から作られる別系統である点を確認すること。
• 表1の参照／更新の列を数える際に列位置をずらして読み違えると、どのプログラムがどのテーブルを参照・更新するかを誤認するため注意すること。
• 直感的に「バグ発生後に実行された全バッチをやり直す」が安全と思い込むこと。バックアップ方針により影響範囲を限定して復旧できるため、無闇な全再実行は非効率となる。

FAQ