Bellek-Optimizasyonlu Tablolarla İşlemler

Şunlar için geçerlidir:SQL Server Azure SQL Veritabanı Azure SQL Yönetilen Örneği

Bu makalede, bellek için iyileştirilmiş tablolara ve yerel olarak derlenmiş saklı yordamlara özgü işlemlerin tüm yönleri açıklanmaktadır.

SQL Server'daki işlem yalıtım düzeyleri bellek için iyileştirilmiş tablolara ve disk tabanlı tablolara göre farklı uygulanır ve temel alınan mekanizmalar farklıdır. Farklılıkların anlaşılması, programcının yüksek aktarım hızı sistemi tasarlamasını sağlar. İşlem bütünlüğünün hedefi her durumda paylaşılır.

Bellek için iyileştirilmiş tablolardaki işlemlere özgü hata koşulları için Çakışma Algılama ve Yeniden Deneme Mantığı bölümüne atlayın.

Genel bilgi için bkz. SET TRANSACTION ISOLATION LEVEL (Transact-SQL).

Kötümser ve İyimser karşılaştırması

İşlevsel farklılıklar, işlem bütünlüğüne yönelik kötümser ve iyimser yaklaşımlardan kaynaklanıyor. Bellek için iyileştirilmiş tablolar iyimser yaklaşımı kullanır:

Kötümser yaklaşım, olası çakışmaları gerçekleşmeden önce engellemek için kilitleri kullanır. Açıklama yürütülürken kilit alınır ve işlem onaylandığında serbest bırakılır.
İyimser yaklaşım, çakışmaları oluştukları sırada algılar ve işleme zamanında doğrulama denetimleri gerçekleştirir.
- Bellek iyileştirmeli bir tabloda, 1205 numaralı kilitlenme hatası çıkamaz.

İyimser yaklaşım daha az ek yüktür ve genellikle daha verimlidir, çünkü çoğu uygulamada işlem çakışmaları yaygın değildir. Kötümser ve iyimser yaklaşımlar arasındaki temel işlevsel fark, bir uyuşmazlık meydana gelirse, kötümser yaklaşımda beklemeniz gerekirken, iyimser yaklaşımda işlemlerden birinin başarısız olması ve müşteri tarafından yeniden denenmesi gerektiğidir. REPEATABLE READ yalıtım düzeyi etkin olduğunda işlevsel farklılıklar daha büyüktür ve SERIALIZABLE seviyesinde en büyüktür.

İşlem Başlatma Modları

SQL Server, işlem başlatma için aşağıdaki modlara sahiptir:

Autocommit - Basit bir sorgunun veya DML deyimin başlangıcı örtük olarak bir işlem açar ve deyimin sonu işlemi örtük olarak tamamlar. Otomatik komut varsayılandır.
- Autocommit modunda, genellikle FROM ifadesinde yer alan bellek içi optimize edilmiş tablo üzerinde işlem yalıtım seviyesiyle ilgili bir tablo ipucu kodlamanız gerekmez.
Açık - Transact-SQL, BEGIN TRANSACTION kodunu ve nihai olarak COMMIT TRANSACTION kodunu içerir. İki veya daha fazla deyim aynı işlemde birleştirilebilir.
- Açık modda, ya MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT veritabanı seçeneğini kullanmalı ya da FROM yan tümcesindeki bellek için iyileştirilmiş tabloda işlem yalıtım düzeyi hakkında bir tablo ipucu belirterek kod yazmalısınız.
Gizli - SET IMPLICIT_TRANSACTION ON etkin olduğunda. Belki IMPLICIT_BEGIN_TRANSACTION daha iyi bir isim olabilirdi, çünkü bu seçenek, 0 = @@trancount olduğunda her UPDATE deyiminden önce örtük olarak açık BEGIN TRANSACTION'ın eşdeğerini gerçekleştirir. Bu nedenle, sonunda açık bir COMMIT TRANSACTION vermek T-SQL kodunuzun elindedir.
ATOMIC BLOCK - ATOMIC bloklarındaki tüm deyimler her zaman tek bir işlemin parçası olarak çalışır. Bir bütün olarak atomik bloğun eylemleri başarıya tamamlanır veya bir hata oluştuğunda eylemlerin tümü geri döndürülür. Yerel olarak derlenmiş her saklı yordam bir ATOMIC bloğu gerektirir.

Açık Modlu Kod Örneği

