OSS-DB Silver 独学の勉強法｜教材選びと学習ロードマップ

PostgreSQL の認定資格である OSS-DB Exam Silver は、DBA としての基礎知識を問う試験です。範囲がはっきりしていて出題範囲外のことは聞かれにくく、教材も日本語で揃っているため、独学で完結させやすい部類に入ります。

一方で「コマンドを暗記すれば受かる」と考えて学習を始めると、選択肢の絞り込みに苦労します。VACUUM が必要な理由、WAL がどの復旧手段の前提になっているか、pg_hba.conf の 1 行が誰の接続を許可しているか。こうした仕組みを踏まえた判断を問う設問が一定数含まれるためです。

この記事では、PostgreSQL の実務経験が浅い状態から独学で OSS-DB Silver を目指す前提で、教材の選び方、学習期間別のロードマップ、Docker での検証環境の作り方、得点差がつきやすい分野の攻略ポイントを整理します。試験の出題比率や受験料といった仕様は改定されることがあるため、最終確認は LPI-Japan の公式サイト（oss-db.jp）で行ってください。

📋 OSS-DB Silver の試験範囲と難易度を先に把握する

OSS-DB Exam Silver は、LPI-Japan が実施する「OSS-DB 技術者認定試験」のエントリーレベルに位置する試験です。対象 RDBMS は PostgreSQL で、出題は PostgreSQL の標準的な機能が中心になります。ベンダー固有のラッパーや商用版特有の機能ではなく、コミュニティ版 PostgreSQL の挙動を素直に押さえていく学習です。

Silver の想定レベルは「データベースシステムの運用管理ができる」というところ。SQL のチューニングや高度な監視設計は上位の Gold の領域で、Silver で問われるのは次のような内容です。

• PostgreSQL のアーキテクチャと特徴（プロセス構成、共有メモリ、MVCC の概要）
• インストールと初期設定、起動・停止、設定ファイルの読み方
• ユーザ（ロール）とデータベース・スキーマの管理、権限
• バックアップとリストア、WAL とアーカイブの基本
• 基本的な SQL（DDL/DML、トランザクション、組み込み関数、インデックス）

難易度を測るうえで効いてくるのは、問題そのものの難しさよりも選択肢の似ている度合いです。「あるコマンドの説明として正しいものを選べ」という形式では、4 つの選択肢すべてが実在するコマンドやパラメータ名で構成されます。うろ覚えだと 2 つまで絞れて外す、という事故が起きます。逆に言えば対象範囲が狭いので、精度を上げる学習を計画的にやれば独学で十分到達できます😇

出題分野と配点比率から学習量を割り振る

OSS-DB Silver の出題は、大きく次の 3 つの分野に分かれています。

分野	主な内容
一般知識	OSS-DB / PostgreSQL の概要、ライセンス、リレーショナルデータベースの一般知識、PostgreSQL のバージョンや特徴
運用管理	インストール、標準付属ツール、設定ファイル、バックアップ・リストア、基本的な運用管理
開発／SQL	SQL コマンド、組み込み関数、トランザクション、データ型、インデックス

このうち配点比率が最も大きいのは「運用管理」で、次に「開発／SQL」、「一般知識」は比率が小さいという構成です。具体的な比率（各分野が何％か）と出題数・試験時間・合格ラインは改定されることがあるため、公式サイトの出題範囲ページで確認してください。比率がわかったら、学習時間の割り振りもその比率に合わせます。

考え方はシンプルです。配点比率が大きい運用管理に学習時間の半分以上を投じます。ここは暗記だけでは対応しづらく、設定ファイルの意味やバックアップ手段の使い分けまで理解が必要なので、かけた時間が素直に点に返ってきます。開発／SQL は既存の SQL 知識との差分だけを埋めます。MySQL や Oracle での経験があるなら、PostgreSQL 固有の構文・データ型・関数名の違いに集中すれば足ります。一般知識は最後に短時間で詰めます。ライセンス（PostgreSQL License）やコミュニティの開発体制、バージョン番号の付け方など、覚えれば取れる項目が多い分野です。

⚠️ やってはいけないのは、SQL が得意だからといって SQL 分野の問題集ばかり回すことです。得点源が伸びない領域に時間を使うと、本番で運用管理の失点が効いてきます。

コマンドの暗記だけでは届かない出題パターン

独学で伸び悩む典型は、次のような出題に弱いケースです。

パターン1：設定値と挙動の因果を問う

「fsync = off に設定した場合の影響として正しいものはどれか」「shared_buffers を大きくしすぎた場合に起こりうる問題はどれか」といった設問です。パラメータ名を覚えているだけでは答えられず、書き込みがディスクに確実に到達したことを保証する仕組みや、OS のページキャッシュとの二重キャッシュといった背景の理解が必要になります。

パターン2：目的から手段を逆算させる

「サービスを停止せずにバックアップを取り、任意の時点に復旧したい。必要な設定と手順はどれか」という形式です。pg_dump / pg_dumpall / pg_basebackup / ファイルシステムレベルのコピー、それぞれの特性と前提条件（アーカイブが必要か、オンラインで可能か、復旧の粒度はどこまでか）を対応表として持っていないと選べません。

パターン3：症状から原因を推定させる

「テーブルの行を大量に削除・更新したのにディスク使用量が減らない。原因はどれか」というタイプです。MVCC によって不要行（デッドタプル）が残ること、VACUUM と VACUUM FULL の違い、autovacuum の役割を繋げて理解している必要があります。

