2012년 밥벌이

DB 버퍼 캐쉬(DB Buffer Cache)

데이터파일로부터 읽어 들인 데이터 블록을 담는 캐시 영역

사용자 프로세스는 서버 프로세스를 통해 DB 버퍼 캐쉬의 버퍼 블록을 동시에(내부적으로 버퍼 lock을 통해 직렬화) 엑세스할 수 있다.

일부 DIRECT PATH READ 메커니즘이 작동하는 경우를 제외하면, 모든 블록 읽기는 버퍼 캐시를 통해 이루어진다. 즉, 읽고자 하는 블록을 먼저 버퍼 캐시에서 찾아보고 없을 때 디스크에서 읽는다. 디스크에서 읽을 대도 먼저 버퍼캐쉬에 적재한 후 읽는다.

데이터 변경도 버퍼 캐시에 적재된 블록을 통해 이루어지며, 변경된 블록(DIRTY 버퍼 블록)을 주기적으로 데이터 파일에 기록하는 작업은 DBWR 프로세스의 몫이다.

1.버퍼블록의 상태

FREE 버퍼 : 인스턴스 기동 후 아직 데이터가 읽히지 않아 비어 있는 상태(CLEAN 버퍼)이거나, 데이터가 담겼지만 데이터 파일과 서로 동기화돼 있는 상태에서 언제든지 덮어 써도 무방한 버퍼 블록을 말한다. 데이터 파일로부터 새로운 데이터 블록을 로딩하려면 먼저 FREE 버퍼를 확보해야 한다. FREE 상태인 버퍼에 변경이 발생하면 그 순간 DIRTY 버퍼로 상태가 바뀐다.

DIRTY 버퍼 : 버퍼에 캐쉬된 이후 변경이 발생되었지만, 아직 디스크에 기록되지 않아 데이터 파일 블록과 동기화가 필요한 버퍼 블록을 말한다. 이 버퍼 블록들이 다른 데이터 블록을 위해 재 사용되려면 디스크에 먼저 기록되어야 하며, 디스크에 기록되는 순간 FREE 버퍼로 상태가 바뀐다.

PINNED 버퍼 : 읽기 또는 쓰기 작업이 현재 진행 중인 버퍼 블록을 말한다.

조인이란 두 개 이상의 테이블을 하나의 집합으로 만드는 연산이다.

1.NL JOIN

프로그램에서 사용하는 중첩된 반복문과 유사한 방식으로 조인을 수행한다. 반복문의 외부에 있는 테이블을 선행 테이블 또는 외부 테이블(OUTER TABLE)이라고 하고, 반복문의 내부에 있는 테이블을 후행테이블 또는 내부 테이블(INNER TABLE)이라고 한다.

FOR 선행 테이블 읽음  -> 외부 테이블(OUTER TABLE)

      FOR 후행 테이블 읽음 -> 내부 테이블(INNER TABLE)

             (선행 테이블과 후행 테이블 조인)

먼저 선행 테이블의 조건을 만족하는 행을 추출하여 후행 테이블을 읽으면서 조인을 수행한다. 이 작업은 선행 테이블의 조건을 만족하는 모든행의 수만큼 반복 수행한다. NL JOIN에서는 선행 테이블의 조건을 만족하는 행의 수가 많으면(처리 주관의 범위가 넓으면), 그 만큼 후행 테이블의 조인 작업은 반복 수행한다. 따라서 결과 행의 수가 적은(처리 주관 범위가 좁은) 테이블을 조인 순서상 선행 테이블으로 선택하는 것이 전체 일량을 줄일 수 있다. NL JOIN은 랜덤 방식으로 데이터를 엑세스하기 때문에 처리 범위가 좁은 것이 유리하다.

NL JOIN의 작업 방법은 다음과 같다.

1. 선행 테이블에서 주어진 조건을 만족하는 행을 찾음

2. 선행 테이블의 조인 키 값을 가지고 후행 테이블에서 조인 수행

3. 선행 테이블의 조건을 만족하는 모든 행에 대해 1번의 작업 반복 수행

이동할 위치 위치 이동 클릭

1. 선행 테이블에서 조건을 만족하는 첫 번째 행을 찾음

-> 이때 선행 테이블에 주어진 조건을 만족하는 않은 경우 해당 데이터는 필터링 됨

2. 선행 테이블의 조인키를 가지고 후행 테이블에 조인키가 존재하는지 찾으러 감

-> 조인시도

3. 후행 테이블의 인덱스에 선행 테이블의 조인 키가 존재하는지 확인

-> 선행 테이블의 조인 값이 후행 테이블에 존재하지 않으며 선행 테이블의 데이터는 필터링 됨(더 이상 조인작업을 진행할 필요 없엄)

4. 인덱스에서 추출한 레코드 식별자를 이용하여 후행 테이블을 엑세스

->인덱스 스캔을 토안 테이블 엑세스

후행 테이블에 주어진 조건까지 모두 만족하면 해당 행을 추출버퍼에 넣음

5~10 앞의 작업을 반복 수행

SORT MERGE JOIN

조인 칼럼을 기준으로  데이터를 정렬하여 조인을 수행, NL JOIN은 주로 랜덤 엑세스 방식으로 데이터를 읽는 반면 SORT MERGE JOIN은 주로 스캔 방식으로 데이터를 읽는다. SORT MERGE JOIN은 랜덤 엑세스로 부담이되던 넓은 범위의 데이터를 처리할 때 이용되던 조인 기법이다. 그러나 SORT MERGE JOIN은 정렬할 데이터가 많아 메모리에서 모든 정렬 작업을 수행하기 어려운 경우에는 임시 영역(디스크)을 사용하기 때문에 성능이 떨어질 수 있다.

일반적으로 대량의 조인 작업에서 정렬 작업을 필요로 하는 SORT MERGE JOIN보다는 CPU 작업 위주로 처리하는 HASH JOIN이 성능상 유리하다. 그러나 SORT MERGE JOIN은 HASH JOIN과는 달리 동등 조인 뿐만 아니라 비동등 조인에 대해서도 작업 가능하다는 장점이 있다.

1. 선행 테이블에서 주어진 조건을 만족하는 행을 찾음

2. 선행 테이블의 조인 키를 기준으로 정렬 작업을 수행

1~2번 작업을 선행 테이블의 조건을 만족하는 행을 찾음

3. 후행 테이블에서 주어진 조건을 만족하는 행을 찾음

4. 후행 테이블에서 조인 키를 기준으로 정렬 작업을 수행

3~4번 작업을 후행 테이블의 조건을 만족하는 모든 행에 대해 반복 수행

5. 정렬된 결과를 이용하여 조인을 수행하며 조인에 성공하면 추출버버에 넣음

