[지디넷코리아]최근 흩어져 있는 데이터를 공유하는 것에 대한 논의가 활발히 이뤄지고 있다. 특히 원거리의 분산환경 상의 정보뿐만 아니라 서로 성격을 달리하는 정보들(DW, CRM, 인사, 회계 등)간의 긴밀한 데이터 통합이 필수적이다. 이런 요구가 생기는 것은 기업 환경의 급격한 변화에 기인하고 있다. 기업에서는 회사의 업무 우선 순위의 변경이라든지 업무요구의 변화에 따라 자체 자원 조정의 요구에 종종 직면하게 된다. 오라클10g에서는 급격한 변화 요구에 따른 회사 자원의 손쉬운 조정을 가능하게 하는 완벽한 그리드 컴퓨팅 솔루션을 제공한다. 정보 프로비저닝(provisioning)은 분산환경하에서 언제 어디서든지 필요로 하는 정보의 접근을 가능케 하는 그리드 솔루션의 중요한 구성요소이다.

원하는 곳, 필요한 때에 데이터 얻기
그리드 컴퓨팅은 필요로 하는 자원의 동적 재배치와 가상화를 통한 조정의 어려움을 배제할 수 있다. 정보는 필요로 하는 곳에 반드시 제공되어야 하는 중요한 자원 중 하나이다. 원하는 곳, 필요로 하는 때에 데이터를 얻기 위해서 매우 정교한 정보 프로비저닝 기술이 요구된다. 이러한 프로비저닝 기술은 정보의 물리적인 위치와 상관없이 필요로 하는 시기와 장소에 최적의 정보를 얻을 수 있도록 한다. 그리드 내의 분산 환경이거나 독립형 시스템, 다수의 그리드에 걸쳐 있는 정보를 통합한다.

정보를 공유하면 사용자가 필요로 할 경우 그것이 어디에 저장되어 있는지 알 필요 없이 정보를 취득할 수 있다. 정보가 어떤 가용 자원상에 있는지 관계없이 처리하기 위해서 그리드는 다수의 시스템에 걸쳐 효율적으로 정보를 공유해야 한다. 그리드는 이기종의 시스템에 있는 데이터 액세스까지도 제공해야만 한다.

오라클10g에서는 분산 SQL, 메시지 큐잉과 복제 기능을 포함한 데이터 공유를 위한 단일 통합환경을 제공하는 오라클 스트림(Streams), 오라클 환경으로부터 non-오라클 시스템의 데이터 접근을 허용하는 ‘투명한 게이트웨이’와 transportable tablespace, data pump 등을 이용한 대규모 데이터 이동 기술을 이용한 정보 프로비저닝 기능을 갖고 있다.

그 중 오라클에서 제시하는 정보 공유(information sharing) 기법들 중 오라클 스트림에 대해서 자세히 알아보도록 하겠다. 오라클 스트림은 오라클9i R2부터 소개된 정보 공유 기능이다. 오라클 스트림은 데이터베이스 내 또는 하나의 데이터베이스에서 다른 데이터베이스로 데이터(데이터, 트랜잭션 및 이벤트)를 전달할 수 있도록 지원한다.

예를 들어 스트림을 사용해 데이터베이스 객체의 DML 및 DDL 변경 사항을 이벤트로 캡처할 수 있다. 그런 다음 데이터베이스 객체를 다른 데이터베이스로 효율적으로 복제해 이러한 이벤트를 다른 데이터베이스에 전달할 수 있다. 또한 같은 오라클 버전, OS, 플랫폼과 같은 제한사항이 없으며, 또한 게이트웨이를 사용해 이기종 DBMS(Heterogeneous DBMS; DB2, SQL 서버, 사이베이스 등)와의 연동까지도 가능하다.

<그림 1> 오라클 스트림

