Belajar oracle (lanjutan)

High Water Mark
Beberapa waktu yang lalu saya membahas tentang bagimana cara mengurangi size dari datafile (tablespace). Datafile tidak bisa dikurangi sampai batas High Water Mark (HWM).
Misalkan kita punya tablespace USERS yang punya datafile 3G. Namun bila kita lihat di OEM, TOAD, atau melalui view dba_free_space, ternyata datafile tersebut mempunyai free space cukup banyak yaitu 2G, itu artinya yang kepakai hanya 1G. Namun datafile tersebut tidak bisa diresize menjadi 1G, bahkan 2G saja tidak bisa.
SQL> alter database
datafile '/oradata/oracle/ts/users01.dbf' resize 2048M;
ORA-03297: file contains used data beyond requested RESIZE value
Dulunya, tablespace USERS mungkin (pasti) pernah kepakai sampai 3G. Bisa kepakai oleh table, index, ataupun temp segment. Namun sekarang sudah banyak yang dihapus sehingga yang terpakai hanya 1G. Nah ini yang penting, DULUNYA pernah dipakai. Oracle membuat aturan bahwa datafile tidak bisa di-resize menjadi ukuran maksimal yang DULUNYA pernah dipakai. Ukuran maksimal yang DULUNYA pernah dipakai ini disebut sebagai HIGH WATER MARK (HWM).
Begini analoginya. Misalkan di kampung kita ada tanggul kali yang tingginya 4 meter. Sejak adanya tanggul itu, paling tinggi air mencapai 3,5 meter (inilah yang disebut sebagai HIGH WATER MARK, batas air paling tinggi yang pernah dicapai), setengah meter lagi mencapai batas atas tanggul.
Namun sejak 10 tahun terakhir ini air paling tinggi hanya mencapai 2 meter. Karena itulah warga sekitar menyarankan agar tanggul diturunkan menjadi 2 meter saja. Tanggul yang tinggi 4 meter itu bikin pemandangan tidak sedap. Tapi… oleh pemerintah daerah tanggul tidak boleh diturunkan sampai 3,5 meter (apalagi di bawah itu). Kalau mau menurunkan ya paling tidak sampai 3,6 meter lah. Katanya, ‘pamali’ kalau menurunkan tanggul di bawah ketinggian air maksimal yang pernah dicapai.
Kira-kira begitulah pengertian HIGH WATER MARK.
Mari kita lihat lebih dalam. Datafile berisi block-block data. Bayangkan dinding yang terbuat dari tumpukan 100 batu bata. Pada awalnya block-block ini disusun secara berurutan. Pada suatu hari kita menghapus data (delete), analoginya kita mau mengambil 5 batu bata. OO… ternyata data (batu bata) yang kita cari itu ada di tumpukan paling bawah. Berikutnya kita ingin menghapus data lagi (sebanyak 4 batu bata). Dan sekarang batu bata yang ini ada di tumpukan tengah. Demikianlah seterusnya hingga akhirnya yang tersisa ada 40 batu bata.
Sekarang, tumpukan 40 batu bata itu tidak beraturan dan memamakan ruang sebesar tumpukan 100 batu bata. Namun kita tidak bisa ngapa-ngapain karena sudah begitu adanya. Kalo diutak-atik malah bisa rubuh tumpukan batu bata itu. Jadi space sebesar tumpukan 100 batu bata itulah yang disebut sebagai HIGH WATER MARK, batas tertinggi yang pernah dipakai.
Gimana cara memaksa untuk menurunkan size datafile sampai di bawah HIGH WATER MARK?
Caranya, rubuhkan dan susun ulang tumpukan batu bata itu. Di database, rubuhkan dan susun ulang block-block data itu. Begini caranya:
1. Export content (data-data) tablespace yang bersangkutan
2. Buat tablespace baru yang punya size lebih kecil
3. Import data yang telah di-export tersebut ke tablespace baru
4. Drop tablespace lama
Namun untuk tablespace SYSTEM kita tidak bisa melakukan hal di atas. Satu-satunya cara bagi tablespace SYSTEM adalah:
1. Export full database
2. Buat database baru yang ukuran tablespace SYSTEM-nya lebih kecil
3. Import full data yang telah di-export tersebut
4. Drop database lama
Tags: Database, datafile, oracle, resize, space, tablespace

