REFERENTIAL INTEGRITY(RI)

DB2 for z/OS açısından RI kullanımı veri kalitesinin, veritabanında güvenli olarak sağlanmasını garanti ediyorsa da, RI her zaman kullanılması desteklenen bir özellik değildir. RI’nin kullanılmasının bazı riskleri vardır.

Availability:
1) Parent (P) Tablo PIT Recovery yapılırsa, Dependent bütün tablolar CHECK Pending’e düşer.
2) Dependent (D) Tablo PIT Recovery yapılırsa tablo CHECK Pending’e düşer.
3) Code Tabloları Parent olarak kabul edilip, sistemdeki bütün tablolardan Foreign Key yaratılırsa ve Code Tablosuna yapılacak bir LOAD REPLACE bütün operasyonel tabloları CHECK PENDING’e düşürür.
4) P ve D, Crash Recovery yapılırsa CHECK Pending oluşmaz.

İlk 3 madde availability riski taşımaktadır. Problem yaşanması durumunda kesinti oluşturur.

Performans:
1) D tablo üzerinde FK için Index tanımlamak gerekir. Bu Indexin cardinality’si çoğunlukla düşük kalır ve Optimizer tarafından performans amaçlı seçilmeyebilir. Sadece P’den yapılan CASCADE DELETE’lerde ve JOIN işlemlerinde Dependent kayıtları bulmak için kullanılır. Dolayısı ile Uygulama SQL’lerin kullanma ihtimalinin az oldugu bir index her FK için tanımlanır. Bu da D tablolarının DELETE/INSERT maaliyetini arttırır.
2) D tabloya bir UOW’de aynı FK için yapılacak birden fazla INSERT olursa, DB2 her bir INSERT’de P tabloya gidip bakar. Eger DB2-RI değil, APP-RI kullanılırsa uygulama mantığı doğru yazıldıgı taktirde P tabloya tek bir lookup ile bu işe gerek kalmaz.
3) Eger Partitioned TS’de FK, DPSI (Data Partitioned Secondary Index) olarak tanımlanırsa, P’den yapılacak DELETE, bütün partition’ları tarar. Application ile yapılırsa WHERE koşulu ile atlanacak bu durum, DB2-RI ile kaçınılmaz olabilir.

DB2 for z/OS Architecture in Nutshell

YTU ve ODTU'de Bilgisayar Muh. Ogrencileri icin hazirladigim sunum
Aşağıdaki linkten indirebilirsiniz.

http://www.slideshare.net/CuneytGoksu/db2-for-zos-architecture-in-nutshell