Bora.Choi

에러 메시지 :

           A time-out occurred while waiting for buffer latch -- type 2, bp 000000C959C8B640, page 3:1524485, stat 0x40d, database id: 48, allocation unit Id: 536870912/281475513581568, task 0x0000000008059468 : 8, waittime 300 seconds, flags 0x3a, owning task 0x0000000006875468. Not continuing to wait.

유형

현재 래치 획득 요구의 래치 모드. 다음 매핑을 사용하는 숫자 값입니다. 0 - NL (사용되지 않음); 1 - KP; 2 - SH; 3 - UP; 4 - EX; 5 - DT.

이유 :

           We would end up with data or data structure inconsistency. To avoid inconsistency SQL Server uses Synchronization Mechanisms like Locks,Latches and Spinlocks.

에러 이후 :  Latch 대기 시간 기다리다가 작업이 중지 됨 (복원,패키지 등. )

5분이상 지속 될 경우 모든 스래드가 포함된 미디 덤프가 발생 한다.

래치 유형은 sysprocesses 의 대기 유형에서 식별 할 수 있음.

PAGEIOLATCH_ * : sysprocesses의이 waittype은 SQL Server가 버퍼 풀 페이지의 물리적 I / O가 완료 될 때까지 기다리고 있음을 나타냅니다. 

                                 1. PAGEIOLATCH_ *는 일반적으로 과도한 IO를 수행하는 쿼리를 조정하여 해결됩니다 (보통 물리적 IO의 양을 줄이기 위해 인덱스 (또는) 통계를 추가, 변경 및 제거 함).

                                 2. 디스크 병목 현상이 있는지 확인하고 수정하십시오 (Pageiolatch 대기 시간 (ex> 30 ms)).

PAGELATCH_ * : sysprocesses의이 waittype은 SQL Server가 데이터베이스 페이지에 대한 액세스를 기다리고 있지만 페이지가 실제 IO를 수행하지 않음을 나타냅니다. 

1.        이 문제는 대개 같은 시간에 동일한 물리적 페이지에 액세스하려고 시도하는 다수의 세션으로 인해 발생합니다. 우리는 spid의 대기 리소스를 봐야합니다. wait_resource는 페이지 번호입니다 (형식은 dbid : file : pageno).

          액세스 중입니다. 

2. 우리는 DBCC PAGE를 사용하여 우리가 논쟁의 대상이되는 페이지의 객체 또는 유형을 식별 할 수 있습니다. 또한 할당, 데이터 또는 텍스트에 대한 경합인지 여부를 결정하는 데 도움이됩니다.

 -> 매번 다르고 디비도 다르고 테이블도 다름.

3.        SQL Server에서 가장 자주 대기하는 페이지가 tempdb 데이터베이스에 있으면 dbid 2의 페이지 번호에 대한 대기 리소스 열을 확인합니다.    http://support.microsoft.com에 언급 된 tempdb 할당 래치 경합이 발생할 수 있습니다 . / kb / 328551

4. 페이지가 사용자 데이터베이스에 있으면 테이블 끝의 동일한 페이지에 대해 모든 스레드가 경합하는 ID와 같은 단조 키에 클러스터형 인덱스가 있는지 확인하십시오. 이 경우 우리는 다른 것을 선택해야합니다.

          다른 페이지에 작업을 분산시키기 위해 클러스터 된 인덱스 키.

LATCH_ * :    비 buf 래치 대기는 여러 가지로 인해 발생할 수 있습니다. sysprocesses의 wait resource 열을 사용하여 관련된 래치 유형을 결정할 수 있습니다 (KB 822101). 

1.        매우 일반적인 LATCH_EX 대기는 프로파일 러 추적 또는 sp_trace_getdata 실행으로 인한 것 입니다. 자세한 내용은 KB 929728을 참조하십시오 .

2.        자동 성장 및 자동 축소.

***********   참고  ***********************

Types of the Latch:

Buffer (BUF) Latch

Used to synchronize access to BUF structures and their associated database pages.

Buffer “IO” Latch

A subset of BUF latches used when the BUF and associated data/index page is in the middle of an IO operation (Reading page from disk or writing page to disk).

Non-Buffer (Non-BUF) Latch

These are latches that are used to synchronize general in-memory data structures generally used by queries/tasks executed by parallel threads, auto grow operations , shrink operations etc. 

