'Oracle/Oracle Scrap' 카테고리의 글 목록

http://kr.forums.oracle.com/forums/thread.jspa?threadID=619271&tstart=0

=========================================================================

PURPOSE

--------------------------------------------------------------------------------

Oracle10g 이상에서는 HANG 발생으로 DB 접속 안될때 OS 디버거 사용안하고도

sqlplus -prelim 옵션으로 간단하게 SYSTEMSTATE DUMP 를 받을 수 있다.

EXPLANATIONS

--------------------------------------------------------------------------------

1. 사용방법

$ sqlplus -prelim / as sysdba

SQL> oradebug setmypid

SQL> oradebug unlimit

SQL> oradebug hanganalyze 1

SQL> oradebug dump systemstate 266

30 초 WAIT

SQL> oradebug dump systemstate 266

30 초 WAIT

SQL> oradebug dump systemstate 266

2. 주의사항

(1) 9.2.0.6 이상에서는 SYSTEMSTATE DUMP LEVEL 266 사용을 권장한다.

LEVEL 266 는 프로세스의 short call stack 을 생성하여 blocker 원인 분석에 유용하다.

(2) 오라클 엔지니어들이 사용하는 SYSTEMSTATE DUMP 분석 툴에서 한 트레이스

파일에 있는 여러개의 SYSTEMSTATE DUMP 들을 비교하여 blocker 를 결정하므로

SYSTEMSTATE DUMP 들이 한 트레이스 취합되도록 동일 세션에서 30초 간격으로 3번 수행한다.

(3) -prelim 옵션 사용시 ORA-7445 에러발생하면 PGA 변수 초기화하여 사용한다.

sqlplus -prelim '/ as sysdba'

oradebug setmypid

oradebug unlimit;

oradebug call ksmcpg

oradebug dump systemstate 266

(4) SYSTEMSTATE DUMP LEVEL 266 사용시 OS 에따라 프로세스의 short call stack

생성 속도와 부하가 다르므로 프러덕션에서 사용 전에 꼭 테스트 후 사용 권장한다.

만약 LEVEL 266 이 너무 느리거나 부하가 많다면 LEVEL 10 을 사용한다.

References

--------------------------------------------------------------------------------

Note 121779.1 - Taking Systemstate Dumps when You cannot Connect to Oracle

Note 417879.1 - ORA-07445 kgllkd With -prelim Option When Running System State Dump

============================================================================================

[경험담]
sqlplus "/as sysdba" 로 접속하였을 때
무슨 이유인지는 모르겠지만 hang이 걸린것 처럼 커서만 깜빡이고 접속이 되질 않았다.

위 설명대로 하였지만,
sqlplus -prelim / as sysdba 조차도 접속이 되질 않아 테스트를 못해보고 있는 상황이다.

결국에는 시스템을 껐다켜니 접속이 되었다.

저작자표시 비영리 변경금지

'Oracle > Oracle Scrap' 카테고리의 다른 글

[스크랩] CHECKPOINT NOT COMPLETE에 대해서 (0)	2011.11.23
[스크랩] 대기 이벤트 (0)	2011.04.14
[스크랩] OPatch (0)	2011.03.11
[스크랩] Patch Set, CPU, PSU 차이점 분석 (0)	2011.03.03
[스크랩]ORA-12801 (0)	2011.01.26

http://forums.oracle.com/forums/thread.jspa?threadID=468708

제품 : ORACLE SERVER

작성날짜 : 2003-06-10

CHECKPOINT NOT COMPLETE에 대해서
================================

database가 전체적으로 멈춘것처럼 어떠한 새로운 작업도 진행이 안되는 경우,
alertSID.log file를 확인해 보면 아래와 같은 message가 적힌 경우가 있다.

Checkpoint not complete

이러한 message가 의미하는 것은 무엇이며, 왜 발생하는지, 그리고 어떠한 조치가
가능한지 자세히 살펴본다.

1. checkpoint란 무엇인가?
~~~~~~~~~~~~~~~~~~~~~~~~~
checkpoint는 memory내의 block buffer의 내용과 disk상의 data block간의 내용을
맞추는 database event라고 할 수 있다.
checkpoint가 발생하면, 그때까지 memory내의 block에 가해진 모든 변경 사항을
disk상의 datafile내에 반영하게 된다. database crash에 의해 recovery가 필요
하게 되면 이 checkpoint이후의 변경사항에 대해서만 recovery를 시도하면 되므로,
recovery를 쉽고 효율적으로 수행할 수 있다.

checkpoint중에 수행되는 작업은 다음 두 가지로 정리할 수 있다.
- DBWR가 buffer cache내의 모든 변경된 block을 datafile에 기록한다.
- LGWR(혹은 CKPT)가 현재 발생한 checkpoint의 SCN값을 datafile과 controlfile
에 기록한다.

여기에서 중요한 것은 checkpoint event가 발생하여 block buffer에 어느 block이
disk로 씌여져야 하는가를 표시하면 dbwr는 이렇게 표시된 buffer를 순서와 관계없이
disk로 write하게 된다. 즉 redo log group1에 대한 buffer를 checkpoint하고 있는
중에 redo log group2에 대한 checkpoint요청이 들어오면 redo log group1에 대한
checkpoint를 끝내고 group 2에 대한 처리를 하는 것이 아니고, redo log group1에
대한 checkpoint가 진행 중에 redo log group2에 해당하는 buffer도 buffer cache
내에 모두 표시한 후 이것도 모두 group 1과 group 2의 구별이나 순서는 유지하지
못한채 같이 checkpoint가 이루어지는 것이다.
이것은 이후에 설명할 Checkpoint not complete가 발생하는 원인을 밝혀주는
중요한 근거가 된다.

checkpoint가 발생되는 경우는 다음 4가지 경우이다.
(1) log switch
(2) log_checkpoint_interval 만큼의 os block 간격
(3) log_checkpoint_timeout 초 간격
(4) alter system checkpoint명령문 수행시
앞의 세가지 경우에 대해서는 아래 별도의 section으로 자세히 설명하였다.

2. checkpoint와 성능
~~~~~~~~~~~~~~~~~~~~

checkpoint를 자주하면 db crash후 recovery시간을 줄일 수 있는 대신에, 운영
중에서는 속도를 저하시킨다. checkpoint중에는 해당 datafile의 header내용이
고정되어 datafile header에 대한 다른 작업이 진행되지 못한다. 또한
checkpoint간격이 너무 짧으면 뒤에서 설명할 'checkpoint not complete'
현상이 발생할 가능성도 커지게 되어 checkpoint에 대한 tuning이 필요하게
되는 것이다.

3. CKPT process
~~~~~~~~~~~~

checkpoint 수행 중 checkpoint SCN의 값을 controlfile과 datafile header에
반영시키는 작업을 수행하는 background process는 LGWR 혹은 CKPT process이다.
LGWR와 CKPT중 어느 process가 작업하는지는 Oracle version과 checkpoint_process
라는 parameter에 의해 결정된다. CKTP process를 사용하여 LGWR process의
작업을 줄이는 것이 성능 향상에 상당한 도움이 되기 때문에 oracle version이
증가할수록 CKPT process의 사용이 자동으로 유도된다.

(1) Oracle 7.0 - 7.3.2
initSID.ora file에 CHECKPOINT_PROCESS=TRUE 로 지정되어 있는 경우만,
CKPT process가 구동된다.

(2) Oracle 7.3.3, 7.3.4
db_files가 50이상이거나, 혹은 db_block_buffers값이 10,000 이상이면,
CHECKPOINT_PROCESS parameter에 관계없이 항상 CKPT process가 구동된다.
CHECKPOINT_PROCESS를 TRUE로 지정하면 db_files나 db_block_buffers값과
무관하게 CKPT process가 기동된다.

(3) Oracle8 8.0.3이상
CKPT process 는 항상 기동되어, CHECKPOINT_PROCESS를 지정하면, 다음과
같은 오류가 발생한다.

LM-101 "unknown parameter name checkpoint_process"

4. checkpoint가 발생되는 시점
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
checkpoint가 발생하는 시점은 아래와 같이 4가지 경우가 있다.

(1) log switch
log switch가 발생하면 항상 checkpoint가 발생한다. 단, checkpoint가
발생한다고 하여 log switch가 되는 것은 아니다. log swtich가 되는 경우는
사용 중인 log file이 모두 씌여졌거나, 명시적으로
'alter system switch logfile' 문장을 수행한 경우이다.

online redo log file의 크기는 성능과 복구에 중요한 영향을 미친다.

(2) LOG_CHECKPOINT_INTERVAL
이 parameter의 단위는 OS block size로, 이 크기만큼의 redo log file에
기록한 후에 checkpoint가 발생하는 것이다.
예를 들어 log_checkpoint_interval로 10,000이 지정되어 있고, 대부분의
Unix의 경우처럼 한 os block size가 512 bytes이면, 10,000 * 512 bytes =
5m가 된다.
redo log file의 크기가 20m라고 가정할 때, 5m마다 checkpoint가 발생하므로,
redo log file하나를 기록하는 동안 4번의 checkpoint가 발생하는 것이다.

그러나 반대로 log file이 이 크기보다 작은 3m라면 log_checkpoint_interval
parameter는 무시되고 log swtich발생마다, 즉 log file에 3m만큼 기록한
후에는 항상 checkpoint가 발생하게 된다.

(3) LOG_CHECKPOINT_TIMEOUT

이 parameter의 단위는 초(second)이며, 이 시간 간격으로 checkpoint가 발생
하게 된다. log swtich전에 checkpoint가 발생하길 원한다면
log_checkpoint_timeout보다는 log_checkpoint_interval을 사용하도록 권장한다.
log_checkpoint_timeout은 transaction이 발생하지 않아도 일정 시간이 지나면,
무조건 checkpoint를 발생하게 하여 불필요한 checkpoint를 발생시키기 때문이다.

5. 그 외의 checkpoint관련 parameter
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(1) DB_BLOCK_CHECKPOINT_BATCH

이 parameter는 Oracle7과 Oracle8.0까지만 사용되는 것으로 checkpoint시에
DBWR가 한번에 disk에 write하는 block buffer의 갯수를 지정한다.
이것을 32정도의 큰 값으로 지정하면 checkpoint속도를 향상시킬 수 있다.

(2) LOG_CHECKPOINTS_TO_ALERT

log swtich는 항상 alert.log에 기록이 남는다. log switch보다 자주
checkpoint가 발생하도록 한 경우 checkpoint발생 시간과 간격을 확인하려면
log_checkoiint_to_alert=true로 init.ora file에 지정하면 확인이 가능하다.

6. redo log file과 checkpoint
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

앞에서 언급한 바와 같이 log switch시에는 항상 checkpoint가 발생한다. 일반적
으로, log_checkpoint_interval이나 log_checkpoint_timeout을 log swtich보다
간격을 크게 하여 checkpoint가 log swtich시에만 발생하도록 사용한다.

redo log file의 크기가 너무 작으면 불필요한 checkpoint작업이 자주 발생할 수
있다. alert.log를 보면 아래와 같은 형태의 log switch에 대한 기록이 남게
되는데, 이것을 통해 log switch 발생 간격을 확인할 수 있다.

Thread 1 advanced to log sequence 248
Current log# 2 seq# 248 mem# 0: /prod1/oradata/logs/redologs02.log

log switch가 자주 발생하게 되면 성능 저하를 가져올 수 있으며, 일반적으로
oracle에서는 한시간에 한번 정도의 log swtich를 권장하고 있다.
오라클 사용자의 경우 log file을 작게 유지하는 이유 중 current redo log file의
corruption시 잃게되는 정보의 양이 log file이 클 수록 비례적으로 큰것을
염려하는 경우가 많은데 이러한 경우는 redo log file에 member를 두고,
그 member를 다른 disk에 위치시킴으로써 위험을 줄일 수 있다.

log file의 크기가 너무 작아 log switch가 자주 발생하게 되는 경우의 또 다른
문제점은 log file의 status가 ACTIVE인 상태로 오래 지속되는 것이다. 이것은 아래
설명할 checkpoint not complete같은 현상에도 직접적인 영향을 미친다.

redo log file은 log swtcih가 발생하고 checkpoint가 진행되는 동안 status가
ACTIVE 상태가 된다. 이것은 해당 redo log에 대한 checkpoint가 완전히 끝나면,
INACTIVE 상태로 변경된다.
그런데 log switch에 의해 checkpoint event가 발생된 경우 아직 이전 redo log
file에 대한 checkpoint가 끝나지 않았다면 이전 checkpoint와 새로운
checkpoint가 구별되어 수행되는 것이 아니고 이전 checkpoint와 새로운
checkpoint가 하나로 묶여 새로운 checkpoint까지 끝나야만 이전 redo log
file도 같이 INACTIVE 상태로 변경이 된다. 이미 1번 checkpoint란 무엇인가
에서 이미 언급한 내용이다.

실제 운영중에 redo log file의 대부분이 ACTIVE인 상태로 유지되다가 batch작업이
끝날때쯤 한꺼번에 모두 INACTIVE로 되는 현상이 바로 이러한 원인때문이다.
즉, 이것은 맨 처음 redo log file에 대한 내용도 여전히 checkpoint가 끝나지 않아,
나머지 redo log 들이 모두 기다리고 있는 현상이 아니라, 빈번한 log switch로
인해 바로 직접의 log에 대한 checkpoint가 끝나기 전에 다음 checkpoint가 요청
되고 이러한 일들이 계속 이어짐에 따라 checkpoint작업이 연속적으로 묶여
발생하는 것이다. 이러한 이유로 실제로는 redo log file의 내용의 대부분이
checkpoint가 이루어졌지만, 다수가 ACTIVE인 상태로 존재하는 현상이
발생하는 것이다.

checkpoint중인 datafile header는 다른 작업이 blocking되기 때문에 checkpoint
중인 상태로 오래 지속되는 것은 바람직하지 않으며, 그래서 적정한 redo
log file의 크기와 갯수가 중요하게 된다.

7. CHECKPOINT NOT COMPLETE
~~~~~~~~~~~~~~~~~~~~~~~~~
다량의 data를 import하거나 load하는 경우 혹은 batch 작업을 진행하는 경우,
database작업이 중간 중간 멈추는 hang현상이 발생하면서, alert.log file에
다음과 같이 'Checkpoint not complete'라는 message가 여러번 적힌 것을 발견
하게 되는 경우가 있다.

Thread 1 advanced to log sequence 248
Current log# 2 seq# 248 mem# 0: /prod1/oradata/logs/redologs02.log
Thread 1 cannot allocate new log, sequence 249
Checkpoint not complete

이 message가 나타내는 것은 LGWR가 redo log를 재사용하려고 하는데, 아직 그
redo log file이 checkpoint가 끝나지 않은 상태임을 나타낸다. 예를 들어,
LGWR가 1번 redo log group에 내용을 기록하고, 2번으로 switch하면서 1번에
대한 checkpoint가 진행중인 상태에서 2번 3번 redo log도 모두 사용하고 다시
1번을 사용하려고 하면 이러한 메시지가 alert.log에 적히게 되고, 1번을 다시
사용할 수 있을 때까지 db의 모든 변경 작업은 waiting상태가 된다.

이러한 현상은 database에 변경을 가하는 dml이 한꺼번에 빠르게 수행되는 경우
LGWR가 redo log file에 빠른 속도로 많은 내용을 기록하는 경우 발생한다.

