[Oracle 구조] 6. 커넥션과 서버 프로세스의 생성

📌 6장에서는 SQL을 처리하기 위해 애플리케이션에서 오라클로의 커넥션을 맺는 것에 관한 전반적인 내용과 서버 프로세스의 생성에 관해 살펴봅니다.

 

6.1 | 애플리케이션에서의 접속을 왜 배워야 하는가?

· 애플리케이션에서 접속을 최적화하는 것만으로도 데이터베이스의 성능을 더욱 끌어올릴 수 있고, 애플리케이션에서 피해야만 하는 코딩 방식을 이해하는 데 도움이 되기 때문

· 접속 설정으로 인한 장애가 쉽게 발생하지만, 애플리케이션 접속을 포함한 아키텍처를 이해하고 있다면 대부분 쉽게 해결할 수 있음 

·  오라클은 애플리케이션 서버를  사용한 시스템이나 클라이언트/서버 형태의 시스템에서도 많이 사용되고 있음. 즉 오라클과 '오라클을 사용하는 애플리케이션'이 같은 서버위에 있는 경우는 드물며, 애플리케이션(오라클 클라이언트)과 오라클이 네트워크를 통해서 통신하는 경우가 많음.

 

 

6.2 | 오라클의 접속 동작

6.2.1 소켓의 동작 이미지

· 오라클은 TCP/IP의 소켓(socket)을 네트워크 통신 수단으로 사용하고 있음

·  소켓을 사용하면 마치 전화처럼 다른 장비에 있는 프로그램과 통신할 수 있음. 장비 안에는 프로그램(프로세스)이 작동하고 있고,  그 프로그램이 수화기에 해당하는 소켓을 가지고 있는 모습을 머릿속에서 그려주면 됨

· 소켓은 '주소(address)'와 '포트(port) 번호'라고 불리는 번호의 조합으로 식별할 수 있으며 연락이 오기만을 기다리는 프로세스가 존재하며 연결할 때는 송신 측에서 '주소'와 '기다리고 있는 포트'를 반드시 지정해야 함

·  네트워크의 드라이버와 OS의 라이브러리가 송수신을 수행하며, 네트워크 안에는 여러 소켓이 존재

 

6.2.2 오라클에서 소켓의 동작

· 오라클에서는 수신을 기다리는 프로세스를 '리스너(lisnter)'라고 부름

· 리스너로 접속하려는 프로세스는 업무 애플리케이션의 프로세스임

 

6.2.3 커넥션 처리 ① : 리스너 기동

① DB서버에서 리스너는 '오라클의 접수 데스크'이며, listner.ora 파일에서 자신이 listen해야 할 포트 번호 등을 확인 한뒤 listen을 시작함

② 애플리케이션의 프로세스는 tnsnames.ora 파일을 확인해서 리스너의 주소나 포트 번호, 서비스 이름 등을 확인함. 확인한 내용을 사용해서 연결(커넥션)을 확립시킴

③ DB서버에서 소켓이 확립되면 서버 프로세스를 생성하며, 소켓은 서버 프로세스에게 전달해줌

· 오라클은 리스너의 포트 번호 '1521'을 사용하지만, 다른 애플리케이션과 충돌 발생 시 다른 번호를 사용

· 리스너가 자신이 안내해야 하는 데이터베이스를 인식하는 방법은 listener.ora 파일에 기록된 설정을 읽거나, 데이터베이스가 자동으로 등록하는 방법이 있음. 일반적으로는 후자(DB가 자동 등록)를 사용

 

6.2.4 커넥션 처리 ② : 애플리케이션에서의 커넥션

· 애플리케이션 안에서 연결하기 위한 명령이 실행되거나, SQL*Plus에서 connect 명령어를 실행한 순간에 DB에 연결됨  

· DB에 연결할 때 필요한 정보를 오라클 클라이언트에 전달할 필요가 있으며, 그 정보를 '커넥션 디스크럽터(connection descriptor)'라고 부름. 커넥션 디스크립터 안에는 '주소', '포트', '서비스 이름' 같은 정보가 포함되어 있음

