Tất cả các phiên bản Cấu trúc Trên Đĩa (ODS) của Firebird và InterBase

By Dmitry Kuzmenko, 24-May-2016

Số ODS (On-Disk Structure) là gì

Nói một cách đơn giản, ODS (On-Disk Structure) là một con số chỉ định dạng tệp cơ sở dữ liệu cho một phiên bản cụ thể của Firebird hoặc InterBase RDBMS.

Hầu hết các phiên bản đều sử dụng cái được gọi là “Y-valve” để hỗ trợ ODS hiện tại và một số ODS cũ. Điều này cho phép máy chủ làm việc với các tệp cơ sở dữ liệu từ các phiên bản trước và đơn giản hóa việc chuyển đổi từ máy chủ cũ sang máy chủ mới. Nhưng có một số hạn chế, sẽ được mô tả ở phần sau.

Bạn có thể tìm ra ODS của cơ sở dữ liệu bằng cách chạy lệnh sau

gstat -h database_file_name

Không cần tên người dùng và mật khẩu ở đây, vì gstat với tùy chọn -h chỉ đọc phần vật lý của cơ sở dữ liệu (trang tiêu đề, số 0).

Nếu gstat không hiểu thông tin đọc được, nó sẽ hiển thị thông báo tương ứng - những gì nó mong đợi và những gì nó tìm thấy.

Ví dụ, nếu chúng ta chạy gstat từ InterBase 4 trên cơ sở dữ liệu từ Firebird 2, nó sẽ hiển thị

Wrong ODS version, expected 8, encountered 32779?

Ở đây, bạn thấy số ODS 32779 - đây là số 11 được mã hóa, với bit cao được thêm vào từ Firebird 2.0 (trong hệ hexa sẽ là 800B, trong đó B = 11), để tránh nhầm lẫn giữa cơ sở dữ liệu InterBase và Firebird, vì từ một thời điểm nào đó chúng có cùng số ODS, nhưng định dạng cơ sở dữ liệu rất khác nhau. Ngoại lệ để có được thông báo dễ hiểu là khi gstat không thể tìm thấy firebird.msg hoặc interbase.msg. Nó sẽ hiển thị một cái gì đó như

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

Vì vậy, điều này có nghĩa là bạn có cài đặt Firebird hoặc InterBase không chính xác, và cần khắc phục điều đó.

Một số ví dụ:

Wrong ODS version, expected 8, encountered 32779? - InterBase 4.x cố gắng mở cơ sở dữ liệu Firebird 2.x

Wrong ODS version, expected 8, encountered 13? - InterBase 4.x cố gắng mở cơ sở dữ liệu IntrBase 2009

Wrong ODS version, expected 15, encountered 32779 - InterBase XE/XE3 cố gắng mở cơ sở dữ liệu Firebird 2.x

Wrong ODS version, expected 11, encountered 11 - Firebird 2.x cố gắng mở cơ sở dữ liệu InterBase 7.x

Wrong ODS version, expected 11, encountered 15- Firebird 2.x cố gắng mở cơ sở dữ liệu InterBase XE/XE3

Đôi khi bạn có thể nhận được một loại thông báo khác, từ máy chủ (không phải từ gstat) nhưng có cùng ý nghĩa.

Ví dụ, khi máy chủ Firebird 1.5 cố gắng mở cơ sở dữ liệu Firebird 2.x:

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

Ở đây bạn có thể thấy bảng phiên bản ODS, kể từ InterBase 4.0 (1994).

Nâng cấp ODS

Mỗi phiên bản máy chủ luôn sử dụng (ngoại trừ InterBase XE7) số ODS chính của nó cho cơ sở dữ liệu được tạo hoặc khôi phục. Nếu ODS của cơ sở dữ liệu nhỏ hơn ODS chính của máy chủ, máy chủ có thể làm việc với cơ sở dữ liệu đó nếu nó hỗ trợ ODS của nó.

