ORACLE/ADMIN2009. 3. 19. 14:14
반응형

Remove the following directories from your filesystem:
<ORACLE_HOME>/<hostname_sid>
<ORACLE_HOME>/oc4j/j2ee/OC4J_DBConsole_<hostname>_<sid>

sys로 접속하셔서
SQL> drop user sysman cascade;
SQL> drop role MGMT_USER;
SQL> drop user MGMT_VIEW cascade;
SQL> drop public synonym MGMT_TARGET_BLACKOUTS;
SQL> drop public synonym SETEMVIEWUSERCONTEXT;

emca -config dbcontrol db -repos create
반응형

'ORACLE > ADMIN' 카테고리의 다른 글

as sysdba로 접속시 암호 물어보게 하는 방법  (0) 2009.03.27
index 정보 조회  (1) 2009.03.20
TABLE별 용량을 파악해보자!  (0) 2009.03.13
유용한 DICTIONARY 뷰 ..  (0) 2009.03.06
PCTFREE, PCTUSED  (0) 2009.02.25
Posted by [PineTree]
ORACLE/TUNING2009. 3. 19. 11:03
반응형

☞ SQL Trace


SQL Trace
 
  - SQL Trace는 실행되는 SQL문의 실행통계를 세션별로 모아서 트레이스 파일을 만듭니다.

  - SQL Trace는 세션과 인스턴스 레벨에서 SQL문장들을 분석 할 수 있습니다.

  - SQL Trace에 의해 생성된 파일의 확장자는 .TRC 입니다.

  - .TRC파일은 직접 읽을수가 없으므로 반드시 TKPROF 유틸리티를 실행 시켜야 합니다.

  - init.ora파일에서 SQL Trace를 지정하여 인스턴스 레벨로 Trace를 수행시키면
    전체적인 수행능력이 20~30% 정도 감소합니다.

 


SQL Trace에서 제공하는 정보

  - parse, execute, fetch count
     : 오라클의 SQL 처리 작업에서 parse,execute,fetch 작업들이 처리된 횟수

  - 수행된 CPU 프로세스 시간과 경과(Elapsed)된 질의 시간들
     : SQL문을 실행하는데 소비된 CPU시간과 실질적인 경과시간

  - 물리적(Disk)/논리적(Memory) 읽기를 수행한 횟수
     : 질이의 parse, execute, fetch 부분들에 대해 디스크에 있는 데이터파일들로부터
       읽은 데이터 블록들의 전체 개수

  - 처리된 로우수 : 결과 set을 생성하기 위해 오라클에 의해 처리된 행의 전체 개수

  - 라이브러리 캐쉬 miss : 분석된 문장이 사용되기 위해  라이브러리 캐쉬 안으로 로드되어야 하는 횟수  

 


SQL Trace와 관련된 파라미터

  - TIMED_STATISTICS : RDBMS가 추가적인 CPU시간, 실행시간등을 모을수 있게 합니다.
     → 이 시간통계는 SQL악성 여부를 판단하는 중요한 요소가 됩니다.
     → ALTER SESSION SET TIMED_STATISTICS=TRUE 또는 init.ora파일에 설정
 
  - SQL_TRACE : SQL Trace의 수행여부
     .ALTER SESSION SET sql_trace=TRUE 또는 init.ora파일에 설정
     
  - USER_DUMP_DEST : Trace파일이 생성되는 디렉토리를 지정 합니다.
   
  - MAX_DUMP_FILE_SIZE : 트레이스파일의 최대 크기(단위: OS블럭수)

 


SQL Trace 실행 방법
 
1. ALTER SESSION SET SQL_TRACE=TRUE;
 
2 .EXECUTE DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION(TRUE)
 
3. EXECUTE DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION(session_id, serial_id, TRUE)
 
4. Init parameter 설정: SQL_TRACE = TRUE


-- SQL_TRACE수행
SQL> ALTER SESSION SET SQL_TRACE = TRUE;
명령문이 처리되었습니다.
 

 


☞ TKPROF

TKPROF(trace 파일 출력)


  - TKPROF는 SQL Trace를 통해 생성된 트레이스파일을 분석이 가능한 형식으로 전환하여
     출력 합니다.
 
  Syntax

   TKPROF tracefile  outputfile  [SORT=number] [PRINT = number]
                [EXPLAIN=username/password]


  - tracefile : SQL Trace 의해 생성된 통계정보를 가진 파일명

  - outputfile : TKPROF가 읽기가능한 텍스트 파일로 생성할 파일명

  - sort=option : 지정된 OPION(EXECPU,FCHDSK,PRSCPU)에 ASCENDING 순으로
                      SQL 문을 정렬합니다.
       ex) SORT=EXECPU -> 가장나쁜 Execute CPU값을 가진 통계값을 먼저 출력합니다.

  - print : 지정된 수의 SQL문에 대해서만 TRACE 결과를 PRINT 합니다.

  - explain : SQL문의 EXECUTION PLAN(실행계획) 을 수립하고 저장합니다.

 


◈ TKPROF 실행
 
--SQL TRACE 파일 위치의 파악
SVRMGR> SHOW PARAMETER USER_DUMP_DEST;
NAME             TYPE     VALUE
---------------- -------- -----------------------------
user_dump_dest   string   C:\oracle\admin\oracle\udump
 

-- TKPROF실행
C:\>TKPROF C:\Oracle\admin\oracle\udump\oracle_ora_1584.trc storm.txt
        EXPLAIN=storm/storm
 
 
 - 생성된 storm.txt파일의 내용 
 - 실행된 SQL문과 분석정보, 실행계획등이 생성되어 있습니다.
********************************************************************************
 
SELECT a.day, SUM(a.counter), ROUND(SUM(a.counter)/b.tot, 2)*200 rate, b.tot
FROM storm_menu_counter a,
        (SELECT max(aa.counter) tot
          FROM
            (SELECT SUM(counter) counter
              FROM storm_menu_counter
              WHERE year = 2001
                   AND month= 7
              GROUP BY day)aa)b
 WHERE a.year = 2001
      AND a.month = 7
GROUP BY day , b.tot
ORDER BY day
 

call     count    cpu  elapsed  disk  query  current   rows
------- ------  ----- -------- ----- ------ --------  -----
Parse        1    0.01     0.04     1      1        0      0
Execute     1    0.00     0.00     0      0        0      0
Fetch        3    0.00     0.01    55    116       0     23
------- ------  ----- -------- ----- ------ --------  -----
total          5    0.01     0.06    56    117        0     23
 
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 65  (STORM)
 
Rows     Execution Plan
-------  ---------------------------------------------------
      0  SELECT STATEMENT   GOAL: CHOOSE
      0   SORT (GROUP BY)
      0    NESTED LOOPS
      0     VIEW
      0      SORT (AGGREGATE)
      0       VIEW
      0        SORT (GROUP BY)
      0         TABLE ACCESS (FULL) OF ’STORM_MENU_COUNTER’
      0     TABLE ACCESS (FULL) OF ’STORM_MENU_COUNTER’
      
******************************************************************************** 

 

TKPROF 결과값

로우/컬럼

설  명

Parse

 SQL문이 파싱되는 단계에 대한 통계.
 새로 파싱을 했거나 Shared SQL Pool에서 찾아 온 것도 같이 포함 됩니다.

Execute

 SQL문의 실행 단계에 대한 통계.
 Update, Insert, Delete문장들은 여기에 수행한 결과만 나옵니다.

Fetch

 SQL문이 실행되면서 페치된 통계.

count

 SQL문이 파싱/실행/페치가 수행된 횟수

cpu

 parse, execute, fetch가 실제로 사용한 CPU시간(1/100초 단위)

elapsed

 작업의 시작에서 종료시까지 실제 소요된 시간

 disk

 디스크에서 읽혀진 데이터 블럭의 수

 query

 메모리내에서 변경되지 않은 블럭을 읽거나 다른 세션에 의해 변경되었으나
 아직 커밋되지 않아 복사해 둔 스냅샷 블럭을 읽은 블럭 수
 SELECT문에서는 거의가 여기에 해당하며 Update,Insert,Delete작업시에는
 소량만 발생 합니다.

 current

 현 세선에서 작업한 내용을 커밋하지 않아 오로지 자신에게만 유효한
 블럭(Dirty Block)을 액세스한 블럭 수
 주로 Update, Insert, Delete작업시 많이 발생 합니다.

 rows

 SQL문을 수행한 결과에 의해 최종적으로 액세스된 로우의 수
 (서브쿼리에서 추출된 로우는 제외됩니다.)



대용량 데이터베이스 솔루션 1 참고

  ================================================
    * 데이터베이스 정보공유 커뮤니티 oracleclub.com
    * 강좌 작성자 : 김정식 (oramaster _at_ naver.com)
  ================================================
반응형
Posted by [PineTree]
ORACLE/INSTALL2009. 3. 18. 17:21
반응형

오라클 완전삭제 왜 할까요?  오라클이 싫어서?  아니죠.

 

1. 서비스기동중지 oracle과 관련된 서비스가 기동되어 있으면 전부 중지 시킨다.
2. universal installer 를 이용하여 오라클 삭제
3. registry 에서 오라클과 관련된 키를 삭제한다.
  HKEY_CURRENT_USER->Software->Oracle
  HKEY_LOCAL_MACHINE->Software->Oracle
  HKEY_LOCAL_MACHINE->SYSTEM->CurrentControlSet->Services 밑의 오라클 관련 키
  HKEY_CURRENT_CONFIG->System->CurrentControlSet->SERVICES 밑의 오라클 관련 키
4. 디렉토리삭제
  C:\Program Files\Oracle
  D:\oracle
5. 시작->프로그램->Oracle관련 메뉴 삭제

<< Windows 95/98 >>


1. 시작-> 실행-> regedit을 기동하여
   HKEY_LOCAL_MACHINESOFTWAREORACLE folder 전체를 삭제한다.
2. HKEY_LOCAL_MACHINESOFTWAREodbc를 삭제한다.
3. autoexec.bat file에서 %ORACLE_HOME%bin과 JRE path를 remove한다.
4. windows 탐색기에서 Oracle directory를 삭제한다.
5. <system_drive>: Program FilesOracle folder를 삭제한다.
6. 이전에 설치한 HOME name인 <HOME>을 다음에서 찾아보고 Icon을 삭제한다.
   <system_drive>: windowsStart MenuProgramsOracle-<HOME> 과
   <system_drive>: windowsStart MenuProgramsOracle Installation Products
7. 시스템을 재기동시킨다.

 

 

<< Windows NT >>


1. Administrator 권한으로 NT를 log on 한다 .
2. 시작-> 실행-> regedit을 기동하여
   HKEY_LOCAL_MACHINESOFTWAREORACLE 폴더 전체를 삭제한다.
