All Days 무한도전

로드밸런싱 (Load Balancing)

하나의 시스템을 운영하다 보면 다양한 종류의 애플리케이션들이 실행됩니다. 대용량의 데이터가 변경되는 오퍼레이션, 한달간 발생한 매출정보를 집계하는 마감작업, 소량의 데이터를 검색하는 오퍼레이션 등, 그 종류는 매우 다양할 것 입니다.

하지만, 처리하려고 하는 데이터의 양과 작업시간에 따라 각각의 오퍼레이션에 소요되는 시스템의 메모리와 CPU 사용시간 등은 제각각 틀릴 것입니다. 문제점은 이러한 오퍼레이션들이 다른 시간대에 따로 수행된다면 문제가 없겠지만, 같은 시간대에 동시에 발생한다면 시스템의 자원(메모리, CPU, 디스크 등) 문제로 인해 원할한 작업이 이루어지지 않을 것 입니다. 많은 데이터를 처리해야 하고 많은 시간이 소요되는 작업은 보다 많은 시스템 자원을 사용하려 할 것이기 때문입니다. 이런 경우, 대부분의 해결방법은 시스템에서 발생하는 작업들을 분석하여 시스템의 자원을 골고루 사용할 수 있도록 분배해 주는 방법일 것 입니다. 이러한 기능을 해주는 대표적인 소프트웨어를 미들웨어라고 말 합니다.

오라클 데이터베이스에서는 시스템이 여러 대인 경우 하나의 시스템이 아닌 여러 대의 시스템으로 작업을 분산시킬 수 있는 로드밸런싱 기능을 다음과 같이 제공해 줍니다.

TNSNAMES,ORA 파일에 [LOAD_BALANCE = ON] 절을 정의하면, 첫 번째 리스너 프로세스에게 접속을 요청할 때 만약 BUSY 한 상태라면 접속을 거부하고 두 번째 정의된 리스너 프로세스에게 작업을 넘기게 됩니다. 즉, 정의된 리스너 프로세스 중 여유 있는 프로세스에게 작업을 넘겨서 전체적인 로드밸런싱을 유지하게 되는 것 입니다.

[FAILOVER] 절은 여러 대의 시스템을 사용하다 보면 시스템이 사용 가능한 상태가 아닌 경우도 발생합니다. 이런 경우가 발생하면 FAILOVER 기능에 의해 두 번째 정의된 리스너 프로세스에게 작업을 넘기게 됩니다. 메인 서버와 백업서버가 존재하는 네트워크 환경에서 메 인 서버에 문제가 발생하는 경우 사용자들도 모르게 자동으로 백업서버로 연결해야 하는 경우에도 적용할 수 있습니다.

[ADDRESS_LIST] 절에 정의되는 첫 번째 ADDRESS 조건은 처음에 요청할 리스너 프로세스에 대한 정보이고, 두 번째 ADDRESS 절은 로드밸런싱 또는 FAILOVER 기능에 의해 요청되는 리스
너 프로세스에 대한 정보를 정의합니다.

물론, 이 기능은 하나의 시스템에 여러 개의 데이터베이스가 설치되어 있는 환경에서도 적용할 수 있습니다.

자원 관리자 (Resource Manager)

데이터베이스 사용자는 자신이 처리하는 어떤 작업이 시스템의 자원(CPU, 메모리, 디스크 크기, 네트워크)을 얼마만큼 사용하고 있는지를 알지 못하며 또한 어떤 작업을 하기 위해 데이터베이스에 접속할 때 자신이 할당 받게 될 시스템의 자원이 얼마나 될 것인지를 아는 사용자는 거의 없을 것입니다. 데이터베이스 자원 관리자는 사용자가 처리하는 업무의 성격에 따라 CPU와 시스템의 자원을 차별적으로 사용할 수 있는 방법을 제공 해 줍니다.

