MSSQL에선 실행 계획을 통해 인덱스를 타는지, 어떠한 쿼리가 더 빠른지 측정할 수가 있습니다. 쿼리 Set Statistics Profile { ON | OFF } -- 쿼리 결과에 실행 계획을 포함 Set Statistics IO {ON | OFF} -- 페이지의 입출력 수를 알 수 있다. Set Showplan_All { ON | OFF } -- 실행 계획만 보는 옵션 실행 계획은 SQL Server 쿼리 프로세서가 각 문을 실행할 때 취한 단계를 나타내는 계층적 트리를 이루는 행 집합으로 정보를 반환합니다. 출력에 반영된 문에는 문의 텍스트가 있는 단일 행이 포함되고, 이 단일 행 뒤에는 실행 단계에 대한 자세한 정보가 있는 몇 개의 행이 있습니다 아래 표에서는 출력에 포함된 열을 보여 줍니다...
복원 - 백업한 데이터를 복구하는 것을 말한다. 쿼리 Restore Database DB이름 From Disk='경로\파일명.bak' 복원시 옵션 1) 일반 옵션 - File : 한 파일 내에 여러개의 백업 존재 시, 백업 디바이스 헤더 검사에서의 Position 값을 넘겨주면 해당 백업만 복원합니다. Restore Database DB이름 From Disk='경로\파일명.bak' With File = 3 -- 해당 파일의 3번 Position의 백업만 복원 - DBO_ONLY : 복원 이후 권한을 db_owner 에게만 준다 Restore Database DB이름 From Disk='경로\파일명.bak' With Dbo_Only 2) 복구 이후 상태 설정용 옵션 - Recovery : 복원이 끝났으니 ..
백업시 참고 사항 - 기본적으로 model, northwind, Pubs, tempdb는 백업하지 않아도 됨. - master테이블은 권한과 같은 정보들이 있고, msdb테이블은 스케쥴이나 패키지 작업이 저장되어 있습니다. 필요한 데이터일 경우에만 백업하면 됩니다. 전체 백업 - 전체 백업은 데이터의 변경 유무에 관여하지 않고 전체 데이터의 복사본을 만드는 백업 방식입니다. - 전체 백업은 복구 과정이 다른 백업 방식보다 간편하고 다른 백업 방식보다 복구 시간이 적게 소요됩니다. 쿼리 Backup Database DB이름 To Disk='경로\파일명.bak' 차등 백업 - 차등 백업은 마지막 전체 백업 이후 변경된 모든 데이터를 백업하는 방식입니다. 이는 증분 백업과는 다르게 전체 백업 이후 파일이 변경..
1 . 데이터의 결합방법 1) 가로로 연결 : JOIN - 의미 있는 연결을 위해서는 로우(ROW)의 공통 요소를 이용하여 연결할 경우 사용 2) 세로로 연결 : UNION - 컬럼(Colum)의 공통된 형식을 어기면 연결 불가 2 . JOIN 가로(수평적)로 하나의 결과 집합과 다른 결과 집합을 연결하는 것 (집합 : 테이블, 뷰, 인라인뷰, 테이블변수....) 조인의 종류 ◎ INNER JOIN ◎ OUTER JOIN (LEFT , RIGHT 모두) ◎ FULL JOIN ◎ CROSS JOIN ◎ SELF JOIN 1) INNER JOIN 두 집합간의 하나나 그 이상의 공통 필드들에 기반해서 레코드들을 일치 INNER JOIN 은 배타적(exclusive) 결합 이다. 두 집합(테이블) 모두에서 일치..
참고 자료 http://support.microsoft.com/kb/197297/ko 용어 정리 Driving Table : 조인에서 기준이 되는 테이블 (= Outer Table) Drived Table : 조인에서 결합 되어지는 테이블 (= Inner Table) Nested Loop - 두개 이상의 테이블에서, Driving Table에서 먼저 조건에 맞는 집합을 만들고, Drived Table에서 조건이 맞는 결과를 얻어낸 후 Row를 결합하여 원하는 결과를 추출하는 방식 (Driving Table의 한 행당 Drived Table의 데이터 검색이 일어난다). - 부분 범위 처리 가능 (정지, 재개 가능. 예를 들어 조건에 만족하는 데이터 1000개만 얻어낸 상태에서, 요청이 들어올경우 1001~..
Page MS-SQL에서 다뤄지는 데이터가 저장되는 최소 단위는 Page 입니다. Page의 크기는 8KB ( 1024 * 8 = 8192 btyes ) 이지만, 실제로 데이터를 저장할 수 있는 maximum row size 는 8090 bytes 입니다. Page의 구성 1. header (96 bytes) 이전페이지와 다음페이지의 정보 저장 2. Data rows (8090 bytes) 실제 데이터 저장부분 3. offset 부분 각 행의 첫번째 바이트가 페이지의 시작부분에서 얼마나 멀리 떨어져 있는지를 저장 Extent 페이지가 최대 8개가 모여 한개의 Extent를 이룹니다. 테이블, 인덱스가 물리적으로 저장되는 최소 단위라고 생각하시면 됩니다. Extent의 크기는 64KB ( 8192 * 8 ..
1. Clustered Index만 존재했을 때 CI의 정렬 기준으로 실제 데이터를 정렬해 둡니다. 데이터를 찾을 때 CI를 타느냐, 테이블 스캔 하느냐의 차이만 존재합니다. 1-2. 구조 루트페이지와 리프페이지의 2중 구조 루트페이지에는 검색기준이 리프페이지에는 실제 데이터가 검색기준에 맞쳐 분류되어있음 쿼리시 루트 페이지에서 해당 검색기준을 통해 리프페이지(실제데이터)를 검색하여 결과처리 데이터 변경작업시 루트페이지에 맞쳐서 리프페이지를 다시 분류작업함 2. Non-Clustered Index만 존재했을 때 이 경우 NI의 키 값 대로 정렬된 데이터가 존재하고, 키 값에 대응하는 실제 데이터의 주소 (파일, 페이지, 행번호) 를 가집니다. NI에서의 키 값에 매칭되는 값을 찾은 후, 실제 데이터를 찾..
- Total
- Today
- Yesterday
- 엘키
- EasyExec
- 임백준
- SDL
- RoR
- 바로가기 프로그램
- 루비
- Rails
- ruby
- SQLite Spy
- 게임데브포에버
- 게임개발포에버
- ftp
- 디자인 패턴
- Ruby on Rails
- c언어
- NDC2013
- perfmon
- CppSQLite
- 조엘 온 소프트웨어
- 디버깅
- MS-SQL
- 멀티스레드
- 루비 온 레일즈
- svn
- TraceRoute
- TDD
- 좋은 프로그래머
- EzShortcut
- 리버스 엔지니어링
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
31 |