SORT MERGE JOIN은 조인 컬럼의 인덱스를 사용하지 않기 때문에 조인 컬럼의 인덱스가 존재하지 않을 경우에도 사용할 수 있는 조인 기법이다. SORT MERGE JOIN 에서 조인 작업을 위해 항상 정렬 작업이 발생하는 것은아니다. 예를 들어, 조인할 테이블 중에서 이미 앞 단계의 작업을 수행하는 도중에 정렬 작업이 미리 수행되었다면 조인을 위한 정렬 작업은 발생되지 않을 수 있다.

HASH JOIN

HASH JOIN은 해쉬 기법을 이용하여 조인을 수행한다. 조인을 수행할 테이블의 조인 컬럼을 기준으로 해쉬 함수를 수행하여 서로 동일한 해쉬 값을 갖는 것들 사이에서 실제 값이 같은지를 비교하면서 조인을 수행한다. NL JOIN의 랜덤 엑세스 문제점과 SORT MERGE JOIN의 문제점인 정렬 작업의 부담을 해결을 위한 대안으로 등장하였다.

1. 선행 테이블에서 주어진 조건을 만족하는 행을 찾음

2. 선행 테이블의 조인키를 기준으로 해쉬 함수를 적용하여 해쉬 테이블을 생성

->조인 컬럼과 SELECT 절에서 필요로 하는 컬럼도 함께 저장됨

1~2번 작업을 선행 테이블의 조건을 모두 만족하는 모든 행에 대해 반복 수행

3. 후행 테이블에서 주어진 조건을 만족하는 행을 찾음

4. 후행 테이블의 조인 키를 기준으로 해쉬 함수를 적용하여 해당 버킷을 찾음

->조인 키를 이용해서 실제 조인될 데이터를 찾음

5. 조인에 성공하면 추출버퍼에 넣음

3~5번 작업을 후행 테이블의 조건을 만족하는 모든 행에 대해서 반복 수행

HASH JOIN은 조인 컬럼의 인덱스를 사용하지 않기 때문에 조인 컬럼의 인덱스가 존재하지 않을 경우에도 사용할 수 있는 조인 기법이다. HASH JOIN은 해쉬 함수를 이용하여 조인을 수행하기 때문에 '='로 수행하는 조인 즉, 동등 조인에서만 사용할 수 있다.

해쉬함수를 적용한 값은 어떤 값을 해쉬될 지 알 수 없다. 해쉬 함수가 적용될 때 보다 큰 값이 항상 큰 값으로 해쉬되고 항상 작은 값으로 해쉬되다는 보장이 없다. 그렇기 때문에 HASH JOIN은 동등한 조인에서만 사용할 수 있다.

HASH JOIN은 조인 작업을 수행하기 위해 해쉬 테이블을 메모리에 생성해야 한다.

생성된 HASH 테이블의 크기가 메모리에 적재할 수  있는 크기보다 더 커지면 임시영역(디스크)에 해쉬 테이블을 저장한다. 그러면 추가적인 작업이 필요해진다. 그렇기 때문에 HASH JOIN을 할 때는 결과 행의 수가 적은 테이블을 선행 테이블로 사용하는 것이 좋다. 선행 테이블의 결과를 완전히 메모리에 저장할 수 있다면 임시 영역에 저장하는 작업이 발생하지 않기 때문이다.

HASH JOIN에서는 선행 테이블을 이용하여 먼저 해쉬 테이블을 생성한다고 해서 선행 테입르을 BUILD INPUT이라고도 하며, 후행 테이블은 만들어진 해쉬 테이블에 대해 해쉬 값의 존재 여부를 검사한다고 해서 PROVE INPUT이라고도 한다.

인덱스

가. 트리기반 인덱스

B-트리 인덱스는 '='로 검색하는 일치(EXACT MATCH) 검색과 'BETWEEN','>'등과 같은 연산자로 검색하는  범위에 모두 적합한 구조이다.

1단계, 브랜치 블록의 가장 왼쪽 값이 찾고자 하는  값보다 작거나 같으면 왼쪽 포인터로 이동

2단계, 찾고자 하는 값이 브랜치 블록의 값 사이에 존재하면 가운데 포인터로 이동

3단계, 오른쪽에 있는 값보다 크면 오르쪽 포인터로 이동

인덱스를 생성할 때 동일 컬럼으로 구성된 인덱스를 중복해서 생성 할  수 없다. 그렇지만 인덱스 구성 컬럼은 동일하지만 컬럼 순서가 다르면 서 다른 인덱스로  생성할 수 있다. 예를 들어 , JOB+SAL 컬럼 순서의 인덱스와 SAL+JOB 컬럼 순서의 인덱를 별도의 인덱스를 생성할 수 있다. 인덱스의 칼럼 순서는 질의의 성능에 중요한 영향을 미치는 요소이다.

1) 인덱스 유일 스캔은 유일 인덱스를(UNIQUE INDEX)를 사용하여 단 하나의 데이터를 추출하는 방식이다. 유일 인덱스는 중복을 허락하지 않는 인덱스이다. 유일 인덱스 구성 컬럼에 모두 '='로 값이 주어지면 결과는 최대 한 1건이 된다. 인덱스 유일 스캔은 유일 인덱스 구성 컬럼에 대해 모두 '='로 값이 주어진 경우에만 가능한 가능한 스캔 방식이다.

2)인덱싀 범위 스캔은 인덱스를 이용하여 한 건 이상의 데이터를 추출하는 방식이다. 유일 인덱스의 구성 컬럼 모드에 대해 '='으로 주어지지 않은 경우와 비유일(NON-UNIQUE)  인덱스를 이용하는 모든 엑세스 방식은 범위 스캔 방식으로 데이터를 엑세스하는 것이다.

3)인덱스 역순 범위 스캔은 리프블록의 양방향 링크를 이용하여 내림 차순으로 데이터를 읽는 방식이다. 이방식을 이용하여 최대값을 쉽게 찾을 수 있다.

실행계획

실행계획(EXECUTION PLAN)이란 SQL에서 요구한 사항을 처리하기 위한 절차와 방법을 의미한다. 실행계획을 생성한다는 것은 SQL을 어떤 순서로 실행할 지를 결정하는 작업이다. 동인한 SQL에 대해 결과를 낼  수 있는 다양한 처리 방법(실행계획)이 존재할 수 있지만 각 처리방법마다 실행 시간(성능)은 서로 다를 수 있다. 옵티마이저는 다양한 처리 방법들 중에서 가장 효율적인 방법을 찾아 준다. 즉, 옵티마이저는 최적의 실행계획을 생성해 준다.

제 8절 절차형 SQL

1. 절차형 SQL의 비교

PL/SQL의 특징

- PL/SQ은 BLOCK 구조로 되어 있어 각 기능별로 모듈화가 가능하다.

- 변수, 상수 등을 선언하여 SQL 문장 간 값을 교환한다.

- IF, LOOP 등의 절차형 언어를 사용하여 절차적인 프로그램이 가능하도록 한다.

