pat98's always & forever

DISTRIBUTED TRANSACTION TROUBLESHOOTING (ORA-1591해결 방법)
==========================================================

다른 database를 이용하지 않는 local transaction이, 비정상 종료시 자동으로
rollback되는 것과는 달리, 분산 트랜잭션의 경우 2 phase commit수행 단계중에
fail이 발생하게 되면 관여된 일부 database에서는 rollback 혹은 commit이 되고,
일부는 distributed lock이 걸린 상태로 계속 지속될 수 있다.
이렇게 pending된 transaction에 대해서는 기본적으로 Oracle의 background
process인 RECO process가 자동으로 정리하여 주나, 경우에 따라 자동으로 정리가
되지 못하는 상황이 발생할 수 있다.

이렇게 정리가 되지 않아, distributed lock이 걸린 경우에는, 이후 관계된
table을 조회나 변경시 ora-1591 오류가 발생할 수 있으므로, distributed
transaction이 실패한 경우 db admin이 관여하여 pending된 transaction을
정리하여 줄 필요가 있다.

distributed transaction이 오류가 발생하거나, 혹은 이후에 ora-1591이 발생하는
경우, 조치 방법을 9단계의 STEP으로 정리하였다.

*** distributed transaction의 2 phase commit에 대한 개념 및 자세한 절차는
<korean bulletin:12185>를 참조한다.

[참고 1] 문서의 이해를 위해서 분산 환경에 포함된 node를 V817LOC와 V817REM으로
예를 들고, V817LOC node에서 transaction을 수행하였다고 가정한다.

[참고 2] 아래에 언급되는 dbms_transaction package는 기본적으로 catproc.sql
script에 의해 생성되나 만약 존재하지 않는다면,
cd $ORACLE_HOME/rdbms/admin directory의 dbmsutil.sql, prvtutil.plb
script를 sys user에서 수행하도록 한다.
(svrmgrl에서 connect internal에서 수행하는것이 일반적)

그리고 이 package는 항상 transaction의 맨 처음에 수행되어야 한다.
즉, 새로 session을 연결하여 수행하거나, 혹은 앞에 dml에 있었다면,
commit이나 rollback을 수행 후 이 package를 수행하여야 한다.

아래의 STEP중 STEP 1 ~ 3까지는 문제 해결을 위해 필수적인 단계는 아니므로 바로
문제를 시급히 해결해야 하는 경우 4번부터 확인하도록 한다.

STEP 1: alert.log file을 check한다.

bdump directory의 alert.log에는 분산 트랜잭션 fail시 관계된 오류 메시지등
log가 항상 남게 된다. 예를 들면 다음과 같은 형태인데, rollback/commit되었
는지, in-doubt 상태인지와 그 외에 transaction id등 정보를 확인할 수 있다.

Tue Dec 12 16:23:25 2000
ORA-02054: transaction 1.8.238 in-doubt
ORA-02063: preceding line from V817REM
Tue Dec 12 16:23:25 2000
DISTRIB TRAN V817LOC.WORLD.89f6eafb.1.8.238
is local tran 1.8.238 (hex=01.08.ee)
insert pending prepared tran, scn=194671 (hex=0.0002f86f)

STEP 2: network 환경을 확인한다.

listener가 떠 있는지, database link가 모두 정상적인지 확인해 본다.

STEP 3: RECO process가 떠 있는지 확인한다.

os상에서 RECO process가 떠 있는지 확인하려면 다음과 같이 한다.

os> ps -ef | grep reco

RECO process는 db가 startup되면서 자동으로 구동되는 background process로
distributed recovery를 disable시키면 사라지게 된다. distributed recovery를
enable/disable시키는 방법은 아래와 같다.

SQL>alter system enable distributed recovery;
SQL>alter system disable distributed recovery;

아래의 조치사항 중에서 STEP 9번을 제외하고는 기본적으로 RECO process가
자동으로 처리하는 작업과 동일하다. 그러나 여러가지 문제로 인해 RECO가
자동으로 정리하지 못한 경우 이 문서의 방법대로 manual하게 정리하여 주어야
한다.

STEP 4: DBA_2PC_PENDING을 조회해 본다.

sqlplus system/manager
SQL>select local_tran_id, global_tran_id, state, mixed, host, commit#
from dba_2pc_pending;

다음과 같은 결과가 return된다.