redo log file의 크기나 갯수가 작아 log switch가 빈번히 발생하는 경우,
LGWR가 redo log에 redo정보를 적으면서 한바퀴 cycle을 도는 시간이 너무
빠르면 이러한 현상은 쉽게 발생 가능하다.
앞 section에서 언급했듯이 oracle에서는 한시간에 한번 정도의 log switch와
log switch시에만 checkpoint가 발생하는 것을 기본적으로 권장한다.

그런데 redo log file의 갯수를 몇개 더 추가하고 size를 증가하였는데도,
마찬가지로 이러한 현상이 발생하는 경우가 있다. redo log group을 추가하여도,
redo log group을 추가할때만 사용이 되다가 다시 추가한 redo log group까지
모두 status가 ACTIVE이다가 어느 정도 시간이 지나거나 작업이 끝나면 동시에
모든 redo log group이 INACTIVE상태로 변경되는 것을 볼 수 있다.

이것은 이미 앞에서 여러차례 설명했듯이 이미 수행중인 checkpoint가 끝나지
않은 경우 다음 checkpoint가 들어오면 이것이 하나로 묶이게 되기 때문이며,
아래에 정리한 방법을 이용하여 tuning하여야 한다.

Checkpoint not complete현상을 해결하기 위한 방법을 정리해 보면 다음과 같다.

(1) LGWR가 redo log file을 한바퀴 도는 cycle을 지연시킨다.
- redo log group을 추가시킨다.
- redo log file의 크기를 증가시킨다.

(2) checkpoint를 자주 발생하지 않도록 한다.
- LOG_CHECKPOINT_INTERVAL의 값을 증가시킨다.
- online redo log file의 크기를 증가시킨다.

(3) checkpoint 작업의 효율성을 증가시킨다.
- CHECKPOINT_PROCESS=TRUE 로 지정하여 CKPT process를 기동시킨다 (Oracle7)
- db_block_checkpoint_batch의 값을 증가시킨다 (7.X ~ 8.0)
- db_block_size를 증가시켜 dbwr가 checkpoint시 disk에 write하는 속도를
향상시킨다.
이것은 database를 완전히 다시 만드는 작업이어서 쉽게 조치하기는
어려우나 이 문제가 자주 발생하여 심각한 영향을 미치는 경우 고려해
볼 수 있다.

Reference Documents

<Note:147468.1> Checkpoint Tuning and Troubleshooting Guide

저작자표시 비영리 변경금지

'Oracle > Oracle Scrap' 카테고리의 다른 글

Diagnostics) Oracle10g DB 접속 안될때 sqlplus 에서 SYSTEMSTATE DUMP 받기 (0)	2011.12.22
[스크랩] 대기 이벤트 (0)	2011.04.14
[스크랩] OPatch (0)	2011.03.11
[스크랩] Patch Set, CPU, PSU 차이점 분석 (0)	2011.03.03
[스크랩]ORA-12801 (0)	2011.01.26

참고URL : http://www.gurubee.net/pages/viewpage.action?pageId=3902699

개념

1. 대기 이벤트란 오라클 인스턴스 내에서 공유된 자원을 사용하기 위해 프로세스들이 점유를 해야하는데

이 때 점유를 하지 못하는 상태에서는 sleep 상태에 빠지며, 이 때 발생되는 현상을 대기 이벤트라고 한다.

그때마다 오라클은 그 상태 정보를 파일 또는 SGA 메모리 내에 저장해 둔다.

2. 오라클 개발자들이 디버깅 용도로 개발한 것이라고 한다.

그것이 오늘에 이르러 OWI라는 이름을 덧입으면서 성능 관리 분야에 일대 변혁을 가져오게된다.

시스템 커널 레벨에서의 표현

1. 다른 프로세스를 기다려야 하는 상황에서 CPU를 쥔 채 대기하면 불필요하게 CPU 자원을 낭비하는 것이므로

CPU를 OS에 반환하고 수면(sleep) 상태로 빠지는 것을 말한다.

2. 수면 상태에 빠진다는 것은 프로세스가 wait queue로 옮겨지는 것을 말하며, wait queue에 놓인

프로세스에게는 CPU를 할당해 줄 필요가 없으므로 OS는 해당 프로세스를 스케쥴링 대상에서 제외 시킨다.

3. 선행 프로세스가 일을 마치면 OS에게 그 사실을 알려 자신을 기다리던 수면 상태의 프로세스를 깨우도록

신호를 보낸다. 그럼 OS는 그 프로세스를 runnalble queue에 옮김으로써 가능한 빨리 CPU를 할당 받아

일을 재개할 수 있도록 스케쥴링한다.

대기 이벤트는 언제 발생할까?

1. 자신이 필요로 하는 특정 리소스가 다른 프로세스에 의해 사용 중일때

- 자신이 읽으려는 버퍼에 다른 프로세스가 쓰기 작업을 진행 중이라면 선행 프로세스가 일을

마칠 때까지 기다려야 한다.

'buffer busy waits','latch free','enqueue' 이벤트 등이 여기에 속함

2. 다른 프로세스에 의해 선행작업이 완료되기를 기다릴 때

- DBWR가 Dirty 버퍼를 디스크에 기록할 때, 먼저 LGWR가 로그 버퍼에 있는 Redo Entry를

Redo Log 파일에 기록하는 작업이 선행되어야 하는데 이때 DBWR는 LGWR를 깨워 로그 버퍼를 비우라는

신호를 보내고 LGWR가 일을 마칠 때까지 수면 상태에서 휴식을 취함.

- LGWR가 일을 마치면 DBWR를 깨우고 자신은 다시 대기 상태로 빠진다.

'write complete waits','checkpoint completed','log file sync','log file switch' 이벤트 등이 여기에 속함

3. 할 일이 없을 때(idle 대기 이벤트)

- 서버 프로세스는 쿼리 결과를 사용자에게 전송하는 동안 array 단위로 일을 처리하는데 array 크기만큼

데이터를 전송하면 다음 Fetch Call를 받을 때까지 기다림. 쿼리 결과집합을 모두 전송하고 나서도

다음 Parse Call 또는 Execute Call를 받을 때까지 기다린다.

'SQL*Net message from client' 등이 여기에 속함

session 1(scott 계정) session2(scott 계정)

SQL>conn scott/tiger SQL>conn scott/tiger

Connected. Connected.

SQL> insert into dept values(90,'DBA','BUSAN'); SQL> insert into dept values(90,'DBA','BUSAN');

1 row created. Hang 상태에 빠짐

SQL>

session3(system 계정)

sqlplus system/-****

SQL> select *

2 from v$session_wait

3 order by wait_class, event, sid;

SID EVENT

--- ----------------------------

140 enq: TX - row lock contention <-- 대기 이벤트 발생.

SQL> select blocking_session_status, blocking_session

2 from v$session

3 where sid = 140;

BLOCKING_SESSION_STATUS BLOCKING_SESSION

----------------------------- --------------------

VALID 155 <-- SID 155가 140을 blocking 하고 있음.

SQL> select * from v$session_wait_class where sid=140;

SID SERIAL# WAIT_CLASS_ID WAIT_CLASS# WAIT_CLASS TOTAL_WAITS TIME_WAITED

--- -------- --------------- -------------- ------------ -------------- -------------

140 2564 4217450380 1 Application 649 188869

140 2564 3386400367 5 Commit 4 16

140 2564 2723168908 6 Idle 36 177751

140 2564 2000153315 7 Network 36 0

140 2564 1740759767 8 User I/O 1 7

->application에 관련된 세션 wait 이벤트가 649회 188869에 걸쳐서 발생됨.

-- session wait history 정보를 자동 저장 관리하고 있다.

SQL> select event, wait_time, wait_count

2 from v$session_wait_history

3 where sid=145;

-- wait 이벤트중 (lock 이 걸렸을 때.)

EVENT WAIT_TIME WAIT_COUNT

---------------------------- ----------- -------------

enq: TX - row lock contention 293 1

-- wait 이벤트가 끝났을 때

EVENT WAIT_TIME WAIT_COUNT

---------------------------- ----------- -------------

log file sync 8 1

SQL*Net message from client 261 1

SQL*Net message to client 0 1

SQL*Net message from client 2 1

SQL*Net message to client 0 1

enq: TX - row lock contention 150 1

SQL*Net message from client 9261 1

SQL*Net message to client 0 1

SQL*Net message from client 2 1

SQL*Net message to client 0 1

대기 이벤트는 언제 사라질까?

1. 오라클 프로세스가 자신이 작업을 진행할 때 선행 프로세스가 먼저 점유하여 대기 상태에 빠질 경우

선행 작업이 끝나고 나서 자신에게 알려주어 일을 진행하거나, 타이머에 설정된 시간에 깨어나

선행 프로세스가 작업을 모두 마쳤는지 확인할 때 사라짐.

2. 대기 상태에 빠진 프로세스가 기다리던 리소스를 사용할 수 있게 될 경우

3. 작업을 계속 진행하기 위한 선행작업이 완료 될 경우

4. 해야 할 일이 생겼을 경우

'Oracle > Oracle Scrap' 카테고리의 다른 글

Diagnostics) Oracle10g DB 접속 안될때 sqlplus 에서 SYSTEMSTATE DUMP 받기 (0)	2011.12.22
[스크랩] CHECKPOINT NOT COMPLETE에 대해서 (0)	2011.11.23
[스크랩] OPatch (0)	2011.03.11
[스크랩] Patch Set, CPU, PSU 차이점 분석 (0)	2011.03.03
[스크랩]ORA-12801 (0)	2011.01.26

남궁혁 | 한국오라클

오라클에서는 패치 관리 유틸리티 Opatch를 통해 새로운 패치 관리 기능들을 제공하고 있다.
여기서는 Opatch의 구성 및 설치 방법과 각 명령어의 사용법을 소개한다.
아울러, 기존에 발생했던 몇 가지 문제들도 소개함으로써, 독자의 Opatch 사용에 도움을 줄 것이다.

오라클에서는 특정 문제를 완벽하게 해결한 패치셋(patchset)이나 차기 릴리즈를 발표하기 전에 임시 패치(interim patch, 혹은‘one-off’patch) 를 제공하여 해당 문제에 적용할 수 있도록 하고 있다. 물론, 이 임시 패치 는 특정 버전의 컴포넌트에만 적용할 수 있다. 예를 들어, Oracle Database 8.1.7.3에 대해 생성된 임시 패치는 Oracle Database 8.1.7.4에 는 적용할 수 없다. 그리고, 대부분의 임시 패치는 차기 패치셋에 포함된다. 그런데, 이 임시 패치는 해당 문제가 해결됐는지는 테스트하지만, 패 치가 적용된 후 발생할 수 있는 부작용 등을 테스트하는 리그레션 (Regression) 테스트는 하지 않는다. 이 리그레션 테스트는 패치셋에서 테 스트된다. 따라서 특별한 경우가 아니라면, 임시 패치를 적용하기보다는 패치셋을 적용할 것을 권한다.
임시 패치를 여러 개 적용하다 보면, 이전 임시 패치와의 충돌이 발생 하기도 한다. 이를 방지하기 위해서, 임시 패치를 요청할 경우에는 Oracle Support에 이전에 설치한 모든 임시 패치 리스트를 제공하여, 충돌여부를 확인하고, 만약 충돌 발생시 병합하는 과정을 거치도록 해야 한다(임시 패 치 적용시 또 하나 주의할 점은 함께 제공되는 해당 패치의 Readme 파일 을 꼭 확인하는 것이다).
Oracle Database 9.0.1 버전까지는 패치 적용시 셸 스크립트를 이용 하여 패치를 적용하도록 되어 있었다. 그러나 9.2 버전부터는‘Opatch’라 는 패치 관리 유틸리티가 등장하여, 이전에 없었던 새로운 패치 관리 기능 들을 제공하고 있다.
이 글에서는 Oracle Database 9.2에서 패치 적용시 사용되는 Opatch 의 구성 및 설치 방법, 각 명령어의 사용방법에 대해 알아보도록 하겠다. 그 리고 기존에 발생했던 대표적인 Opatch 적용시의 문제들도 간략하게 소 개한다.

Opatch 사용 환경 및 설치 방법

Opatch는 Oracle Database 9.2 이상의 오라클 데이타베이스와 Oracle Application Server 10g에 임시 패치를 적용하는 과정을 지원한다. 현재 지원되는 플랫폼은 Unix와 Windows 계열이며, 현재 IBM OS/390에 대 해서는 지원하지 않는다. 따라서, IBM OS/390에 대해서는 이전(Oracle Database 9.0.1 이전 방식)과 동일하게 임시 패치를 적용해야 한다.
Opatch는 Oracle Database 9.2에 포함되어 있지 않으며, 설치하려면 Oracle Metalink에서 다운로드해야 한다. 다운로드 절차는 다음과 같다.

1.Oracle Metalink(http://metalink.oracle.com)에 로그인한다.
2.PATCHES 버튼을 선택한다.
3.Simple Search 링크를 선택한다.
4.Patch(s) Numbers 폼에‘2617419’를 입력한다.
5.Platform or Language 리스트에서 해당 플랫폼을 선택한다.
6.Go 버튼을 선택한다.
7.다음 항목을 선택한다.
2617419 Universal Installer: Patch OPATCH ARU PLACEHOLDER. (10.1.0.2)
8.다운로드가 진행된다.
9.다운 받은 파일을 압축 해제한다.
$ unzip p2617419_10102_GENERIC.zip
10.User Path에 등록한다.
For Korn / Bourne shell : % export PATH=$PATH:/oracle/opatch/Opatch For C Shell : % setenv PATH $PATH:/oracle/opatch/Opatch

Opatch를 실행을 위한 요구사항.

● Perl : 최소 Perl 5.0.0.5_03 이상이 시스템에 설치되어야 하며, 5.6 버전 이상 이 권장된다. Perl은 오라클 설치시‘Typical’옵션으로 설치하거나, ‘Custom’설치시 Apache Web Server를 선택하면 $ORACLE_HOME/ Apache/perl에 설치된다.

● Inventory : 오라클 제품은 두 개의 인벤토리를 유지하는데, 하나는 oraInst.loc 파 일 에 서 지 시 하 는 센 트 럴 인 벤 토 리 이 며 , 보 통 $ORACLE_BASE/oraInventory의 이름으로 존재한다. 이 인벤토리는 설치 된 오라클 제품의 정보를 보관한다. 또 하나의 인벤토리는 로컬 인벤토리로, $ORACLE_HOME/inventory에 위 치 한 다 . 이 인 벤 토 리 에 는 특 정 ORACLE_HOME에 설치된 컴포넌트 정보를 저장한다. 이 두 개의 인벤토리 가 정상적으로 유지되어야 한다(참고로, oralnst.loc의 위치는 AIX, Linux는 /etc 디렉토리에 위치하며, 다른 Unix에서는 /var/opt/oracle에 위치한다. Windows는 레 지 스 트 리 에 서 HKEY_LOCAL_MACHINE/Software/ Oracle/Oracle/inst_loc 항목에 지정된 위치에 있다).

● Opatch : Oracle9i Database에는 Opatch 유틸리티가 번들되어 있지 않으므 로, 앞에서언급한것처럼Oracle Metalink에서다운받아야하며, 해당패치넘 버로 최신Opatch 버전이 업데이트되므로, 항상 최신 버전을 유지하도록 한다.

● Path : RAC(Real Application Cluster)에서 임시 패치 적용시, $ORACLE_ HOME/lib와$ORACLE_HOME/srvm/lib이 라이브러리 패치에 포함되어야 한다(예를 들어, Solaris의 경우 LD_LIBRARY_PATH, HP-UX의 경우 SHLIB_PATH).

Opatch를 설치한 후 디렉토리 구조를 보면 다음과 같이 구성되어 있다.

패치 파일을 다운 받아 압축을 풀면, 해당 패치 번호의 이름으로 디렉 토리가 생성되며, 이 밑에 etc와 files 두 개의 디렉토리가 생성된다. Files 디렉토리 밑에는 lib 디렉토리가 있고, 이 디렉토리에 실제로 적용할 객체 파일들이 있다.
etc 디렉토리 밑에는 config와 xml 디렉토리가 생성된다. Config 디렉토리 밑에 있는 Actions 파일은 패치가 적용되어야 하는 대상 아카이브 파일과 디렉토리, 메이크 파일 등이 기록되어 있다. Inventory 파일에는 패치 적용 후 오라클 인벤토리에 업데이트해야 하는 내용과 대상 플랫폼, 오라클 버전이 기록되어 있다.
Xml 디렉토리에는 GenericAction.xml 파일이 있다. 이 파일에는 각 운영체제별로 사용할 명령어가 정의되어 있다. ShipHomeDirectoryStructure. xml 파일에는 패치 디렉토리의 구조가 정의되어 있다.

Opatch의 사용 방법

Opatch의 기능을 정리하면 다음과 같다.

● 임시 패치의 적용
● 적용한 임시 패치의 제거
● 설치한 컴포넌트와 패치(임시 패치 및 패치셋)에대한정보조회
● 임시 패치에 대한 정보 조회

그러면 이런 기능들을 어떻게 사용하는지 하나씩 알아보자.

Usage : opatch [ -h[elp] ] [ -r[eport] ] [ command ] [ command argument ]
Global argument
-h[elp] : 특정 명령어에 대한 설명
예) opatch -h lsinventory
-r[report] : 실제 패치 적용 없이 처리과정을 화면 출력
패치 적용

