database.sarang.net
UserID
Passwd
Database
DBMS
MySQL
ㆍPostgreSQL
Firebird
Oracle
Informix
Sybase
MS-SQL
DB2
Cache
CUBRID
LDAP
ALTIBASE
Tibero
DB 문서들
스터디
Community
공지사항
자유게시판
구인|구직
DSN 갤러리
도움주신분들
Admin
운영게시판
최근게시물
PostgreSQL Q&A 1144 게시물 읽기
No. 1144
Re: Re: Re: Vacuum도중 에러 (에러는 고쳐졌지만..)
작성자
정재익
작성일
2000-06-04 09:23
조회수
18,102

이런 종류의 에러에 대해서 문서에 자세히 나와 있질 않습니다. 그냥 경험적인 얘기만 하도록 하겠습니다.

일단 pqReadData() 에서 에러가 나면서 backend 가 비정상적인 종료를 해 버리는 경우는 대부분의 경우 table 취급시 무결성 보장이 되지 않은 경우가 많습니다. PostgreSQL 의 경우 내부적으로 MVCC 라고 하여 Concurrency control 을 하고 있습니다.

대부분의 경우 이것으로 충분하지만 사용자의 실수로 어떤 작업 도중에 강제 종료를 시킨다던지 (개인적으로 vacuum 도중 강제 종료하여 이런일을 당한적이 있음), 하는 경우 자료의 안전성을 보장해 주지 못하는 경우가 있습니다. 사실 vacuum 의 경우 transaction 이 따로 열리는 것이 아니기 때문에 그럴 가능성이 크겠지요. 어찌 되었던 이런 저런 원인으로 그런 경우가 가끔 등장하는 것 같습니다.

 

그렇다면 해결법은 어떤 것이 있을까요.

기본적으로 해 볼수 있는 것이 3가지 정도 있는 것 같습니다.

 

1. postmaster backend 를 종료후 재 기동하여 본다.

2. vacuum 을 실행시켜 본다.

3. db 를 백업 받은 후 restore 시켜 본다. 이것으로 안되면 db 를 백업 받고 DBMS system 을 새로 깔고 db 를 restore 시켜 본다.

 

이상의 응급조치로 80% 정도는 해결이 되는 것 같습니다. 하지만 해결이 안되는 20%는 대부분 catalog file 이 깨어져 그런 경우가 많았습니다. 이런 경우는 거의 살리기가 힘든 경우가 많습니다. 많은 경험을 요하는 것 같습니다.

 

이렇게 생각하면 PostgreSQL 이 많이 불안하지 않은가 생각하시는 분들도 계실것인데 그렇지는 않습니다. 이런 에러의 대부분은 사용자의 취급 부주의에서 발생합니다. 아무런 이유없이 발생하는 경우는 더뭅니다. 물론 개인적으로 PostgreSQL 에서 좀더 fail_safe 에 대한 guard가 만들어 졌으면 하고 바랍니다만 현재의 정도로도 사용자가 제대로 다룬다면 충분히 안정된 시스템을 운영할 수 있다고 생각합니다.

 

> 답변 감사합니다..

>

> 여러개의 테이블중에서 2개에만 이런 에러가 발생했답니다...

> 두개의 테이블만 pg_dump로 백업받고.. drop시킨후에 다시 생성시켰더니..

> 이상없이 작동하는구요..

>

> 그런데 이 에러가 어떤 종류의 에러였는지 설명해주실 수 있으신가요..?

> 초보입장에서 어떤 조치는 못하지만 어떤 종류의 에러였는지는 알고 싶어서요..^^*

>

>

> > 데이터베이스에 에러가 났습니다.

> > 이것을 살릴 수 있는 길은 초보 입장에서는 역시나 vacuum 뿐입니다. 서버를 shutdo

> wn 시켰다가 다시

> > 기동한 후 다시 vacuum 을 실행시켜 보시기 바랍니다. 만약 이런 방법으로 살려 지

> 지 않는다면.... /./

