Migrasi data paradox ke postgresql

  Hari ini kita memerlukan melakukan migrasi data dari program kita yang lama, yang memakai database paradox untuk di migrasi ke postgresql.

setelah mencari kesana kemari dan tidak menemukan tools yang bisa langsung mentransfer dari paradox ke postgresql, akhirnya kita menemukan tools yang gratis, yang merubah paradox ke excel. Nama toolsnya adalah Paradox DBase Reader buatan smartmox.

http://www.sportamok.com/development/delphi/8-paradox-dbase-reader

cukup lah jika bisa di transfer ke excel, karena dari excel kita bisa mentrasfernya ke postgresql melalui libreoffice.

tools ini gratis dan free

Migrasi data ke database yang lain

  Apakah anda mendapat tugas untuk melakukan konversi database dari Mysql menuju PostgreSQL, atau dari MS-SQL menuju MySQL, atau dari ACCESS menuju ORACLE ?

Jika iya, maka perlu saya informasikan, bahwasannya pekerjaan melakukan konversi database dari satu database menuju database yang lain, bukanlah pekerjaan yang mudah. Mungkin di internet, kita bisa menemukan suatu software yang mengatakan dapat melakukan migrasi dengan mudah, tinggal klik dan selesai. Tidak, bukan seperti itu, tidak ada yang namanya migrasi antar database dilakukan dengan mudah. Selalu saja ada pekerjaan manual di dalamnya.

Berikut adalah langkah langkah migrasi database yang saya jadikan acuan :

  • Buat sendiri Struktur Database-nya
    • maksudnya adalah, anda harus membuat sendiri struktur database di database yang baru, jangan di serahkan 100% ke software migrasi.
    • perhatikan data-data yang memiliki angka desimal di belakang koma
  • Upload data dengan software migrasi
  • Jika tidak ada, upload dengan menggunakan file text, csv atau yang lainnya.
  • Lakukan simulasi migrasi database terlebih dahulu, untuk melihat tingkat validasi data anda. Semakin banyak simulasi akan semakin baik.

Bagaimana dengan anda ?

Extract table dari file Full Backup

  Hi semua, jumpa lagi. Sudah lama rasanya tidak update blog ini lagi. Kali ini saya akan berbagi pengalaman saya beberapa hari terakhir ini. Salah seorang rekan team di tempat saya, sering kali meminta untuk di restore-kan data dari tabel tertentu yang telah di backup hari sebelumnya. Problemnya adalah, file backup saya adalah full-backup dalam bentuk file *.sql.

Step untuk restore tersebut adalah sebagai berikut :

  • Siapkan file backup yang akan di restore salah satu tabelnya
  • Buka file tersebut dengan text editor, misalnya notepad, wordpad, gedit, vi dan lain lain
  • Cari awal dari tabel yang akan di restore, bisa dengan search nama tabel
  • Copy blok data insert yang paling awal dari tabel tersebut, hingga yang paling akhir
  • dan paste di file text yang baru
  • Simpan file test tersebut dalam format *.sql.
  • Eksekusi / restore file tersebut di database tujuan.

Nah ternyata step tersebut menjadi rumit untuk saya laksanakan, mengapa?
Karena file full backup yang saya miliki ukurannya sangat besar , 3 GB. Ini akan mengakibatkan text editor yang saya pergunakan tidak mampu untuk membaca file tersebut. Saya mempergunakan gedit, dan programnya tidak kuat, hang.

Akhirnya saya harus mencari fungsi file text di linux untuk melakukan pemotongan data itu. Berikut adalah step yang saya lakukan :

  • Siapkan file backup yang akan di restore salah satu tabelnya
  • Saya masuk ke console linux.
  • Saya pakai fungsi fgrep di linux untuk mencari awal tabel yang akan saya copy.
    • $> fgrep -n “nama_tabel” nama_file_backup.sql | more
  • Jika sudah muncul datanya, saya cari baris yang paling awal menampilkan perintah insert terhadap tabel yang saya cari. Saya catat nomor baris nya.
  • Kemudian, saya cari baris yang paling akhir menampilkan perintah insert terhadap tabel yang saya cari. Saya catat nomor baris nya.
  • Jika sudah mencatat baris awal dan akhirnya, sekarang saatnya kita copy data dari awal baris itu ke akhir barisnya, ke file yang lain. Saya pakai perintah sed.
    • sed -n ‘81484141,81498477’p nama_file_backup.sql > file_restore.sql
  • Eksekusi / restore file tersebut di database tujuan.