パターン4：エラーメッセージや出力の読み取り

psql の出力や接続エラーを示して「原因はどれか」と問うものです。たとえば次のようなエラーが提示されたとします。

psql: error: connection to server at "192.168.1.10", port 5432 failed:
FATAL:  no pg_hba.conf entry for host "192.168.1.20", user "app_user",
database "appdb", no encryption

これは「サーバまでは到達しているが、その接続元・ユーザ・データベースの組み合わせを許可するエントリが pg_hba.conf に存在しない」ことを示します。listen_addresses の問題でもファイアウォールの問題でもパスワード誤りでもない、という切り分けが必要です。

💡 こうした問題に対応するには、手を動かして実際の挙動とメッセージを見ておくのが最短です。だからこそ後述の Docker 環境を早めに用意することをすすめます。

📚 独学向けの教材の選び方と組み合わせ

独学で最も失敗しやすいのが教材選びです。「評判のいい本を 3 冊買って全部読む」は非効率で、途中で挫折する確率が上がります。役割の違う教材を最小構成で組み合わせ、それぞれを使い切るのが原則です😅

書籍・問題集・公式ドキュメントの役割分担

教材は 3 種類あり、それぞれ役割が違います。混同すると「読んだのに解けない」「解けるけど理解していない」という状態に陥ります。

1. 試験対策の教科書（インプット用）：1 冊だけ

出題範囲に対応した章構成になっている教科書を 1 冊選び、それを軸にします。選ぶときの基準は次の通りです。

• 対応バージョンが古すぎないか。PostgreSQL はメジャーバージョンごとに機能が追加され、試験も一定の版に対応した内容に更新されます。書籍の対応バージョンと、受験する試験の対応バージョン（公式サイトに記載）が離れすぎていないか確認します。離れている場合は差分を公式ドキュメントで補う前提で使います。
• 出題範囲の 3 分野を網羅しているか。PostgreSQL の入門書は「SQL の書き方」に偏っていることがあり、運用管理の記述が薄いと試験対策としては使えません。目次で「バックアップ」「WAL」「VACUUM」「pg_hba.conf」「ロール」の項目があるかを見ます。
• 章末問題があるか。インプットとアウトプットが同じ本の中で往復できると効率が上がります。

同じレベルの教科書を 2 冊買うのは、重複部分を 2 回読むだけで得るものが少ないため避けます。

2. 問題集・演習（アウトプット用）

教科書とは別に、問題を大量に解く媒体が必要です。試験は選択式なので、選択肢を見て絞り込むという動作自体に慣れる必要があります。問題集を選ぶ基準は解説の厚さです。「正解は B です」だけの解説では独学では伸びません。なぜ他の選択肢が誤りなのか、関連する設定やコマンドは何かまで書かれているものを選びます。

3. PostgreSQL 公式ドキュメント（辞書）

PostgreSQL には日本語訳された公式ドキュメントがあり、独学ではこれが最も頼れる補助教材になります。ただし通読するものではありません。教科書や問題集でわからない点が出たときに、該当箇所だけを引きます✨

特に参照価値が高いのは次の章です。

• サーバの設定（postgresql.conf の各パラメータの意味とデフォルト値）
• クライアント認証（pg_hba.conf の書式と認証方式）
• ルーチンデータベース保守作業（VACUUM、統計情報の更新）
• バックアップとリストア（論理バックアップ、ファイルシステムバックアップ、継続的アーカイブと PITR）
• リファレンス（SQL コマンドと psql 等のクライアントアプリケーション）

パラメータのデフォルト値やコマンドのオプションは公式ドキュメントが最も正確です。書籍の記述とドキュメントが食い違った場合は、受験するバージョンのドキュメントを優先します。

公式サンプル問題と例題解説の使いどころ

OSS-DB の公式サイトには、サンプル問題と「例題解説」という連載形式の解説コンテンツが公開されています（掲載内容・本数は変わることがあるので現況は公式サイトで確認してください）。独学者にとっては最重要の無料教材です。理由は 2 つあります。

理由1：問い方の癖がわかる

市販の問題集は、実際の出題形式とニュアンスがずれていることがあります。公式が出しているサンプル問題は、選択肢の作り方、聞かれ方の粒度、どの程度の細かさまで踏み込むかという試験の温度感を示してくれます。

理由2：解説が範囲の重要度を示している

例題解説では、単に正解を示すだけでなく「この分野はこういう観点で問われる」という説明が入ります。教科書のどこを重点的にやるべきかの判断材料になります。

使うタイミングは次の 3 回に分けると効果的です。

1. 学習開始直後（1 回目）。解けなくてかまいません。ゴールの形と難易度感を掴むために目を通します。
2. 教科書を 1 周した直後（2 回目）。実際に解いて、分野ごとの弱点を洗い出します。間違えた問題に対応する教科書の章に戻ります。
3. 試験直前（3 回目）。最終確認です。ここで間違える問題は本番でも間違える可能性が高いので、優先的に潰します。

💡 1 回目で解いて答えを覚えてしまうと 2 回目・3 回目の診断精度が落ちるため、初回は眺める程度に留めます。

有料の問題演習サービスを追加すべきかの判断基準

Web 上の問題演習サービスや模擬試験を追加すべきかは、状況によります。判断基準を明確にしておきます。

追加を検討したほうがよいケース

