Oracle Veritabanı Seçenekleri ile Veri Ambarına Aktarımı İyileştirme

Bu Linki Görmeniz İçin SupersatForuma Uye Olmanız Gerekmektedir.
Merhaba,Bu makale Turkcell Blog’daki ilk yazım. Öncelikle tüm ekibi ve okuyucuları selamlayarak kendimi kısaca tanıtmak istiyorum. Ben Bu Linki Görmeniz İçin SupersatForuma Uye Olmanız Gerekmektedir. . Kurumsal olarak on seneyi aşkın bir süredir veritabanı uygulamaları ile çalışıyorum. Oracle veritabanı üzerinde hem veri tabanı yöneticisi, hem de uygulama geliştirici olarak önemli tecrübelerim oldu. Şu anda kariyerime Turkcell Teknoloji A.Ş – Gelir Odaklı İş Zekası takımında devam ediyorum.
İş zekası ekipleri olarak birçok kaynak sistemden büyük miktarda verinin raporlama ortamına, raporlama ihtiyaçları paralelinde gerekli dönüştürme işlemlerini gerçekleştirerek performanslı aktarımının yapılması en önemli ihtiyacımızdır. Bu yazımda Oracle veritabanında DIRECT PATH INSERT kavramı, NOLOGGING seçeneği ve indeks kullanımının yazma performansına maliyetleri üzerine örnekler ile tecrübelerimi paylaşmaya çalışacağım.
İşlemlerin cevap süresini azaltmak için talep edilen kısıtlı kaynakların(işlemci, girdi/çıktı, bellek, ağ, kilit gibi) tüketimini düşürmek gerekir. DIRECT PATH INSERT seçeneği bazı özel operasyonlar için kullanıldığında, veritabanı kesinti yaşadıktan sonra yapılan değişikliklerin otomatik tekrarlanabilir olması için gerekli bilgilerin tutulduğu REDO dosyalarına yapılacak girdi/çıktı miktarını önemli miktarda düşürür. Bu yöntemde veriler SGA paylaşımlı bellek havuzunu aradan çıkararak direkt veri dosyalarına yazılır.
Oracle veritabanınız ilk kurulduğunda NOARCHIVELOG biçiminde iken REDO üretimi en düşük seviyededir ve REDO tarihçesi tutulmaz, dolayısı ile yedekten zaman içinde bir noktaya geri dönmek mümkün değildir. Bu nedenle erişebilirliği çok kritik ortamların ARCHIVELOG biçiminde çalışması beklenir, arşivleme seçeneği açık bir Oracle veritabanında NOLOGGING işaretlenmiş bir tablo veya indeks üzerinde yapılan özel bazı işlemler yine de REDO dosyalarına kayıt edilmeyi engelleyebilir. Daha az REDO üreterek kaynak tüketimini düşürecek ve zaman kazandıracaktır. Ancak bu kazancın alternatif maliyeti, bu özel operasyonlarda kesinti yaşandığında, operasyonun sıfırdan tekrarlanmasıdır. Çünkü veritabanı otomatik olarak bu bilgileri size REDO dosyalarından okuyarak geri getiremeyecektir.
Bu seçeneği kullanırken dikkat edilmesi gereken noktaları kısaca belirtelim:

