Nhật ký giao dịch là một thành phần thiết yếu và quan trọng của kiến trúc cơ sở dữ liệu. Trong bài viết này, chúng ta sẽ thảo luận về nhật ký giao dịch SQL Server, tầm quan trọng và vai trò của chúng trong quá trình di chuyển cơ sở dữ liệu.
Giới thiệu
Hãy nói về các tùy chọn khác nhau để sao lưu SQL Server. SQL Server hỗ trợ ba loại Sao lưu khác nhau.
1. Toàn bộ
2. Sự khác biệt
3. Nhật ký giao dịch
Trước khi chuyển sang khái niệm nhật ký giao dịch, hãy thảo luận về các kiểu sao lưu cơ bản khác trong SQL Server.
Một bản sao lưu đầy đủ là một bản sao của mọi thứ. Như tên của nó, nó sẽ sao lưu mọi thứ. Nó sẽ sao lưu tất cả dữ liệu, mọi đối tượng của cơ sở dữ liệu như tệp, nhóm tệp, bảng, v.v.:- Bản sao lưu đầy đủ là cơ sở cho bất kỳ loại sao lưu nào khác.
Một bản sao lưu khác biệt sẽ sao lưu dữ liệu đã thay đổi kể từ lần sao lưu đầy đủ cuối cùng.
Tùy chọn thứ ba là Bản sao lưu nhật ký giao dịch, sẽ ghi lại tất cả các câu lệnh mà chúng tôi cấp cho cơ sở dữ liệu trong nhật ký giao dịch. Nhật ký giao dịch là một cơ chế được gọi là “WAL” (Ghi-Ahead-Ghi nhật ký). Nó ghi mọi thông tin vào nhật ký giao dịch đầu tiên và sau đó vào cơ sở dữ liệu. Nói cách khác, quá trình này thường không cập nhật trực tiếp cơ sở dữ liệu. Đây là tùy chọn đầy đủ duy nhất có sẵn với mô hình khôi phục đầy đủ của cơ sở dữ liệu. Trong các mô hình khôi phục khác, dữ liệu là một phần hoặc không có đủ dữ liệu trong nhật ký. Ví dụ:bản ghi nhật ký khi ghi lại bắt đầu của một giao dịch mới (bản ghi nhật ký LOP_BEGIN_XACT) sẽ chứa thời gian giao dịch bắt đầu và các bản ghi nhật ký LOP_COMMIT_XACT (hoặc LOP_ABORT_XACT) sẽ ghi lại thời gian giao dịch được cam kết (hoặc bị hủy bỏ).
Để tìm nội dung của Nhật ký giao dịch trực tuyến, bạn có thể truy vấn hàm sys.fn_dblog.
Hàm hệ thống sys.fn_dblog chấp nhận hai tham số, đầu tiên, LSN bắt đầu và LSN kết thúc của giao dịch. Theo mặc định, nó được đặt thành NULL. Nếu nó được đặt thành NULL, nó sẽ trả về tất cả các bản ghi nhật ký từ tệp nhật ký giao dịch.
USE WideWorldImporters GO SELECT [Current LSN], [Operation], [Transaction Name], [Transaction ID], [Log Record Fixed Length], [Log Record Length] [Transaction SID], [SPID], [Begin Time], * FROM fn_dblog(null,null)
Như chúng ta đã biết, các giao dịch được lưu trữ ở định dạng nhị phân và nó không phải ở định dạng có thể đọc được. Để đọc tệp nhật ký giao dịch ngoại tuyến, bạn có thể sử dụng fn_dump_dblog.
Hãy để chúng tôi truy vấn tệp nhật ký giao dịch để xem ai đã bỏ đối tượng bằng cách sử dụng fn_dump_dblog.
SELECT [Current LSN], [Operation], [Transaction Name], [Transaction ID], SUSER_SNAME ([Transaction SID]) AS DBUser
FROM fn_dump_dblog (
NULL, NULL, N'DISK', 1, N'G:\BKP\AdventureWorks_2016_log.trn',
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT,
DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT)
WHERE
Context IN ('LCX_NULL') AND Operation IN ('LOP_BEGIN_XACT')
AND [Transaction Name] LIKE '%DROP%'
Chúng tôi sẽ sử dụng hàm fn_dblog () để đọc phần hoạt động của nhật ký giao dịch nhằm tìm kiếm hoạt động được thực hiện trên dữ liệu. Sau khi nhật ký giao dịch bị xóa, bạn phải truy vấn dữ liệu từ tệp nhật ký bằng fn_dump_dblog ().
Hàm này cung cấp tập hợp hàng tương tự như fn_dblog (), nhưng có một số chức năng thú vị làm cho nó hữu ích là một số tình huống khắc phục sự cố và khôi phục. Cụ thể, nó không chỉ có thể đọc nhật ký giao dịch của cơ sở dữ liệu hiện tại mà còn có thể đọc các bản sao lưu nhật ký giao dịch trên đĩa hoặc băng.
Để lấy danh sách các đối tượng bị loại bỏ bằng tệp giao dịch, hãy chạy truy vấn sau. Ban đầu, dữ liệu được kết xuất vào bảng tạm thời. Trong một số trường hợp, việc thực thi fun_dump_dblog () mất nhiều thời gian hơn để thực thi. Vì vậy, tốt hơn nên nắm bắt dữ liệu trong bảng tạm thời.
Để lấy ID đối tượng từ cột Thông tin khóa, hãy chạy truy vấn sau.
SELECT * INTO TEMP FROM fn_dump_dblog ( NULL, NULL, N'DISK', 1, N'G:\BKP\AdventureWorks_2016_log.trn', DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT) WHERE [Transaction ID] in( SELECT DISTINCT [Transaction ID] FROM fn_dump_dblog ( NULL, NULL, N'DISK', 1, N'G:\BKP\AdventureWorks_2016_log.trn', DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT) WHERE [Transaction Name] LIKE '%DROP%') and [Lock Information] like '%ACQUIRE_LOCK_SCH_M OBJECT%'
Để lấy ID đối tượng từ cột Thông tin khóa, hãy chạy truy vấn sau.
SELECT DISTINCT [Lock Information],PATINDEX('%: 0%', [Lock Information])+4,(PATINDEX('%:0%', [Lock Information])-PATINDEX('%: 0%', [Lock Information]))-4,
Substring([Lock Information],PATINDEX('%: 0%', [Lock Information])+4,(PATINDEX('%:0%', [Lock Information])-PATINDEX('%: 0%', [Lock Information]))-4) objectid
from temp
Đối tượng_id có thể được tìm thấy bằng cách thao tác với giá trị cột Thông tin Khóa. Để tìm tên đối tượng cho id đối tượng tương ứng, hãy khôi phục cơ sở dữ liệu từ bản sao lưu ngay trước khi bảng bị xóa. Sau khi khôi phục, bạn có thể truy vấn chế độ xem hệ thống để lấy tên đối tượng.
USE AdventureWorks2016; GO SELECT name, object_id from sys.objects WHERE object_id = '1815677516';
Bây giờ, chúng ta hãy xem các dạng khác nhau của cùng một chi tiết giao dịch bằng cách sử dụng sys.dn_dblog, sys.fn_full_dblog. Hàm hệ thống fn_full_dblog chỉ hoạt động với SQL Server 2017.
Truy vấn tìm nạp 10 giao dịch hàng đầu bằng fn_dblog.
SELECT TOP 10 * FROM sys.fn_dblog(null,null)
Từ SQL Server 2017 trở đi, bạn có thể sử dụng fn_full dblog.
SELECT TOP 10 * FROM sys.fn_full_dblog(null,null,DB_ID(),null,null,null,null,NULL)
Bạn có thể tìm hiểu sâu hơn về chức năng hệ thống bằng sp_helptext fn_full_dblog.
Tiếp theo, truy vấn tệp sao lưu bằng hàm hệ thống sử dụng fn_full_dblog. Một lần nữa, điều này chỉ áp dụng từ SQL Server 2017 trở đi.
Khôi phục tại thời điểm
Giả sử rằng bạn có danh sách sao lưu toàn bộ nhật ký và sau đó khi bạn định khôi phục nhật ký, bạn có khả năng thực hiện khôi phục dữ liệu theo thời gian. Vì vậy, trong quá trình khôi phục nhật ký, bạn không nhất thiết phải khôi phục tất cả dữ liệu, bạn có thể khôi phục dữ liệu đó ngay trước hoặc sau bất kỳ giao dịch riêng lẻ nào. Vì vậy, nếu cơ sở dữ liệu gặp sự cố tại một thời điểm cụ thể và chúng tôi có cả bản sao lưu toàn bộ và sao lưu nhật ký, trước tiên chúng tôi có thể khôi phục bản sao lưu đầy đủ và sau đó khôi phục sao lưu nhật ký và trong quá trình này, hãy khôi phục nhật ký cuối cùng cho đến một thời điểm nhất định và điều đó sẽ khiến cơ sở dữ liệu ở trạng thái chính xác như trước khi sự cố này xảy ra.
Sao lưu nhật ký là VLDB (Cơ sở dữ liệu rất lớn) khá phổ biến và hầu hết các cơ sở dữ liệu quan trọng. Nó luôn được khuyến khích để kiểm tra quá trình khôi phục. Bất cứ khi nào bạn thực hiện sao lưu cơ sở dữ liệu, bạn nên suy nghĩ về quá trình khôi phục và bạn nên kiểm tra quá trình khôi phục thường xuyên hơn.
Thỉnh thoảng nên giảm bớt thử nghiệm trong quá trình khôi phục, vì vậy chỉ cần đảm bảo quá trình này diễn ra sao lưu bình thường.
Tình huống
Hãy để chúng tôi nói về một tình huống, khi bạn cần khôi phục một cơ sở dữ liệu rất lớn và tất cả chúng ta đều biết rằng thông thường có thể mất vài giờ và đó là điều mà mọi người nên lưu ý. Nếu bạn đang lập kế hoạch di chuyển cơ sở dữ liệu mà không mất dữ liệu và thời lượng ngừng hoạt động nhỏ hơn, đó vẫn có thể là một vấn đề khá lớn. Vì vậy, bạn đảm bảo dựa vào bản sao lưu Nhật ký giao dịch để tăng tốc quá trình.
Hãy để chúng tôi xem xét một tình huống khác trong đó bạn đang thực hiện di chuyển song song cơ sở dữ liệu giữa hai phiên bản SQL Server khác nhau; bạn tham gia vào việc di chuyển cơ sở dữ liệu sang cùng một phiên bản phần mềm trên mục tiêu và bao gồm chuyển hệ điều hành, cơ sở dữ liệu, ứng dụng và mạng, v.v.:-; di chuyển cơ sở dữ liệu từ phần cứng này sang phần cứng khác; thay đổi cả phần mềm và phần cứng. Quá trình di chuyển cơ sở dữ liệu luôn là một thách thức trong đó việc mất dữ liệu luôn có thể xảy ra và nó phải chịu tác động của môi trường.
Các phương pháp hay nhất về di chuyển Cơ sở dữ liệu
Hãy để chúng tôi thảo luận về các thực hành tiêu chuẩn của quản lý di chuyển cơ sở dữ liệu.
Việc di chuyển phải được thực hiện theo phương thức giao dịch để tránh sự mâu thuẫn trong dữ liệu. Các bước thông thường của quá trình di chuyển được quy ước như sau:
- Dừng dịch vụ ứng dụng — đây là lúc thời gian ngừng hoạt động bắt đầu
- Bắt đầu sao lưu nhật ký, điều này tùy thuộc vào yêu cầu của bạn
- Đặt cơ sở dữ liệu ở chế độ khôi phục để không có thay đổi nào đối với cơ sở dữ liệu được thực hiện
- Di chuyển (các) tệp nhật ký
- Khôi phục cơ sở dữ liệu (Các) tệp nhật ký giao dịch — được cung cấp, bạn đã khôi phục bản sao lưu đầy đủ của cơ sở dữ liệu về đích và để cơ sở dữ liệu ở trạng thái khôi phục.
- Sao chép thông tin đăng nhập và sửa chữa người dùng mồ côi
- Tạo Công việc
- Cài đặt ứng dụng
- Định cấu hình mạng - Thay đổi các mục nhập DNS
- Định cấu hình lại cài đặt ứng dụng
- Bắt đầu dịch vụ ứng dụng
- Kiểm tra ứng dụng
Bắt đầu
Trong bài viết này, chúng ta sẽ thảo luận về cách xử lý việc di chuyển cơ sở dữ liệu OLTP rất lớn. Chúng ta sẽ thảo luận về các chiến lược sử dụng các kỹ thuật máy chủ SQL và các công cụ của bên thứ 3 để đảm bảo an toàn dữ liệu cùng với mức độ khả dụng của hệ thống sản xuất bằng không hoặc tối thiểu. Trong quá trình này, luôn có khả năng mất dữ liệu. Bạn có nghĩ rằng xử lý liền mạch các giao dịch là một chiến lược tốt? Nếu “có”, lựa chọn yêu thích của bạn là gì?
Hãy để chúng tôi tìm hiểu sâu hơn về các tùy chọn có sẵn:
- Sao lưu và khôi phục
- Ghi nhật ký vận chuyển
- Phản chiếu cơ sở dữ liệu
- Công cụ của bên thứ 3
Sao lưu và khôi phục
Kỹ thuật cơ sở dữ liệu Backup-and-Restore là lựa chọn khả thi nhất cho bất kỳ quá trình di chuyển cơ sở dữ liệu nào. Nếu nó được lên kế hoạch và kiểm tra đúng cách, chúng tôi sẽ tránh được nhiều lỗi di chuyển không lường trước được. Chúng ta đều biết rằng sao lưu là một quá trình trực tuyến, có thể dễ dàng bắt đầu sao lưu Nhật ký giao dịch kịp thời để thu hẹp số lượng giao dịch được cung cấp vào cơ sở dữ liệu mới. Trong cửa sổ di chuyển, chúng tôi có thể giới hạn người dùng truy cập cơ sở dữ liệu và bắt đầu sao lưu nhật ký cuối cùng và chuyển nó đến đích. Bằng cách này, thời gian chết có thể được rút ngắn đáng kể.
Ghi nhật ký vận chuyển
Tất cả chúng ta đều hiểu tầm quan trọng của các tệp nhật ký trong thế giới cơ sở dữ liệu. Kỹ thuật vận chuyển nhật ký cung cấp một giải pháp khôi phục thảm họa tốt và hỗ trợ quyền truy cập giới hạn chỉ đọc vào cơ sở dữ liệu thứ cấp, trong khoảng thời gian giữa các công việc khôi phục. Về cơ bản, đây là một khái niệm sao lưu nhật ký giao dịch và được phát lại trên một bản sao lưu đầy đủ trên một cơ sở dữ liệu thứ cấp nữa. Các cơ sở dữ liệu thứ cấp này là các bản sao của cơ sở dữ liệu chính và liên tục khôi phục các bản sao lưu nhật ký giao dịch thành bản sao của chính chúng, để giữ cho nó đồng bộ với cơ sở dữ liệu chính. Vì cơ sở dữ liệu thứ cấp nằm trên phần cứng riêng biệt, trong trường hợp lỗi cơ sở dữ liệu chính vì bất kỳ lý do gì, bản sao đã sao lưu đầy đủ của hệ thống sẽ ngay lập tức có sẵn để sử dụng và lưu lượng mạng có thể được định tuyến lại đơn giản đến máy chủ thứ cấp mà không người dùng nào biết rằng lỗi đã xảy ra. Vận chuyển nhật ký cung cấp một cách dễ dàng và hiệu quả để quản lý việc di chuyển ở phạm vi rộng hơn trong hầu hết các trường hợp.
Bắt chước
Phản chiếu cơ sở dữ liệu cũng là một tùy chọn để di chuyển cơ sở dữ liệu với điều kiện cả nguồn và đích đều có cùng phiên bản và phiên bản. Về cơ bản, sao chép tạo ra hai bản sao trùng lặp của cơ sở dữ liệu trên hai phiên bản phần cứng. Các giao dịch sẽ xảy ra đồng thời trên cả hai cơ sở dữ liệu. Bạn có thể sử dụng cơ sở dữ liệu sản xuất ngoại tuyến, chuyển sang phiên bản được nhân bản của cơ sở dữ liệu đó và cho phép người dùng tiếp tục truy cập dữ liệu như thể không có chuyện gì xảy ra. Về việc triển khai nó, chúng tôi xử lý một máy chủ chính, một máy chủ nhân bản và một nhân chứng. Nhưng nó sẽ là một tính năng không được dùng nữa và nó sẽ bị xóa khỏi các phiên bản SQL Server trong tương lai.
Tóm tắt
Trong bài viết này, chúng tôi đã thảo luận chi tiết về các loại sao lưu, sao lưu nhật ký giao dịch, tiêu chuẩn di chuyển dữ liệu, quy trình và chiến lược, học cách sử dụng các kỹ thuật SQL để xử lý hiệu quả các bước di chuyển dữ liệu.
Cơ chế ghi nhật ký giao dịch WAL đảm bảo rằng các giao dịch luôn được ghi vào tệp nhật ký trước. Bằng cách này, SQL Server đảm bảo các tác động của tất cả các giao dịch đã cam kết cuối cùng sẽ được ghi vào tệp dữ liệu (vào đĩa) và bất kỳ sửa đổi dữ liệu nào trên đĩa bắt nguồn từ các giao dịch chưa hoàn thành sẽ được ROLLBACK và không được phản ánh trong tệp dữ liệu.
Trong hầu hết các trường hợp, sự chậm trễ trong đồng bộ hóa dữ liệu là không lường trước được và mất dữ liệu là vĩnh viễn. Thường xuyên hơn không, tất cả phụ thuộc vào kích thước của cơ sở dữ liệu và cơ sở hạ tầng có sẵn. Như một phương pháp được khuyến nghị, tốt hơn nên chạy quá trình di chuyển theo cách thủ công hơn là một phần của việc triển khai để giữ mọi thứ được tách biệt để đầu ra có thể dễ đoán hơn.
Cá nhân tôi muốn vận chuyển Nhật ký vì nhiều lý do:Bạn có thể sao lưu trước toàn bộ dữ liệu từ máy chủ cũ, chuyển dữ liệu sang máy chủ mới, khôi phục và sau đó áp dụng các giao dịch còn lại (sao lưu t-log ) từ thời điểm cho đến thời điểm chuyển giao. Quá trình này thực sự khá đơn giản.
Di chuyển cơ sở dữ liệu không khó nếu nó được thực hiện đúng cách. Tôi hy vọng bài đăng này sẽ giúp bạn chạy quá trình di chuyển cơ sở dữ liệu một cách mượt mà hơn.
