튜닝을위한 하드웨어지식 기초

-- * 시스템 튜닝에대한 쿼리문은 꼭 가지고 있을 것.............
go

-- * subquery 종류

--서브쿼리의 위치에 따른 명칭

    -- SELECT문에 있는 서브쿼리 : 스칼라 서브쿼리:1행만 반환

    -- FROM절에 있는 서브쿼리 : 인라인 뷰
 
    -- WHERE절에 있는 서브쿼리 : 서브쿼리

---

-- *인덱스된 뷰!!
-- 실제데이터가 존재하며, 그 데이터는 고유 클러스터형 인덱스에 의해서 정렬이 되어 있는 뷰입니다.
-- 뷰나 인덱스된 뷰는 join 구문 할 때 쓴다

-- 장점
-- 자주 사용되는 뷰의 경우, 아예 뷰에 실제 데이터가 존재하게 되면 
-- 뷰까지만 접근해도 결과를 얻을 수 있게되어서 쿼리의 성능이 향상 될 것입니다

-- 단점
-- 뷰를 만들 때 참조한 테이블이 변경 될때마다, SQL Server가 인덱싱된 뷰의 실제 데이터 부분도 같이 변경해야 합니다


-- 생성
CREATE VIEW 뷰이름 WITH SCHEMABINDING AS SELECT 구문
CREATE UNIQUE CLUSTERED INDEX 인덱스이름 ON 뷰_이름(뷰의 열_이름)
go

-- 예제
CREATE VIEW vProductSum WITH SCHEMABINDING AS

SELECT P.ProductID, COUNT_BIG(*) AS Count, P.Name, SUM(O.OrderQty) AS SumOerQty, SUM(O.LineTotal) AS SumLineTotal

FROM Production.Product P

INNER JOIN Sales.SalesOrderDetail O

        ON P.ProductID = O.ProductID

GROUP BY P.ProductID, P.Name;

GO


CREATE UNIQUE CLUSTERED INDEX vIdx_vProductSum ON vProductSum(ProductID);


-- 특징
-- 인덱싱된 뷰는 업데이트가 드물게 일어나는 테이블에 인덱싱된 뷰를 생성하는 것이 좋습니다.

-- 인덱싱된 뷰를 생성해 놓으면, 인덱싱된 뷰자체를 조회하는 것뿐 아니라, 일반 쿼리도 인덱싱된 뷰를 
-- 사용할 수 있는 경우에는 SQL Server는 알아서 인덱신된 뷰를 사용하는 효율적인 처리를 하는 것입니다.

 

---

 -- * 튜닝
-- 인덱스된 뷰를 사용
-- 튜닝할 때는 tempdb는 위치 공간을 바꾼다

-- 벌크 insert (대랑 데이터 삽입) -> 트리거, 커서 사용

-- 튜닝은 select query문을 주로 한다 

-- cpu를 운영체재로 씀 : 문제 발생시 원격 접속용으로 남겨놓는다 (I/O-입출력, 쿼리용)

-- NO LOCK : Cuncurrency and transctions - 동시성에대한 부분(대량의 insert 중 select을 할 때)

-- 동시성과 통계

-- 예상 실행계획에서 오차범위를 따짐

-- 트리거 : 배치작업

-- 커서 : 행을 열로, 열을 행으로 바꾸는것, 너무 느려서 임시테이블을 씀

-- CTE : mssql에서는 커서를 쓰게되면 매우 느려서 cte를 씀-> 엔진에서 돌리므로 커서보다 빠름

-- 모니터링, 트레이싱 baslining 
go

---

