Oracle Database 10g Express Edition: 초보자만을 위한 제품이 아닙니다.

원문 : http://bangganji.tistory.com/74

Oracle Database 10g Express Edition: 초보자만을 위한 제품이 아닙니다.

Lewis Cunningham l Certegy 의 수석 DBA

아마도 여러분들 중 대부분이 이미 DBA와 개발자를 위한 무료 데이터베이스인 Oracle Database 10g Express Edition (XE)의 정식 버전 출시에 대해 알고 계실 것입니다. 이 제품은 오라클의 역사에 있어 매우 중요한 의미를 갖습니다. Oracle Database XE의 가치는 단순히 초보자, 학생, 소규모 기업 등에 한정되지 않으며, 다른 여러 가지 상황에서 그 매력을 발휘합니다. 기업의 규모를 불문하고, DBA, 개발자, 또는 분석 담당자가 일상 업무를 수행하는 과정에서 가치를 발휘하게 될 것입니다. 

예를 들어, DBA가 사용자들로부터 데이터베이스에 대한 “what-if” 시나리오의 분석을 요청 받는 경우, Oracle Database XE를 이용하여 데이터를 사용자에게 전달하도록 함으로써 운영 서버에 미치는 영향을 최소화할 수 있을 것입니다. 또 오픈 소스 데이터베이스를 다운로드하여 설치한 개발자들이 공통적으로 겪게 되는 유지보수, 기술지원, 보안 등의 골치 아픈 문제를 예방하는 데에도 많은 도움을 얻을 수 있습니다. “DBA” 업무에 대해서 배우고자 하는 개발자, 또는 R&D 데이터베이스에서 새로운 방법을 시도해 보고자 하는 개발자, 또는 오픈 소스 환경의 호환성, 마이그레이션 이슈에 신물이 난 개발자에게 있어서도 Oracle Database XE는 최상의 대안을 제공합니다. 

마지막으로, 비즈니스 애널리스트가 분석하고자 하는 “what-if” 시나리오가 운영 중인 웨어하우스 또는 애플리케이션 상에서 실행하기 어려운 경우, Oracle Database XE를 안정적인 데이터 접근 모델로 활용할 수 있을 것입니다. 본 문서에서는, 지금까지 언급한 세 가지 관점에서 Oracle Database XE가 제공하는 몇 가지 명백한 (또는 명백해 보이지 않는) 효과에 대해 설명하고자 합니다. 하지만 시작하기 전에, Oracle Database XE의 기본적인 한계를 이해하는 것이 중요할 것입니다.

제약사항

(표준 Windows Installer를 이용한) 설치, 구성, 유지보수의 용이성을 높이기 위해, 오라클은 Oracle Database XE에 다음과 같은 제약 사항을 설정하였습니다.

첫 번째 제약 사항은 메모리입니다. Oracle Database XE는 최대 1 GB의 메모리만을 지원합니다. 하지만 1 GB 메모리를 장착한 머신이 (특히 소규모 비즈니스 환경에서는) 그리 흔하지 않다는 사실을 감안한다면, 이러한 제약은 결과적으로 데이터베이스에 접근할 수 있는 동시 사용자의 수에 영향을 미치는 것으로 볼 수 있을 것입니다. 대부분의 경우 Oracle Database XE는 단일 사용자의 데스크탑 환경 또는 소규모 워크그룹 서버에 설치되므로, 1 GB는 충분한 용량입니다.

두 번째로, XE는 하나의 CPU만을 지원합니다. XE에서 멀티-태스킹이 지원되지 않는다거나 한 번에 하나의 함수만을 실행할 수 있다는 의미는 아닙니다. XE는 두 개 이상의 CPU를 장착한 컴퓨터에서 실행 가능하지만, CPU 수만큼의 확장은 지원하지 않습니다. 추가로 장착된 CPU를 사용하려면 Oracle Database Standard Edition 또는 Enterprise Edition을 구입해야 합니다. 하지만 역시, XE가 적용되는 환경에서 하나의 CPU는 충분하고도 남는 수준입니다.

세 번째로, 단일 컴퓨터 상에서 하나의 XE 데이터베이스만이 실행 가능하다는 제약이 존재합니다. 여기서 중요한 것은, 경쟁사의 제품과 달리 XE 환경에서는 생성하는 각 애플리케이션 별로 데이터베이스를 생성할 필요가 없다는 사실입니다. 그 대신, 오라클은 애플리케이션 간의 구분을 위해 스키마(schema)라는 개념을 사용합니다.

