Mustafa Bektaş Tepe

Materialized View diğer viewlerden farklı olarak sadece data dictionary de tutulmuyor bundan farklı olarak fiziksel olarak veride tutan view/objedir. Materialized View ile referans aldığımız sql’in o anki verilerini fiziksel olarak tutarız ve ihtiyacımıza göre view ın verisini değişik opsiyonlarla güncelleyebiliriz.

Tekrar edecek olursak viewler bir sql sorgusunun saklanma şeklidir, Materialized Viewler ise hem sql sorgusu hemde veriden oluşmaktadır. Bu nedenle Materialized View verileri replicate(kopyasini almak) etmektedir. Peki replicate neden gerekebilir ?

Aslında daha çok DW uygulamalrında sıkça rastlarız ama bunun dışında veritabanı transferlerindede kullanılabilir. Örneğin salı günkü verilerden yola çıkarak, çarşamba günü rapor hazırlama işlemleri bu şekilde daha hızlı gerçekleştirilebilir. Salı akşamı sorgular çalıştırılır, Materialized Viewler güncellenir, çarşamba günü sorgular çalıştırıldığında Ana tablo yerine bu Materialized View lerden ilgili bilgiler çekilmiş olur. Bu da bizim kaynakları kullanma performansımızı arttıracak. Fakat bu durumda güncel verilerden yararlanmamış oluyoruz, sadece önceki güne ait verilerden yararlanmış oluyoruz. Tabi istersek bunu önleme yöntemleri de mevcut, Materialized View de.

Yani Materialized Viewler daha çok aşağıdaki konulara çözüm olur.

• Kayıt sayınız artıp, rapor sorgularınız çok geciktiğinde.
• Birden fazla tablodan sorgu almak sizi zorladığında.
• Özet tablolarınızı periyodik olarak doldurmak istediğinizde.
• Anlık olmayan raporlarınızda, yani 1 gün gecikmeli ya da ayda bir verdiğiniz raporlarda veya periyodik güncellenmesi gereken verilerde.

Materialized View oluşturmak için Sintaksis  aşağıdaki gibidir;

- Normal
CREATE MATERIALIZED VIEW view-name
BUILD [IMMEDIATE | DEFERRED]
REFRESH [FAST | COMPLETE | FORCE ]
ON [COMMIT | DEMAND ]
[[ENABLE | DISABLE] QUERY REWRITE]
AS
SELECT ...;

-- Pre-Built
CREATE MATERIALIZED VIEW view-name
ON PREBUILT TABLE
REFRESH [FAST | COMPLETE | FORCE ]
ON [COMMIT | DEMAND ]
[[ENABLE | DISABLE] QUERY REWRITE]
AS
SELECT ...;

(continue reading…)

LOB(Large Object) Veri Tipleri’nin amacı boyutu büyük olan verileri saklamaktır. Örn. doküman(txt, word, excel, xml ), resim, video, ses vb. Bu tarz veriler önceden long, raw , long raw gibi veri tiplerinde tutulurdu günümüzde ise daha çok BLOB, CLOB, NCLOP gibi veri tiplerinde büyük objeler tutulur. long, raw , long raw gibi veri tipleri daha çok eskiye yönelik destek için kullanılmaktadır.
BLOB : Verileri binary olarak saklar. Max 128 TB a kadar veri saklar . Resim , video gibi dosyalar bu veri tipinde saklanabilir .

CLOB : Verileri karakter olarak saklar . Max 128 TB a kadar veri saklar . TXT dosyalarının içerisindeki verileri CLOB veri tipinde saklayabiliriz.
Oracle 11g ile ile birlikte yukarıda saydığımız veri tiplerini saklamak için Oracle Securefile yapısı duyurulmuştur. Securefile ile birlikte lob alanlarda sıkıştırma, yenilenen veriyi engelleme(deduplicate) şifreleme, önbellğe alma(cachinhg), loglama mekanizmasını belirleme gibi özellikler gelmiştir.

• Deduplicate : LOB alanlarda bu özelliği belirledikten sonra her kayıt için hash değerler çıkartılacak örtüşen hash değerler veritabanına 1 defa yazılacaktır. Burada aslında tabloda ne kadar yenileyen verimiz varsa o kadar avantajlıdır. Örnek verecek olursak benim çalıştığım tablolardan birinde 50 GB’lık tabloyu 7 GB’a düşürdü.

ALTER TABLE TEST MOVE LOB (VERI) STORE AS SECUREFILE ( DEDUPLICATE );