書籍の章末問題と公式サンプル問題をやり切ってしまい、演習量が足りていないと感じる場合。特に「知識はあるのに選択肢で迷う」タイプの人は、単純に問題数が必要です。通勤時間などスキマ時間で学習したい場合も向いています。スマートフォンで解ける形式は書籍より継続しやすい。制限時間内に全問解く本番形式の練習をしたい場合も追加の価値があります。時間配分の感覚は模擬試験でしか得られません。

追加しなくてよいケース

教科書をまだ 1 周もしていない段階では、問題数を増やしても知識の土台がないので解説を読んでも定着しません。業務で PostgreSQL の運用に日常的に関わっており、あとは試験特有の用語を合わせるだけ、という場合も不要です。

選ぶときに確認すること

対応している試験バージョンが現行かどうか。古い版のままのサービスは、改定で削除された内容を学習してしまうリスクがあります。解説が付いているかも確認してください。正誤判定だけのサービスは独学では使いにくい。間違えた問題だけを再出題できるかどうかは、復習効率を大きく左右します。

⚠️ 演習サービスを使う場合も、教科書 1 冊は必須です。演習だけで合格を狙うと、知識が問題単位でバラバラに入り、少し角度を変えた設問に対応できなくなります。

🗺️ 学習ロードマップ（未経験ルートと経験者ルート）

学習計画は、PostgreSQL の実務経験の有無で大きく変わります。ここでは 2 パターンのロードマップを示します。週あたりの学習時間は、平日 1 時間・休日 2〜3 時間程度を想定した組み立てです。自分の確保できる時間に応じて週数を伸縮させてください。

PostgreSQL 未経験から始める8週間プラン

MySQL や RDS を少し触った程度で、PostgreSQL の運用管理は未経験、という前提のプランです。

第1〜2週：環境構築とアーキテクチャの理解

最初に手を動かせる環境を作ります（次章の Docker 構成を使用）。環境ができたら、教科書のアーキテクチャの章を読みながら実際に確認します。

• PostgreSQL の起動・停止（pg_ctl、サービス経由）
• プロセス構成の確認（ps でバックエンドプロセスやバックグラウンドワーカーを見る）
• psql の基本操作とメタコマンド（\l \dt \d \du \dn \timing など）
• データベースクラスタのディレクトリ構成（PGDATA の中身、base、pg_wal、global）
• initdb が何をするか

💡 この段階では暗記しようとせず、「どこに何があるか」の地図を作ることに集中します。

第3〜4週：SQL と開発分野

教科書の SQL 章を進めます。すでに SQL が書ける人は、PostgreSQL 固有の部分に絞ると時間が短縮できます。

• データ型（serial / identity、numeric、text、配列、JSON/JSONB、日付時刻型）
• SELECT の各句、結合の種類、サブクエリ、集約とウィンドウ関数の基本
• トランザクションと分離レベル、SAVEPOINT
• インデックスの種類（B-tree、Hash、GiST、GIN、BRIN）とそれぞれの用途
• EXPLAIN の基本的な読み方
• 制約（PRIMARY KEY、UNIQUE、FOREIGN KEY、CHECK、NOT NULL）とその挙動

手元の環境で実行して出力を見ます。特にトランザクションは、ターミナルを 2 枚開いて別セッションから同じ行を更新してみると、ロック待ちの挙動が体感できます👀

第5〜6週：運用管理（最重要）

配点比率が最も大きい分野です。ここに最も時間をかけます。

• 設定ファイル（postgresql.conf、pg_hba.conf）の書式と主要パラメータ
• 設定変更の反映方法（リロードで済むもの／再起動が必要なもの、ALTER SYSTEM、pg_ctl reload）
• ロールと権限（CREATE ROLE、GRANT/REVOKE、ロールの継承、PUBLIC）
• データベース・スキーマ・テーブル空間の管理
• バックアップ／リストア（pg_dump、pg_dumpall、pg_restore、pg_basebackup）
• WAL とアーカイブ、PITR の概念
• VACUUM と ANALYZE、autovacuum
• 標準付属ツール（createdb、dropdb、createuser、vacuumdb、reindexdb、pg_ctl、psql）
• ログ設定と統計情報ビュー（pg_stat_activity など）

各項目で「何のための機能か」「使えない状況はどういうときか」を言葉にできるようにします。ここが曖昧だと前述のパターン2・3の問題で落とします😇

第7週：問題演習と弱点補強

公式サンプル問題と問題集を通しで解き、分野ごとの正答率を記録します。正答率が低い分野に対応する教科書の章に戻り、該当箇所を読み直したうえで再度解きます。この「戻る」作業が独学の質を決めます。

第8週：仕上げ

後述の「試験1〜2週間前の仕上げ」に従って、暗記項目の詰めと本番形式の練習を行います。

業務でPostgreSQLを触っている人の3週間プラン

業務で PostgreSQL のアプリケーション開発や運用に関わっており、psql で作業したことがある人向けの短縮プランです。

第1週：試験範囲との差分洗い出し

まず公式サンプル問題を解いて、どこが弱いかを特定します。実務経験者が落とすのは、たいてい次のいずれかです。

一つは普段自分が触らない領域。バックアップは基盤チームが担当していて触ったことがない、権限設計を自分で設計したことがない、といったケースです。

