자수성가한 부자

Database storage 관리
- control file
- redo log file
- data file


1. Control file

- control 파일을 추가하는 방법을 실습해보자.

파라미터를 변경한다.

shutdown 시킨다.(!!!!안할경우 파일이 깨질 가능성이 있음)

파일을 복사한다.

파일이 잘 복사되었는지 확인한다.

startup을 한다.

잘 되었는지 확인해보자

2. Redo log file

- redo log file을 추가하는 방법을 실습해보자.

현재 redo log 관련 내용을 확인해보자.

     

     v$logfile의 status은 각 의미는 다음과 같다.
       - current : 현재 쓰고 있는 그룹
       - inactive : 언제든지 재이용할 수 있는 그룹
       - active : 지금 dbwr가 쓰고 있는 그룹

로그파일을 추가한다.


2개의 멤버가 있는 1개 그룹과 1개의 멤버가 있는 로그 파일을 추가한다.

잘 추가되었는지 확인해보자.

강제로 log switch 발생시킨다.
  (v$log의 status변경 : unused -> inactive)

강제로 check point 발생
  (v$log의 status변경 : active -> inactive로 변경)

마지막으로 멤버가 하나뿐인 그룹에 1개의 멤버를 추가한다.

리두 로그 멤버 삭제 및 그룹 삭제 :

1번 그룹, 2번 그룹을 alter system switch logfile 및 alter system checkpoint 명령을 이용해서 1번, 2번 그룹의 상태를 inactive로 만든다.

리두 로그를 삭제한다.
아래의 명령어는 control file에서 redo log file의 내용만 사라짐. os에는 파일이 남아 있다.
따라서 OS 명령으로 직접 파일을 삭제해야 한다. 주의할 것!!!!

멤버 파일을 삭제한다.

삭제가 잘 되었는지 확인해본다.(control파일에서 redo log부분만 사라짐)

OS 명령으로 파일을 확인해본다.

위에서 삭제했던 멤버의 파일을 삭제한다. (!!주의)

그룹 삭제를 해본다.

OS내에 파일을 확인한다.

위에서 지운 그룹의 파일을 지운다.

만약 잘못하여 파일을 지울 경우

스타트업 한다.

log file의 정보를 확인한다.

redo03_b.log의 파일을 redo03_a.log로 복사한다.

log switch를 발생시킨다.

확인해보자.

3. Datafile 그리고 Tablespace

테이블 스페이스의 내용을 확인하기 편하도록 아래의 명령어를 파일에 저장해둔다.

데이터베이스의 속성을 확인한다.(속성명과 속성값)

테이블 스페이스를 추가한다.

테이블 스페이스가 추가된 것을 확인할 수 있다.

디폴트 테이블스페이스와 템프 테이블 스페이스를 변경해준다.

잘 변경이 되었는지 확인해본다.

언두 파라미터 확인

 파라미터 파일을 변경한다.

데이터 블럭의 분해

1. 파일 헤더

2. 세그먼트 헤더

    - freelist
      : insert가능한 블럭 주소 시작, 끝이 들어있다.
      (동시에 너무 많은 유저가 insert를 하면 CPU, NETWORK, 메모리에 관계없이 대기 시간 길어짐 
       -> 전체적 성능 저하 -> OWI로 분석 후 해결가능)
    - HWM
      : High Water Mark의 약자
      : full table scan의 기준이 된다. dba_tables로 확인 가능
       (물 증가 후 자국이 남는다.)

3. 블럭 헤더
   - 세그먼트 타입(테이블, 인덱스, ..)
   - 데이터 블럭 주소
   - 테이블 디렉토리
   - 로우 디렉토리
   - 트랜잭션 슬롯 : 트랜잭션당 하나씩 차지한다. undo의 주소가 남는다.
   - 위에서 아래로 채워짐

4. 로우 데이터
   - 실제 데이터가 저장됨.
   - 그림과 같이 아래에서 위로 채워진다.

참고 : oracle10gr2 메뉴얼 concept
 

instance open까지의 단계

shutdown 명령어

shutdown에는 아래와 같이 4개의 옵션이 있다.
- abort
   (새로운 손님 안 받음. 먹고 있는 손님 내보냄. roll forward 과정이 있음.)
