18 Nis 2025·8 dk
Jim Gray, İşlem İşleme ve Neden ACID Hâlâ Önemli
Jim Gray’in işlem işleme fikirlerine pratik bir bakış: ACID ilkelerinin bankacılık, e-ticaret ve SaaS sistemlerinde güvenilirliği nasıl sağladığını anlatır.
Jim Gray’in işlem işleme fikirlerine pratik bir bakış: ACID ilkelerinin bankacılık, e-ticaret ve SaaS sistemlerinde güvenilirliği nasıl sağladığını anlatır.
Jim Gray, basit ama yanıltıcı derecede derin bir soruyla takıntılı olan bir bilgisayar bilimcisiydi: çok kişi aynı anda bir sistemi kullandığında — ve hatalar kaçınılmaz olduğunda — sonuçları nasıl doğru tutarsınız?
İşlem işleme üzerine yaptığı çalışmalar, veritabanlarını “şanslıysanız bazen doğru” olmaktan, gerçekten bir işe dayanacak altyapıya dönüştürmeye yardımcı oldu. Özellikle ACID ilkeleri, ürün toplantısında hiç "işlem" kelimesini duymamış olsanız bile her yerde karşınıza çıkar.
Güvenilir bir sistem, kullanıcıların yalnızca ekranlara değil sonuçlara güvenebildiği sistemdir.
Başka bir deyişle: doğru bakiyeler, doğru siparişler ve eksik kayıt yok.
Kuyruklar, mikroservisler ve üçüncü taraf ödemeler olsa bile modern ürünler yine kritik anlarda işlem düşüncesine dayanır.
Kavramları pratik tutacağız: ACID’in neyi koruduğu, hataların nerede gizlendiği (izolasyon ve eşzamanlılık), ve günlükler ile kurtarmanın hataları nasıl yaşanılabilir kıldığı.
Ayrıca modern ödünleri ele alacağız—ACID sınırlarını nerede çizmelisiniz, dağıtık işlemler ne zaman gerekli, ve saga, retry ile idempotentlik gibi desenlerin gereksiz aşırı mühendislik yapmadan ne zaman “yeterince iyi” tutarlık sağladığı.
Bir işlem, çok adımlı bir iş eylemini tek bir "evet/hayır" birimi gibi ele almanın yoludur. Her şey başarılıysa commit edilir. Bir şey ters giderse sanki hiç olmamış gibi geri alınır.
Checking hesabından Savings hesabına 50$ taşımayı düşünün. Bu tek değişiklik değildir; en az iki adımı vardır:
Sisteminiz sadece "tek adımlı güncellemeler" yapıyorsa, parayı eksiltip sonra yatırma adımı başarısız olabilir. Müşteri 50$ eksik kalır—ve destek talepleri başlar.
Tipik bir checkout sipariş oluşturma, stok ayırma, ödeme yetkilendirme ve makbuz kaydetmeyi içerir. Her adım farklı tabloları (veya farklı servisleri) etkiler. İşlem düşüncesi yoksa, "ödenmiş" işaretli bir sipariş ama ayrılmamış stok ya da hiç oluşturulmamış bir sipariş için rezerve edilmiş stok gibi durumlar oluşabilir.
Hatalar nadiren uygun anlarda olur. Yaygın kırılma noktaları:
İşlem işleme şu basit sözü garanti etmek için vardır: iş eyleminin tüm adımları birlikte etkili olur veya hiçbiri olmaz. Bu söz, para taşırken, sipariş verirken veya abonelik planı değiştirirken güvenin temelidir.
ACID, "bir işlem"i güvenilir hissettiren korumaların bir kontrol listesidir. Pazarlama terimi değildir; önemli veriler değiştirildiğinde neler olacağına dair bir dizi vaadedir.
Atomiklik, bir işlemin ya tamamen tamamlanması ya da hiçbir iz bırakmaması anlamına gelir.
Bir banka transferini düşünün: Hesap A'dan 100$ düşülür, Hesap B'ye 100$ eklenir. Sistem debit yaptıktan sonra çökse atomiklik tüm transferin geri alınmasını (veya tamamen tamamlanmasını) sağlar. Sadece bir tarafın gerçekleştiği geçerli bir son durum yoktur.
Tutarlılık, verinizin kurallarının (kısıtlar ve invariantlar) her commit sonrası doğru kalması demektir.
Örnekler: ürününüz overdraft (eksi bakiye) yasaklıysa bakiye negatife düşemez; bir transfer için debit ve credit toplamlarının eşleşmesi gerekir; bir sipariş toplamı satır kalemleri ve vergiyi eşitlemelidir. Tutarlılık kısmen veritabanı işi (kısıtlar), kısmen uygulama işi (iş kuralları)dır.
İzolasyon, aynı anda birden çok işlem olduğunda sizi korur.
Örnek: iki müşteri bir öğenin son birimini almaya çalışır. Uygun izolasyon olmazsa her iki checkout da "1 kaldı" görüp ikisi de başarılı olabilir ve stok -1 olabilir veya elle düzeltilmesi gerekir.
Kalıcılık, "commit"i gördüğünüzde sonucun çökme veya güç kaybından sonra yok olmayacağını garanti eder. Makbuz transferin başarılı olduğunu söylüyorsa, defter yeniden başlattıktan sonra da bunu göstermelidir.
"ACID" tek bir açma/kapama düğmesi değildir. Farklı sistemler ve izolasyon seviyeleri farklı garantiler sağlar; hangi operasyonlara hangi korumaların uygulanacağını siz seçersiniz.
İşlem dediğinizde bankacılık en açık örnektir: kullanıcılar bakiyelerin her zaman doğru olmasını bekler. Bir bankacılık uygulaması biraz yavaş olabilir; yanlış olamaz. Bir yanlış bakiye overdraft ücretleri, kaçırılmış ödemeler ve uzun manuel düzeltiler zinciri başlatır.
Basit bir banka transferi aslında başarılması gereken birkaç adımdır:
ACID düşüncesi bunu tek bir birim olarak ele alır. Herhangi bir adım başarısızsa—ağ problemi, servis çökmesi, doğrulama hatası—sistem kısmi başarıya izin vermemelidir. Aksi halde A hesabından para eksik ama B'de görünmüyor veya B'de para var ama eşleşen debit yok ya da ne olduğunu açıklayan bir denetim izi yok.
Birçok üründe küçük bir tutarsızlık sonraki sürümde yamalanabilir. Bankacılıkta "sonra düzeltme" itirazlara, düzenleyici risklere ve manuel operasyonlara dönüşür. Destek talepleri tırmanır, mühendisler olay çağrılarına çekilir ve ekipler uyumsuz kayıtları düzeltmek için saatler harcar.
Sayıları düzeltseniz bile geçmişi açıklamanız gerekir.
Bankaların neden defterlere ve ekleme-yalnızca kayıtlara güvendiği bundandır: geçmişi üzerine yazmak yerine debit ve credit dizisini kaydederler. Değişmez günlükler ve net denetim izleri kurtarmayı ve incelemeyi mümkün kılar.
Mutabakat—bağımsız doğruların karşılaştırılması—bir şey ters gidince nerede ve ne zaman sapma olduğunu bulmak için geriye dönük bir emniyet ağıdır.
Doğruluk güven kazandırır. Ayrıca destek hacmini azaltır ve çözümü hızlandırır: bir problem olduğunda temiz bir denetim izi ve tutarlı defter kayıtları "ne oldu?" sorusuna hızlı yanıt verir ve tahmine gerek kalmadan düzeltme yapmayı sağlar.
E-ticaret basit görünür ta ki zirve trafiğe ulaşana kadar: aynı son ürün on sepette, müşteriler sayfayı yeniliyor ve ödeme sağlayıcı zaman aşımına uğruyor. İşte Jim Gray’in işlem işleme zihniyeti, pratik ve sıkıcı şekillerde ortaya çıkar.
Tipik bir checkout birden çok durumu etkiler: stok ayırma, siparişi oluşturma ve ödemeyi tahsil etme. Yüksek eşzamanlılık altında, her adım kendi başına doğru olsa bile kötü bir genel sonuç oluşturabilir.
Stoku izolasyon olmadan azaltırsanız, iki checkout "1 kaldı" okuyup her ikisi de başarılı olabilir—aşırı satış başlar. Ödemeyi alıp sonra sipariş oluşturamazsanız, müşteriyi teslimat için ücretlendirip yerine koyacak bir şeyiniz olmaz.
ACID en çok veritabanı sınırında işe yarar: sipariş oluşturma ve stok ayırmayı tek bir veritabanı işlemi içinde sarmalayın ki ya ikisi commit olsun ya da ikisi rollback olsun. Ayrıca kısıtlarla doğruluğu zorlayabilirsiniz (örneğin, "stok sıfırın altına inemez") böylece uygulama kodu yanlış davransa bile veritabanı imkansız durumları reddeder.
Ağlar yanıtları kaybeder, kullanıcı çift tıklar ve arka plan işleri yeniden dener. Bu yüzden sistemler arasında "tam olarak bir kez" işleme zor iş olur. Hedef genelde: para hareketinde en fazla bir kez, ve diğer her yerde güvenli yeniden denemelerdir.
Ödeme sağlayıcınızla idempotency anahtarları kullanın ve siparişinize bağlı kalıcı bir "ödeme niyeti" kaydedin. Servisiniz yeniden denese bile çifte ücretlendirme olmaz.
İadeler, kısmi geri ödemeler ve chargeback'ler iş gerçeğidir, köşe olguları değil. Net işlem sınırları bunları kolaylaştırır: her düzeltmeyi bir siparişe, bir ödemeye ve bir denetim izine güvenilir şekilde bağlayabilirsiniz—böylece bir şey ters gittiğinde mutabakat açıklanabilir.
SaaS işletmeleri bir vaatte yaşar: müşteri ödediği şeyi hemen ve öngörülebilir şekilde kullanabilmelidir. Bu, plan yükseltmeleri, düşürmeler, dönem içi proration, iadeler ve asenkron ödeme olaylarını karıştırana kadar basittir. ACID tarzı düşünce, "faturalama gerçeği" ile "ürün gerçeğini" uyumlu tutmaya yardımcı olur.
Plan değişikliği genellikle bir dizi eylemi tetikler: fatura oluşturma/ayarlama, proration kaydı, ödeme denemesi ve yetkilendirmeyi güncelleme. Bunları kısmi başarının kabul edilemez olduğu tek bir iş birimi olarak ele alın.
Eğer yükseltme faturası oluşturulur ama yetkilendirmeler güncellenmezse (veya tersi), müşteriler ya ödedikleri halde erişimi kaybeder ya da erişim almalarına rağmen ücretlendirilmezler.
Pratik bir desen, faturalama kararını (yeni plan, yürürlük tarihi, proration satırları) ve yetkilendirme kararını birlikte kalıcı hale getirmek, sonra downstream süreçleri bu commit edilmiş kayıttan çalıştırmaktır. Ödeme onayı sonra gelirse, tarihçeyi yeniden yazmadan güvenle ilerleyebilirsiniz.
Çok kiracılı sistemlerde izolasyon akademik değildir: bir müşterinin yoğun aktivitesi başka bir müşteriyi engellememeli veya bozmemelidir. Tenant-açık anahtarlar kullanın, her tenant için net işlem sınırları belirleyin ve dikkatle seçilmiş izolasyon seviyeleri ile Tenant A'daki yenileme patlaması Tenant B için tutarsız okumalara yol açmasın.
Destek talepleri genelde "Neden bana ücret kesildi?" veya "Neden X'e erişemiyorum?" ile başlar. Kim neyi ne zaman (kullanıcı, admin, otomasyon) değiştirdiğinin append-only bir denetim günlüğünü tutun ve bunu faturalar ile yetkilendirme geçişlerine bağlayın.
Bu sessiz sürüklenmeyi—faturalar "Pro" derken yetkilendirmeler hala "Basic" göstermesi gibi—önler ve mutabakatı bir sorgu haline getirir, soruşturma değil.
İzolasyon ACID'in "I"sidir ve sistemlerin genellikle ince, maliyetli şekillerde başarısız olduğu yerdir. Temel fikir basittir: birçok kullanıcı aynı anda hareket eder, ancak her işlem tek başına çalışmış gibi davranmalıdır.
Bir mağaza hayal edin: iki kasiyer ve rafta son bir ürün. Eğer her iki kasiyer aynı anda stoğu kontrol edip "1 mevcut" görürse, ikisi de satabilir. Hiçbir şey "çökmedi" ama sonuç yanlıştır—çifte satış gibi.
Veritabanları da aynı sorunu yaşar; iki işlem aynı satırı eşzamanlı okuyup güncellemek istediğinde.
Çoğu sistem güvenlik ile verim arasında bir izolasyon seviyesi seçer:
Bir hata finansal kayıp, yasal maruz kalma veya müşteri görünür tutarsızlık yaratıyorsa daha güçlü izolasyona (veya açık kilitlemeye/kısıtlamalara) eğilin. En kötü durum geçici bir UI hatasıysa daha zayıf seviye kabul edilebilir.
Daha yüksek izolasyon, veritabanının daha fazla koordinasyon yapmasını gerektirdiği için verimi düşürebilir—bekleme, kilitleme veya işlem abort/yeniden deneme gibi. Maliyet gerçek, ama yanlış veri maliyeti de öyledir.
Bir sistem çöktüğünde en önemli soru "neden çöktü?" değil, "yeniden başlatmadan sonra hangi durumda olmalıyız?" olmalıdır. Jim Gray'in işlem işleme çalışmaları bu sorunun pratik yanıtını verdi: kalıcılık disiplinli günlükleme ve kurtarma ile sağlanır.
İşlem günlüğü (genellikle WAL olarak anılır) değişikliklerin ekleme-yalnızca kaydıdır. Kurtarmada kritiktir çünkü veritabanı dosyaları yazılırken güç kesilmiş olsa bile niyeti ve güncelleme sırasını korur.
Yeniden başlatma sırasında veritabanı şunları yapabilir:
Bu yüzden "commit ettik" demek, sunucu temiz kapanmamış olsa bile doğru kalmaya devam edebilir.
Write-ahead logging demek: veri sayfaları yazılmadan önce log kalıcı depolamaya flush edilir. Pratikte, "commit", ilgili log kayıtlarının güvenli şekilde diske (veya başka dayanıklı bir yere) yazıldığından emin olmakla bağlıdır.
Çökme tam commit sonrası olursa, kurtarma logu yeniden oynatıp commit edilmiş durumu yeniden kurar. Çökme commit öncesiyse log yarıda kalan işlemleri geri almaya yardımcı olur.
Yedek bir anlık görüntüdür. Loglar ise bir geçmiştir. Yedekler felaket kurtarma (hatalı deploy, silinmiş tablo, fidye yazılımı) için gereklidir. Loglar ise son commit edilmiş işleri kurtarmanızı ve point-in-time recovery sağlamanızı sağlar: yedeği geri yükleyin, sonra logları istenen ana kadar oynatın.
Hiç geri yüklemediğiniz bir yedek umut, plan değil. Düzenli geri yükleme tatbikatları planlayın, veri bütünlüğünü doğrulayın ve kurtarma süresinin gerçekte ne kadar sürdüğünü ölçün. Eğer RTO/RPO ihtiyaçlarını karşılamıyorsa, saklama, log gönderimi veya yedek sıklığını olay olmadan önce ayarlayın.
ACID en iyi tek bir veritabanının "gerçek kaynağı" olarak hareket edebildiği durumda çalışır. Bir iş eylemini birden çok servise (ödeme, stok, e-posta, analiz) yaydığınız anda dağıtık sistemler sahasına girersiniz—burada hatalar temiz "başarılı" veya "hata" gibi görünmez.
Dağıtık kurulumda kısmi hataları kabul etmelisiniz: bir servis commit ederken başka bir servis çökeltebilir, veya ağ gecikmesi gerçek sonucu gizleyebilir. Zaman aşımı belirsizliği—karşı taraf mı başarısız oldu yoksa sadece yavaş mı—çifte ücretlendirme, aşırı satış ve eksik yetkilendirmelerin doğduğu yerdir.
2PC birden çok veritabanının "bir" gibi commit etmesini sağlamaya çalışır.
Ekipler genellikle 2PC'den kaçınır çünkü yavaştır, kilitleri daha uzun süre tutar (verimi düşürür) ve koordinatör bir darboğaz olabilir. Ayrıca sistemleri sıkıca bağlar: tüm katılımcıların protokolü konuşması ve yüksek erişilebilir olması gerekir.
Yaygın yaklaşım, ACID sınırlarını küçük tutmak ve servisler arası işi açıkça yönetmektir:
En güçlü garantileri (ACID) mümkün olduğunca tek bir veritabanı içinde tutun ve bu sınırın ötesindeki her şeyi yeniden denemeler, mutabakat ve "bu adım başarısız olursa ne olur?" davranışıyla koordine edin.
Hatalar nadiren "hiç olmadı" şeklinde görünür. Daha sık olan: bir istek kısmen başarılı olur, istemci zaman aşımına uğrar ve birisi (tarayıcı, mobil uygulama, job runner veya partner sistem) yeniden dener.
Koruma yoksa, yeniden denemeler en kötü türden hatayı yaratır: doğru görünen kod ara sıra çifte ücret, çift gönderim veya çift erişim verir.
Idempotentlik, aynı işlemi birden çok kez yapmak, tek kez yapmakla aynı sonuca yol açması özelliğidir. Kullanıcıya dönük sistemlerde bu "çift denemelere karşı güvenli" olmak demektir.
Yararlı kural: GET doğal olarak idempotent olmalı; birçok POST eylemi tasarlanmadıkça idempotent değildir.
Genelde birkaç mekanizmanın birleşimini kullanırsınız:
Idempotency-Key: ...). Sunucu sonucu bu anahtarla saklar ve tekrarlarda aynı sonucu döner.order_id başına bir ödeme).Bunlar, benzersiz kontrolü ve etkinin aynı veritabanı işleminde yaşadığında en iyi çalışır.
Bir zaman aşımı, işlemin rollback olduğu anlamına gelmez; commit edilmiş olabilir ama yanıt kaybolmuştur. Bu yüzden retry mantığı sunucunun başarılı olabileceğini varsaymalıdır.
Yaygın desen: önce bir idempotency kaydı yazın (veya kilit uygulayın), yan etkileri gerçekleştirin, sonra tamamlandı olarak işaretleyin—mümkünse hepsini bir işlem içinde. Her şeyi tek bir işlem içinde sığdıramıyorsanız (örneğin, bir ödeme ağ geçidine çağrı), kalıcı bir "niyet" kaydedin ve sonrasında mutabakat yapın.
Sistemler "güvenilmez" hissettiğinde, kök neden genellikle bozuk işlem düşüncesidir. Tipik belirtiler: karşılık gelen ödeme olmayan hayalet siparişler, eşzamanlı checkout'lardan sonra negatif stok ve defter, faturalar ve analizler arasında uyuşmayan toplamlar.
Önce invariantlarınızı yazın—her zaman doğru olması gerekenler. Örnekler: "stok asla sıfırın altına düşmez", "bir sipariş ya ödenmemiştir ya da ödenmiştir (ikisi değil)", "her bakiye değişikliğinin eşleşen bir defter kaydı vardır."
Sonra bu invariantları koruyacak en küçük atomik işlem sınırlarını tanımlayın. Tek bir kullanıcı eylemi birden çok satırı/tabloyu etkiliyorsa, nelerin birlikte commit edilmesi gerektiğine ve nelerin güvenle ertelenebileceğine karar verin.
Son olarak, yük altında çatışmaları nasıl idare edeceğinizi seçin:
Eşzamanlılık hataları mutlu yol testlerinde nadiren görünür. Baskı yaratan testler ekleyin:
Koruyamadığınız şeyi ölçemezsiniz. Yararlı sinyaller: deadlock sayısı, kilit bekleme süreleri, rollback oranları (özellikle deploylardan sonra ani artışlar) ve kaynak-of-truth tabloları arasındaki mutabakat farkları (defter vs bakiyeler, siparişler vs ödemeler). Bu metrikler genelde müşterilerin "para/ürün eksik" demesinden haftalar önce sizi uyarır.
Jim Gray’in kalıcı katkısı sadece bir özellikler kümesi değil—"ne yanlış gitmemeli" için ortak bir sözlüktü. Ekipler ihtiyaç duydukları garantiyi (atomiklik, tutarlılık, izolasyon, kalıcılık) adlandırabildiğinde, doğrulukla ilgili tartışmalar belirsiz "güvenilir olmalı" ifadelerinden eyleme geçirilebilir maddelere dönüşür ("bu güncelleme şu ücretle atomik olmalı").
Tam işlemleri kullanın; bir kullanıcının tek, kesin bir sonuç bekleyeceği ve hatanın maliyetli olacağı durumlarda:
Burada garantileri zayıflatıp verimi iyileştirmek genelde maliyeti destek biletlere, manuel mutabakata ve kaybedilen güvene kaydırır.
Geçici tutarsızlığın kabul edilebilir ve kolayca iyileştirilebilir olduğu yerlerde gevşetin:
Püf nokta: "gerçek kaynağın" etrafında net bir ACID sınırı tutmak ve her şeyi onun arkasında geciktirmektir.
Özellikle bu akışları prototipliyorsanız veya eski bir hattı yeniden inşa ediyorsanız, işlemleri ve kısıtları birinci sınıf yapan bir yığını tercih etmek işe yarar. Örneğin, Koder.ai basit bir sohbete dayalı olarak bir React ön yüz ve Go + PostgreSQL arka uç üretebilir; bu, idempotency kayıtları, outbox tabloları ve rollback-güvenli iş akışları dahil olmak üzere gerçek işlem sınırlarını erken kurmak için pratik bir yoldur.
Eğer daha fazla desen ve kontrol listesi isterseniz, bu beklentileri /blog üzerinden bağlayın. Eğer katmanlara göre güvenilirlik beklentileri sunuyorsanız, müşterilerin hangi doğruluk garantilerini aldığını bilmesi için bunları /pricing üzerinde açıkça belirtin.
Jim Gray, işlem işleme konusunu pratik ve anlaşılır hale getiren bir bilgisayar bilimcisiydi. Mirası, para transferi, ödeme süreci, abonelik değişiklikleri gibi çok adımlı önemli eylemlerin eşzamanlılık ve hatalar altında doğru sonuçlar üretmesi gerektiği anlayışıdır.
Ürün açısından: daha az “gizemli durum”, daha az mutabakat yangını ve "taahhüt edilmiş" in gerçekte ne demek olduğu konusunda net garantiler sağlar.
Bir işlem, birden çok güncellemeyi tek bir tamamen-ya-da-hiçbiri birim olarak gruplayandır. Tüm adımlar başarılıysa commit edilir; herhangi biri başarısız olursa rollback yapılır.
Tipik örnekler:
ACID, işlemleri güvenilir kılan garantiler kümesidir:
Bu tek bir anahtar değildir—hangi garantilere ihtiyaç duyduğunuzu ve ne kadar güçlü olmaları gerektiğini seçersiniz.
Üretimde nadiren görülen hataların çoğu zayıf izolasyondan doğar.
Yaygın başarısızlık desenleri:
Pratik çözüm: iş riski temelinde izolasyon seviyesini seçin ve gerektiğinde constraint/locking ile destekleyin.
Önce açık ve basit İngilizce invariantlar yazın (her zaman doğru olması gerekenler), sonra bunları koruyacak en küçük atomik işlem sınırlarını belirleyin.
Birlikte iyi çalışan mekanizmalar:
Kısıtları, uygulama kodu eşzamansız davranış yaptığında güvenlik ağı olarak düşünün.
Write-ahead logging (WAL), veritabanlarının “commit”i çökmelerden sonra korumasını sağlayan yöntemdir.
Operasyonel olarak:
Bu yüzden temiz bir tasarım:
Snapshot yani yedekler nokta-zaman görüntüleridir; loglar ise o görüntüden sonraki değişikliklerin geçmişidir.
Pratik kurtarma duruşu:
Hiç geri yüklemediğiniz bir yedek, plan değil umuttur.
Dağıtık işlemler birden çok sistemi tek bir atomik işlem gibi göstermeye çalışır; ancak kısmi hatalar ve belirsiz zaman aşım durumları bunu zorlaştırır.
İki fazlı commit (2PC) genellikle:
Gerçekten çapraz-sistem atomikliği gerekiyorsa ve operasyonel karmaşıklığı kaldırabiliyorsanız kullanın.
Küçük yerel ACID sınırları tutup servisler arası koordinasyonu açıkça yönetmek genelde daha ölçeklenir.
Yaygın desenler:
Böylece retry ve hatalar altında öngörülebilir davranış elde edilir, her akışı global kilit haline getirmeden.
Bir zaman aşımı “başarısız oldu” anlamına gelmeyebilir; sunucu aslında başarılı olmuş ama cevap kaybolmuş olabilir. Bu yüzden retry mantığı başarı olabileceğini varsaymalıdır.
Teknikler:
En iyi uygulama: dedupe kontrolü ile durum değişikliğini mümkünse aynı veritabanı işlemi içinde yapın.