무료기술지원 1탄 (샘플이라고 하는게 좋을듯)

* 동작 환경
SQL Server 2008 (패치는 대충 이빠이 되어 있음)
게시 - 배포 - 구독 분리 환경이며, 배포에서 구독 반영이 느림 

데이터베이스 용량 :  1TB 이상

CPU 16Core
Memory 16GB
Disk Raid 1+0 (6+6)

* 병목포인트 조사
CPU
  1~4% 정도 사용
Memory
  Page life expectancy 1000 이상
  Lazy writes/sec 거의 없음
  Memory Grants Pending 거의 없음
  Memory Grants Outstanding 거의 없음
Disk
  Idle 0
  Avg. Disk sec/Transfer 5ms ~ 100ms (보통 20 이하여야 합니다.)
  Avg. Disk Queue Length 1
  Avg. Disk Read Bytes/sec 3MB
  Avg. Disk Bytes/Read 8K (모두 랜덤 I/O 임)

12장의 디스크 이므로 8k * 200 (IOPS)
1.6M * 12 장 약 19.2MB가 나올 수 있는데, 경험상 DAS 는 10MB 의 랜덤 I/O 를 처리 할 수 있습니다.
3MB 정도 처리하고 있다면 Disk 는 좀 더 쓸 수 있는 상황.

waitstat 을 보면 PageIOLatch 가 30%, PageLatch 20% 정도 최상위를 랭크에 있음 (핫스팟 인가? ^^;)

사실 SQL 서버에 INSERT UPDATE DELETE 를 하려면, 먼저 데이터를 확인 해야 하기 때문에 읽으러 들어가야 한다. 그런데 그 데이터들이 완전히 RANDOM 하게 DISTRIBUTED 되었다면, DISK I/O 가 증가하게 된다. 그러므로 사용자가 사용하는 데이터 영역만큼 메모리에서 캐시 할 수 있도록 데이터 메모리가 더 필요하다 사실 메모리만 증설해도 이 이슈는 해결 가능 하리라 본다. 왜냐면, 1개로 처리하더라도 병목 포인트를 풀어주면 충분히 해결 가능 하리라 보기 때문이다.

구독의 select * from sysprocesses where spid > 50 결과
1개의 spid 만 열심히 복제 반영중

솔루션 : 배포 agent 속성의 마지막에 -SubscriptionStreams 32 추가 후 agent restart! -- 64로 설정하면 아래 아티클에서 INSANE 이라고 ...-_-
결  과 : 약 5배에서 10배의 성능을 보임
참  고 :
http://blogs.msdn.com/b/repltalk/archive/2010/03/01/navigating-sql-replication-subscriptionstreams-setting.aspx
http://blogs.msdn.com/b/sqlcat/archive/2007/05/07/sql-server-2005-transactional-replication-benefit-of-using-subscriptionstreams-for-low-bandwidth-high-latency-environments.aspx

http://support.microsoft.com/kb/956600/en-us

http://support.microsoft.com/kb/953199/en-us

주의사항 : 가장 좋은 Stream 개수를 찾아야 함. FK 가 있으면, 오류가 발생 할 수 있으므로, NOT FOR REPLICATION 옵션이 필요 할 수 있음

복제가 T-SQL 로 돌아갈수도 있고 파라메터화된 프로시저로 동작하게 할 수 있다.

뭘 쓰면 빠르겠는가? 당근 프로시저를 써야지

그럼 어떻게 확인 하는가?

select * from sysarticles 에서 확인하면 되고,

status 가 8 이면 문제가 있는 혹은 성능이 느린 T-SQL 이고,

status 가 16 이면 성능이 좋은 파라메터화된 프로시저 이다.

how to change? (즉시 반영 됩니다.)

exec sp_changearticle @publication =N'pubname', @article =N'tablename', @property ='status', @value ='parameters'