돼지와함께춤을 님의 블로그

적은 리스크, 간단한 수정만으로 많은 I/O를 줄일 수 있는 사례이다.사실 글을 보고 당연한거 아닐까.. 라고 생각하지만 은근 이부분을 놓치는 개발자들이 많은것 같다, 생각보다 이런 케이스가 잦다 튜닝 요청받은 기존 SQL을 보고 성능 저하 요소를 바로 찾을 수 있었다, 실행계획, 통계 안따도 보이는 사례였다.원본 SQLSELECT 년월 , sum(여성건수 + 남성건수) as 데이터총합FROM ( SELECT substr(처방일자, 1, 6) as 년월 , 진료과코드 , CASE WHEN 진료과코드 IS NULL THEN '계' ELSE FN_ZS_GETDEPTNAME('012', 진료과코드, '20240909') END AS..

Oracle에서 SQL 튜닝을 위해 사용하는 실행계획 명령어를 간단하게 4가지로 정리해보았다.* 주요출력정보에서 파란색 텍스트는 다른 실행계획 출력 방법과 대응되는 의미가 있을시 표기하였고 마지막에 정리하였다.​1. Explain Plan For 　실행계획문법Explain plan[SET STATEMENT_ID = '계획ID' INTO PLAN_TABLE]FOR ;SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY('PLAN_TABLE', '계획ID', 'ALL'));비고sql을 실행하지않고 예상 계획을 수립예상 카디널리티, 코스트, cpu 시간, 바이트크기, 조건절 정보예상계획으로 실제 실행시간은 불가주요 출력 정보predicate information(조건절 정보)ROWSBYTESC..

운영 쿼리를 보다 보면 작성자들은 스칼라 서브쿼리를 참 좋아한다.몰론 운영 쿼리는 초기 작성 상태가 현재까지 유지되는게 아니라사용자 요구에 따라, 변화에 따라 몇년간 수정에 수정을 가해 지금 상태의 아주 길고 복잡한 쿼리가 된건 알지만.. WAS에 올린 쿼리가 아닌 SQL을 보관했다 정기적으로 실행하여 데이터를 추출 전달하는 1회성 쿼리를 보아도지나치게 스칼라 서브쿼리를 좋아하는 경향이 있는것 같다.이유는 딱 한가지, 스칼라 서브쿼리는 SELECT 절 밑에다 덧붙이기 쉬우니까.. 하지만 이러한 SQL작성 습관은 추후 악성쿼리를 유발하기 쉽다.그래서 처음부터 설계시 동일 패턴의 스칼라서브쿼리를 통한 중복 엑세스를 방지 하기 위해 인라인뷰를 활용해보는것도 좋을 것 같다. 아래는 한가지 사례를 들고왔다, ..

튜닝 중 재미있는 사례가 있었다, 사용자 요청으로 인한 데이터 일괄 수정 중 재고부서, 물품코드, 입출 월별로 적요가 모두 공란이면 마지막 입출일자중 마지막 입출번호 데이터에만 적요를 "특이사항 없음" 이라고 적어주세요 아래는 테스트 데이터 예시를 들어보았다, 빨간 표기가 사용자 원하는 일괄수정이다재고부서물품코드입출일자입출번호적요구매팀A202410010001 구매팀A202410010002 구매팀A202410020001 구매팀A202410150001 구매팀A202410150002특이사항 없음구매팀A202411050001 구매팀A202411070001 구매팀A202411070002 구매팀A202411070003 구매팀A202411070004 구매팀A202411250001추가입고구매팀A202412010001 ..