공부, 기록

클러스터드 인덱스의 경우 테이블에 Sch-M 락을 요청한다.해당 락으로 인하여 Sch-S락을 필요로 하는 작업은 블락이 걸린다 (WITH NOLOCK 구문도 Sch-S 락을 요청한다)   논클러스터드 인덱스의 경우 테이블에 Sch-S와 S락을 요청한다.해당 락으로 인하여 단순 조회의 경우 블락이 걸리지 않는다 (S, NOLOCK 등)  아래는 공식 문서의 내용을 가져옴  참조https://learn.microsoft.com/ko-kr/sql/relational-databases/sql-server-transaction-locking-and-row-versioning-guide?view=sql-server-ver16

데이터, 로그 플러시와 커밋에 대해 헷갈리는 부분이 있어 정리하고자 한다. SQL SERVERSQL SERVER는 버퍼캐시라는 메모리 공간을 사용한다.위 아키텍처에서 확인할 수 있듯 버퍼캐시의 내용은 Lazy Write와 Cechk Point에 의해 Datafile로 동기화 된다.1. 데이터 파일은 버퍼캐시의 더티 캐시가 특정 주기 (CHECKPOINT)에 맞춰서 Datafiles로 Flush 된다.2. 로그는 데이터보다 먼저 쓰기 및 커밋이 되는데 이를 WAL 이라고 칭한다.WAL을 통하여 서버 장애로 인한 데이터 파일에 변경 내용이 저장이 되지 않은 커밋은 복구가 가능하다.데이터 변경 -> 로그 캐시 기록 -> 트랜잭션 로그 플러시 및 커밋 -> 더티 캐시 검사점에 의한 데이터 파일 플러시 공식 문서..

SP에서 Sort가 오래 걸리는 상황이 발생하여 정렬되는 기준으로 include 컬럼을 포함한 인덱스를 추가로 생성하였다. 기존 인덱스를 A 신규 인덱스를 B로 칭하면 A는 CREATE INDEX A ON TABLE_MINJAE (COL1, COL2 ) B는 CREATE INDEX B ON TABLE_MINJAE (COL1, COL2 ) INCLUDE (COL3) 인 상황. SP에서 지연되는 부분에 INDEX 힌트로 B 인덱스를 강제하였을 때 Sort 지연이 해소가 되었는데. 실행계획을 자세히 확인하였을 때 해당 인덱스가 아니었어도 동일하게 해소가 되어야 하는 상황으로 보였다. B 인덱스 힌트를 제거하고 A 인덱스 힌트를 사용하였을 때 성능이 다시 좋아진 것을 확인하였고 신규 생성한 인덱스 B를 제거하였..

DROP과 TRUNCATE는 실제 명령이 로그를 생성하지 않는다고 오해한다 하지만 일부 LOG가 생성이되고 (메타 데이터와 페이지, 익스텐트와의 연결을 끊는 상황) 백그라운드 프로세스의 지연된 삭제에 의해 트랜잭션 로그에는 익스텐트 삭제가 기록으로 남는다 일반적으로 테이블의 0.3~0.4%의 크기가 로그 파일에 기록이되고 기록된 로그는 AG, 미러링, 로그 복제의 경우 전달이 된다. 다만 백그라운드 프로세스에서 해당 삭제 처리는 하나의 트랜잭션이 아닌 여러개의 트랜잭션으로 나누어져서 처리가되어 큰 이슈는 없다고 한다.... TEST DROP TABLE ~~~ SELECT [Current LSN], [Operation], [Context], [Log Record Length], [Description] F..

Always On 데이터 동기화 방식Record the data changes that occur on the primary replica.Transfer the records to each secondary replica.Complete the data changes on the secondary replica.The three tasks are mainly completed by the following four threads:Log Writer: It is responsible for recording the modified log information into a log buffer in memory and then written into the physical log file.Log Scanne..

도메인 구성 IP DC : 10.0.16.190 NODE 01 : 10.0.16.245 NODE 02 : 10.0.17.152 도메인 서버 서버관리자 → Active Directory Domain Service 설치 Promote this server to a domain contoller 로 DC로 변경 Add a new forest로 설정한 후 도메인 명칭 입력 쭉쭉 넘기며 설치까지 진행 AD JOIN 각 노드 서버에서 컴퓨터 -> 속성 -> 이름 변경 설정 -> 네트워크 및 인터넷 -> 이더넷 -> 속성 인터넷 프로토콜 버전 4(TCP/IPv4) DC 조인 확인 ISCSI 구성 타겟 서버에서 iSCSI Target Server 기능 추가 iSCSI 디스크 생성 server에 node를 하나씩 추가 ..

