찐빵의 IT World

SQL Server Management Studio 의 상단 메뉴

도구 > 옵션 > 텍스트 편집기 > 모든 언어 > 일반

에서 [표시] 부분의 줄번호 체크 해 주시면 됩니다.

그런데 줄번호 표시하면  텍스트 표시영역을 줄이게 되므로,

줄번호가 표시 안되더라도 [Ctrl] + G 키 누르시면 특정 줄번호로 빠르게 이동하실 수 있습니다.

[Ctrl] + G 키로 줄번호 이동은 대부분의 텍스트 편집기에서 표준으로 제공하는 기능입니다.

SQL 서버를 처음 설치하면 시스템이 동작하기 위한 데이터 베이스

- Master 데이터베이스

SQL 서버의 주요한 메타 데이터들이 있다.

SQL Server 인스턴스에 있는 모든 데이터베이스들에 대한 정보와 각 데이터베이스의 파일 정보, 서버 구성 옵션, 계정 등과 같은 중요한 정보들이 저장된다. SQL Server 초기화 정보도 Master에 관리되어 master 데이터베이스를 사용 못하면 SQL Server 서비스 시작을 못한다.

Master 데이터베이스는 SQL Server 2000 시스템의 모든 시스템 수준 정보를 기록합니다. 모든 로그인 계정과 모든 시스템 구성 설정을 기록합니다. 모든 데이터베이스의 존재 유무를 기록하며, 초기화 정보를 기록합니다.
주기적으로 백업되고 잘 관리되어야만 한다.

- MODEL 데이터베이스

새로운 데이터베이스를 생성할 때 이 데이터베이스를 참고하여 만든다.

새로운 데이터베이스를 생성할 때 특별한 지정이 없으면 이 Model 데이터베이스를 베낀다.

Model 데이터베이스를 수정하여 생성할 때 옵션을 변경시킬 수 있다.

- MSDB 데이터베이스

SQL Server 에이전트 서비스가 사용하는 작업 일정 정보, 백업 및 복원 기록 정보, 경고, SSIS 패키지, 복제정보가 저장.

변경사항이 없다면 백업할 필요가 없다.

- TEMPDB 데이터베이스

임시로 사용하는 데이터베이스

시스템이 재 시작할 때 초기화되어 새로 생성된다. 그러므로 이 데이터베이스의 백업은 불필요.

EX) 인덱스나 그룹핑 쿼리 등을 수행할 때 특정 데이터를 정렬한 후 이용해야 한다면, 이러한 작업들은 실제 사용자 데이터베이스에서 이루어지지 않고, Tempdb 데이터베이스에서 1차 작업 후 옮겨지게 된다.

1. 인덱스 (INDEX)

인덱스의 장점 : 검색 속도가 빠르다.

인덱스의 단점

데이터에 대한 추가/수정/삭제에 대한 연산 속도는 약간 느려진다.

데이터와 별도의 장소에 저장되어서 공간이 조금 더 필요하다. (데이터 저장 크기의 5~20%)

관리자의 수고

인덱스를 이용하게 되는 쿼리

- WHERE 절에서 인덱스 된 컬럼으로 검색할 때

- 조인 질의(Join Query)시 인덱스 된 컬럼으로 검색할 때

- Order By 절에서 인덱스 된 컬럼으로 정렬할 때

- Group By 절에서 인덱스 된 컬럼으로 집합 연산할 때

인덱스를 설정해주면 좋은 컬럼의 예 : 자주 사용되는 컬럼(검색 조건이나 정렬 조건으로 자주 이용되는 컬럼)

- 프라이머리 키(Primary Key) 컬럼

- 참조 키(Foreign Key) 컬럼

- 조인 질의(Join Query)에서 사용되는 컬럼

- 정렬 순서로 자주 사용되는 컬럼

- 자주 범위로 검색되는 컬럼

페이지 분할

데이터에 행을 힙(heap)에 삽입할 때에는 PFS 페이지의 정보를 이용해서 빈 페이지를 찾으므로 페이지 분할이 발생하지 않는다

