Restoring an Existing DDL Environment to a Clean State

Ketika kita mengaktifkan DDL replication di Golden Gate, user Golden Gate akan  melakukan pencatatan terhadap semua proses DDL yang berlangsung didatabase dan menyimpanya didalam table GGS_MARKER.

Jika kita tidak mengaktifkan auto purging terhadap table ini, maka table GGS_MARKER bisa jadi akan sangat besar dan memakan resource disk didatabase yang cukup signifikan. Padahal ddl yang sudah di replikat sebenarnya sudah tidak diperlukan lagi.

Namun, mengaktifkan fitur auto purging DDL_MARKER di saat table tersebut sudah terlanjur besar adalah pekerjaan yang sangat beresiko, karena proses purging terhadap data yang ada akan membuat undo tablespace dan temp tablespace menjadi membengkak.

Untuk itu, kali ini saya ingin membuat tutorial untuk mengembalikan table DDL_MARKER ini kembali kedalam clean state, atau kosong. Setelah itu kita bisa mengaktifkan fitur auto purging tanpa rasa hawatir akan tablespace undo dan temp yang membengkak. Berikut langkah langkahnya .

Langkah pertama, masuk ke direktori instalasi Golden Gate dan masuk ke ggsci. Stop semua extract dan replicat service untuk menghentikan adanya ddl replication untuk sementara.

Langkah selanjutnya adalah, disable ddl replication. Keluar dari ggsci command line, dan masuk ke dalam sqlplus /"as sysdba" masih dalam directory Golden Gate.

Langkah ketiga adalah eksekusi ddl_remove.sql melalui sqlplus masih dari directory Golden Gate. Script ini akan meminta user Golden Gate yang ada di database dan melakukan spool dengan nama file dd_remove_spool.txt untuk keperluan debugging.

Setelah selesai eksekusi ddl_remove.sql, selanjutnya adalah eksekusi marker_remove.sql, masih didalam Golden Gate direktori.

Jika, ada error ORA-20783 seperti di bawah ini yang keluar ketika eksekusi marker_remov, langkah untuk mengatasinya dalah dengan membuat ulang password file untuk sys menggunakan command :

orapwd password=<yousyspassword> file=$ORACLE_HOME/dbs/orapw<YOURSIDNAME> entries=<limit>

Jika sudah sukses eksekusi marker_remove, selanjutnya adalah konfigurasi ulang untuk ddl replication untuk masuk kedalam kondisi clean state. Masih di sqlplus, eksekusi marker_setup.sql

Selanjutnya adalah eksekusi ddl_setup.sql, masukkan Golden Gate user jika diminta, dan masukkan yes ketika konfirmasi untuk membersihkan Recyclebin database oracle.

 Langkah berikutnya dalah eksekusi role_setup.sql, masukkan Golden Gate user jika diminta, dan eksekusi grant command yang diminta di akhir proses.

Untuk menghindari tablespace yang filled up oleh ddl marker ini,kita harus mengaktifkan purgeddlhistory di manager. Stop manager, edit parameter manager, tambahkan line berikut dan restrart manager.

PURGEDDLHISTORY MINKEEPDAYS 5, MAXKEEPDAYS 10
PURGEMARKERHISTORY MINKEEPDAYS 5, MAXKEEPDAYS 10

Langkah terakhir adalah mengaktifkan ddl replication dengan eksekusi command ddl_enable dari sqlplus pada direktori Golden Gate. dan start semua extract dan replicat.

 sekian tutorial untuk membersihkan ddl history dan masuk kedalam mode clean state.

Oracle Golden Gate : Replicat checkpoint lagtime keep growing with status running

We have a source schema BLP in  database OLSV102 in host PREPAID01 replicated to schema BLP in database OLSV102 in host PREPAIDDRC01. An application access this mirror database for reporting purpose. On Monday, 20 October 2014, people in charge to generate the report told me that he could not generate any report from 17 October 2014 and we can see that in the target database, no new data after 16 October 2014 16:43 PM.

we saw the replicat checkpoint lag keep growing. the culprit was tablespace that is used by BLP schema reach its limit.We  added new datafiles. after waiting several hours, the replicat checkpoint lag keep growing. and when i executed command :

send <replicat_name>, status

