Anasayfa > SQL-PL/SQL > Ne Zaman Hangisini Kullanmalıyım? LOGGING mi? NOLOGGING mi?

Ne Zaman Hangisini Kullanmalıyım? LOGGING mi? NOLOGGING mi?

Ne Zaman Hangisini Kullanmalıyım? LOGGING mi? NOLOGGING mi?

LOGGING kelimesi tablo, index veya tablespace oluştururken kullandığımız anahtar kelimedir. Objeyi oluştururken LOGGING kullanırsak ilgili obje üzerindeki DML işlemleri redo log dosyasında loglanır. NOLOGGING kullanılırsa log üretimi bazı durumlarda yapılmaz. LOGGING/NOLOGGING üzerine forumlarda bir çok soru sorulmaktadır. Sorulardan bazıları şu şekilde: NOLOGGING avantajı nedir? Ne zaman NOLOGGING kullanmalıyız? Tablespace düzeyinde NOLOGGING kullanıldıysa, bu tablespace içindeki tablolarımız LOGGING olabilir mi?

Tablespace seviyesindeki LOGGING/NOLOGGING kelimesi sadece bu tablespace içinde oluşturulacak objelerin varsayılan LOGGING durumunu tablespace ‘den miras (inherit) alması içindir. Şimdi test yaparak tek tek inceleyelim.

Önce NOLOGGING kullanarak NOLOGGING_TS adında bir tablespace oluşturuyorum.

CREATE TABLESPACE NOLOGGING_TS DATAFILE

‘/data_TALIPDB/nologging_ts.dbf’ SIZE 1024M AUTOEXTEND OFF

NOLOGGING

ONLINE

PERMANENT

EXTENT MANAGEMENT LOCAL UNIFORM SIZE 10M

BLOCKSIZE 8K

SEGMENT SPACE MANAGEMENT AUTO

FLASHBACK ON;

Şimdi oluşturduğumuz NOLOGGING_TS tablespace içinde aşağıdaki gibi bir tablo oluşturalım ve tablo scriptimizde LOGGING/NOLOGGING ifadesini kullanmayalım;

CREATE TABLE talip_deneme (

id NUMBER

)

TABLESPACE nologging_ts;

Aşağıdaki sorgu ile baktığımızda tablomuzun NOLOGGING (LOGGING=NO) olarak oluşturulduğunu görürüz.

SELECT table_name, logging

FROM dba_tables

WHERE tablespace_name = ‘NOLOGGING_TS’

TABLE_NAME LOGGING

—————————— ——-

TALIP_DENEME NO

Şimdi de tablomuzu aşağıdaki gibi LOGGING ifadesini kullanarak, oluşturduğumuz NOLOGGING_TS tablespace içinde oluşturalım.

CREATE TABLE talip_deneme2 (

id NUMBER

)

TABLESPACE nologging_ts

LOGGING;

Yukarıdaki sorgu ile baktığımızda tablomuzun LOGGING (LOGGING=YES) olarak oluşturulduğunu görürüz.

SELECT tablespace_name, logging

FROM dba_tables

WHERE table_name = ‘TALIP_DENEME2’

TABLE_NAME LOGGING

—————————— ——-

TALIP_DENEME NO

TALIP_DENEME2 YES

O halde tablespace seviyesinde LOGGING/NOLOGGING kelimesinin kullanılması, bu tablespace içinde oluşturulacak objelerin varsayılan loglama durumunu tablespace ‘den alması içindir.

NOLOGGING olarak oluşturulan bir tablo sonradan aşağıdaki gibi LOGGING yapılabilir. Veya tam tersi de olabilir.

ALTER TABLE talip_deneme LOGGING;

ALTER TABLE talip_deneme2 NOLOGGING;

Bu durum tablespace içinde geçerlidir. NOLOGGING olarak oluşturulan bir tablespace sonradan aşağıdaki gibi LOGGING yapılabilir. Veya tam tersi de olabilir.

ALTER TABLESPACE nologging_ts LOGGING;

Bu durumda tablespace içinde önceden oluşturulan NOLOGGING objeler, NOLOGGING olarak devam edecektir. Bu tablespace içinde yeni oluşturulacak objelerin varsayılan loglama durumu LOGGING olacaktır. Yazımın başında NOLOGGING kullanılırsa log üretim işlemi bazı durumlarda yapılmaz demiştim. NOLOGGING kullanılırsa bazı durumlarda log üretimi devam edebilir. Peki bu durumlar nelerdir?

Tablo Log Durumu Insert Modu Arşiv Modu Redo Log üretimi
LOGGING APPEND ARCHIVE LOG REDO Üretilir
NOLOGGING APPEND ARCHIVE LOG REDO Üretilmez
LOGGING No APPEND ARCHIVE LOG REDO Üretilir
NOLOGGING No APPEND ARCHIVE LOG REDO Üretilir
LOGGING APPEND NO ARCHIVE LOG REDO Üretilmez
NOLOGGING APPEND NO ARCHIVE LOG REDO Üretilmez
LOGGING No APPEND NO ARCHIVE LOG REDO Üretilir
NOLOGGING No APPEND NO ARCHIVE LOG REDO Üretilir