LOCAL_TRAN_ID|GLOBAL_TRAN_ID |STATE |MIX|HOST |COMMIT#
-------------|----------------------|--------|---|----------|--------
1.8.238 |V817LOC.WORLD.89f6eafb|prepared|no |SUP_SERVER|194671
|.1.8.238 | | |\eykim |

이 조회로 인해 여러개의 row가 나오는 경우 ora-1591이나 distributed fail에
관련된 오류시 나타나는 local transaction id값과 return된 LOCAL_TRAN_ID값을
비교하여 일치하는 row를 확인하면 된다. 이때 LOCAL_TRAN_ID 값과
GLOBAL_TRAN_ID의 뒷부분의 숫자가 동일하다면 이것은 이 node가 global
coordinator임을 의미한다.

STEP 5: DBA_2PC_NEIGHBORS view를 조회해 본다.

sqlplus system/manager
SQL>select local_id, in_out, database, dbuser_owner, interface
from dba_2pc_neighbors;

LOCAL_TRAN_ID|IN_OUT|DATABASE |DBUSER_OWNER |INT
-------------|------|-------------------------|---------------|---
1.8.238 |in | |SCOTT |N
1.8.238 |out |V817REM.WORLD |SCOTT |C

여기에 나타난 row들이 해당 분산 트랜잭션에 관여한 database 정보이다. 이때
DATABASE column 부분이 null로 나타나는 것은 현재 조회하고 있는 local
database를 의미하며, IN_OUT이 OUT으로 나타나는 경우 참조하는 node정보인데,
DATABASE 컬럼의 값이 해당 database를 가리키는 database link name이 된다.
이 database link name을 이용하여 다음과 같이 remote db의 DBA_2PC_PENDING을
다시 조사하여 관계된 node들의 상태를 확인할 수 있다.

SQL>select local_tran_id, global_tran_id, state, mixed, host, commit#
from dba_2pc_pending@v817rem;

각 node의 DBA_2PC_PENDING의 return된 row들이 같은 분산 트랜잭션에 포함된
정보인지는 GLOBAL_TRAN_ID 값을 이용하여 확인할 수 있다.

STEP 6: commit point site를 확인한다.

commit point site에 대해서는 <korean bulletin:12185>을 참조한다.
이 예의 경우 COMMIT_POINT_STRENGTH를 지정하지 않았기 때문에 default로
global coordinator가 아닌 V817REM이 commit point site가 된다. 일반적으로
commit point site는 global coordinator의 DBA_2PC_NEIGHBORS의 IN_OUT
field가 OUT으로 나타나고 INTERFACE 부분이 C로 나타나게 된다.

commit point site가 중요한 이유는 이 node의 local transaction부분은
prepared상태를 거치지 않아 in-doubt 상태가 되는 일이 없고, 그러므로
distributed lock에 의해 조회나 DML시 오류가 발생하는 없게 된다.
이러한 이유로 제일 중요한 data를 포함하는 중심이 되는 node를 commit point
site로 지정하는 것이 바람직하다.

STEP 7: DBA_2PC_PENDING의 MIXED column을 확인한다.

- MIXED값이 NO인 경우 : STEP 8 수행
- MIXED값이 YES인 경우: STEP 9 수행

DBA_2PC_PENDING에서 MIXED column을 YES나 NO의 값으로 지정하는 것은 RECO
process가 결정하여 변경하게 된다. MIXED가 YES가 되는 대표적인 경우는,
commit point site가 이미 commit을 수행한 상태에서 분산 트랜잭션이 fail된
경우, non-commit point site에서 prepared 상태의 transaction을 rollback
force시켜 분산 트랜잭션의 consistency가 깨진 상태이다.
(STATE column의 경우 commit point site는 COMMITTED로 non-commit point
site는 FORCED ROLLBACK으로 나타난다)

[참고] commit point site가 아직 commit을 수행하기 전에 분산 트랜잭션이
fail되어 commit point site가 rollback된 경우, non-commit point
site에서 prepared 상태의 transaction을 commit force 하면 이것도
논리적으로는 consistency가 지켜지지 않은 것은 동일하나 이때는
MIXED column이 no인 상태가 된다. 그 이유는 commit point site가
rollback되어 DBA_2PC_PENDING view에 entry가 남지 않기 때문에
RECO가 명시적으로 mixed 상태로 인식하는 것이 불가능하기 때문으로
파악된다.