3. HKEY_LOCAL_MACHINESOFTWAREodbc 를 삭제한다.
4. HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServices 에서 oracle로 시작되는 폴더들을 삭제한다.
5. HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesEventLog Application 에서 oracle로 시작되는
폴더들을 삭제한다.
6. regedit을 종료한다.
7. 설정-> 제어판 -> 시스템을 실행하여 환경 tab에서
8. autoexec.bat 화일에서 %ORACLE_HOME%bin과 JRE path를 remove한다.
9. <system_drive>: WinntProfilesAll Users시작메뉴ProgramsOracle 폴더를 삭제한다.
10. <system_drive>: Program FilesOracle 폴더를 삭제한다.
11. 시스템을 재기동시킨다.
12. Oracle Home directory를 삭제한다.
    (HKEY_LOCAL_MACHINESOFTWAREORACLEORACLE_HOME 에서 확인 가능).

* CWI32.DLL 파일 삭제가 안될경우에는 재부팅시 F8 누르고 안전모드로 부팅해서 삭제하면 된다.

 

<< Linux >>


1. 시디를 넣고 GUI 화면이 뜨면 언인스톨 버튼이 나온다.
2. 언인스톨 버튼을 클릭하여 인스톨된 오라클을 삭제한다.
3. /etc/ 디렉토리로 이동한다.
4. ls -al ora* 로 오라클 관련 파일을 확인한다.
5. 확인된 파일 oraInst.loc, oratab 파일을 삭제한다.
6. /usr/local/bin 디렉토리로 이동한다.
7. 오라클 관련 파일이 있을것이다. 삭제한다.

 

* 시디를 넣고 하지않고 삭제하는 방법은 설치된 오라클 디렉토리를 과감하게 삭제하면된다.
물론 3,4,5번은 행해져야한다.


반응형

'ORACLE > INSTALL' 카테고리의 다른 글

LINUX ORALCE 10G설치  (0) 2009.08.04
solaris10 oracle install 9i 설정값  (0) 2009.05.27
CentOS 5.2에 Oracle 9i 설치하기  (0) 2009.02.23
HP-UX 11.11(64bit)에 Oracle 9.2.0.1 설치하기  (0) 2009.01.21
Linux에서 Pro C 설치  (0) 2008.12.11
Posted by [PineTree]
ORACLE/ADMIN2009. 3. 13. 16:24
반응형
딕셔너리뷰에서
USER_SEGMENTS 에서 확인할수 있습니다.

SELECT SEGMENT_NAME, BYTES FROM USER_SEGMENTS where SEGMENT_TYPE=''TABLE''
에서 점유용량을 확인할수 있습니다.

//////////////////////////////////////////////////////////////////////////////////

위 delri님의 방법은 해당 Table에 할당되어 있는 크기를 측정하는 방법이며
만일 Table에 공간 할당은 되었으나 아직 (전혀)사용되지 않은 공간을 제외한 실
제 사용되고 있는
공간을 확인하실려면(즉 HWM 아래 공간)...

1. 해당 table을 analyze 해서

analyze table t_name compute statistics;

2. 해당 table의 blocks를 구한다.

select blocks from dba_tables where table_name =''T_NAME'';

==> blocks +1(segment header block) 이 해당 table이 사용중인 db block 갯수


위 계산에서 물론 사용된 후 delete에 의해 현재 완전히 비어 있는 block도 사용
고 있는 block으로 인식
하므로 완전히 비어 있는 block을 제거하기 위해서는
oracle8 이상인 경우 rowid는 아래처럼 구성되어 있기때문에

object fil block row
------ --- ------ ---
AAABPW AAF AAAAv1 AAA

1. select count(*)
from (select substr(rowid,1,15) from test group by substr(rowid,1,15) );
하면..HWM아래 할당은 되었지만 완전히 비어 있는 block을 빼고 조금이라도 사
용된 block의 갯수만 구함





예제)

1* analyze table costs compute statistics
SQL> /

Table analyzed.

SQL> select blocks from user_tables where table_name=''COSTS'';

BLOCKS
----------
2924 <---HWM 아래 block갯수


1 select count(*)
2 from
3* (select substr(rowid,1,15) from costs group by substr(rowid,1,15))
SQL> /

COUNT(*)
----------
2506 <---HWM 아래 block중 사용중인 block갯수

** 정리하면

Table의 공간(크기)이란 아래 3가지 관점에서 값이 다를수 있습니다.

1. 해당 Table에 할당된 크기
-Table에 할당되었지만 사용중 또는 미사용공간 전부 포함

2. HWM 아래 크기
- 할당된 공간중에서 full table scan시 검색하는 부분까지만의 크기
- 즉 HWM이후 공간은 아직 한번도 사용이 안된 new Block임.

3. HWM 아래중 완전히 비어 있는 block을 제외한 크기
- delete에 의해 block전체가 비어 있는 block을 제외한 크기

//////////////////////////////////////////////////////////////////////////////////

위의 HUMAN21님말대로 USER_SEGMENTS 의 BYTES는 실데이타 공간이 아니라 할당영
역을 나타냅니다.. 빈 블럭도 포함이 되는거죠..
만일 UNUSED 블럭을 제외한 실제 데이타 공간을 구하려면..아래와 같
이 구하시면 될것 같네요

select table_name, GREATEST(4, ceil(num_rows /
((round(((8192 - (ini_trans * 23)) *
((100 - pct_used) /100)) / avg_row_len)))) *
8192)/1024/1024
TableSize_Mbytes
from user_tables


위에서 8192 는 SHOW PARAMETER 의 DB_BLOCK_SIZE 입니다.
위의 문을 정확히 하기위해서는 ANALYZE TABLE은 꼭 해주셔야지 정확한 값이 구해지겠죠..


펌질한곳 : http://otn.oracle.co.kr/forum/forum_open_view.jsp?forum_seqno=20040907205724&forum_cate=ORCL
반응형

'ORACLE > ADMIN' 카테고리의 다른 글

index 정보 조회  (1) 2009.03.20
em 삭제하고 재 설치  (0) 2009.03.19
유용한 DICTIONARY 뷰 ..  (0) 2009.03.06
PCTFREE, PCTUSED  (0) 2009.02.25
oracle em 구성  (0) 2009.02.12
Posted by [PineTree]
ORACLE/OWI2009. 3. 9. 10:08
반응형

OracleRDBMS에선 여러가지 Lock 메커니즘을 사용하고 있다.

주로 다음과 같은 것들이 있다.

 

 ・Latch
 ・엔큐

 ・분산 Lock

 ・글로벌 Lock (OPS/RAC)

 

이 문서에서는 이것들 중에서도 Latch에 중점을 두고 기술합니다.

OracleRDBMS에 있어서 Latch의 실상과 Latch경합의 원인에 대해 설명함으로써 각각의 경합의 튜닝을 할수 있습니다.

 

1. Latch란???

 

Latch란 SGA안에 공유 데이터 구성을 보호하는 저레벨의 직렬화 메커니즘이다. Latch의 실상은 플랫폼에 따라 다르다. Latch은 획득 및 해방이 단시간의 행해지는 종류의 락입니다. Latch는 통상 복수의 프로세스가 같은 처리를 동시에 실행 하는 일을 방지하기 위해서 사용됩니다. Latch를 보관 유지하고 있는 프로세스가 이상종료(ABEND)했을 경우 각 Latch 관련된 크린업 프로시져에 의해 해방된다. Latch에는 데드락이 발생하지 않게 하기 위한 레벨이 관련되어 있습니다. 프로세스가 어떤 레벨의 Latch을 획득하면 그것을 보관한 상태로 그 이하 레벨의 Latch를 요구할 수가 없습니다.

 

2. Latch와 엔큐

 

엔큐는 Latch와는 다른 락  메카니즘입니다. 엔큐는 동시에 복수의 프로세스가 여러가지 방법으로 자원을 공유하는 일을 가능하게 합니다. Latch와 비교해 정교한 메카니즘입니다. 엔큐의 대표적인 예는 테이블에 대한 락입니다. 1개의 테이블에 대해 복수의 프로세스가 공유 모드나 공유행 배타 모드등에서 동시에 락을 획득할 수 있습니다. 엔큐를 요구했을 때 요구하는 락 모드가 이미 그 자원에 대해서 다른 세션이 취득하고 있는 락 모드와 호환성이 없는 경우 나중에 락을 요구한 프로세스는 대기 하게 됩니다만, 그 경우는 FIFO(First-In-First-Out)의 큐 대기라 합니다.

 

Oracle8i까지의 버젼에서는 대부분의 Latch에 대해 획득을 대기할 때에 대기하는 프로세스가 어떤 간격으로 sleeve와 리트라이를 반복하는 구조로 되어 있었습니다. 복수의 프로세스가 같은 Latch를 대기하고 있는 경우 해방 후에 최초로 리트라이를 한 프로세스에 획득이 허가되므로 엔큐와 같이  FIFO로의 획득은 보증되지 않습니다.

Oracle9i 이후의 버젼에서는 대부분의 Latch가 큐를 사용한 대기를 실시하도록 변경되었기 때문에 엔큐와 같게 FIFO로의 획득이 보증됩니다. 다만 각 버젼 모두 일부의 Latch로 예외적인 대기 방법을 취하는 경우가 있습니다.

 

3. Latch을 획득할 필요가 있는 케이스

 

SGA내의 자원을 사용할 때 프로세스는 Latch를 획득해 자원을 사용하는 동안은 Latch를 계속 보관 유지해 자원의 사용을 끝내면 Latch은 해방됩니다. 각 Latch은 Latch명에 의해 식별되어 각각이 다른 자원을 보호합니다. Latch의 조작은"test and set"등의 atomic인 명령으로 실시합니다. 다른 프로세스가 획득한 Latch에 의해 보호되는 코드를 실행하기 위해서는 그 Latch이 해방될 때까지 대기할 필요가 있습니다. 예를 들면, redo allocation, redo copy, archive control등의 Latch에 의해서 로그·버퍼나 어카이브(archive)처등의 공유되는 데이터 구조에의 동시 액세스를 막을 수 있습니다.


Latch의 획득이나 해방이 atomic인 명령으로 행해지기 때문에 1개의 프로세스만이 Latch을 획득 하는 것이 보증되어 획득/해방도 고속으로 실행됩니다. Latch을 획득하고 있는 프로세스가 이상종료(ABEND) 했을 경우 PMON에 의해 Latch은 클린 업 됩니다.

 

4. Latch의 대기 방법

 

Latch의 요구는 willing-to-wait 와 no wait 의 2개의 모드로 행해집니다. 통상은 willing-to-wait 모드로 요구되어 Latch을 획득할 수 있을 때까지 대기합니다. no wait 모드는 다수 있는 Latch의 하나를 획득할 수 있으면 되는 경우 등에 행해져  획득할 수 없는 경우는 다른 Latch이 요구됩니다.

 

Oracle8i까지의 버젼에서는 willing-to-wait로 요구한 Latch이 이미 다른 프로세스에 의해 획득되고 있었을 경우 복수 CPU 환경에 있어서는 나중에 Latch을  요구한 프로세스는 CPU를 획득한 채로 내부적으로 설정되어 있는 최대 회수까지 리트라이를 반복합니다.이 리트라이의 처리를 스핀이라고 부릅니다. 최대 회수 까지 스핀을 반복해도 Latch을 획득할 수 없는 경우 프로세스는 CPU를 해방해 sleeve 합니다. 최초의 sleeve 시간은 100분의 1초로 시간이 되면 다시 CPU를 획득해 Latch 획득을 리트라이 합니다(여기에서도 복수 CPU 환경에서는 스핀을 실시합니다).획득할 수 없으면 다시 sleeve 합니다만, sleeve 시간은  1회마다 배로 증가해 갈 것입니다.스핀을 실시하는 것으로 CPU에 부하가 걸립니다만, 복수 CPU 환경인 프로세스가 스핀중에 다른 CPU를 사용해 Latch 해방을 할 가능성이 있으므로 이러한 처리를 합니다.


