티스토리 툴바


2011/02/11 01:29 분류없음
출처 : http://jayclipse.egloos.com/947237

ORA-04031
이 에러의 원인은 크게 3가지로 나뉘어 진다.

1. 다수의 사용자로 인한 SharedPoolSize부족문제

2. 구동중인 App에 비해 현저히 부족한 SharedPool사용으로 인한 문제

3. 덩치 큰 SQL 구동을 위한 연속된 SharedPool할당 불가로 인한 문제

이중 1,2는 같은 맥락에서 접근할 수 있으므로 크게 2가지라고 볼 수도 있다.

이 문제는 OTN 에서 꽤나 유명한 에러로서 아래와 TechBulletin에는 아래와 같이 언급되어 있다.

No. 10095

ORA-4031 조치 방법 과 DBMS_SHARED_POOL STORED PROCEDURE 사용법
==============================================================

Purpose 
------- 

다음과 같은 작업 수행 시 Oracle 이 Shared pool 에서 연속적인 메모리 부분을 찾지 못해 ORA-4031 에러를 발생시키는 것을 볼 수 있다.

. PL/SQL Routine
. Procedure 수행 시 
. Compile 시
. Forms Generate 또는 Running 시 
. Object 생성하기 위해 Installer 사용 시 

본 자료에서는 이러한 에러에 대한 대처 방안을 설명 하고자 한다. 

Problem Description 
------------------- 

Error 발생의 주된 원인은 Shared Pool의 사용 가능한 Memory 가 시간이 흐름에 따라 작은 조각으로 분할되어 진다는 것이다. 그래서 큰 부분의
Memory 를 할당하려 한다면 Shared Memory가 부족하다는 ORA-4031 Error가 발생한다. 즉, 전체적으로는 많은 양의 사용 가능한 Space가 있다 하더라도
충분한 양의 연속적인 공간이 없으면 이 Error가 발생한다. 

1. Shared Pool과 관련된 인스턴스 파라미터 
다음 3가지 파라미터는 본 자료를 이해 하는데 매우 중요하다.

* SHARED_POOL_SIZE - Shared Pool 의 크기를 지정 한다. 정수를 사용하며 "K" 나 "M" 을 덧붙일 수 있다. 

* SHARED_POOL_RESERVED_SIZE - 공유 풀 메모리에 대한 대량의 연속 공간 요청에 대비해서 예약하는 영역의 크기를 지정한다. 이 영역을 사용하기
위해서는 SHARED_POOL_RESERVED_MIN_ALLOC 보다 큰 영역 할당 요청이어야 한다. 일반적으로 SHARED_POOL_SIZE 의 10% 정도를 지정한다. 

* SHARED_POOL_RESERVED_MIN_ALLOC - 예약 메모리 영역의 할당을 통제한다. 
이 값보다 큰 메모리 값이 할당 요청되었을 때 공유 풀의 free list 에 합한 메모리 공간이 없으면 예약된 메모리 공간의 리스트에서 메모리를 할당해 준다. 
이 값은 8i부터는 내부적으로만 사용된다. 

Workaround 
----------- 
Re-start the instance 

Solution Description: 
--------------------- 
이 Error 해결방안을 살펴 보면 다음과 같다. 

1. 혹시 알려진 제품 문제에 해당 되지 않는지 확인 한다. 

* BUG 1397603: ORA-4031 / SGA memory leak of PERMANENT memory occurs for buffer handles. (Workaround: _db_handles_cached=0, Fixed: 8172,901 )
* BUG 1640583: ORA-4031 due to leak / cache buffer chain contentionfrom AND-EQUAL access. (Fixed: 8171,901 )
* BUG 1318267: INSERT AS SELECT statements may not be shared when they should be if TIMED_STATISTICS. It can lead to ORA-4031. (Workaround: _SQLEXEC_PROGRESSION_COST=0, Fixed: 8171, 8200)
* BUG 1193003: Cursors may not be shared in 8.1 when they should be (Fixed: 8162, 8170, 901)


2. Object를 Shared Pool에 맞추어 Fragmentation을 줄인다.
(Dbms_Shared_Pool Procedure 이용) 

다음은 크기가 크고 빈번히 access되는 package들임.

standard packages
dbms_standard 
diutil
diana
dbms_sys_sql
dbms_sql
dbms_utility
dbms_describe
pidl
dbms_output
dbms_job


3. Shared Pool 을 효율적으로 사용하도록 Application Program을 조절한다.


4. 메모리 할당을 조정한다. 

우선 다음 쿼리로 library cache 문제인지 shared pool reserved space 문제인지 진단한다.

SELECT free_space, avg_free_size, used_space, avg_used_size, request_failures, last_failure_size FROM v$shared_pool_reserved;

만일 REQUEST_FAILURES is > 0 and LAST_FAILURE_SIZE is > SHARED_POOL_RESERVED_MIN_ALLOC
이면 ORA-4031 은 Shared Pool 의 연속 공간 부족의 결과이다. 

해결책: SHARED_POOL_RESERVED_MIN_ALLOC 값을 증가 시켜서 shared pool reserved space 에 올라가는 오브젝트의 수를 줄인다. 그리고
SHARED_POOL_RESERVED_SIZE 와 SHARED_POOL_SIZE 를 충분히 확보해 준다. 

만일 REQUEST_FAILURES is > 0 and LAST_FAILURE_SIZE is < SHARED_POOL_RESERVED_MIN_ALLOC 
이거나 
REQUEST_FAILURES is 0 and LAST_FAILURE_SIZE is < SHARED_POOL_RESERVED_MIN_ALLOC 
이면 ORA-4031 은 library cache 내의 연속된 공간 부족의 결과 이다. 

해결책: SHARED_POOL_RESERVED_MIN_ALLOC 을 줄여서 shared pool reserved space 를 보다 쉽게 사용할 수 있도록 해준다. 그리고 가능하면 SHARED_POOL_SIZE 를 증가시킨다. 


5. DBMS_SHARED_POOL STORED PROCEDURE 사용법

이 stored package는 dbmspool.sql을 포함하며 7.0.13 이상 version에서 사용가능하다. 이는 다음과 같이 3가지 부분으로 나누어 진다. 

Procedure sizes(minsize number):-> Shared_Pool_size 안에서 정해진 Size 보다 큰 Object를 보여준다.

