HOME > 受験対策 > サンプル問題/例題解説 > Goldの例題解説「パフォーマンスチューニング」

Goldの例題解説「パフォーマンスチューニング」

Yahoo!ブックマークに登録

このページでは例題「パフォーマンスチューニング」のアーカイブを試験ごとにまとめています。是非、OSS-DB技術者認定試験の学習にお役立てください。

[パフォーマンスチューニング - 性能に関するパラメータ] から
Q. work_memをチューニングすることによって、性能が向上すると考えられる処理を全て選択しなさい。
  1. A. ORDER BY
  2. B. CREATE INDEX
  3. C. マージ結合
  4. D. VACUUM
  5. E. 自動VACUUM

[パフォーマンスチューニング - チューニングの実施] から
Q. インデックスの作成に関する説明として、適切なものを2つ選びなさい。
  1. A. FILLFACTORの指定が省略された場合、デフォルト値として対象テーブルのFILLFACTORと同じ値が設定される
  2. B. UNLOGGEDパラメータが指定された場合、インデックスの更新時にWALログが取られなくなり、更新処理が高速化する
  3. C. PARALLELパラメータが指定された場合、複数のプロセスによりインデックスが作成され、作成時間が短縮する
  4. D. CONCURRENTLYパラメータが指定された場合、対象テーブルに対する書き込みをロックせずにインデックスを作成するが、通常の方式より作成時間が長くなる
  5. E. インデックスの定義で使用される関数と演算子は、immutableでなければならない

[パフォーマンスチューニング - 実行計画のチューニング] から
Q. GUCパラメータのenable_seqscanをonからoffに変更する前後で、同一のクエリに対してEXPLAIN ANALYZE文で実行計画を取得する。
実行計画の変化の説明として、最も適切ではないものを1つ選びなさい。
この時、enable_seqscan以外の条件はすべて同一とする。
  1. A. Total runtimeの値が大きくなる可能性がある
  2. B. Total runtimeの値が小さくなる可能性がある
  3. C. 最上位ノードの全体推定コストが大きくなる可能性がある
  4. D. 最上位ノードの全体推定コストが小さくなる可能性がある
  5. E. 全く同一の実行計画が選択される可能性がある

[パフォーマンスチューニング - チューニングの実施] から
Q. インデックスの再作成について正しい記述を2つ選びなさい。
  1. A. インデックスの再作成はサービスを停止して行う必要がある。
  2. B. REINDEXはインデックスの元となるテーブルの読み込みをロックしないため、サービス稼働中に実行しても参照処理への影響はない。
  3. C. CREATE INDEX CONCURRENTLYは、同時挿入、更新、削除と競合するロックを獲得せずにインデックスを作成できる。
  4. D. CREATE INDEX CONCURRENTLYでは、プライマリキーの作成も可能である。
  5. E. 定期的にインデックスの再作成を行うことで、インデックスの肥大化を抑止できる。

[パフォーマンスチューニング - チューニングの実施] から
Q. PostgreSQLの処理全般が定期的に遅くなる現象が発生した。この場合のチューニングで効果が期待できる対策を2つ選びなさい。
  1. A. 遅くなったSQLを見直し、負荷の原因となっている記述を修正する。
  2. B. checkpoint_completion_targetを調整して、チェックポイントの負荷分散を図る。
  3. C. autovacuum_cost_limitまたはvacuum_cost_limit値を大きくし、VACUUM処理の負荷低減を図る。
  4. D. ストリーミングレプリケーション構成に変更し負荷分散を図る。
  5. E. PostgreSQLの特性であり対策はない。

[パフォーマンスチューニング - 性能に関するパラメータ] から
Q. full_page_writesパラメータをOFFに設定した場合に関する説明として、適切でないものを2つ選びなさい。
  1. A. データ更新時の応答性能が向上する可能性がある
  2. B. データ更新時のWALの書き込み量が低減する可能性がある
  3. C. wal_levelパラメータがminimalの場合は、応答性能は変化しない
  4. D. システムクラッシュ時に、回復不可能なデータ破損が発生する可能性がある
  5. E. ポイントインタイムリカバリの運用はできなくなる

