ORA-600[729]는 UGA(User Global Area) memory 부족 에러로 database 운영에는 지장을 주지 않는
에러입니다. memory의 제대로 release하지 못하여 발생하는 에러입니다. db shutdown 이나 process 가 disconnect
할때, 반납해야할 memory release 하지 못할 때 발생합니다.
따라서, db 에 저장된 data 에는 전혀 문제가 없고, 일반적으로 무시하셔도 되는 에러 입니다.
다음과 같이 memory leak 을 허용하는 event 를 initSID.ora 에추가한 다음 restartup하면 해결된다 합니다.
event="10262 trace name context forever, level 2000"
즉, disconnect하는 process 를 memory leak 은 허용해도 무방하므로
위의 event 를 사용하시면 위의 에러를 해결할 수 있습니다.
600[12235]는 oracle process가 시작이 됐으나 그 본래의 목적이 없어져서 수행될 수 없는 상태에서
발생되는 에러임. system의 운영에는 이상이 없는 현상입니다.
다음의 방법은 redo log buffer를 할당받기 위한 latch와 관련된 redo log buffer tuning방법입니다.
다음의 sql을 수행후 만일 0에 가깝지 않고 연속 수행시 계속 증가하는 현상이 있다면 늘려 주셔야 합니다.
redo log buffer의 tuning으로 latch contention을 회피할 수 있습니다.
모든 사용자 process는 먼저 redo log buffer가 생성되어야 redo record block을 변경할 수 있습니다.
사용자 process가 redo log buffer를 할당받기 위해서는 redo allocation latch또는 redo copy latch를 먼저
회득하여야 합니다. log_small_entry_max_size보다 작은 entry들 만 redo copy latch없이 쓰여 질 수 있으며
더 큰 size를 가지는 redo emtry는 redo allocation entry를 할당 방고 난 다음 redo copy latch를 요구합니다.
redo allocation latch는 하나의 instance에 하나만 존재합니다. 이것의 경합을 줄이는 것이 성능향상의
목적이 되는데 이의 tuning을 위해서는 작은 log_small_entry_max_size를 사용하면 됩니다.
redo copy latch는 log_simultaneous_copies로서 조정이 가능한데 redo copy latch의 hit ratio가 낮다면
이 값을 증가 시켜야 합니다.
select value "Redo log request"
from v$sysstat
where name = 'redo log space requests';
prompt ***************************************************************
prompt * Redo log space requests가 거의 0에 가까워야 합니다. 만약 이 *
prompt * 수치가 연속적으로 증가하면 log_buffer의 size를 증가 시켜야 *
prompt * 합니다. 증가 시 약 5% 씩 증가한 후 다시 monitoring. *
prompt ***************************************************************
latch관련 정보입니다.
Latch and Enqueue
latch는 SGA에 있는 shared data structure를 보호하기 위해 사용되는 저수준의
serialization mechanism이다. latch는 일종의 lock으로 굉장히 빨리 acquire
되거나 free되며 일반적으로 하나의 process가 어느 한 순간에 실행하는 piece
of code를 다른 process로부터 보호한다. 만약 latch를 잡고있는 process가
죽는다면 그에 대한 cleanup procedure가 실행된다. latch는 dead lock을 막기
위해 level을 갖고 있는데 process가 어떤 level의 latch를 잡고 있으면 같거나
그보다 낮은 level의 latch는 잡을 수 없다.
[ Latch와 enqueue ]
enqueue는 oracle에서 사용되는 다른 종류의 locking mechanism이다. enqueue는
동시에 여러 프로세스가 기존의 resource에 대해서 다른 degree로 공유할 수 있
는 방법을 제공한다. enqueue의 가장 대표적인 예가 table에 대한 lock이라 할
수 있겠다. 즉 하나의 테이블에 대해서 두개의 프로세스가 share mode나 share
update mode로 lock을 잡을 수 있다.
enqueue는 OS의 locking mechanism을 이용하여 user가 request한 lock의 mode에
관한 정보를 갖고 있고 OS lock manager는 lock에 걸린 resource를 계속해서
추적한다.
만약 어떤 프로세스가 요구한 lock mode가 현재에 허용될 수 없다면 OS는
requesting process를 wait queue에 넣게 된다. latch와 enqueue와의 또 다른
하나의 차이는 latch에서는 enqueue에서와 같이 ordered queue를 사용하지 않
는다는 것이다. latch 를 기다리는 process들은 timer를 이용하여 일정기간 후
wakeup하여 다시 latch를 잡으려하고 이를 spin이라한다. 모든 waiting
process들이 동시에 retry하게 되므로 누가 먼저 대기하느냐에 관계없이 latch를
잡을 수 있다. 즉 마지막에 request한 process가 제일 처음 latch를 잡을 수도
있다.
[ 언제 latch를 잡으려고 하는가 ]
latch는 어떤 process가 SGA의 일부분에 대해 작업하려고 할때 요구되며 request
종료 시 latch는 release 된다. 다른 process에 의해 잡혀진 latch를 요구하게
되면 그 latch가 release될 때까지 기다린다. 예를 들면 redo allocation
latchs, copy latches, archive control latch 등이 있다. latch에 관련된
기본적인 idea는 shared data structure에 대해 concurrent access를 하지
못하게 하는 것이다. 이러한 간단한 mechanism에 의해 동작 되므로 굉장히 빠르게
수행되며 아주 짧은 시간 동안 latch를 잡게 된다. 만약 latch를 잡고 있는 것이
비정상적으로 종료되면 PMON에 의해 cleanup된다.
[ latch contention의 원인 ]
Latch는 database의 buffer cache 내에 data structure들을 사용하려는 다른
유저로부터 보호한다. 만약 어떤 프로세스가 즉시 latch를 얻을수 없다면
waiting하게 되며 이는 속도의 저하를 가져올 수 있고 latch를 잡을 때까지 CPU
time을 잡아 먹을 수 있다. CPU의 사용은 주로 'spinning'에서 유래된다.
여기서 'spinning'이란 latch를 잡기 위해 일정 기간 동안 waiting 하다가 다시
latch를 잡으려고 시도하는 동작의 계속적인 반복을 말한다.
[ internal latch의 contention을 알수 있는 방법 ]
sql*dba(7.3에서는 svrmgrm) monitor display를 이용하면 latch waits,
requests, contention을 쉽게 볼 수 있다. latch에 관련된 data dictionary는
다음과 같다.
v$latch
v$latchholder
v$latchname
v$latch 테이블의 각 column은 두 개의 다른 latch type에 관한 정보를 가지고
있다. 두 type에 대한 구분은 다음과 같이 구별한다.
1. willing-to-wait willing-to-wait request에 의해 요구된 latch
는 request 당시 사용할 수 없으면 가능할 때까지
waiting한다.
2. immediate immediate request에 의해 요구된 latch는
request 당시 사용할 수 없으면 wait하지 않고
process를 계속 진행한다.
v$latch column 중 willing-to-wait request 관련 column
GETS
MISSES
SLEEPS
v$latch column 중 immediate request 관련 column
IMMEDIATE_GETS
IMMEDIATE_MISSES
- 한국 Oracle -
 |  기업100%환급/오라클/자바/스프링/안드로이드/닷넷C#/웹퍼블리싱…  | 12-27 | 1894 | |
