응용 프로그램 및 Oracle Net Services 구조

이 장에서는 응용 프로그램 구조를 정의하고 분산 처리 환경에서 Oracle 데이터베이스 및 데이터베이스 응용 프로그램의 작동 방식을 설명합니다. 이 자료는 거의 모든 유형의 Oracle AI Database 환경에 적용됩니다.

Oracle Application Architecture 개요

이 장의 컨텍스트에서 응용 프로그램 구조는 데이터베이스 응용 프로그램이 Oracle 데이터베이스에 연결하는 컴퓨팅 환경을 나타냅니다.

클라이언트/서버 구조 개요

Oracle AI Database 환경에서는 데이터베이스 애플리케이션과 데이터베이스가 클라이언트/서버 아키텍처로 구분됩니다.

구성 요소는 다음과 같습니다.

클라이언트 응용 프로그램 및 데이터베이스가 동일한 컴퓨터에서 실행될 수 있지만 네트워크를 통해 연결된 여러 컴퓨터에서 클라이언트 부분 및 서버 부분을 실행할 때 효율성을 높일 수 있습니다. 다음 절에서는 Oracle AI Database 클라이언트/서버 아키텍처의 변형에 대해 설명합니다.

분산 처리

여러 호스트를 사용하여 개별 작업을 처리하는 것을 분산 처리라고 합니다.

프런트 엔드 및 백 엔드 처리는 다른 컴퓨터에서 발생합니다. 그림 19-1에서 클라이언트와 서버는 Oracle Net Services를 통해 연결된 여러 호스트에 있습니다.

그림 1: 클라이언트/서버 아키텍처 및 분산 처리

그림 cncpt083.gif에 대한 설명

그림 19-2는 분산 데이터베이스를 나타내는 변형입니다. 이 예제에서 한 호스트의 데이터베이스는 다른 호스트에 있는 별도의 데이터베이스에 있는 데이터에 액세스합니다.

그림 2: 클라이언트/서버 아키텍처 및 분산 데이터베이스

그림 cncpt240.gif에 대한 설명

주: 이 장의 나머지 부분은 한 서버에 하나의 데이터베이스가 있는 환경에 적용됩니다.

클라이언트/서버 구조의 장점

분산 처리 환경의 Oracle AI Database 클라이언트/서버 아키텍처는 여러 가지 이점을 제공합니다.

주요 이점:

참조: 분산 데이터베이스에 대한 자세한 내용은 Oracle AI Database Administrator's Guide를 참조하십시오.

다계층 구조 개요

기존의 다계층 구조에서 Application Server는 클라이언트에 데이터를 제공하고 클라이언트와 데이터베이스 서버 간의 인터페이스 역할을 합니다.

이 구조에서는 Application Server를 사용하여 다음 작업을 수행할 수 있습니다.

다계층 구조의 예는 Figure 19-3에 나와 있습니다.

그림 3: 다계층 아키텍처 환경

그림 cncpt121.gif에 대한 설명

클라이언트

클라이언트가 데이터베이스 서버에서 수행할 작업에 대한 요청을 시작합니다.

클라이언트는 웹 브라우저 또는 다른 일반 유저 프로그램일 수 있습니다. 다계층 구조에서 클라이언트는 하나 이상의 Application Server를 통해 데이터베이스 서버에 연결합니다.

애플리케이션 서버

Application Server는 클라이언트의 데이터에 대한 액세스를 제공합니다. 클라이언트와 하나 이상의 데이터베이스 서버 간의 인터페이스 역할을 하며 응용 프로그램을 호스팅합니다.

응용 프로그램 서버는 최소한의 소프트웨어 구성이 장착된 클라이언트인 Thin 클라이언트가 클라이언트 컴퓨터를 지속적으로 유지 관리할 필요 없이 응용 프로그램에 액세스할 수 있도록 허용합니다. 또한 응용 프로그램 서버는 클라이언트에 대한 데이터 재포맷을 수행하여 클라이언트 워크스테이션의 로드를 줄일 수 있습니다.

Application Server는 이 클라이언트에 대한 데이터베이스 서버에서 작업을 수행할 때 클라이언트의 ID를 가정합니다. 가장 좋은 방법은 클라이언트 작업 중에 불필요한 작업과 불필요한 작업을 수행하지 않도록 Application Server의 권한을 제한하는 것입니다.

데이터베이스 서버

데이터베이스 서버는 클라이언트 대신 Application Server가 요청한 데이터를 제공합니다. 데이터베이스가 Query 처리를 수행합니다.