활용방안
데이터 복제 기능 활용
현재의 시스템 환경은 데이터와 인터넷 환경을 통한 사용자의 급격한 증가에 직면하고 있는 상황이다. 고로 OLTP로 운영되는 메인 시스템 같은 경우 피크 타임(peak time)시의 부하량 증가 및 배치 작업시의 OLTP와 대규모 쿼리성 작업의 병목현상으로 인한 문제가 심각하다. 이 경우 보통 OLTP 시스템의 물리적인 증가(CPU, 메모리 증가)를 통해서 문제를 해결하던지 제한적이나마 튜닝을 통해서 해결될 수 있지만, 너무 많은 비용의 소요와 제한적인 해결책이라고 할 수 있다.

OLTP에서 생기는 막대한 데이터들은 배치/리포트용 시스템, fail-over 시스템, 분석 시스템으로 Near Real time으로 이동시키는 것이 가능하다면, 또한 이런 작업을 할 때 OLTP에 부하를 주지 않을 수만 있다면 OLTP 시스템의 안정화, 소규모 투자를 통한 분석/리포트 시스템 구축이라는 두 마리 토끼를 한꺼번에 잡을 수 있다.

현재 이런 작업은 여러 산업 분야에서 사용되고 있으며, 그 중 반도체 생산시스템 분야의 생산 레거시 시스템에서 분석 시스템으로의 데이터 이동 처리 업무에 파일롯 형태로 검토하고 있다.

데이터 웨어하우스 로딩 사용
OLTP에서 DW 시스템으로 데이터를 이동시키는 전통적인 방법은 배치 프로그램을 통한 하루에 한 두 번씩의 대규모 SQL문의 수행이었다. 그러나 새롭게 개선된 오라클 스트림을 사용하면 OLTP 시스템에 부하 없이 리두 로그 파일의 변경된 내용만을 전달하는 것이 가능하고, 또한 리두 로그 파일이 거의 실시간에 데이터가 생기는 속성으로 인해서 근접 실시간 데이터 이동이 가능하다. 현재의 RTE(Real Time Enterprise) 환경에서 가장 중요한 기능이 제공된다.

현재의 진화하는 DW 시스템은 예전의 오래된 데이터를 누적해서 분석하는 차원에서 진일보해 실시간으로 파악되는 현황을 토대로 분석하는 응용된 DW 시스템으로 나아가고 있다. 몇 일전 혹은 몇 년 전의 가격 추이도 중요한 정보지만 지금 당장의 판매 현황, 판매 추이 분석이 더 중요한 기업환경에서 DW의 ETT 작업에 스트림을 활용할 수 있다.

메시지 큐잉 기능의 활용
단순한 데이터의 이동뿐만 아니라 하나의 운영 시스템에서의 특정 데이터를 대상으로 다른 복수의 시스템으로 복수의 변형된 데이터로 변환해 전송할 수 있다. 예를 들면 생산시스템에서 회계 시스템, 판매 시스템, 분석 시스템, DW 시스템, CRM 시스템, EIS 시스템 등 다수의 데이터가 필요한 곳으로 보낼 수도 있고, 필요에 의해서 원본 데이터에서 변형된 형태로 데이터를 보낼 수 있다. 오라클 큐잉 매커니즘을 사용하기 때문에 안정적으로 사용되며, 현 업무에서 적용 가능한 데이터 통합(integration) 시스템의 구축도 가능하다. 보통의 메시지를 이용하는 EAI 솔루션과 동일 수준의 데이터 관리, 이벤트 처리가 가능하며 더불어 데이터베이스의 안정성까지 추가적으로 보장한다.

분산환경에서의 데이터 복제 가능
중앙 집중적인 통합 시스템의 문제로 인한 분산환경으로 시스템이 구축돼 있을 경우 서로 공유하는 데이터에 대해서는 분산 복제 기능을 사용해 데이터의 정확성을 맞춰야 하는데, 이 경우 과거 버전의 오라클에서는 db_link, trigger, replication 등의 방법을 이용했다. 이런 방법들은 발표될 시점에서는 아주 강력하고 손쉬운 방법이었으나, 지금은 셋업의 불편, 퍼포먼스의 문제 등으로 인해 그 사용이 제한적인 상태이다. 스트림을 이용한 데이터 복제는 기존의 오라클 데이터 공유(data sharing) 방법에서 할 수 있는 양방향 복제, 데이터 충돌에 따른 resolution, 이기종 DBMS와의 연동뿐만 아니라 더 빠른 속도와 네트워크 부하의 감소, 더 간편한 셋업(configuration)이 가능하다.