Latch modes

Keep (KP) Latches

Used to ensure that the page is not released from memory while it is in use. 

Shared (SH) Latches

Used for read-only access to data structures and prevent write access by others threads.

This mode allows shared access. 

SH is compatible with KP, SH, and UP.  It should be noted that although in general SH implies read-only access, it is not always the case. For buffer latches SH is the minimum mode required in order to read a data page.

Update (UP) Latches

Allows read access to the data structure(Compatible with SH and KP), but prevents other EX-latch access. 

Used for write operations when torn page detection is off and when AWE is not enabled.

Exclusive (EX) Latches

Prevents any read activity from occurring on the latched structure. EX is only compatible with KP.

Used during read IO during write IO when torn page detection is on or AWE is enabled.

Destroy (DT) Latches

Used when removing BUFs from the buffer pool, either by adding them to the free list or unmapping AWE buffers. 

Latch compatibility

일부 버전에서 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

1.    SQL Server 2016 (데이터베이스 엔진) 의 새로운 기능

-       Automatic Soft NUMA

n  SQL Server 2016에서는 한 NUMA 노드에 8개 이상의 processor가 있을 경우 자동으로 Soft-NUMA를 구성해 확장성을 높여줌

-       Dynamic Memory Object (CMemThread) Partitioning

n  CMemThread 병목 발생시 자동으로 per NUMA or per CPU Partitioning으로 변경해 CMemThread 대기 완화

-       Multiple Log Writers

n  인스턴스당 4개까지(one per H/W NUMA node) Log Writer thread 생성

-       Parallel Recovery

n  Database Recovery 단계 중 Redo에 대해 병렬 처리

-       SOS_RWLock

n  RWLock은 Internal Structure에 대한 일관성을 위해 사용되는 동기화 개체로 SQL Server 2014까지는 내부적으로 spinlock이 사용되었습니다.

n  SQL Server 2016에서는 불필요한 spinlock 대기를 없애도록 re-design되어 scalability를 높임

-       DBCC CHECK* 성능 향상

n  1TB 데이터베이스에 대한 내부 테스트 결과 7배 성능 향상

-       In-direct Checkpoint 기본

n  In-direct checkpoint는 SQL Server 2014에서 추가된 기능이며, SQL Server 2016에서는 Default 설정으로 적용됩니다.

-       Larger Data Writes

n  2016 이전은 한번에 최대 32 Data Pages (256KB)를 Write하였으며, SQL 2016에서는 최대 128 pages (1MB)로 대량 쓰기 성능 향상됨

(LazyWriter, Checkpoint, Bulk Insert 등에 사용)

