Setelah menginstall DB2 ESE 9.1 di Redhat Enterprise 5 dengan lancar, ada kemungkinan ketika menjalankan db2cc dari terminal kita akan mendapatkan error sebagai berikut Xlib: connection to “:0.0″ refused by server Xlib: No protocol spesified Lebih detailnya bisa dilihat pada gambar berikut

Berikut cara menyelesaikan masalah ini.
1. Masuk ke terminal sebagai root dan ketik xhost +
2. Masuk ke terminal sebagai instance owner dan ketik export DISPLAY=:0.0

3. Jalankan db2cc

Semoga bermanfaat.

Come compito per la scuola ci hanno incaricati di fare una ricerca sui vari sistemi di database relazionali. Io ho deciso di farla su Mysql. Tra le altre cose, per lavorare ho fatto un intenso uso di Delicious e delle etichette multiple per dividermi i link interessanti a seconda del paragrafo in cui dovevo metterli. Vedete questa pagina per credere. Questa cosa mi ha divertito perché ho potuto vedere un nuovo modo di adoperare uno strumento web 2.0 che prima non avevo pensato.

Per realizzare la relazione invece ho adoperato Openoffice.org che ormai tutti adorano e qualche font carino. Uno di questi è Sawasdee, di default in Ubuntu, l’altro è Playtime With Hot Toddies, giusto per rendere i titoli un po’ meno seriosi. Visto che alla fine il lavoretto è venuto molto bene e sono alquanto soddisfatto del risultato, ho pensato che potesse essere carino pubblicare la ricerca. Così chi vuole saperne un po’ di più su questo sistema di database magari scoprirà qualcosa di nuovo, e chi vuole usarla come spunto per fare una sua relazione (ho detto spunto, non copia-incolla! ) magari trova un po’ di ispirazione.

Potete scaricare il pdf cliccando qui. Buona lettura!

DATAFILE

Sejauh ini kita baru membahas mengenai fungsi dan sifat Log, Sekarang kita akan membahas mengenai DATAFILE dan hubungannya dengan Log dalam pengimplementasian Backup & Recovery. Pada berbagai Literatur, DATAFILE ini biasa dinamakan DATABASE, karena fungsinya yang menyimpan data sebenarnya. Namun pada System Manajemen Basis Data (DBMS) nama DATABASE sendiri bukanlah sebatas tempat penyimpanan data table, namun juga seluruh data yang dibutuhkan oleh aplikasi DBMS untuk mengelola aplikasinya, maka dari bagian ini dan seterusnya DATABASE yang berada di Hard Disk disebut DATAFILE. Sedangkan DATABASE yang dibuffer di RAM dinamakan Database Buffer.

Datafile adalah file fisik yang menyimpan data yang telah di insert kedalam tiap table pada DBMS.

DATAFILE adalah komponen yang berbeda dengan LOG FILE. Perbedaan komponen tersebut dapat di deskripsikan seperti berikut: DATAFILE adalah tempat menyimpan data, sedangkan LOG FILE adalah tempat penyimpanan catatan bahwa data tersebut telah di simpan.

Karena fungsinya sebagai tempat penyimpanan data (bukan tempat penyimpanan catatan), peranan DATAFILE menjadi sangat penting, karenanya, informasi yang tersimpan di dalamnya HARUS dapat diandalkan (Reliable). Salah satu cara untuk menjaga ke-Reliable-an isi dari DATAFILE ini adalah dengan cara menggunakan catatan pada LOG FILE sebagai acuan dalam proses Recovery, seperti telah di jabarkan pada bagian-bagian sebelumnya.

Redundancy penyimpanan data antara DATAFILE dan LOG FILE menyebabkan dan semakin besarnya kebutuhan penyimpanan data. Namun hal ini sebanding dengan terjaminnya ke-Reliable-an isi data.

Datafile menggunakan Buffer untuk mempecepat pengaksesan data oleh banyak user

DATAFILE suatu perusahaan dapat berukuran ratusan, bahkan hingga ribuan gigabyte. Walaupun tidak semua data ini diakses secara bersamaan, namun biasanya pengaksesan banyak data secara bersamaan sering terjadi (pada jam sibuk misalnya).

System Basis Data harus dapat memfasilitasi jika terjadi pengaksesan banyak data secara bersamaan ini, dengan tetap menjaga kecepatan tiap operasi pengaksesan data, sehingga tidak ada user yang menunggu lama untuk melihat/mengubah datanya.

Untuk kebutuhan itulah DATAFILE menggunakan Buffer pada RAM. Tempat khusus di RAM disediakan untuk hal ini, dinamakan Database Buffer. Pem-buffer-an DATAFILE ini bukan hanya untuk operasi membaca data (SELECT) saja, namun juga penulisan data (INSERT/UPDATE/DELETE). Ini berarti perubahan data dilakukan di Database Buffer (di RAM), bukan langsung ke DATAFILE (di Hard Disk).

Catatan : perbandingan kecepatan ini dapat di coba pada System DBMS pada umumnya, dengan melakukan SELECT yang sama sebanyak dua kali pada data berukuran besar. Pengaksesan data pertama akan membutuhkan waktu yang lebih lama dari pengaksesan kedua, karena pengaksesan pertama mengambil data dari Hard Disk, sedangkan pengaksesan ke dua mengambil data dari RAM.

Penulisan perubahan pada Database Buffer di RAM ke DataFile di Hard Disk terjadi pada saat kapasitas Database Buffer penuh dan setelah Log telah dituliskan sebelumnya.

Seperti telah di bahas sebelumnya, Database Buffer digunakan untuk mempercepat waktu akses data. Data yang tersimpan di Database Buffer akan hilang jika terjadi kegagalan system (baik karena putusnya aliran listrik, System Hang atau sebab-sebab Nonfisik lainnya), oleh karenanya isi Database Buffer harus dituliskan ke DATAFILE di media penyimpanan tetap (Hard Disk). Penulisan Database Buffer ke DATAFILE ditangani oleh proses latar belakang yang bernama Database Writer.

