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

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

애플리케이션의 커넥션을 왜 배워야 하는가?

- 애플리케이션의 커넥션을 최적화 하는 것만으로도 DB의 성능을 더욱 끌어올릴 수 있음.
- 애플리케이션과 오라클이 네트워크를 통해서 통신하는 경우가 많음
    - 그로인해 설정으로 인한 장애가 쉽게 발생하며, 간단한 장애일 때는 아키텍처를 이해할 시 쉽게 해결할 수 있음

오라클의 커넥션 동작 - 소켓

- 오라클은 네트워크 통신 수단으로서 대부분 TCP/IP의 소켓을 사용
    - 소켓을 전화라고 생각하면 이해하기 쉬움
- 네트워크 안에는 여러개의 소켓이 존재함
    - 틀리지 않고 커넥션 하기 위해서 소켓은 주소와 포트를 조합한 번호로 식별이 가능

[커넥션 동작]
1. 서버는 특정 포트번호로 오는 것을 기다림(listen 상태)
2. 클라이언트는 커넥션 하고 싶은 상대의 IP 주소와 포트 번호를 향해 송신
3. 서버는 클라이언트의 요청에 응답

소켓의 동작 원리

- TCP/IP 소켓은 클라이언트 소켓과 서버 소켓(IP주소와 포트번호를 갖고 있음)으로 이루어져 있음.
- 클라이언트 소켓
    1. 처음 소켓을 생성(create)
    2. 서버 측에 연결을 요청(IP 주소와 포트번호를 확인 후 요청)
    3. 서버 소켓에서 연결을 수락 시 데이터 송수신(send/recv)
    4. 모든 처리 완료 시 소켓 닫음(close)
- 서버 소켓
    1. 처음 소켓을 생성(create)
    2. 서버가 사용할 IP 주소와 포트 번호를 생성한 소켓에 결합(bind)
    3. 클라이언트로부터 연결요청이 수신되는지 주시(listen) - listen의 리턴값은 SUCCESS || ERROR
    4. 요청 수신 시 요쳥을 받아들여(accept) 데이터 통신을 위한 소켓을 생성
    5. 데이터 통신을 위한 소켓이 생성되면 클라이언트와 데이터를 송수신(send/recv)
    6. 데이터 송수신 완료 시 소켓을 닫음(close)

오라클에서 소켓의 동작

1. 리스너 : 오라클에서 수신을 기다리는 프로세스
    - 리스너는 listner.ora에서 자신이 listen해야할 포트번호(보통 1521)를 확인 후 listen을 진행
2. 애플리케이션 프로세스 : 리스너로 커넥션 하는 프로세스
    - tnsnames.ora파일을 확인하여 커넥션 디스크립터(DB서버 주소나 리스너의 포트번호, 서비스 이름)을 확인
    - 커넥션 디스크립터를 오라클 클라이언트에게 전달
    - 오라클 클라이언트는 커넥션 디스크립터를 활용해서 애플리케이션 프로세스와 리스너 사이에 소켓을 생성하고, 리스너에게 이 DB와 통신하고 싶다라는 연락을 취함
3. 서버 프로세스
    - 소켓을 생성하면 리스너는 서버 프로세스를 생성해서 소켓을 서버 프로세스에게 전달하고 모든 처리를 인계함
        - 이유는? 한번 SQL을 처리하면 다른 처리를 진행할 수 없으므로.. 리스너는 할 일이 많나봐
    - 서버 프로세스는 공유 메모리도 사용하고 메모리도 확보하고 DB 내부의 처리도 해야함
    - 서버 프로세스는 오랜 시간동안 CPU를 사용

각 프로세스의 정지나 리스너의 상태 확인

- 애플리케이션에서 접속을 종료하면 서버 프로세스도 종료됨
- 리스너는 lsnrctl 명령어를 사용하여 정지
- lsnrctl의 status 명령어로 리스너의 가동 상태나 listen 하고 있는 포트 번호, 유지하고 있는 DB 정보를 알 수 있음

좀 더 성능을 개선하려면

- 서버 프로세스는 SQL을 처리하기 위해 DB와 커넥션하는데 최초 커넥션 할 시 시간이 매우 오래 걸림.
- 그로 인해, 서버 프로세스 몇 개를 풀로 사용하게 만들어 두고 여러 애플리케이션이 자신이 쓰고 싶을 때만 풀에서 하나를 꺼내 사용한다는 구조를 이용 - 커넥션 풀
- 이때, 애플리케이션은 풀에서 커넥션을 가져다 쓰고 다시 풀에 반납해야 함 - but, 커넥션이 열려있는 상태로 반납! why? 다른 애플리케이션도 써야하니깐!

정리