> > 좀더 복잡한 방법으로 DB data 를 오리지널 그대로 백업 받은 후 DBMS 를 다시 설

> 치하고 data directo

> > ry 를 복구한 다음 다시 같은 방법으로 실행해 보시기 바랍니다.

> > 여기서마저 안된다면 정말... /././. 포기하세요.

> >

> > > 안녕하세요..

> > >

> > > vacuum 도중 몇개의 테이블에서 아래와 같은 에러가 발생합니다.

> > > 제가 어떠한 조치를 취할 수 있는 사항인지 알고 싶습니다.

> > > .

> > > .

> > > NOTICE: FlushRelationBuffers(st_daily, 56): block 271 is dirty (private 1,

> global 1)

> > > .

> > > .

> > > NOTICE: FlushRelationBuffers(st_daily, 56): block 94 is referenced (private

> 0, global 1)

> > > FATAL 1: VACUUM (vc_repair_frag): FlushRelationBuffers returned /2

> > > pqReadData() // backend closed the channel unexpectedly.

> > > This probably means the backend terminated abnormally

> > > before or while processing the request.

> > > The connection to the server was lost. Attempting reset: Succeeded.

[Top]
No.
제목
작성자
작성일
조회
1147PostgreSQL 7.0.1 과 ODBC for 7.0 bug fix 판이 release 되었습니다.
정재익
2000-06-04
17154
1151┕>Re: PostgreSQL 7.0.1 과 ODBC for 7.0 bug fix 판이 release 되었습니다.
Coral
2000-06-05 14:09:54
16907
1138LIKE 관련된 문의
초보
2000-06-02
17869
1141┕>Re: LIKE 관련된 문의
김종혁
2000-06-02 14:18:30
18026
1142 ┕>Re: Re: LIKE 관련된 문의
초보
2000-06-02 14:59:30
18152
1146  ┕>Re: Re: Re: LIKE 관련된 문의
정재익
2000-06-04 09:29:44
18565
1135ODBC 설정에 대하여
이용삼
2000-06-01
18986
1137┕>Re: ODBC 설정에 대하여
정재익
2000-06-01 20:13:05
18154
1140 ┕>Re: Re: ODBC 설정에 대하여
이용삼
2000-06-02 11:02:10
17711
1143  ┕>Re: Re: Re: ODBC 설정에 대하여
이용삼
2000-06-02 18:26:05
18712
1145   ┕>Re: Re: Re: Re: ODBC 설정에 대하여
정재익
2000-06-04 09:26:08
18479
1134Vacuum도중 에러 (FlushRelationBuffers....)
안재석
2000-06-01
16316
1136┕>Re: Vacuum도중 에러 (FlushRelationBuffers....)
정재익
2000-06-01 20:09:24
16558
1139 ┕>Re: Re: Vacuum도중 에러 (에러는 고쳐졌지만..)
안재석
2000-06-02 10:27:37
17113
1144  ┕>Re: Re: Re: Vacuum도중 에러 (에러는 고쳐졌지만..)
정재익
2000-06-04 09:23:12
18102
1130pqFlush() -- backend closed the channel unexpectedly.
궁금이
2000-06-01
17018
1133┕>Re: vacuum은...
Coral
2000-06-01 15:58:35
17000
1128postgre backend에관하여
이용삼
2000-06-01
16312
1129┕>Re: postgre backend에관하여
Coral
2000-06-01 13:47:54
16328
1131 ┕>Re: Re: 답변 감사 합니다.
이용삼
2000-06-01 15:25:21
15832
1132  ┕>Re: Re: Re: 답변 감사 합니다.
Coral
2000-06-01 15:55:01
15947
1125긴급 error 테이블 error!! 알려주세요.
오승준
2000-05-31
13769
1126┕>Re: 긴급 error 테이블 error!! 알려주세요.
정재익
2000-05-31 14:54:20
15117
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2024 DSN, All rights reserved.
작업시간: 0.030초, 이곳 서비스는
	PostgreSQL v16.2로 자료를 관리합니다