size는 bytes card는 E-rows에 해당한다고 생각하시면 됩니다.
그리고, 성능을 비교하고 튜닝을 함에 있어서는 무시해도 좋다고 생각합니다.
실제로 아무 도움이 안되죠.
2. dbms_xplan.display_cursor
이 걸로 다 됩니다. 튜닝...
지금 11g가 대세인 시기에 옛날 방식인 10046트레이스를 불편하게 걸어서 보실필요는 전혀 없구요.
다른 이유로 트레이스를 걸어야 할 경우는 있지만요.
3. 실행계획만큼 중요한게 outline정보인데 이게 아주아주 중요합니다.
아래는 제가 즐겨쓰는 출력포맷입니다.
select * from table(dbms_xplan.display_cursor(null,null,'allstats cost last +outline +alias +peeked_binds'));
위의 실행계획에서는 서브쿼리이기 때문에 unnest가 이루어지냐 아니냐가 굉장히 중요하구요.
그 정보가 outline에 나옵니다.
실행계획에서는 A-Rows 항목과 A-time, Buffers항목만 집중해서 보시면 됩니다.
이게 실제 실행결과물이니까요.
cr 이 Buffres에 해당하고 위의 2개 플랜을 비교함에 있어서는 플랜1이 274여서 더 나은 실행계획이라고 할 수 있겠네요.
대부분의 경우 Buffers와 A-time은 비례합니다. (Buffers가 적으면 시간도 더 짧다)
그리고, 성능을 비교하고 튜닝을 함에 있어서는 무시해도 좋다고 생각합니다.
실제로 아무 도움이 안되죠.
2. dbms_xplan.display_cursor
이 걸로 다 됩니다. 튜닝...
지금 11g가 대세인 시기에 옛날 방식인 10046트레이스를 불편하게 걸어서 보실필요는 전혀 없구요.
다른 이유로 트레이스를 걸어야 할 경우는 있지만요.
3. 실행계획만큼 중요한게 outline정보인데 이게 아주아주 중요합니다.
아래는 제가 즐겨쓰는 출력포맷입니다.
select * from table(dbms_xplan.display_cursor(null,null,'allstats cost last +outline +alias +peeked_binds'));
위의 실행계획에서는 서브쿼리이기 때문에 unnest가 이루어지냐 아니냐가 굉장히 중요하구요.
그 정보가 outline에 나옵니다.
실행계획에서는 A-Rows 항목과 A-time, Buffers항목만 집중해서 보시면 됩니다.
이게 실제 실행결과물이니까요.
cr 이 Buffres에 해당하고 위의 2개 플랜을 비교함에 있어서는 플랜1이 274여서 더 나은 실행계획이라고 할 수 있겠네요.
대부분의 경우 Buffers와 A-time은 비례합니다. (Buffers가 적으면 시간도 더 짧다)