데이터 삭제 시 TabLock 의 이슈가 발생T1 테이블의 인덱스는 아래와 같이 구성되어 있습니다. 인덱스 종류 컬럼 Clustered Index + PK C1, C2, C3, C4 이 때, 라이브 중에 아래와 같은 쿼리를 사용하여 데이터를 삭제하려고 합니다.1DELETE FROM dbo.T1 WHERE C2 = 73985cs 문제는 T1 에 C2 의 인덱스가 없어서,TabLock 이 발생하게 되고 이 시간동안에는 다른 테이블이 접근할 수 없다는 점입니다. 이런 경우 TabLock 없이 어떻게 삭제 작업을 진행할 수 있을까요?시퀀스 (identity column)를 잘 활용해 봅시다.(T1 테이블에 너무 많은 데이터가 있다면 이 작업은 적절치 않을 수 있습니다.) TabLock 없이 삭제 방법1. 작업용..
Database
PK 란 ? PK 로 구성된 컬럼은 해당 값은 고유하며 NULL 이 될 수 없다를 의미합니다.즉 PK 로 조회하거나 데이터 변경시에는 무조건 1건만 적용됩니다. 데이터 변경 시, 왜 PK 로 지워야 하나? 1. 원치않는 데이터가 지워지는 경우를 방지데이터 업데이트 혹은 삭제 작업을 할 때,일반적인 인덱스 혹은 테이블 스캔으로 조건을 지정하는 경우원치 않는 데이터가 지워질 수 있음을 방지할 수 있습니다.이 말인 즉 C1, C2 컬럼을 PK 로 가진 테이블의 C1 = 2, C2 = B 를 지우려고 의도하였으나,DELETE FROM T1 FROM C1 = 2 쿼리를 날리게 되어 C2 = A 도 지워질 수 있음을 방지할 수 있다는 것입니다. C1 C2 1 A 2 A 2 B 3 A 2. Lock 이슈PK 가 아닌..
foreign key (외래키)1. 관계를 맺고있는 릴레이션 R1, R2 가 있을 때 R1이 참조하고 있는 릴레이션 R2의 기본키와 같은 R1 릴레이션의 속성을 말합니다.2. 외래키는 참조되는 릴레이션의 기본키와 참조관계를 맺는데 중요한 Key 입니다. 말이 어려울 수 있으니 간단하게 테이블로 참조해보도록 하겠습니다. Blogs 테이블에는 BlogID 의 기본키가 있습니다. Posts 테이블에는 BlogID 를 외래키로 참조하여 구성하였습니다. 즉, 하나의 Blogs 에는 여러개의 Posts 를 구성할 수 있다는 관계를 나타내고 있습니다. 이처럼 DB 에서 설계, 관계도는 매우 중요합니다.그럼에도 많은 사이트에서 foreign key 를 사용하지 않는 경우가 많습니다. foreign key 를 왜 사용하..
SP 검수 시 체크해야 할 리스트 * SQL Server 기준으로 작성하였습니다. 1. Ad-hoc, 동적 쿼리 제거1. Ad-hoc, 동적 쿼리는 실행 시 쿼리가 어떻게 구성되는지 알 수 없습니다. 구성을 알 수 없으면 인덱스가 적절하게 구성되었는지, 실행계획이 잘못풀려 악성쿼리인지 아닌지를 판단할 수 없습니다. 2. where 절 체크 사항1. 동일한 데이터 타입끼리 비교되는지 확인합니다. 서로다른 데이터 타입끼리 비교 시 CONVERT 함수가 사용되기 때문에 인덱스 사용을 할 수 없습니다.2. OR 문은 UNION ALL 로 변경 OR 문은 상황에 따라 Scan 으로 풀릴 가능성도 있습니다. UNION ALL 로 쿼리를 Seek + Seek 하는 방식으로 변경이 가능한지 확인합니다.3. CASE 문..
데이터 대량 변경 작업 시 체크해야 할 리스트 1. 서비스 영향도 확인1. 시간이 얼마나 소요될지에 대해 파악되면 이에대한 영향도를 개발팀에 확인 요청합니다. 2. 데이터 프리징이 가능한지 확인1. TAB LOCK 으로 대량 변경 작업 진행 시 더 빠르게 처리할 수 있습니다. 이는 ROW Lock 과 TAB Lock 에서 트랜잭션 로그가 쌓이는 방식에 대해 이해하고 있어야 합니다.2. 이 때는 점검을 걸어야 하고, 서비스가 불가능 합니다. 3. 대량 DELETE 작업 시 INSERT 작업이 더 효율적인지 비교1. ROW 별로 DELETE 작업을 진행하는 것보다 DELETE 대상이 아닌 데이터를 새로운 테이블에 INSERT 하는 작업이 효율적일 수 있습니다. 프리징이 되었다는 가정에서 새로운 테이블로 IN..
인덱스 삭제 시 체크해야 할 리스트 * SQL Server 기준으로 작성하였습니다. 1. 쿼리 힌트에 인덱스가 사용되지는 않았는지 확인 2. 쿼리 실행계획이 변경될 가능성이 있는지 확인1. 기존 쿼리가 삭제될 인덱스를 사용하는 경우 실행계획이 변경되게 되고 이로인해 이슈가 될 수 있는지 확인합니다. 3. 인덱스에 접근하는 쿼리가 있는지 확인1. dm_db_index_usage_stats 의 동적뷰에 마지막 접근 시간이 기록됩니다. 해당 뷰를 조회해서 인덱스가 지금도 사용되고 있는지 확인합니다. 4. ★ 인덱스를 바로 삭제하려고 하지마십시오.1. rename 으로 인덱스 명을 변경하여 삭제와 같은 상황만 만들어 둡니다. 유사 시 빠르게 복원이 가능하도록 준비하고 있어야 합니다. ( 인덱스 재생성 시, 테이..
테이블 삭제 시 체크해야 할 리스트 * 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. 테이블 명을 규칙없이 생성..