고가용성 솔루션
원본 시스템의 전체 데이터베이스를 백업 시스템으로 near real time으로 이동시킨다면 원본 시스템의 장애시 백업 시스템을 즉시 활용하는 것이 가능하다. 즉 원격지에서의 데이터 보호를 위한 솔루션인 재난복구(DR) 시스템으로도 사용이 가능하다.

스트림 구조
스트림은 오라클9i R2에 소개된 것으로 Logminer(리두 로그 파일 분석기)의 기능을 이용해 리두 로그 파일/아카이브 파일(Archive File)을 읽어서 원하는 테이블, 스키마 혹은 전체 데이터베이스의 변경사항을 캡처해 리모트 데이터베이스(Remote Database)로 전달해 적용한다.

이러한 방식으로 원격지 데이터베이스간의 정보 공유를 지원하며, 또한 스트림은 전달하는 과정에서 소스 변경사항 이외의 추가적인 변경이나 정보를 맵핑해 타겟 데이터베이스에 반영할 수 있는 트랜스포메이션(transformation) 기능도 지원한다.

<그림 2> 스트림 아키텍처

<그림 3> 3대 기본 요소

캡처
원래 오라클 데이터베이스의 변경은 모두 리두 로그 파일로 기록된다. 이 리두 로그 파일은 향후 복구시 이용될 수 있도록 데이터베이스의 변경 내역을 담고 있으며, 또 아카이브 프로세스에 의해서 리두 로그 파일이 arch 로그 파일로 복사된다.

캡처 프로세스는 소스 데이터베이스의 리두 로그 & 아카이브 로그의의 변동 사항을 읽어서 등록된 객체의 변경사항(DML, DDL)이 있으면 리두 로그 포맷을 LCR 포맷으로 변경해 송신 큐에 넣어 주는 역할을 한다. 즉 리두 로그 파일에 있는 변경된 사항만을 캡처해 LCR이라는 형태로 변환시켜 송신 큐에 넣어주는 역할을 하며 캡처 시작(capture start)에 의해서 ora_cnnn_sid라는 백그라운드 프로세스가 실질적인 작업을 한다. 캡처 프로세스는 buffered 큐 형태의 Sys.AnyData라는 데이터 타입을 이용해 LCR 형태로 저장한다. 스트림에서는 모든 사용자 메시지를 SYS.AnyData 타입으로 랩핑(wrapping)해 전달한다.

<그림 4> 캡처 프로세스

◆ 캡처 진행 과정
[1] 사용자에 의해서 dept 테이블에 변경 요청이 들어옴
[2] 오라클 DBMS는 dept 테이블을 수정하고, 그와 동시에 리두 로그 파일에도 그 내용을 저장함
[3] 캡처 프로세스는 리두 로그 파일을 분석해 LCR 포맷의 형태로 전환해 SGA 메모리 영역의 buffered 큐에 저장함(ora_cnnn_sid).
[4] 캡처할 때 규칙에 의한 평가, 변환 작업을 수행할 수도 있다(evaluation & transformation).

Staging & Propagation
소스 데이터베이스 대기열의 변경 사항을 도착지 데이터베이스의 대기열로 전달한다. 도착지(destination) 데이터베이스의 큐에 반영하기 위해 스케줄링을 한다. Staging area는 캡처된 이벤트에 대한 저장, 관리 서비스를 제공하는 큐 매커니즘이다. 동일한 데이터베이스나 다른 데이터베이스에 존재하는 또 다른 staging area로 전달(propagation)될 수 있으며 네트워크 라우팅의 간소화와 트래픽의 감소를 위해 모든 데이터베이스와 애플리케이션에 바로 보낼 필요 없이 일단 일종의 허브 데이터베이스(실제로 적용은 하지 않는)로 전달할 수 있다.

