データベーススペシャリスト午後II 総合事例記述令和6年 秋期
午後II 問1
問1 オートリース会社の車両保守業務におけるデータベースの実装・運用
テーマ：バッチ処理のオンライン時間帯移行に伴う排他制御，障害回復見積り及びテーブル設計・運用
左右2分割表示：左側の問題文をスクロールしながら右側の設問に解答できます
長文事例本文
図表クリックで拡大問1 オートリース会社の車両保守業務におけるデータベースの実装・運用に関する次の記述を読んで，設問に答えよ。
A社は，法人向けに車両のリース及び保守業務を行っており，業務に車両保守システムを使用している。A社では，夜間に実施しているバッチ処理の昼間帯への移行を検討している。
〔車両保守システムの概要〕
1. 業務の概要
(1) 車両のリース提供先の法人を顧客という。顧客との間でリース契約を結び，契約に基づいて車両を定額制で貸し出す。
(2) リース契約に基づいて新しい車両を購入することもあれば，リース契約終了後の車両を再リースすることもある。
(3) 契約のオプションとして車両保守を受託する。車両保守には，車検，法定点検（以下，点検という），整備などの保守区分がある。複数の保守区分を受託することもある。
(4) 外部の自動車整備工場などの委託先に保守区分の実施を依頼する。
(5) 受託ごとに一定期間内の保守区分を洗い出し，保守区分ごとに着手予定日を決めて予定表を作成する。予定表に従って手配を開始し，進捗を確認する。手配は，顧客への事前案内，入庫日の調整，委託先への実施依頼などから成る。手配は，定められた順に実施し，各手配の完了時に進捗を記録する。車検と整備を同時期に実施するなど，同じ車両の異なる保守区分を同時に実施することもある。この場合，保守区分ごとに同じ予定を立てる。
(6) 各車両の一つの保守区分は一つの委託先で実施する。委託先に複数の保守区分の実施を同時に依頼することもある。委託先から保守区分の実施結果を受け取り，進捗を記録する。実施完了の報告を受けると車両の出庫手続に移る。
(7) 車両ごとに，全ての車検，点検，整備の結果及び内容を記録簿に記録する。
2. テーブル構造
車両保守システムのテーブル構造を図1に，主な列の意味・制約を表1に示す。
拡大
表1 主な列の意味・制約
| 列名 | 意味・制約 |
| :--- | :--- |
| 契約#，受託#，保守区分 | リース車両ごとにリース契約を結び，契約#で識別する。車検，点検，整備などの保守区分ごとに車両保守を受託し，受託#で識別する。 |
| 手配#，現手配# | 手配#は，1:事前案内，2:入庫予約受付，3:委託先手配，4:入庫，5:実施完了予定確認，6:出庫予約受付，7:完了確認，8:出庫のいずれかである。現手配#には，予定表の手配が現在どれであるかを記録する。 |
| ソート連番，実施項目# | “実施結果”テーブルのソート連番は，報告YMDごとに，委託先からの複数の報告を識別する番号である。実施項目#は，点検・検査の項目，部品交換などの作業内容を識別する番号である。 |
| 記録# | 車両ごとに，車両の登録，名義変更，車検，点検，整備などの内容を発生の順に記録#を付与して記録する。 |
3. 主な処理
オンライン時間帯は平日の9:00〜19:00で，オンライン時間帯終了後の夜間にバッチ処理を行っている。オンライン処理及びバッチ処理は，それぞれ複数のアプリケーションプログラム（以下，APという）から成る。オンライン処理，バッチ処理の概要及び1日の処理行数を表2，3に，バッチ処理の実行スケジュールを図2に示す。表2，3中の二重引用符で囲んだ名前は図1中のテーブル名である。
表2 オンライン処理の概要及び1日の処理行数
| AP名 | 処理内容 | 1日の処理行数 追加 | 1日の処理行数 更新 |
| :--- | :--- | :--- | :--- |
| 契約登録 | 契約#ごとに“契約”及び付随する“受託”，“点検率”に行を追加，更新する。 | 10,000 | 10,000 |
| 車両登録 | 車両#ごとに“車両”に行を追加，更新する。追加時には，基となる“契約”の車両#を更新し，“記録簿”に行を追加する。 | 10,000 | 6,000 |
| 車両照会 | 指定された車両#について，“車両”，“契約”，“受託”，“記録簿”などの車両に関わる全記録を表示する。 | 0 | 0 |
| 書類発行 | “予定表”に従って顧客に送付する登録書類を作成し，“進捗”に行を追加する。 | 10,000 | 0 |
| 予約登録 | 顧客からの電話又は電子メールで受け付けた車両保守のための入庫又は出庫に対応して，“予定表”の現手配#を更新し，“進捗”に行を追加する。 | 10,000 | 4,000 |
表3 バッチ処理の概要及び1日の処理行数
| AP名 | 処理内容 | 1日の処理行数 追加 | 1日の処理行数 更新 |
| :--- | :--- | :--- | :--- |
| 実施登録 | 委託先から受信した保守区分の実施記録ファイルのデータについて“実施結果”に行を追加する。同時に実施項目#ごとに“記録簿”に行を追加する。各委託先から1日に複数回受信するファイルを一つにまとめたデータを，報告YMD，受信TS順にソートし，報告YMDごとにソート連番を設定する。 | 20,000 | 0 |
| 報告作成 | 次回報告YMDの近い受託を対象に，一定期間の保守区分の一覧及び明細に基づく報告について顧客別に“報告”に行を追加し，追加ごとに“受託”の次回報告YMDを更新する。 | 20,000 | 20,000 |
| 点検抽出 | “車両”を参照し，一定期間内に点検期限を迎える車両を抽出して，ワークテーブル（WK1）に行を追加する。 | 30,000 | 0 |
| 車検抽出1 | 一定期間内に車検の期限を迎える車両を抽出してワークテーブル（WK2）に行を追加する。 | 30,000 | 0 |
| 車検抽出2 | 車検抽出1の結果，“車両”，“予定表”を参照して，事故による修理中など，一定の条件で車検不要なものを除外した上で車検が必要な車両の行をワークテーブル（WK1）に追加する。 | 20,000 | 0 |
| 予定表作成 | 抽出した車両について，保守区分の委託先，開始YMDなどを決めて，“予定表”に行を追加する。 | 20,000 | 0 |
| 進捗更新 | 当日分の“実施結果”の行を基に“進捗”に行を追加，“車両”，“予定表”を更新，“記録簿”に行を追加する。 | 10,000 | 40,000 |
| 依頼作成 | “予定表”を基に，委託先に車両ごとの保守区分の実施を依頼するための依頼データファイルを作成する。 | 0 | 0 |
| 点検率更新 | “実施結果”を報告YMD，ソート連番の順に読み込み，契約#が一致する“点検率”の実績点数に“実施結果”の点数を加算して更新する。 | 0 | 20,000 |
注記 各APは，特に断りのない限り，処理の最後に一度だけコミットを発行するものとする。
拡大
4. 主なAPとテーブルの関係
車両保守システムの主なAPのCRUDを表4に示す。
拡大
5. 障害の考え方
車両保守システムでは，障害を，AP障害，サーバ障害，メディア障害の3種類に分けて，それぞれの対策を立てている。
(1) AP障害は，APのバグ，メモリリークなどによってトランザクションの途中でAPが異常終了する障害である。
(2) サーバ障害は，RDBMSが稼働するサーバが，ハードウェア異常，電源遮断などによって機能停止する障害である。
(3) メディア障害は，RDBMSが使用する制御ファイル，表領域を物理的に格納するストレージの故障，破損によって入出力ができなくなる障害である。
〔RDBMSの主な仕様〕
1. 表領域
(1) テーブル及び索引のストレージ上の物理的な格納場所を表領域という。
(2) RDBMSとストレージとの間の入出力単位をページという。同じページに異なるテーブルの行が格納されることはない。
2. 参照時の専有ロック
データ参照時にFOR UPDATE句を指定すると，ISOLATIONレベルにかかわらず，対象行に専有ロックを掛け，トランザクション終了時に解放する。
3. ログ
ログは，データより先にログバッファからストレージに出力される。これをログ出力処理と呼ぶ。このとき，トランザクションのコミットはログ出力処理の完了まで待たされる。ログ出力処理は，次のいずれかの事象を契機に行われる。
(1) ログバッファが一杯になった。
(2) トランザクションがコミット又はロールバックされた。
(3) あるテーブルのデータバッファが変更ページによって一杯になった。
4. チェックポイント
(1) チェックポイントは，指定されたログの出力量になった時点，又は指定された経過時間に従ってRDBMSが自動で取得する。
(2) チェックポイントは，コマンドを使用して任意に手動で取得することもできる。
5. 異常終了後のRDBMS再開始
RDBMSがサーバ障害によって異常終了した後のRDBMS再開始において，RDBMSは直前のチェックポイントから異常終了時までに完了していたトランザクションの更新データ及び異常終了時に未完了のトランザクションの更新データを自動で回復する。
具体的には，RDBMSはログを用いて，直前のチェックポイントから異常終了時までロールフォワードを行い，異常終了時点と同じデータベースの状態に回復する。その後，異常終了時に未完了だったトランザクションをロールバックする。その際，同じ行の更新順序を担保するために，ロールフォワードは，全てのトランザクションのログに対して，ログが出力されている順に逐次に実行される。トランザクション間の排他制御によって同じ行の同時更新がないことは担保されているので，ロールバックはトランザクションごとに並行して実行される。
6. ログなしモード
ログなしモードとは，ログなしモードを指定されたテーブルの更新に対してログを出力しないモードである。テーブルごとにログなしモードを指定することができる。ログなしモードのテーブルを更新するAPで実行されるトランザクションは，ログを取得しないので，その分だけトランザクションの実行時間を短縮できる。ログなしモードのテーブルを更新するトランザクションには次の制約がある。
(1) ログなしモードのテーブルについて，トランザクション内で最初の更新時にテーブル全体に専有ロックを掛け，トランザクションがコミットされたときに専有ロックを解放する。
(2) ログなしモードのテーブルに専有ロックが掛けられている間は，チェックポイントを取得しない。手動でも取得できない。
(3) トランザクションがロールバックされたとき，ログなしモードのテーブルは使用不可になる。使用不可になったテーブルは，バックアップから復元するか，テーブルを削除して再度定義（以下，再定義という）する必要がある。
7. オンラインバックアップ・回復
データベースの稼働中に更新中のデータを含めて全表領域，全ログをRDBMSの稼働環境とは異なるストレージに複写してバックアップを取得する機能を備えている。
(1) 専用のコマンドを実行して，全表領域，全ログのバックアップを一定の多重度で別系のストレージに格納する。
(2) オンラインバックアップ取得開始後に発生したログは，ストレージに書き込まれると同時にそのログのバックアップが別系のストレージに格納される。
(3) メディア障害発生時には，ストレージ交換後，全表領域，全ログ，オンラインバックアップ取得後に発生したログのバックアップをストレージに復元し，異常終了後のRDBMS再開始と同様にロールフォワード及びロールバックによってデータを回復する。
8. ロックメモリ
RDBMSがロックを掛けるときに排他制御のために使用するメモリ領域をロックメモリという。1行又は1テーブルにロックを掛けるごとにロックメモリにロック情報を登録し，そのロックを解放したらロック情報を削除する。ロックメモリは，同時にロックを掛ける行数，テーブル数から見積もって指定されたサイズで確保する。必要以上に大きなサイズで確保しようとするとメモリ領域が不足してRDBMSを開始できない。逆に，必要なサイズを確保していなければ，SQLの実行時にロックメモリの未使用領域がなくなり，ロックを掛けることができずにSQLがエラーとなる。
〔現行バッチ処理のバックアップ・リカバリ〕
1. バッチ処理のバックアップの取得スケジュール
車両保守システムでは，オンライン時間帯の終了後に次の要件でバックアップを取得している。バックアップの取得スケジュールを表5にまとめた。表5では，図2中の各契機でテーブル単位のバックアップを取得するテーブルに“〇”印をつけている。
(1) 当日のオンライン処理のAPの実行結果を全て反映した状態に回復できること
(2) 全てのバッチ処理のAP（以下，バッチAPという）の実行結果を反映した状態に回復できること
(3) それぞれのバッチAPの実行中にメディア障害が発生した場合，速やかに対象テーブルを回復した後，バッチAPを再実行できること
(4) 必要最小限のバックアップを取得すること
(5) “点検抽出”，“車検抽出1”，“車検抽出2”の各APで更新する，“WK1”，“WK2”の各テーブルには，ログなしモードを指定すること
(6) “WK1”，“WK2”の各テーブルは，ワークテーブルであり，バックアップの対象外とすること。これらのワークテーブルは，オンライン時間帯の終了後，バッチ処理を開始する前に再定義して使用する。
拡大
2. サーバ障害時のRDBMS再開始
RDBMS再開始に備えて，バッチ処理中のチェックポイントに関する検証を行った。なお，T1〜T6は図2中の各契機を示す。
(1) RDBMS再開始後の運用
“実施登録”APと“車検抽出2”APの実行中に，サーバ障害が発生した場合に，RDBMS再開始後にどのような対処が必要になるか，チェックポイントの取得状況に応じた対処を整理した。
契機T2でチェックポイントを取得している場合，“a”テーブルをbした後，“c”AP，“d”APを再実行する。また，“e”APも再実行する。その後，契機T3以降のバッチ処理を継続する。
契機T2でチェックポイントを取得していない場合，チェックポイントを取得している場合の対処を行う前に，“f”テーブルをbした後，“g”APを再実行しておく必要がある。
(2) RDBMS再開始に要する時間
契機T3でチェックポイントを取得後，契機T5からT6の間でサーバ障害が発生して再開始する状況を想定する。契機T3の後，サーバ障害が発生するまでの間にチェックポイントは取得していないものとする。追加・更新1行当たりロールフォワードに2ミリ秒，ロールバックに1ミリ秒を要するものと仮定して，RDBMS再開始のときにデータベースの回復に要する時間を見積もった。
最も時間が掛からないケースは，バッチAPでの更新が発生する直前にサーバ障害が発生した場合で，トランザクションのロールフォワードが必要なAPはh，ロールバックが必要なAPはi，回復に要する時間はj秒となる。最も時間が掛かる，理論上の最悪のケースは，更新処理のある全てのバッチAPがコミットする直前にサーバ障害が発生した場合で，トランザクションのロールフォワードが必要なAPはk，ロールバックが必要なAPはl，回復に要する時間はm秒となる。
〔バッチ処理のオンライン時間帯への移行〕
図2中のバッチ処理の実行順序（先行・後続の関係）を変更せずに，表3の全APをオンライン時間帯に移行するに当たって，APに必要な変更を検討した。
1. 移行後に発生する問題
表2，3中のAPを変更せずに，表3中の全処理をオンライン時間帯に移行すると仮定した場合，発生し得る問題を表6にまとめ，その対処を検討した。表6では，どのAPもISOLATIONレベルをREAD COMMITTEDとしてトランザクションを実行することを前提としている。
表6 発生し得る問題
| 問題# | 内容 |
| :--- | :--- |
| 問題1 | “契約登録”APと“報告作成”APを同時に実行すると，“契約登録”APの応答に遅延が発生する。 |
| 問題2 | “進捗更新”APの実行中に“予約登録”APによる登録を行うと，“予定表”テーブルの現手配#が不正になることがある。 |
| 問題3 | “点検率更新”APの処理が，“実施結果”テーブルの当日分の行数が多い日には，オンライン終了時刻までに終わらない。 |
2. 問題への対処
表6の問題に対処して，表2，3中のいずれかのAPを変更する。
(1) 問題1
この問題は，“報告作成”APが“ア”テーブルの更新対象行に対するイを処理終了まで保持し，“契約登録”APがその解放を待つことで発生する。問題への対処として“報告作成”APを変更する。
(2) 問題2
“予約登録”AP，“進捗更新”APの処理内容を図3，4に示す。図3，4では特に断りのない限り，行の読込みには共有ロックが掛かるものとする。
この問題は，“予約登録”APが点検の出庫予約の受付中に，“進捗更新”APで同じ受託の“予定表”テーブルの現手配#を5（実施完了予定確認）からウに変更し，その後で“予約登録”APが同じ現手配#をエに変更することで発生する。手配#の順序の制約及びISOLATIONレベルを変えずに問題に対処するために，一つのAPを変更することにした。
拡大
“実施結果”テーブルから報告YMDが当日に等しい行を読み込み，行ごとに次を行う。
① “進捗”テーブルに，完了確認の手配#に対応する行を追加する。
② “予定表”テーブルの該当行の現手配#に完了確認の手配#を設定して更新する。
③ 保守区分が車検で，“進捗”テーブルの手配#が完了確認の場合は，“車両”テーブルの車検満了YMDを次回の車検満了日に更新する。
④ “記録簿”テーブルに行を追加する。
⑤ コミットを発行する。
図4 “進捗更新”APの処理内容
(3) 問題3
処理時間の短縮を図るため，“点検率更新”APを同じ報告YMDの中で重複していないソート連番の範囲を指定することで，ジョブを多重処理できるように変更した。“点検率更新”APの処理内容を図5に示す。
① 報告YMD，開始連番，終了連番を引数で受け取る。
② “実施結果”テーブルから指定された引数に報告YMDが一致し，開始連番から終了連番までの間の行をソート連番順に読み込む。
③ 読み込んだ行ごとに，契約#が一致する“点検率”テーブルの行を読み込み，実績点数に点数を加えて更新する。
④ ②，③を繰り返し，結果行を全て処理したら，最後に一度だけコミットを発行する。
図5 “点検率更新”APの処理内容
図5の処理内容変更案をレビューしたところ，APの多重処理によって，デッドロックが発生するおそれがあるとの指摘を受けた。デッドロックの発生を防ぐために，次の二つの案を検討した。
案1 図5中の処理内容を修正する。
案2 表3中の“点検率更新”AP以外のAPを一つ変更する。
〔移行後の運用設計〕
1. メディア障害への対策
メディア障害への対策として，オンライン時間帯に何回かのオンラインバックアップを取得し，オンライン時間帯終了後にRDBMSを停止してデータベース全体のオフラインバックアップを取得することにした。オンライン時間帯にメディア障害が発生した場合のリカバリでは，ログを用いて回復に要する時間がリカバリ時間の多くを占めるので，回復に要する時間を見積もり，オンラインバックアップの取得頻度を求めた。
(1) 見積りの前提
① 表2，3の1日の処理行数の合計がログ量に等しいと仮定する。1日のログ量は，処理行数を合計して，追加に190,000行，更新に100,000行になる。
② 全テーブルの1ページ当たりの平均行数を20行，1ページ当たりのストレージへのI/O時間を10ミリ秒とし，ストレージへのI/O以外のCPU処理，索引探索，ネットワーク通信などに掛かる時間を考慮しないものとする。
③ ログによる回復では，追加については，ページ中の行数が平均行数を超えるまではバッファ内で処理し，更新については，バッファヒット率を0%として試算する。
(2) 見積りの結果
1日の全てのログによる回復時間は，追加では，オページのI/Oが発生するのでカ秒，更新では，キページのI/Oが発生するのでク秒を要する。ログ量が均等になるタイミングでオンラインバックアップを取得し，ログによる回復時間を5分以内にするためには，1日にケ回のオンラインバックアップを取得すればよい。
2. バッチAPの運用変更
ログなしモードのテーブルを対象に実行していた“点検抽出”，“車検抽出1”，“車検抽出2”の各APをオンライン時間帯に移行する影響について検証した。ログなしモードのテーブルを更新するAPをオンラインで実行すると，開始から完了までの間，チェックポイントが取得されない。この間にサーバ障害が発生すると，RDBMS再開始のとき，コが大量に行われるおそれがあり，回復に要する時間が長期化するという問題がある。
そのため，ログなしモードの指定を取りやめることにした。ただし，APの処理内容は変更しない。また，“WK1”，“WK2”の各テーブルは，バックアップ対象外のままとする。この場合，運用の変更に当たって，次の2点のリソースの見直しが必要となる。
(1) “WK1”テーブルと“WK2”テーブルのログが新たに出力されるので，ログの格納領域が不足しないよう見直す。
(2) “WK1”テーブルと“WK2”テーブルのサのでシが不足しないよう見直す。
拡大図1 車両保守システムのテーブル構造（一部省略）
拡大図2 バッチ処理の実行スケジュール
拡大表4 主なAPのCRUD
拡大表5 バックアップの取得スケジュール（未完成）
拡大図3 “予約登録” APの処理内容
設問一覧 ＆ 解答・演習
まずは解答を作成してみましょう。「解答例を見る」をクリックするとIPA公式解答例と採点基準が開きます。
設問1 (1)記号・選択式
〔現行バッチ処理のバックアップ・リカバリ〕について答えよ。
(1) 表5中の太枠部分内に，“〇”を記入して表を完成させよ。ただし，太枠部分以外のバックアップを取得する契機には全て“〇”を記入済みである。なお，バックアップを取得しないテーブルとその契機は，空欄のままとすること。
(1) 表5中の太枠部分内に，“〇”を記入して表を完成させよ。ただし，太枠部分以外のバックアップを取得する契機には全て“〇”を記入済みである。なお，バックアップを取得しないテーブルとその契機は，空欄のままとすること。
※直接入力してください
設問1 (2) (a)記号・選択式
〔現行バッチ処理のバックアップ・リカバリ〕について答えよ。
“2. サーバ障害時のRDBMS再開始”について答えよ。
(a) 本文中の a 〜 g に入れる適切な字句を答えよ。
“2. サーバ障害時のRDBMS再開始”について答えよ。
(a) 本文中の a 〜 g に入れる適切な字句を答えよ。
※直接入力してください
設問1 (2) (b)記号・選択式
〔現行バッチ処理のバックアップ・リカバリ〕について答えよ。
“2. サーバ障害時のRDBMS再開始”について答えよ。
(b) 本文中の h, i に入れる適切なAP名を全て答えよ。ここで，対象となるAPがない場合，“なし”とすること。また，j に入れる適切な秒数を答えよ。
“2. サーバ障害時のRDBMS再開始”について答えよ。
(b) 本文中の h, i に入れる適切なAP名を全て答えよ。ここで，対象となるAPがない場合，“なし”とすること。また，j に入れる適切な秒数を答えよ。
※直接入力してください
設問1 (2) (c)記号・選択式
〔現行バッチ処理のバックアップ・リカバリ〕について答えよ。
“2. サーバ障害時のRDBMS再開始”について答えよ。
(c) 本文中の k, l に入れる適切なAP名を全て答えよ。ここで，対象となるAPがない場合，“なし”とすること。また，m に入れる適切な秒数を答えよ。
“2. サーバ障害時のRDBMS再開始”について答えよ。
(c) 本文中の k, l に入れる適切なAP名を全て答えよ。ここで，対象となるAPがない場合，“なし”とすること。また，m に入れる適切な秒数を答えよ。
※直接入力してください
設問2 (1) (a)記号・選択式
〔バッチ処理のオンライン時間帯への移行〕について答えよ。
(1) 問題1への対処について答えよ。
(a) 本文中の ア, イ に入れる適切な字句を答えよ。
(1) 問題1への対処について答えよ。
(a) 本文中の ア, イ に入れる適切な字句を答えよ。
【選択肢】 クリックして選択（複数選択可）
選択中の解答:未選択（上の選択肢ボタンをクリックしてください）
設問2 (1) (b)記述問題
制限字数：40 字以内
〔バッチ処理のオンライン時間帯への移行〕について答えよ。
(1) 問題1への対処について答えよ。
(b) “報告作成” APの変更内容を40字以内で具体的に答えよ。
(1) 問題1への対処について答えよ。
(b) “報告作成” APの変更内容を40字以内で具体的に答えよ。
0 / 40 文字
設問2 (1) (c)記述問題
制限字数：40 字以内
〔バッチ処理のオンライン時間帯への移行〕について答えよ。
(1) 問題1への対処について答えよ。
(c) (b)の変更を行った場合，AP障害の発生後に行う再処理において，“報告”テーブルに，追加済みの行と報告内容が同一の行の追加は発生するか。発生の有無を判断し，答案用紙の“有”又は“無”のどちらかを〇で囲み，判断の根拠を40字以内で具体的に答えよ。
(1) 問題1への対処について答えよ。
(c) (b)の変更を行った場合，AP障害の発生後に行う再処理において，“報告”テーブルに，追加済みの行と報告内容が同一の行の追加は発生するか。発生の有無を判断し，答案用紙の“有”又は“無”のどちらかを〇で囲み，判断の根拠を40字以内で具体的に答えよ。
0 / 40 文字
設問2 (2) (a)記号・選択式
〔バッチ処理のオンライン時間帯への移行〕について答えよ。
(2) 問題2への対処について答えよ。
(a) 本文中の ウ, エ に入れる適切な手配#を答えよ。
(2) 問題2への対処について答えよ。
(a) 本文中の ウ, エ に入れる適切な手配#を答えよ。
※直接入力してください
設問2 (2) (b)記号・選択式
〔バッチ処理のオンライン時間帯への移行〕について答えよ。
(2) 問題2への対処について答えよ。
(b) 変更するAP名を答えよ。
(2) 問題2への対処について答えよ。
(b) 変更するAP名を答えよ。
※直接入力してください
設問2 (2) (c)記述問題
制限字数：35 字以内
〔バッチ処理のオンライン時間帯への移行〕について答えよ。
(2) 問題2への対処について答えよ。
(c) (b)で解答したAPの変更内容を35字以内で具体的に答えよ。
(2) 問題2への対処について答えよ。
(c) (b)で解答したAPの変更内容を35字以内で具体的に答えよ。
0 / 35 文字
設問2 (3) (a)記述問題
制限字数：30 字以内
〔バッチ処理のオンライン時間帯への移行〕について答えよ。
(3) 問題3への対処について答えよ。
(a) レビューで指摘を受けたデッドロックは，どのような状況で発生するか。30字以内で具体的に答えよ。
(3) 問題3への対処について答えよ。
(a) レビューで指摘を受けたデッドロックは，どのような状況で発生するか。30字以内で具体的に答えよ。
0 / 30 文字
設問2 (3) (b)記述問題
制限字数：20 字以内
〔バッチ処理のオンライン時間帯への移行〕について答えよ。
(3) 問題3への対処について答えよ。
(b) 案1について，図5中の処理内容の修正内容を20字以内で具体的に答えよ。ただし，コミットの発行頻度は変更しないものとする。
(3) 問題3への対処について答えよ。
(b) 案1について，図5中の処理内容の修正内容を20字以内で具体的に答えよ。ただし，コミットの発行頻度は変更しないものとする。
0 / 20 文字
設問2 (3) (c)記述問題
制限字数：30 字以内
〔バッチ処理のオンライン時間帯への移行〕について答えよ。
(3) 問題3への対処について答えよ。
(c) 案2について，変更するAP名を答えよ。また，変更内容を30字以内で具体的に答えよ。
(3) 問題3への対処について答えよ。
(c) 案2について，変更するAP名を答えよ。また，変更内容を30字以内で具体的に答えよ。
0 / 30 文字
設問3 (1)記号・選択式
〔移行後の運用設計〕について答えよ。
(1) 本文中の オ 〜 ケ に入れる適切な数値を答えよ。
(1) 本文中の オ 〜 ケ に入れる適切な数値を答えよ。
※直接入力してください
設問3 (2)記述問題
制限字数：20 字以内
〔移行後の運用設計〕について答えよ。
(2) 本文中の コ, シ に入れる適切な字句を答えよ。また，サ に入れる適切な文を20字以内で答えよ。
(2) 本文中の コ, シ に入れる適切な字句を答えよ。また，サ に入れる適切な文を20字以内で答えよ。
0 / 20 文字
午後II長文記述の得点力を引き上げる定番対策書Amazon・楽天 公式提携
PR
IPA 厳選対策書徹底攻略 データベーススペシャリスト教科書 令和8年度株式会社わくわくスタディワールド 瀬戸 美月 著 / インプレス
DB徹底攻略株式会社わくわくスタディワールド 瀬戸 美月 著 / インプレス
徹底攻略 データベーススペシャリスト教科書 令和8年度
💡 推薦ポイント:午後I・午後IIの概念データモデル穴埋めや排他制御・性能設計の記述問題で確実に合格点を勝ち取る実践テクニックが満載です。
¥3,278（税込）
※本リンク先はプロモーション（アフィリエイト広告）が含まれています
【出題趣旨】IPA公式発表
【採点講評】IPA公式発表
本問に関連するデータベーススペシャリスト重要用語解説
本番形式・制限時間付きで演習する
令和6年 秋期 午後II（2問中1問選択・120分）を実戦演習モードで通し解答し、総合採点を受けられます。