postgresql.log에 있는 내용도 좀 적어주시구요

또한

pg_dump -v

vacuumdb -v

이런 옵션을 추가했을때 나오는 메시지도 좀 적어주세요.

보아하니 shared memory를 얻지 못해서 서버 프로세스가 죽는 것 같네요.

shared memory랑 세마포어 산정하는 계산식은 메뉴얼에 있습니다.

그렇게 어렵지 않을거에요. connection 숫자가지고 간단히 계산했던 것 같구요. 그냥 그 이상 크게 잡으면 문제 없을겁니다. 어짜피 최대값이니 크게 잡는다고 문제가 되지는 않을거에요. 메모리 용량만 충분하다면 말이죠.

두개의 명려을 내리면 아래와같이 나오는군요.

현재 로그 생성은 않하고있어요

./vacuumdb -v -d dbname
CPU 0.11s/0.01u sec elapsed 0.45 sec.
INFO:  vacuuming "public.user_info2"
INFO:  index "user_info2_pkey" now contains 0 row versions in 1 pages
DETAIL:  0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO:  "user_info2": found 0 removable, 0 nonremovable row versions in 0 pages
DETAIL:  0 dead row versions cannot be removed yet.
There were 0 unused item pointers.
0 pages are entirely empty.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO:  vacuuming "pg_toast.pg_toast_1181064"
INFO:  index "pg_toast_1181064_index" now contains 0 row versions in 1 pages
DETAIL:  0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO:  "pg_toast_1181064": found 0 removable, 0 nonremovable row versions in 0 pages
DETAIL:  0 dead row versions cannot be removed yet.
There were 0 unused item pointers.
0 pages are entirely empty.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO:  vacuuming "public.user_info1"
INFO:  index "user_info1_pkey" now contains 0 row versions in 1 pages
DETAIL:  0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO:  "user_info1": found 0 removable, 0 nonremovable row versions in 0 pages
DETAIL:  0 dead row versions cannot be removed yet.
There were 0 unused item pointers.
0 pages are entirely empty.
CPU 0.00s/0.00u sec elapsed 0.00 sec.
INFO:  vacuuming "pg_toast.pg_toast_1181069"
INFO:  index "pg_toast_1181069_index" now contains 0 row versions in 1 pages
DETAIL:  0 index pages have been deleted, 0 are currently reusable.
CPU 0.00s/0.00u sec elapsed 0.01 sec.
INFO:  "pg_toast_1181069": found 0 removable, 0 nonremovable row versions in 0 pages
DETAIL:  0 dead row versions cannot be removed yet.
There were 0 unused item pointers.
0 pages are entirely empty.
CPU 0.00s/0.00u sec elapsed 0.01 sec.
INFO:  vacuuming "public.user_list"
WARNING:  relation "user_list" TID 17741/23: OID is invalid

./pg_dump -v -d dbname

pg_dump: dumpClasses(): SQL command failed
pg_dump: Error message from server: ERROR:  invalid memory alloc request size 1634167144
pg_dump: The command was: FETCH 100 FROM _pg_dump_cursor
pg_dump: *** aborted because of error

로그가 심심찮은데요.

메모리 문제라면, 솔라리스 메뉴얼 찾아서 공유 메모리를 늘리면 되겠지만,

예감에 db 전체가 깨졌는 것 같은 불길한 예감이 듭니다.

만일 이런 경우면, 정말 완벽한 저수준으로 자료를 추출해서 새 db 를 만들든지, 아니면, 백업 파일을 이용하는 수 밖에...

일단, vacuum -f 대신에, 그냥 vacuum 명령이 각 테이블 별로 잘 작동되는지부터 살펴보셔야할 듯합니다.

몇개의 테이블을 검사하니까. 아래와같이 나오는군요.

이것이 깨진게 맞는지 모르겠군요.?

자료를 저수준으로 뽑을려면 어떻게 해야할까요?

[mail]./vacuumdb -U postgres -d dbname -t user_list
WARNING:  relation "user_list" TID 17741/23: OID is invalid

VACUUM
[mail][mail]
[mail]./vacuumdb -U postgres -d dbname -t addr
WARNING:  relation "addr" TID 257/36: OID is invalid
VACUUM

자료를 저수준으로 복구 해야할 상황이다고 확실히 판단되기까지의 과정은 다음과 같습니다.

1. 제일 먼저 해볼일,

select * from tablename

이렇게 해서 자료가 모두 뽑혀진다면, 이 구문으로 자료를 모두 구하면 되겠네요.

2. 윗 명령의 결과가 전체 자료를 모두 못가져온다면, 일단, pg_resetxlog 프로그램을 실행해서 xlog 를 정리해보십시오.

그다음, select * from tablename 명령이 정상 작동한다면, 자료를 가져 오면 될터이고.

3. 이것도 안되면 백업파일에서 자료를 가져오십시오. 그리고는 상사에게 "마지막 백업 자료가 이것밖에 없어서 여기까지만 복구되었다. 그 사이 자료를 복구하지 못했다"고 하고, 태연한척 하는 것이고,

4. 백업파일도 없고, 자료를 못살려내면, 퇴사를 해야할 상황인데, 다른 더 좋은 자리가 있으면 퇴사를 하는 편이 낫고요. 그것도 안된다면, hex code 덤프 프로그램을 가지고 직접 바이너리 파일을 분석해가면서 자료를 뽑으십시오.

부디 마지막 상황까지 가는 일이 없기를...

제가 예전에 4번을 시도한 적이 있었는데요. 자료양이 많지만 않다면 못할 일도 아니지만 가비지 자료가 하도 많아서 포기했었습니다.

그런데 공유메모리 문제는 해결한 상황인가요?

저도 4번은 일어나지 않기를 바라겠습니다.

제가 보기에도..DB가 깨진것 같습니다.

일단 먼저 table list들을 pg_dump -t 옵션을 주면서

하나씩 dump를 받으세요.

그런다음에 깨진 table들을 정리해놓습니다.

그러면서 깨진  Table을 PG_dump를 하는데

아마 깨진 부분부터 dump가 안될껍니다.

깨진 부분까지의 데이터를 살펴보시고

깨졌다고 예상되는 데이터를 수동 복구 또는 삭제하면서

복구 하셔야할것 같습니다.

생각에 데이터의 OID가 사라진것 같은데

그 데이터를 삭제하시던지.. 하셔야할꺼 같습니다.