- immediate
   (새로운 손님 안 받음. 먹고 있는 손님 내보냄 -> DML을 끊고. 비정상적인 프로세스 정리)->생각보다 오랜 시간이 걸림
- transactional
   (새로운 손님 안 받음, 먹고 있는 손님 기다림)
- normal
   (default, 새로운 손님 안받음, 먹고 있는 손님 기다림,
    접속중인 session이 exit명령으로 나갈 경우 종료됨)

  비정상종료(abort)
  정상종료(immediate, transactional, normal)


sqlplus 접속시에 파일 실행 후에 접속하도록 할 수 있다.

다음의 내용을 따라해보면 알 수 있다.

a.sql 파일을 생성한다.


a.sql파일 내부에 넣을 내용


다음의 명령을 실행한다.


a.sql을 실행한 후 sqlplus에 접속한다.


parameter

 - static parameter
   startup 이후에 바꿀 수 없는 parameter
   대표적인 static parameter : alter system set sga_max_size=264 

 - dynamic parameter
   startup 이후에도 바꿀 수 있는 parameter


parameter file

: instance 구성시에 필요한 파일로, initSID.ora, spfileSID.ora
  파라미터 파일 읽는 순서 : spfileSID.ora -> spfile.ora -> initSID.ora -> 에러
  pfile과 spfile이 둘다 없을 경우 startup시에 에러
  (해결방법은 pfile, spfile을 생성 or startup시 파일 지정)
  initSID.ora -> spfileSID.ora 가능
  또한 spfileSID.ora -> initSID.ora도 가능

- pfile
     initSID.ora
     text파일
     alter system set으로 파라미터 변경시 메모리상에만 바꿈. 
     파일의 내용은 안바뀜(수동으로 바꿔줘야 했음)

- spfile
      spfileSID.ora
      binary파일
      alter system set으로 명령을 쳐서 변경 
      메모리와 파일 둘 다 바뀌도록 설정할 수 있음(SCOPE=both일 경우)


아무 위치나 아무 이름의 특정 파일 생성 후 startup 시에 pfile의 경로와 이름을 넣어주면
그 파일에 설정되어 있는 대로 instance가 생성됨




spfile로 시작했을 경우 아래의 커맨드를 치면 확인할 수 있다.
내용이 나오면 spfile로 시작한 경우 이다.

아래는 파라미터 관련 실습 내용이다.

Diagnostic files(진단 파일)

- alertsid.log
   :무조건 생김. 전체 인스턴스 당 하나의 파일이 생김.
    위치 :BACKGROUND_DUMP_DUST에 정의된 위치
    끝없이 커지므로 가끔 지워줘야 함.

- sid_dbw0_pid.trc
   : 프로세스당 하나씩 남는다.
    dbw0대신에 다른 프로세스가 들어간다.
    위치는 BACKGROUND_DUMP_DUST에 정의된 위치
    주로 장애가 날 경우 생김

- sid_ora_pid.trc
   : 서버 프로세스가 남기는 로그로 두군데에 생긴다.
      1. BACKGROUND_DUMP_DUST : 에러시
      2. USER_DEMP_DEST              : 유저요청시

진단 파일의 위치를 알고 싶은 때 명령어

alert파일을 external테이블로 연결하기
참고 : http://blog.naver.com/orapybubu?Redirect=Log&logNo=40050729230



기타사항

RESTRICTED 관련 내용 넣을 것

show parameter sga;

tail -f $ORACLE_HOME/rdbms/log/alertorcl.log

X$로 시작되는 internal테이블
 -> parameter, instance의 활동, control 파일의 내용으로 채워져 있는 테이블

현재 instance의 상태 확인

Static Data Dictionary View

  - 데이터베이스에 존재하는 오브젝트 및 기타 정보에 대한 내용을 조회할 수 있는 뷰
  - 거의 바뀌지 않음
  - open시에만 이용가능(nomount, mount때는 이용 불가능)
  - 정보의 출처는 internal table(obj$, col$, users$ 등)이다.
  - 종류
       USER_* : 소유 
                    USER_OBJECTS, USER_TABLES, USER_TAB_COLUMNS,
                    USER_CONSTARINTS, USER_CONS_COLUMNS, USER_VIEWS,
                    USER_SEQUENCES, USER_SYNONYMS
       ALL_*   : 접근 가능
       DBA_*   : 모든 , DBA라면 많이 알아야 하는 부분

