Minimal logging changed map : 로그레코드를 기록하는 게 아니라, 로그에는 bulk insert만 있었어 라는 상황만 기록하고 실제 minimal logging map에다가 어떤게 변경되었는지 기록한다. Bulk log 방식에서 사용된다.
0번은 파일의 헤더가 위치
1번에 pfs라는 페이지가 위치 (페이지의 사용여부 얼마나 남아있는지)
그래서 64mb의 영역을 하나의 pfs가 담당함
그래서 그 이후에 pfs가 필요
Gam은 2번 페이지에 있다. 고정되어 있다. 4G의 영역에 대한 extent 영역을 traking함.
SGAM은 3번 페이지에 있다. Mixed 판단. 4G의 mixed extent에 대한 영역을 traking함.
저 페이지를 보고 싶다라고 하면
5는 dbid 1은 파일id 1은 페이지 id (DBID:FILEID:PAGE# = 5:1:1 이렇게 줘서 그 위치의 내용을 알 수 있다.)
Dbcc 페이지 명령어로 내용을 볼 수 있다.
Log_reuse_wait_desc
Active_transaction 이런걸 통해서 아직 트랜잭션 하나가 안 끝났어 이런걸 알 수 잇다.
Initial file이 600MB
Vlf
1~64mb : vlf 4개
64~1GB : vlf 8개
1GB이상 : 16개
저 vlf 사이즈를 지나치게 작게 주면….
미리 initial size를 크게 주고..
Simple -> full 로 바꿔도 트랜잭션로그 비워진다.
풀백업 안 받아주면 simple모드처럼 동작한다.
1건의 데이터를 조회하는 lookup 이 많다 보면 비클러스터형이 좋다.
인덱스 페이지 내에서 커버할 수 있는 내용이 다 있다고 하면 lookup이 필요 없다.
Covered index라고 해서 included user라고 하면
다른 값을 갖다가 leaf node 처리… 무슨말일까ㅋㅋ
클러스터인덱스가 있는 상태에서 nc를 만들면
마지막 leaf node에 rid값을 넣는게 아니라 클러스터 인덱스값을 넣게 된다.
Tempdb
처음에 서비스가 시작되면 초기화됨 (recovery 필요 없음)
트랜잭션을 유지하기 위해 사용된다
Bulk나 이런 작업에 대해서도 일반 유에 대해서는 주기적으로 dirtypage에 써지는데 dirtypage에 세션에서만 유지되는 건데 디스크에 쓸 필요가 없다.
체크포인트나 이런 부분이 일반 디비와 다르다.
Version store : 스냅샷 아이솔레이션을 쓰면 tempdb에 버전이 쭉 기록된다.
그래서 version store를 쓰면 tempdb가 커진다.
db파일을 동일한 size로 cpu개수만큼 하는데 8 이하.
Trace flag 1118 : 모든 DB에 적용되어 버린다.
무조건 나는 처음에 생성하더라도 uniform 을 쓰겠다. 라는 의미
Trace Flag 1117
어떤 파일이 하나 늘어날 때 다 늘어나게. 얘도 적용하면 모든 DB에 적용되어 버린다
MS2016에서는 TEMPDB에 대해서 1118,1117이 내재되어 있다.
6장 SQL SERVER TOOLS
Standard reports : reporting service는 http 통해서 보여주는 거고 standard reports 보기 위해 따로 설치할 필요 없다.
퍼포먼스 대시보드 : 2005 부터 사용가능
Activity monitor : 세션들의 상태 정보나 블락킹 걸렸을 때 끊어줄 수 있다든가 io 확인가능. 작업모니터. SSMS 통해서 볼 수 있음 -> DAC 접속해서도 볼 수 있는지? 안 됨.
MDW : codeplex가 ms에서 운영하는 거랭 오홍. 거기서 받을 수 있는듯
Sp_server_diagnostics : deadlock 유발한 쿼리, 실패한 쿼리 내역등 볼 수 있음
Extended events : 프로필러 대체할거라고 하는게 extended events였는데 프로필러가 안 없어지고 있다.
PSSDIAG : 프로필러 수집하는 역할
Standard reports
DMV를 실행하기 위한 권한 (view server state, view ? state 권한이 있어야 리포트를 볼 수 있다.)
로그인 통계 리포트 (로그인에서 우클릭)
Task 리포트 (mgmt에서 우클릭)
Performance dashboard
RDL파일. 사용자 지정 리포트.
다운받고 나서 TOOLS\Performance dashboard 에서 setup.sql 돌리면 저장 프로시저 만들어주는 거다.
그래서 그 RDL 을 실행시키면
가공된 상태의 성능데이터 볼 수 있다.
Activity monitor
인스턴스에서 우클릭 > 작업 모니터
DAC 접속해서는 볼 수 없다.
Dynamic Managemet Views
DMV 쿼리 헤헤
메모리 형태로 저장된 애를 볼 수 있다.
헤카튼에 대한 내용도 볼 수 있다.
Dmv 종류별로
sql 실행계획 확인 : exec_query_stats
exec_sql_text -> exec_query_stats 에서 확인된 핸들로 바인딩시켜주면 실행되고 있는 쿼리 확인 가능 (얘는 DMF라고 한다. 인자를 전달받아서 확인가능한 애를 DMF라고 한다.)
MDW
그래서 MDW 설정하고 나면 standard report 뿐만 아니라 MDW 리포트도 확인 가능
툴을 실제 도입하지 않고 중앙에서 관제해서 볼 수 있는 형태.
MDW의 경우… central 머시깽이?를 구성해서 db들을 모은 후 MDW 디비를 만들어서 하는 형태로 해야 한다.
운영장비가 아닌 개발장비에 구성해서 저장공간을 좀 잘 활용해야…
수집하는 데이터가 많고 보관기간이 길어서 디스크 사용량이 높다.
Sp_server_diagnostics
Isalive : 살아있냐 클러스터의 경우 60초마다 구동되서 살아있냐 체크
Looksalive : ?
시스템헬스 이벤트 : 사용자세션에서 데드락 유발, 실패 로그도 확인 가능.
이렇게 name column에서 deadlock으로 검색
Alwayson_health : alwayson을 시작하면 해당 확장이벤트도 자동으로 시작된다.
|
SQL Trace |
Extended Events |
|
Trace infrastructure |
Event infrastructure |
|
Column-based |
Not bound to columns |
|
Great impact on system performance |
Minimal impact on system performance |
|
Difficult to extended |
Easy to extended |
|
Well known and easy to use |
New and more complex feature |
|
UI |
UI – codeplex project (SQL Denali) |
확장이벤트 : 어떤 이벤트가 발생했을 때 수집해라.
쿼리의 성능수집을 하겟다라고 하면 RPC COMPLETED하고 STATEMENT COMPLETED 두 가지만 수집하면 쿼리에 대한 기본내용들은 수집해서 분석 가능하다.
필수적으로 저장해야 하는게 저 빨간색 네모 애들이당.
Predicate는 where절이에요. cpu사용률이 높을 때 등등
Ring_buffer는 고민해봐야 한다. 메모리 사용량이 높아져서…
보통은 안정하게 사용하기 위해서는 File형태로 저장.
System health 리포트에서 데드락 잡고 있기 때문에 따로 추가로 걸 필요 없다.
Performance monitor counter
Page life expectancy : 페이지가 메모리에 머무르는 시간
30% 이상이면 주의요망
Memory grant pending : 메모리가 부족할 수도 있고 나한테 할당해 준 게 조각화가 심해서 한번에 줄 수 없을 수도 있고.
Memory grant outstanding : 부하가 큰 쿼리로 인해 실행이 지연되는..? 모르겠다.
Batch request/sec : 일반적인 곳에서는 5천 별로 안 넘음. 10000을 넘으면 많이 사용하는 상태. Cpu가 높아서 봤더니 평상시에 5천이었는데 1만이 되었다라고 하면 실제 배치 리퀘스트가 많은 상태. 근데 평상시와 개수가 비슷하면 실제 문제가 있는 상황.
많이 수집하는 항목
LogicalDisk, Memory, Network Interface, Process, Processor,
SQLServer:
Access Methods(의미 없지만 일단 수집),
Buffer Manager
Databases
Deprecated status (없어질 기능을 호출하고 있는지)
Exec stastics
General stastics
Latchs
locks
Memory manager
Sql stastics
PAL (Performance Analysis Log)
차트 컨트롤+닷넷프레임워크 설치필요.
Pal은 별도로 설치할 필요는 없다. xml파일들은 특정 제품들을 기준으로 퍼포먼스 카운터에 대한 가이드라인 권장값들을 저장함.
파워쉘 방식으로 할거면 PAL.ps1
UI면 PALWizard.exe 띄우면 된다.
Counter Log
Sqlnexus
문제되는 시점에 pssdiag로 수집하고 그 결과를 sqlnexus에서 분석한다.
datacollectors 를 그대로 쓰긴 힘들고
pssdiag 서버에서 데이터 수집하고 데이터가 수집하면 sqlnexus로 분석.
별도로 설치하는 툴은 아님.
리포트뷰어 핫픽스 꼭 설치해야 링크들을 볼수가 있다.
데이터를 분석하고 싶으면 새로운 디비를 만들어야 한다.
그래서 운영서버에서 보는게 아니라 개발서버나 랩탑에서 분석해야 한다.
Missing index : 인덱스를 걸어주면 좋겠네… 이런거
Poorman sql formatter : sql 쿼리 이상하게 나올 때 formatter에서 보면 어떤 쿼린지 알기 편함. 보기좋게 쿼릴르 정렬시켜준다.
Notepad++ 플러그인형식으로도 import할수 있고 웹에서 할 수도 있고 그렇다.
ㅇㄴㄹ
7장 SQL SERVER TABLE AND INDEX STRUCTURE
클러스터 타입 인덱스 : 데이터 포함되어 있음.
가급적이면 변경이 되면 안 됨.
인덱스에 너무 많은 필드가 들어가면 안 됨.
자주 조회되는 목적.
데이터 조회를 목적으로 많이 사용됨.
비클러스터형 인덱스 : covering에 마니 쓰인다.
'Database > MS-SQL' 카테고리의 다른 글
| SQL 전문가과정 5일차 (0) | 2016.10.14 |
|---|---|
| SQL 전문가 과정 3일차 (0) | 2016.10.13 |
| 문제상황시 유용한 sql쿼리들 (0) | 2016.10.12 |
| 전문가 과정 2일차 (0) | 2016.10.11 |
| sqlserver stress test (0) | 2016.10.11 |