• DIRECT PATH INSERT seçeneği için Oracle Enterprise Edition lisansına sahip olmalısınız,
• Seçenek seri çalışırken INSERT komutundan hemen sonra APPEND yönlendirmesiyle, ya da paralel çalışıldığında herhangi bir ek belirtece gerek duymadan kullanılabilinir,
• DIRECT PATH INSERT sadece kümeli yükleme yapılan INSERT seçeneği ile birlikte manalıdır, tek bir satır yükleme için yazılan INSERT cümlesinde APPEND yönlendirmesi kullanılsa bile dikkate alınmaz,
• Bir Bu Linki Görmeniz İçin SupersatForuma Uye Olmanız Gerekmektedir. üzerinde aynı anda sadece bir oturum bu seçeneği kullanabilir ve bu seçenek kullanımı sonlana dek kilit düzeyi bu Bu Linki Görmeniz İçin SupersatForuma Uye Olmanız Gerekmektedir. üzerinde sadece eş zamanlı okumaya izin verir,
• APPEND yönlendirmesi HIGH WATER MARK altında kalan boş alanların kullanmasını engeller, veri küme olarak HWM üzerine eklenir, COMMIT ile birlikte HWM güncellenir ve veri diğer oturumlardan görünür olur,
• Dizinler tablolara göre REDO üretiminden çok daha fazla etkilenir, dolayısı ile NOLOGGING seçeneği devrede olsa bile indekslerin operasyon öncesi düşürülerek işlem bittiğinde tekrar inşa edilmeleri tercih edilir,
• Veritabanı veya tablo alanı düzeyinde FORCE LOGGING seçeneği kullanılırsa Bu Linki Görmeniz İçin SupersatForuma Uye Olmanız Gerekmektedir. düzeyindeki NOLOGGING seçeneği ezilmiş olur.
• Eğer Bu Linki Görmeniz İçin SupersatForuma Uye Olmanız Gerekmektedir. COMPRESS özelliği ile yaratıldı ise DIRECT PATH INSERT seçeneği kümeli veri yüklemesinin sıkıştırılarak yapılmasını sağlar,
• DIRECT PATH INSERT seçeneği kullanıldığında daha fazla disk alanı kullanılır,
• DIRECT PATH INSERT seçeneği kullanıldığında eğer ilgili tablonun başka tablolar ile ilişkisel tutarlılık kısıtları var ise bunlar kontrol edilmez.