일반적인 큐잉 시스템이 제공하는 데이터의 유실(loss)을 절대로 허용하지 않기 때문에 도착지 사이트에 전달되기 전까지는 큐에 남아있어 데이터 유실이 전혀 있을 수 없다. 또한 표준 방식을 통해 핸들링되므로 PL/SQL, JMS, OCI 프로그래밍 등 일반적인 프로그래밍 방식을 통해서 사용자 프로그램이 enqueue 메시지 처리를 할 수 있다.

<그림 5> 소스 큐와 Destination 큐

◆ Propagation의 진행 과정
[1] 캡처에 의해서 만들어진 LCR 포맷 데이터나 사용자 프로그램에 의해서 만들어진 사용자 메시지가 큐에 저장된다.
[2] DBMS_job 또는 DBMS_schedule에 의해 등록된 propagation을 처리하는 job이 설정된 값에 따라(1초부터 초단위로 간격 조정 가능) 큐에서 데이터를 읽어 목적지(도착지) 시스템의 큐에 짚어 넣는다.
[3] 이때 사용되는 큐 테이블은 SGA의 메모리 영역에 있는 것으로서 메모리 사이의 I/O를 수행하기 때문에 빠른 처리 속도를 가진다. 만약 할당된 메모리 영역이 부족할 경우는 스트림을 지원하는 테이블스페이스(디스크)에 저장되어, 데이터 유실이 없도록 하는 안정장치를 갖고 있다. 메모리에서 propagation 작업이 이뤄지다가 아직 도착하지 못한 데이터가 있는 상태에서 DBMS의 갑작스런 정지 상황이 생기면 다시 startup될 때 캡처 프로세스에 의해서 소스 큐에 미 전달된 데이터의 정보를 파악해 다시 큐잉 작업을 수행해 도착지 DBMS에 가는 작업을 자동적으로 수행한다.

APPLY
Staging area에 있는 이벤트는 apply 프로세스에 의해 소비(consumption)되어, 데이터베이스 내에서 SQL문 형태로 적용되던지, 또는 사용자 메시지의 경우 애플리케이션에 의해서 도착지 데이터베이스에 적용된다. 이때 빠른 처리를 위해서 병렬 apply 서버 셋업이 가능하다.

결국 범용적인 표준을 따르는 큐에서 데이터를 추출해서 적용하는 것이므로, JMS, C, C++, PLSQL, SOAP (XML/HTTP) 등 어떠한 프로그래밍 방법을 통해서 적용되는 것이 가능하다. 원본 데이터베이스에서 변경된 레코드를 도착지 데이터베이스에서 적용하려고 할 때, 두 데이터를 동시에 변경하면 충돌이 일어날 경우가 있는데, 이 경우 자동적으로 데이터 충돌을 확인해 만약 미리 정의된 해결 루틴이 있다면 그 방법대로 적용하고 해결 루틴이 실패한다면 에러 큐에 저장해 어떠한 경우라도 데이터의 유실이 없도록 한다.

<그림 6> Apply 프로세스

◆ apply 진행 과정
[1] propagation 프로세스에 의해서 도착지 서버의 큐에 도달한 데이터를 apply 프로세스에 의해서 도착지 데이터베이스에 적용한다(ora_annn_SID).
[2] 이때 apply에서 적용하는 핸들러들에 의해서 각 단계나 액션별로 특정 로직을 첨가해 적용되는 데이터에 대한 조작이 가능하다.
[3] apply 핸들러를 거쳐서 해당 테이블에 최종적으로 적용된다.

Apply 핸들러
핸들러에는 다음과 같은 5가지 사항으로 생각해 볼 수 있다.

[1] 메시지 핸들러 : 사용자 메시지(Non-LCR) 처리를 전용하는 핸들러
[2] Pre-commit 핸들러 : commit시의 로직 처리할 때 사용하는 핸들러
[3] DML/DDL 핸들러 : Insert/update/delete/DDL 처리에 적용하는 핸들러
[4] Conflict 핸들러 : Apply 적용시 발생하는 데이터 충돌을 해결하는 핸들러 정의이다. 즉 여러 가지 발생할 수 있는 에러를 위한 해결 로직을 구현해 발생할 수 있는 에러를 해결할 수 있도록 한다.
[5] 에러 핸들러 : Apply 적용시 발생하는 에러에 대한 처리 로직을 등록해 사용할 수 있다. 다만 에러 핸들러와 DML 핸들러는 동시에 사용할 수 없다.