STEP 8: DBA_2PC_PENDING의 STATE column의 값을 확인한다.

CASE 8-1: STATE field값이 COMMITTED인 경우

만약 STATE가 COMMITTED인 경우는 이 local database(V817LOC)에서는
transaction이 성공적으로 commit 되었음을 나타내므로, 이 node에서는 어떠한
작업도 수행할 필요가 없다. 이 entry는 RECO process에 의해 자동으로 지워질
것이며, 만약 RECO가 어떠한 이유로 이 row를 지우지 못했다면 다음과 같이
db admin이 직접 지워도 된다. 괄호 안의 값은 local_tran_id값이다.

sqlplus sys/manager (반드시 sys로 접속한다)
SQL>exec dbms_transaction.purge_lost_db_entry('1.8.238');

이렇게 V817LOC의 STATE부분이 COMMITTED인 경우는, 이미 commit point site인
V817REM은 commit된 후임을 나타낸다. 그러므로 V817REM은 STATE가 COMMITTED로
나타나거나 아니면 commit후 이미 정보가 지워져 DBA_2PC_PENDING에 정보가
나타나지 않을 수 있다. 그러므로 V817REM에 대해서는 필요한 경우 V817LOC의
앞의 조치 방법과 동일하게 DBA_2PC_PENDING의 내용만 정리하여 주면 된다.

만약 V817REM이 아닌 별도의 다른 node가 분산 트랜잭션에 관여했다고 가정하고
V817LOC가 COMMITTED인 상태에서 그 node의 STATE가 PREPARED로 나타난다면
그 node에 대해서는 아래의 CASE 8-2를 참조하여 해결하도록 한다.

CASE 8-2: STATE field값이 PREPARED인 경우

STATE값이 PREPARED인 경우는 이 node(V817LOC)에서 변경된 data가 속한 block
에 distributed lock이 걸린 상태이며, 이런 경우 변경된 data가 있는 block에
대한 모든 read/write가 ora-1591을 발생시키므로 trouble shooting에서 제일
중요한 부분이라 할 수 있다.

먼저 STEP 4와 STEP 5를 참조하여 관계된 모든 node들의 DBA_2PC_PENDING view
를 조회하여 본다. 이때 다른 node(V817REM)의 DBA_2PC_PENDING에 정보가 없다
면 V817REM이 commit point site이고 이미 data는 rollback되었음을 나타낸다.
이때는 V817LOC의 prepared 상태의 transaction을 다음과 rollback force 시켜
준다.

즉, V817LOC에서,

SQL>rollback force '1.8.238';

만약 V817REM node에 해당 정보가 있고 상태가 COMMITTED라면 V817LOC도
다음과 같이 commit을 해 주어야 한다.

SQL>commit force '1.8.238';

이때 local_tran_id 뒤에 SCN을 지정할 수 있는데 이것은 관여된 node 중 제일
큰 SCN을 지정하도록 한다. 이 SCN 값은 DBA_2PC_PENDING의 COMMIT# field에서
값을 확인할 수 있으며 이렇게 하는 이유는 이후 분산 database중 한 database
에서 incomplete recovery가 필요한 경우, 다른 database 들도 일관성을
맞추기 위해 incomplete recovery를 이용할 수 있게 하기 위한 것이다.

SQL>commit force '1.8.238', '194671'

CASE 8-3: STATE field값이 COLLECTING인 경우

STATE field가 collecting인 경우는 아직 distributed lock을 걸기 전단계에서
transaction이 비정상 종료됨을 나타내며, 이 단계에서는 distributed lock이
걸리기 전이어서 변경된 data는 이미 rollback된 상태이다. 이 경우는
DBA_2PC_PENDING에서 해당 entry를 지워 주면 된다.

sqlplus sys/manager (반드시 sys로 접속한다)
SQL>exec dbms_transaction.purge_lost_db_entry('1.8.238');

CASE 8-4: STATE field값이 FORCED ROLLBACK/FORCED COMMIT 인 경우

이미 RECO나 db admin이 rollback force나 commit force 명령을 시도하여
STATE가 FORCED ROLLBACK이나 FORCED COMMIT으로 변경된 경우는 추가적으로
수행할 작업은 없으며, RECO가 자동으로 이 entry를 지워 줄 것이다. 그러나
RECO가 작업하기를 기다리지 않고 다음과 같이 직접 삭제할 수 있다.

