Oracle Redefinition

Redefiniton Oracle 9i ile Oracle dünyasına tanıtılan DBMS_REDEFINITION paketidir. DBMS_REDEFINITON paketi production ortamlarda veritabanında kesinti sürelerini nerdeyse sıfır denilecek sürelerde tablo’nun storage parametrelerini degiştirmek,farklı bir tablespace e taşımak veya yeni kolonlar eklemek,silmek ve degiştirmek için kullanılabilir. Örnekler verecek olursak ;

  • Lob alanlı yapılarda basic file’dan secure file a geçmek
  • Kolon eklemek, çıkarmak veya değiştirmek
  • Tabloyu partitionlı yapıya geçirmek
  • Tabloyu reorganize etmek
  • Ve tablodaki bütün storage parameterelerini değiştirirken kullanabiliriz.

DBMS_REDEFINITION paketi aslında arka planda aşağıda resimde gösterilen işlemi yapıyor.

Oracle Redefinition Example

 

 

 

 

 

 

  1. Öncelikle bu paketle tablonun Online redefinition işlemine uygun olup olmadığına bakıyor. Bu kontrolü yaparken bizden primary key veya rowid değerine göre kontrol yaptırmamızı isteyecek.
  2. Bu adımda tablonun hedeflediğmiz halini oluştururuz. Aslında bu biraz Create table as select’e benziyor.
  3. Üçüncü adımda ise ana tablomuzdaki verileri yeni oluşturduğumuz tabloya aktarır.
  4. Bu adımda ise ana tablo ile yeni tablo arasında veri anlamında çok fark var ise istediğimiz zaman bu verilerin senkronozisyonunu sağlar.
  5. Son adımda ise tabloya kısa bir süreliğine erişimi kapatarak verilerin senkronozisyonunu sağlar ve daha sonrasında tabloların isimleri yer değiştirir. Böylece amacımızada ulaşmış oluyoruz.

Aslında bütün resmin kısaca bir defa daha üstünden geçersek hedeflediğimiz tabloyu oluştururuz. Daha sonra DBMS_REDEFINITION paketini kullanarak ana tablodaki veriler yeni tabloya atılır aslında burda yapılan işlem insert table(a,b,c) select a,b,c from table işlemidir, tabi bununla birlikte yeni tablo materialized view e çevrilir ve aynı anda ana tablo için materialized view log olusturup tablomuza gelen insert,delete ve update işlemlerini kayit altina alınır. Daha sonrasında tablolarımızı her senkron etme işlemimizde ise materialized view log kullanılarak refresh (fast refresh) edilir. En sonda tabloların ismi rename yapılarak isim değişikliği yapılır.

Aşağıda yapacağım örnekte Lob alan bulunan tablomda compress özelliğini kullanacağım ve bunu yaparken redefinition kullanacağım için çok az kesintim olacak.
(devamı..)

Loading


Materialized View

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 ...;

(devamı..)

Loading


Oracle lob veri Securefile

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.

Oracle_SecureFile_Compress_Deduplicate

 

 

 

 

 

 

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

Loading


Overlap(Çakışan/Üst Üste) Olan İndexleri Bulmak için Script

Veritabanında overlap(çakışan) indexleri bulmak için gerekli script.

SELECT miv1.table_owner,
       miv1.table_name,
       miv1.index_name,
       miv2.index_name,
       miv1.index_columns,
       miv2.index_columns
  FROM (  SELECT table_owner, table_name, index_name,
                 listagg (c.column_name, ',') WITHIN GROUP (ORDER BY c.column_position) index_columns
            FROM dba_ind_columns c
WHERE table_owner NOT IN ('SYS', 'SYSTEM', 'SYSMAN', 'XDB', 'OLAPSYS')
        GROUP BY table_owner, table_name, index_name) miv1,
       (  SELECT table_owner, table_name, index_name,
                 listagg (c.column_name, ',') WITHIN GROUP (ORDER BY c.column_position) index_columns
            FROM dba_ind_columns c
WHERE table_owner NOT IN ('SYS', 'SYSTEM', 'SYSMAN', 'XDB', 'OLAPSYS')
        GROUP BY table_owner, table_name, index_name) miv2
 WHERE     miv1.table_owner = miv2.table_owner
       AND miv1.table_name = miv2.table_name
       AND miv1.index_columns LIKE miv2.index_columns || '_%';

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

Loading


İndexi Olmayan Foreign Key leri Çıkartan SQL Scripti

Foreign key ilişkisi olupda index atılmamış sütünlar.

OLTP sistemlerde Foreign Key constraintleri veri bütünlüğünü sağlamak için sıkça kullanmaktayız. Foreign Key kullanımı veri bütünlüğünü sağlayabilmek açısından kullanılaması gereken mekanizmaların başında geliyor ancak foreign key constraint kullanırken yapmamız gereken bazı önemli ayrıntılar mevcut bunu atlamamamız gerekiyor.

