오라클 "엑사데이터"에 대해 얘기할 때 가장 많이 듣는 것이 스마트스캔(Smart Scan) 이라는 기술입니다.

이 기술이 엄청난 성능 향상을 가져온다고 알려져 있죠~

엑사데이터 머신(Exadata Machine)은 어플라이언스 머신, 일체형 장비라고 불립니다.

랙(Rack) 안에 여러대의 서버와 스토리지, 네트웍 장비들이 함께 구성되어 유기적으로 돌아가는 형태이고, 이게 사용자가 여러업체의 장비들을 사다가 구축하는 형태가 아니라, Oracle 사에서 이미 정해진 규격화된 제품들로 랙을 채워서 한꺼번에 공급하는 형태입니다.

어쨌든 랙안에 DB서버와 스토리지가 들어있는데, 이 스토리지가 CPU, Memory 가 탑재된 연산이 가능 스토리지 장비 입니다.

이 연산이 가능한 스토리지 장비가 SQL의 일부연산을 미리 하는 것을 스마트스캔 이라고 합니다

스토리지에서 단순히 Disk I/O 만 하는게 아니라 SQL의 Where 조건절(필터링)을 DB서버대신 일부 수행해 줍니다.

예를 들어, 3GB 크기의 테이블을 DB서버로 읽어와서 SQL을 수행해야 하는 경우에,

Exadata의 스토리지서버는 3GB 를 모두 읽어서 DB서버로 보내지 않습니다.

스토리지서버가 Where 조건절의 일부를 전처리하고, 이 처리결과값만 DB서버로 보냅니다. 그러면, DB서버는 이 데이터만 가지고 나머지 SQL을 마저 처리하는 방식입니다.

원래는 3GB 데이터를 DB서버의 메모리로 로딩해야 하는데, 이런 기술로 10MB 만 DB서버로 보낸다고 생각해 보면,

이게 얼마나 성능을 개선할지는 대충 감이 오게됩니다. ^^

그런데, 이 Smart Scan 을 사용하기 위해서는 몇가지 충족되어야 하는 조건이 있습니다. 모든 SQL들이 다 Smart Scan 을 하는 것은 아닙니다.

그럼, 내 SQL 이 Smart Scan 을 하는지 않하는지 확인하는 방법은?

Wait Event 를 확인하는 방법도 있습니다만, SQL 실행계획과 함께 가장 쉽게 확인해 볼수 있는 방법이 Realtime SQL Monitor 라는 것을 이용하는 것입니다.

아래와 같이 확인이 가능합니다.

1) 스마트 스캔을 하는 경우

2) 스마트 스캔을 안하는 경우

위의 2개의 결과는 Oracle Realtime SQL Monitor 기능을 이용해서 스마트스캔을 하는 경우, 안하는 경우의 Plan 을 떠 본 것입니다.

1) 번에서 보면, 원래는 3GB 를 읽어야 하는데, Offload(스마트스캔) 해서 10MB 만 읽었다는 내용을 확인할 수 있습니다.

2) 번의 경우에는 Exadata 장비가 아닌 일반 장비라 스마트스캔을 할 수가 없습니다. 그래서 Offload 관련된 항목이 나오지 않는 것을 확인할 수 있습니다.

 

 

 

자 그럼 참고로 Realtime SQL Monitoring 에 대하대도 알아보자 
 
 

Oracle DBMS 11g 부터 사용할 수 있는 아주 유용한 기능중에 하나가 Realtime SQL Monitoring 이라는 기능입니다.

이 기능은 EM (Enterprise Manager) 이라는 Oracle 유료 툴의 일부 기능입니다.

따라서 정식으로 사용하기 위해서는 EM Tuning Pack 라이센스가 필요합니다.

하지만, 따로 제한이 걸려있거나 하지 않습니다. 개인적으로, 또는 연습목적으로 사용하는 데는 아무런 제약이 없습니다.

 

Realtime SQL Monitoring 을 사용하는 구문은 아래와 같습니다.

 

SQL> 
set long 1000000
set longchunksize 1000000
set linesize 1000
select DBMS_SQLTUNE.report_sql_monitor(sql_id => '&sql_id', type=>'TEXT' , report_level => 'ALL') from dual;

 