<그림 7>Apply 핸들러

스트림 적용
데이터 충돌
다음의 <그림 7>과 같이 동시에 서울 데이터베이스와 부산 데이터베이스에서 사원번호가 115번인 사람의 manager_id를 변경했을 경우 서울에서 변경된 사항이 리두 로그에 적용되고 캡처에 의해서 큐에 저장되고, propagation에 의해서 부산 데이터베이스의 큐에 도착하고, apply 프로세스에 의해서 적용되려고 할 때, 이때 부산 데이터베이스의 사원번호 115번이 이미 다른 것으로 변경돼 있는 경우 데이터 충돌이 발생한다.

<그림 8> 서울과 부산에서의 스트림 적용

<그림 9>오라클 다운 스트림

좀 더 자세히 살펴보면 다음과 같다.

[1] 소스 사이트에서 데이터를 가져올 때부터 변경되기 전인 old value(manager_id= 100이라고 가정)와 변경된 후인 new value(manager_id=120) 둘 다의 정보(old, new)를 갖고 타겟 사이트로 온다.
[2] 타겟 사이트에서 해당 건(사원번호 115번)의 현재 value(manager_id=108)와 old value(manager_id=100)를 비교한다.
[3] 만약 매치한다면 new value로 적용한다.
[4] 만약 매치가 되지 않는다면, conflict resolution 메쏘드를 이용해 적용을 시도한다. 이때 사용하는 resolution 메쏘드는 timestamp 방식(시간 기준), maximum/minimum value 방식, overwrite(소스 사이트 우선), discard(타겟 사이트 우선), user defined 방식이 있다.
[5] 만약 resolution 메쏘드로 해결되지 않거나 해결 루틴 자체가 없을 경우 정상적으로 적용되지 못하므로 에러 큐에 저장되어져 DBA의 수동적인 처리를 따르게 된다.

또한 스트림의 적용 환경은 다음과 같다.

[1] 오라클9i R2 이상 버전(9.2.0.3 이상 추천), 특히 오라클10g에서는 다운 스트림이 적용 가능
스트림은 오라클9i R2의 기본 기능으로 오라클9i R2를 설치하면 스트림을 사용할 수 있는 소프트웨어 및 데이터베이스 내부의 객체는 모두 설치된다. 즉 다른 스크립트를 수행해줄 필요가 없으며 DBMS 설치 후 즉시 사용 가능하며, DBMS 기본 기능임으로 추가적인 비용이 들지 않는다.
[2] 아카이브 로그 모드로 셋업
캡처 프로세스는 일반적으로 온라인 리두 로그를 읽어서 변경을 Capturing하지만 RAC 환경이나 캡처 프로세스가 다운된 후 재 시작될 때 아카이브 로그 파일을 액세스하는 경우가 있다. 그러므로 소스가 되는 데이터베이스는 반드시 아카이브 로그로 운영되어야 한다.
[3] Initialization 파라미터
Global_names = true(네트워크상에서 unique 오라클을 설정하기 위해 db link를 생성할 때 리모트 데이터베이스의 global_name으로 만들도록 제약을 가하는 파라미터)

다운 스트림
오라클9i R2에 소개된 스트림은 소스 사이트에서 Capturing을 해 타겟으로 전달해 타겟 사이트가 적용하는 방식의 구조이다. 이 경우 보통 소스 사이트는 주요한 레거시 업무를 처리하고, 타겟 사이트는 DW 등과 같은 쿼리 전용 업무를 운영할 경우가 많다. 주요한 레거시 시스템의 캡처 부하를 없애기 위해서 오라클10g부터는 타겟 사이트에서 직접 캡처를 할 수 있는 다운 스트림 캡처를 제공하기 때문에 소스 사이트의 부하를 획기적으로 줄였다.