-DBMS 정의 에러나 사용자 정의 에러를 정의하여 사용할 수 있다.

-PL/SQL은 오라클에 내장되어 있으므로 ORACLE과 PL/SQL을 지원하는 어떤 서버로도 프로그램을 옮길 수 있다.

-PL/SQL은 응용 프로그램의 성능을 향상시킨다.

-PL/SQL은 여러 SQL문장을 BLOCK으로 묶고 한 번에 BLOCK 전부를 서버로 보내기 때문에 통신량을 줄일 수 있다.

PL/SQL의 구조

-DECLEAR : BEGIN~END 절에서 사용될 변수와 인수에 대한 정의 및 데이터 타입을 선언하는 부분이다.

-BEGIN~END : 개발자가 처리하고자 하는 SQL문과 여러 가지 비교문, 제어문을 이용하여 필요한 로직을 처리하는 실행부이다.

-EXCEPTION : BEGIN ~ END 절에서 실행되는 SQL문이 실행될 때 에러가 발생하면 그 에러를 어ㄸ허게 처리할 것인지 정의하는 예외 처리부이다.

. oraenv

+ASM1

sqlplus "/as sysasm"

1.DISPLAY                 --> 예측 실행계획을 보여준다.
2.DISPLAY_CURSOR   --> 실제 실행된 실행계획을 보여준다.
3.DISPLAY_AWR         --> 실제 실행된 실행계획을 보여준다.

--sql레벨
select /*+ GATHER_PLAN_STATISTICS */ *
from dept a
where a.dept_no = '11111'
;

--session 레벨
select  *
from dept a
where a.dept_no = '11111'
;

display_cursor, display_awr 의  경우 statistics_level 파라미터를 all 로 설정하거나 SQL 에 gather_plan_statistics 를 사용한경우 실행통계를 볼수 있다.

-- sql id만 알면 실행계획을 알수 있다
select * from table(dbms_xplan.display_awr(:v_sql_id,null,null,'advanced allstats last'));

select * from table(dbms_xplan.display_cursor(NULL, NULL, 'ALLSTATS ADVANCED'))

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

1)Basics 항목 (Always Available)

Id                :각 Operation 의 ID 임.
                  * 가 달려있는 경우는 predicate 정보에 access 및 filter 에 관한정보가 나옴을 표시한것임.

Operation  : 각각 실행되는 JOB 을 나타냄   row source operation.의 줄임말임.

Name          : Operation 이 엑세스하는 테이블 및 인덱스를 나타냄.
 

2)Query Optimizer Estimations(옵티마이져의 예상 row 수 및 bytes, cost , temp 사용량)

Rows (E-Rows)  : 각 operation 이 끝났을 때 return되는 건수를 나타냄.

                              이것은 예측 건수 이므로 실제 건수와는 다름.

Bytes (E-Bytes) : 각 operation 이 return 한 byte 수.
                              예상치 이므로 실제 받은 byte와는 다름

TempSpc             : 각 operation. 이 temporary space 를 사용한 양(예상치임)

Cost (%CPU)      : 각 operation 의 Cost. (예상치 임)

                              괄호안의 내용은 CPU Cost 의 백분율임.

                               이값은 Child Operation 의 Cost 를 합친 누적치임.

Time                     : 예측 수행시간

3)Partitioning (파티션을 엑세스 할경우만 나타남)

Pstart  : 파티션을 엑세스 하는경우 시작파티션을 나타냄

             상수로 들어올때는 파티션 번호로 나타나며 변수로 들어올때는 KEY 로 나타남

Pstop  : 마지막 파티션을 나타냄.

              따라서 patart, pstop 를 이용하면 access 한 파티션을 알수 있음.

4)Parallel and Distributed Processing (Parallel Processsing 을 사용하거나 DB-LINK 를 사용하는경우)

Inst         :  DB-LINK 명(사용하는 경우만 나타남).

TQ            :  PARALLEL SQL 사용시 table queue 명을 나타냄
                   TQ 는 PARALLEL SLAVE 간의 통신을 담당함.

IN-OUT      :  Parallel processing 시에 각각의 Operation 이 Serial 로 실행되는지 parallel 로 진행되는지를
                     나타냄.

PQ Distrib :  Parallel processing 시에 producers 와 consumers 간의 데이터의 분배방식을 나타냄.

* 이부분의 자세한 내용은 아래를 참조하기 바란다.
1.http://scidb.tistory.com/entry/Parallel-Query-의-조인시-Row-Distribution
2.http://scidb.tistory.com/entry/Parallel-Query-의-조인시-또다른-튜닝방법pxjoinfilter

5)Runtime Statistics (실제 수행시간밑 실제수행건수)
 
Starts     : 각 operation 을 try 한 건수(예를 들어 nested loop join 이라면 인덱스를 여러 번 scan 함)

A-Rows  : 각 operation 이 return 한 건수

A-Time   : 실제 실행시간

0.1초까지 나타남 (HH:MM:SS.FF).

                 이값은 Child Operation 의 Cost 를 합친 누적치임.            
 

6)I/O Statistics (I/O 관련하여 READ / WRITE 한 블록수)
 
Buffers  : 각 Operation 이 메모리에서 읽은 block 수.

Reads   :각 Operation 이 disk 에서 읽은 block 수.

Writes   : 각 Operation 이 disk 에 write한 block 수.

7)Memory Utilization Statistics(hash 작업이나 sort 작업시 사용한 메모리 통계)
 
OMem         : optimal execution 에 필요한 메모리(예측치임).

1Mem          : one-pass execution. 에 필요한 메모리(예측치임)

O/1/M        : 각 operation 이 실행한 optimal/one-pass/multipass 횟수가 순서대로 표시됨.

Used-Mem : 마지막 실행시의 사용한 메모리

Used-Tmp  : 마지막 실행시 메모리가 부족하여 temporary space 를 대신 사용할 때 나타남.

                      보이는값에 1024 를 곱해야함.
                      예를들어 32K 로 나타나면 32MB 를 의미함.

Max-Tmp    : 메모리가 부족하여 temporary space 를 사용할 때 최대 temp 사용량임.

                     USED-TMP 와 다른점은 마지막 수행시가 아니라 SQL을 여러 번 수행했을경우에
                     항상 최대값만 보인다는 것이다.
                     보이는값에 1024 를 곱해야함.
                     예를들어 32K 로 나타나면 32MB 를 의미함.

결론:
이상으로 PLAN 상에 나오는 각 항목에 대하여 빠짐없이 알아보았다.
특히 Runtime 통계,  I/O 통계및 Memory 통계중의 일부항목은 Tkprof 보고서에도 나오지않는 정보

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