마지막으로 디스크 공간에는 4 GB의 제약이 존재합니다. 표면적으로 볼 때, 이것은 매우 심각한 제약 사항처럼 보이기도 합니다. 하지만 대부분의 애플리케이션에 있어 4 GB는 매우 큰 용량입니다. 물론 수 TB 급의 데이터 웨어하우스에 비교한다면 4 GB가 매우 작은 것처럼 느껴지기도 하지만, 실제로는 전혀 그렇지 않습니다.

데이터베이스에 포함된 HR 샘플 스키마를 고려해 봅시다. EMPLOYEES 테이블의 최대 로우 사이즈는 144 바이트입니다. 4 기가바이트는 4,294,967,296 바이트로 환산되며, 4GB/144 =29,826,162입니다. 따라서 4 GB의 용량만으로 3천만 명의 직원 레코드를 저장하는 것이 가능합니다. JOBS, DEPARTMENTS 등의 다른 샘플 테이블들을 감안하더라도, 이처럼 많은 데이터를 로컬 데이터에 한꺼번에 저장하는 경우는 흔치 않습니다. (그리고 이러한 경우를 위해 엔터프라이즈 버전이 존재합니다.) Oracle Database XE는 이러한 데이터의 일부분만을 저장하는 용도로 설계되었습니다.

다음 섹션에서는, 이러한 제약 사항이 일상적인 DBA 업무를 수행하는데 있어 오히려 도움이 된다는 사실을 이해하고 넘어가겠습니다.

집산(Aggregation)에의 활용

데이터 웨어하우스 환경을 한 예로 고려해 봅시다. DW 환경에서 4 GB의 디스크 공간 제약이 존재하는 경우라면, 데이터의 최신성 문제로 고민할 일은 없을 것입니다. XE 환경에서 퍼지(purge) 및 리프레시(refresh) (또는 push 및 pull) 작업을 스케줄하면 됩니다. 데이터베이스가 사용자의 데스크탑에 위치한다고 해서 데이터베이스가 “외부”에 존재한다고 볼 필요는 없습니다.

이러한 이유로, 집산(aggregate) 처리된 데이터를 사용자에게 전송하는 작업을 Oracle Database XE가 담당하게 함으로써, 데이터에 대한 담당자의 컨트롤을 강화하는 한편으로 엔터프라이즈 하드웨어의 부담을 줄일 수 있을 것입니다. EE 라이센스 비용을 CPU 하나 분량만큼이라도 줄일 수 있다면, 노력한 보람이 있다고 볼 수 있을 것입니다. 또한 집산 처리된 데이터에서는 개인정보보호 또는 컴플라이언스 등의 부담이 크지 않은 편입니다.

Oracle Database XE는 Materialized View의 복제를 지원합니다. 하지만 불과 몇 명의 사용자가 XE를 실행 중인 환경에서 굳이 이런 설정을 사용할 필요는 없습니다. 그보다는 클라이언트 사이드(XE)에서 몇 가지 스토어드 프로시저를 생성해 두는 것이 좋은 대안이 될 수 있습니다. 이 프로시저를 이용하여 오래된 데이터의 정제(cleanup)를 수행하고 최신 데이터를 다시 채워 넣는 작업을 수행하게 됩니다. 스크립트의 예가 아래와 같습니다:

/* Turn on spooling and write output to the file
test_links.lst for later review */
spool test_links

/* Connect to the LOCAL XE database as SYSTEM (DBA) 
This user, SYSTEM, has the permissions to execute the 
following grant */
connect system/&local_system_pwd.@local_xe

/* Grant CREATE TABLE directly to HR 
We need to grant explicitly so that the 
create table command can be used in a 
stored procedure */
grant create table to hr;

/* Connect to the REMOTE XE Database as HR 
HR is a sample account that comes pre-loaded 
with Oracle Database XE */
connect hr/&remote_hr_pwd.@remote_xe

/* This select tells us how many records are actually in
the HR.EMPLOYEES table */
select count(*) from hr.employees;

/* Create a view to restrict data in the remote HR schema
The where clause will reduce the number of records that
a user sees */
create or replace view hr_employees_vw as
select * from hr.employees
where salary < 5000;

/* Re-execute the select from above against the new view
and note that there are fewer records in the view 
than there are in the table */
select count(*) from hr_employees_vw;

/* Connect to the local HR account */
connect hr/&local_hr_pwd.@local_xe

/* Create a database link from the local XE database
to the remote XE database HR account */
create database link remote_db
connect to hr
identified by hr
using 'remote_xe';

