Service Broker는 비동기 방식을 통해 서로 메시지를 보내고 받는 기능을 쉽게 구축할 수 있는 응용 프로그램이다. 응용 프로그램에서는 관련된 테스크 집합에 대한 이름인 서비스에 메시지를 보내고 내부 테이블 보기인 큐로부터 메시지를 받는다.

Service Broker는 응용 프로그램이 모든 메시지를 한 번만 받도록 한다. 이때 메시지는 전송된 순서대로 받는다.

Service Broker 큐는 데이터베이스에 통합된다. 이는 일반 데이터베이스 유지 관리 및 운영에 Service Broker도 포함된다는 의미이다.

관련 메시지를 조정하고 순서를 지정한다. 각 메시지를 한 번만 받도록 보장하고 큐에 들어온 순서가 아니라 전송된 순서대로 받는다. 그러므로 응용 프로그램에서 메시지의 순서와 그룹화를 결정해야 한다.

Service Broker 에서는 두 개의 큐 판독기가 같은 대화 또는 관련된 대화 그룹의 메시지를 동시에 처리하지 못하도록 한다.

Service Broker는 각 대화에 대한 우선 순위를 1(낮음) – 10(높음) 범위에서 설정할 수 있도록 지원한다.

Service Broker 에서 메시지 전달은 트랜잭션 및 비동기 방식으로 수행된다. 트랜잭션이 롤벡될 경우 해당 트랜잭션 내의 모든 Service Broker 작업도 롤백된다.

작업 요청이 큐에 배치되면 응용 프로그램은 대화형 사용자에게 즉시 응답할 수 있다. 응용 프로그램은 응답하기 전에 요청과 관련된 모든 작업이 완료될 때까지 기다릴 필요가 없다. 리소스가 사용 가능해지면 큐에 대기 중인 요청이 처리된다. 따라서 효율적인 리소스 사용이 가능하다.

경우에 따라 한 개의 요청과 관련된 작업을 여러 개의 작업 단위로 구분하여 별도의 트랜잭션으로 처리할 수 있다. 이 경우 데이터베이스 응용 프로그램은 요청을 큐에 배치하여 각 작업 단위를 시작할 수 있다.

SQL Server와의 통합을 통해 외부 DTC(Distributed Transaction Coordinator)에 대한 추가적인 오버헤드 및 복잡성 없이 틀내잭션 메시지를 사용할 수 있다. 응용 프로그램에서는 트랜잭션을 커밋할 때까지 어떤 작업도 이루어지지 않는다.

데이터, 메시지 및 응용 프로그램 논리가 모두 데이터베이스에 있으면 응용 프로그램의 관리가 쉬워진다.

공통 개발 환경도 데이터베이스 통합의 장점이다. Service Broker 서비스를 구현하는 프로시저는 Transact-SQL 또는 CLR (공용 언어 런타임) 언어 중 하나로 작성할 수 있다.

Service Broker는 메시지 순서, 고유한 배달 및 대화 식별을 자동으로 처리한다. 두 Service Broker의 끝점 사이에 대화가 설정되고 나면 응용 프로그램에서는 각 메시지를 보낸 순서대로 한 번씩만 메시지를 받는다. 사용자 응용 프로그램에서는 추가 코드 없이 순서대로 정확히 한 번씩만 메시지를 처리할 수 있다. 그리고 모든 메시지에 자동으로 식별자를 포함한다. 응용 프로그램에서는 항상 특성 메시지가 속해 있는 대화를 알려 준다.

응용 프로그램에서는 큐에 메시지를 보낸 다음 계속하여 응용 프로그램 처리를 진행하되 Service Broker를 통해 메시지가 대상에 도착했는지 확인할 수 있다. 이처럼 연결이 느슨하면 유연한 일정 예약이 가능하다. 시작자는 여러 메시지를 내보낼 수 있고 여러 대상 서비스에서는 이를 병렬로 처리할 수 있다.

또한 큐 작업을 통해 시스템에서는 더욱 공평하게 처리를 배포할 수 있으므로 서버에 필요한 최대 용량도 줄어든다. 이러면 전반적인 처리량과 성능이 향상된다.

대상을 즉시 사용할 수 없는 경우 메시지는 보내는 데이터베이스의 전송 큐에 남는다. Service Broker에서는 메시지가 전송될 때까지 또는 대화의 수명이 만료될 때까지 메시지를 다시 시도하여 하나의 서비스가 대화 중 특정 시점에 잠시 사용 불가능하게 되더라도 두 서비스 사이의 안정적인 대화가 계속 진행될 수 있도록 한다.

