'Database_name' veritabanı için işlem günlüğü 'XTP_CHECKPOINT' nedeniyle dolu


26

Bir sorum var XTP_CHECKPOINT.

SQL Server 2014 kullanıyorum. SIMPLE kurtarma modeli modunda bir veritabanına sahibim. Aynı zamanda kopyalanmaktadır.

Açık işlem yok. Koştum DBCC OPENTRANve döner:

"Etkin açık işlem yok."

Ancak ne zaman bir tablo oluşturmaya, bırakmaya ya da verileri silmeye çalıştığımda bu mesajı almaya devam ediyorum:
(Asıl veritabanı adımı kelimeyle değiştirdim database_name)

"'Database_name' veritabanı için işlem günlüğü 'XTP_CHECKPOINT' nedeniyle dolu"

Bunun neden olduğunu bilen var mı ve daha da önemlisi bunu nasıl durdurabilirim?

Ve evet, veritabanı gerçekten BASİT kurtarma modeli modunda. Yani işlem günlüğü otomatik olarak kesilmelidir.

Bu arada, tam kurtarma modunda bulunduğum başka bir veritabanı da aynı şeyi yaptı, aynı hatayı döndürmeye başladı:

'Database_name' veritabanı için işlem günlüğü 'XTP_CHECKPOINT' nedeniyle dolu

Günlük büyüme ayarlarını sınırsız büyüme olarak değiştirmeye çalıştım, ancak aynı hatayı geri getirmeme izin vermedi.

Sadece dosya grubu dışında herhangi bir XTP olayı olmadan sorunu yeniden oluşturabilirim. İşte nasıl: http://pastebin.com/jWSiEU9U

Yanıtlar:


8

Ben de benzer bir problem yaşadım: Çoğaltma yapmamıştım, ancak bir keresinde Bellek İyileştirilmiş tabloyu test olarak, Basit kurtarma modunda veritabanı olarak kullandım, ancak işlem günlüklerim kesilmedi. Tam bir yedeklemeden hemen sonra bile manuel kesme, hatayı verdi:

X dosyasının günlük dosyası daraltılamıyor çünkü dosyanın sonunda bulunan mantıksal günlük dosyası kullanılıyor.

Manuel bir kontrol noktası başarısız oldu:

Msj 41315, Seviye 16, Durum 4, Satır N Denetim noktası işlemi X veritabanında başarısız oldu.

Manuel bir kontrol noktası yalnızca, SQL Servisini yeniden başlattıktan hemen sonra başardı; bu, Multi Tb veritabanı boyutum nedeniyle 4 saatlik bir In Kurtarma durumuna yol açacaktı. Ayrıca otomatik büyümeyi belirli bir boyuta ayarlamaya çalıştım, ancak hepsi aynı şeyi yaptı: boşluk kalmadan önce işlem kayıtlarını doldurun.

Son olarak, günler ve geceler denemeye ve araştırmaya devam ettikten sonra, sorunumun çözümünü SQL Server 2014 SP1 için Toplu Güncelleştirme 3'ü yükleyerek buldum


9

Öncelikle, bağlantı öğesinde belirtildiği gibi çoğaltmanın buna neden olmadığından emin olun , "log_wait_reuse_desc = XTP_CHECKPOINT, XTP denetim noktası çalışanının günlük kesmeyi tuttuğu anlamına gelmez". bu nedenle çalıştırmaya başlayın sp_repltransve tüm verilerin dağıtıldığından emin olun.

Sonra burada bu küçük pasaj var:

msgstr "" "Belleği en iyi duruma getirilmiş dosya grubuna sahip olan bir veritabanında, belleği en iyi duruma getirilmiş tablolara sahip olsun ya da olmasın, öyle olur".

Geçerli geçici çözüm, AutoGrown'u sabit bir boyuta ayarladı. Veya kurtarma modunu Basit olarak değiştirmek ve günlüğü küçültmek. "

Bu nedenle, çoğaltmanın temizlenmesi işe yaramazsa aşağıdakileri deneyin:

checkpoint;
dbcc shrinkfile (Logfile, truncateonly)
alter database [database] modify file (filename = 'TRANSACTIONLOG', FILEGROWTH = 5MB)

Bunun günlük dosyası mı yoksa veritabanı dosyaları mı olduğu belirtilmemiştir, ancak günlük dosyalarını deneyerek başlayalım ve daha sonra veritabanı dosyalarını sabit bir büyüme olarak ayarlamayı deneyelim:


3

XTP_CHECKPOINT sorununu çözmek için eklenen fazladan günlük dosyasını kaldırarak daha sonra tam bir yedekleme yapmamı, birincil günlük dosyası boyutunu ayarlamanızı ve büyümeyi sınırlandırmamı sağlayan başka bir günlük dosyası ekleyerek sorunu gidermeyi başardım.


1

Bunu bir müşteriyle yaşadım. Günlük ve bellekteki FILESTREAM veri dosyaları aynı sürücüdeydi. Yeni bir günlük dosyası oluşturdular (birkaçı bunu önerdiler) ancak sistem bellek içi kontrol noktası dosyalarını (* .HKCKP) oluşturamadığından CHECKPOINT yapamıyor.

Bellek içi FILESTREAM verileriyle sürücüde yer boşaltmayı deneyin.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.