Veritabanındaki yarış koşullarını nasıl test edersiniz?

30

Doğru satırları veya tabloları kilitlediğimden emin olmak için yarış koşullarına tabi olmadığından emin olmak için veritabanı kodunu yazmaya çalışıyorum. Ama sık sık merak ediyorum: Kodum doğru mu? Mevcut herhangi bir yarış koşulunu tezahür ettirmeye zorlamak mümkün mü? Bir üretim ortamında meydana gelirlerse başvurumun doğru olanı yapacağından emin olmak istiyorum.

Genel olarak hangi eşzamanlı sorgunun soruna neden olabileceğini biliyorum, ancak doğru davranış olup olmadığını (örneğin doğru kilit türünü kullandım), doğru davranışların olup olmadığını görmek için onları nasıl eşzamanlı çalıştırmaya zorlayacağımı bilmiyorum. atılmış, vb.

Not: PostgreSQL ve Perl kullanıyorum, bu yüzden eğer genel olarak cevaplanamıyorsa, muhtemelen bu şekilde yeniden etiketlenmelidir.

Güncelleme: Çözüm programlı olsaydı tercih ederim. Bu şekilde, gerileme olmadığından emin olmak için otomatik testler yazabilirim.

concurrency testing

— xenoterracide
kaynak

"Irk koşulu" ile "kilitlenme" mi demek istiyorsun?

— Gaius

2

@Gaius ... hayır, bazı yarış koşullarının olası bir sonucu olduğuna inanıyorum

— xenoterracide

Bir veritabanında @Gaius yarış koşulları, bir tablo oluşturulmadan önce bir tabloyu bırakmak veya eklenmeden önce bir satır güncelleme gibi şeyler yapıyor olacaktır. Genelde veritabanının dışında kalan uygulama mantığı tarafından kullanıldığını hayal ediyorum.

— Mark D

eklenmeden önce bir satır güncelleniyor mu? Bu bir db soruna neden olmaz. hiçbir yarış koşulu bir satır almak ve güncellemek gibi olmaz, ancak başka bir kullanıcının satırınız alındıktan sonra ancak güncellemeniz işlenmeden önce onu güncellemesi gibi olmaz.

— xenoterracide

1

@MarkD - Hayır. Atomik bir iş birimini veritabanınıza yanlış yerleştirmekten kaynaklanan birçok yarış koşulu vardır. İşte bir örnek. Unutmayın, "bir yarış durumu veya yarış tehlikesi, işlemin çıktısının veya sonucunun beklenmedik bir şekilde ve kritik olarak diğer olayların sırasına veya zamanlamasına bağlı olduğu bir elektronik sistem veya süreçteki bir kusurdur ." ( kaynak )

— Nick Chammas,

11

Her zaman T-SQL modüllerimle yapıyorum.

Temel olarak, tek yapmanız gereken modüllerinizi iki veya daha fazla bağlantıdan bir döngü içinde birkaç dakika çalıştırmak . Tipik olarak, tüm potansiyel problemler, makul CPU'lara sahip bir SQL Server kutunuz olduğunu varsayarak birkaç dakika içinde ortaya çıkar.

Burada ve burada birkaç örnek yazdım .

— AK
kaynak

4

Genelde RDBMS'nin komut satırı aracıyla çalışıyorum, CLI'nin sadece 2 (veya daha fazla) örneğini başlattım. Daha sonra , uygulama katmanınızın gönderdiği SQL ifadelerini teker teker ve bir yarış olarak (bir aksiyon-RPG'ye benzeyen) tekrarlayabilirsiniz . Kilitleme sistemlerini denemelisiniz / hissetmelisiniz, çünkü CLI'niz biraz kilitlenir ve kilitlerin diğer CLI'den serbest bırakılmasını bekler.

Bu çamur gibi net geliyorsa, bunu söylemekte tereddüt etmeyin ;-)

— Julien
kaynak

adım adım örnek verebilir misiniz? ve aynı şeyi yapmak için programatik testler yazılabilir mi?

— xenoterracide

1

Yarış Koşulları, birden fazla yürütme ipliği gerektirdiğinden, birimin test edilmesi için, bir veya daha fazla sayıda iplik başlatabilmeniz gerekir. Oracle’da ikinci bir kullanıcıyı simüle etmek için bir işlem yürütmek üzere DBMS_Scheduler kullanırdım. PostgreSQL / Perl'in ikinci bir işlemi programlı olarak başlatmanın bir yolu varsa, bunun gibi bir şey yapmalısınız:

İşlem 1 İşlem 2

İşlem 2'yi başlatın. >>                            
2 işi yapmasına izin vermek için gecikme. 
. Satırları kilitle veya verileri değiştir.
. 1'in çalışmasına izin vermek için gecikme.
Satırları kilitlemeye veya verileri değiştirmeye çalışın. .
Uygun işlem yapıldığından emin olmak için kontrol edin. .
Uçlar. .
                                                Uçlar.

Yarış koşullarının nasıl ele alınacağını ve daha önemlisi onları nasıl test edeceğinizi düşünmek iyidir.

— Leigh Riffel
kaynak

Birim testleri gibi testleri tarif etmem, çünkü birim testleri her zaman aynı şekilde yapılmalıdır. Yarış koşulları başarısız oluyor, süreçler aralıklarla, her seferinde aynı şekilde değil.

— AK

@AlexKuznetsov Beklenmeyen yarış koşullarının kendilerine aralıklı olarak kendilerini gösterebileceği konusunda haklısınız , ancak OP, kodun ele alacağına inandığı Beklenen şartlara atıfta bulunuyor . Bu özel koşullar tam olarak üretilebilir ve işlem bir birim testiyle doğrulanabilir.

— Leigh Riffel

-2

Satırları kilitlediğiniz sürece, hiçbir kilitleme olmadığında ortaya çıkan yarış koşullarına girmemelisiniz.

Ancak bir soru sorunuzu çok uzun süre engellerse kilitlenebilirsiniz.

Veritabanları büyüdükçe sorgular için zaman değişebileceğinden test etmek zordur.

100 000 satırlık test verileriyle iyi çalışan sorgular, 10 000 000 satırlık tablodan çıkar.

Bu tür bir sorunu önceden bulmak çok zor olabilir, ancak çoğu DB yavaş sorguları belirleme yöntemine sahiptir.

Bu yönetmeliği kullanarak, başınızdaki soruları, büyük bir uyarı ile derhal yakalayabilmelisiniz.

Kendi kendine kilitlenirsen, onun başka bir hikayesi var, ama orada yardım edemem.

— Nick Chammas
kaynak

@darioo lol Belki de wn bir şey için bir kısaltma olduğunu düşündüm ... ne demek istediğini "kendi kilitleme" dır. Eğer bir ORM ile demek istemiyorsa, ORM çıktıları kodunu kontrol ettim. sağ kilitleme Potansiyel yarış durumu senaryolarını test edebilmek için nedenlerden biri.

— xenoterracide

Evet, kendimi kastetmiştim ve normalde veri tabanı sürücüsü kilitleme, satır, tablo veya muhtemel alan işlemlerini gerçekleştiriyor, ancak sadece kilitlemeyi kaldıramayan bir veri tabanı kullanma olasılığı için açıyorum;)

.. select for update

— DB'm otomatik