페이지 분할

- 키 순으로 데이터를 정렬해야 하는 클러스터 인덱스에 행을 삽입할 때 페이지 분할이 발생할 가능성이 있다.

- 페이지 분할이 발생할 때 페이지의 절반은 비어있는 새 페이지로 이동된다. 이 때, 같은 익스텐트에서 새 페이지를 먼저 찾고, 없을 경우 새로운 익스텐트를 할당 받는다(GAM, SGAM 을 이용)

- 일단 페이지가 분할되면 롤백을 하더라도 분할 상태가 그대로 유지된다.

1. 자동 증가(Auto Growth) - 성능 하락

데이터베이스의 파일(데이터 및 로그 파일) 단위로 설정되는 옵션, 모든 Edition에서 기본적으로 설정된다.

이 옵션은 성능에 나쁜 영향을 미친다. 이유 : 파일이 증가할 때 증가되는 부분을 모두 0으로 채우는 초기화 작업(zero-out)을 거치므로. 게다가 간헐적으로 증가하다 보면 연속적인 공간사용을 못하게 되어 여기저기 조각이 나게 된다. 따라서 순차적 읽기 대신 랜덤 액세스를 하게 되어 성능이 저하.

EX) 아무 옵션 없이 데이터베이스를 생성하면 1MB로 시작해서 10%씩 자동 증가되도록 설정

SOL) FILEGROWTH 옵션을 0 으로 지정하여 자동증가 해제, DBA가 부하가 덜 한 시간에 ALTER DATABASE 문을 사용하여 파일 크기를 키우던가 파일을 추가해 준다.

저의 회사에서는 사용 & Fixed 용량으로 자동증가를 시켜 놓았다. (% 증가보다 Fixed 증가가 더 좋기 때문)

2. 자동 축소(Auto Shrink) - 성능 하락

데이터베이스의 autoshrink 옵션을 TRUE로 설정하면 주기적으로 데이터베이스 파일의 축소가 발생. SQL Server의 Personal 및 Desktop 판에서 이 옵션이 기본적으로 설정.

* 자동 축소 될 때 DB 잠금이 발생. 데이터 이동에 따른 디스크 I/O 가 발생하여 성능 저하.

3. 자동 닫기(Auto Close) - 성능 하락

- SQL Server의 Personal 및 Desktop 판에서 이 옵션은 기본적으로 설정된다.

- 데이터베이스의 Autoclose 옵션을 TRUE로 설정하면 이 데이터베이스에 대한 마지막 사용자가 연결을 끊을 때 데이터베이스를 메모리에서 내리고, 사용자가 다시 접속할 때 데이터베이스를 메모리로 다시 올린다.

메모리에서 내릴 때에 디스크와 동기화 안된 페이지(Dirty Page)를 기록 하느라 디스크 I/O 발생.

메모리에서 올릴 때에 디스크에서 메모리로 올리면서 디스크 I/O 발생.

4. 통계 자동 생성 및 갱신 - 성능 증가

Auto create statistics

Auto update statistics 옵션으로 설정한다.

1. 시스템 구조

SQL 서버의 시스템 아키텍쳐

1. 논리적 데이터베이스

데이터베이스의 테이블, 뷰, 저장 프로시저 등

2. 물리적인 데이터베이스

데이터베이스의 파일

1. 주 데이터 파일 (Primary Data Files, MDF)

기본적인 데이터 구조 및 데이터 들이 저장

2. 보조 데이터 파일 (Secondary Data Files, NDF)

여러개의 디바이스 파일을 운영할 때 보조 데이터 파일

목적 : 데이터 I/O를 병렬적으로 수행하여 I/O 병목현상 줄이고, 수행 속도 증가

3. 로그 파일 (Log Files, LDF)

데이터베이스를 복구하는데 필요한 정보를 저장

각데이터베이스마다 반드시 있어야 한다.

