Ubuntu Manpage: REINDEX

Provided by: manpages-zh_1.5-1_all

NAME

       REINDEX - 垂堹薑

SYNOPSIS

       REINDEX { DATABASE | TABLE | INDEX } name [ FORCE ]

DESCRIPTION�yz
       REINDEX  基於存儲在表上的數據垂堹薑煄A  替換舊的索引拷貝。使用  REINDEX
       有兩茈Dn鴞]：

       o        索引崩潰，並且不再包含有效的數據。儘管理論上這是不可能發生的，
         但實際上索引會因為軟體毛病或者硬體問題而崩潰。REINDEX       提供了一-
         茷黕_方法。

       o       n處理的索引包含大量無用的索引階撲Q回收。在某些情況下，      這-
         荌暋D會發生在   PostgreSQL   裏悸   B-樹索引上。REINDEX    提供了一-
         蚆Y小索引空間消耗的方法，它採用的方法是寫一茪ㄠa無用索引-
         隍熒s版本的索引。     參閱Section     21.2    ``Routine    Indexing''
         獲取更多信息。

PARAMETERS��數
       DATABASE
               恢復一蚆n明了的數據庫的所有系統索引。
              不包含使用者表上的索引。同樣，除非在獨立運行模式下，也會忽略在共享系統表上的索引（見下文）。

       TABLE      奐s建立聲明的表的所有索引。如果表有荓q屬的"TOAST"表，那麼這-
              茠矰]會奐s索引。

       INDEX   奐s建立聲明了的索引。

       name    n垂堛漫畛n明的數據庫/表/索引的名稱。 表和索引名可以有模式袡╮C

       FORCE   這是一蚍o棄的選項，如果聲明，會被忽略。

NOTES�`�N
        如果你懷疑一茖洏峈怐矰W的索引崩潰了，你可以簡單地垂婺荅薑煄A
       或者該表上地所有索引，使用 REINDEX INDEX 或者 REINDEX  TABLE。  另外一-
       蚢鴷I使用者表索引崩潰的方法時刪除然後垂堨式C如果你還-
       n在表上進行一些維護動作，                   可能這麼做更好一些。REINDEX
       在表上請求排他鎖，而 CREATE INDEX 只是鎖住寫動作， 而不會鎖住讀。

        如果你從一荓Y潰的系統表索引上恢復，事情會更棘手一些。
       這種情況下，系統必須不能使用任何有疑問的索引。
       （實際上，在這種情況下，你可能發現伺服器進程在啟動之後馬上就崩潰了，
       因為依賴於崩潰了的索引。）n想安全恢復，伺服器必須帶著   -P   選項啟動，
       它禁止伺服器在查找系統表的時唻洏巹薑煄C

        這麼做茪@蚇鴘k事停止  postmaster  然後帶著  -P 命令行選項啟動一蚇W立的
       PostgreSQL   伺服器。   然後，根據你希望恢復的程度，可以發出    REINDEX
       DATABASE，REINDEX   TABLE，或者   REINDEX   INDEX。  如果還有懷疑，使用
       REINDEX          DATABASE           選擇奐s構造數據庫中全部的系統索引。
       然後退出獨立伺服器會話並且垮珒雲q的伺服器。參閱    postgres(1)    手冊-
       黃簳有關如何與獨立伺服器交互的信息。

        另外，一荋雲q的會話可以在其命令行選項裏帶著         -P          啟動。
       這麼做的方法因不同的客戶端而異，但是在所有基於  libpq  的客戶端上， 我-
       抭ㄔi以通過在啟動客戶端之前設置  PGOPTIONS   環境變量為   -P   來實現。
       請注意儘管這茪隤k並不-
       n求鎖住其它客戶端，但是禁止其它客戶端連接受損的數據庫，       直到完成-
       袑劦雩茖@茤智的選擇。

        如果懷疑任何共享的系統表的索引損壞（(pg_database，      pg_group，或者
       pg_shadow），                那麼必須用獨立伺服器的方式來袨_它。REINDEX
       不能在多使用者環境下處理共享系統表。

        除了共享系統表之外的所有索引，REINDEX       是抗崩潰並且是事務安全的。
       REINDEX
       對於共享的索引而言不是抗崩潰的，這就是為什麼不允許在正常操作中這麼使用的-
       鴞]。                                 如果在奐s對一茼@享表進行索引的時-
       埽o生了崩潰，那麼在糾正問題之前，就不可能奐s啟動普通的伺服器。    （一-
       茷堨艉F一部分的共享索引的典型症狀是"index is not a btree/索引不是 btree
       索引"錯誤。）

        在    PostgreSQL    7.4   之前，REINDEX   TABLE   並不自動處理   TOAST
       表，因此這些表必須用獨立的命令進行處理。這麼做仍然可以，但是已經多餘了。

EXAMPLES���l
        垂堛 mytable 上的索引：

       REINDEX TABLE my_table;

        垂堻窲索引：

       REINDEX INDEX my_index;

        垂堣@蚍畬w上的所有系統索引，不管他怓O否有效：

       $ export PGOPTIONS="-P"
       $ psql broken_db
       broken_db=> REINDEX DATABASE broken_db;
       broken_db=> \q

COMPATIBILITY���e性
        在SQL 標準裏沒有 REINDEX。

��者
       Postgresql������� ���� <laser@pgsqldb.org>

Ubuntu manuals

NAME

SYNOPSIS