OSS-DB Gold勉強法｜独学合格ロードマップと教材

OSS-DB Silverに合格したあと、Goldを前にして手が止まる人は多いです。Silverは「PostgreSQLの操作と基本概念を知っているか」を問う試験ですが、Goldは「性能問題や障害が起きたときに、何を見てどう判断するか」を問います。市販の対策本は潤沢になく、ネット上の情報も断片的です。

この記事では、PostgreSQLの実務経験が浅い人が独学でGold（PostgreSQL版）を狙う前提で、出題範囲の優先順位、学習の順番、教材の取捨選択の基準、得点源になるテーマの攻略ポイントを整理します。

試験のバージョン・出題範囲・配点比率・受験料は改定されます。学習を始める前に、LPI-Japan（OSS-DB技術者認定資格の公式サイト）で現行バージョンと出題範囲、前提とされるPostgreSQLバージョンを確認してください。この記事も、公式の出題範囲を自分で開いて照合しながら読むのが前提です。

OSS-DB Gold で問われる力は Silver とどう違うのか

Silverの学習は「用語と機能の対応付け」でかなり進みます。pg_dumpのオプション、ロール管理、CREATE TABLEの構文、トランザクション分離レベルの名前。これらは覚えれば答えられます。

Goldでは問題文が「この状況で原因として考えられるものはどれか」「この設定を変更したときに起きることはどれか」という形になり、選択肢が全部もっともらしく見えます。暗記した単語を当てはめる解き方では、似た用語の選択肢に引っかかります。次のような区別は、名前を覚えただけでは正解にたどり着けません。

• VACUUMとVACUUM FULLの違い（領域をファイルシステムに返すか、AccessExclusiveLockを取るか、インデックスを作り直すか）
• synchronous_commitのon / remote_write / remote_apply / local / offが、それぞれどこまでの永続性を保証するか
• wal_keep_sizeとレプリケーションスロットが、どちらもWALを保持する仕組みでありながら挙動が違う点
• 統計情報の更新（ANALYZE）と不要領域の回収（VACUUM）が別の目的を持つこと

Goldで問われているのは、PostgreSQLの内部動作のモデルを持っているかです。MVCCによって更新が追記として書かれ、古い行バージョンが残るからこそVACUUMが必要になる。WALに先に書いてからデータファイルを更新するからクラッシュリカバリとPITRが成立する。プランナがコストモデルで実行計画を選ぶため、統計情報がずれると計画もずれる。この因果がつながれば、知らない設定パラメータが出てきても「どの仕組みに関わるものか」で絞り込めます。

Silverの学習法はOSS-DB Silver勉強法｜独学の教材選びとロードマップにまとめました。Goldでは同じアプローチ（問題集の周回中心）だけでは伸びにくい、という点を最初に押さえてください。

出題範囲と配点から見る優先順位

公開されているGoldの出題範囲は、大きく次の4分野に分かれます（比率は公式サイトの記載を確認してください）。

分野	比率の目安	主な内容
運用管理	約30%	設定ファイル、ユーザ・権限、テーブルスペース、メンテナンス、監視設計
性能監視	約30%	統計情報ビュー、実行計画、ログ出力設定、ボトルネック特定
パフォーマンスチューニング	約20%	メモリ・ディスク関連パラメータ、インデックス設計、クエリ書き換え、VACUUM戦略
障害対応	約20%	バックアップ／リストア、PITR、クラッシュリカバリ、レプリケーション

出題形式は選択式で30問・90分、合格ラインは7割前後とされています。30問しかないので1問の重みは3点以上あり、苦手分野を1つ丸ごと捨てるとそれだけで不合格圏に入ります。

優先順位をつけるなら次の順です。

1. 性能監視（実行計画と統計情報ビュー）。配点が大きく、他分野の問題を解く前提にもなります。EXPLAINが読めないとチューニングの問題も解けません。
2. 障害対応（WAL、バックアップ、レプリケーション）。配点は20%ですが、設定パラメータと手順がはっきりしており、学習コストに対して得点が安定します。
3. パフォーマンスチューニング。メモリ関連パラメータとVACUUM周辺に集約されるため、1と重複して学べます。
4. 運用管理。範囲が広く雑多で、他分野の学習でカバーされる部分が多いので、最後に穴埋めで回収します。