·연결 시마다 정보를 입력할 순 없으므로 tnsnames.ora에 커넥션 디스크립터를 작성해놓고 커넥션 식별자(별칭)를 커넥션 디스크립터마다 붙임. 그래서 연결할 때는 해당 커넥션 식별자를 오라클 클라이언트에 전달하기만 하면 됨. 이를 전화로 비유하면 '단축 다이얼'임

· 오라클 클라이언트는 tnsnames.ora의 커넥션 디스크립터 정보를 사용하여 리스너와 클라이언트 사이에 소켓을 생성하고, 리스너에게 '이 데이터베이스와 통신하고 싶어'라고 연락함

 

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

· 마지막 과정은 서버 프로세스를 생성하고 소켓을 인계받는 것 

· 리스너가 SQL을 처리하게 되면 다른 처리(수신)를 할 수 없게 되므로, 서버 프로세스를 생성해서 SQL 처리를 즉시 인계함

· 서버 프로세스 생성은 OS상에서의 프로세스 생성, 공유 메모리와 서버 프로세스용 전용 메모리(PGA) 확보, 메모리 공간을 오라클용으로 초기화, SGA에 접근할 수 있도록 각종 설정을 수행, 파라미터를 읽어오거나 초기화를 위한 SQL 수행 등 큰 작업임

· 리스너가 인계한 후부터 서버 프로세스와 오라클 클라이언트는 직접 송수신하므로 리스너는 자유로워짐

 

 

6.3 | 접속 동작의 확인

6.3.1 tnsnames.ora 파일을 사용하지 않으면 어떻게 되는가?

· 빈번하게 접속해야하는 환경이라면 tnsnames.ora 파일을 사용하는 것이 좋음

· tnsnames.ora 파일에 해당하는 데이터가 없는 경우 "TNS:could not resolve the connect identifier specified" = 기술된 커넥션 식별자를 알 수 없다(tnsnames.ora 파일에서 찾을 수 없다)라는 메시지가 출력됨

 

6.3.2 데이터베이스 서버의 동작

· tnsnames.ora 파일은 정상적이나 리스너가 기동하지 않는 경우도 있으며, 아래의 경우를 확인해봐야 함

[ 데이터베이스에 접속하지 못할 때 확인해볼 만한 실수들 ]

1. 접속할 호스트명(IP)을 잘못 입력한 경우 → tnsnames.ora 파일의 호스트 IP 확인

2. tnsnames.ora가 올바르지 않은 경로에 위치하는 경우 → ORACLE_HOME/network/admin 경로의 파일을 확인

3. tnsnames.ora에 정의된 내용과 다른 커넥션 식별자를 사용하여 접속 시도 → 커넥션 식별자가 tnsnames.ora에 존재하는지 확인

4. 리스너가 기동되어 있지 않음 → 접속할 호스트의 리스너가 기동되어 있는지 여부를 확인

5. 리스너에 서비스명을 등록하지 않음 → 리스너 기동 후 1분 정도 기다리거나, DB에서 서비스명 등록 명령어 실행

 

 

6.4 | 정지나 리스너의 상태 확인

· 리스너 정지 명령어 "lsnrctl stop"

· 리스너 상태 확인 명령어 "lsnrctl status"

 

 

6.5 | 성능을 개선하기 위해서는?

· 서버 프로세스는 한번 SQL 처리를 시작하면 끝날 때 까지 다른 작업을 하지 않음. 따라서, 병렬 처리를 가능케 하기 위해선 효율을 높여야 함

· 효율을 높이기 위한 방법 중 하나로, 서버 프로세스 몇 개를 풀로 구성해두고 여러 애플리케이션이 자신이 쓰고 싶을 때만 풀에서 하나를 꺼내 사용. 이는 즉, 오라클의 '공유 서버 구성'이나 '커넥션 풀(연결 풀)' 이라고 불리우는 구성임

 

 

6.6 | 요약

· 데이터베이스에 접속하기 위해서는 데이터베이스 서버의 주소와 리스너의 포트 번호가 필요

· tnsnames.ora라는 파일 안에 접속하기 위한 정보를 기록

· 리스너라고 하는 프로세스가 접속 요청을 받으며, 서버 프로세스의 생성도 같이 수행

· listner.ora라는 파일 안에 리스너의 설정(포트 번호)등을 기록

· 서버 프로세스의 생성은 매우 무거운 작업이므로 가능하면 줄이는 것이 좋음