패치 적용은 Apply 명령어를 사용한다. 기본적인 명령은 다음과 같다.

$ opatch apply [ -delay ] [ -force ]
[ -invPtrLoc ]
[ -jdk ] [ -jre ] [ -local ]
[ -minimize_downtime ] [ -no_bug_superset ]
[ -no_inventory ] [ -oh ]
[ -retry ] [ -silent ] [ -verbose ]
각각의명령어아규먼트(command argument)를설명하면, 다음과같다.

● force : 이전에 설치한 임시 패치와 충돌 발생시 이를 무시하고 설치하도록 한 다. 이 경우 기존의 객체 파일을 새로운 객체 파일로 대체하게 되므로 주의하여 야한다.

● invPtrLoc : oraInst.loc 파일의 위치를 수동으로 지정할 때 사용한다. 오라클 제품 설치시 별도의 옵션을 주지 않으면 oraInst.loc 파일은 각 플랫폼의 디폴 트 위치에 생성된다. 이 위치를 사용자가 변경하기 위해‘runInstaller - invPtrLoc <경로 및 파일명>’처럼 사용할 수 있다. Opatch에 oraInst.loc 파 일의 위치를 알려주기 위해 이 아규먼트를 사용해야 한다.

● jdk : 디폴트로 사용되는$ORACLE_HOME/jdk 이외의 jdk를 이용하여 패치 할 때 이 아규먼트를 사용한다.

● jre : 디폴트로 사용되는 $ORACLE_HOME/jre 이외의 jre를 이용하여 패치 할 때 이 아규먼트를 사용한다.

● local : RAC에서 사용할 수 있으며, 패치 적용을 다른 노드에 전파하지 않고 로컬 노드에만 적용한 후 인벤토리도 로컬 노드에서만 업데이트한다. 이 경우 다른 노드에서도 개별적으로 로컬 아규먼트를 이용하여 즉시 패치가 적용되어 야한다. 일부 노드만 패치를 적용해 운영하는 것은 허용되지 않는다.

● minimize_downtime : 임시 패치 적용중 RAC의 다운타임을 최소화하기 위해 사용할 수 있다.

● no_bug_superset : 설치하려는 패치가 이미 설치한 패치의 슈퍼셋인 경우 에러를 발생시킨다.

● no_inventory : 패치 적용 과정 중에서 인벤토리를 읽거나 업데이트하는 과 정을 생략한다. 이 명령어 아규먼트는 인벤토리 변조 등으로 인해 정상적으로 인벤토리를 읽거나 업데이트할 수 없을 때만 사용해야 하며, 일단 사용 후에는 미지원 상태가 되므로 사용에 주의해야 한다. 그리고 위에서 설명한 로컬 명령 어 아규먼트는와는 같이 사용할 수 없다

● oh : 정의된$ORACLE_HOME 대신에사용할ORACLE_HOME을지정한다.

● silent : 사용자 인터랙션을 모두 디폴트 값으로 적용하여 패치를 진행한다.

● verbose : 기본적으로 나타나는 정보보다 더 자세한 내용을 화면과 로그 파일 에 출력한다.

● Patch_location : 설치하려는 임시 패치의 모든 경로를 표시한다.

그러면, 패치 적용의 사용 예를 간단히 알아보자.

$ opatch apply

단순히 이 명령으로 패치를 적용할 수 있다.

$ opatch apply -invPtrLoc $ORACLE_HOME/oraInst.loc -silent

이 명령으로 oraInst.loc 파일의 위치를 알려주고, 모든 사용자 인터랙 션은 디폴트 값으로 설정한 후 패치를 적용할 수 있다.

패치 제거

패치 제거를 위해서는 Rollback 명령어를 사용한다.