もう一つはマネージドサービス前提で覚えている領域。RDS / Aurora では postgresql.conf を直接編集せずパラメータグループで設定するため、設定ファイルの書式や反映方法、pg_ctl の操作、initdb、OS ユーザとしての運用が抜けやすい。RDS ではスーパーユーザ権限が制限されるため、コミュニティ版のスーパーユーザ挙動の理解も不足しがちです💦

あとは用語の対応関係です。普段の呼び方と試験用語がずれている項目が意外に多い。

差分が見えたら、その章だけを教科書で読みます。全章を通読する必要はありません。

第2週：運用管理の穴埋めと SQL の PostgreSQL 固有部分

第1週で洗い出した弱点を潰します。特にマネージドサービス中心の人は、以下を手元の Docker 環境で 1 回は実行しておくと効果が大きいです。

• initdb でクラスタを作る
• pg_hba.conf を書き換えて reload し、認証方式を切り替える
• pg_basebackup でベースバックアップを取る
• WAL アーカイブを有効化して、アーカイブファイルが出力されるのを確認する
• pg_dump の各形式（plain / custom / directory / tar）を試し、pg_restore の挙動を見る

💡 「パラメータグループで設定していた項目が、設定ファイルではどう書かれるのか」を手で確認しておくと、設問の前提がすぐ読めるようになります。

第3週：演習と仕上げ

問題演習を繰り返し、正答率が安定しない分野だけ公式ドキュメントで確認します。実務経験者は「実務ではこうする」という思い込みで選択肢を選んで外すことがあるため、試験は標準的なコミュニティ版 PostgreSQL の挙動を問うという前提を意識して解きます。

🐳 手を動かす検証環境をDockerで用意する

独学で最も効く投資は、いつでも壊せる PostgreSQL 環境を持つことです。Docker があれば数分で用意できます。

最小構成は次のコマンドだけです。

docker run --name pg-study \
  -e POSTGRES_PASSWORD=studypass \
  -e POSTGRES_DB=studydb \
  -p 5432:5432 \
  -d postgres:17

タグのバージョンは、受験する試験が対応している PostgreSQL バージョンに合わせます（対応バージョンは公式サイトで確認）。接続は次のようにします。

docker exec -it pg-study psql -U postgres -d studydb

ただし、試験対策としてはこれだけでは足りません。設定ファイルを編集したりアーカイブ先を確認したりする必要があるため、データとログを永続化した構成にしておきます。

# docker-compose.yml
services:
  db:
    image: postgres:17
    container_name: pg-study
    environment:
      POSTGRES_PASSWORD: studypass
      POSTGRES_DB: studydb
      # initdb 時のオプション（照合順序を試したい場合など）
      POSTGRES_INITDB_ARGS: "--encoding=UTF8"
    ports:
      - "5432:5432"
    volumes:
      - ./pgdata:/var/lib/postgresql/data   # PGDATA を手元で見る
      - ./archive:/mnt/archive              # WAL アーカイブの出力先
    # ログを標準出力ではなくファイルにも出す設定を試す場合はここでコマンド上書き

起動後、PGDATA の中身をホスト側から直接確認できます。ディレクトリ構成を目で見ておくと、「pg_wal に何が入るか」「base の下のディレクトリは何を表すか」といった設問が具体的に理解できます✨

docker compose up -d
sudo ls -l ./pgdata
sudo ls -l ./pgdata/pg_wal

設定ファイルの編集と反映も試しておきます。

# コンテナ内に入る
docker compose exec db bash

# 現在の設定値を確認（psql から）
psql -U postgres -c "SHOW shared_buffers;"
psql -U postgres -c "SELECT name, setting, unit, context FROM pg_settings WHERE name IN ('shared_buffers','work_mem','log_min_duration_statement');"

💡 ここで pg_settings の context 列を見る習慣をつけてください。postmaster なら再起動が必要、sighup ならリロードで反映、user ならセッション単位で変更可能。この反映タイミングの区別がそのまま試験範囲です。

-- 設定を書き換えてリロードで反映されるか確認する
ALTER SYSTEM SET log_min_duration_statement = '200ms';
SELECT pg_reload_conf();
SHOW log_min_duration_statement;

ALTER SYSTEM は postgresql.auto.conf に書き込まれます。ホスト側から pgdata/postgresql.auto.conf を開けば、実際にその内容が追記されていることが確認できます。設定ファイルの優先順位（postgresql.conf → postgresql.auto.conf → 起動オプション → セッション設定）を理解する材料になります。

WAL アーカイブの確認も、この環境ならできます。

-- アーカイブを有効にする（要再起動のパラメータを含む）
ALTER SYSTEM SET wal_level = 'replica';
ALTER SYSTEM SET archive_mode = 'on';
ALTER SYSTEM SET archive_command = 'test ! -f /mnt/archive/%f && cp %p /mnt/archive/%f';

docker compose restart db

# WAL を強制的に切り替えてアーカイブ出力を確認
docker compose exec db psql -U postgres -c "SELECT pg_switch_wal();"
ls -l ./archive

archive_command の %p（アーカイブすべき WAL のパス）と %f（ファイル名）の意味、test ! -f で既存ファイルを上書きしないようにする定型、archive_mode が再起動を要するパラメータであること。これらはすべて試験で問われうるポイントで、1 回手で動かせば記憶に残ります💪

複数セッションでのロックの挙動も試せます。ターミナルを 2 枚開いて、それぞれ別の psql を起動します。

-- セッションA
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
-- COMMIT せずに放置

