연락처
IBSurgeon
이 페이지는 기계 번역되었습니다. 영어 원본을 읽어보세요. English

IBSurgeon 라이브러리

모든 Firebird 및 InterBase 온디스크 구조(ODS) 버전

드미트리 쿠즈멘코 작성, 2016년 5월 24일

ODS(온디스크 구조) 번호란 무엇인가

간단히 말해, ODS(On-Disk Structure)는 특정 Firebird 또는 InterBase RDBMS 버전의 데이터베이스 파일 형식 번호입니다.

거의 모든 버전은 현재 ODS와 일부 이전 ODS를 지원하기 위해 소위 “Y-밸브"를 사용합니다. 이를 통해 서버는 이전 버전의 데이터베이스 파일로 작업할 수 있으며, 이전 서버에서 새 서버로의 전환을 단순화할 수 있습니다. 하지만 몇 가지 제한 사항이 있으며, 이에 대해서는 아래에서 설명하겠습니다.

다음 명령을 실행하여 데이터베이스의 ODS를 확인할 수 있습니다.

Code 
gstat -h database_file_name

여기서 사용자와 비밀번호는 필요 없습니다. gstat는 -h 옵션으로 데이터베이스의 물리적 부분(헤더 페이지, 번호 0)만 읽기 때문입니다.

gstat가 읽은 정보를 이해하지 못하면 예상한 것과 발견한 것을 보여주는 해당 메시지를 표시합니다.

예를 들어, Firebird 2 데이터베이스에서 InterBase 4의 gstat를 실행하면 다음과 같이 표시됩니다.

Code 
Wrong ODS version, expected 8, encountered 32779?

여기서 ODS 번호 32779가 보입니다. 이는 인코딩된 11로, Firebird 2.0 이후 높은 비트가 추가된 것입니다(16진수로 800B, 여기서 B = 11). InterBase와 Firebird 데이터베이스 간의 혼동을 피하기 위함인데, 특정 시점부터 두 제품의 ODS 번호는 같았지만 데이터베이스 형식은 매우 달랐기 때문입니다. 이해 가능한 메시지를 얻지 못하는 예외는 gstat가 firebird.msg 또는 interbase.msg를 찾을 수 없을 때입니다. 다음과 같은 메시지가 표시됩니다.

Code 
can't format message 21:3 -- message file ...msg not found

즉, Firebird 또는 InterBase 설치가 잘못되었으므로 수정해야 합니다.

몇 가지 예:

Wrong ODS version, expected 8, encountered 32779? - InterBase 4.x가 Firebird 2.x 데이터베이스를 열려고 시도

Wrong ODS version, expected 8, encountered 13? - InterBase 4.x가 InterBase 2009 데이터베이스를 열려고 시도

Wrong ODS version, expected 15, encountered 32779 - InterBase XE/XE3가 Firebird 2.x 데이터베이스를 열려고 시도

Wrong ODS version, expected 11, encountered 11 - Firebird 2.x가 InterBase 7.x 데이터베이스를 열려고 시도

Wrong ODS version, expected 11, encountered 15 - Firebird 2.x가 InterBase XE/XE3 데이터베이스를 열려고 시도

때로는 gstat가 아닌 서버에서 같은 의미의 다른 종류의 메시지를 받을 수도 있습니다.

예를 들어, Firebird 1.5 서버가 Firebird 2.x 데이터베이스를 열려고 할 때:

Code 
unsupported on-disk structure for file ...; found 32779, support 10

여기서 InterBase 4.0(1994년) 이후의 ODS 버전 표를 볼 수 있습니다.

