달력

3

« 2024/3 »

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
2013. 4. 30. 14:46

테이블 데이터 복사 그거/DB2013. 4. 30. 14:46

A 테이블

ID        VARCHAR2 (63) NOT NULL,

CONTENT   VARCHAR2 (1000) NOT NULL,

CRE_DATE      DATE NOT NULL,

UPD_DATE      DATE NOT NULL,

TYPE      VARCHAR2 (5) NOT NULL,

USER_ID       VARCHAR2 (63),

GUBUN     CHAR (1),

ETC           VARCHAR2 (10),

DOMAIN_ID     VARCHAR2 (63) DEFAULT 'DEFAULT' NOT NULL


A 테이블의 데이터

ID 

CONTENT 

CRE_DATE 

UPD_DATE 

TYPE 

USER_ID 

GUBUN 

ETC 

DOMAIN_ID 

 EX00001

내용 

2013/04/30 

 2013/04/30

 ERROR

LUCKY 

DOMAIN1 

 EX00002

내용 

2013/04/30 

 2013/04/30 

 ERROR

 LUCKY 

U

N

DOMAIN2 

... 

... 

... 

... 

... 

 ...

 ...

 ...

.. 

 EX00100

 내용 

 2013/04/30 

 2013/04/30 

 ERROR

 LUCKY 

U

N

DOMAIN1 



위와 같은 상황에서


A 테이블의 데이터 중에 DOMAIN_ID 가 'DOMAIN1' 인 데이터를 B 테이블을 새로 만들어서 복사하고자 할 경우


create table B 

as

select 

ID, CONTENT, CRE_DATE, UPD_DATE, TYPE, USER_ID, GUBUN, ETC, DOMAIN_ID

from A where domain_id = 'DOMAIN1'


구문을 사용하면 된다.



이걸 이용해서, A 테이블에서 DOMAIN_ID 가 'DOMAIN1' 인 데이터에 대해서 

DOMAIN_ID 를 'DOMAIN2' 로 A 테이블에 복사하고자 할 경우에는


1. DOMAIN1 데이터를 B 테이블에 임시 복사

2. B 테이블의 데이터를 A 테이블에 DOMAIN2 로 변경해서 복사


를 하면 된다.



QUERY 는 아래처럼~


create table B as select * from a where domain_id = 'DOMAIN1';

insert into A values(id, content, cre_date, upd_date, type, user_id, gubun, etc, domain_id)

   select id, content, sysdate, sysdate, type, user_id, gubun, etc, 'DOMAIN2' from B;


==> 더 간단하게는... 아래와 같이~



insert into A values(id, content, cre_date, upd_date, type, user_id, gubun, etc, domain_id)

   select id, content, sysdate, sysdate, type, user_id, gubun, etc, 'DOMAIN2' from A where domain_id = 'DOMAIN1';



:
Posted by 뽀기
2012. 1. 31. 15:28

Oracle 11g EM 비밀번호 만료 오류 그거/DB2012. 1. 31. 15:28


1. 우선 sqlplus로 접속합니다.(dba 권한이 있는 user 로)

sqlplus "system/password"



2. 계정의 상태를 확인합니다.

SQL> select * from dba_users;

USERNAME    ACCOUNT_STATUS    EXPIRY_DATE
SYSMAN         EXPIRED                   2012.01.03
DBSNMP         EXPIRED                   2012.01.03


3. 위 두계정의 잠금을 풀어줍니다.

SQL> alter user sysman identified by 'new password';
SQL> alter user dbsnmp identified by 'new password';



끝!!!!!
 
:
Posted by 뽀기

oracle 11g 를 설치해서 쓰던 도중...

"비밀번호가 만료되었습니다." 라고 에러가 나서 확인해보니...

따로 설정을 바꾸지 않는 이상 기본으로 180일의 비밀번호 만료 기간이 설정된다고 하는군요!

SQL> SELECT RESOURCE_NAME, LIMIT FROM DBA_PROFILES WHERE PROFILE='DEFAULT';

RESOURCE_NAME                    LIMIT
-------------------------------- ----------------------------------------
.......

PASSWORD_LIFE_TIME               180

.......

PASSWORD_GRACE_TIME              7
바로 PASSWORD_LIFE_TIME               180 요 부분입니다.

아래와  같이 변경해줍니다.
SQL> ALTER PROFILE DEFAULT LIMIT PASSWORD_LIFE_TIME UNLIMITED;