Aşağıdaki yorumlanmış Transact-SQL betiği kullanır:

Açık bir işlem.
Bellek için iyileştirilmiş dbo.Order_mo adlı bir tablo.
READ COMMITTED işlem yalıtım düzeyi bağlamı.

Bu nedenle bellek için iyileştirilmiş tabloda bir tablo ipucu olması gerekir. İpucu "SNAPSHOT" veya daha da fazla yalıtma düzeyi için olmalıdır. Kod örneğinde, ipucu WITH (SNAPSHOT) şeklindedir. Bu ipucu kaldırılırsa betik 41368 hatasıyla karşılaşır ve otomatik yeniden deneme uygun olmaz:

Hata 41368

READ COMMITTED yalıtım düzeyini kullanarak bellek için iyileştirilmiş tablolara erişmek yalnızca otomatik komut işlemleri için desteklenir. Açık veya örtük işlemler için desteklenmez. Bellek için optimize edilmiş tabloya, WITH (SNAPSHOT) gibi bir tablo ipucu kullanarak, desteklenen bir yalıtım seviyesi sağlayın.

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;  
GO  

BEGIN TRANSACTION;  -- Explicit transaction.  

-- Order_mo  is a memory-optimized table.  
SELECT * FROM  
           dbo.Order_mo  as o  WITH (SNAPSHOT)  -- Table hint.  
      JOIN dbo.Customer  as c  on c.CustomerId = o.CustomerId;  
COMMIT TRANSACTION;

İpucu gereksinimi WITH (SNAPSHOT) , veritabanı seçeneğinin MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOTkullanılmasıyla önlenebilir. Bu seçenek ON olarak ayarlandığında, daha düşük bir yalıtım seviyesinden bellek için optimize edilmiş bir tabloya erişim otomatik olarak Anlık Görüntü yalıtımına yükseltilir.

ALTER DATABASE CURRENT
    SET MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT = ON;

Satır Sürümleme

Bellek iyileştirmeli tablolar, Serializable'ın en katı yalıtım düzeyinde bile iyimser yaklaşımı verimli hale getiren oldukça gelişmiş bir satır sürümleme sistemi kullanır. Ayrıntılar için bkz. Memory-Optimized Tablolarına Giriş.

READ_COMMITTED_SNAPSHOT veya SNAPSHOT yalıtım düzeyi etkin olduğunda disk tabanlı tabloların dolaylı olarak bir satır sürüm oluşturma sistemi vardır. Bu sistem, tempdb üzerine inşa edilmiştir ve bellek için optimize edilmiş veri yapıları en yüksek verimlilik için yerleşik satır sürümlendirme özelliğine sahiptir.

Yalıtım Düzeyleri

Aşağıdaki tabloda, işlem yalıtımının olası düzeyleri, en az yalıtımdan çoğuna sıralı olarak listelenir. Oluşabilecek çakışmalar hakkında ayrıntılı bilgi edinmek ve bu çakışmalarla başa çıkmak için mantığı yeniden denemek için bkz. Çakışma Algılama ve Yeniden Deneme Mantığı.