it returned 0 processed data.
any idea or suggestion ?

(i posted this issue in 2 other discussion forum, as soon as i got any hints, ill update this post)

Migrasi database dari MySQL ke Oracle Database Menggunakan Sql Developer

Ketika memasuki kantor yang sekarang, saya mendapatkan challenge untuk memigrasikan salah satu database perusahaan dari MySQL ke Oracle. Pertama kali, namun tidak terlalu khawatir karena mbah google menyediakan banyak link tutorial. Kali ini akan saya tuliskan, catatan saya sendiri.....

Database yang akan saya migrasikan berasal dari database MySQL versi 5 yang ada pada server linux, dan akan dimigrasikan ke oracle 11g pada server yang sama. Hal pertama yang harus dipersiapkan adalah installasi sql developer.

Pada awalnya, sql developer saya install di pc saya, dan membuat koneksi ke database MySql dan Oracle yang ada disever, namun hal ini mengalami kendala untuk tabel yang cukup besar, proses akan terhenti karena java-heap-space. Alternatif yang saya lakukan adalah installasi sql developer di sisi server karena kapasitas dan memorynya tentu lebih lega.

Jika aplikasi sql developer sudah tersedia, langkah berikutnya adalah mengaktifkan koneksi sql developer ke MySQL, karena secara default, sql developer hanya memberikan tab konfigurasi ke database oracle. Tutorial untuk mengaktifkan koneksi dari sql developer ke database MySql akan saya buat di thread terpisah.


Jika koneksi ke database MySQL sudah di enable di sql developer, buat lah koneksi ke database MySQL yang menjadi source database. Buat juga koneksi ke database oracle yang menjadi target migrasi.

koneksi ke database target oracle

Buat sebuah user baru di sisi di Oracle khusus untuk menyimpan repository migrasi. Dalam percobaan saya, saya membuat sebuah user dengan nama migruser menggunakan perintah berikut:

  create user migruser identified by migruser

Koneksi ke database source mysql

User yang berfungsi untuk menyimpan repositori migrasi harus mendapatkan role Resource, dan juga mendapatkan sys privilege yaitu create session dan create view.

grant resource to migruser

grant create session to migruser

grant create view to migruser

Tools -> Migration -> Repository Management -> Create Repository

Setelah user baru jadi dan mendapatkan role dan privileges yang diperlukan, buat koneksi user baru tersebut di sql developer. 

Untuk membuat repository, klik Tools pada toolbar dan pilih Migration->Repository Management ->Create Repository.

Jendela introduction dan ringkasan step step migrasi

Jendela introduction terhadap repository akan dibuka, pada jendela tersebut klik Next untuk melanjutkan.

Pilih koneksi repository

Pada jendela ini, kita harus menentukan koneksi yang akan digunakan untuk membuat repository. dalam hal ini, saya menggunakan koneksi mengguankan user migruser  seperti yang tampak pada capture berikutnya.

Create project dan direktori

Pada jendela  berikutnya kita akan membuat sebuah project migrasi mengan memasukkan nama project dan juga direktori tempat menyimpan output yang dihasilkan dari proses migrasi ini. Dalam hal ini, nama project yang saya masukkan adalah csi_migration.

Memilih koneksi database sumber

Jendela berikutnya adalah untuk memilih koneksi source database yaitu database mysql yang sudah kita konfigur sebelumnya. Pada opsi Mode, pilih Online jika migrasi dilakukan pada saat koneksi ke database tidak dibatasi.

Memilih database yang akan dimigrasikan

Setelah kita memilih koneksi database sumber, langkah selanjutnya adalah memilih database yang akan kita migrasikan. Jika user yang kita gunakan untuk login ke database MySQL memilihi privilege untuk mengakes lebih dari satu database, maka semua database tersebut akan di tampilkan. Kita dapat memilih satu atau lebih database untuk dimigrasikan dalam satu project.

Mapping tipe data

Langkah berikutnya adalah melakukan mapping tipe data. Pada dasarnya sql developer sudah melakukan mapping secara otomatis, tapi kita tetap dapat merubah default mapping tersebut.

Object object lain yang bisa diikut dalam migrasi