sqlplus sys/manager (반드시 sys로 접속한다)
SQL>exec dbms_transaction.purge_lost_db_entry('1.8.238');

STEP 9: 불일치 사항을 파악하고 DBA_2PC_PENDING을 정리한다.

어떠한 경우에 DBA_2PC_PENDING의 MIXED column이 YES가 되는지는 이미 STEP 7
에서 설명하였다. 이렇게 잘못된 조치에 의해 STEP 7에서 설명한 것과 같은
분산 데이타베이스간의 불일치가 발생한 경우는 간단한 operation을 통해
일치성을 맞추는 것은 불가능하다.
분산 트랜잭션의 consistency가 무엇보다 중요한 경우라면 관계된 node의
database를 모두 문제의 분산 트랜잭션이 수행되기 이전 상태로, incomplete
recovery를 수행하거나 할 수 있다. 분산 데이타베이스간의 일관성을 위한
incomplete recovery에 대해서는 여기에서는 다루지 않는다. 한가지 언급한
말한 것은 앞에서 설명한 분산 트랜잭션의 commit시 이용하는 commit SCN을
관계된 모든 node들의 최대 SCN으로 이용하는 것이 바로 이러한 recovery를
위한 것이다. 이렇게 일부 database에서 SCN값이 이전 SCN에서 1씩 증가하는
것이 아니라 큰 값으로 건너뛰어 다른 database와 같은 SCN을 유지하게
함으로써, 이후에 incomplete recovery시에 관계된 node들이 서로 동일한
SCN으로 recovery를 수행하면, 모두 분산 트랜잭션 적용 이전이 되거나 혹은
모두 이후가 되어 일관성을 유지할 수 있도록 해준다.

MIXED가 YES인 상태에서, inconsistency를 받아들이고 DBA_2PC_PENDING view를
정리하려면 다음과 같이 수행한다.

sqlplus sys/manager (반드시 sys user로 수행한다)
SQL>exec dbms_transaction.purge_mixed('1.8.238');

참고 : Note 290405.1
Automatic Undo mode에선 DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY 사용전에
"_smu_debug_mode"를 기술해 주어야 한다.

1.) alter session set "_smu_debug_mode" = 4;
2.) execute DBMS_TRANSACTION.PURGE_LOST_DB_ENTRY('local_tran_id');

주식매매를 시작한지 올해로 13년째이다.

증권사 재직이 5년, 전업한지 8년째...
정말 많은 일들이 주마등처럼 지나간다.

제도권 재직부터 경력 7년째까지는 그야말로
내돈과 고객돈은 세력과 메이져들 돈이었다.

계좌에 돈이 들어가는 즉시 남의 돈이 되버렸으니...

그렇게 7년을  남 좋은일 시키고, 잠수타서 3년을
나만의 그래프와 노하우를  만드는데 썼다.

그리고 나머지 3년과 지금은...
비교적 안정적인 수익을 창출하고 있다.

해서, 지금 어려운 분들에게 조금이라도 힘이 되어주고자
몇가지 글을 올리고자 한다.

첫 째

가장 중요한 것은 대중의 생각과 다른생각을 하라는 것이다.
어차피 주식매매하는  사람들 전부가
수익을 올린다면 누가 주식하지 않겠는가?

95%가 깨져야 나머지 5%가 부자가 된다.
그러려면, 대중 특히 매스미디어와는 친하지 말아야 한다.

외국계 증권사엔 입사하자마자 처음 교육받는것이
대중심리학이라고 들었다.

쉽게 말해서 대중과 멀어져야 내가 산다.

둘 째

내귀에 까지 들어오는 정보는  정보가 아니다.

내귀에 대고 소곤거리는 모든이들을 악마로 취급하라.
80% 이상이 팔아먹기위해 떠드는 소리다.

세력들은 자신들의 주식을 매집국면에서는
완전 보안에 소문내지 않는다.
꼭대기에서 팔아먹을 때라야 비로소 내귀에 들린다.

셋 째

처음매매의 대박은 사망의 지름길!
처음매매의 실패는 성공의 지름길!

처음의 대박은 자신의 눈과 마음을 멀게하고, 붕뜨게 한다.
그만큼의 수익이 아니면, 수익으로 보이지 않는다.

처음매매의 실패는 주식무서운줄 알게되며,
그렇기에 다각도로 공부하며, 겸손할줄 알기에...

