하나의 주요 작업에서 여러 SQL Server 에이전트 작업을 순차적으로 호출하는 좋은 방법은 무엇입니까?


11

순차적으로 실행해야하는 여러 SQL Server 에이전트 작업이 있습니다. 실행해야 할 작업에 대한 좋은 개요를 유지하기 위해을 호출하여 다른 작업을 호출하는 기본 작업을 만들었습니다 EXEC msdb.dbo.sp_start_job N'TEST1'. sp_start_job작업이 될 때까지 즉시 완료 (작업 1 단계),하지만 그때 대기에 내 주요 작업을하려면 TEST1다음 작업을 호출하기 전에 완료했습니다.

따라서 작업이 호출 된 직후 (Job Step 2) 실행을 시작하고 하위 작업이 완료 될 때까지 기본 작업을 대기시키는이 작은 스크립트를 작성했습니다.

WHILE 1 = 1
  BEGIN
    WAITFOR DELAY '00:05:00.000';

    SELECT *
    INTO   #jobs
    FROM   OPENROWSET('SQLNCLI', 'Server=TESTSERVER;Trusted_Connection=yes;',
           'EXEC msdb.dbo.sp_help_job @job_name = N''TEST1'',
           @execution_status = 0, @job_aspect = N''JOB''');

    IF NOT (EXISTS (SELECT top 1 * FROM #jobs))
      BEGIN
        BREAK
      END;

    DROP TABLE #jobs;

  END;

이것은 충분히 잘 작동합니다. 그러나 더 똑똑하고 안전한 WHILE 1 = 1솔루션이 가능해야한다는 느낌이 들었습니다 .

다음 사항이 궁금합니다. 몇 가지 통찰력을 제공해 주시기 바랍니다.

  • 이 접근법의 문제점은 무엇입니까?
  • 더 좋은 방법을 제안 할 수 있습니까?

( 코드 개선에 중점을 두었 기 때문에 StackOverflow 에이 질문을 먼저 게시했습니다 . 여전히 유효합니다. 그러나 제 사람들은 일반적으로 여기 사람들이 내가 왜 그렇게하지 말아야하는지에 대해 더 똑똑하게 말할 것이라고 생각합니다 지금하고 있거나 좋은 대안을 제시하십시오.)

편집 (7 월 25 일)
분명히 스크립트에 문제가 있음을 나타내는 적은 수의 답변에 따라 내 스크립트에는 너무 많은 잘못이 없습니다 :-) 이러한 종류의 스크립팅에 대한 대안은 이들을 위해 설계된 도구를 사용하는 것 같습니다 작업 (예 : SQL Sentry Event Manager 또는 ...)-이러한 도구를 직접 작성하십시오. 우리는 현재 회사에서 그러한 도구를 구매하지 않을 것이므로 지금은 스크립트를 사용합니다.


이러한 작업을 독립적 인 작업 대신 기본 작업의 단계로 고려한 적이 있습니까? 이렇게하면 복잡성이 줄어 듭니다. 특히 이들이 이런 식으로 순서대로 함께 호출 된 경우 ...
Aaron Bertrand

균형입니다. 모든 작업을 기본 작업에 단계로 추가하면 '더 깔끔한'유지 보수가 될 수 있지만, 그렇게하면 많은 개요와 특정 작업을 수동으로 실행할 가능성이 없어집니다. 그래서 나는 그것을 확실히 고려했지만 현재의 '솔루션'은 작동하는 한 많은 이점을 가지고 있습니다.

답변:


9

면책 조항 : SQL Sentry에서 일합니다.

우리의 SQL 센트리 이벤트 관리자의 제품은이에 대해 정확하게 구축 된 시설이 있습니다 체인 작업을하고 다양한 워크 플로우 순서로 정렬.

회사에 합류하기 전에 몇 년 전에 SQL Sentry를 사용하기 시작했습니다. 내가 원했던 것은 프로덕션 백업이 완료된 직후 테스트 서버에서 복원 작업을 시작하는 방법이었습니다.

내가 처음 구현 한 것은 백업 작업 시작 시간과 복원 시작 시간 사이에 상당한 버퍼였습니다. 이것은 정확히 바보가 아니었다. 백업 시간이 다양하기 때문에 버퍼는 종종 복구가 시작되었지만 복구가 시작되지 않은 시간을 낭비했습니다. 그리고 때때로 버퍼가 충분하지 않았습니다.

다음에 구현 한 것은 사용자가 수행 한 것과 유사했습니다. 테스트 서버에 작업을 작성하여 예약 된 백업 직후에 시작했으며 폴링을 유지하여 작업이 완료된 시점을 확인했습니다. 나중에 테스트 서버에서 테이블을 업데이트 한 백업 작업에서 두 ​​번째 단계 만 수행하도록 수정되었습니다. 복원 작업이 작업 기록을 원격으로 모니터링하는 대신 로컬에서만 테이블을 감시해야한다는 점을 제외하고는 크게 다르지 않습니다. 다시 생각해 보면이 테이블에서 트리거가 발생 sp_start_job하여 작업이 n 분마다 실행되거나 일정이 예약되지 않아도됩니다.

마지막 해결책은 서버 A의 백업이 완료되면 Event Manager가 서버 B에서 복원 작업을 시작하는 작업을 함께 연결하는 것입니다. 그리고 세 번째 작업과 네 번째 작업 또는 수행 할 작업을 기반으로하는 조건부 논리가있는 경우 작업이 실패하거나 성공하는 경우 등이 모두 설명 될 수 있습니다. 워크 플로 디자이너는 다음과 같은 많은 SSIS를 상기시킵니다.

여기에 이미지 설명을 입력하십시오

내가 설명하는 것의 기본 메커니즘은 물론 로켓 수술이 아닙니다. 앉아서 체인 킹 래퍼를 직접 만들 수 있습니다. 당신이 필요로하지 않는 한 가지 대안을 제공하십시오.


2

접근 방식의 주요 문제는 무언가가 발생할 때까지 계속 반복해야한다는 것입니다. 당신이 질문을하는 것 같아요.

그렇다면 데이터 중심의 접근 방식을 문제에 사용하는 것은 어떻습니까? 예를 들어, 각 작업이 시작 및 완료 될 때 기록하는 '감사'테이블을 작성하십시오.

직업 명 | 시작 시간 | 종료 시간
--------- + ------------------- + ------------------
시험 1 2012-07-26 07:30 2012-07-26 07:35

모든 작업과 실행 순서를 나열하는 '처리'테이블을 작성하십시오.

직업 명 | 런 오더
--------- + ---------
테스트 1 | 1
테스트 2 | 2
테스트 3 | 삼

작업이 완료되고 감사 레코드가 삽입 될 때 트리거가 다음 작업 (처리 순서별)에 대한 처리 테이블을 조회 한 후 시작하도록 감사 테이블에 삽입 트리거를 작성하십시오.

이 방법의 장점은 다음과 같습니다.

  1. 개발 및 유지 관리는 매우 간단합니다.
  2. 코드 행을 변경하지 않고도 처리 테이블을 통해 새 작업을 추가하거나 기존 작업의 순서를 변경할 수 있습니다.
  3. 감사 테이블은 상황이 발생한 시점에 대한 가시성을 제공합니다.
  4. CPU 사이클을 낭비하지 않습니다. 트리거는 무언가가 발생한 경우에만 발생합니다.
  5. 그것은 느낌이 바로 😉를

HTH


1
고마워요, 당신의 대답을 사랑하십시오! 나는 이것을 시도 할 것입니다!
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.