TIP : 주 데이터 파일의 경로 알아내기

(Master 데이터베이스의 Sysdatabases 검색)

Select * from SYS.DATABASES WHERE name='데이터베이스이름'

파일을 백업 복사하여 다시 첨부 하는 것만으로 그 당시까지의 데이터와 로그를 다시 불러올 수 있다.

이러한 작업에 사용되는 프로시저 = sp_attach_db , sp_attach_single_file_db

2. 데이터 파일 구조

1. 페이지(Page)

데이터를 저장하고 처리하는데 사용되는 가장 기본적인 입출력 단위

페이지 헤더(96바이트)(페이지의 종류, 페이지의 여유공간정보, 페이지가 저장하는 데이터의 오브젝트ID) + 8096바이트 로 구성

- 데이터 파일 앞부분의 특수 페이지들

파일헤더 | PFS | GAM | SGAM | BCM | DCM | ...

* PFS (Page Free Space) - http://blog.naver.com/jumdol625/110169523098

- 페이지의 할당 여부 및 각 페이지에 있는 빈 공간의 크기를 기록하는 페이지

- 각 페이지에 1바이트를 사용하여 페이지의 할당 여부와, 페이지의 남은 공간을 기록

- 힙, 텍스트, 이미지 페이지에 대해서만 페이지 내의 빈 공간의 양이 관리 

- 새로 삽입된 행을 보관할 수 있는 빈 공간이 있는 페이지를 찾아야 할때 사용 

- GAM, SGAM, PFS를 이용해서 사용할 페이지 검색 

- 인덱스의 경우에는 새 행을 삽입할 지점이 인덱스 키 값에 의해 설정되므로 페이지의 빈 공간을 추적할 필요가 없음 

- 8088개의 페이지 관리, 8088개가 넘어가면 PFS페이지를 추가

* GAM (전역 할당 맵) : 어떤 익스텐트가 할당 되었는가

* SGAM (공유 전역 할당 맵) : 어떤 익스텐트가 혼합익스텐트인지, 빈페이지가 있는지, 4GB 관리.

http://blog.naver.com/jumdol625/110168581449 - GAM, SGAM 자세히 나와있는 곳

* BCM (Bulked Change Map)(대량 복사 변경 맵) : Backup Log 문 이후 대량 기록작업에 의해 수정된 익스텐트를 관리

* DCM (Differential Change Map)(차등 변경 맵) : 마지막 BACKUP DATABASE 문(FULL BACKUP) 이후에 변경된 익스텐트를 관리하는 페이지, 차등 백업의 대상 익스텐트를 찾기 위해 사용. 4GB 관리.

2. 익스텐트(Extent) : 8개의 연속된 페이지가 모여 이룬 단위

1. 혼합 익스텐트

8개의 페이지에 각각 다른 오브젝트의 데이터를 저장할 수 있다.

2. 단일 익스텐트

8개의 페이지에 모두 같은 오브젝트를 저장할 수 있다.

테이블이나 인덱스가

8 Page보다 커지기 전까지는 Mixed로 저장된다.(다른 개체에서도 추가되는 작업이 있다면 위의 그럼처럼 떨어져서....)

8 Page보다 커지는 순간

9번째 Page가 저장될때는 Uniform으로 8 Page의 공간이 할당되고 그 Extent에는 해당 객체만 들어갈수 있다!

처음부터 Uniform으로 8 KB씩 할당하지 않는 이유 : 데이터베이스가 많은 작은 테이블을 보유하고 있을때 

공간들이 낭비되지 않게하기 위해서이다. (공간을 효율적으로 사용!)

3. 로그 파일 구조

- 데이터 파일처럼 익스텐트로 구성 X, 가상 로그 파일(Virtual Log File, VLF)이라는 저장 단위로 구성.

- VLF는 트랜잭션 로그의 잘라내기 단위가 된다.

