공급 업체가 비즈니스 응용 프로그램에 대해 5 분마다 MSDB 작업을 실행하려고합니다.


15

우리는 두 DB가 150 개 이상의 다른 DB와 함께 SQL Server 인스턴스에 상주하는 두 개의 서로 다른 응용 프로그램을 통합하려고하는 타사 공급 업체를 보유하고 있으며 5 분마다 두 개의 서로 다른 응용 프로그램을 "동기화"하기 위해 MSDB 작업을 생성하려고합니다 (처음에는 처음에 매분마다 실행하고 싶었습니다).

필자의 첫 번째 직책은 Windows 예약 작업 또는 어쩌면 무서운 트리거 (일반적으로 이와 같은 상황에 의존)를 사용하여 응용 프로그램 계층 에서이 작업을 수행해야한다는 것입니다.

나는 DBA 작업을 위해 MSDB 작업을 가능한 한 많이 예약하고 거기에 혼란을 줄이려고 노력하고 있으며 이와 같은 매우 활동적인 작업으로 작업 기록을 볼 때 MSDB에 대한 쿼리가 느리게 진행됩니다. 백업 기록과 같은 더 중요한 것). 그러나 다시, 내 환경 설정이 잘못되었을 수 있으며 MSDB의 응용 프로그램 계층을위한 공간을 확보하고 소매를 롤업하고 작업 내역 문제를 해결하기 위해 더 많은 기록 항목을 유지해야 할 때 영원히로드하는 문제를 해결해야합니다. 백업과 같은 중요한 것들 (또는 과잉 활성 작업 항목 제거)

내가 가지고있는 또 다른 문제는 이제 GUI를 통해 업그레이드를 수행 할 때 DB에 대해서만 "dbo"권한 대신이 공급 업체에게 "sysadmin"권한을 부여해야하며 내 임무가 중요한 인스턴스를 날려 버리지 않기를 바랍니다. DB는 (통합의 단점 중 하나)입니다.

잘 작동하지 않는 모든 공급 업체를 배치하는 또 다른 "절연 된"인스턴스에이를 배치 할 수 있지만 새 SQL 인스턴스를 가리 키도록 응용 프로그램을 재구성해야합니다 ( 안타깝게도이 경우에는 한숨 이 아님).

공급 업체는 이미 트리거가 얼마나 나쁜지에 대해 우려를 표명했습니다. 그래서, 나는 이것에 대해 "구글 검색"하고 비어 왔습니다. 누군가가 "정식적인보고"라는 링크를 보았는데 이것이 나쁜 생각이고 그것들을 참조 할 수 있습니까? 아니면 그들의 접근 방식을 받아 들여야합니까?

도움을 요청하기 전에 SQL 포럼에 게시 한 적이 있다고 생각하지 않기 때문에 문의 사항이 제대로 작성 되었기를 바랍니다.

편집 : 우리는 SQL Server 2008 Enterprise R2 x64 SP1을 실행 중입니다 (버전을 언급하는 것을 잊어 버렸습니다!) 흠, 새 버전으로 갈 때 MSDB 업그레이드 스크립트를 변경할 필요가 없기를 바랍니다.

시간 내 줘서 고마워! 풍부한


멋지게 말 했어요. 아마도 사용하는 특정 버전으로 태그를 추가 할 수 있습니다 (또한 질문에 언급 된 버전). 표준과 엔터프라이즈간에 차이가 있는지 확실하지 않지만 관련성이있을 수 있습니다.
ypercubeᵀᴹ

항상 작업에 자체 히스토리를 제거하도록 지시 할 수 있습니다 (MSDB 테이블에서 매우 쉽게 삭제할 수 있음). "히스토리 테이블에 대한 느린 조회"가 고려되지 않아야합니다. 나는 역사에 대한 통제력이 적기 때문에 외부 프로세스가 이것을 처리하게하는 것에 대해 더 신경을 썼다. 또한 5 분이 "충분히 현재"인 경우 트리거를 설정하여 모든 단일 DML 작업에 실시간으로 영향을 미치는 이유는 무엇입니까?
Aaron Bertrand

추신 : 나는 실제로 작업 기능을 변경하지 않는 한 (일부 새로운 기능을 이용하지 않는 한 버전에 국한되지는 않음) 2008 R2와 2012 사이에 작업 작성 스크립트가 변경 될 것이라고 의심합니다. 작업 스크립트 자체는 변경되지 않아야합니다.
Aaron Bertrand

2
sysadminSQL 에이전트 작업을 수정 하기 위해 반드시 제공 할 필요는 없습니다. msdn.microsoft.com/en-us/library/ms188283(v=sql.105).aspx를
SQLFox

빠른 응답에 감사드립니다. 나는 그들의 접근 방식을 받아들이고 sysadmin을주지 않는 동시에 제거를 살펴 보겠습니다.
rzuech 2016 년

답변:


12

공급 업체 IMO는 실제로 올바른 길을 가고 있습니다.