-- セッションB
UPDATE accounts SET balance = balance + 100 WHERE id = 1;  -- 待たされる

待たされている間に 3 枚目のセッションから状況を見ます。

SELECT pid, state, wait_event_type, wait_event, left(query, 50) AS query
FROM pg_stat_activity
WHERE datname = 'studydb';

SELECT locktype, relation::regclass, mode, granted, pid
FROM pg_locks
WHERE NOT granted;

行レベルロックの待ち方、pg_stat_activity の wait_event_type、pg_locks の読み方が一度で腹に落ちます🎉

🎯 得点差がつく分野の攻略ポイント

ここからは、独学者が落としやすく、かつ配点の期待値が高い分野を掘り下げます。共通するのは、仕組みを理解すると複数の設問が同時に解けるようになる領域だという点です。

MVCCとVACUUMの不要行が溜まる仕組みから理解する

PostgreSQL の MVCC（多版型同時実行制御）は、Silver の学習で最初に理解すべき仕組みです。ここが分かると、VACUUM、autovacuum、テーブル肥大化、トランザクション分離レベル、pg_stat_user_tables の読み方が一本の線で繋がります。

押さえるべき挙動

PostgreSQL の UPDATE は「行を書き換える」のではなく、新しいバージョンの行を追加し、古いバージョンを不要（デッド）としてマークする動作になります。DELETE も同様に、物理的には行を消さず「削除された」という印を付けるだけです。

なぜこうするのか。読み取りを行うトランザクションが古いバージョンを参照している可能性があるため、いま消してしまうとそのトランザクションが読めなくなります。PostgreSQL は行に「どのトランザクションが挿入したか（xmin）」「どのトランザクションが削除／更新したか（xmax）」の情報を持たせ、各トランザクションは自分のスナップショットから見て有効なバージョンだけを見ます。これにより、読み取りが書き込みをブロックせず、書き込みが読み取りをブロックしないという性質が得られます。この点は Oracle のように UNDO 領域へ旧値を退避する方式との大きな違いで、「古い行がテーブル本体に残る」という PostgreSQL 固有の副作用に繋がります。

その結果として起きること

• DELETE したのにファイルサイズが減らない
• 更新の多いテーブルが徐々に膨らむ（テーブル肥大化）
• 不要行が多いとシーケンシャルスキャンで読むページ数が増え、性能が落ちる

これを回収するのが VACUUM です。

VACUUM と VACUUM FULL の違い（頻出）

	VACUUM	VACUUM FULL
不要領域の扱い	再利用可能な空き領域として登録（ファイルサイズは基本的に縮まない）	テーブルを作り直して詰め直す（ファイルサイズが縮む）
ロック	参照・更新と並行実行できる	テーブルへの排他ロックを取得し、参照も更新もブロックする
追加ディスク	ほぼ不要	新しいテーブルを作るため、元のテーブルとほぼ同量の空き容量が必要
運用上の位置づけ	日常的に（autovacuum が自動実行）	特殊なケースのみ、計画停止時間内に実施

⚠️ 「ディスク使用量を減らしたい」という設問に対して VACUUM を選ぶと誤りになる、というのが典型的な引っかけです。ただし同時に、本番稼働中に VACUUM FULL を安易に打つべきではないという運用判断も押さえておきます。

autovacuum の役割

通常運用では autovacuum が自動的に VACUUM と ANALYZE を実行します。押さえるべきパラメータは次のあたりです。

SELECT name, setting FROM pg_settings WHERE name LIKE 'autovacuum%';

• autovacuum：有効／無効
• autovacuum_vacuum_threshold と autovacuum_vacuum_scale_factor：更新・削除された行数がこの閾値（固定値＋テーブル行数×係数）を超えると VACUUM が走る
• autovacuum_analyze_threshold / autovacuum_analyze_scale_factor：ANALYZE の閾値
• autovacuum_max_workers：同時に動くワーカー数

大きなテーブルでは scale_factor が効いて閾値が非常に大きくなり、なかなか autovacuum が走らない。この運用上の落とし穴も理解しておくと、実務にも直結します😇

トランザクション ID の周回（freeze）

VACUUM のもう一つの重要な役割が、トランザクション ID の周回（wraparound）防止です。トランザクション ID は有限なので、古い行の ID を「凍結（freeze）」して比較対象から外す処理が必要になります。これを放置すると、PostgreSQL は書き込みを止めて保護モードに入ります。Silver では「VACUUM には領域回収以外の役割がある」という点を押さえておけば足りますが、VACUUM FREEZE、autovacuum_freeze_max_age という用語は見ておきます。

ANALYZE との区別

VACUUM は不要領域の回収、ANALYZE はプランナが使う統計情報の収集です。役割が全く違うのに混同しやすい部分です。統計情報が古いと、オプティマイザが行数を誤って見積もり、インデックスを使うべき場面でシーケンシャルスキャンを選ぶ（あるいは逆）といった実行計画のミスが起きます。大量データを投入した直後は統計が追いついていないため明示的に ANALYZE を打つ、という判断基準はそのまま実務の作法でもあります。

-- 不要行の溜まり具合と最終 VACUUM 時刻を確認する
SELECT relname, n_live_tup, n_dead_tup,
       last_vacuum, last_autovacuum, last_analyze, last_autoanalyze
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC;

✅ このビューを一度見ておくと、「不要行の量をどう確認するか」という設問に迷わなくなります。