Database 생성 방식의 종류에는 두가지가 있다.
1. DBCA이용(오라클 교재 참고할 것 3장 초반, dbca실행은 os커맨드창에서 dbca를 실행시키면 됨)
2. 수동으로 생성

여기에서는 수동으로 linux에 Database를 생성하는 방법을 알아보도록 하겠다.
(OS: linux, oracle ver.: 10gr2
 Windows는 첨부파일을 참고할 것)

1. 디렉토리 생성한다. 
   (붉은색으로 되어 있는 부분은 생성하고 싶은 database명과 instance명이다.
    자신이 원하는 이름으로 해주면 되겠다. 
    참고로 보통 database명과 instance명은 같은 이름으로 해준다.)



2. parameter 파일 생성한다. (참고로 parameter파일은 instance의 구성과 관계가 있다.)


아래는 파일에 들어갈 내용이다.



3. nomount상태로 시작한다.



4. database를 생성한다.
  - 실제 Database 를 생성하는 단계이며, Control File / Redo Log File / Data File 이 생성된다
  - 생성 후 OPEN 상태로 변경되어 $ORACLE_HOME/rdbms/admin/sql.bsg 를 자동 실행한다
  - $ORACLE_HOME/rdbms/admin/sql.bsg 의 실행을 통해 TAB$,COL$ 등의 Internal Table을 생성한다



5. sys, system 유저의 패스워드를 변경한다.
   


6. data dictionary, pl/sql, product user profile 테이블 및 관련 프로시져 생성을 위한 작업을 해준다.


아래는 파일에 들어갈 내용이다.


파일을 실행한다. 여기에서 20분가량의 시간이 걸린다.




이걸로 database 생성은 잘 끝났다. 잘 생성되었는지 테스트해보자.






다음은 네트워크 설정이다.
원격지에서 제어하기 위해서 필요한 설정이다.

1. 리스너를 정지한다.



2. listener.ora 파일을 편집한다.


아래의 붉은 부분을 추가해준다.



3. 리스너를 시작한다.



4. tnsnames.ora파일을 편집한다.(isqlplus에 접속할 수 있도록 설정)


붉은 부분을 추가해준다.



5. 패스워드 파일을 생성한다.



여기까지해서 네트워크 세팅이 완료되었다.
잘 되었는지 테스트해보자.



여기까지 수동으로 DB를 생성하고, 네트워크 세팅하는 것을 알아보았다.


참고 : http://cafe.naver.com/gseducation/87
         http://www.urbantree.wo.tc/entry/3
         http://blog.naver.com/enter128

CR블럭

데이터베이스 버퍼 캐쉬에 존재하는 블럭으로 읽기 일관성을 위해 존재한다. 
원본데이터의 복사본


아카이버는 언제 리두 로그파일을 복사할까?

로그 스위치를 하면 바로 동작한다.
예를 들면 (온라인)리두 로그 파일이 1, 2, 3 이렇게 3개 존재할 경우, 1에서 2로 바뀔때, 또는 2에서 3으로 바뀔 때
(오프라인)리두 로그 파일로 복사를 한다.


DBWR는 언제 데이터버퍼 캐쉬의 내용을 파일로 내려쓸까?

아래의 9가지 중 하나에 속할 때 내려쓴다.

- Checkpoint : shutdown, log switch, fast_start_mttr_target..., alter system checkpoint
- Dirty buffers’ threshold
- No free buffers
- Timeout
- RAC ping request
- Tablespace OFFLINE
- Tablespace READ ONLY
- Tablespace BEGIN BACKUP
- Table drop or truncate


LGWR가 리두 로그 버퍼의 내용을 리두 로그 파일로 내려 쓸때는?

총 13가지 인데,
- DBWR가 내려쓰기 전(9가지)
- 3분의 1이 사용되었을 때
- 리두 로그 버퍼가 1M가 찼을 때
- commit
- timeout (default는 3초)
     

