oracle 썸네일형 리스트형 ORACLE 10g nls_database_parameters ORACLE 10g nls_database_parameters from 1. nls_database_parameters view의 활용 A. DB의 각종 설정값을 확인 해 볼 수 있다. B. init parameter 파일에서 확인이 불가능한 경우에도 확인이 가능하다. 2. nls_database_parameters view 의 구조 및 내용 A. column은 parameter 와 value 두개로 구성되어있다. B. Query 실행 SQL> select * from nls_database_parameters; PARAMETER VALUE ------------------------------ ------------------------------ NLS_LANGUAGE AMERICAN NLS_TERR.. 더보기 ORACLE UPDATABLE JOIN VIEW & BYPASS_UJVC v1.0 ORACLE UPDATABLE JOIN VIEW & BYPASS_UJVC from OTN : Managing Views, Sequences, and Synonyms http://download.oracle.com/docs/cd/B10501_01/server.920/a96521/views.htm#3816 from OTN : KEY PRESERVED TABLE http://download.oracle.com/docs/cd/B10501_01/server.920/a96521/views.htm#4054 1. UPDATABLE JOIN VIEW 의 의미 A. 말그대로 JOIN된 VIEW가 UPDATE가 가능함을 말한다. B. MODIFIABLE JOIN VIEW 라고도 한다. 2. UPDATABLE JOIN VIE.. 더보기 ORACLE HARD PARSING TRACE 비교 v1.1 ORACLE HARD PARSING TRACE 비교 v1.1 from 1. 개요 A. HARD PARSING을 유발하는 쿼리에 대해 저번에 배웠다. 이번에는 같은 SQL 쿼리가 상황에 따라 어떤 영향력을 가지는지 비교해보도록 하겠다. 2. 시나리오 A. 상황 i. 세션만 다른 경우 ( 동일 USER, SQL 쿼리 동일 ) ii. 세션과 USER가 다른경우 ( SQL 쿼리 다름 ) iii. 세션과 USER와 객체(소유주)가 다른경우 ( SQL 쿼리 동일, 객체 구조는 동일 ) B. 환경 i. 세션 A, B 두개를 사용 ii. 실행타임은 A가 0초에 실행 후 15초 후에 B를 실행 iii. 각 세션의 쿼리를 실행전 SHARED_POOL FLUSH iv. 값을 비교하는데 있어 SQL_TRACE의 실행타임을 사.. 더보기 ORACLE 장시간의 HARD PARSING 유발 쿼리 ORACLE 장시간의 HARD PARSING 유발 쿼리 여기서는 하나의 쿼리가 장시간의 수행타임을 가지는 쿼리를 만들어보겠다. 1. HARD PARSING A. SQL 수행중 발생한다. B. PARSING -> BIND -> EXECUTE -> FETCH 과정중 PARSING에 해당한다 C. 위 수행 과정 중에 대부분의 수행시간을 차지한다. 2. HARD PARSING 유발 요인 A. Literal SQL B. 적정 크기보다 작은 shared_pool_size C. 부적절한 SQL 3. HARD PARSING 예제 A. 대량의 table 생성 SQL> spool make.sql SQL> set serveroutput on SQL> get m_tbs 1 declare 2 temp varchar2(2000).. 더보기 ORACLE Trace 뽑는 쉘스크립트 스크립트를 사용해 SQL TRACE 하기 Trace 하는 방법은 여러가지가 있다. 여기서는 autotrace 의 한계를 넘는 sql_trace 를 사용하겠다. 첨부한 파일을 보면 총 두개 확장자로 나뉘어진다. 하나는 쉘 스크립트 ( *.sh ) 이며 다른 세가지는 *.sql 이다. m_sct.sh ========== c_trc_on.sql c_trc_off.sql tmp.sql 이렇게 구성되어있고 사용법은 $./m_sct.sh script_name ( !@##%.sql 에서 .sql 부분을 제외한 부분 ) m_sct.sh 는 다른 스크립트를 관리하는 부분이다. c_trc_on.sql , c_trc_off.sql 은 sql_trace 파라미터를 true , false 로 변경해 주는 query 이다. tm.. 더보기 ORACLE 9i lock type ( TX 편 ) v1.0 from Practical OWI | exem | exem lock type - tx tx는 ROW에 대해 걸리는 LOCK 이다. TX Lock 경합 발생 원인으로 동일 Row 변경 Unique Key 충돌 ITL Entry 부족 Bitmap Index Index Leaf Node Split 기타 등의 이유가 있다. 테스트는 9i 에서 확인하였다. v$lock 은 9i에도 있다. ( v$lock_type은 10g에만 있다. ) /*+ 9i 와 10g 비교 해 볼 것 */ 각각의 예를 보기 전에 필요한 view 에 대해 이야기 하고자 한다. tx 락 경합발생 확인을 위해 v$lock view를 사용할 것이며 아래와 같은 쿼리를 사용할 것이다. SQL> get w_cur_lck 1 select sid,typ.. 더보기 Oracle 10g v$lock_type from OTN : v$lock http://download.oracle.com/docs/cd/B10501_01/server.920/a96536/ch396.htm#1116909 v$lock_type v$lock_type 은 10g에서 새로 추가된 view이다. SQL> desc v$lock_type Name Null? Type ----------------------------------------------------- -------- ------------------------------------ TYPE VARCHAR2(64) NAME VARCHAR2(64) ID1_TAG VARCHAR2(64) ID2_TAG VARCHAR2(64) IS_USER VARCHAR2(3) DESCRIPTION VARC.. 더보기 Oracle 10g log file sync v1.0 log file sync from Practical OWI | exem | exem log file sync 정의 Server Process가 Commit , Rollback 수행 후 LGWR process가 관련 Redo Record를 Redo Buffer에서 Redo Log 파일로 기록할 때까지 대기하는 event log file sync 발생의 요인 잦은 Commit 횟수 I/O 시스템의 성능 REDO BUFFER의 지나친 크기 리두데이터의 양 log file sync 는 위의 요인을 보면 결과적으로 REDO LOG BUFFER 의 내용 (DIRTY BUFFER) 을 REDO LOG FILE 로 내려쓰는데 사용되는 시간과 관련있다. DIRTY BUFFER는 DML 작업으로 생겨나기 때문에 DML의 .. 더보기 ORACLE 9iClustering Factor (CF) Clustering Factor (CF) from Practical OWI | exem | exem 1. 정의 CLUSTERING FACTOR - 모든 인덱스 로우에 대해 순차적으로 데이터(테이블) 로우를 엑세스할 때 DISK READ를 일으켜 읽어 들어야 하는 총 데이터 블록의 수 2. 특징 A. CLUSTERING FACTOR 의 값은 NUMBER 타입이며 블록수보다 작을 수 없다. 아래의 쿼리에서는 해당 INDEX 가 사용하는 블록의 수를 조회해 보았다. SQL> select segment_name, blocks from dba_segments where segment_name = 'TEST_ID1_IDX’ SEGMENT_NAME BLOCKS -------------------- ----------.. 더보기 ORACLE 9i v$sql_workarea_histogram v$sql_workarea_histogram from OTN v$sql_workarea_histogram http://download.oracle.com/docs/cd/B10501_01/server.920/a96536/ch3203.htm#1126240 위의 파라미터는 인스턴스 시작이래 정렬을 위해 사용된 work area의 사용 횟수를 누적한다. work area의 size는 총 33개로 0k ~ 1k , 1k ~ 2k, … , 2TB ~ 4TB 까지 2배수로 증가한다. VIEW의 구성 컬럼으로 아래와 같다. COLUMN DATATYPE LOW_OPTIMAL_SIZE NUMBER HIGH_OPTIMAL_SIZE NUMBER OPTIMAL_EXECUTIONS NUMBER ONEPASS_EXECUTIONS .. 더보기 이전 1 ··· 9 10 11 12 13 14 다음