Yalıtım Düzeyi	Description
OKUNMAMıŞ OKUMA	Kullanılamaz: Bellek için iyileştirilmiş tablolara Okunmamış yalıtım altında erişilemez. Oturum düzeyi TRANSACTION ISOLATION LEVEL DEĞERI READ UNCOMMITTED olarak ayarlandıysa, tablo ipucu WITH (SNAPSHOT)'u kullanarak veya veritabanı ayarını MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT AÇıK olarak ayarlayarak SNAPSHOT yalıtımı altında bellek için iyileştirilmiş tablolara erişmek mümkündür.
OKUNDU	Bellek için iyileştirilmiş tablolar için yalnızca otomatik komut modu etkin olduğunda desteklenir. TRANSACTION ISOLATION LEVEL oturum düzeyinde READ COMMITTED olarak ayarlandığında, WITH (SNAPSHOT) tablo ipucunu kullanıp veya veritabanı ayarını MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT ON olarak ayarlayarak SNAPSHOT yalıtımı altında bellek için optimize edilmiş tablolara erişmek mümkündür. READ_COMMITTED_SNAPSHOT veritabanı seçeneği AÇIK olarak ayarlanırsa, aynı SQL deyiminde READ COMMITTED yalıtım seviyesi altında bellek için iyileştirilmiş bir tablo ve disk tabanlı bir tabloya erişim sağlamak mümkün değildir.
AN -LIK GÖRÜNTÜ	Bellek optimize edilmiş tablolar desteklenir. Bellek için iyileştirilmiş tablolar için SNAPSHOT, dahili olarak en az gerektiren işlem izolasyon seviyesidir. SNAPSHOT, REPEATABLE READ veya SERIALIZABLE'dan daha az sistem kaynağı kullanır.
YINELENEBILIR OKUMA	Bellek optimize edilmiş tablolar desteklenir. REPEATABLE READ yalıtımı tarafından sağlanan garanti, işleme zamanında hiçbir eşzamanlı işlemin bu işlem tarafından okunan satırlardan hiçbirini güncelleştirmediğidir. İyimser model nedeniyle eşzamanlı işlemlerin bu işlem tarafından okunan satırları güncelleştirmesi engellenmez. Bunun yerine, işleme zamanında bu işlem REPEATABLE READ yalıtımının ihlal edilmediğini doğrulamıştır. Varsa, bu işlem geri alınır ve yeniden denenmelidir.
SERİLEŞTİRİLEBİLİR	Bellek optimize edilmiş tablolar desteklenir. Yalıtım o kadar katı olduğundan serileştirilebilir olarak adlandırılır, çünkü işlemlerin eşzamanlı olarak değil seri olarak çalıştırılmasına neredeyse biraz benzer.

İşlem Aşamaları ve Yaşam Süresi

Bellek için iyileştirilmiş bir tablo söz konusu olduğunda, işlemin ömrü aşağıdaki görüntüde gösterildiği gibi aşamalar boyunca ilerler:

hekaton_transactions

Aşamaların açıklamaları takip eder.