프로파일이 변경되었습니다.

이미 비밀번호가 만료된 사용자는 다음과 같이 확인할 수 있습니다.
SQL> SELECT USERNAME, ACCOUNT_STATUS, LOCK_DATE, EXPIRY_DATE FROM DBA_USERS WHERE USERNAME='USERNAME';

USERNAME                       ACCOUNT_STATUS                   LOCK_DAT
------------------------------ -------------------------------- --------
EXPIRY_D
--------
USERNAME                       EXPIRED
11/10/04

이 사용자는 아래와 같이 비밀번호를 변경하여 줍니다.
SQL> alter user USERNAME identified by USERNAME;
사용자가 변경되었습니다.

비밀번호 만료가 해제됐는지 확인해봅니다.
SQL> SELECT USERNAME, ACCOUNT_STATUS, LOCK_DATE, EXPIRY_DATE FROM DBA_USERS WHERE USERNAME='USERNAME';

USERNAME                       ACCOUNT_STATUS                   LOCK_DAT
------------------------------ -------------------------------- --------
EXPIRY_D
--------
USERNAME                       OPEN

'그거 > DB' 카테고리의 다른 글

테이블 데이터 복사  (0) 2013.04.30
Oracle 11g EM 비밀번호 만료 오류  (0) 2012.01.31
파티션 테이블 조회하기  (0) 2011.07.26
[DB] MSSQL 실행된 쿼리 조회하기...  (0) 2010.01.29
MSSQL 에서 페이징하기  (0) 2009.07.06
:
Posted by 뽀기
Oracle9i JDBC Developer's Guide and Reference
Release 2 (9.2)


테스트 할 일이 있어서 오랜만에 JDBC 로 select / update 하는 걸 만들어서 돌렸는데...

con.setAutoCommit(false);


이렇게 설정을 해 놓고...

select 를 하고, update 하는 코딩을 하고.

실제 돌기 전에 테스트를 하려고, 마지막에 rollback/commit 을 넣지 않고. 

 
그냥 돌려봤는데......

헐.. update 한 것들의 commit 이 되어 버렸다는...

이건 무슨 상황인지..

분명히 auto commit 은 disabled 해놨고, 코드 끝에 commit 이란걸 하지도 않았는데 

왜 자동 커밋이 되버리냐고 -_-;

내가 알던 것과 다른 상황이 벌어져서 한~~참을 뻘짓거리 하면서 뒤져봤더니..

Oracle9i JDBC Developer's Guide and Reference Release 2 (9.2)   

요 문서를 보면....

Important:
  • If auto-commit mode is disabled and you close the connection without explicitly committing or rolling back your last changes, then an implicit COMMIT operation is executed.
  • Any DDL operation, such as CREATE or ALTER, always includes an implicit COMMIT. If auto-commit mode is disabled, this implicit COMMIT will not only commit the DDL statement, but also any pending DML operations that had not yet been explicitly committed or rolled back.

 
이렇게 씌여져 있었다는.

즉,
 

"auto-commit 을 disabled 한 상태에서 명시적으로 commit/rollback 을 호출하지 않으면 자동으로 commit 이 되버린다"

 
허.. 왜 몰랐을까 ㅜㅜ 
:
Posted by 뽀기
2010. 1. 29. 18:59

[DB] MSSQL 실행된 쿼리 조회하기... 그거/DB2010. 1. 29. 18:59


오라클의 archive를 조회하는 것 처럼.

MSSQL에서도 이미 실행된 쿼리들을 조회할 수 있답니다.


select
db_name(st.dbid) DBName
,qs.total_elapsed_time
,creation_time
,last_execution_time,text
from sys.dm_exec_query_stats qs cross apply sys.dm_exec_sql_text(qs.plan_handle)st
join sys.dm_exec_cached_plans cp on qs.plan_handle = cp.plan_handle
where creation_time >= '2010-01-01 00:00:00'
--and db_name(st.dbid) is not null and cp.objtype = 'proc' --조건: 종류
and text like '%delete%'
order by last_execution_time desc;

이렇게 하면 된답니다.

실행된 파라미터까지 정확히 나오지는 않는듯 합니다.....
@1 이런식으로 나오네요..

:
Posted by 뽀기
2007. 1. 29. 14:59

자주 참조하는 딕셔너리 그거/DB2007. 1. 29. 14:59