Dataguard 10g: Switchover Physical Standby DB
Tulisan ini merupakan lanjutan dari serial Dataguard 10g. Tulisan terdahulu telah membahas tentang persiapannya, cara membuatnya, me-manage-nya, dan ada juga contoh kasus kalau kita kehilangan archived log. Sekarang saya akan membahas switchover (role transition) physical standby database.
Role transition, perubahan fungsi dari PRIMARY ke STANDBY dan sebaliknya, ada dua macam yaitu:
1. Switchover
Sesuai dengan istilahnya, ini adalah men-switch (mengubah) peran dari database STANDBY menjadi PRIMARY dan database PRIMARY menjadi STANDBY. Biasanya dilakukan kalau kita ingin melakukan maintenance pada mesin PRIMARY, misalnya menambah memory atau CPU yang memerlukan downtime.
2. Failover
Bila karena suatu hal tiba-tiba database PRIMARY mati, maka kita tidak bisa melakukan switchover karena database PRIMARY keburu mati duluan. Yang bisa kita lakukan adalah ‘memaksa’ database STANDBY untuk menjadi PRIMARY. Istilah ‘memaksa’ inilah yang kira-kira lebih pas untuk menjelaskan fail over.
Langkah-langkah melakukan Switch Over pada Physical Standby DB
Dalam contoh ini, database PRIMARY ada di MESIN A dan database STANDBY ada di MESIN B. Berikut ini persiapan yang mesti dilakukan:
1. Di database PRIMARY, close semua transaksi dan user session
2. Database PRIMARY harus dalam keadaan OPEN
3. SQL> select DATABASE_ROLE from v$database;
4.
5. DATABASE_ROLE
6. ----------------
7. PRIMARY
8.
9. SQL> select open_mode from v$database;
10.
11. OPEN_MODE
12. ----------
READ WRITE
Database STANDBY harus dalam keadaan MOUNT
SQL> select DATABASE_ROLE from v$database;

DATABASE_ROLE
----------------
PHYSICAL STANDBY

SQL> select open_mode from v$database;

OPEN_MODE
----------
MOUNTED
13. Verify bahwa switch over siap dilakukan. Jalankan query ini di kedua database PRIMARY dan STANDBY
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
Kondisi paling bagus (paling siap dilakukan switchover) adalah kalau kolom SWITCHOVER_STATUS di database PRIMARY nilainya “TO STANDBY” dan di database STANDBY nilainya “TO PRIMARY”
Namun lebih sering kolom SWITCHOVER_STATUS nilainya “SESSIONS ACTIVE”. Inipun gak masalah, switchover bisa dilanjutkan.
Lebih detail tentang kolom SWITCHOVER_STATUS di view V$DATABASE, silahkan lihat di sini Oracle® Database Reference - 10g Release 2 (10.2) - V$DATABASE
Sekarang kita menuju step utamanya
1. Di database PRIMARY (MESIN A)
Lakukan switchover dengan perintah berikut
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;
Kalau masih ada user yang aktif, akan muncul error berikut
ORA-01093: ALTER DATABASE CLOSE only permitted
with no sessions connected
Solusinya adalah: close (kill) semua user session atau tambahkan parameter WITH SESSION SHUTDOWN sehingga command-nya menjadi:
ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;
Setelah itu shutdown dan startup mount.
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
Sekarang verifikasi bahwa database PRIMARY telah beralih menjadi STANDBY
SQL> select DATABASE_ROLE from v$database;

DATABASE_ROLE
----------------
PHYSICAL STANDBY
2. Di database STANDBY (MESIN B)
Sekarang, database STANDBY kita switchover menjadi PRIMARY. Jalankan command berikut:
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
Mungkin kita akan menjumpai error seperti ini:
ORA-16139: media recovery required
Kalau menjumpai error tersebut, jalankan “recover managed standby database” kemudian jalankan switchover:
SQL> recover managed standby database;
Media recovery complete.
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
Setelah switchover berhasil, kemudian open database:
SQL> alter database open;
ORA-01507: database not mounted
Oo… Error. Ternyata tadinya STANDBY database (sejak last startup) pernah saya “OPEN READ ONLY”, jadinya error kayak gitu. Kalau tidak pernah di-”OPEN READ ONLY” harusnya tidak error. OK, kalo gitu, solusinya: restart database.
SQL> SHUTDOWN IMMEDIATE;
SQL> startup
Dah berhasil. Sekarang verify bahwa STANDBY database telah menjadi PRIMARY
SQL> select DATABASE_ROLE from v$database;

