이런 두가지의 경우 테이블이나 데이터셋을 접근하는 경우, “Internal gds software-consistency check”, “Database file appears corrupt”, “Wrong record length”라는 에러 메시지를 토해낸다. 이런 경우 서버를 중지시키고 데이터베이스 파일을 복사하고 다시 서버를 시작하는 것이 좋은 방법이다. 복사한 데이터베이스 파일은 복구서비스에 보내거나 복구를 시도한다.
데이터베이스 복구 4가지 순서
- 데이터베이스를 확인한다 : gfix로 데이터베이스 구조를 확인한다. 이는 “-v -f” 파라미터를 사용하면 된다.
gfix -v -f -user sysdba -pass masterkey server:/경로/database.fdb
gfix는 데이터베이스 구조를 확인하고 문제가 있으면 에러메시지를 보여준다. 에러 메시지가 없다면 데이터베이스 파일은 문제가 없음을 의미한다. - 백업을 준비한다 : gfix를 다시 사용하여 백업을 위한 준비를 한다. 이는 “-mend” 파라미터를 사용하면 된다.
gfix -mend -user sysdba -pass masterkey server:/경로/database.fdb - 백업을 생성한다 : 이는 굉장히 중요한 단계로 만약 이 단계에서 실패하면 파이어버드의 툴로는 데이터베이스를 복구할 수 없다. gbak이란 툴을 이용하여 데이터베이스의 파일의 백업을 생성한다. 데이터베이스에 복구할 수 없는 오류가 있다면 gbak으로 하는 작업은 실패한다.
gbak -b -v -user sysdba -pass masterkey server:/경로/database.fdb /경로/backup.fbk
백업을 생성하는 곳은 로컬 드라이버를 이용하는 것이 낫다. 오류가 없다면 제대로 복구되었음을 의미한다. - 백업을 복구한다 : 백업을 데이터베이스로 파일로 복구한다. 이는 gbak을 다시 이용하면 된다.
gbak -c -r -v -user sysdba -pass masterkey /경로/backup.fbk server:/경로/database.fdb
[댓글] 1) 데이터베이스를 백업할 때, 항상 ”-g” 파라미터를 쓰는 것이 좋습니다. 만약 이 파라미터를 사용하지 않으면 서버는 가바지콜렉션을 초기화하고, 망가진 chain이 있다면 데이터베이스 백업은 실패하게 됩니다.
2) “-c -r” 파라미터를 사용하지 말아야 합니다. 이는 모순 어법이기 때문이며, 망가진 데이터베이스와 복구된 데이터베이스가 같은 이름이면 원본 데이터베이스의 내용들을 지워버리게 됩니다. 또한 “-r” 옵션은 2.x 버전의 파이어버드에서는 작동하지 않는데 이는 “-replace”로 되었기 때문입니다. 그래서 “-c” 파라미터를 사용하고 tmp.fdb같은 다른 이름으로 복구를 해야 합니다. [해석이 어물어물]
출처 : http://daniel-albuschat.blogspot.com/2009/12/firebird-database-corruption-and-what.html
Related posts:
댓글 없음:
댓글 쓰기