넷 째

남이 다 보는 그래프론 승부가 나지않는다.

생각해보라. 다같이 보고 같은방법으로 해석한다면,
어떤 미친세력이나 메이져가 그 방법데로나
그 방향데로 그래프를 만들어 가며 개미에게 충성하겠는가?
그래프나 챠트를 믿어서는 안된다.

다섯째

상대를 모르고선 해답이 없다.

그 주식을 움직이는 세력들이나
시장메이져의 시세내는  방법을 모른다면,
무슨 수익이 날 수 있겠는가?

불행히도 어떤 책, 어떤 매스미디어도
당신의 상대인 그들에 관한 자세한 언급이 없다.
언론은 결코 당신편이 아니라는 것이다.

여섯째

주식엔 고수가 있을지언정 매매의 고수는 없다.
종목을 선별하고, 분석하고,
추천할 수 있는 고수는 널려있다.

그러나 막상 매매해서 지속적이고,
안정적인 수익을 내는 고수는 아주 드물다.

왜 그럴까?
매매에는 인간의 최대의 약점인
욕심과 공포가 있기 때문이다.

한 두 종목 대박은 웬만한 개미들은 격어 볼수있다.
그러나 그것은 한순간의 신기루에 불과하다.

지속적이고 안정적인 수익만이
최고의 고수로 대접받을 수 있으며,
복리대박의 꿈을 실현할 수 있다.

일곱째

좀 더 멀리보고 매매에 임하라.

1주일, 한달, 6개월의 수익보단 1년, 5년, 10년 후의
자신의 계좌를 생각한다면 좀더 느긋 할 수 있고,
여유로와 질수있다.
주식해서 빚을 갚는다든지, 생활비를 해야한다면,
빨리 주식매매 접는게 자신과 가족을 위한 길이다.

여덟째

나쁜 기억과 좋은 기억 모두 절대 잊지 말아라.

박살났던 종목들 대박났던 종목들 빠짐없이
그때의 상황과 자신의 매매패턴을 잊지말아야
미래의 종목들에 적용내지 대응할 수 있다.
그것이 무기가 되어 자신만의 노하우로 축적된다.

주식시장에서 망각은 곧 사망이다.

아홉째

주식은 혼자하는 고독한 게임이다.

여러사람과 같이 한다든지 동호회에 가입하는 사람들치고,
돈버는 사람 못봤다.

배가 산으로 가게 되기때문이다.
물론 카리스마있는 고수가 있어서
무리를 이끌어간다면, 모르겠지만...
비슷한 사람끼리는 절대 함께 매매하지 말아라.
나중에 서로 웬수된다.

열번째

자신만의 노하우를 만들던지...
정말 실전매매에 능통한 고수에게 배우던지 해라.

어차피 주식은 한번 발을 들여 놓으면, 평생빼기 힘들다.
자신만의 처절한 싸움이 지속된다.

거기에서 이기려면 누구도 알 수 없는 자신만의 확고한
노하우가 없다면 성공하기 힘들다.

열한번째

자금관리와 돈질이 중요하다.

수익나면 계좌에서 무조건 빼고 재투자는 하지마라.
투자는 무조건 원금의 영역에서만 하라.

아무리 돈을 벌어도 관리가 안된다면 도로아미타불이다.

그리고 철저한 분할매수와 분할매도만이
자신의 심리를 안정시켜준다.

조금샀는데 날아간다면 그걸로 만족하라.

자신의 복이 그것뿐이 안된다고 생각하고,
다른종목을 찾아라.

주식은 수익보다...
리스크먼저 생각하는 습관을 들여야 성공한다.

먹는거 생각부터 하는 사람치고,
실패하지 않는 사람없다.

위에 나열한 말들이 자신의 매매에
직접적인 영향을 주는 말들이기 보다는
앞으로 새털같이 많은 날들에, 또는 시간에...
꾸준한 도움으로 다가갔으면 하는 진솔한 마음으로
이 글을 쓴다.

RAC(OPS) 환경하에서 양쪽 Node의 archived log file을 RMAN을 사용하여 동시에 BACKUP 받는 방법
======================================================================================

ORACLE 9i 이전 버전
-------------------

Oracle 8i까지는 다음과 같은 Script를 통하여 Backup을 받을 수 있었습니다.