Service Broker에서는 큐 내의 메시지 읽기 작업을 병렬로 처리 시 대화 그룹 잠금을 통해 이러한 문제가 발생하지 않도록 한다.

활성화를 사용하면 응용 프로그램이 큐에 도착하는 메시지 볼륨에 맞게 크기를 동적으로 조정할 수 있다.

Service Broker는 큐의 작업을 모니터링하여 사용 가능한 메시지가 있는 모든 대화에 대해 응용 프로그램이 메시지를 받는지 여부를 확인합니다. Service Broker 활성화는 큐 판독기가 수행할 작업이 있을 때 새 큐 판독기를 시작한다. 큐 판독기가 수행할 작업이 있는 시기를 확인하기 위해 Service Broker에서는 큐의 작업을 모니터링한다. 큐 판독기의 수가 들어오는 트래픽에 일치할 경우 큐는 정기적으로 큐가 비어 있는 상태 또는 큐의 모든 메시지가 다른 큐 판독기에서 처리 중인 대화에 속하는 상태에 이르게 된다. 큐가 일정 기간 동안 이러한 상태에 이르지 않으면 Service Broker는 다른 응용 프로그램 인스턴스를 활성화한다.

응용 프로그램은 데이터베이스 내부에서 실행되는 프로그램과 데이터베이스 외부에서 실행되는 프로그램에 대해 서로 다른 활성화 방법을 사용한다. 데이터베이스 내부의 프로그램에 대해서 Service Broker는 큐에서 지정한 저장 프로시저의 다른 사본을 시작한다. 데이터베이스 외부의 프로그램에 대해서 Service Broker는 활성화 이벤트를 생성한다. 이 이벤트를 모니터링하여 다른 큐 판독기가 필요한 시기를 확인할 수 있다.

Service Broker는 활성화를 통해 시작된 프로그램을 중지하지 않는다. 대신 활성화된 응용 프로그램은 메시지가 도착하지 않은 일정 기간 이후 자동으로 종료되도록 작성된다. 이러한 방법으로 설계된 응용 프로그램을 사용함으로써 서비스에 대한 트래픽 변경으로 인해 여러 응용 프로그램 인스턴스가 동적으로 증가하고 감소할 수 있다. 또한 시스템이 종료되거나 재부팅되면 시스템을 다시 시작할 때 응용프로그램에서 자동으로 큐의 메시지를 읽기 시작한다.

OLTP 시스템과 같이 트리거를 사용하는 응용 프로그램은 Service Broker를 유용하게 활용할 수 있는 경우가 많다. 트리거는 Service Broker 서비스에서 요청이 작동하는 메시지를 대기시킨다. 트리거는 요청된 작업을 실제로 수행하지 않는다. 대신 수행할 작업에 대한 정보가 포함된 메시지를 만들고 해당 작업을 수행하는 서비스에 이 메시지를 보낸다. 그런 다음 트리거는 반환된다.

안정적인 쿼리 처리가 필요한 응용 프로그램은 Service Broker 서비스에 메시지를 보내 쿼리를 전송할 수 있다. 서비스를 구현하는 응용 프로그램은 메시지를 읽고 쿼리를 실행하며 결과를 반환한다. 이 작업은 모두 같은 트랜잭션이 커밋되기 전에 오류가 발생하면 전체 트랜잭션이 롤백되고 메시지가 큐로 반환된다.

큰 원본 집합에서 데이터를 수집하는 응용 프로그램은 Service Broker를 통해 안정적으로 데이터를 수집할 수 있다.

여러 SQL Server 데이터베이스에 액세스하는 대형 응용 프로그램은 Service Broker를 유용하게 활용할 수 있다.

여러 데이터베이스의 정보를 동시에 사용하거나 표시해야 하는 응용 프로그램은 Service Broker를 활용할 수 있다.

대량 일괄 처리를 수행해야 하는 응용 프로그램은 Service Broker에 제공되는 큐 및 병렬 처리 기능을 통해 많은 작업을 신속하고 효율적으로 처리할 수 있다. 응용 프로그램은 처리할 데이터를 Service Broker 큐에 저장한다. 프로그램은 정기적으로 큐에서 데이터를 읽고 해당 데이터를 처리한다. 응용 프로그램은 Service Broker에 제공되는 안정적인 메시징 기능을 통해 요청이 시작된 컴퓨터 이외의 다른 컴퓨터에서 일괄 처리를 수행할 수 있다.

[SQL Server] SSIS Error – Warning: Null value is eliminated by an aggregate or other SET operation.

[SQL Server][MSSQL] Cannot use TEXTIMAGE_ON when a table has no text, ntext, image, varchar(max), nvarchar(max), varbinary(max), xml or large CLR type columns.