Algoritma yang biasa di gunakan untuk penggantian isi Database Buffer adalah Least Recently Used (LRU). Yaitu penulisan isi Database Buffer yang paling terakhir digunakan/diakses ke Hard Disk untuk memberi ruang kepada Database Buffer untuk menyimpan data baru.

Penulisan data ke DATAFILE tidak boleh dilakukan sebelum record Log dituliskanke LOG FILE di media penyimpanan tetap. Karena informasi yang terkandung dalam LOG FILE digunakan untuk merekonstruksi keadaan DATAFILE, jika DATAFILE bermasalah. Perbedaan system penulisan DATAFILE dengan LOG FILE adalah isi DATAFILE ini tidak perlu dituliskan saat transaksi di COMMIT, karena catatan-catatan tentang transaksi telah dituliskanke LOG FILE.

Dalam kejadian data transaksi yang telah di COMMIT pada Database Buffer hilang (karena kegagalan system), data transaksi yang hilang tersebut masih dapat dapat dipulihkan dengan menelusuri catatannya di LOG FILE.

CHECKPOINT
Misalkan kita mengubah sebagian jalan cerita dari cerita 1, dimana setelah Arus Listrik padam, tidak terjadi kerusakan pada Hard Disk Server dan DATAFILE tidak hilang, yang hilang hanya Buffer pada RAM.

Karena meknisme penulisan DATAFILE dari Buffer RAM ke Hard Disk tidak dilakukan saat transaksi COMMIT, berarti saat Server kembali dinyalakan, DATAFILE “belum” dalam kondisi konsisten.

Untuk memulihkan DATAFILE ke kondisi konsisten, maka dilakukan proses Recovery dengan cara menelusuri catatannya di LOG FILE, untuk menentukan operasi mana yang harus di Redo dan operasi mana yang harus di Undo. Secara prinsip, operasi Recovery dilakukan dengan metode menelusuri seluruh Log untuk menentukan operasi apa yang harus dilakukan. Ada dua kekurangan pada metode ini:

1. Proses penelusuran seluruh Log membutuhkan waktu yang lama

2. Kebanyakan transaksi yang harus di Redone telah menuliskan perubahan datanya ke DATAFILE, walaupun mengulangi transaksi tersebut menggunakan tidak berpengaruh (dikarenakan sifat idempoten), pengulangan transaksi tersebut akan menyebabkan proses recovery lebih lama.

Untuk mengurangi kedua kekurangan beban kerja/waktu tambahan tersebut, digunakan konsep Checkpoint.

Checkpoint adalah kejadian penulisan secara paksa dari Buffer di RAM ke File di Hard Disk. Aksi-aksi yang harus dilakukan adalah :

• Menuliskan semua record Log dari Log Buffer di RAM ke LOG FILE di Hard Disk.

• Menuliskan semua DATA dari Database Buffer di RAM ke DATAFILE di Hard Disk.

• Menuliskan record ke LOG FILE di Hard Disk.

Checkpoint dilakukan pada saat tertentu. Biasanya DBMS akan menentukan waktu selang tertentu dalam pengambilan Chekpoint, atau jika terjadi event yang di tentukan oleh system (misalnya pada saat banyaknya transaksi sejak pengambilan Checkpoint terakhir telah bejumlah tertentu)

KEGAGALAN SYSTEM DAN PROSES RECOVERY

Pada kegagalan System, baik disebabkan oleh putusnya aliran listrik ataupun karena aplikasi DBMS harus di restart, isi Buffer pada di RAM hilang, baik Log Buffer maupun

Database Buffer. Pada saat system restart dan melakukan proses recovery, system akan membuat dua daftar :

• [daftar-undo] yang berisi transaksi-transaksi yang harus di Undo (Dibatalakan-ROLLBACK), dan

• [daftar-redo] yang berisi transaksi-transaksi yang harus di Redo (dikerjakan ulang).

System membuat kedua daftar tersebut dengan urutan sebagai berikut : pertama-tama kedua daftar tersebut kosong. System menelusuri Log pada LOG FILE di Hard Disk dari kedepan, dengan rincian urutan :

1. Buat [daftar-redo] dan [daftar-undo] kosong.

2. Baca Log dari , masukkan seluruh transaksi yang sedang berjalan pada saat kedalam [daftar-undo].

3. Mulai telusuri Log kedepan dari

a. jika ditemukan record pindahkan transaksi Ti tersebut ke [daftar-undo]

b. jika ditemukan record atau pindahkan transaksi Ti
tersebut ke [daftar-redo]

4. Setelah kedua daftar tersebut di buat, Ulangi lagi penelusuran Log dari ke depan. Ulangi seluruh transaksi yang ada di [daftar-Redo], sampai akhir dari Log.

5. Setelah seluruh transaksi yang ada di [daftar-redo] telah di ulangi. Telusuri Log dari belakang (dari akhir Log) batalkan seluruh perubahan yang terjadi dari transaksi yang berada di [daftar-undo] sampai ditemukannya record Log untuk transaksi tersebut.

source e-book Pengenalan Konsep dan Komponen Database Recovery Laboratorium Basis Data : Ilmu Komputer & Pendidikan Ilmu Komputer UPI Bandung

Recovery Berbasis Log

Ilustrasi :
(Cerita 1)
Bank Hemat adalah Bank yang memiliki banyak nasabah, Bank ini menggunakan Basis Data untuk menampung seluruh kegiatan transaksi dan data keuangan nasabah. Bob adalah Administrator Basis Data Bank Hemat yang bertanggung jawab akan System Basis Data Bank tersebut.

Pada suatu hari, teknisi maintenance menemukan bahwa umur baterai pada UPS server Basis Data telah sampai pada batas pemakaian. Perbaikan UPS membutuhkan waktu selama 6 jam dan akan dilaksanakan pada keesokan harinya jam 06:00.