-       OPTION (USE HINT('<hint1>', '<hint2>')) 같은 보다 일반적인 쿼리 힌트 모델에 대한 지원이 추가 ( SP1 , https://support.microsoft.com/ko-kr/help/3189813/update-introduces-use-hint-query-hint-argument-in-sql-server-2016)

n  use hint 모양이 추가됨, 보다 직관 적인 힌트 형태가 사용 되어짐.

SELECT * FROM Person.Address 

WHERE City = 'SEATTLE' AND PostalCode = 98104

OPTION (RECOMPILE, USE HINT ('ASSUME_MIN_SELECTIVITY_FOR_FILTER_ESTIMATES', 'DISABLE_PARAMETER_SNIFFING'));

GO 

-       sys.dm_exec_valid_use_hints DMV가 추가됨 – 모든 힌트 목록을 확인 할 수 있음

-       sys.dm_exec_query_statistics_xml DMV이 추가되어 실행 계획 XML 임시 통계 추가 :  기존에 query plan을 수집하기 위해 했던 작업이 간소화 해 짐.

-       estimated_read_row_count 열이 sys.dm_exec_query_profiles에 추가 (SQL2014에서도 있음 )

n  DMV를 사용하여 느리게 실행되는 쿼리 부분을 결정

n  타임스탬프 열을 사용하여 이 DMV를 다른 성능 카운터(예: 성능 모니터, xperf)와 조인

-       UTF-8에 대한 지원

-       메모리 액세스에 최적화된 테이블에 대한 Transact-SQL 개선 사항

n  UNIQUE 제약 조건 및 인덱스가 지원됩니다.

n  메모리 액세스에 최적화된 테이블 간의 FOREIGN KEY 참조가 지원

n  비고유 인덱스에서 해당 키에 NULL 값을 허용할 수 있음

n  TRIGGER가 메모리 액세스에 최적화된 테이블에서 지원 ( insteadof 트리거는 지원되지 않음)

n  스키마 변경합니다(열 추가/삭제/변경, 제약 조건 추가/삭제).

-       프로시저 LOB를 허용

n  본 프로시저에서 문자열 함수(예: LTrim 또는 Substring)에 전달된 매개 변수 가능

-       통계의 업데이트에 대해 선형 폭이 강조되는 임계값

n  대형 테이블에서 통계의 자동 업데이트가 한층 더 강화되었습니다(호환성 수준 130). 대형 테이블의 경우 SQL Server 2016부터 통계 자동 업데이트를 트리거하는 임계값이 20%가 되어 임계값이 테이블에서 행이 증가한 수만큼 줄어든 상태로 시작됩니다(백분율로 표시). 임계값을 줄이기 위해 2371 추적 플래그를 설정하지 않아도 됩니다.

n  대형 테이블일 경우 20% 가 크게 느껴질 수 있는데 조정 가능 해서 성능 향상에 도움이 됨.

-        Live Query Statistics

n  Management Studio는 활성 쿼리의 활성 실행 계획을 보는 기능을 제공합니다. 이 활성 쿼리 계획을 통해 제어권이 한 쿼리 계획 연산자에서 다른 연산자로 흘러갈 때 쿼리 실행 프로세스를 실시간으로 파악할 수 있습니다.

-        Monitoring Performance By Using the Query Store (https://msdn.microsoft.com/ko-kr/dn817826)

n  쿼리 저장소는 DBA에게 쿼리 계획 선택 및 성능에 대한 정보를 제공하는 새로운 기능입니다. 쿼리 계획 변경으로 인해 발생하는 성능 차이를 신속하게 찾을 수 있도록 하여 성능 문제 해결을 간소화합니다. 이 기능은 쿼리, 계획 및 런타임 통계의 기록을 자동으로 캡처하고 검토할 수 있도록 이 기록을 유지합니다. 

-      TempDB 데이터베이스

n  Tempdb에 대한 추적 플래그 1117 및 1118이 필요하지 않습니다. Tempdb 데이터베이스가 여러 개 있을 경우 모든 파일은 증가 설정에 따라 동시에 크기가 증가

n  기본적으로 설치 시 CPU 개수 또는 8개 중 적은 수만큼 tempdb 파일이 추가

n  Tempdb 데이터베이스 파일에 대해 여러 볼륨을 지정할 수 있습니다. 여러 디렉터리가 지정된 경우 tempdb 데이터 파일은 라운드 로빈 방식으로 여러 디렉터리에 분배됩니다.

-       기본 제공 JSON 지원

-       PolyBase 제공 - Hadoop 또는 Azure Blob Storage에 저장된 데이터에 액세스하고 임시 방식으로 데이터를 쿼리할 수 있습니다

-       Stretch Database -스트레치 데이터베이스는 기록 데이터를 Microsoft Azure 클라우드에 투명하고 안전하게 마이그레이션하는 SQL Server 2016의 새로운 기능입니다

-       이제 TRUNCATE TABLE 문은 지정된 파티션의 잘림을 허용합니다

-       Azure SQL 데이터베이스 복제가 지원됨

-      향상된 고가용성 기능 – Always ON

n  Always On 가용성 그룹은 Windows Server 2016에서 분산 트랜잭션 및 DTC를 지원

n  이제 데이터베이스가 오프라인으로 전환될 때 장애 조치(failover)하도록 Always On 가용성 그룹 을 구성할 수 있습니다.

n  이제 Always On은 암호화된 데이터베이스를 지원합니다

n  가용성 그룹의 동기화 처리량은 주 복제본에서 로그 블록의 병렬 및 빠른 압축, 최적화된 동기화 프로토콜, 보조 복제본에서 로그 레코드 다시 실행 및 병렬 압축 풀기를 통해 10배까지 증가되었습니다. 따라서 읽기 가능한 보조 복제본의 새로 고침이 증가되고 장애 조치(failover) 시 데이터베이스 복구 시간이 줄어듭니다. 

export NLS_LANG=American_America.KO16MSWIN949

export LANG=C

export EDITOR=vi

오라클 vs MS SQL 함수 비교

수식/수치 연산 함수

다음은 Oracle에서 지원하는 수식/수치 연산 함수와 그에 상응하는 Microsoft SQL Server의 함수를 정리한 표입니다.

문자열 함수

다음은 Oracle에서 지원하는 문자열 함수 및 그에 상응하는 Microsoft SQL Server의 함수를 정리한 표입니다.

날짜 함수

다음은 Oracle에서 지원하는 날짜 함수 및 그에 상응하는 Microsoft SQL Server의 함수를 정리한 표입니다.

변환 함수

다음은 Oracle에서 지원하는 변환 함수 및 그에 상응하는 Microsoft SQL Server의 함수를 정리한 표입니다.

기타 행 수준 함수

다음은 Oracle에서 지원하는 기타 행 수준 함수 및 그에 상응하는 Microsoft SQL Server의 함수를 정리한 표입니다.

집계 함수

다음은 Oracle에서 지원하는 집계 함수 및 그에 상응하는 Microsoft SQL Server의 함수를 정리한 표입니다.

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/

데이터베이스 성능 튜닝의 3대 핵심 요소 

1. SQL 부하 해소 
2. 데이터 베이스 Call 최소화 
3. I/O 효율화 

정의 데이터베이스 : 물리적인 디스크에 저장된 데이터집합(데이터파일, 리두로그파일, 컨트롤파일) 인스턴스 : 공유메모리(SGA)와 이를 엑세스하는 프로세스 집합 ★하나의 인스턴스는 하나의 데이터베이스를 엑세스(Single), 여러개의 인스턴스는 하나의 데이터베이스를 엑세스(RAC)

나.SQL Server 아키텍처

정의 하나의 인스턴스당 최고 32,767개의 데이터베이스를 정의해서 사용 기본적으로 시스템데이터베이스가 만들어지면, 사용자데이터베이스를 추가하여 생성하는 구조

시스템데이터베이스 : mster, model, msdb, tempdb 등
사용자데이터베이스 : 데이터파일(mdf), 트랜잭션로그파일(ldf), 보조데이터파일(ndf)

파일구조

가.데이터파일

1) 블록(=페이지)

• 대부분의 DBMS에서는 I/O 블록단위로 이루어짐
• 데이터를 읽고 쓸때의 논리적인 단위
• SQL 성능을 좌우하는 가장 중요한 성능지표
• 옵티마이저의 판단에 가장 큰 영향을 미치는 요소

2)익스텐트(Extent)