Procedure keep(name varchar2, flag char Default 'P'):
-> Object (Only Package)를 Shared Pool 에 유지한다. 또한 일단 Keep한 Object는 LRU Algorithm에 영향을 받지 않으며 "Alter System Flush Shared_Pool" Command 에 의해 Package 의 Compiled 
Version 이 Shared Pool에서 Clear되지 않는다.

Procedure unkeep(name varchar2):-> keep() 의 반대 기능이다 

이 Procedure들과 사용법에 대해 보다 더 자세한 정보를 위해서는 $ORACLE_HOME/rdbms/admin/dbmspool.sql script 또는 오라클 레퍼런스 매뉴얼을 참조하기 바람.


Reference Documents 
------------------- 
Diagnosing and Resolving Error ORA-04031. 

위의 내용과 관련하여 SharedPoolSize 조절 방법은 아래와 같다.

이미 공지의 사실이지만 서두로 언급하면 Oracle은 Background Process와 SGA영역으로 구분된다.

그중 SGA는 SharedPool과 RedoLogBuffer, BufferCache로 이루어져 있다. 

이중 SharedPool은 SQL Area와 Data Structure로 이루어져 있다.

SharedPool Size를 산정하는 방법은 아래와 같다.

계산 공식         

Session당 최대메모리사용량(Max Session Memory) * 동시 접속하는 User의 수  
+  Shared SQL 영역으로 사용되는 메모리양          
+  Shared PLSQL을 위해 사용하는 메모리 영역           
+  최소 30%의 여유 공간 

