実機演習テキストƒ†クカン実機...ファイル16384(mydb)、16390(mydb2)のファイルサイズを確認します。...

COPYRIGHT FUJITSU LIMITED 2020

テクニカルカンファレンス 2020

「実習で押さえる PostgreSQL のポイント」

～OSS-DB Gold 試験対策～

実機演習テキスト

第 1.0 版

2020 年 12 月

富士通株式会社


[本資料利用上の注意]

本資料は、富士通株式会社（以下富士通）が、テクニカルカンファレンス 2020 PostgreSQL トレー

ニングセションに申し込まれ、受講される方のために提供しているものです。

受講される方が、本資料をご利用する場合、以下に記載される注意事項をお読みいただき、ご同意い

ただいた上で、ご利用ください。

⚫ 知的財産権について

(1) 本資料の著作権は、富士通に帰属します。

(2) 本資料は、掲記のトレーニングを受講されるためにのみ利用できます。その他の目的で利用する

ことはできません。

(3) 本資料およびその内容については、第三者に開示、提供することを禁じます。

(4) 本資料およびその内容について、営利、非営利を問わず、許可なく複製、改変、送信、販売等

することを禁じます。

(5) 本資料で使用されている商標、製品名またはロゴ等（以下商標）は、富士通または第三者の

登録商標または商標です。

(6) 富士通は、本資料に関して富士通または第三者の著作権、商標権その他いかなる権利も許

諾するものではありません。

⚫ 免責事項について

(1) 本資料については、富士通はその正確性または完全性等についていかなる保証も行うものでは

ありません。

(2) 受講される方は、星領およびその内容に関連して第三者と紛争等を生じた場合であっても、自

ら当該紛争等の解決にあたるものとします。

[登録商標/商標]

⚫ Microsoft、MS、MS-DOS、Windows、Windows Server は、米国 Microsoft

Corporation の米国およびその他の国における登録商標または商標です。

⚫ PostgreSQL は PostgreSQL の米国およびその他の国における商標です。

⚫ そのほか、本資料に記載されている会社名および製品名は、それぞれ各社の商標または登録商標

です。

⚫ 本テキストに記載されている会社名、システム名、製品名などには必ずしも商標表示（TM ・®）

を付記しておりません。


目次

1 運用管理........................................................................................ 2

1-1 課題 1 ..................................................................................... 2

2 性能監視....................................................................................... 14

2-1 課題 2 .................................................................................... 14

2-2 課題 3 .................................................................................... 20

3 パフォーマンスチューニング........................................................................ 26

3-1 課題 4 .................................................................................... 26


1

はじめに

⚫ 本教材は PostgreSQL を使用して、各種操作の演習を行います。

⚫ 実習の前に[実機演習環境構築手順書]の手順に従ってお手持ちの PC に PostgreSQL を

インストースし、環境を構築したのち、演習を行ってください。

⚫ 演習は、環境構築で登録した実習用のユーザーuser01 で Windows にログインして実施してくだ

さい。


2

1 運用管理

1-1 課題 1

演習課題１

PostgreSQL は追記型アーキテクチャーを採用しています。データを更新する際は元のデータを更新する

のではなく、元のデータはそのままに更新後のデータを追記します。そのため、データの追加や削除を繰り返

すと不要な領域がたまっていきます。この不要領域を手動で回収する操作を行います。

対象のテーブル：「mydb」

使用するコマンド：VACUUM コマンド

ここでは、データベースクラスタ「inst01」を作成し、操作を行います。

oid2name コマンドを使用してデータベースとテーブルのデータファイルを特定し、テーブルに対して更新/

削除された行の切り詰めを行うと、テーブルのファイルサイズが減少することを確認します。

【事前準備】

(1) データベースクラスタの作成、サンプルデータの挿入

① OS に Users 権限のユーザー（user01）でログインし、コマンドプロンプトを起動します。

② C:\database\traning_data_gold\inst01 配下にデータベースクラスタを作成します。

コマンドプロンプトで以下のコマンドを実行します。

initdb -D C:\database\traning_data_gold\inst01 --locale="C" --encoding=UTF8

