Oracle - Redo buffer 관련 Wait

(DB) Oracle/기타 2017. 1. 22. 17:17

[ Oracle - Redo buffer 관련 Wait ]     

 

☞ [5] Redo buffer 관련 Wait

  ■ Redo buffer 구조

오라클 리두 구조의 핵심은 모든 트랜잭션 정보를 OS 파일에 기록해 둠으로써 시스템 장애가 발생해도 트랜잭션 단위의 일관성을 잃지 않고 데이터베이스를 복구할 수 있도록 하겠다는 것이다. 리두버퍼(redo buffer)는 이처럼 데이터베이스에 가해진 모든 변경내역을 파일에 기록 하기 위해 잠시 사용되는 메모리 영역이며 리두버퍼에 기록된 리두 정보는 다시 리두로그 파일에 기록되어짐으로써 향후 시스템 복구 작업이 필요할 때에 사용하게 된다. 오라클의 리두 구조를 이해하기 위한 핵심적인 개념을 간단히 정리해보면 다음과 같다.

데이터베이스에 대한 변경내역은 블록단위로 저장된다. 물론 변경되는 모든 블록의 복사본을 통째로 저장하는 것은 아니고 블록별로 어떠한 오퍼레이션을 수행하는가, 그리고 그러한 블록별 오퍼레이션을 어떠한 순서로 수행하는가를 기록한다. 이러한 블록별 단위액션을 change vector라고 부르며 change vector가 순차적으로 모여 하나의 의미 있는 redo record가 된다. 리두로그는 시스템내의 모든 프로세스들에 의해 생성되는 redo record를 SCN 순서대로 저장해놓은 것이다. 이때 리두로그에 기록되는 내용에는 테이블이나 인덱스 등의 데이터 블록 뿐만 아니라 UNDO 블록 또는 UNDO 세그먼트 헤더블록에 대한 변경내용을 포함하는 모든 버퍼캐쉬 블록에 대한 변경내역이 대상이 된다.

리두 정보는 항상 실제 변경작업보다 먼저 보관되어야 어떤 상황에서도 복구가 가능해진다. 따라서 트랜잭션을 수행하는(데이터베이스 블록에 변경을 가하는) 프로세스는 우선 자신의 메모리 영역 내에서 수행하고자 하는 작업에 대한 리두 레코드를 만들며, 이를 먼저 로그버퍼에 기록하고 난 후에 실제 버퍼블록에도 리두 레코드에 담긴 내용을 따라 적용하게 된다. 또한 같은 이유로 오라클은 변경된 버퍼캐쉬 블록을 디스크에 기록하기 전에 먼저 관련된 로그버퍼를 로그파일에 기록하는 작업을 처리하게 된다. 따라서, 리두 버퍼 또는 리두 파일 (아카이브 파일을 포함해서)에 대한 쓰기 작업에 병목이 생기면 시스템에 대한 모든 작업 수행이 대기 상태로 빠지게 될 것이다.

트랜잭션 커밋을 요청한 프로세스는 우선 해당 트랜잭션에 대한 로그버퍼가 리두로그 파일에 기록되는 작업이 완료된 후에야 커밋 완료 메세지를 받을 수 있다. 그렇게 함으로써 버퍼캐쉬 변경내역을 모두 디스크에 반영하지 않고도 시스템의 비정상 종료시 리두파일에 저장된 리두 레코드로부터 커밋 트랜잭션을 보존할 수 있게 된다.

■리두 버퍼관련 Wait 이벤트

일반적으로는 로그버퍼 관련해서 심각한 Waiting이 발생하는 경우는 드물지만, 가끔 볼 수 있는 리두 관련 Wait 이벤트로는 다음과 같은 것들이 있다.

▷ Log file parallel write

LGWR가 OS에 리두 버퍼를 로그파일에 기록하도록 요청해 둔 상태에서 대기하고 있는 이벤트이다. 이 경우에는 DML 작업시 nologging 옵션 등을 사용하여 시스템에서 발생하는 리두 레코드의 절대량을 줄이거나 하드웨어적으로 DISK IO를 개선시켜주는 것이 방안이다.

▷Log buffer space

프로세스가 로그버퍼를 할당하기 위해 대기하는 이벤트인데 LGWR가 로그버퍼를 비우는 것보다 더 빠른 속도로 프로세스들이 리두 레코드를 생성하고 있다는 것을 의미한다. 로그버퍼의 크기를 늘려주거나, DISK IO의 속도를 개선시켜 주어야 할 것이다. 로그버퍼는 로그파일에 대응되는 블록이 맵핑이 된 후에 사용될 수 있으므로 로그 스위치 발생시에도 log buffer space 이벤트에 대한 대기가 발생할 수 있다. 로그 스위치가 너무 잦다면 리두 로그 파일의 크기를 증가시켜주는 것이 좋다.

▷ Log file sync

프로세스가 커밋이나 롤백을 수행할 경우 우선 LGWR에게 해당 트랜잭션까지의 로그버퍼를 Write하도록 요청하게 되는데 이때 사용자 프로세스는 LGWR가 쓰기 작업을 완료할 때까지 log file sync 이벤트를 대기하게 된다. 버전 8i 이전에서는 DBWR가 쓰기 작업을 수행하다가 아직 관련 로그버퍼가 파일에 쓰여지지 않을 경우에도 LGWR에 쓰기를 요청하고 log file sync 이벤트에 대기하였으나 8i 이상에서는 log file sync에 대기하는 대신 deferred write queue에 등록한다. 따라서 버전 8i 이상에서 log file sync 이벤트는 사용자 프로세스에 의해 요청되는 커밋, 롤백 처리 시에 발생하며 결국, 시스템 전체적으로 커밋, 롤백이 지나치게 자주 수행되거나 상대적으로 LGWR의 쓰기 속도가 느린 것이 원인일 것이다. 또는, 로그 버퍼가 너무 커서 LGWR가 백그라운드로 flush 시켜주기 전( 보통 3초 간격 및 1/3 이상의 로그버퍼가 찬 경우)에 커밋에 의한 쓰기 요청이 이루어지므로 커밋 시점에 써야 할 양이 많아 대기시간이 길어지는 경우도 있는데 이 경우엔 리두 버퍼의 크기를 오히려 줄여주어야 할 것이다. 또는, LGWR wait for redo copy 이벤트가 많이 나타난다면 redo copy latch가 너무 많아 LGWR이 사용자 프로세스가 버퍼 쓰기 작업을 마칠 때까지 기다리는 일이 잦은 경우를 뜻하며 이 경우엔 _LOG_SIMULTANEOUS_COPIES 파라미터를 사용하여 copy latch의 수를 줄여주는 조치가 필요할 것이다.
시스템에 따라서 언급한 외의 다양한 이벤트 대기와 원인이 존재할 수 있고, 더구나 버전에 따라 redo copy latch와 redo allocation latch를 포함한 리두 운영 방식상 상이한 부분이 많이 존재하여 그에 따른 추가적인 튜닝요소가 있으나 이 글에서는 지면 관계상 8i를 기준으로 간략히 정리해 보았다.

출처: http://www.oracle.com/technology/global/kr/pub/columns/dbtuning04.html

 

저작자표시

'(DB) Oracle > 기타' 카테고리의 다른 글

Oracle - Transportable Tablespaces  (0) 2017.01.22
Oracle - Top SQL 튜닝하기  (0) 2017.01.22
Oracle - Buffer Cache 관련 Wait  (0) 2017.01.22
Oracle - Shared Pool 관련 Wait  (0) 2017.01.22
Oracle - Enqueue와 Latch 개념 이해하기  (0) 2017.01.22
Posted by 농부지기
,

Oracle - Buffer Cache 관련 Wait

(DB) Oracle/기타 2017. 1. 22. 17:17

[ Oracle - Buffer Cache 관련 Wait ]     

 

☞ [4] Buffer Cache 관련 Wait

 

■ Buffer Cache 구조

Buffer Cache의 기본적인 기능은 여러 프로세스에 의해 공통으로 자주 액세스 되는 데이터베이스 블록을 메모리에 캐쉬하여 물리적인 디스크 IO를 최소화함으로써 더 빠른 액세스 속도를 제공하기 위한 것이다. 복잡한 설명은 생략하고, Buffer Cache 의 기본구조를 이해하기 위한 몇 가지 핵심 용어들을 간단히 정리해 보도록 하겠다.

▷ Buffer header

모든 버퍼 블록들은 각자의 buffer header를 통해 액세스되고 관리된다. 즉, 메모리에 캐쉬된 특정 데이터 블록에 대한 액세스는 먼저 해쉬 알고리즘을 통해 cache chain 상의 buffer header를 찾고 해당 buffer header에 기록된 데이터 블록의 메모리상 주소를 찾아가 원하는 정보를 읽는 방식으로 이루어진다. Buffer header에 기록되는 주요정보는 다음과 같으며 Buffer header의 내용은 V$bh 뷰를 통하여 조회해볼 수 있다.

     - 메모리상에서의 해당 버퍼블록의 주소
     - 해당 버퍼 블록(실제로는 버퍼헤더)가 포함되어 있는 hash chain
     - LRU, LRUW, CKPTQ와 같은 리스트상에서의 해당 버퍼블록의 위치
     - 해당 버퍼블록에 대한 User, Waiter와 상태를 나타내는 각종 Flag

▷ Hash Buckets/ Hash Chains

Buffer Cache의 모든 블록은 해쉬 알고리즘을 통해 관리된다. 곧, 데이터 블록의 DBA, Class 값으로 Hash Function을 적용하여 해당 블록이 속하는 hash buckets을 할당하며, 동일한 hash buckets에 할당되는 데이터 블록의 버퍼헤더들은 linked list형태로 hash chain을 이루게 된다. Hash buckets/hash chains는 특정 데이터 블록을 찾아가기 위한 수단을 제공한다. 각각의 hash buckets에는 자신에 속한 hash chain을 보호하기 위한 latch(cache buffers chains)가 할당된다.

▷ LRU

LRU는 두개의 리스트, 즉 LRUW와 LRU 리스트의 쌍으로 구성된다. LRUW(LRU Write list)는 dirty list와 같은 말이며, 수정되어 디스크에 반영되어야 할 블록들의 리스트이다. LRU(Least recently used list)는 LRUW에 올라가지 않은 나머지 버퍼 블록들이 등록되어 있다. Buffer cache 상의 버퍼블록은 반드시 LRU나 LRUW 둘 중의 하나에 등록되며, 두 리스트에 동시에 포함되는 경우는 없다. LRU는 Free Buffer를 찾기 위한 수단을 제공한다. 경합을 피하기 위해 버퍼캐쉬 블록들을 여러 개의 LRU쌍으로 나누어 관리할 수 있으며, 각 LRU리스트를 보호하기 위해 Latch(Cache buffers lru chain)가 하나씩 할당된다.

■ Buffer Cache 운영규칙

▷ 메모리상의 특정 버퍼블록을 찾아가거나, 특정 블록이 메모리에 캐쉬 되어 있는지를 확인하기 위해서 오라클은 hash bucket/hash chain 구조를 사용한다.

▷새로운 데이터블록을 디스크로부터 메모리로 읽어 들이기 위한 free buffer를 확보하기 위해 오라클은 LRU 리스트를 사용한다.

▷ 버퍼블록은 LRU나 LRUW 둘 가운데 하나에 등록된다.

▷ 하나의 블록에 대해 시간대가 다른 여러 개의 복사본이 존재할 수 있으며, 그 가운데 오직 CURRENT 버퍼만이 변경될 수 있다.

▷하나의 버퍼블록은 한번에 오직 하나의 프로세스에 의해서만 변경될 수 있다.

■ Buffer Cache 관련 Waits

버퍼캐쉬와 관련되어 흔히 발생하는 대표적인 Wait 이벤트는 다음과 같다.

▷ buffer busy waits

여러 세션이 동시에 같은 블록을 읽으려고 하거나 여러 세션이 같은 블록에 대한 변경작업이 완료되기를 기다리고 있는 경우에 발생하며, 특정 블록에 대한 경합을 해소하기 위한 조치는 블록의 유형에 따라 달라진다. Data block에 대한 경합이 많은 경우는 Pct free나 Pct used 값을 사용하여 블록 당 로우수를 줄이거나, 특정 블록에 로우 입력이 몰리는 구조의 인덱스(right-hand-index)일 경우는 reverse key index의 사용을 검토하는 등의 방법이 있으며, segment header의 경합이 많은 경우는 freelist 수를 늘리거나 Extent의 크기를 증가시키는 등의 방법이 있고, undo header나 undo block에 대한 경합은 롤백세그먼트의 개수나 크기를 증가시키는 것이 전형적인 조치 방법이다. v$waitstat과 x$kcbfwait을 이용하며 Class 또는 file별로 wait 발생상황을 판단할 수 있다.

▷ free buffer waits/write complete waits

DBWR가 dirty buffer를 write하는 동안 서버 프로세스가 대기하고 있는 경우 발생한다. 곧, 너무나 많은 dirty buffer가 생겨나거나 DBWR의 쓰기 속도가 충분히 튜닝 되지 못한 경우에 발생한다. 점검 포인트는 물리적 디스크의 속성(stripe size, layour, cache size) 최적화, Raw device의 활용, Async IO나 multi-DBWR(db_writer_processes) 활용여부 등이다.

