BEGIN TRAN etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
BEGIN TRAN etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster

30 Ocak 2021 Cumartesi

Blok ve Bloklanan İşler

 İdeal olarak veritabanı uygulamanızın veritabanı kullanıcı sayısı ile doğrusal olarak ölçeklenmesi gerekir. Ancak kullanıcı sayısı arttıkça kullanıcı sayısı performansı düşürdüğü yaygın bir durumdur. Artan ölçekle ilişkili olan bozulmanın nedeni engellemedir.

SQL Serverda engellemenin temelleri;

*ACID özellikleri

*Veritabanı kilit ayrıntı düzeyi, yükseltme, modlar ve uyumluluk.

*ANSI izolasyon seviyeleri

*Dizinlerin kilitlenme üzerindeki etkisi

*Engellemeyi analiz etmek için gerekli bilgiler

*Engellemeyi önlemek için kararlar ve öneriler

*Engelleme algılama ve bilgi toplama süreçlerinin otomatikleştirme teknikleri,


Atomiklik, Tutarlılık, İzolasyon, Dayanıklılık.


USE AdventureWorks2012;
GO
IF (SELECT OBJECT_ID('dbo.ProductTest')

    ) IS NOT NULL
      DROP TABLE dbo.ProductTest;
GO
CREATE TABLE dbo.ProductTest (
ProductID INT CONSTRAINT ValueEqualsOne CHECK (ProductID = 1));
GO


--All ProductIDs are added into t1 as a logical unit of work
INSERT INTO dbo.ProductTest
          SELECT p.ProductID
          FROM Production.Product AS p;

GO
SELECT *
FROM dbo.ProductTest; --Returns 0 rows
SQL Server önceki INSERT deyimini mantıksal çalışma birimi olarak ele alır. Sütundaki CHECK kısıtı ProductTest tablosunun ProductID sinini yanlızca 1 değerine izin verir. Bu nedenle ProductTest tablosuna hiç bir kayıt eklemeyecektir. CHECK nedeniyle hata oluşacaktır. Bu SQL Server tarafından otomatik olarak sağlanır.


BEGIN TRAN

 --Start: Logical unit of work

--First:

INSERT INTO dbo.ProductTest

            SELECT p.ProductID

            FROM Production.Product AS p;

--Second:

INSERT INTO dbo.ProductTest

VALUES (1);

COMMIT --End: Logical unit of work

GO

SQL Serverda önceki ekleme görevinden birden çok INSERT çalıştığını düşünerek daha büyük bir işin çalıştığını düşünürsek;  yukarıdaki gibi daha büyük mantıksal çalışma birimi oluşacaktır. Önceki komut dosyası zaten oluşmuş olan ProductTest tablosu ile BEGIN TRAN ve COMMIT çifti ile tüm ifadelerin atomik olması gerektiğini öneren mantıksal çalışma birimini tanımlar. ilk INSERT ifadesi başarısız olacak oysa ikinci INSERT makuldur ve varsayılan davranış ikinci INSERT ifadesinden SQL Server yürütmesine izin verecektir.

Kullanıcı tanımlı işlemin atomikliği 2 yolla sağlanır.

* SET XACT_ABORT ON
* Explicit rollback


SET XACT_ABORT ON


SET XACT_ABORT ON deyimini kullanarak işlemin atomikliği değiştirilebilir.

SQL Server komuttaki bir işlemin başarısız olduğunda otomatik olarak geri dönüş yapıp yapmayacağının karar vermesini sağlar. INSERT ifadesindeki birinci aşamadaki işlem başarısız olursa otomatik olarak ikinci INSERT ifadesini yürütmeyecektir. SET XACT_ABORT bağlantı düzeyinde yenide yapılandırılıncaya kadar yada bağlantı kurulana kadar geçerli kalır. Varsayılan olarak bu özellik kapalıdır.


SET XACT_ABORT ON;
GO
BEGIN TRAN
 --Start: Logical unit of work
--First:
INSERT INTO dbo.ProductTest

            SELECT p.ProductID
            FROM Production.Product AS p;
--Second:
INSERT INTO dbo.ProductTest
VALUES (1);
COMMIT
 --End: Logical unit of work GO
SET XACT_ABORT OFF;
GO

Explicit rollback