Nedir bu önemli ayrıntı dediğimizde, yapmamız gereken şeyin foreign key olarak belirlediğimiz kolonu indexlemek olduğunu görmekteyiz. Indexin önemi ise;

  • K kolonu indekslenmemiş bir tablo için Parent tabloda yapılacak bir değişiklik Child tablonun tamamının locklanmasına neden olur.
  • Eğer F.K yaratırken ON DELETE CASCADE opsiyonu kullandık isek, F.K’yi indexlemediğimiz durumda bir sorunda burada yaşayacağız. Burada yaşayacağımız problem yapacağımız DELETE operasyonunun FULL TABLE SCAN operasyonuna neden olacağıdır. Parent tablodan sileceğimiz her kayıt için, Child tabloya erişim FULL TABLE SCAN ile yapılacak ve delete operasyonumuz oldukça yavaş gerçekleşecektir. Bu durumda yine gün sonunda sistemin eş zamanlılık seviyesini negatif yönde etkileyecektir.
  • Parent ve child tablomuzu sık sık joinliyorsak yine F.K üzerinde bir indeksin olmaması sorgunun yavaş çalışmasına neden olacaktır.

Script 1

SELECT a.owner,
       CASE WHEN b.table_name IS NULL THEN 'unindexed' ELSE 'indexed' END
          AS status,
       a.table_name AS table_name,
       a.constraint_name AS fk_name,
       a.fk_columns AS fk_columns,
       b.index_name AS index_name,
       b.index_columns AS index_columns
  FROM (  SELECT a.owner,
                 a.table_name,
                 a.constraint_name,
                 listagg (a.column_name, ',')
                    WITHIN GROUP (ORDER BY a.position)
                    fk_columns
            FROM dba_cons_columns a, dba_constraints b
           WHERE     a.constraint_name = b.constraint_name
                 AND b.constraint_type = 'R'
                 AND a.owner = b.owner
               --  AND a.owner NOT IN ('SYS', 'SYSTEM', 'SYSMAN')
        GROUP BY a.owner, a.table_name, a.constraint_name) a,
       (  SELECT table_owner,
                 table_name,
                 index_name,
                 listagg (c.column_name, ',')
                    WITHIN GROUP (ORDER BY c.column_position)
                    index_columns
            FROM dba_ind_columns c
           --WHERE table_owner NOT IN ('SYS', 'SYSTEM', 'SYSMAN')
        GROUP BY table_owner, table_name, index_name) b
 WHERE     a.table_name = b.table_name(+)
       AND b.index_columns(+) LIKE a.fk_columns || '%'
       AND a.owner = b.table_owner(+)
       order by 2 desc,1;

Script 2

SELECT    acc.owner
         || '-> '
         || acc.constraint_name
         || '('
         || acc.column_name
         || '['
         || acc.position
         || '])'
            "Owner, Name, Column, Position"
    FROM all_cons_columns acc, all_constraints ac
   WHERE ac.constraint_name = acc.constraint_name AND ac.constraint_type = 'R'
         AND (acc.owner, acc.table_name, acc.column_name, acc.position) IN
                (SELECT acc.owner,
                        acc.table_name,
                        acc.column_name,
                        acc.position
                   FROM all_cons_columns acc, all_constraints ac
                  WHERE ac.constraint_name = acc.constraint_name
                        AND ac.constraint_type = 'R'
                 MINUS
                 SELECT table_owner,
                        table_name,
                        column_name,
                        column_position
                   FROM all_ind_columns)
ORDER BY ACC.owner,
         ACC.constraint_name,
         ACC.column_name,
         ACC.position;

Referanslar
https://emrahmete.wordpress.com/2016/01/10/oracle-foreign-key-indexing/

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

Loading


Tablo’nun İlişkide Olduğu Tablo ve Kolonları Öğrenme (Foreign Key Constraint)

SELECT UC.OWNER child_owner,
       UC.TABLE_NAME child_table,
       UCC.COLUMN_NAME c_column_name,
       UC.R_CONSTRAINT_NAME constaint_name,
       uc.constraint_type     constraint_type,
       UCC.TABLE_NAME parent_table,
       UCC.COLUMN_NAME p_column_name
FROM DBA_CONSTRAINTS  UC,
     DBA_CONS_COLUMNS UCC
WHERE UC.R_CONSTRAINT_NAME = UCC.CONSTRAINT_NAME
      AND UC.CONSTRAINT_TYPE = 'R';

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

Loading

Yorum yap devamı...

  • Sertifikasyon



  • Etiketler

  • Topluluklar

                     
                     
  • Copyright © 1996-2010 Mustafa Bektaş Tepe. All rights reserved.
    Türkçeleştirme Blogizma | AltyapıWordPress