–U postgres

【実行結果】


3

データベースクラスタが正常に作成されます。

③ データベースサーバの postgresql.conf の設定を変更します。

※編集をする前に postgresql.conf ファイルをコピーしておきます。（1-1 の課題終了後、

postgresql.conf を元の設定に戻す際に使用します）

以下のファイルをテキストエディタで開きます。

C:\database\traning_data_gold\inst01\postgresql.conf

postgresql.conf のパラメーターを以下のとおり変更し、保存します。

【変更内容】

変更前変更後

#port = 5432 port = 5432

#autovacuum = on autovacuum = off

port：

接続するポートを指定します。5432 ポートをすでに使用している場合は、未使用のポート番号を

指定します。

※ポート番号を 5432 以外に変更した場合は、以降の手順で実行するコマンドの「-p 5432」を

「-p [設定した接続ポート番号]」に読み替えてください。

autovacuum：

先頭の「#」を削除し、自動バキューム機能をオフに設定します。

④ データベースサーバを起動します。


pg_ctl start –D C:\database\traning_data_gold\inst01

【実行結果】

データベースサーバが起動します。


4

⑤ 以下のバッチファイルを実行します。

C:\database\traning_data_gold\1-1sampledata.bat

※②で作成したデータベースクラスタ「C:\database\traning_data_gold\inst01」の接続

ポートが「5432」以外の場合は、バッチファイル内の「-p 5432」を「-p [接続ポート番号]」に変更し

たのちに実行してください。

バッチファイルを実行すると、データベース postgres で、以下の操作が行われます。

テーブル mydb,mydb2 の作成

（mydb,mydb2 ともに同じ構成）

カラム名データ型

num integer

name text

テーブル mydb,mydb2 へ 100 万件のテストデータ挿入/削除の繰り返し

事前準備のバッチファイルを実行すると、テーブル mydb,mydb2 のデータは 3 件のみですが、

データの挿入と削除を繰り返しているため、データファイルのサイズが大きい状態のままとなっています。

選択肢のコマンドを実行し、データファイルサイズが変わるかどうかを確認します。

(2) データファイルの特定、ファイルサイズ確認

VACUUM 実行前のデータファイルサイズを確認します。

① データベース postgres のテーブル mydb,mydb2 のデータファイルを特定します。


oid2name -U postgres -p 5432

【実行結果】

実行結果の Oid 列がデータフォルダ名、Database Name 列がデータベース名となります。

上記の場合はデータベース postgres のデータファイルは

C:\database\traning_data_gold\inst01\base\13012 配下に格納されています。


5

② テーブル mydb のデータファイルを特定します。


oid2name -d postgres -i -t mydb -U postgres -p 5432

【実行結果】

実行結果の Filenode 列がデータファイル名、Table Name 列がテーブル名となります。

上記の場合、データベース postgres のテーブル mydb のデータファイルは

「C:\database\traning_data_gold\inst01\base\13012\16384」となります。

③ テーブル mydb2 のデータファイルを特定します。


oid2name -d postgres -i -t mydb2 -U postgres -p 5432

【実行結果】


上記の場合、データベース postgres のテーブル mydb2 のデータファイルは



6

④ データファイルサイズを確認します。

Windows のエクスプローラで、②、③で特定したデータファイルのディレクトリを開き、ファイルサイズを

確認します。

上記の例の場合、C:\database\traning_data_gold\inst01\base\13012\を開き、

ファイル 16384(mydb)、16390(mydb2)のファイルサイズを確認します。

VACUUM コマンドのオプションの指定による違いを見ていきましょう;

① psql で、データベース postgres に接続します。


psql –U postgres –p 5432

【実行結果】


7

A.VACUUM mydb;

① psql で、以下の SQL を実行します。

VACUUM mydb;

【実行結果】

② データファイルサイズを確認します。

「(2)データファイルの特定、ファイルサイズ確認」の手順に従って、データファイルサイズを確認し

ます。

mydb のデータファイルサイズは変化していません。

◆ A. VACUUM mydb;

⇒VACUUM mydb;を実行してもデータファイルサイズは変わらず、更新/削除された行の切り