$ opatch rollback -id [ -invPtrLoc ]
[ -jdk ] -jre -local
[ -oh [ -ph ]
-silent -verbose
Rollback 명령어 아규먼트 중 Apply 명령어 아규먼트와 중복되지 않 는 아규먼트는 다음과 같다.

● id : 제거하려는 임시 패치 번호이다.
● ph : 패치 스테이지의 위치, 즉 패치를 제거할 때도 패치 파일이 필요하다.

간단한 패치 제거 사용 예는 다음과 같다.

$ opatch -id 380927 -ph /opt/oracle/920/380927

위의 명령으로 패치 번호 380927을 롤백하게 된다.

패치 정보 조회

패치 정보 조회를 위한 명령은 다음과 같다.

$ opatch query [ -all ] [ -get_base_bug ] [ -get_component ]
[ -get_date ] [ -get_os ] [ -get_system_change ]
[ -is_rolling ] [ -is_shutdown ]
패치의 조회는 Query 명령어를 사용하며, 다운 받은 임시 패치 자체 의 정보를 확인할 때 사용한다.
Query 명령어의 아규먼트는 다음과 같다.

● all : 모든 아규먼트로 조회되는 정보를 알려준다.
● get_base_bug : 해당 패치에 의해 수정된 베이스 버그를 알려준다.
● get_component : 패치 적용시 요구되는 컴포넌트를 알려준다.
● get_date : 패치가 생성된 일자를 알려준다.
● get_os : 패치 파일이 지원하는 운영체제를 알려준다.
● get_system_change : 해당 패치를 적용한 후 시스템에 변경되는 사항을 알 려주는 아규먼트이지만, 현재는 지원되지 않는다.
● is_rolling : 해당 패치가 롤링 패치가 가능한지 알려준다.
● is_shutdown : 해당 패치 적용시 인스턴스를 다운해야 하는지 여부를 알려주 지만, 현재는 지원되지 않는다.

설치된 패치 리스트 조회

ORACLE_HOME에 설치된 오라클 제품 컴포넌트를 조회하거나, 적용된 임 시 패치를 조회할 때는 lsinventory 명령어를 사용한다.

$ opatch lsinventory [ -all ] [ -detail ]
[ -invPtrLoc ]
[ -jre ] [ -oh ]
이 명령어의 아규먼트는 다음과 같다.

● all : ORACLE_BASE 밑에 설치된 모든ORACLE_HOME 정보를 표시한다.
● detail : 설치된 패치 내에 포함된 라이브러리 파일까지 표시해 주므로 패치 적 용시 충돌되는 객체 파일을 확인할 수 있다.

Opatch 버전 조회

Opatch의 버전을 조회하는 실제 예는 다음과 같다. 여기서 현재 사용한 Opatch는 1.0.0.0.50 버전임을 알 수 있다.

[rmtdcaix4]/apac/rdbms/3748283> ../OPatch/opatch version
PERL5LIB=/apac/rdbms/64bit/app/oracle/product/9.2.0.4/Apache/perl/lib/5.00503:../
OPatch/perl_modules; export PERL5LIB
/apac/rdbms/64bit/app/oracle/product/9.2.0.4/Apache/perl/bin/perl
../OPatch/opatch.pl version
../OPatch/opatch.pl version: 1.0.0.0.50

RAC에서의 Opatch 사용

기본적으로 임시 패치 적용시는 인스턴스를 다운한 후 적용해야 하므로, 패 치 적용시는 서비스를 할 수 없게 된다. RAC에서는 몇 가지 아규먼트를 사용 하여 다운타임을 최소화할 수 있다.
대략적으로RAC에서 패치가 적용되는 방법을 적어보면 다음과 같다.

If (사용자가 패치 적용방법을minimize_downtime으로 설정)
patching mechanism = Minimize Downtime
else if (패치가 롤링 패치를 지원)
patching mechanism = Rolling
else
patching mechanism = All-Node

여기서, 주의할 점은 CFS 등의 공유 파일 시스템에 오라클 제품을 설치 하여 여러 노드에서 공유하는 경우에는 minimize_downtime과 롤링 패치 가 적용되지 않는다는 것이다.
그러면 각각의 방법에 대해 알아보자.

All-Node

이것은 일반적인 데이타베이스에 패치를 적용하는 것처럼, 모든 인스턴스를 다운한 후, 한 노드씩 순차적으로 진행한다. ORACLE_HOME을 여러 노드 에서 공유하는 경우는 이 방식으로 패치를 적용해야 한다.

Minimize_downtime

Minimize_downtime은 RAC 운영시 다운타임을 최소화하기 위해 사용된 다. 2노드RAC의 경우를 예로 패치 절차를 알아보자.

1.먼저 로컬 노드의 인스턴스를 셧다운한다.
‘opatch apply -minimize_downtime’명령으로 패치를 시작한다.

2. ‘Is this node ready for updating?’질문에‘Yes’로 답하면, 로컬 노드에 패치가 적용된다.

3.패치 적용 후 다음에 적용할 노드명을 물어본다.

4.해당 노드명을 입력하면, 이 노드의 인스턴스를 셧다운하도록 요청한다.

5.요청받은 노드의 인스턴스는‘Shutdown immediate’로 셧다운한 후, 셧 다운이 완료되면 이미 패치가 적용된 노드의 인스턴스가 셧다운한다.

6.두 번째 노드에 패치를 적용한다.

7.인벤토리 정보가 업데이트된다.

8.패치가 완료되면 두 번째 인스턴스도 셧다운한다.

Minimize_downtime 아규먼트를 사용해도 모든 인스턴스가 다운되는 단계는 있지만, 5번 단계에서만 해당되므로, 다운타임을 최소화할 수 있다.

Rolling Patch

롤링 패치가 Minimize_downtime과 틀린 점은 다운타임이 전혀 없다는 것이다. 적용 절차는 다음과 같다.

1.먼저 인스턴스1을 셧다운한다. 이 단계에서 인스턴스2는 서비스 중이다.
2.노드1에서‘opatch apply’명령으로 패치를 적용한다.
3.노드1에 패치가 적용되었으면, 인스턴스1을 시동하라는 메시지를 받는다.
그리고 다음에 적용할 노드를 입력하도록 메시지를 받는다.
4.인스턴스2를 셧다운한다.
5.3번 세션에서 계속 이어서 노드2에 패치를 적용한다.
6.패치 적용후 인스턴스2를 시동한다.

롤링 패치는 모든 패치가 다 가능한 것은 아니고, 롤링 패치를 지원하도 록 설계된 패치만 가능하다. 롤링 패치가 가능한지 여부는‘opatch query - is_rolling’명령으로 확인할 수 있다.

Windows 플랫폼에서 Opatch 사용

Windows에서 Opatch를 사용할 때도 기본적인 명령어는 동일하다.
Opatch 명령을 실행하면 Windows 레지스트리에 ORACLE_HOME 이 등록되어 있어도, ORACLE_HOME이 지정되지 않았다는 메시지가 나 온다. Opatch 명령어를 사용할 때 -oh 아규먼트를 사용하여 ORACLE_HOME을 지정하거나, DOS 프롬프트에서 다음 명령으로 ORACLE_HOME을 지정한다.

C:\> Set ORACLE_HOME =

트러블슈팅

>임시 패치가 적용되었는지 어떻게 확인할 수 있는가?

일반적으로 패치가 적용되었는지를 보려면‘opatch lsinventory’를 사용하 여 확인한다.

Oracle Database 9.2 이 상 에 서 임 시 패 치 를 적 용 하 면 ,

$ORACLE_HOME/.patch_storage 디렉토리 밑에 해당 패치 번호를 이름 으로 디렉토리가 생성되고, 이 디렉토리 밑에 패치 적용 로그와 패치 적용 이전의 라이브러리 파일, 롤백시 적용할 스크립트가 있다. 여기서 로그 파 일을 보는 것도 패치가 적용되었는지 확인하는 방법이 될 수 있다. 이 로그 파일은 패치 적용을 실행하는 횟수만큼 생성된다.
또 한 가지 방법은 아카이브 파일을 Ar 명령으로 조회해 보는 것이다.
예를 들어, kko.o 파일을 libserver9.a에 적용하는 경우, ‘ar tv libserver 9.a|grep kko.o’명령으로 kko.o의 타임스탬프를 조회할 수 있다.

Windows에서 Opatch 실패

Windows 플랫폼에서Opatch를실행하면다음메시지가나오는경우가있다.

C:\oracle\ora92\OPatch>opatch lsinventory
“You have to invoke the patch tool manually.”
“The syntax is:”
“ perl /opatch.pl ”
“If everything is installed correctly you should be able to run”
“ perl /opatch.pl”
“ and see the basic help message.”
C:\oracle\ora92\OPatch>perl opatch.pl lsinventory
<< 중략 >> Required Jar File under Oracle Universal Installer = jlib\OraInstaller.jar
‘“”C:\Program’은(는) 내부 또는 외부 명령, 실행할 수 있는 프로그램, 또는
배치 파일이 아닙니다.
Get inventory loc. from C:Program Files...
<< 생략 >>

Opatch 사용시 권장되는 Perl 버전은 5.6 이상이지만, 이상하게도 Windows에서 Perl 5.6 이상을 사용하여 Opatch를 실행하면 위와 같은 에러 메시지가 발생한다. 이 경우 $ORACLE_HOME/Apache /perl을 사 용하도록 한다.

컴포넌트/버전의 불일치

This Oracle Home does not have components/versions required by the patch.
ERROR: OPatch failed during pre-reqs check.

위와 같은 메시지는 적용하려는 임시 패치가 요구하는 컴포넌트가 설치되 지 않았거나, 지원하는 버전이 틀린 경우이다.
패치 파일의 요구사항은‘opatch-query’명령으로 조회해 볼 수 있다.
혹은 patch stage/etc/config/inventory 파일을 열고, 항목을 확인해도 된다.

유효한 패치 영역이 아닌 경우

Not a valid patch area

이 경우는 현재의 작업 디렉토리가 패치 디렉토리가 아니거나 패치 디렉토 리명이 패치 ID와 같지 않아서 발생하는 문제이다.
패치 디렉토리가 현재 디렉토리가 아닌 경우는 경로를 명시해 주어야 한다. 예를 들어서, 현재 디렉토리는‘/oracle’이고, 패치는‘/oracle/3809254’에 있는 경우, ‘opatch apply /oracle/3809254’라고 명령을 내려야 한다.
패치 디렉토리가 패치 ID와 이름이 다른 경우는 먼저 패치 ID를 확인 한다. 이 정보는‘opatch query -all’로 확인하거나‘patch stage/etc /config/inventory’파일에서 reference_id 항목에서 확인할 수 있다. 이 후 디렉토리명을 패치 번호와 동일하게 맞춰 준다.

java.lang.UnsatisfiedLinkError

Exception in thread “main”java.lang.UnsatisfiedLinkError:
no oraInstaller in java.library.path

이 경우 원인은 대부분 liboraInstaller.so가 라이브러리 경로에 포함 되지 않았기 때문이다.
이 파일은 $ORACLE_HOME/oui/bin/ 디렉토리에 있 다. 이 경로를 라이브러리 경로에 추가하고, 다시 패치를 적용한다.

java.lang.NullPointerException

Exception in thread “main”java.lang.NullPointerException at XXX.main...

오라클 제품의 최초 설치시 RunInstaller를 -invPtrLoc 옵션을 사용해서 실행한 경우일 수 있다. 이 경우 Opatch를 사용할 때도 동일한 -invPtrLoc 를 사용하여 oraInst.loc의 위치를 명시해 주어야 한다.

Oracle Support에 문의해야 하는 경우

모든 문제가 그렇지만, Opatch 실행시 발생하는 문제도 거의 유형별로 다 르기 때문에, 위와 같이 일반화 하는 것이 힘들다. 따라서 일단 문제가 발생 하면, 다음과 같이 기본적인 점검을 하고, 다음 사항을 검토한다.

● Opatch가 최신 버전인지 확인
● Opatch를 실행하기 위한 환경이 셋업되었는지 확인
PERL, JDK, 환경변수(PATH, LIBRARY PATH, …)
● Fresh Install인지 확인
● HP에서 fuser 문제인 경우 NOTE. 234741.1를확인

더 이상 확인이 안될 경우는 Oracle Metalink(http://www. metalink. com)에서TAR를연후Oracle Support 엔지니어와 같이 문제를 해결해야 한다. 이 경우 다음 정보들을 미리 준비하여 Oracle Support에 전달하면 문제 해결에 도움이 될 수 있다.

● 운영체제 디버깅 아웃풋
예 : truss -aefdD -o test.out opatch apply
● oraInst.loc 파일
● $ORACLE_HOME/inventory/ContentsXML/comps.xml
● $ORACLE_HOME/.patch_storage 디렉토리를 압축
● oraInst.loc에 기록된 인벤토리 디렉토리 밑의 ContentsXML/inventory 파일
● 운영체제 환경변수‘OPATCH_DEBUG=TRUE’를 세팅한 후 Opatch 적용시의 아웃풋
● 문제가 발생하고 있는 임시 패치 번호

오라클 관리자의 필수 유틸리티

Oracle Database 9.2부터 지원되는 Opatch는 임시 패치 관리에 있어서 많은 편리한 기능을 제공한다. 애플리케이션 서버도 Oracle Application Server 10g부터는 Opatch로 임시 패치를 관리하게 되므로, 오라클 관리 자에게 Opatch는 필수 유틸리티라고 할 수 있다.
마지막으로 당부하고 싶은 것은 임시 패치 적용 전 반드시 센트럴 인 벤토리와 로컬 인벤토리를 백업하여 예기치 못한 인벤토리 충돌시 복구가 가능하도록 하기 바란다.

제공 : DB포탈사이트 DBguide.net

출처명 : 한국오라클

[출처] 오라클 OPatch 사용법|작성자 sulgata

'Oracle > Oracle Scrap' 카테고리의 다른 글

[스크랩] CHECKPOINT NOT COMPLETE에 대해서 (0)	2011.11.23
[스크랩] 대기 이벤트 (0)	2011.04.14
[스크랩] Patch Set, CPU, PSU 차이점 분석 (0)	2011.03.03
[스크랩]ORA-12801 (0)	2011.01.26
[스크랩] 테이블 스페이스, 데이타 파일, 익스텐트 , 프리스페이스 관리하기 (0)	2010.11.30

작성자 : 박상수
작성일자 : 2010.12.18
작업환경 : VMware7 [ RHEL4 + Oracle 10g R2 ]
참고자료 : 서진수 샘

스크랩URL : http://calmmass.tistory.com/275

1. Patsh Set

오라클에서 패치 샛은 릴리즈 버전의 통합 패치파일로 생각 하시면 됩니다.
만약 10.2.0.1 버전을 Patch Set을 설치할 경우 10.2.0.4 로 변경 되며 각종 실행파일이 모두 10.2.0.4로 변경 됩니다.

결국 Patsh Set는 릴리즈 버전의 업데이트 패치 파일이라고 생각 하시면 보다 쉽게 이해하실 수 있습니다.
oracle 버전별 Patch Set 리스트는 여기에서 확인 하시기 바랍니다.

2. PSU(Patch Set Update)

PSU(Patch Set Update)는 오라클에서 정기적으로 권고하는 패치로써 중요한 단일 패치들을 통합한 것을 의미합니다.
PSU 출시 일정은 분기별로 제공 하며 일정은 다음과 같습니다.
1월, 4월, 7월, 10월 중순의 화요일 제공됩니다.

PSU 패치는 다음과 같은 내용을 포합합니다.
- 실제 운영환경에서 이미 검증
- CPU 패치

PSU 패치는 다음과 같은 내용을 포함하지 않습니다.
- 새로운 인증이 필요한 패치(optimizer plan 이 변경가능한 패치)
- Database 구성의 변경이 필요한 패치

PSU 패치는 10.2.0.2.1~4 까지 가능합니다.(분기별 4번)

3. CPU(Critical Patch Update)

CPU(Critical Patch Update)는 오라클 제품의 보안 문제 해결을 위한 패치입니다.

CPU 출시 일정은 분기별로 제공 하며 일정은 다음과 같습니다.
1월, 4월, 7월, 10월 중순의 화요일 제공됩니다.

CPU 패치는 10.2.0.2.1~4 까지 가능합니다.(분기별 4번)

'Oracle > Oracle Scrap' 카테고리의 다른 글

[스크랩] 대기 이벤트 (0)	2011.04.14
[스크랩] OPatch (0)	2011.03.11
[스크랩]ORA-12801 (0)	2011.01.26
[스크랩] 테이블 스페이스, 데이타 파일, 익스텐트 , 프리스페이스 관리하기 (0)	2010.11.30
[스크랩] ORA-1652 조치 방법 (0)	2010.09.07

http://blog.naver.com/bueun?Redirect=Log&logNo=60062866661

작업을 하면서 이상한 오류가 발생했다.

parallel ......어쩌구 저쩌구....

select * from TCSQCSM

ORA-12801: error signaled in parallel query server P004, instance testdb01:BKTDB

ORA-01157: cannot identify/lock data file 67 - see DBWR trace file

ORA-01110: data file 67: '/dev/rlv006_p023_02'

그래서 알아보다가 테이블이 parallel로 구성되어 있는것을 알았다.

TABLESPACE D01B623

PCTUSED 0

PCTFREE 10

INITRANS 1

MAXTRANS 255

STORAGE (

INITIAL 1M

NEXT 1M

MINEXTENTS 1

MAXEXTENTS 2147483645

PCTINCREASE 0

BUFFER_POOL DEFAULT

)

LOGGING

NOCACHE

PARALLEL ( DEGREE 4 INSTANCES 1 );

일반적으로 NOPARALLEL로 설정하는데....

select table_name, degree

from user_tables

where tablespace_name = 'D01B623'

이렇게 하면 해당 tablespace에 소속된 테이블목록을 볼수 있다.

select 'alter table '||table_name||' parallel 1;'

from user_tables

where degree > 1 ;

alter table TCSQCSM parallel 1 ;

을 사용하면 바꿀수 있다.

parallel의 기능에 대해서 bug가 있다고 하던데..........................................................

그리고 오라클 bug보면 parallel 프로세스끼리 통신을 해야하는데 중간에 어떠한 이유(??)로 인해서 통신을 못하는 경우가 발생한다구 하더라구요.

그러면 parallel query의 실행이 종료되구 에러가 난다구 합니다.

가끔 그러나 봐요... 아주가끔..

시스템 사용율이 높거나 OLTP상황에서는 별루 권장하지 않습니다.

보통땐 1개의 프로세스가 생성되는데 parallel은 degree에 따라서 아무리 간단한 SQL이라도 프로세스를 degree만큼 생성하거든요.

테이블 단위로 parallel은 잘 설정하지 않는게 일반적인데.. 테이블이 어떤 SQL에 포함될지 다 추적할 수 없잖아요.. 그래서 sql에 힌트로 넣는다.

통계생성이나 batch작업시 효과를 많이 볼수 있다.

---퍼왔어요 http://blog.empas.com/matata/4624016

'Oracle > Oracle Scrap' 카테고리의 다른 글

[스크랩] OPatch (0)	2011.03.11
[스크랩] Patch Set, CPU, PSU 차이점 분석 (0)	2011.03.03
[스크랩] 테이블 스페이스, 데이타 파일, 익스텐트 , 프리스페이스 관리하기 (0)	2010.11.30
[스크랩] ORA-1652 조치 방법 (0)	2010.09.07
[스크랩] RAC (0)	2010.05.18

출처 : http://database.sarang.net/ioseph/board/index.php?work=view&criteria=oracle&subcrit=qna&curpg=0&aid=7906
============================================

굳이 대용량이 아니라고 해도, 현재 사용한 용량을 알고 있어야 디스크를 사서 늘려도 늘릴것이고, 언제쯤 사야하겠다는 예상을 할수 있을텐데 그런 것을 위해 있는 것이 ORACLE의 DBA_FREE_SPACE 뷰이다. 그러나 DBA_FREE_SPACE에는 분명 공간이 있는데 ORACLE이 에러를 내는 경우는 많다. 가끔은 10GB TABLESPACE를 잡아놓고 쓴것은 1GB도 되지 않는데 에러를 내기도 한다. 왜 이런 현상이 생기며, 어떻게 관리해야 하는지 알아보자.

tablespace, datafile, extent에 대한 개념은 설명하지 않는다.

select * from dba_freespace where tablespace_name=\'TEST2\';

현재 Tablespace의 여유 공간은 dba_free_space 뷰를 보면 알수 있다.

[pre]
TABLESPACE_NAME FILE_ID BLOCK_ID BYTES BLOCKS RELATIVE_F
------------------------------ ---------- ---------- ---------- ---------- ----------
TEST2 19 52 40960 20 19
TEST2 19 72 40960 20 19
TEST2 19 92 40960 20 19
TEST2 19 112 40960 20 19
TEST2 19 132 40960 20 19
TEST2 19 152 40960 20 19
TEST2 19 172 40960 20 19
TEST2 19 192 40960 20 19
TEST2 19 212 40960 20 19
TEST2 19 232 40960 20 19
TEST2 19 252 40960 20 19
TEST2 19 272 40960 20 19
TEST2 19 292 40960 20 19
TEST2 19 312 40960 20 19
TEST2 19 332 40960 20 19
TEST2 19 352 40960 20 19
TEST2 19 372 40960 20 19
TEST2 19 392 40960 20 19
TEST2 19 412 40960 20 19
TEST2 19 432 40960 20 19
TEST2 19 452 40960 20 19
TEST2 19 472 40960 20 19
TEST2 19 492 43008 21 19
[/pre]
위의 결과에서 보면 이상한 점이 있다. 왜 여러개로 나눠져 있는거고 각 컬럼이 의미하는 것은 뭘까?

우선 행이 나눠져 있는 이유는 할당되었다가 반납된 익스텐트들은 pctincrease가 0일 경우는 자동으로 합쳐지지않는다. 각각은 할당되었다가 반납되어 빈공간(free space)로 잡혀있는 것이다. 첫번째 줄을 보면 52번 블록부터 20개의 블록이 비어있고 두번째 줄을 보면 72번부터 20개의 블록이 비어있다는 것을 알수 있다. 어라! 그럼 52번부터 40개의 블록이 비어있는 것이 아닌가?

이런식으로 보다보니 52~ 513블록이 모두 빈공간이다. 그럼 하나로 합칠수도 있지 않나?

alter tablespace test2 COALESCE; --Dictionary Management tablespace 때 만 필요한 작업이다.

select * from dba_free_space where tablespace_name=\'TEST2\';

TABLESPACE_NAME FILE_ID BLOCK_ID BYTES BLOCKS RELATIVE_F
------------------------------ ---------- ---------- ---------- ---------- ----------
TEST2 19 52 944128 461 1

합쳐졌다는 것을 알수 있다.

그럼 쓰고 있는 공간은 어떻게 알수 있나? DBA_EXTENTS뷰를 보면 알수 있다. 오라클은 extent 단위로 관리하기 때문에 USED_SPACE가 아니라 EXTENTS이다.

select (생략) from dba_extents where tablespace_name=\'TEST2\';

OWNER SEGMENT_NAME EXTENT_ID FILE_ID BLOCK_ID BYTES BLOCKS RELATIVE_F
------ ------------- --------- ---------- ---------- ---------- ---------- ----------
SYS TEST_TABLE1 0 19 2 102400 50 19
위의 결과를 보니 0번 익스텐트이고 2번블록부터 50개의 블록을 쓰고있다. 따라서 102400바이트를 사용하고 있다. 0번 익스텐트이니까 테이블 스페이스를 만들때 storage 옵션에서 initial값을 1M로 준것이 틀림없다.

select * from dba_tablespaces where tablespace_name=\'TEST2\';

TABLESPACE_NAME INITIAL_EX NEXT_EXTEN MIN_EXTENT MAX_EXTENT PCT_INCREA MIN_EXTLEN
---------------- ----------- ---------- ---------- ---------- ---------- ----------
TEST2 102400 40960 1 121 0 0

역시 그렇다. next가 40960으로 되어있는 것도 dba_free_space뷰를 통해 조각나 남아있던 공간들의 크기와 똑같다.

그럼 전체 tablespace의 크기는 사용한 것 102400 + 944128 = 1046528 이라는 계산이 나온다. 실제로는 0번 익스텐트가 2번 블록부터 시작하므로 파일크기는 1046528+2048=1048576이 나올것이다.

select * from dba_data_files where tablespace_name=\'TEST2\';

FILE_NAME FILE_ID TABLESPACE_NAME BYTES BLOCKS
/db2/oradata/test02.dbf 19 TEST2 1048576 512
그런것을 확인할수 있다.

따라서 dba_free_space뷰를 보고 여유공간이 별로 없다면 곧 데이타 파일을 늘리거나 resize를 하는 방법으로 테이블 스페이스를 늘려야 한다는 사실을 알수 있다.

그러나 여기서는 테이블 스페이스의 NEXT_EXTENT값이 40k 정도로 작기 때문에 상관이 없지만, 좀 크다는 DB의 NEXT값이 20M라고 했을때, DBA_FREE_SPACE에 39M가 남아있다면 결과적으로는 20M만 남은것과 다르지 않다는 것 에 유의해야 한다.

그보다 더 중요한 것은 PCT_INCREASE 값인데, 0이 아닌값이 설정되어 있으면, 각 익스텐트의 크기가 각각 다르다. 이경우 반납되었다가 다시 할당될때 정확하게 맞아떨어지지 않는다. 다시말해 단편화가 생긴다는 이야기인데, 파일시스템의 단편화는 단지 읽고쓰는 퍼포먼스의 문제이지만, 오라클에서도 같은 결과를 낸다.

그리고 어떤 경우의 위의 경우에 전혀 해당하는 경우가 없고 free_space가 엄청나게 남아있는데도 문제가 생길수 있는 경우가 있다. 바로 MAX extent 값때문인데, 각종 문의 게시판등을 보면 이 문제때문에 엄청나게 고생한다는 사실을 알수있다. 위의 예에서 MAX_EXTENT값은 121이다. 각 익스텐트의 크기는 40K이므로 4,840K의 공간을 사용할수 있다. 그런데 만약 data파일이 4,840k보다 크다면?
그 이후공간은 전혀 사용할수가 없다.
이 것이 문제가 많이 되는 것은 FREE_SPACE를 보니 전체파일크기에 비해 사용된 량이 별로 되지도 않는데 에러를 낸다는 것이다. 예를 들어 100M가 분명 넘을리 없는 테이블을 위해 테이블 스페이스를 만들었는데 next값이 작아서 채 10M가 되지도 못했는데 에러는 낼수 있다는 것이다.

------------------------------------------------------------------------------------------------

[나의 테스트]

select tablespce_name t_name, file_id, block_id, bytes

from dba_free_space

where tablespace_name = 'USERS'

order by block_id;

T_NAME FILE_ID BLOCK_ID BYTES

USERS 4 209 65536 8

USERS 4 433 65536 8

USERS 4 441 65536 8

USERS 4 449 65536 8

USERS 4 31177 524288 64

USERS 4 42377 9371648 1144

--tablespace의 여유공간 확인.

select sum(bytes) tot_free_space

from dba_free_space

where tablespace_name = 'USERS'

order by block_id;

TOT_FREE_SPACE

10158080

--사용된 tablespace 공간

select segment_name s_name, tablespace_name t_name, extent_id, file_id, block_id, bytes, blocks

from dba_extents where tablespace_name = 'USERS';

S_NAME T_NAME EXTENT_ID FILE_ID BLOCK_ID BYTES BLOCKS

REGIONS USERS 0 4 9 65536 8

select sum(bytes) tot_used_space

from dba_extents

where tablespace_name = 'USERS';

TOT_USED_SPACE

346292224

select * from dba_tablespaces where tablespace_name = 'USERS';

select 346292224+10158080+(8*8*1024) from dual; --356515840

--initial 값을 8M를 주었고 8개블록을 추가해주어야하기 때문에 추가로 더해주어야한다.

select tablespace_name, bytes from dba_data_files where tablespace_name = 'USERS';

TABLESPACE_NAME BYTES

USERS 356515840

'Oracle > Oracle Scrap' 카테고리의 다른 글

[스크랩] Patch Set, CPU, PSU 차이점 분석 (0)	2011.03.03
[스크랩]ORA-12801 (0)	2011.01.26
[스크랩] ORA-1652 조치 방법 (0)	2010.09.07
[스크랩] RAC (0)	2010.05.18
WARNING: inbound connection timed out (ORA-3136) (0)	2010.03.02

제품 : ORACLE SERVER <- 참조하세요. 좋은 정보 또 하나 배웠습니다.

작성날짜 : 1995-11-05

ORA-1652 조치 방법
==================

테이블이나 인덱스 등을 만들 때 자신의 TEMP TABLESPACE가 아닌 곳에서
ORA-1652(temp tablespace가 부족함) 에러가 발생하는 경우가 있다.

V7.1 에서는 테이블, 인덱스 등을 병렬로 생성할 수 있다. 이를 위하여 실제로
테이블 등이 생성될 공간에 Temporary Segment를 만들게 되는데 이 과정에서
Temporary Segment를 만들 공간이 부족하게 되면 실제의 테이블이 생성되는
테이블스페이스에 대하여 ORA-1652 에러가 발생하게 되는 것이다.

ORA-1652 에러를 해결하는 방법은 에러 메시지에서 보여주는 대로 해당 테이블
스페이스에 Temporary Segment가 생성될 만한 연속된 공간을 마련하여 주는 것이다.

다음과 같은 절차로 해결하여 본다.

1. 데이타화일을 추가하여 테이블스페이스의 크기를 확장한다.
SQL> ALTER TABLESPACE data ADD DATAFILE
'/usr/../oracle/data2.dbf' SIZE 100M;

2. 테이블의 storage parameter를 조정하여 현재 남아 있는 영역에 들어갈 수
있도록 한다.

SQL> ALTER TABLE emp STORAGE(NEXT 1M);

3. 테이블스페이스가 fragmentation이 심한 상태이면 export/import를 이용하여
테이블스페이스를 재구성한다.

[예제] 다음의 테이블 생성 문장을 보자.
SQL> CREATE TABLE FEATURE
(feature_code varchar2(4) primary key,
feature_desc varchar2(3) );

ORA-01652, 00000, "unable to extend temp segment by 6144 in
tablespace VESSEL"

테이블스페이스 VESSEL 에 남아 있는 가장 큰 연속된 공간을 확인해 보면

SQL>SELECT MAX(blocks), MAX(bytes)
FROM DBA_FREE_SPACE
WHERE TABLESPACE_NAME = 'VESSEL';

blocks bytes

6143 12,580,864

위의 결과를 보면 현재 VESSEL에 남아 있는 가장 큰 연속된 공간은 6143 블럭인데
오라클은 6144 블럭을 사용하려고 시도하다 이를 할당받지 못하여 이 에러가 발생
하게 된 것이다.

'Oracle > Oracle Scrap' 카테고리의 다른 글

[스크랩]ORA-12801 (0)	2011.01.26
[스크랩] 테이블 스페이스, 데이타 파일, 익스텐트 , 프리스페이스 관리하기 (0)	2010.11.30
[스크랩] RAC (0)	2010.05.18
WARNING: inbound connection timed out (ORA-3136) (0)	2010.03.02
WARNING: inbound connection timed out (ORA-3136) 에 관해 (0)	2010.03.02

[스크랩 URL] http://blog.naver.com/kiyoun82/110071439206

1. RAC [Real Application Cluster]

1) Application : 클라이언트, 리스너 같은 데이터 베이스로 부터 서비스를 받는 모든 것들.

2) Cluster : 군집, 집합 : 하나의 데이터 베이스에 여러개의 인스턴스를 띄어 놓아 만들어진 상태

