Làm thế nào để thu hẹp tệp nhật ký SQL Server ảnh hưởng đến hiệu suất?


19

Tôi có cơ sở dữ liệu SQL Server 2008 có tệp dữ liệu có kích thước khoảng 2 GB, nhưng tệp nhật ký có dung lượng trên 8GB. Với cơ sở dữ liệu trước năm 2008, tôi có thể sử dụng 'Nhật ký sao lưu' và TRUNCATE_ONLYtùy chọn nhưng điều này không còn khả dụng với cơ sở dữ liệu 2008 và mới hơn.

Tôi có một đoạn mã cắt tệp nhật ký:

USE [MyDatabase]
GO
ALTER DATABASE [MyDatabase] SET RECOVERY SIMPLE WITH NO_WAIT
DBCC shrinkfile('MyDatabase_log', 1)
ALTER DATABASE [MyDatabase] SET RECOVERY FULL WITH NO_WAIT
GO

Điều này cắt ngắn hoàn toàn tệp nhật ký, nhưng câu hỏi của tôi là: Điều này có ảnh hưởng đến hiệu suất không?

Tôi thực hiện hai bản sao lưu đầy đủ hàng ngày để nhật ký không thực sự cần thiết khi có liên quan đến việc cuộn dữ liệu.

Câu trả lời:


26

Tôi thực sự khuyên bạn nên đọc Tầm quan trọng của việc quản lý kích thước nhật ký giao dịch phù hợp của Paul S. Randal.

Điều tinh túy là chỉ có hai cách thực sự tốt để xử lý nhật ký giao dịch :

  1. Hoặc là đi với các bản sao lưu tệp LOG thông thường và tệp LOG sẽ sử dụng lại không gian của nó sau mỗi lần sao lưu LOG ​​và sẽ không tăng lên vô thời hạn, hoặc

  2. Sử dụng mô hình khôi phục SIMPLE và bạn không phải quan tâm đến kích thước tệp LOG của mình, vì bạn thường xuyên sao lưu toàn bộ.

Điều đáng quan tâm về việc cắt ngắn và hiệu suất của tệp LOG là bạn sẽ luôn nhận được một cú đánh hiệu suất khi tệp LOG được tăng lên (trích dẫn từ bài đăng trên blog được liên kết ở trên):

Nếu bạn thu nhỏ nhật ký, thì nó sẽ tăng trở lại - có thể gây ra sự phân mảnh VLF và chắc chắn khiến khối lượng công việc của bạn tạm dừng trong khi nhật ký tăng lên, vì nhật ký không thể sử dụng khởi tạo tức thì [...]

Cập nhật: Không nhầm lẫn cắt bớt tệp LOG cho thu nhỏ tệp DATA. Thu hẹp tập tin DATA thực sự là xấu. Xem lý do tại sao bạn không nên thu nhỏ các tệp dữ liệu của mình để biết chi tiết.


URL tới Tại sao bạn không nên thu nhỏ các tệp dữ liệu của mình đã thay đổi. sqlskills.com/bloss/paul/ trên
ripvlan

như có URL để Tầm quan trọng của quản lý kích thước nhật ký giao dịch phù hợp: sqlskills.com/bloss/paul/ trên
ripvlan

6

Trước tiên, có, nhật ký là cần thiết ngay cả với các bản sao lưu đầy đủ hàng ngày nếu bạn muốn phục hồi trong trường hợp xảy ra sự cố. Chúng tôi sao lưu giao dịch của chúng tôi cứ sau 15 phút. Vấn đề là bạn không sao lưu nhật ký giao dịch của mình và đó là lý do tại sao nhật ký phát triển quá mức. Bạn gần như không bao giờ cần phải thu nhỏ nhật ký giao dịch nếu bạn đang thực hiện sao lưu giao dịch chính xác.

Bạn sẽ cần sao lưu cơ sở dữ liệu trước khi cắt bớt nhật ký. Tôi khuyên bạn nên thực hiện vào giờ nghỉ để không có dữ liệu mới nào được chèn giữa bản sao lưu và phần cắt. Sau đó thiết lập sao lưu nhật ký giao dịch thích hợp để bạn không bao giờ gặp vấn đề này nữa.

Về việc ảnh hưởng đến hiệu suất, mà không biết chi tiết về phần cứng và cách sử dụng hệ thống của bạn, điều đó thật khó nói.


4

Làm thế nào nhanh chóng để nhật ký giao dịch phát triển? Nếu nó khá nhanh, bạn sẽ ảnh hưởng đến hiệu suất bằng cách thu nhỏ nó xuống gần như không có gì, vì nó phải mất thời gian để phát triển trở lại. Điều này không có nghĩa là bạn không nên thu nhỏ nó theo thời gian, nhưng bạn phải suy nghĩ về vấn đề kích thước thay vì chỉ thu nhỏ xuống mức tối thiểu. Là sự hoàn hảo lớn? Có thể là không, nhưng nó phụ thuộc vào tải trên máy chủ (số lượng giao dịch, v.v.).

Một điều tôi thấy có vấn đề là "Tôi thực hiện 2 lần sao lưu đầy đủ hàng ngày nên nhật ký không thực sự cần thiết khi có liên quan đến việc cuộn dữ liệu." Nhật ký là cực kỳ quan trọng đối với các điểm giữa các bản sao lưu đầy đủ của bạn. Thậm chí hai lần một ngày không loại bỏ nhu cầu về tệp nhật ký để khắc phục thảm họa, trừ khi đây là cơ sở dữ liệu chỉ đọc (nếu có, bạn sẽ không thấy sự gia tăng lớn trong tệp nhật ký).


Nhật ký mất khoảng 4 - 6 tháng để có kích thước này, vì vậy nó không nhanh lắm. Tôi nghĩ (có thể không chính xác) rằng tệp nhật ký giữ các giao dịch giữa các bản sao lưu đầy đủ, đó là lý do tại sao tôi đã đề cập rằng tôi thực hiện 2 bản sao lưu đầy đủ mỗi ngày nên nội dung của nhật ký giữa không thể quá lớn. Như tôi đã nói, tôi có thể đã hiểu nhầm khái niệm tệp nhật ký.
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.