Oracle9i 이후의 버젼에서는 Latch 의 대기 방법이 변경되었습니다. willing-to-wait로 요구한 Latch 이 이미 다른 프로세스에 의해 획득되고 있는 경우 복수 CPU 환경에 있어 스핀의 처리를 실시하는 점은 같습니다만, 스핀으로 획득할 수 없는 경우는 그 Latch의 대기 리스트에 그 프로세스의 정보를 추가해 sleeve 합니다. Latch이 해방되면 대기 리스트의 선두 프로세스에 통지가 행해지게 되어 있습니다.

 

5.Latch의 경합을 확인하는 방법

 

Latch 경합의 상황은 V$LATCH 및 V$LATCH_CHILDREN로 파악할 수 있습니다. V$LATCH의 행은 Latch명 마다의 각종 통계 정보의 값이 됩니다. Latch안에는 같은 이름을 가지는 Latch가 복수 존재하는「부모와 자식 Latch」이라고 불리는 타입의 것이 있습니다. V$LATCH에서는 그러한 통계 정보의 합계가 표시됩니다만, V$LATCH_CHILDREN에는 각 자식 Latch 마다의 통계 정보가 표시됩니다.

 

V$LATCH / V$LATCH_CHILDREN 의 주된 예 (*1) 
  

 GETS  willing-to-wait 모드의 요구로 획득한 회수
 MISSES  willing-to-wait 모드의 요구로 획득을 시도하고 1번째의 획득에 실패한 회수
 SPIN_GETS  willing-to-wait 모드의 요구로 획득을 시도하고 1번째의 획득에 실패한 후 sleeve 하지 않고 스핀만으로 획득할 수 있던 회수   
 SLEEP1  willing-to-wait 모드의 요구로 획득을 시도하고 1번째의 획득에 실패한 후 1회 sleeve 해 획득할 수 있던 회수
 SLEEP2  willing-to-wait 모드의 요구로 획득을 시도하고 1번째의 획득에 실패한 후 2회 sleeve 해 획득할 수 있던 회수
 SLEEP3  willing-to-wait 모드의 요구로 획득을 시도하고 1번째의 획득에 실패한 후 3회 sleeve 해 획득할 수 있던 회수
 SLEEPS   willing-to-wait 모드의 요구로 획득을 시도하고 1번째의 획득에 실패한 후 sleeve 한 회수의 합계
 WAITERS_WOKEN  Latch 해방시에 대기하고 있는 프로세스에 통지한 회수
 WAIT_TIME  (9.0-) Latch 획득까지의 대기 시간의 합계
 IMMEDIATE_GETS  no wait 모드의 요구로 획득한 회수
 IMMEDIATE_MISSES  no wait 모드의 요구로 획득에 실패한 회수

 

※ SLEEP4 - SLEEP11는 사용되고 있지 않습니다.

 

(*1): 릴리스 9.0.1까지의 「데이타베이스·레퍼런스」에서는 GETS/MISSES가 「대기가 되었다」의 요구, IMMEDIATE_GETS/IMMEDIATE_MISSES가 「대기 없음」의 요구라고 기재되어 있습니다만  기술 미스입니다.

 

릴리스 9.2이후는 GETS가 「대기 가능 모드로 요구된 회수」라고 기재되어 있습니다. 대기 가능    (willing-to-wait) 모드에서는 획득할 수 있을 때까지 대기하므로, 요구 회수와 획득 회수는 최종적으로는 동일해집니다만 GETS가 카운트 되는 것은 대기 가능 모드로 요구해 획득된 시점이므로, 이 문서의 기술이 엄밀한 의미에서는 올바릅니다.

 

Latch 히트율의 계산방법


Latch 히트율(1번째의 획득 시행으로 획득할 수 있던 비율)은 다음의 식에서 계산할 수 있습니다.

 

willing-to-wait 모드의 히트율 : (GETS - MISSES) /GETS
no wait 모드의 히트율     : IMMEDIATE_GETS/(IMMEDIATE_GETS + MMEDIATE_MISSES)

 

V$LATCH / V$LATCH_CHILDREN 에 의한 Latch 경합의 파악 


Oracle8i까지의 버젼에서는 willing-to-wait 모드로 요구해 대기하는 경우 각 프로세스가 sleeve    와 리트라이를 반복하기 때문에 sleeve 회수의 합계인 SLEEPS나, SPIN_GETS/SLEEP1/SLEEP2/SLEEP3의 값의 분포가 경합의 상황을 파악하는데 도움이 됩니다. 단 shared pool, library cache, library cache load lock의 3 종류의 Latch에 대해서는 Oracle9i 이후같은 큐를 사용한 대기 방법을 취하므로 WAITERS_WOKEN를 경합의 지표로 합니다.

 

Oracle9i 이후의 버젼에서는 큐를 사용한 대기를 하므로, sleeve의 합계 회수만으로는 경합의 상황을 파악하기에 불충분합니다. 대기 시간을 나타낸  WAIT_TIME열이 추가되었으므로 이것을 지표로 합니다.

 


반응형

'ORACLE > OWI' 카테고리의 다른 글

Oracle Wait Event 모니터링  (0) 2009.12.02
OWI를 활용한 shared pool 진단 및 튜닝  (0) 2009.06.30
Oracle에서 Latch 가 성능 저하의 원인이 아닙니다  (0) 2009.03.01
Enqueue 와 Latch  (0) 2009.03.01
Direct path read  (0) 2009.02.08
Posted by [PineTree]
ORACLE/ADMIN2009. 3. 6. 14:03
반응형

DICTIONARY(DICT) 뷰

 - 데이터 사전 및 동적 성능 뷰에 대한 정보를 알고 싶으면 DICTIONARY 뷰나
    DICT_COLUMNS 뷰를 조회하면 됩니다.

 - 조회 할 수 있는 모든 데이터사전의 테이블이름과 설명을 조회 할 수 있습니다.
   물론 설명은 영문으로 되어 있습니다.

 - 동의어인 DICT를 이용해서도 똑같은 정보를 조회 할 수 있습니다.

SQL> SELECT * FROM DICTIONARY WHERE table_name LIKE ’%INDEX%’;

SQL> SELECT * FROM DICT WHERE table_name LIKE ’%INDEX%’;


DICT_COLUMNS 뷰

 - 뷰를 질의하면 해당 데이터사전의 컬럼에대한 정보를 조회 할 수 있습니다.

SQL> SELECT * FROM DICT_COLUMNS WHERE TABLE_NAME LIKE ’%INDEX%’;


데이터사전 조회 예제 1)

SQL>SELECT * FROM dict
        WHERE table_name LIKE UPPER(’%&데이타사전%’);


데이터사전 조회 예제 2)

SET LINESIZE 160
SET PAGESIZE 100
COLUMN TABLE_NAME FORMAT A25
COLUMN COLUMN_NAME FORMAT A30
COLUMN COMMENTS FORMAT A80 word_wrapped
 
SELECT *
FROM dict_columns
WHERE table_name LIKE UPPER(’%&데이터사전%’);

 

◈ 아래 데이터사전 정보는 인터넷 정보를 참고했습니다.

* 오브젝트: USER_OBJECTS(OBJ)
   모든 오브젝트에 대한 정보를 지원
   오즈젝트 유형, 작성시간, 오브젝트에 사용된 최종 DDL 명령, alter, grant 및 revoke 등


* 테이블 : USER_TABLES (TABS)   테이블에 대한 정보


* 열 : USER_TAB_COLUMNS (COLS)   컬럼에 대한 정보


* 뷰 : USER_VIEWS   뷰에 대한 정보


* 동의어 : USER_SYNONYMS (SYN)


* 시퀀스 : USER_SEQUENCES (SEQ)


* 제약조건 : USER_CONSTARINTS


* 제약조건열 :  USER_CONS_COLUMNS ( 제약 조건을 가진 열에 대한 정보)


* 제약조건의 예외사항 : EXCEPTIONS  제약조건을 활성화시 에러사항에 대한 정보


* 테이블 주석 : USER_TAB_COMMENTS  테이블/뷰에 대한 주석


* 열 주석 : USER_COL_COMMENTS ( 열에 대한 주석)


* 인덱스 : USER_INDEXES (IND) ( 인덱스에 관한 정보)


* 인덱스 열 : USER_IND_COLUMNS  인덱스열에 대한 정보


* 클러스터 : USER_CLUSTERS (CLU)  클러스터와 관련된 정보


* 데이터베이스 링크 : USER_DB_LINKS  링크에 관련된 정보


* 스냅샷 : USER_SNAPSHOTS


* 스냅샷 로그 : USER_SNAPSHOT_LOGS


* 트리거 : USER_TRIGGERS


* 프로시저, 함수 및 패키지 : USER_SOURCE


* 코드 오류 : USER_ERRORS


* 테이블스페이스 : USER_TABLESPACES


* 영역 할당량 : USER_TS_QUOTAS
   테이블스레이스 단위로 사용자가 이용할 수 있는 영역의 최대크기와
   할당된 영역의 크기 파악에 대한 정보


* 세그먼트와 익스텐트 : USER_SEGMENTS 와 USER_EXTENTS


* 여유 영역 : USER_FREE_SPACE   현재 여유로 표시된 영역이 얼마인지에 대한 정보


* 사용자 : USER_USERS


* 자원 제한량 : USER_RESOURCE_LIMITS


* 테이블 권한 : USER_TAB_PRIVS


* 열 권한 : USER_COL_PRIVS


* 시스템 권한 : USER_SYS_PRIVS


* 사용자 본인 권한 USER_ROLE_PRIVS


  ================================================
    * 오라클 정보공유 커뮤니티 oracleclub.com
    * http://www.oracleclub.com
    * http://www.oramaster.net
    * 강좌 작성자 : 김정식 (oramaster _at_ naver.com)
  ================================================
반응형

'ORACLE > ADMIN' 카테고리의 다른 글

em 삭제하고 재 설치  (0) 2009.03.19
TABLE별 용량을 파악해보자!  (0) 2009.03.13
PCTFREE, PCTUSED  (0) 2009.02.25
oracle em 구성  (0) 2009.02.12
INSERT /*+ APPEND */ VS CTAS  (0) 2009.02.06
Posted by [PineTree]
ORACLE/TroubleShooting2009. 3. 3. 15:04
반응형

Applies to:

Oracle Server - Enterprise Edition - Version: 10.1.0.5 to 10.2.0.4
This problem can occur on any platform.

Symptoms

Database can crash many times if Automatic Shared Memory Management (ASMM) is used.

Database crashes many times with the following messages from alert_log:-

