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)