Malamnya Bob melakukan Backup DATAFILE saldo nasabah sebelum perbaikan. Bob melakukan Backup seluruh DATAFILE nasabah kedalam media Optik DVD, sedangkan LOG FILE tidak di backup karena telah di replikasi pada beberapa Hard Disk. Proses Backup ini baru selesai tepat saat Tim teknisi datang untuk melakukan perbaikan UPS (Jam 06:00).

Saat teknisi melakukan perbaikan UPS, server Basis Data di nonaktifkan sebentar untuk mencabut sambungan listrik dari UPS ke server. Kepala operasional memutuskan bahwa selama perbaikan UPS, Server akan berjalan tanpa menggunakan UPS.

Pada hari yang sama, seorang nasabah bernama Yuni pada jam 08:00 mengambil uang dari tabungannya sebesar Rp 2.000.000 dari ATM. Sehingga saldo tabungan Yuni berkurang dari Rp. 5.000.000 menjadi Rp 3.000.000.

Pada jam 09:00 di hari yang sama, Perusahaan listrik memutuskan bahwa aliran listrik seluruh kota akan di putus selama 15 menit untuk maintenance di karenakan Banjir. Praktis aliran listrik seluruh kota terputus, termasuk aliran listrik ke server basis data bank Hemat.

15 menit kemudian listrik kembali menyala, tetapi saat Bob mengaktifkan kembali server Basis Data, ternyata server tidak mau menyala dengan benar dan Bob menemukan bahwa Hard Disk yang menyimpan DATAFILE nasabah telah rusak permanen di karenakan putusnya aliran listrik secara tiba-tiba. Akhirnya Bob memutuskan untuk mengembalikan kondisi Basis Data menggunakan backup terakhir yang ada pada DVD (Backup jam 06:00) ke Hard Disk baru, tetapi Bob tidak melakukan proses recovery menggunakan Data Log Transaksi.

Keesokan harinya saat Yuni kembali ke ATM, dia terkejut karena menemukan saldo tabungannya masih Rp. 5.000.000.

Pada cerita diatas, jika saja Bob bukan hanya menggunakan Backup terakhir, tetapi juga Log seluruh transaksi terakhir sampai dengan sesaat sebelum aliran listrik putus, maka Yuni akan menemukan saldo tabungannya Rp. 3.000.000 seperti seharusnya dan Bank tidak akan mengalami kerugian.

1.1 LOG
Log adalah catatan transaksi secara mendetail. setiap transaksi yang berjalan pada server basis data di catat secara mendetail pada Log ini. Tiap record pada Log menggambarkan operasi tunggal transaksi yang menuliskan data, Record Log tersebut berisi :

1. Nama transaksi : Nama unik dari transaksi yang menjalankan operasi write

2. Nama data item : Nama unik dari data item yang di tuliskan

3. Nilai lama : Nilai data item sebelum operasi write

4. Nilai baru : Nilai yang akan dimiliki data item setelah operasi write

Sebagai tambahan, ada Record Log khusus yang menandakan awal dan akhir transaksi.

Proses Recovery menggunakan Log harus memiliki sifat Idempoten, yaitu pengeksekusian suatu operasi berulang kali, menghasilkan hasil yang sama dengan eksekusi satu kali.

1.2 LOG DALAM DURABILITY TRANSAKSI
Sifat Durability adalah sifat yang harus dimiliki transaksi, sifat durability ini adalah “setelah suatu transaksi COMMIT, update harus bertahan di basis data” [Yudi Wibisono]. Sifat durability ini harus dipenuhi apapun yang terjadi, untuk itu, digunakan Log untuk memastikan terpenuhinya sidat Durability ini.

Pada cerita 1 diatas, setelah Yuni melakukan transaksi pengambilan saldo sebesar Rp. 2.000.000 dan kemudian melihat bahwa saldonya tidak berkurang sama sekali adalah salah satu contoh terabaikannya sifat durable yang harus dimiliki transaksi. Untuk mencegah kejadian seperti ini, dilakukan penelusuran catatan Log transaksi dengan melakukan operasi Redo.

System melakukan penelusuran LOG FILE dari backup terakhir sampai terjadinya kegagalan System. Seluruh transaksi yang terekam pada LOG FILE tersebut di eksekusi ulang, sehingga tidak ada lagi kejadian hilangnya data suatu transaksi.

1.3 LOG DALAM KEATOMIKAN DAN KONSISTENSI TRANSAKSI
Seperti yang telah anda ketahui, bahwa suatu transaksi harus memiliki sifat atomic, yaitu semua berhasil atau semua gagal. Namun pengimplementasian pada tingkat system, masing-masing elemen operasi dari “semua” ini tetap merupakan suatu individu operasi.

(Cerita 2)

Melanjutkan dari Bank Hemat pada cerita 1,

Tara adalah seorang mahasiswi yang kuliah di luar kota. Ayu adalah ibu dari Tara. Keduanya adalah nasabah Bank Hemat. Ayu memiliki saldo Rp 7.000.000, Ayu memiliki saldo Rp 45.000.

Pada suatu hari yang sama dengan hari perbaikan UPS pada Bank Hemat, Tara meng-SMS ibunya untuk mengirimkan uang sebesar Rp. 500.000 karena uang bulanannya hampir habis. Ayu yang menerima SMS dari anaknya ini segera menuju ke ATM untuk mentransfer uang ke saldo Tara.

Sesaat sebelum aliran listrik putus pada jam 09:00, Ayu melakukan transaksi mentranfer uang ke saldo Tara. Sebelum transaksi transfer uang ini “berhasil sepenuhnya”, aliran listrik tiba-tiba putus.

Pada cerita 2 diatas, yang seperti anda ketahui berarti ada 2 operasi yang harus dilakukan, yaitu:

(1) Mengurangi saldo pada Nasabah Ayu sebanyak Rp 500.000 dan

(2) Menambah saldo pada nasabah Tara sebanyak Rp 500.000.

Skenario diatas menceritakan bahwa transaksi ini tidak “berhasil sepenuhnya”, asumsi tidak berhasil sepenuhnya disini adalah : operasi 1 selesai di kerjakan, sedangkan operasi 2 gagal, dikarenakan putusnya aliran listrik.

Jika kondisi ini dibiarkan begitu saja, akan menyebabkan ketidak konsistenan data, yaitu : Saldo Ayu berkurang Rp 500.000 sedangkan saldo Tara tidak bertambah Rp 500.000.

Ini berarti transaksi ini belum berhasil sempurna (COMMITED), dan transaksi ini harus di batalkan (ROLLBACK), sesuai dengan sifat atomic yang harus dimiliki transaksi.

Untuk skenario seperti ini, Recovery data menggunakan Log ditangani dengan meng-Undo transaksi yang gagal tersebut.

Operasi Undo ini akan berjalan saat mekanisme Recovery RDBMS menjalankan operasi Redo dengan menelusuri catatan Log transaksi dari awal sampai akhir dan menemukan suatu transaksi yang tidak diakhiri dengan sempurna (tidak ditemukannya klausa COMMIT atau ROLLBACK pada Log). Berikut ilustrasinya dengan menggunakan skernario pada cerita 2 :

Karena sampai pada akhir Log tidak di temukan record Log yang mengakhiri transaksi transfer uang Ayu, maka secara otomatis transaksi transfer uang tersebut harus di batalkan (ROLLBACK), sehingga uang Ayu kembali utuh karena transaksi telah di batalkan.

1.4 LOG PADA VOLATILE STORAGE
Secara umum ada dua jenis media penyimpanan data (storage), yaitu Volatile storage dan Nonvolatile storage.

• Media penyimpanan sementara (Volatile Storage). Data yang ada di media penyimpanan ini hanya ada selama aliran listrik mengalir ke media ini. Jika aliran listrik terputus, maka data yang tersimpan akan hilang. Kelebihan media penyimpanan ini adalah kecepatannya yang sangat tinggi (karena metode pengaksesannya secara langsung). Contoh media penyimpanan jenis ini adalah RAM, Cache dan Register.

• Media Penyimpanan Permanen (Nonvolatile Storage). Data yang ada di media penyimpanan ini akan tetap ada walaupun aliran listrik terputus. Kecepatan akses media penyimpanan ini jauh lebih lambat di bandingkan dengan kecepatan akses Volatile Storage. Contoh media penyimpanan jenis ini adalah Hard Disk, Magnetic Tape, Floppy Disk dan Optical Disc.

Perbedaan umum dari kedua jenis storage ini adalah, Volatile Storage cepat tetapi sementara sedangkan Nonvolatile Storage bersifat tetap tetapi lambat.

Catatan : Mulai dari bagian ini dan seterusnya, diasumsikan media penyimpanan volatile adalah RAM dan nonvolatile adalah Hard Disk.

Seperti telah di jelaskan sebelumnya, Tiap record pada Log menggambarkan operasi tunggal transaksi. Tiap catatan ini harus di simpan di nonvolatile storage agar saat terjadi padamnya aliran listrik datanya tidak hilang dan dapat digunakan untuk recovery. Seperti di ilustrasilan pada table contoh record-record Log di bawah ini.

Tiap nilai dari record tersebut di simpan ke Nonvolatile Storage (Hard Disk), jadi,

• Record 1 –> simpan ke Hard Disk,

• Record 2 –> simpan ke Hard Disk,

• Record 3 –> simpan ke Hard Disk,

• Record 4 –> simpan ke Hard Disk,

• Record 5 –> simpan ke Hard Disk,

• Record 6 dan 7 –> gagal karena putusnya aliran listrik.

Hal ini berakibat sangat buruk dalam hal performa, karena kecepatan akses Hard Disk yang lambat, selain itu hal ini juga sangat tidak efisien, karena ukuran masing-masing Record Log yang sangat kecil, sehingga system sangat terbebani dengan operasi tulis ke Hard Disk untuk tiap-tiap Record Log yang berukuran sangat kecil tersebut.

Untuk mengatasi masalah performa dan ketidak efisienan tersebut, digunakan Volatile Storage (RAM). Dengan mekanisme mem-buffer, yaitu mengumpulkan record-record yang berukuran sangat kecil tersebut sampai berukuran cukup besar (biasanya sampai berukuran satu Logical Block [box]), baru dituliskan ke Hard Disk.

Performa –> Gunakan Volatile Storage
Efisiensi –> Membuffer sampai berukuran cukup besar, setelah itu dituliskan ke Hard Disk.

Mekanisme membuffer Record Log pada RAM sampai berukuran cukup besar tersebut memiliki pengecualian, yaitu pada saat suatu transaksi COMMIT, hal ini di sebabkan Sifat Durability yang harus dimiliki transaksi, sifat durability ini adalah “setelah suatu transaksi COMMIT, update harus bertahan di basis data” [Yudi Wibisono]. Pengecualian ini dilakukan untuk menghindari isi Buffer Memory yang hilang saat kegagalan system (baik karena putusnya aliran listrik, System Hang atau sebab-sebab Nonfisik lainnya)
.
Umunya DBMS mengalokasikan tempat khusus di memory untuk fasilitas pem-buffer-an Log ini, yang dinamakan Log Buffer. dan membuat sebuah proses khusus yang menuliskan isi Buffer dari Memory ke Hard Disk, yang di namakan Proses Log Writer. Proses Log Writer ini berjalan di latar belakang (background process). Sedangkan untuk Log yang dituliskan ke Hard Disk dinamakan LOG FILE.

