Nhật ký giao dịch cho cơ sở dữ liệu đã đầy

Tôi có một quá trình hoạt động lâu dài giữ một giao dịch mở trong toàn bộ thời gian.

Tôi không kiểm soát được cách thức thực thi điều này.

Bởi vì giao dịch được giữ mở trong toàn bộ thời gian, khi nhật ký giao dịch đầy, SQL Server không thể tăng kích thước của tệp nhật ký.

Vì vậy, quá trình không thành công với lỗi "The transaction log for database 'xxx' is full".

Tôi đã cố gắng ngăn chặn điều này bằng cách tăng kích thước của tệp nhật ký giao dịch trong thuộc tính cơ sở dữ liệu, nhưng tôi gặp lỗi tương tự.

Không chắc chắn những gì tôi nên thử tiếp theo. Quá trình chạy trong vài giờ nên không dễ để chơi thử và sai sót.

Bất kỳ ý tưởng?

Nếu bất kỳ ai quan tâm, quá trình này là một tổ chức nhập vào Microsoft Dynamics CRM 4.0.

Có nhiều dung lượng đĩa, chúng tôi có nhật ký ở chế độ ghi nhật ký đơn giản và đã sao lưu nhật ký trước khi bắt đầu quá trình.

- = - = - = - = - CẬP NHẬT - = - = - = - = -

Cảm ơn tất cả các ý kiến ​​cho đến nay. Sau đây là điều khiến tôi tin rằng nhật ký sẽ không phát triển do giao dịch mở:

Tôi nhận được lỗi sau...

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

Vì vậy, theo lời khuyên đó, tôi đã đi đến " log_reuse_wait_desc column in sys.databases" và nó có giá trị " ACTIVE_TRANSACTION".

Theo Microsoft: http://msdn.microsoft.com/en-us/library/ms345414(v=sql.105).aspx

Điều đó có nghĩa như sau:

Một giao dịch đang hoạt động (tất cả các mô hình khôi phục). • Một giao dịch lâu dài có thể tồn tại khi bắt đầu sao lưu nhật ký. Trong trường hợp này, việc giải phóng dung lượng có thể yêu cầu một bản sao lưu nhật ký khác. Để biết thêm thông tin, hãy xem "Giao dịch hoạt động dài hạn", ở phần sau của chủ đề này.

• Giao dịch bị hoãn lại (chỉ dành cho SQL Server 2005 Enterprise Edition và các phiên bản mới hơn). Giao dịch hoãn lại thực sự là một giao dịch đang hoạt động có quá trình khôi phục bị chặn do một số tài nguyên không có sẵn. Để biết thông tin về nguyên nhân của các giao dịch bị hoãn lại và cách chuyển chúng ra khỏi trạng thái hoãn lại, hãy xem Giao dịch bị hoãn lại.

Tôi đã hiểu lầm điều gì đó?

- = - = - = - CẬP NHẬT 2 - = - = - = -

Vừa bắt đầu quá trình với kích thước tệp nhật ký ban đầu được đặt thành 30GB. Quá trình này sẽ mất vài giờ để hoàn thành.

- = - = - = - CẬP NHẬT cuối cùng - = - = - = -

Sự cố thực sự là do tệp nhật ký sử dụng tất cả dung lượng đĩa có sẵn. Trong lần thử cuối cùng, tôi đã giải phóng 120GB và nó vẫn sử dụng tất cả và cuối cùng không thành công.

Tôi đã không nhận ra điều này đã xảy ra trước đây bởi vì khi quá trình chạy qua đêm, nó đã bị lỗi. Lần này tôi đã có thể kiểm tra kích thước tệp nhật ký trước khi khôi phục.

Cảm ơn tất cả các đầu vào của bạn.

Đây là kịch bản một lần hay công việc diễn ra thường xuyên?

Trước đây, đối với các dự án đặc biệt tạm thời yêu cầu nhiều dung lượng cho tệp nhật ký, tôi đã tạo tệp nhật ký thứ hai và làm cho nó lớn. Khi dự án hoàn thành, chúng tôi xóa tệp nhật ký bổ sung.

Để khắc phục sự cố này, hãy thay đổi Mô hình khôi phục thành Đơn giản sau đó Thu nhỏ Nhật ký tệp

1. Thuộc tính cơ sở dữ liệu> Tùy chọn> Mô hình khôi phục> Đơn giản

2. Tác vụ cơ sở dữ liệu> Thu nhỏ> Tệp> Nhật ký

Làm xong.