Tue Oct 28 13:20:35 2008
Errors in file /ora/product/10.2.0prd/admin/oradwprd/bdump/oradwprd_cjq0_1990.trc:
Tue Oct 28 13:22:03 2008
System State dumped to trace file
Tue Oct 28 13:41:45 2008
MMNL absent for 1310 secs; Foregrounds taking over
Tue Oct 28 13:41:52 2008
MMNL absent for 1256 secs; Foregrounds taking over
MMNL absent for 1256 secs; Foregrounds taking over
MMNL absent for 1256 secs; Foregrounds taking over
Tue Oct 28 14:25:28 2008
...
Tue Oct 28 20:16:50 2008
ksvcreate: Process(m000) creation failed
Tue Oct 28 20:21:32 2008
MMNL absent for 1311 secs; Foregrounds taking over
Tue Oct 28 20:45:05 2008

The AWR report during the time the crash happens shows the following:-

Cache Sizes
~~~~~~~~~~~ Begin End
---------- ----------
Buffer Cache: 1,280M 1,568M Std Block Size: 8K
Shared Pool Size: 720M 432M Log Buffer: 15,148K

Load Profile
~~~~~~~~~~~~ Per Second Per Transaction
--------------- ---------------
Redo size: 1,031.15 6,487.12
Logical reads: 15,843.66 99,674.56
Block changes: 3.61 22.70
Physical reads: 1,975.69 12,429.32
Physical writes: 454.90 2,861.83
User calls: 53.04 333.65
Parses: 2.14 13.45
Hard parses: 0.44 2.79
Sorts: 1.91 12.00
Logons: 0.03 0.18
Executes: 3.74 23.55
Transactions: 0.16

% Blocks changed per Read: 0.02 Recursive Call %: 43.94
Rollback per transaction %: 7.99 Rows per Sort: ########

Instance Efficiency Percentages (Target 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 97.12 Redo NoWait %: 100.00
Buffer Hit %: 94.80 In-memory Sort %: 99.10
Library Hit %: 84.79 Soft Parse %: 79.23
Execute to Parse %: 42.89 Latch Hit %: 95.30
Parse CPU to Parse Elapsd %: 10.35 % Non-Parse CPU: 62.73

Shared Pool Statistics Begin End
------ ------
Memory Usage %: 14.69 25.80
% SQL with executions>1: 83.47 43.38
% Memory for SQL w/exec>1: 69.04 43.09

Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) Time Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
latch: library cache 125 14,869 ###### 33.3 Concurrenc
latch: shared pool 553 13,177 23828 29.5 Concurrenc
read by other session 1,653,348 8,455 5 18.9 User I/O
CPU time 4,353 9.7
db file sequential read 841,956 3,000 4 6.7 User I/O

Cause

Huge contention for shared pool and library cache latches are seen from AWR report during the problem period.

Also the shared pool size is getting shrinked during the problem as evident from AWR.

This is because of dynamic memory allocation with in SGA.

As Automatic SGA is used, the repeated shrink / growth in the shared pool and buffer cache would happen and that could cause lot of waits in sessions.

Because of Auto SGA, the shared pool is shrinked during the problem and thats why the contention is seen across the shared pool which caused the database crash.

From the systemstate dumps it is shown Location from where latch is held:  ksucrp:
The function is used to Create and initialise a process.
The process cannot be initialized due to lack of memory.

All the messages seen in alert log are the indication of lack of memory available in shared pool.

Bug 6528336 seems to have caused the problem.

Solution

To disable Auto SGA.

sga_target=0

Configure memory components separately for shared pool and buffer cache.

shared_pool_size=<value>M

db_cache_size=<value>M

반응형
Posted by [PineTree]
ORACLE/TUNING2009. 3. 3. 13:57
반응형

원본 출처 http://www.oracleclub.com/article/23893

[ 출처 ]
1. 10g Optimizer개념 및 통계치 생성 방법,SQL Tuning 방법
http://www.dbguide.net/club/board/download.jsp?maskname=274&fileName=10g+Optimizer+to+public.pdf

2.  10g 자동화 통계정보 수집에 관하여... [2008/05/11 Update]
http://blog.naver.com/sungeunn/120051268815

3.  어떤 STATISTICS_LEVEL 을 사용할 것인가 ?
http://cafe.naver.com/prodba/9293

4. 메타링크
  4.1 Two types of automatic statistics collected in 10g [ 559029.1  ]
  4.2 How to Disable Automatic Statistics Collection in 10G ? [ 311836.1 ]
5. 10G References [ STATISTICS_LEVEL ]
  http://download.oracle.com/docs/cd/B19306_01/server.102/b14237/initparams211.htm#REFRN10214

 [ 결론 ]
1. System 통계정보는 따로 생성 하지 않는다.
    어느 시간이 최적인지 모른다. DBA 가 알수 있으면 정기적으로 생성해서 활용한다.
2. 자동 통계정보 수집(CBO) 는 disable 하고, 수동으로 통계정보를 생성한다.
   운영 중에 통계정보 생성으로 인해 업무의 성능 저하를 사전에 예방하자.
3. STATISTICS_LEVEL = TYPICAL 로 유지 하자

4. 자동 통계정보 수집 대상은 User Objects,  Sys/System Object 가 대상이다.

  
[ 요약 ]

  대상  설명   TATISTICS_LEVEL=BASIC  STATISTICS_LEVEL=TYPICAL
 System Statistics  System 성능 ( CPU, DISK )    
 Fixed Objects Statistics  DBMS 성능 ( X$, V$)    
 Dictionary Statistics  SYS/SYSTEM USER TABLE  자동 수집되지 않는다.  자동 수집된다.
 User Table Statistics
 일반 유저 TABLE  자동 수집되지 않는다  자동 수집된다.
 

통계정보의 종류
: 크게 4가지로 구분할 수 있다.
[ 1.System Statistics ]
: 개요 - System Statistics 는 System Hardware 의 I/O, CPU 의 특성을 분석하여
         Optimizer 가 CPU Costing 을 계산할 때 사용하는 정보로써,
         이를 기반으로 Optimizer 가 임의의 SQL에 대한 실행 계획을 수립할 때
         이를 기반으로 계산하게 된다.
  수행주기 - 초기 1회
             시스템 자원의 변경이 생겼을 경우 ( Memory, CPU, I/O 등 )
  9i - 처음 소개된 개념이고, DBA가 수동으로 수집 하지 않으면 기본적으로
       존재하지 않는 정보이다. 기본적으로 I/O Model로 비용산정
       System Statistics 정보가 있으면 Optimizer 가 비용 산정을 CPU Model 로 하고,
       System Statistics 정보가 없다면 Optimizer 가 비용 산정을 I/O Model 로 한다.
  10G - System Statistics 정보를 수집 하지 않는다면 Noworkload System Statistics 가
       사용된다. 10G 에서는 Optimizer 가 비용 산정을 CPU Model 로 한다. [ Default ]
       [ CPUSPEEDNW, IOSEEKTIM, IOTFRSPEED 로 구성된다. ]
       수동으로 System Statistics 수집 시에는 Workload System Statistics 라고 한다.
       결론적으로 운영 시스템의 최적의 System Statistics 를 생성하여, 적절히
       적용 하여 사용하는 것이 최선이나, 보통은 NoWorkload System Statistics 를
       그대로 사용한다.
 주의사항 :
RAC 에서 NODE 가 서로 같은 시스템 사양을 같지 않을 경우에는
       System Statistics 를 Node 별로 나누어 관리 되지 않으므로 전체 System 의
       대표성을 가지는 Node 에서 수행을 한다.
       특히 위와 같은 결정을 하기 위해서는, 각각의 Node 별로 통계치를 생성해
       보고 비교해 본 후에 결정할 수 있다.
       노드의 사양이 동일한 경우 가장 일반적인 Node 에서 수행한다.  

실습
: 시스템 통계정보는 Optimizer 가 실행 계획 세움에 있어서 지대한 영향을
  미치므로, 항상 기존의 시스템 통계자료를 백업 후 진행 하자.
  OLTP 와 OLAP 성 통계정보를 생성하고, IMPORT 해보자

 
-- 1. 시스템 통계정보 확인
SELECT * FROM SYS.AUX_STATS$ ;
SNAME                          PNAME                    PVAL1 PVAL2
------------------------------ -------------------- --------- ------------------------------
SYSSTATS_INFO                  STATUS                         COMPLETED
SYSSTATS_INFO                  DSTART                         02-13-2009 13:33
SYSSTATS_INFO                  DSTOP                          02-13-2009 13:33
SYSSTATS_INFO                  FLAGS                        0
SYSSTATS_MAIN                  CPUSPEEDNW                1489
SYSSTATS_MAIN                  IOSEEKTIM                   10
SYSSTATS_MAIN                  IOTFRSPEED                4096
SYSSTATS_MAIN                  SREADTIM
SYSSTATS_MAIN                  MREADTIM
SYSSTATS_MAIN                  CPUSPEED
SYSSTATS_MAIN                  MBRC
SYSSTATS_MAIN                  MAXTHR
SYSSTATS_MAIN                  SLAVETHR

13 rows selected.