이정보들은 DBMS_XPLAN.DISPLAY 함수에는 적용되지 않는다. 왜냐하면 explain plan 은 쿼리가 실제 수행되는것이 아니므로 실행통계정보가 없기 때문이다.
또한 DBMS_XPLAN.DISPLAY_CURSOR 나 DBMS_XPLAN.DISPLAY_AWR 등의 함수 수행시에도 GATHER_PLAN_STATISTICS 힌트를 주거나 아니면 파라미터 STATISTICS_LEVEL = ALL 로 되어 있어야 출력이 가능하다.

1.allstats : I/O 통계정보(Buffers, Reads, Writes)와 PGA 통계정보(OMem, 1Mem , Used-Mem, Used-Tmp,
                Max-Tmp 등)를 동시에 control 한다.
2.iostats : I/O 통계정보(Buffers, Reads, Writes)를 control 한다.
3.last : 실행통계 출력시 이 control을 명시하면 가장마지막에 수행된 실행통계를 출력한다.
          이 control을 명시하지 않으면 실행통계의 누적치를 출력하므로 주의가 필요하다.
4.memstats :PGA 통계정보(OMem, 1Mem , Used-Mem, Used-Tmp, Max-Tmp 등)를 control 한다.
5.runstats_last : iostats control 과 last control 을 합친것과 같다.
                       이 control은 Oracle 10g Release 1 에서만 사용할수 있다.
6.runstats_tot : iostats control과 동일하다.  이 control은 Oracle 10g Release 1 에서만 사용할수 있다.

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

권장되는 포맷 유형
SELECT *
   FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL, 'allstats last -rows +predicate'));

 포맷을 'allstats last -rows +predicate' 로 주었으므로 예측 row 수(E-row) 가 생략되고 실행통계와
Predicate Information 만을 출력한다.

SELECT * FROM
  TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL, 'allstats last -rows +alias +outline +predicate'));
  'allstats last -rows +alias +outline +predicate' 포맷을 사용하면 Query Block Name / Object Alias 정보와 Outline Data 정보가 추가로 출력된다.

  쿼리변형이 발생한경우나 뷰(혹은 인라인뷰) 등을 튜닝할경우 아주 적합한 옵션이다. 하지만 특이한경우
Column Projection Information 이 필요한경우도 있다. 이경우는 +projection 포맷을 추가해주면 된다.

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

사용방법

① Explain plan [set statement_id = 'identifier' ] [ Into tablename ] for + SQL;

분석하고자 하는 SQL을 'Explain plan for' 다음에 넣고 Enter

② Select * from Table(DBMS_XPLAN.DISPLAY);

SQL이 Explain 되었으면 그 다음에 원하는 포맷으로 출력하기 위해서 위와 같이 기본적으로 'PLAN_TABLE'과 'TYPICAL' Format으로 출력

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

?*Access Predicate*는 Access Type을 결정하는데 사용되는 Predicate(조건)을 의미한다. 더 정확하게 말하면 실제 Block을 읽기 전에 어떤 방법으로 Block을 읽을 것인가를 결정한다는 의미이다.
따라서 Index Lookup이나 Join등은 Access Predicate로 표현된다.
?
*Filter Predicate*는 실제 Block을 읽은 후 Data를 걸러 내기 위해 사용되는 Predicate(조건)를 의미한다

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

Nested Loops Join
 
선행 Table읽으면서 후행 Table을 한번씩 Access
 
실제 Join은 후행 Table에 대한 Access에서 발생하기 때문에 실제 Join은 후행 Table에 대한 Acccess에서 발생한다. 

그러므로 후행 Table을 읽는 단계가 Access Predicate가 된다.
 

Hash Join
 
선행 Table을 먼저 Build한 후, 후행 Table과 한번에 Join
 
실제 Join이 발생하는 Hash Join 단계가 Access Predicat로 표현된다.
 

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

실측내용
 
ALLSTATS LAST
 
실제 액세스한 로우수와 수행시간 그리고 CR, PR, PW 정보를 보여준다.

*가장 최근*에 수행된 값만 보여준다.
 

실측내용
 
ADVANCED ALLSTATS LAST
 
DBMS_XPLAN.DISPLAY_CURSOR에서 지원하는 모든 Format의

정보를 보여준다.
 
------------------------------------------------------------------

SQL> alter session set events '10046 trace name context forever, level 12';
SQL> explain plan for
          select * from delete_test
          where id < 1000;
SQL> alter session set events '10046 trace name context off';

----------------------------------------------------------------
colored sql 이란?

----------------------------------------------------------------
다섯 가지의 실행계획 존재

1. explain plan : 예상실행 계획

2. shared pool에 올라가 있는 실제 실행계획

3. AWR : 과거의 실행계획이 저장

4. SQL Tuning Advisor : 튜닝된 실행계획을 보관

5. SQL Plan Baseline(11g) : 실행가능한 후보 실행계획

이 다섯가지의 실행계획을 좀 더 편하게 조회하게 하는 것이  dbms_xplan package의 목적

다섯개의 함수 제공.

1. display (9i)

2. display_cursor (10g)

3. display_awr (10g)

4. display_sqlset (10g)

5. display_sql_plan_baseline (11g)

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

2) V$SQL_PLAN

10gR2 까지 dbms_xplan 패키지로 v$sql_plan 을 직접 조회할 수 있는 기능은 구현되지 않았으나 차후에 구현될 예정이라고 합니다. Tom Kyte는 이러한 제약사항을 view로 만들어 해결하고 있습니다.

SQL> create or replace view dynamic_plan_table
  2  as
  3  select
  4   rawtohex(address) || '_' || child_number statement_id,
  5   sysdate timestamp, operation, options, object_node,
  6   object_owner, object_name, 0 object_instance,
  7   optimizer,  search_columns, id, parent_id, position,
  8   cost, cardinality, bytes, other_tag, partition_start,
  9   partition_stop, partition_id, other, distribution,
 10   cpu_cost, io_cost, temp_space, access_predicates,
 11   filter_predicates
 12   from v$sql_plan;

위와 같은 view를 만들고 난 후 아래 쿼리로 조회합니다.

SQL> select plan_table_output
  2    from TABLE( dbms_xplan.display
  3                ( 'dynamic_plan_table',
  4                  (select rawtohex(address)||'_'||child_number x
  5                     from v$sql
  6                    where sql_text='select * from t t1 where object_id > 32000' ),
  7                  'serial' ) )
  8  /

DBA 입장에서는 다른 툴이나 모니터링 스크립트를 사용하여 SQL hash value 등을 구하여
아래와 같이 쿼리하는 것이 훨씬 편할 것입니다.

위의 쿼리도 2가지 정도 취약점이 있는데 첫번째는 조회 속도가 약간 느리며 두번째는 child cursor가 생성되면 single row가 아닌 multi row를 리턴하므로 실행 에러가 발생합니다.
또한 버전에 따라 internal error 가 발생할 가능성이 있을 수도 있습니다.