데이터베이스 서버는 응용 프로그램 서버가 클라이언트를 대신하여 자체적으로 수행하는 작업을 감사(audit)할 수 있습니다. 예를 들어, 클라이언트 작업은 클라이언트에 표시할 정보를 요청할 수 있고, 응용 프로그램 서버 작업은 데이터베이스 서버에 대한 연결을 요청할 수 있습니다.

통합 감사에서 데이터베이스는 응용 프로그램별 이름-값 쌍인 응용 프로그램 컨텍스트를 통합 Audit Trail의 레코드에 추가할 수 있습니다. 데이터베이스가 데이터베이스 감사 레코드에 기록하는 응용 프로그램 컨텍스트를 구성할 수 있습니다.

참조: 감사 소개는 Oracle AI Database Security Guide를 참조하십시오.

SOA(Service-Oriented Architecture)

데이터베이스는 기존 다중 계층 또는 SOA(서비스 지향 구조) 환경에서 웹 서비스 공급자 역할을 할 수 있습니다.

SOA는 네트워크를 통한 컴퓨터 간 상호 작용을 지원하는 서비스에 의존하는 다계층 구조입니다. SOA 컨텍스트에서 서비스는 기능 및 서비스 레벨 계약이 잘 정의되어 있고 모니터링 및 관리가 가능하며 정책 준수를 적용하는 데 도움이 되는 자급자족 기능 엔드포인트입니다.

SOA 서비스는 일반적으로 HTTP 프로토콜을 통해 액세스할 수 있는 웹 서비스로 구현됩니다. WSDL 및 SOAP와 같은 XML 표준을 기반으로 합니다.

Oracle XML DB의 일부로 구현되는 Oracle AI Database 웹 서비스 기능은 DBA가 특별히 활성화해야 합니다. 그런 다음 응용 프로그램은 데이터베이스 웹 서비스를 통해 다음을 수행할 수 있습니다.

데이터베이스 웹 서비스는 응용 프로그램 서버 없이도 응용 프로그램 환경에 웹 서비스를 추가하는 간단한 방법을 제공합니다. 그러나 Oracle Fusion Middleware와 같은 응용 프로그램 서버를 통해 웹 서비스를 호출하면 SOA 환경에서 보안, 확장성, UDDI 등록 및 안정적인 메시징이 제공됩니다. 그러나 데이터베이스 웹 서비스는 Oracle Fusion Middleware와 쉽게 통합되기 때문에 SOA 솔루션을 최적화하는 데 적합할 수 있습니다.

참조:

그리드 구조 개요

Oracle AI Database 환경에서 그리드 컴퓨팅은 많은 수의 서버와 스토리지를 유연한 온디맨드 컴퓨팅 리소스로 효과적으로 풀링하는 컴퓨팅 아키텍처입니다.

모듈식 하드웨어 및 소프트웨어 구성 요소는 필요에 따라 연결 및 재결합하여 변화하는 비즈니스 요구 사항을 충족할 수 있습니다.

참조: 서버 및 저장소 그리드에 대한 자세한 내용은 Oracle Clusterware Administration and Deployment Guide를 참조하십시오.

Oracle Net Services 구조 개요

Oracle Net Services는 분산된 이기종 컴퓨팅 환경에서 전사적 연결 솔루션을 제공하는 네트워킹 구성 요소 제품군입니다.

Oracle Net Services를 사용하면 응용 프로그램에서 데이터베이스 인스턴스로의 네트워크 세션과 데이터베이스 인스턴스를 다른 데이터베이스 인스턴스로 전환할 수 있습니다.

Oracle Net Services는 위치 투명성, 중앙 집중식 구성 및 관리, 빠른 설치 및 구성을 제공합니다. 또한 시스템 리소스를 극대화하고 성능을 향상시킬 수 있습니다. 공유 서버 구조는 응용 프로그램의 확장성과 데이터베이스에 동시에 연결된 클라이언트 수를 늘립니다. 가상 인터페이스(VI) 프로토콜은 대부분의 메시징 부담을 고속 네트워크 하드웨어에 배치하여 CPU를 확보합니다.

Oracle Net Services는 분산 데이터베이스 및 분산 처리를 제공하기 위해 광범위한 네트워크에서 지원하는 통신 프로토콜 또는 응용 프로그램 방식 인터페이스(API)를 사용합니다. 네트워크 세션이 설정되면 Oracle Net Services는 연결 설정 및 유지 관리와 메시지 교환을 위해 클라이언트 응용 프로그램 및 데이터베이스 서버에 대한 데이터 통신업체 역할을 합니다. Oracle Net Services는 네트워크의 각 컴퓨터에 존재하므로 이러한 작업을 수행할 수 있습니다.

Oracle Net Services 작동 방식