Đôi khi máy chủ có thể nâng cấp ODS cũ lên một ODS mới hơn, mà không thông báo. Điều này có thể dẫn đến việc không thể quay trở lại phiên bản trước. Ví dụ, nếu bạn mở cơ sở dữ liệu với ODS 8.0 bằng InterBase 4.2, nó sẽ nâng cấp ODS lên 8.2, mà InterBase 4.0/4.1 không hiểu được. Vì vậy, việc nâng cấp nhỏ của ODS làm cho cơ sở dữ liệu không tương thích trong cùng một phiên bản máy chủ chính. Điều này cũng đúng với Firebird 2.5 và InterBase 7.5.

Để tránh các vấn đề khi quay trở lại phiên bản trước, chúng tôi khuyến nghị thực hiện backup trên phiên bản máy chủ hiện tại ngay cả trước khi nâng cấp nhỏ phiên bản máy chủ của bạn.

Sự khác biệt giữa các ODS (chính hoặc phụ) có thể rất lớn, hoặc nhỏ. Nếu bạn đủ tò mò, bạn có thể mở jrd\ods.h (Firebird mã nguồn mở) và tìm sự khác biệt giữa các ODS. Ví dụ, ODS 9.0 so với 8.x có tính toàn vẹn tham chiếu khai báo, vai trò SQL, thu gom rác trong chỉ mục. Nhưng ODS 9.1 chỉ khác 9.0 bởi một chỉ mục, được thêm vào một bảng hệ thống nào đó.

Lưu ý rằng phiên bản ODS chính không thể được nâng cấp ngay lập tức. Bạn chỉ có thể nâng cấp nó bằng backup/restore.

Di chuyển giữa InterBase và Firebird

Các phiên bản cuối của Firebird (3.0) và InterBase (XE7) rất khác nhau, về tính năng và ODS. Như đã nói trước đây, phiên bản chung cuối cùng là ODS 10, và kể từ đó (Firebird 2.0 và InterBase 7.0) cơ sở dữ liệu không tương thích với định dạng của nó.

Vì vậy, việc di chuyển sẽ dễ dàng hơn nếu bạn không sử dụng các tính năng kể từ InterBase 7.x hoặc Firebird 1.5. Nếu có - độ phức tạp của việc di chuyển sẽ phụ thuộc vào số lượng tính năng bạn đã sử dụng trong cơ sở dữ liệu hoặc quy trình quản trị.

Hiện tại, sau nhiều năm phát triển Firebird và InterBase, việc di chuyển giữa các phiên bản mới nhất của các máy chủ này là khó khăn.

Dù sao, nếu bạn cố gắng làm điều này, bạn cần trích xuất script metadata từ cơ sở dữ liệu, và sau đó cố gắng tạo cơ sở dữ liệu mới từ script đó, sử dụng cùng một máy chủ.

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

Điều này cần được thực hiện để kiểm tra xem có bất kỳ metadata cũ xấu nào trong cơ sở dữ liệu của bạn hoặc lỗi trích xuất script trong máy chủ bạn sử dụng. InterBase và Firebird lưu trữ thủ tục, trigger và view (và một số đối tượng khác) ở dạng biên dịch (BLR - Binary Language Representation), và trong quá trình backup/restore metadata không được biên dịch lại (từ SQL sang BLR).

Trong trường hợp này, nếu cơ sở dữ liệu được tạo từ lâu và liên tục được sửa đổi, có thể có BLR không chính xác (cũ) cho một số đối tượng. Những đối tượng này vẫn có thể hoạt động, nhưng cố gắng tạo lại chúng (ALTER) có thể gây ra lỗi cú pháp (hoặc lỗi khác).

Sau đó bạn có thể cố gắng tạo cơ sở dữ liệu từ script đã sửa tại máy chủ mới. Sau khi bạn sửa tất cả các không tương thích trong script này, bạn có thể bơm dữ liệu từ cơ sở dữ liệu cũ sang cơ sở dữ liệu mới.

