Veritabanı için işlem günlüğü dolu

Tam süre boyunca bir işlemi açık tutan uzun süren bir işlemim var.

Bunun uygulanma şekli üzerinde hiçbir kontrolüm yok.

Bir işlem tam süre boyunca açık tutulduğundan, işlem günlüğü dolduğunda, SQL Server günlük dosyasının boyutunu artıramaz.

Yani süreç hata vererek başarısız oluyor "The transaction log for database 'xxx' is full".

Veritabanı özelliklerinde işlem günlüğü dosyasının boyutunu artırarak bunu önlemeye çalıştım, ancak aynı hatayı alıyorum.

Bundan sonra ne denemem gerektiğinden emin değilim. İşlem birkaç saat sürer, bu nedenle deneme yanılma ile oynamak kolay değildir.

Herhangi bir fikir?

İlgilenen biri varsa, süreç, Microsoft Dynamics CRM 4.0.

Bol miktarda disk alanı var, günlük kaydı basit günlük modunda var ve işlemi başlatmadan önce günlüğü yedekledik.

- = - = - = - = - GÜNCELLEME - = - = - = - = -

Şimdiye kadarki yorumlar için hepinize teşekkürler. Aşağıdakiler, açık işlem nedeniyle günlüğün büyümeyeceğine inanmamı sağladı:

Aşağıdaki hatayı alıyorum...

Import Organization (Name=xxx, Id=560d04e7-98ed-e211-9759-0050569d6d39) failed with Exception:
System.Data.SqlClient.SqlException: The transaction log for database 'xxx' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases

Bu tavsiyeye uyarak " log_reuse_wait_desc column in sys.databases" bölümüne gittim ve değeri korudu "ACTIVE_TRANSACTION .

Microsoft'a göre: http://msdn.microsoft.com/en-us/library/ms345414(v=sql.105).aspx

Bu şu anlama gelir:

Bir işlem etkin (tüm kurtarma modelleri). • Günlük yedeklemenin başlangıcında uzun süren bir işlem olabilir. Bu durumda, alanı boşaltmak başka bir günlük yedeklemesi gerektirebilir. Daha fazla bilgi için, bu konunun ilerisindeki "Uzun Süreli Aktif İşlemler" konusuna bakın.

• Bir işlem ertelendi (yalnızca SQL Server 2005 Enterprise Edition ve sonraki sürümler). Ertelenmiş bir işlem, bazı mevcut olmayan kaynaklar nedeniyle geri dönüşü engellenen etkin bir işlemdir. Ertelenen işlemlerin nedenleri ve bunların ertelenmiş durumdan nasıl çıkarılacağı hakkında bilgi için bkz. Ertelenmiş İşlemler.

Bir şeyi yanlış mı anladım?

- = - = - = - GÜNCELLEME 2 - = - = - = -

Başlangıç ​​günlük dosyası boyutu 30 GB olarak ayarlanmış olarak süreci başlattı. Bu işlemin tamamlanması birkaç saat sürecektir.

- = - = - = - Son GÜNCELLEME - = - = - = -

Sorun aslında tüm kullanılabilir disk alanını tüketen günlük dosyasından kaynaklanıyordu. Son denemede 120GB'ı serbest bıraktım ve hala hepsini kullandı ve sonuçta başarısız oldu.

Bunun daha önce olduğunu fark etmemiştim çünkü süreç bir gecede çalışırken, başarısızlık üzerine geri dönüyordu. Bu sefer geri dönüşten önce günlük dosyasının boyutunu kontrol edebildim.

Girdiğiniz bütün veriler için teşekkürler.

Bu tek seferlik bir senaryo mu yoksa düzenli olarak gerçekleşen bir iş mi?

Geçmişte, günlük dosyası için geçici olarak çok fazla alan gerektiren özel projeler için, ikinci bir günlük dosyası oluşturdum ve onu çok büyük hale getirdim. Proje tamamlandığında fazladan günlük dosyasını kaldırdık.

Bu sorunu çözmek için, Kurtarma Modelini Basit olarak değiştirin ve ardından Küçült Dosyalar giriş

1. Veritabanı Özellikleri> Seçenekler> Kurtarma Modeli> Basit

2. Veritabanı Görevleri> Küçült> Dosyalar> Günlük

Bitti.

Ardından, db günlük dosyanızın boyutunu kontrol edin. Veritabanı Özellikleri> Dosyalar> Veritabanı Dosyaları> Yol'dan

Tam sql sunucu günlüğünü kontrol etmek için: SSMS> Veritabanı> Yönetim> SQL Sunucu Günlükleri> Geçerli'de Günlük Dosyası Görüntüleyiciyi açın

Bu hatayı bir kez yaşadım ve bu, sunucunun disk alanı tükenen sabit sürücüsü oldu.

Eğer var mı Autogrowth etkinleştirme ve Sınırsız Dosya Büyüme günlük dosyası için hem etkin? Bunları SSMS aracılığıyla "Veritabanı Özellikleri> Dosyalar" altında düzenleyebilirsiniz.

