Trong hai bài viết cuối cùng của tôi, tôi đã thảo luận về các cách để giảm số lượng nhật ký giao dịch được tạo và cách đảm bảo nhật ký giao dịch luôn có thể rõ ràng đúng cách. Trong bài đăng này, tôi muốn tiếp tục với chủ đề hiệu suất nhật ký giao dịch và thảo luận về một số vấn đề cấu hình nhật ký giao dịch có thể gây ra sự cố.
Quá nhiều VLF
Nhật ký giao dịch được chia thành nhiều phần được gọi là tệp nhật ký ảo (VLF) để hệ thống quản lý nhật ký có thể dễ dàng theo dõi phần nào của nhật ký giao dịch có sẵn để sử dụng lại. Có một công thức cho số lượng VLF bạn nhận được khi tạo nhật ký giao dịch, phát triển thủ công hoặc tự động phát triển:
| Lên đến 1MB | 2 VLF, mỗi VLF chiếm khoảng 1/2 tổng kích thước |
|---|---|
| 1MB đến 64MB | 4 VLF, mỗi VLF chiếm khoảng 1/4 tổng kích thước |
| 64MB đến 1GB | 8 VLF, mỗi VLF chiếm khoảng 1/8 tổng kích thước |
| Hơn 1GB | 16 VLF, mỗi VLF khoảng 1/16 tổng kích thước |
Ví dụ:nếu bạn tạo nhật ký giao dịch có dung lượng 8GB, bạn sẽ nhận được 16 VLF trong đó mỗi VLF có dung lượng khoảng 512MB. Sau đó, nếu bạn tăng nhật ký thêm 4GB, bạn sẽ nhận được thêm 16 VLF với mỗi VLF khoảng 256MB, với tổng số 32 VLF.
Lưu ý:thuật toán này đã thay đổi một chút đối với SQL Server 2014 để giảm bớt sự cố phân mảnh VLF - xem bài đăng blog này để biết chi tiết
Một phương pháp chung tốt nhất là đặt tự động tăng trưởng nhật ký thành thứ gì đó khác với 10% mặc định, để bạn có thể kiểm soát thời gian tạm dừng bắt buộc khi khởi tạo không gian nhật ký giao dịch mới. Giả sử bạn tạo nhật ký giao dịch 256MB và đặt tự động tăng trưởng thành 32MB, sau đó nhật ký phát triển đến kích thước trạng thái ổn định là 16GB. Với công thức trên, điều này sẽ dẫn đến nhật ký giao dịch của bạn có hơn 2.000 VLF.
Nhiều VLF này có thể sẽ dẫn đến một số vấn đề về hiệu suất cho các hoạt động xử lý nhật ký giao dịch (ví dụ:khôi phục sự cố, xóa nhật ký, sao lưu nhật ký, sao chép giao dịch, khôi phục cơ sở dữ liệu). Tình huống này được gọi là có sự phân mảnh VLF. Nói chung, bất kỳ số lượng VLF nào nhiều hơn một nghìn hoặc hơn đều sẽ có vấn đề và cần được giải quyết (số lượng nhiều nhất tôi từng nghe nói là 1,54 triệu VLF trong nhật ký giao dịch có kích thước hơn 1TB!).
Cách để biết bạn có bao nhiêu VLF là sử dụng DBCC LOGINFO không có giấy tờ (và hoàn toàn an toàn) yêu cầu. Số hàng đầu ra là số lượng VLF trong nhật ký giao dịch của bạn. Nếu bạn nghĩ rằng bạn có quá nhiều, cách để giảm bớt chúng là:
- Cho phép xóa nhật ký
- Thu nhỏ nhật ký theo cách thủ công
- Lặp lại các bước 1 và 2 cho đến khi nhật ký đạt kích thước nhỏ (điều này có thể phức tạp đối với hệ thống sản xuất bận rộn)
- Phát triển nhật ký theo cách thủ công đến kích thước cần thiết, với các bước lên đến 8GB để mỗi VLF không lớn hơn khoảng 0,5GB
Bạn có thể đọc thêm về các vấn đề phân mảnh VLF và quy trình khắc phục chúng tại:
- Bài viết KB của Microsoft khuyên giảm số lượng VLF
- Việc phát triển tệp nhật ký có thể ảnh hưởng đến DML không?
- 8 bước để thông lượng nhật ký giao dịch tốt hơn
Tempdb
Tempdb cần phải cấu hình nhật ký giao dịch của nó giống như bất kỳ cơ sở dữ liệu nào khác và nó có thể phát triển giống như bất kỳ cơ sở dữ liệu nào khác. Nhưng nó cũng có một số hành vi ngấm ngầm có thể khiến bạn gặp sự cố.
Khi một phiên bản SQL Server khởi động lại vì bất kỳ lý do gì, dữ liệu tempdb và tệp nhật ký sẽ hoàn nguyên về kích thước mà chúng được đặt gần đây nhất. Điều này khác với tất cả các cơ sở dữ liệu khác, vẫn ở kích thước hiện tại sau khi khởi động lại phiên bản.
Hành vi này có nghĩa là nếu nhật ký giao dịch tempdb đã phát triển để đáp ứng khối lượng công việc bình thường, bạn phải thực hiện ALTER DATABASE để đặt kích thước tệp nhật ký, nếu không, kích thước của nó sẽ giảm sau khi khởi động lại phiên bản và nó sẽ phải phát triển trở lại. Mỗi khi tệp nhật ký phát triển hoặc tự động phát triển, không gian mới phải được khởi tạo bằng 0 và hoạt động ghi nhật ký sẽ tạm dừng trong khi hoàn tất. Vì vậy, nếu bạn không quản lý chính xác kích thước tệp nhật ký tempdb của mình, bạn sẽ phải trả một khoản tiền phạt về hiệu suất khi nó tăng lên sau mỗi lần khởi động lại phiên bản.
Tệp nhật ký thông thường đang thu hẹp
Tôi thường nghe mọi người nói cách họ thường thu nhỏ nhật ký giao dịch của cơ sở dữ liệu sau khi nó phát triển từ một hoạt động thông thường (ví dụ:nhập dữ liệu hàng tuần). Đây không phải là điều tốt nên làm.
Như tôi đã giải thích ở trên, bất cứ khi nào nhật ký giao dịch phát triển hoặc tự động phát triển, sẽ có một khoảng dừng trong khi phần mới của tệp nhật ký không được khởi tạo. Nếu bạn thường xuyên thu nhỏ nhật ký giao dịch vì nó phát triển đến kích thước X, điều đó có nghĩa là bạn thường xuyên gặp phải các vấn đề về hiệu suất khi nhật ký giao dịch tự động phát triển trở lại kích thước X.
Nếu nhật ký giao dịch của bạn tiếp tục tăng đến kích thước X, hãy để nó yên! Chủ động đặt nó thành kích thước X, quản lý VLF của bạn như tôi đã giải thích ở trên và chấp nhận kích thước X là kích thước cần thiết cho khối lượng công việc bình thường của bạn. Nhật ký giao dịch lớn hơn không phải là vấn đề.
Nhiều tệp nhật ký
Không có hiệu suất tăng từ việc tạo nhiều tệp nhật ký cho một cơ sở dữ liệu. Tuy nhiên, việc thêm tệp nhật ký thứ hai có thể là cần thiết, nếu tệp nhật ký hiện có hết dung lượng và bạn không muốn buộc xóa nhật ký giao dịch bằng cách chuyển sang mô hình khôi phục đơn giản và thực hiện một điểm kiểm tra (vì điều này phá vỡ sao lưu nhật ký chuỗi).
Tôi thường được hỏi liệu có bất kỳ lý do cấp bách nào để xóa tệp nhật ký thứ hai hay không hay liệu bạn có thể để nó ở nguyên vị trí đó hay không. Câu trả lời là bạn nên xóa nó càng sớm càng tốt.
Mặc dù tệp nhật ký thứ hai không gây ra sự cố về hiệu suất cho khối lượng công việc của bạn, nhưng nó sẽ ảnh hưởng đến việc khôi phục sau thảm họa. Nếu cơ sở dữ liệu của bạn bị phá hủy vì lý do nào đó, bạn sẽ cần khôi phục lại từ đầu. Giai đoạn đầu tiên của bất kỳ trình tự khôi phục nào là tạo dữ liệu và tệp nhật ký nếu chúng không tồn tại.
Bạn có thể thực hiện việc tạo tệp dữ liệu gần như ngay lập tức bằng cách bật tính năng khởi tạo tệp tức thì bỏ qua quá trình khởi tạo bằng 0 nhưng điều đó không áp dụng cho tệp nhật ký. Điều này có nghĩa là quá trình khôi phục phải tạo tất cả các tệp nhật ký tồn tại khi bản sao lưu đầy đủ được thực hiện (hoặc được tạo trong khoảng thời gian được sao lưu nhật ký giao dịch) và không khởi tạo chúng. Nếu đã tạo tệp nhật ký thứ hai và quên thả lại, việc không khởi tạo tệp đó trong quá trình khôi phục thảm họa sẽ thêm vào tổng thời gian ngừng hoạt động. Đây không phải là vấn đề về hiệu suất khối lượng công việc, nhưng nó ảnh hưởng đến tính khả dụng của toàn bộ máy chủ.
Hoàn nguyên từ Ảnh chụp cơ sở dữ liệu
Vấn đề cuối cùng trong danh sách của tôi thực sự là một lỗi trong SQL Server. Nếu bạn sử dụng snapshot cơ sở dữ liệu như một cách để nhanh chóng khôi phục trở lại thời điểm đã biết mà không cần phải khôi phục các bản sao lưu (được gọi là hoàn nguyên từ snapshot) thì bạn có thể tiết kiệm được rất nhiều thời gian. Tuy nhiên, có một nhược điểm lớn.
Khi cơ sở dữ liệu hoàn nguyên từ ảnh chụp nhanh cơ sở dữ liệu, nhật ký giao dịch được tạo lại bằng hai VLF 0,25MB. Điều này có nghĩa là bạn sẽ phải phát triển nhật ký giao dịch của mình trở lại kích thước và số lượng VLF tối ưu (hoặc nó sẽ tự phát triển), với tất cả các lần tạm dừng không khởi tạo và khối lượng công việc mà tôi đã thảo luận trước đây. Rõ ràng không phải là hành vi mong muốn.
Tóm tắt
Như bạn có thể thấy từ bài đăng này và hai bài viết trước của tôi, có nhiều điều có thể dẫn đến hiệu suất nhật ký giao dịch kém, sau đó ảnh hưởng trực tiếp đến hiệu suất của khối lượng công việc tổng thể của bạn.
Nếu bạn có thể đảm nhận tất cả những điều này, bạn sẽ có nhật ký giao dịch tốt. Nhưng nó không kết thúc ở đó vì bạn cần đảm bảo rằng bạn đang theo dõi nhật ký giao dịch của mình để bạn được cảnh báo về những thứ như tự động phát triển và độ trễ I / O đọc và ghi quá mức. Tôi sẽ trình bày cách thực hiện điều đó trong một bài đăng trong tương lai.