WAL・アーカイブとバックアップ／リカバリ手段の対応関係

運用管理分野で最も配点が期待でき、かつ独学者が整理しきれないのがここです。個々のコマンドを覚える前に、手段と目的の対応表を作ってしまうのが早い。

まず WAL の役割を理解する

WAL（Write Ahead Logging）は、データファイルを書き換える前に「これから何をするか」をログに書き、そのログをディスクに確実に書き込んでからコミットを完了させる仕組みです。

なぜこうするのか。データファイルへの変更をコミットのたびにディスクへ書き出すと、ランダム書き込みが大量に発生して遅くなります。WAL はシーケンシャルな追記なので高速です。コミット時には WAL だけを確実に書き、データファイルへの反映は後からまとめて行う（チェックポイント）ことで、性能と耐久性を両立させています。

この構造から、次のことが導かれます。

• クラッシュリカバリが可能。異常終了しても、最後のチェックポイント以降の WAL を再適用すれば一貫した状態に戻せる
• ⚠️ fsync = off は危険。WAL がディスクに到達した保証がなくなるため、クラッシュ時にデータが失われうる
• チェックポイントは重い処理。溜まったダーティページを一気に書き出すため I/O が跳ねる。checkpoint_timeout や max_wal_size で頻度が決まる
• WAL を溜めておけば任意時点に復旧できる。これが PITR（Point-In-Time Recovery）の原理

wal_level と archive_mode

wal_level は WAL にどれだけの情報を記録するかを決めます。minimal ではクラッシュリカバリに必要な最小限のみで、アーカイブやレプリケーションには不足します。replica でアーカイブ・スタンバイが可能になり、logical で論理レプリケーションに対応します。

archive_mode と archive_command は、完了した WAL セグメントを外部に退避する設定です。これがないと WAL は再利用時に上書きされてしまい、過去の時点に戻れません。

バックアップ手段の対応表

手段	種別	オンライン可否	復旧の粒度	前提・特徴
pg_dump	論理	可	バックアップ取得時点	データベース単位。テーブル単位の抽出や別バージョンへの復元が可能。ロール・テーブル空間などクラスタ全体の情報は含まれない
pg_dumpall	論理	可	バックアップ取得時点	クラスタ全体。ロールやグローバルオブジェクトを含む。出力はプレーンテキストのみ
pg_basebackup	物理	可	ベースバックアップ時点（WAL があれば任意時点）	クラスタ全体のファイルコピー。PITR やスタンバイ構築の起点
ファイルシステムのコピー	物理	原則不可（整合性のある方法が必要）	コピー時点	サーバ停止中のコールドバックアップ、または低レベル API と WAL アーカイブを併用する方法が必要

判断基準として覚えること

• 任意の時点に戻したい（PITR）なら、物理バックアップ（pg_basebackup 等）＋ WAL アーカイブが必須。論理バックアップだけでは不可能
• 特定のテーブルだけ戻したいなら論理バックアップ（pg_dump）。物理バックアップからテーブル単位の復元はできない
• 別のメジャーバージョンに移したいなら論理バックアップ。物理ファイルはバージョン間で互換性がない
• クラスタ全体を丸ごとなら pg_dumpall または pg_basebackup

pg_dump の形式

# プレーンテキスト（SQL スクリプト）: psql で復元
pg_dump -U postgres -d studydb -f studydb.sql

# カスタム形式: pg_restore で復元、並列復元や選択的復元が可能
pg_dump -U postgres -d studydb -Fc -f studydb.dump

# ディレクトリ形式: 並列ダンプが可能
pg_dump -U postgres -d studydb -Fd -j 4 -f studydb_dir

💡 形式によって復元に使うコマンドが変わる（プレーンは psql、それ以外は pg_restore）という点が頻出です。また、カスタム形式・ディレクトリ形式では復元時にテーブルを選んだり、インデックスだけ後回しにしたりできます。

# カスタム形式から特定テーブルだけ復元
pg_restore -U postgres -d studydb -t accounts studydb.dump

# 中身の目次だけ確認
pg_restore -l studydb.dump

PITR の流れ

手順の概略を言葉で言えるようにしておきます。

1. wal_level を replica 以上にし、archive_mode = on、archive_command を設定してアーカイブを有効化
2. pg_basebackup でベースバックアップを取得
3. 障害発生後、ベースバックアップを展開
4. リカバリ設定（復旧に使う WAL の取得方法 restore_command、戻したい時点 recovery_target_time など）を記述し、リカバリ signal ファイルを置く
5. サーバを起動すると WAL の適用が始まり、指定した時点まで復旧して昇格する

⚠️ リカバリ設定の書き方はバージョンで変わっています。PostgreSQL 12 より前は recovery.conf という専用ファイルを使いましたが、12 以降は postgresql.conf（または postgresql.auto.conf）に書き、recovery.signal / standby.signal の有無でモードを判別する方式になりました。書籍が古い場合はここが食い違うので、受験するバージョンのドキュメントで確認してください。

pg_hba.confとロール・権限の読み解き方

設定ファイルの読み取りと権限は、読めれば取れる領域なので確実に得点源にします。

pg_hba.conf の書式

# TYPE  DATABASE        USER            ADDRESS                 METHOD
local   all             all                                     peer
host    all             all             127.0.0.1/32            scram-sha-256
host    appdb           app_user        192.168.1.0/24          scram-sha-256
host    all             all             0.0.0.0/0               reject