- 싱글 DB

- RAC

- 인스턴스는 각 머신에 있다.

- 1번 인스턴스에서 작업을 하다 인스턴스가 죽었을 경우(Fail over)

- 2번 인스턴스로 투명하게 넘어가서 쓰게 된다. (가용성)

2. RAC 를 쓰는 이유?

1) 가용성

2) 로드 발란스

* RAC 구조

- Interconnect : DATAFILE로 내려가지 않고 메모리 to 메모리로 전송이 가능하게 해준다.

(Cache Fusion)(OPS 보다 당연히 빠르다.)

- Ethernet + UDP : 가장 보편적으로 사용

- 1Gbit Ethernet : 현재 보편적으로 사용 (초당 125M정도)

- 10Gbit Ethernet : 향후..

- Infiniband : 향후 (초당 2Gbit ~ 96Gbit 까지 적용) 전송량이 많을 때 부하가 생긴다.

- OPS : 메모리에서 다른 메모리로 읽어질 때 중간에 디스크로 내려썼다가 올라온다.

- 한쪽 클라이언트에서 다른 쪽 클라이언트까지 같이 설치해 주어야 한다.

- Shared Storage

- Raw Device - 가장 보편적으로 사용 / 쓰기 속도가 좋다 / 관리가 불편

- Clustered File System : 비싸다. 잘 깨진다는 문제가 있다.

- ASM : 점점 기능이 좋아지고 있다(11g에서 활용성 높음)

3. 클러스터

1) OS 클러스터

2)ORACLE 클러스터

4. 10g RAC 설치 순서

1) 오라클 클러스터를 먼저 설치

2) 오라클 소프트웨어 설치

3) 오라클 ASM 설치 (10g) [OS 클러스터를 안쓸 경우 ASM 을 무조건 설치해 주어야 한다.]

4) 오라클 DB 설치

5. RAW Device => OS 클러스터를 설치 해 주어야 한다.

$ CRS_STAT -t : [Target 컬럼] online 되어져 있어야 다른 쪽 노드로 넘어갈 수 있다.

: [State] 현재 상태

$ CRS_STOP -all : RAC 서비스가 멈춰 있을 경우에는 stat를 먼저 확인해 본 후 offline 되었을 경우.

$ CRS_START -all : 서비스를 내렸다가(STOP) 다시 올려준다.(START)

1) GCS : Global Cache Service

- 노드간의 DATA, 메세지 전송을 관리하는 서비스

- LMS Process : Global Cache 동기화, 최대20개까지(10gR1), 최대 36개까지(10gR2)

2) GES : Global Enqueue Service

- Global 하게 Lock을 관리

- 노드간의 Lock 정보를 요청하고 응답하는 것을 관리하는 서비스

- LMD Process : Global enqueue 동기화(Lock)

- LCK Process : Library Cache Lock / Pin, Row Cache Lock 동기화

3) CGS : Cluster Group Service

- 클러스터의 멤버쉽을 관리하는 서비스

- LMON Process : Global Lock Monitoring Process Recover 등의 작업 수행

4) GRD : Global Resource Directory

- Global Resource 의 위치 및 상태를 관리하는 분산 DATABASE

- 모든 BLOCK의 정보는 BLOCK이 속한 MASTER NODE를 GRD 에서 관리

- BLOCK에 최신 정보가 있다.

- GRD가 관리하는 정보

: DBA(Data Block Address) + Location Holder 위치(holding 하고 있는 위치, ex. emp가 1번에 있니?2번에 있니? 없니??)

+ LOCK MODE(Null, Shared, Exclusive) + Role(Local, Global) + SCN + PI(Past Image)

6. show parameter service

하나의 노드가 깨졌을때 OCR 의 정보를 보고 복구를 한다.

RAC는 datafile, controlfile, redologfile 이외에 Voting Disk 와 OCR 이 필요함.

1) OCR : 클러스터 구성에 필요한 메타 정보를 가지고 있다.

작업 중이던 노드가 죽으면 다른 노드에 넘겨야 한다는 정보가 들어있다.)

2) Voting Disk : Split Brain 현상을 방지하기 위한 파일

※ Split Brain : 의학 용어로 좌뇌와 우뇌의 Sync가 맞지 않은 경우, 동기화가 이루어져 있지 않은 경우를 말함

일관된 이미지를 보기 위한 것

양 쪽의 노드가 동기화, 맞춰주는 것

7. 논리적/물리적으로 백업을 반드시 해야함.

8. OCR은 자동백업

9. Cache Fusion

1) interconnect 를 통한 효율적인 글로벌 버퍼 동기화 메커니즘

2) Memory to Memory 동기화.

-> Request Node, Master Node, Holder Node 가 Interconnect 를 통해 Block/Message 를 교환하는 Mechanism

1) Request Node : 필요한 특정 블록을 Master Node 의 LMSn에 요청

2) Master Node : 요청받은 블록(버퍼)의 홀더 노드를 파악한 후 LMSn 에게 요청 노드로의 버퍼 전송을 요청

만일 없을 시에는 Block grant message 전달(직접 디스크에서 읽어들이도록 권한 부여)

3) Holder Node : 블럭(버퍼)전송이 가능한 경우, 요청 노드로 버퍼를 전송한다.

※ 노드가 2개 일 경우.

1. A user 가 EMP를 읽으려면 1번 instance GRD를 확인, 없으면 2번 GRD 확인, 없으면 디스크에서 올린다.

2. 이 때 B user 가 EMP를 읽으려고 2번 instance 에서 접근시 LMSn 이 interconnect로 emp를 넘겨준다.

3. 이 경우 둘 다 Shared mode 의 Lock을 갖는다.

4. B user 가 scott의 SAL 을 UPDATE하고 COMMIT 하였을 경우,

-> B user가 갖고 있떤 Shared mode Lock은 Exclusive 하게 바뀐다.

5. A user 가 가지고 있던 Shared Mode Lock은 Null Mode로 바뀐다.

6. A user 가 다음 EMP를 보고자 할 경우에는 UPDATE 된것을 보아야 한다.(commit 했으니깐..)

(Null Mode는 다른 노드에서 받아와야 한다는 의미를 내포한다.)

'Oracle > Oracle Scrap' 카테고리의 다른 글

[스크랩] 테이블 스페이스, 데이타 파일, 익스텐트 , 프리스페이스 관리하기 (0)	2010.11.30
[스크랩] ORA-1652 조치 방법 (0)	2010.09.07
WARNING: inbound connection timed out (ORA-3136) (0)	2010.03.02
WARNING: inbound connection timed out (ORA-3136) 에 관해 (0)	2010.03.02
GRID & RAC 개념 (0)	2010.02.23

http://iotn.co.kr/power/zboard.php?id=9_1_bbs&no=939

최길호

2008-07-04 14:58:56, 조회 : 2,514

출처: http://forums.oracle.com/forums/thread.jspa?messageID=1612957&tstart=0

"WARNING: inbound connection timed out (ORA-3136)"은 client에서 Oracle에 접속시
SQLNET.INBOUND_CONNECT_TIMEOUT에 기술된 시간에 인증을 받을수 없는 경우에 발생 합니다.

SQLNET.INBOUND_CONNECT_TIMEOUT은 기본적인 값이 60 SEC 이며 정의된 시간에 인증이 않되면
alert log file에 "WARNING: inbound connection timed out (ORA-3136)"를 발생 합니다.

AIX Oracle 10.2.0.2

alert.log
=================================================
WARNING: inbound connection timed out (ORA-3136)

조치
=================================================
$ORACLE_HOME/network/admin/sqlnet.ora
SQLNET.INBOUND_CONNECT_TIMEOUT=0

or

lsnrctl
===================================================================================
LSNRCTL> show inbound_connect_timeout
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=Linux4U2_DB)(PORT=1521)))
LISTENER parameter "inbound_connect_timeout" set to 60 <<<< 60 sec
The command completed successfully

LSNRCTL> set inbound_connect_timeout 0
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=Linux4U2_DB)(PORT=1521)))
LISTENER parameter "inbound_connect_timeout" set to 0 <<<< Change Value
The command completed successfully

test
===================================================================================
Linux env not exist sqlnet.ora file
[Linux4U2_DB :/home/gh]$ ls $ORACLE_HOME/network/admin/sqlnet.ora
ls: /oracle/product/10.2/network/admin/sqlnet.ora: No such file or directory

LSNRCTL> show inbound_connect_timeout
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=Linux4U2_DB)(PORT=1521)))
LISTENER parameter "inbound_connect_timeout" set to 0
The command completed successfully

LSNRCTL> set inbound_connect_timeout 60
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=Linux4U2_DB)(PORT=1521)))
LISTENER parameter "inbound_connect_timeout" set to 60
The command completed successfully

LSNRCTL> stop
LSNRCTL> start
LSNRCTL> show inbound_connect_timeout
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=Linux4U2_DB)(PORT=1521)))
LISTENER parameter "inbound_connect_timeout" set to 0
The command completed successfully

inbound_connect_timeout = 0 [ default ]

최길호

oracle 10.2

LISTENER parameter "inbound_connect_timeout" set to 10
telnet loclhost 1521
[10초 경과]
Connection closed by foreign host.

listener.log
=======================================================================
TNS-12525: TNS:listener has not received client's request in time allowed
TNS-12535: TNS:operation timed out
TNS-12606: TNS: Application timeout occurred

'Oracle > Oracle Scrap' 카테고리의 다른 글