Nah selesai sudah, dengan ini, berapapun ukuran file backup yang saya miliki, saya tetap bisa melakukan restore. Bagaimana dengan rekan rekan yang lain ? apakah ada alternatif yang lainnya ?

Memindahkan MS-Access Database ke PostgreSQL

  Beberapa waktu yang lalu, saya memiliki kebutuhan untuk mentransfer database MS-Access ke dalam PostgreSQL. Sempat terpikir untuk melakukan transfer data secara manual dengan penggunakan pentaho, tetapi karena jumlah tabel yang cukup banyak dan waktu yang sangat singkat, sehingga saya memutuskan untuk mencari software gratisan untuk melakukan proses transfer tersebut. Akhirnya setelah mencari melalui GOOGLE, saya menemukan software yang dimaksud, yaitu “Access To PostgreSQL” buatan dari BullZip. Software gratis inilah yang mengkonversikan database MS-Access saya ke PostgreSQL.

  Berikut langkah langkah saya dalam menggunakan software ini :

  • Download dan Install terlebih dahulu PostgreSQL ODBC di sini. Software ini di test dengan odbc versi 8.4.
  • Buat Database Target di dalam PostgreSQL.
  • Jalankan Program “Access To PostgreSQL” dan pilih ms-access file sebagai database sumber dan masukkan database postgresql yang baru sebagai database tujuan.
  • Apabila anda memiliki tabel dengan ukuran yang besar, misal 500 ribu record, maka upload tabel tersebut secara terpisah, untuk menghindari kegagalan.

Software ini sangat bagus, dan saya rekomendasikan untuk teman teman yang ingin melakukan konversi. Silahkan mencoba.

Desain Table untuk replikasi

  Hi, sudah lama blog ini tidak saya update, tentu saja alasan paling utama adalah kesibukan. Klise sekali ya, jadi ingat para blogger yang lain, selalu memakai alasan yang sama, sibuk.

Baiklah, topik kita kali ini adalah desain tabel yang akan di pergunakan untuk replikasi. Replikasi data ditempat kita adalah Master to Master, artinya setiap lokasi dapat melakukan update data dan masing masing lokasi akan melakukan sinkronisasi dengan lokasi lainnya. Desain tabel ini berdasarkan pengalaman yang kita miliki selama ini, yaitu :

  • Primary Key
    • Setiap record yang tercatat harus memiliki primary key, yang dapat dipergunakan untuk identifikasi unik record tersebut. Tingkat ke-unik-annya harus mempertimbangkan kode lokasi dan kode perusahaan.
    • Dengan pertimbangan di atas, pada saat replikasi, kita yakin bahwasannya data setiap record itu adalah unik, tidak akan mungkin tercampur / bertabrakan dengan data dari lokasi lainnya.
    • Contoh primary key nya :
      • A1   : A untuk kode lokasi, 1 untuk no urut data
      • XA1 : X untuk kode perusahaan, A untuk kode lokasi, 1 untuk no urut data.
  • Tanggal Pembuatan
    • Kita harus mencatat juga kapan record tersebut di catat di dalam tabel. Umumnya kita kombinasikan dengan constraint DEFAULT.
    • Contoh untuk Postgresql dan Oracle :
      • created_date timestamp default NOW()
      • created_by numeric(8)
  • Tanggal Perubahan
    • Kita juga harus mencatat kapan record tersebut berubah/diubah di dalam tabel. Pencatatannya dilakukan pada saat kita menjalankan perintah UPDATE atau REPLACE.
    • Contoh untuk Postgresql dan Oracle :
      • modified_date timestamp
      • modified_by numeric(8)

ID yang unik adalah suatu keharusan, sementara untuk tanggal Pembuatan dan perubahan sebagai data pendukung terhadap status record tersebut. Tentusaja data pendukungnya dapat bertambah sesuai kebutuhan, tetapi kolom kolom yang diatas itu adalah keharusan di tempat kita. Jadi standard DDL untuk tabel yang akan di replikasi seperti berikut :

