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.

Apa itu Database OLTP ?

  OLTP adalah singkatan dari On-line Transaction Processing. Menurut Wikipedia,

Online transaction processing, or OLTP, is a class of information systems that facilitate and manage transaction-oriented applications, typically for data entry and retrieval transaction processing. The term is somewhat ambiguous; some understand a “transaction” in the context of computer or database transactions, while others (such as the Transaction Processing Performance Council) define it in terms of business or commercial transactions.[1] OLTP has also been used to refer to processing in which the system responds immediately to user requests. An automatic teller machine (ATM) for a bank is an example of a commercial transaction processing application.

Jadi, OLTP adalah sistem informasi yang berbasis transaksi. Transaksi dalam konteks Applikasi OLTP adalah satu proses transaksi atau satu cyle, ada awal ada akhir. Proses transaksi di dalam applikasi sendiri bervariasi jenisnya,  antara lain :

  • Proses penyimpanan 1 form, contoh 1 Purchase Order, 1 Sales Order, 1 Material Incoming dan lain lain
  • Proses End of Month, contoh proses akhir bulan Accounting, akhir bulan Banking, dan lain lain
Semua jenis transaksi tersebut diatas itulah yang disebut Proses Transaksi atau transaction processing.  Sedang yang dimaksud dengan Transaksi Database adalah proses menyimpan sebuah record dalam suatu tabel. Sehingga dengan penjelasan ini, 1 Transaksi Applikasi dapat berisikan ribuan Transaksi Database.
Database OLTP harus didesain dan di rancang untuk menangani kegiatan Transaksi Applikasi. Desain databasenya memiliki karakteristik sebagai berikut :
  • Normalisasi
    • Tabel tabel yang dimiliki selalu dalam bentuk tabel normalisasi atau 90% atau lebih dari tabel yang dimilikinya dalam bentuk normalisasi
  • Database Blok berukuran kecil, 2 kilobyte atau 4 kilobyte
    • Setiap blok penyimpanan di database umumnya memakai besaran 2kb atau 4kb
    • Ukuran blok yang kecil ini akan mempercepat proses pencarian data yang spesifik
  • Transaction Control
    • Selalu menggunakan transaction contol, yakni begin transaction, end transaction, commit dan rollback.
    • Kontrol ini dipergunakan untuk memastikan 1 Transaksi Applikasi berjalan semestinya hingga akhir dengan benar.

Dengan karakteristik seperti itu, maka Transaksi Applikasi di database OLTP haruslah transaksi yang memiliki proses penyimpanan dengan cepat. Kecepatannya harus kurang dari 60 detik. Lebih cepat lebih baik. Misal, 1 Transaksi Applikasi, menyimpan 1 Form Purchase Order, haruslah kurang dari 60 detik. Jadi semua Transaksi Applikasi jenis OLTP ini harus cepat.

Bagaimana dengan Proses Analisa ? Proses analisa umumnya melibatkan banyak tabel yang harus di join. Semakin banyak tabel yang di join akan mempengaruhi kecepatan pemrosesan data. Proses Analisa tetap dapat di lakukan dengan menggunakan database OLTP, tetapi ada keterbatasan di dalamnya, karena normalisasi, atau karena blok database. Seberapa besar batasan yang dapat diterima itu harus ditentukan. Jikalah Proses Analisa cukup tinggi pengunaannya, lebih baik proses analisa dilakukan di DATAWAREHOUSE.

Bucardo : Mengatur object dalam sync

  Sekarang  bucardo sudah berjalan dengan lancar. Kadang kala kita perlu mengatur object postgresql di dalam bucardo sync. Object ini adalah table dan sequence. Kedua object ini dapat kita tambahkan atau kita hapus.

Contoh yang saya miliki adalah sebagai berikut :

  • Table A, ingin saya replikasi dari db1 ke db2, tetapi tidak untuk db3.
  • Sequence B, ingin saya replikasi dari db1 ke db3, tetapi tidak untuk db2.