Oracle AI Database 프로토콜은 Oracle 애플리케이션 인터페이스에서 SQL 문을 수락한 후 Oracle AI Database로 전송하도록 패키지화합니다.

전송은 지원되는 산업 표준 상위 레벨 프로토콜 또는 API를 통해 발생합니다. Oracle AI Database의 회신은 동일한 상위 레벨의 통신 메커니즘을 통해 패키지화됩니다. 이 작업은 네트워크 운영 체제와 독립적으로 수행됩니다.

Oracle AI Database를 실행하는 운영 체제에 따라 데이터베이스 서버의 Oracle Net Services 소프트웨어에 드라이버 소프트웨어가 포함되어 추가 백그라운드 프로세스를 시작할 수 있습니다.

참조: Oracle Net Services 작동 방식에 대한 자세한 내용은 Oracle AI Database Net Services Administrator's Guide를 참조하십시오.

Oracle Net Listener

Oracle Net Listener(리스너)는 들어오는 클라이언트 연결 요청을 수신하고 데이터베이스에 대한 트래픽을 관리하는 서버측 프로세스입니다. 데이터베이스 Instance가 시작될 때와 수명 중 여러 시기에 Instance는 리스너에 연결하여 이 Instance에 대한 통신 경로를 설정합니다.

서비스 등록을 통해 리스너는 데이터베이스 서비스와 해당 서비스 처리기의 사용 가능 여부를 확인할 수 있습니다. 서비스 처리기는 데이터베이스에 대한 연결 지점 역할을 하는 전용 서버 프로세스 또는 디스패처입니다. 등록 중에 LREG 프로세스는 리스너에 인스턴스 이름, 데이터베이스 서비스 이름, 서비스 처리기의 유형 및 주소를 제공합니다. 이 정보를 사용하면 클라이언트 요청이 도착하면 리스너가 서비스 처리기를 시작할 수 있습니다.

다음 그림은 각각 별도의 호스트에 있는 두 개의 데이터베이스를 보여줍니다. 데이터베이스 환경은 각각 별도의 호스트에 있는 두 개의 리스너에서 서비스를 제공합니다. 각 데이터베이스 Instance에서 실행되는 LREG 프로세스는 두 리스너와 통신하여 데이터베이스를 등록합니다.

그림 4: 두 개의 리스너

그림 cncpt315.png에 대한 설명

그림 19-5는 HTTP 연결을 설정하는 브라우저와 리스너를 통해 데이터베이스를 연결하는 클라이언트를 보여줍니다. 리스너가 데이터베이스 호스트에 상주할 필요는 없습니다.

그림 5: 리스너 구조

그림 cncpt311.gif에 대한 설명

클라이언트가 리스너를 통해 연결을 설정하는 기본 단계는 다음과 같습니다.

  1. 클라이언트 프로세스 또는 다른 데이터베이스가 연결을 요청합니다.

  2. 리스너는 적절한 서비스 처리기를 선택하여 클라이언트 요청을 처리하고 요청을 처리기로 전달합니다.

  3. 클라이언트 프로세스는 서비스 처리기에 직접 연결합니다. 리스너는 더 이상 통신에 관여하지 않습니다.

서비스명

서비스 이름은 클라이언트 연결에 사용되는 서비스의 논리적 표현입니다.

클라이언트가 리스너에 연결하면 서비스에 대한 연결을 요청합니다. 데이터베이스 Instance는 시작 시 자체적으로 리스너에 등록되어 이름으로 하나 이상의 서비스를 제공합니다. 따라서 리스너는 클라이언트와 Instance 간의 중개자 역할을 하며 연결 요청의 경로를 올바른 위치로 지정합니다.

리스너에 의해 알려진 단일 서비스는 하나 이상의 데이터베이스 Instance를 식별할 수 있습니다. 또한 단일 데이터베이스 Instance는 리스너에 하나 이상의 서비스를 등록할 수 있습니다. 서비스에 연결하는 클라이언트는 필요로 하는 Instance를 지정할 필요가 없으며 그림 19-6은 book.example.com 및 soft.example.com의 두 서비스와 연관된 단일 인스턴스 데이터베이스를 보여줍니다. 서비스를 통해 동일한 데이터베이스를 서로 다른 클라이언트에서 다르게 식별할 수 있습니다. 데이터베이스 관리자는 시스템 리소스를 제한하거나 예약할 수 있으므로 이러한 서비스 중 하나를 요청하는 클라이언트에 더 나은 리소스를 할당할 수 있습니다.

그림 6: 하나의 데이터베이스와 연결된 여러 서비스

그림 cncpt314.gif에 대한 설명

참조: 이름 지정 방법에 대한 자세한 내용은 Oracle AI Database Net Services Administrator's Guide를 참조하십시오.

