平成22年度春期 データベーススペシャリスト 午後Ⅰ 問3

手順の目的と前提状態を対応づける

運用や障害対応に関する手順は、それぞれ何を守るために行われ、どの時点のどのような状態を前提にしているかで性格が決まります。用語の印象ではなく、目的と前提の組合せに注目して、内容が筋道として成り立つかを自分で確かめましょう。

この問題で問われていること

この問いで問われているのは、個々の用語を知っているかよりも、ある手順や仕組みが『何を防ぐ・何を取り戻すためのものか』と『それが働くには何がそろっている必要があるか』を結び付けて考えられるかという点です。

視点

運用設計の各要素は、いずれも『守りたいもの』と『そのために事前に用意・記録しておくもの』の組で理解すると整理しやすくなります。ある要素について、目的・発動のきっかけ・必要な前提の三つを自分の言葉で書き出し、互いに矛盾がないかを見比べる習慣をつけると、似た名前の概念を取り違えにくくなります。

確認ポイント

• その手順や仕組みは、何を防ぐ・何を取り戻すことを目的としているか
• それが機能するために、事前に何が用意・記録されている必要があるか
• 目的と前提の組合せが、問われている状況の条件と食い違っていないか

解説

通信販売の請求情報処理を題材に、DBの保守・運用を問う問題です。主な論点は、一意性制約による再実行時の重複防止、同期点を細かく取ることによるログ量対策、READ UNCOMMITTEDで読んだ途中状態の検出、ログを出さないロードを使った一括削除手順での停止範囲と回復方法、CRUDとデータの特徴から全体IC・差分IC・増分ICの容量を見積もることです。

問題の全体像

E社の請求情報処理では、4テーブル（会員、請求、請求明細、商品別請求）を、照会（オンライン）と請求登録・入金登録・請求一括削除（バッチ）・請求取消（オンライン）が使います。テストで三つの問題が起きました。A：異常終了後に再実行すると請求が二重に登録される。B：削除1がログ量の上限を超えて失敗する。C：一括削除中に照会が長時間排他待ちになる。これらへの対策に加え、ログを出さないロードを使った削除手順（表1）と、定期バックアップ計画（表2・表3）を検討します。出題趣旨では、バックアップ・回復・ロードといったRDBMSの機能の知識と、業務の理解に基づいて、制約・SQL・排他制御・保守運用を設計する力を問うとしています。

設問1(1)(列名)

注目するのは、再実行で『請求番号を除き、同じ内容の請求データ行』が追加された点です。請求番号はRDBMSが自動で採番するので、請求番号の一意性では重複を防げません。請求登録処理は会員ごとに月1回行い、請求日には処理日を設定します。したがって、同じ会員に同じ請求日の請求が2行あってはいけません。公式解答例でも、制約の対象は『会員番号，請求日』の組合せです。

設問1(1)(目的)

｛会員番号，請求日｝に一意性制約（候補キーとしての制約）を付けると、同じ処理日に最初から再実行しても、登録済みの会員の行は追加が拒否されます。そのため重複行ができません。公式解答例では、目的を『一意性を保証するため』としています。15字以内なので、『（会員番号と請求日の組の）一意性を保証する』という要素に絞って書けば十分です。

設問1(2)

本文には『最も多い月で平均的な月の1.2倍』『今後，年率20%以上の増加が見込まれる』とあります。方法1のように上限値を20%上げても、データ量が増え続ければ、いずれまた上限を超えます。方法2のように一定行数ごとに同期点を取れば、1作業単位のログ量は削除対象の総件数に関係なく一定に収まります。公式解答例では、理由を『データ量の増加に影響されないから』としています。

設問1(3)(a)

READ UNCOMMITTEDでは、未コミットのデータや処理途中の状態を読むことがあります。例えば、削除1と削除2の間の状態では、請求明細の行が先に消えて請求の行は残っています。また請求登録では、請求番号ごとに同期点を取るため、明細の追加が途中の状態もあります。このとき照会2の請求額合計は少なくなります。そこで、請求の明細数と、実際に存在する請求明細の行数を比べます。公式解答例では、aは『COUNT(*)』または『MAX(請求明細番号)』です。請求明細番号は請求番号ごとに1から振る連番なので、最大値も行数の代わりになります。

設問1(3)(b)

副問合せで数えたいのは、請求番号ごとの明細行の数です。そのため、FROMに指定するテーブルは請求明細で、相関名はZです。公式解答例でもbは『請求明細』です。副問合せでは返品フラグで絞り込まない点に注意してください。明細数は返品を含めた明細全体の数だからです。

設問1(3)(c)

副問合せは、照会対象の請求番号の明細だけを数える必要があります。公式解答例では、cは『X.請求番号=Z.請求番号』『Y.請求番号=Z.請求番号』『Z.請求番号=:請求番号』のいずれかです。どれも、外側の問合せと同じ請求番号にZを限定する条件です。

設問2(1)

手順1の全体オンラインICは、手順2以降でテーブルを元の状態に戻す必要が生じたときの拠り所になります。手順3ではログを出さずに全ページを空にするので、手順2の抽出ファイルが使えないと元に戻す手段がありません。公式解答例では、例として次の三つを挙げています。手順2の最中にディスク障害が発生した場合。手順2の出力ファイルが破損して読み込めなかった場合。手順2で残すべき行を選択しなかった場合。採点講評では、OS障害などのシステム障害を挙げた解答が多かったと指摘しています。システム障害はDBMSの再始動で回復できます。バックアップファイルが必要になる障害（媒体障害や作業ミス）を答える必要があります。