- 로그 파일은 Circular queue 방식으로 순차적으로 저장이 되기 때문에 여러개의 파일로 분할하여도 성능향상은 기대할 수 없다. Circular queue 방식의 경우 데이터가 최근 저장된 순서로 다시 인출될 수 있으므로 트랜잭션의 개념에 가장 잘 부합된다.

- Transaction Log : UPDATE/DELETE/INSERT 등과 같은 작업 시에 기록되는 로그, 임의의 시점에 Checkpoint가 발생하면 Physical database에 기록

- 가상 로그 파일의 성능 : 파일이 작고 많을 경우 성능을 저하시킨다.

- 가상 로그 파일 변경 방법

1. BACKUP LOG 문을 사용하여 로그 백업을 수행.

2. CHECKPOINT 문을 사용하여 메모리와 디스크를 동기화.

  DBCC SHRINKFILE( logfilename, TRUNCATEONLY ) 를 사용하여 트랜잭션 로그 파일 축소.

  Sp_helpdb 데이터베이스명  으로 logfilename을 알 수 있다.

3. 데이터베이스 변경을 하여 로그 파일 크기를 수정(충분히 크게 늘려서 가상로그 파일의 크기가 크고, 개수가 적도록 한다. 증가값 역시 충분히 크게 잡는다.) 구문은 다음과 같다.

ALTER DATABASE dbname

 MODIFY FILE ( NAME = file_name, SIZE = new_size, FILEGROWTH = XXMB )

4. 데이터 페이지의 구조

text, ntext, image의 데이터 형태를 제외한 모든 데이터 로우들이 저장된다.

페이지 헤더에는 전페이지와 후페이지의 관계에 대한 포인터를 가지고 있다.

Offset은 각 Row가 시작되는 위치(시작되는 바이트가 페이지의 시작에서 얼마나 떨어져 있는지)를 알려준다.

5. 데이터 페이지의 동작 원리 

1. 클러스터드 인덱스 테이블(Clustered Index Table)

데이터 페이지들이 순서대로 정렬이 되어 저장되어 있는 상태. 따라서 각 테이블에 클러스터드 인덱스는 1개만 존재가능.

2. 넌 클러스터드 인덱스 테이블(Non-Clustered Index Table)

3. 데이터페이지의 관리

클러스터드나 넌클러스터드 인덱스 모두 B-Tree(Balanced Tree)구조를 가진다.

인덱스 된 뷰(Indexed View)는 클러스터드 테이블과 동일한 저장구조를 가진다.

* 모든 테이블, 인덱스, 인덱스 된 뷰 는 SYSINDEXES 테이블에 페이지 포인터(Page Pointer)를 가지게 된다. SYSINDEXES 테입블은 각 인덱스에 존재. SYSINDEXES 테이블에는 각 객체들에 대한 ID와 인덱스에 대한 ID인 INDID가 존재

이를 조회하는 쿼리

SELECT ID, INDID, FirstIAM FROM SYSINDEXES

이를 조회했을 때

1. INDID = 0  : 클러스터드 인덱스가 아닐 때. 순서 없이 저장된 테이블 = 이를 힙(Heap)이라고 한다. 이러한 힙 형태의 정보를 찾기 위해서는 SYSINDEXES.FirstIAM을 통해 데이터를 검색한다.

- 데이터 페이지 검색 방법 : SYSINDEXES의 FirstIAM 컬럼의 주소 값을 기준으로 첫 번째 IAM 페이지를 찾아간다. 이 IAM 페이지를 기준으로 익스텐트를 찾고 IAM 페이지에 있는 익스텐트 들을 모두 스캔했으면 다음 IAM페이지로 가서 또 스캔한다.

2. INDID = 1 : 클러스터드 인덱스. SYSINDEXES.Root 컬럼에는 클러스터드 인덱스의 루트 인덱스 위치 값이 존재

- 데이터 페이지 검색 방법 : 데이터가 정렬되어 있으므로 B-Tree를 검색하면 원하는 데이터 페이지 바로 검색 가능