OFA란?

:Optimal Flexible Architecture의 약자로,
 오라클 핵심 개발자 몇명이 선호하는 파일 배치 방식이다. 오라클 나름의 기준의 디렉토리 및 파일의 배치를 말한다.

Explain Plan(예측 실행 계획)

explain plan(예측 실행 계획)을 조회하는 가장 일반적인 방법은 아래와 같다.



※  예측 실행 계획을 볼때는 dbms_xplan.display를 이용할 것
     (sqlplus에서 set autot on으로 이용하는 방법도 있지만 10gR2이후 버전부터는
      둘다(dbms_xplan.display, set autot on) 같은 쿼리를 이용하기 때문에...)


Execution Plan(실행계획)

오라클에서 제공하는 실행 계획에는 총 5가지가 존재한다.

실행 계획의 종류

1. 예측 실행 계획 : Plan Table상에 존재. explain plan 명령 이용
2. 실제 실행 계획 : Shared Pool에 존재. v$sql_plan
3. 과거 실행 계획 : AWR에 존재. dba_hist_sql_plan
4. Tuning Set에 있는 실행 계획 : Tuning Advisor에 의해 생성된 실행 계획
5. Baseline에 있는 실행 계획 : SPM에 의해 관리되는 실행 계획


실행 계획의 구성요소

1. 단계별 Operation
2. Predicate(조건절) 정보
3. Query Block Name 정보
4. Outline 정보
5. Column Projection 정보

※더 자세한 내용은 다음의 책을 참조할 것
http://book.interpark.com/product/BookDisplay.do?_method=Detail&sc.shopNo=0000400000&sc.di
spNo=&sc.prdNo=201787078&bsch_sdisbook

관련내용 : http://121.254.172.39:8080/pls/apex/f?p=101:11:0::::P11_QUESTION_ID:4452200346716146

오라클이 grid computing을 지원하는 최초의 데이터베이스라고 하는 근거는 무엇일까?

아래의 3가지 측면의 서비스를 제공해야 Grid computing이라고 할 수 있다.
오라클은 ASM, RAC, oracle streams 등의 소프트웨어를 제공함으로써 3가지 서비스를 제공한다고 할 수 있다.

	storage	database	application
pooling 여러 소집단을 묶는 것	ASM	RAC	oracle streams, AS
virtualization 가상화	ASM	RAC	oracle streams, AS
provisioning 필요한 쪽에 공급할 수 있는 능력	ASM	RAC	oracle streams, AS

아래의 설명을 보면 각 서비스의 내용을 이해할 수 있다.

작은 디스크를 모아서 디스크 그룹을 생성한다. (pooling)



4개의 디스크에 25m씩 저장.(virtualization)



디스크 추가(추가되는 곳에 1/n이 넘어감)
각 디스크에서 5m씩 복사해서 새로운 디스크로 복사후 기존 데이터 5m지움.
각 디스크에는 20m씩 데이터가 들어가 있음



dg2의 diska5를 drop시킨다.
dg2의 diska5 내에 있는 데이터를 dg2의 diska1~diska4로 옮기고
diska5를 dg1으로 옮긴다.(provisioning)

다음의 Query의 실행순서는 어떻게 될까요?



parsing

select 문의 parsing과 같다. (참조)


execute

1. data block 및 undo block을 읽어서 database buffer cache에 올려놓는다.(undo의 공간이 부족하면 에러남)

2. database buffer cache에 row level lock을 건다.

3. redo log buffer에 redo entry를 생성한다.(내가 무슨 짓을 한다.를 기록)

4. undo data 생성
   - 변경전 데이터를 undo segment에 기록

5. user data 수정


rollback; 의 경우
undo data로 user data를 덮어씀

commit; 의 경우
Buffer cache 정리(lock 해제, 메모리의 변경 확정)
redo log buffer의 내용을 redo log file로 내려쓴다.


fast commit
database buffer cache의 내용을 정리.
그것과 관련된 redo log buffer의 내용 redo log file로 내려씀
dirty buffer들은 여전함(데이터파일과 버퍼의 내용이 다름)