child cursor에 따른 version 문제는 child_number 를 조회조건에 추가하여 single row 만을 리턴하도록 회피하면 됩니다. 조회속도는 문제는 v$sql_plan 의 특정 실행계획을 plan_table 에 저장한 후 dbms_xplan 을 조회하는 방법을 사용해도 되겠습니다.

SQL> insert into plan_table                                               
  2  select                                                               
  3   rawtohex(address) || '_' || child_number statement_id,              
  4   sysdate timestamp,'' remarks, operation, options, object_node,      
  5   object_owner, object_name, 0 object_instance, '' object_type,       
  6   optimizer,  search_columns, id, parent_id, position,                
  7   cost, cardinality, bytes, other_tag, partition_start,               
  8   partition_stop, partition_id, other, distribution,                  
  9   cpu_cost, io_cost, temp_space, access_predicates,                   
 10   filter_predicates                                                   
 11   from v$sql_plan where hash_value = 2799829231;           

-SQL> select * from table(dbms_xplan.display);           

job test를  수행합니다.

해당 job은

create sequence seq_job_seq1;

create table job_test01
(no number,
name varchar(5)
)

create or replace procedure insert_job_test01
is
begin
insert into scott.job_test01
values(seq_job_seq1.nextval, dbms_random.string('a',3));
end;
/

begin
dbms_job.submit
(
:jno,
'scott.insert_job_test01;',
sysdate,
'sysdate + 1/24/60',
false);
end
/

How to clean up after a failed 11g CRS install. What is new in 11g R2?

How to clean up after a failed 11g CRS install. What is new in 11g R2?

Although it sounds pretty much the same as a previous post How to Clean Up After a Failed 11g CRS Install in Linux
here we are looking at specifics related to Oracle 11g R2.

In Oracle 11g R1 if the Oracle Clusterware installation failed a manual cleanup was required. Steps to re-install Oracle clusterware was:

1. Manually cleanup after the failed Oracle Clusterware install
   
2. Fix the problem
   
3. Restart the Oracle Clusterware installation.
   

In Oracle 11g R2 the installation and configuration are made more flexible and there is a clearer line between installation and configuration. In Oracle 11gR2 a new script roocrs.pl is available to de-configure and clean the Grid Infrastructure installation without removing the binaries. This script also cleans the OCR and vote disks created on ASM. The script allows to clean up the Grid Infrastructure without removing the binaries, fix the problems and re-run root.sh.

Manual Cleanup for RAC 11gR1

The Oracle provided scripts rootdelete.sh and rootdeinstall.sh remove Oracle Clusterware from your system. After running these scripts, run Oracle Universal Installer to remove the Oracle Clusterware home.
The rootdelete.sh script should be run from the Oracle Clusterware home on each node. It stops the Oracle Clusterware stack, removes inittab entries, and deletes some of the Oracle Clusterware files. The rootdeinstall.sh script should be run on the local node only, after rootdelete.sh has been run on all nodes of the cluster. Use this command either to remove the Oracle Clusterware OCR file, or to downgrade your existing installation. If for some reasons there is no access to the scripts look at the post How to Clean Up After a Failed 11g CRS Install in Linux how to remove the inittab entries and Oracle Clusterware. Although the method described in the post applies to Oracle 11g R2 the new tools can suffice most of the time.

What is new in Oracle 11g R2?

In Oracle 11g R2 a tool rootcrs.pl is provided allowing de-configuration without deinstall. After Oracle Clusterware is de-configured we can fix the problem and re-run the root.sh to re-start the Oracle Clusterware configuration.

New deinstall utility removes the binaries from the server in a similar way to OUI in previous Oracle versions.

So if root.sh fails while we install Oracle Grid infrastructure we can gather error messages from the logs, de-configure Oracle clusterware and troubleshoot the reason for the failure. After Oracle Clusterware de-configuration and successful troubleshooting we can proceed further with the configuration re-running root.sh if the problem can be fixed. Thus, in case of errors such as permissions we can save time re-installing Oracle Clusterware binaries. If necessary, we still have an option to completely remove the Oracle Clusterware binaries using the deinstall utility. Prior to running deinstall Oracle Clusterware must be de-configured using rootcrs.pl tool. Successful deinstall preceded by successful de-configure gives a pristine environment to re-start Oracle Grid installation after the failed install is troubleshot based on information gathered examining the logs.

Deconfigure Oracle Clusterware without removing the binaries:

• Log in as the root user on a node where you encountered an error. Change directory to $GRID_HOME/crs/install. For example:
  

  # cd $GRID_HOME/crs/install
  

• Run rootcrs.pl with the -deconfig -force flags on all but the last node.
  

  # perl rootcrs.pl -deconfig -force
  

• If you are deconfiguring Oracle Clusterware on all nodes in the cluster, then on the last node add the –lastnode flag that completes deconfiguration on the cluster including the OCR and the voting disks.
  

  # perl rootcrs.pl -deconfig -force -lastnode
  

Deinstall Command for Oracle Clusterware and ASM

In Oracle 11gR2 binaries cannot be removed using the OUI. Instead Oracle provides deinstall utility. The deinstall utility removes the Oracle clusterware and ASM from the server. The deinstallation Tool (deinstall) stops Oracle software, and removes Oracle software and configuration files on the operating system. It is available in the installation media before installation, and is available in Oracle home directories after installation. It is located in the path $ORACLE_HOME/deinstall. You can use the Deinstallation Tool (deinstall) to remove failed or incomplete installations. It is available as a separate download from the Oracle Technology Network (OTN) Web site.

As the deinstall command runs, you are prompted to provide the home directory of the Oracle software that you want to remove from your system. Provide additional information as prompted. To run the deinstall command from an Oracle grid infrastructure for a cluster home, enter the following command.

$ cd /u01/app/11.2.0/grid/deinstall/ 
$ ./deinstall 

You can generate a deinstall parameter file by running the deinstall command using the -checkonly flag before you run the command to deinstall the home, or you can use the response file template and manually edit it to create the parameter file to use with the deinstall command.

August 12, 2010 - Posted by gjilevski | oracle

7 Comments »

1.  

   1

    

   0

    

   i

    

   Rate This

   

   Thanks for the update about deinstall utility. what would be the sequence if I want to uninstall entire RAC setup which includes Cluster,ASM and DB?

   I guess I need to run “deinstall” from Database and then go for the “Deinstall Command for Oracle Clusterware and ASM” as suggested by you…

   Please correct me if wrong.

   Comment by Suchi | November 16, 2010 | Reply

   •  

     0

      

     0

      

     i

      

     Rate This

     

     Hello,

     Correct, you need to deinstall the binaries and drop database(s). I would

     1. Drop database(s) RDBMS $OH
     2. Deinstall binaries RDBMS $OH
     3. Deconfigure and deinstall Grid $OH

     Regards,

     Comment by gjilevski | November 16, 2010 | Reply