[스크랩] ORA-1652 조치 방법 (0)	2010.09.07
[스크랩] RAC (0)	2010.05.18
WARNING: inbound connection timed out (ORA-3136) 에 관해 (0)	2010.03.02
GRID & RAC 개념 (0)	2010.02.23
(Oracle 10g) MMAN 백그라운드 프로세스를 통한 자동 공유 메모리 관리 (0)	2010.02.17

WARNING: inbound connection timed out (ORA-3136) 에 관해

2010. 3. 2. 17:07

PRODBA 카페의 [용돌이]님이 작성하신 글입니다.

http://cafe.naver.com/prodba/11505

처음 ORA-3136을 접했을때 생각해봤던 건데 도움이 될까 해서 정리해서 올립니다.

10g가 되면서 inbound_connect_timeout 이 60초로 바뀌게 되었고 그로 인해서 가끔씩 alert에 제목과 같은

메지시가 나오곤 합니다.

우선 ORA-3136이 발생되는 경우를 살펴보면

CASE 1

WIPPY@/oracle> sqlplus /@rac1
SQL*Plus: Release 10.2.0.4.0 - Production on Wed Jan 7 13:33:27 2009
Copyright (c) 1982, 2007, Oracle. All Rights Reserved.
ERROR:
ORA-01017: invalid username/password; logon denied
Enter user-name:

이상태에서 타이핑 없이 대기를 하게되면 60초 후에 alert log에 ORA-3136 이 떨어지게 됩니다.

그렇다면 그 60초 동안 어떤일이 발생하는가?

1. ps -ef|grep LOCAL=NO 로 확인해 보면 process가 하나 늘어나 있는 것을 볼 수 있습니다.

2. v$process 나 v$resource_limit를 보면 process가 하나 늘어나 있는 것을 볼 수 있습니다.

위를 통해서 60초를 강제로 설정해 놓은 이유를 알 수 있습니다.

누군가 악의적인 목적으로 저런식의 접속을 한다음 끊지 않으면 설정해 놓은 process개수를 다 채워버리게 되고

정상적인 connection이 처리되지 못하는 문제가 있겠죠. 따라서 60초를 주기로 oracle에서는 저런 process를 강제로

죽이는 것입니다.

ORA-3136을 발생시키지는 않지만 유사한 경우가 있습니다.

CASE 2

WIPPY@/oracle> telnet 192.168.0.11 1521
Trying 192.168.0.11...
Connected to 192.168.0.11 (192.168.0.11).
Escape character is '^]'.

위와 같이 했을 경우에는 다음과 같은 현상이 나타나게 됩니다.

1. ps -ef|grep LOCAL=NO 로 확인해 보면 process하나 늘어나 있는 것을 볼 수 있습니다.

2. v$process 나 v$resource_limit를 보면 변화가 없습니다.

즉 OS상에서는 process가 뜨지만 oracle의 view에는 반영이 되지 않는 상황입니다.

이러한 상황도 system resource를 사용하는 것이기 때문에 그다지 좋은 상황은 아니겠죠.

위에 유사한 두가지 CASE에 대해서 설명을 했는데 ORA-3136 에 대해서 좀 찾아보신 분들은 알겠지만 이 메세지를 안나오게

하기위해서는 sqlnet.ora 에 SQLNET.INBOUND_CONNECT_TIMEOUT = 0 설정을 하거나 listener.ora에

INBOUND_CONNECT_TIMEOUT_<listener_name> = 0 을 설정하라고 합니다.

제가 테스트 해본 결과에 의하면

sqlnet.ora - SQLNET.INBOUND_CONNECT_TIMEOUT = 0 : sqlplus /@RAC1 에만 영향을 줍니다.

listener.ora - INBOUND_CONNECT_TIMEOUT_<listener_name> = 0 : telnet 192.168.0.11 1521 에만 영향을 줍니다.

즉 APP의 접속 형태에 따라 sqlner.ora와 listener.ora를 취사선택하거나 둘다 설정을 해야할 필요성이 있는 것입니다.

INBOUND_CONNECT_TIMEOUT을 설정할때는 위와 같은 내용을 인지하고 설정을 하셔야 할것으로 생각됩니다.

무작정 ERROR를 보이지 않게 하기 위해서 설정을 한다면 보안상 심각한 문제를 야기할 수도 있으니까요.

즉 ORA-3136이 발생하게 되면 connection이 늦게 처리되는 APP에 대해서 먼저 확인하고 60초 안에 접속이 이루어 지도록

APP단의 수정을 해야 하는 것이 우선이라고 생각합니다.

## 10.2.0.4 linux에서 테스트한 결과 입니다. 버전에 따라 차이가 있을 수 있음을 .. 이해하시길..

---------------------------------------------------------------------------------

나의 의견 : alert file에 ora-3136이 떴을때 웬지 모를 불안감이 생겼었지만..

이 에러에 대해서 조금 알고나니..

유용한 에러라 생각되어집니다.

inbound_connect_timeout을 유용하게 사용할 수 있을 것 같습니다.

'Oracle > Oracle Scrap' 카테고리의 다른 글

[스크랩] RAC (0)	2010.05.18
WARNING: inbound connection timed out (ORA-3136) (0)	2010.03.02
GRID & RAC 개념 (0)	2010.02.23
(Oracle 10g) MMAN 백그라운드 프로세스를 통한 자동 공유 메모리 관리 (0)	2010.02.17
DATABASE 일일 점검 리스트 (0)	2009.12.15

GRID & RAC 개념

2010. 2. 23. 10:21

1. GRID의 개념

1.1 GRID의 개념

1) GRID 컴퓨팅의 정의

자세한 정보는 http://blog.naver.com/sbg10?Redirect=Log&logNo=120009432781 참고

그리드 컴퓨팅(Grid Computing)의 핵심 개념은 전화나 전기, 수도 같은 유틸리티로써의 컴퓨팅이다.

사용자는 원하는 때 원하는 만큼 정보나 컴퓨팅 작업을 요청하고 받을 수 있게 된다.

그리드 컴퓨팅은 프로세싱, 네트워크 대역폭 및 스토리지지 용량과 같은 분산된 컴퓨팅 자원을 가상화하여

하나의 시스템 이미지를 만들어 사용자 및 응용 프로그램이 다양한 IT 기능에 완벽하게 접근 할 수 있도록

지원한다.

쉽게 기업내에 산재해 있는 소형 서버들을 연결해 하나의 커다란 컴퓨터처럼 사용하는 개념으로

생각할 수 있다.

유틸리티 컴퓨팅은 "클라이언트 측면에서" 본 것이다. "서버 측면에서" 보자면(그리드의 이면을 파고들면),

"그리드"는 자원 할당, 정보 공유 그리고 고가용성과 관련된 개념이다.

① 자원할당

- 자원을 요청하고 필요로 하는 누구든지 원하는 것을 얻을 수 있도록 하는 것

- 요청이 없는 동안에 자원의 낭비를 막는 것.

② 정보공유

- 사용자와 어플리케이션이 필요로 하는 정보는 언제 어디서나 필요에 따라 이용할 수 있도록 해주는 것.

③ 고가용성

- 고가용성이란 하나의 노드에 문제가 생긴 경우 다른 노드에서 서비스나 기능을 대신 제공하는 것을 말한다.

- 긴 시간동안 지속적으로 운영이 가능한 시스템이나 컴포넌트로 가용성이란 흔히 "100% 가용" 등과 같이

상대적으로 측정되거나 또는 "절대 고장나지 않음" 등과 같이 표현 될 수 있다.

2) GRID 컴퓨팅의 필요성

① GRID 컴퓨팅은 소형 서버들을 연결, 고성능을 유지하면서 더욱 많은 자원을 활용 가능 하므로 효율적인

IT인프라 사용을 위한 좋은 방안이다.

② 기존에 사용하던 시스템을 전환할 필요 없이, 기존 인프라스트럭처로부터 GRID 컴퓨팅으로 전환 가능하다.

③ GRID 컴퓨팅은 저렴한 가격으로도 기업의 인프라를 효율적으로 활용할 수 있는 최적의 솔루션이다.

3) 오라클 GRID 컴퓨팅

- 저렴한 다수의 컴퓨팅 자원으로 고가의 컴퓨팅 자원보다 더 높은 성능을 구현할 수 있다.

- 그리드는 어떤 컴퓨터든, 자원을 항상 최대 용량 만큼 쓰는 것이 아니기 때문에 쉬고 있는 순간에

다른 업무에 활용할 수 있도록 빌려준다는 개념으로도 이해할 수 있다.

- Oracle Database 10g는 Enterprise Grid Computing을 위해 디자인된 최초의 데이터베이스이다.

2 RAC의 개념

2.1 RAC의 정의

- Oracle Real Application clusters(RAC)는 Oracle Parallel Server(OPS)의 후속 제품으로 개발되어

Oracle9i 버전부터 기능을 제공 한다.

- RAC는 동일 데이타베이스(스토리지)를 여러 인스턴스에서 동시에 액세스할 수 있다

- RAC는 시스템 확장이 가능하기 때문에 결함 허용, 로드 밸런싱 및 향상된 성능을 제공한다.

- 모든 노드가 동일한 데이타베이스를 액세스하기 때문에 한 인스턴스에서 장애가 발생해도

데이타베이스에 대한 액세스가 손실되지 않는다.

- Oracle RAC의 핵심은 공유 디스크 하위 시스템이다.

- 클러스터의 모든 노드는 클러스터 내의 모든 노드에 대한

데이타, 리두 로그 파일, 제어 파일 및 매개변수 파일을 액세스할 수 있어야 한다.

- 데이터 디스크는 모든 노드가 데이타베이스를 액세스할 수 있도록 허용하기 위해

전역으로 사용할 수 있어야 한다.

2.2 RAC의 장점

① 확장성(자원(CPU/메모리/디스크등)이 부족했을 경우에 대처 할 수 있는 구조)

- 새로운 업무가 지속적으로 추가되어 서버의 용량이 부족해지는 경우가 발생된다면 클러스터상에

새로운 서버를 유연하게 확장 할 수있고, 서버를 확장 하더라도 문제가 발생하지 않는다.

② 고가용성 (장애가 발생해도 시스템 전체가 운용 될 수 있는 구조)

- 하나의 서버로 구성된 데이터베이스일 경우 데이터베이스 장애가 발생할 경우 복구될때까지

서비스 이용이 불가능 했으나, RAC의 경우에는 하나의 서버에 장애가 발생하더라도,

나머지 서버에서 지속적인 서비스를 제공할 수 있어 서비스의 중지가 발생하지 않는다.

3. RAC 구조

3.1 RAC의 구조

- 물리적인 하나의 데이터베이스를 여러 대의 서버가 공유하여 사용하는 것.

- 모든 서버들은 같은 데이터를 사용하게 되어 논리적으로는 하나의 시스템을 이용하는 것임.

- Cache Fusion 기능을 위해 NODE간 High-Speed Interconnect Network는 필수

reference

- Linux 및 FireWire에 RAC 클러스터 구축 (주)한국오라클

- RAC & Enterprise Manageability Best Practices (주)한국오라클

================================================

* 데이터베이스 정보공유 커뮤니티 oracleclub.com

* 강좌 작성자 : 김정식 (oramaster _at_ naver.com)

================================================

※ oracleclub 강좌를 다른 웹 페이지에 게재할 경우에는 출처를 꼭 밝혀 주시면 고맙겠습니다.~^^

※ oracleclub 강좌는 개인의 학습용으로만 사용 할 수 있습니다. 학원 홍보용이나 수익을 얻기 위한 용도로

사용을 하시면 안됩니다. ^^

'Oracle > Oracle Scrap' 카테고리의 다른 글

WARNING: inbound connection timed out (ORA-3136) (0)	2010.03.02
WARNING: inbound connection timed out (ORA-3136) 에 관해 (0)	2010.03.02
(Oracle 10g) MMAN 백그라운드 프로세스를 통한 자동 공유 메모리 관리 (0)	2010.02.17
DATABASE 일일 점검 리스트 (0)	2009.12.15
오라클 클라이언트 설치 - Javaw.exe에러 (0)	2009.07.20

(Oracle 10g) MMAN 백그라운드 프로세스를 통한 자동 공유 메모리 관리

2010. 2. 17. 13:55

http://kr.forums.oracle.com/forums/thread.jspa?messageID=1699078

(Oracle 10g) MMAN 백그라운드 프로세스를 통한 자동 공유 메모리 관리
========================================

PURPOSE

이 문서에서는 Oracle database 10g의 Self Managing 기능 중의 하나인 자동 공유 메모리 관리 기능에 대하여 알아보고

SGA_TARGET 이라는 새로운 파라미터와 MMAN이라는 새로운 백그라운드 프로세스에 대하여 소개하기로 한다.

Explanation

1. 개요

SGA_TARGET 파라미터를 이용한 자동 SGA 튜닝이 어떻게 이루어지는지 그 원리를 알아보도록 한다.
자동 SGA 튜닝은 Oracle database 10g의 ADDM을 가능하게 하는 요소인 메모리 advisor가 그 기능을 수행한다.

자동 공유 메모리 관리 기능이 갖는 장점은 다음과 같은 몇 가지가 있다.

첫째, workload가 변함에 따라 자동으로 공유 메모리가 적용이 된다.
둘째, 메모리의 활용률을 극대화한다.
세째, out-of-memory라는 메모리 부족 발생으로 인한 에러를 예방할 수 있다.

즉, 오라클의 공유 메모리 영역 중

Shared pool size, Buffer cache size, Large pool size, Java pool size를 매뉴얼하게 셋팅할 필요가 없다.

가용한 메모리의 사용을 보다 효과적으로 해주는 것 뿐만 아니라, 메모리 자원을 얻는 데 필요한 비용을 줄여줄 수 있다.
무엇보다 dynamic하고 flexible한 메모리 관리 구조를 통하여 오라클 데이타베이스 관리를 단순화시켜 준다.

2. MMAN 백그라운드 프로세스

공유 메모리의 자동 튜닝을 위하여 MMAN이라는 백그라운드 프로세스가 새로이 등장하였다.
MMAN이라는 백그라운드 프로세스가 5분 마다 주기적으로 수집한 작업 부하(Workload) 정보를 바탕으로

동적으로 구성이 된다. 메모리는 가장 필요한 곳으로 동적으로 할당이 된다.

SPFILE을 사용하면 MMAN이 변경한 파라미터들의 정보가 자동으로 SPFILE에 저장이 된다.
그러므로, 가능한 Oracle 9i 이상부터는 SPFILE 의 사용을 권장한다.
왜냐 하면 다음과 같은 세 가지 장점이 있기 때문이다.

첫째, 각 부분 크기의 권장안을 인스턴스 종료 후에도 보관할 수 있다.
둘째, 저장되어진 각 파라미터들의 사이즈는 데이타베이스 기동 시 할당이 된다.
세째, 각 파라미터들의 최적의 값을 찾는 데 드는 비용을 줄일 수 있다.

이렇게 MMAN 이라는 프로세스에 의해서 자동 공유 메모리 관리 기능이 구현이 되는 것이다.

3. SGA_TARGET 파라미터를 통한 자동 공유 메모리 관리

자동 공유 메모리 관리 기능을 사용하게 되면 오라클 SGA 관련 네 가지 파라미터들을 DBA가 일일이 셋팅할 필요가 없다.
오라클의 공유 메모리 크기는 SGA_TARGET 이라는 파라미터 하나로 다 조절이 된다.
SHARED_POOL_SIZE, DB_CACHE_SIZE, LARGE_POOL_SIZE, JAVA_POOL_SIZE 라는 파라미터들을 구성하는 데 관여하지 않아도 된다는 뜻이다.

