[Oracle] Chapter 12. 오라클 아키텍처와 동작에 관한 Q&A

12.1 지금까지의 복습

디스크에 접근하기 위한 오버헤드는 앞서 이야기했던 것처럼 '첫머리를 찾는 것'에 해당하는 탐색이 가장 크게 점유하고 있으며, 메모리에 접근하는 속도에 비해 매우 느리다.

 

SQL 처리를 위해 디스크에서 읽어오는 작업은 차치하고라도, 버퍼 캐시에서 디스크로 데이터를 기록하는 작업까지 서버 프로세스가 담당하게 하면 SQL의 응답 시간이 떨어지기 떄문에 바람직하지 않다. 이러한 몆 가지 작업은 서버 프로세스 이외의 백그라운드 프로세스(오라클을 사용하는 환경이 윈도우라면 프로세스가 아니라 스레드 구성이다. 따라서 윈도우에서 오라클을 사용한다면 앞으로 나오는 프로세스를 스레드라고 바꿔서 읽자.)가 담당한다. 프로세스의 역활을 나눈 원칙은 'SQL의 결과를 가져오는 데 필요한 작업은 서버 프로세스가 수행하고, 그 이외는 백그라운드 프로세스가 수행한다'이다.

 

오라클에는 '대기 이벤트(wait event)'라는 개념이 있다. 대기 이벤트라고 하면 인상이 좋아 보이지는 않지만, 실제로 '대기(wait)'라는 것은 단순히 기다리고 있는 상태를 나타낼 뿐이다. 또한, 대기 이벤트를 간단히 이야기하면 '기다리고 있는 일'이다. 기다리는 것으로 인해 SQL의 처리가 늦어지는 일도 많이 발생하지만, 실제로 대기는 다음과 같이 세 가지로 나누어진다.

 

- 처리할 것이 없어서 쉬고 있는 대기

- 이유가 있어 어쩔 수 없이 하는 대기

- 이상한 상태 등 쓸데없이 SQL을 기다리게 하는 대기

 

쉬고 있는 대기를 'Idle'이라고 말하며, 디스크 I/O를 기다리는 대기 등을 'Non-Idle 대기'라고 부른다. SQL의 처리를 튜닝한다는 관점에서는 'Non-Idle 대기 + SQL 처리에 걸리는 CPU 시간'이 SQL을 처리하는 시간이라 할 수 있다.

 

Non-Idle 대기 이벤트 중 가장 유멍한 것은 Lock 이다. Lock의 본질은 '다중 처리를 구현하기 위해 작업 중인 처리를 보호하는 장치'이다. 따라서 Lock이 걸려 있는 시간을 줄이거나, Lock을 걸고 있는 프로세스의 처리가 진행되지 않는 이유를 조사하고 원인을 제거할 필요가 있다. 일반적인 대기 개선 방법은 대기하고 있는 원인을 제거하거나, Lock을 획득하는 횟수를 줄여 전체 시간을 최소화하는 형태를 고려해볼 만하다. 다만, Lock 대기가 많다고 해서 세션 수를 줄이는 형태로 튜닝해도 크게 개선되지 않는 경우가 많다. 세션 수를 줄이더라도 '큐(queue)가 생기는 위치가 Lock 대기가 아닌 다른 곳'이 되는 일이 많기 떄문이다.

 

12.2 오라클의 동작에 관한 질문

 

Q1. I/O 의 지연이 발생하면 오라클은 어떻게 되는가?

일반적인 OLTP 시스템에서 I/O에 지연이 발생했다고 가정해보자. 이때 오라클은 어떤 상황이 되며, 어떤 동작을 할까? 그리고 어떻게 조사를 해야 할까? 할 수 있다면 배치 시스템에서의 상황도 생각해보자.

 

A1. 오라클 시스템(서버)에서 I/O가 지연되었으니 오라클의 처리도 지연된다. 비유해보자면 은행 창구의 처리(I/O 처리)가 느려진 상태이다. 고객의 수가 평소와 같다 해도 일 처리를 느릿느릿하게 한다면, 고객(오라클)이 줄을 서서(큐가 만들어져) 기다리는 상황을 상상할 수 있을 것이다. OLTP 시스템에서는 오라클에도 대기열(큐)이 발생하며, 쉬고(idle) 있지 않는 세션수(특히 I/O 대기)의 형태로 나타난다.

 

조사하는 방법으로는 오라클의 AWR, 스태츠팩이나 OS의 I/O 정보에 표시되는 I/O 1회의 시간, v$session_wait에서 확인할 수 있는 I/O 관련 대기 이벤트의 수, 유닉스는 vmstat에서의 b 컬럼(디스크 I/O)를 대기하는 프로세스 수)을 조사하면 된다. 단, DBWR이나 LGWR의 I/O 지연은 I/O에 대기열(큐)이 생기지 않는다. 서버 프로세스가 DBWR이나 LGWR의 I/O 처리를 기다리는 것이므로 서버 프로세스의 대기 이벤트(예: log file sync)가 대량으로 발생하는 것을 통해 DBWR이나 LGWR의 I/O 지연을 확인할 수 있다.

 

◆ 배치 시스템에서 I/O의 지연을 조사하기 위해서는?