逆にやってはいけないのは、出題範囲の1項目目から順に潰そうとすることです。運用管理の細かい話から始めると、実行計画に取りかかる前に息切れします。

独学で合格するまでの学習ロードマップ

全体の流れは「範囲の地図を作る → 手を動かして挙動を確認する → 問題で穴を見つける」の3段階です。問題集から入ると正解の選択肢を覚えるだけになり、言い換えられた出題に対応できません。

週に6〜8時間確保できる人なら2〜3か月が目安です。PostgreSQLの運用経験があれば短縮できますが、縮むのは第2段階だけです。

第1段階：出題範囲を公式マニュアルに紐づけて潰す

最初にやるのは、公式の出題範囲を1行ずつPostgreSQL公式マニュアル（日本語版）の該当章に対応づける作業です。スプレッドシートで構いません。列は「出題範囲の項目」「対応するマニュアルの章」「読んだか」「自分の言葉で説明できるか」の4つ。

対応づけの例を挙げます。

• 「クエリの実行計画」→ マニュアル「性能に関するヒント」のEXPLAINの章、および「サーバ設定」のプランナコスト定数
• 「VACUUMの運用」→「定常的なデータベース保守作業」の章、特にトランザクションIDの周回防止の節
• 「バックアップとリストア」→「バックアップとリストア」の章（SQLダンプ／ファイルシステムレベル／継続的アーカイブ）
• 「監視」→「データベース活動状況の監視」の章（統計情報コレクタと各ビューの列定義）

この作業で、試験対策の出典を一か所に固定できます。Goldは情報源が散らばっており、ブログ記事を拾い読みしていると古いバージョンの挙動と新しい挙動が混ざります。マニュアルの章番号に紐づけておけば、迷ったときに戻る場所ができます。

参照するマニュアルのバージョンも固定してください。日本語マニュアルは複数バージョンが並行して公開されています。試験が前提とするバージョンに最も近いものを1つ選び、ブラウザのブックマークに入れます。

第1段階の完了条件は「全項目にマニュアルの章が紐づき、一度読み通した」状態です。この時点で理解できていなくても構いません。地図を作ることが目的です。

第2段階：検証環境で設定値を動かして挙動を確かめる

Goldの問題は「パラメータを変えたときに何が起きるか」を問います。手を動かさないと身につきません。DockerでPostgreSQLを1台立て、設定を変えて再読み込みする作業を日常化します。

docker run -d --name pg-gold \
  -e POSTGRES_PASSWORD=postgres \
  -p 5432:5432 \
  -v pg-gold-data:/var/lib/postgresql/data \
  postgres:17

docker exec -it pg-gold psql -U postgres

最初に覚えるべきは、パラメータの反映方法が3種類あることです。これ自体が出題対象になります。

-- 現在値と、変更の反映に何が必要かを確認する
SELECT name, setting, unit, context, source
  FROM pg_settings
 WHERE name IN ('shared_buffers','work_mem','wal_level','log_min_duration_statement');

context列がpostmasterなら再起動が必要、sighupなら設定リロード（pg_reload_conf()／pg_ctl reload）で反映、userならセッション内でSETできます。shared_buffersとwal_levelは再起動必須、log_min_duration_statementはリロードで反映、work_memはセッション単位で変更可能、という区別は確実に押さえてください。

-- ファイルを書き換えずに設定を変える（ALTER SYSTEM は postgresql.auto.conf に書かれる）
ALTER SYSTEM SET log_min_duration_statement = '200ms';
SELECT pg_reload_conf();
SELECT name, setting, source, sourcefile FROM pg_settings WHERE name = 'log_min_duration_statement';

検証テーマは優先順位に合わせて次の順で回します。1テーマは「仮説を立てる → 実行する → 期待と違ったらマニュアルに戻る」で30分から1時間です。