예를 들어, ABC 회사에서는 고객에게 정보를 제공해주는 업무가 가장 중요한 일이라면OLTP(Online-Transaction Processing) 업무를 처리하는 사용자에게는 더 많은 시스템 자원을 할당해 주고 DSS(Discussion Support System) 업무와 유지보수(MAINTENANCE) 업무를 처리하는 사용자에게는 보다 작은 시스템 자원을 할당해야 할 것입니다. 즉, 보다 중요한 일을 처리하는 사용자에게 원할한 작업을 위해 시스템 자원을 충분하게 할당해 주고 그렇지 못한 사용자에게는 최소한의 자원을 할당해 주는 방법입니다.

구성요소

데이터베이스 자원 관리자는 다음과 같이 3가지 구성요소로 만들어집니다. 자원 소비자 그룹(RESOURCE CONSUMER GROUP)은 유사한 업무를 처리하는 데이터베이스 사용자(마감작업 또는 통계 분석작업 등)나 요구하는 시스템의 자원이 비슷한 업무(온라인 업무 또는 배치 업무)를 처리하는 사용자들의 그룹을 의미합니다.

자원사용 계획(RESOURCE PLANS)은 자원 소비자 그룹에게 할당해줄 시스템의 자원사용에 대한 계획명을 의미합니다.
마지막으로, 자원사용계획 다이렉티브(RESOURCE PLANS DIRECTIVES)는 자원사용 계획에 대한 구체적인 계획을 의미합니다.

생성 방법

다음 예제는 BATCH 업무 사용자를 위한 자원사용 계획을 생성하는 절차입니다.
자원사용자 그룹명은 "BATCH"이고 자원사원 계획은 "NIGHT"이며 CPU를 100% 사용할 수 있도록 하고 병렬처리를 위해 20개의 프로세스를 사용할 수 있는 자원사용 계획을 세우는 절차입니다. 자원 관리자는 다음의 5단계 과정으로 설정할 수 있습니다.

자원계획을 실행하는 사용자는 데이터베이스 관리자로 부터 자원계획을 생성할 수 있는 권한(ADMINISTER_RESOURCE_MANAGER 권한)을 부여받아야 만 사용할 수 있습니다. SCOTT 사용자에게 자원계획을 생성할 수 있는 권한을 부여하되 SCOTT 사용자가 다시 이 권한을 다른 사용자에게는 부여할 수는 없습니다.

먼저, 자원계획을 저장할 데이터베이스 공간을 할당해야 합니다.(이 작업은 한번만 실행하면 됩니다.) 공간할당이 끝나면 자원소비자 그룹 "BATCH"를 생성하십시오. COMMENT라는 인수를 통해 해당 자원 소비자그룹에 대한 주석을 작성하십시오.

다음은 자원 사용계획을 생성합니다. 새롭게 생성되는 자원계획은 ①에서 생성한 저장공간에 저장됩니다.

자원사용 다이렉티브를 생성 해 보십시오. CPU를 100% 사용할 수 있도록 하고 병렬처리를 위해 20개의 프로세스를 사용할 수 있는 자원사용 계획을 작성하십시오.

지금까지 작성한 자원계획이 제대로 작성되었는지 검증을 해 보십시오. 패키지를 실행하면 자원 소비자 그룹과 자원계획이 제대로 작성되었는지 검증해 줍니다.
또한, 작성된 자원사용계획을 저장공간에 저장하십시오.

자원 소비자 그룹을 사용자에게 부여합니다.
SCOTT은 자원 소비자 그룹의 사용자를 의미하며 'BATCH'는 자원 소비자 그룹을 의미합니다. 그리고, FALSE는 SCOTT 사용자가 자신이 받은 자원계획의 사용권한을 다른 사용자에게 부여하지 못함을 의미합니다.

자 ~ 지금까지 데이터베이스 자원사용계획과 그룹을 생성해 보았습니다. 이제부터는 자원 사용계획을 활성화시켜 특정 사용자가 처리하는 트랜잭션이 설정된 자원사용 계획에 의해 처리될 수 있도록 해 줍니다. 데이터베이스 전체 환경에서 설정할 수도 있고 특정 세션에서만 적용할 수도 있습니다. 다음은 데이터베이스 전체 환경에서 설정하는 방법입니다.
INIT<DB명>.ORA 파일에 자원사용 계획명을 정의하십시오.