Jendela berikutnya kita menentukan object object yang ingin di translate. Table dan index pada dasarnya langsung akan di migrasikan. Tetapi kita dapat memilih object oject seperti constraint, function, procedure,  trigger dan views untuk ikut di migrasi ke target database atau tidak.

Pilih koneksi database target

Jendela  berikutnya adalah memilih koneksi untuk target database oracle yang sudah kita konfigure sebelumnya. Pada pilihan Mode migrasi, pilih Online karena database target dalam kondisi open.

Berikutnya adalah menentukan koneksi sumber dan target untuk move data. Pilih koneksi Mysql pada Source dan koneksi ke oracle database sebagai target. Pada pilihan Mode, pilih online untuk melakukan migrasi data pada saat kedua database dalam keadan open. Klik Finish untuk mengakhiri konfigurasi dan memulai proses migrasi.





Pada tahap ini kita tinggal duduk, menyenderkan punggung di sandaran kursi dan menunggu proses migrasi selesai. Sekian tutorial migrasi, monggo yang kalo ada yang ingin di tanyakan atau ingin  di komplein ataau ada cara lain yang jauh lebih Oke

Solveed : ORA-28000 Locked Account

Hari ini, seorang temen yang nanganin aplikasi RTS/X, entah aplikasi apalah itu yang diberikan oleh BI ke setiap perbankan, mengalami masalah. Aplikasi tidak bisa jalan karena masalah login ke database. Usut punya usut, user yang digunakan ternyata dalam kondisi lock. Wow, pasti baru baru ini ada  yang mencoba masuk dengan nebak nebak password nih.

Untuk mengetahui status user, kita bisa query ke oracle view, dba_users, menggunakan query berikut:

 select account_status from dba_users where username='myusername'

 Untuk mengilangkan status lock ini tidak terlalu sulit, cukup eksekusi perintah berikut :

alter user myusername identified by myusername account unlock;

 simple kaaaan ??

Handover II : Export Import menggunakan EXPDP

Hari kedua gw bersama sang mentor, Nandar, gw diajarin untuk melakukan migrasi database dari satu server ke server lainnya menggunakan EXPDP.

Expdp atau dikenal dengan Export Data Pump adalah salah satu utilitas dari oracle database untuk melakukan export database untuk kebutuhan migrasi dari satu database ke database lainnya (masih dalam platform oracle). Fitur serupa adalah EXP yaitu Export Utility Wizard. Serupa tapi tak sama. Expdp jauh lebih powerfull dari pada Exp sehingga menjadi favorit saya tiap kali harus migrasi data dari satu database ke database yang lainya.

Jika Expdp adalah utilitas untuk export, maka oracle menyediakan Impdp. Fitur Impdp digunakan untuk melakukan import data dari dump file (*.dmp) yang dihasilakan dari Expdp. Artinya, kita tidak bisa menggunakan impdp untuk melakukan import data dari dump file yang dihasilkan oleh Exp dan begitu juga sebaliknya.

Berikut adalah prerequisite untuk dapat memanfaatkan utilitas ini .

1. Jika menggunakan utilitas ini menggunakan user selain user sys dan system, pastikan user tersebut sudah mendapatkan grant untuk menggunakan sys privilege Export Full Database untuk Expdp dan Import Full Database untuk Impdp.
2. Jika menggunakan utilitas ini menggunakan user selain user sys dan system, pastikan user tersebut sudah mendapatkan privilege read dan write terhadap directory DATA_PUMP_DIR atau directory lain yang digunakan selama memanfaatkan utilitas Expdp/Impdp. Jika tidak yakin apakah user tersebut mendapatkan akses read, dan write terhadap directory tersebut,  gunakan script berikut untuk grant akses read dan write terhadap sebuah directory.

grant read,write on directory DATA_PUMP_DIR to myuser

 Gunakan script berikut untuk melihat directory beserta physical path yang ada pada database tersebut :

select * from dba_directories;

3. Pastikan ORACLE_SID, ORACLE_BASE, ORACLE_HOME sudah disetting dengan benar di environment user OS yang login.
4. Pastikan $ORACLE_HOME/bin sudah terdafter dalam variable Path

 Contoh paling sederhana penggunaan Expdp/Impdp :