Düzenli İşleme: 1. Aşama (3'ünden)

Bu aşama, sorgudaki tüm sorguların ve DML deyimlerinin yürütülmesinden oluşur.
Bu aşamada ifadeler, işlemin mantıksal başlangıç anında bellek-optimize edilmiş tabloların sürümünü görür.

Doğrulama: 2. Aşama (/ 3)

Doğrulama aşaması bitiş saatini atayarak başlar ve bu sayede işlemi mantıksal olarak tamamlandı olarak işaretler. Bu tamamlanma, işlemdeki tüm değişiklikleri bu işleme bağımlı olan diğer işlemlere görünür hale getirir. Bu işlem başarıyla tamamlanana kadar bağımlı işlemlerin işlemesine izin verilmez. Buna ek olarak, bu tür bağımlılıkları barındıran işlemlerin, istemcinin yalnızca veritabanına başarıyla kaydedilmiş verileri gördüğünden emin olmak için sonuç kümelerini istemciye döndürmesine izin verilmez.
Bu aşama, yinelenebilir okuma ve seri hale getirilebilir doğrulamayı içerir. Yinelenebilir okuma doğrulaması için, işlem tarafından okunan satırlardan herhangi birinin güncelleştirilip güncelleştirilmediğini denetler. Serileştirilebilir doğrulama için, bu işlem tarafından taranan herhangi bir veri aralığına satır eklenip eklenmediğini denetler. Yalıtım Düzeyleri ve Çakışmalar içindeki tabloya göre, benzersiz ve yabancı anahtar kısıtlamalarının tutarlılığını doğrulamak için anlık görüntü yalıtımı kullanılırken hem yinelenebilir hem de seri hale getirilebilir doğrulama gerçekleşebilir.

Taahhüt İşleme: Aşama 3 (3'te 3)

İşleme (commit) aşamasında, dayanıklı tablolardaki değişiklikler günlüğe yazılır ve günlük diske kaydedilir. Ardından denetim istemciye döndürülür.
İşlem tamamlandıktan sonra, tüm bağımlı işlemlere işlem yapabilecekleri bildirilir.

Her zaman olduğu gibi, işlem birimlerinizi veri gereksinimleriniz için geçerli olduğu kadar az ve kısa tutmaya çalışmanız gerekir.

Çakışma Algılama ve Yeniden Deneme Mantığı

İşlemin başarısız olmasına ve geri alınmasına neden olan işlemle ilgili iki tür hata koşulu vardır. Çoğu durumda, böyle bir hata oluştuğunda, kilitlenme oluştuğunda olduğu gibi işlemin yeniden denenmesi gerekir.

Eşzamanlı işlemler arasındaki çakışmalar. Bunlar güncelleştirme çakışmaları ve doğrulama hatalarıdır ve işlem yalıtım düzeyi ihlallerinden veya kısıtlama ihlallerinden kaynaklanabilir.
Bağımlılık hataları. Bunlar, işlemeye bağlı olduğunuz işlemlerin başarısız olması veya bağımlılık sayısının fazla artmasından kaynaklanır.

Aşağıda, bellek için iyileştirilmiş tablolara erişirken işlemlerin başarısız olmasına neden olabilecek hata koşulları yer alır.

Hata Kodu	Description	Nedeni
41302	Mevcut işlemin başlangıcından bu yana farklı bir işlemde güncelleştirilen bir satırı güncelleştirme girişiminde bulunu.	İki eşzamanlı işlem aynı anda aynı satırı güncelleştirmeye veya silmeye çalışırsa bu hata koşulu oluşur. İki işlemden biri bu hata iletisini alır ve yeniden denenmiş olması gerekir.
41305	Yinelenebilir okuma doğrulama hatası. Bellek optimizasyonlu bir tablodan okunan bir satır, bu işlemin tamamlanmasından önce sonuçlanan başka bir işlem tarafından güncellendi.	Bu hata, REPEATABLE READ veya SERIALIZABLE yalıtımı kullanılırken ve eşzamanlı işlem eylemleri yabancı anahtar kısıtlamasının ihlaline neden olduğunda oluşabilir. Yabancı anahtar kısıtlamalarının eş zamanlı ihlali nadirdir ve genellikle uygulama mantığıyla veya veri girişiyle ilgili bir sorunu gösterir. Ancak, YABANCı ANAHTAR kısıtlamasıyla ilgili sütunlarda dizin yoksa da hata oluşabilir. Bu nedenle rehber, bellek optimizasyonlu bir tablodaki yabancı anahtar sütunlarına her zaman bir dizin oluşturulmasını önermektedir. Yabancı anahtar ihlallerinin neden olduğu doğrulama hataları hakkında daha ayrıntılı konular için SQL Server Müşteri Danışmanlığı Ekibi'nin bu blog gönderisine bakın.
41325	Serileştirilebilir doğrulama hatası. Daha önce mevcut işlem tarafından taranan bir aralığa yeni bir satır eklendi. Buna hayalet satır diyoruz.	Bu hata, SERIALIZABLE yalıtımı kullanılırken ve eşzamanlı işlem eylemlerinin bİrİnCİl ANAHTAR, BENZERSİz veya YABANCI ANAHTAR kısıtlamasının ihlaline neden olması durumunda da oluşabilir. Bu tür eşzamanlı kısıtlama ihlali nadirdir ve genellikle uygulama mantığı veya veri girişiyle ilgili bir sorunu gösterir. Ancak, yinelenebilir okuma doğrulama hatalarına benzer şekilde, söz konusu sütunlarda dizin içermeyen bir FOREIGN KEY kısıtlaması varsa da bu hata oluşabilir.
41301	Bağımlılık hatası: Daha sonra işlenemeyen başka bir işleme bağımlılık eklendi.	Bu işlem (Tx1), başka bir işlem (Tx2) üzerinde, Tx2'nin doğrulama veya taahhüt işleme aşamasındayken Tx2 tarafından yazılan verileri okuyarak bir bağımlılık oluşturdu. Tx2 daha sonra gerçekleştirilmedi. Tx2'nin işleyememesinin en yaygın nedenleri, yinelenebilir okuma (41305) ve serileştirilebilir (41325) doğrulama hatalarıdır; günlük GÇ hatası daha az yaygın bir nedendir.
41823 ve 41840	Bellek iyileştirmeli tablolarda ve tablo değişkenlerinde kullanıcı verileri kotasına erişildi.	Hata 41823, SQL Server Express/Web/Standard Edition'ın yanı sıra Azure SQL Veritabanı'ndaki tek veritabanları için de geçerlidir. Hata 41840, Azure SQL Veritabanı'ndaki elastik havuzlar için geçerlidir. Çoğu durumda bu hatalar maksimum kullanıcı veri boyutuna ulaşıldığını gösterir ve hatayı düzeltmenin yolu verileri bellek için iyileştirilmiş tablolardan silmektir. Ancak, bu hatanın geçici olduğu nadir durumlar vardır. Bu nedenle, bu hatalarla ilk karşılaştığınızda yeniden denemenizi öneririz. Bu listedeki diğer hatalar gibi, 41823 ve 41840 hataları da etkin işlemin durdurulmasına neden olur.
41839	İşlem, maksimum commit bağımlılıkları sayısını aştı.	Şunlar için geçerlidir: SQL Server 2016 (13.x). SQL Server ve Azure SQL Veritabanı'nın sonraki sürümlerinde işleme bağımlılıklarının sayısı sınırı yoktur. Belirli bir işlemin (Tx1) bağlı olabileceği işlem sayısıyla ilgili bir sınır vardır. Bu işlemler dışa giden bağımlılıklardır. Ayrıca, belirli bir işleme (Tx1) bağlı olabilecek işlem sayısıyla ilgili bir sınır vardır. Bu işlemler gelen bağımlılıklardır. Her ikisi için de sınır 8'dir. Bu hata için en yaygın durum, tek bir yazma işlemi tarafından yazılan verilere erişen çok sayıda okuma işleminin olduğu durumdur. Okuma işlemlerinin tümü aynı verilerde büyük taramalar gerçekleştiriyorsa ve yazma işleminin doğrulanması veya işlenmesi uzun sürüyorsa, örneğin yazma işlemi serileştirilebilir yalıtım altında büyük taramalar yapar (doğrulama aşamasının uzunluğunu artırır) veya işlem günlüğü yavaş bir günlük GÇ cihazına yerleştirilirse (işleme işleme uzunluğunu artırır) bu koşula isabet etme olasılığı artar. Okuma işlemleri büyük taramalar gerçekleştiriyorsa ve yalnızca birkaç satıra erişmeleri bekleniyorsa, bir dizin eksik olabilir. Benzer şekilde, yazma işlemi serileştirilebilir yalıtım kullanıyorsa ve büyük taramalar yapıyorsa ancak yalnızca birkaç satıra erişmesi bekleniyorsa, bu aynı zamanda eksik bir dizinin göstergesidir. İşleme bağımlılıklarının sayısı sınırı, izleme bayrağı 9926 kullanılarak kaldırılabilir. Eksik dizin olmadığını onayladıktan sonra, belirtilen durumlarda bu sorunların üstünü örtebileceği için bu izleme bayrağını yalnızca hala bu hata koşuluyla karşılaşıyorsanız kullanın. Bir diğer uyarı da, her işlemin çok sayıda gelen ve giden bağımlılıkları olduğu ve tek tek işlemlerin birçok bağımlılık katmanına sahip olduğu karmaşık bağımlılık grafiklerinin sistemde verimsizliğe yol açabileceğidir.

Mantığı Yeniden Dene

Yukarıda belirtilen koşullardan herhangi biri nedeniyle bir işlem başarısız olduğunda işlem yeniden denenmelidir.

Yeniden deneme mantığı istemci veya sunucu tarafında uygulanabilir. Genel öneri, daha verimli olduğundan ve hata oluşmadan önce işlem tarafından döndürülen sonuç kümeleriyle ilgilenmenize olanak sağladığından istemci tarafında yeniden deneme mantığının uygulanmasıdır.

T-SQL Kodunu Yeniden Deneme Örneği

T-SQL kullanan sunucu tarafı yeniden deneme mantığı yalnızca istemciye sonuç kümeleri döndürmeyen işlemler için kullanılmalıdır. Aksi takdirde, yeniden denemeler potansiyel olarak istemciye döndürülmesini beklenenlerin ötesinde ek sonuç kümelerine neden olabilir.

Aşağıdaki yorumlanan T-SQL betiği, bellek için iyileştirilmiş tablolar içeren işlem çakışmalarıyla ilişkili hatalar için yeniden deneme mantığının nasıl görünebileceğini gösterir.

-- Retry logic, in Transact-SQL.
DROP PROCEDURE If Exists usp_update_salesorder_dates;
GO

CREATE PROCEDURE usp_update_salesorder_dates
AS
BEGIN
    DECLARE @retry INT = 10;

    WHILE (@retry > 0)
    BEGIN
        BEGIN TRY
            BEGIN TRANSACTION;

            UPDATE dbo.SalesOrder_mo WITH (SNAPSHOT)
                set OrderDate = GetUtcDate()
                where CustomerId = 42;

            UPDATE dbo.SalesOrder_mo WITH (SNAPSHOT)
                set OrderDate = GetUtcDate()
                where CustomerId = 43;

            COMMIT TRANSACTION;

            SET @retry = 0;  -- //Stops the loop.
        END TRY

        BEGIN CATCH
            SET @retry -= 1;

            IF (@retry > 0 AND
                ERROR_NUMBER() in (41302, 41305, 41325, 41301, 41823, 41840, 41839, 1205)
                )
            BEGIN
                IF XACT_STATE() = -1
                    ROLLBACK TRANSACTION;

                WAITFOR DELAY '00:00:00.001';
            END
            ELSE
            BEGIN
                PRINT 'Suffered an error for which Retry is inappropriate.';
                THROW;
            END
        END CATCH

    END -- //While loop
END;
GO

--  EXECUTE usp_update_salesorder_dates;

Kapsayıcılar Arası İşlem

İşlem, şu durumda kapsayıcılar arası işlem olarak adlandırılır:

Yorumlanmış Transact-SQL'den bellek için iyileştirilmiş bir tabloya erişir; veya
Bir işlem zaten açık olduğunda yerel bir proc yürütür (XACT_STATE() = 1).

"Kapsayıcılar arası" terimi, işlemin biri disk tabanlı tablolar ve biri bellek için iyileştirilmiş tablolar için olan iki işlem yönetimi kapsayıcısı arasında çalıştığı gerçeğinden türetilir.

Tek bir kapsayıcılar arası işlemde, disk tabanlı ve bellek için iyileştirilmiş tablolara erişmek için farklı yalıtım düzeyleri kullanılabilir. Bu fark, WITH (SERIALIZABLE) gibi açık tablo ipuçları veya veritabanı seçeneği MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT aracılığıyla ifade edilir. İşlem yalıtım düzeyi READ COMMITTED veya READ UNCOMMITTED olarak yapılandırılmışsa bellek ile iyileştirilmiş tablonun yalıtım düzeyi örtük bir şekilde anlık görüntü moduna yükseltilir.

Aşağıdaki Transact-SQL kod örneğinde:

Table_D1 disk tabanlı tabloya READ COMMITTED yalıtım düzeyi kullanılarak erişilir.
Bellek için optimize edilmiş tablo Table_MO7, SERIALIZABLE izolasyon seviyesi kullanılarak erişilir. Table_MO6 belirli bir ilişkili yalıtım düzeyine sahip değildir, çünkü eklemeler her zaman tutarlıdır ve temelde serileştirilebilir yalıtım altında yürütülür.

-- Different isolation levels for
-- disk-based tables versus memory-optimized tables,
-- within one explicit transaction.

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
go

BEGIN TRANSACTION;

    -- Table_D1 is a traditional disk-based table, accessed using READ COMMITTED isolation.

    SELECT * FROM Table_D1;


    -- Table_MO6 and Table_MO7 are memory-optimized tables.
    -- Table_MO7 is accessed using SERIALIZABLE isolation,
    --   while Table_MO6 does not have a specific isolation level.

    INSERT Table_MO6
        SELECT * FROM Table_MO7 WITH (SERIALIZABLE);

COMMIT TRANSACTION;
go

Sınırlamalar

Bellek ile optimize edilmiş tablolar için veritabanları arası işlemler desteklenmez. Bir işlem bellek için iyileştirilmiş bir tabloya erişiyorsa, işlem aşağıdakiler dışında başka bir veritabanına erişemez:
- tempdb veritabanı.
- Ana veritabanından yalnızca okuma yapılabilir.
Dağıtılmış işlemler desteklenmez: BEGIN DISTRIBUTED TRANSACTION kullanıldığında, işlem bellek için iyileştirilmiş bir tabloya erişemez.

Yerel Olarak Derlenmiş Saklı Yordamlar

Yerel bir proc'da ATOMIC bloğunun, bloğun tamamı için işlem yalıtım düzeyini bildirmesi gerekir, örneğin:
- ... BEGIN ATOMIC WITH (TRANSACTION ISOLATION LEVEL = SNAPSHOT, ...) ...
Yerel işlem gövdesinde açık işlem kontrol ifadelerine izin verilmez. BEGIN TRANSACTION, ROLLBACK TRANSACTION vb. tümüne izin verilmiyor.
ATOMIC blokları ile işlem denetimi hakkında daha fazla bilgi için bkz . Atomik Bloklar

Diğer İşlem Bağlantıları

Geri Bildirim

Bu sayfayı yararlı buldunuz mu?

Last updated on 2025-10-10