–
– hangi işletim sistemi ve veritabanı sürümünde denemeler yapıldı, LOGGING düzeyi veritabanında neydi
–
SQL> set linesize 2500
SQL> select * from v$version ;
BANNER
——————————————————————————–
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 – 64bit Production
PL/SQL Release 11.1.0.7.0 – Production
CORE 11.1.0.7.0 Production
TNS for HPUX: Version 11.1.0.7.0 – Production
NLSRTL Version 11.1.0.7.0 – Production
SQL> SELECT platform_name,
2 log_mode,
3 force_logging
4 FROM v$database;
PLATFORM_NAME LOG_MODE FOR
———————– ———— —
HP-UX IA (64-bit) ARCHIVELOG NO
SQL> SELECT supplemental_log_data_min,
2 supplemental_log_data_pk,
3 supplemental_log_data_ui
4 FROM v$database;
SUPPLEME SUP SUP
——– — —
NO NO NO
–
– geçici bir tablo alanı ve içi boş geçici bir tablo yaratalım
–
SQL> create tablespace tbs_direct_path_deneme logging ;
Tablespace created.
SQL> create table tab_nologging_test tablespace tbs_direct_path_deneme as select * from dba_source where 1 = 2 ;
Table created.
–
– ilk deneme öncesi bellek etkisinden kaçınmak için bir kerelik adımları çalıştıralım ve tabloyu boşaltalım
–
SQL> insert into tab_nologging_test select * from dba_source ;
SQL> commit;
–
– REDO etkisini ölçebilmek için iki SQL*Plus seçeneğini aktive edelim
–
SQL> set autotrace traceonly statistics
–
– ilk deneme: veritabanı ARCHIVELOG, tablo LOGGING, APPEND yönlendirmesi kullanılmadı
–
SQL> truncate table tab_nologging_test ;
SQL> insert into tab_nologging_test select * from dba_source ;
SQL> commit;
Statistics
———————————————————-
..
145099352 redo size
..
982219 rows processed
–
– ikinci deneme: veritabanı ARCHIVELOG, tablo LOGGING, APPEND yönlendirmesi ile
–
SQL> truncate table tab_nologging_test ;
SQL> insert /*+ append */ into tab_nologging_test select * from dba_source ;
SQL> commit;
Statistics
———————————————————-
..
163117624 redo size
..
982219 rows processed
Sonuç: Tek başına APPEND yönlendirmesi REDO miktarının düşmesine neden olmadı, Bu Linki Görmeniz İçin SupersatForuma Uye Olmanız Gerekmektedir. NOLOGGING çekilmesi gerek.
–
– üçüncü deneme: veritabanı ARCHIVELOG, tablo NOLOGGING, APPEND yönlendirmesi kullanılmadan
–
SQL> truncate table tab_nologging_test ;
SQL> alter table tab_nologging_test nologging ;
SQL> insert into tab_nologging_test select * from dba_source ;
SQL> commit;
Statistics
———————————————————-
..
145357488 redo size
..
982219 rows processed
Sonuç: Tek başına Bu Linki Görmeniz İçin SupersatForuma Uye Olmanız Gerekmektedir. NOLOGGING çekilmesi REDO miktarının düşmesine neden olmadı, APPEND yönlendirmesi de gerek.
–
– dördüncü deneme: veritabanı ARCHIVELOG, tablo NOLOGGING, APPEND yönlendirmesi ile
–
SQL> truncate table tab_nologging_test ;
SQL> insert /*+ append */ into tab_nologging_test select * from dba_source ;
SQL> commit;
Statistics
———————————————————-
..
308496 redo size
..
982219 rows processed
Yorum: İki seçenek bir arada kullanıldığında REDO miktarı oldukça düştü.
–
– beşinci deneme: veritabanı ARCHIVELOG, tablo NOLOGGING, APPEND yönlendirmesi ile, LOGGING bir dizin ekleyelim
–
SQL> truncate table tab_nologging_test ;
SQL> create index nui_tab_nologging_test on tab_nologging_test(owner,name,line) tablespace tbs_direct_path_deneme logging ;
SQL> insert /*+ append */ into tab_nologging_test select * from dba_source ;
SQL> commit;
Statistics
———————————————————-
..
153720712 redo size
..
982219 rows processed
Sonuç: REDO miktarı indeks ile birlikte tekrar arttı.
–
– altıncı deneme: veritabanı ARCHIVELOG, tablo NOLOGGING, APPEND yönlendirmesi ile, dizin NOLOGGING
–
SQL> truncate table tab_nologging_test ;
SQL> alter index nui_tab_nologging_test nologging ;
SQL> insert /*+ append */ into tab_nologging_test select * from dba_source ;
SQL> commit;
Statistics
———————————————————-
..
153379200 redo size
..
982219 rows processed
Sonuç: Dizin NOLOGGING yapılsa da REDO miktarında beklenilen azalma olmadı.
–
– yedinci deneme: veritabanı ARCHIVELOG, tablo NOLOGGING, APPEND yönlendirmesi ile, dizin UNUSABLE
–
SQL> truncate table tab_nologging_test ;
SQL> alter index nui_tab_nologging_test unusable ;
SQL> insert /*+ append */ into tab_nologging_test select * from dba_source ;
SQL> commit;
Statistics
———————————————————-
..
309168 redo size
..
982219 rows processed
Sonuç: REDO miktarını düşürmek için dizinin UNUSABLE tutulması gerekti.
Notlar/Uyarılar –

• Oracle 10gR2 sürümü öncesinde UNUSABLE durumda dizinleri olan bir tabloya erişmek için SKIP_UNUSABLE_INDEXES seçeneğini aktive etmek gerek:

alter session set skip_unusable_indexes=true;

• Yükleme işlemi sonrasında dizinin kullanılabilir olması için tekrar inşa edilmelidir:

alter index nui_tab_nologging_test rebuild nologging ;

• Denemelerin tamamında seri çalışılmıştır, paralel işlemlerin varsayılan davranışı DIRECT PATH operasyondur

• V$DATAFILE.UNRECOVERABLE_CHANGE# ve UNRECOVERABLE_TIME kolonları ile NOLOGGING operasyon görmüş veri dosyaları tespit edilip yedekleme işlemi planlanabilir

Kullanılan Kaynaklar
Oracle® Database Data Warehousing Guide 11g Release 1 (11.1)
Bu Linki Görmeniz İçin SupersatForuma Uye Olmanız Gerekmektedir.
Effective Oracle by Design, Thomas Kyte
Bu Linki Görmeniz İçin SupersatForuma Uye Olmanız Gerekmektedir.
Oracle® Database Administrator’s Guide 11g Release 1 (11.1)
Bu Linki Görmeniz İçin SupersatForuma Uye Olmanız Gerekmektedir.
VN:F [1.5.7_846]