<!-- Center Pane -->
Create Table Master_tbl
( id varchar(16),
  ...
  ...
  created_date timestamp default NOW(),
  created_by numeric(8),
  modified_date timestamp,
  modified_by numeric(8),
  contraint master_tbl_pk primary key (id)
);

Bagaimana dengan teman teman ?

Nulls hanya untuk tipe data berbasis character dan timestamp

  Bruse momjian adalah salah satu orang penting di dunia PostgreSQL, salah satu pendiri The PostgreSQL Global Development Group, dan dia sudah bekerja dengan PostgreSQL sejak tahun 1996. Beliau juga menulis buku yang berjudul “PostgreSQL: Introduction and Concepts“.

Menurut beliau, nulls adalah nothing atau pointer yang tidak menunjuk kemana mana. Untuk itipe data character, nulls dapat ditulis dengan spasis kosong atau zero length, sedangkan untuk numeric dan timestamp, nulls harus di tulis dengan apa ? 0, -1 atau yang lain ? timestamp dengan 01/01/01 ?

Berikut adalah file presentasi beliau mengenai Nulls, silahkan diambil disini. Presentasi ini telah di presentasikan dalam ajang pgCon 2013. Bruce juga menjelaskan apa, mengapa dan bagaimana pemakaian nulls yang benar. Benar benar penjelasan yang menarik untuk disimak. Sayangnya tidak ada penjelasan mengenai performance database apabila kita menggunakan nulls, jadi kita tidak tahu apa efek dari pemakaian nulls terhadap performance database kita, lebih cepat atau lebih lambat.

Berdasarkan presentasi tersebut, saya dapat mengambil kesimpulan bahwa nulls sebaiknya hanya dipergunakan untuk tipe data yang berbasis character, semisal tipe data character, text, atau variable character. Untuk tipe data berbasis numeric dan timestamp lebih baik menghindari nulls.

Untuk tipe data numeric, saya memiliki trik untuk menghindari nulls yakni dengan selalu menambahkan integrity NOT NULL DEFAULT 0. Jadi jika saya melakukan insert terhadap tabel tersebut dan tidak mencantumkan suatu value, maka secara otomatis database akan menambahkan angka 0.

Sementara untuk tipe data berbasis timestamp, saya memiliki kesulitan, karena dalam beberapa kasus kolom tersebut tidak dapat dikenakan integrity NOT NULL, sehingga nulls tetap diperkanankan. Integrity DEFAULT juga tidak dapat dikenakan karena saya tidak dapat menentukan tanggal berapa yang di pergunakan sebagai nilai default. Contoh, setiap tabel saya memiliki kolom MODIFIED_DATE, dan kolom ini hanya berisikan data pada saat terjadi perintah UPDATE. Sehingga pada saat dia berisikan nulls,saya dapat mengetahui bahwa memang belum pernah terjadi perintah UPDATE pada baris data tersebut. Seandainya saya menentukan default tanggalnya adalah 17/08/1945 dan menerapkan integrity NOT NULL DEFAULT TO_DATE(’17/08/1945′,’DD/MM/YYY’), maka akan muncul permasalahan pada penampilan data, karena secara default nilai kolom tersebut adalah ’17/08/1945′ padahal saya ingin melihat kolom tersebut dengan kosong untuk menyatakan tidak ada proses UPDATE.

Jadi, untuk saat ini, nulls akan saya terapkan untuk tipe data berbasis charcter dan timestamp. Bagaimana dengan teman teman ?

Replikasi melambat setelah tabel reorganize dengan CTAS

  Teman teman pasti tahu kalau saya memakai Bucardo untuk replikasi. Nah kejadian terakhir yang saya alami dengan bucardo berhubungan dengan tabel reorganisasi. Begini ceritanya.

Saya memiliki 3 server yang saya pergunakan untuk master to master replication dan hanya salah satu server saja yang di pergunakan sebagai server transaksi utama, lainnya untuk keperluan backup dan baca data. Nah saat saya melakukan analisa terhadap server untuk keperluan backup dan data ini, saya menemukan beberapa tabel yang ukurannya 3x lebih besar dari asalnya di server transaksi utama. Saya cek apakah mungkin tabelnya ter-fragmentasi atau tidak. Ternyata benar ada fragmentasi disana.

Akhirnya tabel yang ter-fragmentasi itu saya betulkan dengan metode CTAS. Berhasil. Salah satu tabel tersebut setiap malamnya melakukan update data sekitar 150k records. Jadi kalau dengan bucardo akan menjadi 300K records. Saya berkeyakinan bahwa semuanya akan lancar.

Esoknya, hari ke 1, sewaktu saya memonitor ZABBIX, ini adalah tools di linux untuk melihat kondisi server, saya mendapati bahwa dua server dimana saya melakukan CTAS kemarin cpu-load-nya sangat tinggi. Itu selesai setelah 6 Jam process, baru load nya turun drastis. Langsung saja saya curiga, mungkin itu terjadi karena tabel yang kemarin saya CTAS. Kemudian saya coba matikan bucardo-nya dan berharap esok hari zabbix akan memberikan laporan yang lebih baik.

Esoknya, hari ke 2, pagi pagi langsung saya lihat kondisi Zabbix, ternyata benar, load selama 12 jam terakhir rendah sekali. Jadi saya berkesimpulan bahwa load yang tinggi kemarin itu karena Bucardonya. Saya remove tabel tabel yang kemarin saya CTAS dari daftar tabel yang di replikasi di bucardo. Kemudian bucardo saya start lagi untuk menyelesaikan semua data data yang belum di replikasi. Dalam 3 jam ke depan Zabbix menunjukan kalau 2 server tersebut sibuk, karena menyelesaikan transaksi bucardo. Setelah itu rendah kembali, normal seperti sedia kala.,

Nah, saya browsing mencari jawaban mengenai hal ini, tetapi masih belum juga ketemu jawabannya. Mengapa setelah tabel tersebut di CTAS, process bucardo di  tabel tersebut jadi lebih lambat. Apakah ada teman teman yang memiliki pengalaman seperti ini ? mohon info nya.

Bucardo : Perintah Truncate Table Ter-Replikasi

  Hari ini saya mendapatkan pelajaran berharga dari bucardo. Saya secara tidak sengaja, maksudnya aktivitas yang saya kerjakan akan ter-replikasi ke server yang lain.

Jadi ceritanya, saya akan mendaftarkan tabel baru ke dalam replikasi bucardo. Tabel ini tabel aktif, dan transaksi masih sedang berlangsung. Rencana saya, setelah saya daftarkan tabel tersebut di bucardo, saya akan sinkronisasi datanya terlebih dahulu, baru kemudian mengaktifkan bucardonya. Sebelum melakukan sinkronisasi saya harus memastikan tabel di server yang lain kosong, saya pakai perintah truncate, dan ini adalah kesalahan saya, karena ternyata perintah truncate termasuk perintah SQL yang akan ter-replikasi juga.

Berikut kronologis  nya :

  • Server A: Tambahkan tabel yang baru ke dalam replikasi bucardo
  • Server A: Validate sync-nya
  • Server B: kosongkan tabel yang baru di server B pakai perintah truncate
  • Server A: copy data dari server A ke server B
  • Server A: start bucardo

Nah, begitu bucardo start, terjadilah replikasi dari server B ke server A, perintah truncate tersebut, sehingga data di server A terhapus juga. Berikut ini adalah urutan yang benar  :

  • Server B: kosongkan tabel yang baru di server B pakai perintah truncate
  • Server A: copy data dari server A ke server B
  • Server A: Tambahkan tabel yang baru ke dalam replikasi bucardo
  • Server A: Validate sync-nya
  • Server A: start bucardo

Dijamin, truncate tidak akan ikut ter-replikasi.

Apa itu DataWarehouse ?

  Menurut Wikipedia, Datawarehouse adalah

In computing, a data warehouse or enterprise data warehouse (DWDWH, or EDW) is a database used for reporting and data analysis. It is a central repository of data which is created by integrating data from one or more disparate sources. Data warehouses store current as well as historical data and are used for creating trending reports for senior management reporting such as annual and quarterly comparisons.

The data stored in the warehouse are uploaded from the operational systems (such as marketing, sales etc., shown in the figure to the right). The data may pass through an operational data store for additional operations before they are used in the DW for reporting.

