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

IBSurgeon 라이브러리

모든 Firebird 및 InterBase ODS(On-Disk-Structure) 버전

작성자: Dmitry Kuzmenko, 2016년 5월 24일

ODS(On-Disk Structure) 번호란 무엇인가

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

거의 모든 버전은 소위 “Y-valve"를 사용하여 현재 ODS와 일부 이전 ODS를 지원합니다. 이를 통해 서버는 이전 버전의 데이터베이스 파일과 함께 작동할 수 있으며 이전 서버에서 새 서버로의 전환을 간소화합니다. 그러나 몇 가지 제한 사항이 있으며, 이에 대해서는 아래에서 설명합니다.

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

Code 
gstat -h database_file_name

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

gstat이 읽은 정보를 이해하지 못하면, 무엇을 예상했고 무엇을 발견했는지에 대한 해당 메시지를 표시합니다.

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

Code 
Wrong ODS version, expected 8, encountered 32779?

여기서 ODS 번호 32779가 보입니다. 이는 인코딩된 11이며, InterBase와 Firebird 데이터베이스 간의 혼동을 피하기 위해 Firebird 2.0부터 상위 비트가 추가되었습니다(16진수로는 800B, 여기서 B = 11). 왜냐하면 어느 시점부터 두 제품이 동일한 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 데이터베이스는 13.0에서 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 IBCONFIG에서 “현재” ODS를 설정할 수 있습니다. 이렇게 하면 XE7은 지정된 ODS(13, 15, 16)를 기본값으로 사용하여 데이터베이스를 생성합니다(복원 포함).

ODS 업그레이드

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

때로는 서버가 알리지 않고 이전 ODS를 더 새로운 ODS로 업그레이드할 수 있습니다. 이로 인해 이전 버전으로 되돌릴 수 없게 될 수 있습니다. 예를 들어, InterBase 4.2로 ODS 8.0 데이터베이스를 열면 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. X에서 X-1로 gbak 유틸리티를 복사합니다.
  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로 - 불리언 컬럼과 31자보다 긴 객체 이름이 없어야 합니다.
  • Firebird 1.5에서 InterBase로 - BIGINT 컬럼과 트리거 및 프로시저의 새로운 SQL 확장이 없어야 합니다.
  • Firebird 2.0에서 Firebird 1.5로 - 새로운 Firebird 2.0 기능이 없어야 합니다.
  • 기타 등등

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

Firebird Migration service

종종 마이그레이션은 복잡한 작업이며, 특히 원래 개발자들에 의해 방치된 레거시 Firebird 데이터베이스의 경우 더욱 그렇습니다. 저희 회사는 복잡한 Firebird 데이터베이스를 위한 종합 마이그레이션 서비스를 제공합니다. 기본 요금은 미화 2,900달러입니다.

예를 들어, SQL 스크립트가 55메가바이트이고 5,000개 이상의 저장 프로시저, 1,000개의 테이블, 수천 개의 임시 SQL 쿼리를 포함한 데이터베이스를 3개월 이내에 마이그레이션한 적이 있습니다.

질문이 있으시면 [email protected]으로 연락해 주십시오.