Bu eski bir yaklaşımdır, ancak yinelemeli bir güncelleme yapıyorsanız veya SQL'de uzun süre çalışan bir işlem yapıyorsanız, periyodik olarak (programlı olarak) "denetim noktası" olarak adlandırmak iyi bir fikirdir. "Denetim noktası" nın çağrılması, SQL'in tüm bu yalnızca bellek değişikliklerini (kirli sayfalar, çağrılırlar) ve işlem günlüğünde depolanan öğelerin diske yazmasına neden olur. Bu, işlem günlüğünüzü periyodik olarak temizleme etkisine sahiptir, böylece anlatılana benzer sorunları önler.

Aşağıdakiler günlüğü kesecektir.

USE [yourdbname] 
GO

-- TRUNCATE TRANSACTION LOG --
DBCC SHRINKFILE(yourdbname_log, 1)
BACKUP LOG yourdbname WITH TRUNCATE_ONLY
DBCC SHRINKFILE(yourdbname_log, 1)
GO

-- CHECK DATABASE HEALTH --
ALTER FUNCTION [dbo].[checker]() RETURNS int AS BEGIN  RETURN 0 END
GO

Veritabanı kurtarma modeliniz doluysa ve bir günlük yedekleme bakım planınız yoksa, bu hatayı alırsınız çünkü işlem günlüğü LOG_BACKUP .

Bu, bu veritabanı üzerinde herhangi bir eylemi (örn. Küçültme) engeller ve SQL Server Veritabanı Motoru 9002 hatası verir.

Bu davranışın üstesinden gelmek için şunu kontrol etmenizi tavsiye ederim. 'SharePoint_Config' veritabanı işlem günlüğü , sorunu çözmek için ayrıntılı adımları gösteren LOG_BACKUP nedeniyle dolu .

Disk alanını boşaltmak için veritabanımdaki tablolardan eski satırları silerken, "ACTIVE_TRANSACTION" nedeniyle "veritabanı için işlem günlüğü" ... "hatasıyla karşılaştım. Bu hatanın, satır sayısı kadar silinmesi benim durumumda 1000000'den büyüktü, dolayısıyla 1 DELETE deyimi kullanmak yerine DELETE TOP (1000000) .... deyimini kullanarak silme görevini böldüm.

Örneğin:

bu ifadeyi kullanmak yerine:

DELETE FROM Vt30 WHERE Rt < DATEADD(YEAR, -1, GETDATE())

aşağıdaki ifadeyi tekrar tekrar kullanarak:

DELETE TOP(1000000) FROM Vt30 WHERE Rt < DATEADD(YEAR, -1, GETDATE())

Sınırlı sayıda silme işleminin birden çok yapılmasıyla sorunum çözüldü gibi

Önce

DELETE FROM TableName WHERE Condition

Sonra

DELETE TOP(1000) FROM TableName WHERECondition

Sorunun cevabı bir tablodan satırları silmek değil, aktif bir işlem nedeniyle kaplanan tempDB alanıdır. bu çoğunlukla güncelleme eklemeye ve işlemleri silmeye çalıştığımız bir birleştirme (upsert) çalıştırıldığında gerçekleşir. Tek seçenek, DB'nin basit kurtarma modeline ayarlandığından emin olmak ve ayrıca dosyayı maksimum alana çıkarmaktır (Başka bir dosya grubu ekleyin). Bunun kendine özgü avantajları ve dezavantajları olmasına rağmen, bunlar tek seçenektir.

Sahip olduğunuz diğer seçenek, birleştirmeyi (yukarı kaldırmayı) iki işleme ayırmaktır. biri eklemeyi yapan, diğeri güncellemeyi ve silmeyi yapan.

Bunu dene:

USE YourDB;  
GO  
-- Truncate the log by changing the database recovery model to SIMPLE.  
ALTER DATABASE YourDB
SET RECOVERY SIMPLE;  
GO  
-- Shrink the truncated log file to 50 MB.  
DBCC SHRINKFILE (YourDB_log, 50);  
GO  
-- Reset the database recovery model.  
ALTER DATABASE YourDB
SET RECOVERY FULL;  
GO 

Umut ediyorum bu yardım eder.

İşte benim kahraman kodum. Bu problemle karşılaştım. Ve bunu düzeltmek için bu kodu kullanın.

 USE master;

    SELECT 
        name, log_reuse_wait, log_reuse_wait_desc, is_cdc_enabled 
    FROM 
        sys.databases 
    WHERE 
        name = 'XX_System';

    SELECT DATABASEPROPERTYEX('XX_System', 'IsPublished');


    USE XX_System;
    EXEC sp_repldone null, null, 0,0,1;
    EXEC sp_removedbreplication XX_System;


    DBCC OPENTRAN;
    DBCC SQLPERF(LOGSPACE);
    EXEC sp_replcounters;



    DBCC SQLPERF(LOGSPACE);

Bunu dene:

Mümkünse MSSQLSERVER ve SQLSERVERAGENT hizmetlerini yeniden başlatın .