Tabloyu bir çalışan SP'den alabilir ve SQL Server'da başka bir SP'ye verebilir miyim?

Question

SQL DBA rolüne yeniyim. Günde birden çok kez çalışabilen bir Saklı Yordam (SP1) var. Tablo1'de, yapılması gereken 15 dakika süren pahalı bir SELECT çalışır. Tablo 1'de 1 saniye sürecek bir SELECT çalıştıran başka bir Stored Procedure (SP2) var.

SP1 çalıştırdıktan sonra SP2 SP1 bitene kadar beklemeli! SP2'yi çalıştırmak için gerekli kaynağı (tablo1'den seçme gibi) alabileceğim ve SP2 tamamlandıktan sonra SP1'e geri vermenin herhangi bir yolu var mı?

SELECT WITH (NOLOCK) kullanmak istemiyorum, çünkü diğer sorgular tablo1'i düzenlemeyi deneyebilir.

Answer 1

Sorunuzun basit cevabı "hayır" olur. Görünüşe göre, SP1'de çok uzun süren bir sorguya sahip olduğunuz ve Tablo1'de paylaşılan kilitleri alan herhangi bir UPDATE veya INSERT SP2'nin SP1 tamamlanıncaya kadar beklemesi gerekir, böylece gerekli özel kilitler alınabilir (işlemlerden bahsetmediniz) yalıtım seviyeleri bu yüzden ben daha sonra herhangi bir sonraki işlem değil zaman alır SELECT kendisi olduğunu kabul edeceğim - SP1 o zaman bazı UPDATE s veya INSERT s kendi gerçekleştirebilir olduğunu söylemiş olmasına rağmen). Toplayabildiğim kadarıyla, SP1'in SELECT SP2'nin UPDATE s performansını gerçekleştirebilmesi için kilitlerini serbest bırakmasını ve daha sonra SP2'nin kilitlerini serbest bırakmasını istediğinizde SP1'in SELECT'a devam etmesine izin verin. Korkarım ki bu SQL'in kilitleme mantığına ve gerçekten de ACID ilkelerine aykırı. SP1 (veya başka bir işlem) her UPDATE gerçekleştirdiğinde tutarlı bir sonuç elde etmek için SP1'in SELECT yeniden başlatılması gerektiğinden, veritabanı performansı için felaketle sonuçlanacak şekilde çalışmasını istiyordu.

Saklı yordamlarınızı/uygulamalarınızı yeniden yapılandırmaya bakmanız gerektiği gibi geliyor. Bir SP'yi düzenli olarak çalıştıran, 15 dakika süren ve potansiyel olarak bir masaya kilitlenebilen bir ana darboğaz gibi görünüyor. Kırılmayabilir - belki SP2'nin mantığından bazılarını segmentlerden birine dahil edebilir mi? Ayrıca, neden bu kadar uzun sürüyor? SELECT zamanını azaltmak için uygulanabilecek indeksleme yok ve aynı zamanda ıstırap çektiğiniz tablo/aralık kilitlerinden de kaçınıyor musunuz?

Answer 2

READ_COMMITTED_SNAPSHOT'a bir göz attınız mı? anlık

net etkisi:

Kesinlikle ilk olmayan bir üretim ortamında bunu test etmek gerekir ama umarım Ancak NOLOCK

alternatif olmalı, çevrimiçi kitapları söylüyor Yalıtım, işlemin, işlemin başlangıcında var olan tüm verileri, temel tablolara onur vermeksizin veya herhangi bir kilit koymaksızın görmesidir. Bu, çekişmenin olduğu durumlarda performans iyileştirmelerine yol açabilir.

sizin TempDB için zararlı olabilir ama bunun için boşluk varsa, bu size bazı yardımcı olabileceğini burada bir uyarı yok.

Kesinlikle bu konu hakkında bir şeyler okumuştum ve belki de diğer answers numaralarına bakabilirim.