멀티테넌트 환경의 서비스

클라이언트는 서비스를 사용하여 PDB 또는 응용 프로그램 루트에 연결해야 합니다.

서비스 이름을 사용하는 연결은 PDB 또는 응용 프로그램 루트에서 새 세션을 시작합니다. 포그라운드 프로세스, 따라서 세션의 수명 주기 동안 모든 순간에 고유하게 정의된 현재 컨테이너가 있습니다.

다음 그림은 두 개의 서로 다른 리스너를 사용하여 PDB에 연결하는 두 개의 클라이언트를 보여줍니다.

그림 7: CDB의 서비스

그림 cncpt368.png에 대한 설명

서비스 생성

CREATE PLUGGABLE DATABASE 문을 실행하여 PDB를 생성하면 데이터베이스가 자동으로 CDB 내에서 서비스를 생성하고 시작합니다.

기본 서비스에는 PDB를 서비스의 초기 현재 컨테이너로 식별하는 속성이 있습니다. 이 속성은 DBA_SERVICES.PDB 열에 표시됩니다.

기본 서비스

기본 서비스의 이름은 PDB와 동일합니다. PDB 이름은 적합한 서비스 이름이어야 하며 CDB 내에서 고유해야 합니다.

AS APPLICATION CONTAINER 절을 지정해야 하는 애플리케이션 컨테이너를 생성할 때 Oracle AI Database는 애플리케이션 루트에 대한 새 기본 서비스를 자동으로 생성합니다. 서비스의 이름은 애플리케이션 컨테이너와 동일합니다. 클라이언트가 이 서비스에 액세스하려면 Oracle Net Services를 올바르게 구성해야 합니다. 마찬가지로 모든 애플리케이션 PDB에는 고유의 기본 서비스 이름이 있고, 애플리케이션 시드 PDB에는 고유의 기본 서비스 이름이 있습니다.

예제 19-1 기본 서비스를 사용하여 PDB로 전환

이 예에서는 PDB와 이름이 동일한 기본 서비스를 사용하여 PDB 이름 salespdb로 전환합니다.

ALTER SESSION SET CONTAINER = salespdb;
비기본 서비스

각 PDB에 대해 최대 10,000개의 CDB당 추가 서비스를 생성할 수 있습니다. 각 추가 서비스는 해당 PDB를 초기 현재 컨테이너로 나타냅니다.

그림 19-7에는 erppdb 및 hrpdb에 대한 비기본 서비스가 있습니다. 예를 들어, 그림 19-7에서 hrpdb라는 PDB의 기본 서비스는 hrpdb입니다. 기본 서비스는 삭제할 수 없습니다.

ALTER SESSION SET CONTAINER를 사용하여 컨테이너로 전환할 때 세션은 컨테이너에 대한 기본 서비스를 사용합니다. 선택적으로 SERVICE = service_name를 지정하여 컨테이너에 대해 다른 서비스를 사용할 수 있습니다. 여기서 service_name은 서비스 이름입니다. 세션이 서비스 측정항목, 로드 균형 조정, Resource Manager 설정 등과 같은 서비스 속성 및 기능을 활용할 수 있도록 특정 서비스를 사용할 수 있습니다.

예 19-2 비기본 서비스를 사용하여 PDB로 전환

이 예에서 hrpdb에 대한 기본 서비스는 서비스 측정항목, FAN, 로드 밸런싱, Oracle AI Database Resource Manager, Transaction Guard, Application Continuity 등과 같은 모든 서비스 속성 및 기능을 지원하지 않습니다. 다음과 같이 비기본 서비스로 전환합니다.

ALTER SESSION SET CONTAINER = hrpdb SERVICE = hrpdb_full;

CDB의 컨테이너에 대한 연결

일반적으로 CDB 관리자는 PDB를 프로비저닝하고 다양한 컨테이너에 연결할 수 있는 적절한 권한을 가지고 있어야 합니다. CDB 관리자는 일반 사용자입니다.

CDB 관리자는 다음 기술 중 하나를 사용할 수 있습니다.

다음 표는 그림 19-7의 CDB와 관련된 시나리오를 설명합니다. 각 행은 이전 행의 작업 이후에 발생하는 작업을 설명합니다. 일반 사용자 SYSTEM는 현재 컨테이너의 이름과 CDB에 있는 PDB의 이름을 질의합니다.

CDB의 테이블 1 서비스

작업 설명 
SQL> CONNECT SYSTEM@prod
 Enter password: ********
 Connected.
 CDB의 모든 컨테이너에 공통되는 SYSTEM 사용자는 prod라는 서비스를 사용하여 루트에 연결합니다. 