veya

CREATE TABLE TEST
(
ID NUMBER,
VERI CLOB
)
TABLESPACE "TEST_SECUREFILE"
LOB ("VERI") STORE AS SECUREFILE
(TABLESPACE "TEST_SECUREFILE" DEDUPLICATE);

• Compress : Secure file burada standart sıkıştırma teknolojilerini kullanıyor ve verileriniz özellikle text tabanlıysa çok büyük avantajlar sağlayabiliyor bu daha çok verininizin tipine bağlı ama özellikle xml ve türevleri için şiddetle tavsiye ederim. Örnek verecek olursam benim ele aldığım bir tabloda 400 GB’dan 50 GB’a düştü tablo. Ve compress teknolojisiyle sadece disk alanından değil daha az i/o yapacağı için performansdan’da ciddi kazanç sağlanılıyor. Çok güzel sonuçlar aldım kesinlikle testler yapıp sonuçlarına göre uygulamaınızı öneririrm.
• Encryption : Verilerinizi wallet ile şifreleyebilirsiniz.
• Caching : Sık kullandığımız veri ise file systemden farklı olarak verilerimizi cache tutabiliriz.
• Logging : lob alanlarda ki verilerimiz büyük olduğu için redo loga gitmeden işlemlerimizin yapılmasını isteyebiliriz.

Securefile ile ilgili hikaye kısmından sonra gerçek hayattan tecrübelerimize gelecek olursak lob alanlarda saklanan veriye bağlı olarak deduplication ve compress özelliği disk alanı ve performans(disk io’dan dolayı) olarak çok etkileyici sonuçlar verebiliyor. Buda aslında pozitif olarak bütün yapıyı etkiliyor rman(yedek alacağı veritabanının boyutu azalıyor), datapump, data guard gibi ;
NOT : Securefile’ı kullanacağınız tabloyu mutlaka ve mutlaka tek tek test ettikten sonra karar verin çünkü tablonun içerdiği veriye bağlı olarak herhangi bir kazancı olmadığı gibi performans olarak kayba neden olabiliyor.
NOT : Aşağıdaki testler insert içindir delete ve select içinde bu paralelde sonuçlar vermektedir.

NOT : db_securefile parametresi veritabanında securefile kullanımını belirler.

• Permitted : Varsayılan değerdir. Varsayılan olarak lob lar basicfile olarak oluşturulur ama isteğe bağlı olarak securefile oluşturulabilir.
• Always : Varsayılan olarak lob alanlar securefile ile oluşturulur.
• Never : Lob alanlarda securefile kullanımını engeller.
• Ignore : Securefile kelimesi yok sayılır.

Yararlı olması Dilegiyle …
Yazar : Mustafa Bektaş Tepe

SQLPLUS araci ile excel çıktısı alabilmek için örnek;

set term off
set echo off
set underline off
set colsep “;”
set linesize 100
set pagesize 0
set sqlprompt ”
set lines 1000 pages 1000
set trimspool on
set feedback off
set heading on
set newpage 0
set headsep off

spool myFile.csv
select * from locations;
spool off;
exit;
/

Performans testleri sırasında, sonuçları etkileyen birçok parametre vardır. Hardware özellikleri, (varsa) network hızı, işletim sistemi vs. Bir bütün olarak bütün bu parametreler önem kazanıyor.
İşte, bunlardan biri de harddisk okuma/yazma(disk I/O) hızıdır. Sonuçları iyi yorumlayabilmek adına, normal şartlarda diskin I/O değerlerini bilmemiz önemlidir.

Depolama satıcıları, ürünleri üzerinde sonsuz miktarda performans verisi sunar, ancak bilgiler, bir Oracle veritabanı tarafından kullanıldığında, depolamanın nasıl performans göstereceğini yansıtmaz. Burada, işletim sistemi seviyesinde ve Oracle tarafından sağlanan bazı yardımcı programlar da dahil olmak üzere depolama sistemlerinizin performansını test etmek için birkaç yoldan bahsedeceğiz.

NOT : Oracle araçları (utilities), Oracle veritabanı tarafından gerçekleştirilen işlem türlerini taklit etmek için benzetilmiş bir yük kullanır. Uygulamalarınızın ürettikleri performans seviyesini başarabileceklerinin garantisi yoktur.