위와 같은 버퍼 블록에 대한 경합 역시 비효율적인 실행계획을 통해 수행되는 애플리케이션에 의하여 불필요하게 많은 블록이 메모리로 올라오는 것이 원인일 경우가 많으므로 경합이 빈번한 블록이 속하는 테이블/인덱스 명을 찾아낼 수 있다면 관련 SQL을 찾아내어 보다 효과적인 튜닝작업이 이루어질 수 있을 것이다. v$session_wait의 p1,p2 컬럼에 각각 file#, block#값을 표시하여 주므로 이 값을 이용하여 아래의 SQL문으로 현재 어떤 오브젝트에 대하여 해당 wait가 발생하고 있는지를 추적할 수 있다. ( 1회에 소개한 SQL문에서는 Additional Info 값을 참조. )

     select segment_name, segment_type
     from dba_extents
     where file_id = :file#
     and :block# between block_id and block_id + blocks -1

▷ cache buffers chains latch

SGA내에 캐쉬된 데이터블록을 검색할 때 사용된다. 버퍼캐쉬는 블록들의 chain을 이루고 있으므로 각각의 chain은 이 Latch의 child들에 의해 보호된다. 이 Latch에 대한 경합은 특정 블록에 대한 대량의 동시 액세스가 발생할 때 유발된다. 애플리케이션을 검토해 보아야 한다.
Ø cache buffers lru chain latch
버퍼캐쉬의 버퍼를 LRU 정책에 따라 이동시켜야 할 필요가 있는 경우 프로세스는 이 Latch 획득하게 된다. 이 Latch에 대한 경합은 Multiple buffer pool을 사용하거나 DB_BLOCK_LRU_LATCHES 를 증가시켜 LRU Latch의 개수를 늘려서 해소할 수 있다. SQL문을 튜닝하면 해당 프로세스에 의해 액세스 될 블록의 수가 줄어들 것이므로 당연히 효과를 거둘 수 있다.
위와 같이 버퍼캐쉬를 관리하는 Latch에 대한 경합은 경합이 집중되는 특정 Child Latch에 의해 관리되는 버퍼블록을 찾아 해당 블록이 속한 세그먼트 정보를 알아낸다면 보다 효과적인 조치가 가능할 것인데, latch free wait일 경우 v$session_wait의 p1raw 값이 해당 Latch address를 의미한다. 이 값을 x$bh의 hladdr 값과 조인하면 관련 오브젝트 이름을 추적해볼 수 있다.

     select file#, dbarfil, dbablk, obj, o.name
     from x$bh bh, obj$ o
     where bh.hladdr = :latch_address
     and bh.obj = o.obj#;

 

출처: http://www.oracle.com/technology/global/kr/pub/columns/dbtuning04.html

 

저작자표시

'(DB) Oracle > 기타' 카테고리의 다른 글

Oracle - Top SQL 튜닝하기  (0) 2017.01.22
Oracle - Redo buffer 관련 Wait  (0) 2017.01.22
Oracle - Shared Pool 관련 Wait  (0) 2017.01.22
Oracle - Enqueue와 Latch 개념 이해하기  (0) 2017.01.22
Oracle - Wait Event 모니터링  (0) 2017.01.22
Posted by 농부지기
,

Oracle - Shared Pool 관련 Wait

(DB) Oracle/기타 2017. 1. 22. 17:17

[ Oracle - Shared Pool 관련 Wait ]     

 

☞ [3] Shared Pool 관련 Wait

  ■Share pool과 성능문제

오라클이 공유 메모리(SGA)를 사용하는 가장 큰 이유는 기본적으로 메모리 사용을 최소화하면서 처리성능은 최대화하기 위한 것이다. 한번 액세스된 블록을 Database buffer cache에 캐쉬 함으로써 비용이 큰 Disk I/O를 최소화하는 것처럼, 한번 처리된 SQL의 실행 정보를 Shared Pool에 공유함으로써 파싱 작업을 위한 CPU, 메모리 자원의 사용을 최소화하고 SQL 수행속도를 증가시킬 수 있다. Shared Pool에는 SQL이나 PL/SQL을 수행하기 위한 각종 정보 - SQL구문 및 실행계획, PL/SQL 소스, 테이블, 뷰 등의 각종 오브젝트와 오브젝트 상호간의 의존관계, 권한관계 등 - 가 저장되어 있다. 지면 관계상 이 글에서 Shared Pool의 관리 메커니즘을 상세히 기술할 수는 없지만 몇 가지 내재적인 특징으로 인해 Shared Pool은 오라클의 메모리 영역 가운데에서도 가장 성능문제의 요소가 많은 곳이면서도 효과적인 튜닝이 수월치 않은 영역이기도 하다.

무엇보다, Shared Pool에서 가장 문제가 되는 것은 메모리의 조각화(Fragmentation)이다. Shared Pool에서 라이브러리 캐쉬 오브젝트를 위해 할당되는 메모리 단위를 chunk라고 부르는데 chunk의 크기는 수 바이트에서 수 K바이트에 이르기까지 필요에 의해 다양하게 할당된다. 새로운 chunk의 할당이 필요하게 되면, 프로세스는 이미 존재하는 chunk로부터 필요한 만큼의 크기만을 떼어내어 사용하므로 시간이 흐를수록 점차 메모리가 조각화 되는 것을 피할 수 없다. ( 이는, Pctincrease가 0가 아닌 테이블스페이스에서 익스텐트의 할당과 해제가 반복됨에 따라 공간의 조각화가 심해지는 것을 떠올리면 이해가 쉬울 것이다. ). 어느 정도 정형화된 패턴의 애플리케이션이 수행되는 환경이 아니라, 공유가 불가능한 다양한 형태의 SQL(대표적으로 Literal SQL)이 빈번히 요청되는 환경이라면 Shared Pool 메모리 조각화에 따른 문제는 더욱 심각해진다.

또한, Shared Pool은 일반적인 메모리 캐쉬와는 달리 메모리에 저장되었던 정보를 잠시 기록해둘 대응되는 디스크 공간이 없으므로 한번 flush된 라이브러리 캐쉬 오브젝트를 reload하기 위해서는 해당 정보를 재생성 해야만 한다. 이 과정에서 관련 오브젝트 정보의 검색 및 참조, locking, 메모리 할당 등의 작업을 위해 많은 비용이 들기 때문에 결국 Shared Pool 관련 튜닝의 최대 과제는 SQL 공유를 최대화하여 새로운 파싱 요청과 메모리 요청을 최소화하는 것이라고 할 수 있다. 헌데, 이는 애플리케이션의 설계와 연계되는 영역으로서 이미 개발이 완료된 운영서버에서는 변경작업이 여의치 않은 것이 현실이다. 앞서, Shared Pool이 DBA로서 튜닝이 수월치 않은 영역이라고 표현한 이유 가운데 하나가 여기에 있다.

■ Shared Pool 관련 오해 바로잡기

Shared Pool과 관련하여 판단이 쉽지 않은 부분 가운데 하나가 과연 shared_pool_size를 얼마나 할당할 것인가 하는 것이다. 오라클은 Shared Pool 메모리를 최대한 효율적으로 활용하기 위하여 다양한 기법을 동원하고 있는데, 이러한 메모리 관리 메커니즘에 대해 정확히 알지 못하여 Shared Pool 크기를 지나치게 크게 할당함으로써 오히려 문제를 악화시키는 경우도 드물지 않다. 이러한 오해를 바로잡기 위해 Shared Pool의 메모리 할당과정을 간단하게나마 살펴보도록 하겠다.

새로운 메모리 Chunk가 할당되는 과정을 살펴보면, 우선 프로세스는 Free List를 검색하여 자신이 필요로 하는 크기의 Free Chunk를 찾고, 그러한 Free Chunk가 없으면 원하는 크기보다 한단계 큰 Free Chunk를 찾아서 필요한 크기만큼 분할하여 사용하게 된다. 만약 Free List에서 충분한 크기의 Free Chunk를 찾을 수 없다면, 이미 사용되었으나 현재는 사용되고 있지 않는(unpinned) Chunk들의 LRU List를 검색하여 오래된 것부터 8개씩 flush시켜 Free Chunk로 만든 후 자신이 필요한 크기를 할당하여 사용하게 된다. 만약 이 과정에서 현재 사용중인(pinned) Chunk가 대부분이거나, 너무 메모리 조각화가 많이 일어나서 기존 Chunk를 Flush시킨 후 인접한 Free Chunk들을 병합해보아도 원하는 크기의 Free Chunk를 얻어낼 수 없다면 오라클은 ORA-4031 에러를 발생시키는데, 그 이전에 한가지 최후의 비밀무기가 더 숨어 있다. 바로 Spare Free 메모리라는 것인데 오라클은 인스턴스 기동 후 처음에는 전체 Shared Pool의 50% 가량은 Free List에 올려놓지 않고 아예 숨겨두었다가 앞서와 같이 도저히 피할 수 없는 순간이 되면 조금씩 해제 시켜 사용하도록 한다. 그야말로 메모리의 조각화를 최소화하기 위한 오라클의 눈물 나는 노력이라고 할 수 있을 것이다. 물론 이 영역까지 다 소모한 후에 flush를 통해서도 필요한 Chunk를 확보할 수 없는 상황이 되면 결국 ORA-4031 에러가 발생할 것이다.

많은 이들이 Shared Pool의 남아있는 Free memory의 크기가 작으면 shared_pool_size를 증가시켜주어야 한다고 믿고 있는데 이는 잘못된 것이다. Shared Pool은 정보의 재사용을 위해 운영하는 것이므로 SQL 실행이 끝났다고 해서 해당 Chunk를 Free List로 반납하지 않는다. 즉, Free Memory가 남아있는 한 계속 소모 시키는 방식으로 사용되므로 오랜 시간동안 운영되어온 시스템에서 Shared Pool의 Free Memory가 매우 적게 남아 있는 것은 그 자체로는 문제가 되지 않으며, 오히려 피크타임이 지난 후에도 많은 양의 Free Memory가 남아있다면 이는 Spare Free 메모리도 다 소모하지 않은 상태로서 불필요하게 많은 메모리가 할당되어 낭비되고 있음을 의미한다. 더구나, Shared Pool 크기가 지나치게 크면 Free Memory를 다 사용할 때까지의 기간이 연장되는 효과는 얻을 수 있겠지만, 시간이 지날수록 Memory의 조각화가 더욱 심해지고 Free List의 길이가 길어져 Free Chunk의 검색과 할당에 걸리는 시간이 지연되므로 오히려 성능이 악화되는 결과를 초래할 것이다.

또한, 메모리 조각화에 따른 영향을 줄이기 위해 오라클은 5000 bytes가 넘는 큰 사이즈의 Chunk만을 위해 전체 Shared Pool의 5% 정도를 따로 관리하는 방법을 사용하고 있는데, 경험적으로 보면 이 공간은 거의 사용되지 않고 버려지고 있는 경우가 많다. 이는 V$SHARED_POOL_RESERVED 뷰의 USED_SPACE 값을 확인해 보면 알 수 있으며, 5000 bytes 이상의 large chunk가 거의 요구되지 않는 환경에서는 오히려 이 크기를 줄여주는 것이 나을 것이다.


■Shared Pool 관련 wait