Berikut langkah langkah untuk menambah suatu object ke dalam sync :

  • stop bucardo
  • bucardo add table schema.nama_table herd=my_herd
  • bucardo add sequence schema.nama_sequence herd=my_herd
  • bucardo validate sync my_sync
  • start bucardo

Dan untuk menghapus, langkah langkah nya sebagai berikut :

  • stop bucardo
  • bucardo remove table schema.nama_table
  • bucardo remove sequence schema.nama_sequence
  • bucardo validate sync my_sync
  • start bucardo

Jika setelah menghapus suatu object, kita menemukan pesan errod di dalam file log, seperti ini :

“(23143) [Mon Dec 3 13:18:24 2012] VAC Warning! VAC was killed at line 6486: DBD::Pg::st pg_result failed: ERROR: relation “bucardo.delta_265672″ does not exist”

artinya ada object postgresql yang secara fisik sudah tidak ada di postgresql tetapi masih terdaftar di dalam sistem bucardo. Mengapa ini dapat terjadi ? bucardo yang kita pakai bukan versi stabil, masih versi beta atau alpha. Tenang saja, kita bisa memperbaikinya kan.

Untuk membetulkannya:

  • bucardo stop
  • login ke db1
  • cek melalui perintah
    • select * from pg_class where oid = 265672
  • jika tidak ada hasilnya, berarti object memang tidak ada.
  • delete from bucardo.bucardo_delta_targets where tablename = 265672
  • if no result…. ulang step ke db yang lainnya  ..dan seterusnya
  • bucardo start

Bagaimana pengalaman anda dengan bucardo ? mohon infonya.

Bucardo Server Down

  Yup betul. Pagi ini saya mendapati server bucardo saya mati. Hardware error. Saya coba restart server, selalu terhenti dengan pesan kesalahan ada pada perangkat keras. Sedikit panik sih, tetapi harus tetap tenang.  Saya hitung pilihan yang saya punya.

  • 1 Mesin DB slave
  • Tidak ada backup database bucardo
  • Server DB Master dan Server DB Slave masih berfungsi.

Pilihan yang ada adalah install bucardo di mesin DB Slave, dan register ulang semua tabel yang akan di replikasi. Seharusnya proses registrasi ulang ini dapat di hindari, tetapi karena saya tidak punya backup database bucardo, jadi harus registrasi ulang. Kalau ini berjalan, saya harus ikutkan database bucardo dalam skema backup saya.

Ada sedikit kekhawatiran dalam hati, jangan jangan bucardo nya tidak mau replikasi karena saya install database bucardo yang baru. Dalam hati berharap semoga bucardo nya tetap dapat melakukan replikasi.

So, setelah install ulang bucardo di mesin DB Slave, registrasi ulang, maka sekarang saatnya untuk start bucardo. Sambil berharap harap cemas, saya start bucardo dan tail -f log.bucardo.

Ternyata berjalan normal, tanpa kurang suatu apapun. L E G A.

Bagaimana dengan teman teman, ada memiliki pengalaman seperti ini ?

5 Tips PostgreSQL dari Instagram

  Teman teman pasti tahu tentang instagram.  Instagram adalah website social networking dan berbagi photo secara online. User dapat meng-upload foto dan membagikannya ke teman teman yang lainnya. Foto yang di upload, dapat juga di modifikasi dengan penggunaan filter. Banyak sekali filter yang dimilikinya. Instagram sangat populer, mereka mengklaim sudah mendapatkan 100 juta pengguna pada february 2013.

Instagram menggunakan database PostgreSQL sebagai database backend mereka dan framework Django sebagai framework applikasi mereka. Instagram juga memiliki beberapa server postgresql yang bekerja secara shared. Saya masih tidak paham apakah mereka menggunakan clustering atau replication, selengkapnya dapat teman teman baca disini.