[1] 처리 방식
로그 트랜스포트 메쏘드(Log transport method)나 FTP와 유사한 방식으로 소스 사이트의 리두 로그를 타겟 사이트로 이동한 후 캡처하는 것이다. 고로 연관된 객체, logminer session, queues, rules, capture process가 타겟 사이트에 생성된다. 특히 소스 사이트에서 하는 일은 리두 로그를 타겟 사이트로 이동시키는 것만 담당하기 때문에 시스템 부하가 거의 없다.

[2] 장점
소스 사이트의 부하를 거의 완전히 없앨 수 있다. 또한 캡처 프로세스 관리가 용이하다(여러 개의 다른 소스 사이트의 로그를 캡처하고 제어할 수 있음). 그리고 소스 사이트의 장애에 대한 추가적인 보호 장치로서 역할을 한다.

[3] 제약 사항
리두 로그 파일, 아카이브 로그 파일을 다른 시스템으로 전송해야 하므로 같은 OS, 오라클10g이어야 한다. 단, 다운 스트림 후 또 다른 타겟 사이트에 전송한다면 스트림의 일반 특성과 마찬가지로 같은 OS일 필요는 없다.

◆ Support 타입
[1] support datatype
CHAR , NCHAR
VARCHAR2, NVARCHAR2,
NUMBER,
DATE,
RAW,
BLOB, CLOB , NCLOB
TIMESTAMP
LONG, LONG RAW, UROWID columns
UROWID columns
BINARY_FLOAT and BINARY_DOUBLE columns -- 오라클10g부터 생긴 데이터 타입
Index organized tables (IOTs): 예외 LOB, overflow segment, partition IOT,
Tables that use function-based & descending indexes

[2] Unsupport datatype
BFILE, Unicode CLOBs,
ROWID
Changes to SYS objects, Changes to SYSTEM objects,
Temporary Objects,
Simple and nested user-defined datatypes,
Collections (REFs, nested tables and VARRAYs),
XML Type,
Object REFs,
CREATE TABLE AS SELECT of a table with a clustered key,
Spatial datatypes

데이터 공유 기술 중 최고의 기능을 활용
데이터 공유의 요구가 증가하는 IT 환경에서 오라클의 스트림 기술은 기본적으로 DB 기본 기능에 포함되어 있으므로, 비용이 추가적으로 더 들지 않으면서도 데이터 통합, 데이터 공유의 요구를 완벽히 이룰 수 있다. 더군다나 빠른 처리 메커니즘이나 아주 유연한 변환 기능은 다른 상용 제품을 완전히 대체할 수 있다. 데이터 통합이 주요한 이슈이거나, 기존 시스템에 부하 없이 데이터를 가져오고 싶을 때 활용할 수 있으며, 오라클 데이터 공유 기술 중에 최고의 성능과 기능을 가진 오라클 스트림을 많이 활용해 보길 바란다.

그리드 컴퓨팅 적용으로 IT 과제 해결
TenG 주식회사의 ‘그리드 TFT 팀’은 IT 시스템을 오라클10g를 적용하기로 결정해 나가는 과정에서 여러 기술적인 요건을 살펴봤다. 또한 그리드 컴퓨팅에 대해 다양한 개념을 접하고 있는 상태이다. 온 디맨드 비즈니스, 어댑티브 비즈니스, 유틸리티 컴퓨팅 등 많은 새로운 컴퓨팅 환경 중에 유독 ‘그리드 컴퓨팅’이 가장 주목받고 있는 이유는 무엇인가? 그 배경에는 크게 두 가지 이유가 있다. 첫 번째는 자원의 효과적 활용, 두 번째는 IT의 복잡성을 줄일 수 있기 때문이다.

첫 번째, ‘자원의 효율적 활용’은 그리드 컴퓨팅의 기본 개념이라고 볼 수 있다. 즉 표준화되고 모듈화된 스토리지와 서버들을 하나의 풀(pool)로 만들어 놓고 이를 총체적으로 자동 관리하도록 한다는 것이다. 두 번째 ‘IT의 복잡성을 줄인다’는 측면에서 봐도 그리드 컴퓨팅은 IT 인프라의 고립화, 복잡화의 문제점을 해결해 줄 수 있는 실현 가능한 대안이 되고 있는 것이다.