SQL> SHOW CON_NAME

  CON_NAME
 --------
 CDB$ROOT
 SYSTEM는 SQL*Plus 명령 SHOW CON_NAME를 사용하여 사용자가 현재 접속되어 있는 컨테이너의 이름을 나열합니다. CDB$ROOT는 루트 컨테이너의 이름입니다. 
SQL> SELECT NAME, PDB FROM V$SERVICES
  2 ORDER BY PDB, NAME;

  NAME PDB
 ---------------------- --------
 SYS$BACKGROUND CDB$ROOT
 SYS$USERS CDB$ROOT
 prod.example.com CDB$ROOT
 erppdb.example.com ERPPDB
 erp.example.com ERPPDB
 hr.example.com HRPDB
 hrpdb.example.com HRPDB
 salespdb.example.com SALESPDB

  8 rows selected.
 V$SERVICES 질의는 서비스 이름이 PDB 이름과 일치하는 세 개의 PDB가 존재함을 보여줍니다. hrpdb 및 erppdb 모두 추가 서비스가 있습니다. 
SQL> ALTER SESSION SET CONTAINER = hrpdb;

  Session altered.
 SYSTEM는 ALTER SESSION를 사용하여 hrpdb에 접속합니다. 
SQL> SELECT SYS_CONTEXT
  2 ('USERENV', 'CON_NAME')
 3 AS CUR_CONTAINER FROM DUAL;

  CUR_CONTAINER
 -------------
 HRPDB
 질의는 현재 컨테이너가 현재 hrpdb임을 확인합니다.

참조: ALTER SESSION SET CONTAINER의 구문 및 의미는 Oracle AI Database SQL Language Reference

서비스 등록

Oracle Net에서 서비스 등록은 LREG 프로세스가 리스너에 인스턴스 정보를 동적으로 등록하는 기능입니다.

이 정보를 사용하여 리스너는 클라이언트 연결 요청을 해당 서비스 처리기로 전달할 수 있습니다. LREG는 리스너에 다음 정보를 제공합니다.

서비스 등록은 동적이며 listener.ora 파일에서 구성할 필요가 없습니다. 동적 등록을 수행하면 여러 데이터베이스 또는 인스턴스에 대한 관리 오버헤드가 줄어듭니다.

초기화 매개변수 SERVICE_NAMES는 인스턴스가 속한 서비스를 나열합니다. 시작 시 각 Instance는 동일한 서비스에 속하는 다른 Instance의 리스너에 등록합니다. 데이터베이스 작업 중에 각 서비스의 Instance는 CPU 사용 및 현재 연결 수에 대한 정보를 동일한 서비스의 모든 리스너에 전달합니다. 이 통신을 통해 동적 로드 밸런싱 및 연결 복구가 가능합니다.

참조:

전용 서버 구조

전용 서버 구조에서 각 클라이언트 프로세스 대신 생성된 서버 프로세스를 전용 서버 프로세스(또는 섀도우 프로세스)라고 합니다.

전용 서버 프로세스는 그림 19-8과 같이 클라이언트 프로세스와 별개이며 대신 작동합니다.

그림 8: 전용 서버 프로세스를 사용하는 Oracle AI Database

그림 cncpt303.gif에 대한 설명

클라이언트 프로세스와 서버 프로세스 사이에 일대일 비율이 있습니다. 유저가 능동적으로 데이터베이스 요청을 하지 않는 경우에도 전용 서버 프로세스는 비활성화되어 있고 일부 운영 체제에서 페이징 아웃할 수 있지만 그대로 유지됩니다. 그림 19-8에서는 네트워크로 연결된 컴퓨터에서 실행되는 사용자 및 서버 프로세스를 보여줍니다. 그러나 Dedicated Server 구조는 동일한 컴퓨터가 클라이언트 응용 프로그램과 데이터베이스 코드를 모두 실행하지만 두 프로그램이 단일 프로세스에서 실행된 경우 호스트 운영 체제에서 분리된 상태를 유지할 수 없는 경우에도 사용됩니다. Linux는 이러한 운영 체제의 예입니다.

전용 서버 구조에서 사용자 프로세스와 서버 프로세스는 다음 방식을 사용하여 통신합니다.

활용률이 낮은 전용 서버로 인해 운영 체제 리소스가 비효율적으로 사용되는 경우가 있습니다. 전용 서버 프로세스가 있는 주문 입력 시스템을 고려합니다. 고객은 담당 직원이 데이터베이스에 주문을 넣을 때 주문을 합니다. 대부분의 트랜잭션에서 담당 직원은 담당자의 클라이언트 프로세스 전용 서버 프로세스가 Idle 상태인 동안 고객과 통화하게 됩니다. 대부분의 트랜잭션 동안에는 서버 프로세스가 필요하지 않으며 시스템이 너무 많은 프로세스를 관리하는 경우 명령을 입력하는 다른 직원에게는 시스템이 느려질 수 있습니다. 이러한 유형의 응용 프로그램에는 Shared Server 구조가 바람직할 수 있습니다.