응용 프로그램 계층 작업을 수행하려면 즉시 사용 가능한 많은 SQL 에이전트 기능 (예 : 이미 실행중인 작업을 실행하지 않는 논리, 보안 및 자격 증명 저장소 솔루션 제공, 작업 결과 통합)을 다시 실행해야합니다. SQL 등의 오류보고 및 결과 추적 등). 그리고 가장 중요한 것은 스케줄링을위한 백업 / HA / DC 솔루션을 제공하는 것입니다. 당신은 원하지 않는 당신의 재해 복구 이야기로 '당신이 50 개 NT 스케줄러 작업을 만들 가서 대기 서버를 복구 완료 후'. 따라서 그는 시스템 스케줄러를 사용하지 않고 다시 추진할 수 있으며 에이전트가 가진 기능은 없습니다.

그는 방아쇠를 뒤로 밀기에 훨씬 더 옳습니다. 주기적 작업을 동기식 트리거로 교체하면 요청 대기 시간이 증가하고, 응집력 및 커플 링이 증가하고 (스키마 변경 고려), 동기화 문제로 인한 다운 타임 위험이 증가합니다 (트리거 오류-> 앱 오류 대 작업 오류-> 수정 후 나중에 다시 시도) , 추적 / 트랙 키 사이의 교차 업데이트로 인해 교착 상태 문제가 크게 증가하고 더 많은 문제가 있습니다.

가장 쉬운 솔루션은 실제로 에이전트 작업이며 msdb결코 DBA를 위해 예약되어 있지 않습니다. 더 멋진 솔루션은 대화 타이머내부 활성화 를 사용 하는 것입니다. 이는 주로 봉쇄 (앱 DB 내부에있는 모든 것, 미러링 장애 조치 시나리오를 생각 함)로 인해 에이전트 작업보다 몇 가지 이점이 있지만 공급 업체가 매우 특정한 노하우가 필요한 것을 시도하는 것을 꺼려합니다. BTW DB 당 5 분마다 하나의 작업을 의미하지 않기를 바랍니다 .

sysadmin 권한과 관련하여 게임 이름은 코드 서명 입니다. 개인 인증서로 서명하여 특정 절차에 대한 권한을 부여 할 수 있습니다.


여기에 스택 오버플로 답변에 대한 링크는 것을 보여준다 대화 타이머 및 내부 활성화의 예 : stackoverflow.com/a/4079716
존 Seigel

1
나는 이것을 합의 인 것처럼 보이는 대답으로 표시했다. 내가이 모든 것을 빼앗아 간 가장 큰 것은 응용 프로그램이 자주 MSDB 작업을 사용하는 것이 좋다는 것입니다. 여기에 제공된 링크를 사용하여 적절한 보안 방식으로 작업을 수행하면됩니다. 매우 통찰력있는 여러분, 여러분의 의견과 시간에 감사드립니다!
rzuech

2

개인적으로 선호하는 것은 트리거를 사용하여 동기화의 적어도 일부를 처리하는 것입니다. 잠재적 인 충돌, 부실 데이터, 반복 작업의 성능 영향 등을 처리해야하므로 예약 된 폴링 동기화는 특별히 신경 쓰지 않습니다. 1-5 분 정도 적극적으로 수행하려면 그것은 갈등과 낡음을 완화시키는 것이며, 방아쇠의 즉시 성은 그것을 해결할 것입니다.

모두 동일한 서버에서 발생하는 경우 동기화 코드를 트리거 내에 넣거나 트리거가 영향을받는 각 레코드를 동기화하는 저장 프로 시저를 호출하도록하는 것이 좋습니다. 동기화가 서버에 걸쳐 있거나 하나의 데이터베이스를 오프라인으로 설정해도 다른 데이터베이스를 사용할 수 없도록하려면 Service Broker를 사용하여 비동기 업데이트를 처리하십시오. 이 작업을 수행하여 두 개의 다른 서버간에 판매 항목 수치를 CRM 데이터와 동기화하는 한편 다른 응용 프로그램에 영향을주지 않고 두 서버 중 하나를 오프라인 상태로 만들 수 있습니다. 백업되면 Service Broker는 메시지를 전달하고 원격 서버의 데이터를 업데이트합니다.

트리거에 대해서는 본질적으로 나쁘지는 않지만 T-SQL의 대부분의 측면과 마찬가지로 끔찍하게 수행되는 코드를 작성할 수 있습니다. 나는 그것이 도움이된다면 트리거의 일반적인 함정에 관한 기사를 썼다.

올바르게 작동하는 트리거 작성


예, 2 개의 DB가 동일한 서버 인스턴스에 있습니다. 개인적으로, 나는 방아쇠도했을 것입니다. 그들의 응용 프로그램은 우리가 가지고있는 꽤 무거운 듀티 DB에 비해 꽤 작은 감자입니다. 그러나 응용 프로그램 동기화에 MSDB 작업을 사용하지 않는 것과 관련된 "모범 사례"항목을 실제로 지적 할 수 없기 때문에 공급 업체를 설득 할 수 있다고 생각하지 않습니다. 또한 나는 Aaron의 의견을 상당히 존중하므로 그들을 누르지 않을 것입니다. db2 나는 당신의 링크를 읽고 상당히 유익한 것을 발견했으며, Service Broker는 내가 고려하지 않은 또 다른 좋은 옵션입니다. 감사!
rzuech 2016 년

예, 트리거 실패 (오프라인 데이터베이스, 스키마 변경 등)에 대해 걱정이된다면 즉각적인 동기화를 원한다고 가정하면 Service Broker를 사용할 수 있습니다.
db2
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.