긴 SQL 작업: VPN이 끊겨도 계속 실행되게 하기

인덱스 재구성이 시작된 지 이십 분 만에 VPN이 끊기고 SQL 클라이언트는 끊어진 연결을 보여 주며, 당연한 질문에는 이 오류 안에 답이 없습니다. 문장이 끝났는지, 롤백되었는지, 아니면 당신 없이 계속 실행 중인지. 다시 연결해서 다시 제출하는 것은 하나의 불확실한 결과를 두 개의 가능성으로 바꾸기 때문에 세 가지 선택 중 최악입니다. 다음 작업 창이 오기 전에 작업을 영속적인 소유자가 있는 곳으로 옮기세요.

연결 오류가 말해 주지 않는 것

클라이언트 측 오류는 클라이언트를 설명합니다. 소켓이 닫혔다는 것만 알려 줄 뿐, 서버가 트랜잭션을 어떻게 했는지는 알려 주지 않습니다. 문장이 아직 실행 중일 수도, 연결이 끊기기 직전에 커밋되었을 수도, 세션이 정리될 때 롤백되었을 수도 있습니다. 세 경우 모두 노트북에는 같은 메시지를 냅니다.

이를 확정할 수 있는 것은 서버의 상태뿐입니다. 무엇이든 결정하기 전에 그곳을 보세요.

작업을 서버 측 소유자에게 넘기기

사람이 지켜볼 필요가 없는 작업이라면 데이터베이스 호스트가 실행을 소유하게 하세요. SQL Server Agent는 요청 시 또는 일정에 따라 작업을 실행하고 매 실행을 기록하므로, 작업의 수명 주기는 VPN 세션과 무관합니다. 작업이 요구하는 권한만 작업 ID에 부여하고, 관리자의 전체 대화형 컨텍스트는 부여하지 않습니다. 그러면 노트북은 작업을 시작하고 결과를 읽는 역할이 되고, 작업을 살려 두는 프로세스가 되지 않습니다.

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

Agent의 가용성은 배포한 에디션과 서비스에 따라 다릅니다. 이것이 어디에나 있다고 가정하지 말고, 플랫폼이 실제로 제공하는 메커니즘을 사용하세요.

데이터베이스 근처의 점프 호스트는 경로를 줄여 주고 있으면 좋지만 소유권 문제를 바꾸지는 않습니다. 네트워크가 끝나면 세션도 끝납니다. 관찰에 쓰고, 작업을 살려 두는 대상으로 쓰지 마세요.

다음 세션이 읽을 수 있는 기록을 남기기

작업 이름이나 식별자, 대상 데이터베이스, 기대하는 결과를 적어 두세요. 바로 그 기록이 다른 세션이나 다른 사람이, 오류가 답하지 못한 질문에 답할 수 있게 합니다. 없으면 업데이트에 대한 흐릿한 기억만 남고 확인할 방법이 없습니다.

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

기록은 단계별 결과와 시간을 보여 주므로 단일 성공 플래그보다 유용합니다. 데이터를 바꾸는 작업에는 행 수, 체크섬, 또는 작업이 기록하는 상태 행 같은 애플리케이션 자체의 검증도 더하세요. 독립적인 두 기록이 있어야 재시도가 안전해지며, 기록된 작업 기록이 그 첫 번째입니다.

다시 제출하기 전에 대조하기

관찰하던 연결이 사라지면, 다른 실행을 시작하기 전에 기존 실행을 찾으세요. 그 단계별 결과를 읽고 작업이 커밋되었는지, 일부만 완료되었는지, 아예 시작되지 않았는지 판단합니다. 무작정 다시 제출하면 로드를 중복시키거나 두 번째로 중간에 실패할 수 있으므로, 그런 다음에야 워크플로가 정의한 재시도 규칙을 적용하세요.

영속적인 소유자와 검사 가능한 결과를 유지하면, 짧은 접근 장애는 추측이 아니라 불편이 됩니다. 그것이 설계의 목표 전부이며, 작업은 그것을 요청한 연결보다 오래 살아야 합니다.