1. 数十万行のテーブルを作り、インデックスの有無でEXPLAIN ANALYZEの計画がどう変わるか
2. work_memを小さくしてSort Method: external merge Diskを出し、大きくしてquicksortに変わることを確認
3. 更新・削除を繰り返してpg_stat_user_tables.n_dead_tupを増やし、VACUUM前後でテーブルサイズと計画がどう変わるか
4. wal_level = replicaでアーカイブを有効にし、pg_basebackupでバックアップを取ってPITRを一度通す
5. ストリーミングレプリケーションを1組構成し、pg_stat_replicationのLSN列を確認する

テストデータはgenerate_seriesで作れます。

CREATE TABLE t_order (
  id        bigint PRIMARY KEY,
  user_id   int    NOT NULL,
  status    text   NOT NULL,
  amount    numeric(12,2) NOT NULL,
  created_at timestamptz NOT NULL
);

INSERT INTO t_order
SELECT g,
       (random()*10000)::int,
       (ARRAY['new','paid','shipped','canceled'])[1 + (random()*3)::int],
       (random()*10000)::numeric(12,2),
       now() - (random()*365) * interval '1 day'
  FROM generate_series(1, 500000) g;

ANALYZE t_order;

コンテナが起動しない、データが消えるといったつまずきは学習の本筋ではありません。詰まったらPostgreSQL Docker起動エラー切り分け手順に沿って早く抜け、環境構築に時間を使いすぎないようにしてください。

第3段階：模擬問題で弱点を特定し、解説を自分の言葉で再構成する

問題演習の目的は、自分がどの仕組みを理解していないかを特定することです。解いた後の処理を決めておきます。1問ごとに、以下のどれかに分類します。

• A: 根拠を説明して正解した。復習不要
• B: 正解したが、消去法や勘が混じった。要復習（ここが一番危険）
• C: 間違えた。要復習

BとCは、解説を読んだうえでマニュアルの該当箇所を開き、自分のノートに3〜5行で書き直します。このとき「なぜその選択肢が誤りなのか」を全選択肢について書きます。Goldの選択肢には「正しいことを言っているが設問の条件に合わない」ものが混ざるため、誤答理由の言語化が直接得点につながります。

ノートの書き方の例です。

テーマ: autovacuum が走らない
仕組み: autovacuum は (しきい値 + 係数 × 行数) を超えた dead tuple で起動判定される
確認手順: pg_stat_user_tables の n_dead_tup / last_autovacuum、pg_settings の autovacuum 系
誤答しやすい点: autovacuum = off でも、周回の危険が迫れば強制的に実行される
戻る場所: マニュアル「定常的なデータベース保守作業」

試験直前の1〜2週間は、このノートだけを読み返す期間にします。新しい教材を増やすのは逆効果です。

教材・問題集の比較と選び方（網羅性・対応バージョン・解説の深さ・入手性）

Goldは教材が少ないため、「良い教材を探す」よりも「限られた選択肢をどう組み合わせるか」が実際の判断になります。評価軸は4つです。

1. 対応バージョン（最重要）

Goldの出題は内部動作に踏み込むため、バージョン差が得点に直結します。教材はまず対応バージョンを確認してください。古い教材だと、次のような記述が現行と食い違います。

• リカバリ設定がrecovery.confに書かれている（PostgreSQL 12以降はpostgresql.conf + recovery.signal / standby.signal）
• wal_keep_segments（13以降はwal_keep_size）
• checkpoint_completion_targetのデフォルトが0.5（14以降は0.9）
• pg_stat_bgwriterにチェックポイント統計が含まれている（17でチェックポイント関連はpg_stat_checkpointerに分離）
• I/O統計のビューがない（16でpg_stat_ioが追加）

古い教材を使わざるを得ない場合は、設定パラメータ名と統計情報ビューの列を必ず現行マニュアルで突き合わせてください。概念（MVCC、WAL、コストモデル）の説明は古くても通用しますが、名前と数値は信用しないという切り分けです。

2. 網羅性