1) Script Name: arch_backup.rcv

run{
allocate channel node_1 type disk connect 'system/manager@v92hp1';
allocate channel node_2 type disk connect 'system/manager@v92hp2';

backup filesperset 1
(archivelog until time 'SYSDATE' thread 1 channel node_1)
(archivelog until time 'SYSDATE' thread 2 channel node_2);

release channel node_1;
release channel node_2;

}

2) 수행 방법

$ rman target=system/manager catalog=rman_user/rmanpw cmdfile='arch_backup.rcv' log='arch_backup.log'

ORACLE 9i 이후 버전
-------------------

그러나 Oracle9i 이상부터는 Archived file backup전에 다음과 같은 설정을 먼저
해 주셔야만 합니다.

1) Configuration 설정

$ rman target=system/manager catalog=rman_user/rmanpw
RMAN> Show all;
RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM 2;
RMAN> configure default device type to disk;
RMAN> configure channel 1 device type disk connect 'system/manager@v92hp1';
RMAN> configure channel 2 device type disk connect 'system/manager@v92hp2';

위 설정은 backup을 Disk에 받는 경우로 가정하고 device type을 모두 disk로 설정하였습니다.
만일 backup solution을 사용하여 tape에 받는다면 device type을 'sbt_tape'으로 변경해 주시면 됩니다

몇개의 Channel을 설정할 것인가에 따라 PARALLELISM의 값을 반드시맞춰 주어야 합니다.
이것을 맞춰주지 않으면 다음과 같은 형태의 Error가 발생하면서 다른 Node의 archive file들을 인식하지
못하게 됩니다.(실제로 Archived file들은 정상적으로 존재합니다)

RMAN-06059: expected archived log not found, lost of archived log compromises recoverability
ORA-19625: error identifying file /u01/64bit/app/oracle/product/9.2.0/admin/V92HP/arch/arch1_146.dbf
ORA-27037: unable to obtain file status
HP-UX Error: 2: No such file or directory
Additional information: 3

위 설정은 한번만 수행해 주시면 됩니다.
만일 CHANNEL을 잘못 설정하였으면 다음과 같은 명령으로 Clear 해 주시면 됩니다.

RMAN> configure channel 1 device type disk clear;

2)Archived file을 Backup 받습니다.

RMAN> run { backup
format='/u01/64bit/app/oracle/product/9.2.0/admin/V92HP/arch/%U'
archivelog all delete input;
}

ADDITIONAL INFORMATION(1)
-------------------------
RAC 환경 하에서 일부 Archived file들이 OS에서 삭제 되었을 경우 다음과 같은 명령을 통하여
validation check를 수행한 후에 backup을 수행하여 주십시요

RMAN> allocate channel for maintenance type disk connect 'system/manager@v92hp1';
RMAN> allocate channel for maintenance type disk connect 'system/manager@v92hp2';
RMAN> crosscheck archivelog all;

만약에 Configuration에서 이미 Channel을 설정해 주었다면
Channel allocation 없이 바로 crosscheck명령어를 수행해 주시면 됩니다.

ADDITIONAL INFORMATION(2)
-------------------------
Channel Configuration 설정시에 Backup FORMAT을 함께 설정하려면 다음과 같은 형태로 수행합니다.

RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM 2;
RMAN> configure default device type to disk;
RMAN> configure channel 1 device type disk connect 'system/manager@v92hp1' FORMAT '/arch/bkup%t_s%s_s%p';
RMAN> configure channel 2 device type disk connect 'system/manager@v92hp2' FORMAT '/arch/bkup%t_s%s_s%p';

ADDITIONAL INFORMATION(3)
-------------------------
Tape device를 사용할 경우 device type은 'sbt_tape'을 사용합니다.

RMAN> CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 2;
RMAN> configure default device type to 'sbt_tape';
RMAN> configure channel 1 device type 'sbt_tape' connect 'system/manager@v92hp1' FORMAT 'bkup%t_s%s_s%p';
RMAN> configure channel 2 device type 'sbt_tape' connect 'system/manager@v92hp2' FORMAT 'bkup%t_s%s_s%p';

△ 체코판 에스콰이어 11월호 ▲





아래는 GQ 10월호...

확대하면 후덜덜한 몸매를 후덜덜한 해상도로 볼수 있어요~ ^^

jackie myung의 블로그 : http://blog.naver.com/jackie_m94