詰めが行われていません。

★POINT★

FULL オプションを指定しない VACUUM は、不要になったデータ領域を回収して再利用可能にしま

す。不要領域を再利用可能な状態にするだけであるため、データファイルの物理サイズは変わりませ

ん。


8

B.VACUUM VERBOSE mydb;

① psql で、以下の SQL を実行します。

VACUUM VERBOSE mydb2;

【実行結果】

② データファイルサイズを確認します。

「(2)データファイルの特定、ファイルサイズ確認」の手順に従って、データファイルサイズを確認しま

す。

mydb のデータファイルサイズは変化していません。

◆ B.VACUUM VERBOSE mydb;

⇒VACUUM VERBOSE mydb;を実行しても、データファイルサイズは変わらず、更新/削除

された行の切り詰めが行われていません。

★POINT★

VERBOSE オプションは VACUUM 処理の詳細情報を出力します。


9

C.VACUUM FULL mydb;

① sql で、以下の SQL を実行します。

VACUUM FULL mydb;

【実行結果】

② データベースサーバから切断します。


\q

【実行結果】

プロンプトが「C:\」になっていることを確認します。

③ データファイルサイズを確認します。

VACUUM FULL を実行するとデータの詰め直しが行われるためデータファイルが変わります。


oid2name -d postgres -i -t mydb -U postgres -p 5432

【実行結果】


上記の場合、データベース postgres のテーブル mydb のデータファイルは


Windows のエクスプローラで、特定したデータファイルのディレクトリを開き、ファイルサイズを

確認します。

上記の例の場合、C:\database\traning_data_gold\inst01\base\13012\を開き、

ファイル 16396(mydb)、16390(mydb2)のファイルサイズを確認します。


10

mydb のみデータファイルサイズが小さくなっています。

◆ C.VACUUM FULL mydb;

⇒mydb のみデータファイルが小さくなっており、更新/削除された行の切り詰めが行われ

ていることを確認できます。

★POINT★

VACUUM は不要になったデータ領域を回収して再利用可能にするだけですが、VACUUM FULL

では、データの詰め直しを行うためテーブルの排他的ロックが必要となり、実行速度も低速です。ま

た、テーブル名を指定せずに VACUUM コマンドを実行すると、データベース上のすべてのテーブルを

VACUUM 処理の対象とします。


11

D.VACUUM;




【実行結果】

② psql で、以下の SQL を実行します。

VACUUM;

【実行結果】

③ データベースサーバから切断します。


\q

【実行結果】

④ データファイルサイズを確認します。

「(2)データファイルの特定、ファイルサイズ確認」の手順に従って、データファイルサイズを確認しま

す。

mydb,mydb2 のデータファイルサイズは変化していません。


12

◆ D.VACUUM;

⇒VACUUM;を実行してもデータファイルサイズは変わらず、更新/削除された行の切り

詰めが行われていません。

★POINT★

FULL オプションを指定しない VACUUM は、不要になったデータ領域を回収して再利用可能にしま

す。不要領域を再利用可能な状態にするだけであるため、データファイルの物理サイズは変わりませ

ん。

テーブル名を指定せずに VACUUM コマンドを実行すると、データベース上のすべてのテーブルを

VACUUM 処理の対象とします。


13

課題終了後、postgresql.conf を課題開始前の状態に戻します。

① 課題の開始前にコピーした postgresql.conf を、以下の場所に貼り付けてください。

格納先 C:\database\traning_data_gold\inst01

② postgresql.conf のパラメーターを以下のとおり変更し、保存します。

【変更内容】

変更前変更後

#port = 5432 port = 5432

port：

接続するポートを指定します。5432 ポートをすでに使用している場合は、未使用のポート番

号を指定します。

※ポート番号を 5432 以外に変更した場合は、以降の手順で実行するコマンドの「-p

5432」を「-p [設定した接続ポート番号]」に読み替えてください。

③ データベースサーバを再起動します。


pg_ctl restart -D C:\database\traning_data_gold\inst01

データベースサーバが再起動されます。


14

2 性能監視

2-1 課題 2