2.  

   0

    

   1

    

   i

    

   Rate This

   

   Can i have only one device /dev/sdc1 defined for OCR and voting disk. I did so and grid installation went through fine. CRS was also working fine.
   But when I restarted CRS is not starting. ASM instance is up and running.
   Error in the log is: CRS-1013: the OCR location in an ASM disk group is inaccessible
   Error in open/create file in dg[DGDATA]

   Comment by Dinesh | May 25, 2011 | Reply

   •  

     0

      

     1

      

     i

      

     Rate This

     

     Hi,

     What is Oracle Clusterware version?

     To see more information why the clusterstack did not start up look into the following logfiles:

     $GI_HOME/log//alert*.log

     For the specific process (crsd, cssd)
     $GI_HOME/log//cssd.log
     $GI_HOME/log//crsd.log

     How is the diskgroup defined? If external redundancy is used than you should be able to start if ASM dishgroup is used for storage.

     Where exactly the error happened? I would examine the logs. There are some notes on MOS about this error. It depends on Oracle GI version and OS version.

     You need to see according to the specifics OS/GI/RDBMS version and number of nodes.

     Regards,

     Guenadi Jilevski

     Comment by gjilevski | May 25, 2011 | Reply

   •  

     0

      

     0

      

     i

      

     Rate This

     

     CRS-1013:The OCR Location in an ASM Disk Group is Inaccessible on Clusterware Startup [ID 1153244.1]
     CRS Does not Start after Node Reboot in 11gR2 Grid Infrastructure [ID 1215893.1]
     11.2.0.1 Grid Infrastructure Installation Failed at Second Nodes While Running root.sh Due To ASM Crash Caused by lmon Timeout [ID 1239123.1]

     etc..

     Regards,

     Guenadi Jilevski

     Comment by gjilevski | May 25, 2011 | Reply

3.  

   0

    

   2

    

   i

    

   Rate This

   

   Wonderful work! That is the type of info that are supposed to be shared around the internet. Disgrace on the seek engines for no longer positioning this post upper! Come on over and consult with my site . Thank you =)

   Comment by business directory | November 30, 2011 | Reply

4.  

   0

    

   0

    

   i

    

   Rate This

   

   [...] We have refer Guenadi Jilevski Blog [...]

   Pingback by CRS-4046: Invalid Oracle Clusterware configuration. – 11gR2 | hiteshgondalia | March 10, 2013 | Reply

statistics_level  파라메터 - 오라클 자가 진단을 통해 통계치를 수집하는 레벨을 정의하는 파라메터

                                      TYPICAL - 데이터베이스 통계를 수집

  ALL - 데이터베이스 통계와 SQL 실행 계획 통계를 추가로 수집

Automatic Workload Repository(AWR)

자가 진단(Automaic Database Diagnostic Monitor, ADDM)

공유 메모리 자동 관리

자동 옵티마이저 통계 수립

--data pump 모니티링
select * from dba_datapump_jobs;
select * from dba_datapump_sessions;

--directory 생성
create directory temp_dir as '/u01';
grant read,write on directory temp_dir to scott;--  유저에 권한 부여
grant EXP_FULL_DATABASE, IMP_FULL_DATABASE  to scott;

SQL> create user dpumpuser identified by dpumpuser;
SQL> grant connect, resource, exp_full_database, imp_full_database to dpumpuser;
SQL> create directory data_pump as '/home/oracle/data_pump';
SQL >grant read, write on directory data_pump to dpumpuser;

$ expdp system/asd123 full=y directory=DATA_PUMP_DIR dumpfile=DATA_PUMP_TEST.dmp
$ impdp dpumpuser/dpumpuser directory=data_pump dumpfile=20081030.dmp

11:50

expdp system/asd123 DIRECTORY=DATA_PUMP_DIR  dumpfile=test1.dmp, test2.dmp, test3.dmp parallel=3 Logfile=DATA_PUMP_TEST2.log CONTENT=DATA_ONLY

dumpfile=DATA_PUMP_TEST1.dmp
dumpfile=(test1.dmp, test2.dmp, test3.dmp) parallel=3

contents={all | metadata_only | data_only}

Data Pump Export 파라메타 (파일 및 디렉토리 관련 파라메타)

      1)  DIRECTORY : 덤프파일의 위치 및 로그파일의 위치 지정

      2)  DUMPFILE : export 받아 파일시스템에 저장될 덤프파일의 이름을 지정하는 파라메타

      3)  FILESIZE : export 받는 1개 파일의 최대크기를 지정하는 파라메타

      4)  PARFILE : 파일에 파라메타들을 저장해 두고 Data Pump를 이용할 때마다 참조 하여 작업을 수행

      5)  LOGFILE and NOLOGFILE :  로그파일명을 지정하는 파라메타. 파라메타를 설정하지 않으면 export.log라는
                                  파일명으로 로그가 남음
    
      6)  COMPRESSION : METADATA_ONLY, NONE 두개의 옵션이 있으며 덤프파일내에 메타데이타가 압축되어 보관된다.
                        디폴트는 METADATA_ONLY로 설정되어 있음 (실제 데이터가 압축되어 보관됨)
                       
Data Pump Export 파라메타 (export 필터링 관련 파라메타)

      1)  CONTENT : 3개의 옵션을 가질 수 있음. (ALL, DATA_ONLY, METADATA_ONLY)

      2)  EXCLUDE and INCLUDE : 원하는 오브젝트를 제외하거나 포함 시켜 받을 수 있다.
                               INCLUDE 또는 EXCLUDE=OBJECT_NAME:”=‘조건’” 형식으로 사용할 수 있으며,
                               오브젝트의 종류에는 TABLE, INDEX, PROCEDURE, FUNCTION 등이 있다.

      3)  QUERY : 테이블 내에 있는 데이터 중 특정 조건에 만족하는 데이터만 export 받고자 할 때 사용.
                      EX) QUERY=SCOTT.EMP:”where SAL>1000”

      4)  SAMPLE : 테이블의 데이터를 export 할 때 퍼센트를 정해서 지정된 퍼센트 만큼의 데이터를 샘플링 해서 뽑음.
                      EX) SAMPLE=SCOTT.EMP:20

  Data Pump Export 파라메타 (JOB 관련 파라메타)

      1)  JOB : Data Pump의 작업명을 JOB 파라메타에 주어진 이름으로 등록

      2)  STATUS : 작업의 갱신된 내용을 STATUS에 설정된 크기의 시간 간격으로 진행 상태를 보고자 할 때 등록

      3)  FLASHBACK_SCN : FLASHBACK_SCN 파라메타를 이용하여 SCN(system change number) 값을 지정할
                         경우에 설정된 SCN기준 이전까지의 상태를 받아 볼 수 있다.

      4)  FLASHBACK_TIME : 파라메타에 지정된 시간까지의 변경사항만을 Export 하게 된다.

      5)  PARALLEL : PARALLEL 파라메타를 사용할 경우 export 작업시에 프로세스를 필요한 숫자 만큼 만들어
                    수행 함으로써 작업의 속도를 향상 시킬 수 있다. PARALLEL 수만큼 dmp 파일 개수가 필요함