設問2(2)(ア)

参照も止めるべきなのは、テーブルの中身が不完全になっている間です。手順3でページを空にし始めた時点から、正しい行は存在しなくなります。公式解答例では、アは『3』です。

設問2(2)(イ)

手順4でロードが終わると、残すべき行はすべてそろいます。ログを出さないロードの後は参照だけが可能で、手順5のオフラインICの取得中も参照は可能です。したがって、参照を止める範囲は手順4の終了までです。公式解答例では、イは『4』です。

設問2(2)(ウ)

手順2で残すべき行を抽出し始めた後に追加・更新・削除を許すと、その変更は抽出ファイルに反映されません。手順3・4を経ると、その変更は消えてしまいます。そのため、更新系の操作は手順2の開始から止める必要があります。手順1はオンラインICなので、すべての操作を許せます。公式解答例では、ウは『2』です。

設問2(2)(エ)

本文によると、ログを出さないロードの後は参照だけが可能で、全体ICを取得して初めてすべての操作が可能になります。手順5の全体オフラインICが終わるまでは、更新系の操作を再開できません。公式解答例では、エは『5』です。

設問2(3)(手順番号)

手順5の後の更新はログに残っていますが、ログを適用する起点になる手順5のICが使えません。手順4のロードはログを出していないので、手順1のICにログを適用して手順5の時点までたどることもできません。未コミットのデータを含まず、オンライントランザクションを開始できる状態のうち、障害の直前に最も近いのは、残すべき行だけがロードされた手順4の後の状態です。公式解答例でも『4の後』です。採点講評によると、『手順2の後』と答えた解答が多かったとのことです。手順2の後はまだ削除すべき行が残っており、手順4の後とは内容が違う点に注意が必要です。

設問2(3)(回復方法)

手順2で作ったファイルは1か月間保存されます。これをもう一度テーブルにロードすれば、手順4の後の状態を再現できます。公式解答例では『手順2のファイルをテーブルにロードする。』です。25字以内なので、『手順2のファイル』と『テーブルへのロード』という要素を、表1の用語で書くことがポイントです。

設問3(1)(d)

請求登録処理は、『“請求”テーブルと“請求明細”テーブルに行を追加し』と書かれています。請求テーブルに対して欠かせない操作は追加なので、公式解答例ではdは『C』です。

設問3(1)(e)

同じ記述から、請求明細テーブルにも行を追加します。公式解答例ではeは『C』です。

設問3(1)(f)

請求登録処理では、会員テーブルの最新請求日に処理日を設定します。これは既存行の更新なので、公式解答例ではfは『U』です。

設問3(1)(g)

請求取消処理では、請求テーブルの請求取消日に返品日を設定します。これも既存行の更新なので、公式解答例ではgは『U』です。

設問3(2)(h)

請求テーブルは、1回の請求登録で全会員の25%分（1か月分の25%）の行が追加されます。同じ日の入金登録では、別の25%の行の入金日が更新されます。合わせると、1回で約50%のページが変わります。与えられた請求明細の値（追加だけなので1回25%）とも対応が取れます。公式解答例ではhは『50』です。

設問3(2)(i)

増分ICは、全体ICの取得以降に変更されたページを累積して持ちます。請求テーブルでは、毎回、別の会員の行が追加・更新されるため重なりません。2回目は50+50＝100%になります。公式解答例ではiは『100』です。

設問3(2)(j)

同様に1回50%ずつ累積するので、4回目は200%になります。請求テーブルには最大2か月分の行を保存するので、1か月分の全体ICの2倍になり得ます。公式解答例ではjは『200』です。

設問3(2)(k)

会員テーブルは、請求登録で25%、入金登録で別の25%の会員の行が更新され、1回で最大50%です。差分ICは前回の差分IC以降の変更だけを持つので、2回目も50%になります。公式解答例ではkは『50』です。

設問3(2)(ℓ)

会員テーブルの行数は増えません。更新されるページは、既存ページの範囲内に限られます。2回目の増分ICで既に100%に達しているので、4回目も100%を超えません。公式解答例ではℓは『100』です。

設問3(2)(m)

商品別請求テーブルは、請求登録で請求額合計が更新されます。売れる商品は月平均で全種類の25%なので、各回に更新されるのは、その25%の商品のページです。公式解答例ではmは『25』です。

設問3(2)(n)

月内に売れる商品は同じ25%の範囲に収まるので、各回に更新されるページは重なります。そのため、増分ICを累積しても25%のままです（1回目の増分ICも25）。公式解答例ではnは『25』です。

設問3(2)(o)

同じ理由で、4回目の増分ICも25%です。公式解答例ではoは『25』です。採点講評では、各テーブルがいつ、どの処理によって、どの範囲で変更されるかをつかめていない解答が多かったと指摘しています。そのうえで、表2のCRUDと表3の請求明細の値を手掛かりにすれば正解を導けるとしています。

学習のポイント

ICの種類と回復に使う入力の組合せ、ログを出さないロード後の制約、システム障害と媒体障害の違い、各処理がどのテーブルをどの範囲・どの頻度で変更するかの読み取りを重点的に学習してください。