저희 회사 데이터베이스(PostgreSQL 6.x)의 시스템 카탈로그가 깨진것 같습니다. (정말 울고 싶습니당...) 사건의 전말은 다음과 같습니다...

이 데이터베이스를 수년간 사용해온 터라 pg_log 파일이 상당히 커졌습니다(약 80메가). 그래서 pg_log 파일을 삭제하면 속도가 개선될 것이라는 막연한 기대를 갖고 pg_log 파일을 다른 이름으로 리네임하고, touch 명령으로 빈 pg_log 파일을 하나 생성했습니다(솔직히, 저는 pg_log 파일이 아파치웹서버의 access 로그처럼 단순히 접속 기록만 쌓이는 파일인줄 알았습니다. 게다가, DB를 셧다운시키지 않고 이 짓을 한것이 문제의 근원인것 같습니다).

그런데, 그 다음부터 데이터베이스에 접속은 되나, 파일을 하나도 못찾는 현상이 발생했습니다. 그리하여 허겁지겁 리네임한 원래의 pg_log 파일을 다시 pg_log라고 리네임하여 시스템을 재기동하였으나... 역시 테이블을 못찾는 현상이 계속되었습니다... 허거걱.

그래서 제가 아는 유일한 복구 명령인 vacuum 명령을 리눅스 콘솔에서도 해보고(vacuumdb), psql로 들어가서도 해봤습니다... 잠깐 복구되는듯 하더니(여러개의 DB 중에서 특정한 하나의 DB에서 5~6개의 파일이 \d 명령으로 보이더군요), 다시 접속해 보니 아무소용이 없습니다(처음처럼 모든 DB의 테이블이 없다고 나옵니다).

확인 결과 PGDATA 디렉토리에는 테이블, 인덱스 관련 데이터 파일들이 멀쩡히 살아 있습니다. psql 로 특정 DB접속해서 'vacuum 테이블'명 하면 잘 실행되구요...

이런 현상들을 종합해 보면 제 짧은 소견으로는 pg_class 파일 같은 카탈로그 파일이 깨진것이 아닌가 생각해 봅니다(pg_class 파일을 Hex Editor 로 열어보면 테이블명 등 데이터가 잘 보이기는 합니다).

어떻게 하면 좋을까요??? 데이터 파일이 있으니, 수동으로 시스템 카탈로그 파일 만들어 주면 될까요?

지금은 물리적인 파일의 자료구조를 파악해서 텍스트 파일로 덤프라도 뜨려고 시도하는 중입니다...

물론, 평소에 DB백업 제대로 안한 제 잘못이라는거 잘 압니다... 저도 무지하게 반성하고 있습니다... 그러하오니, 너무 나무라지는 마시고, 제발 해결책-해결책이 아니라 해결책을 찾는 아이디어라도-을 알려주셨으면 합니다. 꼭 부탁합니다.