-- 2. 기존 통계정보 백업 받을 테이블 생성
SQL> execute DBMS_STATS.CREATE_STAT_TABLE(’SYS’,’ORIGIN’,’USERS’);
PL/SQL procedure successfully completed.
-- 기존 통계정보 백업
SQL> execute DBMS_STATS.EXPORT_SYSTEM_STATS(stattab =>’ORIGIN’, STATID =>’ORIGIN’,STATOWN =>’SYS
PL/SQL procedure successfully completed.
-- 백업 받은 시스템 통계정보 데이타 확인
SQL> SELECT STATID, C1, C2, C3 FROM ORIGIN ;
--  C1 = COMPLETED     --> 수집 완료


-- 3. 시스템 통계정보 수집
-- 사전에 JOB PROCESS 확인 ( 1보다 커야 한다.)
SQL> show parameters job_queue

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
job_queue_processes                  integer     0
SQL> alter system set job_queue_processes = 5 ;
System altered.

SQL> show parameters job_queue
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
job_queue_processes                  integer     5

 

-- 4.  OLTP 성 시스템 통계정보 수집하기
-- OTLP용 시스템 통계정보 생성을 위한 통계정보 테이블 생성
-- OWNER, TABLE 이름, TABLESPACE 이름 순
SQL> execute DBMS_STATS.CREATE_STAT_TABLE(’SYS’,’OLTP’,’USERS’);
PL/SQL procedure successfully completed.
--  지금 부터 INTERVAL 로 지정된 시간 동안 시스템 통계정보를 생성 하라..
--  2분동안 시스템 통계정보를 수집 하라
SQL> execute DBMS_STATS.GATHER_SYSTEM_STATS(GATHERING_MODE =>’INTERVAL’,INTERVAL=> 2, STATTAB => ’OLTP’, STATID => ’OLTP’);
PL/SQL procedure successfully completed.
-- 시스템 통계정보 수집 확인
SQL> select STATID, C1, C2, C3 from OLTP;
STATID               C1                             C2                             C3
-------------------- ------------------------------ ------------------------------ ------------------------------
OLTP                 AUTOGATHERING                  02-24-2009 08:54               02-24-2009 08:56
OLTP
--  C1 = AUTOGATHERING --> 수집 중
--  C1 = COMPLETED     --> 수집 완료 로 변경된다. [ 2분 경과 후 ]

--  10분동안 시스템 통계정보를 수집 하라 [앞서 수행한 2분동안 통계정보는 Update 된다.  ]
execute DBMS_STATS.GATHER_SYSTEM_STATS(GATHERING_MODE =>’INTERVAL’,INTERVAL=> 10, STATTAB => ’OLTP’, STATID => ’OLTP’);
-- 시스템 통계정보 수집 확인
SQL> select STATID, C1, C2, C3 from OLTP;
STATID               C1                             C2                             C3
-------------------- ------------------------------ ------------------------------ ------------------------------
OLTP                 AUTOGATHERING                  02-24-2009 08:56               02-24-2009 08:58
OLTP
--  C1 = AUTOGATHERING --> 수집 중

-- 시스템 통계정보 수집 중지 하기 [ gathering_mode=>’STOP’ ]
SQL> execute DBMS_STATS.GATHER_SYSTEM_STATS(GATHERING_MODE =>’STOP’,INTERVAL=> 10, STATTAB => ’OLTP’, STATID => ’OLTP’);

-- 시스템 통계정보 수집 확인
SQL> select STATID, C1, C2, C3 from OLTP;
--  C1 = AUTOGATHERING --> 수집 중
--  C1 = COMPLETED     --> 수집 완료 [ 강제로 중지 하여도 COMPLETED 로 나온다. ]

 

--  5. OLAP 성 시스템 통계정보 수집하기
SQL> execute DBMS_STATS.CREATE_STAT_TABLE(’SYS’,’OLAP’,’USERS’);
PL/SQL procedure successfully completed.
execute DBMS_STATS.GATHER_SYSTEM_STATS(GATHERING_MODE =>’INTERVAL’,INTERVAL=> 2, STATTAB => ’OLAP’, STATID => ’OLAP’);
SQL> SELECT STATID, C1, C2, C3 FROM OLAP ;

STATID               C1                             C2                             C3
-------------------- ------------------------------ ------------------------------ ------------------------------
OLAP                 COMPLETED                      02-24-2009 09:04               02-24-2009 09:06
OLAP
-- C1 => AUTOGATHERING -- 수집 중
-- C1 => COMPLETED     -- 수집 완료 로 변경된다.  [ 2분 경과 후 ]

 

-- 6. 생성한 OLAP_STATS 시스템 통계정보 IMPORT 하기
-- 기존 통계정보 삭제
execute DBMS_STATS.DELETE_SYSTEM_STATS ;
-- 기존 통계정보를 삭제 하면,
-- SYSSTATS_INFO.DSTART 와 SYSSTATS_INFO.DSTOP 값만 DELETE 시점으로 변경된다.
SQL> select  * from sys.aux_stats$;
SNAME                          PNAME                    PVAL1 PVAL2
------------------------------ -------------------- --------- ------------------------------
SYSSTATS_INFO                  STATUS                         COMPLETED
SYSSTATS_INFO                  DSTART                         02-24-2009 09:08
SYSSTATS_INFO                  DSTOP                          02-24-2009 09:08

-- OLTP 시스템 통계정보 IMPORT 하기
execute DBMS_STATS.IMPORT_SYSTEM_STATS(stattab =>’OLTP’, STATID =>’OLTP’,STATOWN =>’SYS’);
-- Import 된 시스템 통계정보 확인
-- OLTP 시스템 통계정보를 수행한 시간으로 SYSSTATS_INFO.DSTART 와 SYSSTATS_INFO.DSTOP
-- 값이 변경되어 진다.
SQL> select * from sys.aux_stats$ ;
SNAME                          PNAME                    PVAL1 PVAL2
------------------------------ -------------------- --------- ------------------------------
SYSSTATS_INFO                  STATUS                         COMPLETED
SYSSTATS_INFO                  DSTART                         02-24-2009 08:56
SYSSTATS_INFO                  DSTOP                          02-24-2009 08:58


-- 7. 다시 원복 하기
SQL> execute DBMS_STATS.DELETE_SYSTEM_STATS ;
PL/SQL procedure successfully completed.

SQL> execute DBMS_STATS.IMPORT_SYSTEM_STATS(stattab =>’ORIGIN’, STATID =>’ORIGIN’,STATOWN =>’SYS’);
PL/SQL procedure successfully completed.

SQL> select * from sys.aux_stats$ ;
SNAME                          PNAME                    PVAL1 PVAL2
------------------------------ -------------------- --------- ------------------------------
SYSSTATS_INFO                  STATUS                         COMPLETED
SYSSTATS_INFO                  DSTART                         02-13-2009 13:33
SYSSTATS_INFO                  DSTOP                          02-13-2009 13:33
--  SYSSTATS_INFO.DSTART 와 SYSSTATS_INFO.DSTOP 로 ORIGIN 으로 변경됨


-- 8. 수동으로 시스템 통계정보 생성하기 [ 파라미터 개별 설정 ]
-- 기존 시스템 통계정보 삭제 하기
execute DBMS_STATS.DELETE_SYSTEM_STATS ;
-- CPUSPEED 설정
-- CPUSPEED : Wait time to read single block, in milliseconds
SQL> execute DBMS_STATS.SET_SYSTEM_STATS(PNAME =>’CPUSPEED’, PVALUE=>400);
PL/SQL procedure successfully completed.
-- CPUSPEED 값 변경 확인
SQL> select * from sys.aux_stats$ WHERE PNAME =’CPUSPEED’;
SNAME                          PNAME                    PVAL1 PVAL2
------------------------------ -------------------- --------- ------------------------------
SYSSTATS_MAIN                  CPUSPEED                   400
-- SREADTIM 설정
-- SREADTIM : wait time to read single block, in milliseconds
SQL> execute DBMS_STATS.SET_SYSTEM_STATS(PNAME =>’SREADTIM’, PVALUE=>100);
PL/SQL procedure successfully completed.
-- SREADTIM 값 변경 확인
SQL> select * from sys.aux_stats$ WHERE PNAME =’SREADTIM’;
SNAME                          PNAME                    PVAL1 PVAL2
------------------------------ -------------------- --------- ------------------------------
SYSSTATS_MAIN                  SREADTIM                   100

 

-- 9. 원복 하기
SQL> execute DBMS_STATS.DELETE_SYSTEM_STATS ;
PL/SQL procedure successfully completed.

SQL> execute DBMS_STATS.IMPORT_SYSTEM_STATS(stattab =>’ORIGIN’, STATID =>’ORIGIN’,STATOWN =>’SYS’);
PL/SQL procedure successfully completed.

-- 원복 결과 확인
SQL> select * from sys.aux_stats$ ;

SNAME                          PNAME                    PVAL1 PVAL2
------------------------------ -------------------- --------- ------------------------------
SYSSTATS_INFO                  STATUS                         COMPLETED
SYSSTATS_INFO                  DSTART                         02-13-2009 13:33
SYSSTATS_INFO                  DSTOP                          02-13-2009 13:33

 

[ 2.Fixed Objects Statistics ]
  개요 - 
Dynamic Performance View와 같이 fixed view(x$ tables)에 대한 통계치는
          Manual 한 Gathering 이 필요하다. 이 Fixed Objects Statistics 는
          Database 의 Activity 를 기록하게 되므로 database 가 일반적인 운영 상태
          일때 gathering  하여야 한다.
          일반적으로 Fixed Object Statistics 통계치는 V$ view 를 조회하는
          사용자 Query에 필요하다.
  수행주기 - 초기 1회
             추가적인 Application 이나 변경으로 동시 사용자 등의 변경 발생시
  주의사항 - 자동화 대상이 아니다. [ 자동으로 Fixed Object의 통계정보가 생성되지 않는다. ]
             RAC 에서는 아직 Fixed Objects Statistics 를 Instance 별로 구분하지
             않기 때문에, 가장 부하가 많은 Node(Instance)에서 통계치를 조사한다.

 
실습
: Fixed Object 통계정보는 DBMS 성능에 지대한 영향을 미치므로,
  항상 기존의 Fixed Object 통계정보를 백업 후 진행 하자.
  OLTP 와 OLAP 성 Fixed Object 통계정보를 생성하고, IMPORT 해보자

 

-- 1. 기존의 Fixed Object 통계정보 백업 테이블 생성   
SQL> execute DBMS_STATS.CREATE_STAT_TABLE(’SYS’,’FIX_ORIGIN’,’USERS’);           
-- EXPORT_FIXED_OBJECTS_STATS 를 통한 백업 수행
SQL> execute DBMS_STATS.EXPORT_FIXED_OBJECTS_STATS(stattab =>’FIX_ORIGIN’,STATID =>’FIX_ORIGIN’,STATOWN =>’SYS’);
PL/SQL procedure successfully completed.

 

-- 2. 신규로 Fixed Object 통계정보 테이블 생성  
SQL> execute DBMS_STATS.CREATE_STAT_TABLE(’SYS’,’FIX_NEW’,’USERS’); 
-- 신규 Fixed Object 통계정보 수집
SQL> execute DBMS_STATS.GATHER_FIXED_OBJECTS_STATS(’SYS’,’FIX_NEW’,’SYS’);
BEGIN DBMS_STATS.GATHER_FIXED_OBJECTS_STATS(’SYS’,’FIX_NEW’,’SYS’); END;

*
ERROR at line 1:
ORA-20000: Insufficient privileges to analyze an object in Fixed Ob
ORA-06512: at "SYS.DBMS_STATS", line 13578
ORA-06512: at "SYS.DBMS_STATS", line 13892
ORA-06512: at "SYS.DBMS_STATS", line 14420
ORA-06512: at line 1

SQL> execute DBMS_STATS.GATHER_FIXED_OBJECTS_STATS(’FIX_NEW’);
PL/SQL procedure successfully completed.

 

-- 3. 기존 Fixed Object 통계정보 확인 하기
SQL>  select table_name, to_char(last_analyzed, ’yyyymmdd hh24:mi:ss hh24:mi:ss’)
      from dba_tab_statistics
      where table_name like ’X$%’ ;

TABLE_NAME                     TO_CHAR(LAST_ANALYZED,’YYY
------------------------------ --------------------------
X$KQFTA                       
X$KQFVI                       
X$KQFVT                       
X$KQFDT                       


-- 4. 신규 Fixed Object 통계정보 IMPORT
--  FIXED TABLE 의 통계정보 삭제
SQL> execute DBMS_STATS.DELETE_FIXED_OBJECTS_STATS ;
PL/SQL procedure successfully completed.
-- 신규 Fixed Object 통계정보 Import
SQL> execute DBMS_STATS.IMPORT_FIXED_OBJECTS_STATS(stattab =>’FIX_NEW’, STATID =>’FIX_NEW’,STATOWN =>’SYS’);
PL/SQL procedure successfully completed.


-- 5. 신규 Fixed Object 통계정보 확인 하기
SQL>  select table_name, to_char(last_analyzed, ’yyyymmdd hh24:mi:ss hh24:mi:ss’)
      from dba_tab_statistics
      where table_name like ’X$%’ ;

TABLE_NAME                     TO_CHAR(LAST_ANALYZED,’YYY
------------------------------ --------------------------
X$KQFTA                        20090224 09:50:34 09:50:34
X$KQFVI                        20090224 09:50:34 09:50:34
X$KQFVT                        20090224 09:50:34 09:50:34
X$KQFDT                        20090224 09:50:34 09:50:34
...
일부는 last_analyzed 가 Update 되지 않는다.
Note that the database can decide not to collect stats for objects
that were either never used or are totally volatile.

 

6. Fixed Object 통계정보 원복 하기
SQL> execute DBMS_STATS.DELETE_FIXED_OBJECTS_STATS ;
PL/SQL procedure successfully completed.

SQL> execute DBMS_STATS.IMPORT_FIXED_OBJECTS_STATS(stattab =>’FIX_ORIGIN’, STATID =>’FIX_ORIGIN’,STATOWN =>’SYS’);
PL/SQL procedure successfully completed.

-- 복원된 정보 확인 하기
SQL > select table_name, to_char(last_analyzed, ’yyyymmdd hh24:mi:ss hh24:mi:ss’)
      from dba_tab_statistics
      where table_name like ’X$%’ ;

 
[ 3.Dictionary Statistics ]
  개요 - DBMS_STATS.GATHER_DICTIONARY_STATS 를 이용하여 Sys, System Schema 의
        Object를 Gathering 한다. 이 procedure 는 또한 DRSYS 나 CTX user Schema의
        Object 도 함께 Gathering 한다.
  수행주기 - 초기 1회
             Database Object(사용자 Table, PL/SQl, User생성) 의 변경이 있는 경우
            
실습
: Dictionary 통계정보는 DBMS 성능에 지대한 영향을 미치므로,
  항상 기존의 Dictionary 통계정보를 백업 후 진행 하자.
  OLTP 와 OLAP 성 Dictionary 통계정보를 생성하고, IMPORT 해보자

 

-- 1. 기존의 Dictionary 통계정보 통계정보 백업 테이블 생성   
SQL> execute DBMS_STATS.CREATE_STAT_TABLE(’SYS’,’SYS_ORIGIN’,’USERS’);
PL/SQL procedure successfully completed.
-- EXPORT_DICTIONARY_STATS 를 통한 백업 수행
SQL>  execute DBMS_STATS.EXPORT_DICTIONARY_STATS(stattab =>’SYS_ORIGIN’,STATID =>’SYS_ORIGIN’,STATOWN =>’SYS’);
PL/SQL procedure successfully completed.


-- 2. 신규로 Dictionary 통계정보 테이블 생성  
SQL> execute DBMS_STATS.CREATE_STAT_TABLE(’SYS’,’SYS_NEW’,’USERS’); 
PL/SQL procedure successfully completed.
-- 신규 Dictionary 통계정보 수집
SQL> execute DBMS_STATS.GATHER_DICTIONARY_STATS(’SYS_NEW’);
PL/SQL procedure successfully completed.

 

3. 신규 Dictionary 통계정보 확인 하기
SQL>   select table_name, to_char(last_analyzed, ’yyyymmdd hh24:mi:ss hh24:mi:ss’)
       from dba_tab_statistics
       where table_name like ’%$’
       order by 2
....
X$LOGMNR_OBJ$                  20090224 10:07:20 10:07:20
X$LOGMNR_TABCOMPART$           20090224 10:07:20 10:07:20
X$LOGMNR_USER$                 20090224 10:07:20 10:07:20
SUMDELTA$
SDO_TOPO_DATA$
...
일부는 last_analyzed 가 Update 되지 않는다.
Note that the database can decide not to collect stats for objects
that were either never used or are totally volatile.


4. Dictionary 통계정보 IMPORT 하기
SQL> execute DBMS_STATS.DELETE_DICTIONARY_STATS ;
PL/SQL procedure successfully completed.
-- 신규 Fixed Object 통계정보 Import
SQL> execute DBMS_STATS.IMPORT_DICTIONARY_STATS(stattab =>’SYS_NEW’, STATID =>’SYS_NEW’,STATOWN =>’SYS’);
PL/SQL procedure successfully completed.

-- IMPORT 된  Dictionary 통계정보 확인 하기
SQL>   select table_name, to_char(last_analyzed, ’yyyymmdd hh24:mi:ss hh24:mi:ss’)
       from dba_tab_statistics
       where table_name like ’%$’
       order by 2;
SRS$                           20081229 22:00:05 22:00:05
X$LOGMNR_ATTRIBUTE$            20090224 10:07:19 10:07:19
X$LOGMNR_COLTYPE$              20090224 10:07:19 10:07:19
X$LOGMNR_IND$                  20090224 10:07:19 10:07:19
X$LOGMNR_COL$                  20090224 10:07:19 10:07:19
X$LOGMNR_DICT$                 20090224 10:07:19 10:07:19
==> 테스트 에서는 실제로 Dictionary 통계정보를 가진 Table Count 가 오히려 줄어들었다.
      
5. Fixed Object 통계정보 원복 하기
SQL> execute DBMS_STATS.DELETE_DICTIONARY_STATS ;
PL/SQL procedure successfully completed.

SQL> execute DBMS_STATS.IMPORT_DICTIONARY_STATS(stattab =>’SYS_ORIGIN’, STATID =>’SYS_ORIGIN’,STATOWN =>’SYS’);
PL/SQL procedure successfully completed.

-- 복원된 정보 확인 하기
SQL>   select table_name, to_char(last_analyzed, ’yyyymmdd hh24:mi:ss hh24:mi:ss’)
       from dba_tab_statistics
       where table_name like ’%$’
       order by 2;

 

[ 4.User Table Statistics ]
: 사용자의 Object 에 대한 통계치 수집은 10G 에서 기본적인 GATHER_STATS_JOB 을
이용한다. 이 JOB 은 기존 DATA의 10% 이상의 변경이 있거나, 오랫동안 통계치가
변경되지 않거나, 통계치가 없거나 한 Object 에 대한 Gathering 을 수행한다.
또한 분석하는 순서 역시 우선순위 순으로 수행한다.
만약 Object 에 많은 Data 가 Load 되거나 변경이 있는 경우에는  Manual 하게
수행한다.
- 10G 에서 말하는 자동 통계정보 수집 기능(Automatic Statistics) 의 대상은
  1. AWR(Automactic Workload Repository)
   - 분석, Self-Tuing 및 일반적인 Tuning 을 목적으로 하는 자료로
     특정 시간 동안 데이타 베이스에서 발생한 여러 가지 상황 정보를 이른다.
     Wait Events, Latces, Enqueues, Cpu Consumption, SGA Compoenent, PGA 등에
     대한 자료 이다.
      ’STATISTICS_LEVEL’ 에 의해서 수집되는 자료의 LEVEL 이 결정된다.
     AWR 정보는 디폴트로 7일간 보관한다. [ SYSAUX TABLESPACE 에 ]
    
  2. CBO(Cost-Based Optimizer)
   - Database 의 Object 즉,  Application 및 Oracle Internal (Sys/System) 유저의
     Table, Index 에 대한 통계정보 수집
     이 수집된 정보는 Optimizer 가 수행계획 수립 시에 의해 사용된다.
     GATHER_STATS_JOB 에 의해서 수집 된다. [DB 생성시 자동 생성됨]
     Optimizer historical 통계정보는 디폴트로 31일간 보관한다.
     STATISTICS_LEVEL=BASIC 이면 CBO 통계정보가 수집되지 않는다.
        - Automatic Optimizer Statistics Collection
        - Object level Statistics  
     [ SYSAUX TABLESPACE 에 ]  
    
-- SYSAUX 사용 현황 파악 하기
 SELECT occupant_name, space_usage_kbytes FROM V$SYSAUX_OCCUPANTS;
 1. SM/AWR 
  - AWR 정보 수집
  - AWR 정보 수집 옵션 확인
    SQL>  SELECT DBID, RETENTION, TOPNSQL  FROM DBA_HIST_WR_CONTROL ;
          DBID RETENTION                      TOPNSQL
    ---------- ------------------------------ ----------
    2466823093 +00007 00:00:00.0              DEFAULT
    보존 변경은 dbms_workload_repository.modify_snapshot_settings 를 통해서 가능
   
    -- AWR 정보 한달 보관주기로 변경 [ 60*24*31 = 44640 분 ]
    SQL> EXECUTE DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS(retention => 44640 );
    PL/SQL procedure successfully completed.
    -- 변경되 AWR 정보 확인
    SQL> SELECT DBID, RETENTION, TOPNSQL  FROM DBA_HIST_WR_CONTROL ;
   
          DBID RETENTION                      TOPNSQL
    ---------- ------------------------------ ----------
    2466823093 +00031 00:00:00.0              DEFAULT

 2. SM/ADVISOR
    SQL Tuning Advisor, SQL Access Advisor, ADDM 이 사용하는 정보 저장소

 3. SM/OPTSTAT    
    - 구버전(Old) Optimizer 통계정보 저장소
    - SM/OPTSTAT 저장 기간 확인
      SQL> select dbms_stats.get_stats_history_retention from dual;
      GET_STATS_HISTORY_RETENTION
      ---------------------------
                               31
      ==> Default 로 31일
    -- 10일로 조절
    SQL> exec dbms_stats.alter_stats_history_retention(10);
    PL/SQL procedure successfully completed.

    SQL> select dbms_stats.get_stats_history_retention from dual;
    GET_STATS_HISTORY_RETENTION
    ---------------------------
                         10
    -- 원복
    SQL> exec dbms_stats.alter_stats_history_retention(31);
    PL/SQL procedure successfully completed.

  4. SM/OTHER
     - Alert History 등의 저장소


--  STATISTICS_LEVEL PARAMETER
    : Database 와 OS 의 통계정보의 수집 Level 을 제어 하는 파라미터
    1.Typical
      - Default, 일반적인 환경에 가장 적합
    2. ALL
      - typical + Timed OS Statistics + Plan Execution Statistics
    3. BASIC
      - 아래 기능을에 필요한 중요한 통계정보를 수집 할 수 없다.
        - AWR
        - ADDM
        - All Server-Generated Alerts
        - Automatic SGA Memory Management
        - Automatic Optimizer Statistics Collection
        - Object level Statistics
        등...
           
 
실습 : 여기서 말하는 자동 통계수집 이란 CBO 에 대한 것을 이른다.
     - 1. 자동 통계수집일정을 확인하고
     - 2. 자동 통계수집을 Disable 해보자
     - 3. 통계정보 백업 / 복구 하기 
     - 4. 특정 테이블 통계수집 중지 하기
 
-- 1.1 자동통계정보 수집 확인 하기
SQL >  select job_name, job_type, program_name, schedule_name, job_class
      from dba_scheduler_jobs
       where job_name =’GATHER_STATS_JOB’;
JOB_NAME             JOB_TYPE         PROGRAM_NAME         SCHEDULE_NAME                  JOB_CLASS
-------------------- ---------------- -------------------- ------------------------------ ------------------------------
GATHER_STATS_JOB                      GATHER_STATS_PROG    MAINTENANCE_WINDOW_GROUP       AUTO_TASKS_JOB_CLASS

-- 1.2 자동통계정보 수집 시 실행 되는 Program 확인
SQL> select program_Action from dba_scheduler_programs where program_name =’GATHER_STATS_PROG’;

PROGRAM_ACTION
--------------------------------------------------
dbms_stats.gather_database_stats_job_proc


--  1.3 자동통계정보 수집 시 스케줄 확인
SQL> select * from dba_scheduler_wingroup_members where window_group_name =’MAINTENANCE_WINDOW_GROUP’;

WINDOW_GROUP_NAME              WINDOW_NAME
------------------------------ ------------------------------
MAINTENANCE_WINDOW_GROUP       WEEKNIGHT_WINDOW
MAINTENANCE_WINDOW_GROUP       WEEKEND_WINDOW

 

--  1.4 자동통계정보 수집 시 스케줄 상세 확인
SQL> select window_name, repeat_interval, duration
     from dba_scheduler_windows
     where window_name in (’WEEKNIGHT_WINDOW’,’WEEKEND_WINDOW’);

WINDOW_NAME          REPEAT_INTERVAL                                                                  DURATION
-------------------- -------------------------------------------------------------------------------- --------------------
WEEKNIGHT_WINDOW     freq=daily;byday=MON,TUE,WED,THU,FRI;byhour=22;byminute=0; bysecond=0            +000 08:00:00
WEEKEND_WINDOW       freq=daily;byday=SAT;byhour=0;byminute=0;bysecond=0                              +002 00:00:00

-- 매주 월,화,수,목,금요일은 밤 10시에 8시간 동안 수행 된다.
-- 토요일 0시에 수행되어 이틀 동안 수행된다.

 

-- 2.1 자동통계정보 수집 중지
-- STATISTICS_LEVEL=BASIC 이면 자동통계정보 수집(CBO)
SQL> select job_name, state from dba_scheduler_jobs where job_name =’GATHER_STATS_JOB’;

JOB_NAME             STATE
-------------------- ---------------
GATHER_STATS_JOB     SCHEDULED

SQL> exec dbms_scheduler.disable(’GATHER_STATS_JOB’);

PL/SQL procedure successfully completed.

SQL> select job_name, state from dba_scheduler_jobs where job_name =’GATHER_STATS_JOB’;

JOB_NAME             STATE
-------------------- ---------------
GATHER_STATS_JOB     DISABLED

 

-- 2.2 자동통계정보 수집 재설정
SQL> exec dbms_scheduler.enable(’GATHER_STATS_JOB’);

PL/SQL procedure successfully completed.

SQL> select job_name, state from dba_scheduler_jobs where job_name =’GATHER_STATS_JOB’;

JOB_NAME             STATE
-------------------- ---------------
GATHER_STATS_JOB     SCHEDULED

 

-- 3.1 통계정보 백업 / 복구 하기
-- 유저 테이블 통계정보 백업 받을 테이블 생성하기
SQL> execute dbms_stats.create_stat_table(’SYS’,’USER_STATS’,’USERS’);
PL/SQL procedure successfully completed.
-- SCOTT 유저 테이블 통계정보 백업 받기
SQL> execute dbms_stats.export_schema_stats(’SCOTT’,’USER_STATS’,’SCOTT’,’SYS’);
PL/SQL procedure successfully completed.
-- 백업된 SCOTT 유저의 통계정보 확인
SQL> select STATID, C1, C2, C4, D1 from  USER_STATS ;


-- 3.2 신규로 유저 테이블 통계정보 생성
SQL> execute dbms_stats.gather_schema_stats(ownname=>’SCOTT’, ESTIMATE_PERCENT  => DBMS_STATS.AUTO_SAMPLE_SIZE,-
     GRANULARITY => ’AUTO’, DEGREE => null, METHOD_OPT => ’FOR ALL COLUMNS SIZE 1’, -
     CASCADE => TRUE );
-- 신규로 유저 테이블 통계정보 확인
select OWNER,TABLE_NAME,PARTITION_NAME,LAST_ANALYZED
from  dba_tab_statistics
WHERE OWNER=’SCOTT’
ORDER BY LAST_ANALYZED DESC ;  
-- 날짜에 주목하자

 

-- 3.3 유저 테이블 통계정보 원복하기
SQL> exec dbms_stats.delete_schema_stats(’SCOTT’);
PL/SQL procedure successfully completed.

SQL> exec dbms_stats.import_schema_stats(’SCOTT’,’USER_STATS’,’USER_STATS’,’SYS’);
PL/SQL procedure successfully completed.
 
-- 3.4 신규로 유저 테이블 통계정보 확인
select OWNER,TABLE_NAME,PARTITION_NAME,LAST_ANALYZED
from  dba_tab_statistics
WHERE OWNER=’SCOTT’
ORDER BY LAST_ANALYZED DESC ;  
-- 날짜에 주목하자

 

-- 4.1 특정 테이블 통계수집 중지 하기
-- 수동으로 통계정보 수집 하여 LAST_ANALYZED  Update 하기
SQL>  execute dbms_stats.gather_schema_stats(ownname=>’SCOTT’, ESTIMATE_PERCENT  => DBMS_STATS.AUTO_SAMPLE_SIZE,-
     GRANULARITY => ’AUTO’, DEGREE => null, METHOD_OPT => ’FOR ALL COLUMNS SIZE 1’, -
      CASCADE => TRUE );
PL/SQL procedure successfully completed.
-- 4.2 신규로 유저 테이블 통계정보 확인
select OWNER,TABLE_NAME,PARTITION_NAME,LAST_ANALYZED
from  dba_tab_statistics
WHERE OWNER=’SCOTT’
ORDER BY LAST_ANALYZED DESC ;  
-- 날짜에 주목하자

-- 특정 테이블 통계정보 수집 막기
SQL> execute dbms_stats.lock_table_stats(’SCOTT’,’T1’);
PL/SQL procedure successfully completed.

-- 특정 테이블 통계정보 수집 막음 확인
SQL> SELECT owner, table_name, stattype_locked
     FROM dba_tab_statistics
     WHERE OWNER=’SCOTT’
     and stattype_locked is not null;
    
OWNER                          TABLE_NAME                     STATT
------------------------------ ------------------------------ -----
SCOTT                          T1                             ALL


-- 확인을 위해서 수동으로 통계정보 수집 하여 LAST_ANALYZED  Update 하기
SQL> execute dbms_stats.gather_schema_stats(ownname=>’SCOTT’, ESTIMATE_PERCENT  => DBMS_STATS.AUTO_SAMPLE_SIZE,-
> GRANULARITY =>’AUTO’, DEGREE => null, METHOD_OPT => ’FOR ALL COLUMNS SIZE 1’, -
> CASCADE => TRUE );
PL/SQL procedure successfully completed.

SQL>  select OWNER,TABLE_NAME, to_char(last_analyzed, ’yyyymmdd hh24:mi:ss hh24:mi:ss’)
      from  dba_tab_statistics
      WHERE OWNER=’SCOTT’
     and table_name in (’T1’,’EMP’,’DEPT’);

OWNER                          TABLE_NAME                     TO_CHAR(LAST_ANALYZED,’YYY
------------------------------ ------------------------------ --------------------------
SCOTT                          DEPT                           20090224 11:37:57 11:37:57
SCOTT                          EMP                            20090224 11:37:57 11:37:57
SCOTT                          T1                             20090224 11:32:53 11:32:53

==> Lock 되어진 T1 에 대해서는 테이블 통계정보가 생성되지 않았음을 확인

반응형
Posted by [PineTree]
ORACLE/TroubleShooting2009. 3. 2. 01:06
반응형

RAC 환경에서 ORA-29740 문제 진단
=================================


PURPOSE


이 문서는, RAC 환경에서의 ORA-29740 문제를 진단하는 방법을 기술하는 데 목적이 있다.

SCOPE


Real Application Clusters(RAC) Option은 9i Standard Edition에서는
지원하지 않는다.

Problem Description


ORA-29740 에러는, 클러스터 환경에서 소속된 그룹의 다른 인스턴스가 여러가지 이유로 인해, 멤버 인스턴스를
축출할 때 발생하는 문제이다. 주요 이유로는, 클러스터 내부의 통신 장애나, control file에 대한 heartbeat 실패
등이 있다.
이와 같은 메카니즘은, 데이터베이스 전체에 미치는 악영향을 예방하기 위해 설계된 것이다. 예를 들어,
클러스터 전체에 Hang이 발생하는 것보다는, 오라클에서는 문제를 유발시키는 인스턴스를 클러스터에서
추출시키는 편을 택한다.
ORA-29740 에러가 발생할 경우, 클러스터에 계속 남게되는 인스턴스가, 문제를
유발시키는 인스턴스를 클러스터에서 제외시키게 된다.

문제가 발생할 경우, 여러개의 인스턴스는, control file에 대한 갱신 권한을 획득 하기위해 control file에 대한
lock에 대해 경합하게 된다.
Control file에 대한 lock을 RR lock 또는 Result Record Lock이라 한다.
마침내 lock을 획득한 인스턴스가, 클러스터 멤버 구성을 결정하기 위한, "투표"
를 주관하게 된다.
멤버 인스턴스는 다음과 같은 경우 추출된다.

a) 통신 회선 장애
b) 하나 이상의 subgroup에서, subgroup 간 split-brain 현상이 발생
하는데, 멤버 인스턴스가, 가장 큰 subgroup에 속하지 않는 경우
c) 멤버 인스턴스가 inactive 상태인 것이 감지되었을 때

* Split-brain 현상은 클러스터 내 노드 간의 통신 장애가 발생하여, 각 노드입장에서는 다른 노드가 죽은 것으로 간주
하는데, 실제로는, 각 노드들은 살아 있는 경우를 말한다. 이와 같은 현상이 발생했을 때 적절한 조치를 취하지
않는다면, 각 노드에서 오라클 데이터 파일에 대해 write를 수행하여, corruption이 발생할 수 있다.

추출된 인스턴스의 alert log에는 다음과 같은 메시지가 남아 있게 된다.

Fri Sep 28 17:11:51 2001
Errors in file /oracle/export/TICK_BIG/lmon_26410_tick2.trc:
ORA-29740: evicted by member %d, group incarnation %d
Fri Sep 28 17:11:53 2001
Trace dumping is performing id=cdmp_20010928171153
Fri Sep 28 17:11:57 2001
Instance terminated by LMON, pid = 26410

ORA-29740 에러에 대한 진단을 위해서는 각 인스턴스 별 LMON 트레이스 파일을 분석하는 것이 중요하다.
추출된 인스턴스에서는 다음과 같은 메시지가 남게 된다.

*** 2002-11-20 18:49:51.369
kjxgrdtrt: Evicted by 0, seq (3, 2)
^

위 내용은, 어느 인스턴스에서 추출을 시켰는지를 나타낸다.

추출을 시킨 인스턴스에서는 다음과 같은 메시지가 남는다.

kjxgrrcfgchk: Initiating reconfig, reason 3
*** 2002-11-20 18:49:29.559
kjxgmrcfg: Reconfiguration started, reason 3

...
*** 2002-11-20 18:49:29.727
Obtained RR update lock for sequence 2, RR seq 2
*** 2002-11-20 18:49:31.284
Voting results, upd 0, seq 3, bitmap: 0
Evicting mem 1, stat 0x0047 err 0x0002

위에서 보는 바와 같이 인스턴스에서는 reconfiguration을 reason 3에 의해
시작하였음을 알 수 있다. (reconfiguration 관련 내용은, Note 139435.1
참조.

클러스터에 대한 reconfiguration을 시작한 인스턴스는 RR lock (Results Record Lock)을 획득하여야
하는데 이것은 이 인스턴스가, 멤버 구성에 대한 투표를 주재할 권한을 가진 다는 것을 의미한다.
마지막 줄에서는, 투표 결과를 나타내고 있으며, 결과적으로 1번 인스턴스를 추출시키는 것을
나타내고 있다.

ORA-29740 에러에 대한 문제 해결을 위해서는 '이유'가 (위 예에서는 reason 3로 나와있음)
무엇인지가 중요하다.
위 예제에서 첫번째 섹션이 reconfiguration을 시작한 이유를 나타내고 있다.

Reason 0 = No reconfiguration
Reason 1 = The Node Monitor generated the reconfiguration.
Reason 2 = An instance death was detected.
Reason 3 = Communications Failure
Reason 4 = Reconfiguration after suspend

대부분의 ORA-29740 에러에서는 reason 코드 1,2,3번을 만나게 될 것이다.

다음은 각각의 코드에 대한 설명이다.

Reason 1: 노드 모니터에서 reconfiguration을 지시하는 경우 :

a) 인스턴스가 클러스터에 합류할 때
b) 인스턴스가 클러스터에서 이탈할 때
c) 노드가 halt 상태가 될 때