RESOURCE_MANAGER_PLAN = NIGHT (NIGHT는 자원계획명 입니다.)

다음은 특정 세션에서만 적용하는 방법입니다.

SQL> ALTER SESSION SET RESOURCE_MANAGER_PLAN = NIGHT; (NIGHT는 자원계획명 입니다.)

기타 자원 사용 계획

자원 관리자(RESOURCE MANAGER) 기능은 오라클 이전 버전부터 제공되던 프로파일(시스템의 Resource를 제한하는 기능) 기능에 대한 보다 향상된 기능이며 오라클 8i 버전부터 소개되었지만 CPU 사용과 Parallel Query Process에 대한 시스템 자원만 사용할 수 있었습니다.
오라클 9i 버전에서는 이 기능 이외에 Active Session Pool 과 Undo(Rollback) Segment에 대한 자원계획을 추가하게 되었습니다. CPU와 병렬처리에 대한 자원 사용계획은 이미 소개되었으므로 오라클 9i에서 추가된 자원계획을 알아보도록 하겠습니다.

Active Session Pool

자원 소비자 그룹마다 동시에 접속할 수 있는 세션 수를 제한할 때 사용합니다.
기본적으로 ACTIVE_SESS_POOL_P1의 값은 1000000 이며 너무 많은 세션이 발생하면 큐(Queue)에서 접속을 위해서 대기하게 되는데 대기시간을 지정하는 파라메터는 Queueing이며
기본 값은 1000000입니다.

UNDO Segment

특정 사용자가 데이터베이스 내에서 사용하게 될 Undo(Rollback) Space에 대한 자원사용을 제한할 때 사용합니다. 기본 UNDO_POOL의 값은 1000000이며 Kilobytes 단위로 표시합니다.

AUTOMATIC CONSUMER GROUPING SWITCHING

정의된 시간이 지나면 특정 사용자의 자원소비자 그룹을 다른 소비자 그룹으로 자동으로 스위칭 해 줍니다.

MAXIMUM ESTIMATED EXECUTION TIME

실행될 SQL문을 실행하기 전에 실행시간을 분석한 다음 너무 오래 걸릴 것 같으면 SQL문을 실행시키지 않습니다.

자 ~ 다음 예제를 따라 해 보십시오

먼저, 데이터베이스 사용자는 Resource Manager를 사용할 수 있는 권한이 있어야 한다.

System Rersource에 대한 Plan을 저장할 영역을 할당하십시오.

Consumer Group을 생성하십시오.

Consumer Group에 지정할 자원사용 계획명을 생성하십시오.

생성된 자원사용 계획명에 실제 계획을 작성하십시오.

할당된 Pending 영역에 작성된 자원사용 계획이 유효한지 검증해 보십시오.

자원사용 계획을 데이터베이스에 저장하십시오

공유 서버 프로세스

하나의 사용자 프로세스마다 하나씩 할당되는 서버 프로세스를 전용서버 프로세스라고 한다면 여러 개의 사용자 프로세스에게 하나의 서버 프로세스가 할당되는 환경을 공유서버 프로세스라고 합니다.

일반적으로, 전용서버 프로세스는 마감작업, 통계 분석작업, 전산관리 업무 등과 같은 배치성 작업이나 데이터베이스의 유지보수 작업(STARTUP, SHUTDOWN, BACKUP & RECOVERY 작업)을 수행하는 사용자에게 적합하고 공유서버 프로세스는 간단한 입력, 수정, 삭제, 조회 등의 일상적인 작업처리 업무를 수행하는 사용자들에게 적합합니다. 만약, 마감작업을 처리하는 사용자가 공유서버 프로세스로 접속하여 SQL문을 처리한다면 작업 성능은 매우 늦어질 것입니다.