| [채용예정교육]오라클자바개발잘하는신입뽑기2개월과정,교육전취… | 12-11 | 1382 | |
| 53 | [평일주간]100%환급6건,안드로이드,자바,C#,스프링3.2,SQL,힌트/… | 03-15 | 1126 | |
| 52 | [주말주간]C#, ASP.NET마스터 | 01-31 | 1294 | |
| 51 | [평일,기업100%환급]SQL기초에서 Schema Object까지 | 01-31 | 1084 | |
| 50 | [평일야간]HTML5, CSS3,Ajax, jQuery마스터과정 | 01-31 | 986 | |
| 49 | [평일주간,평일야간,주말]Spring,MyBatis,Hibernate개발자과정 | 01-19 | 1294 | |
| 48 | [평일주간,평일야간,주말]안드로이드개발자과정 | 01-11 | 1137 | |
| 47 | [평일야간,주말주간]JAVA,Network&WEB&Framework | 01-03 | 1634 | |
| 46 | 기업100%환급/오라클/자바/스프링/안드로이드/닷넷C#/웹퍼블리싱… | 12-27 | 1894 | |
| 45 | [평일야간,주말]자바기초에서JSP,Ajax,jQuery,Spring3.2,MyBatis… | 12-19 | 1401 | |
| 44 | 웹퍼블리싱 마스터(HTML5,CSS3,jQUERY,AJAX,JavaScript) | 12-14 | 1378 | |
| 43 | [채용예정교육]오라클자바개발잘하는신입뽑기2개월과정,교육전취… | 12-11 | 1382 | |
| 42 | [평일,기업100%환급]자바기초에서 JDBC, Servlet/JSP까지 | 12-09 | 1112 | |
| 41 | [평일야간]닷넷(C#,Network,ADO.NET,ASP.NET)마스터 | 12-01 | 1302 | |
| 40 | [기업100%환급]C#4.0,WinForm,ADO.NET프로그래밍(평일주간(단기)… | 12-01 | 1485 | |
| 39 | [평일야간,주말]SQL기초에서실무까지(SQL기초,PLSQL,힌트,튜닝) | 12-01 | 984 | |
댓글 없음:
댓글 쓰기