Nah, team engineering instagram membagikan 5 tips Postgresql yang sangat membantu database mereka :

  • Partial Indexes
    • Partial index ini adalah index yang dibuat berdasarkan karakteristik query yang kita buat. Dan dalam proses pencariannya memakan waktu yang lama. Karakteristiknya juga selalu tetap dan tidak pernah berubah.
    • Contoh karakteristik query selalu memakai where item_name ilike ‘software%’.
    • Maka partial indexnya adalah … Create Index idx1 on mytable where item_name ilike ‘software%’;
    • Saya sendiri belum pernah memakai partial index ini, karena karakteristik query saya lebih banyak memakai ‘%software%’ dibandingkan dengan ‘software%’; Jadi walaupun saya pakai partial index untuk kolom tersebut, tetap saja tidak akan terpakai indexnya, mengapa ? karena saya memakai  ilike ‘%…%’, yang mana akan melakukan pencarian sequential dari awal tabel hingga akhir tabel.
  • Functional Indexes
    • Index yang dibuat dengan menggunakan fungsi, contohnya substr, lower, upper, concatenate dan seterusnya.
    • Karakter query yang di pergunakan juga bersifat tetap dan tidak pernah berubah.
    • Contoh karakter query yang selalu memakai where … substr(item_name, 0, 8 ) = ‘software’
    • Maka functional indexnya adalah … Create index idx1 on mytable (substr(item_name,0,8))
    • Saya sendiri jarang memakai functional index, saya pernah pakai untuk concatenate, penggabungan dua kolom.
  • pg_reorg For Compaction
    • Seperti yang pernah saya tulis, database postgresql juga pasti akan mengalami fragmentasi suatu saat nanti, demikian juga database postgresql yang dipakai di instagram.
    • Team instagram memakai pg_reorg untuk melakukan defrag.
    • Saya sendiri masih memakai cara manual, tetapi prinsipnya sama dengan yang dipakai pg_reorg, yakni dengan metode CTAS.
  • WAL-E for WAL archiving and backups
    • WAL-E adalah program untuk membackup file postgresql WAL archive file yang dapat melakukan archive secara terus menerus.
    • Saya sendiri belum pernah menggunakannya. Karena karakteristik backup saya beda.
  • Autocommit mode and async mode in psycopg2
    • Tips ini dipergunakan jika kita menggunakan psycopg2.
    • Saya tidak memakai psycopg2, jadi belum bisa berkomentar.

Berdasarkan tips tips tersebut, team instagram mampu membuat PostgreSQL mereka melaju dengan sangat cepat. Secepat apa ? terus terang saya juga tidak tahu. Yang pasti, tips seperti partial index dan functional index itu sangat membantu sekali, walaupun saya belum pernah menggunakannya. Tetapi dari simulasi yang saya lakukan, hasilnya memang menggembirakan.

Bagaimana pendapat teman teman ?

Bucardo : Mengubah stuktur table

  Setelah memakai Bucardo sekaian lama, saya memiliki kebutuhan untuk merubah struktur tabel. Menambah kolom, merubah tipe data, melebarkan kolom, atau menambah constraint. Proses ini harus dilakukan dengan kondisi tidak ada proses replikasi yang sedang berjalan atau dengan kata lain Bucardo harus berhenti.

Berikut adalah langkah langkah merubah struktur tabel :

  • Matikan Bucardo
    • bucardo stop
  • Ubah stuktur tabel di semua lokasi
    • psql -h 192.168.0.2 -U postgres
    • alter table my_table add column ….
    • alter table add constraint my_constraint …
    • Ulangi hingga semua lokasi memiliki struktur table yang sama
  • Jalankan Bucardo kembali
    • Bucardo Start

Setelah itu kita hanya perlu memonitor file log.bucardo, jikalau tidak ada error berarti proses perubahan struktur tabel berhasil dilakukan. Silahkan mencoba.