TRY/CATCH hata yakalama mekanizmasını kullanarak kullanıcı tanımlı bir işlemin atomikliğini yönetebilirsiniz. SQL Server içerisinde TRY kod bloğu içinde ifade hata alırsa kodu CATCH bloğuna hatayı paslayarak tüm işlemler geri alınabilir ve sonraki ifadelerin yürütülmesi engellenebilir.


BEGIN TRY
      BEGIN TRAN
      --Start: Logical unit of work
      --First:
      INSERT INTO dbo.ProductTest

                  SELECT p.ProductID
                  FROM Production.Product AS p
      Second:
      INSERT INTO dbo.ProductTest
                  (ProductID)
      VALUES (1)
      COMMIT --End: Logical unit of work
END TRY
BEGIN CATCH
      ROLLBACK
      PRINT 'An error occurred'
      RETURN
END CATCH


3 Ocak 2021 Pazar

DeadLock Analiz #2



Öncelikle kilitlenme bayrağı 1222 ve xml_deadlock_report olaylarının kullanıma açıldığından emin olmamız gerekiyor.

Tek bir bağlantıda aşağıdaki komut çalıştırılabilir;

BEGIN TRAN
UPDATE Purchasing.PurchaseOrderHeader
SET Freight = Freight * 0.9 -- 10% discount on shipping
WHERE PurchaseOrderID = 1255;

ikinci bağlantıda aşağıdaki komut çalıştırılabilir.

BEGIN TRANSACTION
UPDATE Purchasing.PurchaseOrderDetail
SET OrderQty = 4
WHERE ProductID = 448
AND PurchaseOrderID = 1255;

Yukarıdaki komutlar çalıştırıldığında her biri bir işlem açar ve verileri işlemeye başlar. Ancak ne kadar zamanda işlemi yapacağını ve geri alacağını bilemiyoruz.

Birinci komuta gidip aşağıdaki işlemi çalıştırılalım;

UPDATE Purchasing.PurchaseOrderDetail
SET OrderQty = 2
WHERE ProductID = 448
AND PurchaseOrderID = 1255;

İlk bağlantı büyük ihtimalle bir kaç saniye sonra bir kilitlenme oluşacaktır. 

Msg 1205, Level 13, State 51, Line 1
Transaction (Process ID 52) was deadlocked on lock resources with another process and has been
chosen as the deadlock victim. Rerun the transaction.

Önce izleme olayı aracılıyla toplanan kilitlenme grafiğini incelememiz ardından xml_deadlock_report olay için bu pencerede verilen grafiği incelememiz gerekir. 

Ancak daha detaya inerek kilitlenme olayının tam olarak nerede olduğu hangi süreçlerin buna neden olduğu hangi nesnelerin dahil edildi bilgileri XML dosyasını doğrudan genişletilmiş olay grafiğini değerlerinden bulabiliriz.


Örnek tabloda uPurchaseOrderDetail adlı bir tetikleyici bulunuyor. Tüm bu bilgiler hangi kod parçalarının kilitlenmeye yol açtığını belirlememizde yardımcı olacaktır. Ayrıca SQL Handle  gibi bilgileri almak, DMO lar ile birlikte ifadeleri almak kilitlenme ile ilgili bilgilerde bize yardımcı olacaktır.

İzleme bayrağı 1222 tarafından toplanan veriler ile XML içerisindeki bilgiler hemen hemen aynıdır.  Ana farklılıkları biçimlendirme ve konumudur. İzleme bayrağı 1204 tarafından toplanan veriler ise tamamen farklıdır.  Kullanabiliyorsanız Genişletilmiş olayları kullanmaya devam etmeniz işinizin kolaylaşması açısında daha iyidir. 1222 takip edilmesi genellikle önerilir. system_health içinde oluşan bilgilerde size yardımcı olacaktır. 

Yukarıdaki örnekde kilitlenme Purchasing.PurchaseOrderDetail  tablosundaki bir tetikleyiciden kaynaklanmaktadır. Miktar güncellendiğinde Purchasing.PurchaseOrderDetail tablosunda Purchasing.PurchaseOrderHeader tablosu güncellemeye çalışır. İlk iki sorgu çalıştığında her biri açık bir işlem üzerinde bir engelleme durumu söz konusu olur. İkinci sorgu ilk sorgunun temizlenmesini bekler böylece Purchasing.PurchaseOrderHeader tablosunu güncelleyebilir. Sorunu çözebilmek için süreçlerden birini öldürmektir.