그리드 컴퓨팅 데이터베이스의 약진 Oracle Database 10g Release 2
| Oracle Database 10g Release 2의 비전 |
| Oracle Database 10g Release 2의 해부 |
| Oracle Database 10g Release 2의 첫인상 |
ORACLE DATABASE 10g Release 2의 첫 인상
Oracle Database 10g Release 2를 처음 접한 이후 6개월여가 지났다. 그간 Oracle Database 10g Release 2에 대한 자료 및 테스트 등을 통해 생각했던 주목할 만한 몇 가지 기능을 OTN의 고정 필자인 Tom Kyte의‘My First Day with the New Release’ 글을 참고하여 소개하고자 한다.
Conditional Compilation
Oracle Database 10g Release 2에서는 PL/SQL 부문으로 여러 새로운 기능들을 제공하고 있다. 그 중 필자가 처음 주목한 것은 Conditional Compilation이다.
Conditional Compilation은 컴파일러가 의도에 따라 코드의 실행 여부를 결정할 수 있도록 하는 기능이다. 언뜻 들어서는 그저 그런 기능 같지만, 사실은 매우 유용한 기능이다.
Conditional Compilation을 이용하면,
• 현재 애플리케이션의 디버그 코드를 그대로 둘 수 있고, 이 코드를 원하는 대로 동작하게 하거나 동작하지 않도록 할 수 있다.
• C에서 하는 것처럼 Assertion을 프로그래밍할 수 있다. 예를 들어, 각 서브프로그램은 인풋 값을 테스트할 수 있고, 그 값이 특정 조건을 만족하는지 검증할 수 있다. 이런 테스트들이 전체 개발 기간 동안은 Active 상태이고, 프로덕 션 단계에서는 Inactive 상태일 수 있는 것이다. 그러나, 코드가 남아 있으므로 프로덕션 환경에서의 버그를 디버깅할 때 간단하게 활성화시킬 수 있다.
. 버전에 구애 받지 않는 코드를 작성할 수 있다. 버전 X용 코드 세트와 버전 Y용의 다른 코드 세트를 컴파일하면 되 므로, 두 세트의 코드를 가지지 않아도 된다. 새로운 DBMS_DB_VERSION 패키지를 살펴보라.
<리스트1>은 Conditional Compilation이 어떻게 구현될 수 있는지를 간략하게 보여 준다.
<리스트 1> Conditional PL/SQL Compilation 예
SQL> create or replace procedure p
2 as
3 begin
4 $IF $$debug_code $THEN
5 dbms_output.put_line‘( Our debug code’);
6 dbms_output.put_line‘( Would go here’);
7 $END
8 dbms_output.put_line‘( And our real code here’);
9 end;
10 /
Procedure created.여기서 어떻게‘debug’코드가 프린트 되지 않고, $$debug_code 값이 정의되지 않은 채 코드가 컴파일되는지 주목하기 바란다.
SQL> exec p
And our real code here
PL/SQL procedure successfully completed.간단하게 debug_code 값을 변경함으로써 디버그 코드를 활성화시킬 수 있다.
SQL> alter procedure P compile“
2 plsql_ccflags =‘ debug_code:true’reuse settings;
Procedure altered.
SQL> exec p
Our debug code
Would go here
And our real code here
PL/SQL procedure successfully completed.Database Transport
Oracle Database 10g Release 1에서 서로 다른 플랫폼간의Transportable Tablespace를소개한다음, 이번 Oracle Database 10g Release 2에서 이를 한 단계 더 발전시켰다. Oracle Database 10g Release 2 부터는 동일한 Endian(바이트 순서)을 갖는 전 플랫폼에서 전체 데이터베이스를 트랜스포트할 수 있다. 예를 들어, Apple Macintosh에서 HP-UX로, 또는 Solaris x86에서 Open VMS로 단지 개개의 테이블스페이스를 트랜스포트하는 것이 아니라 전체 데이터베이스를 통째로 트랜스포트할 수 있다.
Native XQuery 지원
Oracle Database 10g Release 2는 W3C가 지정한 XML 질의용 표준인 XQuery를 지원한다. 이 기능은 XMLQuery와 XMLTable의 두 가지 기능으로 구현되어 있다. XMLQuery는 SQL 클라이언트에서 XQuery 언어를 사용해 해당 데이터와 관련된 XML 뷰를 질의하거나 Oracle XML DB 리파지토리 문서를 질의할 수 있도록 해준다. XMLTable은 XQuery의 결과를 관련 로우와 칼럼으로 매핑해 주므로, SQL을 사용해 그 매핑 결과에 대해 질의할 수 있다.
Direct SGA Access
데이터베이스가 응답이 없거나 혹은 시스템 성능이 너무 느린 경우, DBA가 가장 먼저 하고자 하는 일은 데이터베이스에 SYSDBA로 접속하여 Wait Event를 체크하는 일일 것이다. 그러나, 인스턴스가 행(hang) 상태라면 로그인도 못하는 지경일 수 있고, 로그인에 성공했다 하더라도 문제 해결을 위한 질의가 제대로 수행되지 못하는 경우가 상당하다.
Oracle Database 10g Release 2의 OEM Grid Control은 사용자의 요청에 따라 Direct SGA Attach 가 가능하므로 프로세스로부터 데이터를 수집할 수 있다. 이러한 메모리 액세스 모드는 SQL이 불가능할 정도로 인스턴스가 심각한 상태라 하더라도 성능 데이터 등을 모니터링할 수 있도록 한다. 이러한 Direct SGA Access 기능은Oracle Enterprise Manager를통해<화면1>과 같이 활용할 수 있다.
<화면 1> Direct SGA Access 기능의 활용
Asynchronous Commit
일반적으로 Java, C, Visual Basic 애플리케이션에서 COMMIT을 실행하면, Wait, 특히, Log File Sync Wait이 발생하게 된다. 이 Wait은 Transaction Permanence를 위해 Log Writer Process가 디스크에 리두를 플러시시킬 때까지 클라이언트가 기다리기 때문이다. 그리고 이것은 일반적인 것으로 커밋을 수행하면, 그 데이터는‘Permanent’해야 하기 때문이다.
그러나 모든 법칙에는 예외가 있기 마련이다. 센서나 네트워크를 통해서 들어오는 기록들을 가능한 빨리 처리해야 하는 시스템이라면, 얘기가 달라진다. 이런 프로그램의 목표는 여러 레코드들을 일괄로 묶은 뒤 INSERT하고 Commit 한 뒤, 계속해서 이런 작업을 반복하는 것이다. 커밋이 완벽하게 수행될 때까지 기다린다면, 기대만큼 빠 르게 실행될 수 없을 것이므로, 이런 프로그램은 그런 방식을 원하지 않을 것이다.
이 제 Oracle Database 10g Release 2에서 Asynchronous Commit을 이용해 보자.‘ commitbut- don’t wait’이나‘commit, and please do wait’ 을지정할수있다. 그러나, commit-but-don’t wait을 사용한다면, 드물게나마‘Commited’데이터가 분실될 수 있음을 예상해야 한다. commit-but-don’t wait을 이용하는 중에 시스템이 중단되면, 그 데이터는 커밋되지 않았을 수 있다. 그렇기 때문에, 사용자가 업무 성격에 따라 판단하여 commit-but-don’t wait을 사용하는 것이 필요하다. 참고로, 쏟아져 들어오는 데이터를 데이터베이스에 신속하게 기록하는 것이 애플리케이션의 최대 목적인 경우가 있다면, 이런 애플리케이션에서는 commitbut- don’t wait을 사용하는 것이 적합할 뿐 아니라 성능 측면에서 절대적으로 필요할 수 있다. <리스트 2>는 이런 예를 보여주는 Java 루틴이다.
<리스트 2> commit-but-don’t wait - Asynchronous Commit
public class instest
{
static public void main(String args[]) throws Exception
{
DriverManager.registerDriver(new oracle.jdbc.driver.OracleDriver());
Connection
conn = DriverManager.getConnection
“( jdbc:oracle:thin:@desktop:1521:ora10gr2”,
“scott”,”tiger”);
conn.setAutoCommit( false )
Statement sql_trace =
conn.createStatement();
sql_trace.execute
“( truncate table t”);
System.out.println“( Table truncated”);
sql_trace.execute
“( begin“ +
“ dbms_monitor.session_trace_enable( WAITS=>TRUE );”+
“end;”);
// create table t(x char(2000))
// create index t_idx on t(x)
PreparedStatement pstmt =
conn.prepareStatement
“( insert into t(x) values(?)”);
pstmt.setString( 1“, x”);
PreparedStatement commit =
conn.prepareStatement
“( commit work write batch nowait”);
//“ ( commit work write immediate wait”);
for( int i = 0; i < 1000; i++ )
{
pstmt.executeUpdate();
commit.executeUpdate();
}
conn.close();
}
}<리스트2>에서 COMMIT WORK WRITE BATCH NOWAIT나 COMMIT WORK WRITE IMMEDIATE WAIT이 어떻게 사용되고 있는지 보자. 전자가 새로운 기능으로, 커밋이 끝날 때까지 기다리지 않고 커밋하는 방법을 보여 주고 후자는 이전에 수행되던 형태이다. 필자가 <리스트 2>에서 (CREATE TABLE은 INSERT 문 앞에서 참조를 위한 커멘트이다) 테스트 프로그램을 실행 했을 때, WAIT 옵션에서는 로그 파일 동기화를 위한 wait 으로 오랜 시간이 걸렸지만, NOWAIT 옵션에서는 wait time이 전혀 없었다. 그 결과는 <리스트 3>와 같다.
<리스트 3> WAIT와 NOWAIT 결과 비교
Event Waited On Times Waited Max. Wait Total Waited
----------------------- --------------- ---------- ------------
log file sync (nowait) 19 0.02 0.04
log file sync (wait) 1017 0.04 1.43<리스트 3>의 결과를 보면, 로드 중간에 주기적으로 커밋을 필요로 하는 고속의 데이터 로드 프로그램에서는 상당한 차이가 나타날 수 있음을 예상할 수 있다.
Transport AWR Data
데이터베이스의 성능 문제를 분석하기 위해 AWR 데이터는 매우 중요하다. 하지만 운영 중인 데이터베이스에서 AWR 데이터를 분석하는 것이 불가능할 수 있는데, 이러한 경우 AWR 데이터를 별도의 저장소에 로드하고 성능 분석을할수있도록하는기능을Oracle Database 10g Release 2에서 제공하고 있다
Oracle Database 10g Release 2에 새로 추가된 DBMS_SWRF_INTERNAL 패키지가 바로 이기능을 가능하게 하는데, AWR_EXTRACT 프로시저를 이용하면 AWR 데이터를 Data Pump dmp 파일로 다운로드 할수있다.
s1 begin
2 DBMS_SWRF_INTERNAL.AWR_EXTRACT (
3 dmpfile =>‘ awr.dmp’, // data pump export 파일 명
4 dmpdir =>‘ AWR_DIR’, // dmp 파일이 기록되는
디렉토리 오브젝트
5 bid => 302, // 시작 snapshot ID
6 eid => 305 // 끝 snapshot ID
7 );
8* end;이제 awr.dmp 파일을 새로운 위치로 이동하고, DBMS_SWRF_INTERNAL 패키지의AWR_LOAD 프로시저를 이용하여 로드할 수 있다.
1 begin
2 DBMS_SWRF_INTERNAL.AWR_LOAD (
3 SCHNAME =>‘ AWRUSER’,
4 dmpfile =>‘ awr’,
5 dmpdir =>‘ AWR_DIR’
6 );
7* end;AWRDIR 디렉토리 오브젝트에 정의된 디렉토리로 부터 awr.dmp 파일을 이용하여 AWR 데이터를 로드하는데, 이때 로드는 직접 SYS 스키마로 바로 로드되지 않고 중간에 스테이징용 스키마에 로드된다. 이후 스테이징 작업이 완료되면, 최종적으로 SYS 스키마로 데이터를 이동시키는 작업이 필요하다.
1 begin
2 DBMS_SWRF_INTERNAL.MOVE_TO_AWR (
3 SCHNAME =>‘ AWRUSER’
4 );
5* end;이와 같은 방법으로 AWRUSER 스키마에서 SYS 스키마로 AWR 데이터를 이동한 후 성능 분석 작업을 하 면 되는 것이다.
AWR 데이타를 다른 데이터베이스로 이동하여 분석하는 것이 갖는 가장 큰 장점은 운영 데이터베이스에 영향 을 주지 않고 분석 작업을 수행할 수 있다는 것이다. 또한, 여러 데이터베이스로부터 수집된 AWR 데이터를 중앙집중적으로 관리할 수 있다는 장점도 있다
Transparent Data Encryption
이제Oracle Database 10g Release 2의 혁신적인 기능인 Transparent Data Encryption에 대해 살펴보자. 이것은 데이타를 쉽게 암호화할 수 있는 기능으로, 이 기능 덕분에 애플리케이션에서 더 이상 암호화 키를 다루지 않아도 된다. Transparent Data Encryption 기능은 데 이터베이스 레벨에서 칼럼 등에 대한 암호화 설정으로 자동 암호화 및 복호화를 지원한다. 데이터는 디스크에 저장될 때 암호화되어 저장되므로, 누군가가 데이터베이스를 훔치는 경우에 데이타는 보호될 수 있다. 아직 Transparent Data Encryption을 완전히 경험해 본 것은 아니지만, 잠깐 살펴본 결과 그 특징과 사용법을 소개하면 다음과 같다.
제일 먼저 해야 할 일은‘Wallet’을 설정하는 것이었다. 이 Wallet에 암호화 키가 저장될 것이고, 그 다음 이 파일은 패스워드로 보호될 것이다.
간단한 예제를 살펴보자. Oracle 홈에서‘wallet’이라는 디렉토리를 만들고, 다음 사항을 sqlnet.ora 파일에 기술한다.
WALLET_LOCATION=
(SOURCE=(METHOD=FILE)
(METHOD_DATA=
(DIRECTORY=/home/ora10gr2/wallet)
)
)그 다음에는 Wallet을 열기만 하면 된다.
SQL> alter system
2 set encryption wallet open
3 identified by foobar;
System altered.위작업은Transparent Data Encryption 기능을 사용하려면, 데이터베이스 오픈 후 반드시 해야 하는 작업이다.
이제 암호화 키를 셋업하도록 하자.
SQL> alter system
2 set encryption key
3 identified by foobar;
System altered.여기서는 시스템이 키를 만들도록 했지만, 고유의 키를 만들 수도 있다. 이렇게 하면 이 시스템에서 또 다른 시스템으로 쉽게 데이터를 옮길 수 있다.
이상으로 간단한 셋업이 끝났고 이제 데이터를 암호화를 위한 작업을 시작해보자.
SQL> create table t
2 ( c1 varchar2(80),
3 c2 varchar2(80) encrypt )
4 tablespace test;
Table created.
SQL> insert into t values
2 ‘( this_is_unencrypted’,
3 ‘this_is_encrypted’);
1 row created.이제 데이터는 암호화되어 디스크상에 저장되고, 권한 있는 사용자는 데이터 질의 시 데이터의 암호가 해제되어 리얼 데이터를 확인할 수 있게 된다.
SQL> select *
2 from t;
C1 C2
--------------------------- -----------------------
this_is_unencrypted this_is_encrypted그렇다면, 데이터가 암호화되었다는 건 어떻게 확인 할 수 있을까? 오라클 데이터파일에서 특정 문자열과 grep을 사용해 그 문자열을 찾을 수 있는지 없는지 알아 보았다. 먼저, 암호화된 데이터가 들어 있는 블록이 디스 크에 저장되어 있는지부터 확인해 보았다.
SQL> alter system checkpoint;
System altered.그 다음에 문자열들을 찾아보았다.‘ this_is’를 포함 하고 있는 암호화된 dbf 데이터파일에서 문자열을 찾아보 았다.
$ strings -a encrypt.dbf|grep this_is
this_is_unencrypted보다시피,‘ this_is_unencrypted’문자열만 나타났다. 다른 문자열은 저장되기 전에 이미 암호화 되었기 때문에 볼 수가 없는 것이다.
이 간단한 예제는 새로운 암호화 기능의 빙산의 일각 에 불과하다. Transparent Data Encryption은 외부의 테이블 언로드, 데이터 펌프 등과도 잘 작동하며, Oracle Wallet Manager 같은 GUI 툴을 통해 Wallet과 Passwrd를관리할수있다. 또, 키 손상된 것 같으면, 명령어를 이용해 데이터를 리키 할(re-key) 수있다. 개인적으로 Transparent Data Encryption은 Oracle Database 10g Release 2에서 가장 훌륭한 기능 중 하나라고 생각한다.
Autotrace
Oracle Database 10g Release 2의 Autotrace 기능은 DBMS_XPLAN 패키지를 사용해 Explain Plan을 디스플레이 한다. 그래서, 이전 릴리즈에 비하여 더욱 상세한 Explain Plan을 제공한다. Oracle9i Database Release 2 이상부터는 DBMS_XPLAN 패키지를 사용 해 이러한 플랜을 구할 수 있었으나, Autotrace가 DBMS_XPLAN을 사용함으로써 작업이 한결 쉬워졌다. 이DBMS_XPLAN 아웃풋에서특징적인부분은플랜의 하단에 Predicate Information(where절 부분)이 추 가된 것으로, 오라클 데이터베이스가 where 절 구문을 어느 단계에서 어떻게 사용할 것인지 정확하게 보여주는 것으로, 상당히 훌륭한 기능이라고 생각한다<리스트 4>.
<리스트 4> Autotrace with DBMS_XPLAN
SQL> set autotrace traceonly explain
SQL> select *
2 from emp, dept
3 where emp.deptno = dept.deptno
4 and emp.job =‘ CLERK’;
Execution Plan
-------------------------------------------------------------
Plan hash value: 877088642
----------------------------------------------------------------
| Id | Operation | Name| Rows| Bytes | Cost (%CPU) | Time |
----------------------------------------------------------------
|0 |SELECT STATEMENT | | 4 | 468 | 7 (15) | 00:00:01 |
|* 1 | HASH JOIN | | 4 | 468 | 7 (15) | 00:00:01 |
|* 2 | TABLE ACCESS FULL| EMP | 4 | 348 | 3 (0) | 00:00:01 |
| 3 | TABLE ACCESS FULL| DEPT | 4 | 120 | 3 (0) | 00:00:01 |
-----------------------------------------------------------------
Predicate Information (identified by operation id):
-----------------------------------------------------------------
1 - access“( EMP”.”DEPTNO”=”DEPT”.”DEPTNO”)
2 - filte“r( EMP”.”JOB”=’CLERK’)
Note
--------
- dynamic sampling used for this statementDBMS_OUTPUT
DBMS_OUTPUT이 Oracle Database 10g Release 2에서 업그레이드되었다. 버퍼 사이즈를 무제한으로(100 만 바이트까지!) 정의할 수 있을 뿐 아니라 255 Character 이상의 라인도 프린트할 수 있다. 현재 최대 라인 길이는 32K이다. 다음은 DBMS_OUTPUT의 실제 활용 예 이다.
SQL> set serveroutput on -
> size unlimited
SQL> begin
2 dbms_output.put_line
3 ( rpad‘( *’,2000,’*’) );
4 end;
5 /
************************
...
************************
PL/SQL procedure successfully completed.Oracle DataGuard Fast-Start Failover
Oracle Database 10g Release 2의 또 다른 신기능은 관리자가 일련의 명령어를 실행하거나 버튼을 누르지 않 아도 되는 스탠드바이 데이터베이스의 자동 페일오버이 다. Oracle Data Guard가 Production(Active) Server와 스토리지, 네트워크의 장애 발생시 스탠드바이 데이터베이스를 자동으로 페일오버하는 것이다.
Data Pump 압축
Oracle Database 10g Release 1이처음나왔을때희 소식은 완전히 새로 만들어진 Export (EXP), Import (IMP) 유틸리티와 EXPDP, IMPDP의 새로운 Oracle Data Pump 유틸리티였다. 하지만, EXPDP와 IMPDP 툴은 엑스포트 중에 DMP 파일들을 압축할 수 없다는 한 가지 단점이 있었다. EXPDP의 경우, 먼저 DMP 파일을 만든 후 이를 압축해야 했다. 예전의 EXP 툴에서는 지정된 파이프에 데이터를 기록하고, 그 파이프 에 기록된 데이터를 압축하도록 명령할 수 있었던 것에 비 하면, 이것은 분명 원하지 않던 단점이었다. 그러나, 이제 그런 번거로움이 없어졌다.
다행히도Oracle Database 10g Release 2에서는 이전 툴과 비교해 훨씬 쉽게 DMP 파일을 만들면서 부분 압축할 수 있게 되었다. EXPDP 스스로 덤프 파일에 씌 어진 모든 메타 데이터를 압축할 것이고, IMPDP는 자동 으로 압축 해제할 것이다. 또한, Oracle Database 10g Release 2에서처음으로Windows 플랫폼에서의DMP 파일 부분 압축이 가능하게 되었다.
LOG ERRORS
Log Errors는 Oracle Database 10g Release 2의 Delete, Insert, Merge 및 Update 문에서 볼 수 있는 새로운 구문이다. Log Errors는 많은 로우의 벌크 처리 시 실행에 실패한 로우들을 저장할 수 있도록 해준다. 이 전에는 문장 전체를 에러 처리함으로써 성공한 로우 데이 터에 대해서 재작업을 해줘야 하는 비효율성이 있었다.
예를들어, Insert Into T Select A,B,C From T2 Log Errors Into Errlog(‘ Bad_Rows_For_T’) Reject Limit Unlimited 같은 문장을 만들 수 있다.
이 문장은 조건에 위배되는 로우도 Bad_Rows_For _T 테이블에 로깅할 수 있도록 해준다. 이를테면, 너무 긴 칼럼 값 때문에 생긴 에러, Constraint Violation(Not Null, unique, referential, check constraint), 트리거실행중발생한에러, Type Conversion 에러, 파티 션 매핑 에러 등을 로깅할 수 있다. 에러가 발생하면, 이 에 러를 야기한 로우는 오라클 에러 번호, 에러 메시지 텍스트, 작업 유형(Insert, Update 또는 Delete) 그리고 Update 및 Delete 작업 중 실패한 로우의 RowID와 함께‘bad’테이블에 로그된다.
필자는 Oracle Database 10g Release 2의 여러 새 기능들 중 이 기능을 특히 좋아하게 될 것 같다. 각각의 로우를 일일이 처리하는 대신 벌크 작업을 수행하면 속도 와 자원 활용 면에서 큰 혜택을 볼 수 있을 것이다. 그리고, 실패한 로우의 에러 로깅은 이전부터 늘 요구되는 기능이 었는데, 이제 Log Errors로 완전히 해결되었다.
Restore Points
Oracle Database 10g Release 2에는Restore Point 를 설정할 수 있는 기능이 있다. Oracle Database 10g Release 1에서 데이터베이스를 플래시백할 수 있는 기능이 처음 소개되었지만, SCN(System Change Number) 과 플래시백할 시점을 알아내야 했다. 그러나, Oracle Database 10g Release 2에서는 먼저 Restore Point‘ X’를 생성하고, 손상을 입힐 만한 일, 예를 들어 애플리케이션의 업그레이드 같은 일을 수행 한 뒤, 업그레이드가 실패한 경우 간단하게Flashback Database To Restore Point‘ X’를 실행하면 작업 전의 상태로 돌아가는 것이다. 이제 더 이상 플래시백을 위한 SCN을 찾기 위 해 Select문을 실행하거나 플래시백 시점을 추정할 필요가 없게 된 것이다.
요약
이상은 Oracle Database 10g Release 2의 새 기능들 중 일부를 간략하게 훑어본 것이다. 위의 기능들과 언급하 지 못한 심도 깊고 다양한 Oracle Database 10g Release 2의 신기능들을 독자 여러분들이 직접 체험할 수 있기를 바란다.
출처명: 한국오라클'