과거에는 이러한 파라미터들을 너무 낮게 잡게 되면 성능도 저하될 뿐만 아니라 out-of-memory error인 ORA-4031 ERROR를 자주 만나게 되었고 메모리 낭비도 있었다.

그러나, Oracle database 10g의 New Feature는 SGA_TARGET이라는 새로운 파라미터만 셋팅하여도 되게 설계되었다.
SGA_TARGET이라는 파라미터는 해당 인스턴스에 필요한 SGA의 최대 크기를 나타낸다.
이 파라미터는 SGA 내의 모든 메모리들을 포함한다.
즉, Automatic하게 사이즈가 결정되는 파라미터, 매뉴얼하게 결정되는 파라미터, startup 시에 할당되는 internal metadata 할당을 다 포함한다.

10g 이전 버젼처럼 SGA의 TOTAL 크기를 정확히 컨트롤하는 것이 어렵지가 않다는 뜻이다.

SGA_TARGET 파라미터를 셋팅할 때에는 다음을 염두에 두어야 한다.

1) SGA 영역 중 자동 구성으로 조절되지 않는 영역이 있는데
Redo Log buffer 와 Fixed SGA 영역, BUFFER KEEP, RECYCLE과 관련된 파라미터, STREAMS POOL 관련 파라미터들이다.

2) SGA_TARGET 파라미터가 0으로 셋팅되면 자동 공유 메모리 기능은 DISABLE된다.
SGA_TARGET 파라미터의 DEFAULT 값은 0이다.
SGA_TARGET 파라미터가 0이 아닌 어떤 값으로 셋팅이 되어 있어도
SHARED_POOL_SIZE 또는 DB_BLOCK_BUFFERS 와 같은 파라미터들은 여전히 셋팅할 수는 있다.

3) SGA_TARGET 파라미터가 설정되어 있지 않거나 0 으로 셋팅되어 있을 경우,
자동 튜닝 파라미터들은 10g 이전 버젼에서와 같이 관리된다.
단, 예외는 있다. SHARED_POOL_SIZE가 그 경우인데, 내부적인 STARTUP 시 소모되는 오버헤드는 포함이 된다.

이 부분이 SHARED_POOL_SIZE에 포함이 된다.
Oracle 10g 이전 버젼에서는 이 부분이 SHARED_POOL_SIZE에 포함되지 않았으나
10g부터는 포함되게 되어 SHARED_POOL_SIZE를 좀 더 크게 잡아야 한다.
구체적으로 10g에서는 SHARED_POOL_SIZE를 32m 정도 더 크게 잡아야 한다.
예를 들어, Oracle 9i에서 SHARED_POOL_SIZE를 256M를 사용했었다면,
Oracle 10g에서는 같은 효과를 얻으려면 288M 정도로 잡아야 한다.

4) SGA_TARGET 파라미터가 0이 아닌 값으로 셋팅이 되어 있는 경우
자동으로 튜닝되는 SGA 파라미터들은 모두 기본적으로 0으로 셋팅이 된다.
이러한 파라미터들은 자동 공유 메모리 관리 알고리즘에 의하여 자동으로 사이즈가 결정이 된다.
그러나, 만약 이러한 자동 튜닝 파라미터들이 0이 아닌 어떤 값으로
셋팅이 되어 있다면 명시한 값은 자동 튜닝 알고리즘에 의해 최저값을 나타낸다.
예를 들어, SGA_TARGET 파라미터가 8G로 셋팅되어 있고, SHARED_POOL_SIZE가
1G로 셋팅되어 있다면 SHARED_POOL_SIZE는 절대 1G 아래로 떨어지지 않음을 뜻한다.

V$SGA_Dynamic_components 뷰를 조회하면 자동 튜닝 component들의 실제 사이즈를 확인할 수 있다.

SELECT component, current_size/1024/1024
FROM v$sga_dynamic_components;

4. 수동으로 튜닝되는 SGA 파라미터 설정

SGA의 몇몇 구성 파라미터들은 자동으로 튜닝되지 않아서 매뉴얼하게 튜닝을 해야 한다.
다음은 수동으로 튜닝되는 SGA 파라미터들이다.

- KEEP 및 RECYCLE 버퍼 캐시
- 멀티 블록 사이즈 캐시(DB_nK_cache_size)
- 로그 버퍼
- 스트림즈 POOL

수동으로 튜닝되는 파라미터들은 반드시 사용자에 의해 명시되어져야 한다.
이런 파라미터들은 10g 이전 버젼에서와 같이 정밀하게 크기가 제어되어야 한다.
매뉴얼하게 튜닝되는 이러한 파라미터들은 SGA_TARGET에는 포함되지만, 자동으로 튜닝되지는 않는다.
예를 들어, SGA_TARGET 이 8G이면 MANUAL하게 수동으로 조절되는

파라미터들의 사이즈의 합을 1G로 잡으면 7G는 자동으로 오라클이 알아서 설정한다.

5. SGA_TARGET 파라미터의 설정 변경

SGA_TARGET 파라미터의 RESIZING이란 SGA_TARGET 파라미터의 설정 변경을 의미한다.
SGA_TARGET 초기화 파라미터의 특징은 다음과 같다.

첫째, 운영 중에 동적으로 변경이 가능하다.
둘째, SGA_MAX_SIZE 내에서 크기를 증가시킬 수 있다.
세째, 모든 구성 요소의 최저값의 합까지 크기를 감소시키는 것이 가능하다.
또한, SGA_TARGET 파라미터의 설정은 오직 자동으로 튜닝할 수 있는
파라미터들에만 영향을 준다.

예를 들어, SGA_MAX_SIZE가 10G이고, SGA_TARGET이 8G로 가정을 한다.
만약, DB_KEEP_CACHE_SIZE가 1G로 셋팅이 된다고 하면 SGA_TARGET 을 최대 9G까지 늘릴 수 있다.
추가적인 1G는 SGA_TARGET에 의해 조절되는 자동 튜닝 파라미터들에게 분배가 된다.
DB_KEEP_CACHE_SIZE 는 영향을 받지 않는다는 뜻이다.
이것은 SGA_TARGET 파라미터를 줄일 때에도 해당된다.

6. 자동 공유 메모리 관리 비활성화

이 기능을 비활성화하려면 SGA_TARGET 파라미터를 0으로 설정하면 된다.
이렇게 SGA_TARGET 파라미터를 0으로 설정하게 되면 자동 튜닝 파라미터들은 그 당시의 값으로 설정된다.
그리고, 전체 SGA 크기에는 영향을 미치지 않는다.

예) 변경 전 값
SGA_TARGET=8G
SHARED_POOL_SIZE=1G

변경 후 값
SGA_TARGET=0
SHARED_POOL_SIZE=2G
DB_CACHE_SIZE=4G
LARGE_POOL_SIZE=512M
JAVA_POOL_SIZE=512M

SGA_TARGET이 8G로 셋팅되어 있고, SHARED_POOL_SIZE 파라미터가 1G로
설정되어 있다가 SGA_TARGET을 0으로 변경하면 자동 튜닝 파라미터들은
그 당시의 값으로 셋팅되고 전체 SGA 크기는 이전 SGA 크기를 초과하지 않는다.
SHARED_POOL_SIZE가 2G로 셋팅이 된 것은 내부적으로 측정하여 결정된 수치이다.

7. 동적 SGA 파라미터의 수동 변경

자동 튜닝되는 파라미터를 수동으로 변경할 경우 다음과 같은 영향을 가진다.

1) 만약 파라미터의 새로이 반영되는 값이 현재의 값보다 클 경우에는 즉시 반영이 된다.
그러나, 새로이 반영되는 값이 현재의 값보다 작을 경우에는 현재의 값에는 즉시 변화가 없고 최저값으로 셋팅이 된다.

2) 자동으로 튜닝되는 파라미터들을 수동으로 변경하였을 경우에는 SGA의 자동 튜닝 부분에 영향을 준다.
RESIZE 수행 시에 사용되는 메모리는 자동 튜닝 파라미터들로부터
더해지거나 감해질 뿐 매뉴얼하게 조절되는 파라미터들에는 영향을 주지 않는다.

Example

다음은 자동 튜닝 파라미터 설정 시 V$PARAMETER 조회 결과 예이다.

SGA_TARGET=8G
DB_CACHE_SIZE=0
JAVA_POOL_SIZE=0
LARGE_POOL_SIZE=0
SHARED_POOL_SIZE=0

SELECT name, value, isdefault
FROM V$PARAMETER
WHERE name LIKE '%size%';

만약 SGA_TARGET 파라미터가 0이 아닌 값으로 셋팅이 되어 있는 경우

자동 튜닝되는 파라미터들은 값을 명시하지 말라는 뜻이다.
V$PARAMETER 뷰를 조회하였을 때 자동으로 튜닝되는 이러한 SGA 파라미터들의 값은 모두 0이다.
이것이 정상이고, isdefault 컬럼 값은 TRUE 이다.

즉, 자동 공유 메모리 관리 기능을 구현할 때에는 이 파라미터들은 매뉴얼하게 설정을 하지 않으면 된다.

'Oracle > Oracle Scrap' 카테고리의 다른 글

WARNING: inbound connection timed out (ORA-3136) 에 관해 (0)	2010.03.02
GRID & RAC 개념 (0)	2010.02.23
DATABASE 일일 점검 리스트 (0)	2009.12.15
오라클 클라이언트 설치 - Javaw.exe에러 (0)	2009.07.20
오라클의 각종 limit 값 (0)	2008.12.03

DATABASE 일일 점검 리스트

2009. 12. 15. 09:49

카페 > ProDBA | jams

http://cafe.naver.com/prodba/15608

< 일일 CECKLIST > <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><?xml:namespace prefix = o />

l DATABASE

1.1 매일 alertSID.log 화일의 내용과 trace file의 내용을 check

- 이 화일에서 internal error나 다른 oracle error들을 알수 있다.

이 화일의 내용은 무한히 늘어나므로 이 화일의 directory space도 조절할 필요가 있다.

1.2 alerSID.log화일이나 trace 화일 일정 크기 이상이 되면 backup

- alertSID.ora는 무한히 커지므로 적당한 양만큼 bacup을 받아라. 이 화일로 장애 발생의 유추가 가능하므로 필요하다.

1.3 *_dump_dest의 free space여부를 항상 확인

- InitSID.ora이나 configSID.ora에 *_dump_dest가 설정되어 있다.

1.4 각 tablespace에 free space의 fragmentation이 일어났는지 확인

- fragmentation이 많이 일어나고 free space는 많이 존재하지 않는다면 하나의 data file을 첨가하라.fraementation도 높고 free space와 disk space가 거의 존재하지 않는다면 table들과 free space를 각각 연속적으로 연결이 되도록 backup/export를 받은 후 다시 drop/import를 하고 재구성한다.

1.5 각 tablespace에 free space를 생성되는 속도를 확인

- 즉 database의 성장 속도를 확인하여 space 부족으로 생길 수 있는 DB가 hang이 걸리는 문제를 미리 대비할 수 있도록 하라.

2 CONTROL FILE

2.1 매일 밤 hot backup을 받아라. (ARCHIVE경우)

3 Online Redo Log File

3.1 V$LOG를 사용해서 invalid하거나 stale 상태를 check하라.

- INVALID log file error는 I/O error로서 alert.log에 기록되지 않으며 alert.log file을 분석함으로써탐지가 가능하다. STALE은 shutdown abort전에 쓰여지고 있는 log가 완전하지 않거나 그log에 대해 걸려있는 write 상태가 알 수 없는 것일 때에 생성된다. 이것도 역시 alert.log 화일에 기록되지 않는다.

이런 현상이 자주 일어나면 hardware의 문제를 가리키는 것일 수도 있다.

3.2 log switch interval을 자주 check하라.

- log switch interval은 위의 time의 차이를 계산하면 알 수 있다.

Log Switch가 너무 자주 발생하면 혹시 hot backup 상태로 두고 있는 화일이 있는지 확인 하라.

3.3 checkpoint 간격을 자주 확인

- 권할 만한 checkpoint의 간격은 매10에서 15분 정도이다.이 checkpoint의 간격은 Background process가 죽어서 instance가 abort되는 극한 상황에서 database를 살리고 잠깐의 시간 동안crash recovery를 할 때 반영된다.위의 간격을 조절하려면 database에서 checkpoint interval setting 또는 checkpoint_timeout을 조절함에 의해 가능하다.checkpoint_timeout을 0으로 그리고checkpoint_interval을 online redo log file의 크기보다 크게 두면 checkpoint는 log switch가 일어날때 일어난다.

- 잦은 checkpoint는 crash recovery의 기간은 줄여주나 dirty buffers를 자주 쓰는 것과 file headers를 자주 update하는데 드는 overhead가 발생한다.

4 Rollback Segment tablespace

4.1 Rollback Segment가 online이 되어있는지 확인

- 어떤 rollback segment는 의도적으로 offline이 되어있을 수 있다.

예를 들면 rollbacksegment를 가진 datafile에 문제가 발생시 등에서다. 이런 경우의 원인을 조사하라.

4.2 ORA-1555 error가 생성되는지 여부를 확인

- Database는 여전히 사용가능하며 application error가 일어날 수도 있다.

4.3 ORA-1538,1551,1552,1553,1554,1555,1556,1557,1558,1559,1562를 check하라.

- 위의 error는 extent를 할당할 수 없거나 tablespace fragmentation이 일어나는 경우에 나타난다.위의 error가 발생해도 database는 여전히 사용이 가능하나 application errors가 일어날 수 있다.

- 이 경우datafile을 더함으로써 많은 space를 추가하거나 더욱 큰 rollback segments를 추가하여더 큰 transaction을 다룰 수 있도록 재구성하라.

5 Archived Redo Logs (ARCHVIE LOG MODE ONLY)

5.1 archive file이 생성되는 destination에 여유 공간이 있도록 유지하라.

- disk에 여유공간이 없어 archive log를 write할 수 없어서 DB가 hang이 걸림을 방지하기 위해서 필수적이다.archive destination에 freespace가 특정 threshold이상이면 alarm하게 함으로써 수시 점검이 가능하도록 하여야 한다

5.2 archived log file을 특정 threshold에 도달할 때마다 backup을 받아라.

- Archived redo log file의 갯수는 log file의 크기와 redo의 양에 의해 달려있다. 그리고 redo의 양은 transaction의 비율과 연관성이 있다. 위의 양에 따라 더 자주backup을 받을 수 있다. backup을 받을 때 archiver가 완전이 다 쓴 archived redo log file만을 받도록 해야 한다.

5.3 Archived redo log file의 sequence number가 순차적인지 확인

- Archive file에 이름이 명명되어질 때 archived log file은 log sequece가 주어지도록 되어 있다.그러므로 log switch가 일어날 때마다 sequence number는 하나씩 증가된다.

그러나,OPS의 경우에는 thread number가 함께 명명되어짐을 잊지 말아야 한다.

5.4 ARCH process가 움직이는지를 자주 확인하라

- OS상에서 ARCH process가 움직이는지 확인함으로써 ARCH process가 움직이지 않아서DB가 hang이 걸리는 문제를 막을 수 있다.

5.5 alert.log에 Archive log들에 관한 error가 있는지 확인

- 위의 화일은 대걔 $ORACLE_BASE/admin/$ORACLE_SID/bdump에 존재하거나 initSID.ora (parameter file)내의 *_dump_dest방향을 참조하라.

6 OS detection