Dari sebab, akibat dan solusi diatas, kita dapat mengambil suatu kesimpulan, yaitu, Transaksi yang belum di COMMIT data-data Lognya akan berada pada RAM. baru setelah di-COMMIT, data-data Log tersebut dituliskanke Hard Disk oleh sebuah proses.

source e-book Pengenalan Konsep dan Komponen Database Recovery Laboratorium Basis Data : Ilmu Komputer & Pendidikan Ilmu Komputer UPI Bandung

Recovery Transaksi

System komputer, seperti perangkat-perangkat lain, tidaklah luput dari kegagalan yang diakibatkan berbagai hal, seperti : disk crash, padam listrik, software error, kebakaran di ruang server, bahkan sabotase. Kegagalan system dapat mengakibatkan hilangnya data.

Untuk itulah System Basis Data harus melaksanakan tindakan tertentu untuk menjamin sifat transaksi yang Atomik dan Bertahan (Durable). Bagian terintegrasi dari sebuah System Basis Data adalah recovery scheme (rencana pemulihan) yang dapat memulihkan Basis Data kepada keadaan konsisten sebelum kegagalan system.

Kenapa kegagalan system saat transaksi merupakan hal yang harus di perhatikan secara seksama? Hal ini bersangkut paut dengan tiga sifat yang harus dimiliki sebuah transaksi, yaitu :

• Atomic, yaitu suatu transaksi berhasil seluruhnya atau gagal seluruhnya

• Consistency, yaitu suatu transaksi bersifat mempertahankan kebenaran data, dan

• Durability, yaitu saat suatu transaksi telah di COMMIT maka perubahan data yang telah dilakukan pada transaksi itu harus bertahan pada Basis Data, tidak peduli apa yang terjadi.

Hubungan Durability dengan Consistency adalah : perubahan data yang telah dilakukan pada transaksi jika tidak bertahan pada basis data akan menyebabkan tidak konsistenannya data.

Ilustrasi :

Seperti dideskripsikan pada gambar diatas, Recovery merupakan solusi dari hampir semua fitur ACID yang harus dimiliki transaksi, oleh karena itu transaksi tidak hanya di sebut sebagai suatu unit pekerjaan, namun juga sebagai unit recovery. Tulisan ini akan membahas mengenai Recovery. Karena pada DBMS modern, konsep recovery ini sangat penting, bahkan konsep Backup pada DBMS modern tidak akan dapat dimengerti sepenuhnya tanpa pengertian yang cukup tentang konsep recovery. Hampir seluruh DBMS modern menggunakan konsep Recovery berbasis Log. Konsep dan penerapannya dalam System Basis Data akan di bahas pada part II.

source e-book Pengenalan Konsep dan Komponen Database Recovery Laboratorium Basis Data : Ilmu Komputer & Pendidikan Ilmu Komputer UPI Bandung

Questa breve guida illustra come installare MySQL e alcune utility per lavorare con il DBMS open source più famoso al mondo. Il procedimento è veramente semplice, come ogni installazione su Mac

Prima di tutto dovreste scaricare questi file .dmg, trovate qui sotto i link:

• MySQL 5.1 – Questa è la versione per Leopard (o superiore) per Mac x86, altri package sono disponibili nella sezione download di mysql.com
• MySQL Workbench 5.1 – Un utility che permette la progettazione visuale del DB e l’implementazione direttamente dal modello ER
• MySQL GUI Tools 5.0 – Applicazioni grafiche per l’amministrazione, la gestione del DB e un browser per le query.

Trovato tutto? Bene, si comincia!

Il primo passo è l’installazione del DBMS, montate il primo file che avete scaricando facendo doppio clic e procedete all’installazione dei pacchetti.

Procedere installando il pacchetto principale, poi Startupitem e infine le preferenze di sistema

Iniziate dal package di sinistra, procedete confermando tutte le richieste e le licenze, poi fate lo stesso per il secondo package (MySQLStartupitem) ed infine doppio clic sul pannello per le preferenze di MySQL (MySQL.prefPane) anche qui procedete con tutte le conferme richieste.

Ora è la volta della workbench, l’installazione è immediata. Una volta montato il volume (dovrebbe essere automatico al termine del download), trascinate l’icona della Workbench nella cartella applicazioni e il gioco è fatto.

Una volta aperta la cartella MySQL Workbench è sufficente trascinare l'icona nella cartella Applicazioni

Per ultimo i GUI Tools, anche qui è sufficente il drag & drop della cartella in cui sono contenuti i tools nelle applicazioni. Una finezza: se siete interessati potreste anche installare il widget che trovate in questa stessa cartella, vi permetterà di monitorare connessioni e azioni compiute sul DB.

Stessa operazioni per il GUI Tools, just drag them off!

Non vi resta che attivare MySQL tramite le preferenze di sistema…buon divertimento!

IBM meluncurkan sebuah teknologi terbaru bernama DB2 Pure Scale. Teknologi ini dapat membantu meningkatkan jumlah transaksi sekaligus mengurangi resiko dan biaya yang dibutuhkan untuk mengupgrade sistem.

Penambahan kapasitas ini dapat dilakukan tanpa perubahan di aplikasi ataupun database tuning. Dengan Pure Scale, perusahaan dapat membeli hanya yang mereka butuhkan saja untuk menambah kapasitas yang diperlukan dengan hanya menambah server ke dalam sistem DB2 Pure Scale.

Dari segi efisiensi, dengan menggunakan lebih dari 100 Power Server, dalam test performa tercatat produktifitas sistem mencapai 80%, sedangkan jika 64 server maka akan mencapai 90%.

Dengan kombinasi PowerHA, maka teknologi ini mempunyai beberapa keunggulan
- unlimited capacity
- application transparency
- continuous availability

Produk ini akan tersedia di Power 550 Express dan Power 595.

Sumber
http://www-01.ibm.com/software/data/db2/9/editions-features-purescale.html