演習課題２

実行されたすべての SQL 文の実行時統計情報を記録する方法を実施します。そのためには、

pg_stat_statements をクエリにより参照します。

pg_stat_statements ビューでは、実行されたすべての SQL 文の実行ユーザー、データベースの Oid、

SQL 文の実行時間を要したのかなどの統計情報を確認できます。

【事前準備】

① pg_stat_statements ビューはデフォルトでは使用できないため、モジュールのロードを行います。

データベースクラスタ「inst01」の postgresql.conf の編集を行います。

編集をする前に postgresql.conf ファイルをコピーしておきます。（3-3 の課題終了後、

postgresql.conf を元の設定に戻す際に使用します）

(1)以下のファイルをテキストエディタで開きます。

C:\database\traning_data_gold\inst01\postgresql.conf

(2) postgresql.conf のパラメーターを以下のとおり変更し、保存します。

【変更内容】

変更前変更後

#shared_preload_libraries = '' shared_preload_libraries =

'pg_stat_statements'

shared_preload_libraries：

先頭の「#」を削除し、「pg_stat_statements」を指定します。

② psql で、データベース postgres に接続します。



【実行結果】


15

③ psql で、以下の SQL を実行します。

create extension pg_stat_statements;

【実行結果】

④ データベースサーバから切断します。


\q

【実行結果】


⑤ データベースサーバを再起動します。





16

【実施による確認】

ここでは実習課題１にて作成したデータベースクラスタ「inst01」を使用して確認します。

① pg_stat_statements ビューの項目を確認します。


psql –U postgres –p 5432 -x –c "select * from pg_stat_statements;"

pg_stat_statements ビューの結果が表示されます。

pg_stat_statements ビューでは、実行されたすべての SQL 文にて以下の項目が参照できます。

項目名説明

userid 対象 SQL文の実行ユーザーの Oid を表す。

dbid 対象 SQL文の実行データベースの Oidを表す。

queryid 内部ハッシュコードを表す。

query 実行された SQL文の代表的な文字列を表す。


17

calls 対象 SQL文の実行回数を表す。

total_time 対象 SQL文の処理にかかった、ミリ秒単位の総時間を表す。

min_time 対象 SQL文の処理にかかった、ミリ秒単位の最小時間を表す。

max_time 対象 SQL文の処理にかかった、ミリ秒単位の最大時間を表す。

mean_time 対象 SQL文の処理にかかった、ミリ秒単位の平均時間を表す。

stddev_time 対象SQL文の処理にかかった、ミリ秒単位の母標準偏差を表す。

rows 対象 SQL文にて取得されたまたは影響を受けた行数を表す。

shared_blks_hit 対象 SQL文にてヒットした共有ブロックキャッシュ総数を表す。

shared_blks_read 対象 SQL文にて読み込まれた共有ブロック総数を表す。

shared_blks_dirtied 実行された SQL 文によりダーティー状態となった共有ブロック総数

を表す。

shared_blks_written 対象 SQL文にて書き込まれた共有ブロック総数を表す。

local_blks_hit 対象 SQL文にてヒットしたローカルブロックキャッシュ総数を表す。

local_blks_read 対象 SQL文にて読み込まれたローカルブロック総数を表す。

local_blks_dirtied 対象 SQL 文にてダーティー状態となったローカルブロック総数を表

す。

local_blks_written 対象 SQL文にて書き込まれたローカルブロック総数を表す。

temp_blks_read 対象 SQL文にて読み込まれた一時ブロック総数を表す。

temp_blks_written 対象 SQL文にて書き込まれた一時ブロック総数を表す。

blk_read_time ブロック読み取りにかかった、ミリ秒単位の総時間を表す。

blk_write_time ブロック書き出しにかかった、ミリ秒単位の総時間を表す。

★POINT★

pg_stat_statements はすべての SQL 文の統計情報を記録しますが、デフォルトでは記録される

SQL 文の最大数が 5000 に指定されています。最大数を超えて異なる SQL 文を検出すると、最

も実行回数の少ない SQL 文の情報が削除されます。

