Bora.Choi

일부 버전에서 CU 버전 으로 업그레이드 후 CDC의 변경 테이블에 업데이트 행의 순서대로 정렬되어야 하는데 잘 못 정렬이 되어 데이터 변경 반영이 잘 못 될 수 있는 버그가 발견 되었습니다.

해당 버그는 2017.03.22일에 최종 패치가 되었으며 관련 하여, 모든 누적 패치 파일이 수정되었습니다. 

현재는 CDC를 사용하고 있지 않지만.  사용하는 서버가 있다면 예전에 받아 업그레이 된 버전이 잘 못 된 것이기 때문에  추가로 누적 업데이트 버전을 설치해야 문제가 해결 됩니다. 

관련 설명 :

https://blogs.msdn.microsoft.com/sql_server_team/cdc-functionality-may-break-after-upgrading-to-the-latest-cu-for-sql-server-2012-2014-and-2016/?utm_source=Brent+Ozar+Unlimited%C2%AE+List&utm_campaign=228cf805e8-Weekly_Links_2017_04_09&utm_medium=email&utm_term=0_8e3e861dd9-228cf805e8-296468997&goal=0_8e3e861dd9-228cf805e8-296468997&mc_cid=228cf805e8&mc_eid=00ebe8618a

조짐

Microsoft SQL Server 2012, 2014 또는 2016 데이터베이스에 대해 변경 데이터 캡처 를 사용하도록 설정 하면 변경 테이블 의 __ $ 작업 열이 업데이트 된 행에 대해 잘못 정렬 될 수 있습니다. 행을 업데이트하면 변경 테이블에 __ $ 작업 에 대한 삭제 및 삽입과 함께 두 개의 행이 있습니다 . 그러나 삽입 작업이 예기치 않게 삭제 작업 전에 나타날 수 있습니다. 응용 프로그램이 기본 키 제약 조건을 사용하여 행을 다른 테이블에 다시 적용하면 다음 기본 키 위반이 발생할 수 있습니다.
 

메시지 2627, 수준 14, 상태 1, 줄 6 PRIMARY KEY 제약 조건 ' Primary_Key_name '. ' table_name ' 개체에 중복 키를 삽입 할 수 없습니다 . 중복 키 값은 ( 값 )입니다.

https://support.microsoft.com/en-us/help/3030352/fix-the-change-table-is-ordered-incorrectly-for-updated-rows-after-you

• SQL Server 2016 RTM 용 누적 업데이트 5
• SQL Server 2016 SP1 누적 업데이트 2
• SQL Server 2014 SP2 용 누적 업데이트 4
• SQL Server 2014 SP1 용 누적 업데이트 10
• SQL Server 2014 용 누적 업데이트 9
• SQL Server 2012 SP3 용 누적 업데이트 8
• SQL Server 2012 SP2 용 누적 업데이트 7

MSDN에 참고 

• https://msdn.microsoft.com/en-us/library/ms189573(v=sql.105).aspx

Database Checkpoints (SQL Server)

• https://msdn.microsoft.com/en-us/library/ms189573.aspx

CHECKPOINT vs LAZY WRITER

• http://blog.sqlxdetails.com/checkpoint-vs-lazy-writer/

미니 덤프의 추출을 요청 드리며, 해당 방법에 대하여 다음과 같이 안내 드립니다.

 SQL Performance Baseline Template v0.docx

1.     성능 Counter

http://blogs.technet.com/b/askcore/archive/2012/03/16/windows-performance-monitor-disk-counters-explained.aspx

Disk Transfers/sec (Disk Reads/sec, Disk Writes/sec) 

Perfmon captures the total number of individual disk IO requests completed over a period of one second.

If the Perfmon capture interval is set for anything greater than one second, the average of the values captured is presented. 
Disk Reads/sec and Disk Writes/sec are calculated in the same way, but break down the results in read requests only or write requests only, respectively.

1초 기간에 걸쳐 요청에 대한 완료된 개별 Disk I/O 총 수,  수집 간격이 설정되어 있지 않으면 평균을 이미 한다.

디스크 초당 읽기, 쓰기도 같은 방법이다.

Avg. Disk Bytes/Transfer (Avg. Disk Bytes/Read, Avg. Disk Bytes/Write) 
Displays the average size of the individual disk requests (IO size) in bytes, for the capture interval.

Example: If the system had ninety nine IO requests of 8K and one IO request of 2048K, the average will be 28.4K. Calculation = (8k*99) + (1*2048k) / 100 
The Avg. Disk Bytes/Read and Avg. Disk Bytes/Write counters break down the results showing the average size for only read requests or only write requests, respectively. 