Data Pump import 관련 파라메타(필터링 관련 파라메타)

      1)  CONTENT : DATA_ONLY, ALL, METADATA_ONLY 3가지 값을 가질 수 있음.

      2)  INCLUDE, EXCLUDE : INCLUDE 또는 EXCLUDE=OBJECT_NAME:”=‘조건’” 형식으로 사용할 수 있으며,
                            오브젝트의 종류에는 TABLE, INDEX, PROCEDURE, FUNCTION 등이 있다.

      3)  TABLE_EXISTS_ACTION : SKIP, APPEND, TRUNCATE, REPLACE 의 값을 가질 수 있다.
            - SKIP : 같은 테이블을 만나면 지나치고 다음 테이블을 import 한다.
            - APPEND : 같은 테이블을 만나면 기존의 데이터에 추가하여 import 한다
            - TRUNCATE : 같은 테이블을 만날 경우 기존의 테이블을 TRUNCATE 하고 새로운 데이터를 import 한다.
            - REPLACE : 같은 테이블을 만날 경우 기존의 테이블을 DROP 하고 테이블을 재생성 한 후 데이터를 import한다.
           
Data Pump import 관련 파라메타(리맵핑 관련 파라메타)

      1)  REMAP_SCHEMA : A 유저 스키마로 Export 받은 데이터를 B 유저 스키마로 import 하고자 할때 사용.
                           EX) REMAP_SCHEMA=SCOTT:TEST

      2)  REMAP_DATAFILE : Export 된 dumpfile 에는 datafile 정보까지 포함하게 된다. 하지만 다른 시스템의 디스크
                           경로 상에는 존재하지 않는 경로이기 때문에 import에 실패하게 된다. 이러한 경우에 사용
                           할 수 있는 파라메타가 REMAP_DATAFILE 이다.
                           EX) REMAP_DATAFILE='/ora10/oradata1','/ora10/oradata2'

      3)  REMAP_TABLESPACE : Export 받은 데이터파일에 속한 TABLESPACE에서 다른 테이블 스페이스로
                             REMAPPING 하고자 하는 경우 사용
                           EX) REMAP_TABLESPACE='scott_tsb':'test:tbs'

expdp hr/hr
tables=paratest
directory=data_pump_test
dumpfile=paratest%U.dmp
parallel=3
job_name=parr_test

impdp hr/hr directory=data_pump_test dumpfile=paratest%U.dmp job_name=parr_test ; --parallel로 import 할때

impdp system/asd123 directory=data_pump_test dumpfile=paratest%U.dmp schemas=SCOTT 

impdp
idb/idbpwd
DIRECTORY=impdp_dir
dumpfile=xxx.dmp
REMAP_SCHEMA=ida:idb
REMAP_TABLESPACE=ida_tbs:idb_tbs

expdp 나 impdp 실행시 ORA-39213:Metadata processing is not available 오류가 발생하면
execute dbms_metadata_util.load_stylesheets 실행

expdp system/asd123 schemas=SCOTT DIRECTORY=DATA_PUMP_DIR  dumpfile=YSS.dmp Logfile=YSS.log CONTENT=ALL COMPRESSION=METADATA_ONLY
impdp system/asd123 directory=DATA_PUMP_DIR dumpfile=YSS.dmp schemas=SCOTT CONTENT=ALL TABLE_EXISTS_ACTION=REPLACE

ㅁ

정리.docx

disk.locking = "FALSE"
diskLib.dataCacheMaxSize = "0"
scsi1.sharedBus = "virtual"

scsi1:0.deviceType = "disk"
scsi1:1.deviceType = "disk"
scsi1:2.deviceType = "disk"
scsi1:3.deviceType = "disk"
scsi1:4.deviceType = "disk"
scsi1:5.deviceType = "disk"

--vmware tool install
# cd /tmp
# gunzip -c /media/cdrom/VMwareTools-8.1.3-203739.tar.gz |tar xf -
# cd vmware-tools-distrib/
# ./vmware-install.pl

# ifconfig             //IP확인
# netstat -nr         //gatewqy 확인
# neat                //네트워크 설정

[root@rac1 ~]# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:0C:29:5C:14:40 
          inet addr:192.168.110.128  Bcast:192.168.110.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe5c:1440/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1 errors:0 dropped:0 overruns:0 frame:0
          TX packets:41 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:342 (342.0 b)  TX bytes:6496 (6.3 KiB)
          Interrupt:19 Base address:0x2424

eth1      Link encap:Ethernet  HWaddr 00:0C:29:5C:14:4A 
          inet addr:192.168.107.128  Bcast:192.168.107.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe5c:144a/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1 errors:0 dropped:0 overruns:0 frame:0
          TX packets:41 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:342 (342.0 b)  TX bytes:6496 (6.3 KiB)
          Interrupt:16 Base address:0x24a4

lo        Link encap:Local Loopback 
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:2050 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2050 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:5619564 (5.3 MiB)  TX bytes:5619564 (5.3 MiB)

[root@rac1 ~]# netstat -nr
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.110.0   0.0.0.0         255.255.255.0   U         0 0          0 eth0
192.168.107.0   0.0.0.0         255.255.255.0   U         0 0          0 eth1
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth1
0.0.0.0         192.168.110.2   0.0.0.0         UG        0 0          0 eth0

vi /etc/hosts

# Public - (eth0)
192.168.110.128 rac1
192.168.110.129 rac2

# Private - (eth1)
192.168.107.128 rac1-priv
192.168.107.129 rac2-priv

# VIP
192.168.110.40 rac1-vip
192.168.110.41 rac2-vip

# Grid SCAN(dns)
192.168.110.1 rac-cluster-scan

--host name
rac1
192.168.107.1

네트워크 설정 후 재시작
# /etc/init.d/network restart

Ping Test
# ping 168.126.63.1

불 필요한 서비스 Off하기
chkconfig --level 123456 xinetd off
chkconfig --level 123456 sendmail off
chkconfig --level 123456 cups off
chkconfig --level 123456 cups-config-daemon off
chkconfig --level 123456 smartd off
chkconfig --level 123456 isdn off
chkconfig --level 123456 iptables off

# vi /etc/sysctl.conf
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
net.ipv4.ip_local_port_range = 9000 65500
net.core.wmem_max = 1048576
net.core.rmem_default = 4194304
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
fs.file-max = 6815744
fs.aio-max-nr = 1048576

# vi /etc/security/limits.conf
grid soft nproc 2047
grid hard nproc 16384
grid soft nofile 1024
grid hard nofile 65536
oracle soft nproc 2047
oracle hard nproc 16384
oracle soft nofile 1024
oracle hard nofile 65536

# vi /etc/pam.d/login
Session     required     pam_limits.so