• 테이블스페이스로부터 공간을 할당하는 단위

• 균일익스텐트(Uniform) : 64KB 이상의 공간을 필요로 하는 테이블이나 인덱스를 위해 사용됨
  8개 페이지 단위로 할당된 익스텐트를 단일 오브젝트가 모두 사용
• 혼합익스텐트(Mixed) : 한 익스텐트에 할당된 8페이지를 여러 오브젝트가 나누어 사용
  모든 테이블이 처음에는 혼합 익스텐트로 시작하지만 64KB가 넘으면서 두번째부터는 균일익스텐트 사용

3)세그먼트(Segment)

• 테이블, 인덱스,Undo 처럼 저장공간을 필요로하는 데이터베이스 오브젝트 (한개 이상의 익스테트 사용)
• 파티션은 오브젝트와 세그먼트가 1:M (파티션을 만들면 내부적으로 여러개의 세그먼트가 만들어짐)
• 한 세그먼트에 할당된 엑스텐트가 여러 데이터파일에 흩어져 저장됨(디스크 경합감소.I/O 분산효과)

4) 테이블스페이스(Tablespace) 

• 세그먼트를 담는 콘테이너로서 여러개의 데이터파일로 구성됨
• 사용자는 데이터파일을 직접 선택할수 없으므로 실제 파일을 선택하고 익스텐트를 할당하는것은 DBMS의 몫

DUAL 테이블 특징

 - 사용자 SYS가 소유하며 모든 사용자가 액세스 가능한 테이블이다.
- SELECT ~ FROM ~ 의 형식을 갖추기 위한 일종의 DUMMY 테이블이다.
- DUMMY라는 문자열 유형의 칼럼에 'X'라는 값이 들어 있는 행을 1건 포함하고 있다.