/* Create a procedure to populate a local table
The procedure drops the local HR_LOCAL_EMPLOYEES
table and then recreates it by selecting from
the newly created HR_EMPLOYEES_VW in the remote
XE database using the database link created above */
create or replace procedure pop_hr_data as
begin

begin
-- Drop the local table
execute immediate 'drop table hr_local_employees cascade constraints';
exception
when others then
null;
end;

-- Create the table by selecting across the database link
execute immediate 'create table hr_local_employees as ' ||
'select * from hr_employees_vw@remote_db';

end;
/

/* Run the procedure to execute the new procedure */
exec pop_hr_data

/* Verify that the procedure, link and view are working
by executing a select that counts the number of records
in the HR_LOCAL_EMPLOYEES table. This number should be
the same number as the count from
the remote XE restricted view above */
select count(*) from hr_local_employees;

/* Turn off the spooled output. This will save the file 
so that the script and results can be reviewed */
spool off

이러한 접근 방식의 가장 큰 장점 중 하나는, 리프레시 작업의 스케줄링이 가능하므로 각 사용자 별로 최적의 로드 타임을 결정할 수 있다는 것입니다.

EE의 뷰를 이용하여 웨어하우스 또는 SE/EE 데이터베이스에서 각 사용자에게 ID를 부여함으로써 특정 사용자의 데이터를 컨트롤할 수 있습니다. 사용자는 할당된 스토어드 프로시저를 실행하여 데이터의 입력(population)을 수행하고, ID를 이용하여 개별적인 데이터베이스 링크를 생성합니다. 나중에 동일한 링크를 사용하여 데이터베이스에 접근하는 경우, 이전과 동일한 권한과 역할이 할당될 것입니다. 따라서 DBA는 보안 문제로 추가적인 부담을 느낄 필요가 없습니다. (사용자의 직책 변경, 퇴사 등으로 인해) 사용자의 데이터 접근 권한을 제한하려면, 사용자 계정을 잠그거나 제거하기만 하면 됩니다.

Oracle Warehouse Builder의 차세대 버전(코드명 “Paris”)에서도 사용자의 데이터 전달을 위한 새로운 대안이 제공될 것입니다. Paris는 제너릭한 연결(ODBC)을 이용한 매핑을 통해 요약(summary) 테이블로부터 데이터를 추출하는 기능을 제공할 것입니다 (따라서 Oracle Database XE 뿐만 아니라 경쟁사의 제품을 타겟 데이터베이스로 활용할 수 있습니다.) 타겟 데이터베이스는 PC 또는 워크그룹 서버에 존재할 수도 있습니다.

Oracle Database XE는 external table을 지원합니다. 이미 플랫 파일을 웨어하우스에 임포트(import)하는 환경을 구현하였거나 플랫 파일을 다른 용도로 활용하고 있는 경우라면, 사용자에게 external table의 생성을 위한 스크립트를 추가로 제공할 수 있을 것입니다. 이 경우 플랫 파일을 복사하는 것만으로 데이터의 변경 작업이 완료됩니다. 엔드 유저는 계산된 결과 및 기타 사용자 데이터를 자신의 테이블에서 직접 관리할 수 있습니다. 위에서 언급한 4 GB의 디스크 공간 한계는 데이터베이스 내부의 사용자 공간에만 적용되며, external table에는 적용되지 않습니다.

소스 컨트롤, 구성 관리, 버그 추적, 프로젝트 관리와 같은 대부분의 소규모 애플리케이션은 ODBC 또는 JDBC 연결과 ANSI SQL을 사용하여 오픈 소스 데이터베이스에 데이터를 저장합니다. Oracle Database XE는 ANSI 표준 SQL과 ODBC/JDBC 연결을 모두 지원합니다. (데이터베이스 오브젝트 생성을 위한) 몇 가지 DDL 스크립트만 실행함으로써 기존 애플리케이션 환경을 Oracle Database XE로 이전할 수도 있을 것입니다. 또 XE 버전의 인기가 확산되면서, 새로운 오픈 소스 프로젝트에 XE 지원 기능이 추가될 것으로 기대됩니다.

개발자를 위한 활용 방안

많은 개발자들이, 프로젝트를 바로 시작해야 하는 상황에서 개발 용도의 인스턴스 생성이 완료되기까지 기다려야 했던 경험을 갖고 있을 것입니다. 또 아이디어를 테스트해보고 싶지만 이에 필요한 권한이 부여되지 않는 경우도 존재합니다. 또는 데이터베이스 매개변수를 조정해서 그 결과를 확인해 보려 했지만 “그건 DBA가 할 일이다”라는 말을 듣는 경우도 있습니다. 이러한 경우라면, Oracle Database가 훌륭한 대안이 됩니다.

