Jumat, Juni 13, 2008

Migrasi Firebird 2.0x ke 2.1.x

Masalah yang sering muncul dalam migrasi database:
  • Indeks/Key. Kadang versi lama kurang ketat dalam menerapkan indeks/constraint/key, sedangkan di versi yang baru sangat ketat. Jadi indeks ini perlu diperhatikan serius.
  • User Defined Function (UDF). Seringkali UDF di versi sebelumnya tidak serta merta kompatibel dengan versi yang baru, sehingga banyak objek database yang tidak bisa digunakan sampai masalah ini terselesaikan. Kadang UDF lama sudah digantikan oleh built-in function di versi baru.
  • Tipe Data. Ini masih berhubungan dengan perkembangan produk database. Bermunculannya tipe data baru, atau ada perubahan jenis tipedata, perlu diuji lebih dalam agar data di sistem baru bisa optimal.

Indeks
Terkadang, bagi pengguna Firebird versi 2.0 kebawah, index sering jadi masalah saat restore data dari backup, sehingga harus mengambil pilihan menon-aktifkan indeks saat restore (lihat pilihan yang ada di gbak).

Untuk mengaktifkan semua indeks, berikut caranya:

SET TERM !! ;

EXECUTE BLOCK AS
DECLARE VARIABLE stmt VARCHAR(1000);
BEGIN
for select 'ALTER INDEX '||rdb$index_name ||' ACTIVE;'
from rdb$indices
where rdb$system_flag is not null and rdb$system_flag = 0
into :stmt
do EXECUTE STATEMENT :stmt;
END!!

SET TERM ; !!


Untuk Firebird 1.x yang tak ada perintah EXECUTE BLOCK, gunakan query berikut:

select 'ALTER INDEX '||rdb$index_name ||' ACTIVE;'
from rdb$indices
where rdb$system_flag is not null and rdb$system_flag = 0



UDF
Sudah banyak fungsi-fungsi yang jadi buit-in function, seperti beberapa fungsi di UDF seperti FreeAdHocUDF. Misal, F_DaysBetween dan F_MonthsBetween yang di FB 2.1.x digantikan oleh datediff.

Sudah digunakan Firebird versi LI-V2.1.1.17910 Firebird 2.1.

1 komentar:

Anonim mengatakan...

Firebird 2.1.1 ini lebih stabil dibanding versi 2.0.1 sebelumnya. Selain itu juga lebih cepat. Banyaknya built-in function baru sangat memudahkan daripada menggunakan UDF.

Setelah migrasi, tidak ada lagi masalah FB server yang restart sendiri (karena crash) kalau mengeksekusi proses-proses yang berat dengan query yang komplex dan melibatkan volume data cukup besar.