Veritaban\u0131 sistemleri, modern uygulamalar\u0131n bel kemi\u011fidir ve veri tutarl\u0131l\u0131\u011f\u0131, eri\u015filebilirli\u011fi ile g\u00fcvenilirli\u011fi kritik \u00f6neme sahiptir. Peki, birden fazla kullan\u0131c\u0131n\u0131n ayn\u0131 anda veri \u00fczerinde i\u015flem yapt\u0131\u011f\u0131 durumlarda veri b\u00fct\u00fcnl\u00fc\u011f\u00fcn\u00fc nas\u0131l sa\u011fl\u0131yoruz? \u0130\u015fte bu sorunun cevab\u0131, SQL’deki i\u015flemler (transactions), kilitlenmeler (deadlocks) ve g\u00fcnl\u00fck tabanl\u0131 kurtarma (log-based recovery) mekanizmalar\u0131nda gizlidir. Bu makalede, bu temel kavramlar\u0131 ba\u015ftan sona ele alacak, kar\u015f\u0131la\u015fabilece\u011finiz sorunlar\u0131 ve \u00e7\u00f6z\u00fcm yollar\u0131n\u0131 ger\u00e7ek d\u00fcnya senaryolar\u0131yla ad\u0131m ad\u0131m inceleyece\u011fiz. Amac\u0131m\u0131z, veritaban\u0131 y\u00f6netimini daha iyi anlaman\u0131za ve sistemlerinizi daha sa\u011flam hale getirmenize yard\u0131mc\u0131 olmakt\u0131r.<\/p>\n
SQL veritaban\u0131 sistemlerinde, bir i\u015flem (transaction) tek bir mant\u0131ksal \u00e7al\u0131\u015fma birimi olarak tan\u0131mlan\u0131r. Bu, bir dizi veritaban\u0131 i\u015fleminin (INSERT, UPDATE, DELETE gibi) ya tamamen ba\u015far\u0131yla tamamland\u0131\u011f\u0131 (commit edildi\u011fi) ya da hi\u00e7birinin ger\u00e7ekle\u015fmemi\u015f gibi geri al\u0131nd\u0131\u011f\u0131 (rollback edildi\u011fi) anlam\u0131na gelir. Peki, neden bu kadar \u00f6nemli? \u00c7\u00fcnk\u00fc veri tutarl\u0131l\u0131\u011f\u0131, \u00f6zellikle e\u015fzamanl\u0131 olarak bir\u00e7ok kullan\u0131c\u0131n\u0131n veritaban\u0131na eri\u015fti\u011fi sistemlerde, i\u015flemler olmadan sa\u011flanamaz. Bir banka hesab\u0131ndan di\u011ferine para transferi gibi karma\u015f\u0131k operasyonlar\u0131 d\u00fc\u015f\u00fcn\u00fcn; bu i\u015flem, al\u0131c\u0131n\u0131n hesab\u0131na para eklenmeden \u00f6nce g\u00f6ndericinin hesab\u0131ndan para \u00e7ekilirse, bir felaketle sonu\u00e7lanabilir. \u0130\u015flemler, tam da bu t\u00fcr durumlar\u0131 \u00f6nlemek i\u00e7in tasarlanm\u0131\u015ft\u0131r.<\/p>\n
\u0130\u015flemlerin g\u00fcvenilirli\u011fini ve tutarl\u0131l\u0131\u011f\u0131n\u0131 sa\u011flayan d\u00f6rt ana \u00f6zellik vard\u0131r. Bunlar, k\u0131saca ACID olarak adland\u0131r\u0131l\u0131r:<\/p>\n
Bu \u00f6zellikler sayesinde, veritabanlar\u0131m\u0131z g\u00fcvenilir bir \u015fekilde \u00e7al\u0131\u015f\u0131r. \u00d6zellikle \u00e7ok kullan\u0131c\u0131l\u0131 ortamlarda, e\u015fzamanl\u0131l\u0131\u011f\u0131n y\u00f6netilmesi kritik bir konudur. SQL Server, MySQL, PostgreSQL gibi t\u00fcm modern ili\u015fkisel veritabanlar\u0131, bu ACID \u00f6zelliklerini destekler. Bir i\u015flemi manuel olarak ba\u015flatmak i\u00e7in \u015eimdi bir \u00f6rnekle daha netle\u015ftirelim. Diyelim ki bir e-ticaret siteniz var ve m\u00fc\u015fteri \u00fcr\u00fcn sat\u0131n al\u0131yor. Bu s\u00fcre\u00e7te iki temel ad\u0131m vard\u0131r: \u00fcr\u00fcn sto\u011funu azaltmak ve m\u00fc\u015fterinin bakiyesinden paray\u0131 \u00e7ekmek. Bu iki ad\u0131m\u0131n ayn\u0131 anda ba\u015far\u0131l\u0131 olmas\u0131 gerekir. \u0130\u015fte bir SQL \u00f6rne\u011fi:<\/p>\n <\/code><\/p>\n Bu \u00f6rnekte, stok veya bakiye yetersizse t\u00fcm i\u015flem geri al\u0131n\u0131r, b\u00f6ylece veritaban\u0131nda tutars\u0131z bir durum olu\u015fmas\u0131 engellenir. \u0130\u015flemlerin bu g\u00fcc\u00fc, uygulamalar\u0131m\u0131z\u0131n g\u00fcvenle \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flar. Ancak, e\u015fzamanl\u0131l\u0131\u011f\u0131n y\u00f6netilmesi konusunda i\u015fler bazen kar\u0131\u015fabilir ve kilitlenmeler gibi sorunlara yol a\u00e7abilir.<\/p>\n E\u015fzamanl\u0131 i\u015flemlerin veritaban\u0131 kaynaklar\u0131na ayn\u0131 anda eri\u015fmeye \u00e7al\u0131\u015fmas\u0131 durumunda kilitlenmeler (deadlocks) meydana gelebilir. Bir kilitlenme, iki veya daha fazla i\u015flemin birbirlerinin sahip oldu\u011fu kaynaklar\u0131 bekledi\u011fi ve sonsuz bir d\u00f6ng\u00fcye girdi\u011fi bir durumu ifade eder. Bu durum, hi\u00e7bir i\u015flemin ilerleyemedi\u011fi ve veritaban\u0131 sisteminin t\u0131kanmas\u0131na neden olabilece\u011fi anlam\u0131na gelir. Genellikle modern veritaban\u0131 sistemleri, kilitlenmeleri otomatik olarak alg\u0131lar ve bunlardan birini \"kurban\" se\u00e7erek sonland\u0131r\u0131r (rollback yapar), b\u00f6ylece di\u011fer i\u015flemlerin devam etmesini sa\u011flar. Ancak, bir i\u015flemin geri al\u0131nmas\u0131, uygulama taraf\u0131nda hataya ve tekrar deneme ihtiyac\u0131na neden olur, bu da kullan\u0131c\u0131 deneyimini olumsuz etkileyebilir.<\/p>\n En basit kilitlenme senaryosu, iki i\u015flem (Transaction A ve Transaction B) ve iki kaynak (Resource 1 ve Resource 2) aras\u0131nda ya\u015fan\u0131r. Ad\u0131m ad\u0131m inceleyelim:<\/p>\n \u0130\u015fte bu noktada kilitlenme olu\u015fmu\u015ftur. Transaction A, Transaction B'nin bitmesini beklerken, Transaction B de Transaction A'n\u0131n bitmesini beklemektedir. Her iki i\u015flem de di\u011ferinin serbest b\u0131rakmas\u0131n\u0131 bekledi\u011fi i\u00e7in sonsuza kadar bu durumda kalacakt\u0131r. Veritaban\u0131 y\u00f6netim sistemi (DBMS) bu durumu alg\u0131lar ve genellikle daha az maliyetli olan bir i\u015flemi \"deadlock victim\" olarak se\u00e7er ve onu geri al\u0131r. Bu, di\u011fer i\u015flemin ilerlemesine olanak tan\u0131r.<\/p>\n Ger\u00e7ek D\u00fcnya Vaka Analizi: Online Bankac\u0131l\u0131k<\/strong><\/p>\n Bir online bankac\u0131l\u0131k sisteminde, iki farkl\u0131 kullan\u0131c\u0131n\u0131n ayn\u0131 anda birbirine para transferi yapmaya \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 d\u00fc\u015f\u00fcnelim:<\/p>\n Olas\u0131 kilitlenme ad\u0131mlar\u0131:<\/p>\n Bu senaryo, tipik bir kilitlenme durumunu g\u00f6sterir. Her iki i\u015flem de birbirlerinin sahip oldu\u011fu kayna\u011f\u0131 bekledi\u011fi i\u00e7in ilerleyemezler. Veritaban\u0131 sistemi birini geri alarak bu d\u00f6ng\u00fcy\u00fc k\u0131rar. Bu durum, kullan\u0131c\u0131lardan birinin i\u015fleminin ba\u015far\u0131s\u0131z oldu\u011fu anlam\u0131na gelir ve tekrar denemesi gerekir.<\/p>\n Kilitlenmelerin tespiti ve analizi, performans\u0131 ve kullan\u0131c\u0131 deneyimini iyile\u015ftirmek i\u00e7in hayati \u00f6neme sahiptir. Veritaban\u0131 sistemleri genellikle kilitlenmeleri alg\u0131lad\u0131\u011f\u0131nda kendi hata g\u00fcnl\u00fcklerine (error logs) bilgi yazar. SQL Server gibi sistemlerde, \u00d6rne\u011fin, mevcut kilitlenmeleri ve bekleyen kaynaklar\u0131 g\u00f6rmek i\u00e7in a\u015fa\u011f\u0131daki gibi sorgular kullanabiliriz:<\/p>\n <\/code><\/p>\n Bu sorgular, hangi oturumlar\u0131n hangi kaynaklar\u0131 kilitledi\u011fini ve hangi oturumlar\u0131n kilitli kaynaklar \u00fczerinde bekledi\u011fini anlamam\u0131za yard\u0131mc\u0131 olur. Kilitlenme sorunlar\u0131n\u0131 gidermenin ilk ad\u0131m\u0131, bu sorunlar\u0131n nerede ve neden ortaya \u00e7\u0131kt\u0131\u011f\u0131n\u0131 do\u011fru bir \u015fekilde te\u015fhis etmektir. Bir sonraki b\u00f6l\u00fcmde, kilitlenmeleri \u00f6nlemek veya etkilerini azaltmak i\u00e7in uygulayabilece\u011fimiz stratejileri ke\u015ffedece\u011fiz.<\/p>\n Kilitlenmelerin veritaban\u0131 performans\u0131 ve uygulama g\u00fcvenilirli\u011fi \u00fczerindeki olumsuz etkilerini en aza indirmek i\u00e7in \u00e7e\u015fitli stratejiler mevcuttur. Bu stratejiler, hem veritaban\u0131 tasar\u0131m\u0131 hem de uygulama kodlamas\u0131 a\u015famas\u0131nda dikkate al\u0131nmal\u0131d\u0131r. Amac\u0131m\u0131z, kilitlenmeleri tamamen ortadan kald\u0131rmak m\u00fcmk\u00fcn olmasa bile, olu\u015fma s\u0131kl\u0131\u011f\u0131n\u0131 ve etkisini minimize etmektir.<\/p>\n Uzman \u0130pucu:<\/strong> Bir\u00e7ok veritaban\u0131, Kilitlenmeler tamamen \u00f6nlenemese de, meydana geldiklerinde uygulama taraf\u0131nda bunu ele alman\u0131n yollar\u0131 vard\u0131r. En yayg\u0131n stratejilerden biri, kilitlenme hatas\u0131 alan i\u015flemleri otomatik olarak yeniden denemektir. Veritaban\u0131, bir i\u015flemi kilitlenme kurban\u0131 se\u00e7ip geri ald\u0131\u011f\u0131nda, uygulamaya genellikle belirli bir hata kodu (\u00f6rne\u011fin, SQL Server'da 1205) d\u00f6nd\u00fcr\u00fcr. Uygulama bu hata kodunu yakalad\u0131\u011f\u0131nda, k\u0131sa bir bekleme s\u00fcresinden sonra i\u015flemi tekrar denemeli, ancak belirli bir say\u0131da deneme ba\u015far\u0131s\u0131z olursa kullan\u0131c\u0131ya hata mesaj\u0131 vermelidir.<\/p>\n Bu yeniden deneme mant\u0131\u011f\u0131, \u00f6zellikle yo\u011fun sistemlerde kullan\u0131c\u0131 deneyimini \u00f6nemli \u00f6l\u00e7\u00fcde iyile\u015ftirir \u00e7\u00fcnk\u00fc kullan\u0131c\u0131, k\u00fc\u00e7\u00fck, ge\u00e7ici bir kilitlenme nedeniyle i\u015fleminin hemen ba\u015far\u0131s\u0131z oldu\u011funu g\u00f6rmez. Yeniden denemeler aras\u0131nda hafif bir rastgele gecikme (exponential backoff) eklemek, ayn\u0131 anda tekrar kilitlenme ya\u015fama olas\u0131l\u0131\u011f\u0131n\u0131 azaltabilir.<\/p>\n <\/code><\/p>\n Bu uygulama taraf\u0131 yakla\u015f\u0131m\u0131, veritaban\u0131 katman\u0131ndaki kilitlenmeleri tamamen engellemese de, kullan\u0131c\u0131lar\u0131n bu durumdan en az etkilenmesini sa\u011flayarak sistemin genel kullan\u0131labilirli\u011fini ve performans\u0131n\u0131 art\u0131r\u0131r. Sonu\u00e7 olarak, kilitlenmelerle ba\u015fa \u00e7\u0131kmak, hem dikkatli veritaban\u0131 tasar\u0131m\u0131 hem de dayan\u0131kl\u0131 uygulama mimarisi gerektiren \u00e7ok y\u00f6nl\u00fc bir \u00e7abad\u0131r.<\/p>\n Veritaban\u0131 sistemlerinin temel hedeflerinden biri, herhangi bir felaket (sistem \u00e7\u00f6kmesi, elektrik kesintisi, donan\u0131m ar\u0131zas\u0131 vb.) durumunda bile veri b\u00fct\u00fcnl\u00fc\u011f\u00fcn\u00fc ve kal\u0131c\u0131l\u0131\u011f\u0131n\u0131 garanti etmektir. \u0130\u015fte bu noktada g\u00fcnl\u00fck tabanl\u0131 kurtarma (log-based recovery) mekanizmalar\u0131 devreye girer. Bu sistemler, veritaban\u0131nda yap\u0131lan her de\u011fi\u015fikli\u011fi (insert, update, delete) detayl\u0131 bir \u015fekilde bir i\u015flem g\u00fcnl\u00fc\u011f\u00fcne (transaction log) kaydeder. Bu kay\u0131tlar, veritaban\u0131 \u00e7\u00f6kse bile, sistemin son tutarl\u0131 durumuna geri d\u00f6nebilmesini sa\u011flar.<\/p>\n G\u00fcnl\u00fck tabanl\u0131 kurtarman\u0131n merkezinde, Write-Ahead Logging (WAL) prensibi yatar. WAL, herhangi bir veritaban\u0131 sayfas\u0131ndaki bir de\u011fi\u015fiklik diskteki ana veri dosyas\u0131na yaz\u0131lmadan \u00f6nce, bu de\u011fi\u015fikli\u011fin a\u00e7\u0131klamas\u0131n\u0131 i\u00e7eren g\u00fcnl\u00fck kayd\u0131n\u0131n (log record) diske yaz\u0131lmas\u0131n\u0131 zorunlu k\u0131lar. Bu prensip, veritaban\u0131 kurtarman\u0131n en \u00f6nemli garantisidir. E\u011fer sistem bir anda \u00e7\u00f6kerse ve baz\u0131 de\u011fi\u015fiklikler hen\u00fcz ana veri dosyas\u0131na yaz\u0131lmam\u0131\u015fsa, g\u00fcnl\u00fck dosyas\u0131 sayesinde bu de\u011fi\u015fiklikler yeniden uygulanabilir (REDO) veya k\u0131smen yap\u0131lm\u0131\u015f i\u015flemler geri al\u0131nabilir (UNDO).<\/p>\n Her bir g\u00fcnl\u00fck kayd\u0131 tipik olarak a\u015fa\u011f\u0131daki bilgileri i\u00e7erir:<\/p>\n Bu detayl\u0131 kay\u0131tlar sayesinde, veritaban\u0131 motoru herhangi bir anda veritaban\u0131n\u0131n hangi durumda oldu\u011funu tam olarak bilebilir ve gerekti\u011finde tutarl\u0131 bir duruma geri d\u00f6nebilir.<\/p>\n G\u00fcnl\u00fck dosyalar\u0131 s\u00fcrekli b\u00fcy\u00fcd\u00fc\u011f\u00fc i\u00e7in, veritaban\u0131 motoru belirli aral\u0131klarla \"checkpoint\" ad\u0131 verilen bir i\u015flem yapar. Bir checkpoint, o ana kadar bellekteki t\u00fcm kirli sayfalar\u0131 (yani diskteki versiyonundan farkl\u0131 olan sayfalar\u0131) diske yaz\u0131lmaya zorlar ve bu durumu g\u00fcnl\u00fck dosyas\u0131nda i\u015faretler. Checkpointler, kurtarma s\u00fcresini \u00f6nemli \u00f6l\u00e7\u00fcde k\u0131salt\u0131r \u00e7\u00fcnk\u00fc sistem \u00e7\u00f6kt\u00fc\u011f\u00fcnde, kurtarma i\u015flemi son checkpoint'ten ba\u015flamak zorunda kal\u0131r, g\u00fcnl\u00fck dosyas\u0131n\u0131n ba\u015f\u0131ndan de\u011fil. Bu, uzun s\u00fcreli bir kurtarma i\u015flemi yerine daha h\u0131zl\u0131 bir geri d\u00f6n\u00fc\u015f sa\u011flar.<\/p>\n Bir sistem \u00e7\u00f6kmesi sonras\u0131 veritaban\u0131 ba\u015flat\u0131ld\u0131\u011f\u0131nda, kurtarma s\u00fcreci genellikle \u00fc\u00e7 a\u015famadan olu\u015fur:<\/p>\n Bu s\u00fcre\u00e7, veritaban\u0131n\u0131n \u00e7\u00f6kme \u00f6ncesindeki tutarl\u0131 durumuna geri d\u00f6nmesini ve hi\u00e7bir onaylanm\u0131\u015f verinin kaybolmamas\u0131n\u0131 sa\u011flar. G\u00fcnl\u00fck tabanl\u0131 kurtarma, modern veritaban\u0131 sistemlerinin neden bu kadar g\u00fcvenilir oldu\u011funun temel nedenidir. Bu mekanizma olmasayd\u0131, her sistem \u00e7\u00f6kmesi potansiyel bir veri felaketi anlam\u0131na gelirdi. Bu g\u00fcnl\u00fck dosyalar\u0131 ayn\u0131 zamanda yedekleme ve felaket kurtarma stratejilerinde de merkezi bir rol oynar.<\/p>\n Veritaban\u0131 kurtarma modelleri, veritaban\u0131n\u0131z\u0131n yedeklenmesi ve bir felaket durumunda kurtar\u0131lmas\u0131 i\u00e7in nas\u0131l davranaca\u011f\u0131n\u0131 belirler. \u00d6zellikle SQL Server gibi sistemlerde, farkl\u0131 kurtarma modelleri, veri kayb\u0131 tolerans\u0131 ve yedekleme esnekli\u011fi a\u00e7\u0131s\u0131ndan farkl\u0131 se\u00e7enekler sunar. Do\u011fru kurtarma modelini se\u00e7mek, i\u015fletmenizin veri b\u00fct\u00fcnl\u00fc\u011f\u00fc gereksinimleri ve kurtarma zaman\u0131 hedefleri (RTO - Recovery Time Objective, RPO - Recovery Point Objective) ile do\u011frudan ili\u015fkilidir.<\/p>\n SQL Server \u00f6zelinde \u00fc\u00e7 ana kurtarma modeli bulunur:<\/p>\n Uzman \u0130pucu:<\/strong> Kurtarma modeli se\u00e7imi, uygulaman\u0131z\u0131n RPO (Recovery Point Objective - ne kadar veri kayb\u0131na dayanabilece\u011finiz) ve RTO (Recovery Time Objective - veritaban\u0131n\u0131 ne kadar s\u00fcrede \u00e7al\u0131\u015f\u0131r hale getirebilece\u011finiz) hedeflerine g\u00f6re yap\u0131lmal\u0131d\u0131r. Kritik i\u015f y\u00fckleri i\u00e7in genellikle FULL kurtarma modeli tercih edilir.<\/p>\n Kurtarma modelleriyle birlikte, etkili bir yedekleme stratejisi de olu\u015fturman\u0131z gerekir:<\/p>\n Bir felaket kurtarma senaryosunda, veritaban\u0131n\u0131 yeniden kurmak i\u00e7in \u00f6nce en son tam yedekten, ard\u0131ndan varsa en son diferansiyel yedekten ve son olarak da \u00e7\u00f6kme an\u0131na kadar olan t\u00fcm ard\u0131\u015f\u0131k i\u015flem g\u00fcnl\u00fc\u011f\u00fc yedeklerinden faydalan\u0131l\u0131r. \u0130\u015fte bir <\/code><\/p>\n Bu ad\u0131mlar, veritaban\u0131n\u0131z\u0131 felaketten kurtarman\u0131n temelini olu\u015fturur. D\u00fczenli test yedeklemeleri ve kurtarma senaryolar\u0131, bu s\u00fcrecin sorunsuz \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flamak i\u00e7in kritik \u00f6neme sahiptir. Veritaban\u0131 y\u00f6neticilerinin en \u00f6nemli sorumluluklar\u0131ndan biri, uygun kurtarma modelini se\u00e7mek ve belirlenen RPO\/RTO hedeflerini kar\u015f\u0131layacak sa\u011flam bir yedekleme ve kurtarma stratejisi uygulamakt\u0131r.<\/p>\n Bu makalede, SQL veritaban\u0131 d\u00fcnyas\u0131n\u0131n temel direklerinden olan i\u015flemler, kilitlenmeler ve g\u00fcnl\u00fck tabanl\u0131 kurtarma mekanizmalar\u0131n\u0131 detayl\u0131 bir \u015fekilde inceledik. G\u00f6rd\u00fc\u011f\u00fcm\u00fcz gibi, veritaban\u0131 i\u015flemleri, ACID \u00f6zellikleriyle veri b\u00fct\u00fcnl\u00fc\u011f\u00fcn\u00fcn ve tutarl\u0131l\u0131\u011f\u0131n\u0131n garant\u00f6r\u00fcd\u00fcr. Kilitlenmeler ise e\u015fzamanl\u0131l\u0131\u011f\u0131n ka\u00e7\u0131n\u0131lmaz bir yan etkisi olup, do\u011fru stratejilerle y\u00f6netilmesi gereken performans engelleridir. Son olarak, g\u00fcnl\u00fck tabanl\u0131 kurtarma ve farkl\u0131 kurtarma modelleri sayesinde, en k\u00f6t\u00fc senaryolarda bile veritaban\u0131 sistemlerimizin veriyi koruyabildi\u011fini ve i\u015fletmelerin h\u0131zl\u0131ca toparlanabildi\u011fini \u00f6\u011frendik. T\u00fcm bu kavramlar, sa\u011flam, g\u00fcvenilir ve y\u00fcksek performansl\u0131 veritaban\u0131 uygulamalar\u0131 geli\u015ftirmek ve y\u00f6netmek i\u00e7in temel bilgilerdir.<\/p>\n Veritaban\u0131 y\u00f6neticileri ve geli\u015ftiriciler olarak, bu mekanizmalar\u0131n derinlemesine anla\u015f\u0131lmas\u0131, sadece sorunlar\u0131 \u00e7\u00f6zmekle kalmaz, ayn\u0131 zamanda gelecekteki olas\u0131 sorunlar\u0131 \u00f6nceden tahmin etme ve daha dayan\u0131kl\u0131 sistemler tasarlama yetene\u011fimizi de art\u0131r\u0131r. Unutmay\u0131n, iyi bir veritaban\u0131 y\u00f6netimi, projenin ba\u015far\u0131s\u0131 i\u00e7in vazge\u00e7ilmezdir.<\/p>\n Modern web sitelerinin mobil cihazlarda da d\u00fczg\u00fcn g\u00f6r\u00fcnmesi hayati \u00f6neme sahiptir. A\u015fa\u011f\u0131daki CSS kodu \u00f6rne\u011fi, bir sayfan\u0131n d\u00fczeninin farkl\u0131 ekran boyutlar\u0131na nas\u0131l uyarlanabilece\u011fini g\u00f6stermektedir. Bu makalenin i\u00e7eri\u011fi de bu prensiplere uygun olarak tasarlanm\u0131\u015ft\u0131r.<\/p>\nBEGIN TRANSACTION<\/code> komutunu kullan\u0131r\u0131z. \u0130\u015flem ba\u015far\u0131l\u0131 oldu\u011funda COMMIT<\/code> ile de\u011fi\u015fiklikleri kal\u0131c\u0131 hale getiririz. E\u011fer bir hata olu\u015fursa veya i\u015flem geri al\u0131nmak istenirse, ROLLBACK<\/code> komutu ile t\u00fcm de\u011fi\u015fiklikler iptal edilir ve veritaban\u0131 i\u015flemin ba\u015flang\u0131\u00e7taki durumuna d\u00f6ner.<\/p>\n\nBEGIN TRANSACTION;\nDECLARE @urunID INT = 123;\nDECLARE @musteriID INT = 456;\nDECLARE @miktar DECIMAL(10, 2) = 50.00;\n\n-- 1. \u00dcr\u00fcn sto\u011funu azalt\nUPDATE Urunler\nSET StokAdedi = StokAdedi - 1\nWHERE UrunID = @urunID AND StokAdedi > 0;\n\nIF @@ROWCOUNT = 0\nBEGIN\n -- Stok yetersizse i\u015flemi geri al\n ROLLBACK TRANSACTION;\n PRINT 'Stok Yetersiz! \u0130\u015flem Geri Al\u0131nd\u0131.';\n RETURN;\nEND\n\n-- 2. M\u00fc\u015fteri bakiyesinden paray\u0131 \u00e7ek\nUPDATE MusteriBakiyeleri\nSET Bakiye = Bakiye - @miktar\nWHERE MusteriID = @musteriID AND Bakiye >= @miktar;\n\nIF @@ROWCOUNT = 0\nBEGIN\n -- Bakiye yetersizse i\u015flemi geri al\n ROLLBACK TRANSACTION;\n PRINT 'Bakiye Yetersiz! \u0130\u015flem Geri Al\u0131nd\u0131.';\n RETURN;\nEND\n\n-- Her \u015fey yolundaysa i\u015flemi kal\u0131c\u0131 hale getir\nCOMMIT TRANSACTION;\nPRINT 'Sat\u0131\u015f \u0130\u015flemi Ba\u015far\u0131l\u0131!';\n\n<\/pre>\nSQL'de Kilitlenmeler (Deadlocks) Nas\u0131l Ortaya \u00c7\u0131kar ve Nas\u0131l Tespit Edilir?<\/h2>\n
Bir Kilitlenme Senaryosu Nas\u0131l Geli\u015fir?<\/h3>\n
\n
\n
\n
Kilitlenmeleri Nas\u0131l Tespit Ederiz?<\/h3>\n
sp_who2<\/code>, sys.dm_tran_locks<\/code> veya sys.dm_os_waiting_tasks<\/code> gibi dinamik y\u00f6netim g\u00f6r\u00fcn\u00fcmleri (DMV'ler) kullanarak mevcut kilitleri ve bekleyen g\u00f6revleri inceleyebiliriz. Ayr\u0131ca, SQL Server Profiler veya Extended Events gibi ara\u00e7lar, kilitlenme olaylar\u0131n\u0131 ger\u00e7ek zamanl\u0131 olarak izlemek ve detayl\u0131 kilitlenme grafikleri olu\u015fturmak i\u00e7in kullan\u0131labilir.<\/p>\n\n-- Mevcut kilitleri g\u00f6sterir\nSELECT\n request_session_id,\n resource_type,\n resource_database_id,\n resource_associated_entity_id,\n request_mode,\n request_status,\n request_owner_type,\n resource_description\nFROM\n sys.dm_tran_locks\nWHERE\n request_status = 'WAIT';\n\n-- Hangi SPID'lerin hangi kilitlerde bekledi\u011fini g\u00f6sterir (SQL Server \u00f6rne\u011fi)\nSELECT\n t1.resource_type,\n t1.resource_database_id,\n t1.resource_associated_entity_id,\n t1.request_mode,\n t1.request_session_id,\n t2.blocking_session_id,\n t2.wait_type,\n t2.wait_duration_ms\nFROM\n sys.dm_tran_locks as t1\nINNER JOIN sys.dm_os_waiting_tasks as t2\n ON t1.request_session_id = t2.session_id;\n\n<\/pre>\nKilitlenmelerle Ba\u015fa \u00c7\u0131kma Stratejileri: Performans ve G\u00fcvenilirlik \u0130\u00e7in Ne Yapmal\u0131y\u0131z?<\/h2>\n
Kilitlenmeleri \u00d6nleme ve Azaltma Y\u00f6ntemleri Nelerdir?<\/h3>\n
\n
READ COMMITTED<\/code> \u00e7o\u011fu durum i\u00e7in iyi bir dengedir.<\/li>\nWITH (NOLOCK)<\/code> veya READ UNCOMMITTED<\/code> izolasyon seviyesi gibi se\u00e7enekler sunar. Bunlar, okuma i\u015flemlerinin kilitleri atlamas\u0131n\u0131 ve kilitlenme riskini azaltmas\u0131n\u0131 sa\u011flayabilir. Ancak, bu se\u00e7enekler \"kirli okumalara\" (uncommitted data reading) yol a\u00e7abilece\u011finden, yaln\u0131zca veri tutarl\u0131l\u0131\u011f\u0131n\u0131n en kritik olmad\u0131\u011f\u0131 durumlarda dikkatli kullan\u0131lmal\u0131d\u0131r.<\/p>\nUygulama Katman\u0131nda Yeniden Deneme (Retry Logic) Mant\u0131\u011f\u0131 Nas\u0131l Uygulan\u0131r?<\/h3>\n
\n\/\/ C# \u00f6rne\u011fi (pseudocode)\npublic void TransferPara(int kaynakHesapId, int hedefHesapId, decimal miktar)\n{\n int denemeSayisi = 0;\n int maxDeneme = 5;\n bool basarili = false;\n\n while (denemeSayisi < maxDeneme && !basarili)\n {\n try\n {\n using (var connection = new SqlConnection(connectionString))\n {\n connection.Open();\n using (var transaction = connection.BeginTransaction())\n {\n \/\/ SQL Komutlar\u0131: Kaynak hesaptan d\u00fc\u015f, hedef hesaba ekle\n \/\/ \u00d6rne\u011fin:\n \/\/ new SqlCommand(\"UPDATE Hesaplar SET Bakiye = Bakiye - @miktar WHERE HesapID = @kaynakHesapId\", connection, transaction).ExecuteNonQuery();\n \/\/ new SqlCommand(\"UPDATE Hesaplar SET Bakiye = Bakiye + @miktar WHERE HesapID = @hedefHesapId\", connection, transaction).ExecuteNonQuery();\n\n transaction.Commit();\n basarili = true;\n Console.WriteLine(\"\u0130\u015flem ba\u015far\u0131yla tamamland\u0131.\");\n }\n }\n }\n catch (SqlException ex)\n {\n \/\/ Kilitlenme hatas\u0131 (SQL Server'da 1205)\n if (ex.Number == 1205)\n {\n denemeSayisi++;\n Console.WriteLine($\"Kilitlenme tespit edildi, yeniden deniyor... ({denemeSayisi}\/{maxDeneme})\");\n \/\/ Rastgele bir s\u00fcre bekle (exponential backoff)\n Thread.Sleep(TimeSpan.FromMilliseconds(50 * Math.Pow(2, denemeSayisi)));\n }\n else\n {\n Console.WriteLine($\"Bir hata olu\u015ftu: {ex.Message}\");\n throw; \/\/ Di\u011fer hatalar\u0131 yeniden f\u0131rlat\n }\n }\n }\n\n if (!basarili)\n {\n Console.WriteLine(\"\u0130\u015flem defalarca ba\u015far\u0131s\u0131z oldu, l\u00fctfen daha sonra tekrar deneyin.\");\n }\n}\n<\/pre>\nG\u00fcnl\u00fck Tabanl\u0131 Kurtarma (Log-Based Recovery) Nedir ve Veri B\u00fct\u00fcnl\u00fc\u011f\u00fcn\u00fc Nas\u0131l Sa\u011flar?<\/h2>\n
Write-Ahead Logging (WAL) Prensibi Nedir?<\/h3>\n
\n
Checkpoints ve Kurtarma S\u00fcreci: REDO ve UNDO \u0130\u015flemleri<\/h3>\n
\n
Veritaban\u0131 Kurtarma Modelleri: \u0130htiya\u00e7lar\u0131n\u0131za En Uygun Se\u00e7im Nas\u0131l Yap\u0131l\u0131r?<\/h2>\n
FULL, SIMPLE ve BULK_LOGGED Kurtarma Modelleri Aras\u0131ndaki Farklar<\/h3>\n
\n
\n
\n
\n
BULK INSERT<\/code>, SELECT INTO<\/code>, indeks yeniden olu\u015fturma) i\u00e7in g\u00fcnl\u00fck kayd\u0131n\u0131 minimuma indirir (minimally logged).<\/li>\nYedekleme Stratejileri ve Felaket Kurtarma Senaryolar\u0131<\/h3>\n
\n
RESTORE DATABASE<\/code> komutu \u00f6rne\u011fi:<\/p>\n\n-- Tam yede\u011fi geri y\u00fckle (NO_RECOVERY ile, \u00e7\u00fcnk\u00fc daha fazla g\u00fcnl\u00fck uygulanacak)\nRESTORE DATABASE YourDatabaseName\nFROM DISK = 'C:\\Backup\\YourDatabaseName_Full.bak'\nWITH NORECOVERY, REPLACE;\n\n-- Diferansiyel yede\u011fi geri y\u00fckle (e\u011fer varsa, yine NO_RECOVERY ile)\n-- RESTORE DATABASE YourDatabaseName\n-- FROM DISK = 'C:\\Backup\\YourDatabaseName_Diff.bak'\n-- WITH NORECOVERY;\n\n-- \u0130\u015flem g\u00fcnl\u00fc\u011f\u00fc yedeklerini s\u0131rayla uygula\nRESTORE LOG YourDatabaseName\nFROM DISK = 'C:\\Backup\\YourDatabaseName_Log1.trn'\nWITH NORECOVERY;\n\nRESTORE LOG YourDatabaseName\nFROM DISK = 'C:\\Backup\\YourDatabaseName_Log2.trn'\nWITH NORECOVERY;\n\n-- Son i\u015flem g\u00fcnl\u00fc\u011f\u00fc yede\u011fini ve kurtarma i\u015flemini tamamla\n-- (Burada TO_DATE veya STOPAT se\u00e7enekleri ile nokta kurtarma yap\u0131labilir)\nRESTORE LOG YourDatabaseName\nFROM DISK = 'C:\\Backup\\YourDatabaseName_Log_Last.trn'\nWITH RECOVERY; -- Bu, veritaban\u0131n\u0131 online hale getirir\n\n<\/pre>\nSonu\u00e7 ve S\u0131k\u00e7a Sorulan Sorular<\/h2>\n
S\u0131k\u00e7a Sorulan Sorular<\/h3>\n
\n
READ COMMITTED<\/code> izolasyon seviyesi, okunmam\u0131\u015f verilerin okunmas\u0131n\u0131 engeller ve di\u011fer i\u015flemlerin commit edilmemi\u015f de\u011fi\u015fikliklerini g\u00f6rmemeyi sa\u011flar. Ancak, \u00f6zellikle yazma kilitleriyle ilgili olan kilitlenmeleri do\u011frudan \u00f6nlemez. Kilitlenmeleri azaltmak i\u00e7in di\u011fer stratejiler (i\u015flem s\u00fcrelerini k\u0131saltma, kaynaklara s\u0131ral\u0131 eri\u015fim vb.) gereklidir.<\/dd>\nSqlException<\/code> s\u0131n\u0131f\u0131n\u0131n Number<\/code> \u00f6zelli\u011fini kontrol ederek kilitlenme hata kodu olan 1205'i yakalayabilirsiniz. Di\u011fer veritabanlar\u0131 i\u00e7in ilgili d\u00f6k\u00fcmanlar\u0131 inceleyerek kendi spesifik kilitlenme hata kodlar\u0131n\u0131 bulman\u0131z gerekir. Hata yakaland\u0131\u011f\u0131nda, i\u015flemi geri al\u0131p (rollback) uygun bir gecikmeyle yeniden deneme mekanizmas\u0131 uygulamak en iyi yakla\u015f\u0131md\u0131r.<\/dd>\n<\/dl>\nMobil Uyumlu HTML i\u00e7in \u00d6rnek Media Query<\/h3>\n
\n