꾸러기

- DB 서버에 접속하기 위해 필요한 프로그램

- N-tier

- Middleware

- Net 8 ; Client와 Server를 연결(중계)해주는 역할 (일종의 프로토콜)
=> Oracle Clinent를 설치하면 Net 8이 설치됨 / client에 설치 됨
=> tnsnames.ora ; DB 서버에 관한 주소록 (접속하고자 하는 서버의 목록을 넣어 둠)
=> 1. ip, 2. port, 3. SID 확인하여 server 접속

- listener ; server에서 client와의 연결을 돕는 프로그램으로 초기 접속시에만 관여함
=> listener.ora ; user process가 요구한 SID를 확인하여 server process와 연결시킴
=> 기존에 접속된 프로세스는 listener가 필요하지 않음 / 프로그램이 종료되어 다시 접속할 때는 필요
=> fork ; 여러개가 복제되어 사용됨

- tnsname.ora ; 텍스트 파일로 수정 가능
$ tnsping testdb2

- listener.ora ; 2GB가 될 경우 다운됨 => 지우지 않고 사이즈를 0으로 만들어줘야 함
$ echo /dev/null > /home/oracle/product/10g/network/admin/listener.ora
$ ls -lsh /home/oracle/product/10g/network/admin/listener.ora

- DB link ; 접속하고자 하는 서버에 tnsnames.ora에 정보가 등록되어야 함
> create public database link testdb2_scott => public은 모든 사용자가 사용 / 없으면 생성한 유저만 사용
connect to scott identified by tiger
using 'testdb2';

- 버전이 달라도 DB Link는 가능 (버전이 높은 곳에 tnsname.ora를 설정해야 함)

- DDL은 사용할 수 없음

- trigger ; 무결성을 지키기 위해 연관된 데이터까지 자동으로 업데이트를 해줌
=> 잘못된 자료를 입력하였을 경우 수정이 불가능

- disable ; 데이터 이관시 처리 속도를 향상시키기 위해 constraint 검사를 일시 중지함

- B-tree Index ; tree 양쪽의 균형이 맞아야 최상의 성능을 발휘할 수 있음
=> 실제 데이터는 leaf에 저장되며 root나 branch는 leaf에 있는 정보를 찾기 위해 사용됨

- index에서 4~5% 이내의 데이터를 찾을 때 효율적, index가 과다할 경우 DML 발생시 성능 저하
=> index를 사용할 경우 single block I/O, 일반적인 경우 multi block I/O

- Bitmap ; cardinality만큼 생성됨 => 통계 정보를 낼 경우 유리함 (기정 사실로 변경이 없는 데이터)
=> cardinality가 적을수록 유리함 (많을 경우 bitmap의 종류수가 많아지게됨)
=> data의 변경이 적어야 함 (새로운 종류의 map이 추가될 경우 기존의 map도 업데이트해야 함)

- regular table (heap table) ; 일반적인 table으로 입력하는대로 순서나 규칙없이 저장
=> insert는 쉬우나 update나 검색이 느림 (index 사용 필요)

- partitioned table ; 일정한 구역으로 구분하여 저장함 (규칙을 정하여 저장할 필요가 있음)

- LRU list ; 블록의 상태를 알 수 있음, dirty list와 free list로 구분됨

- row chaining ; update로 인해 한 row의 내용이 다른 블록에 걸쳐 저장되는 현상
=> update시 해당 컬럼만 다른 블록에 저장되어 발생함 (7까지 적용). 검색시간이 길어짐

- row migration ; row chaining을 줄이기 위해 update된 row 전체를 다른 컬럼으로 이동 (8부터 적용)
=> row chaining을 줄이기 위해 PCTFree를 할당 (9부터는 오라클이 자동으로 관리함)

- extents ; 각 extents의 크기가 다르기 때문에, 지워진 빈 공간에 크기가 다른 내용을 덮어쓰지 않음
대신, 마지막 사용한 공간 이후부터 채워넣기를 함 => 이를 해결하기 위해 extents를 같은 크기로 할당함
=> 수동으로 defrag를 해주거나 테이블을 다른 tablespace로 이동함 (index를 새로 만들어야함)

- unused ; 나중에 drop할 것을 고려하여 미리 표시함 (나중에 unused를 한꺼번에 삭제할 수 있음)
=> 그러나 취소할 수 없으므로 사용되지 않음