이 경우는, 에러의 원인을 모든 인스턴스의 alert log와 LMON 트레이스파일을 살펴봄으로써 쉽게
알 수 있다. 인스턴스가 클러스터에 합류 또는 이탈하거나 halt 상태가 될 때
ORA-29740 에러가 발생하는 것은 정상적인 경우이며 문제가 되지 않는다.
만약 문제가 되는 경우로 의심이 된다면 Metalink에서 다음 검색어로 검색하도록 한다.

ORA-29740 'reason 1'

살펴 보아야 할 주요 파일은 다음과 같다:

a) 각 인스턴스의 alert log
b) 각 인스턴스의 LMON 트레이스 파일
c) 각 노드의 syslog 또는 messages 파일 (유닉스 플랫폼의 경우)


Reason 2: 인스턴스 종료가 감지된 경우 :

a) 인스턴스가 비정상 종료가 heartbeat 또는 control file로 인해 발생한 경우

Hearbeat이 누락될 경우, LMON에서는 heartbeat을 보내지 않는 인스턴스에 대해 네트워크
ping을 테스트 해 본다. 인스턴스가 ping에 대해 응답할 경우 LMON에서는 인스턴스가
살아 있는 것으로 간주한다. 하지만, hearbeat이 일정 기간동안 발생하지 않을 경우 ( 기간은
control file의 enqueue timeout에 지정되어 있음 ) 해당 인스턴스에 문제가 발생한 것으로
간주하고, 그 인스턴스를 클러스터에서 추출한다. 문제가 발생하는 경우에 대해서는 추가적인
분석이 필요한데, 이것은, 일반적으로 클러스터에서 추출 되기 전 ORA-600 2103 에러가
수반되기 때문이다. 만약 문제가 되는 경우로 의심 된다면, Metalink에서 다음 검색어로
검색 하도록 한다.
ORA-29740 'reason 2'