Shared Pool과 관련하여 흔히 발생하는 Wait은 라이브러리 캐쉬 오브젝트에 대한 동시 액세스와 메모리 할당에 따른 관련 Lock 또는 Latch에 대한 경합이 대부분이며, 구체적인 이름은 다음과 같다. (Latch free 이벤트시 괄호 안의 관련 latch 이름은 v$session_wait의 p2값과 v$latchname의 latch#를 조인하여 얻어낼 수 있다. 1회 SQL 참조)
Latch
Lock
latch free ( library cache )
latch free ( library cache load lock)
 library cache lock, library cache pin
library cache load lock
latch free ( row cache objects )
 row cache lock
latch free ( shared pool )
  

Library cache lock, library cache pin, library load lock은 각각 특정 라이브러리 캐쉬 오브젝트에 대한 검색이나 변경 및 실행 또는 로드 시에 대상 오브젝트에 대해 할당되며, 이러한 Locking 작업은 library cache latch와 library cache load lock latch의 관할 하에 처리된다. Shared pool latch는 Free List나 LRU List를 검색하거나 메모리를 할당하는 작업에 사용되며, row cache lock과 row cache objects latch는 Data dictionary cache 오브젝트에 대한 동시 액세스를 제어하는데 사용된다.

Latch의 개수는 시스템 전체적으로 하나 또는 제한된 개수가 존재하는 것이고 Lock은 대상 오브젝트 각각 대해 할당되는 것이므로, 엄밀하게 말해서 Lock에 대한 경합은 직접적으로는 특정 라이브러리 캐쉬 오브젝트에 대한 동시 액세스로 인해 유발되는 것인 반면에, Latch에 대한 경합은 시스템 전체적으로 관련 오퍼레이션(즉, SQL 파싱) 자체가 지나치게 많이 발생하거나, 짧은 시간 내에 처리되지 못함으로 인해 유발되는 것이라고 구분해볼 수 있다. 그러나, 결국 이 모든 경합은 근본적으로 Shared Pool의 조각화(Fragmentation)에 따른 문제가 주된 원인이며 다시 이러한 조각화는 요청되는 SQL들이 공유되지 못하고 지속적으로 새롭게 파싱되고 메모리가 할당됨으로 인해 발생하는 것이다. 따라서, 이러한 문제를 해결하는 가장 효과적인 방법은 Literal SQL을 바인드 변수를 사용하도록 수정하거나, SQL작성 표준을 마련하고, HOLD_CURSOR/ RELEASE_CURSOR, SESSION_CACHED_CURSORS, CURSOR_SPACE_FOR_TIME, CURSOR_SHARING 등의 파라미터를 활용하는 등의 방법을 통해 SQL의 공유도를 높여주는 것이며, 또한 자주 사용되는 PL/SQL에 대해서는 DBMS_SHARED_POOL 패키지를 사용하여 메모리에서 Flush되지 않도록 보존하는 등의 조치를 취해주면 도움이 될 것이다. SQL의 수정이 어려운 환경이거나 시스템에 요청되는 SQL의 절대량이 확보된 메모리 공간에 비해 많은 상황이라면 주기적으로 피크타임을 피해 Shared Pool을 직접 Flush(alter system flush shared_pool 명령을 사용한다.) 시켜주는 것도 권장할 만한 관리 방법이다. 많은 이들이 우려하는 바와는 달리 Shared Pool을 직접 flush 시키는 것이 심각한 성능상 문제를 야기하지는 않으며 특히 중요한 패키지나 SQL cursor, Sequence 등이 keep되어 있는 경우라면 더욱 그러하다.

가끔 버그를 포함한 특수한 상황에서 특정 라이브러리 캐쉬 오브젝트에 대한 lock이 장시간 해제되지 못하고 있는 경우도 있는데 이때는 X$KGLLK 뷰를 조회하면 library cache lock에 대한 holder/waiter를 확인하여 조치할 수 있다. 또한, Row cache lock에 대한 경합은 Locally managed tablespace를 도입하거나, DML이 빈번한 테이블에 대한 인덱스의 개수를 줄여주는 등의 조치를 통해 완화될 수 있을 것이다.

부연하자면, Shared Pool과 관련된 Wait는 특정 오브젝트 자원에 대한 경합에 의해 발생하기 보다는 애플리케이션의 설계, 보다 단순화시켜 표현하면 Literal SQL에 의한 메모리 조각화에 의해 발생하는 경우가 많다. 따라서, Shared Pool관련 Wait가 많이 발생하여 오라클이 그로 인한 성능상의 문제를 드러낼 때 눈에 띄는 하나의 주범을 찾아내려는 노력은 별 효과를 거두지 못하는 경우가 많으며, 그러한 시점에 DBA가 즉각적으로 취할 수 있는 조치로는 직접 Shared Pool을 Flush 시키는 정도가 있을 것이다. 결국, 평소에 꾸준한 모니터링을 통해 Shared Pool의 적절한 크기와 관련 파라미터 값을 찾아가는 것, 그리고 무엇보다 애플리케이션 측면에서 튜닝 및 수정 작업을 진행함으로써 성능문제를 사전에 예방하는 것이 최선이다.

출처: http://www.oracle.com/technology/global/kr/pub/columns/dbtuning04.html

 

저작자표시

'(DB) Oracle > 기타' 카테고리의 다른 글

Oracle - Top SQL 튜닝하기  (0) 2017.01.22
Oracle - Redo buffer 관련 Wait  (0) 2017.01.22
Oracle - Buffer Cache 관련 Wait  (0) 2017.01.22
Oracle - Enqueue와 Latch 개념 이해하기  (0) 2017.01.22
Oracle - Wait Event 모니터링  (0) 2017.01.22
Posted by 농부지기
,

Oracle - Enqueue와 Latch 개념 이해하기

(DB) Oracle/기타 2017. 1. 22. 17:16

[ Oracle - Enqueue와 Latch 개념 이해하기 ]     

 

☞ [2] Enqueue와 Latch 개념 이해하기

 

DBMS의 가장 주된 기능 중에 하나는 동일 자원에 대한 동시 액세스를 관리하는 것이며, 이를 위해 오라클이 사용하는 대표적인 제어 구조가 Enqueue와 Latch이다.
Enqueue와 Latch는 모두 특정 자원에 대한 접근을 serialize하는 것이 목적이라는 점에서는 같은 Lock의 일종이지만 관리방식이나 용도에서 차이가 있다. Enqueue는 이름에서 보듯 Queue를 통해 관리된다. 대상 자원에 대한 Owner, Waiter, Converter Queue를 관리하면서 먼저 요청한 순서대로 Lock을 획득하도록 하는 구조이며, Exclusive 모드 뿐 아니라 다양한 수준의 공유를 허용한다. 대표적인 것이 테이블 데이터를 Update할 때 사용되는 TM, TX enqueue이다.

반면에, Latch는 Enqueue에 비해 훨씬 단순한 구조로서 매우 짧은 시간 내에 획득되고 해제된다. Queue를 통해 관리되지 않으므로 먼저 Request한 프로세스가 먼저 latch를 획득한다는 보장이 없으며, 대부분의 경우 Exclusive모드로만 획득된다. Latch는 주로 SGA의 특정 메모리 구조체에 대한 액세스(library cache latch, cache buffers chains latch) 혹은 메모리 할당 시 (shared pool latch) 사용되거나 오라클의 중요한 코드가 동시에 수행되지 않도록 하기 위한 용도로(redo writing latch) 사용된다. Latch는 Enqueue보다는 하위 level에서 Locking 자체의 부하를 최소화하며 작동하는 제어 메커니즘이라고 할 수 있으며, 실제로 Enqueue 역시 내부적으로는 Latch (enqueues, enqueue hash chains latch )에 의해 운영된다는 점을 생각하면 둘 사이의 차이를 쉽게 이해할 수 있을 것이다.

■ Enqueue

Enqueue 정보는 내부적으로 Enqueue Resource 배열과 Enqueue Lock 배열에 저장된다. 특정 자원에 대한 Lock이 요청되면 대상을 하나의 Resource로 정의하여 할당하고 그 Resource에 대해 관련 Lock 정보를 Owner, Waiter, Converter가운데 하나로서 Link시키는 방식으로 운영되며, 이러한 정보는 V$RESOURCE와 V$LOCK 뷰를 통해 조회해 볼 수 있다. V$RESOURCE와 V$LOCK은 1:M 관계로 하나의 Resource에 대하여 여러 건의 Lock 레코드가 Owner (LMODE>0, REQUEST=0), Waiter (LMODE=0 ,REQUEST>0), Converter (LMODE>0, REQUEST>0) 중 하나로서 대응된다.
Enqueue Wait이 발생하는 것은 다른 세션이 이미 나보다 먼저 해당 자원에 대한 Lock을 잡고 있으므로 인해 내가 원하는 모드로 Lock을 할당 받을 수 없기 때문이다. 자신이 필요로 하는 Lock의 획득에 실패한 세션은 Owner가 작업을 완료하고 자신을 깨워줄 때까지(세마포어를 포스트해줄 때까지) Waiter 혹은 Converter Queue에서 대기하게 되며, 기다려도 소식이 없으면 3초 간격으로 timeout에 의해 일어나 혹시 Deadlock 상황이 아닌지 점검해 본 후 다시 Sleep에 빠져들기를 반복하게 된다. 튜닝관련 자료를 보다 보면 가끔 Enqueue에 대한 Wait이 많은 경우에 Enqueue_resource나 Enqueue_lock 파라미터를 증가시켜 주어야 한다는 가이드를 보게 되는 경우가 있는데 이 파라미터들은 Enqueue resource와 lock 배열의 크기를 늘려줄 뿐 특정 Enqueue 자원에 대한 동시 경합을 해소시키는 것과는 상관이 없다. Enqueue Wait를 해소하기 위한 구체적인 방법은 Enqueue type에 따라 달라지지만 결국은 Enqueue를 불필요하게 요청하는 경우가 없는지를 살펴 Enqueue에 대한 요청을 최소화하고 Enqueue를 점유하는 시간을 최대한 단축시키는 것이다. TX Enqueue에 대한 Wait은 대상 자원에 대한 Lock을 소유하고 있는 세션과 그 세션이 수행 중인 SQL을 찾아 트랜잭션이 장시간 지속되고 있는 이유가 무엇인지 애플리케이션 측면에서 조사해야 하며, SQ enqueue는 Sequence 값 할당 시 발생하는 경합이므로 cache값을 늘려줌으로써 완화시킨다거나 ST Enqueue의 경합이 존재할 경우에는 Locally managed tablespace를 사용하거나 Initial, Next 등의 extent 크기를 적당한 값으로 조정하여 실시간 공간할당을 감소시켜주는 등의 방법들이 Enqueue Wait에 대처하는 대표적인 사례이다. 지난 호에서 소개한 Session Waiter 스크립트는 Enqueue Wait 이벤트에 대해서 Enqueue type과 모드를 함께 표시하여 주도록 하고 있으며, 참고로 Enqueue type별 누적 Wait현황을 확인하고자 하면 아래 SQL을 수행하면 된다.


select q.ksqsttyp type,
           q.ksqstget gets,
           q.ksqstwat waits,
            round(q.ksqstwat/q.ksqstget,3) waitratio
       from sys.x$ksqst q
where q.inst_id = userenv('Instance')
      and q.ksqstget > 0
order by waits desc
/


■ Latch

오라클 운영 시에 하위레벨에서 내부적으로 처리되는 다양한 조작들이 latch의 관할 하에 수행되는데 V$LATCHNAME을 조회해보면 (9i 기준으로) 239 종류나 되는 Latch가 존재하는 것을 확인할 수 있다. 이 가운데 우리가 자주 접하게 되는 latch는 다음과 같은 정도이며 각 Latch의 기능은 관련 SGA별 Wait를 다룰 때 간단하게나마 소개하도록 하겠다.

Shared pool
library cache latch, shared pool latch, row cache objects
Buffer Cache
 cache buffers chains latch, cache buffers lru latch, cache buffer handle
Redo log
 redo allocation latch, redo copy latch, redo writing latch
OPS
 dlm resource hash list


▷ Willing to wait 모드와 No-wait 모드

Latch 획득 방식은 No-wait과 Willing to wait 의 두 가지 모드로 구분할 수 있다. Willing to wait 모드는 Latch의 획득에 실패하면 좀더 시간을 끌면서 해당 Latch를 잡을 때까지 재시도를 해보는 방식을 말한다. 일차적으로는 CPU를 놓지 않고 정해진 횟수만큼 Spinning을 한 후 재시도를 해보다가 그래도 실패하면 CPU를 놓고 Sleep하다가 timeout되어 재시도하는 작업을 반복하면서 Latch의 획득을 노력하게 된다. Latch가 sleep에 들어가게 되면 'latch free' wait event 대기가 시작된다. sleep의 지속시간은 sleep 횟수가 늘어갈수록 점점 길어지게 되는데, 따라서 V$LATCH의 Gets와 Sleeps의 비율과 함께 Sleep1~sleep4 항목에서 몇차 Sleep까지 발생했는지 여부도 각 Latch Wait의 심각성을 판단하는 요소 가운데 하나가 된다.

No-wait 모드는 Willing to wait과는 달리 더 이상 미련을 두지 않고 해당 Latch에 대한 획득을 포기하는 것이다. No-wait 모드가 사용되는 경우는 두 가지가 있는데, 하나는 동일한 기능을 하는 Latch가 여러 개 존재하여 그 중에 하나만 획득하면 충분하여서 특정 Latch에 미련을 가질 필요가 없는 경우이다. 물론, 이 때에도 같은 기능의 모든 Latch에 대한 시도가 실패로 끝날 경우에는 Willing to wait 모드로 요청을 할 것이다. No-wait 모드가 사용되는 다른 한가지 경우는 dead lock을 피하기 위해서 이다. 오라클은 기본적으로 latch dead lock 상황을 피하기 위하여 모든 Latch에 level을 부여하여 정해진 순서를 따라서만 Latch를 획득하도록 하고 있는데, 필요에 의해 이 규칙을 어기고 Latch를 획득하고자 할 경우 일단 No-wait 모드로 시도를 해보는 것이다. 다행히 Latch를 잡으면 좋은 것이고 비록 latch를 잡을 수 없더라도 무한정 기다림으로써 dead lock 상태에 빠지는 일은 피할 수 있는 것이다. No-wait 모드의 Latch작업에서는 당연히 Latch 관련 wait이 발생하지 않으며, redo copy latch를 제외하고는 Willing to wait 모드로 Latch를 획득하는 경우가 훨씬 많다.

▷ Parent latch와 Child latch

Latch 가운데에는 동일 기능을 하는 Child latch들의 set으로 운영되는 Latch도 있으며 하나의 Latch로만 운영되는 Latch도 있다. 전자의 대표적인 예로는 cache buffers chains (버퍼캐쉬 블록 들을 같은 이름의 다수의 Latch가 나누어 담당)가 있으며, 후자의 예로는 shared pool latch (shared pool내에서 메모리 할당을 위해 획득해야 하는 Latch로 시스템에 하나만 존재)가 있다. 이와 같은 Latch 관련 통계 정보는 Parent latch와 Child latch의 개념으로 관리가 되는데 Latch set에서 개별 Child latch에 대한 통계정보는 V$LATCH_CHILDREN 뷰를 통해 조회할 수 있으며, 단일 Latch 혹은 Latch set의 마스터 Latch (parent)에 대한 통계정보는 V$LATCH_PARENT 뷰를 통해 조회할 수 있다.

지금까지 한 회 분량을 할애하여 Enqueue와 Latch에 대해 요약해본 이유는, 많은 Waiting이 SGA내의 공유자원 (Block, Cursor 등)에 대한 경합으로 인해 발생하며 이러한 경합은 다시 해당 자원에 대한 동시 액세스를 제어하는 Enqueue와 Latch에 대한 경합으로 흔히 드러나게 되므로 오라클의 Wait Event를 모니터링하기 위해서는 Enqueue와 Latch의 구조와 작동원리에 대해 이해하는 것이 필수적이기 때문이다.
 

출처: http://www.oracle.com/technology/global/kr/pub/columns/dbtuning04.html

저작자표시

'(DB) Oracle > 기타' 카테고리의 다른 글

Oracle - Top SQL 튜닝하기  (0) 2017.01.22
Oracle - Redo buffer 관련 Wait  (0) 2017.01.22
Oracle - Buffer Cache 관련 Wait  (0) 2017.01.22
Oracle - Shared Pool 관련 Wait  (0) 2017.01.22
Oracle - Wait Event 모니터링  (0) 2017.01.22
Posted by 농부지기
,

Oracle - Wait Event 모니터링

(DB) Oracle/기타 2017. 1. 22. 17:15

[ Oracle Wait Event 모니터링 ]

 

☞ [1] Oracle Wait Event 모니터링

  흔히 DBA를 3D업종이라고 부르는 이유 가운데 하나는 몸은 고달픈데 반해 그 성과가 별로 티가 나지 않는다는 사실 때문일 것이다. 실제로, DBA가 수행해야 하는 일상적인 관리 업무들은 몸은 다소 피곤하게 만들지 몰라도 어느 정도 경험이 쌓이면 그리 부담을 주는 일은 아니다. 우리가 한단계 업그레이드된 전문가로서 인정 받는 DBA가 되기 위해서는 장애상황 혹은 유사 장애 상황에서 DB 모니터링 작업을 수행하고 분석할 수 있어야 한다. 시스템이 갑자기 느려지고 업무가 마비되는 상황에 맞닥뜨렸을 때 문제의 원인이 무엇인지를 집어낼 수 있는 능력이 있어야 하며 최소한 오라클의 문제인지 아닌지를 판단할 수는 있어야 몸으로 야간작업이나 때우는 DBA가 아니라 조직에 없어서는 안될 전문가로서의 나의 존재가치를 인정 받을 수 있을 것이다.

이 글에서는 오라클 Wait Event에 대하여 간단히 알아보고 일시적인 성능저하 상황에서 Wait Event를 모니터링하고 그 원인을 찾아가는 방법에 대하여 다루어 보고자 한다. 짧은 지면 위에 다룰 수 있는 내용도 제한되어 있고 글쓴이의 지식 또한 일천하지만 오라클 전문가가 되기 위해 같은 길을 가고 있는 동료로서 가진 지식 몇 가지 공유한다는 취지로 이 글을 쓴다.
오라클의 Wait Event 정보는 V$SYSTEM_EVENT, V$SESSION_EVENT, V$SESSION_WAIT 등이 있는데, 이 가운데 V$SESSION_WAIT는 각 세션이 현재 Waiting 하고 있는 Event나 마지막으로 Wait한 Event 정보를 보관하고 있으며, V$SYSTEM_EVENT와 V$SESSION_EVENT는 시스템이 Startup된 이후 각각 시스템 전체, 혹은 세션별로 발생한 Wait Event 정보를 누적하여 기록하고 있다.

오라클의 Wait Event는 성격에 따라 Network교신이나 IO를 위해 대기하는 일상적인 Wait와 특정 자원에 대해 여러 프로세스가 동시에 액세스하고자 할 때 발생하는 Wait, 별달리 할 일이 없어 대기하고 있는 Idle Wait 등 세가지 유형으로 구분할 수 있는데 그 유형에 따라 해석방법도 달라진다. 일단, Idle Wait는 일반적인 관심의 대상에서 제외되며 IO나 Network 관련 Wait는 작업량이 증가하면 같이 증가하는 Wait이므로 전체 서비스 시간(CPU time)과 비교하여 상대적으로 평가해야 하며 총 Wait time보다는 평균 Wait Time에 관심을 두고 분석을 해야 할 것이다. 시스템 자원에 대한 Wait는 데이터베이스 서버 튜닝시 가장 주된 관심 대상이 되며 이들 Wait에 대해서는 평균 Wait Time뿐만 아니라 총 Wait Time에도 관심을 가지고 분석해야 할 것이다. 유형별로 대표적인 Wait Event를 살펴본다면 아래와 같다.

☞ [주요 Wait Event]

 
구분
이벤트명
설 명

일상적인
   Wait Event

db file scattered read Full Scan시 OS에 I/O를 요청해놓고 대기
db file sequential read Index Scan시 OS에 I/O를 요청해놓고 대기
(IO, Network) log file sync 변경 log buffer를 log file에 반영하는 동안 대기
DFS lock handle OPS 환경에서 노드간 분산 Lock 교환에 따른 대기
global cache cr request OPS 환경에서 노드간 Buffer Block 교환에 의한 대기
자원 경합에 따른
Wait Event 		 enqueue Type에 따라 세분화 (24개의 enqueue type (9i))
latch free Name에 따라 세분화 (239개의 latch가 존재 (9i))
buffer busy waits 동일블록에 대한 동시 액세스에 따른 경합
free buffer waits free buffer를 할당위해 DBWR의 Write를 대기
Log buffer space Log buffer를 할당 받기 위해 LGWR의 write를 대기
library cache lock SGA내의 library cache를 참조하기 위한 대기(검색)
row cache lock SGA내의 dictionary cache를 참조하기 위한 대기
Idle Event  SQL*Net message from client Client로부터의 작업요청을 대기
Pmon timer PMON이 할일 없을 때 대기하는 Event

 

☞ 업무시간대에 시스템이 갑자기 느려졌다면서 오라클 서버에 문제가 없는지 문의가 들어오면 글쓴이는
   우선 아래의 SQL을 수행시켜본다.

 
select /*+ ordered / distinct /* 속도를 위해 v$sql을 조인할 경우 중복되는 레코드 제거 */
       s.sid SID, s.username, s.program, p.spid "OS-Pid",w.seconds_in_wait as "W_time(Sec)",
      decode(w.wait_time,0,'Wai-ting', 'Waited') Status, w.ename event,
--              p1text || ':' || decode(event,'latch free',p1raw, to_char(p1)) ||','||
--              p2text || ':' || to_char(p2) ||','|| p3text || ':' || to_char(p3) "Additional Info",
           q.sql_text
from ( select a.*, decode(a.event,'latch free', 'latch free (' ||b.name||')',
                           'row cache lock', 'row cache lock (' || c.parameter || ')',
                            'enqueue', 'enqueue ('||chr(bitand(p1, -16777216)/16777215)||
                                                    chr(bitand(p1,16711680)/65535)||':'||
                    decode(bitand(p1,65535), 1, 'N', 2, 'SS',3,'SX',4,'S',5,'SSX',6,'X') ||')',
                             a.event ) ename
       from  v$session_wait a, v$latchname b, v$rowcache c
       where a.p2 = b.latch#(+) and a.p1 = c.cache#(+) and c.type(+) = 'PARENT'
       and   a.event not in ('rdbms ipc message','smon timer','pmon timer','slave wait',
                              'pipe get','null event',
                     'SQL*Net message from client', 'SQL*Net message to client','PX Idle Wait',
                     'PX Deq: Execution Msg', 'KXFQ: kxfqdeq - normal deqeue',
                     'ges remote message', 'wakeup time manager', /* idle event 적절히 수정 */
                     'lock manager wait for remote message', 'single-task message')
        ) w, v$session s, v$process p, v$sql q
where w.sid = s.sid and s.paddr = p.addr
and s.sql_hash_value = q.hash_value(+) and s.sql_address = q.address(+)
order by w.ename;
SQL의 구체적인 내용이야 필요한 정보와 개인적 취향에 따라 달라지겠지만, 중요한 것은 일단 V$SESSION_WAIT 뷰로부터 실시간 Wait Event 정보를 얻어낸다는 것이다. 위 SQL을 수행했을 때 나타나는 결과가 없다면 일단 오라클 측면에서 업무성능을 심각하게 마비시키는 Waiting이 발생하고 있지 않다고 봐도 큰 무리가 없을 것이다.

일반적인 상태에서는 주로 'db file sequential read'나 'db file scattered read' 가 나타날 텐데, 이러한 Wait Event는 보통 짧은 시간 동안 지속되며 대상 자원(블록)을 바꿔가며 Wait가 반복되는 형태로 나타날 것이다. 이는 작업 처리량이 많을 때 일상적으로 발생하는 IO관련 Wait Event이므로 해당 세션에서 IO를 제법 많이 유발하고 있다는 정도로 이해하고 넘어가면 될 것이다. 물론, Wait의 지속시간이 길거나 지나치게 빈번히 나타나는 SQL에 대해서는 비효율적인 실행계획을 수립하고 있지 않은지 검토해서 튜닝해 주어야 한다.

성능저하의 원인이 오라클 쪽에 있는 경우에는 특정 자원에 대한 Waiting이 상당히 오랫동안 지속되어 현재까지 Waiting이 진행 중인 세션들(STATUS가 'Wai-ting' (wait_time=0)이며 'W_time(sec)' (seconds_in_wait) 값이 상당히 큰 세션)이 존재할 가능성이 높다. 오라클의 내부적인 작업들은 매우 짧은 기간에 처리되어야 하므로, Idle event(where절에서 not in으로 처리한 부분, 버전에 따라 달라질 수 있다.) 이외의 특정 Wait Event가 눈에 띌 정도로 검출된다는 것은 오라클 내부적으로는 훨씬 더 많은 Waiting이 발생하고 있다고 생각해야 한다. 바로 이런 세션들이 문제의 범인들이며 이제부터 DBA는 이들 Wait Event에 대한 원인을 파악하여 조치하는 작업을 해주어야 한다. 각각의 Wait Event에 따라 원인을 추적하고 조치하는 방법은 달라질 것이다.

다음 호에서는, 자주 경험하는 몇가지 대표적인 Wait Event들에 대하여 SGA 영역별로 구분하여 좀 더 자세히 살펴보고, 그에 앞서 Lock 또는 Latch Event의 이해를 위해 필요한 Enqueue와 Latch의 개념을 간단히 알아보도록 하겠다.
 

 

저작자표시

'(DB) Oracle > 기타' 카테고리의 다른 글

Oracle - Top SQL 튜닝하기  (0) 2017.01.22
Oracle - Redo buffer 관련 Wait  (0) 2017.01.22
Oracle - Buffer Cache 관련 Wait  (0) 2017.01.22
Oracle - Shared Pool 관련 Wait  (0) 2017.01.22
Oracle - Enqueue와 Latch 개념 이해하기  (0) 2017.01.22
Posted by 농부지기
,

Oracle - System Table 사용예제

(DB) Oracle/System Table 2017. 1. 22. 17:15

[ Oracle - System Table 사용예제   ]    

 

☞ Dictionary Table

 

SELECT *   FROM 　　 DICTIONARY ;
 - 사용자가 소유한 모든 데이터 사전 뷰 :
     SELECT table_name FROM dictionary WHERE table_name LIKE 'USER%';


☞ physical I/O가 많은 상위 10개 테이블 조회하기

 

select table_name,total_phys_io
from ( select owner||'.'||object_name as table_name,
               sum(value) as total_phys_io
         from   v$segment_statistics
         where  owner!='SYS' and object_type='TABLE'
         and  statistic_name in ('physical reads','physical reads direct',
                                 'physical writes','physical writes direct')
         group by owner||'.'||object_name
         order by total_phys_io desc )
 where rownum <=10;


☞ DBA권한을 가진 계정 검색

 

select * from dba_role_privs where granted_role='DBA'


 

저작자표시

'(DB) Oracle > System Table' 카테고리의 다른 글

Oracle - System_Table_List  (0) 2017.01.22
Oracle - User_Schema_List  (0) 2017.01.22
Posted by 농부지기
,

Oracle - Lock걸린_자료조회

(DB) Oracle/튜닝 및 조작 2017. 1. 22. 17:14

[ Oracle - Lock걸린_자료조회 ]

 

저작자표시

'(DB) Oracle > 튜닝 및 조작' 카테고리의 다른 글

Oracle - 여러 가지 조작  (0) 2017.01.22
Oracle - Lock List 보기 및 Lock 해제  (0) 2017.01.22
Oracle - DBA Scripts  (0) 2017.01.22
Oracle - Optimizer  (0) 2017.01.22
Oracle - HINT  (0) 2017.01.22
Posted by 농부지기
,

Oracle - System_Table_List

(DB) Oracle/System Table 2017. 1. 22. 17:13

[ Oracle - System_Table_List ]

 

1. constraint_name  : constraint 즉 forign key 리스트

    user_constraints :

 

2. V$SGA,    V$INSTANCE,     V$PARAMETER,      V$SESSION,     V$OPTION,      V$VERSION,      V$PROCESS

    

   

   

      http://www.databaser.net/oracle/often_ref_dictionary.htm  

 

-- 테이블 정보보기

--예)