계산 예제          

  (1) 적당한 user session에 대한 session id를 찾는다.         
          
        SQLDBA>  select sid from v$process p, v$session s           
             where p.addr=s.paddr and s.username='SCOTT';          

              SID          
           ----------          
               29          
        1 rows selected.          

  (2) 이 session id에 대한 maximum session memory를 찾는다.         
          
        SQLDBA> select value from v$sesstat s, v$statname n           
            where s.statistic# = n.statistic#           
            and n.name = 'session uga memory max' and sid=29;          

           VALUE               
           -----------          
            273877                  
        1 rows selected.          
          
  (3) Total shared SQL area를 구한다.         
          
        SQLDBA>  select sum(sharable_mem) from v$sqlarea;          

        SUM(SHARAB          
        ---------------------          
               8936625          
        1 row selected.          
          
  (4) PLSQL sharable memory area를 구한다.          
          
        SQLDBA>  select sum(sharable_mem) from v$db_object_cache;          

        SUM(SHARAB          
        ------------------          
            4823537          
        1 row selected.          
          
          
  (5) Shared pool size를 계산한다.          
                  
             274K shared memory  *  400 users          
        +      9M Shared SQL Area               
        +      5M PLSQL Sharable Memory           
        +      60M Free Space (30%)               

        =    184M Shared Pool             
                  
           
   이 예제에서는 Shared pool의 size는 184M가 적당하다고 할 수 있다. 이때 Free Space(60M) 계산 방법은 전제 184 M 에 대한 30 % 정도의 추정치 이다.         
          
Shared Memory부족 (ORA-4031)에 대한 대처

 다음과 같은 방법으로 에러를 피해 갈 수 있다.- "Sys.dbms_shared_pool.keep" procedure사용.         

[참고] 위 package를 사용하려면 ?/rdbms/admin/dbmspool.sql,prvtpool.sql를 수행시켜 package를 create시킨 후 사용한다.         
    (자세한 사항은 bulletin 10095,Oracle7 Server Tuning 4장12를 참조한다.)          
          

ORACLE_HOME/dbs/initSID.ora에 보시면 Processes=???값과 sessions=?????라는 
값에 좌우가 되는데 시스템에서 허락되는 
User별 process값이 있고 이 범위내에서 허용이 된다. 
SQL> show parameter process; 

NAME TYPE VALUE 
------------------------------------ ------- ------------------------------ 
aq_tm_processes integer 0 
db_writer_processes integer 1 
job_queue_processes integer 0 
log_archive_max_processes integer 1 
processes integer 300 
SQL> show parameter session; 

NAME TYPE VALUE 
------------------------------------ ------- ------------------------------ 
java_max_sessionspace_size integer 0 
java_soft_sessionspace_limit integer 0 
license_max_sessions integer 0 
license_sessions_warning integer 0 
mts_sessions integer 330 
session_cached_cursors integer 0 
session_max_open_files integer 10 
sessions integer 335 
SQL> 
        
저작자 표시 비영리
posted by starland
2011/02/09 10:02 분류없음

./runInstaller -ignoreSysPrereqs -J-DTRACING.ENABLED=true -J-DTRACING.LEVEL=2
-> DEBUG모드



./runInstaller -ignoreSysPrereqs -record -destinationFile "/tmp/my_response.rsp"
-> 설치 Response 파일 작성(summary 페이지까지 보여주고 설치 OUI종료)

./runInstaller -silent -responseFile "/tmp/my_response.rsp"
-> 작성된 Response 파일 로 ORACLE설치


 

저작자 표시 비영리
posted by starland
2011/02/02 02:22 분류없음
./runInstaller -ignoreSysprereqs -debug -logLevel finest >inst1.out 2>inst2.out

./runInstaller -ignoreSysprereqs -J-DTRACING.ENABLED=true -J-DTRACING.LEVEL=2

저작자 표시 비영리
posted by starland
2011/02/01 23:43 분류없음

http://www.allsoft.co.kr/bbs/board.php?bo_table=tip_tech&wr_id=55


저작자 표시 비영리
posted by starland
2011/02/01 23:06 분류없음
★ crs가동 중지관련
10g R1은 요걸로 내린단다
/sbin/init.d/init.crs stop
/sbin/init.d/init.crs start

10g R2부터는
crsctl stop crs
crsctl start crs


★ 리소스별 설정확인 관련
crs_stat -p 명령은 리소스별 설정보는건데,
너무 많이 나오므로 필요한것만 정리 해서 보기.

crs_stat -p | grep -iE "name=|auto|check_in" | grep -v _ALERT
NAME=ora.DBPA.DBPA1.inst
AUTO_START=1
CHECK_INTERVAL=600
NAME=ora.DBPA.DBPA2.inst
AUTO_START=1
CHECK_INTERVAL=600
NAME=ora.DBPA.db
AUTO_START=0
CHECK_INTERVAL=600
NAME=ora.flprpd01.LISTENER_FLPRPD01.lsnr
AUTO_START=1
CHECK_INTERVAL=600
NAME=ora.flprpd01.gsd
AUTO_START=1
CHECK_INTERVAL=600
NAME=ora.flprpd01.ons
AUTO_START=0
CHECK_INTERVAL=600
NAME=ora.flprpd01.vip
AUTO_START=1
CHECK_INTERVAL=60
NAME=ora.flprpd02.LISTENER_FLPRPD02.lsnr
AUTO_START=1
CHECK_INTERVAL=600
NAME=ora.flprpd02.gsd
AUTO_START=1
CHECK_INTERVAL=600
NAME=ora.flprpd02.ons
AUTO_START=0
CHECK_INTERVAL=600
NAME=ora.flprpd02.vip
AUTO_START=1
CHECK_INTERVAL=60
저작자 표시 비영리
posted by starland
2011/01/11 15:32 블로그관련

Office 2010 Word에 연동해 보았습니다^^

tistory로 이사올수 있도록 초대장을 나눠주신 악랄가츠(http://realog.net/)님 감사드립니다.

아직 사이드바 위치도 못잡았지만,

열심히 활동하겠습니다!!

posted by starland
2010/12/30 14:06 WINDOW관련

 

배치 스크립트 모음

http://bcheul.tistory.com/156

 

배치 스크립트 경로

%~dp0관련

http://snoopybox.co.kr/970

posted by starland
2010/10/11 05:55 분류없음
http://blogdoc.nate.com/301543


posted by starland
2010/09/16 09:04 유용한 툴

완전 필요했던 기능!
쓸데없는 F1키 비활성화 하기

키보드 F1 키를 사용하지 않도록 Turn off (Remap)

키보드에 맵핑된 일부 키를 원하는 키로 변경(Remap) 할 수 있는 방법이 있을까요? 레지스트리 정보에 저장된 Scancode Map 을 변경하면 가능하긴 합니다만.... 왜 써야 하는지 아직 이해하지 못하고 있는 일인...;;;


[환경]
Windows XP


[문의사항]
개인의 취향(드라마 제목 아님)으로 F1 키를 자주 누르게 되는데 이 때, 도움말이 나오는 게 너무 싫음.
키보드 F1 키를 누르더라도 아무런 반응이 일어나지 않게 Turn off 하는 방법 문의


[해결방법]
아래 레지스트리 정보를 TurnOff_F1.reg 파일로 저장한 후 실행한 후 재부팅 하면 F1 기능은 Disable 됩니다. 이 기능을 원래 상태로 복구하기 위해서는 Scancode Map 키를 삭제하고 시스템을 재시작하면 됩니다. 레지스트리 변경은 항상 주의가 요구됩니다. 아시죠?

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout]
"Scancode Map"=hex:00,00,00,00,00,00,00,00,02,00,00,00,00,00,3b,00,00,00,00,00


02 : Scancode Map 정보를 1개 변경 (예를 들어 2개 변경 시 03)
00,00 : Turn off (다른 Key Scan Code 를 입력하면 기능이 바뀌겠지요)
3b, 00 : F1 Scan code


[제거방법]
명령 프롬프트에서 아래 명령을 실행하여 해당 키를 제거할 수 있습니다.

reg delete "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout" /v scancode /f


Scancode Map 값에 대한 설명은 아래 KB를 참조하시기 바랍니다.


[참고자료]
Key Scan Codes
http://msdn.microsoft.com/en-us/library/aa299374(VS.60).aspx

Disabling the Windows Key on Microsoft Natural Keyboard
http://support.microsoft.com/kb/181348/en-us


작성자 : Lai Go / 작성일자 : 2010.04.20

posted by starland
2010/09/05 18:04 Oracle관련
출처 : http://soff.tistory.com/133


Data Guard

Active Data Guard가 어떻게 실시간 쿼리를 통해 스탠바이 환경에 대한 투자를 가치 있게 만들면서, 물리적 스탠바이 데이터베이스를 스냅샷 스탠바이로 변환해, 아카이브 로그 및 많은 새로운 향상된 기능을 인프라에 적용하는지 자세한 정보를 알아 보겠습니다. Oracle Database 11g 다운로드


Oracle Database 11g에는 책 한 권을 채울 수 있을 만큼 많은 Data Guard의 향상된 기능이 있습니다. 따라서 모든 향상된 기능을 자세히 밝히기는 불가능합니다. 대신 가장 흥미롭다고 생각되는 것을 중심으로 설명하도록 하겠습니다.
보다 간편하진 스탠바이 데이터베이스 생성

이제 시작합니다. 먼저 물리적 스탠바이 데이터베이스의 생성입니다. Oracle Database 11g에서, 이 프로세스는 RMAN 커맨드 하나면 족할 정도로 무척 간편해졌습니다. 이전에는, 2대의 머신 사이에 Data Guard를 설정하려면, Grid Control 마법사 인터페이스를 사용했습니다. 이 글을 작성하고 있는 시점 에서는, Oracle Enterprise Manager Grid Control 11g는 아직 사용할 수 없고, Database Control도 Data Guard를 위한 마법사를 가지고 있지 않습니다. 그러나 SQL 커맨드 사용 경험의 유무에 상관없이, Oracle Database 11g에, Data Guard 환경을 설정하는 것은 어렵지 않습니다. 이는 너무 단순해 여기서 모든 단계를 설명할 수 있습니다.

prolin11로 명명된 기본 데이터베이스가 prolin1이라는 서버에서 운영되고 있다고 가정합니다. 스탠바이 데이터베이스는 prolin2라는 서버에 설정하려고 합니다. 스탠바이 데이터베이스 인스턴스의 명칭은 pro11sb입니다. 단계는 다음과 같습니다:
이미 가지고 있는 경우가 아니라면, 우선, prolin1에 spfile을 생성합니다.
SQL> create spfile from pfile;
이 단계는 필수적인 것은 아니지만, 프로세스를 쉽게 해주는 이점이 있습니다. 데이터베이스 생성 후, spfile을 사용하기 위하여 prolin11 데이터베이스를 다시 시작합니다

스탠바이 재실행 로그 생성은 필수적인 것은 아니지만, 그렇게 하는 것이 좋습니다. 스탠바이 재실행 로그는 기본 데이터베이스에 발생하는 변화를 거의 실시간으로 스탠바이에 반영되도록 하는데, 이것이 Real Time Apply (RTA)라는 개념입니다. 따라서, 우리는 여기서 기본 데이터베이스에 스탠바이 재실행 로그를 생성할 것입니다 (스탠바이 재실행 로그는 기본 데이터베이스에 생성된다는 것을 잊지 마십시오. RMAN이 이 일을 할 것입니다):
SQL> alter database add standby redo logfile group 4
  2> (‘+DG1/sby_redo01.rdo') size 50M;
SQL> alter database add standby redo logfile group 5
  2> (‘+DG1/sby_redo02.rdo') size 50M;
SQL> alter database add standby redo logfile group 6
  2> (‘+DG1/sby_redo03.rdo') size 50M;
SQL> alter database add standby redo logfile group 7
  2> (‘+DG1/sby_redo04.rdo') size 50M;
이를 통해 4개의 스탠바이 재실행 로그 그룹이 생성됩니다.

prolin2 서버의 listener.ora 파일에 pro11sb를 위한 입력을 합니다:
SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (GLOBAL_DBNAME = pro11sb)
      (ORACLE_HOME = /opt/oracle/product/11g/db1)
      (SID_NAME = pro11sb)
    )
  )
 
LISTENER =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = prolin2)(PORT = 1521))
  )
리스너를 실행하려면 재로딩합니다
prolin1에서, $ORACLE_HOME/network/admin: 하부의 tnsnames.ora 파일에 pro11sb 데이터베이스를 위한 입력을 합니다 :
PRO11SB =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = prolin2)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SID = pro11sb)
    )
  )