SQL*Loader veri yükleme yöntemlerinden birisi olan “Direct Path Load” işlemleri NOLOGGING bir tabloda redo log üretmez. Veritabanında “force logging” yapılmışsa, yani loglamaya zorlanmışsa, her zaman (LOGGING veya NOLOGGING) redo log üretilir. Tablo LOGGING modunda olsa bile veritabanı arşiv modu NO ARCHIVE LOG ise, “Direct Path Load” işlemleri redo log üretmez. Veritabanı arşiv modu ARCHIVE LOG ise, tablomuz LOGGING modunda redo log üretir. Yine böyle bir durumda “Direct Path Load” işlemleri redo log üretir. Veritabanı arşiv modu ARCHIVE LOG olsa bile tablomuz NOLOGGING modunda redo log üretmez. Yine böyle bir durumda “Direct Path Load” işlemleri redo log üretmez.

“Direct Path Load” dediğimiz işlem, buffer cache ‘i geçerek direk disk ile işlem yapar.

Bir tabloyu NOLOGGING oluşturmak LOGGING olarak oluşturmaktan daha kısa sürer. Basit bir test yapalım. Önce “dba_tables” görüntüsünün (view) bir kopyasını oluşturmak isteyelim. Önce LOGGING olarak kopya oluşturalım ve işlem süresini görelim;

SQL> set timing on

SQL> create table talip_logging logging as select * from dba_tables;

Table created.

Elapsed: 00:00:01.20

Şimdi de NOLOGGING olarak kopya oluşturalım ve işlem süresini görelim;

SQL> create table talip_nologging nologging as select * from dba_tables;

Table created.

Elapsed: 00:00:00.60

Süreleri inceledğimizde NOLOGGING işlem daha kısa sürdüğünü görüyoruz.

NOLOGGING yapılacak objeler genelde verisi hiç değişmeyen, sabit objelerdir. Versi hiç değişmeyen parametrik tablolar, doldur/boşalt tablolar örnek olarak verilebilir. Bu tip objelerin mutlaka tam (full) yedeği alınmalıdır. Aksi takdirde kurtarma (recover) işlemini gerçekleştiremezsiniz. Son olarak aklınıza şöyle bir soru gelebilir. NOLOGGING olarak açılan bir tabloda bir kaydı yanlışlıkla silersek artık rollback yapamam gibi bir durum söz konusu değildir. Tablonuz NOLOGGING olsa bile, yanlışlık sildiğiniz bir kaydı rollback ile geri getirebilirsiniz. Çünkü bu işlem UNDO dediğimiz segmentlerle alakalıdır. LOGGING/NOLOGGING tamamen redo ile alakalı bir durumdur. Bu durum ile alakalı da bir örnek yapalım. Önce NOLOGGING bir tablo oluşturalım;

CREATE TABLE talip_deneme3 (

isim varchar2(10)

)

NOLOGGING;

Tablomuza bir kayıt girelim;

insert into talip_deneme3 values(‘talip’);

commit;

Kaydımızı silelim;

delete from talip_deneme3;

rollback;

select * from talip_deneme3;

rollback yaptığımızda tablomuz NOLOGGING olduğu halde verimizin geri geldiğini gördük. Demek ki rollback işlemi LOGGING/NOLOGGING ile alakalı değildir.

Talip Hakan Öztürk

  1. Mutlu İnan
    11/12/2011, 9:38 pm

    Teşekkürler , güzel bir yazı hazırlamışsınız .
    Küçük bir ekleme yapmak istiyorum müsadenizle .
    Bildiğiniz üzere Oracle ‘ın bir ERP paketi var ismi de E-Business Suite olarak geçiyor.
    Bu uygulama kurulurken Oracle Default olarak karşı tarafta uygulama ile konuşacak olan veritabanını yaratırken ” NOLOGGING ” mode’da yaratıyor.
    Amacı ciddi şekile Redolog yani arşiv üretimini kesmek yada engellemek olarak düşünülebilir.
    Kurulum tamamlandıktan sonra veritabanı seviyesinde FORCE_LOGGING mode YES yapılmasını şiddetle tavsiye ederim .
    Aksi takdir de kurulumuş veritabanın bir Standby veritabanı oluşturulmak istendiğinde ve ileride bir bu Standby ‘dan geri dönüş yapılmak istenildiğinde BLOCK CORRUPTION hataları ile boğuşmak istenilmiyorsa , bu şekilde bir önlem alınması faydalı olacaktır diye düşünüyorum .
    İyi çalışmalar.

    • 13/12/2011, 8:43 pm

      Güzel bir konuya değinmişsiniz. Ben kısaca “Veritabanında “force logging” yapılmışsa, yani loglamaya zorlanmışsa, her zaman (LOGGING veya NOLOGGING) redo log üretilir.” yazmıştım. Standby veritabanınız varsa, dediğiniz gibi sıkıntı çıkabilir. Bundan dolayı standby db kurulumlarında primary veritabanında herzamana force_logging “yes” yapılır.

      Paylaşımınız için çok teşekkür ederim. Elinize sağlık.

  1. No trackbacks yet.

Bir Cevap Yazın

Aşağıya bilgilerinizi girin veya oturum açmak için bir simgeye tıklayın:

WordPress.com Logosu

WordPress.com hesabınızı kullanarak yorum yapıyorsunuz. Log Out / Değiştir )

Twitter resmi

Twitter hesabınızı kullanarak yorum yapıyorsunuz. Log Out / Değiştir )

Facebook fotoğrafı

Facebook hesabınızı kullanarak yorum yapıyorsunuz. Log Out / Değiştir )

Google+ fotoğrafı

Google+ hesabınızı kullanarak yorum yapıyorsunuz. Log Out / Değiştir )

Connecting to %s

%d blogcu bunu beğendi: