네트워크에서의 대기 이벤트들

 

- 네트워크 관련 대기 이벤트들

1) SQL*Net message from/to client

2) SQL*Net more data from/to client

3) SQL*Net message from/to dblink

4) SQL*Net more data from/to dblink

이들 이벤트가 성능문제가 연관되는 경우는 네트워크 속도가 느린 경우, SQL 실행횟수가 불필요하게 높은 경우, 어플리케이션의 구현방식에 문제가 있는 경우이다.

 

 

- 네트워크 속도가 느린 경우

만일 위 이벤트를 대기하는 시간이 불필요하게 높다면 네트워크 속도를 의심해볼 수 있다. 클라이언트와 DBMS 간의 문제가 있다면 1번과 2번의 문제이며, DBMS와 DBMS간의 네트워크 문제가 있다면 3번과 4번에 대한 대기시간이 증가할 수 있다. 이 경우 시스템 관리자와 협의하여 네트워크 레이어를 검증해야 한다. 만약 RAC 환경에서 GC와 관련된 평균 대기시간이 지나치게 높게 나온다면, 마찬가지로 네트워크 성능을 점검해볼 필요가 있다. RAC에서 네트워크 문제가 있을 경우 이것이 성능 문제로 직결된다. 네트워크 속도와 스위치 장비의 설정이 적절하게 되어있는지 확인해야한다.

 

 

- SQL 실행횟수가 불필요하게 높은 경우

실행 횟수가 과다한 경우 클라이언트와 DBMS 간의 네트워크 통신이 빈번하게 이루어져야 하고, 이로 인하여 네트워크 관련 대기 시간이 증가할 수 있다. 이 경우 오라클은 클라이언트로부터 응답이 오기를 대기해야 하므로 SQL*Net message from client 또는 SQL*Net more data from client 이벤트를 대기하게 된다. 특히, 정체 대기 시간 중 SQL*Net more data from client가 어느 정도 비중 있는 대기 시간을 차지한다면 불필요한 실행횟수에 의한 시스템 성능 저하를 의심해보아야 한다. 클라이언트 관점에서의 실행 횟수가 많은 경우에는 네트워크 통신에 따른 대기 시간으로 인해 사용자가 느끼는 응답시간이 크게 저하될 수 있다. 이 경우 PL/SQL 등을 이용해 작업을 처리하고, 어레이 프로세싱을 사용해서 DBMS 콜을 줄이는 방안을 모색해야한다.

 

 

- 어플리케이션의 구현 방식에 문제가 있는 경우

DBMS와 접속을 유지한 채 불필요하게 대기하는 시간이 많다면 SQL*Net message from client 대기 시간이 높게 나올 수 있다. 사용자 입장에서는 마치 어플리케이션의 응답속도가 느린 것처럼 보일 수 있다.

가령 어플리케이션이 오라클에서 한 건의 데이터를 가져온 다음 복잡한 계산을 수행하고, 다시 오라클에서 한 건의 데이터를 가져온 다음 또 다른 일을 하는 방식으로 구현되어 있다면 오라클 관점에서는 아무런 성능문제가 발견되지 않지, 사용자 입장에서는 시스템이 매우 느린 것으로 느껴지게 된다. 만일 사용자 관점에서 응답시간이 느린 데도 오라클에서 어떤 성능문제도 발견할 수 없다면 비효율적인 어플리케이션 작동방식이 원인일 수도 있다는 가능성을 열어 두어야 한다.