수집된 간격의 바이트의 개발 디스크 요청의 평균 크기이다.

예) 8K 의 99번의 요청과  2048K 하나의 IO 요청이 있었다면

(8k*99) + (1*1024) /100 =    부근에 있다.

Avg. Disk sec/Transfer (Avg. Disk sec/Read, Avg. Disk sec/Write) 
Displays the average time the disk transfers took to complete, in seconds.

Although the scale is seconds, the counter has millisecond precision, meaning a value of 0.004 indicates the average time for disk transfers to complete was 4 milliseconds. 
This is the counter in Perfmon used to measure IO latency. 
I wrote a blog specifically about measuring latency with Perfmon. For details got to “Measuring Disk Latency with Windows Performance Monitor”. 

           디스크에 전송하는데 완료한 초에 대한 평균 시간이다.

          스케일은 초 이지만 카운터의 값이 0.004의 값을 완료 하는데 4밀리초로 하였고, 완료하기 까지 평균 시간을 갖는다.

           이 카운터는 IO 대기 시간을 측정하는데 사용된다.

디스크 지연에 대한 블로깅 : http://blogs.technet.com/b/askcore/archive/2012/02/07/measuring-disk-latency-with-windows-performance-monitor-perfmon.aspx

SQLServer:Buffer Manager\Readahead pages/sec

 미리 읽기 수 , 디스크에서 읽어서 Buffer pool로 미리 읽어 오는 작업

(SQL 서버의 저장소 엔진은 성능 최적화 메커니즘라는 이름의 미리 읽기 (짧은 RA)를 지원합니다. 그 목적은 쿼리 실행 계획을 이행하는 데 필요한 데이터 및 인덱스 페이지를 예상하고 실제로 쿼리에 의해 사용되기 전에 버퍼 풀 (캐시)에 해당 페이지를 가져오고있다. 이 계산을 할 수 있습니다 및 I / O는 CPU와 디스크를 모두 최대한 활용 하기 위해 )

 이 수치가 높으면 디스크 액세스 속도를 개선 하여 성능을 향상 시킬 수 있습니다.  필요 한 것 보다 더 많이 읽지 않도록 성능을 개선 할 수 있다.

테이블 스캔을 줄이기 위해 인덱스를 다시 생성 한다.

         참고 ) http://www.sqlshack.com/

http://blogs.technet.com/b/askcore/archive/2012/03/16/windows-performance-monitor-disk-counters-explained.aspx

Disk Transfers/sec (Disk Reads/sec, Disk Writes/sec) 
Perfmon captures the total number of individual disk IO requests completed over a period of one second.

If the Perfmon capture interval is set for anything greater than one second, the average of the values captured is presented. 
Disk Reads/sec and Disk Writes/sec are calculated in the same way, but break down the results in read requests only or write requests only, respectively.

1초 기간에 걸쳐 요청에 대한 완료된 개별 Disk I/O 총 수,  수집 간격이 설정되어 있지 않으면 평균을 이미 한다.

디스크 초당 읽기, 쓰기도 같은 방법이다.

Avg. Disk Bytes/Transfer (Avg. Disk Bytes/Read, Avg. Disk Bytes/Write) 
Displays the average size of the individual disk requests (IO size) in bytes, for the capture interval.

Example: If the system had ninety nine IO requests of 8K and one IO request of 2048K, the average will be 28.4K. Calculation = (8k*99) + (1*2048k) / 100 
The Avg. Disk Bytes/Read and Avg. Disk Bytes/Write counters break down the results showing the average size for only read requests or only write requests, respectively. 

수집된 간격의 바이트의 개발 디스크 요청의 평균 크기이다.

예) 8K 의 99번의 요청과  2048K 하나의 IO 요청이 있었다면

(8k*99) + (1*1024) /100 =    부근에 있다.

Avg. Disk sec/Transfer (Avg. Disk sec/Read, Avg. Disk sec/Write) 
Displays the average time the disk transfers took to complete, in seconds.

Although the scale is seconds, the counter has millisecond precision, meaning a value of 0.004 indicates the average time for disk transfers to complete was 4 milliseconds. 
This is the counter in Perfmon used to measure IO latency. 
I wrote a blog specifically about measuring latency with Perfmon. For details got to “Measuring Disk Latency with Windows Performance Monitor”. 

           디스크에 전송하는데 완료한 초에 대한 평균 시간이다.

          스케일은 초 이지만 카운터의 값이 0.004의 값을 완료 하는데 4밀리초로 하였고, 완료하기 까지 평균 시간을 갖는다.

           이 카운터는 IO 대기 시간을 측정하는데 사용된다.