살펴 보아야 할 주요 파일은 다음과 같다:

a) 각 인스턴스의 alert log
b) 각 인스턴스의 LMON 트레이스 파일
c) 추출된 인스턴스의 CKPT process trace file
d) bdump 또는 udump에 존재하는 다른 파일
e) 각 노드의 syslog 또는 messages 파일 (유닉스 플랫폼의 경우)


Reason 3: 통신 장애가 발생한 경우 :

a) LMON 프로세스가 서로 통신 할 수 없을 때
b) 인스턴스가 다른 인스턴스의 LMD 프로세스와 통신 할 수 없을 때
c) LMON 프로세스가 블러킹, 스핀 (무한루프) 또는 살아는 있으나 동작을
하지 않아 다른 인스턴스의 LMON 프로세스의 요청에 응답하지 않을 때
d) LMD 프로세스가 블럭킹 또는 스핀 상태가 될 경우

이 경우 ORA-29740 에러는, 인스턴스간의 통신이 실패할 경우 기록된다.
이것은 인스턴스가 IPC 전송에 대한 timeout이 발생하여, 클러스터에서 추출 된
경우를 의미한다. LMON이 아닌 foreground 또는 backgroupd 프로세스와 원격지 LMON에서 통신 장애가
발생 할 경우에도 ORA-29740 이 발생하며 코드로 reason 3 이 남게 된다.
이와 같은 ㅁ문제가 발생 할 경우, 트레이스 파일 또는, 프로세서에서 다음과 같은
메시지가 나타난다 :