Disk performans testleri, buffer ve gerçek disk hızı olarak ayrılmaktadır. Buffer ön belleğin verdiği tepki süresidir. Gerçek disk hızı ise, diskinizin fiziksel olarak yazma / okuma işlemlerine verdiği tepki süresidir. İşleme başlangıç süresi, işlemi bitirme süresi ve işlemin disk boyutu olarak kriterler bulunmaktadır.

Biz bu yazımızda disk performansını ölçmek için aşağıdaki araçları sırayla kullanacağız.

• dd
• hdparm
• ORION
• CALIBRATE_IO

(continue reading…)

OSWatcher aracı belirli aralıklarla top, iostat,vmstat, netstat gibi komutlar ile üretilen verilerin analiz edilip saklanılıp raporlanması için geliştirilmiş bir araçtır.İçinde barındırdığı OSWg aracı ile analiz edilen verileri grafik olarak sunar.

OSWatcher aracı Oracle tarafından geliştirilmiştir ve metalink üzerinden (support.oracle.com) ücretsiz indirip kullanabilirsiniz. Metalink üzerinden (https://support.oracle.com) “OS Watcher Black Box User Guide [ID 301137.1]” isimli dokümanda bulunan oswbb733.tar isimli dosyayı indirelim.

1.Bu dosyayı WinSCP tarzı bir program ile Linux sunucumuza “oracle” kullanıcısı ile kopyalayalım.

2.tar dosyasını “oracle” kullanıcısı ile açalım.

[oracle@test-rac1 oswatcher]$ tar xvf /home/oracle/oswatcher/oswbb733.tar
oswbb/
oswbb/docs/
oswbb/docs/The_Analyzer/
oswbb/docs/The_Analyzer/OSWatcherAnalyzerOverview.pdf
oswbb/docs/The_Analyzer/oswbbaUserGuide.pdf
oswbb/docs/The_Analyzer/oswbba_README.txt
oswbb/docs/OSWatcher/
oswbb/docs/OSWatcher/oswbb_README.txt
oswbb/docs/OSWatcher/OSWatcherUserGuide.pdf
oswbb/Exampleprivate.net
oswbb/nfssub.sh
oswbb/stopOSWbb.sh
oswbb/call_du.sh
oswbb/iosub.sh
oswbb/OSWatcherFM.sh
oswbb/ifconfigsub.sh
oswbb/ltop.sh
oswbb/mpsub.sh
owbb/call_uptime.sh
oswbb/psmemsub.sh
oswbb/tar_up_partial_archive.sh
oswbb/oswnet.sh
oswbb/vmsub.sh
oswbb/call_sar.sh
oswbb/oswib.sh
oswbb/startOSWbb.sh
oswbb/Example_extras.txt
oswbb/oswsub.sh
oswbb/oswbba.jar
oswbb/OSWatcher.sh
oswbb/tarupfiles.sh
oswbb/xtop.sh
oswbb/src/
oswbb/src/Thumbs.db
oswbb/src/OSW_profile.htm
oswbb/src/tombody.gif
oswbb/src/missing_graphic.gif
oswbb/src/coe_logo.gif
oswbb/src/watch.gif
oswbb/src/oswbba_input.txt
oswbb/oswrds.sh
[oracle@test-rac1 oswatcher]$

NOT : OSWatcher ksh kabuğunda(shell) yazıldığı için sistemimizde ksh olması gerekmektedir. ksh olup olmadıgını anlamak için aşagıdaki komutdan yararlanabiliriz.

[root@test-rac1 ~]# rpm -qa | grep ksh
ksh-20100621-19.el6.x86_64

(continue reading…)

SYS_CONTEXT fonksiyonunu veri tabanına bağlı bulunduğumuz kullanıcı üzerinde set edilmiş sistem değişkenlerini(enviroment) toplamak için kullanabiliriz. Bu sayede kullanıcı üzerine atadığımız ya da otomatik olarak atanan tüm değerlere ulaşabiliriz.
Özellikle yazılım için de log mekanizması veya trigger larda çok fazla kullanıldığı gibi çokda iş görüyor.
Bu fonksiyon ile database üzerinden birçok veriye ulaşabiliriz. Kullanıcı bilgisi, ip bilgisi, tarih formatı, dil bilgisi vb.Örnegin; Veritabanı sid bilgisine ulaşmak için;

select sys_context('userenv','sid') from dual;

veya veritabanı ismine ulaşmak için aşagıdaki sql’den yararlanabiliriz.

select sys_context('userenv','db_name') from dual;

SYS_CONTEXT ile kullanabilecegimizparametrelerden bazıları aşagıda ki gibidir. (continue reading…)