반대로, 한 건의 행을 입력하는 사용자가 전용서버로 접속하여 작업을 처리한다면 성능은 빨라지겠지만 메모리의 낭비가 될 것입니다. 오라클 데이터베이스를 설치하면 기본적인 모드는 전용서버 프로세스 환경입니다. 공유서버 프로세스를 사용하기 위해서는 별도의 환경설정이 필요하며, 환경설정 후에는 공유서버 프로세스와 전용서버 프로세스를 동시에 사용할 수 있습니다. 그럼, 공유서버 프로세스의 환경 설정하는 방법과 처리과정에 대해서 자세히 알아봅시다.

먼저, 공유서버 프로세스를 사용하기 위해서 필요한 기타 프로세스와 구조체를 알아봅시다. 위 그림에서 보시는 것처럼, 공유서버 프로세스(SHARED SERVER), 리스너 프로세스(LISTEN ER1), 디스패쳐 프로세스(DISPATCHER1, DISPATCHER2, DISPATCHER3)가 필요하고 SGA 영역에는 요청 큐(REQUEST QUEUE), 응답 큐(RESPONSE QUEUE)가 필요합니다. 그럼, 각 프로세스와 구조체가 어떤 기능을 하는지 처리과정을 통해 알아보겠습니다.

사용자가 리스너 프로세스에게 데이터베이스 접속을 요청합니다.

리스너 프로세스는 현재 활동 중인 디스패쳐 프로세스를 검사합니다.

분석된 디스패쳐 프로세스의 상태정보를 저장한 다음 그 중에 가장 적게 작업을 처리하는
디스패쳐 프로세스의 주소를 사용자에게 리턴해 줍니다.

사용자는 리스너 프로세스로부터 받은 디스패쳐 프로세스의 주소를 이용하여 해당 디스패쳐 프로세스에 접속한 다음 SQL문의 실행을 요구합니다.

디스패쳐 프로세스는 사용자의 요구사항(데이터베이스 접속, SQL문의 실행)을 요청 큐에 저장합니다.

공유서버 프로세스 중에 가장 적게 작업을 처리하고 있는 프로세스가 요청 큐로부터 사용자의 요구사항을 읽어옵니다.

공유서버 프로세스는 작업을 처리한 후 디스패쳐 프로세스가 활성화될 때 각각 만들진 해당 응답 큐에 작업결과를 저장합니다.

해당 디스패쳐 프로세스는 자신의 응답 큐로부터 결과를 읽어와서 ⑩ 사용자에게 리턴해 주면 모든 작업은 완료됩니다.

지금까지, 공유서버 프로세스를 통해 사용자의 작업이 어떻게 처리되는지 알아보았습니다.
이제부터, 각 프로세스를 활성화하기 위한 환경설정 방법을 알아보도록 하겠습니다.

이 프로세스들을 활성화하기 위해서는 INIT<DB명>.ORA 파일에 다음과 같은 파라메터를 추가하셔야 합니다.

[DISPATCHERS]에는 데이터베이스를 시작(STARTUP)했을 때 최초 할당될 디스패쳐 프로세스의 수와 프로토콜을 정의하십시오.(기본값은 5개입니다)

[MAX_DISPATCHER]는 [MTS_DISPATCHERS] 파라메터에 의해 사용 중인 디스패쳐 프로세스들이 현재 접속한 모든 사용자들의 작업을 원활하게 처리해 줄 수 없을 때 지정한 개수만큼 추가적으로 디스패쳐 프로세스를 활성화 해줍니다.

[SHARED_SERVERS]는 데이터베이스를 시작(STARTUP)했을 때 최초 할당될 공유서버 프로세스의 수를 정의하십시오.

[MAX_SHARED_SERVERS]는 [MTS_SERVERS] 파라메터에 의해 사용 중인 공유서버 프로세스들이 현재 접속한 모든 사용자들의 작업을 원활하게 처리해 줄 수 없을 때 지정한 개수만큼 추가적으로 공유서버 프로세스를 활성화 해줍니다.(기본값은 20입니다.)

[SHARED_SERVER_SESSIONS]는 할당된 전체 공유서버가 동시에 오픈할 수 있는 세션 수를 의미합니다.

