Her zaman bir işlem oluşturmak kötü bir uygulama mıdır?

Her zaman bir işlem oluşturmak kötü bir uygulama mıdır?

Örneğin, basit bir işlemden başka bir şey için bir işlem oluşturmak iyi bir uygulamadır SELECT?

Gerçekten gerekli olmadığında işlem yaratmanın maliyeti nedir?

Gibi bir izolasyon seviyesi kullanıyor olsanız bile READ UNCOMMITTED, bu kötü bir uygulama mı?

Her zaman bir işlem oluşturmak için kötü bir uygulama mı?

Burada hangi bağlamda konuştuğunuza bağlı. Bu bir güncelleme ise, TRANSACTIONS'ı açık bir şekilde kullanmanızı şiddetle tavsiye ederim. Bir SELECT ise, HAYIR (açıkça).

Ama önce anlamak için daha çok şey var: sql sunucusundaki her şey bir işlemde var.

Oturumu seçeneği ne zaman IMPLICIT_TRANSACTIONSolduğunu OFFve açıkça belirtmek begin tranve commit/rollbacksonra bu yaygın bir şekilde bilinmektedir Açık İşlem . Aksi takdirde bir autocommit işlemi alırsınız.

Ne zaman IMPLICIT_TRANSACTIONSolduğunu ONbir örtük işlem kitapları çevrimiçi makalesinde (örn belgelenen deyimi türlerinden birini infaz otomatik olarak başlatılan SELECT/ UPDATE/ CREATE) ve işlenen veya açıkça geri alınması gerekmektedir. Bir yürütme BEGIN TRANartırmak istiyorum bu modda @@TRANCOUNTve başka bir "iç içe" hareketi başlatmak)

Hangi modu kullandığınızı değiştirmek için,

SET IMPLICIT_TRANSACTIONS ON

veya

SET IMPLICIT_TRANSACTIONS OFF

select @@OPTIONS & 2

Yukarıdaki 2 döndürürse, gizli işlem modunda demektir. 0 döndürürse, autocommit'tesiniz.

Gerçekten gerekli olmadığında işlem yaratmanın maliyeti nedir?

Veritabanını bir tutarlı durumdan başka bir tutarlı duruma almak için işlem yapılması gerekir. İşlemlere alternatif olmadığından işlemlerin maliyeti yoktur. Bakınız: Satır Sürüm Oluşturma Tabanlı Yalıtım Düzeylerini Kullanma

Bir izolasyon seviyesi kullanıyor olsanız bile read_uncomitted. Kötü bir uygulama mı? çünkü kilitlemeyle ilgili sorun yaşamamalıdır.

READ_UNCOMMITED izolasyon seviyesi, tanımlara göre kirli okumalara izin verir, yani bir işlem diğer işlemler tarafından yapılan taahüt edilmemiş değişiklikleri görebilecek. Bu izolasyon seviyesinin yaptığı şey, veritabanının eşzamanlılığını korumak için kilitleme yönteminin kilitleme başının üstünü gevşetmesidir.

Bunu diğer sorguları etkilemeyecek şekilde bir bağlantı / sorgu düzeyinde kullanabilirsiniz.

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

Jeff Atwood'un Yemek Filozofları Yapbozuna Bağlı Deadlock'ları tanımlayan ve okunan anlık görüntü yalıtım seviyesini anlatan ilginç bir makale buldu .

DÜZENLE:

Meraktan, T-log üzerindeki etkisini ölçmek için Log Bytes Flushed / Sec, Log Flush Waits / Sn (LOG flushed beklemekte olan komisyon sayısı) gibi Perfmon sayaçları ile bazı grafikler çizdim:

basit kod :

create table testTran (id int, Name varchar(8))
go

-- 19 sec
-- Autocommit transaction
declare @i int
set @i = 0
while @i < 100000
begin 
insert into testTran values (1,'Kin Shah')
set @i = @i+1
end
---------------------------------------------------
-- 2 sec
-- Implicit transaction
SET IMPLICIT_TRANSACTIONS ON
declare @i int
set @i = 0
while @i < 100000
begin 
insert into testTran values (1,'Kin Shah')
set @i = @i+1
end
COMMIT;
SET IMPLICIT_TRANSACTIONS OFF


----------------------------------------------------
-- 2 sec
-- Explicit transaction
declare @i int
set @i = 0
BEGIN TRAN
WHILE @i < 100000
Begin
INSERT INTO testTran values (1,'Kin Shah')
set @i = @i+1
End
COMMIT TRAN

Autocommit İşlemleri : (@TravisGan tarafından vurgulandığı şekilde düzenlendi)

• Ekleme 19 saniye sürdü.
• Her Autocommit, autocomit nedeniyle T-log tamponunu diske aktaracaktır (@TravisGan vurgulandıktan sonra ve bahsettiğimi kaçırdım).
• CHECKPOINT işlemi hızlı bir şekilde tamamlanacaktır, çünkü temizlenmesi gereken kirli günlük arabellek miktarı sıkça sessizce çalıştığından daha az olacaktır.

UYGULAMA & Açık İşlem:

• Ekleme 2 saniye sürdü.
• EXPLICIT işlemi için kayıt arabellekleri yalnızca dolu olduklarında temizlenir.
• Autocommit işleminin aksine, EXPLICIT işleminde, CHECKPOINT işleminin temizlenmesi için daha fazla günlük arabelleği olacağından daha uzun sürecektir (günlük arabelleği yalnızca dolu olduklarında temizlendi).

Veritabanı düzeyinde İşlemler hakkında bilgi döndürecek bir DMV sys.dm_tran_database_transactions var.

Açıkçası, bu etkiyi göstermek için daha basit bir testtir. Disk alt sistemi, otomatik veritabanı büyüme ayarları, veritabanının ilk boyutu, aynı sunucuda çalışan diğer işlemler \ veritabanı, vb. Gibi diğer faktörlerin de etkisi olacaktır.

Yukarıdaki testlerden, Kapalı ve Açık işlemler arasında bir fark yoktur.

@TravisGan'a cevabınıza daha fazla şey eklemenize yardımcı olduğun için teşekkürler

Bir SQL deyimi her zaman bir işlemde çalışır. Açıkça bir tane başlatmazsanız, her SQL ifadesi kendi işleminde çalışır.

Tek seçenek, bir işlemde birden fazla ifadeyi paketleyip paketlemeyeceğinizdir. Birden çok ifadeyi kapsayan işlemler eşzamanlılığa zarar veren kilitler bırakır. Bu yüzden "her zaman" bir işlem yaratmak iyi bir fikir değildir. Maliyeti fayda ile dengelemelisiniz.

Mesele, bir operasyon grubunun tek bir eylem olarak ele alınması gerekip gerekmediğidir. Diğer bir deyişle, tüm işlemler başarılı bir şekilde tamamlanmalı ve yapılmalıdır ya da hiçbir işlem yapılamaz. Ön verileri okumanızı ve ardından bu verilere dayanarak güncellemeleri gerçekleştirmenizi gerektiren bir senaryonuz varsa, ilk okuma muhtemelen işlemin bir parçası olmalıdır. Not: Bilerek Seç / Ekle / Güncelle'den kaçınıyorum. İşlem kapsamı aslında uygulama düzeyinde olabilir ve birden fazla veritabanı işlemi içerebilir. Uçak Koltuğu Rezervasyonu veya Banka Bakiyesi Sorgu / Para Çekme gibi klasik kalıpları düşünün. Tüm uygulamanın güvenilir ve tutarlı veri elde etmesini sağlamak için sorunun daha geniş bir görüşle ele alınması gerekir.