SELECT

      A.TABLE_NAME

     , C.COMMENTS

     , A.COLUMN_NAME

     , A.DATA_TYPE

     , A.DATA_LENGTH

     , B.COMMENTS

     , A.COLUMN_ID

FROM DBA_TAB_COLUMNS A, DBA_COL_COMMENTS B, DBA_TAB_COMMENTS C

WHERE A.TABLE_NAME = B.TABLE_NAME

AND A.TABLE_NAME = C.TABLE_NAME

AND B.TABLE_NAME = C.TABLE_NAME

AND A.COLUMN_NAME = B.COLUMN_NAME

 

 

--

 

select  b.status, b.server, b.schemaname, b.osuser, b.machine, b.program, c.spid

from    v$session b, v$process c

where   b.schemaname = 'HRMS'

and     b.paddr = c.addr

and     b.sid in (select distinct sid from v$lock);

 

select b.sid, b.username, b.machine, b.process, b.program, a.sql_text

from   v$sql a, v$session b

where  a.address = b.sql_address

and    a.hash_value = b.sql_hash_value

and    b.sid in ('79');

저작자표시

'(DB) Oracle > System Table' 카테고리의 다른 글

Oracle - System Table 사용예제  (0) 2017.01.22
Oracle - User_Schema_List  (0) 2017.01.22
Posted by 농부지기
,

Oracle - User_Schema_List

(DB) Oracle/System Table 2017. 1. 22. 17:12

[ Oracle - User_Schema_List ]

☞ 목록

All_all_tables

user가 access할수있는 모든 Table  (속성:tablespace등)

All_catalog

user가 access할수있는 모든 Table, Views, synonyms, sequence

All_clusters

user가 access할수있는 모든 clusters

All_col_comments

user가 access할수있는 모든 Table,Views에 대한 칼럼comments

All_col_privs

user에게 또는 Public에게 허용된 모든 칼럼에 대한 권한.

All_col_privs_made

user가 부여한 칼럼에 대한 권한.

All_col_privs_recd

user에게 또는 Public에게 허용된 모든 칼럼에 대한 권한.

All_coll_types

user가 access 할수 있는 모든 collection type

All_cons_columns

제약조건에 관련된 칼럼, access할수 있는 대한 정보

All_constraints

access할수 있는 테이블에 대한 제약조건.

All_db_links

user가 access 할수 있는 데이터베이스 link

All_def_audit_opts

오브젝트가 생성될때 적용될수있는 default오브젝트감사내용.

All_dependencies

user가 access할수있는 오브젝트간의 dependencies(참조,link)

All_directories

user가 access할 수 있는 모든 directories (owner 는 항상 sys)

All_errors

user가 access할수있는 모든 objects(view,procedure,package, function,packagebody) 에 대한 에러.

All_ind_columns

user가 access할수있는 테이블에 대한 인덱스의 칼럼.

All_ind_partitions

user가 access할수있는 인덱스partition, partition에 대한 storage매개변수, Analyze명령에 의해 결정된 partition통계.

All_indexes

user가 access할수있는 테이블의 인덱스. 이 view의 통계를 수집하기위해, Analyze명령을 사용한다. 병렬partition인텍스탐색을 지원한다.

All_labels

system labels 에 대한 Oracle server view.

All_libraries

user가 access할 수 있는 모든 libraries.

All_lobs user

가 access할 수 있는 모든테이블에 포함된 LOBs.

All_lobs user

가 access할 수 있는 모든테이블에 포함된 LOBs.

All_method_params

user가 access할 수 있는 method와 그method의 parameter.

All_method_results

 

All_nested_tables

user가 access할수있는테이블내의 Nested Table

All_object_tables

user가 access할수있는테이블의모든정보.

All_objects

user가 access할수있는objects(index partition,table partition,package,package body, trigger)

All_part_col_statistics

user가 access할 수 있는 테이블partition에 대한 칼럼통계와 막대그래프화된 정보.

All_part_histograms

user가 access할수있는 테이블partition의 histograms에 대한 histogram정보.

All_part_indexes user

가 access할수있는 모든partition된 index의 partition정보.

All_part_key_columns

user가 access할수있는 partition된 objects의 partition key 칼럼에 대한정보

All_part_tables

user가 access할수있는partition된 Table에 대한 partition정보.

All_refresh

user가 access할수있는모든 refresh groups.

All_refresh_children

user가 access할 수 있는 refresh groups 안의 모든objects

All_refs

user가 access할 수 있는 칼럼중 REF칼럼과, REF속성.

All_registered_snapshots

모든 등록된 snapshots.

All_sequences

user가 access할수있는 sequences.

All_snapshot_logs

모든 snapshot logs.

All_snapshot_ref

resh_times 모든 snapshot refresh times.

All_snapshots

user가 acces할수있는 모든 snapshots.

All_source

user가 access할수있는 모든 stored objects의 text source.

All_synonyms

user가 access할수있는 모든 synonyms.

All_tab_col_statistics

'User_tab_columns' view안의 정보에대한 칼럼통계와 그래프정보

All_tab_columns

user가 access할수있는모든 table, views, clusters에 대한 칼럼. 이 view를 활용하기위해서는 Analyze명령어를 사용한다.

All_tab_comments

user가 access할 수 있는 모든 table, views에 대한 comments.

All_tab_histograms

user가 access할수있는table, views에 대한 histograms.

All_tab_partitions

user가 access할수 있는 각각의 테이블partition에 대한 partition정보, storage parameter, Analyze명령에 의한 통계정보등을 서술한다.

All_tab_privs

user혹은 PUBLIC가 부여받은 오브젝트권한.

All_tab_privs_made

user가 부여한 user권한과 오브젝트권한.

All_tab_privs_recd

user 또는 PUBLIC이 부여받은 오브젝트권한.

All_tables

user가 access할 수 있는 모든 테이블. Analyze명령으로 이 view의 통계를 얻을 수 있다.

All_triggers

user소유의 trigger, user소유테이블의 trigger, 또는 user가 CREATE ANY TRIGGER 권한을 갖고있다면, 모든 트리거에 대한 정보.

All_trigger_cols

user소유의 trigger, user소유테이블의 trigger, 또는 user가 CREATE ANY TRIGGER 권한을 갖고있다면, 모든 트리거에 대한 칼럼정보.

All_type_attrs

user가 access할 수 있는 type의 attributes.

All_type_methods

user가 access할수있는type의 methods.

All_types

user가 access할 수 있는 type.

All_updatable_columns

join view에서 update가능한 칼럼에 대한 정보.

All_users

데이터베이스의 모든 user에 대한 정보.

All_views

user가 access할수있는view의 텍스트.

Audit_actions

감사추적type코드 정보.

 

catalog Oracle 5.0 version과의 호환정보를 포함한다. 이 view의 사용은 추천할만하지 못하다.

cat user_catalog 에 대한 synonym.

chained_rows ANALYZE LIST CHAINED ROWS 명령에 대한 default table.

clu user_clusters 테이블의 synonym.

code_pieces dba_object_size 와 user_object_size view를 create 시에 사용됨.

code_size dba_object_size 와 user_object_size view를 create 시에 사용됨.

col Oracle 5.0version 호환정보를 포함하고 있다.

cols user_tab_columns view 의 synonym.

column_privileges user가 부여한권한,부여받은권한, owner인권한, 또는 PUBLIC에게 부여받은 권한에 대한 칼럼정보.

   
   
☞ 목록

Dba_2pc_neighbors

진행중인 트랜잭션에 대한 연결 및 종료에 대한 정보.

Dba_2pc_pending

recovery를 기다리는 분산된트랜잭션에 대한 정보.

Dba_all_tables

데이터베이스내의 모든테이블(object table, relational table).

Dba_audit_exists

UDIT NOT EXISTS and "AUDIT EXISTS"에 의해 생성된 감사추적요소.

Dba_audit_object

시스템내의 모든 object에 대한 감사추적기록.

Dba_audit_session

세션연결과 종료에 관련된 모든 감사 추적기록.

Dba_audit_statement

GRANT, REVOKE, AUDIT, NOAUDIT, ALTER SYSTEM 관련된 감사추적기록.

Dba_audit_trail

모든 감사추적요소.

Dba_blockers

누군가가 스스로 걸지않은 lock이 해제되기를 기다리는 session정보.

Dba_catalog

모든 데이터베이스 table, views, synonyms 과 sequence에 대한 정보.

Dba_clu_columns

cluster칼럼과 table칼럼의 mapping정보.

Dba_clusters

데이터베이스내에 있는 모든 cluster.

Dba_col_comments

데이터베이스내의 모든 table, views의 칼럼에대한 comments.

Dba_col_privs

데이터베이스내의 칼럼에 대한 모든권한.

Dba_coll_types

데이터베이스내의 모든 collection type, VARRAYs, nested tables,object tables 등에 대한 정보.

Dba_constraints

모든테이블에 대한 constraint(primary, check, unique,referential integrity, with check option on a view, with read only on a view) 정보.

Dba_cons_columns

constraint 정의안에 있는 access가능한 칼럼에 대한 정보.

Dba_data_files

데이터베이스파일에 관한 정보.

Dba_db_links

데이터베이스내의 모든 Link.

Dba_Ddl_locks

데이터베이스내의 모든 DDL lock과 DDL lock이 현저하게 요구되는 사항에 관한정보.

Dba_dependencies

object 에 대한 Dependence.(REF, HARD)

Dba_directories

데이터베이스내의 모든 directory objects.

Dba_Dml_locks

데이터베이스내에 구성된모든 DML lock과 DML lock이 현저하게 요구되는사항에 관한정보.

Dba_errors

데이터베이스내의 저장된 object에 대해 가장최근에 발생된 error.

Dba_exp_files

export파일에 대한 정보.

Dba_exp_objects

점진적으로 export 되고있는 object에 대한 정보.

Dba_exp_version

가장최근에 export된 session에 대한 version 정보.

Dba_extents

데이터베이스내의 모든 세그먼트를 이루는 extents에 대한 정보.

Dba_free_space

모든 테이블스페이스내의 free extents의 정보.

Dba_free_space_coalesced

테이블스페이스내의 합쳐진 공간에 대한 통계정보.

Dba_indexes

데이터베이스내의 모든 index. 통계정보를 얻기위해 Analyze를 사용.

Dba_ind_columns

모든테이블과 클러스터에서 인덱스를 구성하는 칼럼에 대한정보.

Dba_ind_partitions

각각의 index파티션에 대해서, 파티션정보, 파티션에대한 storage 매개변수, Analyze에 결정된 파티션통계자료.

Dba_jobs

데이터베이스에 있는 모든 Jobs.

Dba_jobs_running

데이터베이스내에 현재 실행중인 모든 Jobs.

Dba_libraries

데이터베이스내의 모든 libraries.

Dba_lobs

모든 테이블에 포함된 LOBs.

Dba_locks

데이터베이스내에 생성된 모든 lock, latch과 lock,latch가 현저하게 요구되는 사항에 대한 정보.

Dba_method_params

데이터베이스내에 type에 대한 method 매개변수.

Dba_method_results

데이터베이내에 type에 대한 method results.

Dba_nested_tables

모든테이블내에 포함된 nested table에 대한 정보.

Dba_object_size

PL/SQL object에 대한 size, bytes.

Dba_object_tables

데이터베이스내에 모든 object tables.

Dba_objects

데이터베이스내에 모든 objects.(index partition, table partition, package,package_body,trigger)

Dba_obj_audit_opts

모든 table, view에 대한 감사 option.

Dba_part_col_statistics

모든 table 파티션에 대한 칼럼통계와 그래프정보.

Dba_part_histograms

모든 table 파티션의 histogram에 대한 데이터(endpoint).

Dba_part_indexes

모든 partition index에 대한 정보.

Dba_part_key_columns

모든 partition된 object에 대한 분할키칼럼정보.

Dba_part_tables

모든 partition된 table에 대한 정보.

Dba_priv_audit_opts

시스템과 user에 의해 감사를 받고있는 시스템 privileges.

Dba_profiles

모든 profiles과 해당 profile의 limit을 나타냄.

Dba_queue_schedules

메시지를 전달하는 schedule.

Dba_queue_tables

데이터베이스내에 생성된 모든 queue테이블의 queue type의 name과 type.

Dba_Queus

데이터베이스내의 모든 queue에 대한 동작특성.

Dba_rchild

refresh group 안의 모든 children object.

Dba_refresh

모든 refresh group 에 대한 정보.

Dba_refresh_children

refresh group 안의 모든 object에 대한 정보.

Dba_refs

데이터베이스내의 모든 테이블의 REF칼럼과, REF 속성을 가진 칼럼.

Dba_refistered_snapshot_groups

모든 snapshot 사본 그룹.

Dba_registered_snapshots

지역테이블의 원격snapshot 에 대한 정보.

Dba_rgroup

모든 refresh group.

Dba_roles

모든 데이터베이스내에 존재하는 roles.

Dba_role_privs

user와 role에 부여된 role에 대한 정보.

Dba_rollback_segs

rollback segments 에 대한 정보.

Dba_segments

모든 데이터베이스 segment에 대한 할당된 storage에 대한 정보.

Dba_sequences

모든 데이터베이스내의 sequences 에 대한 정보.

Dba_snapshot_logs

모든 데이터베이스내의 snapshot_logs.

Dba_snapshot_refresh_times

snapshot refresh 한 시간.

Dba_snapshots

모든 데이터베이스내의 snapshots.

Dba_source

모든 데이터베이스내의 저장object 의 source를포함.
                  view, function, procedure 에 대한 source 관리

Dba_stmt_audit_opts

system, user에 의한 현재의 감사option에 대한 정보.

Dba_synonyms

데이터베이스내의 모든 synonyms

Dba_sys_privs

user에게 부여된 system privilege와 role.

Dba_tab_col_statistics

Dba_tab_columns view에 있는정보에 대한 칼럼통계와 그래프정보

Dba_tab_columns

모든 table, view, cluster에 대한 칼럼정보. Analyze명령어사용.

Dba_tab_comments

데이터베이스내의 모든 table, view에 대한 주석.

Dba_tab_histograms

모든 table의 칼럼에 대한 histogram.

Dba_tab_partitions

각각의 table partition에 대해서, partition level의 partition정보와, partition의 storage매개변수 ,Analyze 에의해 결정된 여러 partition통계정보.

Dba_tab_privs

모든 데이터베이스내의 object에 부여된 권한.

Dba_tables

모든 데이터베이스내의 관계형테이블에 관한정보.Analyze로 통계정보를 얻을수 있다.

Dba_tablespaces

모든 테이블스페이스에 관한정보.

Dba_triggers

모든 데이터베이스내의 trigger 정보.

Dba_trigger_cols

모든 trigger에서 사용된 칼럼정보.

Dba_ts_quotas

모든 user에게 할당된 tablespace.

Dba_type_attrs

데이터베이스내의 type에 대한 속성.

Dba_type_methods

데이터베이스내의 모든 type에 대한 methods.

Dba_types

데이터베이스내의 모든 추상적데이터type.

Dba_updatable_columns

join view에서 데이터베이스관리자가 update할수있는칼럼정보.

Dba_users

데이터베이스내의 모든 user정보.

Dba_views

모든 데이터베이스내의 view의 text.

Dbms_alert_info

등록된 alert정보.

 

 

Dbms_lock_allocated 사용자에게 할당된 lock정보.

Deptree utldtree.sql 에의해 생성되며, object의 dependency tree정보를 포함함. 'Sys' user인 경우. 이 object에 관련된 공유커서를 나타내고, 다른 user인 경우공유커서이외의 object를 나타낸다. 다른 user는 공유커서정보를 얻기위해, Sys.deptree를 access할수있다.

Dictionary data dictionary table, view에 대한 정보.

Dict_columns data dictionary table, view에 대한 칼럼.

Error_size Dba_obejct_size 와 user_obejct_size view를 create 할때 사용된다.

Exceptions 무결성제약조건에 위배되는 정보를 포함. utlexcpt.sql 로 생성.

File_lock 병렬서버view. 초기화파라미터 GC_FILE_TO_LOCKS 에 명시된, 데이터파일에 PCM lock의 mapping정보.

File_ping 병렬서버view.각데이타파일에 할당된 block의 수. GC_FILES_TO_LOCKS 최적값을 구하기 위해 현존하는 데이터파일의 access방법을 결정하는데 이 정보를사용할 수 있다.

FILEXT$ DBA_DATA_FILES 와 동일. (DBA_DATA_FILES의 사용을 추천)

GLOBAL_NAME 현제 데이터베이스의 유일한 이름.

HS_ALL_CAPS 모든 비 Oracle Data store (FDS) 와 관련된 특성에 관한정보.

HS_ALL_DD 모든 비 Oracle Data store(FDS)에 대한 Data dictionary.

HS_ALL_INITS 비 Oracle Data store(FDS)에 대한 초기화 매개변수.

HS_BASE_CAPS 비 Oracle Data store(FDS)에 대한 기본특성에 관한정보.

HS_BASE_DD 비 Oracle Data store(FDS)에 대한 Data dictionary.

HS_CLASS_CAPS 비 Oracle Data store(FDS)에 포함된 class-specific 특성정보.

HS_CLASS_DD 비 Oracle Data store(FDS) class_specific data dictionary.

HS_CLASS_INIT 비 Oracle Data store(FDS) class-specific 초기화 매개변수.

HS_EXTERNAL_OBJECT_PRIVILEGES user에게 부여된 object권한.

HS_EXTERNAL_OBJECTS oracle server에서 access가능한 external obejct.

HS_EXTERNAL_USER_PRIVILEGES 어느 특정object에 국한되지않은 모든 부여된권한

HS_FDS_CLASS 비 oracle (FDS) class 에 관한 정보.

HS_FDS_INST 비 oracle (FDS) instance에 관한정보.

HS_INST_CAPS instance-specific 특성정보.

HS_INST_DD 비 oracle (FDS) instance-specific data dictionary 변경정보.

HS_INST_INIT 비 oracle (FDS) instance-specific 초기화 매개변수정보.

IDEPTREE UTLDTREE.sql 로 생성하고, 관련tree를 나타냄. Deptree의 자동정렬버젼.

INDEX_HISTOGRAM Analyze index...validate structure 명령에 대한정보.

INDEX_STATS 마지막 Analyze index..validate structure 명령에 대한정보.

NLS_DATABASE_PARAMETERS 데이터베이스의 NLS 매개변수.

NLS_INSTANCE_PARAMETERS instance의 NLS 매개변수.

NLS_SESSION_PARAMETERS user session의 NLS 매개변수.

OBJ user_objects 의 synonym.

PARSED_PIECES Dba_object_size, User_object_size view를 생성시에 필요.

PARSED_SIZE Dba_obejct_size, User_object_size view를 생성시에 필요.

Plan_table explain plan의 결과에 대한 table. utlxplan.sql로 생성.

Product_component_version Oracle 제품군의 버전과 상태설명.

Pstubtbl Pstub utility에 의해 생성된 stub에 관한정보.

Publicsyn public synonym 에 관한 정보.

Public_dependency object와 관련된 dependencies.(parent object)

Resource_cost 각각의 resource에 대한 cost.

Resource_map 각각의 resource에 대한 정보.(resource name, resource number)

Role_role_privs 다른 role에 부여된 role정보.(user가 access가능한 role에 한해)

Role_sys_privs 다른 role에 부여된 system role정보(user가 access가능한role에 한해)

Role_tab_privs 다른 role에 부여된 table privileges정보.(user가 access가능한role에 한해)

SEQ user_sequences 의 synonym.

Session_privs 현재 user에게 사용가능한 권한.

Session_roles 현재 user에게 사용가능한 roles.

Source_size Dba_object_size, User_object_size view를 생성시 필요.

Stmt_audit_option_map 감사 option type code정보.

Syn user_synonyms 에 대한 synonym.

Synonyms Oracle ver 5.와 호환성을 포함. not recommend

Syscatalog Oracle ver 5.와 호환성을 포함. not recommend

Sysfiles Oracle ver 5.와 호환성을 포함. not recommend

Syssegobj Oracle ver 5.와 호환성을 포함. not recommend

System_privilege_map system privilege code에 대한 정보.

Sys_objects object ID와 object type 그리고 segment data block주소를 매핑하는정보.

Tab Oracle ver 5.와 호환성을 포함. not recommend

Table_privileges user가 부여한, 부여받은, 소유한, 그리고 PUBLIC으로 부여된 object 권한정보. Oracle ver 6.과 호환성을 포함. not recommend.

Table_privilege_map access 가능한 권한code/권한명칭 정보.

Tabs User_tables 의 synonym.

Tabquotas Oracle ver 5.와 호환성을 포함. not recommend

Trusted_servers 분산환경에서 서버가 신뢰할만한지를 나타냄.

Tp_pitr_check catpitr.sql 에 의해 생성. 테이블스페이스의 point-in-time복구를 방해할지도 모르는 dependencies혹은 restriction에 관한 정보제공.

Ts_pitr_objects_to_be_dropped 테이블스페이스의 point-in-time복구수행의 결과 손실된 object에 대한 정보. (point-in-time recovery의 경우만 해당).

User_all_tables user가 사용가능한 테이블(object table, relational table)정보.

User_arguments user가 access가능한 object의 매개변수정보.

User_Audit_object cataudit.sql로 생성. object에 관련된 감사추적기록.

User_Audit_session cataudit.sql로 생성. user의 연결/종료에 관련된 감사추적기록.

User_Audit_statement cataudit.sql로 생성. user에 의해 실행된 GRANT,REVOKE,AUDIT, NOAUDIT, ALTER SYSTEM 명령에 대한 감사추적기록.

User_Audit_trail user와 관련된 전반적인 사항의 감사추적기록.

User_catalog user 소유의 table, views, synonyms, sequences 의 이름과 type.

User_clusters user소유의 cluster.

User_clu_columns user table 의 칼럼과 cluster칼럼과의 매핑테이블.

User_col_comments user 의 table, view의 칼럼에 대한 주석.

User_col_privs user 가 소유한, 부여한, 부여받은 칼럼에 대한 권한.

User_col_privs_made user 소유 object의 칼럼에 대한 권한.

User_col_privs_recd user가 부여받은 칼럼에 대한 권한.

User_coll_types user가 명명한 collection type정보.

User_constraints user소유 테이블의 제약조건정의.

User_cons_columns user소유 제약조건에 정의된 칼럼에 대한정보.

User_db_links user소유 데이터베이스링크에 대한정보.

User_dependencies user소유 object에 대한 dependencies.

User_errors user소유 저장 object에 대한 현재의 에러.

User_extents user소유 object에 속하는 세그먼트의 extent 정보.

User_free_space user가 access가능한 테이블스페이스내의 free extent 정보.

User_indexes user 소유의 indexes. Analyze명령을 사용해야함. 병렬서버를 지원.

User_ind_columns user소유 index 또는 user소유 table 의 칼럼정보.

User_ind_partitions user소유의 index partition각각에 대한설명과, partition정보, partition의 storage 매개변수, Analyze명령으로 결정된 여러partition통계

User_jobs user소유의 모든 job.(export/import, execution)

User_libraries user소유의 모든 libraries .

User_lobs user소유의 table에포함된 LOBs정보. internal LOBs( BLOBs, NCLOBs) 만해당, external LOBs(i.e, BFILES)은 아님.

User_method_params user type의 method 매개변수.

User_method_results user type의 method 의 results.

User_nested_tables user소유 테이블에 포함된 nested tables.

User_object_tables user가 사용가능한 object table.

User_objects user소유의 object.(index partition, table partition, package, packagebody, trigger)

User_object_size user소유의 PL/SQL object.

User_obj_audit_opts cataudit.sql로 생성. user소유의 table,view에 대한 감사option

User_part_col_statistics user소유의 tablepartition정보에 대한 칼럼통계와 그래프정보.

User_part_histograms user가 access할수있는 table partition의 histogram에 대한 그래프데이터(end-pointer).

User_part_key_columns user소유의 partition object의 partition key칼럼에 대한정보.

User_part_indexes 모든 user소유의 partition index의 partition정보.

User_part_tables user소유의 partition table에 대한 object 레벨의 partition정보.

User_password_limits user에게 적용된 password profile parameter.

User_queue_tables user소유 스키마에 생성된 queue table내부의 queues정보.

User_Queues user스키마의 모든 queue에 대한 동작 특성을 나타냄.

User_refresh 모든 refresh group.

User_refresh_children user가 소유한 refresh group 내부의 object에 관한정보.

User_refs user소유테이블의 object type칼럼중 REF칼럼, REF속성.

User_resource_limits 현재 user의 resource 한계.

User_role_privs user에게 부여된 roles.

User_segments user오브젝트에 포함된 데이터베이스 segments의 storage할당정보.

User_sequences user 소유의 sequences.

User_snapshots user 가 볼수있는 snapshots.

User_snapshot_logs user 소유의 모든 snapshot logs.

User_source user소유 저장 objects 의 모든 text source.

User_snapshot_refresh_times snapshot refresh time.

User_synonyms user소유의 synonym.

User_sys_privs user에게 부여된 system 권한.

User_tab_col_statistics user_tab_columns view에 대한 칼럼통계와 그래프정보를 나타냄.

User_tab_columns user소유의 table, view, cluster의 칼럼정보.(Analyze명령사용)

User_tab_comments user소유의 table, view에 대한 주석.

User_tab_histograms user소유 table의 칼럼에 대한 histogram.

User_tab_partitions user소유 table partition에 대한, partition 레벨의 분할정보와, partition의 storage매개변수, Analyze에 의해 집계된 여러통계정보.

User_tab_privs user가 소유한, 부여한, 부여받은 object에 대한 권한 정보.

User_tab_privs_made user가 소유한 object에 관한 모든 권한.

User_tab_privs_recd user가 부여받은 object 권한정보.

User_tables user소유의 relational table에 대한 정보. (Analyze명령사용)

User_tablespaces user가 access 가능한 tablespaces에 대한 설명.

User_triggers user가 소유한 triggers 정보.

User_trigger_cols user가 소유한 또는 user테이블에 있는 trigger안의 column 정보.

User_ts_quotas user에게 할당된 tablespace quotas 정보.

User_types 테이블안의 user소유의 type.

User_type_attrs user type의 속성을 나타냄.

User_type_methods user type의 methods를 나타냄.

User_updatable_columns join view에서 사용자에게 update가 허용된 칼럼정보.

User_users 현재 user에 관한 정보.

User_views user 소유의 view에 대한 text.

FILEXT$ 데이터파일의 AUTOEXTEND를 ON으로 변경했을 때 처음 생성.

V$ACCESS 현재 데이터베이스내의 lock이걸린 object와 그 object를 access 하려는 session id.

V$ACTIVE_INSTANCES 현재 데이터베이스내의 Mount된 모든 인스턴스에대하여 인스턴스 이름과, 번호를 매치.

V$AQ 데이터베이스내의 모든 Queue에 대한 통계.

V$ARCHIVE Archive에 필요한 redo log file에 대한 정보. 각각의 행은 하나의 thread에 대한 정보이다. V$LOG도 동일한정보.

V$ARCHIVE_DEST 현재의 instance에서, 모든 archive log destination, 현재값, mode, status.

V$ARCHIVED_LOG archive log 이름을 포함하는 controlfile에 대한 archive log 정보, archive log 기록은 online중 redo log가 성공적으로 저장되었거나, clear(log가 clear되면, name칼럼은 null이 된다)된후 insert된다.

V$BACKUP 모든 online 데이터파일의 backup 상태를 나타낸다.

V$BACKUP_CORRUPTION 데이터파일의 backup 중 에러정보를 나타낸다. 에러들은 control 파일과 achived log backup 에 포함되지 않는다.

V$BACK_DATAFILE control 파일에서 datafile과 controlfile 의 backup정보를 보여줌.

V$BACK_DEVICE 지원되는 backup 디바이스정보.

V$BACK_PIECE controlfile에서 backup piece에 대한 정보를 포함. 각각의 backup set 은 하나 또는 그이상의 backup piece로 구성된다.

V$BACKUP_REDOLOG controlfile에서 backup set의 저장된 log에 대한 정보. Online redo logs는 곧바로 backup 되지 않는다. 먼저 disk에 저장된후 backup 된다. 저장된 log backup set 은 하나 또는 그이상의 logs들로 구성된다.

