LOGGING/NOLOGGING membantu mengelola pengaktifan penulisan jalur langsung untuk mengurangi pembuatan REDO dan UNDO. Ini adalah salah satu dari beberapa cara untuk mengontrol keseimbangan antara kemampuan pemulihan dan kinerja.
Informasi Latar Belakang Arsitektur Oracle
ULANG adalah bagaimana Oracle menyediakan daya tahan, "D" di ACID. Ketika transaksi dilakukan, perubahan tidak harus disimpan dengan rapi di file data. Itu membuat segalanya cepat dan memungkinkan proses latar belakang menangani beberapa pekerjaan. REDO adalah deskripsi perubahan. Itu disimpan dengan cepat, di banyak disk, dalam log "bodoh". Perubahan berlangsung cepat dan jika server kehilangan daya satu mikrodetik setelah komit kembali, Oracle dapat menelusuri log REDO untuk memastikan bahwa perubahan tidak hilang.
UNDO membantu Oracle memberikan konsistensi, "C" di ACID. Ini menyimpan deskripsi tentang cara membalikkan perubahan. Informasi ini mungkin diperlukan oleh proses lain yang membaca tabel dan perlu mengetahui nilai apa yang digunakan berada di titik waktu yang lebih lama.
Penulisan jalur langsung lewati REDO, UNDO, cache, dan beberapa fitur lainnya, dan langsung ubah file data. Ini adalah opsi yang cepat tetapi berpotensi berbahaya di banyak lingkungan, itulah sebabnya ada begitu banyak opsi yang membingungkan untuk mengendalikannya. Penulisan jalur langsung hanya berlaku untuk INSERTS, dan hanya dalam skenario yang dijelaskan di bawah.
Jika Anda tidak melakukan apa pun, opsi default adalah yang paling aman, LOGG.
Banyak Cara untuk Mengontrol Penulisan Jalur Langsung
LOGGING/NOLOGGING adalah salah satu dari beberapa opsi untuk mengontrol penulisan jalur langsung. Lihat tabel ini dari AskTom untuk memahami bagaimana semua opsi yang berbeda bekerja bersama:
Table Mode Insert Mode ArchiveLog mode result
----------- ------------- ----------------- ----------
LOGGING APPEND ARCHIVE LOG redo generated
NOLOGGING APPEND ARCHIVE LOG no redo
LOGGING no append ARCHIVE LOG redo generated
NOLOGGING no append ARCHIVE LOG redo generated
LOGGING APPEND noarchive log mode no redo
NOLOGGING APPEND noarchive log mode no redo
LOGGING no append noarchive log mode redo generated
NOLOGGING no append noarchive log mode redo generated
FORCE LOGGING dapat mengesampingkan semua pengaturan tersebut. Mungkin ada beberapa sakelar lain yang tidak saya sadari. Dan tentu saja ada banyak batasan yang mencegah jalur langsung - pemicu, kunci asing, cluster, tabel terorganisir indeks, dll.
Aturannya bahkan lebih ketat untuk indeks. Sebuah indeks akan selalu menghasilkan REDO selama pernyataan DML. Hanya pernyataan DDL, seperti CREATE INDEX ... NOLOGGING atau ALTER INDEX ... REBUILD pada indeks NOLOGGING tidak akan menghasilkan REDO.
Mengapa ada begitu banyak cara? Karena pemulihan sangat penting dan peran yang berbeda mungkin memiliki pandangan yang berbeda tentang masalah tersebut. Dan terkadang keputusan beberapa orang perlu mengesampingkan orang lain.
Pengembang putuskan pada tingkat pernyataan, "Sisipkan Mode". Banyak hal aneh dapat terjadi dengan /*+ APPEND */ petunjuk dan pengembang harus memilih dengan hati-hati kapan menggunakannya.
Arsitek putuskan di tingkat objek, "Mode Tabel". Beberapa tabel, terlepas dari seberapa cepat pengembang ingin menyisipkannya, harus selalu dapat dipulihkan.
Administrator Basis Data putuskan pada mode database atau tablespace, "Arsip log" dan FORCE LOGGING. Mungkin organisasi tidak peduli untuk memulihkan database tertentu, jadi setel ke mode NOARCHIVELOG. Atau mungkin organisasi memiliki aturan ketat bahwa semuanya harus dapat dipulihkan, jadi atur tablespace ke FORCE LOGGING.