そのため、場合に応じて以下パラメーターを postgresql.conf に追加し、記録される SQL 文の最

大数を変更しましょう。

パラメーター：pg_stat_statements.max = [最大数]


18

【補足】

pg_stat_statements ビューにて統計情報を参照してみましょう。

今回の演習では、以下の例を想定して参照を行います。

例）実行時間の長い SQL 文の上位 5 件を参照したい。




【実行結果】

② psql で、以下の SQL を実行します。

SELECT userid,dbid,query,calls,total_time,rows

FROM pg_stat_statements

ORDER BY total_time DESC LIMIT 5;

【実行結果】

「total_time」列を降順に表示することで、実行時間が長い SQL 文の上位 5 件が表示されます。

③ データベースサーバから切断します。


\q

【実行結果】



19

課題終了後、postgresql.conf を課題開始前の状態に戻します。

① 課題の開始前にコピーした postgresql.conf を、以下の場所に貼り付けてください。

格納先 C:\database\traning_data_gold\inst01

② データベースサーバを再起動します。





20

2-2 課題 3

演習課題 3

以下のような SQL 文を実行することで、データベースのどのような統計情報を確認できるのかを確認しま

す。

A.SELECT * FROM pg_stat_activity;

B.SELECT * FROM pg_stat_database;

C.SELECT * FROM pg_stat_bgwriter;

D.SELECT * FROM pg_stat_all_tables;

E.SELECT * FROM pg_stat_all_indexes;


21

演習課題 1 にて作成したデータベースクラスタ「inst01」を使用して確認します。

A.SELECT * FROM pg_stat_activity;

① pg_stat_activity ビューの項目を確認します。


psql -U postgres -p 5432 -x -c "select * from pg_stat_activity;"

★POINT★

pg_stat_activity ビューでは、サーバプロセスあたり 1 行の形式で現在の活動状況に関連した情

報を表示します。

状況に応じて、クライアントが PostgreSQLに接続した時刻やトランザクションの開始時刻、SQL 文

の実行開始時刻（無応答になっていたり、長時間トランザクションになっていたりしないか）、ロック

待ちになっていないか、実行されている SQL 文の内容などを確認できます。

省略


22

B.SELECT * FROM pg_stat_database;

① pg_stat_database ビューの項目を確認します。


psql -U postgres -p 5432 -x -c "select * from pg_stat_database;"

★POINT★

pg_stat_database ビューでは、クラスタ内のデータベース当たり 1 行の形式にてデータベース全体

の統計情報を表示します。

状況に応じて、コミット数やロールバック数、現在のデータベース接続数、更新および参照件数、デッ

ドロック数などを確認できます。

省略


23

C.SELECT * FROM pg_stat_bgwriter;

① pg_stat_bgwriter ビューの項目を確認します。


psql -U postgres -p 5432 -x -c "select * from pg_stat_bgwriter;"

★POINT★

pg_stat_bgwriter ビューでは、バックグラウンドライタプロセスの活動状況に関連する統計情報を

表示します。

バックグラウンドライタプロセスは、バックグラウンドで共有バッファを監視し、新規または更新されたダー

ティーページをハードディスクに書き出す処理を行います。


24

D.SELECT * FROM pg_stat_all_tables;

① pg_stat_all_tables ビューの項目を確認します。


psql -U postgres -p 5432 -x -c "select * from pg_stat_all_tables;"

★POINT★

pg_stat_all_tables ビューでは、データベース内のテーブルあたり 1 行の形式にて特定のテーブル

へのアクセスに関する統計情報を表示します。

状況に応じて、シーケンシャルスキャンの回数と件数、テーブル更新件数、自動または手動による

VACUUM や ANALYZE が最後に実行された時刻などを確認できます。

省略

省略


25

E.SELECT * FROM pg_stat_all_indexes;

① pg_stat_all_indexes ビューの項目を確認します。


psql -U postgres -p 5432 -x -c "select * from pg_stat_all_indexes;"

★POINT★

pg_stat_all_indexesビューでは、データベースのインデックスあたり1行の形式にて特定のインデッ

クスへのアクセスに関する統計情報を表示します。

