Documentation PostgreSQL 7.4.29 | ||||
---|---|---|---|---|
Pr�c�dent | Arri�re rapide | Avance rapide | Suivant |
REINDEX reconstruit un index bas� sur les donn�es stock�es dans la table, rempla�ant l'ancienne copie de l'index. Il y a deux raisons principales pour utiliser REINDEX :
Un index a �t� corrompu et ne contient plus de donn�es valides. Bien qu'en th�orie, ceci ne devrait jamais arriver, en pratique, les index peuvent se corrompre � cause de bogues dans le logiciel ou d'�checs mat�riels. REINDEX fournit une m�thode de r�cup�ration.
L'index en question contient beaucoup de pages d'index mortes qui ne sont pas r�clam�s. Ceci peut arriver avec des index B-tree dans PostgreSQL sous certains mod�les d'acc�s. REINDEX fournit un moyen de r�duire la consommation d'espace de l'index en �crivant une nouvelle version de l'index sans les pages mortes. Voir Section 21.2 pour plus d'informations.
Recr�e tous les index syst�me d'une base de donn�es sp�cifi�e. Les index sur les tables utilisateur ne sont pas trait�s. De plus, les index sur les catalogues syst�me partag�s ne sont pas pris en compte sauf dans le mode autonome (voir ci-dessous).
Recr�e tous les index d'une table sp�cifi�e. Si la table a une seconde table <<�TOAST�>>, elle sera aussi r�index�e.
Recr�e un index sp�cifi�.
Le nom de la base de donn�es, table ou index sp�cifique � r�indexer. Les noms de table et d'index pourraient �tre qualifi�s du nom du sch�ma.
Ceci est une option obsol�te ; elle est ignor�e si elle est sp�cifi�e.
Si vous suspectez une corruption d'un index sur une table utilisateur, vous pouvez simplement reconstruire cet index, ou tous les index de la table, en utilisant REINDEX INDEX ou REINDEX TABLE. Une autre approche pour g�rer un index corrompu de table utilisateur est de simplement le supprimer et de le recr�er. Ceci pourrait en fait �tre pr�f�rable si vous souhaitez maintenir un certain �tat d'op�rations de base sur la table pendant ce temps. REINDEX acquiert le verrou exclusif sur la table alors que CREATE INDEX verrouille seulement l'�criture et non pas les lectures de la table.
Les choses sont plus difficiles si vous avez besoin de r�cup�rer de la corruption d'un index sur une table syst�me. Dans ce cas, il est important pour le syst�me de ne pas avoir utilis� lui-m�me un des index suspects. (En fait, dans ce type de sc�nario, vous pourriez trouver que les processus serveur s'arr�tent brutalement imm�diatement au lancement, � cause du besoin des index corrompus.) Pour r�cup�rer proprement, le serveur doit �tre lanc� avec l'option -P, qui l'emp�che d'utiliser les recherches de catalogues syst�me.
Une fa�on de faire ceci est d'arr�ter le postmaster et de lancer le serveur PostgreSQL en mode autonome avec l'option -P plac�e sur la ligne de commande. Ensuite, REINDEX DATABASE, REINDEX TABLE ou REINDEX INDEX peuvent �tre lanc�s suivant ce que vous souhaitez reconstruire. En cas de doute, utilisez REINDEX DATABASE pour s�lectionner la reconstruction de tous les index syst�me dans la base de donn�es. Enfin, quittez la session autonome du serveur et relancez le serveur habituel. Voir la page de r�f�rence de postgres pour plus d'informations sur l'interaction avec l'interface du serveur autonome.
Autrement, une session standard du serveur peut �tre lanc�e avec -P inclus dans les options de la ligne de commande. La m�thode pour ce faire varie entre les clients mais dans tous les clients bas�s sur libpq, il est possible de configurer la variable d'environnement PGOPTIONS � -P avant de lancer le client. Notez que, bien que cette m�thode ne r�clamait pas le verrouillage des autres clients, il pourrait �tre conseill� d'emp�cher les autres utilisateurs, il pourrait toujours �tre conseill� d'emp�cher les autres utilisateurs de se connecter � la base de donn�es endommag�e jusqu'� la fin des r�parations.
Si une corruption est suspect�e dans les index de tout catalogue syst�me partag�e (pg_database, pg_group ou pg_shadow), alors un serveur autonome doit �tre utilis� pour le r�parer. REINDEX ne traitera pas les catalogues partag�es dans le mode multiutilisateur.
Pour tous les index sauf les catalogues syst�me partag�es, REINDEX est prot�g� contre les arr�ts brutaux et comprend les transactions. REINDEX n'est pas prot�g� pour les index partag�s, ce qui explique pourquoi ce cas est d�sactiv� pendant les op�rations normales. Si un �chec survient lors de la r�indexation d'un de ces catalogues dans le mode autonome, il ne sera pas possible de relancer le serveur r�gulier jusqu'� ce que le probl�me soit rectifi�. (Le symptome typique d'un index partag� reconstruit partiellement est <<�index n'est pas un btree�>> errors.)
Avant PostgreSQL 7.4, REINDEX TABLE ne traitait pas automatiquement les tables TOAST et, du coup, elles devaient �tre r�index�es par des commandes s�par�es. C'est toujours possible mais redondant.
Recr�e les index sur la table ma_table :
REINDEX TABLE ma_table;
Reconstruit un index simple :
REINDEX INDEX my_index;
Reconstruit tous les index syst�me d'une base de donn�es particuli�re sans croire qu'elles sont d�j� valides :
$ export PGOPTIONS="-P" $ psql broken_db ... broken_db=> REINDEX DATABASE broken_db; broken_db=> \q
Pr�c�dent | Sommaire | Suivant |
PREPARE | Niveau sup�rieur | RESET |