instance recovery:
문제가 생겼을 경우 startup시에 복구
리두로그파일을 읽어서 복구
인스턴스가 죽기 직전의 상황으로.. 
ORACLE_SID -> spfileSID.ora -> Instance 구성 -> Control file read -> data file, redo log file read
   -> INSTANCE Recovery

기타 참고사항
- undo 영역 관련 쿼리
   select * from dba_rollback_segs;

- undo를 남길 여지가 없을 경우 DML에러가 남.

- undo 전문적으로 예전의 데이터를 보관하는 공간.

- redo는 복구시에만 필요함.

- 블럭 : datafile의 블럭
   버퍼 : database buffer cache의 블럭
            종류
          - free : start up이래로 한번도 바뀐적이 없는 버퍼
          - pinned : 지금 보고있거나 바꾸고 있는 버퍼(일종의 lock). 재이용 불가능
          - dirty : 원본과 내용이 다른 버퍼. pinned에서 수정이 완료된 버퍼. 재이용 불가능.
          - clean : 재이용 가능 버퍼.


- DBWn : 데이터베이스로 모아서 내려쓰는 역할
- LGWR : 데이터베이스로 모아서 내려쓰는 역할

- DBWn, LGWR의 사명
   : 사용 가능 메모리(Database buffer cache, redo log buffer)가 많아지도록 항상 내려씀.
     왜? user process, server process가 원활하게 작업할 수 있도록. 3초마다(파라미터 값에 따라 조정가능 함)


- 시스템 테이블 스페이스
- 유저 테이블 스페이스
- undo 테이블 스페이스
   - undo segment

- DBWn, CKPT
  빈집털이 공범
  DBWn가
  CKPT가 신호를 보내고, 끝나고 검사.(Control file과 Data file에 씀)


SCN(system change number)
  참고 : http://aozjffl.tistory.com/165

아래의 QUERY가 실행되는 순서를 알아보자.



- 사용자가 QUERY를 날린다.


parse

1. 동일 문장을 찾는다.
   ascii값으로 바꾼다. -> 바꾼 ascii값으로 hashing 함수를 통과시킨다. 
      -> hash key 값이 나옴 
          (Shared Pool의 Library Cache에서 hash chain을 찾는다.
           Library Cache에는 이전에 실행했던 SQL의 hash chain이 있다.)
   hashing된 결과를 볼 수 있는 query는 다음과 같다.(관련 column : hash_value)


2. syntax 검사
    : 키워드의 오타 검사

3. semantics 검사
    : 단어를 놓고 관계를 검사.(권한, 객체 유무 등) -> recursive SQL(재귀적 SQL) 
       system 파일에 저장되어 있음 -> database buffer cache로 가져옴(block 단위)

4. Execution plan
    : 실행계획을 선택한다. (SQL> set autot on : 실행계획을 볼 수 있다.)


execute

:메모리에 있는 것을 읽음 - logical read 또는 cache hit라고 부른다.
 파일에 있는 것을 읽음 - physical read 또는 cache miss라고 부른다.


fetch

:가서 가져 오다.라는 뜻으로 select에서만 일어난다. 필요할 경우 sort가 됨
database buffer cache의 정렬이 안된 데이터를 PGA로 가져와서 정렬해서 리턴


기타 참고 사항

- DBA는 코딩규약을 만들어 개발자들이 지키도록 해야한다.
  같은 쿼리를 또다시 parsing과정을 거치지 않게 하기 위해서.
  메모리의 크기, 속도에 연관이 있다.

- select * from v$bh 로 database buffer cache의 내용을 볼 수 있다.
   bh는 block header의 약자

- 오라클은 디스크 기반 DBMS이다.

- 메인 메모리 DB도 있다. (응답속도가 매우 빠른 증권시스템에서 쓰임)

각 부분이 존재하는 이유
- library cache  : 동일 문장의 reparsing을 줄이기 위해
- row cache(data dictionary cache) : meta data disk i/o를 줄이는 위해
- database buffer cache : user data disk i/o 를 줄이기 위해

- 메타데이터 : 데이터 관리용 데이터
- 유저데이터 : 유저가 만든 데이터
- 서버튜닝(조정) : 상황에 따라 각 부분(library cache, row cache, database buffer cache)의 크기를 조정하는 것.