目次で4分野すべてをカバーしているかを判定します。Goldの教材は性能チューニングに偏りがちで、障害対応（PITR、レプリケーション）の記述が薄いものがあります。1冊で足りないのが普通なので、内部構造と運用の全体像をつかむ本1冊、リファレンスとして引ける本またはマニュアル、問題演習できるもの、という3点セットを前提に組みます。書籍の層ごとの整理はPostgreSQL本おすすめ｜レベル別の読む順番にあるので、1冊目の選定はそちらを参照してください。Gold対策では「SQLの書き方」より内部構造・運用設計の層を厚くします。

3. 解説の深さ

問題集を選ぶ基準は問題数より、解説が「なぜ他の選択肢が誤りか」まで書いてあるかです。サンプルを見られるなら、1問の解説が3行で終わっていないか確認します。正解の根拠だけ書かれた解説では、Goldには情報量が足りません。

4. 入手性と無償リソース

有償教材の前に、無償で確実に使えるものを押さえます。

• PostgreSQL公式マニュアル（日本語）。第1段階の軸で、章単位で紐づけて使う
• 公式サイトの出題範囲。試験の正式な仕様で、改定の有無をときどき確認する
• 公式サイト掲載の例題と例題解説。選択肢の作り方や問題文の長さを把握するために読む
• 公式サイトのサンプル問題や技術解説セミナー資料。公開状況は時期によって変わるので、現在の掲載内容を確認する

Web問題集サービスを使う場合は、申込前にGold（PostgreSQL版）に対応しているか、対応バージョンはいつか、問題数はいくつかを確認してください。Silverは対応していてもGoldは対象外、というケースがあります。

教材の組み合わせを決めるときの判断基準は次のとおりです。

状況	推奨する重心
PostgreSQLの運用経験がほぼない	内部構造の本を1冊通読 → 検証環境 → 問題演習
運用経験はあるが性能分析が未経験	実行計画と統計情報ビューに特化して検証 → 問題演習
チューニング経験はあるが障害対応が未経験	PITRとレプリケーションを実機で1周 → 問題演習
試験まで時間がない	例題解説と問題集で弱点特定 → 弱点のみマニュアル精読

得点源になる重点テーマの攻略法

配点が大きく、独学で差がつきやすい3テーマを掘ります。

実行計画：EXPLAIN (ANALYZE, BUFFERS) の読み方とコスト見積りのズレ

まず押さえるのは、プランナが実行時間を予測していない点です。プランナが計算しているのは抽象的な「コスト」で、内訳はコスト定数と統計情報から決まります。

SELECT name, setting FROM pg_settings
 WHERE name IN ('seq_page_cost','random_page_cost','cpu_tuple_cost',
                'cpu_index_tuple_cost','cpu_operator_cost','effective_cache_size');

デフォルトではseq_page_cost = 1.0、random_page_cost = 4.0、cpu_tuple_cost = 0.01などで、ランダムアクセスがシーケンシャルの4倍高コストと見なされます。この比率は回転ディスク時代の想定であり、SSDやキャッシュが利用できる環境ではrandom_page_costを下げるとインデックススキャンが選ばれやすくなります。この因果を説明できるかが問われます。effective_cache_sizeが実際にメモリを確保せず、プランナへのヒントとして働く点も頻出です。

実行計画を読むときは、必ずANALYZEとBUFFERSを付けます。

EXPLAIN (ANALYZE, BUFFERS, VERBOSE)
SELECT user_id, sum(amount)
  FROM t_order
 WHERE status = 'paid'
   AND created_at >= now() - interval '30 days'
 GROUP BY user_id;

出力は次の順で見ます。

1. rows=の見積りとactual rows=の乖離。数倍以上ずれていると、上位ノードの結合方式の選択がまるごと変わります。原因はANALYZEが走っていない、default_statistics_targetが足りない、複数列の相関がある、のいずれかに大別できます。
2. loops=。Nested Loopの内側ノードはloops回実行されるため、表示される時間は1回分です。合計時間はactual time × loopsで考えます。
3. Buffers: shared hit / read / dirtied / written。hitは共有バッファのヒット、readはバッファに無くて読み込んだ分です。readが大きければI/O待ちを疑います。temp read/writtenが出ていれば、ソートやハッシュが一時ファイルに溢れています。
4. Sort Method。quicksortならメモリ内、external merge Diskならwork_mem不足です。Hash JoinのBatchesが1を超えている場合も同様です。
5. Heap Fetches。Index Only Scanで可視性マップが古いとheapを参照しに行きます。VACUUMとの関連で問われます。
6. Workers PlannedとWorkers Launched。並列実行が計画されても、max_parallel_workers_per_gatherやワーカー枯渇で実際には起動しないことがあります。

