아키텍처 입문 - 통합 그거/Architecture2007. 1. 29. 15:07
 |
 |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
'그거 > Architecture' 카테고리의 다른 글
| 아키텍처 입문 - 샘플 프로젝트 (0) | 2007.01.29 |
|---|---|
| 아키텍처 입문 - 자산과 패턴 (0) | 2007.01.29 |
| 아키텍처 입문 - 모델링 (0) | 2007.01.29 |
| 아키텍처 입문 - 요구사항 분석 (0) | 2007.01.29 |
| 아키텍처 입문 - 개요 (0) | 2007.01.29 |
아키텍처 입문 - 자산과 패턴 그거/Architecture2007. 1. 29. 15:07
|
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||
'그거 > Architecture' 카테고리의 다른 글
| 아키텍처 입문 - 샘플 프로젝트 (0) | 2007.01.29 |
|---|---|
| 아키텍처 입문 - 통합 (0) | 2007.01.29 |
| 아키텍처 입문 - 모델링 (0) | 2007.01.29 |
| 아키텍처 입문 - 요구사항 분석 (0) | 2007.01.29 |
| 아키텍처 입문 - 개요 (0) | 2007.01.29 |
아키텍처 입문 - 모델링 그거/Architecture2007. 1. 29. 15:06
|
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
'그거 > Architecture' 카테고리의 다른 글
| 아키텍처 입문 - 샘플 프로젝트 (0) | 2007.01.29 |
|---|---|
| 아키텍처 입문 - 통합 (0) | 2007.01.29 |
| 아키텍처 입문 - 자산과 패턴 (0) | 2007.01.29 |
| 아키텍처 입문 - 요구사항 분석 (0) | 2007.01.29 |
| 아키텍처 입문 - 개요 (0) | 2007.01.29 |
아키텍처 입문 - 요구사항 분석 그거/Architecture2007. 1. 29. 15:05
|
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
'그거 > Architecture' 카테고리의 다른 글
| 아키텍처 입문 - 샘플 프로젝트 (0) | 2007.01.29 |
|---|---|
| 아키텍처 입문 - 통합 (0) | 2007.01.29 |
| 아키텍처 입문 - 자산과 패턴 (0) | 2007.01.29 |
| 아키텍처 입문 - 모델링 (0) | 2007.01.29 |
| 아키텍처 입문 - 개요 (0) | 2007.01.29 |
아키텍처 입문 - 개요 그거/Architecture2007. 1. 29. 15:04
|
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
'그거 > Architecture' 카테고리의 다른 글
| 아키텍처 입문 - 샘플 프로젝트 (0) | 2007.01.29 |
|---|---|
| 아키텍처 입문 - 통합 (0) | 2007.01.29 |
| 아키텍처 입문 - 자산과 패턴 (0) | 2007.01.29 |
| 아키텍처 입문 - 모델링 (0) | 2007.01.29 |
| 아키텍처 입문 - 요구사항 분석 (0) | 2007.01.29 |
자주 참조하는 딕셔너리 그거/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)
'그거 > DB' 카테고리의 다른 글
| TOAD에서 Explain plan 사용하기 (0) | 2007.08.02 |
|---|---|
| [Oracle] recursive select (0) | 2007.08.02 |
| 테이블의 FK 잠깐 꺼 놓는 방법 (0) | 2007.08.01 |
| [오라클 10g와 그리드] 스트림 기능 이용하기 (0) | 2007.01.29 |
| 오라클 한글지원 문자타입들 (0) | 2007.01.29 |
[오라클 10g와 그리드] 스트림 기능 이용하기 그거/DB2007. 1. 29. 14:57
최근 흩어져 있는 데이터를 공유하는 것에 대한 논의가 활발히 이뤄지고 있다. 특히 원거리의 분산환경 상의 정보뿐만 아니라 서로 성격을 달리하는 정보들(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 과제를 해결할 수 있을 것이다. @
| ||||||
| ||||||
|
'그거 > 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 |
오라클 한글지원 문자타입들 그거/DB2007. 1. 29. 14:56
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로 하시는 것이 좋을 듯 합니다.
'그거 > DB' 카테고리의 다른 글
| TOAD에서 Explain plan 사용하기 (0) | 2007.08.02 |
|---|---|
| [Oracle] recursive select (0) | 2007.08.02 |
| 테이블의 FK 잠깐 꺼 놓는 방법 (0) | 2007.08.01 |
| 자주 참조하는 딕셔너리 (0) | 2007.01.29 |
| [오라클 10g와 그리드] 스트림 기능 이용하기 (0) | 2007.01.29 |
서버 설치부터 개발까지「플렉스 활용 가이드」 그거/Issue2007. 1. 29. 14:55
현우성 (드림헌터) 2004/10/26
하루가 다르게 신기술이 쏟아진다. 시시각각 변화하는 IT 환경을 보고 있자면 문득 스펜서 존슨의 「누가 내 치즈를 옮겼을까」라는 책이 떠오른다. 사람들은 변화를 진행하고 있는 일의 일부라고 생각할 뿐 생활의 일부로 받아들이지 않는다. 자신이 하고 있는 일이 언제까지 계속 안정적으로 지속될 수 있을 것인가? 우리는 언제나 변화하고 있는 환경에 대처하는 준비가 필요하다. X인터넷의 활용 가치가 부각되는 요즘 관련 기술들에 대해 조금만 더 귀를 기울여 보자. 준비가 되었다면 지금부터 새로운 치즈인 ‘플렉스’를 향한 여행을 시작해 보자. 플렉스의 설치 플렉스의 탄생과 그 특성에 대해서는 각각 1, 2부에서 살펴봤다. 이 글에서는 플렉스의 설치에 관한 내용부터 접근해 보겠다. 여기서 설치하는 플렉스는 윈도우용 버전이며, 설치 파일은 .exe 파일로 제공되어 더블클릭만으로 쉽게 설치할 수 있다(만약 자바 애플리케이션 서버가 설치되어 있는 상태에서 플렉스를 설치한다면 설치 완료 후 해당 디렉토리에 war 파일의 압축을 풀어 배포하면 된다). 설치 도중 인스톨 옵션을 선택하는 항목이 나타나는데, 기존 자바 애플리케이션 서버가 설치되어 있는 곳에 플렉스를 설치할 것인지 또는 JRun4와 통합된 플렉스를 설치할 것인지를 선택해야 한다. 필자는 JRun4와 통합되어 있는 설치를 선택했다. JRun4와 통합된 플렉스를 설치하면 다음과 같은 폴더가 구성된다. ㅡ /dochome.htm /license.htm /Macromedia_Flex_1.0_InstallLog.log /readme.htm /bin/... /extras/.. /flexforflash/.. /jrun4/bin/.. /jrun4/lib/.. /jrun4/servers/default/flex/.. (exploded flex.war application ? context root) /jrun4/servers/default/profiler/.. (exploded profiler.war application - profiler) /jrun4/servers/default/samples/.. (exploded samples.war application - samples) /lib/.. /UninstallerData/.. JRun4와 통합된 플렉스를 설치하면 war 파일 형태가 아닌 세 개의 폴더(flex, profiler, samples)가 생성되어 시스템에 위치하며, 기본적으로 8700포트가 사용된다. http://locathost:8700/samples 설치가 끝나면 샘플로 제작된 플렉스의 데모를 볼 수 있다. 자세한 설치 관련 사항은 플렉스 인스톨 문서(http://www.macromedia.com/go/flex_install)를 참고하기 바란다. 플렉스에서는 콜드퓨전이나 커뮤니케이션 서버와 같은 어드민 콘솔 형식의 사용자 컨피규레이션 툴은 제공하지 않는다. 서버의 설정은 flex-config 파일을 통해 가능하며, 여기서는 디버깅 정보 생성 여부(프로파일링 포함), 컴포넌트 관련 경로, 웹 서비스나 HTTP 서비스 그리고 리모트 오브젝트, 캐싱, 컴파일러, 플래시 플레이어 자동 감지, 로깅, 폰트 등을 설정할 수 있다. 플렉스 애플리케이션 제작에는 MXML과 액션스크립트가 사용된다. 두 가지의 언어로 작성된 코드는 플렉스 컴파일러에 의해 브라우저가 MXML 파일을 요청할 때 그에 상응하는 swf 파일로 컴파일해 사용자의 브라우저에서 보여진다. 현재 베타 4 테스트 중인 플렉스 빌더 ‘브래디(Brady)’로 제작하면 쉽고 빠르게 제작이 가능하지만, 일반적인 텍스트 에디터나 메모장을 사용해도 상관없다. 물론 자바 개발 툴인 이클립스 등을 사용해도 된다. 플렉스 컴포넌트 흔히 컴포넌트는 프로그램의 꽃이라 비유된다. 컴포넌트의 장점이라 한다면 간단한 설정을 통해 프래그램에서 다양한 효과를 손쉽게 구현할 수 있다는 데에 있다. 플렉스에서 컴포넌트들은 모두 액션스크립트의 MovieClip 클래스로부터 상속받아 사용된다(<그림 1>).
무비클립은 플래시에서 가장 많이 사용되는 요소 중 하나로, 외부로부터 불러들이는 플래시 무비나 그림들은 모두 무비클립 형태로 이용된다. 플렉스 프로그램의 개발시에도 개발자가 직접 만든 플래시 컴포넌트를 플렉스 애플리케이션에서 사용할 수 있다. 그러나 이때에는 작성된 결과물을 일반 swf 파일이 아닌 swc 파일 형식으로 만들어 사용해야 한다. 플래시에서는 컴포넌트의 개념이 스마트클립에서 출발해 MX 버전부터 본격적으로 적용됐다. 따라서 역사가 길다고 할 수는 없으나 유용한 컴포넌트들이 많이 존재한다. 컴포넌트 중 가장 일반적인 UI 컴포넌트 사용 예제를 살펴보자(<리스트 1>).
<리스트 1>에서 컴포넌트의 내부 구성이 어떻게 되어 있는지는 전혀 알 수 없다(컴포넌트를 사용하면 사용자의 간단한 조작으로 원하는 형태의 결과물을 얻을 수 있다. 플렉스에서 사용되는 플래시 컴포넌트는 swc 파일로 존재한다). 몇 줄 되지 않는 코드에서 보여지는 화면은 정말 흥미롭다. 앞에서도 언급했듯 플렉스 컴포넌트는 무비클립 클래스에 기반을 두고 있다. 무비클립 클래스에 대한 자세한 내용은 「Flex ActionScript and MXML API Reference」를 참조하기 바란다.
플렉스 컨트롤 컨트롤은 UI 컴포넌트의 컨트롤을 의미한다. 여기서는 Checkbox, Button, Text Area, 그리고 Combobox 컨트롤에 대해서 알아보자. 플렉스에서는 기본적인 컨트롤(버튼, 체크박스, 라디오 버튼 등)과 데이터 프로바이더 컨트롤(리스트, 트리, 콤보박스 등)을 제공한다.
<리스트 2>에서 데이터 ComboBox 컨트롤에 데이터를 넣는 법, CDATA 섹션을 사용해 데이터를 처리하는 부분, MXML에서 Action 함수를 호출하는 부분은 유심히 봐야 한다. 기존의 데이터 ComboBox에 데이터를 설정하는 방법은 두 가지로 분류했다. colorCombo ComboBox에는 MXML 코드에서 직접 데이터를 넣었고, cityCombo ComboBox에는 프로그램적인 요소가 섞여 있을 경우 액션스크립트를 사용해 처리했다. 만일 XML 파서가 액션스크립트 구문 안에 ‘{‘ 나 ‘<’ 같은 문자들을 XML 코드로 인식해 파싱하게 되면 에러가 발생한다. 이런 경우에는 CDATA 섹션을 사용해 파싱하지 않고 파서에 넘겨주는 방법을 사용하며, 일반적으로 액션스크립트 블럭은 CDATA섹션으로 감싸주는 것이 좋다.
컨테이너 사용 컨테이너란 컴포넌트가 실행되는 것으로 알려져 있는 프로그램 빌딩 블럭 내의 애플리케이션이나 서브시스템을 말한다. 플렉스에서 컨테이너의 개념은 컨트롤을 담는 컴포넌트를 일컫는다. 보통 웹 프로그램에서는 화면을 프레임, 테이블 등으로 구성하지만 일반 윈도우 응용 프로그램 작성시에는 panel이나 Group Box 등을 이용해 화면을 구성하게 된다. 얼마 전 후배가 델파이로 작성된 프로그램을 갑자기 수정해야 할 일이 생겼다며 필자를 찾아 온 적이 있었다. 이 후배는 ASP, PHP, JSP 등 웹 프로그램만을 하다가 윈도우 응용 프로그램은 처음 접한 상황이었다. 그 후배가 필자를 급히 찾았던 이유는 기존에 구성된 폼에 패널을 추가해 화면을 재구성하는 내용이었다. 플래시는 Panel이나 Canvas 등을 사용해 화면을 구성하는 개념 없이 무비를 구성한다. 이 때문에 플렉스에서 컨테이너를 구성과 배치하는 것이 어색하게 느껴질 수도 있을 것이다. 가장 좋은 방법은 머릿속에 화면 구성을 생각해 놓고 자신이 생각한 그대로를 만들어 보는 것이다. 플렉스에서 컨테이너를 사용해 구성한 예제를 살펴보자(<리스트 3>).
Panel 안에 Horizonatl divider로 좌우를 나눈 다음 좌측은 Tree가 위치하고, 우측은 다시 Tab TabNavigator로 나누었다. 오른쪽의 Tree 메뉴에서는 XML 파일에서 데이터를 읽어와 Tree 메뉴를 구성했다. 컨테이너를 사용해 화면을 구성할 때에는 일반 메모장이나 에디터 프로그램보다는 ‘브래디’를 활용하는 것이 더욱 편리하다. 마치 HTML로 화면 구성시 드림위버를 사용하는 것에 비유할 수 있다.
이벤트 사용 이벤트란 프로그램에 의해 감지되는 어떤 행동이나 발생된 사건 등을 가리킨다. 예를 들어 마우스 단추나 키보드 키를 누르는 것과 같이 사용자에 의해 발생하는 행위뿐 아니라, 특정 조건에 의해 시스템에서 발생한 일들도 이벤트로 간주된다. 대부분의 최신 응용 프로그램들은 이벤트에 반응하도록 설계되어 있기 때문에 프로그램을 만드는 데 있어 이벤트처리는 매우 중요하다. 플렉스 애플리케이션 역시 이벤트 처리가 중요한 것은 말할 것도 없다. 플렉스 애플리케이션에서는 액션스크립트를 사용해 발생되는 이벤트를 처리한다. <mx:Script> <![CDATA[ function btnClick(){ alert("button Click"); } ]]> </mx:Script> <mx:Button label="click me" id="btn" click="btnClick()"/> <리스트 4>는 기본적인 버튼 이벤트의 구성이다. 사용자가 버튼을 클릭하면 btnClick 함수를 호출한다. 여기서 MXML 파일에서 click 이벤트를 호출하는 방법은 자바스크립트의 문법과 거의 유사하다. ComboBox에 두 가지의 이벤트가 사용됐다. 콤보박스가 열릴 때 openEvt() 함수를 호출하고, 내용이 바뀔 때 changeEvt()가 실행되어 Object를 인자로 넘긴다.
<리스트 5>는 이벤트 리스너를 사용한 이벤트 처리 예제이다. 이벤트 리스너는 함수가 아닌 객체이므로 객체를 생성한 다음 addEventListener 메쏘드로 해당 이벤트를 추가한 후 사용해야 한다.
스타일 사용 플렉스 컴포넌트의 외형을 바꾸기 위해서는 스타일 프로퍼티를 사용해야 한다. 프로퍼티로는 크기, 폰트, 라벨 컨트롤 또는 배경색을 수정하는 데 사용되며, 한번 정의된 스타일을 이용해 모든 타입과 클래스에 이 속성을 적용시킬 수 있다. 또한 이 속성을 이용해 사용자가 적용하고 싶은 곳에만 스타일을 적용시킬 수도 있어 사용자가 애플리케이션을 제작할 때 매우 유연하게 컨트롤할 수 있다. <mx:Style> .myFontStyle{fontSize : 15} </mx:Style> <mx:Button id = "myButton" label="Click"> 일반적으로 이 방법은 해당 파일에만 스타일을 적용할 경우 사용되며,
스타일 프로퍼티를 직접 제어하는 방법은 mx.styles.StyleMamager.styles.style_name.property=“value”;과 같다. 글로벌한 스타일을 적용시킬 경우에는 타입과 클래스를 선택해서 적용시킬 수 있다. // 타입 선택의 경우 : 모든 툴 팁에 적용됨 mx.styles.StyleManager.styles.ToolTip.fontWeight = “bold”; // 클래스 선택의 경우 : 스타일 이름이 myStyle인 모든 컨트롤에 적용됨 mx.styles.StyleManager.styles.myStyle.fontWeight = “bold”; 다음은 setStyle()과 getStyle 메쏘드를 적용시킨 예제이다. // ex_style.mxml <?xml version="1.0" encoding="utf-8"?> <mx:Application xmlns:mx="http://www.macromedia.com/2003/mxml"> <mx:Style> .myClass{ <!?사용자 스타일 클래스 정의--> fontFamily : Arial, Helvetica, "_sans"; color:Red; fontSize: 22; fontWeight:bold;} Button {fontSize : 10pt ; color:Blue} </mx:Style> <mx:Script> <![CDATA[function setNewStyles(newSize){ <!? ip1 텍스트의 폰트 크기를 적용하고 해당 값을 lb1 텍스트에 출력한다. ip1.setStyle("fontSize",newSize); lb1.text=ip1.getStyle("fontSize"); } function readStyle(){ myLabel.text = "style : "+myLabel.fontStyle; <!?myLable 텍스트의 폰트 스타일을 읽어 출력한다. --> } ]]> … 스타일시트가 적용되는 우선 순위는 <그림 2>와 같다. ◆ 해당 코드 라인에 정의된 경우 : ◆ setSyle() 메쏘드가 정의된 경우 : btn1.setStyle(“color”, “red”) ◆ 인스턴스 클래스 선택의 경우 : ◆ 타입 선택의 경우 : Button{ color : red } 또는 StyleManager.styles.Button.setStyle(“color”, “red”) ◆ Global 스타일 타입 선택의 경우 : Global{ color : red } 또는 StyleManager.styles.global.setStyle ("color”, "red”)
드래그 앤 드롭 매니저 사용 리치 인터넷애플리케이션의 장점을 그대로 보여지게 하는 기능 중 하나이다. 컴포넌트 또는 리스트, 이미지 등의 데이터 이동이 마우스의 드래그 앤 드롭만으로 가능하다. <화면 7>에서 볼 수 있듯이 놀라운 효과의 구성이 플렉스에서는 너무도 간단하게 구현 가능하다.
이 기능을 활용하면 시각적인 효과가 뛰어나고 사용하기 쉬운 애플리케이션을 제작할 수 있다. <리스트 6>은 Canvas 컨테이너에는 드래그가 가능하도록 MouseDown 이벤트를 정의하고, List 컨트롤에는 dragEnter, dragExit, dragOver, dragdrop 이벤트를 정의해 구성된 예제이다.
소스를 하나씩 살펴보자. 사용자가 Canvas 컨테이너를 드래그할 때 dragIt() 함수를 호출하며, 함수 내에 정의된 DragManager 클래스인 dodrag 메쏘드가 실행되어 Canvas가 드레그된다. 이때 드래그된 컨테이너가 타겟 컨테이너 위에 위치하면 dragEnter() 함수가 해당 컨테이너로의 추가 여부를 판단한다. 만일 조건이 성립되면 doDragDrop 함수를 통해 해당 아이템을 추가한다. 또한 doDragDrop() 함수는 doDragOver() 함수에서 데이터의 복사, 링크, 이동 여부를 판단해(함수에서 정의한 대로 <Ctrl> 키를 누르고 타겟 컨테이너 위에 위치하면 복사, <Shift> 키는 링크, 아무런 키의 누름이 없으면 이동으로 처리된다) 각 조건에 맞는 문자열을 List 컨트롤에 추가한다.
액션스크립트 프로파일러 기존의 스크립트 언어에서 코드의 성능 측정(performance profiling)은 거의 불가능한 일이었다. 그러나 플렉스에서는 자신이 만든 프로그램의 성능을 측정할 수 있는 액션스크립트 프로파일러가 존재한다. 프로파일러는 J2SE 1.3 스펙을 지원하는 운영체제와 애플리케이션 서버에서 동작하며, 플래시 플레이어에서 실행되는 액션스크립트의 성능 데이터를 출력하고 리포트 생성기를 통해 출력된 데이터를 바탕으로 보고서를 보여준다(웹 브라우저를 통해 보여진다, http://localhost:8700/profiler). 프로파일러는 플래시 플레이어가 swf 파일을 실행할 때(플래시에서 디버깅 모드로 컴파일해야 한다. 즉 swd 파일이 존재해야 한다) 함수가 실행된다. 이 때 요구되는 시간은 밀리세컨드 단위로 측정하고 파일에 바이너리 포맷으로 시간 데이터를 기록한다. 파일에 기록된 바이너리 데이터는 프로파일링 세션 동안 swf 애플리케이션의 실행 내용을 보여준다. 액션스크립트 프로파일러를 통해 다음과 같은 성능 데이터 측정이 가능하다. ◆ 성능 스냅샷 요약(Performance Snapshot Summary) : 프로파일링 세션 동안 플레이어가 실행하는 모든 함수를 요약해서 보여준다. 요약 보고서는 다른 성능 분석의 시작점이 된다. 이 보고서는 호출 횟수, 누적 시간, 셀프타임 등이 보여진다. 셀프타임(self-time)이란 하나의 메쏘드가 실행되는데 걸린 총 시간을 말하고, 사용자들은 누적 시간 별, 셀프타임 별로 데이터를 정렬할 수 있다. 그리고 요약 보고서에 있는 이름을 클릭함으로써 성능이 좋지 않은 함수를 발견하고 수정 및 보완할 수 있다. ◆ 메쏘드 레벨 통계(Method-Level Statistics) : 한 명의 사용자가 로파일링 세션 동안 플레이어에서 실행하기 위해 선택되는 함수 하나의 통계를 보여준다. 성능 스냅샷 요약과 유사하게 호출 횟수, 누적 시간, 셀프타임을 보여준다. 정렬 기능을 지원하며 사용자들은 다른 메쏘드 레벨 통계로 가기 위해 함수 이름을 클릭할 수 있다. ◆ MXML/액션스크립트 소스 레벨 통계 : 액션스크립트 소스 레벨 통계 페이지는 로파일링 세션 동안 사용자가 선택한 함수의 통계를 보여준다. 이것은 호출 횟수를 라인별로 보여주며, MXML 컴포넌트들의 모든 ◆ 프레임 기반 성능 요약(Frame-Based Performance Summary) : 프로파일링 세션 동안 업데이트되는 프레임 사이에 실행되는 모든 함수의 실행 시간을 보여준다. 그러나 기본적으로 프레임 기반 관점으로 데이터를 보여주는 성능 스냅샷 요약 보고서와 같다. ◆ 비동기 함수 레이턴시(Asynchronous Function Latencies) :모든 네트워크 함수의 지연 시간을 밀리세컨드로 보여준다. 일신우일신 ‘플렉스’ 지금까지 플렉스에서 사용되는 기본 요소들에 대해 간단히 살펴봤다. 매크로미디어는 X인터넷의 선두 주자이며, 그 중 플렉스는 확실히 리치 인터넷 애플리케이션을 쉽고 빠르게 개발하기 위한 좋은 도구임에 틀림없다. 또한 지금 베타 4 테스트중인 플렉스 IDE 툴 ‘브래디’가 정식 발매되어 사용된다면 그 효과는 더할 나위가 없을 것이다. 플래시가 버전을 거듭할수록 언제나 새로운 모습을 보여왔듯 플렉스 역시 계속해서 새로운 모습을 보일 것임을 믿어 의심치 않는다. @ |
'그거 > Issue' 카테고리의 다른 글
| 「동적 웹 페이지 특허」재심 결정 (1) | 2007.02.01 |
|---|---|
| 「HD 포토」포맷, 믿을 건 비스타 밖에 없다 (1) | 2007.01.30 |
| 「액티브X가 뭐길래..」비스타 출시 앞두고 가열찬 논란 (1) | 2007.01.30 |
| ActiveX 문제의 진실 (1) | 2007.01.30 |
| NHN UI Library (0) | 2007.01.29 |
JSP best practices : JSP 태그용 커스텀 애트리뷰트 만들기 그거/Java2007. 1. 29. 14:51
|
태그 기능을 사용자 정의 애트리뷰트로 확장하기 |
|
|
난이도 : 초급 Brett McLaughlin, Author, O'Reilly and Associates 2003 년 8 월 05 일 커스텀 타임-스탬프를 확장하여 페이지 작성자가 자신의 타임-스탬프 포맷을 선택할 수 있도록 하는 방법을 설명한다. 지난 시간에는 JSP 페이지에서 커스텀 태그 라이브러리의 기본적인 사용 방법을 설명했다. 간단한 태그를 정의하고 태그 라이브러리 디스크립터(TLD)를 통해 다른 JSP 작성자까지 사용 할 수 있도록 만들었다. 이번 주에는 커스텀 태그에 대해 알고 있는 지식에 기반하여 구현을 할 것이다. 여기에서 사용할 예제 태그는 매우 간단하다. 따라서 커스텀 애트리뷰트를 결합하여 기능을 확장할 것이다. 예제에 대하여: 이 글에 사용된 모든 예제 코드는 지난 번 우리가 개발한 JSP 태그의 가장 일반적인 요구사항은 페이지로부터 오는 데이터를 받아들이고 그 데이터에 응답할 수 있어야 한다는 것이다. 태그 애트리뷰트로 이 기능을 우리의 커스텀 태그에 결합할 수 있다. 간단한 예제로 "Hello, world" 애플리케이션을 들어보겠다. 이 스크립틀릿의 기능을 구현하는 커스텀 태그를 상상하는 것은 쉽지만 이를 어떻게 확장할 것인가? Listing 1은 전형적인 "Hello, world!"를 결합한 JSP 페이지이다. Listing 1. "Hello, world!" 태그
Listing 2. hello 태그용 코드
Listing 2의 코드는 매우 단순하다.
페이지 작성자에게 단지 하나의 디스플레이 옵션을 주는 대신 원하는 대로 아웃풋 포맷팅을 설정할 수 있도록 하고 싶다. Listing 3. LastModifiedTag 클래스에서 SimpleDateFormat 사용하기
Listing 4에서는 새로운 포맷팅 기능을 태그로 가져왔다. Listing 4. 새로운 애트리뷰트 핸들링하기
Listing 5. TLD 수정하기
TLD를 업데이트 할 때, 새로운 애트리뷰트를 사용해야만 한다. 테스트도 필수이다. 서블릿 컨테이너를 재시작하여 이것이 새로운 태그와 TLD 변화를 감지했는지를 확인하고 여기에 당연히 타임 스탬프가 나타난다. 만일 여러분이 내가 보고있는 것을 보고있다면 아웃풋의 포맷팅은 전과 같다. 문제는 어떤 새로운 커스텀 애트리뷰트에 디폴트 값을 주는 것은 좋은 생각이다. 왜냐하면 페이지 작성자가 고유의 값을 제공하고 싶지 않을 때 곤경에 처하지 않기 때문이다. 때로는 새로운 애트리뷰트와 포맷을 배우는데 시간이 필요하고 그 사이 디폴트는 훌륭한 대리인이 되는 것이다.
Listing 6 은 타임 스탬프 예제("JSP best practices : 타임 스탬프의 힘" 참조)의 footer.jsp 이다. Listing 6. 포맷 애트리뷰트 사용하기
| |||||||||||||||||||||||||||||||||||||
'그거 > Java' 카테고리의 다른 글
| Java 5의 새로운 기능 (0) | 2007.01.29 |
|---|---|
| 오픈 소스 자바 심층 탐구 (0) | 2007.01.29 |
| JSTL 기초, Part 2: 핵심에 접근하기 (0) | 2007.01.29 |
| JSTL 입문 Part 1: Expression Language (0) | 2007.01.29 |
| 커스텀 태그로 JSP 페이지 제어하기 (0) | 2007.01.29 |
