oracle 11g 삭제하는 방법

1. su - oracle

2. cd $ORACLE_HOME

3. cd deinstall/

4. ./deinstall  엔터

5. cd /etc

oraInst.loc

oratab 둘 다 삭제

6. cd /usr/local/bin

rm -rf dbhome, oraenv, coraenv 파일을 모두 삭제할 것

7. 사용자 계정 oracle 폴더 날리기

1. 파일을 다운로드 받는다.

   설치파일의 경로를 어디든 상관이 없다.

2. 각 파라미터 값을 설정해준다.

3. 유저와 그룹을 생성한다.

4. manager의 passive를 실행 후

   xclock 나 export DISPLAY=현재 내가 쓰는 ip:0.0

5. ./runInstaller

6. 다음 및 상황을 보고 설치를 한다.

    각 화면별로 왜 하는지 정확히 알고 넘어갈 것

7. netca

8. dbca

설치시 프로세스를 1000 이상 줄 것

redolog file size를 100m~200m로 줄 것

관리자와 이야기를 해서 설정할 것

9. em

    em 레버지토리 둘 다 체크하지 말 것

    혹시 rman 을 사용할거면 fra 을 안해도 됨

10. 제일 마지막에 커스텀에서 제일 위에 것만 체크할 것

설치시 계속 oracle 계정과 root 계정으로 변경하면서 설치를 하면 꼬일 수 있으니,

터미널 창을 두 개 열어서 작업을 하자.

86페이지

아래 5번과 관련해서 참고해서 볼 사항 

http://m.dbguide.net/knowledge.db?cmd=view&boardConfigUid=21&boardUid=168439

원본출처 : 

http://www.adminschool.net/wiki/doku.php?id=study:oracle:adv_owi_10g:oracle_internal_owi:buffer_cache_owi

Buffer Cache 란

1. 오라클은 물리적인 I/O를 최소화 하기 위해 최근에 사용된 블럭에 대한 정보를 메모리의 일정 부분에 보관하려 한다 ⇒ 이 영역을 Buffer Cache 라고함.

Buffer Cache 구조