참조: 전용 서버 프로세스에 대한 자세한 내용은 Oracle AI Database Net Services Administrator's Guide를 참조하십시오.

Shared Server 구조

공유 서버 구조에서 디스패처는 여러 수신 네트워크 세션 요청을 Shared Server 프로세스 풀에 전달합니다.

공유 풀을 사용할 경우 각 연결에 대해 Dedicated Server 프로세스가 필요하지 않습니다. 풀에서 유휴 상태인 공유 서버 프로세스는 공통 대기열에서 요청을 가져옵니다.

Shared Server의 잠재적 이점은 다음과 같습니다.

Shared Server는 경우에 따라 응답 시간이 느려지는 경우, 불완전한 기능 지원, 설정 및 튜닝의 복잡성 증가 등 여러 가지 단점을 가지고 있습니다. 일반적으로 운영 체제보다 데이터베이스에 대한 동시 연결이 더 많은 경우에 공유 서버를 사용해야 합니다.

Shared Server 구조에는 다음 프로세스가 필요합니다.

데이터베이스는 Shared Server와 Dedicated Server 연결을 모두 동시에 지원할 수 있습니다. 예를 들어, 한 클라이언트는 전용 서버를 사용하여 연결할 수 있고 다른 클라이언트는 공유 서버를 사용하여 동일한 데이터베이스에 연결할 수 있습니다.

참조:

디스패처 요청 및 응답 대기열

유저의 요청은 유저의 SQL 문에 속하는 단일 API 호출입니다.

사용자가 전화를 걸면 다음 작업이 수행됩니다.

  1. 디스패처가 요청을 요청 대기열에 두면, 이 대기열은 사용 가능한 다음 공유 서버 프로세스에 의해 픽업됩니다.

    요청 대기열은 SGA에 있으며 인스턴스의 모든 디스패처 프로세스에 공통됩니다.

  2. Shared Server 프로세스는 Common Request Queue에서 새 요청을 확인한 후 First-in-first-out에 따라 새 요청을 선택합니다.

  3. 하나의 Shared Server 프로세스가 큐에서 하나의 요청을 선택하여 이 요청을 완료하는 데 필요한 모든 데이터베이스를 호출합니다.

    각 데이터베이스 호출은 서로 다른 서버 프로세스에서 처리할 수 있습니다. 따라서 query 구문 분석, 첫번째 행 패치(fetch), 다음 행 패치(fetch) 및 결과 집합 닫기 요청은 각각 다른 Shared Server에 의해 처리될 수 있습니다.

  4. 서버 프로세스는 요청을 완료하면 호출 중인 디스패처의 응답 대기열에 응답을 저장합니다. 각 디스패처에는 자체 응답 대기열이 있습니다.

  5. 디스패처가 완료된 요청을 해당 클라이언트 프로세스로 반환합니다.

예를 들어, 주문 입력 시스템에서 각 직원의 클라이언트 프로세스는 디스패처에 연결됩니다. 담당 직원이 요청한 각 요청은 이 디스패처로 전송되며, 이 디스패처는 요청을 대기열에 넣습니다. 사용 가능한 다음 공유 서버는 요청을 선택하여 서비스를 제공하고 응답을 응답 대기열에 넣습니다. 요청이 완료되면 담당 직원은 디스패처에 연결된 상태로 유지되지만 요청을 처리한 공유 서버는 해제되어 다른 요청에 사용할 수 있습니다. 한 명의 사원이 고객과 대화하는 동안 다른 사원이 동일한 Shared Server 프로세스를 사용할 수 있습니다. 그림 19-9에서는 API에서 클라이언트 프로세스가 디스패처와 통신하는 방법 및 디스패처가 사용자 요청을 공유 서버 프로세스로 전달하는 방법을 보여줍니다.

그림 9: 공유 서버 구성 및 프로세스

그림 cncpt067.gif에 대한 설명

디스패처 프로세스(D nnn)

디스패처 프로세스를 사용하면 클라이언트 프로세스가 제한된 수의 서버 프로세스를 공유할 수 있습니다.

단일 데이터베이스 Instance에 대해 여러 디스패처 프로세스를 생성할 수 있습니다. 운영 체제 제한 사항 및 각 프로세스에 대한 연결 수에 따라 디스패처 프로세스의 최적 수입니다.

