Tác vụ SQL dài: giữ nó chạy khi VPN rớt

VPN rớt hai mươi phút sau khi bắt đầu xây dựng lại chỉ mục, ứng dụng SQL của bạn hiển thị kết nối bị đứt, và câu hỏi hiển nhiên không có câu trả lời trong lỗi đó. Câu lệnh đã chạy xong, đã rollback, hay vẫn tiếp tục chạy mà không có bạn? Kết nối lại và gửi lại là lựa chọn tệ nhất trong ba, vì nó biến một kết quả không chắc chắn thành hai kết quả có thể. Hãy chuyển công việc sang thứ gì đó có chủ sở hữu bền vững trước cửa sổ tiếp theo.

Điều mà lỗi kết nối không cho bạn biết

Lỗi phía máy khách mô tả máy khách. Nó báo rằng socket đã đóng, chứ không phải máy chủ đã làm gì với giao dịch. Câu lệnh có thể vẫn đang chạy, có thể đã commit ngay trước khi đường truyền chết, hoặc có thể đã rollback khi phiên của nó bị dọn. Cả ba đều tạo ra cùng một thông báo trên máy tính xách tay của bạn.

Chỉ trạng thái của máy chủ mới giải quyết được. Hãy nhìn vào đó trước khi quyết định bất cứ điều gì.

Giao công việc cho chủ sở hữu phía máy chủ

Với công việc không cần người trông coi, hãy để máy chủ cơ sở dữ liệu sở hữu việc thực thi. SQL Server Agent chạy tác vụ theo yêu cầu hoặc theo lịch và ghi lại mỗi lần chạy, nên vòng đời của tác vụ độc lập với phiên VPN của bạn. Danh tính của tác vụ cần đúng những quyền mà nhiệm vụ yêu cầu, không phải toàn bộ ngữ cảnh tương tác của quản trị viên. Sau đó máy tính xách tay khởi động công việc và đọc kết quả thay vì là tiến trình giữ nó sống.

EXEC msdb.dbo.sp_start_job @job_name = N'nightly-customer-reindex';

Tính sẵn có của Agent phụ thuộc vào phiên bản và dịch vụ bạn triển khai. Hãy dùng cơ chế mà nền tảng của bạn thực sự cung cấp thay vì giả định cơ chế này có ở mọi nơi.

Một máy chủ nhảy gần cơ sở dữ liệu rút ngắn đường đi và đáng có, nhưng nó không thay đổi câu hỏi về quyền sở hữu. Phiên vẫn kết thúc khi mạng kết thúc. Hãy dùng nó để quan sát, không phải để trở thành thứ giữ công việc sống.

Để lại một bản ghi mà phiên tiếp theo có thể đọc

Ghi lại tên hoặc mã định danh tác vụ, cơ sở dữ liệu đích và kết quả bạn mong đợi. Chính bản ghi đó cho phép một phiên khác, hoặc một người khác, trả lời câu hỏi mà lỗi không thể. Không có nó, bạn chỉ còn một ký ức mơ hồ về lần cập nhật và không có cách nào kiểm tra.

EXEC msdb.dbo.sp_help_jobhistory @job_name = N'nightly-customer-reindex';

Lịch sử hiển thị kết quả và thời gian từng bước, hữu ích hơn một cờ thành công duy nhất. Với tác vụ thay đổi dữ liệu, hãy thêm cả kiểm chứng của chính ứng dụng: số dòng, checksum hoặc một dòng trạng thái do tác vụ ghi. Hai bản ghi độc lập là thứ khiến việc thử lại an toàn, và lịch sử tác vụ được ghi lại là bản ghi đầu tiên trong đó.

Đối chiếu trước khi gửi lại

Khi kết nối quan sát biến mất, hãy tìm lần chạy hiện có trước khi bắt đầu lần khác. Đọc kết quả từng bước và quyết định xem công việc đã commit, hoàn thành một phần hay chưa từng bắt đầu. Chỉ khi đó mới áp dụng quy tắc thử lại do quy trình công việc định nghĩa, vì gửi lại một cách mù quáng có thể nhân đôi một lần tải hoặc thất bại giữa chừng lần thứ hai.

Giữ chủ sở hữu bền vững và kết quả có thể kiểm tra, và một lần mất quyền truy cập ngắn sẽ thành bất tiện thay vì phỏng đoán. Đó là toàn bộ mục tiêu thiết kế: công việc phải sống lâu hơn kết nối đã yêu cầu nó.