Memory -> PRocess 의 집합 -> Instance 라고 부름. Instance 는 DB를 변경하기 위한 구조..?
DB (데이터 집합소 자체)
DBMS (DB 를 쉽게 접할 수 있도록 도와주는 SW, ex) Oracle, Maria DB, Window 등))
>> Instance (메모리 영역에서 수행했던 작업들이 디스크 쪽에 반영이 되어야 하는데, 그 반영을 해주는 프로세스가 필요, 이 메모리와 프로세스의 집합을 인스턴스라고 부름)
DBS ()
pg 28 DB 서버 구조
내가 필요한 데이터가 있는 DB 서버에 접속하게 됨. 이 DB 접속을 요청하는 쪽은 Client 라고 부름
Client 에서 보내는 SQL ----> DB서버에서 컴파일 해주고, 네트워크를 통해서 Data 들을 전송해주게 됨.
> DB 서버 레벨로 보내주기 위한 Process 가 기동이 되는데 ( Client 에서 만든 SQL 을 보내주기 위한 프로세스) : User Process
>>> 반대로 DB 서버에서 그 sQL 을 받아주기 위한 프로세스 - Server Process
> pg 31
SQL 문장이 진행되는 3가지 단계
Parse (SQL 언어를 DB가 하기위한 동작으로 이해한다) (매우 다양한 일들이 일어남)
>> 보통 조직 내 SQL 언어를 작성하는 규칙을 만듬. PARSE 를 효율적으로 하기 위한 DB 세팅을 하는 사람들이 정함
>> 1) Syntax Check >> sql 명령어 중에서 약속된 키워드 (reserved) (select, where,from join, on 등) 이런것들이 정상적으로 적용이 되었는지 체크하는 영역
>> 2) Semantic & Privilege Check >> 우리가 원하는 테이블이, 이런 칼럼들이 정말 우리 DB 내에 생성되어 있는 테이블인지, 그 테이블에 존재하고 있는 칼럼들인지 체크하는 것이 Semantic Check
indexing 을 이용할 것이면 indexing 이 어떻게 이루어져있는지를 확인하는지 등도 Semantic Check
Privilege Check >> 그곳에 출입할 수 있는 권한이 있는지 ? 지금 접속한 사용자가 있을 것임. DB 가 그 사용자에게 권한을 주었을 것인데, (유저별 권한도 DB로 저장되어 있어서, 그것을 DB에서 읽는 과정을 거치겠지?) 그 권한으로 지금 얘가 원하는 동작을 수행할 수 있는지 체킹을 한다
>> 3) P_code >> Parse Tree, 암시적 Cursor 라고 부르기도 한다. (컴파일 단계) >> SQL 문장이 컴파일 된다. ( 이 3~3.1번이 제일 오래걸리는 일임)
>> 3.1) 굉장히 중요한 일 : 실행계획 (Execution Plan) :: 이걸 어떻게 하면 가장 효과적으로 가져올 수 있는지 계획을 짠다.
예를 들어, Data 를 읽어올 때 ~~ 방식으로 읽어와, 어떤 것은 제외하고 읽어와 등의 실행계획을 수행하고, 그 이후에 Execute 를 수행하게 된다.
Execute (필요한 동작을 수행한다) (입력, 변경, 삭제 등이 수행되었다는 로그만 띄워줌)
Fetch (조회시, 조건에 맞는 데이터들을 반환한다)
================================================================================================
* 우리가 쓴게 어떻게 DB 서버에서 처리가 될까??
pg29
오라클으 ㅣ메모리는 공유메모리 영역, 개별 메모리 영역이 있음.
> 공유 메모리 : 내 작업을 실제로 받아서 컴파일 등의 일을 수행할 서버 프로세스, 실제로 DB애에 반영해주기 위한 백그라운드 프로세스 등 모두다 공유해서 사용하는 메모리 영역 >> SGA : 공유 메모리 영역 (Shared Global)
> 중요한 3가지 : Shared Pool, Database Buffer Cache (실제로 반영), Redo Log Buffer --> 운영, 복구 등과도 관련이 있음. (아래 3단계 같이 보면서 ㄱㄱ)
shared pool >>>>> PARSING 하는 시점에 사용되는 메모리 영역
두가지로 나뉜다 : library cache, dictionary cache
ex) SELECT ename, sal FROM emp WHERE empno = 7788;
>> PARSE 과정 : 1) syntax check, 2) semantic * privilege check 3)
>> dictionary cache 에는 내가 셀렉트하려고 하는 emp 란 테이블이, emp 내부에 ename, sal 이란 칼럼이 있는지, empno 란 칼럼이 정말로 존재하는지 체크를 해야하는데,
그걸 체크하기 위해서 "정보가 어딘가에는 저장되어야 한다". 이걸 체크하기 위해서 어딜 먼저 찔러보냐면, Dicitionary cache 를 찔러보게 된다. " 야 내가 이런이런 정보들, 이런이런 권한 이런게 필요해, 이런 것들이 메모리 상에 있니? "했더니
>> 이게 최초로 실행한 SQL 문장이였기 때문에 메모리에는 아무런 정보가 올라와 있지 않았음. 즉 없음, 그랬으면 확인 불가
>> 이 시점에 그 정보를 저장하고 있는 dataffile 에 가서 읽은 다음에 그 정보들을 dictionary cahce 에 끌어 올린다. 그 이후에 semantic & privilege check 진행
>> 3) 그 이후 컴파일된 코드 값들 (P_CODE) 가 만들어지고 실행 계획이 SU 된다.
ex2) 위에 SQL을 이걸 두번 실행한다고 가정해보자
> 할 것도 많은데, 1번에서 한 일을 또 쭉~~ 다시 한다고 하면.... 좀 비효율 적이다.
> 컴파일된 코드값과 실행계획을 한번만하고 버리는게 너무 아까움. (이것을 우린 저장해 놓을 것이다)
> 똑같은 SQL 문장이 들어오면, 이미 메모리에 저장되어 있는지를 먼저 한번 체크를 해주겠습니다.
>> Parse 과정은 두가지로 또 나뉘어진다. (1) Soft Parse , (2) Hard Parse
> 2) 은 위에 1) 처럼 다~~ 하는 것
> 1) 은 Semantic & privilege 체크까지만 해줌. (모든 SQL 은 이 체킹까지는 꼭 해줘야함) 3)의 P-code 와 실행계획 만들기 전에 내가 실행하려는 SQL 문장이 메모리에 있는지 확인을 해줘야 한다 >> Library Cache 로 가서 확인한다 (P_code 와 실행계획을 저장하는 공간) 만약 최초 실행이 되었다면, Hard Parse 를 해줘야 함.
> 3 과정은 제일 오래걸리는 일인데, 이 과정을 줄여줄 수 잇다는 중요한 포인트가 있음. >> 조직 별로 SQL 가이드를 만드는 중요한 이유 중 하나이다 (대문자, 소문자 는 다르게 인식하기 때문에 일치시켜주자 이런 약속이 있음) .
컴파일 되는 기준
1) SELECT ename, sal
2) FROM emp
3) WHERE empno = 7788;
이게 Shraed Pool 이 하는 일이다 . PARSE 가 끝. 이제 아래 EXECUTE 랑 연결
==================================================================================
이제 DB Buffer Cache 를 살펴보자.
>> DB File 은 디스크의 페이징으로 인해 동일한 공간으 ㅣ여러개를 가지고 있을 것임.
>> 각각 datafile 들이라고 부름 (한 페이지) -> oracle 에선 block 이라 부르고, data 가 저장되어 있는 최소 단위라고 읽음.,
>> 7788 이란 친구가 2번 페이지에 저장이 되어 있었다고 가정해보자.
>> 위 예시에서 전해지는 상황임. 이제 2 Execute 란 작업이 실행되어야 할 차례
>> 내가 한번 읽은 data (조회든, 업뎃이든) 는 메모리 쪽에 계속 저장해 두겠다 (계속 물리적 IO 를 일으키는 것은 DB 성능 저하를 일으킨다)
>> 그 저장해 두는 영역이 DB Buffer Cache 입니다. (왜 바둑판 처럼 표시될까)
>> DB 를 읽을 때는 레코드(행) 단위로 읽지 않는다. block 단위로 읽은 다음에 copy 해서 메모리로 올리는 것임.
>> 따라서 execute 할 단계에서, DB buffer cache 에 block 이 올라가 있는지 먼저 확인. 없으면 IO 실행
>> 내가 필요한 7788 사원이 있는 2번 페이지 (블락) 을 copy 해서 DB buffer cache 한 바둑판 블락에 붙여넣기를 해 놓는 것임.
>> 이것만 하면, EXECUTE 가 끝남 (select 일시)
이젠 3 FETCH 가 일어난다 (역시 select 일시)
copy 된 블락에서 where 조건을 만족하는 행 data 를 읽은 다음에 그것을 반환하게 된다.
그 이후로 7700 사원 것도 하려고 함.
만약 7788 이랑 같은 블락에 있으면, IO 작업을 할 필요가 없음.
q)) 그러면,,,, DB Byffer Cache 에 저장된 모든 블락을 다 읽은 다음에 IO 작업 여부를 판별하는 걸까?? 그리고 join 절, on 절 등이 추가되면....?? 이렇게 되면 좀 많이 복잡한듯? 블락 안에 어떻게 저장되어 있는지를 알면 좀 이해가 될듯. 왜냐면 where 조건들이 저장될 리는 없으니까.
블락 단위로 cache 에 올려둔다는 점이 꽤나 중요함.
(하나의 SQL 문장은 10개의 block 을 가지고 와줘, 100개의 block 을 가지고 와줘 이런 식으로 tuning 을 할 수 있음)
QUERY 명령어 - SELECT
DML - INSERT, Update, Delete l.....
DDL (Data definition Language) - CREATE, ALTER, DROP ....
TCL (Tranx Control Lang // DML 과 연관) - 변경된 것들로 저장하는 commit 을 할 것인지, 저장하지 않는 rollback 을 할 것인지
DCL (Data Control Lang) - grant (권한 주기), revoke (권한 뺏기)
REDO LOG BUFFER - query 명령어인 select 를 제외한 모든 명령어가 기록이 되는 곳이 redo log buffer 입니다.
왜 기록이 될까요?? DB Buffer 캐시에 있었던 애들로 update 까지 해주는거임. 수정, 삭제 등까지 이 캐시에서 하는 것입니다. 나중에 디스크 datafile 이 깨지기라도 했을 때, 그 시점으로 돌아가기 위한 모~ 든 수정 /삭제 / 입력 등의 명령을 복구시켜야 한다. 따라서 select 를 제외한 모든 명령어를 기록한다.
>> 어떻게 기록되는지 살펴볼까??
솔직히 모든 SQL 에선 SELECT Tuning 만 95% 함. 제일 중요하기 떄문.
자 update 를 한다고 생각해보자
UPDATE emp SET sal = sal*1.1 WHERE empno=7788; 을 수행할 것임.
Library cache 에는 7788 select + 실행 계획 저장
Dic cache 에는 emp, sal 등에 대한 저장,
DB Buffer chace = 7788 정보 저장
1. PARSE 는 메모리 상에 저장되어 있는 것들을 확인하고, select 7788 에 대한 정보만 있었기 때문에 P_CODE 생성이 실행되어, 컴파일 및 실행계획을 진행한다.
2. EXECUTE 단계로 가서, 필요한 데이터가 DBBC 에 저장되어 있기 때문에, 거기서 활용을 할 것임.
3. 7788 급여가 현재 1000원 이였다고 가정을 하겠다. 즉 1100으로 변경을 해야함.
>> 일어나는 일
1. REDO LOG BUFFER 에 우리가 던진 update sql 문이 그대로 기록이 된다) > 먼저 기록이 되지 않으면 변경 반영 작업이 수행될 수 없다.
2. DB Buffer Cache 에 있는 7788 의 정보중 1000 의 급여를 1100 으로 변경을 한다.
==== EXECUTE 끝남
하지만 변화된 것으로 저장할지, 되돌릴지 (commit, rollback) 를 판별하지 않았음.
> 과거로 되돌아 가겠다고 했음. 그러면 REDO LOG BUUFER 로 [rollback] 이란 명령어를 기록한다.
다시 DB BC 로 감. (모든 select, update, delete 등의 작업은 표면상으로 DBBC 에서 우선 수행된다). 어떻게 1000으로 되돌릴 까?
> 한 블럭이 100건의 행 data 가 있다고 해보자. 난 한 행을 바꾸고 싶은데, 100 개의 행 이 있는 블락을 다 가지고 올라와야 한다. (읽쓰 작업은 블락 단위기 때문)
> 메모리 블록에는 참고로 원본 복사본에 대한 블락 값이 한 값만 존재할 수 있음.
*** 다시 정리....
실제 모든 데이터는 디스크 안에 있음. 7788 의 급여느느 1000원 > 모든 변경 작업은 메모리에서 진행되기 때문에 DB Buffer Cache 로 읽어온다.
>> 과거로 되돌리기 위해서는 과거 값이 어딘가에는 있어야 한다.
>> 변경작업이 일어나는 원리 : execute 단계에서, select 와는 다르게 일어나느 일이 있음. 즉, Rollback 대비를 위해 undo data 에 저장을 한다. datafile 들 중에서, 오로지 변경작업을 수행을 할 때, 변경작업을 위해 전문적으로 저장하는 데이터파일이 undo datafile. >>> 쌍으로 올라와 있는지 체크.
>> 내가 필요한 데이터 블록이 메모리에 올라와 있음. undo datafile 에 가서 before 작업을 담을 수 있는 블락을 메모리로 올린다.
>> undo block 에 기존 1000을 입력을 시킨다. 그리고, 실제 데이터 블락에 있는 내용을 1100으로 변경을 한다
>> 따라서 , 지금 메모리에는 대상 데이터에 대한 실제 data 블락, undo data 블락 두개가 올라가 있는 상태이며, 1100으로 변경만 되어 있는 상태이다. 여기서 확정 (commit) 및 반영 을 시킬 수 있고, 취소 (rollback) 를 시킬 수 있음.
> 만약 확정하지 않고, rollback 하라는 명령을 수행했다.
>> rollback 역시 redo log buffer 에 저장되며, 어떤 rollback 인지에 대한 것도 같이 담김. 그럼 바로 위 update 에 대한 rollback 이다라는 정보도 같이 저장되는 것임.
>> 그러면 undo data block 에 있는 1000이라는 값을 읽어서, 그 값을 data 블락에 다시 써준다. 1000으로.
> 만약 확정되어서, commit 을 수행했다.
>> commit 역시 기록이 된다.
>> 변경된 데이터는 DBBC에서 datafile 로 내려 써줘야 할 것 같음. 하지만 그렇게 수행되지 않는다.
>> 이유 : 현재 한 블록에 100개의 행 데이터가 저장되어 있다고 보자. 그리고 1100으로 바뀐 상태이다. 커밋을 해서 내려 썼다고 하자. datafile 내 블락을 overwrite 했다.
이 때 누군가가같은 블록 내 다른 행을 변경하려고 한다면, 그 블록을 다시 불러 올려야 한다. 그러면 또 다시 다 올리고, 하나만을 변경하기 위해서이지만 전부 다 또 overwrite 를 해야함. (물리적인 IO를 최대한 줄여주는 것이 굉장히 중요함)
> 따라서, 되도록 한 블록이 올렸으면 그 블록은 오래오래 유지할 수 있는만큼 유지했으면 좋겠다는 목적에서 ㅈ시작되는 것임.
>> 그래서 oracle 에서는 다음과 같이 함. redo log buffer 에 쓰여진 변경 history 를 통해서 commit 을 보장해주겠다고 함.
>> 자 다시! 누군가가 1000 --> `1100으로 변경함. 이 시점에서!
>> 근데 다른 누군가가
update A -> b 를 하겠다고 함. DBBC 에 A가 있는지 확인했는데 없음. 그래서 다시 IO 작업을 통해서 불러왔음. 그리고 undo datafile 도 있는지 확인을 했음. 없음. 그래서 undo data file 에서 비어 있는 블록을 하나 복사 시켜서 메모리에 올려줌.
이제 Redo log buffer 에 update A-> b 기록 할것임
그리고 Data A 를 Undo A 로 기록을 한다.
그리고 Data A를 Data B 로변경을 한다
(변경까지는 완료된 상태, 확정은 안됨. 여기까지는 위와 똑같음)
이 상태에서 다시 위의 1000 --> 1100 하겠다는 사용자가 commit 을 수행함
"commit "
========================
update DEPT d
set d.loc = 'DENVER'
where d.deptno = 40;
를 하면 다음과 같이 출력됨.
DEPTNO DNAME LOC
---------- -------------- -------------
10 ACCOUNTING NEW YORK
20 RESEARCH DALLAS
30 SALES CHICAGO
40 OPERATIONS BOSTON
1 행 이(가) 업데이트되었습니다.
이 상태에서 commit 을 함.
DEPTNO DNAME LOC
---------- -------------- -------------
10 ACCOUNTING NEW YORK
20 RESEARCH DALLAS
30 SALES CHICAGO
40 OPERATIONS BOSTON
1 행 이(가) 업데이트되었습니다.
커밋 완료.
이렇게 출력된다.
====================================
>> '커밋 완료.' 이란 메시지가 어떻게 출력되냐면,
>> commit 이란 명령은 우선 redologbuffer 에 저장이 된다. commit 도 rollback 처럼 [어떤 변경 작업들에 대한 commit 인지] 에 대한 정보도 같이 되어 있음.
>> data base 가 가지고 있는 datafile 종류
1) db -datafile ( 진짜 db 들어가 있는 애들)
2) control datafile
3) redo log file >>>>>>>>>>> 메모리 상에 있으면 buffer, 디스크에 있으면 file.
>> 자 redologbuffer 에 있는 commit 시, buffer 에 있는 변경 history 를 redo log file 이라는 db 공간으로 써준다. (현재, 1000-> 1100 변경, A-> B 로 변경 history) 두가지에 대한 history 가 redo log file 에 내려써진다. (현재 commit 은 첫번째 update 에 관한 것이라는 정보도 같이) 이렇게 된다면!! commit complete (커밋완료.) 메세지를 출력하도록 명령한다.
>> 여기까지 보면 확정이라고 보고, DB Buffer Cache 도 정리해줌.
>> 하지만 여전히 datafile 에는 변경 전의 data 를 가지고 있다.
>>
만약 이 시점에서 DB가 재시작된다면, Redo Log file 을 읽는다. 그리고 그 파일을 통해 datafile 에 입력을 한다.
> 이 떄, 첫 업데이트에 대해선 완전한 저장을 수행한다. 두번 째 업데이트 (a->b ) 에 대해선 commit ㅇl 명시적으로 되어 있지 않다면, ROLLBACK 을 수행하는 것이 약속이다
> 이래서 블록 단위로 진행을 하는 것임.
Q)) 그렇다면 redo log file 이 data file 에 반영되는 시점은 >> 무조건 DB가 재시작되는 시점인가요? 그럼 다시 그 값을 조회하라는 명령이 들어온다면, 메모리에서 읽어서 반납해주는 것?
>> 그리고 update 가 완료 commit 이 진행되면 DBBC 에 있는 두가지 블록은 제거되나요? 그랬으면 2번째 질문이 불가하지 않나?
A: 일반적인 반영은 그냥 냅두면 됨. 왜냐면 DBBC 가 꽉 차면 오래된 애들을 기점으로 data file 에 반영 후 삭제하기 떄문.(LRU 알고리즘 사용) 그 때 반영됨. 그 전에 그 데이터에 대한 요청은 memory 단에서 해결. 따라서 commit 했다고 제거되거나 그러진 않음.
================================================================================
각 백그라운드 프로세스들도 알고 있기 (PG30) -- 사실... 뭐 꼭 다 알아야 할 필요는 아님.
SMON, PMON, DBWR, CKPT, LGWR
(프로세스 모니터: USER PC 에서는 USER PROCESS 가 있음, DB 서버에는 SERVER PROCESS 가 있으서 sql 을 받게됨. 이 DB에는 listener 라는 프로세스가 필요함. - 이 프로세스는 네트워크를 담당하는 프로세스임. 이 프로세스는 유저 프로세스의 요청을 받아서 db에 전달 하여 연결시키는 작업을 하게 된다. ) SID = prod 라고 한 것은, 해당 DB를 위해 작업하는 인스턴스의 이름임.
> listener 프로세스는 user process (ora01 이란 유저) 의 접속 요청을 받음. listener 프로세스는 자신이 접속을 시켜줄 수 있는 db 라는 것을 확인할시, listener 는 server process 를 가동. server process 는 user process와의 connection 을 하게 해줌.
말그대로 listener 는 user, server process 를 연결 시켜주는게 다임.
server process 가 모든 일은 다 함.
두 관계가 비정상 적인 종료가 되어 있을 때, 이 user process 으 ㅣcommit 이 없을시에 수행한 모든 작업을 rollback 시킴. (이게 PMON 이 하는 일)
================================================================================
메모리 구성 요소 관리
select * from emp where deptno = 30;
DBBC 로 해당 블록이 올라옴.
만약 order by sal; 라는 게 들어간다.
>> 이 부분은 "나 한테만 필요" 즉, 이 부분은 공유 데이터 (SGA) 에서 사용하는게 아님
>> PGA (Program, Private Global Area) : 정렬이 필요한 그 Client 에게만 필요할 시 여기서 함.
PGA >> sort_area_size , hash_area_size, bitmap_area_size 등 개별 작업을 위해 메모리에 얼마만큼을 사용하겠다라는 지정을 할 수 있음.
pg 37 ~ 38
공유 메모리 자동 관리 기법 >> 옛날에는 PGA, SGA 끼리 서로 침범을 못함. 이제는 SGA 가 부족하면 PGA 남은거 가져다 쓰고, 반대쪽까지 해결해줄 수 있도록 지원해주는 시스템이 도입됨.
pg 39
DB 구성 파일들
>> Control, Data ,redo log. (DB 를 직접적으로 구성하는 파일들)
>> Control File 은 뭘까? 제어를 위한 파일임. DB 구성하는 DB 파일이 가장 많음. redo log 파일. 이 파일들이 실제 어디에 있는지, 각 파일의 상태는 어떤지 등을 관리 / 저장되어 지는 파일이 Control File 이다.
>> 각 파일들의 정합성 등을 체크하기 위함.
그림에서 위에 3개의 파일들은 항상 Access 가능해야 함.
아래 5개 파일은 특정 필요 시점에 Access 하는 파일들.
1
1) Parameter 파일 >
다음과 같은 sql 수행
============================================================
show parameter sga_; (sga 를 위한 파라미터들을 보여달라)
show parameter pga_; (pga 가 들어가 있는 모든 파라미터들을)
NAME TYPE VALUE
---------------------------- ----------- -------
sga_max_size big integer 1G
sga_min_size big integer 0
sga_target big integer 1G
unified_audit_sga_queue_size integer 1048576
NAME TYPE VALUE
-------------------- ----------- -----
pga_aggregate_limit big integer 2G
pga_aggregate_target big integer 512M
============================================================
SQL 튜닝할 때 이런 것들은 변경해주기도 함.
SQL 프로그램 시작되는 과정
Shutdown
--> nomount (Instance 구성단계)
--> mount (controle File Open) : Instance 를 통해 연결될 DB가 어떤 DB인지 확인 후 연결 짓는다. (parameter_file 에 db 이름 있음) mount 의 이름 그대로임
--> open (datafile, read log file Open) : 이 작업까지 와야 SQL 을 제어할 수 있음.
>> Parameter 파일은 Instance 를 구성해주기 위한 파일들을 담고 있는 정보들이다.
2) 백업 파일
데이터 파일의 백업 파일, 콘트롤 파일의 백업 파일, (redo log file 은 또다른 bu 시스템이 있음)
=========================================================
클러스터링 환경
>> 여러 개의 인스턴스로 하나의 공유 DB 를 access 하는 환경을 말한다.
>> 고가용성의 장점을 가지고 있다.
> I1 에 접속해서 작업을 하다가 I1 이 죽음.
> I2, I3 인스턴스로 자동으로 fail-over 해준다.
> I1 이 100000건 조회 중에, 5000건 fetch 하고 fail 나면, I2, 로 바로 옮겨져서 나머지를 수행해준다.
==================================================================================================================
DB 저장영역 구조
pg43
논리적 영역과 물리적 영역
Full Table Scan
>>
불러오기 위해서 모든 Data block 을 다 불러온다? 그리고 원하는 값이 없으면 버리는?
>> Table Space (논리적인 데이터)
> 물리적으로는 datafile 에 있으나, 논리적으로는 테이블 스페이스. 하나의 업무별 space 에는 그 space 를 위해서 여러개의 segment 들이 만들어졌음. 그게 table seg , index seg, undo seg, temporary seg 일 수도 있음.
> 그 아래로 Extent 가 있음. (한 저장공간의 크기) > Extent 란 연속된 Block 의 집합으로 이루어져 있음.
*
create 를 통해 만들 수 있는 모든 것은 Object (객체) 라고 부름.
그 중 Segment 란, Data 를 저장하기 위해서 저장공간이 필요한 객체들을 Segment 라고 부름.
> 대표적인 Segment = Table, Index, UNDO, TEMPORARY
사실 물리적으론 모두 OS File (data file) 에 저장을 한다. (DB Datafile) > Oracle 입장에서 관리를 편하게 하기 위해서 논리적인 이름을 붙여주기로 하고, 그 논리적인 이름을 테이블 스페이스라고 한다(논리적 공간).
Extent 는 Oracle Block 으로 이루어져 있음.
q) 정렬이 실제 DB 를 정렬하는건지??
============================================================================================