인덱스 삭제 시 체크해야 할 리스트 * SQL Server 기준으로 작성하였습니다. 1. 쿼리 힌트에 인덱스가 사용되지는 않았는지 확인 2. 쿼리 실행계획이 변경될 가능성이 있는지 확인1. 기존 쿼리가 삭제될 인덱스를 사용하는 경우 실행계획이 변경되게 되고 이로인해 이슈가 될 수 있는지 확인합니다. 3. 인덱스에 접근하는 쿼리가 있는지 확인1. dm_db_index_usage_stats 의 동적뷰에 마지막 접근 시간이 기록됩니다. 해당 뷰를 조회해서 인덱스가 지금도 사용되고 있는지 확인합니다. 4. ★ 인덱스를 바로 삭제하려고 하지마십시오.1. rename 으로 인덱스 명을 변경하여 삭제와 같은 상황만 만들어 둡니다. 유사 시 빠르게 복원이 가능하도록 준비하고 있어야 합니다. ( 인덱스 재생성 시, 테이..
Database/DBA 의 개인생각
테이블 삭제 시 체크해야 할 리스트 * SQL Server 기준으로 작성되었습니다. 1. SP, 배치작업, 타 서비스에서 해당 테이블을 사용하는지 확인1. 테이블을 사용하고 있었는데, 갑자기 삭제가 된다면 서비스 장애로 이어지게 됩니다. 2. 테이블에 접근하는 쿼리가 있는지 확인1. dm_db_index_usage_stats 의 동적뷰에 마지막 접근 시간이 기록됩니다. 해당 뷰를 조회해서 테이블이 지금도 사용되고 있는지 확인합니다. 3. ★ 테이블을 바로 삭제하려고 하지마십시오. 1. rename 으로 테이블 명을 변경 하여 삭제와 같은 상황만 만들어 둡니다. 유사 시 빠르게 복원이 가능할 수 있도록 항상 준비되어 있어야 합니다. 생성과 다르게 삭제는 위험도가 높은 작업입니다.서비스에 영향이 없는지 꼼꼼..
컬럼 추가 시 체크해야 할 리스트 1. 컬럼의 Data Type 이 적절한지 확인1. Data Type 타입이 의미없이 크게 설정되어 있지는 않은지 확인합니다. 저장공간을 최대한 효율적으로 사용해야 합니다.2. TEXT / VARCHAR(MAX) / LOB 타입은 VARCHAR(8000) 과 같은 타입으로 변경할 수 있는지 확인합니다. 저장된 데이터를 한번 더 찾아가야 하는 비용을 줄일 수 있습니다. 2. 기존 서비스 중에서 * 로 조회하는 쿼리가 있는지 확인1. * 로 조회하는 경우, 컬럼이 추가되면서 서비스의 장애가 발생할 수도 있습니다. 아래와 같은 경우가 있겠죠. 'INSERT INTO VALUES (, , , ) SELECT * FROM .. ' INSERT 의 컬럼과 매칭되지 않게 됩니다. 그..
인덱스 생성 시 체크해야 할 리스트 * SQL Server 기준으로 작성하였습니다. 인덱스는 아래의 경우로 나뉠 수 있습니다.- 테이블을 생성하면서 만드는 경우- 서비스 도중에 쿼리가 추가되면서 만드는 경우 테이블을 생성하면서 만드는 경우에는 테이블에 접근하는 쿼리들을 최대한 수집 후에 필요한 인덱스를 생성하시면 됩니다. 1. 기존의 인덱스와 비교1. 생성하려는 인덱스가 기존에 구성된 인덱스에 포함시킬 수 있는지 확인합니다.2. 인덱스를 만드려고 하는 이유와 해당 인덱스를 사용하는 쿼리가 기존의 인덱스를 사용할 수는 없는지 확인합니다.3. 인덱스를 생성함으로 써 쿼리가 가지고 있는 이슈가 해결되는 지 확인합니다. -> '막무가내로 만들면 안된다' 를 전달하고 싶습니다. 2. 인덱스 생성 시 소요시간 체크..
테이블 생성 시 체크해야 할 리스트 * SQL Server 기준으로 작성하였습니다. 1. 테이블의 용도 1. 해당 테이블이 어떤 용도로 인해 만들어 졌는지 DBA 도 알고 있어야 합니다.2. 로그성 테이블인 경우 데이터 보관일자에 대해서도 결정이 되어야 합니다. 로그성 데이터는 계속 쌓을 이유는 없기 때문입니다. ( 그래서 많은 사이트의 경우, 몇년 이상의 기록은 확인할 수 없다. 라는 내용을 확인할 수 있습니다. ) 2. 데이터 유입량 체크 1. 테이블을 생성하면 하루에 유입되는 데이터 량과 최대 어느정도까지 데이터가 들어올지를 알고 있어야 합니다.2. 그 기준으로 데이터 파일 크기가 어느정도까지 늘어날지, 디스크의 이슈는 없는지 확인이 가능합니다. 3. 명명 규칙 확인 1. 테이블 명을 규칙없이 생성..
트리거란특정 이벤트가 발생하였을 때 동작합니다.특정 이벤트에 포함되는지 검사하기 위해 쿼리 수행마다 트리거를 확인하는 작업이 필요합니다. 트리거가 미치는 성능 테스트트리거 생성 전 테스트트리거를 생성하지 않고 trg_table 을 생성 한 후 20,000 건을 INSERT 합니다. SET NOCOUNT ON CREATE TABLE trg_table (C1 INT, C2 VARCHAR(500))GO DECLARE @ST DATETIMEDECLARE @ET DATETIMEDECLARE @I INTSET @I = 1SET @ST = GETDATE()WHILE @I
게시판의 구성 방식 구성 설명 블록 검정색 네모박스로, 페이지의 집합을 의미합니다. 페이지 주홍색 네모박스로, 게시글의 집합을 의미합니다. 이전/다음 블록 이동 녹색 네모박스로, 블록의 이동을 의미합니다. 이전/다음 페이지 이동 파란색 네모박스로, 페이지의 이동을 의미합니다. 테스트에 사용된 샘플 테이블은SQL Server 에서 제공하는 AdventureWorks 데이터베이스이 Sales.SalesOrderDetail 테이블 입니다.해당 테이블의 건수는 121,317 건이고, SalesOrderDetailID 컬럼에 DESC 정렬의 인덱스를 생성했습니다. 한 블록에는 10개의 페이지가, 한 페이지에는 10개의 게시글이 존재하고 있습니다.페이징 기법이 처리되지 않은 프로시저를 먼저 보고, 페이징 기법이 처..
이번 포스팅은 정말 주관적인 생각입니다. 테이블의 총 건수를 알고싶은 경우 COUNT(*)를 사용하여야 합니다.이는 DB입장에서 메타에 총 건수를 저장하여 COUNT(*)를 호출했을 때 해당 메타 정보를 반환하지 않는 한,언제나 Full Scan을 해야한다는 상당히 고비용의 작업이 요구됩니다. 따라서 실시간 서비스를 하는 입장에서는 부담이 큽니다. 개인적으로 생각한 대안의 방법으로는 (이 방법이 좋은지 않좋은지는 알 수 없습니다. 상황에 따라 많이 다르기도 하고요.)물리적으로 테이블 명과 해당 테이블의 레코드 수를 저장하는 테이블을 하나 더 만들어서 그곳에 데이터를 넣는 방법을 사용하면 어떤지 생각해 봅니다. 예시로 어떤 쿼리를 보겠습니다. (문법은 무시해 주시고 의미만 파악해주시길 부탁드립니다.)INS..
DBA 란 Database Administration 해석하면 데이터베이스 관리 입니다.데이터베이스에 관련된 모든 관리를 하는 직업군을 의미한다고 보시면 좋습니다. DBA 가 하는일 그럼 모든 관리에는 어떤것들이 속할까요? [개발단계] 에서는 아래와 같은 일을 합니다.1. 기획안 분석 후 데이터베이스 관계모델 설계2. 테이블 생성 및 프로시져 작성3. 인덱스, 정규화, 비정규화 등의 튜닝작업 [운영단계] 에서는 아래와 같은 일을 합니다.1. 데이터베이스 관리2. 백업 그렇다면 여기에서 데이터베이스 관리에 한번더 궁금증이 들어갑니다. 어떤 관리지?먼저 말하면 데이터베이스가 갑작스런 사태로 인해 죽는사태를 사전에 예방하는 역할을 말합니다.1. 디스크관리 : 로그를 작성하던 중 디스크 풀로 인해 데이터베이스 ..
CHAR 와 VARCHAR CHAR 고정길이 문자열 타입으로 만약 타입의 크기만큼의 데이터가 들어오지 않은경우 이후의 공간을 스페이스로 채워넣습니다.고정길이 문자열이기 때문에 헤더에는 레코드의 길이에 대한 정보가 들어있지 않습니다. VARCHAR 가변길이 문자열 타입으로 타입의 크기만큼의 데이터가 들어오지 않더라도 이후의 공간을 스페이스로 채워넣지 않습니다.가변길이 문자열이기 때문에 헤더에는 레코드의 길이에 대한 정보가 포함되어야 합니다. 예를들어 CHAR(5) 와 VARCHAR(5) 에 데이터 ABC 가 들어오는 경우 아래처럼 저장이 됩니다. CHAR 와 VARCHAR 의 차이점 그렇다면 실제 쿼리에서 조회를 하게 되면 어떻게 될까요?GOLDILOCKS 데이터베이스에서 테스트를 진행해보았습니다. ORA..
