sql server

sql server는 날짜함수에 계속 약해왔음

-> 버그

trace flag(추적 플래그) 4199

https://support.microsoft.com/en-us/kb/974006

-> 2014에서 해결됨 

where 절에서   and /or 나열시 작성순서대로 나열되지 않음 -> sql 2000버전과 이 후버전에서 달리 나타남

-> 건수, 행수 알아낸다음에 나머지 검색 -> 2000 이후

-> equal 먼저 검색 -> 2000  이전

-> 버전이 바뀌고 나서 쿼리 처리 속도의 변화 생김

-> 각기 다른 case별 flag들을 각기 쓰는 것이 아닌 한방에 처리하겠다 ->  trace flag 4199

인덱스 추가 후 결과 정합성 문제

-> hotfix 설치후 TF4199적용 필요

-> sql server 2014 + sp1 에서 TF4199

-> 외국에선 이미 default, 국내에서는 운영중인 시스템에 적용했을시 리스크때문에 잘 적용 안되고 있는 현실

-----------

select * from dbo.Orders

where OrderID IN (select orderID from Customers);

-> FAIL

select * from dbo.Orders

where OrderID IN (select orderID.asd from Customers);

조건이 불만족 상태에서 모든 결과가 출력되는 case

->테이블 이름만 쓰지말고 별칭을 혼용할 필요가 있음

 

---------------

단일 열 값 동적 검색 조건 

-> 만능조회 쿼리

declare @sflag int= 10250

select * from dbo.Orders where OrderID in (10248, @sflag, @2, @3, @4, @5 )

 split  -> 가장 안 좋은 방법

select * from Northwind.dbo.Orders

where 

Intersect -> 교집합 구하는 함수

intersect 

(

select 10248 union all

...

...

------------

TVP ->  .net에서만 가능 -> 대량의 데이터를 매게변수로 변환 가능

client에서 넘길때 XML로 넘겨서 join

CT -> 제귀 호줄 -> split과 같은 기능으로 활용 가능

 

---------------

쿼리가 실행이 되다가 갑자기 느려짐 ->  duration 이 느려짐, 5분 간격 -> 주기적으로 튀는 현상

-> background에서 정기적으로 도는게 없는지 확인 

-> 외부이중화 솔루션이 원인(ms클러스터링말고 디스크 동기화, 복제가 돌았었음)

------------

대용량 테이블 인덱스 작업

-> default 제약 조건 확인 

----------

- sort작없을 temp DB에서 

-> 메모리에서 안하고 디스크에서하면 엄청 느려짐

-> 프로파일러 sort warning 이벤트 발생

-> 쿼리가 느려질수 밖에 없음

-> hash warning 

-> ...

sort warning 유발자

-> agent job 쿼리 문제? -> 알고보니 사용자 쿼리가 아니라 update statistics 쿼리가 원인

-> ms 버그

-> 일반적으로 크게 원인이 되지는 않음

-------------

sch-m,. sch-s  차단 

alter table 차단 -> 수정한 내용이 테이블과는 아무런 관계가 없음에도 차단됨

-> 

-------------

테이블 변수가 가지고 있는 문제

-> 행수 예측을 못함 -> 통계를 못함 

-> 런타임에 변수가 생성 -> 쿼리를 컴파일하는 단계에서는 없는 상태 

-> 예상행수에 0은 없음 -> 예상 행수는 1건

-> 테이블 변수를 다른 쿼리와 같이 쓸경우 주의 필요

TF2453 flag 이용 가능

 -> DBCC TRACEON(2453,-1)

 -> 쿼리 트레이스 힌트지원 안됨 -> 다소 risky

-> OPTION(RECOMPILE)  -> sql server 만병통치약

-> 부하 측면에서 보면 TF2453이 가벼울거라는 의견

KB2952444 문서 참조

----------

리소스에 대량의 대기 발생

-> tempdb에 병목 -> pagelatch_up -> 메모리 구조에 대한 대기

-> 동시에 대량의 처리가 일어나야 발생하는 흔치 않은 상황

-> sort warning 같은 종류의 이벤트가 발생시, 

tempdb에 새로운 페이지를 할당하는 작업을 하면서 발생 -> 시스템 성능 해악

------------

update 문에서 join걸 때

-> source table 쪽에 NOLOCK 사용시 문제 발생될 수 있음

-> KB2878968  패치 나왔지만 NOLOCK사용시 문제

------------

sp_reset_connection (connection Pooling)

-> 시스템 저장 프로시져

 -> .NET은 주로 하지만 java는 connection pooling 주로 안 함

-----------

가변 길이 +NULL 열로 INSERT 후 UPDATE 실험

-> split 유발

->  varchar 길이보다는 고정길이 char로 하는 것이 나음

--------------

원격 서버에서 네트워크를 거쳐오는 쿼리 시간이 네트워크 때문에 길어지는 현상 -> 결과 출력 생략하여 실제 수행 속도 확인

-> 쿼리 옵션 -> 표 ->  

-----------

실행계획 재사용 이슈 -> 불균등 분포 -> 잘되다 갑자기 느려짐

option(recompile)

---------------

힘수 내부 쿼리의 불균등 분포

-> 함수 안에 사용한 select 쿼리 

------------

실제 재사용 이슈, if ~ else

-> 프로시져 안에 if else 구분 사용

-> 특정 매계변수 넘길때만 지연 발생

-> option(recompile) 하면 줄어듬

-----------

option(recompile) 버그

-> 잘못된 바인딩

-> 최신 버전은 패치된 상태

https://support.microsoft.com/en-us/kb/2965069

--------------

Calender- loop join 방지

-> 테이블 조합 방법은 join만 있는게 아니라 union도 사용가능하다는 사실

-> calender 테이블 별도로 구성 -> rdb에서 테이블을 결합하는 방법 -> join / union 서로 대체 가능

-> union으로 별도 처리

-----------

merge 문 버그

-> 기능은 좋으나 버그가 많음

------------

조건문 구성시 -> if else

  -> update 친후 -> if @@row=0 면 insert /else....

 -> merge 문 사용하여 조건문 구성

---------

recursive CTE 성능 고려사항

CTE가 적합한 경우

-> 중복 부모가 아닌 경우

-> 위에서 아래로 내려오는 경우

-> 아래서 위로 한 번만 올라가는 경우

-> 조건자가 단순한 경우

-> 그렇지 않은 경우 

-> 행 수 예측 오류, spool 연산 고비용 등 이슈 검토 후 튜닝

-> 혹은 while + 쿼리 튜닝으로 대체 고려

----------

다중문 테이블 값 함수를 IN 서브쿼리에 사용 시 주의

select * from orders

where orderID IN (select value from dbo.uf_func());

-> 문제가 되면 join 구문으로 바꿀 필요 있음

-> IN에 있는 distinct와의 문제