6.1 Disk failure나 controller의 이상이 있는지 항상 확인

6.2 OS mirroring이 되고 있는지 항상 확인

'Oracle > Oracle Scrap' 카테고리의 다른 글

GRID & RAC 개념 (0)	2010.02.23
(Oracle 10g) MMAN 백그라운드 프로세스를 통한 자동 공유 메모리 관리 (0)	2010.02.17
오라클 클라이언트 설치 - Javaw.exe에러 (0)	2009.07.20
오라클의 각종 limit 값 (0)	2008.12.03
[오라클] 날짜 계산 SQL문 예시 (0)	2007.08.30

오라클 클라이언트 설치 - Javaw.exe에러

2009. 7. 20. 12:47

천상태자 | 천상태자

오라클 클라이언트를 다시 설치하다보니

Javaw.exe 에서 에러가 발생하는 군요. @@;;

이전 포스팅에 R2 버전은 잘 된다라고 했더니, 여기저기서 안된다는 분들이 있었는데,

아마도 이 문제였나봅니다.

아무리 해봐도 안되어서 @@; Java를 통한 GUI 설치를 포기하고

콘솔에서 무인 자동설치로 설치해 버렸습니다.

일단, 하드디스크 특정 폴더로 오라클 클라이언트 설치 파일들을 모두 옮깁니다.

response 폴더의 clientadmin.rsp 파일을 열어 내용을 수정합니다.

(clientadmin.rsp는 관리자 모드로 설치하기 위한 스크립트 파일입니다.)

#-----------------------------------------------------------------------------
#Name       : ORACLE_HOME
#Datatype   : String
#Description: Complete path of the Oracle Home.
#Example    : ORACLE_HOME = "/product/10.2.0/client"
#-----------------------------------------------------------------------------
ORACLE_HOME="c:\oracle\product\10.2.0\client"

#-----------------------------------------------------------------------------
#Name       : ORACLE_HOME_NAME
#Datatype   : String
#Description: Oracle Home Name. Used in creating folders and services.
#Example    : ORACLE_HOME_NAME = "OraClient10ghome1"
#-----------------------------------------------------------------------------
ORACLE_HOME_NAME="OraClient10ghome1"

값은 꼭 위와 같지 않아도 됩니다. ^^

그런후 명령 프롬프트를 실행한 후 아래의 명령을 입력합니다.

>> setup.exe -silent -responsefile c:\임시파일\response\clientadmin.rsp

이쁜 설치 화면은 뜨지 않지만, 잘 ~ 설치 됩니다. ^^

'Oracle > Oracle Scrap' 카테고리의 다른 글

(Oracle 10g) MMAN 백그라운드 프로세스를 통한 자동 공유 메모리 관리 (0)	2010.02.17
DATABASE 일일 점검 리스트 (0)	2009.12.15
오라클의 각종 limit 값 (0)	2008.12.03
[오라클] 날짜 계산 SQL문 예시 (0)	2007.08.30
with grant option & with admin option (0)	2007.04.27

오라클의 각종 limit 값

2008. 12. 3. 23:06

카페 > ProDBA | 오라킬

http://cafe.naver.com/prodba/9276

<?xml:namespace prefix = o /><?xml:namespace prefix = o /><?xml:namespace prefix = o />

오라클의 각종 Limit 값

기준환경은 Linux(32bit 64bit파일)를 사용했을 때를 기준으로 설명되어 있다.

AIX, Windows, Mac 에 대해서는 플랫폼 별 매뉴얼을 참조

구분		최대값	비고
스키마 오브젝트	Column 수,	1000 개	테이블,컬럼명 길이제한 - 30 바이트(30 캐릭터)
	Sequence	38 자리
	결합 인덱스 컬럼 수	l 32 개 컬럼 l 한 BLOCK 80% 이상 차지하면 에러	BLOCK 사이즈 제한은 일반 컬럼과는 다르게 INDEX 는 row chaining 의 구조를 적용 할 수 없음
	PK 컬럼 수	l 32개 컬럼 l 한 BLOCK 80% 이상 차지하면 에러
데이터 블록	데이터베이스 블록 사이즈	2K/4K/8K/16K/( 32K 64bit OS)
	하나의 데이터파일의 최대 데이터 블록 수	2^22 – 1 블록 (4,194,303 개)	예제) 블록사이즈 4K 이면 약 16 GB 데이터파일 사이즈 8K이면 32 GB, 16K 이면 64GB 128K 이면 128GB
	BIGFILE 최대 데이터 블록 수	2^32 –1 블록 (4,294,967,295 개)	예제) 블록사이즈 4K 이면 약 16 TB
EXTENT 최대크기	딕셔너리 관리방식	4GB * 블록사이즈
	로컬 관리 방(uniform으로extent 지정)	2GB * 블록사이즈
	MAXEXTENT	무제한
파일	Control 파일사이즈	블록사이즈 * 20,000 (리커버리 카탈로그를 사용하는 Rman 이 아닌 경우)
	데이터 파일수	l 전체- 65,533 개 l 하나의 테이블스페이스- 1,022 개	참조 파라미터 DB_FILES
	데이터파일 사이즈	4,194,303 * 블록사이즈(UNIX)	Imp/exp –32bit의 경우 2 GB 64bit의 경우–무제한 SQL*LOADER파일 – 32bit의 경우 – 2 GB 64bit의 경우 – 무제한
SQL문의 제약사항	SQL문의 크기	65,535 Byte (Oracle 9i) 제한없음 (10g)	미들웨어에 따라서는 32K 제약이 있는 경우도 있다. DBMS_SQL 패키지를 사용해서 최대값 이상 사용가능
	Dynamic SQL (Execute immediate)	32 KB (Varchar2 의 최대값과 같다)	이를 초과하면 Ora-06502 에러 발생
	FROM절	제한없음
	WHERE절	제한없음
	IN 리스트	1000 개
	GROUP BY 개수	기술하는 그룹핑 컬럼의 사이즈가 1BLOCK 사이즈를 초과하지 못한다.	매뉴얼상에는 이렇게 기술되어 있지만 실제로는 제한이 없는 것으로 알려져 있다.(확실치않음 ^^;; )
	ORDER BY	제한없음
	표준함수의 최대값	COALESCE 함수의 인수의 최대값 – 256 개 DECODE 함수의 인수의 최대값 – 255 개
PL/SQL 제약사항	User defined Function의 인수의 개수	PL/SQL 프로시저의 인수의 최대값은 65,536
PL/SQL 제약사항	PL/SQL 의 원시코드 사이즈	스토어드프로시저, function, trigger 등의 상한값은 64 KB(일부의 windows에서는32KB)	트리거 소스코드의 사이즈가 지나치게 길게 되면DBMS_METADATA 실행 시에 에러발생

원문 http://www.shift-the-oracle.com/oracle/limits.html

'Oracle > Oracle Scrap' 카테고리의 다른 글

(Oracle 10g) MMAN 백그라운드 프로세스를 통한 자동 공유 메모리 관리 (0)	2010.02.17
DATABASE 일일 점검 리스트 (0)	2009.12.15
오라클 클라이언트 설치 - Javaw.exe에러 (0)	2009.07.20
[오라클] 날짜 계산 SQL문 예시 (0)	2007.08.30
with grant option & with admin option (0)	2007.04.27

[오라클] 날짜 계산 SQL문 예시

2007. 8. 30. 17:43

... | 준팅

http://blog.naver.com/jun6739/110017203980

# 날짜계산

select months_between(sysdate,to_date(2007-12-22','yyyy-mm-dd'))

-- months_between(A,B) = A-B/30

--select add_months(sysdate,4) -- 특정일의 달수 더한 날

--select next_day(sysdate,'friday') -- 특정일의 다음주 요일

--select last_day(sysdate) -- 특정일의 해당 월의 마지막 날

--select round(sysdate,'dd') -- 특정일의 반올림(오후면 다음날..)

--select trunc(sysdate,'ww') -- 특정일의 전주 토요일(해당 전주의 마지막 날)에해당하는 날짜

--select trunc(sysdate,'D') -- 특정일의 주 일요일(해당 주의 첫째 날)에해당하는 날짜

from dual

/* 어제 */ 날짜칼럼 BETWEEN TRUNC(SYSDATE-1) AND TRUNC(SYSDATE-1)+0.99999421

/* 오늘 */ 날짜칼럼 BETWEEN TRUNC(SYSDATE) AND TRUNC(SYSDATE) + 0.99999421

/* 내일 */ 날짜칼럼 BETWEEN TRUNC(SYSDATE+1) AND TRUNC(SYSDATE+1)+0.99999421

/* 금주 */ 날짜칼럼 BETWEEN TRUNC(SYSDATE+1)-TO_CHAR(SYSDATE,'D')

AND TRUNC(SYSDATE+1)-TO_CHAR(SYSDATE,'D')+6.99999421

/* 차주 */ 날짜칼럼 BETWEEN TRUNC(SYSDATE+8)-TO_CHAR(SYSDATE, 'D')

AND TRUNC(TRUNC(SYSDATE)+14.99999421)-TO_CHAR(SYSDATE, 'D')

/* 금월 */ 날짜칼럼 BETWEEN TRUNC(SYSDATE+1)-TO_CHAR(SYSDATE,'DD')

AND TRUNC(LAST_DAY(SYSDATE))+0.99999421

/* 전월 */ 날짜칼럼 BETWEEN TRUNC(ADD_MONTHS(SYSDATE,-1)+1)-TO_CHAR(SYSDATE,'DD')

AND TRUNC(LAST_DAY(ADD_MONTHS(SYSDATE, -1)))+0.99999421

/* 차월 */ 날짜칼럼 BETWEEN ADD_MONTHS(TRUNC(SYSDATE),1)-TO_CHAR(SYSDATE,'DD')+1

AND LAST_DAY(ADD_MONTHS(TRUNC(SYSDATE),1)+0.99999421)

# 특정일 까지의 간격을 년, 개월, 일로 표현하기

SELECT

TRUNC(MONTHS_BETWEEN(SYSDATE, TO_DATE(?', 'YYYYMMDD'))/12) "년",

TRUNC(MONTHS_BETWEEN(SYSDATE, TO_DATE(?', 'YYYYMMDD')) -

TRUNC(MONTHS_BETWEEN(SYSDATE, TO_DATE(?', 'YYYYMMDD'))/12) * 12) "개월",

TRUNC((MONTHS_BETWEEN(SYSDATE,TO_DATE(?', 'YYYYMMDD')) -

TRUNC(MONTHS_BETWEEN(SYSDATE, TO_DATE(?', 'YYYYMMDD')))) * 30.5) "일"

FROM DUAL;

# 당월의 주차 구하기..

SELECT

?' as "날짜"

, ceil((to_number(substrb(?', -2, 2)) + 7 - to_number(TO_CHAR(TO_DATE(?','YYYYMMDD'),'D')))/7) as "월별 주차"

from dual;

# 시간 계산 SQL

SELECT TRUNC(TO_DATE(?','YYYYMMDDHH24MISS')-TO_DATE(?','YYYYMMDDHH24MISS')) || ' day ' ||

TRUNC(MOD((TO_DATE(?','YYYYMMDDHH24MISS')-TO_DATE(?','YYYYMMDDHH24MISS')),1)*24) || ' hour ' ||

TRUNC(MOD((TO_DATE(?','YYYYMMDDHH24MISS')-TO_DATE(?','YYYYMMDDHH24MISS'))*24,1)*60) || ' minute ' ||

TRUNC(ROUND(MOD((TO_DATE(?','YYYYMMDDHH24MISS')-TO_DATE(?','YYYYMMDDHH24MISS'))*24*60,1)*60)) || ' sec '

" Time Interval "

FROM DUAL ;

출처 : oramaster.net

'Oracle > Oracle Scrap' 카테고리의 다른 글

(Oracle 10g) MMAN 백그라운드 프로세스를 통한 자동 공유 메모리 관리 (0)	2010.02.17
DATABASE 일일 점검 리스트 (0)	2009.12.15
오라클 클라이언트 설치 - Javaw.exe에러 (0)	2009.07.20
오라클의 각종 limit 값 (0)	2008.12.03
with grant option & with admin option (0)	2007.04.27

with grant option & with admin option

2007. 4. 27. 17:27

with grant option과 with admin option

(둘다 실행 권한을 받은 user가 다시 실행 권한을 다른 user에게 줄 수 있게 해주는 option이다.)
-- 차이는 with admin option으로 권한을 받은 user1이 다른 user2에게 권한을 부여한 후 user1으로부터
권한을 revoke하면 user1의 권한만 revoke되나
with grant option으로 부여하면 user1에게 revoke 될 시 user2의 권한도 cascade로 revoke된다.

oracle@swsvrctr:/home/oracle> sqlplus internal

SQL> col grantor format a10
SQL> col grantee format a10
SQL> col table_name format a10
SQL> col table_schema format a10
SQL> col privilege format a25
SQL> grant create user to scott with admin option; ==> with admin option으로 권한 부여후
SQL> connect scott/tiger
SQL> grant create user to oracle; ==> 다시 oracle 에게 같은 권한 부여후
SQL> connect internal
SQL> select * from dba_sys_privs
2 where grantee in ('SCOTT','ORACLE');

GRANTEE PRIVILEGE ADMIN_
---------- ------------------------- ------
ORACLE CREATE USER NO
SCOTT CREATE USER YES
SCOTT UNLIMITED TABLESPACE NO

SQL> revoke create user from scott; ==> scott의 권한을 revoke
SQL> select * from dba_sys_privs
2 where grantee in ('SCOTT','ORACLE');

GRANTEE PRIVILEGE ADMIN_
---------- ------------------------- ------
ORACLE CREATE USER NO ==> scott의 create user 권한만 revoke되었다.
SCOTT UNLIMITED TABLESPACE NO oracle권한은 그대로

SQL> grant select on dept to oracle with grant option; ==> with grant option 으로 권한 부여후
SQL> connect /
SQL> create user myuser identified by myuser1$
2 default tablespace ts_user1
3 temporary tablespace temp;

SQL> grant select on scott.dept to myuser; ==> 다시 같은 권한을 다른 myuser에게 부여

Grant succeeded.

SQL> select * from all_tab_privs
2 where table_name='DEPT';

GRANTOR GRANTEE TABLE_SCHE TABLE_NAME PRIVILEGE GRANTA
---------- ---------- ---------- ---------- ------------------------- ------
SCOTT ORACLE SCOTT DEPT SELECT YES
ORACLE MYUSER SCOTT DEPT SELECT NO

SQL> revoke select on dept from oracle; ==> oracle의 권한을 revoke

Revoke succeeded.

SQL> select * from all_tab_privs ==> with grant option으로 생성된 이하 myuser의 권한도
2 where table_name='DEPT'; revoke 되었다.

no rows selected

===================================================================================

http://cafe.naver.com/jjuvva.cafe?iframe_url=/ArticleRead.nhn%3Farticleid=287

푸뇽(edood)님 께서 작성하신 글입니다.

스크랩이 안되서 긁어왔습니다.

'Oracle > Oracle Scrap' 카테고리의 다른 글

(Oracle 10g) MMAN 백그라운드 프로세스를 통한 자동 공유 메모리 관리 (0)	2010.02.17
DATABASE 일일 점검 리스트 (0)	2009.12.15
오라클 클라이언트 설치 - Javaw.exe에러 (0)	2009.07.20
오라클의 각종 limit 값 (0)	2008.12.03
[오라클] 날짜 계산 SQL문 예시 (0)	2007.08.30

PREV 1 NEXT

+ Recent posts

Powered by Tistory, Designed by wallel

개발은 너무해