.\\" auto-generated by docbook2man-spec $Revision: 1.2 $
.TH "REINDEX" "" "2004-06-19" "SQL - 言語" "SQL コマンド"
.SH NAME
REINDEX \- インデックスの再構築

.SH SYNOPSIS
.sp
.nf
REINDEX { DATABASE | TABLE | INDEX } \fIname\fR [ FORCE ]
.sp
.fi
.SH "説明"
.PP
\fBREINDEX\fR は、テーブルに保存されたデータを元にインデックスを再構築し、古いインデックスのコピーと置き換えます。
\fBREINDEX\fR の使用には大きく2つの目的があります。
.TP 0.2i
\(bu
インデックスが破損してしまい、有効なデータがなくなった場合です。
理論的には決して起こらないことですが、実際には、ソフトウェアのバグやハードウェアの障害により破損することがあります。
\fBREINDEX\fR はこの修復手段を提供します。
.TP 0.2i
\(bu
対象とするインデックスが回収されることがない使用されないインデックスページを多く含む場合です。
これは、特定のアクセスパターン下のPostgreSQLのB-treeインデックスで起こり得ます。
\fBREINDEX\fR は、使用されないページを持たない新しいインデックスを書き直すことでそのインデックスの領域消費量を減少させる手段を提供します。
詳細は[XRef to ROUTINE-REINDEX]を参照してください。
.PP
.SH "パラメータ"
.TP
\fBDATABASE\fR
指定したデータベースの全てのシステムインデックスを再作成します。
ユーザテーブル上のインデックスは処理されません。
また、スタンドアローンモード(後述)以外では、共有システムカタログは飛ばされます。
.TP
\fBTABLE\fR
指定したテーブルの全インデックスを再作成します。
テーブルに2次的な``TOAST''テーブルがあっても、同様にインデックスを再作成します。
.TP
\fBINDEX\fR
指定したインデックスを再作成します。
.TP
\fB\fIname\fB\fR
インデックスを再作成するデータベース、テーブル、インデックスを指定する名前です。
テーブルとインデックスはスキーマで修飾可能です。
.TP
\fBFORCE\fR
このオプションは廃止されました。指定されても無視されます。
.SH "注釈"
.PP
ユーザテーブル上の1つのインデックスに破損の疑いがある場合、単にそのインデックスを再構築してください。
テーブル上の全てのインデックスの場合は、\fBREINDEX INDEX\fR か \fBREINDEX TABLE\fR を使用してください。
破損したユーザテーブルのインデックスを扱う他の方法は、単純にそれを削除し生成し直すことです。
差し当たり見かけ上通常の操作で保守作業を行いたい場合は、この方法が実際の所好まれます。
\fBREINDEX\fR はそのテーブルの排他的ロックを必要としますが、\fBCREATE INDEX\fR はテーブルへの書き込みのみをロックし、読み込み時はロックしません。
.PP
システムテーブルのインデックスの破損を復旧する必要がある場合はより複雑になります。
この場合、システムに疑わしいインデックス自体を使用しないようにさせることが重要です。 
(実際は、このような場合は、破損したインデックスへの依存によりサーバプロセスはその起動時に強制終了してしまうことになるでしょう。)
安全に復旧させるには、システムカタログ検索時のインデックスの使用を抑制する\fB-P\fRオプションを使用してサーバを起動させなければなりません。
.PP
この1つの方法は、postmasterを停止させ、\fB-P\fRオプションをコマンドラインに入れてスタンドアロン状態のPostgreSQL サーバを起動させることです。
そして、どこまで再構成させたいのかによって、\fBREINDEX DATABASE\fR、\fBREINDEX TABLE\fR、または、\fBREINDEX INDEX\fR コマンドを発行します。
不明な場合は、\fBREINDEX DATABASE\fR を使用して、そのデータベースの全てのシステムインデックスを再構成を選んでください。
そして、スタンドアロン状態のサーバセッションを停止させ、実サーバを再起動して下さい。
スタンドアロン状態のサーバインタフェースの操作方法についてのより詳細は\fBpostgres\fR(1)マニュアルページを参照してください。
.PP
その他、\fB-P\fR をコマンドラインオプションに含めて、実サーバセッションを起動させることができます。
これを実現させる方法は、クライアントによって異なります。
しかし、全ての\fBlibpq\fRベースのクライアントでは、クライアントを起動する前に\fBPGOPTIONS\fR環境変数を-Pに設定することで可能です。
この方法では他のクライアントを締め出す必要はありませんが、修復が終るまで破損したデータベースへの他のユーザの接続を防止する方が良いことに注意してください。
.PP
共有システムカタログ(\fBpg_database\fR、\fBpg_group\fR、\fBpg_shadow\fR)のいずれかのインデックスが破損した疑いがある場合、修復のためにはスタンドアロンサーバを使用しなければなりません。
マルチユーザモードでは共有カタログの処理を行いません。
.PP
共有システムカタログ以外の全てのインデックスでは、\fBREINDEX\fRはクラッシュセーフかつトランザクションセーフです。
共有インデックスに対する\fBREINDEX\fRはクラッシュセーフではありません。
これが、通常の運用状態で実行できない理由です。
スタンドアロンモードで、これらのカタログのインデックス再作成処理中に問題が発生した場合、問題が修正されるまで実サーバを再起動することができなくなります。
(共有インデックスの部分的な再構築に関するよくある兆候は、``index is not a btree'' というエラーです。)
.PP
PostgreSQL 7.4より前まで、\fBREINDEX TABLE\fRはTOASTテーブルに対して自動的に処理を行いませんでした。そのため、別のコマンドでインデックスを再作成しなければなりませんでした。
これは可能になりましたが、冗長です。
.SH "例"
.PP
my_table テーブルのインデックスを再作成します。
.sp
.nf
REINDEX TABLE my_table;
.sp
.fi
.PP
1つのインデックスを再構築します。
.sp
.nf
REINDEX INDEX my_index;
.sp
.fi
.PP
既に有効かどうかを確認することなく、あるデータベース内の全てのシステムインデックスを再構築します。
.sp
.nf
$ \fBexport PGOPTIONS="-P"\fR
$ \fBpsql broken_db\fR
...
broken_db=> REINDEX DATABASE broken_db;
broken_db=> \\q
.sp
.fi
.SH "互換性"
.PP
標準SQLには\fBREINDEX\fRはありません。
