어플리케이션의 성능 문제를 마주하였을 때, 여러가지 요소들을 고려해야 한다. 어플리케이션 자체의 문제, 운영체제, 가상화(VM), 스토리지, 하드웨어 및 네트워크를 포함하여, 사용자와 DB 사이의 모든 가동 부분에 대해서 생각해 봐야 한다. 본 포스팅에서는 어플리케이션의 성능이 문제가 되었을 때, 적어도 DB에서 생기는 문제는 이 포스팅을 통해 모두 해결의 실마리를 찾고, DB외의 것들을 고려할 수 있는 단계로 넘어가는 것을 목표로 한다. 어떤식으로 데이터베이스를 모니터링 해야 하는가? 데이터베이스 모니터링의 본질은 어느 특정한 날에 성능을 비교할, 과거 성능 통계 기록을 만들어 두는 것에 있다. 시간 경과에 따른 DB 성능을 모니터링하고, 장기적 관점에서 리소스 활용도를 요약하는 스냅샷 모음을 점진적으..

본 포스팅에서는 쿼리 성능 향상 및 리소스 소비 감소를 위한 인덱스 최적화에 대해서 알아볼 것이다. DB에서 테이블에 인덱스를 생성하고 나면, 생성한다고 끝나는 것이 아닌, 주기적인 관리가 필요하며 이러한 관리가 제대로 되지 않으면 인덱스를 쓰지 않는것만도 못하게 된다. 따라서 어떤 식으로 관리해야 되는지에 대해 알아보자! 우선 인덱스 관리의 필요성을 알아보기 위해, 인덱스 조각화(Index Fragmentation)에 대해 알아보자! 인덱스 조각화(Index Fragmentation)란? : 디스크 상에 Page들이 연속적으로 위치해 있지 않고(서로 연관된 데이터들이 한 Extent로 묶이지 않는), 공간을 두고 떨어져 있는 현상을 말한다. 인덱스를 처음 생성했을 때에는 연속해서 서로 연관된 데이터들끼..

본 포스팅에서는 지난 '[MSSQL] 통계(Statistics) (1)' 포스팅에 이어, MSSQL의 통계에 더 알아볼텐데, Optimizer의 CREATE 및 UPDATE의 시기 설정과 통계를 효율적으로 사용하기 위해 쿼리를 어떤 식으로 작성해야 하는지에 대해 알아볼 것이다. 언제 CREATE STATISTICS 해야 하는가? 먼저 통계가 쿼리 옵티마이저에 의해 자동으로 생성되는 두 가지 경우를 살펴보자. 인덱스가 생성되면, 쿼리 옵티마이저는 테이블 또는 뷰(View)의 인덱스에 대한 통계를 생성. 이때 통계는 인덱스 키 Column에 대해 만들어지며, 필터링된 인덱스(특정 조건에 맞는 데이터에 대해서만 인덱스를 생성한 것)의 경우, 필터링된 인덱스로 지정된 Row의 동일한 Subset에 대해 필터링된..

지난 포스팅에서 MSSQL에서의 백업의 종류에 대해서 알아봤다! MSSQL에서 백업은 Full 백업, Differential 백업, Transaction Log 백업으로 총 3가지를 지원하는 것을 알았다. 백업의 종류에 관한 내용은 아래 링크를 참고하면 된다. https://co-no.tistory.com/5 [MSSQL] 백업 종류 - Full / Differential / Transaction SQL Server에서의 백업 종류 3가지를 알기 전에, 먼저 MSSQL에서 데이터가 어떤 식으로 저장되는지부터 알아야 할 필요가 있다. MSSQSL은 3가지의 파일형식으로 데이터를 저장한다. 각각 MDF, NDF, LDF 라 co-no.tistory.com 이번 포스팅에서는 백업을 진행하여 생성된 백업 데이터..

SQL Server라는 DBMS에 대하여 배우려고 왔는데, 갑자기 '통계'라는 내용이 나와서 당황스러울 것이다. 여기서 말하는 '통계'란 교육과정에서 배웠던 따분했던 '확률과 통계'와 같은 내용은 아니니, 안심하길 바란다! 그렇다면 MSSQL에서 말하는 통계란 무엇인지 살펴보자! SQL Server의 통계(Statistics)란? 테이블 또는 인덱스 뷰에서 하나 이상의 컬럼 값들의 분포에 대한 통계 정보를 포함하는 BLOB(Binary Large Objects) 이다. Query Optimizer가 이러한 통계 정보를 활용하여, 쿼리결과의 *카디널리티, 행(Row)의 개수 등을 예측하고, 최적의 Query Plan을 작성한다. => 이러한 *카디널리티 예측치를 활용하여 Query Optimizer가 리소..

인덱스란? : 추가적인 쓰기 작업과 저장 공간을 활용하여 DB 테이블의 검색 속도를 향상시키기 위한 자료구조 "책의 앞 부분에 있는 목차!" => 목차가 없다면, 찾으려고 하는 내용을 만날 때까지 책을 한 장씩 모두 넘겨야 한다. => 목차가 있기 때문에, 책의 어느 위치에 원하는 내용이 있는지 쉽게 찾을 수 있다! => 데이터를 조회할 때 테이블의 모든 데이터를 하나하나 읽는 것보다 더 적은 페이지를 읽음으로써, 발생하는 Disk I/O를 줄일 수 있다. But, 인덱스 역시 Page로써 존재하므로 물리적인 공간을 차지한다. SELECT의 성능은 향상시킬 수 있지만, UPDATE,INSERT,DELETE와 같은 데이터 변경 작업의 경우, 모든 인덱스에도 동일하게 작업이 수행되어야 하기 때문에 오히려 성..