V$BACKUP_SET controlfile에서 backupset 정보를 보여줌. backup set 행은 backup set이 성공적으로 완료되었을 때 insert된다.

V$BGPROCESS 백그라운드 프로세스 정보.

V$BH 병렬서버 view이다. SGA내의 모든 버퍼에 대한 ping의 상태와 수를 나타낸다.

V$BUFFER_POOL 인스턴스내에서 사용가능한 모든 버퍼풀에 대한정보.

V$CACHE 병렬서버 view이다. 특정데이타베이스object에 관련된 현재의 인스턴스의 SGA내부의 각각의 block에 대한 block header에 대한 정보.

V$CACHE_LOCK 병렬서버view. platform-specific lock manager 식별자를 제외하면, V$CACHE와 유사하다.

V$CIRCUIT 가상 circuit에 관한 정보이며, 가상circuit란 dispatcher와 server를 통한 데이터베이스와의 user 연결을 말한다.

V$CLASS_PING 각각blockclass마다 ping된 블록의 수를나타낸다. 다른class블록의 충돌을 비교하기위해 사용.

V$COMPATIBILITY 이전버전으로 downgrade를 방지하기위해 데이터베이스인스턴스에 의해 사용된특성들을 설명. 다른 인스턴스가 갖고있는 특성에 영향을 미치지 않으며, 데이터베이스가 완전히 정지한이후에도 존재하지 않는 일시적인 비호환성들을 포함할수도 있다.

V$COMPATSEG 이전버전으로 되돌아가는 것을 막기위한 데이터베이스에서 사용되는 영구적인 특성들.

V$CONTROLFILE 컨트롤파일의 이름과 상태.

V$CONTROLFILE_RECORD_SECTION 컨트롤파일의 record에 대한 정보.

V$COPY_CORRUPTION 컨트롤파일로부터 데이터파일의 복사불량에 대한 정보.

V$CURRENT_BUCKET 캐쉬내의 버퍼의 수가 감소할때 발생할 수 있는 캐쉬손실의 경우수를 예상하는데 유용.

V$DATABASE control file 로부터 데이터베이스정보를 포함.

V$DATAFILE 컨트롤파일로부터데이타파일에대한 정보를 포함.

V$DATAFILE_COPY 컨트롤파일로부터 데이터파일의 복사에 대한 정보를포함.

V$DATAFILE_HEADER 데이터파일헤더에 대한 정보.

V$DBFILE 데이터베이스를 구성하는 모든 데이터파일. 대신에 V$DATAFILE 추천한다.

V$DBLINK 세션에 의해 open된 데이터베이스링크에 대한 설명. 이 데이터베이스링크들은 닫히기전에 commit되거나 rollback되어야만 한다.

V$DB_OBJECT_CACHE library cache에 cach된 데이터베이스오브젝트를 나타냄.

V$DB_PIPES 데이터베이스내에 현재 운영중인 pipe에 대한 설명.

V$DELETED_OBJECT 삭제된 archived 로그, 데이터파일 copy, 컨트롤파일에서 백업piece 에 대한 정보. 이뷰의 목적은 복구목록의 재동조작업을 최적화하는 것이다. archived 로그나, 데이터파일 copy, 백업piece 등이 삭제될때는 해당하는 행이삭제되었음이 표시된다.

V$DISPATCHER dispatcher 프로세스에 관한 정보.

V$DISPATCHER_RATE dispatcher 프로세서에 관련된 확률통계.

V$DLM_CONVERT_LOCAL lock 변환작업에 대한 경과시간.

V$DLM_CONVERT_REMOTE 원격 lock변환작업에 대한 경과시간.

V$DLM_LATCH DLM 잠금에 대한 통계. 각각의 잠금에 대한 통계보다는, 각 타입에 대한 총계를 포함. 개념적으로 IMM_GETS/TTL_GETS 값은 1에 가깝게 된다.

V$DLM_LOCKS 병렬서버 view이다. 블록화되었거나, 다른 것을 블록화하고있는 lock manager에 알려진 모든 lock에 대한 정보.

V$DML_MISC 잡다한 DLM 통계에 대한 정보.

V$ENABLEDPRIVS 사용가능한 권한에 대한정보, 이들권한은 SYS.SYSTEM_PRIVILEGES_MAP테이블에 존재해야만 한다.

V$ENQUEUE_LOCK 큐에 대기상태인 오브젝트에의해 소유된 모든 lock이 view의 칼럼은 V$LOCK의 칼럼과 동일하다. 자세한 것은 V$LOCK을 참고.

V$EVENT_NAME wait event 에 대한 정보.

V$EXECUTION 병렬 질의 실행에 대한 정보.

V$EXECUTION_LOCATION 병렬 질의 실행 트리의 위치에 대한 자세한 정보.

V$FALSE_PING 병렬서버view. ping에 실패지도 모르는 버퍼에 대한 정보. 즉, 10회이상ping된 다른 버퍼와 동일한 lock으로 잠겨있는 버퍼를 말한다. ping이 실패로 판명된 버퍼는 lock충돌을 감소시키기위해 1-44페이지의 "GC_FILES_TO_LOCK"에 다시 매핑된다.

V$FILE_PING 데이터파일마다 ping된 블록수를 보여줌. 이정보는 현존하는 데이터파일에 대한 access패턴을 결정하는데 and, 데이터파일블록을 PCM lock에 새로 매핑하는것을 결정하는데 사용된다.

V$FILESTAT 파일 read/write 통계.

V$FIXED_TABLE 데이터베이스내의 모든 동적실행테이블, views, 유도테이블. 실제테이블을 참조하는 약간의 V$테이블은 리스트에 없다.

V$FIXED_VIEW_DEFINITION (V$로 시작하는)고정view에 대한 설명. 유의해서 사용해야한다.

V$GLOBAL_TRANSACTION 현재 활동중인 트랜잭션에 대한 설명.

V$INDEXED_FIXED_COLUMN index된 동적실행테이블(X$ table)의 칼럼에 대한 설명. X$ table은 경고없이 변경할수있다. 이view는 보다 효과적으로 고정뷰(V$view)에 대한

V$INSTANCE 현재의 인스턴스의 상태를 나타냄. V$INSTANCE의 버전은 V$INSTANCE의 초기버전과 호환성이 없다.

V$LATCH 하위 잠금에 대한 통계와 상위 잠금에 대한 요약통계. 즉, 상위잠금에 대한 통계는 그 하위잠금에 대한 각각의 통계를 포함한다.

V$LATCHHOLDER 현재잠금에 대한 정보.

V$LATCHNAME V$LATCH 에 있는 잠금에 대한 디코드된 잠금이름에 대한 정보. V$LATCHNAME의 행들은 V$LATCH의 행들과 1

V$LATCH_CHILDREN 하위잠금에 대한 통계를 포함. V$LATCH의 칼럼에 child# 칼럼이추가되었다. LATCH#칼럼이 서로 동일하다면, 하위잠금이 동일한 상위잠금을 갖는 것이다.

V$LATCH_MISSES 잠금을 획득하는데 실패한 시도에 대한 통계.

V$LATCH_PARENT 상위잠금에 대한 통계. V$LATCH_PARENT 칼럼은 V$LATCH칼럼과 동일하다.

V$LIBRARYCACHE library cache의 실행과 활동통계.

V$LICENSE license 한계에 대한 정보.

V$LOADCSTAT 직접적재하는동안 컴파일된 SQL*loader 통계정보. 이테이블에대한 어떤 Select 문도 "no rows returned" 결과가 나오는데, 왜냐면, 동일한 시간에 데이터를 적재하면서, 쿼리를 날릴수 없기 때문이다.

V$LOCK 현재 Oracle 서버에 의해 확립된 잠금에 대한 정보나 lock또는 latch에 대한 두드러진요청

V$LOCK_ACTIVITY 병렬서버view이다. V$LOCK_ACTIVITY는 현재의 인스턴스의 DLM잠금동작을 나타낸다. 각각의 행은 잠금동작의 타입과 일치된다.

V$LOCK_ELEMENT 병렬서버view이다. 버퍼캐쉬에 의해사용된 각각의 PCM잠금에 대해 v$LOCK_ELEMENT 에 한행이다. 잠금요소에 대응되는 PCM잠금의 이름은 'BL',indx,class등이다.

V$LOCKED_OBJECT 시스템안의 모든 트랜잭션에 걸린 잠금을 나타낸다.

V$LOCKED_WITH_COLLISIONS 병렬서버view이다. 여러버퍼를 보호하는 lock을 찾는데 사용되며, 그 버퍼들은 최소한 10회이상 각각 강제로 쓰여지거나, 강제로 읽혀진 버퍼들이다.

V$LOG 컨트롤파일로부터 log 파일정보를 포함한다.

V$LOGFILE redo log 파일정보. redo log 그룹과 멤버 파일명.

V$LOGHIST 컨트롤파일로부터 log history정보를 포함. 지속적인 호환성을 포함하고 있다. 대신에 V$LOG_HISTORY의 사용을 권장한다.

V$LOG_HISTORY 컨트롤파일로부터 log history 정보를 포함한다.

V$MLS_PARAMETERS Oracle Server의 확정된 초기화파라미터를 나타냄.

V$MTS multi-threaded server의 성능향상을위한 정보를 포함.

V$MYSTAT 현재 세션에 대한 통계값포함.

V$NLS_PARAMETERS 현재의 NLS 매개변수의 값들을 포함.

V$NLS_VALID_VALUES 유효한 NLS 매개변수값.

V$OBJECT_DEPENDENCY 현재 공유풀에 적재되어있는 package, procedure,cursor등에 관련되어있는 object를 결정하는데 사용된다. 예를들면, V$SESSION, V$SQL등과 조인하면, 현재 어떤 user가 실행중인 SQL문에서 어떤 테이블이 사용되었는지를 알아낼수가 있다.

V$OFFLINE_RANGE 컨트롤파일로부터 offline된 datafile을 보여준다. DATAFILE행에 저장되어있는 각각의 데이터파일의 최종offline 간격을 보여줌. offline 간격은 테이블스페이스가 처음 offline normal, 또는 Read Only로 변경되고난이후 다시 online 또는 read-write로 변경된다음에 확정된다. 데이터파일이 스스로 Offline로 변경되거나 테이블스페이스가 OFFLINE IMMEDIATE로 변경되면, offline간격은 확정되지 않는다.

V$OPEN_CURSOR 각각 user 세션이 열렸있거나, 정지되어있는 cursor를 보여준다.

V$OPTION Oracle Server와 같이 설치된 선택사항들.

V$PARAMETER 초기화 파라미터에 대한 설명이다.

V$PING 병렬서버view이다. 최소한 1번이상 ping된 블록만을 보여준다는 것을 제외하고 V$CACHE view와 동일하다.특정 데이터베이스 object와 관련된 현재의 인스턴스내의 SGA에 있는 각각의 블록에대한 block header정보를 포함하고 있다.

V$PQ_SESSTAT 병렬쿼리에 대한 session 통계를 포함.

V$PQ_SLAVE 인스턴스내에 실행중인 parallel 쿼리서버에 대한 통계.

V$PQ_SYSSTAT 병렬쿼리에 대한 시스템통계.

V$PQ_TQSTAT 병렬쿼리 동작의 통계를 포함. 통계는 질의가 완료된후에 컴파일되며 세션이 살아있는동안 계속 남아있는다.

V$PROCESS 현재 작업중인 프로세스에 대한 정보. LATCHWAIT 칼럼은 프로세스잠금이 무엇을 기다려야하는가를 나타내며, LATCHSPIN 칼럼은 프로세스잠금이 동작되는 것을 나타낸다. 멀티프로세서의 경우 Oracle 프로세스는 잠금을 기다리기전에 실시한다.

V$PWFILE_USERS password 파일로부터 유도해낸 SYSDBA, SYSOPER 권한을 부여받은 user.

V$QUEUE 멀티쓰레드 메시지큐에 대한 정보.

V$RECENT_BUCKET 대용량 캐쉬실행을 평가하기에 유용한 정보.

V$RECOVER_FILE media 복구에필요한 파일의 상태를 나타냄.

V$RECOVERY_FILE_STATUS 각각의 RECOVER명령에 대한 각 데이터파일에 대한 정보를 한행씩 포함. Oracle프로세스가 복구를 수행하는데 유용한 정보임. recover manager는 서버프로세스에 직접 복구를수행하도록 했을 때, recovery manager가 이 view에서 관련된정보를 참고할 수 있다. 다른user들에게는 유용하지 않다.

V$RECOVERY_LOG 완벽한 media복구에 필요한 archived logs에 관한 정보. 이정보는 log history view인 V$LOG_HISTORY에서 유도된 것이다.

V$RECOVERY_PROGRESS 데이터베이스복구작업이 중간에 멈추지않도록하는데 사용되며, 복구작업을 완료하는데 요구되는 시간을 측정하는데 사용된다.

V$RECOVERY_STATUS 현재의 복구진행상태를 나타낸다. 단지 복구를 수행하는 Process 에대한 정보만이유용하다. 복구관리자가 서버프로세스에게 복구를 수행하라고 지시할때에, 복구관리자는 이view에서 관련정보를 참조할 수 있다. 다른 user에게는 불필요하다.

V$REQDIST MTS dispatcher의 응답시간에 대한 그래프통계를 나타내며, time range는 버킷 number의 지수함수로 증가한다.

V$RESOURCE 자원(resource)의 이름과 주소정보를 포함.

V$RESOURCE_LIMIT System 자원의 부분적인 사용에 대한 정보. 자원의 소비를 모니터링함으로서 낭비를 방지하는데 사용된다.

V$ROLLNAME 모든 online중인 rollback segments의 이름. 데이터베이스가 open시에만 조회가능.

