ÖNEMLİ: Bu makale, bir kişi tarafından çevrilmek yerine, Microsoft makine-çevirisi yazılımı ile çevrilmiştir. Microsoft size hem kişiler tarafından çevrilmiş, hem de makine-çevrisi ile çevrilmiş makaleler sunar. Böylelikle, bilgi bankamızdaki tüm makalelere, kendi dilinizde ulaşmış olursunuz. Bununla birlikte, makine tarafından çevrilmiş makaleler mükemmel değildir. Bir yabancının sizin dilinizde konuşurken yapabileceği hatalar gibi, makale; kelime dağarcığı, söz dizim kuralları veya dil bilgisi açısından yanlışlar içerebilir. Microsoft, içeriğin yanlış çevrimi veya onun müşteri tarafından kullanımından doğan; kusur, hata veya zarardan sorumlu değildir. Microsoft ayrıca makine çevirisi yazılımını sıkça güncellemektedir.
Orijinal İngilizce makaleyi görüntüleyin: 317375
Not: SQL Server 2005 ve sonraki sürümlerinde, neden hareket günlük alanı kullanılmaz ve işlem günlüğü neden kesilmiş olamaz belirlemek için sys.databases Katalog görünümü log_reuse_wait ve log_reuse_wait_desc sütunlarını gözden geçirebilirsiniz.
Kaydedilmemiş hareketleri
Açık hareketler açıkça COMMIT veya ROLLBACK komutu vermek değil kaydedilmemiş kalır. Bu en sık uygulama iptal etme veya ilgili bir geri alma komutu olmadan KILL Transact-SQL komutu verdiğinde oluşur. Hareket İptal gerçekleşirse, ancak onu geri almaz. Bu nedenle, SQL Server Durdurulan işlem hala açık olduğundan, bundan sonra gerçekleşen her hareket kesemez. Belirli bir zamanda bir veritabanında etkin bir işlem olduğundan emin olmak için DBCC OPENTRAN Transact-SQL başvuru kullanabilirsiniz. Belirli bu senaryo hakkında daha fazla bilgi için Microsoft Bilgi Bankası'ndaki makaleleri görüntülemek üzere aşağıdaki makale numaralarını tıklatın:
Senaryolar kaydedilmemiş hareketleri neden olabilir:
- Tüm hatalar Windows Installer neden varsayar bir uygulama tasarımı.
- Adlandırılmış hareketleri ya da iç içe özel olarak adlandırılmış hareketleri geri geldiğinde, SQL Server davranışı tamamen dikkate almaz bir uygulama tasarımı. İç adlı bir hareketi geri almak çalışırsanız, aşağıdaki hata iletisini alırsınız:SQL Server hata iletisi oluşturduktan sonra bir sonraki ifadeye geçer devam eder. Bu, tasarım gereğidir. Daha fazla bilgi için SQL Server Books Online'da "İç içe geçmiş hareketler" veya "İçinde SQL Server" konusuna bakın.Sunucu: Msg 6401, Level 16, State 1, satır 13 olamaz geri InnerTran. Herhangi bir hareket veya adının noktası bulundu.
Uygulamanızı tasarlarken aşağıdakileri uygulamanızı öneririz:
- Kalem yalnızca bir hareket birimi (başka bir işlem sizin çağırabilir olasılıklarını dikkate alın).
- Bir TAMAMLAMA, geri alma, bir dönüş veya benzer bir komut veya deyimi kesmeden önce @@TRANCOUNT denetleyin.
- Başka bir @@TRANCOUNT "sizin iç içe" ve bir hata oluştuğunda geri alınması için dış @@TRANCOUNT plan varsayımı ile kodunuzu yazın.
- Noktası gözden geçirin ve hareketler için seçenekleri işaretleyin. (Bunlar kilitleri kaldırmak değil!)
- Tam sınama gerçekleştirin.
- Hareketleri içinde kullanıcı etkileşimi sağlayan bir uygulama. Bu işlem uzun süre açık kalmasına neden olur ve bu engelleme nedenleri ve hareket büyüme açık hareket kesilmiş ve yeni hareketler sonra açık hareket günlüğüne eklenir çünkü oturum.
- Bir uygulama @@TRANCOUNT açık bir hareket olduğunu doğrulamak için denetlemez.
- Ağ veya diğer hatalar bildiren olmadan SQL Server istemci uygulama bağlantısını kapatın.
- Bağlantı havuzu oluşturma. Çalışan iş parçacığı oluşturulduktan sonra SQL Server bağlantı Bakımı değil, bunları kullanır. Kullanıcı bağlantısının bir hareket başlatır ve tamamlama ya da aynı iş parçacığı kullanır, sonra hareket ve bağlantı geri alınıyor önce keser, önceki işlem hala açık kalır. Bu durum önceki bir hareketin açık kalacağını kilitleri sonuçlanır ve kesilmesi günlüğündeki hareketleri önler. Bu günlük büyük dosya boyutlarına neden olur. Bağlantı havuzu oluşturma hakkında daha fazla bilgi için Microsoft Bilgi Bankası'ndaki makaleyi görüntülemek üzere aşağıdaki makale numarasını tıklatın:164221 bir ODBC uygulamasında bağlantı havuzu oluşturmayı etkinleştirme hakkında
Genellikle, işlem günlüğü dosyasının boyutunu en fazla sayısını denetim noktaları veya işlem günlüğü yedekleri tarafından tetiklenen hareket günlük truncations arasında gerçekleştirilen işlemler olmuyorsa kararlı hale gelinceye.
Çok büyük ve çalışma alanı yetersiz hale gelir veya tam duruma işlem günlüğü olabilir ancak, bazı durumlarda. Genellikle, bir işlem günlüğü dosyası kullanılabilir disk alanı kullanır ve artık genişletilemiyor aşağıdaki hata iletisini alırsınız:
Veritabanı için günlük dosyası ' %. * ls dolu.
Veritabanı için işlem günlüğü ' %. * ls dolu. Neden günlüğünde alanı tekrar kullanılamaz dışarı bulmak için log_reuse_wait_desc sütununda sys.databases bakın.
Ayrıca, işlem günlüğünün genişlemesi için aşağıdaki nedenlerden ya da aşağıdaki senaryolardan birinde oluşabilir:
- Bir çok büyük bir işlem günlük dosyası.
- İşlemleri başarısız olabilir ve geri almak başlayabilir.
- İşlemlerin tamamlanması uzun sürebilir.
- Performans sorunları oluşabilir.
- Engelleme oluşabilir.
- Veritabanı içinde bir AlwaysOn Kullanılabilirlik grubu katılıyor.
Çok büyük hareketleri
Bir işlem tarafından işlem bazında işlem günlüğü dosyalarını günlük kayıtları kesiliyor. İşlem kapsamı değil kaldırdıktan sonra işlem günlüğünden tamamlanmış sürece hareket ve tüm işlemleri başlatılan büyük ise. Bu büyük günlük dosyalarında neden olabilir. Hareket yeterince büyük ise, günlük dosyası kullanılabilir disk alanı kullanmak ve neden "tam işlem günlüğü" hata 9002 hata iletisi türü. Bu tür bir hata iletisi aldığınızda, yapmanız gerekenler hakkında daha fazla bilgi için bu makalenin "Ek bilgi" bölümüne bakın. Ayrıca, çok fazla zaman ve büyük işlemleri geri almak için SQL Server ek yükü alır.
İşlemleri: DBCC DBREINDEX ve CREATE INDEX
Değişiklikler nedeniyle SQL Server 2000'deki kurtarma modeli tam kurtarma modu kullanın ve DBCC DBREINDEX çalıştırdığınızda işlem günlüğü önemli ölçüde daha, SQL Server 7.0 bir eşdeğer kurtarma modunda "NSAT. ve SELECT INTO veya BULK COPY ile karşılaştırıldığında genişleyebilir Üzerinde chkpt. oturumunu".
DBREINDEX işleminden sonra işlem günlüğünün boyutunu bir sorun olabilir, ancak bu yaklaşımı daha iyi günlük geri yükleme performansı sağlar.
Hareket günlüğü yedekleri geri yüklerken
Bu aşağıdaki Microsoft Bilgi Bankası makalesinde açıklanmıştır:
SQL Server 2000 Bulk-Logged modunu kullanacak şekilde ayarlayın ve BULK COPY veya SELECT INTO deyimi sorun, değiştirilen her ölçüde işaretlenmiş ve sonra işlem günlüğünü yedeklediğinizde yedeklendi. Bu geri yukarı hareket günlüklerini ve toplu işlemler gerçekleştirdiğinizde hatalardan kurtarmalarına olanak verir, ancak bu işlem günlüklerinin boyutunu için ekler. SQL Server 7.0, bu özelliği içermez. Hangi uzantıların değişen yalnızca SQL Server 7.0 kaydeder, ancak gerçek kapsamlarını kaydetmez. Bu nedenle, günlüğü, SQL Server 2000'de SQL Server 7.0 Toplu günlük modunda, ancak kadar tam modda mı daha önemli ölçüde daha fazla alan kullanır.
İstemci uygulamaları tüm sonuçları işlemez
Bir sorgu için SQL Server sorun ve sonuçları hemen işlemeyen kilitli tutan ve sunucuda eşzamanlılık azaltır.
Örneğin, satır, sonuç kümesini doldurmak için iki sayfa gerektiren bir sorgudur sorun varsayalım. SQL Server ayrıştırır, derler ve sorguyu çalıştırır. Başka bir deyişle paylaşılan kilitleri sorgunuz karşılamak için gereken satırları içeren iki sayfada eklenir. Ayrıca, tüm satırlar bir SQL Server TDS paket uyacak varsayalım (sunucu tarafından istemci ile iletiime yöntemi). TDS paketleri doldurmuş ve istemciye gönderilir. İlk sayfa'den tüm satırlar üzerinde TDS paket sığıyorsa, SQL Server bu sayfada paylaşılan kilidi kaldırır ancak ikinci sayfasında paylaşılan kilit bırakır. Sonra SQL Server istemci (örneğin DBNEXTROW/DBRESULTS, SQLNextRow/SQLResults veya FetchLast/FetchFirst kullanarak bunu yapabilirsiniz) daha fazla veri istemek bekler.
Başka bir deyişle, kalan verileri istemci istekleri kadar paylaşılan kilit tutulur. İkinci sayfasından veri isteği diğer işlemler tarafından engellenebilir.
Zaman aşımı false 'Tam günlüğü' hata iletileri alıyorsunuz ve işlem günlüğü genişletme biter önce sorgular
Yeterli disk alanı olmasına karşın bu durumda, hala bir "yetersiz alanı" hata iletisi alırsınız.
Bu durum, SQL Server 7.0 ve SQL Server 2000 için değişir.
Bir sorgu otomatik olarak işlem günlüğü neredeyse doluysa genişletmek işlem günlüğü neden olabilir. Bu ek zaman alabilir ve bir sorgu durdurulmuş olabilir veya bu nedenle, zaman aşımı süresini aşabilir. SQL Server 7.0, bu durumda hata 9002 döndürür. Bu sorun, SQL Server 2000 için geçerli değildir.
SQL Server 2000'de Otomatik küçülme seçeneği açık bir veritabanı varsa, bir çok küçük sırasında işlem günlüğü otomatik olarak genişletmek çalıştığı süresi yoktur. Otomatik küçültme işlevi aynı anda çalışmadığından genişletilemiyor. Bu hata 9002 yanlış örneklerini de neden olabilir.
Genellikle, işlem günlüğü dosyalarının otomatik olarak genişlemesini hızlı bir şekilde gerçekleşir. Ancak, aşağıdaki durumlarda, normalden daha uzun sürebilir:
- Büyüme artış çok küçük.
- Sunucu çeşitli nedenlerden dolayı yavaş olur.
- Disk sürücüleri, yeterince hızlı değil.
Çoğaltılmamış hareketleri
Çoğaltma kullanıyorsanız, publisher veritabanı hareket günlük boyutunu genişletebilirsiniz. Çoğaltılan nesneleri etkiler hareketleri "İçin çoğaltma." olarak işaretlenmiş Bu hareketler, kaydedilmemiş hareketleri gibi günlük okuyucu görev hareketleri dağıtım veritabanına kopyalar ve bunları imler kadar denetim noktası veya sonra işlem günlüğünü geri silinmez. Günlük Okuyucu görev ile ilgili bir sorun bu hareketler Yayımcı veritabanındaki okumasını engeller, işlem günlüğünün boyutunu olmayan yinelenmiş hareketleri artar sayısı olarak genişletmek devam edebilirsiniz. DBCC OPENTRAN Transact-SQL başvuru, eski yinelenmemiş hareketi tanımlamak için kullanabilirsiniz.
Çoğaltılmamış hareketleri ile ilgili sorunları giderme hakkında daha fazla bilgi için SQL Server Books Online'da "sp_replcounters" ve "sp_repldone" konularına bakın.
Daha fazla bilgi için Microsoft Bilgi Bankası'ndaki makaleleri görüntülemek üzere aşağıdaki makale numaralarına tıklayın:
AlwaysOn 'AVAILABILITY_REPLICA' bir ikincil veritabanı için işlem günlüğü kayıtlarının uygulanıyor
AlwaysOn Kullanılabilirlik etkin gruplar ile SQL Server 2012'de SQL hata günlüğünde iletiden görebilirsiniz:
Veritabanı için işlem günlüğü ' %. * ls, 'AVAILABILITY_REPLICA' nedeniyle tam
AlwaysOn Kullanılabilirlik grupları bir ikincil kopya bu veritabanının işlem günlüğü kayıtlarının karşılık gelen bir ikincil veritabanına uyguluyor AVAILABILITY_REPLICA log_reuse_wait gösterir.
Günlük büyüme kullanılabilirlik veritabanı ve AVAILABILITY_REPLICA içinde yol açabilecek iki senaryo vardır ' log_reuse_wait:
Senaryo 1: Gecikme teslim değişiklikleri için ikincil oturum
Bir hareket olduğunda, birincil gerçekleştirilen oturum bloklar gerekir teslim edilebilir ve ikincil veritabanı günlük dosyasına sıkı. Herhangi bir gecikme kesilmesi veritabanındaki birincil yineleme sırasında günlüğe kaydedilen değişiklikleri engeller.
Senaryo 2: Yineleme gecikme süresi
İkincil veritabanı günlük dosyası için sıkı bir kez ayrılmış Yinele iş parçacığı günlük kayıtları geçerlidir.
Yinele işlemi ile oluşturulan işlem günlüğü tutmayı mümkün değilse, büyük olasılıkla büyüme oturum artırabilir. Birincil, ikincil çoğaltma yineleme işlemi arkasında için karşılık gelen bir ikincil veritabanı bu değişiklikleri uygulama ise, hareket günlüğü kesemez mümkün olmayacaktır. Birden fazla ikincil tanımlamak için hangi ikincil veritabanı günlük kesilme geciktirme, ise sys.dm_hadr_database_replica_states dinamik yönetim görünümü truncation_lsn sütun birden fazla ikincil sunucular arasında karşılaştırın.
AlwaysOn panoyu kullanabilirsiniz ve günlük izlemeye yardımcı olmak için sys.dm_hadr_database_replica_states dinamik yönetim görünümleri sıraya gönderme ve sıra yineler. Bazı anahtar alanları şunlardır:
|Alan||Açıklama|
|log_send_queue_size||İkincil yinelemede ulaşan değil günlük kayıtlarını tutar|
|log_send_rate||İkincil veritabanları için günlük kayıtları gönderilme oranı|
|redo_queue_size||Henüz, kilobayt (KB) cinsinden alýnýp değil, ikincil çoğaltma günlük dosyalarında günlük kayıtlarını tutar|
|redo_rate||Hangi günlük kayıtları alýnýp kilobayt (KB) cinsinden belirli bir ikincil veritabanı üzerinde kuru / saniye|
|last_redone_lsn||İkincil veritabanı üzerinde geri alınmış son günlük kaydının asıl günlük sıra numarası. last_redone_lsn her zaman last_hardened_lsn az|
|last_received_lsn||Hangi tarihe kadar tüm günlük blokları bu ikincil veritabanını barındıran ikincil çoğaltma tarafından alınan noktası tanımlama bloğu ID oturum. Bir günlük bloğu kimlik, sıfırlarla azsa yansıtır. Bir asıl günlük sıra numarası değil.|
Not: Sys.dm_hadr_database_replica_states Görünüm hakkında daha fazla bilgi için aşağıdaki TechNet Web sitesine bakın:
http://technet.microsoft.com/en-us/library/ff877972.aspx
- Etkin: Günlük etkin bölümü (kaydedilmemiş) etkin bir işlem temsil eden küçük günlük sıra sayılarını (LSN) başlar. Günlük etkin bölümü en son yazılan LSN sona erer. Etkin günlük herhangi bir parçasını içeren herhangi bir VLFs kabul active VLFs (fiziksel günlüğünde kullanılmayan alanı VLF herhangi bir parçası değildir.).
- KURTARILABİLİR: en eski etkin hareket yalnızca bir dizi kurtarma günlüğü yedekleri korumak gerekli olan önce gelir günlüğü parçası.
- Yeniden kullanılabilir: işlem günlüğü yedekleri korumak değil veya Kütüğü yedeklediyseniz, SQL Server VLFs önce en eski etkin hareket kullanır.
Daha fazla bilgi için SQL Server Books Online'da "İşlem günlüğünün fiziksel yapısı" konusuna bakın. Ayrıca, Diyagram ve bu (Soukup Ron. tartışma sayfasında 190 "İç SQL Server 7.0" görebilirsiniz İç Microsoft SQL Server 7.0, Microsoft Press, 1999) ve ayrıca sayfalarında 182 için 186 "İç SQL Server 2000" (Delaney, Kalen. İç Microsoft SQL Server 2000, Microsoft Press, 2000).
Sunucu bu seçenekleri nasıl etkileyebileceği hakkında daha fazla bilgi için Microsoft Bilgi Bankası'ndaki makaleyi görüntülemek üzere aşağıdaki makale numarasını tıklatın:
İşlem günlüklerinin daraltma hakkında daha fazla bilgi için Microsoft Bilgi Bankası'ndaki makaleleri görüntülemek üzere aşağıdaki makale numaralarını tıklatın:
SQL Server 2005 ve sonraki sürümlerinde günlük alanı büyük miktarda tüketen sorguları bulmaSQL Server 2005 ve sonraki sürümlerinde, günlük alanı büyük miktarda tüketen sorguları bulmak için sys.dm_tran_database_transactions dinamik yönetim görünümü (DMV) kullanabilirsiniz. Sys.dm_tran_database_transactions aşağıdaki sütunlarda DMV yararlı olabilir:
- database_transaction_log_bytes_used
- database_transaction_log_bytes_used_system
- database_transaction_log_bytes_reserved
- database_transaction_log_bytes_reserved_system
- database_transaction_log_record_count
DMV sys.dm_tran_database_transactions hakkında daha fazla bilgi için sys.dm_tran_database_transactions (Transact-SQL) Microsoft Developer Network (MSDN) Web sitesine gidin.
DMV sys.dm_tran_session_transactions hakkında daha fazla bilgi için sys.dm_tran_session_transactions (Transact-SQL) MSDN Web sitesine gidin.
DMV sys.dm_exec_requests hakkında daha fazla bilgi için sys.dm_exec_requests (Transact-SQL) MSDN Web sitesine gidin.
Makale No: 317375 - Son İnceleme: 24 Şub 2017 - Düzeltme: 1