주: 두 프로세스가 동일한 호스트에서 실행되는 경우에도 디스패처에 연결하는 각 클라이언트 프로세스는 Oracle Net Services를 사용해야 합니다.

디스패처 프로세스는 다음과 같이 통신을 설정합니다.

  1. 인스턴스가 시작되면 네트워크 리스너 프로세스가 열리고 사용자가 Oracle AI Database에 연결하는 데 사용하는 통신 경로가 설정됩니다.

  2. 각 디스패처 프로세스는 디스패처가 연결 요청을 수신하는 주소를 리스너 프로세스에 제공합니다.

    데이터베이스 클라이언트가 사용할 각 네트워크 프로토콜에 대해 디스패처 프로세스를 하나 이상 구성하고 시작해야 합니다.

  3. 클라이언트 프로세스가 연결을 요청할 때 리스너는 클라이언트 프로세스가 공유 서버 프로세스를 사용해야 하는지 여부를 결정합니다.

    • 리스너가 공유 서버 프로세스가 필요하다고 판단한 경우 리스너는 로드가 가장 적은 디스패처 프로세스의 주소를 반환하며 클라이언트 프로세스는 디스패처에 직접 연결합니다.

    • 프로세스가 디스패처와 통신할 수 없거나 클라이언트 프로세스가 전용 서버를 요청하는 경우 리스너는 전용 서버 프로세스를 생성하여 적절한 연결을 설정합니다.

참조: Oracle AI Database Net Services Administrator's Guide에서 디스패처 구성 방법 알아보기

공유 서버 프로세스(S nnn)

각 Shared Server 프로세스는 Shared Server 구성에서 여러 클라이언트 요청을 처리합니다.

공유 서버 프로세스와 전용 서버 프로세스는 특정 클라이언트 프로세스가 연관되지 않은 경우를 제외하고 동일한 기능을 제공합니다. 대신 Shared Server 프로세스는 Shared Server 구성에서 모든 클라이언트 요청을 처리합니다.

Shared Server 프로세스의 PGA에는 UGA 데이터가 포함되지 않으며 모든 Shared Server 프로세스에서 이 데이터에 액세스할 수 있어야 합니다. Shared Server PGA에는 프로세스 특정 데이터만 포함됩니다.

모든 세션 관련 정보는 SGA에 포함됩니다. 모든 서버가 모든 세션의 요청을 처리할 수 있도록 각 Shared Server 프로세스는 모든 세션의 데이터 공간에 액세스할 수 있어야 합니다. SGA에는 각 세션의 데이터 공간에 대한 공간이 할당됩니다.

참조: "PGA(Program Global Area) 개요"

공유 서버의 제한된 작업

인스턴스 종료 또는 인스턴스 시작과 매체 복구를 포함하여 디스패처 프로세스에 연결된 동안에는 특정 관리 작업을 수행할 수 없습니다.

이러한 작업은 일반적으로 관리자 권한과 연결된 경우 수행됩니다. 공유 서버로 구성된 시스템에서 관리자 권한으로 연결하려면 Dedicated Server 프로세스를 사용하도록 지정해야 합니다.

참조: 적절한 접속 문자열 구문은 Oracle AI Database Net Services Administrator's Guide를 참조하십시오.

데이터베이스 상주 접속 풀링

DRCP(데이터베이스 상주 연결 풀링)는 일반적인 웹 응용 프로그램 시나리오를 위한 전용 서버의 연결 풀을 제공합니다.

웹 응용 프로그램은 일반적으로 데이터베이스 연결을 만들고 해당 연결을 간략하게 사용한 다음 해제합니다. DRCP를 통해 데이터베이스는 수만 개의 동시 연결로 확장할 수 있습니다.

DRCP는 다음과 같은 이점을 제공합니다.

DRCP는 전용 서버 프로세스(공유 서버 프로세스가 아님)와 결합된 데이터베이스 세션과 동일한 풀링된 서버를 사용합니다. 풀링된 서버 모델은 서버가 필요한 모든 연결에 대해 짧은 기간 동안 서버를 전용으로 지정하는 오버헤드를 방지합니다.

데이터베이스 상주 접속 풀에서 접속을 획득하는 클라이언트는 접속 브로커라고 하는 Oracle 백그라운드 프로세스에 접속합니다. Connection Broker는 풀 기능을 구현하고 클라이언트 프로세스의 인바운드 연결 간에 풀링된 서버를 다중화합니다.

그림 19-10에 표시된 것처럼 클라이언트에 데이터베이스 액세스가 필요한 경우 연결 브로커는 풀에서 서버 프로세스를 선택하여 클라이언트로 전달합니다. 요청이 처리될 때까지 클라이언트는 서버 프로세스에 직접 연결됩니다. 서버가 완료되면 서버 프로세스가 풀로 해제됩니다. 클라이언트의 연결이 broker로 복원됩니다.

