지혜를 창출할 창고

보호되어 있는 글입니다.

카테고리 조회하는 웹 페이지에서 조회가 느려서 원인을 파악하기 시작 쿼리 수행 시간은 20msec (페이지 요청 후 응답이 끝나는 시점까지 총 7초~8초가 소요되었다.) 쿼리는 총 여섯 번의 self join하는 쿼리인데, 쿼리 수행만 본다면 문제가 되지 않는다. 과도하게 찍히는 로그 로그를 보니 개발과 운영 모두에서 이 정도의 로그는 필요하지 않기 때문에 로그를 껐다. - resultSet에 관련 내용을 검색한 결과 - 방대한 양의 로그를 찍어준다. - 결론 : resultSet 의 로그 끄기 logback-test.xml, logback.groovy 등의 파일이 있을 수 있다. 1. appender 2. 페이지가 요청 후 바로 뜨는 것을 확인하고 요청 업무는 해결하였다. 불필요한 로그는 끄자. - m..

참 간단한 설정으로 실행계획을 확인할 수 있었다. 단축키 Ctrl + M 추가로 statistics로 실행 시간을 메시지 형태로 확인할 수 있는데, 설정 경로는 캡처로..

늘 약했던 DB, 실행 계획을 조금 더 이해하고 능동적인 개선을 실행하자. Scouter 보고 있던 중 실행 계획, 바인딩 변수, 정적 실행에 대해 이야기 나누던 중 SSMS(Microsoft SQL Server Management Studio) 사용방법에 대해 코칭을 받게 되었다. 기본적으로 WHERE 절과, scala query가 포함된 SQL 구문으로 이야기가 이어졌다. 바인딩 변수 실행계획 cost 계산 시 해당 컬럼의 분포도만 가지고 실행 계획을 산정한다. 정적인 변수 컬럼에 해당 값이 어느정도 있는지 확인 후 cost 계산을 산정한다. 1번 테이블을 기준으로 2번 테이블을 출력하는 과정이며, 조회하고자 하는 컬럼은 1번 테이블의 인덱스 설정이 되어있는 1_SEQ 컬럼과 스칼라 서브쿼리의 컬럼이..