<그림 10> 인포메이션 아키텍처와 그리드 컴퓨팅과의 관계

이와 같이 데이터베이스 선택 기준이 그리드 컴퓨팅이 되는 것이다. 오라클10g는 그리드의 개념을 데이터베이스 선택기준으로 제시하며 다음과 같은 특성이 기업의 기존 인프라를 그리드 환경으로 전환하도록 지원한다.

[1] 프로비저닝
[2] 리소스 풀링 및 가상화
[3] 양질의 서비스
[4] 관리의 편이성

<표 1> 그리드 컴퓨팅을 통한 기업 IT 과제의 해결

TenG 주식회사와 같이 시스템 중단이 없는 기업 인프라를 갖추고자 한다면 인포메이션 아키텍처를 구성하면서 향후 컴퓨팅 환경의 가장 주요한 변환 추세인 그리드 컴퓨팅을 기업 내에 적용해 나가며 <표 1>과 같은 IT 과제를 해결할 수 있을 것이다. @

[Replication vs. 스트림]

시스템 오버헤드의 감소 이전의 replication 방식은 복제가 설정된 테이블 하나하나 마다 inner-trigger, 패키지를 이용해 트랜잭션이 발생할 때마다 inner-trigger, 패키지가 구동되는 메커니즘을 갖고 있어 오버헤드를 수반하는 방식이었다. 그러나 스트림 방식은 DB 운영 중에 기본적으로 생기는 리두 로그 파일에서 변경된 것만 캡처하고, 또한 데이터베이스 코어 프로세스가 아닌 별도의 캡처 프로세스를 활용함으로 시스템의 로드를 줄인다. 또한 매번 발생하는 트랜잭션마다의 처리가 아니라 리두 로그 파일 단위의 async한 처리 위주임으로 일의 양이 대폭 줄어든다. 더군다나 오라클10g의 다운 스트림을 이용한다면 시스템의 오버헤드를 더 줄일 수 있다. exp/imp/data pump 사용 가능 이전의 replication 방식은 새로운 사이트가 생기거나 데이터를 이동할 경우 exp/imp 등과 같은 bulk 작업이 원활 하지 않았으나, 스트림은 exp/imp/data pump와 같은 기능들을 아무런 제한 없이 사용하는 것이 가능하다. 이전에는 100만건 정도의 데이터를 초기 셋업하는데 10시간 정도 걸렸다면, 스트림에서 pump를 사용하면 1분 이내에 처리가 될 수 있다. transformation 기능 제공 이전의 replication 방식은 단순한 데이터 복제를 하거나 부분 집합 정도의 처리밖에 하지 못했으나, 스트림은 transformation 기능을 이용하거나 apply시 핸들러를 이용한 로직 처리를 통해서 데이터 포맷의 변경, 데이터 처리의 변환까지 가능하다. 데이터 integrate 차원의 기능을 지원한다. DDL 처리시에도 복제 가능 이전의 replication 방식은 멀티 마스터 환경에서만 DDL 변경이 가능했고, 또 이 경우에도 복제 환경을 정지시키고서야 가능했다. 그러나 스트림에서는 복제 환경이 계속되고 있는 상태에서 DDL 처리를 할 수 있다. 이전 방식의 셋업 환경보다 획기적으로 개선됐다. 다른 데이터베이스와 강력한 통합 이전의 replication 방식에서도 이기종과의 통합이 가능했으나 그 제약사항이 많았다. 그러나 스트림에서는 transparent 게이트웨이 및 generic connectivity를 이용해 이기종 DBMS와의 연동을 아주 쉽고 강력하게 이룰 수 있다. 이기종 DBMS에서 어댑터 프로그램을 이용하거나 사용자 프로그램을 이용해서 데이터를 캡처해 낼 수도 있으며, apply시 게이트웨이나 자바 프로그램을 통해서 이기종 DBMS에 적용시키는 것도 가능하다.