- Tx lock (row level lock) ; 작업하는 row를 단위로 lock이 됨 (다른 DBMS의 경우 page level lock)
- Tm lock (table level lock) ; 작업하는 테이블 전체를 lock함

- undo data ; roll back을 대비해서 이전의 data를 보관

- undo segment ; undo data를 모아두는 장소 (segment ; 들어있는 내용에 따라 명칭이 달라지는 테이블)

- DB buffer cache > undo table space > undo segment

- commit이나 roll back이 되어 비어있는 segment가 있는지를 먼저 확인하여 비어있는 segment를 재활용함
- commit이 발생하더라도 undo는 지워지지 않고 나중에 덮어쓰기만 됨 (따라서 크기가 줄지 않고 커지기만 함 - 8i)
- 모든 segment가 transaction 중일 경우에는 새로운 segment를 만듬 (제한된 크기까지 segment가 확장됨)
- undo가 확장되지 못해서 저장을 못할 경우 DML 도중에 error가 발생, 따라서 DML시 최우선적으로 undo를 확보함

- read consistency (읽기 일관성) ; commit이 안된 내용을 다른 user가 select할 경우 undo의 내용을 불러와서 보여줌

- instance recovery ; 오류 복구시 commit이 되지 않은 내용도 우선 적용하였다가 commit이 안된 것만 다시 roll back함

- 8i의 undo 생성과정 (수동)
table space 생성 -> roll back segment 생성 -> enable ; 9i부터는 table space만 생성하면 이후의 과정은 자동 (AUM)
=> 그래도 여전히 불필요하게 커진 undo는 수동으로 삭제해야함 (다른 파일로 대체한 후 삭제)

- tablespace는 여러개가 존재할 수 있지만, 한번에 1개만 사용할 수 있음 (반드시 사용중인 1개는 존재해야함)
=> 사용중인 tablespace를 다른 것으로 변경할 경우에는 일시적으로 2개 사용 (사용중인 것은 삭제 불가)

- snap shot too old error ; commit된 undo 파일의 내용이 다른 프로세스에 의해 덮어씌워져서 발생하는 오류
=> undo_retention ; snap shot too old error를 줄이기 위해 commit된 내용을 undo에 잠시 더 유지하는 옵션

- tablesapce ; 주메모리에 테이블이 보관된 가상의 공간 (logical space)

- datafile ; 보조기억장치에 테이블이 저장된 공간 (physical space)

- 하나의 datafile은 여러개의 tablespace에 속할 수 없다.

- 데이터를 안전하게 보호하기 위한 도구

- commit을 하면 System Commit Number 발생 (효과적으로 관리하기 위함) ; SMON이 관리
=> 중복없이 순차적으로 번호가 부여되므로 오라클의 시계라고도 함 (DB와 control file에도 SCN이 기록됨)

- Redo Log File이 가득차면 LGWR에 의해 새로운 로그 파일로 넘어가며 Log Switch(신호)를 발생시킴

- Log Switch가 발생하면 CKPT가 DBWR에 checkpoint를 발생해서 DB캐시에 있는 내용을 DB로 내려 쓴다.

- CKPT가 checkpoint SCN을 발생하면 checkpoint SCN 이전의 SCN의 내용도 모두 저장된다.
=> 일일이 하나의 SCN마다 checkpoin를 발생시키지않고, redo log file의 마지막 SCN만 발생시키면,
상위의 번호들은 자동적으로 따라서 저장됨

- Log Sequence Number (redo log file의 페이지 번호) ;
SCN의 위치를 쉽게 찾기 위해 발행하며 log switch가 발생할 때마다 번호가 부여됨

- redo log file의 손상을 대비해 group을 생성하고 같은 group 내에 동일한 member를 복제하여
하나가 손실되었을 때를 대비함 (동일한 group 내의 member의 내용은 같아야 한다)
=> 최소 2개의 group(권장 3개 이상), 최소 1개의 member

- redo log file의 3가지 상태 (보호중일 때는 group의 drop이 불가능)
current ; LGWR이 현재 사용하고 있는 group (보호 중)
active ; data file에 아직 반영되지 않은 상태 (따라서 보호되고 있는 상태)
inactive ; data file에 변경 사항이 반영된 상태 (보호 해제됨)