in Mails und Gesimmsels ?

Buschbrände ausser Kontrolle in Australien sind beUNruhigend, wenn man weiss, dass dbmS sich auf einer Farm in deren ca-Radius befindet.

BE-ruhigend ist die globalisierte Welt, wenn man hier nachts Message gefunkt kriegt, dass der Feuer-Radius ihn noch nicht erfasst hat

Noch BE-ruhigender ist, wenn ein Bild mitgesimmselt wird mit ihm und Koalabärlie als Klammeraffe in seinem Arm.

Jedenfalls solange mir keiner sagt, dass Koalas inzwischen Mobiles klauen, Bilder loaden und simmseln

Materialized Query Table (MQT) adalah sebuah table yang terbuat dari hasil sebuah query. Data yang ada di MQT berasal dari satu atau lebih table. MQT dapat dibayangkan seperti sebuah view. Namun query di view akan dijalankan ketika sebuah view dilihat, namun MQT menyimpan hasil query sebagai data sehingga tidak perlu melakukan query kembali.

Menggunakan MQT ini dapat meningkatkan kinerja terutama untuk query yang kompleks. Jika optimizer menganggap sebuah query atau sebagian dari query dapat menggunakan MQT, query dapat dibuat ulang untuk mendapatkan keuntungan dari MQT.

Ketika kita membuat MQT, kita dapat menentukan apakah table tersebut akan dimaintain oleh system atau oleh user. Jika dimaintain oleh system, maka tidak bisa dilakukan operasi insert, update atau delete terhadap table tersebut.

Ketika kita membuat MQT, juga kita dapat menentukan apakah data akan REFRESH IMMEDIATE atau REFRESH DEFERRED. Dengan ini kita dapat menentukan apakah data akan berubah secara otomotis jika terjadi perubahan pada table yang direferensi (REFRESH IMMEDIATE) atau terjadi saat diinginkan saja (REFRESH DEFERRED)

Sebelum menggunakan MQT, kita harus melakukan SET INTEGRITY terlebih dahulu karena MQT berada dalam check pending state.

Kita akan mencoba mempraktekkan MQT.
1. Buat sebuah table untuk menampung hasil query
2. Buat sebuah script bernama mqt.txt dan berisi script sebagai berikut
———————————————————————–
connect to sample;

alter table employee add unique (empid);
alter table department add unique (deptno);

create table emptest as (select e.empno,e.firstnme,e.lastname,d.deptno,d.deptname from employee e,department d where e.workdept = d.deptno)
data initially deferred refresh immediate;

set integrity for emptest immediate checked not incremental;
———————————————————————–

3. Kemudian jalankan db2cmd, arahkan ke path tempat script berasa dan ketikkan db2 – tvf mqt.txt

Table emptest diatas merupakan table yang dimaintained oleh system. Sehingga jika kita melakukan operasi insert, update atau delete maka akan muncul error DB21034E.

4. Buat sebuah script bernama mqt2.txt dan berisi script berikut
connect to sample;

create table ontario_2005_sales_team as (select distinct e.empno,e.firstnme,e.lastname, e.workdept, e.phoneno, ‘Ontario’ as region, year(s.sales_date) as year
from employee e, sales s
where e.lastname = s.sales_person and year(s.sales_date)= 2005
and left(s.region, 3) = ‘Ont’)
data initially deferred refresh deferred maintained by user;

set integrity for ontario_2005_sales_team materialized query immediate unchecked;

export to ontario_2005_sales_team.del of del
select distinct e.empno, e.firstnme,e.lastname,e.workdept,e.phoneno, ‘Ontario’ as region, year(s.sales_date) as year
from employee e, sales s
where e.lastname = s.sales_person and year(s.sales_date) = 2005 and left(s.region,3) =’Ont’;

import from ontario_2005_sales_team.del of del insert into ontario_2005_sales_team;

insert into ontario_2005_sales_team values(‘006900′,’RUSS’,'DYERS’,'D44′,’1234′,’Ontario’,2005);

select * from ontario_2005_sales_team;

5. Kemudian jalankan db2cmd, arahkan ke path tempat script berasa dan ketikkan db2 – tvf mqt.txt

Jika kita melihat, maka command insert yang kita lakukan diatas berhasil dengan baik. Hal ini terjadi karena kita menggunakan MAINTAINED BY USER.

Source
http://www.ibm.com/developerworks/data/library/techarticle/dm-0509melnyk/

Kita akan membahas mengenai penggunaan parameter yang ada di DB2. Paramater ini dapat merupakan configurasi instance atau database. Untuk sekarang kita akan membahas terlebih dahulu mengenai instance configuration.

Instance configuration dapat diliat dari Control Center ataupun dari command prompt. Jika dari command prompt maka ketikkan command “db2 get dbm cfg”, namun melihat dari commant prompt agak lebih sulit karena tidak terbagi-bagi. Jika menggunakan Control Center, pilih instance, kemudian klik kanan dan pilih Configure Parameter.

Ada beberapa pembagian configuration di Control Center.
1. Administration
2. Application
3. Communications
4. Diagnostic
5. Environment
6. Miscellaneous
7. Monitor
8. Parallel
9. Performance
10. Secure Socket Layer

Sekarang kita akan membahas yang communications.
1. discover : menentukan tipe dari permintaan recovery yang client dapat lakukan.

parameter yang digunakan
- search (default) : client dapat mengeluarkan search discovery request untuk mencari DB2 server di dalam jaringan.
- known : hanya discovery request yang dikenal saja yang dapat dilakukan oleh client. Client harus menentukan beberapa informasi agar dapat mendapatkan informasi dari DB2 server.
- disable : client tidak dapat melakukan discovery.

2. nname : berguna untuk menentukan nama node atau workstation di NetBIOS LAN.

3. svcename : berisikan nama dari port TCP/IP dimana database server menunggu komunikasi dari client. Untuk dapat menggunakan ini, service name harus didefinisikan terlebih dahulu di service file.