날짜형 함수
  날짜형 함수는 DATE 타입의 값을 연산하는 함수이다.
  Oracle의 TO_NUMBER(TO_CHAR( )) 함수의 경우 변환형 함수로 구분할 수도 있으나 SQL Server의 YEAR, MONTH,DAY 함수와 매핑하기 위하여 날짜형 함수에서 설명한다. 

변환함수
변환형 함수는 특정 데이터 타입을 다양한 형식으로 출력하고 싶을 경우에 사용되는 함수이다.  

암시적 데이터 유형 변환의 경우 성능 저하가 발생할 수 있으며, 자동적으로 데이터베이스가 알아서 계산하지 않는 경우가 있어 에러를 발생할 수 있으므로 명시적인 데이터 유형 변환 방법을 사용하는 것이 바람직하다. 

명시적 데이터 유형 변환에 사용되는 대표적인 변환형 함수는 다음과 같다. 

CASE 표현
IF-THEN-ELSE 논리와 유사한 방식으로 표현식을 작성해서 SQL의 비교 연산 기능을 보완하는 역할을 한다.  

집계 함수와 NULL

  리포트의 빈칸을 NULL이 아닌 ZERO로 표현하기 위해 NVL(Oracle)/ISNULL(SQL Server) 함수를 사용하는 경우가 많은데, 다중 행 함수를 사용하는 경우는 오히려 불필요한 부하가 발생하므로 굳이 NVL 함수를 다중 행 함수 안에 사용할 필요가 없다.
다중 행 함수는 입력 값으로 전체 건수가 NULL 값인 경우만 함수의 결과가 NULL이 나오고 전체 건수 중에서 일부만 NULL인 경우는 NULL인 행을 다중 행 함수의 대상에서 제외한다.
   SUM(CASE MONTH WHEN 1 THEN SAL ELSE 0 END)처럼 ELSE 절에서 0(Zero)을 지정하면 불필요하게 0이 SUM 연산에 사용되므로 자원의 사용이 많아진다.
하나가 Oracle의 SUM(NVL(SAL,0)), SQL Server의 SUM(ISNULL (SAL,0)) 연산이다. 개별 데이터의 급여(SAL)가 NULL인 경우는 NULL의 특성으로 자동적으로 SUM 연산에서 빠지는 데, 불필요하게 NVL/ISNULL 함수를 사용해 0(Zero)으로 변환시켜 데이터 건수만큼의 연산이 일어나게 하는 것은 시스템의 자원을 낭비하는 일이다.

NATURAL JOIN

NATURAL JOIN은 두 테이블 간의 동일한 이름을 갖는 모든 칼럼들에 대해 EQUI(=) JOIN을 수행한다. NATURAL JOIN이 명시되면, 추가로 USING 조건절, ON 조건절, WHERE 절에서 JOIN 조건을 정의할 수 없다. 그리고, SQL Server에서는 지원하지 않는 기능이다. 

SELECT DEPTNO, EMPNO, ENAME, DNAME
FROM   EMP NATURAL JOIN DEPT ;

NATURAL은 식별자를 가질 수 없다. 또한 동일한 열에 대해서는 생략된다. 

USING 조건절

NATURAL JOIN에서는 모든 일치되는 칼럼들에 대해 JOIN이 이루어지지만, FROM 절의 USING 조건절을 이용하면 같은 이름을 가진 칼럼들 중에서 원하는 칼럼에 대해서만 선택적으로 EQUI JOIN을 할 수가 있다. 다만, 이 기능은 SQL Server에서는 지원하지 않는다. 

SELECT *
FROM DEPT JOIN DEPT_TEMP
USING (DEPTNO);

SELECT *
FROM DEPT JOIN DEPT_TEMP
USING (LOC, DEPTNO);

USING절에 명시된 컬럼이 기준이 되어 동일한 열들을 조인한다. 명시된 데이터가 앞에 나온다. 

SELECT *
FROM DEPT JOIN DEPT_TEMP
USING (DEPTNO);

SELECT *
FROM DEPT JOIN DEPT_TEMP
USING (LOC, DEPTNO);

USING절에 명시된 컬럼이 기준이 되어 동일한 열들을 조인한다. 명시된 데이터가 앞에 나온다. 