押さえるポイントは 3 つです。

1. 上から順に評価され、最初に一致した行が使われる

一致した行の認証方式で認証が行われ、失敗しても後続の行は評価されません。上の例で 0.0.0.0/0 の reject を先頭に置いてしまうと、すべての接続が拒否されます。「順序を入れ替えたらどうなるか」という設問が作りやすい部分です😱

2. TYPE の違い

• local：Unix ドメインソケット経由の接続
• host：TCP/IP 接続（SSL 有無を問わない）
• hostssl：SSL を使った TCP/IP 接続のみ
• hostnossl：SSL を使わない TCP/IP 接続のみ

local の行には ADDRESS を書かない、という点も含めて覚えます。

3. 主な認証方式

• trust：無条件で許可。パスワード不要。検証環境以外では使わない
• reject：無条件で拒否
• scram-sha-256：パスワードを SCRAM-SHA-256 で検証。現在の推奨
• md5：パスワードを MD5 ハッシュで検証。古い方式
• peer：OS のユーザ名とデータベースユーザ名が一致するかで判定（local のみ）
• ident：ident サーバに問い合わせる（TCP/IP 接続用）
• cert：クライアント証明書で認証

peer は local 接続でのみ使える、という制約が問われます。

変更の反映

pg_hba.conf の変更は再起動不要で、リロードで反映されます。

docker compose exec db psql -U postgres -c "SELECT pg_reload_conf();"
# または
docker compose exec db pg_ctl reload -D /var/lib/postgresql/data

現在読み込まれているルールを確認するビューもあります。

SELECT line_number, type, database, user_name, address, auth_method, error
FROM pg_hba_file_rules;

ロールと権限

PostgreSQL では「ユーザ」と「グループ」の区別がなく、どちらもロールとして扱われます。LOGIN 属性を持つロールがログインでき、いわゆる「ユーザ」に相当します。

-- ログインできるロール
CREATE ROLE app_user LOGIN PASSWORD 'secret';
-- 上と実質同じ（CREATE USER は LOGIN 付きの CREATE ROLE）
CREATE USER app_user2 PASSWORD 'secret';

-- ログインできないロール（グループとして使う）
CREATE ROLE readonly;

-- グループロールのメンバにする
GRANT readonly TO app_user;

主なロール属性は SUPERUSER、CREATEDB、CREATEROLE、LOGIN、REPLICATION、CONNECTION LIMIT、VALID UNTIL。それぞれ何ができるようになるかを押さえます。SUPERUSER がすべての権限チェックを迂回する点は特に重要です。

オブジェクト権限

-- スキーマ内の既存テーブルすべてに SELECT 権限
GRANT SELECT ON ALL TABLES IN SCHEMA public TO readonly;

-- 今後作られるテーブルにも自動で付与
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO readonly;

-- スキーマそのものへのアクセス権（これがないとテーブルに触れない）
GRANT USAGE ON SCHEMA public TO readonly;

⚠️ GRANT SELECT ON ALL TABLES は実行した時点のテーブルにしか効かない、というのが引っかかりどころです。今後作成されるテーブルには ALTER DEFAULT PRIVILEGES が必要です。

権限の確認方法も押さえます。

-- psql のメタコマンド
\dp accounts
\du

-- 関数で確認
SELECT has_table_privilege('readonly', 'accounts', 'SELECT');

⚠️ public スキーマのデフォルト権限は PostgreSQL 15 で変更されました。それ以前は全ユーザが public スキーマにオブジェクトを作成できましたが、15 以降はデータベース所有者のみです。バージョン差が出る箇所なので、対応バージョンを意識して覚えます。

📝 試験1〜2週間前の仕上げと受験申込・当日の流れ

直前期は新しい教材に手を出さず、取れる問題を確実に取る方向に振り切ります。

やること

1. 間違えた問題だけを解き直す。問題集を頭から解き直すのは時間の無駄です。過去に間違えた問題に絞り、正解した理由まで説明できるか確認します。
2. 暗記項目の詰め込み。以下は覚えれば取れるので、直前に一気に固めます。
   • 標準付属ツールの名前と用途（createdb、dropdb、createuser、dropuser、vacuumdb、reindexdb、clusterdb、pg_ctl、pg_isready、initdb）
   • psql のメタコマンド一覧
   • 主要パラメータのデフォルト値と反映タイミング（再起動／リロード）
   • pg_hba.conf の認証方式一覧
   • データ型の名前と範囲
   • インデックスの種類と適した用途
   • pg_dump のオプションと出力形式
3. 本番形式で 1 回通す。制限時間内に全問解き切る練習を 1 回はやります。時間が足りないタイプなのか、余るタイプなのかを知っておくと当日の配分を決められます。
4. 公式サンプル問題の最終確認。ここで間違える問題は優先度最高です。

やらないこと

• 新しい問題集を買う
• Gold の範囲に手を出す
• EXPLAIN の詳細な読み方など、Silver の範囲を超える深掘り

受験申込と当日の流れ

OSS-DB の試験は、ピアソン VUE を通じて申し込み、全国のテストセンターで受験する CBT（コンピュータベーストテスト）形式です。オンライン受験に対応しているかどうか、受験料、当日必要な本人確認書類、再受験のルール（同一試験を再受験する際の待機期間など）は変更されることがあるため、ピアソン VUE と LPI-Japan の公式サイトで最新情報を確認してください。