분류

성능뷰 / 딕셔너리

딕셔너리

세션과 관련된 정보

V$SESSION

세션에 대한 전반적인 정보를 보여준다

V$SESSSTAT

세션의 현황에 대한 통계정보를 보여준다

V$SESSION_WAIT

세션의 WAITING 통계정보를 보여준다

V$SESSION_EVENT

세션의 현재 WATING EVENT를 보여준다

V$SESS_IO

세션의 IO현황을 보여준다

V$STATNAME

SESSSTAT STATUS의 이름을 보여준다.

성능 관련 정보

V$SYSTAT

시스템 전반의 성능 통계 정보를 보여준다

V$SYSTEM_EVENT

시스템의 WATING EVENT별 통계정보를 보여준다

V$LIBRARYCACHE

라이브러리 캐쉬 사용 정보를 보여준다.

V$ROWCACHE

데이터 딕셔너리의 사용정보를 보여준다

V$LATCH

LATCH에 대한 정보를 보여준다

V$LOCK

LOCK에 대한 정보를 보여준다

V$LOCKED_OBJECT

LOCK이 걸린 오브젝트에 대한 정보를 보여준다

V$SQLAREA

SQLAREA에 대한 정보를 보여준다

V$WAITSTAT

시스템의 현재 Waiting현황을 보여준다

SQL관련

V$SQL

Parse SQL문장을 보여줌

V$SQLTEXT

라인별로 SQL문장을 보여줌

V$SQLTEXT_WITH_NEWLINES

NewLine을 포함하여 SQL문장을 보여줌

시스템
구성정보

V$SGA

SGA 의 정보를 보여준다

V$PARAMETER

InitSID.ora 등에서 설정된 파라메터, 즉 데이터베이스의 구동되었을 때의 환경 파라메터 정보이다

V$CONTROLFILE

Control 파일에 대한 정보를 보여준다.

V$DATAFILE

데이터 파일에 대한 정보를 보여준다.

V$LOG, V$LOGFILE

리두 로그에 대한 정보를 보여준다.

USER

DBA_USERS

데이터베이스 USER에 대한 정보를 보여준다

권한

DBA_ROLES

ROLE에 대한 정보를 보여준다.

DBA_TAB_PRIVS

테이블에 대한 권한이 설정된 정보를 보여 준다

DBA_SYS_PRIVS

SYSTEM 권한이 설정된 정보를 보여준다

DBA_ROLE_PRIVS

ROLE에 대한 권한이 설정된 정보를 보여 준다.

DBA_COL_PRIVS

컬럼 단위로 권한이 설정된 정보를 보여준다.

세그먼트&오브젝트

DBA_SEGMENTS

세그먼트(저장공간이 있는 오브젝트)에 대한 정보를 보여준다.

DBA_OBJECTS

모든 오브젝트에 대한 정보를 보여준다.

테이블

스페이스

V$TABLESPACE

테이블 스페이스에 대한 정보를 보여준다.

DBA_TABLESPACES

테이블 스페이스에 대한 정보를 보여준다.

DBA_DATA_FILES

테이블스페이스를 구성하고 있는 데이터 파일에 대한 정보를 보여준다.

DBA_FREE_SPACE

아직 사용되지 않은 영역에 대한 정보를 보여준다.

DBA_EXTENTS

할당된  EXTENT의 정보를 보여준다.

DBA_TS_QUOTAS

QUOTA가 설정된 정보를 보여준다

테이블

DBA_TABLES

테이블에 대한 정보를 보여준다.

DBA_TAB_COLUMNS

테이블을 구성하는 컬럼에 대한 정보를 보여준다

DBA_TAB_COMMENTS

테이블의 설명에 대한 정보를 보여준다

DBA_PART_TABLES

파티션 테이블에 대한 정보를 보여준다.

DBA_PART_KEY_COLUMNS

파티션을 구성하는 기준 컬럼에 대한 정보를 보여준다

DBA_COL_COMMENTS

컬럼에 대한 설명에 대한 정보를 보여 준다

인덱스

DBA_INDEXES

인덱스에 대한 정보를 보여준다.

DBA_PART_INDEXES

파티션된 인덱스에 대한 정보를 보여준다

DBA_IND_COLUMNS

인덱스를 구성하는 컬럼에 대한 정보를 보여준다

CONSTRAINT

DBA_CONSTRAINTS