複数列の相関による見積りずれは、拡張統計で改善できます（PostgreSQL 10以降）。

-- 市区町村と都道府県のように相関がある列の組み合わせ
CREATE STATISTICS st_order_user_status (dependencies, ndistinct)
  ON user_id, status FROM t_order;
ANALYZE t_order;

特定の列だけ統計の精度を上げるなら、列単位で指定できます。

ALTER TABLE t_order ALTER COLUMN status SET STATISTICS 500;
ANALYZE t_order;

分布の確認はpg_statsビューです。n_distinct、most_common_vals、most_common_freqs、correlationの意味、特にcorrelationが物理的な並び順との相関でインデックススキャンのコスト見積りに影響する点を、説明できるようにしておきます。

VACUUM・凍結・HOT と統計情報ビューの確認ポイント

VACUUMはGoldで最も出題が濃いテーマの1つです。暗記ではなく、MVCCから順に因果で押さえます。

PostgreSQLのUPDATEは、既存行を書き換えず、新しい行バージョンを追記して古いバージョンに終了トランザクションID（xmax）を設定します。更新・削除を繰り返すと、どのトランザクションからも見えない死んだ行バージョンが溜まります。これを回収して再利用可能領域（FSM）に登録するのがVACUUMの第一の役割です。

第二の役割が凍結（freeze）です。トランザクションIDは32bitで周回するため、十分に古い行は「常に可視」を意味する凍結状態に書き換える必要があります。関連パラメータの役割分担を区別してください。

• vacuum_freeze_min_age。この年齢を超えた行を凍結対象にする
• vacuum_freeze_table_age。通常のVACUUMを全ページ走査（aggressive）に切り替える境界
• autovacuum_freeze_max_age。これを超えると、autovacuum = offでも周回防止のVACUUMが強制的に起動する

最後の挙動は頻出です。「autovacuumを無効にしておけばVACUUMは一切走らない」は誤りです。現在の年齢はこう確認します。

SELECT relname,
       age(relfrozenxid) AS xid_age,
       pg_size_pretty(pg_total_relation_size(oid)) AS size
  FROM pg_class
 WHERE relkind = 'r'
 ORDER BY age(relfrozenxid) DESC
 LIMIT 10;

HOT（Heap Only Tuple）更新も押さえどころです。更新対象の列がどのインデックスにも含まれず、同一ページ内に新しい行バージョンを置ける場合、インデックスを更新せずに済みます。書き込み量とインデックス肥大化が抑えられます。だからこそfillfactorを下げてページに余裕を残す設計が意味を持ちます。

ALTER TABLE t_order SET (fillfactor = 80);
-- 既存ページには即座には効かない点に注意

autovacuumの起動判定は、しきい値と係数の組み合わせです。

# 判定式のイメージ: dead tuple 数 > threshold + scale_factor * 行数
autovacuum_vacuum_threshold = 50
autovacuum_vacuum_scale_factor = 0.2
autovacuum_analyze_threshold = 50
autovacuum_analyze_scale_factor = 0.1

デフォルトのscale_factor = 0.2は「行数の20%が死ぬまで走らない」という意味で、大規模テーブルでは遅すぎます。テーブル単位で上書きするのが実務の定番です。

ALTER TABLE t_order SET (autovacuum_vacuum_scale_factor = 0.02,
                         autovacuum_vacuum_threshold = 1000);

PostgreSQL 13以降は、INSERTのみのテーブルでも凍結・可視性マップ更新のためにautovacuum_vacuum_insert_thresholdによる起動が追加されています。こうしたバージョン差は、参照しているマニュアルのバージョンで確認してください。

