Veritabanlar\u0131, modern bilgi sistemlerinin kalbinde yer al\u0131r ve \u015firketlerin, kurumlar\u0131n ve bireylerin kritik verilerini depolar. Bu verilerin do\u011frulu\u011fu, g\u00fcvenli\u011fi ve tutarl\u0131l\u0131\u011f\u0131, i\u015f s\u00fcreklili\u011fi ve g\u00fcvenilirlik a\u00e7\u0131s\u0131ndan hayati \u00f6neme sahiptir. Bir veritaban\u0131nda ger\u00e7ekle\u015ftirilen her t\u00fcrl\u00fc de\u011fi\u015fiklik \u2013 yeni veri ekleme, mevcut veriyi g\u00fcncelleme veya silme \u2013 potansiyel olarak veritaban\u0131n\u0131n genel durumunu etkileyebilir. Bu nedenle, bu de\u011fi\u015fikliklerin belirli kurallar ve prensipler \u00e7er\u00e7evesinde y\u00f6netilmesi gerekir. \u0130\u015fte bu noktada “i\u015flem” (transaction) kavram\u0131 ve onun ayr\u0131lmaz par\u00e7alar\u0131 olan COMMIT ve ROLLBACK mekanizmalar\u0131 devreye girer.<\/p>\n
Veritaban\u0131 i\u015flemleri, bir veya daha fazla veritaban\u0131 operasyonunun mant\u0131ksal bir birim olarak ele al\u0131nmas\u0131n\u0131 sa\u011flar. Bu, t\u00fcm operasyonlar\u0131n ba\u015far\u0131l\u0131 olmas\u0131 durumunda de\u011fi\u015fikliklerin kal\u0131c\u0131 hale getirilmesi (COMMIT) veya herhangi bir hata durumunda t\u00fcm de\u011fi\u015fikliklerin geri al\u0131nmas\u0131 (ROLLBACK) prensibine dayan\u0131r. Bu makalede, SQL d\u00fcnyas\u0131nda COMMIT ve ROLLBACK’in ne anlama geldi\u011fini, nas\u0131l \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131, neden bu kadar \u00f6nemli oldu\u011funu ve veritaban\u0131 y\u00f6netimindeki rol\u00fcn\u00fc detayl\u0131 bir \u015fekilde inceleyece\u011fiz. Ayr\u0131ca, i\u015flem y\u00f6netiminin temelini olu\u015fturan ACID \u00f6zelliklerine, SAVEPOINT kullan\u0131m\u0131na ve e\u015fzamanl\u0131l\u0131k (concurrency) sorunlar\u0131na da de\u011finece\u011fiz.<\/p>\n
Bir i\u015flem (transaction), veritaban\u0131 \u00fczerinde ger\u00e7ekle\u015ftirilen bir veya daha fazla operasyonun (SELECT, INSERT, UPDATE, DELETE) mant\u0131ksal bir birim olarak kabul edildi\u011fi bir dizidir. Bu operasyonlar, ya tamamen ba\u015far\u0131l\u0131 olur ve veritaban\u0131na kal\u0131c\u0131 olarak yans\u0131r ya da herhangi bir hata durumunda hi\u00e7biri yans\u0131maz; yani t\u00fcm\u00fc geri al\u0131n\u0131r. Bu “ya hep ya hi\u00e7” prensibi, veritaban\u0131n\u0131n tutarl\u0131l\u0131\u011f\u0131n\u0131 sa\u011flamak i\u00e7in kritik \u00f6neme sahiptir.<\/p>\n
Bir i\u015flem, tek bir mant\u0131ksal i\u015f birimini temsil eder. \u00d6rne\u011fin, bir banka uygulamas\u0131nda bir hesaptan ba\u015fka bir hesaba para transferi i\u015flemi, asl\u0131nda birden fazla veritaban\u0131 operasyonunu i\u00e7erir:
\n1. Kaynak hesaptan para \u00e7ekme (UPDATE i\u015flemi).
\n2. Hedef hesaba para yat\u0131rma (UPDATE i\u015flemi).
\n3. Transfer kayd\u0131n\u0131 olu\u015fturma (INSERT i\u015flemi).<\/p>\n
Bu \u00fc\u00e7 operasyonun da ba\u015far\u0131l\u0131 bir \u015fekilde tamamlanmas\u0131 gerekir. E\u011fer kaynak hesaptan para \u00e7ekilir ancak hedef hesaba yat\u0131r\u0131lamazsa (\u00f6rne\u011fin bir sistem hatas\u0131 nedeniyle), veritaban\u0131n\u0131n tutarl\u0131l\u0131\u011f\u0131 bozulur. \u0130\u015fte i\u015flem y\u00f6netimi, bu t\u00fcr senaryolar\u0131 ele alarak veritaban\u0131n\u0131n her zaman ge\u00e7erli ve tutarl\u0131 bir durumda kalmas\u0131n\u0131 sa\u011flar.<\/p>\n
Veritaban\u0131 i\u015flemlerinin g\u00fcvenilirli\u011fini ve tutarl\u0131l\u0131\u011f\u0131n\u0131 sa\u011flamak i\u00e7in tasarlanm\u0131\u015f d\u00f6rt temel \u00f6zellik vard\u0131r. Bu \u00f6zellikler, k\u0131saca “ACID” olarak bilinir: Atomicity (B\u00fct\u00fcnl\u00fck), Consistency (Tutarl\u0131l\u0131k), Isolation (Yal\u0131t\u0131m) ve Durability (Kal\u0131c\u0131l\u0131k).<\/p>\n
Atomicity, bir i\u015flemin ya tamamen ba\u015far\u0131l\u0131 olmas\u0131 ya da tamamen ba\u015far\u0131s\u0131z olmas\u0131 gerekti\u011fini belirtir. Yani, bir i\u015flemdeki t\u00fcm operasyonlar ya hep birlikte tamamlan\u0131r (commit edilir) ya da hi\u00e7biri tamamlanmaz (rollback edilir). E\u011fer i\u015flem s\u0131ras\u0131nda bir hata olu\u015fursa, i\u015flem yar\u0131da kalmaz; t\u00fcm de\u011fi\u015fiklikler geri al\u0131n\u0131r ve veritaban\u0131 i\u015flemin ba\u015flang\u0131c\u0131ndaki durumuna d\u00f6ner. Yukar\u0131daki para transferi \u00f6rne\u011finde, para ya her iki hesaptan da do\u011fru \u015fekilde i\u015flenir ya da hi\u00e7bir de\u011fi\u015fiklik yap\u0131lmaz.<\/p>\n
Consistency, bir i\u015flemin tamamlanmas\u0131ndan sonra veritaban\u0131n\u0131n tutarl\u0131 bir durumda kalmas\u0131n\u0131 garanti eder. Bu, i\u015flemin veritaban\u0131n\u0131n \u00f6nceden tan\u0131mlanm\u0131\u015f t\u00fcm kurallar\u0131na, k\u0131s\u0131tlamalar\u0131na (primary key, foreign key, unique, check k\u0131s\u0131tlamalar\u0131) ve tetikleyicilerine (trigger) uymas\u0131 gerekti\u011fi anlam\u0131na gelir. Bir i\u015flem ba\u015flad\u0131\u011f\u0131nda veritaban\u0131 tutarl\u0131 bir durumdad\u0131r ve i\u015flem bitti\u011finde de tutarl\u0131 bir durumda olmal\u0131d\u0131r. \u00d6rne\u011fin, bir banka hesab\u0131n\u0131n bakiyesi asla negatif olamaz gibi bir kural varsa, bir i\u015flem bu kural\u0131 ihlal edemez.<\/p>\n
Isolation, e\u015fzamanl\u0131 olarak y\u00fcr\u00fct\u00fclen i\u015flemlerin birbirini etkilememesini sa\u011flar. Her i\u015flem, di\u011fer i\u015flemlerden ba\u011f\u0131ms\u0131z olarak y\u00fcr\u00fct\u00fcl\u00fcyormu\u015f gibi g\u00f6r\u00fcn\u00fcr. Yani, bir i\u015flem devam ederken, di\u011fer i\u015flemler bu i\u015flemin hen\u00fcz tamamlanmam\u0131\u015f de\u011fi\u015fikliklerini g\u00f6remez. Bu, birden fazla kullan\u0131c\u0131n\u0131n ayn\u0131 anda ayn\u0131 veriler \u00fczerinde i\u015flem yaparken veri b\u00fct\u00fcnl\u00fc\u011f\u00fcn\u00fcn korunmas\u0131n\u0131 sa\u011flar. \u00d6rne\u011fin, A kullan\u0131c\u0131s\u0131 bir hesaptan para \u00e7ekerken, B kullan\u0131c\u0131s\u0131 ayn\u0131 hesab\u0131n bakiyesini kontrol etti\u011finde, A kullan\u0131c\u0131s\u0131n\u0131n i\u015flemi tamamlanana kadar eski bakiyeyi g\u00f6rmelidir.<\/p>\n
Durability, ba\u015far\u0131l\u0131 bir \u015fekilde tamamlanan (commit edilen) bir i\u015flemin de\u011fi\u015fikliklerinin kal\u0131c\u0131 olmas\u0131n\u0131 ve sistem ar\u0131zalar\u0131 (g\u00fc\u00e7 kesintisi, sistem \u00e7\u00f6kmesi) durumunda bile kaybolmamas\u0131n\u0131 garanti eder. Veritaban\u0131 sistemi, commit edilen de\u011fi\u015fiklikleri kal\u0131c\u0131 depolama birimlerine (sabit disk) yazarak bu \u00f6zelli\u011fi sa\u011flar. Bu genellikle, de\u011fi\u015fikliklerin bir i\u015flem g\u00fcnl\u00fc\u011f\u00fcne (transaction log) yaz\u0131lmas\u0131yla ger\u00e7ekle\u015ftirilir. Sistem yeniden ba\u015flat\u0131ld\u0131\u011f\u0131nda, bu g\u00fcnl\u00fckler kullan\u0131larak son commit edilen duruma geri d\u00f6n\u00fclebilir.<\/p>\n
COMMIT komutu, bir i\u015flem i\u00e7indeki t\u00fcm de\u011fi\u015fikliklerin veritaban\u0131na kal\u0131c\u0131 olarak kaydedilmesini sa\u011flar. Bir i\u015flem COMMIT edildi\u011finde, bu i\u015flemin yapt\u0131\u011f\u0131 t\u00fcm de\u011fi\u015fiklikler di\u011fer kullan\u0131c\u0131lar ve i\u015flemler taraf\u0131ndan g\u00f6r\u00fcn\u00fcr hale gelir ve art\u0131k geri al\u0131namaz.<\/p>\n
COMMIT, bir i\u015flem blo\u011funun ba\u015far\u0131yla tamamland\u0131\u011f\u0131n\u0131 ve bu blok i\u00e7indeki t\u00fcm SQL komutlar\u0131n\u0131n (INSERT, UPDATE, DELETE) veritaban\u0131 \u00fczerinde kal\u0131c\u0131 bir etki yaratt\u0131\u011f\u0131n\u0131 bildiren komuttur. Bu, i\u015flemi ba\u015flatan kullan\u0131c\u0131 veya uygulama i\u00e7in i\u015flemin sonland\u0131\u011f\u0131 ve yap\u0131lan de\u011fi\u015fikliklerin art\u0131k sistemin bir par\u00e7as\u0131 oldu\u011fu anlam\u0131na gelir.<\/p>\n
\u00c7o\u011fu veritaban\u0131 sistemi, varsay\u0131lan olarak “otomatik commit” modunda \u00e7al\u0131\u015f\u0131r. Bu modda, her bir SQL komutu (\u00f6rne\u011fin, tek bir INSERT veya UPDATE ifadesi) ayr\u0131 bir i\u015flem olarak kabul edilir ve otomatik olarak commit edilir. Ancak, daha karma\u015f\u0131k ve birden fazla ad\u0131m\u0131 olan i\u015flemler i\u00e7in manuel i\u015flem y\u00f6netimi tercih edilir. Manuel i\u015flem y\u00f6netimi, Genel s\u00f6zdizimi olduk\u00e7a basittir:<\/p>\n \u00d6rnek:<\/strong> Bir m\u00fc\u015fterinin e-posta adresini g\u00fcncelleyelim ve bu de\u011fi\u015fikli\u011fi kal\u0131c\u0131 hale getirelim.<\/p>\n Bir i\u015flem commit edildi\u011finde, veritaban\u0131 y\u00f6netim sistemi (DBMS) \u015fu ad\u0131mlar\u0131 atar: ROLLBACK komutu, bir i\u015flem i\u00e7inde yap\u0131lan t\u00fcm de\u011fi\u015fiklikleri geri al\u0131r ve veritaban\u0131n\u0131 i\u015flemin ba\u015flang\u0131c\u0131ndaki durumuna d\u00f6nd\u00fcr\u00fcr. Bu, i\u015flemin ba\u015far\u0131s\u0131z oldu\u011fu, bir hata olu\u015ftu\u011fu veya kullan\u0131c\u0131n\u0131n i\u015flemi iptal etti\u011fi durumlarda kullan\u0131l\u0131r.<\/p>\n ROLLBACK, bir i\u015flemin yar\u0131da kald\u0131\u011f\u0131n\u0131 veya ba\u015far\u0131s\u0131z oldu\u011funu belirtir ve bu i\u015flem taraf\u0131ndan yap\u0131lan t\u00fcm de\u011fi\u015fikliklerin iptal edilmesini sa\u011flar. Bu, veritaban\u0131n\u0131n tutarl\u0131l\u0131\u011f\u0131n\u0131 korumak i\u00e7in hayati bir mekanizmad\u0131r, \u00e7\u00fcnk\u00fc k\u0131smen tamamlanm\u0131\u015f veya hatal\u0131 i\u015flemlerin veritaban\u0131nda kal\u0131c\u0131 izler b\u0131rakmas\u0131n\u0131 engeller.<\/p>\n ROLLBACK genellikle a\u015fa\u011f\u0131daki durumlarda tetiklenir: Genel s\u00f6zdizimi:<\/p>\n \u00d6rnek:<\/strong> Bir para transferi i\u015flemi s\u0131ras\u0131nda bir hata oldu\u011funu varsayal\u0131m.<\/p>\n Bir i\u015flem rollback edildi\u011finde, DBMS \u015fu ad\u0131mlar\u0131 atar: SAVEPOINT (kay\u0131t noktas\u0131), bir i\u015flem i\u00e7inde belirli bir noktay\u0131 i\u015faretlemek i\u00e7in kullan\u0131l\u0131r. Bu, t\u00fcm i\u015flemi geri almak yerine, i\u015flemin sadece belirli bir k\u0131sm\u0131n\u0131 geri almay\u0131 (ROLLBACK TO SAVEPOINT) m\u00fcmk\u00fcn k\u0131lar.<\/p>\n SAVEPOINT, \u00f6zellikle karma\u015f\u0131k ve uzun s\u00fcren i\u015flemlerde faydal\u0131d\u0131r. Bir i\u015flemin birden fazla a\u015famas\u0131 oldu\u011funda ve bu a\u015famalardan birinde hata olu\u015fursa, t\u00fcm i\u015flemi geri almak yerine sadece hatal\u0131 a\u015famadan \u00f6nceki SAVEPOINT’e geri d\u00f6n\u00fclebilir. Bu, ba\u015far\u0131l\u0131 olan \u00f6nceki a\u015famalar\u0131n tekrar \u00e7al\u0131\u015ft\u0131r\u0131lmas\u0131n\u0131 \u00f6nler ve performans\u0131 art\u0131r\u0131r.<\/p>\n * Kademe Kademe Onay:<\/strong> Bir uygulaman\u0131n birden fazla ad\u0131mdan olu\u015fan bir i\u015flem ger\u00e7ekle\u015ftirmesi ve her ad\u0131m\u0131n ba\u011f\u0131ms\u0131z olarak geri al\u0131nabilir olmas\u0131 gerekti\u011finde. Modern veritaban\u0131 sistemleri, ayn\u0131 anda binlerce hatta milyonlarca i\u015flemin e\u015fzamanl\u0131 olarak \u00e7al\u0131\u015fmas\u0131na olanak tan\u0131r. Bu e\u015fzamanl\u0131l\u0131k, veritaban\u0131 performans\u0131n\u0131 art\u0131r\u0131rken, ayn\u0131 zamanda veri tutarl\u0131l\u0131\u011f\u0131n\u0131 korumak i\u00e7in dikkatli bir y\u00f6netim gerektirir.<\/p>\n E\u015fzamanl\u0131l\u0131k kontrol\u00fc i\u00e7in veritaban\u0131 y\u00f6netim sistemleri kilitlenme mekanizmalar\u0131n\u0131 kullan\u0131r. Bir i\u015flem bir veri \u00f6\u011fesini de\u011fi\u015ftirdi\u011finde, o veri \u00f6\u011fesi \u00fczerinde bir kilit tutulur. Bu kilit, di\u011fer i\u015flemlerin ayn\u0131 veri \u00f6\u011fesini ayn\u0131 anda de\u011fi\u015ftirmesini veya bazen okumas\u0131n\u0131 engeller. Kilitler, i\u015flemin COMMIT veya ROLLBACK edilmesiyle serbest b\u0131rak\u0131l\u0131r.<\/p>\n SQL standard\u0131, e\u015fzamanl\u0131 i\u015flemlerin birbirini ne kadar etkileyebilece\u011fini belirleyen d\u00f6rt ana izolasyon seviyesi tan\u0131mlar: \u0130zolasyon seviyesinin se\u00e7imi, uygulama gereksinimleri ve performans dengesi aras\u0131nda dikkatli bir denge gerektirir.<\/p>\n Deadlock, iki veya daha fazla i\u015flemin birbirlerinin kilitledi\u011fi kaynaklar\u0131 bekledi\u011fi ve bu nedenle hi\u00e7birinin ilerleyemedi\u011fi bir durumdur. \u00d6rne\u011fin, \u0130\u015flem A, X kayna\u011f\u0131n\u0131 kilitler ve Y kayna\u011f\u0131n\u0131 beklerken, \u0130\u015flem B, Y kayna\u011f\u0131n\u0131 kilitler ve X kayna\u011f\u0131n\u0131 bekler. Bu durumda, her iki i\u015flem de sonsuza kadar bekler.<\/p>\n Veritaban\u0131 sistemleri, deadlock’lar\u0131 tespit etmek ve \u00e7\u00f6zmek i\u00e7in mekanizmalara sahiptir. Genellikle, sistem deadlock’u tespit etti\u011finde, i\u015flemlerden birini (genellikle en az kaynak kullanan\u0131) otomatik olarak geri al\u0131r (rollback eder) ve di\u011fer i\u015flemin devam etmesini sa\u011flar. Uygulama geli\u015ftiricileri, i\u015flemlerin kaynaklara eri\u015fim s\u0131ras\u0131n\u0131 standartla\u015ft\u0131rarak ve i\u015flemleri m\u00fcmk\u00fcn oldu\u011funca k\u0131sa tutarak deadlock riskini azaltabilirler.<\/p>\n Veritaban\u0131 i\u015flemlerini y\u00f6netmenin iki ana yolu vard\u0131r: otomatik (implicit) ve manuel (explicit).<\/p>\n Baz\u0131 veritaban\u0131 sistemleri ve ba\u011flant\u0131 s\u00fcr\u00fcc\u00fcleri, her bir SQL komutunu otomatik olarak bir i\u015flem i\u00e7inde y\u00fcr\u00fct\u00fcr ve komut ba\u015far\u0131l\u0131 oldu\u011funda otomatik olarak commit eder. Bu, \u00f6zellikle basit sorgular ve tekil veri manip\u00fclasyonlar\u0131 i\u00e7in kolayl\u0131k sa\u011flar. Ancak, birden fazla komutun mant\u0131ksal bir b\u00fct\u00fcn olu\u015fturdu\u011fu durumlarda, otomatik i\u015flemler veri tutars\u0131zl\u0131\u011f\u0131na yol a\u00e7abilir.<\/p>\n Manuel i\u015flemler, Manuel i\u015flemlerin avantaj\u0131, birden fazla veritaban\u0131 operasyonunu tek bir mant\u0131ksal birim olarak gruplayabilme ve bu birimin b\u00fct\u00fcnl\u00fc\u011f\u00fcn\u00fc garanti edebilme yetene\u011fidir. Dezavantaj\u0131 ise, geli\u015ftiricinin i\u015flem y\u00f6netimini do\u011fru bir \u015fekilde ele almas\u0131 gerekti\u011fidir; aksi takdirde a\u00e7\u0131k b\u0131rak\u0131lan i\u015flemler kilitlenmelere ve kaynak t\u00fcketimine yol a\u00e7abilir.<\/p>\n Daha \u00f6nce bahsetti\u011fimiz para transferi \u00f6rne\u011fini daha detayl\u0131 inceleyelim.<\/p>\n Bu senaryoda, herhangi bir ad\u0131mda bir sorun olu\u015fursa (kaynak hesap yok, yetersiz bakiye, hedef hesap yok), Bir e-ticaret uygulamas\u0131nda bir \u00fcr\u00fcn\u00fcn sat\u0131\u015f\u0131 ger\u00e7ekle\u015fti\u011finde hem stok miktar\u0131n\u0131n g\u00fcncellenmesi hem de sipari\u015f kayd\u0131n\u0131n olu\u015fturulmas\u0131 gerekir.<\/p>\n B\u00fcy\u00fck miktarda verinin tek seferde i\u015flenmesi gerekti\u011finde, her bir kayd\u0131 ayr\u0131 ayr\u0131 commit etmek yerine t\u00fcm toplu i\u015flemi tek bir i\u015flem olarak ele almak performans\u0131 art\u0131rabilir ve veri tutarl\u0131l\u0131\u011f\u0131n\u0131 sa\u011flayabilir. E\u011fer toplu i\u015flemin ortas\u0131nda bir hata olursa, t\u00fcm toplu i\u015flem geri al\u0131nabilir.<\/p>\n \u0130\u015flem y\u00f6netimi, veritaban\u0131 uygulamalar\u0131n\u0131n performans\u0131 ve g\u00fcvenilirli\u011fi i\u00e7in kritik \u00f6neme sahiptir. \u0130\u015fte baz\u0131 en iyi uygulamalar:<\/p>\n 1. \u0130\u015flemleri K\u0131sa Tutun:<\/strong> Uzun s\u00fcren i\u015flemler, kaynaklar\u0131 daha uzun s\u00fcre kilitli tutar, bu da e\u015fzamanl\u0131l\u0131\u011f\u0131 azalt\u0131r ve deadlock riskini art\u0131r\u0131r. \u0130\u015f mant\u0131\u011f\u0131n\u0131z\u0131 m\u00fcmk\u00fcn oldu\u011funca k\u00fc\u00e7\u00fck ve atomik i\u015flemlere b\u00f6l\u00fcn. SQL'deki COMMIT ve ROLLBACK komutlar\u0131, modern veritaban\u0131 y\u00f6netim sistemlerinin temelini olu\u015fturan g\u00fc\u00e7l\u00fc ara\u00e7lard\u0131r. Bu mekanizmalar, veritaban\u0131 i\u015flemlerinin ACID \u00f6zelliklerini (Atomicity, Consistency, Isolation, Durability) sa\u011flamas\u0131na yard\u0131mc\u0131 olarak, veri b\u00fct\u00fcnl\u00fc\u011f\u00fcn\u00fc ve g\u00fcvenilirli\u011fini garanti eder. COMMIT ile ba\u015far\u0131l\u0131 i\u015flemler kal\u0131c\u0131 hale gelirken, ROLLBACK ile hatal\u0131 veya tamamlanmam\u0131\u015f i\u015flemler geri al\u0131narak veritaban\u0131n\u0131n tutarl\u0131 bir durumda kalmas\u0131 sa\u011flan\u0131r. SAVEPOINT'ler ise daha esnek i\u015flem y\u00f6netimi sunarak, karma\u015f\u0131k senaryolarda verimlili\u011fi art\u0131r\u0131r.<\/p>\n Do\u011fru i\u015flem y\u00f6netimi stratejileri ve en iyi uygulamalar\u0131n benimsenmesi, geli\u015ftiricilerin sa\u011flam, g\u00fcvenilir ve y\u00fcksek performansl\u0131 veritaban\u0131 uygulamalar\u0131 olu\u015fturmas\u0131na olanak tan\u0131r. Veri, g\u00fcn\u00fcm\u00fcz d\u00fcnyas\u0131n\u0131n en de\u011ferli varl\u0131klar\u0131ndan biri oldu\u011fundan, bu verilerin do\u011fru ve g\u00fcvenli bir \u015fekilde i\u015flenmesi, her veritaban\u0131 profesyonelinin \u00f6ncelikli sorumlulu\u011fudur. COMMIT ve ROLLBACK, bu sorumlulu\u011fu yerine getirmede vazge\u00e7ilmez bir rol oynar.<\/body><\/p>\n","protected":false},"excerpt":{"rendered":"SQL Commit ve Rollback: Veritaban\u0131 \u0130\u015flemlerinde Tutarl\u0131l\u0131k ve G\u00fcvenlik\nGiri\u015f: Veritaban\u0131 \u0130\u015flemlerinin \u00d6nemi\nVeritabanlar\u0131, modern bilgi s","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"csco_page_header_type":"","csco_page_load_nextpost":"","csco_page_subscribe_form":"","csco_page_contact_form":"","footnotes":""},"categories":[1505],"tags":[],"class_list":{"0":"post-31930","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-sql-2","7":"cs-entry","8":"cs-video-wrap"},"yoast_head":"\nBEGIN TRANSACTION<\/code> (veya START TRANSACTION<\/code>) komutuyla ba\u015flar ve COMMIT<\/code> veya ROLLBACK<\/code> komutuyla sona erer.<\/p>\nS\u00f6zdizimi ve \u00d6rnek<\/h3>\n
BEGIN TRANSACTION;\n-- SQL komutlar\u0131 (INSERT, UPDATE, DELETE)\nCOMMIT;<\/code><\/pre>\nBEGIN TRANSACTION;\n\nUPDATE Musteriler\nSET Email = 'yeni.eposta@example.com'\nWHERE MusteriID = 123;\n\n-- E\u011fer yukar\u0131daki UPDATE ba\u015far\u0131l\u0131ysa ve ba\u015fka bir hata yoksa, i\u015flemi commit et.\nCOMMIT;<\/code><\/pre>\nCOMMIT’in Ard\u0131ndaki Mekanizma<\/h3>\n
\n1. G\u00fcnl\u00fck Kayd\u0131 (Logging):<\/strong> \u0130\u015flem s\u0131ras\u0131nda yap\u0131lan t\u00fcm de\u011fi\u015fiklikler, kal\u0131c\u0131 depolama biriminde bulunan i\u015flem g\u00fcnl\u00fc\u011f\u00fcne (transaction log) yaz\u0131l\u0131r. Bu g\u00fcnl\u00fckler, sistem ar\u0131zas\u0131 durumunda verilerin kurtar\u0131lmas\u0131 i\u00e7in kritik \u00f6neme sahiptir.
\n2. Veri Yazma (Data Writing):<\/strong> De\u011fi\u015ftirilen veriler, veritaban\u0131n\u0131n ana veri dosyalar\u0131na yaz\u0131l\u0131r. Bu genellikle tampon belleklerden (buffer cache) disk \u00fczerine yazma (flushing) i\u015flemiyle ger\u00e7ekle\u015fir.
\n3. Kilitlerin Serbest B\u0131rak\u0131lmas\u0131 (Releasing Locks):<\/strong> \u0130\u015flem s\u0131ras\u0131nda veriler \u00fczerinde tutulan t\u00fcm kilitler serbest b\u0131rak\u0131l\u0131r. Bu, di\u011fer i\u015flemlerin bu verilere eri\u015fmesine ve \u00fczerinde de\u011fi\u015fiklik yapmas\u0131na olanak tan\u0131r.
\n4. \u0130\u015flem Sona Ermesi:<\/strong> \u0130\u015flem ba\u015far\u0131l\u0131 bir \u015fekilde tamamlan\u0131r ve sistem kaynaklar\u0131 serbest b\u0131rak\u0131l\u0131r.<\/p>\nROLLBACK Nedir?<\/h2>\n
Tan\u0131m ve Amac\u0131<\/h3>\n
Hata Durumlar\u0131 ve Kullan\u0131c\u0131 \u0130ptali<\/h3>\n
\n* Sistem Hatas\u0131:<\/strong> Veritaban\u0131 sunucusunun \u00e7\u00f6kmesi, a\u011f ba\u011flant\u0131s\u0131n\u0131n kesilmesi veya disk hatas\u0131 gibi durumlar.
\n* Uygulama Hatas\u0131:<\/strong> Uygulama mant\u0131\u011f\u0131nda bir hata olu\u015fmas\u0131 (\u00f6rne\u011fin, ge\u00e7ersiz veri giri\u015fi, s\u0131f\u0131ra b\u00f6lme hatas\u0131).
\n* K\u0131s\u0131tlama \u0130hlali:<\/strong> Veritaban\u0131 k\u0131s\u0131tlamalar\u0131n\u0131n (PRIMARY KEY, FOREIGN KEY, CHECK) ihlal edilmesi.
\n* Kullan\u0131c\u0131 \u0130ptali:<\/strong> Kullan\u0131c\u0131n\u0131n i\u015flemi manuel olarak iptal etmesi veya bir i\u015flemin \u00e7ok uzun s\u00fcrmesi nedeniyle zaman a\u015f\u0131m\u0131na u\u011framas\u0131.<\/p>\nS\u00f6zdizimi ve \u00d6rnek<\/h3>\n
BEGIN TRANSACTION;\n-- SQL komutlar\u0131 (INSERT, UPDATE, DELETE)\nROLLBACK;<\/code><\/pre>\nBEGIN TRANSACTION;\n\n-- Kaynak hesaptan para \u00e7ekme\nUPDATE Hesaplar\nSET Bakiye = Bakiye - 100\nWHERE HesapID = 1;\n\n-- Hedef hesaba para yat\u0131rma\n-- Bir hata oldu\u011funu varsayal\u0131m, \u00f6rne\u011fin hedef hesap ID'si yanl\u0131\u015f\nUPDATE Hesaplar\nSET Bakiye = Bakiye + 100\nWHERE HesapID = 999; -- Bu HesapID'si mevcut de\u011fil veya yanl\u0131\u015f\n\n-- E\u011fer yukar\u0131daki UPDATE ba\u015far\u0131s\u0131z olursa (\u00f6rne\u011fin etkilenen sat\u0131r 0 ise),\n-- t\u00fcm i\u015flemi geri almal\u0131y\u0131z.\nIF @@ROWCOUNT = 0 -- SQL Server i\u00e7in, di\u011fer veritabanlar\u0131nda farkl\u0131 olabilir\nBEGIN\n PRINT 'Hedef hesap bulunamad\u0131, i\u015flem geri al\u0131n\u0131yor.';\n ROLLBACK;\nEND\nELSE\nBEGIN\n COMMIT;\nEND;<\/code><\/pre>\nROLLBACK’in Ard\u0131ndaki Mekanizma<\/h3>\n
\n1. G\u00fcnl\u00fck Kullan\u0131m\u0131 (Log Usage):<\/strong> \u0130\u015flem g\u00fcnl\u00fc\u011f\u00fcnde kaydedilen de\u011fi\u015fiklikler tersine \u00e7evrilir. DBMS, i\u015flemin ba\u015flang\u0131c\u0131ndan itibaren yap\u0131lan t\u00fcm de\u011fi\u015fiklikleri bulur ve veritaban\u0131n\u0131 i\u015flemin ba\u015flang\u0131c\u0131ndaki durumuna geri d\u00f6nd\u00fcr\u00fcr. Bu, “undo” i\u015flemleri olarak bilinir.
\n2. Kilitlerin Serbest B\u0131rak\u0131lmas\u0131:<\/strong> \u0130\u015flem s\u0131ras\u0131nda tutulan t\u00fcm kilitler serbest b\u0131rak\u0131l\u0131r.
\n3. \u0130\u015flem Sona Ermesi:<\/strong> \u0130\u015flem iptal edilir ve sistem kaynaklar\u0131 serbest b\u0131rak\u0131l\u0131r.<\/p>\nSAVEPOINT Nedir?<\/h2>\n
Tan\u0131m ve Amac\u0131<\/h3>\n
Kullan\u0131m Senaryolar\u0131<\/h3>\n
\n* Deneysel De\u011fi\u015fiklikler:<\/strong> Bir dizi de\u011fi\u015fiklik yapmadan \u00f6nce bir SAVEPOINT olu\u015fturup, de\u011fi\u015fikliklerin istenildi\u011fi gibi gitmemesi durumunda bu noktaya geri d\u00f6nmek.
\n* Hata Y\u00f6netimi:<\/strong> \u0130\u015flemin belirli bir b\u00f6l\u00fcm\u00fcnde hata yakaland\u0131\u011f\u0131nda, sadece o b\u00f6l\u00fcm\u00fc geri al\u0131p i\u015flemin di\u011fer k\u0131s\u0131mlar\u0131na devam etme.<\/p>\nS\u00f6zdizimi ve \u00d6rnek<\/h3>\n
BEGIN TRANSACTION;\n\n-- \u0130lk set i\u015flemler\nINSERT INTO Tablo1 VALUES (1, 'Veri1');\nSAVE TRANSACTION Nokta1; -- veya SAVEPOINT Nokta1;\n\n-- \u0130kinci set i\u015flemler\nUPDATE Tablo2 SET Kolon = 'YeniDeger' WHERE ID = 1;\nSAVE TRANSACTION Nokta2;\n\n-- \u00dc\u00e7\u00fcnc\u00fc set i\u015flemler\nDELETE FROM Tablo3 WHERE ID = 5;\n\n-- E\u011fer \u00fc\u00e7\u00fcnc\u00fc set i\u015flemlerde bir sorun olursa, sadece Nokta2'ye geri d\u00f6n\n-- DELETE i\u015flemi geri al\u0131n\u0131r, di\u011ferleri kal\u0131r.\nROLLBACK TRANSACTION Nokta2; -- veya ROLLBACK TO SAVEPOINT Nokta2;\n\n-- E\u011fer t\u00fcm i\u015flemde bir sorun olursa, en ba\u015fa d\u00f6n\n-- ROLLBACK;\n\nCOMMIT; -- E\u011fer her \u015fey yolundaysa<\/code><\/pre>\n\u0130\u015flem Y\u00f6netimi ve E\u015fzamanl\u0131l\u0131k<\/h2>\n
Kilitlenme (Locking) Mekanizmalar\u0131<\/h3>\n
\u0130zolasyon Seviyeleri (Isolation Levels)<\/h3>\n
\n* Read Uncommitted:<\/strong> En d\u00fc\u015f\u00fck izolasyon seviyesi. Bir i\u015flem, commit edilmemi\u015f de\u011fi\u015fiklikleri (kirli okuma – dirty read) g\u00f6rebilir. Bu, en y\u00fcksek e\u015fzamanl\u0131l\u0131\u011f\u0131 sa\u011flar ancak veri tutars\u0131zl\u0131\u011f\u0131na yol a\u00e7abilir.
\n* Read Committed:<\/strong> Bir i\u015flem, yaln\u0131zca commit edilmi\u015f de\u011fi\u015fiklikleri g\u00f6rebilir. Kirli okumalar\u0131 \u00f6nler, ancak tekrarlanamayan okumalar (non-repeatable read) ve fantom okumalar (phantom read) olu\u015fabilir. \u00c7o\u011fu veritaban\u0131nda varsay\u0131lan seviyedir.
\n* Repeatable Read:<\/strong> Bir i\u015flem, kendi ba\u015flad\u0131\u011f\u0131 anda okudu\u011fu veriyi, i\u015flem bitene kadar ayn\u0131 \u015fekilde okumas\u0131n\u0131 garanti eder. Tekrarlanamayan okumalar\u0131 \u00f6nler, ancak fantom okumalar hala m\u00fcmk\u00fcnd\u00fcr.
\n* Serializable:<\/strong> En y\u00fcksek izolasyon seviyesi. T\u00fcm e\u015fzamanl\u0131 i\u015flemler, sanki birbiri ard\u0131na s\u0131rayla \u00e7al\u0131\u015f\u0131yormu\u015f gibi g\u00f6r\u00fcn\u00fcr. Kirli okumalar\u0131, tekrarlanamayan okumalar\u0131 ve fantom okumalar\u0131 tamamen \u00f6nler, ancak e\u015fzamanl\u0131l\u0131\u011f\u0131 ve performans\u0131 d\u00fc\u015f\u00fcrebilir.<\/p>\nDeadlock (Kilitlenme) ve \u00c7\u00f6z\u00fcmleri<\/h3>\n
Otomatik ve Manuel \u0130\u015flem Y\u00f6netimi<\/h2>\n
Implicit Transactions (Otomatik \u0130\u015flemler)<\/h3>\n
Explicit Transactions (Manuel \u0130\u015flemler)<\/h3>\n
BEGIN TRANSACTION<\/code> (veya START TRANSACTION<\/code>) komutuyla a\u00e7\u0131k\u00e7a ba\u015flat\u0131l\u0131r ve COMMIT<\/code> veya ROLLBACK<\/code> komutlar\u0131yla a\u00e7\u0131k\u00e7a sonland\u0131r\u0131l\u0131r. Bu yakla\u015f\u0131m, geli\u015ftiriciye i\u015flem ak\u0131\u015f\u0131 \u00fczerinde tam kontrol sa\u011flar ve karma\u015f\u0131k i\u015f mant\u0131\u011f\u0131na sahip uygulamalar i\u00e7in idealdir.<\/p>\n-- SQL Server'da otomatik i\u015flem modunu a\u00e7ma\/kapama \u00f6rne\u011fi\nSET IMPLICIT_TRANSACTIONS ON;\n-- Bu noktadan sonra her DML (INSERT, UPDATE, DELETE) veya DDL (CREATE, ALTER, DROP)\n-- komutu otomatik olarak yeni bir i\u015flem ba\u015flat\u0131r.\n-- Bu i\u015flemin COMMIT veya ROLLBACK edilmesi gerekir.\nUPDATE TabloA SET Kolon = 'Deger'; -- Yeni bir i\u015flem ba\u015flar\nCOMMIT; -- \u0130\u015flemi sonland\u0131r\u0131r\n\nSET IMPLICIT_TRANSACTIONS OFF;\n-- Varsay\u0131lan modda, her komut kendi i\u00e7inde commit edilir\nINSERT INTO TabloB VALUES (1, 'Test'); -- Otomatik commit edilir<\/code><\/pre>\nCommit ve Rollback Kullan\u0131m Senaryolar\u0131<\/h2>\n
Para Transferi (Detayl\u0131)<\/h3>\n
BEGIN TRANSACTION;\nDECLARE @KaynakHesapID INT = 101;\nDECLARE @HedefHesapID INT = 102;\nDECLARE @Miktar DECIMAL(18, 2) = 500.00;\nDECLARE @KaynakBakiye DECIMAL(18, 2);\n\n-- 1. Kaynak hesab\u0131n bakiyesini kontrol et\nSELECT @KaynakBakiye = Bakiye FROM Hesaplar WHERE HesapID = @KaynakHesapID;\n\nIF @KaynakBakiye IS NULL\nBEGIN\n PRINT 'Kaynak hesap bulunamad\u0131.';\n ROLLBACK;\nEND\nELSE IF @KaynakBakiye < @Miktar\nBEGIN\n PRINT 'Yetersiz bakiye.';\n ROLLBACK;\nEND\nELSE\nBEGIN\n -- 2. Kaynak hesaptan para \u00e7ek\n UPDATE Hesaplar\n SET Bakiye = Bakiye - @Miktar\n WHERE HesapID = @KaynakHesapID;\n\n -- 3. Hedef hesaba para yat\u0131r\n -- Hedef hesap mevcut de\u011filse hata olu\u015ftu\u011funu varsayal\u0131m\n IF NOT EXISTS (SELECT 1 FROM Hesaplar WHERE HesapID = @HedefHesapID)\n BEGIN\n PRINT 'Hedef hesap bulunamad\u0131.';\n ROLLBACK; -- Kaynak hesaptan \u00e7ekilen paray\u0131 geri al\n END\n ELSE\n BEGIN\n UPDATE Hesaplar\n SET Bakiye = Bakiye + @Miktar\n WHERE HesapID = @HedefHesapID;\n\n -- 4. \u0130\u015flem kayd\u0131n\u0131 olu\u015ftur\n INSERT INTO Islemler (KaynakHesapID, HedefHesapID, Miktar, Tarih, Durum)\n VALUES (@KaynakHesapID, @HedefHesapID, @Miktar, GETDATE(), 'Tamamland\u0131');\n\n -- T\u00fcm ad\u0131mlar ba\u015far\u0131l\u0131, i\u015flemi kal\u0131c\u0131 hale getir\n COMMIT;\n PRINT 'Para transferi ba\u015far\u0131yla tamamland\u0131.';\n END\nEND;<\/code><\/pre>\nROLLBACK<\/code> komutu t\u00fcm i\u015flemi geri al\u0131r ve veritaban\u0131 tutarl\u0131 bir durumda kal\u0131r.<\/p>\nStok G\u00fcncelleme<\/h3>\n
BEGIN TRANSACTION;\nDECLARE @UrunID INT = 10;\nDECLARE @Adet INT = 2;\nDECLARE @MevcutStok INT;\n\nSELECT @MevcutStok = StokAdedi FROM Urunler WHERE UrunID = @UrunID;\n\nIF @MevcutStok < @Adet\nBEGIN\n PRINT 'Yetersiz stok.';\n ROLLBACK;\nEND\nELSE\nBEGIN\n -- Stoktan d\u00fc\u015f\n UPDATE Urunler\n SET StokAdedi = StokAdedi - @Adet\n WHERE UrunID = @UrunID;\n\n -- Sipari\u015f kayd\u0131n\u0131 olu\u015ftur\n INSERT INTO Siparisler (UrunID, Adet, SiparisTarihi, Durum)\n VALUES (@UrunID, @Adet, GETDATE(), 'Onayland\u0131');\n\n -- Her \u015fey ba\u015far\u0131l\u0131ysa kaydet\n COMMIT;\n PRINT 'Sipari\u015f ba\u015far\u0131yla olu\u015fturuldu ve stok g\u00fcncellendi.';\nEND;<\/code><\/pre>\nToplu Veri Giri\u015fi\/G\u00fcncelleme<\/h3>\n
En \u0130yi Uygulamalar (Best Practices)<\/h2>\n
\n2. Kilitlenmelerden Ka\u00e7\u0131n\u0131n:<\/strong> \u0130\u015flemler i\u00e7inde gereksiz kilitlenmeleri \u00f6nlemek i\u00e7in veritaban\u0131 eri\u015fim s\u0131ras\u0131n\u0131 standartla\u015ft\u0131r\u0131n. M\u00fcmk\u00fcn oldu\u011funca az veri \u00fczerinde kilit tutun ve kilitleri m\u00fcmk\u00fcn olan en k\u0131sa s\u00fcrede serbest b\u0131rak\u0131n.
\n3. Hata Y\u00f6netimi Stratejileri:<\/strong> Her i\u015flemde potansiyel hatalar\u0131 yakalamak ve uygun ROLLBACK<\/code> veya ROLLBACK TO SAVEPOINT<\/code> komutlar\u0131n\u0131 kullanmak i\u00e7in sa\u011flam hata y\u00f6netimi mekanizmalar\u0131 uygulay\u0131n. Try-Catch bloklar\u0131 bu konuda yard\u0131mc\u0131 olabilir.
\n4. \u0130zolasyon Seviyelerini Do\u011fru Se\u00e7in:<\/strong> Uygulaman\u0131z\u0131n veri tutarl\u0131l\u0131\u011f\u0131 gereksinimleri ile performans hedefleri aras\u0131nda denge kurmak i\u00e7in uygun izolasyon seviyesini se\u00e7in. \u00c7o\u011fu uygulama i\u00e7in READ COMMITTED<\/code> yeterli olabilirken, baz\u0131 kritik senaryolar daha y\u00fcksek seviyeler gerektirebilir.
\n5. Test Edin:<\/strong> \u0130\u015flemlerinizi farkl\u0131 e\u015fzamanl\u0131l\u0131k senaryolar\u0131nda, hata durumlar\u0131nda ve performans y\u00fck\u00fc alt\u0131nda kapsaml\u0131 bir \u015fekilde test edin. Deadlock'lar ve tutars\u0131zl\u0131klar genellikle y\u00fcksek y\u00fck alt\u0131nda ortaya \u00e7\u0131kar.
\n6. BEGIN TRANSACTION<\/code> ve COMMIT\/ROLLBACK<\/code> Dengesi:<\/strong> Her BEGIN TRANSACTION<\/code> komutunun kar\u015f\u0131l\u0131\u011f\u0131nda bir COMMIT<\/code> veya ROLLBACK<\/code> komutu oldu\u011fundan emin olun. A\u00e7\u0131k b\u0131rak\u0131lan i\u015flemler kaynak s\u0131z\u0131nt\u0131lar\u0131na ve performans\u0131 d\u00fc\u015f\u00fcren kilitlenmelere yol a\u00e7abilir.<\/p>\nSonu\u00e7: Veritaban\u0131 Tutarl\u0131l\u0131\u011f\u0131n\u0131n Temel Ta\u015flar\u0131<\/h2>\n