Dari informasi diatas, maka datawarehouse adalah suatu database yang dipergunakan untuk keperluan membuat laporan dan analisa data. Database ini berperan sebagai pusat data dari berbagai sumber data, semisal dari 2 atau 3 database yang lainnya.  Datawarehouse menyimpan data saat ini dan data history yang dipergunakan untuk membuat report report perbandingan antara suatu waktu atau area dengan yang lainnya. Jadi orientasi dari datawarehouse adalah analisa data.

Contoh jenis analisa di dalam datawarehouse :

  • Data Penjualan berdasarkan :
    • Area, Tahun, Jenis Produk, dll
  • Data Kemampuan Karyawan berdasarkan :
    • Skill, Umur, Test, dll
  • Data Pembelian berdasarkan :
    • Tahun, Supplier, Produk, OnTime, dll

Data yang disimpan di dalam database datawarehouse itu berasal dari berbagai database berjenis OLTP. OLTP adalah database yang dipergunakan untuk keperluan penyimpanan data transactional. Jadi data data OLTP harus di upload ke dalam database datawarehouse, proses upload data ini dikenal dengan istilah ETL ( Extract, Transform, Load). Penjelasannya sebagai berikut :

  • Extract
    • Ekstrak data dari sumber data yang lain, dari database OLTP atau dari file Excell, atau dari file Log dan sebagainya.
  • Transform
    • Transformasi data agar sesuai dengan kebutuhan kita, termasuk urutan, perhitungan atau penjabaran.
  • Load
    • Loading ke dalam database tujuan kita, database datawarehouse.

Database Datawarehouse harus didesain dan di rancang untuk menangani kegiatan Analisa Data. Desain databasenya memiliki karakteristik sebagai berikut :

  • De-Normalisasi
    • Tabel tabel yang dimiliki selalu dalam bentuk tabel de-normalisasi atau 90% atau lebih dari tabel yang dimilikinya dalam bentuk de-normalisasi
  • Database Blok berukuran besar, 8 kilobyte , 16 kilobyte atau 32 kilobyte
    • Setiap blok penyimpanan di database umumnya memakai besaran lebih dari 8kb
    • Ukuran blok yang besar ini akan mempercepat proses pencarian keseluruhan data di dalam tabel
  • Data diatur berdasarkan subyeknya
    • Subyek ini yang menentukan data didalam datawarehouse, contohnya data penjualan, pembelian dan lain lain.
  • Integrasi
    • Data yang berasal dari berbagai sumber data tentu memiliki beberapa perbedaan, misal nama kolom atau tipe data. Perbedaan perbedaan ini harus di atasi, agar dapat di buat laporan dengan format yang valid dan kosisten.
  • Non-Volatile
    • Artinya, sekali data itu masuk ke datawarehouse, data tidak boleh di ubah. Mengapa ? karena fungsi datawarehouse adalah untuk mengetahui apa yang terjadi.
  • Time Variant
    • Data yang disimpan di dalam datawarehouse di kelompokkan berdasarkan waktunya, mingguan, bulanan atau tahunan.

Dengan karakteristik seperti itu, maka database Datawarehouse haruslah dapat menyimpan data dalam jumlah yang besar, gigabye atau terabyte. Pengambilan data dalam jumlah besar juga harus dapat dilakukan, tidak harus cepat, tapi harus dapat dilakukan. Misal untuk membuat suatu analisa perlu melakukan query terhadap database yang menghasilkan 1 Trilyun record, yang kemudian di summarize menjadi 100 record.

Kecepatan bukan hal yang utama disini, penyelesaian suatu analisa itu yang paling utama.

RedHat akan mengganti MySQL dengan MariaDB

  Collin Charles melaporkan dari blognya bahwa Red Hat Enterprise Linux 7 akan melepas database MySQL dan menggantinya dengan database MariaDB. Pengumuman ini dikeluarkan pada #rhsummit yang sedang berlangsung di xxx.

Sejak MySQL di akuisisi oleh ORACLE pada tahun 2010, para pengembang MySQL memisahkan diri dan membuat versi terbuka dan mandri yang di beri nama MariaDB. MariaDB masih kompatible dengan MySQL, sehingga jikalau applikasi kita beralih dari database MySQL ke MariaDB dapat langsung berjalan.

Kabar ini tentu saja akan menggembirakan para pengguna MariaDB dan membantu para pemakai MySQL yang risau setelah pengakuisisian MySQL oleh Oracle. Termasuk saya tentunya, bagaimana dengan anda ?