Bucardo : Menambah Server ke dalam Replikasi Master To Master

  Beberapa waktu yang lalu, saya memutuskan untuk menambahkan 1 server lagi kedalam replikasi master to master yang saya pergunakan. Saya memakai Bucardo untuk menangani replikasi master to master. Performancenya cukup memuaskan saya. Nah saat ini saya merasa perlu untuk menambah 1 server lagi untuk membagi beban kerja di server.

Pada awalnya tujuan memakai 2 server hanya untuk keperluan berbagi beban server dan backup di dalam 1 lokasi gedung, ternyata diperjalanannya untuk lokasi kota yang lain perlu juga di bagi beban servernya dan backup jika sewaktu waktu jaringan antar kota terputus, sehingga tidak akan mengganggu transaksi lokal. Untuk instalasi awal replikasi master to master dengan bucardo dapat anda baca disini.

Informasi :

  • db1 memiliki ip address 192.16.0.1
  • db2 memiliki ip address 192.16.0.2
  • db1 dan db2 berada dalam 1 gedung
  • db3 memiliki ip address 192.16.1.3
  • db3 berada di kota yang berbeda

Nah berikut adalah langkah langkah untuk menambahkan Server Database db3  ke dalam replikasi :

  • Login ke Server Bucardo dan stop replikasinya.
    • bucardo stop
  • Login ke Server Applikasi dan stop semua applikasi yang terkoneksi ke Server Database
  • Login ke Server Database ke 1 , backup dan kirim Server Database ke 3
    • pg_dump -h 127.0.0.1 -U postgres my_database > my_database.dmp
    • scp my_database.dmp root@192.16.1.3:/root
  • Login ke Server Database ke 3, buat database baru, dan restore database backupnya
    • psql -h 127.0.0.1 -U postgres -c “create database my_database; ” template1
    • psql -h 127.0.0.1 -U postgres -d my_database < my_database.dmp
  • Login ke Server Bucardo, daftarkan Server Database ke 3, dan syncronize ulang
    • bucardo add db db3 dbname=eis dbhost=192.16.1.3 dbuser=postgres dbpass=password
    • bucardo remove sync db_sync
    • bucardo remove dbgroup db_group
    • bucardo add dbgroup db1:source db2:source db3:source
    • bucardo add sync db_sync herd=db_herd dbs=db_group
    • bucardo start
  • Kemudian check log.bucardo, kita akan menemukan pesan kesalahan seperti ini :
    • “(23143) [Mon Dec 3 13:18:24 2012] VAC Warning! VAC was killed at line 6486: DBD::Pg::st pg_result failed: ERROR: relation “bucardo.delta_265672? does not exist”
    • Tenang, pesan kesalahan ini terjadi karena kita melakukan restore database beserta object object bucardo dari server asal.
    • Setelah kita restore database dan kemudian bucardo kita start, maka bucardo akan melakukan proses sinkronisasi objectnya. Karena kita melakukan restore, tentu saja object id atau OID dari object table di server yang baru akan berbeda dengan object id dari server yang lama. Oleh karena itu, bucardo akan mendaftarkan ulang object table di server yang baru, sehingga kita harus menghapus object id yang lama secara manual.
    • Mari kita periksa table bucardo_delta_targets, disinilah object table di daftarkan.
      • select * from bucardo.bucardo_delta_targets;
    • Kita akan mendapati, daftar table dengan perbedaan di tanggal registrasi, di kolom cdate. Yang perlu kita lakukan adalah menghapus semua table yang memiliki tanggal cdate tidak sama dengan saat ini atau saat prosess restore.
      • delete from bucardo.bucardo_delta_targets where to_char(cdate,’dd/mm/yyyy’) <> to_char(now(),’dd/mm/yyyy’);
    • Setelah itu periksa kembali file log.bucardo, seharusnya pesan kesalahan sudah tidak muncul lagi.
  • Done