expdp <username>/<password> schemas=<schemaname> directory=<directoryname> dumpfile=<dumpfilename> logfile=<logfilename>

expdp blp/blp schemas=blp directory=data_pump_dir dumpfile=blp.dmp logfile=expdp_blp.log

impdp <username>/<password> schemas=<schemaname> directory=<directoryname> dumpfile=<dumpfilename> logfile=<logfilename>

 impdp blp/blp schemas=blp directory=data_pump_dir dumpfile=blp.dmp logfile=impdp_blp.log

Script diatas akan melakukan export schema blp dalam bentuk dumpfile yang disimpan di directory data_pump_dir. Sebelum melakukan eksekusi script tersebut, pastikan tidak ada file dengan nama yang sama pada physical path directory tersebut. Jika tidak, maka script tersebut akan gagal. Value pada parameter schemas bisa lebih dari satu, setiap schema yang ingin di export dipisahkan menggunakan koma ','.

Berikut adalah contoh melakukan export hanya pada salah satu atau lebih table.

expdp <username>/<password> tables=<tablename> directory=<directoryname> dumpfile=<dumpfilename> logfile=<logfilename>

expdp blp/blp tables=account directory=data_pump_dir dumpfile=blp.dmp logfile=expdp_blp.log

impdp <username>/<password> schemas=<tablename> directory=<directoryname> dumpfile=<dumpfilename> logfile=<logfilename>

 impdp blp/blp schemas=account directory=data_pump_dir dumpfile=blp.dmp logfile=impdp_blp.log

 Skrip diatas akan melakukan export hanya pada table yang disebutkan saya pada parameter tables. Value tersebut dapat lebih dari satu tables, dan pisahkan menggunakan koma ','.

Lalu bagaimana jika kita ingin melakukan export hanya pada table table tertentu saja ? kita bisa menambahkan parameter include. Jika kita ingin melakukan pengecualian pada proses export kita bisa menggunakan parameter exclude. Kedua parameter tersebut berlaku juga untuk proses import menggunakan Impdp. Berikut adalah contoh penggunaan kedua parameter tersebut.

expdp blp schemas=blp dumpfile=blp.dmp logfile=impdp_blp.log directory=data_pump_dir  include=TABLE:\"IN \(\'EFT_POS\',\'POS_MESSAGE\'\)\"

impdp blp schemas=blp dumpfile=blp.dmp logfile=impdp_blp.log directory=data_pump_dir  exclude=TABLE:\"IN \(\'EFT_POS\'\)\"

Pada contoh diatas, saya melakukan export terhadap  2 table EFT_POS dan POS_MESSAGE menggunakan parameter include. Dumpfile yang terbentuk kemudian di import, namun hanya table POS_MESSAGE, menggunakan parameter exclude. Parameter include dan exclude ini tidak terbatas pada filter untuk table, para meter tersebut juga berlaku untuk object lain seperti prosedur, trigger, index.

Kasus lain adalah bagaimana jika kita ingin melakukan export dari schema blp, dan kemudian akan di import ke schema lain bernama blp2 ? kasus seperti ini kita bisa lakukan dengan menambahkan parameter remap_schema=schema_lama:schema_baru.  Pastikan schema yang baru tersebut benar benar ada pada database tersebut.

Setiap object di dalam database yang menyimpan data yaitu table dan index memerlukan tablespace untuk menyimpan data tersebut secara logical. Namun bagaimana jika export schema blp yang kita lakukan dari database A menggunakan tablespace tblspc_a, dan akan kita import ke database B yang memiliki tablespace tblspc_b. Ada dua opsi dalam melakukan import untuk kasus seperti ini, yaitu membuat tablespace tblspc_a di database B atau menambahkan parameter remap_tablespace pada script import yang kita gunakan dengan format remap_tablespace=tablespace_lama:tablespacebaru,tablespace_lama:tablespace_baru. Koma kita gunakan untuk memisahkan jika kita perlu melakukan remap terhadap lebih dari satu tablespace.

Salah satu kasus yang pernah saya alami juga adalah harus melakukan migrasi data dari oracle 11g dan akan diimport kedalam database oracle 10g. Dalam kasus seperti ini, kita harus menambahkan parameter version pada script export kita dengan format version=10.2.0 dan akan dapat digunakan untuk import dengan format seperti biasa.