parameter
- null (default)

Sumber
http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=/com.ibm.db2.luw.admin.config.doc/doc/r0053734.html

Berikut adalah langkah-langkah untuk menginstall DB2 9.1 di Windows Server 2003
1. Lakukan cek dengan menjalankan db2prereqcheck.
2. Jika muncul output Instalation Prereq is OK, lanjutkan ke langkah berikut
3. Klik setup.exe.
4. Pilih Install the product, pilih install new
5. Pilih path installation C:\IBM
6. Isi username dan password, untuk domain pilih use local user account
7. Uncheck set up your DB2 server to send notification (jika memiliki SMTP server bisa diisi sesuai configurasi yang ada)
8. Baca kembali summary yang ada, kemudian klik install.
9. Start->Run ketik db2cmd, kemudian db2sampl.

Semoga bermanfaat.

Kadang kala kita membutuhkan versi dari Java dan JDBC yang kita gunakan. Beberapa aplikasi kadang membutuhkan versi yang spesifik untuk dapat berjalan. Dan JDBC cukup berpengaruh terhadap koneksi dari aplikasi ke database.

Berikut caranya
C:\>java -version
java version “1.6.0_13″
Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode, sharing)

C:\Program Files\IBM\SQLLIB\java>java com.ibm.db2.jcc.DB2Jcc -version
IBM DB2 JDBC Universal Driver Architecture 3.57.82

Semoga bermanfaat.

Kadang kala terjadi kecelakaan dimana tanpa sengaja kita melakukan drop table. Hal ini dapat dibetulkan dengan mudah dengan melakukan restore dari backup yang pernah kita lakukan. Namun pada database retail, melakukan restore 1 database untuk membetulkan 1 table sangat tidak efektif. Oleh karena itu kita dapat melakukan restore tablespacenya saja.

Berikut langkah-langkahnya
1. Buat sebuah database / atau bisa juga menggunakan database yang sudah ada
2. Cek apakah tablespace letak database tersebut fitur DROP_RECOVERYnya ON
db2 select TBSPACE, DROP_RECOVERY from SYSCAT.TABLESPACES

3. Jika tidak enable, maka untuk mengaktifkannya bisa menggunakan command berikut
db2 ALTER TABLESPACE DROPPED TABLE RECOVERY ON

4. Kemudian agar recovery dapat terjadi kita harus menggunakan log archival
db2 update db cfg for using logretain on

5. Lakukan backup database
db2 backup database

6. Buat sebuah table, lakukan insert, kemudian lakukan drop table
7. Kita dapat melihat history drop table. Disini kita bisa mendapatkan backup ID untuk table tersebut dan juga DDLnya
db2 list history dropped table all for

8 Lakukan restore dengan menggunakan backup, kemudian lakukan juga roll forward
db2 restore database test tablespace (USERSPACE1) from c:\backup without rolling forward without prompting
db2 rollforward database to end of logs and complete recover dropped table 000000000000af000002002 to c:\backup

9. Dengan menggunakan DDL yang ada buat kembali table tersebut.
10. Kemudian kita import content table dari file yg terjadi sebagai hasil dari langkah ke 8
db2 import from c:\backup\NODE0000\data of del method p(1) messages c:\recover.log insert into .

Semoga bermanfaat

DB2 Connection Concentrator dapat mengurangi sumber daya yang dibutuhkan oleh DB2 for OS/390 dan z/OS. Fungsi ini meningkatkan secara drastis scalability dan juga menyediakan operasi fail-safe dan load balancing.

Dengan fungsi ini memungkinkan DB2 Connect Enterprise menyediakan support bagi ribuan user secara simultan melakukan transaksi, dan juga mengurangi beban yang terjadi di database server. Hal ini dimungkinkan dengan cara memfokuskan workload dari semua aplikasi ke dalam koneksi database server yang lebih kecil jumlahnya.

Walaupun agak mirip dengan connection pooling, connection concentrator agak lebih rumit. Disini dikenalkan Logical Agent yang menangani user context sementara coordinating agent terus memiliki koneksi dan thread. Ketika user ingin melakukan koneksi, LA ditugaskan untuk ini. Ketika transaksi selesai, maka CA akan kembali ke ke pool dan lepas dari LA. Untuk menugaskan sebuah CA untuk sebuah transaksi, DB2 Connect menggunakan algoritma schedule yang menggunakan OS/390 dan z/OS Workload Manager (WLM).

Connection Concentrator ini aktif jika jika mengatur maximum logical agent (MAX_LOGICAGENTS) lebih tinggi daripada jumlah coordinating agent (MAX_COORDAGENT).

Berikut merupakan beberapa restriction untuk connection concentrator
- hanya dapat digunakan di DB2 version 7 ke atas
- menggunakan TCP/IP
- hanya mendukung dynamic SQL dari CLI. Aplikasi CLI juga tidak boleh menggunakan KEEPDYNAMIC.
- dynamic prepare request dari embedded dynamic SQL application akan ditolak. Gunakan static SQL atau gunakan CLI untuk dynamic SQL.

Berikut ini merupakan lanjutan artikel mengenai fitur compression yang dimiliki DB2. Dengan adanya fitur ini, perusahaan dapat menghemat kapasitas storage yang diperlukan untuk menyimpan database.

Selain row compression,db2 juga memiliki fitur lainnya seperti
- automatic index compression
- automatic temporary tables compression
- intelligent compression of large object
- backup compression
- value compression
- xml compression
- mdc

Kita akan membahas mengenai row compression. Berikut langkah-langkah dalam melakukan row compression
1. connect ke database
2. lakukan create / alter table
3. lakukan reorg

