커넥션과 서버 프로세스의 생성

애플리케이션에서의 접속을 배워야하는 이유

애플리케이션에서의 접속을 최적화하는 것만으로도 DB의 성능을 끌어올릴 수 있고, 애플리케이션에서 피해야만 하는 코딩 방식을 이해하는 데도 도움이 되기 때문이다. 오라클은 애플리케이션 서버를 사용한 시스템이나 클라이언트/서버 형태의 시스템에서도 많이 사용되고 있다. 즉 오라클과 '오라클을 사용하는 애플리케이션'이 같은 서버 위에 있는 경우는 드물며, 애플리케이션과 오라클이 네트워크를 통해 통신하는 경우가 많다. 그래서 접속 설정으로 인한 장애가 쉽게 발생할 수 있다.

 

오라클의 접속 동작

오라클은 TCP/IP의 소켓을 네트워크 통신 수단으로 사용하고 있다. 소켓을 사용하면 마치 전화처럼 다른 장비에 있는 프로그램과 통신할 수 있으며, 장비 안에는 프로그램이 동작하고 있고(프로세스), 그 프로그램이 수화기에 해당한다. 한번 소켓을 만들어두면 소켓을 읽고 쓰기만 해도 송수신을 구현할 수 있으므로 프로세스 측면에서 보면 편리한 기능이다.

네트워크의 드라이버와 OS의 라이브러리가 송수신을 수행하며, 네트워크 안에는 여러 개의 소켓이 존재한다. 소켓은 주소와 포트의 번호 조합으로 식별할 수 있으며 아래 그림과 같이 동작한다. 

위 그림에서 중요한 부분은 연락이 오기만을 기다리고 있는 프로세스가 존재한다는 점과 연결을 할 때는 송싱 측에서 주소와 포트를 반드시 지정해야 한다는 점이다.

오라클에서 소켓의 동작

오라클에서 소켓을 사용하고 있는데, 수신을 기다리는 프로세스를 리스너라고 부른다.(서버 프로세스가 아니다) 리스너로 접속하려는 프로세스는 업무 애플리케이션의 프로세스이다. 

 

커넥션 처리 1: 리스너 기동

리스너는 창고 회사 오라클의 접수 데스크로 비유할 수 있다. listener.ora 파일은 접수 데스크가 가지고 있는 '회사 대표 번호' 및 '내전 전화번호부'이며, 하나의 리스너는 여러 개의 DB에 안내할 수 있지만 일반적으로는 하나의 리스너가 하나의 DB를 담당한다. 리스너는 자신이 listen해야 할 포트 번호 등을 listener.ora 파일에서 읽어 시작한다. 오라클은 기본적으로 1521 포트번호를 사용하지만 다른 번호를 사용해도 상관없다. 리스너는 lsnrctl이라는 도구를 사용해서 리스너를 기동한다. 리스너가 자신이 안내해야 할 DB를 인식하는 방법으로는 listener.ora 파일에 기록되어 있는 설정 파일을 읽거나, DB가 자동으로 등록하는 방법이 있는데 일반적으로는 사용이 간단한 자동 등록을 선택해서 사용한다.

 

커넥션 처리 2: 애플리케이션의 커넥션

업무 애플리케이션 안에서 연결하기 위한 명령이 실행되거나, SQL*Plus에서 connect 명령어를 실행한 순간 DB에 연결이 된다. 먼저 DB에 연결할 때 필요한 정보를 오라클 클라이언트에 전달 할 필요가 있으며, 그 정보를 '커넥션 디스크립터'라고 한다. 이 안에는 '주소는 XXX이며, 포트가 XXX이고, 서비스 이름이 XXXX' 같은 정보가 포함되어 있다. 연결할 때마다 정보를 입력할 수는 없으므로, 일반적으로 tnsnames.ora에 커넥션 디스크립터를 작성해놓고 커넥션 식별자를 커넥션 디스크립터마다 붙인다. 즉 오라클 클라이언트는 tnsnames.ora의 커넥션 디스크립터 정보를 사용해서 리스너와 클라이언트 사이에 소켓을 생성하고, 리스너에게 '이 DB와 통신하고 싶어'라고 연락한다. 

tnsnames.ora의 예제

커넥션 처리 3: 서버 프로세스의 생성

마지막 과정은 서버 프로세스를 생성하고 소켓을 인계받는 것이다. 소켓을 생성하면 리스너가 그대로 SQL 처리를 해도 될 것처럼 보이지만, 한번 SQL 처리를 시작하면 요청받은 SQL을 처리하느라 다른 처리를 사용할 수 없게 되므로 전담 영업 담당자인 서버 프로세스를 생성해서 SQL 처리를 즉시 인계한다.