状況確認に使うビューは、列名まで覚えるつもりで触っておきます。

-- 肥大化と最終実行時刻
SELECT relname, n_live_tup, n_dead_tup, n_mod_since_analyze,
       last_vacuum, last_autovacuum, last_analyze, last_autoanalyze
  FROM pg_stat_user_tables
 ORDER BY n_dead_tup DESC LIMIT 10;

-- 実行中の VACUUM の進捗（phase 列が重要）
SELECT pid, relid::regclass, phase, heap_blks_total, heap_blks_scanned
  FROM pg_stat_progress_vacuum;

-- 待機イベントでボトルネックを見る
SELECT pid, state, wait_event_type, wait_event, query
  FROM pg_stat_activity
 WHERE state <> 'idle';

VACUUM FULLはAccessExclusiveLockを取得してテーブルを書き換え直すため、オンラインでは使えません。領域をOSに返す必要がある場合に限り、停止時間を確保して実行する。この判断基準まで含めて覚えます。

WAL・バックアップ／リカバリとレプリケーションの設定値

このテーマは設定パラメータと手順が明確なので、きちんと準備すれば取りこぼしが少なくなります。

出発点はWALの役割です。変更をまずログ（WAL）に書き、チェックポイント時点以降のWALを使って復旧できる状態を保つ。この前提から、wal_levelの3段階が導けます。

• minimalはクラッシュリカバリに必要な最小限で、アーカイブリカバリやレプリケーションはできない
• replicaはWALアーカイブとストリーミングレプリケーション、スタンバイでの読み取りが可能
• logicalは論理デコーディング（論理レプリケーション）に必要な情報を追加で記録する

チェックポイント関連は、「頻度を下げると復旧時間が延び、頻度を上げるとI/Oが増える」というトレードオフで覚えます。

wal_level = replica
max_wal_size = 4GB
min_wal_size = 1GB
checkpoint_timeout = 15min
checkpoint_completion_target = 0.9   # 14 以降のデフォルト
full_page_writes = on
archive_mode = on
archive_command = 'test ! -f /arch/%f && cp %p /arch/%f'

full_page_writesは、チェックポイント後の最初の変更時にページ全体をWALに書く設定です。部分書き込み（torn page）対策で、offにするとWAL量は減りますがクラッシュ時にデータ破損の恐れがある、という理由まで言えるようにします。archive_commandの%p（WALファイルのパス）と%f（ファイル名）、そして成功時に0を返さないとPostgreSQLはWALを削除しない点も確認しておいてください。PostgreSQL 15以降はarchive_libraryによるモジュール方式も追加されています。

バックアップとPITRは一度通しで実行するのが最短です。

# ベースバックアップ
pg_basebackup -D /backup/base -Fp -Xs -P -h localhost -U replicator

# リストア後、PITR の指定（postgresql.conf に記述）
#   restore_command = 'cp /arch/%f %p'
#   recovery_target_time = '2026-10-20 03:00:00+09'
#   recovery_target_action = 'promote'
# そして recovery.signal を作成して起動する
touch /var/lib/postgresql/data/recovery.signal

PostgreSQL 12以降でrecovery.confが廃止され、リカバリ設定がpostgresql.confに統合されたこと、アーカイブリカバリではrecovery.signal、スタンバイではstandby.signalを置くことは、バージョン差の定番論点です。

レプリケーションは、同期レベルとWAL保持の2系統で整理します。

# プライマリ側
max_wal_senders = 10
wal_keep_size = 1GB
synchronous_commit = on
synchronous_standby_names = 'ANY 1 (standby1, standby2)'

# スタンバイ側
primary_conninfo = 'host=primary port=5432 user=replicator'
hot_standby = on
hot_standby_feedback = on
max_standby_streaming_delay = 30s

押さえるべき因果は3つです。

