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]