- on line redo log file ; 실제 사용하고 있는 redo log file로 내용이 덮어 씌워짐
- archived redo log file ; Arch에 의해 redo log file의 내용을 계속 적재시킴
 (on line redo log file이 덮어씌워져 복구할 수 없을 경우 대비해 별도로 보관함)

- 저장 공간이 부족할 경우 archive가 되지 않으면 DB에러가 발생함
=> 백업이 된 이후의 내용만 남겨두고 이전 내용은 삭제하여 공간을 확보해야 함 (70% 찻을 경우 전체 백업을 함)

SQL> alter database add logfile group # 
'경로' size @M;
=> 해당 경로에 @메가 크기로 #번의 redo log file 그룹을 생성

SQL> alter database add log member
'경로' to group #;
=> 해당 경로에 #번의 redo log file의 맴버를 생성

SQL> alter database drop logfile member
'경로';
=> 해당 경로의 맴버를 그룹에서 삭제 (실제 파일의 삭제는 이뤄지지 않음)

SQL> alter database drop logfile group #;
=> #번의 그룹을 제거함 (실제 파일의 삭제는 이뤄지지 않음)

SQL> alter system switch logfile; => log switch 신호 수동 생성

SQL> alter system checkpoint; => checkpoint 수동으로 생성

- no mount ; parameter file => 인스턴스를 만들기 위한 설계도
인스턴스 생성(SGA, background process), alert log 기록

- pfile (8i) ; 파라미터 수정 후 재부팅, 사용 및 관리가 편함
- spfile (9i ; server parameter file) ; p파일을 숨겨놓고 sp파일을 우선적으로 사용, 관리가 힘듬


- mount ; control file => DB 검사준비
SMON이 오류 검사 및 수정


- open ; data / redo log

- Dedicated Server ; 하나의 user process당 하나의 server process가 관리함
자원 사용률은 나쁘나 관리가 편함

- Shared Server (=Multi Thread Server) ; 여러개의 user process를 하나의 server process가 관리함
자원 사용률은 좋으나 관리하기가 힘듬
(하나의 user process에 문제가 발생할(무한 loop 등) 경우 server process가
문제가 생긴 프로세스의 처리에만 집중되어 다른 프로세스를 관리하지 못하게 됨)
=> 이를 해결하기 위해 문제가 생긴 server process를 roll back할 경우 다른 모든 user process도 날라감



- Mandatory background processes
DBWn, PMON, CKPT, LGWR, SMON


- DBWn (DBWR) ; data buffer cache의 내용을 data file에 저장하는 역할
checkpoint 명령이 있을 때 Data Buffer Cache의 내용을 data file로 저장함 (commit이 저장하는 것은 아님)
=> checkpoint는 DBA에 의해 발생(full checkpoint)하거나, 자동으로 발생(증분 체크포인트)함

- checkpoint가 발생하기 전까지 buffer cache의 내용을 보호하기 위한 상태 신호
- dirty ; 트랜젝션 종료 후 미 저장 (commit이 되었으나 data file에 저장되지 않음)
- pinned ; 사용중인 버퍼(블록)
- free ; 사용가능

- checkpoint queue ; checkpoint가 발생한 블록들을 우선 저장해 놓았다가 특정 시간이 되면 한꺼번에 datafile에 저장함
=> full checkpint는 사용자가 queue에 보관된 내용을 모두 data file로 저장시킴
=> control file에 data file로 저장된 sequence가 보관되어 비상시에 이를 토대로 복귀함

- timeout ; 3초에 1번씩 checkpoint queue에 보관된 내용을 control file로 옮김

- RAC ; 여러대의 시스템이 하나의 data file을 분산하여 처리함
RAC ping ; 다른 시스템에서 commit되었으나 checkpoint가 발생하지 않아 저장되지 못한 data가 있을 경우,
수정(commit)한 시스템에 RAC ping을 요청하여 checkpoint를 발생시켜 datafile에 저장하도록 함
=> RAC ping이 없을 경우, 수정된 시스템의 data와 다른 시스템의 data가 다를 수 있음


- LGWR ; redo log buffer의 내용을 redo log file에 저장하는 역할
(redo log buffer의 내용은 server process가 씀)

- redo log buffer의 내용을 HDD에 저장한 것이 redo log files임 (commit을 할 때 함께 실행됨)