DATABASE_ROLE
----------------
PRIMARY

Startup dan shutdown instance
Administrasi (aktivitas) yang bisa kita lakukan pada instance adalah startup, shutdown, dan alter. Secara umum proses startup adalah sebagai berikut:
1. Database mati (shutdown)
Background process belum naik. Memori belum dialokasikan
2. nomount
Backgroung process dinaikkan. Memory dialokasikan
3. mount
Instance membaca control file. Control file berisi konfigurasi database. Instance belum membaca data file.
4. open
Instance sudah membaca data file (header). Database siap diakses

Command (perintah) startup :
startup
startup open
startup nomount
startup mount
startup force
Command “startup” saja tanpa argument, by default adalah “startup open”
Command “startup force” adalah sama saja dengan “shutdown abort” kemudian “startup”
Command shutdown :
shutdown normal
shutdown transactional
shutdown immediate
shutdown abort
Berikut ini perbandingan proses shutdown normal (N), transactional (T), immediate (I), dan abort (A):


Men-setting database menjadi archivelog mode
Di database Oracle, semua transaksi di-record (disimpan) di dalam log file. Dalam 1 instance, minimal ada 2 group logfile. Mekanisme kerjanya adalah sirkular. Bila logfile penuh, maka transaksi disimpan di log berikutnya. Setelah semua log terisi, maka log yang terlama akan ditulis ulang (rewrite), tentu saja dengan menghapus content (isi) sebelumnya. Tentu saja, kita akan kehilangan jejak transaksi yang ada di logfile tersebut.
Dalam database dengan mode archivelog, sebelum logfile ditulis ulang, content-nya dicopy (backup) dulu ke archived log. Oleh karena itu kita tidak kehilangan jejak transaksi yang disimpan di log yang ditulis ulang tersebut.
Archived log digunakan untuk recovery database. Bila kita me-restore dari hasil offline backup, maka data yang bisa diambil adalah data ketika off line backup dilakukan. Jadi, seandainya full backup dilakukan sebulan yang lalu, maka data yang bisa diselamatkan (diambil) adalah data sebulan yang lalu tersebut.
Berbeda dengan jika kita me-restore dari hasil online backup. Setelah file backup di-restore, kemudian archived log yang terbentuk setelah online backup (yang berisi rekaman transaksi itu) di-apply kembali (istilahnya recovery). Sehingga kita bisa mendapatkan data sampai archived log terakhir, atau sesaat sebelum terjadi bencana (kerusakan database).
Untuk melihat apakah database sudah dalam mode archivelog atau tidak
SQL> archive log list
Database log mode No Archive Mode
Automatic archival Disabled
Archive destination /oradata/oracle/ts/arc
Oldest online log sequence 56
Next log sequence to archive 58
Current log sequence 58
Dalam contoh di atas, mode database masih belum archivelog. Untuk mengaktifkan mode archivelog, jalankan command berikut:
SQL> shutdown immediate
SQL> startup mount
SQL> alter database archivelog;
SQL> alter database open;
Lihat, sekarang mode database sudah archivelog
SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /oradata/oracle/ts/arc
Oldest online log sequence 56
Next log sequence to archive 58
Current log sequence 58
Catatan:
Perintah “alter database archivelog” adalah untuk membuat mode database menjadi ARCHIVELOG. Untuk meng-archive log file dilakukan dua cara:
1. Manual
2. otomatis
Pilihan manual adalah jarang terjadi, kecuali untuk tujuan tertentu, misalnya belajar. Semua database production selalu memilih yang otomatis.
Untuk mengotomatiskan pekerjaan archive, init parameter log_archive_start harus TRUE. Jadi harus mengaktifkan parameter tersebut di file init.
Saya menggunakan database 10g release 2 (10.2.0). Parameter log_archive_start tidak perlu saya setting, alias bernilai false, tapi archive jalan otomatis. Kayaknya di versi 10g parameter ini dah gak dibutuhkan lagi, saya belum explore lebih jauh.
Yang pasti, database 10g saya archive-nya jalan otomatis tanpa mensetting parameter log_archive_start.
Tags: archive log, Backup, Database, mode, online, oracle, recovery, restore