/*
11-16일

튜닝 1장

* Connection Protocols
Three network protocols are supported:

Shared memory : 로컬에서 붙음

Named Pipes : 특정한 이름의 Pipe 1개를 꽂고 주고받고 한개에서 이루어짐 : 데이터가 변동됨

TCP/IP : 내부 테트워크에 대한 방화벽, 윈도우즈 방화벽

Stream protocol : 응용프로그램에서만 쓸때 만. Stream=빨대. 빨대 2개로 받고 줌 : 데이터 변동 없음

TDS : Tabular Data Stream약자, .NET프로그램같은경우 씀....

---

엔진
* Database Engine


-- Query Execution(->컴파일: 문법검사) : 쿼리문을 던지면 sql이 윈도우즈 운영체제에 맞는 기계어로 바꿈


-- Storage Engine(빌드-> 설정값에 맞춰 실행준비) : 실제 mssql운영체제에 보내기 위해 기계어로 보내고 mssql설정에 맞춰 실행까지 해달라고 함
 쿼리 실행층에서 엔진이 실행에대한 계획대로 실행을 하려하는데 그 계획은 mssql설정값에 맞춰서 
 하려고 하는것. (잠금-> commit umcommit, 트렌젝션 등을 함)

-- SQLOS(실행) : 윈도우즈 운영체제와 연동이 되게하는 중계자 역할..(mssql문을 엔진에서 바꾼것을 윈도우즈와 정함)
운영체제에 있는 자원을 할당받고, 그것을 윈도우즈 운영체제에서 실행함(실제 실행)

---

* SQLOS

-- * 데드락 교착상태 :  응답없음 상태..

-- 자원에 대한 할당, 실행, 관리를 추상적으로한다 : 추상적인 이유는 윈도우즈 운영체제에 기대서 
하기 때문에 추상적으로 한다고 한다. (윈도우를 만나야 실체화 됨)

위의 내용을 윈도우즈 운영체제에 요청,계획을 세운다

---

* Multiple CPUs—SMP and NUMA

메모리는 짝수로 사서 꽂는다(듀얼 채널 개념)
2,4,6... 왜냐면 컴퓨터는 2의 n승으로 처리하기 때문에.


cpu는 쓰레드라는 단위로 일을 한다

윈도우즈 운영체제중 멀티 쓰레드 OS: 장점> 실시간처리 
A.exe 프로세스 안의 일을 실행하는 것 : 쓰레드 단위 , 동시에 몇개의 일을 처리하는가?>하이퍼 쓰레드



-> 실행  ->

^
|

준비 <- 대기


대기 : 실행 순서에 따라 대기
준비 : 처음실행하는지, 두번째의 여부에 따라 cpu메모리와 자원할당을 준비함
실행 : 한번에 쿼리 한줄만 실행
CPU : 메모리를 기록하는 란에서, 나가면서 몇번 cpu의 몇번 쓰레드의 얼마나를 썼는지 기록함

->

대기 : 순서대기
준비 : 메모리에서 기록을 빼내와 몇번 코어,쓰레드기록을 가져옴, 바쁘면 다른 빈 코어/쓰레드에 들어감
실행 : 쿼리 한줄만 실행
CPU : 

.....쿼리문이 끝날때 까지 계속 반복(쿼리문의 행을 줄이는것이 중요)

---

- cpu 클럭수
CPU의 속도를 나타내는 대표적인 단위는 클럭(clock)'입니다
클럭 펄스(clock pulse) 라고도 하는데요
이는 1초당 CPU 내부에서 몇 단계의 작업이 처리되는 지를 측정해
이를 주파수 단위인 'Hz(헤르츠)' 로 나타낸 것 입니다

---

- 캐시 메모리(Cache Memory)
캐시 메모리란 비단 cpu에만 적용 되는 것이 아니고 속도가 빠른 장치와 느린 장치 사이에서
속도차에 따른 병목 현상을 줄이기 위한 범용 메모리입니다
L1(Level 1 cache memory), L2(Level 2 cache memory), L3(Lev3el  cache memory) 캐시 메모리로 나뉘는데요
이 캐시 메모리의 용량이 작으면 CPU에 비해 동작 속도가 훨씬 느린 주 기억장치(RAM, 메모리)나
보조 기억 장치(하드디스크, CD-ROM 등)로부터 직접 데이터를 불러들이는 빈도가 높아지는데
이런 경우 컴퓨터의 전반적인 처리 속도가 크게 저하됩니다
L1 캐시는 일반적으로 CPU 칩안에 내장되어, 데이터 참조에 가장 먼저 사용됩니다
CPU가 가장 빠르게 접근할 수 있으며, 여기서 데이터를 찾지 못하면, 이제 L2 캐시 메모리로 넘어가게 됩니다

L2 캐시 메모리는 용도와 역할은 L1 캐시와 비슷하지만, 속도는 그 보다 느립니다
L3 캐시 메모리도 동일한 원리이지만 요즘 웬만한 프로세서에서는 L3 캐시 메모리는 달고 있지 않습니다
L2 캐시로 대체할 수 있기 때문입니다

캐쉬메모리는 비싼 CPU에 들어있고 더 빠르다........(저장프로시져)

---

-- NUMA : 하드웨어 단위를 DOCKER의 컨테이너처럼 격리화 시킴
NUMA가 자원을 분리시켜놓음, 분리시켜놓은곳에서 자원들이 활용됨
(오류가 나도 그쪽만 문제가 발생함)



mssql은 셀프튜닝하며 자원을 스스로 운영함
mssql의 자원을 적절히 해서 특정 하드웨어의 운영을 적절히 하기위해... mssql의 성능을 제한한다.....





입출력장치 연산/처리를 할 때 요즘엔 CPU까지 안가고 GPU가 껴들어 CPU의 부화를 줄인다


메모리와 CPU 공부!!!!!!!!
메모리에 적재되서 CPU에 올라간다

---

트랜젝션 단위로 Query가 실행된다


tempdb는 트랜잭션 로그가 끝나면 끝났다고 알려주고 일이 시작되도 끝났다고 알려줌
비긴, 커밋은 명시적으로 비긴~커밋까지 날려 라고 말하는 것
실행하는 로그파일을 저장하기 전에 쿼리가 있는곳이 tempDB이다.

조인구문을 할 때 drivetable은 처음 연결하는 테이블을 tempdb에 저장하고 이것을 드라이브 테이블이라고 한다

임시적으로 쿼리문을 가지고 있는곳이 tempdb라고 한다.

쿼리문을 임시로 가지고 있다가 트랜잭션이 끝나면 지우려고 한다

로그파일도 계속 저장하려 하기 떄문에 관리안하면 기하급수적으로 늘어나므로 
정기적으로 백업, 공간추가를 해줘야한다.

tempdb는 사용자의 요청을 저장함, join등을 사용할때 임시로 가져오는 데이터를 다 저장하고있으므로 공간을 많이씀

데이터를 임시로 설정하기때문에 하드디스트도 별도로 두면좋다
SSD를 데이터베이스, 로그, tempDB 등 따로 운영공간을 잡아준다

---

-- * 레이드 : 숫자가 올라갈수록 속도가 느려짐
RAID는 여러개의 디스크를 묶어 하나의 디스크 처럼 사용하는 기술 입니다.


RAID 0 : 속도 제일 빠르나, 하드디스크 여러가지 묶었을 때 하나의 디스크만 뻑나면 모두 날아감
-> 주로 tempDB로

RAID 1 : 똑같은 하드디스크를 두고 1번을 2번에 복제하며 1번에 문제가 생기면 2번이 이어서 함.
-> 주로 C드라이브 용도로 씀.(운영체제)

>> 2,3,4는 건너뜀

RAID 5 : 최소 하드디스크 3개이상(물리적으로 4개), 하드디스크를 추가하여 오류받는 곳을 하나 더 만들어놓은것.
RAID 6 : 오류 체크하는 녀석을 복제해놨다가 이어받아서 함
-> RAID 5, RAID 6 은 log파일


RAID를 사용하였을 때 기대 효과는
 - 대용량의 단일 볼륨을 사용하는 효과
 - 디스크 I/O 병렬화로 인한 성능 향상 (RAID 0, RAID 5, RAID 6 등)
 - 데이터 복제로 인한 안정성 향상 (RAID 1 등)
이 있습니다.

RAID는 컴퓨터를 구성하는 여러 부품 (구성품) 중 기계적인 특성 때문에
상대적으로 속도가 (많이) 느린 하드디스크를 보완하기 위해 만든 기술입니다.


RAID를 구성하는 디스크의 개수가 같아도, RAID의 구성 방식에 따라 성능, 용량이 바뀌게 됩니다.

harryp.tistory.com/806

 

[스토리지] RAID 정리 1. RAID 기본 설명 및 RAID Level (레이드 레벨)

 

 

 

 

---

 

-- * 복구와 복원
복구 : 데이터베이스는 특정한 시점까지 복구를 해주는 경우가 많다
복원 : 마지막 순간까지 ..

log파일이 있다면 마지막 주기까지 복원 가능하므로 트랜젝션에서는 매우 중요히 여긴다

따라서 레이드 컨트롤러로 이런것들을 계산하여 log파일 저장공간을 확보 한 후 시작한다.




-- IO 밴드위스........공부!!!!!!!!!!!!!!
-- 레이드컨트롤러 싼거/비싼거 확인...........!!!!!!!



L1, L2, L3 캐시
L1, L2 는 용량이 작아 L3캐시를 추가하는데 없다면 속도가 느리다고 보면 된다

직렬, 병렬 CPU
직렬 CPU는 처리가 빠름...
따라서 병렬식인 인텔(제온)은 UNIX가 부러워 내놓은 CPU가 따로 있음....

---

-- * 컴퓨터 구조지식(RISC vs CISC )

CISC
  -  연산에 처리된느 복잡한 명령어들을 수백 개 이상 탑재하고 있는 프로세서
  -  마이크로 프로그래밍을 통해 사용자가 작성한 고급 언어에 각가 하나식 기계어를 대응시킨 
회로로 구성된 중앙처리장치의 한 종류
  -  컴퓨터가 지원하는 명령어가 많을수록 프로그램 내의 Instruction count는 줄어듬
  -  명령어 길이가 상이함

 

RISC
  -  복잡한 80%의 명령어를 제거, 사용빈도가 높은 명령어 위주로 20%명령어를 H/W화해 처리속도
향상시킨 프로세서
  -  복잡한 처리는 소프트웨어에 맡기는 방법을 채택해, 명령세트를 축소 설계한 컴퓨터
  -  모든 명령어의 길이를 일정하게 만듬
  -  하나의 Cycle에 여러 명령어 수행/Hardwired control

---

메모리 

DDR3, DDR4(보편화)
RMRD메모리(짝수로밖에 못꽂음)

 

 

kr.transcend-info.com/Support/FAQ-296

SDRAM, DDR1, DDR2, DDR3 그리고 DDR4 사이의 차이점은 무엇인가요? - 제품 지원

 

 

 

 

 

데이터베이스는 가상화를 안둠. (클라우드 가능)

 
라이브마이그레이션이란 다른 하드웨어로 가상정보가 이동하는것. 이때 트렌젝션이 올라감. 
따라서 메모리를 가상/ 공유/ 다른 하드디스크로 옮기는데 계속처리가 발생하면 물려서 못넘어감
따라서 가상으로 만들어 쓰기도 함.....

---

하드웨어 성능 올리는 법...
1. SSD 바꿈
2. 입출력장치 바꿈
3. 노가다

튜닝
1. 레이드 컨트롤러 이해
2. 



-- 하이버네이트란
Object Relation Mapping(ORM - 객체 관계 매핑) Framework 중 하나.

sarc.io/index.php/development/1132-hibernate

Hibernate(하이버네이트) 란?

 

 

 

---

 

 

-- 셀프튜닝 설정시 참고하면 좋을것.....
셀프튜닝 후 운용한 결과를 지켜봄....6개월간
입출력이 많으면 CPU사용개수를 입출력에 주면됨

---

-- * baseline ...!????

시스템의 생명주기의 일정 시점마다 그간의 제품상태(산출물)를 검토하고, 그 결과를 반영하여 
다음 개발단계로 이전하는 방법을 사용한다. 이러한 시점이 곧 베이스라인(Baseline)이다

gmood.tistory.com/428

형상관리 ⑤ - 형상관리 베이스라인(Baseline)의 개념

 

 

 

Context Switch (컨텍스트 스위치)

---

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


* The Query Life Cycle
물리적인 저장소에서 

SQL Server 컴파일 되면 사용됨 -> 
CPU 처리
메모리 임시저장소
하드디스크 영구저장소

따라서, 데이터 베이스는 입출력에대한 부하가 심할 수 있다

---

* Monitoring Engine Behavior


데이터는 500에서 700기가정도 차면 물리적으로 나눈다
-> 논리적으로 파일 그룹과 파일로 나눠서 저장한다
-> A~ D까지는 primary 그룹에 , 나머지는 second그룹에 저장?
-> 데이터를 분산시키는 이유 : 한곳에 집중적으로 저장하면 성능이 떨어짐
-> 분산의 단점 : 쿼리문이 바뀌게 되고, 번거로워짐...

---

* Performance and Scalability in a SQL Server Instance on an Azure Virtual Machine
가상머신 : azure
라이브 마이크레이션
OLTP는 
데이터웨어하우스 BI같은경우에는 

---

*  Windows Scheduling vs. SQL Server Scheduling
스케줄링을 하는 이유

스케줄링을 하며 6개월(선택)에 한번씩 
하드디스크 공간을 늘릴 지에대한 계획을 함 : 비율%, 용량% 방법으로 




종류
- 윈도우즈 : 
- sql스케줄링 : 윈도우즈와 같이돌아감



자원을 작업의 용도로 쓸 수 있도록 한다

 

 

 

 

 

 

---

 

 

** MS도움말 보는법 익히기, 쿼리문 가져다 실행해보기 -> 작업모니터 키기

docs.microsoft.com/ko-kr/sql/relational-databases/system-dynamic-management-views/sys-dm-os-wait-stats-transact-sql?view=sql-server-ver15

 

 

 

** 리소스모니터 보는법 익히기
-> 작업관리자와 같이 보기

 

 

---

 

 

 

 

** 마이크로소프트의 권장 
* CPU 수(Core)
64비트

CPU(2의n승) 쓰레드
4 512
8 576
16 704
32 960
64 1472
128 2496
256 4544
--------------------------

* 메모리
OS : 1 ~ 2G에서 4G 메모리를 둠

메모리 계산
1,024 * 메모리(os사용량 빼고)
->예를 들면 16G이면 os사용량 2G빼고 최대서버메모리는 1024*14=14336이 됨

 

 

---

 

 

데이터베이스 설정 : 

최대 병렬처리 CPU 수 설정 -> 선택한CPU수만큼
병렬로 밸런스를 적절하게 맞춘다

 

---

 

 

-- * tempdb 같은 경우에오 CPU코어당 TempDB 에 데이터파일을 생성하고
최대 8개까지만 생성하는것이 기본 튜닝이라고 본다.

---

 

 

 

시스템 관련(데이터베이스 속성 : CPU수, 메모리크기, 원격서버 연결 허용) 채우기비율, 통계에대한 값들
시스템 DM명령어 확인 후 몇개의 코어사용할지 확인.

 

 

---

SSD와 HDD의 속도 차이는 SELECT의 읽기에서는 많이 나지 않는다
INSERT등 쓰기를 할 때 tempdb와 통계의 영향때문에 느려진다

SSD가 더 빠르다.
서버에서 RAID CONTROL하게되면 더 빠르다.

가상화 하드디스크를 만들면 더 느려진다. 왜냐면 가상화된 하드를 타고 들어가기 때문이다.

 

 

---

 

* 저장소에서 꼭 확인해야 할 것
I/O장치의 대역폭RAID, SSD나 HDD장치의 대역폭(SSD), 
RAM카드 장치의 대역폭, 네트워크에 대한 대역폭(네트워크속도)

저장프로시저는 하드디스크 안씀

 

 

---

SSD와 HDD의 속도 차이는 SELECT의 읽기에서는 많이 나지 않는다
INSERT등 쓰기를 할 때 tempdb와 통계의 영향때문에 느려진다

SSD가 더 빠르다.
서버에서 RAID CONTROL하게되면 더 빠르다.

가상화 하드디스크를 만들면 더 느려진다. 왜냐면 가상화된 하드를 타고 들어가기 때문이다.

 

---

 

- 사용량과 시간에따른 사용량 파악하기
아침에만 많이쓰고 그 후에 안쓴다면 아침에만 잠깐 저장프로시져를 쓰면 됨
입출력장치가 얼마나 맣이일어나는지, 바이트단위가 어떻게 된느건지, 폭주할때 감당 할 수 있는건지를
따져야 함.
따진 후, 좋고/나쁘고를 판단하고 하드웨어가 감당할 수 있을지 판단.
감당 할 수 없으면 하드웨어 업그레이드가 필요...
이런것을 따지려면 6개월정도 지속적으로 보며 사용자들의 기간별(시간별)사용량 패턴을 파악한다.
입출력 장치가 감당 할 수 있는 처리량 파악 필수, 지속적 모니터링 함.
(DB는 설치하고 사용하는것 만으로 끝이아니다)

시스템 디스크 큐, 큐적채.................공부!!!!

초당 읽기, 초당 쓰기를 측정. 

쿼리실행 -> tempdb -> 실제 저장 : 데이터디스크 -> 로그디스크 저장 (적채현상이 많이 일어나, 별도로 트랜잭션로그를 줌)

 

---

 

SSD 메모리 타입(방식)
SLC : 수명이 길고 빠른데 비쌈, 수명 5년
MLC서버 : SLC보다는 덜함, TLC의 2배가격이다.
TCL서버 : 3개로 저장함 ,수명3년
QLC서버 : 4개로 저장함, 용량크고 저렴 -> 데이터 저장소에 많이 씀

 

 

---

 

-- * database 파일

 

엔진이 컨트롤 하는 것이 있고, 인스턴스별로 서비스 한다.
보통 설치를 할 때 한개의 database서버에 한개의 인스턴스만 설치 한다. (여러개 둘 수는 있음)
인스턴스 위에 data를 저장하는 공간을 둠. 해당 위치에 한개이상의 파일이 있음 
(-> 파일로 그룹핑을 하여 관리함)
스키마 라는 그룹핑을 둠-> 데이터 테이블을 스키마와 연결(스키마에 맞춰 파일 그룹을 나눔)

 

유형:

데이터베이스 파일파일Description

주	데이터베이스의 시작 정보를 포함하며 데이터베이스의 나머지 파일을 가리킵니다. 모든 데이터베이스에는 하나의 주 데이터 파일이 있습니다. 권장되는 주 데이터 파일 확장명은 .mdf입니다.
보조	선택적 사용자 정의 데이터 파일입니다. 각 파일을 서로 다른 디스크 드라이브에 배치하여 데이터를 여러 디스크에 분산시킬 수 있습니다. 권장되는 보조 데이터 파일 확장명은 .ndf입니다.
트랜잭션 로그	이 로그에는 데이터베이스 복구에 사용되는 정보가 저장됩니다. 데이터베이스마다 최소한 하나의 로그 파일이 있어야 합니다. 권장되는 트랜잭션 로그 파일 확장명은 .ldf입니다.

 

 

-- 파일의 구조
B-tree 형식으로 가져감(2진트리 형식)

파일 밑에 dbo라는 스키마를 두고 그아래 테이블, 그아래 데이터를 둔다.
-> page를 최대 8KB인 곳에 저장함.

 

 

데이터베이스 속성의 복구모델에서
단순 : 풀 백업밖에 할 수 없음. -> 전체백업하고 변경된것은 백업 불가능하다.
(10G면 10G만 계속 백업하게됨,-> 용량이 계속 찰 수 있으므로 조심스럽게 써야함)\
(트랜젝션 로그의 부분을 풀 백업)
전체 :  풀이아닌 변경 된 것도 할 수 있음.
대량로그 :  오로지 insert만 백업한다.-> 읽기전용, 오로지 데이터만 넣겠다 할 때사용.
(별로 좋지 않음.)

 

 

블랍스토리지 blob storage :대용량의 데이터를 저장

 

데이터베이스 속성 -> 파일의 최대크기 설정 
-> 몇명이 사용하고 얼마만큼 사용할지를 파악하여 설정하여 사용한다.

 

 

 

파일 관련 DBCC명령어~

exec sp_helpfile ERPDB
-- Name 을 지정 하지 않으면 현재 데이터베이스에 있는 모든 파일의 특성이 반환 됩니다.
exec sp_helpfilegroup SE2


select * from sys.database_files
select * from sys.filegroups
select * from sys.master_files
select * from sys.dm_db_file_space_usage

 

 

---

-- * Shrink (청소)

DB를 관리하다 보면 로그 파일이 불필요하게 늘어나거나 디스크의 용량이 부족하여 공간을 
확보해야 할 필요가 있다. 이럴때 사용 가능한 것이 Shrink이다. (방 청소), 속성에서 설정된 
로그파일의 MB보다 적게 축소 할 수 없다. (쉬링크 = 도구상자의 : 데이터베이스 축소)

1. DBCC SHRINKDATABASE : 현재 데이터베이스에 소속된 모든 데이터 파일과 로그  파일에 적용된다.
2. DBCC SHRINKFILE : 특정 파일만을 축소 시키는 것

 

 

--쉬링크를 하면서 디스크가 조각이 난다.
- 디스크 조각모음 : 빵꾸난 메모리를 없애고 데이터들을 비슷한 연관된것들끼리 묶어내는것.
-> 조각모음을 많이하면 성능이 느려짐
-> 조각모음을하면 서버가 꺼져있어야 함

 

- 자동축소
인덱스가 조각화가 되어버려 성능에 영향을 준다

 

---

 

 

--  * 트랜잭션 로그백업은 

 

트랜잭션 로그백업은 
데이터베이스 옵션이 '전체'일경우 가능하다
트랜잭션 로그백업의 확장자는 trn이다.
트랜잭션 로그백업음 별도로 해야한다.
백업을 하고 파일의 크기를 보면 bak보다 훨씬 용량이 적게 들어있는것을 볼 수 있다.
전체 백업을 한 후 '트랜잭션 로그백업'을 해야 된다.

 

 

---

 

TEMPDB

 

 

tempDB 시스템 데이터베이스는 SQL Server 인스턴스에 연결된 모든 사용자가 사용할 수 있는 전역 리소스 이고, 사용자 개체, 내부 개체, 버전 저장소를 저장하는 데 사용한다.

사용자 개체(User Objects)

사용자 개체는 사용자에 의해 명시적으로 생성되는 것을 말한다. 이러한 개체들은 사용자의 세션 범위나 
해당 개체를 만든 루틴 범위에서만 존재한다. 사용자 개체는 아래의 나열된 것에 하나일수 있다.

l  사용자 정의 테이블 및 인덱스
l  시스템 테이블 및 인덱스
l  전역 임시 테이블(##<table>) 및 인덱스
l  로컬 임시 테이블(#<table)) 및 인덱스
l  테이블 변수(create table @<table>)
l  테이블 값 함수에서 반환된 테이블

 

내부 개체(Internal Objects)

내부 개체는 SQL Server 엔진에서 T-SQL문을 처리 하기 위해 필요에 따라 자동적으로 생성 및 삭제가 되며,
sys.all_objects와 같은 view에서 확인이 되지 않는다. 내부 개체는 아래의 나열된 것에 하나일수 있다.

l  Sort 중에 발생하는 중간 결과 값
l  Hash join, hash aggregate 과정에서 발생하는 중간 결과 값
l  XML, LOB(text, image, varchar(MAX)등) 변수 저장
l  중간 결과 값을 저장하기 위해 Spool이 필요한 query
l  Keys을 저장하기 위한 keyset cursor
l  Query 결과를 저장하기 위한 static cursor
l  인덱스 생성 또는 다시 작성시 SORT_IN_TEMPDB가 지정된 경우
l  Group by, order by ,union



버전 저장소(Version Store)

버전 저장소는 행 버전 관리를 사용하는 기능을 지원하는 데 필요한 데이터 행을 보관하는 데이터 페이지 모음이다. SQL Server 2005에는 일반 저장소와
온라인 인덱스 작성 버전 저장소가 있습니다.
l  행 버전 관리 격리 수준을 사용하여 커밋된 읽기 또는 스냅숏을 사용하는 데이터베이스의 데이터 수정 트랜잭션에서 생성된 행 버전
l  온라인 인덱스 작업, MARS(Multiple Active Result Sets) 및 AFTER 트리거 같은 기능에 대한 데이터 수정 트랜잭션으로 생성된 행 버전

- 내부개체는 8페이지 까지만 저장하나, 익스텐트하면 9페이지까지 저장가능

 

-- *Tempdb : JOIN에서 사용함
->설정을 제대로 안하면 sql 성능이 안나옴:너무 큰용량으로 하면 안되고 적절히 조절필요,모니터링필요
->Hash 값에 대한 작업파일
->Hash 집계 작업파일
->Index 재작성, Rebuild ( Group BY / Order BY / UNION 등의 중간결과 저장)
->행과 열을 처리하는 부분에서 임시로 저장한다(커서)
->8MB(시작값) ~ 64MB 범위로 자동증가: 설정이 없으면 디스크 꽉 찰 때 까지)

- DTU 기반 서비스: 성능에 맞춰 TempDB를 맞춘다

- Tempdb는 CORE1개당 파일1개 매칭하는 것(최대 8개)이 원칙이나, 버전이 올라가면서 달라짐
-> CPU가 12개 이상일경우 (고 성능일 때) 파일은 12개까지, Temp 32G

기본 14G 이상, 최대 : 32/64/96/167/192/320/384G (짝수 )

 

 

 

-- * TempDB의 성능 최적화

1. TempDB 설정이 잘못된 경우(위의 용량대로 하지 않을경우)
용량이 작을때 : sql재시작을 할 경우 시스템의 처리 부분에서 부하가 작동한다.
시스템 처리를 위해서 SQL이 내부 처리를 할 때 TempDB를 사용하기 때문이다.
->masterDB에서 Select해서 가져오기 때문임

2. TempDB 사용할 때 성능향상의 주요사항
임시태이블을 만들 경우 : 해당되는 테이블 변수를 만든다->캐시사용
TempDB의 로그파일, 데이터파일

SSD의 임시테이블이나 변수를 두는경우 TempDB를 씀

3. TempDB는 성능을 위해 CORE(논리프로세스)에 맞추어 파일을 생성한다 :
-> 병렬처리

 

 

 

 

---

 

 

메모리DB

 

요청을 응답 할 때 
(수시로 요청 응답은 메모리DB와 맞지 않음, 비 정기적으로 요청할때가 최적)

 

SQL메모리 확인

SELECT value,  minimum, maximum  
FROM sys.configurations   
WHERE name in ('min server memory (MB)','max server memory (MB)')

value 는 설정되어 있는 min server memory/max server memory 의 값이며,

minimum/maximum 은 해당 메모리를 설정할 수 있는 최소값/최대값이다.

* max server memory 은 최소 128 (MB) 이상이여야 한다.