9. MANAGING UNDO DATA
Objektif :
Setelah menyelesaikan materi ini, peserta dapat melakukan hal sebagai berikut : 1. Menjelaskan DML dan membatalkan pembuatan data
2. Memantau dan mengelola pembatalan Data
3. Menjelaskan perbedaan antara data undo dan redo data 4. Konfigurasi membatalkan retensi
5. Jaminan membatalkan retensi 6. Menggunakan Undo Advisor
9.1. Data Manipulation
Data dimanipulasi, atau dimodifikasi, oleh kelas DML dengan statement SQL : INSERT, UPDATE, DELETE, dan MERGE. Pernyataan-pernyataan ini mengeksekusi sebagai bagian dari transaksi, yang dimulai dengan sukses pernyataan DML pertama dan berakhir dengan baik COMMIT atau ROLLBACK perintah. Sebuah transaksi adalah baik seluruhnya diberikan perintah COMMIT atau ROLLBACK
Rollback juga dapat terjadi jika ada proses atau sistem kegagalan.
Catatan: perintah Merge melakukan kombinasi sisipan dan update untuk menggabungkan data dari satu tabel ke tabel lain.
9.2. Undo Data
Oracle Database menyimpan nilai lama (undo data) ketika proses perubahan data dalam database. Menyimpan data seperti yang ada sebelum dimodifikasi. Menangkap pembatalan data yang memungkinkan untuk memutar kembali data yang tidak terikat. Undo juga mendukung read- consistent dan flashback query.
Read-consistent query memberikan hasil yang konsisten dengan data pada saat query dimulai.
Agar query read-consistent berhasil, informasi asli masih harus ada seperti informasi undo. Selama informasi undo dipertahankan, database Oracle dapat merekonstruksi data yang untuk memenuhi permintaan read-consistent.
Query Flashback adalah query yang sengaja meminta versi data sebagaimana yang ada pada beberapa waktu di masa lalu. Selama membatalkan informasi untuk itu masa lalu masih ada, query flashback dapat berhasil menyelesaikan. Membatalkan data juga digunakan untuk memulihkan data dari transaksi gagal. Sebuah transaksi gagal terjadi ketika sesi pengguna berakhir tidak normal (mungkin karena kesalahan jaringan atau kegagalan pada komputer klien) sebelum pengguna memutuskan untuk commit atau rollback transaksi. Transaksi gagal juga dapat terjadi ketika misalnya crash.
Dalam transaksi gagal, perilaku yang paling aman yang dipilih, dan database Oracle membalikkan semua perubahan yang dilakukan oleh pengguna, dengn mengembalikan data asli.
Urungkan mempertahankan informasi untuk semua transaksi, setidaknya sampai transaksi berakhir dengan :
Pengguna mengembalikan transaksi (rollback)
Pengguna mengakhiri transaksi (commit)
Pengguna sesi normal terminating (rollback)
Pengguna sesi biasanya mengakhiri dengan exit (commit)
Jumlah data undo yang ditahan dan waktu untuk yang dipertahankan tergantung pada jumlah aktivitas database dan konfigurasi database.
9.3. Transactions and Undo Data
Ketika transaksi dimulai, ditugaskan untuk segmen sepanjang kehidupan transaksi, ketika data berubah, asli (sebelum perubahan) nilai-nilai yang disalin ke dalam segmen undo. Dapat dilihat transaksi yang ditugaskan untuk yang membatalkan segmen dengan memeriksa v$transaction dengan view performa dinamis.
Membatalkan segmen adalah segmen khusus yang secara otomatis dibuat oleh contoh yang diperlukan untuk mendukung transaksi. Seperti semua segmen, membatalkan segmen terdiri dari luasan, yang, pada gilirannya, terdiri dari blok data. Membatalkan segmen otomatis tumbuh dan menyusut sesuai kebutuhan, bertindak sebagai buffer penyimpanan melingkar untuk transaksi mereka ditugaskan.
Transaksi mengisi di segmen undo mereka sampai transaksi selesai atau semua ruang dikonsumsi. Jika batas mengisi dan lebih banyak ruang yang dibutuhkan, transaksi memperoleh yang ruang dari tingkat berikutnya dalam segmen. Setelah semua luasan telah dikonsumsi, transaksi baik membungkus kembali ke tingkat pertama atau meminta batas baru yang akan dialokasikan untuk segmen undo.
Catatan: operasi DML Paralel sebenarnya dapat menyebabkan transaksi untuk menggunakan lebih dari satu segmen undo.
9.4. Storing Undo Information
Segmen Undo hanya bisa dilakukan dalam bentuk khusus tablespace disebut tablespace undo.
Meskipun database mungkin memiliki banyak membatalkan tablespace, hanya salah satu dari mereka pada suatu waktu dapat ditunjuk sebagai salah satu saat yang membatalkan data ditulis.
Segmen undo selalu dimiliki oleh SYS. Karena segmen bertindak sebagai penyangga melingkar, setiap segmen memiliki minimal dua luasan. Jumlah maksimum default luasan tergantung pada ukuran blok database, tapi sangat tinggi (32.765 untuk ukuran blok 8-KB).
Undo tablespace adalah permanen, tablespace dikelola secara lokal dengan alokasi batas otomatis. Mereka berhasil seperti tablespace lain dengan pengecualian pemulihan. Karena data undo diperlukan untuk memulihkan dari transaksi gagal (seperti yang mungkin terjadi saat sebuah contoh crash), membatalkan tablespace dapat dipulihkan hanya sementara contoh dalam keadaan MOUNT.
9.5. Undo Data Versus Redo Data
Undo data dan redo data tampak sama pada awalnya, tetapi mereka melayani tujuan yang berbeda. Membatalkan data yang diperlukan jika ada kebutuhan untuk membatalkan perubahan, dan ini terjadi untuk read-consistency dan rollback. Redo data yang diperlukan jika ada kebutuhan untuk melakukan perubahan lagi, dalam kasus mereka hilang untuk beberapa alasan.
Proses commit memerlukan verifikasi bahwa perubahan dalam transaksi telah ditulis ke file redo log, yang merupakan penyimpanan persisten pada disk, sebagai lawan memori. Selain itu, biasanya multiplexing. Jadi, ada beberapa salinan data redo pada disk. Meskipun perubahan mungkin tidak belum ditulis ke file data di mana blok tabel sebenarnya disimpan, menjamin bahwa perubahan telah ditulis ke file redo log cukup. Sebuah pemadaman listrik yang terjadi sebelum perubahan berkomitmen telah tercermin ke dalam file data tidak menimbulkan masalah karena transaksi telah dilakukan. Jadi, ketika sistem dimulai lagi, ia mampu menggulung maju setiap catatan redo yang belum tercermin dalam file data pada saat outage.
Gambar 9.1.Undo Data Versus Redo Data
9.6. Monitoring Undo
Sebagian besar waktu, undo dikelola secara otomatis oleh misalnya dengan sedikit kebutuhan untuk database administrator (DBA) Beberapa hal yang mungkin memerlukan keterlibatan administrator meliputi:
Tidak cukup ruang untuk undo
Pengguna menerima pesan kesalahan ORA-01555 snapshot too old
Informasi undo selalu dipertahankan sampai transaksi berakhir. Ini berarti bahwa jika jumlah yang sangat besar data yang dihapus atau diperbarui (operasi Insert mengkonsumsi ruang undo sangat sedikit karena gambar asli dari data yang dimasukkan adalah nilai null.) Tanpa dilakukan, undo tablespace harus sama-sama besar untuk memuat data asli . Bayangkan sebuah kasus di mana tabel 50-GB memiliki semua baris dihapus dengan perintah berikut:
SQL> DELETE FROM reallybigtable;
Undo tablespace akan diperlukan untuk membuat ruang untuk 50 GB dari informasi asli hanya dalam kasus pengguna yang mengeluarkan pernyataan ini berubah pikirannya dan ingin memutar kembali perubahan. Ketika undo tablespace kehabisan ruang untuk data undo, pengguna menerima pesan kesalahan seperti berikut:
ORA-01650: unable to extend rollback segment
Monitoring secara proaktif mendeteksi masalah ruang dalam tablespace undo sebelum mereka mempengaruhi pengguna. Masalah lain adalah administrator perlu mengakses pembatalan informasi yang telah ditimpa. Hal ini mungkin terjadi dalam long-running atau flashback query.
Ketika query membutuhkan "snapshot" dari data dari beberapa waktu di masa lalu, dan merekonstruksi snapshot yang memerlukan membatalkan data yang tidak ada lagi, permintaan mengembalikan error berikut:
ORA-01555: snapshot too old
Hal ini dapat terjadi karena Oracle Database menyajikan pengguna dengan tampilan yang konsisten dari data seperti yang ada pada saat permintaan mulai berjalan. Jika ada perubahan uncommitted ke tabel yang bertanya, database Oracle membaca data undo untuk mendapatkan versi commit data. Ini terbaca secara konsisten. Jika query berjalan begitu lama bahwa sementara itu mereka modifikasi memang berkomitmen, dan kemudian data yang undo mereka dilepaskan
dan ditimpa, maka permintaan berjalan lama tidak lagi dapat melihat tampilan yang konsisten dari data pada ketika pertama kali mulai menjalankan . Untuk alasan ini, membatalkan retensi harus dikonfigurasi untuk mengakomodasi terpanjang query.
9.7. Administering Undo
Disarankan agar menggunakan manajemen pembatalan secara otomatis (automatic undo management), dikonfigurasi dengan menetapkan parameter UNDO_MANAGEMENT yang diinisialisasi ke AUTO. Manajemen membatalkan pengguna didukung untuk kompatibilitas dengan Oracle8i dan versi sebelumnya, tetapi membutuhkan interaksi DBA lebih.
Dengan manajemen pembatalan otomatis, DBA mengelola pembatalan di tingkat tablespace, mengendalikan, dengan UNDO_TABLESPACE parameter inisialisasi, yang membatalkan tablespace yang digunakan. Setelah memilih tablespace undo, administrator perlu khawatir hanya tentang menyediakan ruang yang cukup dan mengkonfigurasi interval retensi undo. Dengan manajemen manual, DBA juga harus mempertimbangkan:
Segmen ukuran, termasuk luasan maksimum dan batas ukuran
Mengidentifikasi dan menghilangkan block transaction
Membuat segmen rollback cukup untuk menangani transaksi (Dalam mode manual, membatalkan segmen yang dikenal sebagai segmen rollback.)
Memilih tablespace untuk mengandung segmen rollback (Undo tablespace digunakan hanya dengan manajemen membatalkan otomatis.)
9.8. Configuring Undo Retention
UNDO_RETENTION menspesifikasikan (dalam detik) nilai ambang rendah undo penyimpanan. Untuk AUTOEXTEND yang membatalkan tablespace, sistem mempertahankan membatalkan setidaknya waktu yang ditentukan dalam parameter ini, dan secara otomatis lagu periode retensi undo untuk memenuhi persyaratan undo dari query. Untuk ukuran tetap membatalkan tablespace, sistem secara otomatis lagu untuk memungkinkan periode retensi undo maksimum atas dasar ukuran undo tablespace dan sejarah penggunaan; mengabaikan
UNDO_RETENTION kecuali jaminan retensi diaktifkan. Jadi untuk manajemen membatalkan otomatis, untuk tiga kasus yang terdaftar, pengaturan UNDO_RETENTION digunakan. Dalam kasus lain dari tiga ini, parameter ini diabaikan.
Undo informasi dibagi menjadi tiga kategori:
Uncommitted undo information: Mendukung transaksi yang sedang berjalan, dan itu diperlukan jika pengguna ingin rollback atau jika transaksi gagal. Informasi membatalkan uncommitted tidak pernah ditimpainformasi.
Committed undo information : tidak lagi diperlukan untuk mendukung transaksi berjalan, tetapi masih dibutuhkan untuk memenuhi interval retensi undo. Hal ini juga dikenal sebagai informasi "belum berakhir" membatalkan. Informasi berkomitmen membatalkan dipertahankan jika memungkinkan tanpa menyebabkan transaksi aktif untuk gagal karena kurangnya ruanginformasi.
Expired undo information : tidak lagi diperlukan untuk mendukung transaksi berjalan.
Expired membatalkan informasi ditimpa bila ruang diperlukan olehaktif transaksi.
9.9. Guaranteeing Undo Retention
Gambar 9.2. Guaranteeing Undo Retention
Standarnya membatalkan perilaku adalah untuk menimpa transaksi berkomitmen bahwa belum kedaluwarsa bukan untuk memungkinkan transaksi aktif gagal karena kurangnya ruang undo.
Perilaku ini dapat diubah dengan menjamin retensi. Dengan retensi terjamin, membatalkan
pengaturan retensi ditegakkan bahkan jika mereka menyebabkan transaksi gagal. RETENTION GUARANTEE adalah atribut tablespace daripada parameter inisialisasi. Atribut ini dapat diubah hanya dengan pernyataan baris perintah SQL. Sintaks untuk mengubah tablespace undo untuk menjamin retensi adalah:
Untuk mengembalikan undo tablespace dijamin pengaturan normal, gunakan perintah berikut:
Jaminan retensi hanya berlaku untuk membatalkan tablespace. Upaya untuk mengaturnya pada non-membatalkan hasil tablespace dalam kesalahan berikut:
9.10. Sizing the Undo Tablespace
Gambar 9.3. Sizing the Undo Tablespace
Tablespace Undo harus berukuran sehingga mereka dapat berisi informasi asli untuk semua transaksi. klik link Undo Management pada halaman Administrasi Enterprise Manager untuk melihat gambaran dari sistem undo, termasuk pengaturan saat ini, membatalkan konsumsi per menit, dan panjang query terpanjang diamati selama jangka waktu tertentu.
File data milik sebuah tablespace undo dapat secara otomatis memperpanjang ketika mereka kehabisan ruang bebas. Oracle Corporation merekomendasikan bahwa file data yang berkaitan dengan membatalkan tablespace, tidak seperti tablespace lain, tidak harus memiliki ekstensi otomatis diaktifkan. Ketika pertama kali menentukan pembatalan kebutuhan ruang, Anda mungkin ingin mengaktifkan perpanjangan otomatis file data, tapi setelah Anda benar berukuran tablespace, Anda harus menonaktifkannya. Menonaktifkan perpanjangan otomatis di file data undo tablespace ini mencegah satu pengguna dari secara tidak sengaja mengkonsumsi sejumlah besar ruang disk dengan mengabaikan untuk melakukan transaksi.
9.11. Using the Undo Advisor
Gambar 9.4. Using the Undo Advisor
Undo Advisor diakses melalui halaman properti Undo Management. Ini memberikan perkiraan ukuran undo tablespace diperlukan untuk memenuhi retensi undo diberikan. Masukkan periode retensi yang diinginkan, dan wilayah analisis penasihat menampilkan ukuran tablespace yang diperlukan untuk mendukung masa retensi. Anda juga dapat mengklik titik pada grafik untuk melihat ukuran tablespace yang diperlukan untuk mendukung jangka waktu yang dipilih. Setelah Anda telah memilih periode retensi undo, klik OK untuk menerapkan periode retensi baru.