테이블에 걸려있는 제약조건을 보여준다.

DBA_CONS_COLUMNS

제약조건을 구성하는 컬럼에 대한 조건을 보여준다.

DBA_VIEWS

VIEW를 정의한 정보를 보여준다.

시노님

DBA_SYNONYMS

시노님에 대한 정보를 보여준다.

시퀀스

DBA_SEQUENCES

시퀀스에 대한 정보를 보여준다.

DB LINK

DBA_DB_LINKS

DB 링크에 대한 정의를 보여준다

트리거

DBA_TRIGGERS

트리거에 대한 정의를 보여준다.

DBA_TRIGGER_COLS

컬럼 단위로 작성된 트리거에 대한 정의를 보여준다.

ROLLBACK

DBA_ROLLBACK_SEGS

롤백세그먼트에 대한 정보를 보여 준다.

FUNCTION, PROCEDURE,

PACKAGE

DBA_SOURCE

FUNCTION, PROCEDURE,PACKAGE를 구성하는 PL/SQL 소스코드를 보여준다


(출처: 마소지 2003.09)
:
Posted by 뽀기
오라클 10g와 그리드] 스트림 기능 이용하기

최치영, 정현훈 (한국오라클)

 

최근 흩어져 있는 데이터를 공유하는 것에 대한 논의가 활발히 이뤄지고 있다. 특히 원거리의 분산환경 상의 정보뿐만 아니라 서로 성격을 달리하는 정보들(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으로 만들도록 제약을 가하는 파라미터)


JOB_QUEUE_PROCESSES = 10
AQ_TM_PROCESSES = 2
STREAMS_POOL_SIZE = 200m


다운 스트림
오라클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에 적용시키는 것도 가능하다.

'그거 > DB' 카테고리의 다른 글

TOAD에서 Explain plan 사용하기  (0) 2007.08.02
[Oracle] recursive select  (0) 2007.08.02
테이블의 FK 잠깐 꺼 놓는 방법  (0) 2007.08.01
자주 참조하는 딕셔너리  (0) 2007.01.29
오라클 한글지원 문자타입들  (0) 2007.01.29
:
Posted by 뽀기
2007. 1. 29. 14:56

오라클 한글지원 문자타입들 그거/DB2007. 1. 29. 14:56

한글을 지원하는 characterset 에는 아래의 것들이 있습니다.

KO16KSC5601
- 완성형
- 한글 2350자 지원

KO16MSWIN949
- 일명 확장완성형(MS에서 windows 에 만들어 놓은 codepage)
- 한글 11172자 지원
- 한글 순서가 뒤죽박죽(2350자의 KSC5601 에서 지원하는 글자는 가나다 순이지만 그 외 글자는 남는 코드 여기저기에 들어가 있음)
- 8.0.6 이상에서만 사용가능 (8.0.5 이하 버전과의 db link나 client 가 8.0.5 등인 경우는 문제가 발생)

UTF8
- Unicode의 CES 중 하나(구현방법중 하나라고 생각하면 될 듯)
- ascii는 1byte, 그 외 유럽쪽은 2byte, 아시아는 3byte(CJK)
- 한글 11172자 지원(고어도 지원) 및 가나다 순 정렬
=> '가'와 '나'의 차이와 '나'와 '다'의 차이가 같음. 제대로 된 전화번호부를 만들 수 있을 듯...

AL32UTF8
- Unicode의 CES중 하나(9i부터 나온 것으로 알고 있음)
- Length semantics로 하면 4 byte( varchar2(3 char) 로 하면 12byte, UTF8에서는 9byte로 알고 있음)
- UTF8과 한글지원 부분은 똑같은 것으로 알고 있음.
- 8i는 미지원이므로 db link나 8i client 사용시 정상적 처리 불가

AL16UTF16
- Unicode의 CES중 하나
- national characterset 에서만 선택가능
- 모든 글자를 2byte or 4byte로 표현

고로

용량을 줄이면서 한글표현 다하고 싶고 8.0.5는 없다면 ko16mswin949를,
한글 표현 제대로 하면서 가나다 순으로 제대로 정렬될 필요가 있으면서 8i와 전혀 연동할 계획이 없다면 AL32UTF8,
위와 같지만 8i가 껴있다면 UTF8로 하시는 것이 좋을 듯 합니다.
 
 
OTN 퍼옴..  TUNNEL 님..
:
Posted by 뽀기