V$ROLLSTAT 롤백세그먼트통계정보.

V$ROWCACHE 자료사전활동에 대한 통계. 각각의 행은 하나의 자료사전cache 통계를 포함.

V$SESSION 현재 open된 세션에 대한 정보.

V$SESSION_CONNECT_INFO 현재의 세션에 대한 network 연결에 대한 정보.

V$SESSION_CURSOR_CACHE 현재의 세션에 대한 cursor 사용에 대한 정보. SESSION_CACHED_CURSORS 초기화파라미터에 대한 효율을 측정하지는 않는다.

V$SESSION_EVENT 세션의 event 대기에 관한정보.

V$SESSION_LONGOPS 장시간실행되는 작업에 대한 상태. SOFAR, TOTALWORK칼럼은 진행상태를 제공한다. 예를들어 다음요소(hach cluster creations, backup, recovery) 에 대한 작동상태를 모니터링할 수 있다.

V$SESSION_OBJECT_CACHE 로칼서버의 현재사용중인 user세션의 object, cache통계정보.

V$SESSION_WAIT 활동중인 세션이 대기하고있는 자원또는 이벤트이다.

V$SESSTAT user세션 통계이다. 통계number(statistic#)에 해당하는 통계name을 찾으려면, V$STATNAME를 참고하면 된다.

V$SESS_IO 각각의 user세션에 대한 I/O 통계이다.

V$SGA System Global Area 에대한 간략한 정보.(name, size)

V$SGASTAT System Global Area에 대한 자세한 정보.(name, bytes, pool)

V$SHARED_POOL_RESERVED Shared Pool내에 예약풀과 공간을 바꾸고자할 때 도움이 되는통계.

V$SHARED_SERVER Shared Server processes 에 대한 정보를 포함.

V$SORT_SEGMENT 주어진 인스턴스내의 각 sort세그먼트에 대한 정보. 테이블스페이스가 Temporary 타입일때만 update된다.

V$SORT_USAGE sort 사용에 대해 기술한다.

V$SQL Group by절이없는 공유sql영역에대한 통계이며 입력된 원래 sql문장의 각 child의 row를 포함.

V$SQL_BIND_DATA 데이터가 이 서버에서 추출가능하다면 이 view를 조회하는 세션에 소유된 각 커서안에 있는 각각의 원격bind변수에 대한 클라이언트에 의해 보내진 데이터.

V$SQL_BIND_METADATA 이view를 조회하는 세션에 소유된 각커서안에 있는 각각의 원격bind변수에 대해 클라이언트에의해 제공되는 bind metadata.

V$SQL_CURSOR 이 view를 조회하는 세션과 관련된 각 cursor에 대한 디버깅정보.

V$SQL_SHARED_MEMORY 메모리 스냅샷에 공유된 커서에 대한 정보. 공유풀에 저장된 각SQL문은 관련된 하나또는 그이상의 하위object를 가지고 있다.

V$SQLAREA 공유SQL영역에 대한 통계를 가지고있으며, Sql 문자열마다 한행을 포함한다. 메모리내에 존재하는, parse된, 실행을 대기하고있는 SQL문장에 대한 통계를 제공한다.

V$SQLTEXT SGA내부의 공유SQL 커서에 속해있는 SQL문장을 포함.

V$SQLTEXT_WITH_NEWLINES 가독성이 증가되고, 공백을 포함한 SQL문장안에 newline과 tabs을 대체하지 않는다는 것을 제외하고는 V$SQLTEXT view와 동일하다.

V$STATNAME V$SESSTAT와 V$SYSSTAT테이블에서 나타난 statistics에 대한 이름.

V$SUBCACHE 현재 라이브러리 캐쉬메모리에 적재된 하위 캐쉬에 대한 정보. 모든 라이브러리캐쉬에 대해 언급하고있으며, 각 라이브러리 캐쉬object마다 각 적재된 하위 캐쉬에 대해 한행을 나타낸다.

V$SYSSTAT 시스템 통계이다. 각 statistic number(statistic#)와 관련된 statistic의 이름을 찾기위해서는, "V$STATNAME"를 보시오.

V$SYSTEM_CURSOR_CACHE 시스템 전반적인정보라는 것을 제외하고, V$SESSION_CURSOR_CACHE와 유사한 정보를 나타낸다.

V$SYSTEM_EVENT 이벤트에 대한 총 wait정보. TIME_WAITED,AVERAGE_WAIT칼럼은 급속메커니즘을 지원하지 않는 플랫폼에서 0값을 포함할 것이다. 이런 플랫폼에서 DB를 운영중이고, 이칼럼이 wait time을 줄여주기를 원한다면, 파라미터파일의 TIMED_STATISTICS를 TRUE로 세팅하면된다. 단지 이렇게 하면, 시스템 성능에 약간의 마이너스효과를 가져올 것이다.

V$SYSTEM_PARAMETER System parameter에 대한 정보.

V$TABLESPACE 컨트롤파일로부터 테이블스페이스 정보를 나타내준다.

V$THREAD 컨트롤파일로부터 thread 정보를 가져온다.

V$TIMER 1/100 초로 나타낸 경과시간. 시간은 epoch가 시작된이후부터 측정되며, epoch는 OS의 특성이며, 값이 4bytes(약 497일)를 넘을때마다 0근처의 값이 된다.

V$TRANSACTION 시스템내의 활동중인 트랜잭션.

V$TRANSACTION_ENQUEUE 트랜잭션 오브젝트에 의해 소유된 lock를 나타냄.

V$TYPE_SIZE 데이터블록용량을 측정하는데 사용되는 여러 데이터베이스컴포넌트들의 SiZe.

V$VERSION Oracle Server의 core 라이브러리 컴포넌트의 Version수이다. 각 컴포넌트에 한 row가 있다.

V$WAITSTAT 블록점유에 대한 통계. 통계가 사용가능한 시간에만 갱신된다.

V$RECOVERY_STATUS 현재의 복구진행상태를 나타낸다. 단지 복구를 수행하는 Process 에대한 정보만이유용하다. 복구관리자가 서버프로세스에게 복구를 수행하라고 지시할때에, 복구관리자는 이view에서 관련정보를 참조할 수 있다. 다른 user에게는 불필요하다.

V$REQDIST MTS dispatcher의 응답시간에 대한 그래프통계를 나타내며, time range는 버킷 number의 지수함수로 증가한다.

V$RESOURCE 자원(resource)의 이름과 주소정보를 포함.

V$RESOURCE_LIMIT System 자원의 부분적인 사용에 대한 정보. 자원의 소비를 모니터링함으로서 낭비를 방지하는데 사용된다.

V$ROLLNAME 모든 online중인 rollback segments의 이름. 데이터베이스가 open시에만 조회가능.

V$ROLLSTAT 롤백세그먼트통계정보.

V$ROWCACHE 자료사전활동에 대한 통계. 각각의 행은 하나의 자료사전cache 통계를 포함.

V$SESSION 현재 open된 세션에 대한 정보.

V$SESSION_CONNECT_INFO 현재의 세션에 대한 network 연결에 대한 정보.

V$SESSION_CURSOR_CACHE 현재의 세션에 대한 cursor 사용에 대한 정보. SESSION_CACHED_CURSORS 초기화파라미터에 대한 효율을 측정하지는 않는다.

V$SESSION_EVENT 세션의 event 대기에 관한정보.

V$SESSION_LONGOPS 장시간실행되는 작업에 대한 상태. SOFAR, TOTALWORK칼럼은 진행상태를 제공한다. 예를들어 다음요소(hach cluster creations, backup, recovery) 에 대한 작동상태를 모니터링할 수 있다.

V$SESSION_OBJECT_CACHE 로칼서버의 현재사용중인 user세션의 object, cache통계정보.

V$SESSION_WAIT 활동중인 세션이 대기하고있는 자원또는 이벤트이다.

V$SESSTAT user세션 통계이다. 통계number(statistic#)에 해당하는 통계name을 찾으려면, V$STATNAME를 참고하면 된다.

V$SESS_IO 각각의 user세션에 대한 I/O 통계이다.

V$SGA System Global Area 에대한 간략한 정보.(name, size)

V$SGASTAT System Global Area에 대한 자세한 정보.(name, bytes, pool)

V$SHARED_POOL_RESERVED Shared Pool내에 예약풀과 공간을 바꾸고자할 때 도움이 되는통계.

V$SHARED_SERVER Shared Server processes 에 대한 정보를 포함.

V$SORT_SEGMENT 주어진 인스턴스내의 각 sort세그먼트에 대한 정보.테이블스페이스가 Temporary 타입일때만 update된다.

V$SORT_USAGE sort 사용에 대해 기술한다.

V$SQL Group by절이없는 공유sql영역에대한 통계이며 입력된 원래 sql문장의 각 child의 row를 포함.

V$SQL_BIND_DATA 데이터가 이 서버에서 추출가능하다면 이 view를 조회하는 세션에 소유된 각 커서안에 있는 각각의 원격bind변수에 대한 클라이언트에 의해 보내진 데이터.

V$SQL_BIND_METADATA 이view를 조회하는 세션에 소유된 각커서안에 있는 각각의 원격bind변수에 대해 클라이언트에의해 제공되는 bind metadata.

V$SQL_CURSOR 이 view를 조회하는 세션과 관련된 각 cursor에 대한 디버깅정보.

V$SQL_SHARED_MEMORY 메모리 스냅샷에 공유된 커서에 대한 정보. 공유풀에 저장된 각SQL문은 관련된 하나또는 그이상의 하위object를 가지고 있다.

V$SQLAREA 공유SQL영역에 대한 통계를 가지고있으며, Sql 문자열마다 한행을 포함한다. 메모리내에 존재하는, parse된, 실행을 대기하고있는 SQL문장에 대한 통계를 제공한다.

V$SQLTEXT SGA내부의 공유SQL 커서에 속해있는 SQL문장을 포함.

V$SQLTEXT_WITH_NEWLINES 가독성이 증가되고, 공백을 포함한 SQL문장안에 newline과 tabs을 대체하지 않는다는 것을 제외하고는 V$SQLTEXT view와 동일하다.

V$STATNAME V$SESSTAT와 V$SYSSTAT테이블에서 나타난 statistics에 대한 이름.

V$SUBCACHE 현재 라이브러리 캐쉬메모리에 적재된 하위 캐쉬에 대한 정보. 모든 라이브러리캐쉬에 대해 언급하고있으며, 각 라이브러리 캐쉬object마다 각 적재된 하위 캐쉬에 대해 한행을 나타낸다.

V$SYSSTAT 시스템 통계이다. 각 statistic number(statistic#)와 관련된 statistic의 이름을 찾기위해서는, "V$STATNAME"를 보시오.

V$SYSTEM_CURSOR_CACHE 시스템 전반적인정보라는 것을 제외하고, V$SESSION_CURSOR_CACHE와 유사한 정보를 나타낸다.

V$SYSTEM_EVENT 이벤트에 대한 총 wait정보. TIME_WAITED,AVERAGE_WAIT칼럼은 급속메커니즘을 지원하지 않는 플랫폼에서 0값을 포함할 것이다. 이런 플랫폼에서 DB를 운영중이고, 이칼럼이 wait time을 줄여주기를 원한다면, 파라미터파일의 TIMED_STATISTICS를 TRUE로 세팅하면된다. 단지 이렇게 하면, 시스템 성능에 약간의 마이너스효과를 가져올 것이다.

V$SYSTEM_PARAMETER System parameter에 대한 정보.

V$TABLESPACE 컨트롤파일로부터 테이블스페이스 정보를 나타내준다.

V$THREAD 컨트롤파일로부터 thread 정보를 가져온다.

V$TIMER 1/100 초로 나타낸 경과시간. 시간은 epoch가 시작된이후부터 측정되며, epoch는 OS의 특성이며, 값이 4bytes(약 497일)를 넘을때마다 0근처의 값이 된다.

V$TRANSACTION 시스템내의 활동중인 트랜잭션.

V$TRANSACTION_ENQUEUE 트랜잭션 오브젝트에 의해 소유된 lock를 나타냄.

V$TYPE_SIZE 데이터블록용량을 측정하는데 사용되는 여러 데이터베이스컴포넌트들의 SiZe.

V$VERSION Oracle Server의 core 라이브러리 컴포넌트의 Version수이다. 각 컴포넌트에 한 row가 있다.

V$WAITSTAT 블록점유에 대한 통계. 통계가 사용가능한 시간에만 갱신된다.

 

[ http://www.hasspark.com/bbs/view.html?id=234&code=tech ]

저작자표시

'(DB) Oracle > System Table' 카테고리의 다른 글

Oracle - System Table 사용예제  (0) 2017.01.22
Oracle - System_Table_List  (0) 2017.01.22
Posted by 농부지기
,

Oracle - 여러 가지 조작

(DB) Oracle/튜닝 및 조작 2017. 1. 22. 17:10

[ Oracle - 여러 가지 조작 ]     

 

☞ tablespace 변경

 

alter table <TABLE> move tablespace <TABLESPACE>;
alter index <INDEX> rebuild tablespace <TABLESPACE>;

☞ table 변경

 

drop table (table_name) cascade constraints;


 

저작자표시

'(DB) Oracle > 튜닝 및 조작' 카테고리의 다른 글

Oracle - Lock걸린_자료조회  (0) 2017.01.22
Oracle - Lock List 보기 및 Lock 해제  (0) 2017.01.22
Oracle - DBA Scripts  (0) 2017.01.22
Oracle - Optimizer  (0) 2017.01.22
Oracle - HINT  (0) 2017.01.22
Posted by 농부지기
,

티스토리툴바