Sau đó, kiểm tra kích thước tệp nhật ký db của bạn tại Thuộc tính cơ sở dữ liệu> Tệp> Tệp cơ sở dữ liệu> Đường dẫn

Để kiểm tra nhật ký máy chủ sql đầy đủ: mở Trình xem tệp nhật ký tại SSMS> Cơ sở dữ liệu> Quản lý> Nhật ký máy chủ SQL> Hiện tại

Tôi đã gặp lỗi này một lần và nó kết thúc là ổ cứng của máy chủ hết dung lượng đĩa.

Bạn đã Enable autogrowth và không bị giới hạn tập tin tăng trưởng cả kích hoạt cho các tập tin đăng nhập? Bạn có thể chỉnh sửa chúng qua SSMS trong "Thuộc tính cơ sở dữ liệu> Tệp"

Đây là một cách tiếp cận cũ, nhưng nếu bạn đang thực hiện cập nhật lặp đi lặp lại hoặc thao tác chèn trong SQL, một thứ hoạt động trong một thời gian dài, thì bạn nên gọi định kỳ (theo chương trình) gọi "checkpoint". Việc gọi "điểm kiểm tra" khiến SQL ghi vào đĩa tất cả các thay đổi chỉ dành cho bộ nhớ đó (các trang bẩn, chúng được gọi) và các mục được lưu trữ trong nhật ký giao dịch. Điều này có tác dụng làm sạch nhật ký giao dịch của bạn theo định kỳ, do đó ngăn ngừa các vấn đề như mô tả.

Sau đây sẽ cắt ngắn nhật ký.

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

Nếu mô hình khôi phục cơ sở dữ liệu của bạn đã đầy và bạn không có kế hoạch bảo trì sao lưu nhật ký, bạn sẽ gặp lỗi này vì nhật ký giao dịch bị đầy do LOG_BACKUP.

Điều này sẽ ngăn chặn bất kỳ hành động nào trên cơ sở dữ liệu này (ví dụ: thu nhỏ) và Công cụ cơ sở dữ liệu máy chủ SQL sẽ phát sinh lỗi 9002.

Để khắc phục hiện tượng này, tôi khuyên bạn nên kiểm tra mục này Nhật ký giao dịch cho cơ sở dữ liệu 'SharePoint_Config' đã đầy do LOG_BACKUP hiển thị các bước chi tiết để giải quyết vấn đề.

Tôi đã gặp lỗi: "Nhật ký giao dịch cho cơ sở dữ liệu '...' đã đầy do 'ACTIVE_TRANSACTION' trong khi xóa các hàng cũ khỏi các bảng trong cơ sở dữ liệu của tôi để giải phóng dung lượng đĩa. Tôi nhận ra rằng lỗi này sẽ xảy ra nếu số lượng hàng được xóa lớn hơn 1000000 trong trường hợp của tôi. Vì vậy, thay vì sử dụng 1 câu lệnh DELETE, tôi đã chia tác vụ xóa bằng cách sử dụng câu lệnh DELETE TOP (1000000) .....

Ví dụ:

thay vì sử dụng câu lệnh này:

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

sử dụng câu lệnh sau nhiều lần:

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

Vấn đề của tôi đã được giải quyết khi thực hiện nhiều lần xóa giới hạn như

Trước

DELETE FROM TableName WHERE Condition

Sau

DELETE TOP(1000) FROM TableName WHERECondition

Câu trả lời cho câu hỏi không phải là xóa các hàng khỏi bảng mà là không gian tempDB đang được sử dụng do một giao dịch đang hoạt động. điều này chủ yếu xảy ra khi có một hợp nhất (upert) đang được chạy trong đó chúng tôi cố gắng chèn cập nhật và xóa các giao dịch. Tùy chọn duy nhất là đảm bảo DB được đặt thành mô hình khôi phục đơn giản và cũng tăng tệp lên dung lượng tối đa (Thêm một nhóm tệp khác). Mặc dù điều này có những ưu và nhược điểm riêng nhưng đây là những lựa chọn duy nhất.

Tùy chọn khác mà bạn có là chia hợp nhất (nâng cấp) thành hai hoạt động. một cái thực hiện chèn và cái kia cập nhật và xóa.

Thử cái này:

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 

Tôi hy vọng nó sẽ giúp.

Đây là mã anh hùng của tôi. Tôi đã đối mặt với vấn đề này. Và sử dụng mã này để sửa lỗi này.

 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);

Thử cái này:

Nếu có thể, hãy khởi động lại các dịch vụ MSSQLSERVER và SQLSERVERAGENT .