17 Ocak 2017 Salı
Trigger’lar Nasıl Çalışır?
Trigger’ı tetikleyen bir olayla karşılaşıldığında işlem ile trigger ikisi birlikte bir transaction bloğu olarak ele alınır.
Trigger’lar çalıştığı zaman INSERTED ve DELETED tablolarını kullanırlar. Bu tabloların her ikisi de ana tabloyla yani trigger’ın tetiklediği tabloyla eşdeğer alanlara sahiptir.
Bu tablolar mantıksal tablo şeklinde RAM’de bulunurlar. Gerçek tabloya bir kayıt eklendiği zaman trigger çalışırsa bu kayıt aynı zamanda Inserted tablosuna da eklenir. İstenildiğinde bu tablodaki kayıtlara erişilebilmektedir.
Yani trigger, kendisini çağıran işlemi onaylamak anlamında hiçbir işlem yapmayabilir yada ROLLBACK ile geçersiz kılınabilmektedir.
Tablodan bir kayıt silindiğinde, silinen kayıt DELETED tablosunda saklanır.
UPDATE işlemi ise, DELETE ve hemen ardından yapılmış olan bir INSERT işlemi olarak ele alınır.
Bir kayıt UPDATE edildiğinde orijinal kayıt DELETED tablosuna eklenir.
Değişen kayıtta INSERTED tablosuna eklenir.
Klasik Trigger’ların Özellikleri
Bir trigger, birden fazla olayı gerçekleştirebilmektedir.
Örneğin bir tabloya kayıt eklendiğinde devreye giren bir trigger bu kayıtları başka bir yere de ekledikten sonra başka bir tablo üzerinde de güncellemeler yapabilmektedir.
Trigger, geçici tablo yada sistem tablosu oluşturamaz ama bu türden tablolara erişebilmektedir.
Diğer yandan bir trigger, birden fazla olay tarafından tetiklenebilmektedir. Yani hem ekleme hem de güncelleme işlemi için veya her ikisi için devreye girmek üzere programlanabilmektedir.
Temel olarak iki farklı trigger çeşidi vardır.
AFTER Trigger
AFTER trigger’ı sadece tablolar üzerinde tanımlanabilmektedir.
INSTEAD OF Trigger
INSTEAD OF trigger’ı hem tablolar hem de view’lar üstünde tanımlanmaktadır.
İkisi arasındaki en önemli fark, AFTER trigger’ını devreye sokan olay olmuş kabul edilerek akışı trigger’a bırakırken, INSTEAD OF trigger’ı istenilen işlemi gerçekleştirmez. Sadece sözde tablolara kaydetmekle yetinir. Ayrıca basamaklı güncelleme ve silme işlemine destek vermez.
Bu iki trigger’ ın karşılaştırılması tabloda verilmektedir.
Örneğin bir tabloya kayıt eklendiğinde devreye giren bir trigger bu kayıtları başka bir yere de ekledikten sonra başka bir tablo üzerinde de güncellemeler yapabilmektedir.
Trigger, geçici tablo yada sistem tablosu oluşturamaz ama bu türden tablolara erişebilmektedir.
Diğer yandan bir trigger, birden fazla olay tarafından tetiklenebilmektedir. Yani hem ekleme hem de güncelleme işlemi için veya her ikisi için devreye girmek üzere programlanabilmektedir.
Temel olarak iki farklı trigger çeşidi vardır.
AFTER Trigger
AFTER trigger’ı sadece tablolar üzerinde tanımlanabilmektedir.
INSTEAD OF Trigger
INSTEAD OF trigger’ı hem tablolar hem de view’lar üstünde tanımlanmaktadır.
İkisi arasındaki en önemli fark, AFTER trigger’ını devreye sokan olay olmuş kabul edilerek akışı trigger’a bırakırken, INSTEAD OF trigger’ı istenilen işlemi gerçekleştirmez. Sadece sözde tablolara kaydetmekle yetinir. Ayrıca basamaklı güncelleme ve silme işlemine destek vermez.
Bu iki trigger’ ın karşılaştırılması tabloda verilmektedir.
Trigger’lar Ne Zaman Kullanılmalıdır?
Trigger’lar aşağıdaki amaçlara yönelik kullanılırlar.
Değişiklikleri takip etmek için: Kritik kayıtlar üzerinde değişiklik yapan kişiler ve değişiklik miktarlarını ya da kayıtlarının takibini tutmak için kullanılırlar.
Birincil anahtar üretmek için: IDENTITY( ) fonksiyonu birincil anahtar olarak sadece sayı üretebilmektedir. Bazı durumlarda birincil anahtarın belli harf ve rakamlardan oluşması gerekebilir. Böyle durumlarda yine trigger’lara başvurulabilmektedir.
Trigger’lar aşağıdaki amaçlara yönelik kullanılırlar.
Karmaşık iş kurallarını gerçeklemek için: Bazen uygulama veritabanının dışında bir veritabanına karşı, yabancı anahtar geçerliliğini denetlemek gerekebilmektedir. Bu durumda sadece veritabanı içindeki işler denetlenebilmektedir. Fakat trigger’ lar ile diğer veritabanları da denetlenebilmektedir.
Mail atmak gibi işleri otomatikleştirmek için: Örneğin herhangi bir sipariş verildiğinde müşteriye bilgilendirme mail göndermek için kullanılabilmektedir.
Bunların dışında;
Standart hata mesajlarının dışında hata mesajı vermek için
Veritabanı erişimlerini takibe almak için
Yeni nesne oluşturma işlemlerini, sunucu veritabanlarının tutarlılıklarını sağlamak için
Nesne değişikliklerini takip etmek ve engellemek için
kullanılabilmektedirler.
Trigger’lar
Trigger yani tetikleyici, ilişkisel veritabanı yönetim sistemlerinde bir tabloda belirli olaylar meydana geldiği zaman yani ekleme, güncelleme, silme işlemlerinden biri gerçekleşmeden önce veya sonra çalışan ve belirli işlemleri kodlandığı şekilde yerine getiren yordamdır.
Tetikler veritabanında yapılan değişikliklerle birlikte otomatik olarak çalışan prosedürel program parçacıklarıdır.
Trigger’lar, veri değişiminin hemen ardından log dosyalar üzerinden otomatik olarak devreye giren özel bir Stored Procedure’dür.
Genellikle karmaşık iş kurallarını gerçekleştirmek için veya basamaklı veri bütünlüğünü programlamak için kullanılırlar.
SQL Server ve Transaction
SQL Transaction’ları da diğer işlemlerden farksız olarak atomik bir yapıya sahiptir.
Herhangi bir SQL sorgusu da aynı yapıda olduğu için ya tüm komut/sorgu başarıyla çalıştırılır ve sonucu alınır ya da veri tabanında hiçbir değişiklik yapılmadan işlem sonuçlandırılır. Dolayısı ile bunları Transaction yapıları içinde kullanmak mümkündür.
SQL Server’ da transaction’ın genel yapısı aşağıdaki gibidir.
BEGIN TRANSACTION
Transaction komutları
COMMIT TRANSACTION / ROLLBACK
Aşağıdaki niteliklere sahip banka hesaplarının tutulduğu bir tablo oluşturalım.
Oluşturduğumuz bu tabloya iki adet kayıt ekleyelim. Dilerseniz daha fazla kayıtta ekleyebilirsiniz.
Oluşturduğumuz bu tablo üzerinde bir Stored Procedure (SP) tanımlayalım.
Bu SP dışarıdan havale yapanın hesap numarasını, havaleyi alacak olan kişinin hesap numarasını ve havale miktarını alacak ve Transaction başladıktan sonra havale işlemini gerçekleştirecektir.
Eğer havalede bir sorun çıkmaz ise işlem geçerli olacaktır. Bir sorun oluşur ise, her aşamada «ROLLBACK» komutu ile bütün işlemler geri alacaktır.
Oluşturduğumuz «havale» procedure’ü aşağıdaki gibidir.
SP’yi bir havale işlemi gerçekleştirerek test ederek sonuçlarına baktığımızda havale işleminin sorunsuz gerçekleştiği görülmektedir.
Bu transaction bloğu çalıştırıldığında hesap numaralarının herhangi birinin yanlış girilmesi durumunda dikkat edilirse herhangi bir uyarının verilmediği görülür.
Bu gibi durumlarda hata yakalama komutu olan "TRY-CATCH" yapısına ihtiyaç vardır. Bu yapı oluşacak hataları kullanıcının görmesini ve gerekli düzeltmeleri yapmasını sağlamaktadır.
TRY-CATCH bloğunu ekleyerek SP’yi yeniden düzenleyelim.
Yeni SP aşağıdaki gibi olacaktır.
Bu gibi durumlarda hata yakalama komutu olan "TRY-CATCH" yapısına ihtiyaç vardır. Bu yapı oluşacak hataları kullanıcının görmesini ve gerekli düzeltmeleri yapmasını sağlamaktadır.
TRY-CATCH bloğunu ekleyerek SP’yi yeniden düzenleyelim.
Yeni SP aşağıdaki gibi olacaktır.
Eğer herhangi bir hata meydana gelirse bir hata kodu üretilerek kullanıcı bilgilendirilecektir.
Bu hata elektrik kesintisi, donanımsal yada programlama ile ilgili bir hata olabilmektedir.
Bu hata elektrik kesintisi, donanımsal yada programlama ile ilgili bir hata olabilmektedir.
Transaction Bloğunun Çalışması
SQL Server üzerinde herhangi bir veride değişiklik yapıldığı zaman, ilgili sayfalar daha önce diskten hafızaya çağrılmamış ise öncelikle tampon belleğe alınır.
Daha sonra üstünde değişiklikler yapılır.
Yapılan değişiklikler diske hemen yansıtılmaz. Bu şekilde içeriği denenmiş ama henüz diske kaydedilmemiş sayfalara kirli sayfa adı verilmektedir.
Sayfada meydana gelen her değişiklik *.ldb uzantılı transaction log dosyalarına kaydedilir. Kirli sayfaların diske kaydedilmesi işlemine «arındırma» adı verilmektedir.
Arındırma işlemi gerçekleşmeden önce kirli sayfalardaki tüm değişiklikler log dosyasına yansıdığı için işlem gerçekleşirken ortaya çıkacak olan istenmeyen durumlardan sonra eski haline dönmek mümkün olmaktadır.
Eğer herhangi bir sorun ortaya çıkmaz ise arındırma işlemi düzgün olarak gerçekleşir ve veriler diske yazılır.
Transaction’lar içerdikleri tüm işlemleri başarıyla gerçekleştiren ya da veri tabanı üzerinde hiçbir değişiklik yapmayan atomik yapılardır.
Olası bir durumda kurtarma işlemlerinin gerçekleştirilebilmesi için her işlemin ne zaman başladığı, ne zaman bittiği ve başarılı bir şekilde tamamlanıp tamamlanmadığı bilgisinin sistemde tutulması gereklidir. Bu sebeple kurtarma yöneticisi (recovery manager) şu bilgileri saklamaktadır
BEGIN TRANSACTION: Transaction’ ın başlangıcını işaretler.
READ/WRITE: Transaction’ın içeriğinde gerçekleştirilen işlemlerin bilgisini içerir.
END TRANSACTION: Transaction’ın bitişini işaretler.
COMMIT: Transaction’ın başarıyla sonuçlandığı bilgisini içerir.
ROLLBACK/ABORT: Transaction’ın başarısız olduğu bilgisini içerir.
Bir transaction’ın çalışması aşağıdaki gibidir.
Transaction Kuralları
Bir veritabanı veriler üzerinde değişiklik yaparken dört kuralı sağlamak zorundadır. Sağlanması gereken bu dört kural aşağıdaki gibidir.
Bölünmezlik (Atomicity)
Bir transaction bloğu asla yarım kalamaz. Ya hepsi gerçekleşmiş sayılır yada hiçbir işlem gerçekleşmemiş kabul edilerek başa dönülür. Başka bir ifade ile transaction, daha küçük parçalara ayrılamayan işlem birimi olarak ele alınır.
Tutarlılık (Consistency)
Transaction veritabanının yapısını bozmadan işlem bloğunu terk etmelidir. Yani ara işlemler yapılırken işlem bloğunun etkisini veritabanına yansıtarak transaction’ı terk edemez.
Örneğin A kullanıcısının hesabından parayı azaltıp B kullanıcısına eklemeden işlemi sonlandırmaz. Veritabanının mutlaka tutarlı olması gerekmektedir.
İzolasyon (Isolation)
Farklı transaction’lar birbirinden farklı olarak ele alınmalıdırlar.
Her transaction için veritabanının yapısı ayrı ayrı korunmalıdır.
İlk transaction tarafından yapılan değişiklikler ikinci transaction’da görülmemelidir. Ancak işlem bittiğinde bir bütün olarak görülmelidirler.
Dayanıklılık (Durability)
Tamamlanmış bir transaction’nın hatalara karşı esnek olması gerekmektedir.
Elektrik kesilmesi, herhangi bir donanım arızası gibi nedenlerden dolayı yapılacak işlemlerin gerçekleşmesine engel olması gerekmektedir.
Bunun için gerçekleşmiş ve başarılı olmuş transaction’nın değişikliklerinin diske kalıcı olarak yansıtılması gerekmektedir.
Transaction - Temel Bilgiler
Önce transaction bloğu çalıştırılır. Transaction bloğunun çalıştırılması ile bütün işlemlerin bir bütünlük arz ettiği ve her an tamamının geçersiz sayılabileceği tanımlanmış olur.
Bütün işlemler transaction log’ ların da tutulur ve herhangi bir problemde bu log’ lar dikkate alınır.
Transaction bloğu SQL Server tarafından otomatik olarak veya kullanıcı tarafından «BEGIN TRANSACTION» komutu ile başlatılabilir.
BEGIN TRANSACTION yerine BEGIN TRAN komutu da kullanılabilmektedir.
Transaction bloğunda yapılan her işlemin başarılı olup olmadığı, her biten işlem sonunda kontrol edilir. Eğer başarılı olunmadıysa yapılan işlem geri alınır.
Geri alma işlemi «ROLLBACK» komutu ile gerçekleştirilir.
Başarılı olunduysa bir sonraki işleme geçilir.
Bu işlemler kullanıcı tarafından ve SQL Server tarafından gerçekleştirilebilir.
Tüm işlemler tamamlandığında «COMMIT» işlemi ile tüm veriler yeni hali ile veritabanına kaydedilir.
Eğer işlem başarısız olursa «ROLLBACK» komutu ile bütün işlemler tekrar en başa alınır ve yapılacak olan işlem veritabanına yansıtılmaz.
Örnek: Transaction
Bir banka sistemini ele alarak bir havale işlemini gerçekleştirelim.
A kullanıcısı B kullanıcısına havale yaptığında;
A kullanıcısının hesabından havale edilecek olan miktar düşülür. Ardından B kullanıcısının hesabına bu havale miktarı eklenir ve havale işlemi gerçekleşmiş olur.
Ancak her zaman bu şartlar sağlanamamış olabilmektedir. Örneğin, A kullanıcısı para havale ettiğinde elektrikler kesilebilir yada programda bir hata meydana gelebilir. Bu gibi bir durumda neler olabilir?
Transaction Nedir?
Transaction veri tabanındaki verilere erişen ve çoğunlukla bu veriler üzerinde değişiklikler yapan bir program kesimidir.
Birçok kullanıcının eşzamanlı olarak işlem yaptığı büyük veri tabanı sistemlerinde daha çok kullanılmaktadır.
Bir işlem büyük bir bütünün parçası olabilir. Bu işlemlerden herhangi bir tanesinin gerçekleşmemesi bütün işlemleri anlamsız kılmaktadır.
Böyle bir durumda bütün işlemler tek bir işlem gibi ele alınmalıdır. Bu parçalanamaz işlemlerin oluşturduğu yeni tek işleme «transaction» adı verilmektedir.
Transaction yönetim sistemleri (transaction processing systems) banka, otel rezervasyon, süpermarket gibi birçok kullanıcının eşzamanlı olarak işlem yaptığı büyük veri tabanı sistemleri için geçerlidir. Bu sistemlerin yüksek performansla ve doğrulukla çalışması son derece önemlidir.
Bazı durumlarda yapılan bir işlem büyük bir bütünün parçasıdır. Bu işlemlerden herhangi bir tanesinin gerçekleşmemesi bütün işlemleri anlamsız kılmaktadır. Bu durumda bürün işlemler tek bir işlem gibi ele alınmalıdır. Bu parçalanamaz işlemlerin oluşturduğu yeni tek işleme transaction adı verilmektedir. Bir diğer değişle transaction, daha küçük parçacıklara ayrılamayan işlem bloklarıdır.
Kaydol:
Kayıtlar (Atom)