Ngay cả khi bạn đã thử backup trên máy chủ cũ và restore tại máy chủ mới, và nó hoạt động - đừng bao giờ tin điều này. Nếu cơ sở dữ liệu của bạn chứa nhiều đối tượng, bạn không thể kiểm tra tất cả chúng cùng một lúc trên máy chủ mới, vì vậy, lỗi sẽ xuất hiện một thời gian sau đó.

Làm thế nào để quay trở lại phiên bản trước của Firebird hoặc InterBase

Đôi khi, bạn có thể cần thực hiện hạ cấp và quay trở lại từ máy chủ mới. Lý do có thể khác nhau - lỗi đột ngột trong máy chủ, vấn đề hiệu suất, và vân vân.

Nếu bạn đã thực hiện backup trước khi nâng cấp máy chủ, sẽ không có vấn đề gì để quay trở lại. Nhưng nếu không, bạn sẽ phải đối mặt với vấn đề quay trở lại từ ODS mới sang ODS cũ.

Để làm điều đó, bạn sẽ cần 2 máy tính với máy chủ mới và máy chủ cũ. Nếu bạn chưa sử dụng bất kỳ tính năng mới nào của máy chủ X (phiên bản InterBase hoặc Firebird), bạn có thể quay trở lại X-1 theo các bước sau:

1. Lấy tiện ích gbak từ máy chủ X-1, và thực hiện backup bằng nó tại máy chủ X
2. Chuyển backup sang máy chủ X-1, và khôi phục nó

Nếu có một số vấn đề ở bước 1, bạn có thể thử

1. Thực hiện backup tại máy chủ X, sử dụng gbak của nó
2. Sao chép tiện ích gbak từ X sang X-1
3. Khôi phục backup tại X-1 sử dụng gbak từ X

Lưu ý rằng giao thức cục bộ giữa máy chủ X và X-1 có thể không tương thích, vì vậy, tốt hơn là chỉ định tên máy chủ:

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

Kết quả sẽ thành công chỉ với điều kiện là bạn chưa thay đổi bất kỳ đối tượng cơ sở dữ liệu nào tại máy chủ X kể từ khi bạn nâng cấp từ X-1.

Dưới đây là các ví dụ:

• Từ 5.x sang 4.2 - không có vai trò và tính toàn vẹn tham chiếu khai báo mới phải được sử dụng
• Từ 6.x sang 5.x - không có thay đổi metadata, vì 6.x sử dụng định dạng BLR mới
• Từ InterBase 7.x sang Firebird - không có cột boolean và tên đối tượng dài hơn 31 ký tự.
• Từ Firebird 1.5 sang InterBase - không có cột BIGINT và tiện ích mở rộng SQL mới trong trigger và thủ tục
• Từ Firebird 2.0 sang Firebird 1.5 - không có chức năng mới nào của Firebird 2.0.
• Và vân vân

Nếu vẫn còn lỗi, không thể sửa được, cách duy nhất là tạo cơ sở dữ liệu tại máy chủ X-1 từ script SQL và bơm dữ liệu.

Dịch vụ di chuyển Firebird

Thường thì việc di chuyển là nhiệm vụ phức tạp, đặc biệt đối với các cơ sở dữ liệu Firebird cũ, đã bị các nhà phát triển ban đầu bỏ rơi. Công ty chúng tôi cung cấp dịch vụ di chuyển toàn diện cho các cơ sở dữ liệu Firebird phức tạp. Phí thông thường là 2900 USD.

Ví dụ, chúng tôi đã di chuyển cơ sở dữ liệu có script SQL là 55 Megabyte, với hơn 5000 thủ tục lưu trữ, 1000 bảng và vài nghìn truy vấn SQL ad hoc, trong vòng chưa đầy 3 tháng.

Nếu bạn có bất kỳ câu hỏi nào, vui lòng liên hệ với chúng tôi [email protected]