개인적으로 아직 그런 노가다를 해 보지는 않았습니다. 그래서 data structure 를 살펴볼 생각도 않았지요. 정말 노력에 찬사를 보냅니다. :/)
그리고 이왕 그렇게 된김에 부탁을 하나 드리고자 합니다. 이번에 얻으신 경험은 대단히 중요한 자료라고 생각합니다. 앞으로도 얼마든지 그런 일이 발생할 수 있지요.
그래서 이번에 얻으신 경험을 글로 정리해서 남겨 주셨으면 합니다. PostgreSQL 의 테이블 구조 및 복구 방법에 대한 글을 간단하게 정리해서 주신다면 더없는 영광으로 알겠습니다.
::김상기 님께서 쓰시길::
> 이 문제로 Postgres 메일링 리스트에 포스팅 해보았으나,
> 희망적인 대답이 나오지는 않더군요.
>
> 결국 닭질을 시작했습니다.
> 왜냐하면, 다섯명이서 거의 한달간 입력한 자료인데,
> 그것을 다시 그사람들에게 입력해 달라고 하기에는
> 너무도 가혹한 짓인 것 같아서 /./
>
> 문제의 테이블이 vacuum 되기 전이다는 것을 감안해서,
> 데이터가 변동되기 전에 제빨리, 테이블 파일을 복사를 해서,
> 오늘 하루 종일, 그 파일의 구조 분석에 들어갔고,
> 한 6시간 뒤즈음에 100% 복구를 했습니다.
>
> 덕분에, hexcode를 얼마나 많이 보았는지 모르겠습니다. /./
>
> 이 사태를 치르고 나니, 오직 생각 나는 것은
> 백업철저! 이것 뿐이더군요. /./
>
> 잡담: 개인적으로 기능적으로 공개용 RDBM 치고는 Postgres 만한것이
> 없어서 Postgres를 제일 많이 사용하는데, 이 사태를 격고 나니,
> Oracle의 undo log가 무진장 부럽더군요. /./
>
> 정재익 님께서 쓰시길::
>
> > 오옷.. 그런 엄청난 실수를...
> > 안타깝게도 commit 이 마지막 보루입니다.
> > 논리적으로 다시 살릴수는 없습니다.
> > PostgreSQL의 경우 로깅 시스템이 아직 불완전하여 살릴수가 없습니다.
> > 날아간 자료에 조의를... /./
> > 필히 데이터는 백업을 받으시기 바랍니다. 현재로서는 그 방법 말고는 좋은 방안이 없는 것 같습니
> 다.
>
|