sekian dulu catatan saya tentang menggunakan expdp ini, kalo ada yang ingin di tanyakan monggo, atau saran untuk ditambahkan, silahkan tuliskan di komentar dan akan saya update halaman ini, atau kalo ada koreksi juga sangat diperlukan.

Hand over : Arsitektur Oracle Database

Ini lah perkenalan pertama gw dengan oracle databaase. Kejadianya di kantor BII Maybank, Sentral Senayan III lt 3. Nandar, nama mentor gw saat itu, tinggal 2 hari bekerja di PT Aprisma. Jadi gw punya waktu 2 hari untuk belajar Oracle Database dan menjadi DBA. Wonderfull.... :]

oracle arsitektur sederhana

Yang pertama kali, gw dikenalkan dengan yang nama nya oracle arsitektur. Dari coret coretan yang di reka ulang, arsitektur oracle itu terdiri dari instance yang didalamnya terdapat memory structure yaitu SGA dan PGA, serta process sturcture yaitu PMON, SMON, DBWR, LGWR dan CKPT.

Selain instance, oracle database juga memiliki database files yang terdiri dari data files, log files dan control files.

selain dua komponen diatas, terdapat juga komponn komponen lain yang menduruk kerja oracle database, yaitu parameter file (pfile), password file, archive log, server process dan user process. Untuk lebih jelasnya, masing masing komponen diatas akan di jelaskan dalam halaman terpisah. 

kira kira beginilah isi dari hari pertama gw hand over dengan Nandar.

Perkenalkan saya

Perkenalkan saya.. Herman Ginting :D

DBA, aka Database Administrator bisa dibilang salah satu profesi idaman mahasiswa mahasiswa Teknik Komputer. Beberapa teman saya kuliah, dan kenalan semasa kerja, banyak yang bertanya tanya, bagaimana saya bisa menjadi seorang DBA. Well jawabanya adalah Rezeki dari Allah..wkwkwk

Semasa kuliah, saya sangat menikmati dunia per-koding-an, saya mempelajari java desktop, php, java ee hingga mengantarkan saysa pada pekerjaan professional pertama saya di semester 6 sebagai programmer Adobe Coldfusion di DataOn Corp (PT Indodev Niaga Internet).  Di DataOn, saya banyak expolore pemanfaatan componen dan store procedure dari SQL Server untuk mengolah data sebelum di tampilkan atau di olah kembali di sisi aplikasi.

Jenuh dengan per-koding-an di DataOn, saya memutuskan untuk tidak melanjutkan kontrak kerja saya setelah bekerja 1 tahun 2 bulan. Setelah menganggur selama 2 minggu, saya di panggil oleh PT Aprisma Indonesia untuk posisi System Engineer. 

Melamar sebagai System Engineer, saya hanya bermodalkan ijazah lulusan Fakultas Ilmu Komputer, saya sama sekali tidak ada ide hal hal yang dikerjaan oleh orang orang di divisi ini. Mengetahui background saya yang sering berinteraksi dengan store proc di perusahaan sebelumnya, Manager HRD PT Aprisma Indonesia akhirnya mengarahkan saya untuk menjadi Database Specialist aka DBA, salah satu komponen di System Engineer mereka. Jadi lah mulai saat itu saya berprofesi sebagai DBA.

1 tahun 4 bulan di Aprisma, saya akhirnya memutuskan untuk resign. Saya melihat kondisi saya sebagai DBA yang dikirim ke client dengan permasalah yang cenderung tidak variatif dan pemanfaatan teknologi di bidang database yang sangat terbatas. Banyak hal di dunia database, khususnya oracle yang saat itu saya pegang tidak bisa saya explore karena semua bergantung pada kebutuhan client.

 Sekarang saya bekerja sebagai DBA di salah satu bank swasta nasional. Disini ada lebih banyak hal yang sudah saya explore di dunia database yang akan saya bagikan melalui blog sederhana ini. Sebagai DBA di bank yang memiliki banyak sekali aplikasi, saya akhirnya juga harus belajar banyak database mulai dari Oracle, MySQL, SQL Server, DB2 hingga AS400.

Sekian perkenalan singkat saya, dan lets get in touch..