• natural join 에선 using 절 사용 불가하지
• using 절은 Inner join 에서만 사용하는 구문
• Inner Join 에서 On 절 또는 Using 절 필수
• Inner Join 에서 On 절 사용결과 와 Using 절 결과가 다름(Select * 시 조회 컬럼수가 다름)
• Inner Join 에서 On 절 사용 : 모든 항목이 조회됨
• Inner Join 에서 Using 절 사용 : 조인키 항목은 한번만 조회됨

SELECT ...
FROM   TABLE
WHERE  CONDITION AND CONDITION
START WITH CONDITION
CONNECT BY [NOCYCLE] CONDITION AND CONDITION
[ORDER SIBLINGS BY COLUMN, COLUMN......]

[성능 TEST No2]

[성능 TEST No3]

성능 TEST No4]

1.     SQL 2008이 있는 경우  - 아래 두개의 시험을 봐야 MCSA가 됩니다.  Admin 기준. 

MCSE: Data Platform involves

·   A pass in Microsoft Certified IT Professional (MCITP) Database Administrator 2008 or Database Developer 2008 (70-450 or 70-451)

• Exam 70-457: Transition your MCTS on SQL Server 2008 to MCSA: SQL Server 2012 – Part 1
• Exam 70-458: Transition your MCTS on SQL Server 2008 to MCSA: SQL Server 2012 – Part 2
• Exam 70-459: Transition your MCITP: Database Administrator 2008 or MCITP: Database Developer 2008 to MCSE:Data Platform

MCSE: Business Intelligence involves

A pass in Microsoft Certified IT Professional (MCITP) Business Intelligence 2008 (70-452)

·         Exam 70-457: Transition your MCTS on SQL Server 2008 to MCSA: SQL Server 2012 – Part 1

·         Exam 70-458: Transition your MCTS on SQL Server 2008 to MCSA: SQL Server 2012 – Part 2

·         Exam 70-460: Transition your MCITP: Business Intelligence Developer 2008 to MCSE: Business Intelligence 

2.     처음 부터 SQL 2012를 취득 하고 자 한다면 

master에 Sp를 생성하고 모든 DB의 객체 view를 인식 할 수 있게 하는 방법. 

이렇게 하면  동적 쿼리를 사용하지 않아도 됨. 

어떤 사용자도 호출 할 수 있게 하려면 public에 권한 부여

등록을 해지 하고 싶다면 ?

1.  메모리 덤프를 crash dump 파일 방식으로 실행 합니다.

2.  명령 창에 관련 symbols 파일을 받습니다.  ( 파일 열어 보면 명령창 입력 하는 부분이 있습니다. )

sympath srv*C:\PublicSymbols*http://msdl.microsoft.com/download/symbols;  <- C 밑에 받게 설정.

3.  Symbols 파일을 내려 받습니다.

.reload /f sqlservr.exe  ß--  sql 지정해 주지 않으면 모든 실행파일에 대한 것 받습니다 오래 걸립니다.   허나 제 컴이 2012만 설치되어 있어서 서버 버전과 같은 sql이 있어야 할 것 같은 느낌 입니다.

4.  문제되는 스래드 를 파악 해 봅니다. ^^

~~[스래드번호]s  

아래 노란색이 스래드 번호 입니다.

2014-10-31 07:07:06.960 서버           Process 0:0:0 (0x3318) Worker 0x000000002A7EA1A0 appears to be non-yielding on Scheduler 22. Thread creation time: 13059177216471. Approx Thread CPU Used: kernel 0 ms, user 70543 ms. Process Utilization 30%. System Idle 68%.

5.     자세한 내역을 봅니다. 

kL100

15번 파일을 그런 단계로 본 내역입니다.  Call site 값으로 세부적으로 뭔가 봐야 하는데 그 다음 명령을 모르겠습니다.

6.     참고로

.cxr sqlservr!CXStmtQuery::ErsqExecuteQuery+0x602    이 노란색이 call site 값인 것 같은데요..

7.     아래 부분 처럼

du 0x00000101`c21ae200 L100    이게 쿼리 내역을 보는 법인 것 같습니다.  RetAddr 값 일까요???  ㅋㅋ.

답변 받은 분도 명령창 번호가 같은걸로 봐서는  15번 덤프 파일을 가지고 분석 했습니다

참고로 ) 여러가지 원인이 있다는 Non-yielding Scheduler  dump 내역 입니다.

http://technet.microsoft.com/en-us/library/cc917684.aspx#XSLTsection129121120120