- data file에 수정된 내용을 저장할 때 수정해야할 블록의 위치를 찾아서 저장해야하지만,
redo는 위치에 관계(검색X)없이 순차적으로 저장하므로 저장 시간이 빠름 (따라서 오라클은 redo를 자주 활용함)

- commit이 발생시, commit이 발생하지 않더라도 1/3, 1MB가 찻을 때, 3초마다


- PMON ; 좀비 process를 제거함 (돌발 상황으로 user 접속이 해제되어 남겨진 server process를 제거)

- 기본적으로 server process가 roll back을 함, 문제가 생겨서 아무것도 할 수 없는 서버 프로세스를 롤백함


- SMON ; PMON을 대신하여 비정상 종료(instance crash)를 해결함

- roll foward, roll back


- CKPT ; checkpoint 신호를 만듬

- 메모리 부분 => Instance (작업 진행) / HDD => Database (자료 저장) 로 구분함

- instance의 처리속도가 빠르므로 database의 자료를 불러와 작업을 한다. (자료를 접근하기 위한 수단)

- instance는 SGA와 background process로 나뉘어진다.

- 오라클 클라이언트를 설치해야 서버를 접속할 수 있음 (toad, orange, editerplus, golden 활용가능)
tnsnames.ora ; 서버 정보(ip)를 입력해놓는 주소록

- toad, orange 등으로 sql 작성 => 클라이언트 (user process)로 서버 접근 => 서버의 리스너로 서버에 데이터 요청
=> 서버에서 PMON이 필요한 데이터를 가져옴 (server process) => listener가 서버 프로세스와 유저 프로세스를 연결함
=> 서버 프로세스가 유저 프로세스를 직접 담당함

- toad, orange 등으로 처음 접속하는 시점에만 listener를 경유함 (이미 접속된 상태에서는 바로 서버 프로세스와 연결)
접속이 끊어졌다가 다시 재접속하는 경우, 다른 접속 프로그램으로 변환하여 재접속할 경우에만 다시 listener를 경유함
(기존의 접속자는 서버 프로프로세스와 직접 대화를 하므로 listener의 영향을 받지 않음)

- user process에서 server process로 SQL를 넘기면, 오라클은 SQL을 parsing함 (compile과 비슷한 개념)
1. 문법검사 ; SQL 문장에 오류가 없는지 먼저 검사함 (dictionary를 바탕으로 조사)
2. 실행계획작성 ; SQL을 실행하기 위한 계획을 작성함 (optimizer가 dictionary를 참조하여 실행 계획을 수립)
=> 최적의 실행(최소의 시간, 최소의 비용, 최고의 효율성)을 위해 실행 계획을 수립함

- parse (구문분석) ; shared pool에서 이루어짐
soft parsing ; 기존에 실행되었던 구문을 토대로 재분석을 하며 library cache를 주로 활용 (속도 빠름)
hard parsing ; 처음 실행되었던 문장의 구문을 분석할 경우 optimizer를 활용 (s.p의 결과가 없을 경우 2차로 실행)
library cache ; 한번 실행되었던 SQL 문장들을 저장하는 공간
dictionary cache ; 문법과 실행계획을 검토하기 위한 참고자료

- DB buffer cache ; 사용중인 데이터가 보관되어 있는 메모리 공간

- execute (실행)
필요한 블록(기본크기 8k)을 찾아서 DB에서 DB buffer cache로 불러오는 과정
하나의 개별 자료만 불러들이는 것이 아니라, 필요한 자료가 있는 block 전체를 buffer로 불러들인다

- fetch (인출)
buffer에서 원하는 자료만 가져오는 기능

- select 문이 실행되는 과정 ; parsing => execute => fetch

- redo log buffer ; 데이터가 바뀌는 내용을 저장하는 일종의 작업일지로 모든 '변화'를 저장함

- update 문이 실행되는 과정 ; parsing => execute => ...
1. redo에 실행될 내용 저장
2. undo에 기존의 내용 백업 ; commit, rollback 등을 위해 보관
3. DB buffer cache의 데이터를 수정 (fetch는 안됨)

- System Global Area (Shared Global Area) ; 모든 프로세스가 공유하는 공간
Program Global Area (PGA) ; 하나의 특정 서버 프로세스만이 사용하는 공간

- latch ; 작업 순서를 할당해주는 역할

- connection ; user - server 간의 접속 / session ; server - instance 간의 접속

- large pool ; 백업, 복구, 병렬처리 과정에서 사용