저장 프로 시저는 (사용 커서) 내가 서버 2 (연결된 서버 사용) 서버 1에서 처리되지 않은 (<code>processed=0</code>) 레코드를 삽입 할 수있는 아래의 코드를

Question

너무 느려, 한 번이 processed=1

으로 업데이트해야 삽입

INSERT INTO SELECT FROM WHERE processed=0 
UPDATE processed=1 WHERE processed=0 

질의 2 :

을 그냥

검색어 1을 사용했다 데이터베이스의 모든 오류가있을 경우, 그것은 영향을 미칠 것이기 때문에 내가 검색어 1 멀리 (1 개 기록 업데이트를 30 초 소요)

DECLARE pending_records CURSOR LOCAL FOR 
SELECT FROM WHERE processed=0 

OPEN pending_records 

FETCH NEXT FROM pending_records INTO @UniqueID 

WHILE @@FETCH_STATUS=0 
BEGIN 

INSERT INTO SELECT FROM WHERE UniqueID=@UniqueID 

IF @@ROWCOUNT=1 .... UPDATE processed=1 WHERE UniqueID=@UniqueID 

FETCH NEXT FROM pending_records INTO @UniqueID 

END 

CLOSE pending_records 

DEALLOCATE pending_records 

쿼리 1은 슈퍼 빠른 및 쿼리 사용하여 커서가 너무 느립니다 기록. 참고 : 추가 설정이 필요하므로 지금 당장 DISTRIBUTED TRANSACTION을 사용할 수 없습니다.

Answer 1

시도해 볼 수 있습니다. 별도의 처리 플래그를 넣는 테이블에 여분의 열을 추가하십시오. 저장 프로 시저의 시작 부분에 GUID를 생성하고 테이블 업데이트 :

UPDATE <table> 
SET processing_flag = <GUID> 
WHERE processed = 0; 

을 그리고 당신은 단순히 당신이 = 1을 처리 설정할 수 있습니다 이후

INSERT INTO <target> 
SELECT <columns> 
FROM <source> 
WHERE processed = 0 AND processing_flag = <GUID>; 

하여 다른 서버에 행을 전송할 수 있습니다 processing_flag를 소거한다. 실패한 경우 처리 된 = 0 및 processing_flag! = NULL에 의해 전송되지 않은 모든 행을 선택할 수 있습니다.

단일 행을 전송하는 것과 비슷한 문제가있었습니다. 그들 모두를 하나로 묶어 내 문제가 해결되었습니다.

대상 서버 또는 연결이 너무 느릴 수 있습니다.

Answer 2

'FAST_FORWARD'인수를 사용해 보셨습니까?

'FAT_FORWARD'는 성능 최적화가 설정된 FORWARD_ONLY, READ_ONLY 커서를 지정합니다. SCROLL 또는 FOR_UPDATE도 지정되어 있으면 FAST_FORWARD를 지정할 수 없습니다.

자세히 알아보기 here