• synchronous_commitの値でコミット応答を返す条件が変わる（remote_writeはスタンバイのOSに書けた時点、remote_applyは適用完了まで待つ）。remote_applyはスタンバイでの読み取り整合性を強める一方、レイテンシが増える
• スタンバイでの長いクエリとプライマリのVACUUMが衝突すると、クエリがキャンセルされるか（max_standby_streaming_delay）、hot_standby_feedback = onによってプライマリ側の不要行回収が遅れる
• レプリケーションスロットは、スタンバイが受け取っていないWALを無制限に保持するため、スタンバイが停止したままだとプライマリのpg_walが溢れる

最後の点は試験でも実務でも重要で、特に論理レプリケーションスロットの放置はWAL肥大化の典型原因です。仕組みと確認コマンドはPostgreSQL WAL肥大化の原因｜レプリケーションスロットで詳しく扱っています。確認の入口はこのビューです。

SELECT slot_name, slot_type, active, restart_lsn,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS retained
  FROM pg_replication_slots;

SELECT application_name, state, sync_state,
       pg_wal_lsn_diff(sent_lsn, replay_lsn) AS replay_behind_bytes
  FROM pg_stat_replication;

独学者が不合格になる典型パターンと対策

パターン1：問題集の答えを覚えてしまう

同じ問題集を周回すると正答率は上がりますが、問題文のパターンを記憶しただけという状態になりがちです。対策は、第3段階で挙げた「全選択肢の誤答理由を書く」の徹底と、正解した問題も消去法だったかを記録することです。消去法で当たった問題は、未習得として扱います。

パターン2：パラメータ名だけ覚えて、効く仕組みを知らない

work_memを「ソート用メモリ」と暗記しても、1クエリ内の複数のソート・ハッシュノードごとに割り当てられ、同時実行数と掛け算でメモリを消費する性質を知らないと応用問題で落とします。パラメータを覚えるときは「どのレイヤに関わるか」をセットで書きます。共有メモリ（shared_buffers、wal_buffers）か、プロセス・処理単位（work_mem、maintenance_work_mem）か、プランナへのヒント（effective_cache_size、random_page_cost）か、の3分類が有効です。

パターン3：バージョン差で失点する

古い記事や旧版の教材を混ぜて学習すると、recovery.conf、wal_keep_segments、pg_stat_bgwriterのチェックポイント列など、名前が変わった項目で間違えます。対策は第1段階で決めたマニュアルのバージョンを基準にし、教材で出てきたパラメータ名をpg_settingsで実際に検索して存在を確かめることです。

SELECT name FROM pg_settings WHERE name LIKE 'wal_keep%';

存在しなければ、その教材はバージョンが古いという判断材料になります。

パターン4：性能監視を「ツールの使い方」として捉える

ビューの名前を覚えるだけでは、「この症状のとき何を見るか」という問題に答えられません。対策は、症状から確認手順を逆引きする表を自分で作ることです。

症状	最初に見るもの	次に見るもの
特定のクエリだけ遅い	EXPLAIN (ANALYZE, BUFFERS)	見積りと実測の乖離、統計情報の鮮度
全体的に遅い	pg_stat_activityのwait_event	pg_stat_databaseのヒット率、I/O統計
テーブルサイズが減らない	pg_stat_user_tables.n_dead_tup	長時間トランザクション、レプリケーションスロット
更新が止まる	pg_locksとpg_blocking_pids()	log_lock_waitsのログ
ディスクが埋まる	pg_walのサイズ	pg_replication_slots、archive_commandの失敗

パターン5：障害対応を手を動かさずに済ませる

PITRとレプリケーションは、読んだだけでは手順の前後関係が頭に残りません。pg_basebackupからrecovery.signalを置いて復旧完了までを一度自分で通すだけで、関連する設問の正答率は変わります。検証に2〜3時間かければ済むので、ここを省略しないことです。

パターン6：Oracle の知識をそのまま当てはめる

Oracle経験者が陥りやすいパターンです。UNDO表領域に相当するものがPostgreSQLにはなく古いバージョンがテーブル本体に残る（だからVACUUMが要る）、空文字とNULLの扱いが違う、といった前提のずれが失点につながります。移行時に問題になる差分はOracle PostgreSQL移行の注意点｜症状別の切り分けと対処の論点と重なるので、Oracle側の常識を一度切り離して読み直してください。