서버 버전 주요 ODS 번호 작업 가능한 ODS 참고
InterBase 4.0/4.1 8.0
InterBase 4.2 8.2 8.2 InterBase 4.2는 ODS 8.0을 8.2로 강제 업그레이드
InterBase 5.0/5.1 9.0 8.2 InterBase 5.x는 ODS 8.0을 8.2로 강제 업그레이드
InterBase 5.5/5.6 9.1 8.2
InterBase 6.0
Firebird 1.0
Yaffil 1.0		 10.0 9.0/9.1 ODS 9.x로 작업하는 것은 위험합니다. 새 InterBase와 Firebird는 InterBase 5.x가 인식하지 못하는 새 메타데이터 형식을 사용하기 때문입니다.
Firebird 1.5 10.1 9.0/9.1/10.0 64비트 Firebird 1.5의 ODS 10.1은 32비트 ODS 10.1과 호환되지 않습니다. 이는 32/64비트 버전 간 데이터베이스 형식의 유일하게 알려진 비호환성입니다.
InterBase 7.0 11.0 10.0 Firebird 2.x의 ODS 11과 호환되지 않음
InterBase 7.1 11.1 10.0 InterBase 7.5는 InterBase ODS 11.0/11.1을 11.2로 업그레이드하며, 이는 이전 버전(7.0/7.1)과 호환되지 않습니다.
InterBase 7.5 11.2 10.0
Firebird 2.0 11.0 10.x Firebird 2.0의 ODS 11은 InterBase 7.x와 호환되지 않음
Firebird 2.1 11.1 10.x/11.0 Firebird 2.0의 ODS 11은 InterBase 7.x와 호환되지 않음
Firebird 2.5 11.2 10.x/11.x ODS 11.2는 Firebird 2.0/2.1과 호환되지 않음
Firebird 3.0 12.0 이전 ODS를 지원하지 않으며 12.0만 지원
Firebird 4.0 13.0 13.0
Firebird 5.0 13.1 13.0, 13.1 데이터베이스는 gfix -upgrade로 13.0에서 13.1로 업그레이드하거나 백업/복원으로 업그레이드할 수 있습니다.
InterBase 2007 12.0 11.x
InterBase 2009 13.1 12.0
InterBase XE, XE3 15.0 13.1 ODS 14는 어디에?
InterBase XE7 16.0 15, 13 “현재” ODS는 IBCONFIG에서 설정할 수 있습니다. 이렇게 하면 XE7은 지정된 ODS(13, 15, 16)를 기본값으로 데이터베이스(복원 포함)를 생성합니다.

ODS 업그레이드

각 서버 버전은 (InterBase XE7 제외) 생성되거나 복원된 데이터베이스에 항상 주요 ODS 번호를 사용합니다. 데이터베이스의 ODS가 서버의 주요 ODS보다 낮으면 서버가 해당 ODS를 지원하는 경우 해당 데이터베이스로 작업할 수 있습니다.

때로는 서버가 통지 없이 이전 ODS를 더 새로운 ODS로 업그레이드할 수 있습니다. 이로 인해 이전 버전으로 돌아갈 수 없게 될 수 있습니다. 예를 들어, ODS 8.0 데이터베이스를 InterBase 4.2로 열면 ODS가 8.2로 업그레이드되어 InterBase 4.0/4.1이 이해할 수 없게 됩니다. 따라서 ODS의 사소한 업그레이드는 동일한 주요 서버 버전 내에서도 데이터베이스를 호환되지 않게 만듭니다. 이는 Firebird 2.5와 InterBase 7.5에도 해당됩니다.

이전 버전으로 돌아가는 문제를 피하기 위해 서버 버전의 사소한 업그레이드 전에도 현재 서버 버전에서 백업을 수행할 것을 권장합니다.

ODS(주요 또는 사소한)의 차이는 크거나 작을 수 있습니다. 호기심이 많다면 jrd\ods.h(Firebird 오픈 소스)를 열어 ODS 간의 차이를 찾을 수 있습니다. 예를 들어, ODS 9.0은 8.x에 비해 선언적 참조 무결성, SQL 역할, 인덱스의 가비지 수집이 있습니다. 그러나 ODS 9.1은 일부 시스템 테이블에 추가된 하나의 인덱스만 9.0과 다릅니다.

주요 ODS 버전은 즉시 업그레이드할 수 없습니다. 백업/복원으로만 업그레이드할 수 있습니다.

InterBase와 Firebird 간 마이그레이션

최신 버전의 Firebird(3.0)와 InterBase(XE7)는 기능과 ODS 면에서 매우 다릅니다. 앞서 말했듯이 마지막 공통 ODS는 10이었으며, 그 이후(Firebird 2.0 및 InterBase 7.0) 데이터베이스는 형식이 호환되지 않습니다.

따라서 InterBase 7.x 또는 Firebird 1.5 이후의 기능을 사용하지 않았다면 마이그레이션이 더 쉬울 것입니다. 사용했다면 마이그레이션의 복잡성은 데이터베이스 또는 관리 프로세스에서 사용한 기능의 수에 따라 달라집니다.

현재, 수년간의 Firebird와 InterBase 개발 이후, 이 서버들의 최신 버전 간 마이그레이션은 어렵습니다.

어쨌든 이를 시도하려면 데이터베이스에서 메타데이터 스크립트를 추출한 다음 동일한 서버를 사용하여 해당 스크립트로 새 데이터베이스를 만들어야 합니다.

Code 
isql -x db.gdb …
isql -i script.ddl …