prolin2에서, Oracle Home/dbs 디렉토리에 1 라인을 포함하는 initodba11sb.ora 파일을 생성합니다:
db_name=prolin11
이는 스탠바이 인스턴스를 위한 초기화 파일로 기능할 것입니다; 파라미터의 나머지는 우리가 나중에 보게 될 RMAN 커맨드에 의해 자동 입력됩니다.

prolin2에서, $ORACLE_BASE/admin 디렉토리 갑니다. 여기에 pro11sb라는 이름의 디렉토리를 생성한 다음, 스탠바이 인스턴스에 대한 감사 파일을 보유하기 위하여 pro11sb 내에 adump라는 이름의 디렉토리를 생성합니다.

prolin1의 $ORACLE_HOME/dbs 디렉토리 하부에서, 흔히 orapworadba11로 명명되는 인스턴스 패스워드 파일을 볼 수 있습니다. 이 파일을 볼 수 없다면 (가능성은 희박하지만), 이를 생성합니다. 다음 그 파일을 prolin2의 $ORACLE_HOME/윤 하부로 복사합니다. 이를 orapwodba11sb 파일로 복사합니다. 이렇게 하면 기본 데이터베이스의 sysdba 연결 패스워드를 스탠바이에도 적용할 수 있습니다.

prolin2에서, NOMOUNT 상태의 인스턴스 pro11sb를 실행합니다:
$ sqlplus / as sysdba
SQL> startup nomount
이는 인스턴스를 실행하지만 아무것도 마운팅하지 않습니다.

이제 모든 초기화 준비가 완료되었으므로, 스탠바이 데이터베이스를 생성할 강력한 RMAN 스크립트를 호출합니다. prolin1에서, RMAN을 가동해 다음 스크립트를 실행합니다. 이를 파일에 저장하고 RMAN 프롬프트에서 스크립트를 실행하는 것은 매우 쉽습니다.
connect target sys/oracle123@prolin11
connect auxiliary sys/oracle123@pro11sb
 
run {
   allocate channel c1 type disk;
   allocate auxiliary channel s1 type disk;
 
   duplicate target database
        for standby
        from active database
        dorecover
        spfile
        parameter_value_convert 'prolin11','pro11sb'
        set db_unique_name='pro11sb'
        set db_file_name_convert='/prolin11/','/pro11sb/'
        set log_file_name_convert='/prolin11/','/pro11sb/'
        set control_files='/oradata/pro11sb/control01.ctl'
        set fal_client='pro11sb'
        set fal_server='prolin11'
        set standby_file_management='AUTO'
        set log_archive_config='dg_config=(prolin11,pro11sb)'
        set log_archive_dest_2='service=prolin11 LGWR ASYNC valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=pro11sb'
        set log_archive_dest_state_2='enable'
        set log_archive_format='pro11sb_%t_%s_%r.arc'
   ;
  sql channel c1 "alter system archive log current";
  sql channel s1 "alter database recover managed standby database using current logfile disconnect";
}
이 스크립트는 스탠바이 데이터베이스를 생성하고, 적절한 파라미터를 스탠바이 데이터베이스를 위한 spfile에 배치하고, 스탠바이 데이터베이스를 위한 진단 데스티네이션을 생성하고, 스탠바이를 다시 시작합니다. 이 작업의 정확한 구조를 이해하려면, 여기서 RMAN 커맨드의 아웃풋을 볼 필요가 있습니다.

아래의 2 라인은 기본 및 스탠바이 인스턴스에 연결됩니다:
connect target sys/oracle123@prolin11;
connect auxiliary sys/oracle123@pro11sb;
패스워드 파일을 스탠바이 호스트에 복사했기 때문에, SYS 패스워드는 동일하게 남아 있으며 따라서 스탠바이 인스턴스에 연결은 (마운팅 데이터베이스가 없지만) 성공적입니다. 다음으로, 다음과 같은 라인들이 실행됩니다:
duplicate target database for standby from active database
     spfile
        parameter_value_convert 'prolin11','pro11sb'
        set 'db_unique_name'='pro11sb'
        set 'db_file_name_convert'='/prolin11/','/pro11sb/'
        ... and so on ...