よくある質問

OSS-DB Gold は Silver を持っていなくても受験できる？

公開されている制度では、Gold試験そのものはSilver認定なしでも受験でき、Gold認定を得るにはSilver認定が必要という扱いです。Goldに合格してもSilverを持っていなければ認定されず、後からSilverに合格した時点でGold認定になります。受験順の制約はないので、同時並行で進めることも可能です。ただしGoldはSilverの知識を前提に出題されるため、Silverの範囲（SQL、基本的な運用管理）が曖昧なまま進むのは非効率です。制度の詳細と現行の条件は公式サイトで確認してください。

勉強時間はどれくらい見ておけばいい？

一律の答えはありませんが、必要な時間は「PostgreSQLの運用経験」と「性能分析の経験」で決まります。

• PostgreSQLの運用・監視を日常的にやっている → 範囲の抜け確認と問題演習が中心。比較的短期間で届く
• SQLは書けるが運用はしていない → 第2段階（検証）に最も時間が必要。ここを厚く取る
• 他DBMSの運用経験がありPostgreSQLは未経験 → 概念の読み替えに時間がかかる。VACUUM、WAL、プロセス構成から入る

週に確保できる時間を決め、第1段階に全体の2割、第2段階に5割、第3段階に3割という配分で割り振るのが目安です。「あと何時間」で考えるより、第2段階の検証テーマを何個消化したかで進捗を測るほうが実態に合います。

実務未経験でも合格できる？

PostgreSQLの実務経験がなくても、検証環境で手を動かせば到達可能な試験です。Goldの問題は、本番環境でしか経験できない固有のトラブルより、設定パラメータと内部動作の因果を問うものが中心です。

ただし条件があります。検証環境での作業を省略しないことです。実務経験がない分を埋めるのは、EXPLAINの出力を何十回も見た経験と、PITRを自分で通した経験です。実務でチューニングをしている人でも、担当範囲外（たとえばレプリケーション構築）は同じように検証で埋める必要があります。

資格だけで実務力が証明されるわけではありませんが、Goldの学習過程で身につく「症状から確認箇所を逆引きする手順」は、そのまま現場で使えます。

まとめ：次の1週間で着手すること

計画を今日決めるために、最初の1週間でやることを具体化します。

1日目：地図を作る 公式サイトで現行の出題範囲と前提バージョンを確認し、スプレッドシートに項目を転記します。列は「項目／マニュアルの章／読了／説明できる」。マニュアルのバージョンを1つ決めてブックマークします。

2日目：検証環境を立てる DockerでPostgreSQLを1台起動し、generate_seriesで数十万行のテストテーブルを作ります。pg_settingsのcontext列を見て、再起動が必要なパラメータとリロードで済むパラメータを分類します。

3〜4日目：実行計画に集中する EXPLAIN (ANALYZE, BUFFERS)を10パターン以上出力し、見積り行数と実測行数の乖離、Buffersの内訳、Sort Methodの変化を観察します。work_memを変えて一時ファイルが出るかどうかも確認します。

5日目：VACUUM を体感する 大量に更新・削除してn_dead_tupを増やし、VACUUM前後のテーブルサイズと計画を比較します。autovacuum_vacuum_scale_factorをテーブル単位で変えて、起動タイミングが変わることを確認します。

6日目：例題を解いて現在地を知る 公式サイトの例題・例題解説を解き、A（根拠つき正解）／B（消去法）／C（誤答）で分類します。BとCの数が、残りの学習量の見積りになります。

7日目：教材を確定し、週次計画に落とす B・Cの偏りを見て、不足している層（内部構造の本か、問題演習か、リファレンスか）を決めます。対応バージョンを確認してから購入します。あわせて、第2段階の残り検証テーマ（PITR、レプリケーション、ロック競合）をカレンダーに配置します。

この1週間を終えた時点で、どの分野に何時間必要かが自分の数字で見えます。Goldは教材が少ない試験ですが、公式マニュアルと検証環境という最も信頼できる教材が無償で手に入ります。問題集探しに時間を使うより、まず環境を1台立ててください。