1. Hash Chain 구조의 시작점은 Hash Table인데, Hash Table은 Hash Bucket으로 구성되어져 있다
2. 오라클 블럭(DBA: Data Block Address File# , Block# )과 블럭 클래스 에 대한 Hash 함수 결과 값으로 해당 Hash Bucket을 찾아가서 해당 데이터 블럭이 메모리에 존재 하는지를 확인 할 수 있는 것 이다
3. Hash Bucket에 딸린 Buffer Header는 Buffer에 대한 메타 정보만 가지고 있고 Buffer 메모리 영역의 실제 버퍼에 대한 포인터 값을 가지고 있다.
4. Hash Chain 구조는 Shared Pool 영역에 존재 하며 실제 버퍼에 대한 정보들은 버퍼 캐쉬 영역에 존재 한다
5. 특정 블럭에 대한 Scan을 할려고 하면 Cache buffer chains latch를 획득 해야만 한다. 
   ※ 9i부터 읽기 작업에 한하여  cache buffer chains latch를 shared 모드로 획득 한다
6. 다음과 같은 쿼리를 이용하여 cache buffer chains latch의 갯수를 확인가능 하다 
   

   SQL> SELECT COUNT(*) FROM v$latch_children WHERE name = 'cache buffers chains'
    
     COUNT(*)
   ----------
        65536

• cache buffer chains latch ⇒ hash 함수로 얻은 값으로 해당 데이터가 어떠한 bucket에 있는가를 확인할때 발생되는 latch

Working Set

• 오라클은 Buffer Cache에 대하여 효율적으로 사용하기 위해 두 종류의 LRU리스트를 사용한다.

1. LRU List : 가장 최근에 사용되거나 미사용된 버퍼들의 List
   1. Free(미사용) , 사용중이거나 사용된 버퍼 아직 LRUW로 옮겨지지 않은 Dirty 버퍼
   2. 메인 리스트 : 사용된 버퍼들의 리스트 , 핫 영역과 콜드 영역으로 구분 관리 됨
   3. 보조 리스트 : 프리 버퍼들의 리스트 , 미사용 된 버퍼나 DBWn에 의해 기록 된 버퍼 관리
2. LRUW List : 아직 디스크에 기록 되지 않은 Dirty한 버퍼들의 List
   1. 메인 리스트 : 변경된 버퍼들의 리스트
   2. 보조 리스트 : 현재 DBWR에 의해 기록중인 버퍼 리스트

• 다음 그림과 같이 LRU , LRUW를 합쳐서 하나의 Working Set 이라고 부른다.

• Working Set 개수는 Cache buffer lru latch 개수에 의해 결정( 하나의 working set을 하나의 lru latch가 관리함 )되며 X$KCBWDS( Kerner Cache Buffer Working sets Descriptors )를 조회 하면 확인 가능 하다
• LRU , LRUW List를 탐색 하고자 하는 프로세스는 반드시 cache buffer lru chain latch를 획득 해야 함.
• cache buffer chains lru latch ⇒ bucket의 header chain을 검색하여 블록이 버퍼캐시안에 없을때 lru를 뒤져 free buffer을 찾기위해 발생되는 latch

Touch Count

• 오라클은 개별 버퍼 마다 Touch Count를 관리 하며 , 프로세스에 의해서 스캔이 이루어 질때 마다 Touch Count를 1씩 증가시킴

1. Cold 영역의 꼬리에 있으면서 Touch Count가 1이하인 것이 Free Buffer로 사용된다.
2. Cold 영역의 꼬리에 있으면서 Touch Count가 2 이상인 블럭을 만나면 Hot영역의 head 부분으로 옮기고 Touch count를 0 으로 초기화 한다.
3. 핫 영역으로 옮기는 기준은 _DB_AGING_HOT_CRITERIA 파라메터 이며 기본이 2 이다.
4. 만약 Single블럭 I/O에 의해 읽혀진 블럭은 Mid-Point에 삽입되며 Touch Count는 1 이다.
5. Full table scan 이나 인덱스 Full Scan으로 읽혀진 데이터 들은 Mid-Point에 삽입되었다 바로 Cold 영역의 꼬리로 옮겨져서 버퍼 캐쉬에 머무를 확률이 작아 진다.

Buffer lock

• buffer 자체 보호 . 즉 , 버퍼의 내용을 변경하거나 읽으려고 하는 프로세스는 변경 작업이나 읽기 작업을 완료할때 까지 해당 버퍼 (정확하게 말하면 Buffer header)에 대해서 buffer lock을 exclusive 또는 shared 하게획득 해야 한다.

Buffer Cache 블록을 올리거나 버퍼캐시에 올라와있는 블록을 사용하고자 할때

1. sql문에 의해서 조건에 만족하는 데이터가 버퍼캐시에 존재 여부 확인하기 위해 DBA(data block address) + class(data, sort, undo)를 조합하고 > hash function을 돌려 해당 데이터가 어떠한 bucket에 있는가 확인(= DBA + class를 hash 함수로 돌린뒤 그값을통해 hash bucket를 찾음)
2. cache buffer chains latch를 획득(읽기는 shared, 변경은 exclusive)
3. hash bucket에서 관리하는 buffer header들(chain)을 검색하여 블록이 버퍼캐시안에 존재 하는지 확인
4. 버퍼캐시안에 없을경우 cache buffer lru chain latch를 획득함
5. LRU 보조 리스트를 통해 free buffer를 검색
6. LRU 메인리스트에서 free buffer을 검색
   1. 검색중 dirty블럭을 만나면 LRUW 리스트의 메인 리스트에 추가
   2. 검색중 touch count가 2이상인 것을 만나면 hot 영역의 머리부분으로 옮기고 touch count를 0으로 세팅
   3. 검색중 LRU 리스트를 40% 스캔을 했는데도 free block을 찾지 못하면 LRU 스캔을 멈추고 DBWR에게 dirty 버퍼를 파일에 기록할것을 요구(_DB_BLOCK_SCAN_MAX_PCT 파라미터에 의해 %를 정함)
   4. DBWn에 의해서 프리버퍼가 확보 될때까지 free buffer waits 이벤트 대기
   5. 요청받은 DBWn은 cache buffer lru chain latch를 획득 후 LRUW 리스트의 cold 영역 꼬리부터 탐색하여 기록함
   6. 기록된 블럭은 LRU 보조 리스트로 옮겨짐
7. free block를 찾으면 buffer lock을 exclusive하게 획득 후 데이터 파일로 부터 block를 load

Buffer Cache Dump

1. 버퍼의 구조를 가장 명확하게 알 수 있는 방법은 버퍼 캐시 덤프를 이용하는것 
   

   SQL> ALTER SESSION SET evnets 'immediate trace name buffers level 1';
   OR
   SQL> oradebug dump buffers 1

• 참고로 oradebug 를 추천한다 
  

1. X$BH 뷰에서 확인가능하다

• 눈여겨 봐야될 컬럼은 다음과 같다

컬럼	내용
HLADDR	해당 버퍼를 관장하는 래치의 주소 V$LATCH_CHILDREN.ADDR 과 조인해서 원하는 래치정보를 얻을수 있다
TS#	블록이 속한 테이블스페이스 번호 V$TABLESPACE.TS# 과 조인
DBARFIL	DBA 중 파일번호
DBABLK	DBA 중 블록번호
CLASS	블록 클래스
STATE	버퍼의 상태
0	FREE no valid block image
1	XCUR a current mode block, exclusive to this instance
2	SCUR a current mode block, shared with other instances(RAC환경에서만 쓰임)
3	CR a consistent read (stale) block image
4	READ buffer is reserved for a block being read from disk
5	MREC a block in media recovery mode
6	IREC a block in instance (crash) recovery mode
8	PI past image(RAC환경에서만 쓰임)
TCH	Touch Count

http://docs.oracle.com/cd/B19306_01/server.102/b14220/memory.htm

위와 같은 숫자 번호대로 sql의 실행계획을 읽는다. 

레벨이 같은 단계는 위에서부터 읽고, 오른쪽에서 시작해서 가장 왼쪽으로 들어간 것을 먼저 읽는다. 

예1)

 A 4