一般的な流れとして押さえておく点は次の通りです。

• 事前に受験者アカウントの作成が必要。試験当日ではなく、余裕をもって作っておきます
• 本人確認書類が必要。氏名の表記がアカウント登録名と一致しているかを事前に確認します。ここが合わないと受験できないことがあります
• CBT なので結果は受験後すぐわかります
• 認定を受けるには、認定ポリシーへの同意など所定の手続きが必要な場合があります。合格後の流れも公式サイトで確認します

当日の解き方

• 💡 迷う問題は印を付けて先に進み、最後に戻る。1 問に固執しないことが最優先です
• 「明らかに違う選択肢を消す」から入る。4 択のうち 2 つを消せれば、知識が曖昧でも期待値が上がります
• 複数選択の問題では、選ぶ個数の指定を読み飛ばさないよう注意します

❓ 独学でつまずきやすい点とよくある質問

Q. PostgreSQL をインストールしたことがなくても受かるか

範囲の暗記だけで合格する人もいますが、効率は落ちます。特に運用管理分野は、設定ファイルを見たことがあるかどうかで理解の速度が変わります。Docker があれば導入は数分なので、環境は作ることをすすめます。

Q. MySQL の経験は活きるか

SQL の基本文法とリレーショナルデータベースの一般知識は活きます。ただし、次の点は PostgreSQL 固有なので学び直しが必要です。

• MVCC の実装方式（PostgreSQL は追記型で、不要行を VACUUM で回収する）
• ストレージエンジンの概念がない（InnoDB / MyISAM のような選択はない）
• ロール／スキーマの体系（MySQL の「データベース」と PostgreSQL の「スキーマ」は使い分けが違う）
• データ型と関数名（AUTO_INCREMENT ではなく serial / GENERATED AS IDENTITY、LIMIT/OFFSET の扱い、文字列連結は ||）
• バックアップツール（mysqldump と pg_dump はオプションが異なる）

💡 MySQL の知識をそのまま当てはめると外す設問があるので、「違いの一覧」を自分で作っておくと有効です。

Q. RDS / Aurora しか触っていない場合の注意点

マネージドサービスでは触れない領域がそのまま弱点になります。具体的には次の項目です。

• initdb によるクラスタ作成、PGDATA のディレクトリ構成
• postgresql.conf / pg_hba.conf の直接編集と反映方法
• pg_ctl による起動・停止・リロード
• OS ユーザ（postgres）としての運用、peer 認証
• スーパーユーザ権限の完全な挙動（RDS では rds_superuser などに制限されている）
• archive_command を自分で書くこと（RDS では自動バックアップが抽象化されている）

⚠️ Aurora PostgreSQL はストレージ層の実装がコミュニティ版と異なり、WAL の扱いやバックアップの仕組みも独自です。試験で問われるのはコミュニティ版 PostgreSQL の挙動なので、Aurora の知識で答えると外れることがあります。「Aurora ではこうだが、コミュニティ版ではこうだ」と切り分けて覚えます。

Q. どのバージョンで勉強すればよいか

試験には対応バージョンが定められており、改定されます。公式サイトで現行の対応バージョンを確認し、それに合わせて検証環境と教材を選びます。バージョン差が出やすい代表的な項目は以下です。

• リカバリ設定の方式（12 で recovery.conf が廃止）
• public スキーマのデフォルト権限（15 で変更）
• パラレルクエリやパーティショニング関連機能の充実度
• 認証方式の推奨（md5 から scram-sha-256 へ）

Q. 暗記でよい範囲と理解が必要な範囲の線引きは

暗記で足りる	理解が必要
ツール名と用途	MVCC と VACUUM の関係
psql のメタコマンド	WAL とバックアップ／リカバリ手段の対応
データ型の名前	pg_hba.conf の評価順序と認証方式の制約
認証方式の名前	トランザクション分離レベルの差異
主要パラメータ名	パラメータの反映タイミングと理由
ライセンス・コミュニティ情報	インデックスの種類と選択基準

💡 右列は 1 つ理解すると複数問が解ける領域です。時間が限られているなら右列を優先します。

Q. 学習が続かない場合の対処

独学で最も多い失敗は、教科書の途中で止まることです。対策として次の 2 つが効きます。

1. 最初に受験日を決めて申し込む。締切がない学習は伸び続けます😅
2. 読む前に手を動かす順序にする。章を読んでから試すのではなく、まず Docker で動かしてから該当章を読むと、内容が「答え合わせ」になって頭に入りやすくなります。

Q. Silver の次はどうするか

OSS-DB Gold は、パフォーマンスチューニング、運用管理の応用、障害対応といったより実務的な範囲を扱います。Silver で身につけた MVCC / WAL / VACUUM の理解はそのまま土台になります。Silver 合格直後は知識が新鮮なので、Gold を目指すならこのタイミングで続けると効率がよいです。認定の有効期限や上位認定の要件（Gold 認定に Silver 合格が必要かなど）は公式サイトで確認してください。

独学で合格するための要点をまとめると、教科書 1 冊＋問題演習＋公式ドキュメント（辞書として）＋Docker 環境という最小構成を作り、配点比率の大きい運用管理に時間を集中させ、MVCC / WAL / 認証・権限の 3 つは仕組みから理解する。この方針で組み立てれば、スクールを使わなくても到達できる試験です。まずは受験日を決めて、Docker で PostgreSQL を起動することから始めてください🚀