Kita akan mencoba mempraktekkannya
1. db2 connect to sample
2. db2 create table rowcompress (name varchar(50), dept varchar(50), salary int, zip char (5))
3. letakkan file insertrow, di path command prompt berada dan jalankan db2 -tvf insertrow.txt / lakukan insert dengan cukup banyak row.  Disini saya membuat sebuah file berisi perintah insert sebanyak 8000an row.
4. buka db2 control center, klik kanan pada table dan pilih estimate size. Kemudian cek berapa besar table tersebut seperti gambar di bawah

5. db2 alter table rowcompress compress yes
6. db2 reorg table rowcompress resetdictionary
7. jalankan no 4 kembali, jalankan runstat kemudian refresh. Maka akan menghasilkan seperti gambar berikut.

Jika kita lihat disini terjadi pengurangan ukuran dari 0.33KB menjadi 0.12KB. Terjadi penghematan hampir 30%. Namun angka ini dapat berubah tergantung redundancy data yang terjadi di table. Semakin banyak kemiripan, maka storage yang dapat di hemat akan semakin besar.

Semoga bermanfaat.

Di artikel sebelumnya kita sudah belajar bagaimana cara membuat database spatial. Namun ketika kita mengenable fitur spatial extender kita mendapatkan warning. Disini kita akan memodifikasi configuration atau istilahnya melakukan tuning.

Beberapa hal yang perlu dituning
1. Log : spatial extender membutuhkan log yang besar jika
- menggunakan database spatial di environtment windows
- menggunakan stored procedure ST_import_shape untuk mengimport shape file
- menggunakan geocoding dengan scope commit yang besar
- menjalankan concurrent transaction

Parameter yang perlu diganti
LOGFILSIZ default 1000, rekomendasi >1000
LOGPRIMARY default 3, rekomendasi 10
LOGSECOND default 2, rekomendasi 2

2. application heap size : parameter ini menentukan jumlah memory yang dialokasikan untuk digunakan oleh DBM untuk agent tertentu. Nilai defaultnya adalah 128 (4KB), untuk menjalankan spatial extender disarankan 2048

3. application control heap size : parameter ini menentukan jumlah maksimal memory shared untuk application control.

UPDATE DATABASE CONFIGURATION FOR spatial USING LOGFILSIZ 2000;
UPDATE DATABASE CONFIGURATION FOR spatial USING LOGPRIMARY 10;
UPDATE DATABASE CONFIGURATION FOR spatial USING LOGSECOND 2;
UPDATE DATABASE CONFIGURATION FOR spatial USING APPLHEAPSZ 2048;
UPDATE DATABASE CONFIGURATION FOR spatial USING APP_CTL_HEAP_SZ 1024;

Setelah menjalankan command diatas, maka proses spatial akan lebih cepat.

Semoga bermanfaat.

Berikut adalah langkah-langkah untuk membuat database spatial.
1. install DB2 9.5 ESE
2. install DB2 spatial extender for 9.5, default setting
3. buat database khusus untuk spatial
db2 create db spatial
4. enable fitur spatial extender
db2se enable_db spatial
Enabling database. Please wait …
GSE1036W  The operation was successful.  But values of certain
database manager and database configuration parameters should be
increased.
5. Kemudian dengan menggunakan file yang telah disediakan oleh DB2 Spatial Extender, kita mengimport file tersebut untuk mengisi database kita. Dengan mengimport file tersebut, kita membuat table bernama MAIN_STREETS, dengan kolom yang berisikan data spatial bernama SHAPE

db2se import_shape SPATIAL -filename sjMainStreets -srsName NAD83_SRS_1 -tablename MAIN_STREETS -createTableFlag 1 -spatialColumn SHAPE -idColumn SE_ROW_ID -commitScope 1000 -client 1

File tersebut bisa didapatkan di
…\GSE\image\db2\Windows\GSE_0029.cab

Kemudian kita membuat semua kolom spatial memiliki sebuah spatial reference system.

db2se register_spatial_column SPATIAL -tablename MAIN_STREETS -columnName SHAPE -srsName NAD83_SRS_1

Jika kita melihat, maka kita sudah membuat sebuah table berisikan data spatial. Data ini dapat dilihat secara visual dengan menggunakan tool seperti ESRI ArcExplorer, ArcView GIS, ArcInfo, ArcView BusinessAnalyst, ArcIMS dan ArcSDE.

Semoga bermanfaat.

Tool ini merupakan tool yang dapat digunakan untuk mengubah database source dari DBMS lain seperti Oracle, MySQL atau SQL Server dll ke DB2.

Berikut akan kita coba lakukan untuk migrasi dari SQL Server 2005
1. pertama-tama download tool ini di http://www.ibm.com/developerworks/apps/download/index.jsp?contentid=398532&filename=IBMDataMovementTool.zip&method=http&locale=worldwide
2. dari command prompt IBMDataMovementTool.cmd
3. buat database terlebih dahulu di DB2
4. kemudian isi configurasi sesuai koneksi database asal dan tujuan seperti gambar dibawah berikut.

5. jika 2 koneksi telah berhasil, klik button extract DDL/ data
6. kemudian klik deploy DDL/ data. Jika berhasil maka akan menghasilkan output seperti berikut.

7. lihat jika ada error / warning
8. cek di DB2 apakah database tersebut terbuat.

Sumber database yang saya gunakan memiliki 41 table dan merupakan database sebuah perusahaan pemesanan tiket pesawat. Proses konversi berjalan dengan mulus tanpa error. Jadi bisa dikatakan bahwa tool ini mempunyai tingkat keberhasilan yang tinggi.

Note :
untuk mengetahui port SQL server
1. Masuk ke SQL Server Configuration Manager
2. Masuk ke Protocol for SQLEXPRESS
3. Enabled TCP/IP
4. klik kanan TCP/IP dan pilih properties
5. lihat di TCP dynamic port

untuk mengetahui port DB2
1. Buka control center
2. klik kanan instance dan pilih setup communication
3. Lihat di bagian TCP/IP properties
4. Lihat port number