이는 데이터베이스에 잘못된 이전 메타데이터나 사용 중인 서버의 스크립트 추출 버그가 있는지 확인하기 위해 수행해야 합니다. InterBase와 Firebird는 프로시저, 트리거, 뷰(및 기타 일부 객체)를 컴파일된 형태(BLR - Binary Language Representation)로 저장하며, 백업/복원 중에 메타데이터는(SQL에서 BLR로) 다시 컴파일되지 않습니다.

이 경우, 데이터베이스가 오래 전에 생성되어 지속적으로 수정된 경우 일부 객체에 잘못된(이전) BLR이 있을 수 있습니다. 이러한 객체는 여전히 작동할 수 있지만, 이를 다시 생성(ALTER)하려고 하면 구문(또는 다른) 오류가 발생할 수 있습니다.

그런 다음 수정된 스크립트로 새 서버에서 데이터베이스를 만들 수 있습니다. 이 스크립트의 모든 비호환성을 수정한 후에는 이전 데이터베이스에서 새 데이터베이스로 데이터를 이전할 수 있습니다.

이전 서버에서 백업하고 새 서버에서 복원하는 것이 작동했다 하더라도 절대 신뢰하지 마십시오. 데이터베이스에 많은 객체가 포함된 경우 새 서버에서 모든 객체를 한 번에 확인할 수 없으므로 오류는 나중에 발생할 것입니다.

Firebird 또는 InterBase의 이전 버전으로 돌아가는 방법

때로는 다운그레이드를 수행하고 새 서버에서 돌아가야 할 수 있습니다. 이유는 다양할 수 있습니다 - 서버의 갑작스러운 버그, 성능 문제 등.

서버 업그레이드 전에 백업을 만들었다면 돌아가는 데 문제가 없을 것입니다. 하지만 그렇지 않다면 새 ODS에서 이전 ODS로 돌아가는 문제에 직면하게 됩니다.

이를 위해 새 서버와 이전 서버가 있는 컴퓨터 2대가 필요합니다. 서버 X(InterBase 또는 Firebird 버전)의 새로운 기능을 사용하지 않았다면 다음 단계를 따라 X-1로 돌아갈 수 있습니다:

  1. X-1 서버에서 gbak 유틸리티를 가져와서 X 서버에서 백업을 수행합니다.
  2. 백업을 X-1 서버로 전송한 후 복원합니다.

1단계에서 문제가 발생하는 경우 다음을 시도할 수 있습니다:

  1. X 서버에서 자체 gbak을 사용하여 백업을 수행합니다.
  2. gbak 유틸리티를 X에서 X-1로 복사합니다.
  3. X에서 가져온 gbak을 사용하여 X-1에서 백업을 복원합니다.

서버 X와 X-1 간의 로컬 프로토콜이 호환되지 않을 수 있으므로 서버 이름을 지정하는 것이 좋습니다:

Code 
gbak -b localhost:c:\dir\data.gdb

이 결과는 X-1에서 업그레이드한 이후 X 서버에서 데이터베이스 객체를 변경하지 않은 경우에만 성공합니다.

예시는 다음과 같습니다:

  • 5.x에서 4.2로 - 역할과 새로운 선언적 참조 무결성이 사용되지 않아야 합니다.
  • 6.x에서 5.x로 - 6.x가 새로운 BLR 형식을 사용하므로 메타데이터 변경이 없어야 합니다.
  • InterBase 7.x에서 Firebird로 - boolean 열과 31자를 초과하는 객체 이름이 없어야 합니다.
  • Firebird 1.5에서 InterBase로 - BIGINT 열과 트리거 및 프로시저의 새로운 SQL 확장이 없어야 합니다.
  • Firebird 2.0에서 Firebird 1.5로 - Firebird 2.0의 새로운 기능이 없어야 합니다.
  • 기타 등등

여전히 해결할 수 없는 오류가 있는 경우, 유일한 방법은 X-1 서버에서 SQL 스크립트로 데이터베이스를 생성하고 데이터를 이전하는 것입니다.

Firebird 마이그레이션 서비스

특히 원래 개발자가 포기한 레거시 Firebird 데이터베이스의 경우 마이그레이션은 복잡한 작업인 경우가 많습니다. 당사는 복잡한 Firebird 데이터베이스를 위한 종합 마이그레이션 서비스를 제공합니다. 일반 요금은 USD$2900입니다.

예를 들어, SQL 스크립트가 55MB이고 5000개 이상의 저장 프로시저, 1000개의 테이블 및 수천 개의 임시 SQL 쿼리가 있는 데이터베이스를 3개월 이내에 마이그레이션한 사례가 있습니다.

질문이 있으시면 [email protected]으로 문의해 주세요.