여러분들도 잘 알고 있는 것처럼, 위와 같은 상황에서 오픈 소스 데이터베이스를 사용하는 것은 문제의 소지가 있습니다. 서로 다른 데이터베이스는 결코 동일한 환경으로 구성될 수 없습니다. 대부분의 오픈 소스 데이터베이스에서 사용되는 매개변수는 오라클과 전혀 다릅니다. 데이터베이스 간의 관리 작업도 전혀 다르게 수행됩니다. 오픈 소스 데이터베이스에서 성공한 아이디어가 오라클 환경에서도 동일하게 성공할 것이라 보장할 수는 없습니다. 또 오픈 소스데이터베이스에서 프로그래밍을 시작한 경우, 언젠가는 오라클로의 마이그레이션 문제로 고민해야 합니다.

Oracle Database XE에서는 이러한 문제로 고민할 필요가 없습니다. 개발자가 DBA의 역할까지 떠맡더라도 문제 될 것이 없습니다. 설치 및 구성 작업에는 최소한의 노력만이 필요하기 때문에 개발 작업에 집중할 수 있습니다. 또는 데이터베이스의 설정을 변경해 보고자 하는 경우에도 완벽한 통제권을 확보할 수 있습니다.

Oracle Application Express(구제품명 HTML DB)의 admin control을 이용하여 다수의 사용자에게 각자 다른 권한을 부여하거나, SQL*Plus를 통해 사용자, 역할, 프로파일을 생성할 수 있습니다. 설정 및 기타 DBA 작업에 사용되는 시간은 전적으로 여러분이 하기 나름입니다. Oracle Database XE는 기본적으로 설치 후 별도의 설정을 거치지 않고도 개발 작업을 시작할 수 있는 제품입니다.

하지만 설치 용량을 줄이고 관리 오버헤드를 최소화하는 과정에서 누락된 기능도 물론 있습니다. 먼저 데이터베이스 내부적으로 Java가 지원되지 않습니다. JDBC를 통해 외부 JVM에 연결하는 것은 가능하지만, 현재로서는 내부 JVM은 전혀 제공되지 않습니다.

반면 .NET CLR 외부 프로세스 리스너는 포함되어 있습니다. 이 리스너는 Oracle 8.0부터 제공되어 온 C 외부 리스너와 유사합니다. 이 외부 프로세스는 .NET 프로그램을 데이터베이스 내부적으로 등록하고 PL/SQL 스토어드 프로시저로부터 호출될 수 있게 하는데 사용됩니다.

.NET 지원 기능은 Windows 플랫폼 상에서만 제공되며, 아직까지 Visual Studio 2003 환경만이 지원됩니다. (VS2005에 대한 지원은 2006년 초에나 제공될 것입니다.) 하지만, 마이크로소프트가 VS Express 툴셋에 적용한 기능상의 제약으로 인해 VS Express 툴은 사용할 수 없습니다.

TOAD, JDeveloper, Forms, PHP, (오라클의 새로운 그래픽 데이터베이스 개발 툴인) Project Raptor 등의 다른 모든 개발 툴은 모두 XE와 호환 가능합니다. 개발자는 애플리케이션 요구 사항에 따라 다양한 옵션을 테스트해 볼 수 있습니다.

다른 버전의 경우와 마찬가지로, Oracle Database XE는 Application Express 웹 기반 개발 및 구축 툴과 XML DB를 포함하고 있습니다. XML DB의 경우 XML, WebDAV, 빌트인 HTTP/FTP 서버 등의 즉각적인 활용이 가능합니다.

(참고: 오라클 개발자의 경우 자신의 PC에 다수의 Oracle Home이 설정되어 있을 수 있습니다. 가능한 한, XE를 다른 오라클 툴보다 먼저 설치하도록 하십시오. 이것이 가능하지 않다면, 설치를 시작하기 전에 ORACLE_HOME과 TNS_ADMIN 매개변수를 커멘트 처리해야 합니다. TNS_ADMIN 매개변수를 설정했다면, 전체 Oracle Home 디렉토리에 대해 하나의 TNSNAMES.ORA 파일을 관리할 수 있습니다.)

