ORACLE Database / WAS (iAS) / SQL 자료실 - 포기하지 않으면 실패하지 않는다!
Vote Reply Modify Delete Forward Prev Next List

  Author   : 조성환 [ ladmin ] Vote: 1428, Modifies: 1, Hit: 3710, Lines: 144, Category: Etc.
About SGA (System Global Area)

출처: http://blog.naver.com/khjluck/80009737239
http://blog.naver.com/khjluck?Redirect=Log&logNo=80009737239



1) SGA란 무엇인가?

- System global area 또는 Shared global area라고 합니다.
말 그대로 여러 유저 세션이 공유하는 메모리 영역이지요. 이 곳은 크게 다음과 같이 구성됩니다.

  Shared pool

  Database Buffer Cache

  Redo Log Buffer



추가로 large pool과 java pool이 있을 수 있지요.



- SGA 할당 상태는 다음과 같이 확인합니다.



SQL> SHOW SGA

Total System Global Area 2270502804 bytes       
Fixed Size                    73620 bytes                -> 시스템 관련 메모리(관리 대상이 아님)
Variable Size             375775232 bytes             -> Shared pool과 기타 optional space
Database Buffers         1884160000 bytes
Redo Buffers               10493952 bytes


- Dynamic하게 사이즈가 결정됩니다. 즉, 사용자는 최대 사이즈를 SGA_MAX_SIZE 파라미터를 이용해 정의하고, 실제 사이즈는 동적으로 할당되는 것입니다.

(9i에서 자동할당을 지원한다고 합니다.)



2) GRANULE(그래뉼)은?

- 연속적인 가상 메모리 할당 단위 입니다. 데이터 I/O 단위인 블럭과 비슷한 개념이겠죠.

- 일반적으로 예상 SGA의 총 크기가 128보다 작거나 같으면 1granule = 4MB이고 그 외의 경우는 16MB입니다.



이제 SGA의 세부적인 사항에 대해 알아볼까요? ^^



** Shared Pool **

이 곳은 가장 최근에 실행한 SQL문과 최근에 사용한 데이터의 정의(예를 들면 number(5), varchar2(12) 등등)를 저장하는 곳입니다. 뭐하러 이런걸 다 저장하냐구요? 물론 퍼포먼스를 위해서죠~ 자주 사용되는 커리문 같은 건 이 곳에 올려놓고 다른 사람이 똑같은 커리를 날린다면?? 저장해놓은 정보를 이용해 빠르게 답을 보여줄 수 있지 않겠습니까? ^^

이 곳의 공간이 크면 많은 정보를 저장할 수 있으므로 전체적인 응답시간을 줄일 수 있답니다. 크기 조정은 다음과 같이 하죠

SQL> alter system set shared_pool_size = 100M;

위 커리를 이용해 수정하는 것은 9i 버전 이상부터 가능합니다~ 이 아래의 버전은 파라미터 파일을 텍스트모드로 열어서 수정해야 하죠 ^^ 이것은 다음에 공부하겠습니다.



용도에 따라~ 다음과 같이  두 부분으로 나뉩니다.



(1) Library Cache

 - 이부분이 바로 가장 최근에 사용한 SQL문과 pl/sql문에 대한 정보를 저장합니다.

 - 모든 유저가 공유하구요

 - SQL문을 저장하는 부분과 PL/SQL을 저장하는 부분은 분리되어 있습니다.

   즉 영역이 다르다는 거죠.


(2) Data dictionary cache

  - 최근에 사용된 데이터의 정의 모음을 저장합니다.

  - 예를 들어 파일, 테이블 , 인덱스 , 컬럼, 유저, 권한 등의 온갖 정보를 사용했다면!!

    이곳에 저장해 놓는 것입니다.  

  - 오라클 커리문도 일반 프로그램 언어와 비슷하게 parsing 작업을 합니다. 이 단계동안 서버프로세스는 데이터 딕셔너리를 뒤적뒤적해서 필요한 데이터의 정보를 빼내오게 되죠. 그런데 이 정보들을 메모리에 저장해놓으면 더 빠르게 정보를 얻을 수 있으니까, 최근에 사용한 데이터의 정보는 또 사용할 수 있다는 전제 하에 Data dictionary cache에 저장합니다~



흠.. 위의 내용을 꼼꼼히 읽었다면 눈치챌 수 있겠죠? 이 두 파트는 LRU(Least Recently Used) 알고리즘으로 관리됩니다.  ^^



** Database Buffer Cache  **

한 디비의 data역시 여러 유저가 공유할 수 있습니다. 그렇다면~ 다른 사람이 검색해서 나온 결과가 미리 캐쉬 메모리에 들어있다면 어떨까요? 다음 유저가 똑같은 데이터의 내용을 참조하고자 할 때 이 메모리에 저장되엉 있던 내용을 얼른 꺼내 보면 퍼포먼스가 향상되겠죠? 네. 이 역시 response time을 줄이기 위함입니다.

다음과 같이 크기를 조정해볼까요? 9i이상 버젼에서만 다음 커리로 적용이 가능하답니다.

SQL> ALTER SYSTEM SET DB_CACHE_SIZE=128M;



조금만 더 깊게 들어가볼까요 ^^

이 데이터베이스 버퍼 캐쉬는 다음과 같은 서브 cache로 구성됩니다.

이들은 서로 독립적이죠.

- DB_CACHE_SIZE : default 버퍼 캐쉬의 크기를 정의합니다. 따라서 0이상의 수여야 하겠죠

- DB_KEEP_CACHE_SIZE : 다시 사용할 메모리 블럭을 보유하는데 사용되는 크기를 정의합니다.

- DB_RECYCLE_CACHE_SIZE : 거의 재사용되지 않을 메모리 블럭을 제거하는 데 사용되는 크기

                                              를 정의한 것입니다.




** Redo Log Buffer **

디비를 사용하다보면 update, insert, delete 등의 테이블을 변경하는 일이 많을 것입니다. 그런데.. 무심코 잘못 수정했다거나, 갑작스런 사고가 생긴다거나 할 경우 원래 데이터로 돌릴 방법이 있어야 되지 않겠습니까? ^^ 이 리두로그 버퍼 역시 recovery를 위해 존재합니다.

이 곳에 데이터베이스 데이터 블럭의 모든 변경사항을 기록하는 것입니다. 이렇게 내부에 기록된 변경사항을 redo entry라고 하고 이 곳엔 변경사항을 원래대로 다시 돌리거나, 다시 실행할 수 있는 정보가 있게 되는 것입니다!

그러다 commit이 일어나면? 그냥 날려버릴까요? 아닙니다. 리두로그 파일에 LGWR이라는 프로세스가 내용을 써준답니다. 여기에 관해선 공부할게 더 많으니 다음에 꼭 다시 정리하도록 하겠습니다.





** 기타 optional area **

- Large pool : large pool의 부담을 줄이기 위한 목적입니다.  

- java pool : 자바를 설치하고 사용하는 경우 필요합니다.


Prev: Tablespace (테이블스페이스) drop 하기
Next: WHEN MODIFYING LARGE_POOL_SIZE OR JAVA_POOL_SIZE
2006/05/04(13:12) from 203.234.120.78
CrazyWWWBoard 2000

Vote Reply Modify Delete Forward Prev Next List
(c) Nobreak Technologies, Inc.