Nah, sekarang kita memiliki 3 server di dalam replikasi master to master kita, db1 dan db2 dalam 1 gedung, db3 berada di kota yang lain. Dengan cara ini, apabila terjadi putusnya jaringan antar kota, maka user di kota yang lain tetap dapat menjalankan applikasi. Dan pada saat jaringan tersambung kembali maka bucardo akan melakukan sinkronisasi data kembali. Bagaimana pendapat anda ?

Migrasi redmine ke server yang lain

  Saya memakai software project management bernama Redmine. Redmine adalah software gratis dan open source, project management dan bug tracking software berbasis web, Fiturnya termasuk kalender , Gantt-Chart dan menangani banyak project secara bersamaan.

Redmine yang saya pakai adalah versi 0.7.3, dan akan saya upgrade ke version 1.3.2 di mesin Ubuntu 12.04. Berikut adalah langkah langkah yang saya lakukan untuk melakukan upgrade.

Langkah di server lama adalah sebagai berikut :

  • Backup Mysql Databasedan kirim file backup ke server yang baru
    • mysqldump -u root -p redmine > redmine.dmp
    • scp redmine.dmp root@192.168.0.2:/root
  • Transfer directory files
    • scp -r /opt/redmine.0.7.3/files root@192.168.0.2:/root
  • create configuration files

Langkah di server baru adalah sebagai berikut :

  • Install semua paket yang dibutuhkan
    • sudo apt-get install apache2 mysql-client mysql-common mysql-server ruby1.8 ruby1.8-dev ruby-i18n ruby-rails-2.3 ruby-tmail rubygems ruby-builder ruby-coderay ruby-text-format ruby-blankslate ruby-mysql ruby-net-ldap ruby-rack ruby-rchardet redmine redmine-mysql
  • Buat symbolic-link halaman web redmine ke /var/www/redmine
    • sudo ln -s /usr/share/redmine/public /var/www/redmine
  • Ubah hak akses halaman web redmine
    • sudo chmod a+x /usr/share/redmine/public
  • Buat file konfigurasi untuk redmine
    • sudo vim /etc/init/redmine.conf
    • # Redmine
      description "Redmine"
      start on runlevel [2345]
      stop on runlevel [!2345]
      expect daemon
      exec ruby /usr/share/redmine/script/server webrick -e production -b 192.168.0.2 -d
  • login ke database mysql
    • mysql -u root -p
  • Buat ulang database redmine default dengan cara drop database yang lama dan buat yang baru
    • drop database redmine_default; create database redmine_default;
  • Keluar dari mysql
    • \q
  • Import database redmine yang lama ke database redmine yang baru
    • mysql -u root -p redmine_default < redmine.dmp
  • Masuk direktori redmine
    • cd /usr/share/redmine
  • Update database redmine yang lama ke database yang baru
    • rake db:migrate RAILS_ENV=production
  • Hapus semua cache yang ada
    • rake tmp:cache:clear
    • rake tmp:sessions:clear
  • Restart apache web server
    • sudo service apache2 start
  • Start redmine server
    • sudo service redmine start
  • Akses redmine melalui web browser
    • http://192.168.0.2:3000/
  • Done

Sekarang redmine saya udah menggunakan redmine 1.3.2. Semoga bermanfaat.

Migrasi server SVN

  Saya memiliki SVN server. SVN atau Subversion adalah open source version-control yang saya pergunakan untuk menyimpan kode sumber saya dan team. Pada saat kita memulai proyek , version-control yang ada hanyalah CVS dan SVN saja. Sehingga kita pakailah SVN. Kalau sekarang sudah banyak software version control yang open source yang memiliki fitur fitur lebih hebat daripada SVN seperti GIT, Mercurial dan Bazaar.

Nah, saat ini ada kebutuhan dari team untuk memindahkan SVN Server kita ke mesin yang lebih baru.

Berikut adalah langkah langkah di Server yang lama :

  • Backup repository
    • cd /data/svn/
    • svnadmin dump repository > repository.dump
  • Transfer ke server yang baru
    • scp repository.dump root@192.16.0.1:/root