공유서버 프로세스와 디스패쳐 프로세스에 대한 환경설정이 완료되었으면 데이터베이스를 재 시작해야 합니다. 그리고, 각 프로세스와 큐 구조들이 생성되었는지 확인해 보십시오.
먼저, V$SHARED_SERVERS 자료사전을 참조해 보면 MTS_SERVERS 파라메터에 의해 활성화 되어 있는 공유서버 프로세스를 확인할 수 있을 것입니다. 공유서버 프로세스의 이름은 S000부터 Snnn 형태로 생성됩니다.

V$DISPATCHER 자료사전을 참조해 보면 MTS_DISPATCHERS 파라메터에 의해 활성화 되어있는 디스패쳐 프로세스들을 확인할 수 있을 것입니다. 디스패쳐 프로세스의 이름은 D000부터 Dnnn 형태로 생성됩니다.

마지막으로, V$QUEUE 자료사전을 참조해 보면 요청 큐와 각 디스패쳐 프로세스의 응답 큐를 확인할 수 있습니다. PADDR 컬럼의 값이 0은 REQUEST 큐에 대한 정보이고 TYPE 컬럼의 값이 DISPATCHER는 RESPONSE 큐에 대한 정보입니다. 공유서버 환경에서 REQUEST 큐의 개수는 한 개이고 RESPONSE 큐의 개수는 디스패쳐 프로세스 부 만큼 생성됩니다.

공유 서버 프로세스 환경의 튜닝

공유서버 프로세스가 주로 사용될 수 있는 환경은 많은 사용자가 동시에 데이터베이스에 접속하며 소량의 데이터를 처리하는 OLTP(Online Transaction Process) 업무에 가장 적합합니다. 공유서버 프로세스 환경에는 디스패쳐 프로세스, 공유서버 프로세스, RESPONSE 큐와 같은 프로세스들이 필요한데 시스템에서 시용할 수 있는 개수는 항상 제한적입니다.

만약, 동시에 많은 사용자들이 데이터베이스에 접속하게 되면 제한된 프로세스를 서로 나누어서 사용해야 하기 때문에 하나의 프로세스에 대해 경합현상이 발생하게 됩니다.
경합현상이 발생하게 되면 대기상태가 일어나게 되고 결국 성능이 저하되는 문제가 발생하게 되는 것 입니다. 공유서버 환경에서 경합이 발생할 수 있는 부분은 3가지 포인트가 있습니다.

첫 번째 부분은, 사용자가 접속을 요구했을 때 디스패쳐 프로세스가 부족하여 발생하는 경합문제 입니다. 하나의 디스패쳐가 처리할 수 있는 작업의 범위는 제한되어 있습니다. 그리고, 디스패쳐 프로세스의 최대 개수도 제한되어 있습니다. 동시에 많은 사용자가 데이터베이스에 접속을 요구하고 SQL문의 실행을 요구한다면 서로 디스패쳐 프로세스를 사용하기 위해 경합을 벌이게 될 것 입니다. 즉, 성능이 저하될 수 있다는 의미입니다.
이런 경우에는 디스패쳐 프로세스에 경합이 발생하는지를 분석한 다음 보다 많은 디스패쳐 프로세스 수를 늘려주어야 경합을 최소화할 수 있고 궁극적으로 성능을 향상 시킬 수 있습니다. 다음은 디스패쳐 프로세스에 경합이 발생하는지를 분석하는 방법입니다.