[パフォーマンスチューニング - 性能に関するパラメータ] から
Q. 性能低下の原因に関して正しいものをすべて選択しなさい。
  1. A. shared_buffersの値を大きく設定しすぎたことによって、チェックポイント中の問い合わせの性能が低下した。
  2. B. maintenance_work_memをwork_memよりも大きく設定したことによって、VACUUM処理の性能が低下した。
  3. C. 複数のセッションが多量のINSERTを発行したことによって、WALファイルへの書き込みで競合が発生し、INSERTの性能が低下した。
  4. D. pgstattupleを用いて定期的にタプルレベルの統計情報を取得しなかったため、PostgreSQLが最適な実行計画を作成できずに問い合わせの性能が低下した。

[パフォーマンスチューニング - 性能に関するパラメータ] から
Q. GUCパラメータの説明として、誤っているものを全て選択しなさい。
  1. A. enable_seqscanをoffに設定しても、Seq Scanが選択されることがある
  2. B. enable_indexscanをoffに設定すると、Index Only Scanが選択されない
  3. C. enable_mergejoinをoffに設定しても、Merge Joinが選択されることがある
  4. D. default_statistics_targetをより小さい値に設定すると、実行計画の生成時間が短縮される
  5. E. from_collapse_limitをより小さい値に設定すると、実行計画の生成時間が短縮される

[パフォーマンスチューニング - ディスクI/Oの分散] から
Q. ディスクI/Oの分散に関する説明として、適切ではないものを1つ選びなさい。
  1. A. GUCパラメータ wal_buffersの値を増加させることで、WALの書き込み回数が減少し、パフォーマンスが改善する可能性がある。
  2. B. GUCパラメータ work_memの値を増加させることで、ソート処理やハッシュテーブル作成時のディスク書き込みが減少し、パフォーマンスが改善する可能性がある。
  3. C. 複数のディスクがマウントされた環境において、テーブルスペース機能によって各テーブルデータを異なるディスク上に格納してディスクIOを分散させることで、パフォーマンスが改善する可能性がある。
  4. D. パーティショニング機能によって物理的に複数に分割されたテーブルに対してパラレルクエリを実行することで、問い合わせのパフォーマンスが改善する可能性がある。
  5. E. 統計情報データの一時的な出力先としてRAMベースのファイルシステムを指定することで、ディスクI/O要求が減少し、パフォーマンスが改善する可能性がある。

[パフォーマンスチューニング - チューニングの実施] から
Q. データベースに大量データを投入する際の性能を向上させるために、一時的に講じることとして、適切とは言えないものを2つ選びなさい。
  1. A. 自動コミットをオフにする
  2. B. インデックスや外部キー制約を削除する
  3. C. maintenance_work_memを増やす
  4. D. checkpoint_segmentsを減らす
  5. E. checkpoint_timeoutを増やす

[パフォーマンスチューニング - 性能に関係するパラメータ(ロック管理)] から
Q. デッドロックに関する GUC パラメータ deadlock_timeout の説明として、正しいものをすべて選びなさい。
  1. A. deadlock_timeout で指定された時間を経過してもロックが獲得できなければ、デッドロックが発生していると判断される。
  2. B. deadlock_timeout の値を調整することで、デッドロックの発生を回避できる。
  3. C. deadlock_timeout の値を小さくすると、ロック待ちのプロセスが減るので、結果的にCPU負荷を小さくすることができると考えられる。
  4. D. デッドロックはアプリケーションの作り方を工夫することで回避すべきであり、deadlock_timeout の値はなるべく大きくすることが望ましい。
  5. E. deadlock_timeout のデフォルトの設定では、デッドロックの検出は自動的には実行されない。

[パフォーマンスチューニング - 性能に関係するパラメータ] から
Q. GUCパラメータの説明として、誤っているものを1つ選びなさい。
  1. shared_bufferは、PostgreSQLサーバが使用する共有メモリバッファのサイズ を設定する。
  2. max_connectionsは、PostgresSQLサーバに接続できる最大クライアント数を 設定する。
  3. work_memは、VACUUM、CREATE INDEXなどの保守作業で使用されるメモリの最 大容量を設定する。
  4. sslをonに設定することでSSL接続を有効にする。
  5. wal_levelは、WALに書き込まれる情報を制御するパラメータである。

ページトップへ