| PostgreSQL 8.3.3문서 | ||||
|---|---|---|---|---|
| Prev | Fast Backward | Fast Forward | Next | |
REINDEX는 인덱스의 테이블에 보존된 데이터를 사용해 인덱스를 재구축 하고 그 인덱스의 오래된 복사본으로 대체합니다. 이하에REINDEX가 사용되는 상황을 나타냅니다.
한 인덱스에 오류가 발생했고 더 이상 유요한 데이터를 갖고 있지 않습니다. 이론적으로는 결코 일어나지 않을 것입니다만, 실제로는 소프트웨어의 버그나 하드웨어의 장해에 의해 인덱스가 파손하는 일이 있습니다. REINDEX는 이 복구 방법을 제공합니다.
인덱스가"팽창 상태" 즉, 많이 비거나 거의 빈 페이지를 가지는 상태가 되어 있는 경우입니다. 이 상황은 PostgreSQL의 B-tree 인덱스가 특정의 패턴으로 액세스 되었을 경우에 일어날 수 있습니다. REINDEX를 사용해 사용되지 않는 페이지를 없이 새로운 인덱스 버젼을 작성하므로 인덱스의 영역 소비량을 감소할 수가 있습니다. 자세한 것은Section 22.2을 참조해 주세요.
인덱스의 저장 매개변수(fillfactor와 같은)를 변경해, 이 변경이 유효한가 어떤가를 확인하고 싶은 경우입니다.
CONCURRENTLY옵션을 붙인 인덱스 작성이 실패해,"무효인"인덱스가 남았을 경우입니다. 이러한 인덱스는 사용되지 않지만, REINDEX를 사용해 간단하게 재작성할 수가 있습니다. REINDEX에서는 동시 구축을 할 수 없는 것에 주의해 주세요. 운용에 영향을 주지 않고 인덱스를 작성하기 위해서는, 인덱스를 삭제하고 나서CREATE INDEX CONCURRENTLY명령을 재발행해야 합니다.
지정한 인덱스를 재작성합니다.
지정한 테이블의 전인덱스를 재작성합니다. 테이블에 2차적인"TOAST"테이블이 있어도, 똑같이 인덱스를 재작성합니다.
현재의 데이터베이스의 모든 시스템 인덱스를 재작성합니다. 또, stand-alone 모드(후술) 이외의 모드에서는, 공유 시스템 카탈로그의 인덱스는 처리되지 않습니다. 이 구문의REINDEX를 트랜잭션(transaction) 블록내에서 실행할 수 없습니다.
현재의 데이터베이스의 모든 시스템 카탈로그의 인덱스를 재작성합니다. 사용자 테이블의 인덱스는 처리되지 않습니다. 또, stand-alone 모드(후술) 이외의 모드에서는 공유 시스템 카탈로그의 인덱스는 처리되지 않습니다. 이 구문의REINDEX를 트랜잭션(transaction) 블록내에서 실행할 수 없습니다.
인덱스를 재작성하는 인덱스, 테이블, 데이터베이스의 이름입니다. 인덱스와 테이블은 schema로 수식 가능합니다. 현재 상태로서는 REINDEX DATABASE와 REINDEX SYSTEM는 현재의 데이터베이스의 인덱스만을 재작성할 수가 있습니다. 그 때문에, 이 매개변수는 현재의 데이터베이스명으로 일치해야 합니다.
이 옵션은 폐지되었습니다. 지정되어도 무시됩니다.
테이블의 인덱스가 손상되었다면, REINDEX INDEX 또는 REINDEX TABLE를 사용하여 간단히 인덱스를 재작성 할 수 있습니다.
시스템 테이블의 인덱스의 파손에 대한 복구가 필요하다면 더욱 어렵습니다. 이 경우, 시스템에 의해 파손의 가능성이 있는 인덱스 자체가 사용되지 않게 하는 것이 중요합니다 (실제로 이러한 케이스에서는 파손한 인덱스에 의존하고 있었기 때문에, 서버 프로세스가 기동시에 강제 종료해 버릴 가능성이 있습니다). 안전하게 복구시키려면 시스템 카탈로그 검색시의 인덱스의 사용을 금지한다. -P옵션을 사용해 서버를 기동하지 않으면 안됩니다.
생각되는 방법의 하나는 다음의 방법입니다. 우선 서버를 정지해 명령 라인으로부터-P옵션을 지정해 싱글 유저 상태의PostgreSQL서버를 기동합니다. 그리고, 복구성 하는 범위에 응해 REINDEX DATABASE, REINDEX SYSTEM, REINDEX TABLE 또는 REINDEX INDEX 명령을 발행합니다. 범위가 불명한 경우는 REINDEX SYSTEM를 사용해, 그 데이터베이스의 모든 시스템 인덱스를 복구 이루어 주세요. 그 후, 싱글 유저 상태의 서버 세션을 정지해 보통 서버를 재기동합니다. 싱글 유저 상태의 서버 인터페이스의 조작 방법에 대한 자세한 것은 postgres 메뉴얼 페이지를 참조해 주세요.
그 외, 명령 라인으로-P를 지정해 정규 서버 세션을 시작할 수도 있습니다. 구체적인 방법은 클라이언트에 따라서 다릅니다. 그러나 libpq베이스의 클라이언트면, ㅋ클라이언트를 시작하기 전에PGOPTIONS환경 변수를-P로 설정하면 실현될 수 있습니다. 이 방법에서는 다른 클라이언트를 내쫓을 필요는 없습니다만, 복구가 끝날 때까지 파손한 데이터베이스에의 다른 사용자의 접속을 방지하는 편이 좋은 것에 주의해 주세요.
공유 시스템 카탈로그 (pg_authid, pg_auth_members, pg_database, pg_pltemplate, pg_shdepend, pg_shdescription, pg_tablespace)의 몇개의 인덱스가 파손한 혐의가 있는 경우는 독립형 서버를 사용해 복구되어야 합니다. REINDEX는, multiuser 모드에서는 공유 카탈로그를 처리하지 않습니다.
공유 시스템 카탈로그 제외된 모든 인덱스에서는 REINDEX는 crash-safe 이고 트랜잭션(transaction) safe 입니다. 다만, 공유 인덱스에 대한REINDEX는 crash-safe가 아닙니다. 이것이, 통상의 운용 상태로 실행할 수 없는 이유입니다. 독립형 모드로, 이러한 카탈로그의 인덱스 재작성 처리중에 문제가 발생했을 경우, 문제가 수정될 때까지 규정 서버를 재기동할 수가 없게 됩니다 (공유 인덱스의 재구축이 불충분한 것을 나타내는 전형적인 증상으로서 "index is not a btree"라고 하는 에러가 발생하는 일이 자주 있습니다).
REINDEX는 인텍스를 삭제하거나 제거로 인해 재구축된 인덱스 내용 재작성하는 것과 비슷합니다. 그러나, 락에 관해서는 다릅니다. REINDEX는 인덱스의 원이 되는 테이블의 기입을 잠급니다만, 읽기는 잠그지 않습니다. 또, 처리중의 인덱스에 대한 배타 락을 취득하므로, 그 인덱스를 사용하는 읽기는 막힙니다. 한편, DROP INDEX는 순간적으로 원이 되는 테이블의 배타 락을 취득하므로, 기입도 읽기도 막힙니다. 그 후에 실시하는CREATE INDEX에서는 기입만을 잠그어, 읽기는 잠그지 않습니다. 인덱스는 존재하지 않기 때문에, 인덱스를 사용하는 읽기는 발생하지 않습니다. 따라서, 읽기가 막히지 않으나 가격이 비싼 순차적인 스캔의 사용을 강제당하게 됩니다. 또 다른 중요한 포인트는 삭제/생성이 REINDEX 사용하지 않는 동안 인덱스를 사용하는 캐시된 쿼리의 계획을 무효로 만들 것입니다.
단일 인덱스 또는 단일 테이블의 인덱스 재작성을 실시하려면 , 그 인덱스 또는 테이블의 소유자가 아니면 안됩니다. 데이터베이스에 대한 인덱스 재작성을 실시하려면 , 데이타베이스의 소유자가 아니면 안됩니다 (그러므로 이 소유자는 다른 유저가 소유하는 테이블의 인덱스를 재작성할 수가 있습니다). 물론, 슈퍼 유저는 항상 모든 인덱스 재작성을 실시할 수가 있습니다.
PostgreSQL 8.1보다 전까지에서는 REINDEX DATABASE는 이름으로부터 예상되는 모든 인덱스에 대한 처리는 아니고, 시스템 인덱스만을 처리하고 있었습니다. 이 것은 의외의 요소를 줄이는 것에서 바뀌곤 합니다. REINDEX SYSTEM로, 이 이전의 처리를 실시하게 할 수가 있습니다.
PostgreSQL 7.4보다 전까지는 REINDEX TABLE는 TOAST 테이블에 대해서 자동적으로 처리를 실시하지 않았습니다. 그 때문에 다른 명령으로 인덱스를 재작성하지 않으면 안됩니다. 현재에도 이것은 가능합니다만, 중복됩니다.