서버 프로세스의 생성은 큰 작업인데, 먼저 OS상에서 프로세스를 생성해야 하며(메모리 확보), 서버 프로세스가 사용할 수 있는 공유 메모리를 확보해야 한다. 또한, 서버 프로세스용 전용 메모리(PGA)도 확보해야 한다. 그 외에 DB 내부의 처리도 여러가지가 남아있다. 따라서 서버 프로세스를 한번 생성하는데는 가벼운 SQL문을 처리할 때 사용하는 CPU 시간보다 몇 배에서 몇십 배 많은 CPU 시간을 사용한다. 리스너는 서버 프로세스 생성이 끝나면 소켓을 서버 프로세스에 인계한다.

클라이언트에서 사용되는 일반적인 OLTP 시스템의 대부분은 간결한 SQL문으로 이루어져 있으며, 접속 처리에 비하면 매우 짧은 시간만 사용하고 끝나는 경우가 많다. OLTP란 On-Line Transaction Processing의 약어로, 호스트 컴퓨터와 온라인으로 접속된 여러 단말 간의 처리 형태의 하나로 여러 단말에서 보내온 메세지에 따라 호스트 컴퓨터가 DB에 액세스하고, 바로 처리 결과를 돌려보내는 형태를 말한다. 따라서 커넥션을 생성하는 작업은 무거운 처리라는 것을 알 수 있다.

 

접속 동작의 확인

tnsnames.ora 파일을 사용하지 않으면 커넥션 디스크립터를 직접 작성해서 연결해야 한다.

- tnsnames.ora 파일을 사용하지 않고 접속할 때

SQL > connect scott/tiger@(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = XXXX)(PORT = 1521))(CONNECT_DATE = (SERVER = DEDICATED)(SERVICE_NAME = orcl)))

 

- tnsnames.ora 파일을 상요해서 접속할 때

SQL > connect scott/tiger@ORA18C

 

tnsnames.ora

========================================

(DESCRIPTION = 

   (ADDRESS = (PROTOCOL = TCP)(HOST = XXXX)(PORT = 1521))

   (CONNECT_DATE = 

      (SERVER = DEDICATED)

      (SERVICE_NAME = orcl)

)

========================================

 

- EZCONNECT를 사용해 접속할 때

SQL > connect scott/tiger@XXXX:1521/orcl

 

- tnsnames.ora 파일에 해당하는 데이터가 없을 때

 

ORA-12154 : TNS:could not resolve the connect identifier specified

접속을 시도했지만 에러가 발생한 경우

1. 리스너가 기동하지 않았을 떄 -> ORA-12541: TNS: no listener

2. 리스너가 가진 DB의 정보와 일치하지 않을 때 -> ORA-12512: TNS:listener does not currently know of service requested in connect descriptor

 

정지나 리스너의 상태 확인

일반적으로 애플리케이션에서 접속을 종료하는 처리(close, disconnect)를 수행하면 서버 프로세스도 함께 종료된다. 리스너는 lsnrctl의 stop 명령어를 사용해 정지할 수 있으며, status 명령어로 현재 리스너의 기동 상태나 listene하고 있는 포트의 번호, 보유하고 있는 DB 정보 등을 알 수 있다. 

오라클은 대부분의 환경에서 TCP/IP를 사용하고 있으므로 TCP/IP에서 에러가 반환되지 않으면 오라클은 문제가 있다는 것을 눈치 못챌 수 있다. 따라서 다음 명령어를 통해 접속을 끊고 Lock을 해제하던가 인스턴스를 재기동하여 대처한다.

alter system kill session ...;

 

성능을 개선하기 위해서

커넥션을 맺는것과 서버 프로세스를 생성하는 것은 오라클에게는 무거운 작업이다. 따라서 '병렬 처리를 가능하게 하고 높은 처리량'을 지키면서 개선하는 방법으로 힌트는 '현실의 실제 시스템에서 서버 프로세스는 긴 시간 동안 아무 것도 하지 않는다'라는 점이다. 수십, 수백 개의 서버 프로세스가 가동 중인 시스템도 드물지는 않지만, 대부분은 서버 프로세스는 일부만이 SQL을 처리하고 있다. 또 클라이언트와 일대일로 대응하여 서버 프로세스가 존재하고 있는 이상, 서버 프로세스의 수를 줄이는 것은 곤란할 수 있다.(애플리케이션 수를 줄인다)

효율을 높이기 위한 방법 중 하나로 여러 서버 프로세스가 여러 클라이언트의 SQL을 처리할 수 있도록 하는 방법이 있다. 서버 프로세스 몇 개를 풀로 구성해두고 여러 애플리케이션이 자신이 쓰고 싶을 때만 풀에서 하나를 꺼내 사용하는 구조로 사용하면 대부분이 대기 상태이던 서버 프로세스의 가동률을 높일 수 있다. 이 구성을 위해 오라클의 '공유 서버 구성'이나 '커넥션 풀'이라고 불리는 구성을 사용할 수 있다.

 

 

참고

- https://it-mesung.tistory.com/5

커넥션과 서버 프로세스의 생성

- https://loosie.tistory.com/506

[DB/ Oracle] 오라클 동작과정을 이해해보자 (애플리케이션과 오라클의 커넥션)