B 3

C 1

D 2

예2)

A 5 

B 2

C 1

D 4

E 3

SQL 실행 계획 예 

EXPLAIN PLAN 명령 등을 수행한 경우의 실행 계획의 표현 

ID OPERATION                      OPTIONS               OBJECT_NAME

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

0   SELECT STATEMENT

1       FILTER

2           NESTED LOOPS

3                TABLE ACCESS    FULL                     EMP

4                TABLE ACCESS    BY ROWID                 DEPT

5                     INDEX UNIQUE SCAN    PK_DEPTNO

6                TABLE ACCESS    FULL                     JOBS

3-5-4-6-2-1-0

mts 관련 정보 링크

76 101

https://community.oracle.com/thread/428692?start=0&tstart=0

http://mclee.tistory.com/129

1 사용자가 특정 데이터의 변경을 요청하는 쿼리를 수행

2 유저프로세스로 부터 해당 sql을 받은 서버프로세스는 원하는 block가 있는지 없는지 확인

   원하는 파일이 없을 경우 해당 블록을 데이터 파일에서 찾아 복사 후 메모리로 가지고 옴

3 해당 블록의 해당 row부분을 다른 사용자가 바꿀 수 없도록 블록에 lock를 설정 - page fix

4 PGA 영역에서 Server process가 redo change vector 를 생성 후 redo log buffer 에서 필요한 용량을 계산함 

redo change vector : 변경된 데이터를 복구 할 목적으로 redo log에 기록할 변경된 데이터에 대한 모든 정보의 세트

undo 관련 내용도 들어있음 ( rollback 데이터를 복구할 경우

commit 후 checkpoint 발생 전에 DB 강제종료가 일어나서 

DB가 강제 종료 되었을 때도 rollback 해야할 때 이전 데이터가 필요하기 때문) 

changer vector 들은  redo record 라는 형태의 row  단위로 redo log buffer 에 복사 됨

5 Change vector 를 redo log buffer에 복사하기 위해 필요한 redo copy latch를 획득해야 하며, 

   change vector 를 redo buffer 에 복사하는 작업의 전 과정동안 redo copy를 보유해야 함. 

latch : 일종의 번호표 개념, 한정된 메모리 자원을 여러 사용하자 사용할 때 순서를 정리해 주는 역할

    여러개의 Server process가 동시에 데이터를 변경하면, 

    Redo copy latch를 획득하는 과정에서 경합( latch : redo copy 이벤트 대기 ) 이 발생됨

    경합이 발생하면 성능이 저하됨

6 Redo copy latch 를 확보한 Server process는 Redo log buffer에 내용을 기록하기 위해 Redo allocation latch를 확보 해야 함

oracle 8i : Redo allocation latch 1개, 많은 경합이 생겨 성능이 저하됨

oracle 9i : Shared Redo Strand 기능 - Redo log buffer를 여러 개의 공간으로 나누어 각 공간 별로 Redo allocation latch를 할당

               여러 서버 프로세스가 동시에 작업이 가능해 성능이 높아짐 

   Redo log buffer 를 몇 개로 나누는 가가 성능에 영향을 미침 

   Strands : 여러 개로 분할된 영역을 의미

   기본값 LOG_PARALLELISM = 1

oracle 10g : LOG_PARALLELISM 가 히든파라미터 _LOG_PARALLELISM 로 바뀜 

oracle 이 동적으로 관리하도록 _LOG_PARALLELISM_DYNAMIC 파라미터가 추가됨

이 값을 TRUE로 설정하면 Oracle 이 해당 Strand 개수를 자동으로 제어함, 권장값은 ( CPU개수 / 8)

Private Redo Strand 기능 - 9i 의 Shared Redo Strand 보다 확장된 개념이 도입됨

        각 Server process 는 Shared pool 에 자신 만의 독립적인 Private Strand 공간을 만들어  

        이 곳에 Change vector 을 생성 후 필요할 경우 LGWR 이 Redo log file 에 바로 기록함

        latch를 거치지 않기 때문에 성능이 향상됨, 그래서 'zero copy redo' 라고도 함 

 7 Redo log buffer에 기록 된 내용( Change 

최소 단위에서 큰 단위

OS block -> Oracle block -> Extent -> Segment -> Tablespace 

Oracle Block의 개요

Oracel 11g R2 

Grid Infrastructure Single Client Access Name(SCAN)

SCAN(Single Client Access Name) 

상세한 설명은 이 링크로 들어가서 볼 것!!

정리 잘 되어 있음

http://energ.tistory.com/entry/11gR2-Grid-Infrastructure-Single-Client-Access-Name-SCAN-%EC%9D%B4%EA%B1%B4-%EB%98%90-%EB%AD%90%EC%95%BC