Otomatik büyüme seçeneğini Microsoft SQL Server 2005 ve sonraki sürümleri, SQL Server 2000 ve SQL Server 7.0 ayarlı ise, işlem günlüğü dosyalarının otomatik olarak günlük dosyasının başına 2 terabayt (TB) en büyük günlük dosyası boyutunu genişletebilirsiniz.
Genellikle, denetim noktaları veya işlem günlüğü yedekleri tarafından tetiklenen hareket günlüğü kesilmeleri arasında oluşabilecek en fazla sayıda işlemi tutabildiğinde işlem günlüğü dosyasının boyutu kararlı hale gelir.
Ancak, bazı durumlarda işlem günlüğü çok büyük hale gelir ve çalışma alanı yetersiz hale gelir veya dolar. Genellikle, bir işlem günlüğü dosyası kullanılabilir disk alanını kullanır ve artık genişletilemezse aşağıdaki hata iletisini alırsınız:
Bu hata iletisinin yanı sıra, sql Server veritabanı şüpheli olarak bir işlem günlüğünün genişlemesi alanı yetersizliği nedeniyle işaretleyebilir. Bu durumdan kurtarma hakkında daha fazla bilgi için sql Server Books Online'da "Yetersiz Disk alanı" konusuna bakın.
Ayrıca, işlem günlüğünün genişlemesi için aşağıdaki nedenlerden biri veya aşağıdaki senaryolardan birinde oluşabilir:
İşlem günlüğünün genişlemesi biri aşağıdaki nedenlerden veya senaryolar için oluşabilir.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ş işlemler
Açık hareketler açıkça COMMIT veya ROLLBACK komutu vermek değil kaydedilmemiş kalır. Bu, en sık uygulama iptal etme veya karşılık gelen 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. Bu durumu 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:
295108
Tamamlanmamış bir işlemi çok sayıda kilitler ve büyük/küçük harf engelleme saptanabilir.
171224
KILL Transact-SQL komutu nasıl çalıştığını anlama
Ayrıca, SQL Server Books Online'da "DBCC OPENTRAN" konusuna bakın.Senaryolar kaydedilmemiş hareketleri neden olabilir
:
Çok büyük işlemler
- Tüm varsayar bir uygulama tasarım hataları causerollbacks.
- Adlandırılmış hareketleri veya özel olarak iç içe 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:
Hata iletisi SQL Servergenerates sonra sonraki ifadeye devam eder. Bydesign budur. 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. Notransaction veya o adı noktası bulundu.
Uygulamanızı tasarlarken aşağıdakileri uygulamanızı öneririz:
- Kalem tek 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 kontrol edin.
- 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 açık hareket sonra günlüğe eklenen oturum çünkü.
- Orada verifythat için @@TRANCOUNT açık bir hareket olduğunu denetlemek bir uygulama.
- Ağ veya diğer hatalar için SQL Server istemci applicationconnection bildiren olmadan kapatmak.
- 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 ö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 büyük günlü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şturma nasıl etkinleştirilir
Bir işlem tarafından işlem bazında işlem günlüğü dosyalarını günlük kayıtları kesiliyor. İşlem kapsamı onu kaldırılmaz sonra işlem günlüğünden tamamlanmış sürece hareket ve tüm işlemleri başlatıldı, büyükse. 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 hata 9002 hata iletisi "tam işlem günlüğü" 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. İşlemler: DBCC DBREINDEX ve CREATE INDEX
SQL Server 2000'deki Kurtarma modelindeki değişiklikler nedeniyle, tam kurtarma modu kullanmak ve DBCC DBREINDEX çalıştırdığınızda işlem günlüğü önemli ölçüde daha, SQL Server 7.0 için eşdeğer kurtarma modunda "NSAT. ve SELECT INTO veya BULK COPY ile karşılaştırıldığında genişletmek Üzerinde chkpt. oturumunu".
Bu yaklaşım DBREINDEX işleminden sonra hareket günlüğü boyutu bir sorun olabilir, ancak günlük geri yükleme daha iyi performans sağlar. İşlem günlüğü yedeklerini geri yüklerken
Bu aşağıdaki Microsoft Bilgi Bankası makalesinde açıklanmıştır:
232196
Kullanılan günlük alanı yedekten geri yükledikten sonra büyüyor gibi görünüyor
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 hareket günlüklerini ayarlayın ve hatta toplu işlemleri gerçekleştirdikten sonra hatalarını kurtarıp sağlar, ancak bu işlem günlüklerinin boyutunu 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, oturum açma SQL Server 2000'de SQL Server 7.0 Toplu günlük modunda, ancak kadar onu tam modda daha önemli ölçüde daha fazla alan kullanır. İstemci uygulamaları tüm sonuçları işlemez
Bir sorgunun SQL Server'a vermek ve sonuçları hemen işlemeyen kilitli tutan ve sunucudaki eşzamanlılık azaltır.
Örneğin, sonuç kümesini doldurmak için iki sayfa satırlarını gerektiren bir sorgudur sorun varsayalım. SQL Server ayrıştırır, derler ve sorguyu çalıştırır. Başka bir deyişle, sorgunuzu karşılamak zorunda içeren iki sayfada paylaşılan kilitleri 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 (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. İşlem günlüğü genişletme tamamlanmadan önce sorgular zaman aşımına uğruyor ve yanlış 'Günlük dolu' hata iletileri alıyorsunuz
Yeterli disk alanı olmasına karşın bu durumda, yine "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, bir veritabanı için Otomatik küçültme
seçeneğiniz açıksa, 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:
Çoğaltılmamış hareketler
- Büyüme artış çok küçük.
- Çeşitli nedenlerden dolayı yavaş sunucudur.
- Disk sürücüleri yeterince hızlı değildir.
Ç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ş Kaydedilmemiş hareketleri gibi bu hareketler 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 çoğaltılmamış hareketleri artar sayısı olarak genişletmek devam. DBCC OPENTRAN Transact-SQL başvuru eski çoğaltılmamış 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ını tıklatın:
306769
Düzeltme: Anlık yayımlanan veritabanının işlem günlüğü kesilmiş olamaz
240039
Düzeltme: DBCC OPENTRAN çoğaltma bilgilerini bildirmiyor
198514AlwaysOn ikincil veritabanı için işlem günlüğü kayıtlarının uygulanıyor ' AVAILABILITY_REPLICA'
Düzeltme: Yeni sunucuya geri hareket günlüğüne kalmasına neden olur.
AlwaysOn Kullanılabilirlik etkin gruplar ile SQL Server 2012'de SQL hata günlüğünde iletiden görebilirsiniz:
Hata: 9002, önem derecesi: 17, durum: 9.
Veritabanı için işlem günlüğü ' %. * ls, 'AVAILABILITY_REPLICA' tam
AlwaysOn Kullanılabilirlik grupları 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.
Büyüme kullanılabilirlik veritabanı ve AVAILABILITY_REPLICA oturum için 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ı. Gecikme kesilmesi birincil yineleme veritabanında günlüğe kaydedilen değişiklikleri engeller.Senaryo 2: Yineleme gecikme süresi
İkincil veritabanı günlük dosyasına 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, bu büyük olasılıkla büyüme oturum neden olabilir. 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 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 Panosu kullanabilir 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 Yinele sıra. Bazı anahtar alanları şunlardır:
Not
|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) 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 azdır|
|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 ID sıfırlarla azsa yansıtır. Asıl günlük sıra numarası değil.|
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