어떤 경우에는 Oracle Personal Edition(PE)가 보다 적절한 대안이 될 수도 있습니다. PE는 별도의 라이센스를 요구하지만, EE의 모든 기능을 활용할 수 있을 뿐 아니라 Oracle Metalink 지원 서비스가 제공된다는 이점이 있습니다. 테이블 파티셔닝이 필요하거나, VPD를 이용하여 애플리케이션의 보안을 보장해야 하거나, 4 GB 이상의 테이블을 관리해야 하는 경우에는 PE가 XE보다 나은 대안이 될 것입니다.

24/7 “What-If” 분석

대부분의 분석 담당자들은 오라클 대신 MS 엑셀 또는 액세스를 이용하여 업무를 수행합니다. 이러한 PC 애플리케이션에는 심각한 단점이 존재합니다. 엑셀의 경우만 해도 안정성, 보안, 로우 제한(64K)과 같은 심각한 제약 사항이 존재합니다.

하지만 애널리스트가 자신만의 테이블을 직접 생성하고, 데이터를 자유롭게 조합하고 수정하여 “what-if” 시나리오를 수행할 수 없었던 기존 환경에서는 별 뾰족한 대안을 찾기 어려웠습니다. 매우 적은 (디스크/메모리) 설치 용량과 뛰어난 설치 편의성을 제공하는 Oracle Database XE는 위의 조건을 모두 만족합니다. 운영 데이터베이스에 계정을 보유한 분석 담당자라면, 데이터베이스 링크를 설정하는 작업만으로도 Oracle Database XE로 데이터를 가져오는 작업을 완료할 수 있습니다.

여기서 가장 요긴하게 활용되는 기능이 바로 Application Express입니다. Application Express는 프로그래밍에 대한 지식이 전혀 없는 사용자를 감안하여 설계된 웹 기반 GUI 스크린 및 리포트 빌더입니다. 스크린과 보고서를 생성하는 것 이외에도, Application Express 마법사를 사용하여 디스크 사용량을 조회하거나 테이블, 인덱스 등의 데이터베이스 오브젝트를 생성할 수 있습니다.

Application Express는 (SQL에 대한 지식이 없는 사용자들을 위해) 그래픽 쿼리 빌더와 그래픽 데이터베이스 브라우저를 제공합니다. 데이터베이스 브라우저는 데이터베이스 내부의 오브젝트에 대한 내비게이션을 통해 조회, 수정 작업을 수행할 수 있게 합니다.

분석 담당자들은 Application Express의 "Create From Spreadsheet" 마법사를 사용하여 기존 스프레드시트로부터 테이블과 애플리케이션을 생성할 수 있습니다. 메뉴 옵션을 클릭한 후, 스프레드시트의 업로드를 선택하기만 하면 됩니다. 마법사는 스프레드시트로부터 생성된 결과에 대한 요약 리포트를 제공합니다.

Application Express의 출력은 CSV 파일로 저장되어, 나중에 Excel에서 실행할 수 있습니다.

MS Access 애플리케이션의 경우, Excel 스프레드시트보다 좀 더 복잡한 지식이 요구됩니다. Access 애플리케이션을 Application Express로 마이그레이션하는 과정에서의 주의 사항은 이 프리젠테이션을 참고하시기 바랍니다.

Oracle Database XE는 LAG, LEAD, PERCENTILE_RANK, STDDEV 등의 다양한 빌트인 분석 함수를 제공합니다. 이러한 분석 함수들은 Application Express 애플리케이션에서 직접 활용이 가능합니다. 단 복잡한 비즈니스 인텔리전스 애플리케이션에서 사용되는 OLAP과 SELECT MODEL 구문은 XE에서 지원되지 않습니다.

단순한초보자용데이터베이스가아닙니다

지금까지 여러 가지 이점에 대해 설명했지만, Oracle Database XE가 결코 만병통치약이 될 수는 없습니다. 개인정보보호 또는 컴플라이언스에 관련한 분명한 요구사항이 존재하는 경우에는 보안 및 감사 환경의 통제가 가능한 중앙 데이터베이스에 데이터를 저장하는 것이 적절합니다. 많은 수의 사용자를 지원해야 하는 경우, 또는 XE의 디스크 용량이 한계에 이른 경우에도, 보다 통제된 환경에서 데이터베이스가 DBA에 의해 관리되도록 하는 것이 바람직합니다.

하지만 XE는 (단순한 교육, 테스트 용도를 넘어서는) 다양한 용례를 갖습니다. 소규모 기업 환경에서 포춘 500대 기업에 이르기까지, XE는 사용자들의 요구사항을 만족시키는 데이터베이스 제품으로 활용될 것입니다.