[DB] SQL 튜닝 강의 2일차

환경 설정에 대한 문제 , 물리적으로는 노트북이 부족해서 불평을 표하는 사람들이 많아서 조금은 불쾌하게 강의를 시작한 느낌이 있지만 될수 있으면 좋은 강의를 긍정적으로 들을 수 있도록 .... 오늘도 시작합니다.

Read consistent?

읽기의 일관성을 위해 Update등을 하면 update를 실시 한 사용자는 변경한 값을 볼 수 있지만 다를 사용자는 Commit을 하기 전까지는 볼 수 없는 내용을 확인하기 위해서 Undo Table에 있는 값을 읽어 와 update되기 전의 값을 읽어오는 것을 읽기 일관성(Read consistent)이라고 합니다.

위 내용은 제가 들은 설명을 정리한 것이라 정확하지 않을 수 있습니다. 조금 더 정리를 하여 수정하고 다듬도록 할 예정입니다.

"다른것은 다 잊으셔도 되니 DML을 쓸 때 DB Block계층이 나타납니다."  라는 말씀을 강하게 하셨습니다.

삽입, 수정, 삭제 를 빨리할 수 있는 방법은 뭐가 있을까요??

insert -> 딱히 없네요 방법이 느려지는 이유를 찾으려면 다른 것을 확인해야 합니다.

Update -> 한건정도만 하면? 찾아야 하는데... 찾는데 조건을 잘 줘서, 예를들면 인덱스를 주고 찾을 수 있겠습니다.

Delete -> 한 행을 지운다고 가정할 때 위와 같이 한 행을 인덱스를 통해 빨리 찾으면 됩니다.

sort(memory) 통계값과 sort(disk)값은 각각의 장치에 정렬을 한 횟수로 메모리에서의 정렬은 PGA에서 처리를 합니다. 위 정렬 작업을 간단히 비유하면 암산을 하다가 양이 많아지면(숫자가 커지면) 손으로 써서 계산을 하는 것과 유사합니다.

통계값중 값이 나올 경우 가장 성능저하를 가져 올 수 있는것은 무엇일까요?

 

 

1. consistent gets

2. physical read

3. sort(memory)

4. sort(disk)

 

답은......

 

4번.... 이유는 뭘까요?? 우선 1번과 3번은 작업하는 HW가 메모리입니다. 속도가 훨씬 빠릅니다. 물리적인 디스크를 사용하는 2번과 4번을 비교해야 하는데 2번의 경우에는 물리적인 읽기를 할 경우에는 해당 내용을 메모리로 caching 하므로 다시 활용을 할 수도 있습니다. 모든 data는 한번은 Caching해야하기 때문이죠... 하지만 4번의 경우는 정말 좋지 않습니다. 그 이유는 disk에서 정렬을 하여 쓰고, 그러므로 메모리보다 속도가 느립니다. 게다가 재활용이 불가능 하기 때문입니다.

따라서 2번과 4번 특히 4번의 경우는 수치가 0이거나 0에 가까울 수록 좋습니다. 특히 서버의 성능이 나쁠수록 해당 수치들에 민감한 편입니다.

 

위의 붉은 상자로 처리 한 부분은 실행 계획만을 보는 것으로 파싱을 한 후 실행계획을 만들었다라는 의미의 확인 메시지로 생각하면 될 것 같습니다.

-------------------------------------------------------2---------------------------

실행계획 보기 다른방법

 

V관련된 것을 보려면 일반사용자는 권한이 없어서 Error이 발생합니다.

권한을 부여하는 아래의 SQL문을 수행하면

SQL> conn / as sysdba

SQL> grant select on v_$session to scott;

SQL> grant select on v_$sql_plan_statistics_all to scott;

SQL> grant select on v_$sql_plan to scott;

SQL> grant select on v_$sql to scott;

SQL> conn scott/tiger

SQL> SELECT * FROM dept WHERE deptno=10;

SQL> SELECT * FROM table(DBMS_XPLAN.DISPLAY_CURSOR);

바로 위의 SQL문을 수행했을 때 아까와 달리 결과가 정상적으로 보입니다.

 

 

 

trace결과를 보기 위에 위의 화면 위에 있는 이전의 파일을 tkprof를 사용하여 보기 좋은 양식으로 정리 된 결과라고 생각하시면 됩니다.

 

 

위 화면은 TKPROF만 입력하여 해당 툴을 사용하는 방법을 안내해주는 화면을 캡쳐한 것이고 옵션들을 접두어에 따라 분류 해 표시하였습니다.

위의 옵션들은 여러개를 동시에 사용할 수 있습니다.

 

========================================================3============================

두가지 실행계획을 비교할 수 있습니다. 그 두가지는 이전에 실행 항 것과 지금 다시 실행 한 것을 비교하는 것입니다.

위의 화면을 보면 Row Source Operation과 Excution Plan을 비교하여 볼 수 있는 것 입니다. Row Source Operation 가 실제로 실행된 것입니다.

 

위의 화면은 대기시간이 발생한 화면을 캡쳐 한 것입니다. 정상적인(?) 범위를 넘어서는 대기시간입니다.

 

위의 화면은 대기시간이 발생한 이유를 캡쳐한 화면으로 해당 화면을 분석을 하면 LOCK때문에 발생한 대기임을 확인할 수 있습니다.

위와 같은 대기시간이 배치작업이 아닐경우 문제가 됨.

배치작업 또한 오래 걸리지 않는 작업이지만 lock에 걸려서 대기하는 시간이 대부분이고 그 때문에 배치작업이 사간을 많이 소요하게 됩니다.

3~5초 소요되면 퇴근????????????????????????????????????????????????????!!!!!!!!!!

실행 계획만을 보면 되는 것이 아니라 실제로 사용된 것과 대기시간도 확인을 해야 성능저하 문제를 해결할 수 있는 경우가 있습니다.

아기의 울음에 비유하셔서 설명.... 아기가 우는것과 DB의 성능저하를 같다고 보면 아이가 운다고 모두 한가지 원인인 것은 아니라는 느낌!! 배고파서 울 수 있고 아파서 울 수 있으므로 그렇습니다.