<- 만약, , sum(busy) / (sum(busy + sum(idle) 의 비율이 0.5 를 초과한다면 디스패쳐 프로세스에 경합이 발생한 것이며 성능이 저하될 수 있음을 의미합니다.

이런 경우에는 다음과 같이 디스패쳐 프로세스의 수를 보다 많이 할당해 주어야 합니다.

두 번째 부분은 사용자의 요구를 받은 디스패쳐 프로세스가 REQUEST 큐에 요청된 내용을 저장한 후 공유서버 프로세스에 의해 처리되면 RESPONSE 큐에서 결과를 가져오게 됩니다.

그런데, 디스패쳐 프로세스가 너무 많은 일들을 처리하다 보면 이미 처리가 되어 RESPONSE 큐에 저장되어 있는 결과를 읽어서 사용자 프로세스에게 돌려주지 못하여 RESPONSE 큐에 결과가 쌓이는 현상이 발생하게 됩니다. 즉, 디스패쳐 프로세스 수가 부족하여 대기상태가 발생하는 경우입니다,

이런 경우에는 디스패쳐 프로세스와 RESPONSE 큐 간의 대기상태를 분석한 다음 보다 많은 디스패쳐 프로세스 수를 늘려주어야 성능을 향상 시킬 수 있습니다. 다음은 디스패쳐 프로세스와 RESPONSE 큐 간의 대기상태를 분석하는 방법입니다.

<- 만약, sum(wait) / sum(totalq) 결과가 0 값이면 RESPONSE 큐에 대기중인 처리결과가 없다는 의미이며 이 결과값이 계속적으로 증가한다면 처리결과가 계속 쌓이고 있다는 의미입니다. 즉, 디스패쳐 프로세스의 수가 부족하여 성능이 저하될 수 있습니다.

이런 경우에도 첫 번째 경우의 조치방법과 같이 디스패쳐 프로세스의 수를 보다 많이 할당해 주어야 합니다.

세 번째 부분은 디스패쳐 프로세스들에 의해 요청된 내용이 REQUEST 큐에 저장되면 작업이 가능한 공유서버 프로세스가 요청된 내용을 처리하게 됩니다. 만약, 활성화된 공유서버 프로세스들 중에 여유가 있는 프로세스가 없다면 REQUEST 큐에는 요청된 작업 내용들이 쌓이게 될 것이고 SQL문의 성능은 저하될 것입니다.

이런 경우에는 공유서버 프로세스의 경합상태를 분석한 다음 보다 많은 공유서버 프로세스 수를 늘려주어야 성능을 향상 시킬 수 있습니다. 다음은 공유서버 프로세스의 경합상태를 분석하는 방법입니다.

<- 만약, count(*)의 결과가 mts_servers 파라메터에 설정된 값보다 커지 않다면 공유서버 프로세스에는 경합이 발생하고 있지 않은 것을 의미하며, mts_max_servers 파라메터에 설정된 값과 같은 결과가 나타나면 경합이 발생하고 있는 것 입니다. 즉, 공유서버 프로세스의 수가 부족하여 성능이 저하될 수 있습니다.

이런 경우에는 다음과 같이 공유서버 프로세스의 수를 보다 많이 할당해 주어야 합니다.

다음 예제는 REQUEST 큐에 얼마나 많은 요청된 내용이 쌓여 있는지를 분석하는 방법입니다.

<- 만약, wait / totalq 결과가 0 값이면 REQUEST 큐에 대기중인 요청내용이 없다는 의미이며 이 결과값이 계속적으로 증가한다면 요청내용이 계속 쌓이고 있다는 의미입니다. 즉, 공유서버 프로세스의 수가 부족하여 성능이 저하될 수 있습니다.

Pre-Spawn 서버 프로세스

전용서버 프로세스는 개발자가 클라이언트로부터 데이터베이스에 접속하는 순간 리스너 프로세스에 의해 할당됩니다. 이렇게 개발자의 요구가 있을 때 마다 리스너 프로세스가 하나씩 활성화되게 되는데 이런 유형을 스판 전용서버 프로세스(SPAWN DEDICATED SERVER PROCESS)라고 합니다. 문제점은 대용량 데이터베이스 환경에서 많은 사용자들이 동시에 데이터베이스에 접속을 요구하게 되면 하나의 리스너 프로세스가 필요할 때 마다 서버 프로세스를 활성화시켜야 하기 때문에 접속할 때 일시적으로 대기상태가 발생할 수도 있습니다.
즉, 데이터베이스에 접속할 때 성능이 저하될 수 있다는 의미입니다.

이런 문제를 해결하기 위해서는 여러가지 네트워크 솔루션들이 사용될 수 있지만 가장 기본적인 방법은 프리스판 전용서버 프로세스(PRE-SPAWN DEDICATED SERVER PROCESS)를 활성화하는 방법입니다. 스판 전용서버 프로세스가 필요할 때 마다 프로세스를 활성화하는 방법이라면 프리스판 전용서버 프로세스는 미리 여러 개의 프로세스를 활성화시킨 다음 새로운 접속이 요구될 때마다 미리 활성화 해둔 프리스판 전용서버 프로세스를 할당해 주는 방법입니다.
즉, 데이터베이스에 접속을 요구하면 미리 준비된 프로세스를 연결 만 시켜주면 되기 때문에 데이터베이스 접속이 빨라집니다.( 이 기능은 오라클 8i 버전까지 사용가능 합니다.)

위 그림의 오퍼레이션 절차를 보다 자세히 알아 봅시다.

LISTENER.ORA 파일에 프리스판 전용서버 프로세스를 활성화하기 위한 환경설정을 한 다음 리스너 프로세스를 시작합니다. 만약, 3개의 프리스판 프로세스를 활성화 시켰다면
운영체계 상에 프로세스들을 확인할 수 있을 것 입니다

다음 예제는 LISTENER.ORA 파일에 프리스판 전용서버 프로세스를 위한 환경설정 방법입니다.(DB명은 ORA90이라고 가정합니다)

$ cd $TNS_ADMIN

$ vi listener.ora

LISTENER=

(ADDRESS_LIST =

(ADDRESS = (PROTOCOL = TCP)(Host = 192.9.200.1)(Port = 1521))

)

SID_LIST_LISTENER =

(SID_LIST =

(SID_DESC =

(ORACLE_HOME=/export/home/dbaxx)

(SID_NAME = ORA90)

)

)

:wq!

리스너를 다시 재 시작하여 프리스판 프로세스를 활성화 하십시오.

$ cd $TNS_ADMIN

$ lsnrct| stop LISTENER

$ lsnrct| start LISTENER

LSNRCTL for Solaris : Version 9.0.1.0.0 - Production on 27-JUL-99 17:37:53

(c) Copyright 1997 Oracle Corporation. All rights reserved.

(ADDRESS=(PROTOCOL=tcp)(DEV=12)(HOST=XXX.XXX.XXX)(PORT=80xx))

Connected to (ADDRESS=(PROTOCOL=TCP)(Host=192.9.200.1)(Port 1521))

STATUS of the LISTENER

----------------------

Alias LISTENER

……………………

Services Summary…

LISTENER has 1 service handler(s)

The command completed successfully

자~ 정말 프리스판 전용서버 프로세스가 활성화되었는지 확인해 봅시다.

<- 각 프로세스 상태를 확인해 보면 "COMMAND=prespawn" 이라는 상태값을 확인할 수 있을 것 입니다.

프리스판 전용서버 프로세스가 활성화 되었다면 이제 데이터베이스에 접속해 보도록 하겠습니다.

$ sqlplus scott/tiger@ora816

SQL*PLUS 툴을 이용해 데이터베이스에 접속을 요구하면, 먼저 사용자 프로세스가 활성화됩니다. 그리고, 사용자 프로세스는 호스트 스트링이 의미하는 네트워크 환경정보를 통해 데이터베이스가 있는 서버의 리스너에게 접속을 요구하게 됩니다.

리스너 프로세스는 현재 활성화되어 있는 프리스판 전용서버 프로세스 중에서 하나의 프로세스 주소를 읽어 옵니다.

프리스판 전용서버 프로세스의 주소를 사용자 프로세스에게 알려 줍니다.

접속할 프로세스의 주소를 넘겨받은 사용자 프로세스는 할당 받은 전용서버 프로세스에게 개발자가 실행한 SQL문의 실행을 요청합니다.

프리스판 전용서버 프로세스는 사용자 프로세스로부터 요청 받은 SQL문을 분석한 다음 실행합니다.

리스너 프로세스는 방금 하나의 프리스판 전용서버 프로세스가 사용되었으므로 필요한 개수만큼 활성화시켜 놓습니다.