# vi /etc/modprobe.conf
options hangcheck-timer hangcheck_tick=30 hangcheck_margin=180

# modprobe -v hangcheck-timer

# vi /etc/rc.local
/sbin/modprobe hangcheck-timer rdate -s 192.168.110.128

# vi /etc/profile
for i in /etc/profile.d/*.sh ; do
    if [ -r "$i" ]; then
        if [ "${-#*i}" != "$-" ]; then
            . $i
        else
            . $i >/dev/null 2>&1
        fi
--여기부터 추가
if [ $USER = "oracle" ]; then
            if [ $SHELL = "/bin/ksh" ]; then
                      ulimit -p 16384
                      ulimit -n 65536
            else
                      ulimit -u 16384 -n 65536
            fi
            umask 022
    fi
--여기 까지
fi
done

NTP Service 파일 설정 ? 양쪽 노드간 TIME  sync를 반드시 필요
# vi /etc/sysconfig/ntpd
OPTIONS="-x -u ntp:ntp -p /var/run/ntpd.pid”   
※ 빨간색으로 표시한 부분 -x만 추가하면 된다.

# service ntpd restart
Shutting down ntpd: [FAILED]
ntpd: Synchronizing with time server: [ OK ]
Starting ntpd: [ OK ]

필수 RPM검사
# rpm ?qa RPM명
binutils   compat-libstdc++-33    elfutils-libelf    elfutils-libelf-   devel gcc gcc-c++    glibc   glibc-common   glibc-devel   glibc-headers   ksh   libaio libaio-devel   libgcc   libstdc++   libstdc++-devel   make   sysstat   unixODBC unixODBC-devel

User, group 생성, oracle passwd 설정
# groupadd -g 1000 oinstall
# groupadd -g 1200 dba
# useradd -u 1200 -g oinstall -G dba oracle
# passwd oracle

설치 디렉토리 생성(Grid, oracle database SW 설치용)
mkdir -p /u01/app/oraInventory
mkdir -p /u01/app/11.2.0/grid
mkdir -p /u01/app/oracle
mkdir /u01/app/oracle/cfgtoollogs
mkdir -p /u01/app/oracle/product/11.2.0/db_1
chown -R oracle.oinstall /u01
chmod -R 755 /u01

# vi .bash_profile
export GRID_HOME=/u01/app/11.2.0/grid
export PATH=$PATH:$HOME/bin:$GRID_HOME/bin

# su - oracle
$ vi .bash_profile
export TMP=/tmp
export TMPDIR=$TMP
export ORACLE_HOSTNAME=rac1
export ORACLE_UNQNAME=RAC
export ORACLE_BASE=/u01/app/oracle
export ORACLE_HOME=$ORACLE_BASE/product/11.2.0/db_1
export GRID_HOME=/u01/app/11.2.0/grid
export ORACLE_SID=racdb1
export ORACLE_TERM=xterm
export PATH=/usr/sbin:$PATH
export PATH=$ORACLE_HOME/bin:$GRID_HOME/bin:$PATH
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib
export CLASSPATH=$ORACLE_HOME/JRE:$ORACLE_HOME/jlib:$ORACLE_HOME/rdbms/jlib

루트 계정으로 추가한 6개 디스크 파티션
# fdisk /dev/sdb
# fdisk /dev/sdc
# fdisk /dev/sdd
# fdisk /dev/sde
# fdisk /dev/sdf
# fdisk /dev/sdg

[root@rac1 ~]# fdisk /dev/sdb

Command (m for help):
Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
Partition 1 is already defined.  Delete it before re-adding it.

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

ASM환경 설정
# oracleasm configure -i

[root@rac1 ~]# oracleasm configure -i
Configuring the Oracle ASM library driver.

This will configure the on-boot properties of the Oracle ASM library
driver.  The following questions will determine whether the driver is
loaded on boot and what permissions it will have.  The current values
will be shown in brackets ('[]').  Hitting <ENTER> without typing an
answer will keep that current value.  Ctrl-C will abort.

Default user to own the driver interface []: oracle
Default group to own the driver interface [oracle]: dba
Start Oracle ASM library driver on boot (y/n) [y]: y
Scan for Oracle ASM disks on boot (y/n) [y]: y
Writing Oracle ASM library driver configuration: done

마운드 포인트 생성 : 경로생김
# oracleasm init

마운트 포인트 생성은 안해도 되지만
/dev/oracleasm/경로 밑에 디스크가 생성됨

[root@rac1 ~]# oracleasm init
Creating /dev/oracleasm mount point: /dev/oracleasm
Loading module "oracleasm": oracleasm
Mounting ASMlib driver filesystem: /dev/oracleasm

공유 디스크 생성
# oracleasm createdisk ocr_vote01 /dev/sdb1
# oracleasm createdisk ocr_vote02 /dev/sdc1
# oracleasm createdisk ocr_vote03 /dev/sdd1
# oracleasm createdisk asm01 /dev/sde1
# oracleasm createdisk asm02 /dev/sdf1
# oracleasm createdisk asm03 /dev/sdg1

스캔작업
# oracleasm scandisks

생성 리스트 확인
# oracleasm listdisks

# chown -R oracle.oinstall /dev/oracleasm/

hostname
su -

reboot

ping rac1
ping rac2

ping rac1-priv
ping rac2-priv

grid 설치
eth0 192.168.110.0 public
eth1 192.168.107.0 private

/dev/oracleadm/disks

crs_stat -t

ora.gsd ora.gsd.type OFFLINE
ora.oc4j ora.oc4j.type OFFLINE
ora.rac1.gsd application OFFLINE
ora.rac2.gsd application OFFLINE
 
srvctl enable nodeapps -g
[root@rac1 u01]# srvctl start nodeapps
PRKO-2421 : Network resource is already started on node(s): rac2,rac1
PRKO-2420 : VIP is already started on node(s): rac2,rac1
PRKO-2420 : VIP is already started on node(s): rac2,rac1
PRKO-2422 : ONS is already started on node(s): rac2,rac1
PRKO-2423 : eONS is already started on node(s): rac2,rac1

[root@rac1 u01]# srvctl stop oc4j -f
OC4J failed to stop
PRCC-1016 : oc4j was already stopped
srvctl remove oc4j

ocrcheck

Oracle 11g RAC_ASM.pdf

export ORACLE_BASE=/oracle/app/oracle

export ORACLE_HOME=/oracle/app/oracle/product/10.1

export ORACLE_SID=ORCL

export NLS_LANG=American_America.KO16KSC5601

export TNS_ADMIN=$ORACLE_HOME/network/admin

export ORA_NLS22=$ORACLE_HOME/ocommon/nls/admin/data

export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$ORACLE_HOME/lib32:/usr/lib

- 버젼 확인

uname -a

- 패치 확인

/usr/sbin/swlist -l patch | grep patch_name

- 커널 파라메터 설정

리눅스