운영중이지 않은 MYSQL 서버가 SHUTDOWN 되어 확인이 필요했다. 1. 메모리 관련 지표의 특이사항 2. OS 에서 OOM 로그 확인 메모리 증가로 인한 OOM으로 확인이 되었으나 해당 서버는 대기 서버로 MYSQL 서버의 급격한 메모리 사용이 있을 수 없는 상황이었다. A -> B -> C 서버로 구성된 복제 서버중 C 서버였고 A, B 서버 모두 메모리 관련으로 인한 서버 이슈가 없는 상태에서 C 서버에서만 MYSQL 이 죽었기 때문에 MYSQL의 영향이 아닌 다른 프로세스의 영향이라고 생각이 되었으며 DOWN 당시 MYSQL의 rss 는 3.5G 였다(서버는 8G의 메모리) 서버의 AD 계정 인증을 위한 SSSD 프로세스 중 하나가 RSS 값이 3G를 넘게 사용하고 있었고 이것에 대한 확인을..

수정내용 : 파라미터 값에 따라 쿼리 리소스가 증가하는 SP에 대하여 RECOMPILE OPTION 추가 RECOMPILE에 대해 잘못 알고 있었던 점이 있었다. RECOMPILE을 할 경우 나는 최신의 통계로 실행계획을 다시 수립해서 옵티마이저가 더 좋은 실행계획을 생성하고 이로 인하여 성능이 개선되는 경우가 있다고 생각했는데, 사실 RECOMPILE은 통계 업데이트와는 상관없다. 다만 로컬변수의 상수화가 되는 것이 가장 큰 차이였다. 다만 RECOMPILE 옵션은 매번 SP 호출마다 컴파일을 해야하므로 약간의 CPU 상승은 동반된다(다만 개선된 쿼리가 더 큰 차이의 CPU 개선을 보였음). ※ RECOMPILE을 하는 이유 파라미터 스니핑 대책 SP의 경우 처음 들어오는 매개변수 값에 따라 실행계획이..

서비스에서 6개월 단위의 데이터만 남기는 작업을 6개월 ~ 1년 단위로 진행하고 있었다. 해당 테이블은 개발팀을 통해 무료 재화 개념의 데이터로 법적 보관 의무가 없어서 상시 6개월 데이터만 보관하여도 가능한 것 확인. 데이터 분포 파악 -- 일 평균 44만건 (최대 94만 최소 18만 건) 개선 방안 파티션 테이블 검토 VIEW 생성하여 물리적인 파티션 개념 적용 매일 6개월이 지난 데이터 삭제 1. 파티션 테이블 생성할 경우 결제 일자값으로 생성 테이블 자동 관리가 용이할 것으로 보임 다만 주요 조회 값은 결제번호로 조회가 되므로 성능 향상에 기대가 어려움 참고) 더보기 파티션 테이블 인덱스 비파티션 - 파티션 키 칼럼이 조건절에 누락되면 여러 인덱스 파티션을 액세스해야 하므로 비효율적. 특히, OL..

DETAIL 테이블의 ParentDetailNo 컬럼으로 조건 조회를 하면서 테이블 풀스캔이 발생함. 해당 테이블에 인덱스 추가 또는 조건절 변경이 필요. ParentDetailNo 컬럼은 해당 SP에서만 조회 조건으로 사용이 됨(인덱스 설정시 사용하는 쿼리가 하나..) DETAIL 테이블과 MASTER 테이블 은 1:N 관계이고 MASTER 테이블의 PK 는 ParentDetailNo 컬럼 1:N 관계 MASTER 테이블 DETAIL 테이블 존재 관계는 1: N 또 DETAIL 테이블 내에서 하나의 PK는 여러 다른 ROW의 부모 값이 될 수 있는 상황 위 상황에서 DETAIL 테이블에 새로운 조건으로 WHERE 절이 추가되었고 해당 컬럼은 인덱스가 없는 상태에서 UNION ALL로 처리가 되고 있었음..