状況に応じて、インデックススキャンの実行回数や項目数、テーブル更新件数、インデックススキャン

によって取り出された有効テーブル行数などを確認できます。

省略


26

3 パフォーマンスチューニング

3-1 課題 4

演習課題 4

GUC パラメーターの enable_seqscan を on から off に変更する前後で、クエリの実行計画にどのよう

な変化があるのかを確認します。

そのために、GUC パラメーターの enable_seqscan を on から off に変更する前後で、同一のクエリに

対して EXPLAIN ANALYZE 文で実行計画を取得することで確認します。

ここでは、データベースクラスタ「inst02」を作成し、操作を行います。

【事前準備】

① OS に Users 権限のユーザー（user01）でログインし、コマンドプロンプトを起動します。

② データベースクラスタ「inst02」を作成します。


initdb -D C:\database\traning_data_gold\inst02 --locale="C" --encoding=UTF8

–U postgres

【実行結果】

データベースクラスタが正常に作成されます。


27

③ データベースサーバを起動します。


pg_ctl start –D C:\database\traning_data_gold\inst02

【実行結果】

データベースサーバがポート番号「5432」で起動されます。

④ 以下のバッチファイルを実行してください。

C:\database\traning_data_gold\3-1sampledata.bat

バッチファイルを実行すると、データベース postgres で、以下の操作が行われます。

テーブル tbl1 の作成

カラム名データ型

id integer

name text

テーブル tbl1 へ 100 万件のテストデータ挿入

「name」列へインデックス作成

バッチファイルを実行すると、テーブル tbl1 のデータは 100 万件となっており、「id」列に昇順で数値

データが挿入されます。


28

【実習による確認】




【実行結果】

② enable_seqscan の状態を確認します。


show enable_seqscan;

【実行結果】

「on」であることを確認します。

③ テーブル tbl1 を使用し、「id」列を対象に ORDER BY 処理を行います。


explain analyze select * from tbl1 order by id;

【実行結果】

「Seq Scan」でテーブルにアクセスしていることを確認します。

また、最上位ノードの全体推定コストと、「Execution Time」の値を確認しておきます。

④ enable_seqscan を off にします。


set enable_seqscan to off;


29

【実行結果】

⑤ enable_seqscan の状態を確認します。


show enable_seqscan;

【実行結果】

「off」であることを確認します。

⑥ テーブル tbl1 を使用し、「id」列を対象に再度 ORDER BY 処理を行います。


explain analyze select * from tbl1 order by id;

【実行結果】

「Seq Scan」でテーブルにアクセスしていることを確認します。

また、③の実行結果と比較して最上位ノードの全体推定コストが増えていること、「Execution

Time」の値が変わっていることを確認します。

※上記の実行結果では、「Execution Time」の値が大きくなっていますが、場合によっては小さく

なる可能性があります。


30

◆ 最上位ノードの全体推定コストが小さくなる可能性があることが確認できました。

PostgreSQL は、問い合わせを実行するときの実行計画のコストを計算し、基本的に最もコストが

低い実行計画を選びます。

enable_seqscan を on から off に設定することで、シーケンシャルスキャンを行う実行計画のコス

トが大きくなるため、シーケンシャルスキャンが選択されにくくなります。

シーケンシャルスキャンとは、テーブルを最初から最後までアクセスするスキャン方法であり、取り出す

データ件数が多い場合に有効です。

★POINT★

enable_seqscan を off にすることで、シーケンシャルスキャン以外の効率の悪いスキャン方式を利

用し Execution Time の値が大きくなったり、本来選択すべき効率の良いスキャン方式を利用し

Execution Time の値が小さくなったりする可能性があります。

また、シーケンシャルスキャンを利用する問い合わせでは、enable_seqscan を off にしてもコストを

10000000000 として算定しシーケンシャルスキャンを選択します。この場合は、他の何らかのコスト

が小さくなるわけではないため、全体推定コストの小さい実行計画が選択される可能性はありませ

ん。

実機演習テキストƒ†クカン実機...ファイル16384(mydb)、16390(mydb2)のファイルサイズを確認します。...

Documents