Oracle Transactions – 2

Herkese Selam,

Bu yazıda daha önce anlatmaya başlamış olduğumuz Oracle’da Transaction alt yapısını incelemeye devam edeceğiz. Bu yazıyı okumadan önce Oracle Transactions – 1 yazısını okumakta fayda olacaktır.

Oracle Transactions – 1 yazısında Transaction kavramına giriş yapıp özelliklerinden ve nasıl kontrol edilebileceğin bahsetmiştik. Bu yazıda ise  Transaction’ların en önemli karakteristiklerinden biri olan Atomicity kavramını ve seviyesini inceliyiceğiz.

ATOMICTY 

Transaction’ların atomicity karakteristiği, transactionların parçalanmaz bir bütün olduğunu işaret eder. Bunun anlamı bir transaction ya tamamen çalışır ve biter, yada hiç çalışmaz.  Atomicity, Oracle’ın Transaction alt yapısında farklı seviyelerde implemente edilmiştir. Bu seviyeleri kısaca sayacak olursak;

– Statement Level Atomicity

– Procedural Level Atomicty

– Transaction Level Atomicty

– DDL Atomicity

Şimdi bu Atomicity seviyelerini ayrı ayrı incelemeye başlayalım.

Statement Level Atomicity

Örnek üzerinden açıklayacak olursak, Öncek 2 tablo yaratalım. Bu tablolardan birine insert atalım ve üzerinde çalışan bir trigger yazalım, bu tablo modify edilmeden hemen önce trigger çalışsın ve işlemi halledip transaction’a devam etsin.  Daha sonra attığımız kayıda göre sonuçları inceleyelim.

CREATE TABLE atomicity(cola NUMBER CHECK(cola<25));

CREATE TABLE atom(cola NUMBER default 0);

INSERT INTO atom values(0);
CREATE TRIGGER atom_trigger
BEFORE INSERT OR UPDATE
ON atomicity
FOR EACH ROW
BEGIN
IF INSERTING
THEN
UPDATE atom
SET cola = cola + 1;
ELSE
UPDATE atom
SET cola = cola – 1;
END IF;
END;

INSERT INTO atomicity
VALUES (27);

atomicity tablosuna bir insert update veya delete işlemi yapılmadan hemen önce üzerine yazdığımız trigger hemen tetiklenir ve yapılan işlemin tipine göre atom tablosunu update eder. Anacak yukarıdaki örneği sıra ile çalıştırıp atom tablosunun son halini incelediğimizde atom tablosundaki colA kolonun değerinin hiç artmadığını gözlemleriz. Bunun nedeni atomicty tablosuna constraint ihlali sonucunda kayıt atılamamasıdır. Halbuki trigger insert’den hemen önce çalışıp update işlemini bitirmişti. Evet bu durumdanda anladığımız üzere asıl olan insert işlemi düzgün bir şekilde sonlanmadığından triggerda yapılan işlemde Oracle tarafından ROLLBACK edildi. Bu davranışla transaction sanki hiç çalışmamış gibi davranıldı ve data eski haline geri getirildi.

Procedural Level Atomicity

Örnek üzerinden açıklayacak olursak, 

Önce bir tablo yaratalım be tabloya bir check constraint ekleyelim.
CREATE TABLE atomicity(cola NUMBER CHECK(cola<25));

— Daha sonra bir Begin End bloğu içinde bu tabloya 2 insert yapalım. Insertlerden biri —— constraint’i ihlal ederken diğeri etmesin ve sonucu inceleyelim.

BEGIN
INSERT INTO atomicity
VALUES (22);

INSERT INTO atomicity
VALUES (27);

END;

Yukarıdaki bloğu çalıştırdığımızda ilk insert cümlesi sorunsuz bir şekilde çalıştıktan sonra 2. insert cümlesinde hata alındığından dolayı Transaction hata alarak sonlanmıştır. İlgili tablomuza son işlem olarak select atıp içerideki kayıtları incelediğimizde 1. insert cümlesi sorunsuz çalışmasıkna rağmen içeride hiç bir kayıdın olmadığını görmekteyiz. İşte transaction’ının bu karakteristiği statement seviyesindeki atomiklikten gelmektedir. İşlemler tek tek sorunsuz çalışsalar bile herhangi birinde alınan hata tüm transactionın rollback edilmesine sebeiyet verecektir. Bu sebepten ötürü db üzerinde yazacağımız fonksyonlarda prosedürlerde veya triggerlarda bu durumu göz önünde bulundurup beklenmeyen durumlar ile karşılaşmamak için Exception Handling’i doğru bir şekilde uygulamalıyız.

Transaction Level Atomicity

Tansaction Level Atomicity aslında bundan önce anlattığımız 2 seviyeyide encapsule eden genel bir kavram. Bu yapı ile Transaction’lar database’i tutarlı bir durumdan diğer tutarlı bir duruma geçiriyor ve data bütünlüğü sağlıyor.Bu işlemi gerçekleştirirkende ya commit ile tüm değişiklikleri geçerli kılıp kalıcı hale getiriyor. Yada rollback ederek db’yi bir önceki kararlı haline geri getiriyor.

DDL and Atomicity

DDL cümlecikleri otomatik olarak, çalıştıktan önce ve sonra sanki commit komutu verilimiş gibi çalışmaktadır. Yazdığımız PL/SQL kod bloklarında bu ayrıntının unutulmaması gerekmektedir. Aksi takdirde çalıştırdığımız DDL’er auto commit olduğundan dolayı transaction mantığımızı kırabilir ve db’nin atomicity ile bize sunduğu consistent yapıyı bozmamıza sebeiyet verebilir.

Kaynaklar:

“Expert Oracle Database Architecture 2011″, Tom KYTE

tahiti.oracle.com

tonguc.wordpress.com

Advertisements

About ... from Emrah METE

Bilgisayar Mühendisi
This entry was posted in Oracle, Root, Uncategorized and tagged , , , , . Bookmark the permalink.

3 Responses to Oracle Transactions – 2

  1. Pingback: Oracle Transactions – 3 | Emrah METE

  2. Pingback: CREATE SCHEMA SÖZ DEYİMİ İLE TRANSACTIONAL DDL | Emrah METE

  3. Pingback: TRANSACTIONAL DDL BASIS WITH CREATE SCHEMA PHRASE | Emrah METE

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s