duplicate target database 커맨드는 우선 원격 서버에 있는 SQL*Net를 통해 기본 데이터베이스의 이미지를 복사함으로써 기본 데이터베이스로부터 스탠바이를 생성합니다. 복사가 완료되면, 내부적으로 커맨드를 발령하여 (switch clone datafile all;), 스탠바이 데이터베이스를 클론으로 만듭니다. 스크립트의 세트 커맨드가 스탠바이 인스턴스를 위한 SPFILE의 파라미터를 설정하며, 이 데이터베이스가 스탠바이 데이터베이스가 됩니다. 다시 말하지만, RMAN 아웃풋은 배후 활동에 대한 모든 정보를 제공합니다.
물리적 스탠바이 데이터베이스를 구축하는 것이 매우 쉽다는 것을 알아 두십시오. 이는 스크립트를 실행하는 것만큼이나 간단합니다!
Active Data Guard

물리적 스탠바이 데이터베이스를 사용하여 Data Guard 환경을 구현할 때 오랫동안 장애로 남아 있던 것 중의 하나는 스탠바이 데이터베이스의 수동성이었습니다. Oracle Database 10g 및 그 이전에는, 물리적 스탠바이 데이터베이스를 복구 프로세스를 멈춘 후에만, 읽기 전용 (말하자면, 리포팅 부담을 줄이기 위해)으로 개방했습니다. 이들 제품에서, Data Guard가 DR 솔루션의 일부이었다면, 뒤처지는 것이 두려워 오랫동안 복구 프로세스를 멈출 수 없었을 것이며, 따라서 물리적 스탠바이 데이터베이스는 읽기 전용을 위한 것이 아니라면, 당연히 무용지물이었을 것입니다

Oracle Database 11g로, 이제 상황이 변했습니다: 물리적 스탠바이 데이터베이스를 읽기 전용 모드로 개방하고 복구 프로세스를 다시 시작할 수 있습니다. 이는 기본 데이터베이스를 지속적으로 사용하면서 리포팅을 위해 스탠바이를 사용할 수 있다는 것을 의미합니다. (이전 버전의 경우와 마찬가지로, 스탠바이에서 백업도 할 수 있습니다.) 이것이 어떻게 이루어지는지 살펴 보겠습니다.

우선, 스탠바이 복구 관리를 취소합니다:
SQL> alter database recover managed standby database cancel;

Database altered.
다음, 데이터베이스를 읽기 전용으로 개방합니다:
SQL> alter database open read only;
 
Database altered.
여기까지는, 프로세스가 11g 이전 버전과 동일합니다. 이제, 11g의 정점을 살펴 보도록 하겠습니다: 스탠바이 데이터베이스가 읽기 전용으로 개방되어 있는 동안, 복구 프로세스 관리를 다시 시작할 수 있습니다.
SQL> alter database recover managed standby database disconnect;
 
Database altered.
이제 스탠바이 데이터베이스는 복구 관리 모드로 배치되어, 개방되어 있는 동안, 로그 파일을 적용합니다. 어떻게 이를 확인할 수 있을까요? 간단합니다; 단지 기본 데이터베이스의 최장 시퀀스 번호를 스탠바이의 그 것과 비교하면 됩니다. 기본 데이터베이스에서, 로그 변환을 하여 최장 시퀀스 번호를 확인합니다:
SQL> alter system switch logfile;
 
System altered.

