SQL Server 에이전트를 사용하여 데이터베이스 이외의 작업을 예약하고 있습니다. 이것은 나쁜 생각입니까?


13

필자는 DBA (대부분의 경우 사실상 sysadmin)이므로 SQL Server는 정기적으로 작업해야하는 거의 모든 서버에 설치됩니다. 최근에 기본 Windows 작업 스케줄러가 아닌 거의 모든 경우에 SQL 에이전트를 작업 스케줄러로 사용하고 있음을 깨달았습니다.

내 관점에서 볼 때 SQL 에이전트는 기본 Windows 작업 스케줄러에 비해 여러 가지 장점이 있습니다.

  • 내 워크 스테이션에서 원격으로 작업 시작 / 중지 / 모니터링
  • 공유 일정 (각 작업 자체가 아닌)
  • 여러 단계 및 제어 흐름
  • 다양한 유형의 작업
  • 실패 / 완료에 대한 경고
  • 다른 사용자로 작동하도록 구성 가능
  • 오류 코드가 아닌 설명적인 오류 메시지

그러나 이것이 나쁜 습관이라는 느낌을 피할 수는 없습니다. SQL 에이전트는 데이터베이스 관련 작업만을 위해 예약해야하며, 사용성에 대한 싫어 함에도 불구하고 Windows 작업 스케줄러에서 OS 수준의 작업을 실행해야합니다.

이런 식으로 SQL 에이전트에 의존해도 괜찮습니까? 그렇지 않은 경우 찾고있는 기능 중 일부를 얻기 위해 타사 Windows 작업 스케줄러를 고려해야합니까?


이것이 여기 대신 SF에 속하는 경우 알려 주시면 거기로 옮길 것이지만 데이터베이스 도구를 사용하고 있기 때문에 여기에 속해 있다고 생각했으며 다른 DBA / SA 관리자가하고 있는지 확인하고 싶습니다. 똑같은 것.
SqlRyan

답변:


7

개인적으로 가장 큰 경고는 작업 목록을 정리하는 데 어려움이있을 것이라고 생각합니다. 내가 아는 한 작업을 구성하기 위해 폴더를 만들 수 없으므로 많은 수의 번거로울 것입니다. 그러나 내 서버 중 12 개 이상의 작업을 가진 서버가 없기 때문에 100 % 확신 할 수 없습니다. Server 2008 이상의 작업 스케줄러를 사용하면 훨씬 쉽게 조직, IMO를 수행 할 수 있으며 일반적으로 이전 버전보다 기능이 훨씬 우수합니다. 타사 응용 프로그램이 더 나은 작업을 할 것이라고 확신합니다. Server 2003의 작업 스케줄러 또는를 사용해야하는지 울고 싶습니다 at.exe.

내가 생각할 수있는 두 번째 경고는 잠재적으로 SQL 서버에 너무 많은 부하를 줄 것입니다. 에이전트는 작은 프로그램이지만 길거나 복잡한 작업을 실행하면 많은 리소스를 쉽게 소비 할 수 있습니다. 이러한 리소스는 SQL 엔진에 사용할 수 없습니다. SQL 엔진이 사용 가능한 시스템 메모리의 약 80 %를 차지하도록 프로그래밍 되었기 때문에 문제가 될 수 있습니다.

셋째, 백업이 문제 일 수 있습니다. 작업을 복구 할 수 있도록 파일 시스템뿐만 아니라 msdb 데이터베이스도 백업해야합니다 (또는 텍스트 파일에 작업을 스크립팅하는 데 사용). 이는 재해 복구에 복잡한 계층을 추가합니다.

마지막으로, SQL Server 에이전트를 실행하기 위해 SQL Server 라이센스 비용을 지불하고 싶지는 않습니다. 데이터베이스가 폐기되면 SQL Server 에이전트를 마이그레이션하기위한 계획을 개발해야합니다.


모든 확실한 포인트-경고에 감사드립니다. 네이티브 Window 스케줄러에서 예약 된 작업 목록을 백업하는 방법을 모르는 경우를 제외하고 3 번에 대해 걱정할 것이므로 (현재) 해당 목록을 완전히 잃을 준비가되었습니다. 사본을 보관할 방법이 있다고 확신합니다. 조직이 가장 큰 관심사 일 수 있습니다. 아직 서버가없는 것은 아니지만 시스템이 제대로 갖추어져 있지 않으면 서버가 도착하는 것을 볼 수 있습니다.
SqlRyan

9

이전 작업에서 가장 정확하게 수행 한 작업은 대부분 작업이 가장 가시적 인 서버 인 중앙 기본 클러스터에서 실행 되었기 때문입니다. 여러 서버에서 명령 줄을 확인하지 않고 예약 된 모든 작업을 한 곳에서 볼 수있었습니다.

이것은 주관적이지만 (이 형식에서 "올바른"답변을 도출하기 어려울 수 있지만) 단일 실패 지점이 아닌 다른 방법으로이 접근 방식에 본질적으로 문제가 있다고 생각하지 않습니다.

모든 작업이 작동중인 데이터베이스 서버와 실행중인 SQL Server 서비스 (이 경우에는 해당)와 상호 작용하거나 의존하는 경우에는 관련이 없을 수 있습니다.

아, 그리고 작업을 실행하려고하는 서버가 작동하지 않는 경우 오류 처리를 추가해야합니다. 작업이 해당 서버에 설정되어 있으면 수행 할 필요가 없습니다.


의견을 보내 주셔서 감사합니다. 두 방법 모두 작업을 수행함에 따라 질문이 매우 주관적이라고 생각합니다. 그러나 "예, Windows 작업을 많이 남겨 두어야합니다"또는 "아니요. 아이디어, 여기에 이유가 있습니다 ... "우리는 무슨 거품이 일어 났는지 볼 것입니다!
SqlRyan

숨을 너무 많이들이 쉬기 전에 사람들이 PowerShell 작업을 포주 할 것이라고 확신합니다. 개인적으로 이러한 작업과 Windows 작업을 관리하는 것이 좀 더 지루하지만 마일리지는 다를 수 있습니다.
Aaron Bertrand

0

아마도 데이터베이스 작업을 위해 Windows 작업 관리자보다 SQL 에이전트를 사용합니다.

전혀 코딩을 할 수 있거나 코딩 할 수있는 사람들이 있다면 콘솔 앱을 사용하여 TopShelf (http://topshelf-project.com/)와 같은 서비스 제작자로 래핑 할 수 있습니다. 쉽게 해킹하여 SQL 에이전트에서 모든 것을 분리하고 그 시점에 있으면 대기열에 대한 계층을 제공하기 시작합니다.

개인적으로, 당신은 이것에 대해 충분히 신경 쓰는 것뿐만 아니라 당신이 괜찮을 것이라고 생각하는 당신의 문제를 충분히 아는 것 같습니다. 내가 정말로 걱정하는 것은 신경 쓰지 않는 사람들입니다. 합리적인 간격으로 솔루션을 평가하고 그에 따라 조치를 취할 것입니다.


-1

또 다른 옵션은 저장 프로 시저가있는 예약 된 작업에 대한 테이블을 만들어 메시지 큐 테이블을 업데이트하는 것입니다. 그런 다음 SQL Server 에이전트는 저장 프로 시저를 너무 자주 호출하여 메시지를 만들고 작업 상태를 업데이트합니다. 다른 시스템은 SQL 연결 또는 웹 API 계층을 통해 JSON으로 메시지 큐 테이블을 쿼리합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.