그닥, 복잡하지 않습니다. DBMS_SQLTUNE 패키지의 report_sql_monitor() 함수를 호출하면 됩니다.

이때, 결과를 보기좋게 만들기 위해 set long, set linesize 같은 구문을 실행해 줍니다.

 

실행결과는 아래와 같이 나옵니다.

 

 

맨 윗부분에 실행한 SQL문장이 표시되고,

다음에 정보(Information) 부분이 표시됩니다. 실행중인지, 실행이 끝났는지, 어떤 유저에서 실행한 건지 등등...

다음으로 통계정보(Stats) 가 표시됩니다.

    - Elapsed Time : 경과시간

    - Cpu Time(s)   : CPU 사용시간 (초단위)

    - IO Waits(s)    : Disk I/O에 걸린 시간 (초단위)

    - Fetch Calls    : Fetch 횟수 (조회결과 건수 아님)

    - Buffer Gets   : 가져온 Block 갯수

    - Read Reqs    : Disk I/O 요청 횟수

    - Read Bytes   : Disk I/O 한 크기 (MB)

 

마지막으로 Plan 이 표시됩니다. 정확히 말하면 Plan + Trace 입니다.

단순히 실행계획만 나타나는 것이 아니고, 실제로 실행한 정보가 표시됩니다.

아래 일반 Plan 과 비교해보면 차이점을 확연히 알 수 있습니다.

 

 

위 Plan 뜬 걸 보면 Rows 가 8192건으로 나옵니다. 이건 실제로 조회를 해보지 않고, 통계정보만을 바탕으로 Oracle Optimizer 가 예측한 정보입니다.

 

 

Realtime SQL Report 에서 보면 Rows(Actual) 이라는 값을 확인할 수 있습니다.

통계정보를 기반으로 Plan을 봤을때는 Rows(Estim) 값이 8192 건으로 예측되었지만,

실제로 실행해보니, Row(Actual) 값이 65536 건이 조회되었다는 의미입니다.

 

이렇게 실제 실행한 정보를 확인할 수 있기 때문에 과거 Trace 뜨는 것과 같은 효과를 발휘합니다.

이 경우는 통계정보가 실제와 많이 다른 것을 확인할 수 있고, 따라서 통계정보 갱신작업을 해줄 필요가 있습니다.

 

위에서 report_sql_monitor() 함수를 호출하면, &sql_id 에 의해 sql_id 값을 입력하라고 합니다.

즉, sql_id 값을 알아야 Realtime SQL Report 를 확인할 수 있습니다.

 

SQL> 
set linesize 1000
select username, module, sql_id, substr(sql_text,1,60) sql_text
from v$sql_monitor
where sql_exec_start >= sysdate - 1/24
order by sql_exec_start;

 

sql_id 값을 얻기 위해 위와 같이 딕셔너리 뷰에서 조회할 수 있습니다.

 

 

v$sql_monitor 딕셔너리뷰를 조회하면 위에서처럼 SQL 문장들을 확인할 수 있고, 내 SQL문을 찾으면, sql_id 값을 확인할 수 있습니다.

sql_id 는 다른 toad 나 orange 같은 툴에서도 쉽게 확인할 수 있습니다. 툴에서 나오는 sql_id 와 같은 것이기 때문에 그걸 사용해도 됩니다.

 

Realtime SQL Monitoring 은 디폴트로 5초 이상 수행된 SQL에 대해 위와같은 정보를 가지고 있습니다.

따라서 5초 이내로 수행된 SQL 들은 위와같이 조회해도 sql_id 값을 찾을 수 없습니다.

5초 이내의 SQL 이라도 특정 SQL 에 대해 모니터링하고자 하는 경우는 SQL에 /*+ monitor */ 힌트를 주면 됩니다.

 

또, sys 나 system 유저가 아닌 일반 DB유저 (예, scott) 에서 report_sql_monitor() 함수를 실행하고자 하는 경우는 에러가 발생합니다. 이때는 해당 유저에 권한부여가 필요합니다.   ( 참조 => 모니터링 권한부여 )

 

 

▶ 참고) Realtime SQL Monitoring 으로 Plan 그래픽컬하게 보기

 

+ Recent posts