Hareketler

Hareketler tüm veritabanı sistemlerinin en temel konularından biridir. Bir hareketin başlıca özelliği ya hep ya hiç şeklinde uygulanmak üzere çok sayıda adımın tek bir adım haline getirilmesidir. Hareketi oluşturan adımlar arasındaki işlemler onunla işbirliği yapan diğer hareketlere görünür değildir ve hareketin tamamlanmasını engelleyen bazı olumsuzluklar olduğunda hareketi oluşturan adımların hiçbiri veritabanını etkilemez.

Örneğin, bir bankanın şube hesapları (branches) olsun ve bu hesaplarda çeşitli müşteri hesapları (accounts) ve bu hesaplarda da bir miktar nakit (balance) bulunsun. Alice'in hesabından 100.00 doları Bob'ın hesabına geçirmek istediğimizi kabul edelim. Son derece basitleştirerek, SQL komutları şöyle olurdu:

UPDATE accounts SET balance = balance - 100.00
    WHERE name = 'Alice';
UPDATE branches SET balance = balance - 100.00
    WHERE name = (SELECT branch_name FROM accounts WHERE name = 'Alice');
UPDATE accounts SET balance = balance + 100.00
    WHERE name = 'Bob';
UPDATE branches SET balance = balance + 100.00
    WHERE name = (SELECT branch_name FROM accounts WHERE name = 'Bob');

Bu komutların ayrıntılarının burada bir önemi yoktur; önemli olan bunun basit işlemler olarak değil, ayrı ayrı güncellemelerin hepsinin birden yapılmasıdır. Bankamızın memurları bu işlemlerin ya hepsinin yapılmasını ya da hiçbirinin yapılmamasını ister. Eğer Bob, Alice'in hesabından yeterli miktarı alamazsa ya da Alice'in hesabından gerekli miktar alındığı halde Bob'un hesabına geçmezse sistemin hata vermesinden başka her iki müşteri de memnun olmayacaktır. Yani, eğer işlemlerden biri gerçekleşmezse bu adımların hiçbirinin veritabanını etkilemeyeceğini garantilemeliyiz. Yapılacak işlemlerin bir hareket içinde gruplanması bize bu garantiyi sağlar. Bir hareket atomik olmalıdır, denir: diğer hareketler açısından ya tüm adımların hepsi gerçekleşmeli ya da hiçbiri gerçekleşmemelidir.

Kesinlikle emin olmamız gereken bir nokta ise bir hareket başarı ile işlemi yürütmüş olsa bile, bilginin tamam olarak veritabanına geçip geçmediğidir, son anda bir sistem kaynaklı hata olsa bile. Örneğin, Bob'un hesabından para çekmeye çalıştığımızda, o daha bankanın kapısında çıkmadan, paranın bir hata sonucu onun hesabında çekilmiş olarak gözükmemesi gibi bir şansı göze alamayız. Tam bu noktada bir veritabanı, bir hareketle ilgili tüm işlemler yapılıp kayıtlar sabit disk gibi bir saklama alanına aktarılmadan 'tamam' sonucunu göndermez.

Bir diğer önemli nokta ise çok sayıda hareket aynı anda çalışırken birbirlerinin tamamlanmamış sonuçlarını görmemesi gerektiğidir. Örneğin bir hareket tüm şubelerdeki (branches) hesap miktarlarını toplarken başka bir hareket Alice ya da Bob'un hesabı üzerinde işlem yapamayacaktır. Kısaca bir hareket tamam benim işim bitti demeden, diğer bir hareket bir işlem başlatamayacaktır.

PostgreSQL'de bir hareket, BEGIN ve COMMIT SQL komutları ile sarmalanmış adımlardan oluşur. Bu durumda, banka işlemlerimiz aslında şöyle görünecektir:

BEGIN;
UPDATE accounts SET balance = balance - 100.00
    WHERE name = 'Alice';
-- vesaire vesaire
COMMIT;

Hareketin de belli bir noktasında işlemin iptal edilmesi gerekebilir (Mesela Alice'in hesabı aktarılacak miktar için yetmeyip negatife düşerse), bunun için COMMIT yerine ROLLBACK kullanabiliriz ve böyle bir durumda tüm güncellemeler iptal edilir.

PostgreSQL^TM aslında her SQL cümlesini sanki bir hareket gerçekleştiriyormuş gibi ele alır. Bir BEGIN komutu kullanmazsanız, her cümlenin başına örtük bir BEGIN ve cümle başarılı ise sonuna da örtük bir COMMIT getirilir. Bu nedenle, BEGIN ve COMMIT komutları ile sarmalanmış cümlelere bazan hareket kümesi de dendiği olur.

	Not
	Bazı istemci kütüphaneleri `BEGIN` ve `COMMIT` komutlarını kendiliğinden koyar, böylece istemeden hareket kümelerinin etkileriyle karşılaşırsınız. Bu bakımdan kullandığınız arayüzün belgelerine bakmayı unutmayın.

Bir hareketi içinde kayıt noktaları belirterek cümle cümle denetlemek de mümkündür. Kayıt noktaları bir hareketin belli parçalarını seçerek iptal etmeyi mümkün kılar. Bir kayıt noktasını SAVEPOINT ile tanımladıktan sonra ihtiyaç duyarsanız, ROLLBACK TO ile bu kayıt noktasına kadar olan kısmı geri sarabilirsiniz. Bir hareketin bu iki komut arasında kalan veritabanı değişiklikleri iptal edilir, fakat, bu bölümden önce yapılanlar veritabanında kalır.

Bir kayıt noktasına kadar geri sarıldıktan sonra, işlem bu noktadan devam eder, öyle ki, bu defalarca yapılabilir. Tersine, belli bir kayıt noktasına geri sarmaya artık ihtiyaç duymayacağınızdan emin olduğunuzda, onu serbest bırakabilirsiniz, böylece sistem bazı özkaynakları serbest bırakabilir. Serbest bırakmanın da, bir kayıt noktasına geridönmenin de tanımlanmasının ardından tüm kayıt noktalarının özdevimli olarak serbest bırakılacağını unutmayın.

Bunların hepsi hareket kümesinin içinde gerçekleşir, dolayısıyla, bu işlemlerin hiçbiri diğer veritabanı oturumlarına görünür değildir. Bir hareket kümesini işleme sokulduğunda, geriye sarma işlemleri diğer oturumlara asla görünür olmazken, işleme sokulan diğer eylemler bir birim olarak diğer oturumlara görünür hale gelir.

Bankanın veritabanını hatırlarsanız, Alice'in hesabından Bob'un hesabına 100 dolar aktarmıştık ama daha sonra baktığımızda, paranın Wally'nin hesabına geçmesi gerektiğini keşfetmiş olalım. Bunun için kayıt noktalarını şöyle kullanabiliriz:

BEGIN;
UPDATE accounts SET balance = balance - 100.00
    WHERE name = 'Alice';
SAVEPOINT my_savepoint;
UPDATE accounts SET balance = balance + 100.00
    WHERE name = 'Bob';
-- dur bakalım ... Wally'nin hesabını kullanacağız
ROLLBACK TO my_savepoint;
UPDATE accounts SET balance = balance + 100.00
    WHERE name = 'Wally';
COMMIT;

Bu örnek, şüphesiz fazla basit, fakat bir hareket bloğu üzerinde kayıt noktalarınını kullanımı ile ilgili yeterince denetim var. Dahası, sistem tarafından bir hatadan dolayı çıkış istendiğinde, ROLLBACK TO bir hareket kümesinin denetimini yeniden kazanmanın tek yoludur, tamamen gerisarma yapılıp tekrar başlanabilir.