배치 시스템은 OLTP와 동작이 다르다. 그 이유는 동시에 발생하는 작업 요청의 수가 한정되어 있기 때문이다. 예를 들면, 한 번에 대량 처리를 의뢰하는 소수의 고객만을 전담하여 운영하는 은행이라고 생각하시면 된다. 고객들의 요청을 일대일로 맡아 처리해주는 전담 창구가 있으므로 처리하는 데 시간이 길어져도 뒤에서 기다리는 고객이 없는 모습을 떠올려보자. 하지만 창구의 업무 처리가 늦어지면 고객이 요청한 처리가 끝나는 시간도 늦어질 수밖에 없다. 이러한 지연을 조사하는 방법으로는 오라클의 AWR, 스태츠팩이나 OS의 I/O 정보에 표시되는 1회의 I/O에 걸린 시간을 조사하면 된다. 대기열(큐)이 만들어지진 않으므로 v$session_wait에서 대기 이벤트 수를 조사하거나 vmstat의 b 컬럼을 조사하는 것만으로는 확인하기가 어렵다. 

 

◆ I/O 관련 대기 이벤트에는 어떤 것이 있는가?

I/O 관련 대기 이벤트에는 'db file sequential read(싱글 블록 I/O)'나 'db file scattered read(멀티 블록 I/O)' 이외에도 여러 가지가 있다. 예를 들어, 'read by other session(다른 세션이 읽어오는 중이므로 대기)'나 'write complete waits(기록하고 있으므로 대기)', 'buffer busy waits(블록 사용 중)'의 일부와 'free buffer waits(빈 버퍼가 부족하다)'의 대부분 그리고 'log file sync(REDO 로그 기록을 대기)'의 대부분의 경우가 I/O 관련 대기이다.

 

Q2. 네트워크에서 지연이 발생하면 오라클은 어떻게 되는가?

일반적인 OLTP 시스템에서 네트워크의 어딘가에 지연이 발생했다고 가정하겠다. 오라클은 어떤 상황이 되며, 어떤 동작을 할까? 조사할 방법도 포함해서 생각해보자.

 

A2. 오라클의 관점에서는 네트워크에 지연이 발생해서 작업 요청이 도착하지 않았을 때는 처리할 작업이 없는 것처럼 보인다. 이를 조사하기 위한 방법으로는 '애플리케이션 측면에서 봣을 때는 요청을 보냈지만, v$session을 사용해서 데이터베이스를 확인해보니 작업 요청이 아직 도착하지 않았다'는 상황을 직접 확인하거나, 패킷 캡처 도구를 이용해서 패킷의 송수신을 직접 보는 방법을 추천한다. 하지만 패킷 캡처 도구를 사용할 때는 OS나 네트워크에 부담을 주지 않도록 주의를 기울려라.

 

Q3. OS에서 지연이 발생하면 오라클은 어떻게 되는가?

일반적인 OLTP 시스템에서 OS의 어딘가에 지연(예를 들면, CPU 부족)이 발생했다고 가정해보자. 오라클은 어떤 동작을 할까? 그리고 그런 문제는 어떤 방식으로 조사해야 할까?

 

A3. 일반적인 OLTP 시스템에서 OS의 어딘가에서 지연(예를 들면, CPU 부족)이 발생하면, 전체적으로 처리하는 속도가 느려진다. 기본적으로 처리의 전반적인 부분들이 느려지므로 마치 '슬로우 모션'으로 움직이는 것 같아 보인다. 또한, OLTP 시스템에서는 당연히 대기열이 발생하지만, 어디에 대기열이 생길지는 알 수 없다. 사례로 보면 'latch free'라는 오라클 내부의 Lock을 가진 대기 이벤트의 형태로 나타나는 일이 많다. 

 

이런 상황을 조사하기 위해서는 OS 측의 정보를 사용해 조사하는 것이 좋다. 유닉스라면 vmstat, sar(CPU의 사용률 등을 조사할 수 있는 도구)등을 사용할 수 있으며, 윈도우라면 성능 모니터를 사용할 수 있을 것이다.

 

Q4. 테스트할 때 오라클에 과도한 부하를 주면 어떻게 되는가?

오라클이 과부하가 걸리기 전이라면 오라클 안에 부자연스러운 대기는 없으며, 도착한 SQl을 거의 즉시 처리해서 되돌려주는 상태일 것이다. 지금까지의 설명에서 알 수 있듯이, 과부하 상태가 되면 주로 오라클 내부에서 대기열이 생기며, 애플리케이션의 응답 시간이 악화된다.

 

이런 상황을 조사하기 위해서는 OS의 정보, I/O의 정보, v$session_wait 등에서 대기열이 생기지 않았는지를 확인하는 방법이 있다. 또는 커넥션 수를 줄이는 방법 등으로 가능한 부하를 줄인 후 각 처리에 걸리는 시간의 변화를 조사하는 방법도 있다. 이는 부하 상태가 해소되면 대기열로 인해 쓸데없이 기다리는 시간이 없어지기 때문이다. 만약 이렇게 조치해서 처리 시간이 짧아졌다면, 과부하가 원인이었을 가능성이 크다고 말할 수 있다.