3. INDID = 2~250 : 넌클러스터드 인덱스. SYSINDEXES.Root 컬럼에 넌클러스터드 인덱스의 루트 인덱스 위치 값이 존재

- 데이터 페이지 검색 방법 : SYSINDEXES의 개체 아이디가 일치하는 것을 검색한 후에 Root 컬럼 값을 찾아내면 해당 넌클러스터드 인덱스의 루트 노드를 가리키는 주소 값을 찾을 수 있다. 동일하게 B-Tree를 검색하면 원하는 데이터 페이지의 주소를 검색할 수 있다.

4. INDID = 255 : 텍스트나 이미지 형태. 각 테이블당 하나의 텍스트 및 이미지 컬럼을 가질 수 있다.

4. IAM (Index Allocation Map Page)

힙이나 인덱스 된 형태, 텍스트와 이미지 등 모든 개체의 익스텐트들을 관리

IAM 페이지에는 익스텐트의 시작 지점을 가리키는 헤더 정보를 갖고있다.

개체가 커져서 하나의 IAM으로 관리할 수 없을 떄는 연결 리스트 구조로 새로운 IAM이 추가된다.

IAM 때문에 한 데이터베이스에 파일이 여러개 일 때 DBCC SHOWCONTIG를 하면 약간의 왜곡이 생긴다.

* SQL 서버가 새로운 데이터를 데이터 페이지에 할당할 때

- 먼저 IAM페이지를 통해 개체에 할당된 익스텐트를 참조하여 익스텐트가 비어있지 않다면, PFS 페이지 정보를 검색하여 새로운 데이터를 저장. 이때 IAM이나 PFS 페이지 모두 메모리 버퍼 풀(Memory Buffer Pool)에 상주하여 매우 빠른 속도로 검색된다) 그리고 이러한 익스텐트에 대한 검색은 데이터를 삽입할 때 충분한 공간이 존재하지 않았을 때만 발생.

DELETE 삭제

TRUNCATE 삭제

DROP 삭제

테이블을 만들어서 100M짜리 데이타

이때, 데이타는 100만건있고

홍길동을 셀렉트로 검색하면 1시간 걸린다

Delete 를 하면 데이타는 지우지만 용량은 그대로이다 테이블 용량은 100M 그대로 

데이타를 줄이려면 100M -> 1M로 줄이려면 REORG 해줘야한다

delete하고 홍길동을 셀렉트 하면, 여전히 1시간 그대로 걸린다

TRUNCATE 는

내용을 다 날려버리고, 처음 create 했던것처럼 만든다

100M -> 1M 로 바로 줄어든다

Drop 은

create로 만들었던 테이블 까지 다 지워버린다

DDL(Data Definition Language) – 객체의 생성,변경,삭제 명령어 (CREATE , ALTER , DROP,RENAME 등)

▪SCHEMA, DOMAIN, TABLE, VIEW, INDEX를 정의하거나 변경 또는 삭제할 때 사용하는 언어
▪데이터베이스 관리자나 데이터베이스 설계자가 사용함
▪데이터 정의어(DDL)의 3가지 유형  

DML(Data Manipulation Language)- 레코드 제어 명령어 (SELECT, INSERT, UPDATE ,DELETE )
▪데이터베이스 사용자가 응용 프로그램이나 질의어를 통하여 저장된 데이터를 실질적으로 처리하는데 사용하는 언어
▪데이터베이스 사용자와 데이터베이스 관리 시스템 간의 인터페이스 제공
▪데이터 조작어(DML)의 4가지 유형

DCL(Data Control Language) – 객체 권한 부여등의 제어어 (GRANT 등)
▪데이터의 보안, 무결성, 데이터 회복, 병행 수행 제어 등을 정의하는 데 사용하는 언어
▪데이터베이스 관리자가 데이터 관리를 목적으로 사용함
▪데이터 제어어(DCL)의 종류

출처 : http://xxwony.egloos.com/25958 , http://blog.naver.com/digimon1740/110169209102