디스크 지연에 대한 블로깅 : http://blogs.technet.com/b/askcore/archive/2012/02/07/measuring-disk-latency-with-windows-performance-monitor-perfmon.aspx

SQLServer:Buffer Manager\Readahead pages/sec

 미리 읽기 수 , 디스크에서 읽어서 Buffer pool로 미리 읽어 오는 작업

(SQL 서버의 저장소 엔진은 성능 최적화 메커니즘라는 이름의 미리 읽기 (짧은 RA)를 지원합니다. 그 목적은 쿼리 실행 계획을 이행하는 데 필요한 데이터 및 인덱스 페이지를 예상하고 실제로 쿼리에 의해 사용되기 전에 버퍼 풀 (캐시)에 해당 페이지를 가져오고있다. 이 계산을 할 수 있습니다 및 I / O는 CPU와 디스크를 모두 최대한 활용 하기 위해 )

 이 수치가 높으면 디스크 액세스 속도를 개선 하여 성능을 향상 시킬 수 있습니다.  필요 한 것 보다 더 많이 읽지 않도록 성능을 개선 할 수 있다.

테이블 스캔을 줄이기 위해 인덱스를 다시 생성 한다.

         참고 ) http://www.sqlshack.com/

펌 : http://blogs.the451group.com/information_management/2013/02/04/updated-database-lanscape-map-february-2013/

   Update 된 Database Map 입니다. 

tempdb 복구

tempdb는 SQL Server에서 정렬, GROUP BY를 사용한 집계, 커서 사용, 임시테이블 및 테

이블변수 사용, 일부 JOIN, SORT_IN_TEMPDB 옵션을 사용한 인덱스 생성, 데이터베이스

의 복구 작업 등에서 사용됩니다. 따라서, 손상 시에는 이와 같은 작업들을 진행할 수 없게

됩니다. tempdb의 손상 시 tempdb를 사용하는 작업은 다음과 같이 913 오류를 발생하며

정상적으로 실행되지 않습니다.

또한, tempdb의 size나 경로를 잘못 설정하여 SQL Server가 시작 시 정상 상태가 아닐 경우도 문제가 발생합니다.

tempdb가 주의 대상일 경우 재 시작 만으로 복구되기도 하지만 아닐 경우도 있습니다.

이럴 경우 최소 로그 이면서 tempdb를 skip 하면서 SQL 서버를 수동으로 시작 해야 합니다.

1.     명령 프론트를 실행하고 SQL Sever 실행된 경로로 이동 한다.

2.     tempdb 없이 실행하는 추적플래그 –T3609,  자동으로 실행하는 저장 프로시저를 실행하지 않게 하는 플래그 –T4022로 실행합니다.

3.     경우에 따라 최소 옵션인 –f도 포함합니다. , -m : 단일 사용자 모드  

실행하는 명령창은 닫지 말고 그대로 둡니다.

4.     경로가 잘 못 되었거나, size가 잘 못 되었을 경우 정보를 Alter database  구문을 통해 수정 합니다.

5.     SQL Server 2000 이하의 경우 주의 대상을 정상 상태로 변경 하기 위해서

명령으로 강제로 복원 할 수도 있습니다.

6.     3번의 실행 명령창에 Ctrl + c를 입력한 다음 “Y” 키를 눌러 SQL Server를 종료후 정상적으로 서비스를 기동 합니다.

7.     tempdb에 문제가 없는지 확인 합니다. 

와 어찌 하다가 이제서야 알게됨.

TABLEDIFF 유틸..   이름에서도 알 수 있 듯이 테이블 차이점 찾기 유틸입니다.

복제되어 있는 곳에서 데이터 불일치 문제를 해결하는데 유용하며,

batch file일 이용해서 사용 할 수 있습니다.

• 복제 게시자 역할을 하는 MicrosoftSQL Server 인스턴스에 있는 원본 테이블과 복제 구독자 역할을 하는 하나 이상의 SQL Server 인스턴스에 있는 대상 테이블을 행 단위로 비교할 수 있습니다.

• 행 개수와 스키마만 비교하여 비교 작업을 빨리 수행할 수 있습니다.

• 열 수준에서 비교할 수 있습니다.

• 대상 서버의 불일치를 해결하는 Transact-SQL 스크립트를 생성하여 원본 테이블과 대상 테이블을 일치시킬 수 있습니다.

• 결과를 출력 파일이나 대상 데이터베이스의 테이블에 기록할 수 있습니다.

데이터 형식이 sql_variant 인 열은 지원하지 않는다.

도움말 :http://msdn.microsoft.com/ko-kr/library/ms162843(v=SQL.100).aspx

• 사용권한

• 사용 법

• 결과