Langkah langkah di Server yang baru :

  • Install SVN dan Apache
    • sudo apt-get install subversion apache2 libapache2-svn
  • Aktifkan package dav_svn
    • vim /etc/apache2/mods-enabled/dav_svn.conf
  • Buat User Admin
    • sudo htpasswd -cm /etc/apache2/dav_svn.passwd admin
  • Tambahkan User Member yang lainnya
    • sudo htpasswd -m /etc/apache2/dav_svn.passwd member_1
  • Buat repository di direktory /data/svn
    • cd /data/svn/
    • sudo svnadmin create repository
  • Load data repository ke svn
    • sudo svnadmin load repository < repository.dump
  • Ubah hak akses direktory repository
    • sudo chown www-data:www-data repository -R
  • Masuk ke Web Browser dan akses melalui
    • http://server_baru/svn
  • Done

Semoga bermanfaat.

Defrag database PostgreSQL

  Artikel ini di peruntukkan pengguna Database PostgreSQL yang memutuskan untuk melakukan defrag terhadap database anda.

Berikut adalah langkah langkah untuk melakukan defrag di database PostgreSQL :

  • Cek tabel tabel dan index index yang memiliki fragmentasi dengan menjalankan skrip berikut ini dan melihat nilai rasio dan wastebyte dari tabel bloat anda.
    • Nilai rasio itu menentukan seberapa besar fragmentasi yang terjadi di dalam tabel atau index anda.
    • Semakin besar rasio semakin besar fragmentasi yang terjadi.
    • Wastebyte adalah kondisi dimana blok data tidak dapat dipergunakan untuk menyimpan data.
  • Apabila anda mendapati rasio > 1.5 lakukan VACUUM ANALYZE.
    • VACUUM ini akan merubah wastebyte yang tidak dapat dipergunakan untuk transaksi menjadi aktif dan dapat dipergunakan lagi.
    • ANALYZE akan melakukan pembuatan statistik untuk tabel atau index tersebut.
    • Dengan melakukan VACUUM ANALYZE ini, maka wastebyte yang ada akan di aktifkan kembali, walaupun posisinya berada ditengah tengah blok data yang ada isinya.
  • Apabila anda mendapati rasio > 5 lakukan VACUUM FULL, REINDEX TABLE dan ANALYZE
    • VACUUM FULL ini akan mengaktifkan kembali wastebyte yang ada dan mengisinya dengan blok data dari bagian akhir dari tabel atau index. Sehingga bagian yang ter-fragmentasi itu akan terisi dengan data, kemudian sisa free space yang ada akan dikembalikan ke Sistem Operasi, sehingga tabel tidak akan menyimpan free-space lagi.
    • VACUUM FULL ini akan mendefrag tabel, tetapi tidak mengurutkan datanya sesuai dengan primary key tabel itu.
    • Kemudian lakukan REINDEX terhadap tabel ini, untuk membuat ulang index-indexnya.
    • Kemudian lakukan ANALYZE untuk melakukan pembuatan statistik untuk tabel dan indexnya.
    • Lakukan proses ini pada saat koneksi user sedikit, karena postgresql akan melakukan lock terhadap tabel secara keseluruhan. Untuk versi 9.0 keatas proses vacuum sangat cepat.
  • Apabila anda mendapati rasio > 10 lakukan dengan metode CTAS.
    • Untuk proses ini, pastikan jangan ada user atau applikasi yang terkoneksi ke database.
    • Proses ini akan melakukan membuat tabel baru dengan data yang telah terurut berdasarkan primary key atau unique indexnya.
    • Jangan lupa untuk melakukan ANALYZE di akhir proses untuk membuat statistik terhadap tabel dan indexnya.
  • Solusi yang lain adalah menggunakan extensi pg_reorg.
    • Solusi ini berbasis metode CTAS dan saya belum pernah mencobanya.

Demikian cara saya untuk melakukan defrag database PostgreSQL.

Bagaimana dengan anda ?