Reporting Communication error with instance:

만약 통신 장애가 클러스터 레벨에서 발생할 경우 (예 : 네트워크 케이블이 뽑힌 경우) 클러스터 소프트웨어는
클러스터의 split-brain 현상에 대응하기 위해 노드 추출을 시도하게 된다.
이 문제는 LMON 이 캐쉬된 자원을 처분할 (cleanup) 때도 발생할 수 있다. 만약 한번에 100개의 자원을 처분하려 한다면
중간에 클러스터 매니저의 활동을 점검해 본다. 만약 각각의 삭제 작업이 그리 오랜 시간이 걸리지 않지만
처분해야 할 자원이 너무 많다면, LMON이 상당 시간동안 블러킹 상태가 되며, LMON에서 원격지의 메시지를 처리
할 수 없게 되어 timeout이 발생하게 된다. 이 문제는 9.0.1.4 이상과 9.2.0.1에서 해결된 문제이다.

사용중인 오라클 버전에서 bug 2276622가 해결되었는지 확인해 볼 필요가 있으며, 만약 위 bug이 해결된
버전에서 클러스터 추출이 문제가 되는 경우로 의심된다면, Metalink에서 다음 검색어로
검색 하도록 한다.

ORA-29740 'reason 3'

살펴 보아야 할 주요 파일은 다음과 같다:

a) 각 인스턴스의 alert log
b) 각 인스턴스의 LMON 트레이스 파일
c) 각 인스턴스의 LMD trace file
d) bdump 또는 udump에 존재하는 다른 파일.
e) 각 노드의 syslog 또는 messages 파일 (유닉스 플랫폼의 경우)
f) Netstat -ai 그리고 netstat -s 결과
반응형
Posted by [PineTree]
ORACLE/OWI2009. 3. 1. 16:55
반응형

mutex나 semaphore는 시스템에서 동기화를 위해서 제공하는 자원(리소스)이고, latch와 lock은 db에서 사

용하는 동기화 기법으로 정리됩니다. latch와 lock을 mutex 또는 semaphore로 구현을 할 수 있습니다.


첫번째 mutex를 보면,
상호배제를 구현하기 위한 동시성 제어 단위이다.

mutex는 단지 어떤 리소스에 대한 권한을 획득/비획득 이라는 2개의 상태로 나뉘어 진다.

가장 쉬운 예로 pthread_mutex_lock / unlock 함수를 들 수 있다.


둘째로 latch라는 개념은 (물론 운영체제와 같은 다른 C/S field에서는 다른 개념으로 사용할 수 있다)

이렇게 표현된다.

"물리적인 대상의 리소스에 대해 짧은 시간동안 권한(읽기/쓰기)를 획득하여 작업하고자 할 경우 사용되는 동시성 제어 단위"

DBMS 입장에서 설명을 하자면, 물리적이라는 의미는 대상이 특정 버퍼 블럭이나, 낮은 수준의 객체에 대한 것이라고 해석될 수 있다.

또한, 짧은 시간동안이라는 것은 상대적인 개념으로서 뒤에 설명될 lock보다 짧다는 것인데, 이 latch의 목적이 가능한한 빠른 연산을 목표로 하고 있기 때문에 짧다라는 표현을 쓴다.

그리고, latch는 mutex와는 달리 모드를 가질 수 있다.

대표적으로 읽기 모드와 쓰기 모드인데, 본인이 알고 있는 범위내에서는 DBMS에서의 latch는 이 두가지의 모드밖에 보지 못했다.

마지막으로 가장 중요한 또 한가지 점은 이 latch는 dead lock이 발생하지 않는다고 가정한다는 것이다.

물론 잘못된 순서로 객체에 latch를 잡는 경우에는 dead lock이 발생할 수 있지만, 이러한 상황은 개발자에 의한 버그이지 원래 latch의 목적과는 상반된다는 것이다.

따라서, latch에서는 dead lock 상황에 대한 해결책도 가지지 않는다. 일반적으로 이러한 목적을 DBMS내부에서 부합하기 위해서 latch의 대상이 되는 객체는 엄격한 순서로 연산이 이루어 지게 되어 있다.

특히, 인덱스나 레코드 페이지에 대한 순서가 어긋나면 DBMS가 정지하는 상황이 발생하고, 개발자는 혹독한 (기초도 모르는!!!) 시련을 겪게 된다.

세번째로, lock은 DBMS 에서 이렇게 표현된다.

"논리적인 대상에 대한 작업시 사용되는 동시성 제어 단위로서 비교적 긴 시간동안 발생하는 연산" 정도로 말할 수 있겠다.

우선 이 논리적인 대상이라는 의미는 단순이 메모리 대상 객체라기 보다는 테이블 혹은 레코드라는 보다 추상적인 의미가 강하고, 또한 lock이 잡히는 길이도 사용자에 의해서 상당히 긴 시간동안 발생할 수 있다.

또한, mutex는 1개, latch는 2개 정도의 모드를 가지는 반면, lock의 경우에는 S,X,IS,IX,SIX,U 등의 다양한 모드로 연산이 발생할 수 있다.

그리고, 이 lock은 dead lock이 발생하는 것을 허용하고, 또한 이러한 dead lock에 대한 내부적인 방지책을 가지고 있다.

가만히 생각해 보면, 너무나도 당연한 이야기인데, 사용자는 어떤 논리적 대상에 대한 lock을 걸 때 순서를 상관하지 않기 때문에 발생한다.

Oracle에서 Latch 가 성능 저하의 원인이 아닙니다. 증상일 뿐이죠.

예를 들어... Library cache 관련된 Latch가 나타날 경우... APP쪽에서 none-bind 를 사용한 SQL이 그만큼 많다거나 그런 원인이구요.

Buffer Cache Chain Latch 라면 뭔가 비효율적인 인덱스를 타거나 대량의 Full Scan을 하는 악성 SQL이 있다는 뜻입니다.

반응형

'ORACLE > OWI' 카테고리의 다른 글

OWI를 활용한 shared pool 진단 및 튜닝  (0) 2009.06.30
Latch의 발생과 경합의 원인  (0) 2009.03.09
Enqueue 와 Latch  (0) 2009.03.01
Direct path read  (0) 2009.02.08
LIBRARY CACHE LOCK WAIT EVENT가 나타날 때의 해결방법  (0) 2008.12.22
Posted by [PineTree]