SQL> select max(Sequence#) from v$log;
 
MAX(SEQUENCE#)
--------------
            79
로그 변환은 스탠바이가 읽기 전용 모드로 개방되어 있는 동안 진행됩니다. 스탠바이의 최장 시퀀스를 확인합니다:
SQL> select max(Sequence#) from v$log;
 
MAX(SEQUENCE#)
--------------
            79
이것 역시 79로 기본과 같습니다. 이는 로그 애플리케이션이 여전히 작업 중이라는 것을 보여줍니다. 여기서 이는 단순히 로그가 적용되고 있다는 것만을 보여주는 것이 아니냐는 의문이 생길 수 있습니다. 기본에서 진행되는 변화가 이 모드에서 보일까요? 확인해 보겠습니다. 기본에서, 테이블을 생성합니다:
SQL> create table test2 (col1 number);
 
Table created.
...그리고 나서 몇 개의 로그 변환을 하고 이들 로그가 스탠바이에 적용될 때까지 기다립니다. 다음으로 스탠바이 데이터베이스를 확인합니다:
SQL> desc test2
 Name                                      Null?    Type
 ----------------------------------------- -------- ---------------------------
 COL1                                               NUMBER
Presto! 테이블이 스탠바이에 생성되고, 쿼리가 가능해졌습니다.

이 경우, 기본에서 생긴 변화를, 네트워크가 사용 가능하다면, 스탠바이에 즉각 나타나게 해주는 Real Time Apply를 사용할 수 있었다는 것을 기억하십니까? RTA는 ADG에 필수적인 것은 아니지만, 기본에 생긴 최근의 변화를 보고자 할 때, ADG가 보다 유용한 것이 되도록 해줍니다

보안과 관련해선, 걱정할 것이 없습니다. 데이터베이스는 읽기 전용 모드에 있기 때문에, 아무것도 여기에 쓸 수 없습니다. 만약 audit_trail 파라미터가 기본에서 DB로 설정되어 있다면 (Oracle Database 11g에서의 디폴트), 스탠바이에서도 동일하지만, 일기 전용이기 때문에, 감사 추적을 쓸 수는 없습니다

알림 로그에 나타난 라인을 보십시오:
AUDIT_TRAIL initialization parameter is changed to OS, as DB is NOT compatible for database opened with read-only access
아하! 감사 추적은 멈추지 않습니다; 오히려, 데이터베이스가 개방되었을 때, OS 파일로 자동 전환됩니다. 스탠바이 데이터베이스를 활성화하면, audit_trail은 DB로 자동 재설정됩니다.
스냅샷 스탠바이

일반적 시나리오를 생각해 보겠습니다: 새로운 애플리케이션을 데이터베이스에 배치 중이고, 데이터베이스 성능의 영향에 대해 알고 싶다고 합시다. Oracle Database 11g에는, SQL 구문을 캡처하고 이를 재생하는 완벽한 툴이 있지만 (Database Replay), 그 영향력을 직접 실행해 보고 확인해 볼 필요가 있습니다. 테스트 시스템을 캡처하더라도, 프로덕션 시스템에서 재생하는 것은 불가능합니다. 우선, 배치가 되지 않습니다, 또한, 배치된다고 하더라도, 애플리케이션으로 다른 테이블을 변경할 수 없습니다. 그러면 애플리케이션의 영향력을 확인하려면 어떻게 해야 할까요?

완벽한 답은 물리적 스탠바이 데이터베이스를 업데이트가 가능한 스냅샷 스탠바이 데이터베이스로 임시 변환할 수 있는 Oracle Database 11g입니다. 이 모드에서, 애플리케이션을 운영할 수 있고—많은 테이블 변경 가능—그 영향력을 평가할 수 있습니다. 영향력을 평가한 후, 데이터베이스를 정상적 복구가 진행되고 있는 스탠바이로 변환할 수 있습니다. 이는 정해진 지점으로 플래시백하여 모든 변화를 원상 복구하는 플래시백 데이터베이스 기능을 사용하여 데이터베이스 복구 지점을 생성함으로써 가능합니다. 이 작업이 어떻게 진행되는지 알아보겠습니다:

우선, 이미 진행되고 있는 경우가 아니라면, 스탠바이에서 복구를 시작합니다:
SQL> alter database recover managed standby database disconnect;

Database altered.
복구가 몇 개의 로그 파일을 선정할 때까지 기다립니다. 그리고 복구를 중단합니다.
SQL> alter database recover managed standby database cancel;
 
Database altered.
여기서, 스냅샷 스탠바이 데이터베이스를 생성할 수 있습니다. 이것은 플래시백 로깅을 가능하게 하기 때문에, 플래시 복구 영역을 구성하지 않으면, 다음과 같은 메시지를 받게 됩니다:
ORA-38784: Cannot create restore point 'SNAPSHOT_STANDBY_REQUIRED_01/12/2008
00:23:14'.
ORA-38786: Flash recovery area is not enabled.
이를 피하기 위해서는, 미리 플래시 복구 영역을 생성해야 합니다. 이미 그렇게 하지 않았다 하더라도, 걱정할 필요는 없습니다. 지금 생성하면 되기 때문입니다:
SQL> alter system set db_recovery_file_dest_size = 2G;
 
System altered.
 
SQL> alter system set db_recovery_file_dest= '/db_recov';
 
System altered.
이제 절차를 마쳤으므로, 다음과 같은 간단한 커맨드를 사용해 스탠바이 데이터베이스를 스냅샷 스탠바이로 변환할 수 있습니다:
SQL> alter database convert to snapshot standby;

Database altered.
이제 데이터베이스를 리사이클링합니다:
SQL> shutdown immediate
ORA-01507: database not mounted
...
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
이제 데이터베이스가 읽기/쓰기 작업을 위해 개방되었습니다:
SQL> select open_mode, database_role
  2  from v$database;
 
OPEN_MODE  DATABASE_ROLE
---------- ----------------
READ WRITE SNAPSHOT STANDBY
이제 데이터베이스를 변경할 수 있습니다. 여기가 Database Replay를 사용하여 캡처한 작업을 재생할 최적의 지점입니다. 이제 데이터베이스에서 시스템을 변경하고 변화의 영향력을 보기 위하여 몇 차례 재생할 수 있습니다. 이것은 프로덕션 데이터베이스의 복사본이므로, 재생은 해당 작업을 정확하게 재현합니다.

테스트가 완료되면, 스냅샷 스탠바이 데이터베이스를 정상적인 물리적 스탠바이 데이터베이스로 변환합니다. 다음과 같은 단계를 거칩니다:
SQL> connect / as sysdba
Connected.
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
 
...
Database mounted.
SQL> alter database convert to physical standby;
 
Database altered.
이제 끄고, 데이터베이스를 마운팅하고 복구 관리를 시작합니다.
SQL> shutdown
ORA-01507: database not mounted
 
 
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
...
Database mounted.
Start the managed recovery process:
SQL> alter database recover managed standby database disconnect;
이제 스탠바이 데이터베이스가 복구 관리 모드로 복귀했습니다. 당연히, 데이터베이스가 스냅샷 스탠바이 모드에 있으면, 기본의 아카이브 로그가 적용되지 않습니다. 이것은 지금 적용되며 작업 완료까지 몇 분 걸립니다.

스냅샷 스탠바이 데이터베이스는 스탠바이 데이터베이스를 사용하여 프로덕션 데이터베이스의 변화를 사전에 정확히 예상할 수 있습니다. 그러나 이게 전부가 아닙니다. 또 다른 장점이 있습니다. 기본에서 생긴 변화를, 네트워크가 사용 가능하다면, 스탠바이에 즉각 나타나게 해주는 Real Time Apply를 사용할 수 있었다는 것을 기억하십니까? 누군가 기본 데이터베이스에서 대규모 업데이트를 하거나 일부 코드를 변경하는 등 실수를 한다면 어떻게 될까요? 이전 버전에서, 이 같은 실수가 스탠바이로 확산되는 것을 방지하기 위하여, 신중하게 스탠바이 데이터베이스에서 딜레이를 사용합니다. 그러나 딜레이로 인해, 스탠바이가 올바로 작동하지 않거나 프로덕션의 활성 카피로 사용될 수 없을 수 있습니다.

더 이상은 필요 없습니다. 스탠바이 데이터베이스를 플래시백할 수 있기 때문에, 딜레이를 유지하고 있을 필요가 없습니다. 문제가 있다면, 언제든지 이전 상태로 플래시백할 수 있습니다.
물리적 스탠바이에서 논리적 스탠바이로의 변환

이제 물리적 스탠바이 데이터베이스를 논리적인 것으로 쉽게 변환할 수 있습니다. 다음 단계를 거칩니다:
스탠바이 데이터베이스는 어딘가로부터 데이터 딕셔너리 정보를 가져올 필요가 있습니다. 딕셔너리 정보는 기본의 재실행 스트림에 배치되어야 합니다. 따라서, 기본 데이터베이스에서, 다음과 같이 하여 딕셔너리를 위한 LogMiner 테이블을 만듭니다:
SQL> begin
  2    dbms_logstdby.build;
  3  end;
  4  /
 
PL/SQL procedure successfully completed.
스탠바이에서, 복구 관리 프로세스를 멈춥니다
SQL> alter database recover managed standby database cancel;

Database altered.
이제, 스탠바이에 커맨드를 입력해 이를 논리적인 것으로 변환합니다:
SQL> alter database recover to logical standby pro11sb;
 
Database altered.
1 단계를 실행하지 않았다면, 위의 커맨드는 딕셔너리 정보가 없기 때문에, 멈춰 있을 것입니다. 이 경우 여기서 1 단계를 실행하면 됩니다. RTA를 실행했다면, 정보는 스탠바이 데이터베이스에 즉각 정보가 나타날 것입니다.
기본의 몇 가지 로그 변환을 통해 아카이브 로그를 생성해 스탠바이로 보내야 합니다:
SQL> alter system switch logfile;
 
System altered.
잠시 후, 스탠바이에서, 데이터베이스 변경 커맨드가 완료되는 것을 볼 수 있습니다. 이제 스탠바이가 논리적인 것으로 변했습니다. 알림 로그에서 다음과 같은 것이 나타납니다:
RFS[12]: Identified database type as 'logical standby'
Recycle the database:
SQL> shutdown
ORA-01507: database not mounted
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
 
Total System Global Area 1071333376 bytes
...
Database mounted.
SQL> alter database open resetlogs;
 
Database altered.
이제 논리적 스탠바이로 되었으므로, SQL Apply 프로세스를 시작해야 합니다
SQL> alter database start logical standby apply immediate;
SQL> alter database start logical standby apply immediate; 논리적 스탠바이 데이터베이스가 이제 완전 작동합니다! 일단 물리적 스탠바이를 논리적인 것으로 변환하면, 다음에서 설명할 특수 구문 ("keep identity")을 사용하지 않는 한 ,이를 다시 물리적인 것으로 변환할 수 없습니다.
롤링 업데이트

DBA의 업무에서 어려운 점은 업그레이드를 위해 꽤 오랜 시간 데이터베이스를 내려야 하는 정당성을 밝히는 것입니다. Oracle Database 11g에서는, 롤링 업데이트를 통해 어떠한 유형의 스탠바이 데이터베이스라도 가지고 있다면, 이 일은 매우 쉬어집니다:
스탠바이를 업그레이드합니다.
애플리케이션을 스탠바이로 옮깁니다.
기본을 업그레이드합니다.
애플리케이션을 다시 본래의 기본으로 옮깁니다.
이것이 논리적 스탠바이라면, 스탠바이가 단지 기본의 SQL을 적용하면 되기 때문에, 프로세스가 매우 간편합니다. SQL이 적용되면, 업그레이드는 해당 데이터베이스에서 쉽게 이루어집니다. 복구를 멈추고, 스탠바이를 업그레이드하고, 복구를 진행한 후, 스탠바이를 기본으로 변환할 수 있습니다. 나중에, 본래의 기본을 업그레이드 할 스탠바이로 만들 수 있습니다. 마지막으로, 역할을 바꿔, 본래의 기본을 새로운 기본으로 만들 수 있습니다.

그러나, 많은 스탠바이 데이터베이스는 사용 및 관리의 간편성을 위해 본질적으로 물리적입니다. 스탠바이가 논리적이 아니라 물리적이라면, 단계는 거의 흡사합니다. 스탠바이를 임시로 논리적으로 변환한 후 다시 물리적으로 변환하는 것입니다. 여기서 중요한 것은 영구적이 아니라 임시로라는 것입니다. 따라서, 다음과 같이 "keep identity"구문을 가진 변환 커맨드를 입력합니다:
SQL> alter database recover to logical standby keep identity;
 
Database altered.
보다 자세한 내용은 문서에서 확인할 수 있습니다.
기타 개선 사항

Data Guard 프로세스 자체에 몇 가지 중요한 개선 내용이 있습니다:
재실행 압축

Data Guard는 기본의 아카이브 로그를 스탠바이 데이터베이스 서버로 옮겨 이를 해당 데이터베이스에 적용한다는 전제를 가지고 있습니다. 기본과 스탠바이 사이의 시간 지체의 핵심 요소의 하나는 아카이브 로그를 옮기는 시간입니다. 이는 재실행 스트림을 압축하면 어느 정도 줄일 수 있습니다.

Oracle Database 11g에서는 TRUE로 설정된 파라미터 압축을 사용하여 SQL*Net를 통해 스탠바이 서버 전체를 경유하는 재실행 스트림을 압축할 수 있습니다. 이는 오로지 갭 해소 중에 옮겨지는 로그를 위한 것입니다. 이 문서의 앞부분에 제시된 사례에서 압축을 할 때 사용할 수 있는 커맨드는 다음과 같습니다.
alter system set log_archive_dest_2 = 'service=pro11sb LGWR ASYNC
valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=pro11sb compression=enable'
네트 타임 아웃

Data Guard 환경은 데이터베이스 인스턴스 연결을 통해 재실행 데이터를 스탠바이 서버로 보내 작동시킨다. 인스턴스가 시간 내 응답하지 않으면, 로그 전송 서비스는 지정된 타임 아웃 값을 기다린 후 중단합니다. 이 타임 아웃 값은 Oracle Database에 net_timeout이라는 파라미터를 사용해 설정할 수 있습니다. 최대 보호 모드에서, 로그 전송 서비스는 중단 전 20회의 재시도를 합니다.

그러나 우선 로그 전송에서 얼마만큼의 딜레이가 존재하는지 알아야 합니다. 새로운 뷰 v$redo_dest_resp_histogram에 막대 그래프 모양으로 시간이 나타납니다:
SQL> desc v$redo_dest_resp_histogram
 Name                   Null?    Type
 ---------------------- -------  --------------
 DEST_ID                         NUMBER
 TIME                            VARCHAR2(20)
 DURATION                        NUMBER
 FREQUENCY                       NUMBER
 
뷰는 해당 버킷에서 전송 시간 측정 결과를 보여줍니다. 작동 후 며칠 후 뷰를 조사해 보면, 타임 아웃에 설정에 대한 구상을 할 수 있을 것입니다. 다음과 같이 하여 타임 아웃 값을 설정할 수 있습니다:
alter system set log_archive_dest_2 = 'service=pro11sb LGWR ASYNC
valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE) db_unique_name=pro11sb compression=enable net_timeout=20'
다시 한 번 말하지만, 이는 앞에서 제시한 사례와 관련된 것입니다. 파라미터 값의 "net_timeout=20" 구문을 기억해 두십시오.
동적 변경 가능 파라미터

논리적 스탠바이 데이터베이스 환경 운영 프로세스에서, 프로세스를 튜닝하고 일부 파라미터 값을 조정할 필요가 있습니다. Oracle Database 11g에서, 이들 대부분의 파라미터는 온라인에서 업데이트할 수 있습니다. 뷰 dba_logstdby_parameters를 쿼리하면 이를 알 수 있습니다.
col name format a30
col value format a10
col unit format a10
col setting a6
col setting format a6
col dynamic format a7
select *
from dba_logstdby_parameters
order by name
/

NAME                           VALUE      UNIT       SETTIN DYNAMIC
------------------------------ ---------- ---------- ------ -------
APPLY_SERVERS                  5                     SYSTEM YES
EVENT_LOG_DEST                 DEST_EVENT            SYSTEM YES
                               S_TABLE
LOG_AUTO_DELETE                TRUE                  SYSTEM YES
LOG_AUTO_DEL_RETENTION_TARGET  1440       MINUTE     SYSTEM YES
MAX_EVENTS_RECORDED            10000                 SYSTEM YES
MAX_SERVERS                    9                     SYSTEM YES
MAX_SGA                        30         MEGABYTE   SYSTEM YES
PREPARE_SERVERS                1                     SYSTEM YES
PRESERVE_COMMIT_ORDER          TRUE                  SYSTEM NO
RECORD_APPLIED_DDL             FALSE                 SYSTEM YES
RECORD_SKIP_DDL                TRUE                  SYSTEM YES
RECORD_SKIP_ERRORS             TRUE                  SYSTEM YES
RECORD_UNSUPPORTED_OPERATIONS  FALSE                 SYSTEM YES
칼럼 DYNAMIC이 값을 동적으로 변경 가능한지를 보여 준다는 사실을 기억해 두십시오. 거의 모든 파라미터는 동적입니다. 예를 들어, 스탠바이를 멈추지 않고 파라미터 APPLY_SERVERS를 변경하려면, 다음과 같이 합니다.
SQL> begin
  2     dbms_logstdby.apply_set('APPLY_SERVERS',2);
  3  end;
  4  /
이는 apply_servers 값을 2로 설정하는데, 이는 스탠바이를 멈추지 않고 할 수 있습니다.
SQL Apply 이벤트 테이블

Oracle Database 10g에서, SQL Apply와 관련된 이벤트는 알림 로그에 작성되는데, 알림 혹은 리포팅 확인을 위하여 스크립트를 작성하는 편이 좋기 때문에, 그다지 유용한 것이 못됩니다. Oracle Database 11g에서, 이벤트는 디폴트로 SYSTEM 스키마의 새로운 테이블 LOGSTDBY$EVENTS에 작성되도록 되어 있습니다. 다음은 샘플 쿼리입니다:
select event_time, error
from system.logstdby$events
order by 1;
The output:
EVENT_TIME                    ERROR
----------------------------- -------------------------------------------------
13-JAN-08 11.24.14.296807 PM  ORA-16111: log mining and apply setting up
13-JAN-08 11.24.14.320487 PM  Apply LWM 2677727, HWM 2677727, SCN 2677727
14-JAN-08 07.22.10.057673 PM  APPLY_SET: APPLY_SERVERS changed to 2
14-JAN-08 07.22.11.034029 PM  APPLY_SERVERS changed to 2
14-JAN-08 07.45.15.579761 PM  APPLY_SET: EVENT_LOG_DEST changed to DEST_ALL
14-JAN-08 07.45.16.430027 PM  EVENT_LOG_DEST changed to DEST_ALL
여러 가지 이유로, 이 이벤트를 테이블에 가지고 있는 것이 좋습니다. 예를 들면, 조작 및 리포팅이 간편해집니다. 그러나 때로는, 특히 오류 및 메시지 알림 로그를 스캐닝하기 위한 모니터링 툴을 구현했다면, 이를 알림 로그에서 보는 것도 괜찮습니다. 이는 논리적 스탠바이 데이터베이스 적용 파라미터 "event_log_dest"를 "DEST_ALL"로 설정하면 가능해집니다:
begin
   dbms_logstdby.apply_set('EVENT_LOG_DEST','DEST_ALL');
end;
이는 동적으로 이루어지며, 이벤트는 테이블과 알림 로그 모두에 전달됩니다. 이 커맨드를 입력한 후, 알림 로그를 확인할 수 있습니다. 많은 SQL Apply 이벤트와 더불어 최소한 다음의 2 라인이 보일 것입니다:
LOGSTDBY: APPLY_SET: EVENT_LOG_DEST changed to DEST_ALL
LOGSTDBY status: EVENT_LOG_DEST changed to DEST_ALL
결론

우선, 우리는 활성 기본 데이터베이스로부터 물리적 스탠바이 데이터베이스를 구현하는 것이 별 것 아니라는 것을 알게 되었습니다. 또한, 물리적 스탠바이를 논리적으로 변환하는 것이 매우 간단하다는 것도 알게 되었습니다. 이 사실로부터 누릴 수 있는 최대의 장점은 스탠바이 데이터베이스를 어떤 방식으로든 비즈니스 지원을 위해 사용할 수 있다는 것입니다. Active Data Guard 기능은 스탠바이 데이터베이스를 개방해 아카이브 로그가 적용되는 동안 쿼리를 허용합니다. 스냅샷 스탠바이 데이터베이스는 데이터베이스에서 프로덕션 데이터베이스 로딩을 허용한 후 정상적 복구 관리 프로세스를 다시 시작하도록 처음 시작했던 지점으로 플래시백합니다. 이들 2가지 기능은 스탠바이 서버의 프로세싱 기능을 활용할 수 있도록 허용하기 때문에 11g로의 업그레이드를 위한 강력한 촉매 역할을 할 것입니다.

'Oracle관련' 카테고리의 다른 글

[ORACLE] ADG 관련  (0) 2010/09/05
[Oracle] 랜덤값 발생시키기  (0) 2010/09/05
[Oracle] 11g pivot, unpivot기능  (0) 2010/09/05
[Oracle]11g ADR adrci  (0) 2010/09/05
ORA-01555 snapshot too old  (0) 2010/08/11
[ORACLE] 펌 spfile 과 pfile (startup pfile='/xxxx/xxxx/init<SID>.ora')  (0) 2010/03/28
posted by starland
TAG adg, oracle
 <PREV 1 2 3 4 5 ... 17    NEXT>