그림 10: DRCP

그림 cncpt312.gif에 대한 설명

DRCP에서 리소스를 해제하면 세션은 그대로 유지되지만 더 이상 연결(서버 프로세스)과 연관되지 않습니다. Shared Server와 달리 이 세션은 해당 UGA를 SGA가 아닌 PGA에 저장합니다. 클라이언트는 작업 감지 시 투명하게 연결을 재설정할 수 있습니다.

참조:

프로그램 인터페이스 개요

프로그램 인터페이스는 데이터베이스 애플리케이션과 Oracle AI Database 간의 소프트웨어 계층입니다.

프로그램 인터페이스는 다음 기능을 수행합니다.

Oracle 코드는 서버 역할을 하며 데이터 블록에서 행 인출과 같은 응용 프로그램(클라이언트)을 대신하여 데이터베이스 작업을 수행합니다. 프로그램 인터페이스는 Oracle AI Database 소프트웨어와 운영 체제별 소프트웨어에서 제공하는 여러 부분으로 구성됩니다.

프로그램 인터페이스 구조

프로그램 인터페이스는 여러 가지 구성 요소로 구성됩니다.

다음과 같은 구성 요소가 포함됩니다.

프로그램 인터페이스의 사용자 및 Oracle AI Database 측은 드라이버와 마찬가지로 Oracle 소프트웨어를 실행합니다.

프로그램 인터페이스 드라이버

드라이버는 일반적으로 네트워크를 통해 데이터를 전송하는 소프트웨어입니다.

드라이버는 연결, 연결 해제, 신호 오류 및 오류 테스트와 같은 작업을 수행합니다. 드라이버는 통신 프로토콜에만 해당됩니다.

기본 드라이버는 항상 존재합니다. 비동기 또는 DECnet 드라이버와 같은 여러 드라이버를 설치하고 하나를 기본 드라이버로 선택할 수 있지만 사용자가 연결할 때 드라이버를 지정하여 다른 드라이버를 사용할 수 있습니다.

프로세스마다 다른 드라이버를 사용할 수 있습니다. 프로세스는 서로 다른 Oracle Net Services 드라이버를 사용하여 단일 데이터베이스 또는 여러 데이터베이스에 대한 동시 연결을 가질 수 있습니다.

참조:

운영 체제용 통신 소프트웨어

사용자측을 프로그램 인터페이스의 Oracle AI Database측에 연결하는 최하위 레벨 소프트웨어는 호스트 운영 체제가 제공하는 통신 소프트웨어입니다.

예제는 DECnet, TCP/IP, LU6.2 및 ASYNC입니다. 통신 소프트웨어는 Oracle에서 제공할 수 있지만 일반적으로 하드웨어 공급업체나 타사 소프트웨어 공급업체와 별도로 구매합니다.

Oracle True Cache 개요

True Cache는 Oracle AI Database 앞에 있는 인메모리 읽기 전용 캐시입니다.

Oracle Active Data Guard와 마찬가지로 True Cache는 기본 데이터베이스의 완전하게 작동하는 읽기 전용 복제본입니다. 단, 대부분 디스크가 없는 복제본입니다.

최신 애플리케이션은 종종 많은 수의 연결과 짧은 대기 시간의 데이터 액세스가 필요합니다. 일반적으로 응용 프로그램은 갱신보다 읽기 횟수가 많고 데이터베이스 성능에 영향을 주지 않고 캐시에서 읽을 수 있기 때문에 캐시를 데이터베이스 앞에 배치하는 것이 가장 좋습니다. 예를 들어, 항공 예약 시스템은 사람들이 항공편을 쇼핑할 때 자주 데이터를 읽으며, 데이터가 데이터베이스의 데이터와 비교하여 최신 데이터가 아닌 경우 괜찮습니다. 응용 프로그램은 누군가가 비행을 예약 할 때 최신 데이터에 액세스해야합니다.

기존의 캐시와 달리 True Cache는 가장 자주 액세스하는 데이터를 캐시에 자동으로 보관하고 캐시를 기본 데이터베이스, 동일한 캐시의 다른 객체 및 기타 캐시와 일관되게 유지합니다. JSON을 포함한 모든 Oracle AI Database 객체 및 데이터 유형을 캐시합니다.

True Cache는 Oracle AI Database 보안 정책을 구현하기 때문에 캐시에 대한 액세스를 제어할 수 있습니다. 이를 통해 일반적으로 캐시에 저장하지 않을 수 있는 개인 정보와 같은 중요한 데이터를 캐시에 저장할 수 있습니다.

관련 항목