목차 1. Tibero RDBMS 소개 2. 데이터베이스로서의기본기능 3. 데이터베이스저장구조 (Database Storage Structure) 3.1. Logical Structure 3.2. Physical Storage Structure 4. 티베로프로세스 (T

Transcription

1 TECHNICAL WHITE PAPER Tibero RDBMS Architecture

2 목차 1. Tibero RDBMS 소개 2. 데이터베이스로서의기본기능 3. 데이터베이스저장구조 (Database Storage Structure) 3.1. Logical Structure 3.2. Physical Storage Structure 4. 티베로프로세스 (Tibero Process) 4.1 클라이언트프로세스 (Client Process) 4.2. 워킹프로세스 (Working Process 또는 Foreground Process) 4.3. 백그라운드프로세스 (Background Process) 4.4. 리스너 (Listener) 4.5. 서버프로세스생성순서 4.6. 워킹프로세스와백그라운드프로세스작동과정 5. 티베로메모리 (Tibero Memory) 5.1. 공유메모리 (Shared Memory) 구조 5.2. 시스템메모리 (System Memory) 구조 현재기업의비즈니스는폭발적인데이터의증가와다양한환경및플랫폼의등장으로빠르게확장되고있다. 새로운비즈니스환경이도래함에따라보다더효율적이고유연한데이터서비스와정보의처리, 데이터관리기능이필요하게되었다. Tibero RDBMS 는이러한변화에맞춰기업비즈니스구현의기반이되는데이터베이스인프라구성을지원하며고성능, 고가용성및확장성의문제를해결하는엔터프라이즈데이터베이스관리시스템이다. 기존 RDBMS 의단점을보완하기위해 Tibero RDBMS 는독자적인 Tibero Thread Architecture 를채택, 구현하였다. 한정된서버프로세스의 CPU 및메모리등의시스템리소스를효율적으로사용하면서뛰어난성능과안정성및확장성을보장하고편리한개발환경과관리기능을제공한다. Tibero RDBMS 는초기설계부터대규모사용자, 대용량데이터, 강화된안정성, 향상된호환성측면등에서타 DBMS 와차별화를고려하여개발되었다. Tibero RDBMS 는이처럼기업이원하는최적의데이터베이스환경을제공하는대표적인 RDBMS 이다. 2. 데이터베이스로서의기본기능 Tibero RDBMS 는 SQL 문장의논리적인묶음인데이터베이스트랜잭션이안전하게수행되는것을보장하기위해서다음의 4 가지성질을만족한다. Atomicity All-or-nothing 즉트랜잭션이행한모든일이적용되던가, 아니면모두적용되지않아야함을의미한다. Tibero RDBMS 에서는이를위하여 undo data 를사용한다. Consistency 어떠한트랜잭션이든지실행결과와상관없이데이터베이스에정의된규칙을지키면서언제나 1. Tibero RDBMS 소개 일관성있는데이터베이스상태를유지하는것을의미한다. 2

3 트랜잭션이데이터베이스의 consistency 를깨뜨리는일은여러방면에서생겨날수있다. 간단한예는테이블과인덱스간에서로다른내용을담고있어서 consistency 가깨지는것이다. 이를막기위해 Tibero 에서는트랜잭션이적용한일들중일부만자신이나남에게적용되는것을막고있다. 즉, 테이블만수정했고아직인덱스를수정하지않은상태라고해도다른트랜잭션에서는이를예전모습으로돌려보아서테이블과인덱스가항상 consistency 가맞는형태로보이게된다. Isolation 트랜잭션을수행시다른트랜잭션이수행과정에끼어들지못하도록보장하는것을의미한다. 이것은트랜잭션밖에있는어떤연산도중간단계의데이터를볼수없음을의미한다. 트랜잭션은혼자만돌고있는것처럼보이게된다. 물론다른트랜잭션이수정한데이터에접근 영속성을보장해준다. 또한블럭이디스크에내려가기전에항상 Redo 로그가먼저내려가서데이터베이스전체가일관성을지니게한다. 3. 데이터베이스저장구조 (Database Storage Structure) Tibero RDBMS 의데이터를저장하는구조는다음과같이논리적구조와물리적구조로나뉜다. 논리적구조와물리적구조는분리되어있기때문에논리적저장구조접근에직접적인영향을주지않고데이터의물리적구조를다룰수있다. 논리적구조데이터베이스의스키마객체를저장하는영역이다. 시에는이를기다릴수는있지만다른트랜잭션이수정중이므로접근할수없다고에러가나지는않는다. 이를위해 Tibero 에서는 Multi version concurrency control 기법과 Row-level locking 기법을사용한다. 데이터를참조하는경우에는 MVCC 기법을이용하여다른트랜잭션과무관하게참조가능하며, 데이터를수정할때도 row level 의 fine-grained lock control 을통하여최소한의충돌만을일으키고만약같은데이터에접근한다고해도단지기다림으로써이를해결한다. 즉, 데이터최소단위인 Row 단위의 locking 을통하여최대한의 concurrency 를보장해준다. 많은 Row 들을수정한다고해도테이블에 lock 이걸려서동시에발생하는 DML 이수행되지못하는상황은발생하지않는다. 이러한기법을통해 OLTP 환경에서더욱강력한성능을발휘하고있다. Durability 트랜잭션이커밋이되면전력손실, 고장, 에러등다양한 논리적저장영역은다음과같은포함관계가있다. 데이터베이스 > 테이블스페이스 > 세그먼트 > 익스텐트 > 블록물리적구조운영체제와관련된파일을저장하는영역이다. 물리적저장영역은다음과같은포함관계가있다. 데이터파일 > 운영체제의데이터블록 장애상황에서도영원히반영되어야함을의미한다. Tibero RDBMS 에서는이를위하여 Redo 로그와 writeahead logging 기법을사용한다. 트랜잭션이 commit 될때해당 Redo 로그가디스크에기록되어트랜잭션의 3.1. Logical Structure 블록 (Block) 3

4 데이터베이스에서사용하는논리적저장구조의최소단위이다. Tibero RDBMS 는데이터를블록 (Block) 의형태로저장하고관리한다. 그크기는초기화파라미터 DB_BLOCK_SIZE( 기본값 8K) 의해결정된다. 즉, DB_BLOCK_SIZE 는 Tibero RDBMS 내에데이터파일이나인덱스파일을접근할때사용할수있는가장작은입출력단위이다. 블록의앞부분에는블록에포함된로우데이터에대한위치및메타정보가담긴헤더가존재한다 익스텐트 (Extent) 익스텐트 (Extent) 는특정타입의데이터를저장하기위해서할당된연속된데이터블록의집합이다. 세그먼트를처음만들거나, 세그먼트의저장공간이더필요한경우, Tibero RDBMS 는테이블스페이스에서연속된블록의주소를갖는데이터블록을할당받아세그먼트에추가한다 세그먼트 (Segment) 세그먼트 (Segment) 는익스텐트 (Extent) 의집합이다. 하나의테이블, 인덱스등에대응되는것으로, CREATE TABLE 등의문장을실행하면생성된다 데이터세그먼트 (Data Segment) 데이터세그먼트 (Data Segment) 는하나의테이블, 파티션테이블내에포함된모든데이터를저장하고있다 인덱스세그먼트 (Index Segment) 인덱스세그멘트 (Index Segment) 는하나의인덱스내에포함된모든데이터를포함하고있다 언두세그먼트 (Undo Segment) 언두세그먼트 (Undo Segment) 는특정트랜잭션에의해 정합성 (read consistency) 를보장하기위해서도사용할수있다. Tibero RDBMS 에제공하는읽기정합성은다음과같이두가지종류가있다. 가 ) 문장수준의읽기정합성 (Statement-level read consistency) 문장수준의읽기정합성은특정쿼리로부터반환된결과데이터는쿼리의시작시점의데이터로부터나온것을보장한다. 따라서레벨에서는쿼리수행중에다른트랜잭션에의해서만들어진데이터의변화를보지않는것을보장한다. Tibero RDBMS 는기본적으로문장수준으로읽기정합성을보장한다. 나 ) 트랜잭션수준의읽기정합성 (Transaction-level read consistency) 트랜잭션수준의읽기정합성은하나의트랜잭션내모든쿼리는같은트랜잭션내에서쿼리에의해서이루어진데이터변화를볼수있으나다른트랜잭션에의해서이루어진데이터의변화는볼수없는것을보장한다. 이러한트랜잭션을직렬화 (serializable) 트랜잭션이라고한다 임시세그먼트 (Temporary Segment) 임시세그먼트 (Temporary Segment) 는쿼리수행중간단계에서임시작업공간으로사용할수있는공간이다. 주로 ORDER BY, GROUP BY, UNION, INTERSECT, MINIUS, DISTINCT 연산등에서사용한다 테이블스페이스 (Tablespace) 테이블스페이스는데이터베이스의물리적관리를단순화시키기위해서서로관련된테이블이나인덱스와논리적객체들을하나로묶어놓은논리적저장구조이다. 테이블스페이스를통해서물리적파일시스템내에서데이터베이스데이터를저장할공간을할당하고분배한다. 변경되기이전의데이터블록의내용을담고있다. 트랜잭션의일부분이성공적으로끝나지않은경우, 언두 세그먼트에저장된이전데이터블록을이용하여데이터를 가 ) 테이블스페이스의논리적구조 이전상태로돌린다. 또한언두세그먼트는읽기 - 4

5 다음은데이터베이스내에포함된테이블스페이스의 논리적구성을나타내는그림이다. 다 ) 다음은테이블스페이스의물리적구성을 나타내는그림이다. 테이블스페이스는 [ 그림 3.2] 와같이물리적으로여러 하나의데이터베이스내에는여러개의테이블스페이스가존재할수있다. 하나의테이블스페이스는테이블이나인덱스를나타내는여러개의세그먼트들이존재할수있다. 각각의세그먼트들은익스텐트단위로확장하여여러개의익스텐트들이존재할수있다. 마지막으로각각의익스텐트들은연속된블록으로구성되어있다. 개의데이터파일로구성된다. 빈번하게사용되는두테이블스페이스 ( 예 : 테이블과인덱스 ) 는물리적으로서로다른디스크에저장하는것이좋다. 왜냐하면한테이블스페이스를액세스하는동안에디스크의헤드가그테이블스페이스에고정되어있기때문에, 다른테이블스페이스를액세스할수없다. 따라서, 서로다른디스크에각각의테이블스페이스를 나 ) 테이블스페이스의물리적구조 저장하여동시에액세스하는것이데이터베이스성능을 그림 3.1 테이블스페이스의논리적구조 그림 3.2 테이블스페이스의논리적구조 5

6 향상시키는데도움이된다. 테이블스페이스안에서특정한데이터파일을사용할수있도록임의로지정할수없다. 또한, 테이블스페이스내의모든데이터블록은구분되지않고저장공간에할당된다. 논리적저장영역과물리적저장영역에공통적으로포함된다. 논리적저장영역에는 Tibero RDBMS 의모든데이터가저장되며, 물리적저장영역에는데이터파일이하나이상저장된다. 테이블스페이스는논리적저장영역과물리적저장영역을연관시키기위한단위이다. 이상의데이터베이스에서사용될수도없다. 테이블스페이스가처음생성될때, 그와관련된데이터파일의물리적디스크공간은미리초기화가된다. 그리고사용자가테이블스페이스의테이블에데이터를추가할경우, 익스텐트형태로공간을확보한다. 이후에블록단위로데이터를기록하고읽는다 Redo Log File 로그파일은 Redo 로그를저장하는파일이다. Redo 로그는데이터베이스에서발생하는모든변경내용을포함하며, 데이터베이스에치명적인에러가발생한경우, 커밋된트랜잭션의갱신된내용을복구하는핵심적인 3.2. Physical Storage Structure 데이터구조이다 Data File 데이터파일은테이블이나인덱스형태로표현되는논리적객체의실제데이터를포함하고있다. 데이터파일의실제물리적구조는 OS 나파일시스템의종류에따라다르다. 사용자의질의요청에따라데이터파일에저장된데이터는운영중에읽혀져데이터베이스버퍼캐시에올라가게된다. 하나의테이블스페이스는하나또는여러개의데이터파일로구성된다. 하지만하나의데이터파일은하나이상의테이블스페이스에소속될수없다. 또한하나 가 ) Redo 로그구조다음은 Redo 로그의구조를나타내는그림이다. [ 그림 3.3] 에서보듯이, Redo 로그는두개이상의로그그룹 (Log Group) 으로구성된다. Tibero RDBMS 에서는이러한로그그룹을순환적 (Circular) 으로사용한다. 예를들어, 세개의로그그룹으로 Redo 로그를구성하는경우, 먼저로그그룹 1 에로그를저장한다. 로그그룹 1 에로그가가득차면, 그다음로그그룹 2, 3 에로그를 그림 3.3 Redo 6 로그의구조

7 저장한다. 로그그룹 3 까지로그가가득차면로그그룹 1 부터다시저장한다. 이처럼하나의로그그룹을모두사용하고그다음로그그룹을사용하는것을로그전환 (log switch) 이라고한다. Redo 로그에는하나이상의로그레코드 (log record) 가저장된다. 로그레코드에는데이터베이스에서발생하는모든변경내용이포함되어있으며, 이전에변경된값과새로운변경값이함께저장된다. 다 ) 로그멤버의다중화로그그룹하나에포함된로그멤버는시스템의성능을위해서로다른디스크에저장하는것이좋다. 같은로그그룹내의모든멤버는같은로그레코드를저장해야한다. 모든로그멤버가서로다른디스크에존재하게된다면, 로그레코드를저장하는과정을동시에수행할수있다. 다음은같은로그그룹의모든로그멤버를서로다른디스크에배치한그림이다. Tibero RDBMS 는동시에하나의로그그룹만을사용하는데, 현재사용중인로그그룹을활성화 (active) 된로그그룹이라고한다. 하나의로그그룹은하나이상의로그멤버로구성할수있다. 이러한구성을다중화 (multiplexing) 라고한다. 단, 다중화를하려면동일한그룹에속해있는모든로그 멤버의크기는일정해야하며, 동일한데이터를저장하고동시에갱신되어야한다. 반면에서로다른영역에있는로그그룹은각각다른개수의로그멤버를포함할수있으며, 로그멤버의크기가같지않아도된다. 하나의로그그룹을여러로그멤버로구성하는이유는일부로그멤버가손상되더라도다른로그멤버를사용하기위함이다. 디스크가대단히신뢰성이높거나데이터가손실되어도큰문제가없다면다중화를하지않아도된다. 그림 3.4 로그멤버의다중화 [ 그림 3.4] 에서 Log Member 1-1 은로그그룹 1 의첫번째로그멤버라는의미이다. 하나의디스크에같은그룹의로그멤버가존재한다면동시에같은로그레코드를저장할수없다. 이때문에데이터베이스시스템의성능이저하되는원인이되기도한다. 로그아카이브모드를 ARCHIVELOG 로설정했을때, Redo 로그안에활성화된로그그룹의로그가저장됨과 나 ) Redo 로그파일의구성로그멤버는기본적으로하나의로그파일이다. Redo 로그를구성할때, 각로그그룹과로그멤버에서로다른로그파일을할당해야한다. 로그파일은데이터파일과서로다른디스크에저장할것을권장한다. 로그파일과데이터파일을같은디스크에저장하는경우, 디스크에장애가발생한다면데이터베이스를다시복구할수없게된다. 각로그그룹이여러개의로그멤버로구성된다면, 최소한로그멤버하나는데이터파일과다른디스크에저장되어야한다. 동시에비활성화된로그그룹중하나에대해서아카이브가수행된다. 활성화된로그그룹과아카이브중인로그그룹이한디스크에존재하게된다면이또한데이터베이스시스템의성능이저하되는원인이된다. 따라서, 서로다른로그그룹의로그파일은각각다른디스크에저장하는것이시스템성능을높이는데도움이된다. 라 ) 로그그룹의다중화다음은두개의로그멤버로구성된두개의로그그룹을서로다른디스크에분리하여배치한그림이다. 7

8 정보 설명 데이터베이스이름, $TB_SID.tip 파일의 데이터베이스 이름또는생성되었거나변경된 타임스탬프등이있다. 테이블스페이스를구성하는데이터파일 테이블스페이스 또는생성되었거나변경된타임스탬프 등이있다. 그림 3.5 로그그룹의다중화 [ 그림 3.5] 에서 Log Member 1-1 은로그그룹 1 의첫번째로그멤버라는의미이다. 로그그룹의크기와개수를정할때는아카이브작업을충분히고려해야한다. 로그그룹의크기는제 3 의저장장치에빠르게전달하고저장공간을효율적으로사용할수있도록설정해야한다. 또한, 로그그룹의개수는 데이터파일 Redo 로그 데이터파일의이름과위치또는생성되었거나변경된타임스탬프등이있다. 로그그룹의개수및이를구성하는로그멤버 ( 로그파일 ) 의이름과위치또는생성되었거나변경된타임스탬프등이있다. 아카이브중인로그그룹을대기하는경우가발생하지않도록해야한다. 로그그룹의크기와개수는데이터베이스를실제로운영하면서변경해야한다. 즉, 데이터베이스에최적화된파라미터를설정한후로그그룹의크기와개수를증가시켜가면서, 데이터베이스처리성능에무리가가지않는범위에서변경해야한다 Control File 컨트롤파일은데이터베이스자체의메타데이터를보관하고있는바이너리파일이다. 최초의컨트롤파일은 Tibero RDBMS 를설치할때함께생성된다. 최초로설정된컨트롤파일에대한정보는 $TB_SID.tip 파일에저장된다. 컨트롤파일은 Tibero RDBMS 에의해서만생성과갱신을할수있다. 단, DBA 가컨트롤파일의내용을조회하거나갱신할수는없다. 컨트롤파일에는다음과같은정보가포함되어있다. 최근체크포인트를수행한타임스탬프체크포인트등이있다. Tibero RDBMS 에서는데이터베이스를다시기동할때마다먼저컨트롤파일을참조한다. 참조하는절차는다음과같다. 1) 테이블스페이스와데이터파일의정보를얻는다. 2) 데이터베이스에실제저장된데이터사전과스키마객체의정보를얻는다. 3) 필요한데이터를읽는다. Tibero RDBMS 에서컨트롤파일은같은크기, 같은내용의파일을두개이상유지하기를권장한다. 이는 Redo 로그멤버를다중화하는방법과유사하다. 같은로그그룹내의로그멤버를서로다른디스크에설치하는것처럼, 컨트롤파일의복사본을서로다른디스크에저장하는것이좋다. 이는데이터베이스의시스템성능과안정성을유지하는데매우필요하다. 8

9 예를들어, 한디스크에컨트롤파일의복사본이존재하는경우문제가발생할수있다. 만약이디스크를영구적으로사용할수없게된다면, 컨트롤파일은복구할수없는상태가된다. 따라서컨트롤파일은 Redo 로그와연관하여배치하는것이좋다. 가 ) 주의컨트롤파일은데이터베이스를운영할때매우중요한파일이므로컨트롤파일이손상되지않도록주의해야한다. 다음은컨트롤파일을다중화한그림이다. 손상될경우를대비하는작업이다. 아카이브에사용되는저장장치로는대용량하드디스크또는테이프등이있다. Tibero RDBMS 에서는 Redo 로그를사용하지않을때나, 데이터베이스와함께사용중인경우에도동시에아카이브를수행할수있다. Redo 로그를사용하는중에아카이브를하려면로그아카이브모드를 ARCHIVELOG 로설정해야한다. 가 ) ARCHIVELOG 모드의설정 ARCHIVELOG 모드는마운트 (MOUNT) 상태에서다음의 SQL 문장을실행하여설정할수있다. SQL> ALTER DATABASE ARCHIVELOG; ARCHIVELOG 모드에서는아카이브가되지않은로그 그룹은재사용되지않는다. 예를들어, 로그그룹 1 를 전부사용하고나서로그그룹 2 를사용하려고할때, 그림 3.6 컨트롤파일의다중화위 [ 그림 3.6] 에서보듯이, 디스크마다하나의로그그룹에여러로그멤버를배치한것처럼컨트롤파일의복사본을같은위치에배치한다. Tibero RDBMS 에서는컨트롤파일로부터정보를확인할때여러복사본중에서하나만읽는다. 그리고테이블스페이스의변경등의이유로컨트롤파일을갱신해야하는경우에는모든복사본을동시에갱신한다. 컨트롤파일의갱신을유발하는 SQL 문장은모두 DDL 문장이다. DDL 문장의특징은하나의문장이하나의트랜잭션이된다는것이다. 따라서, DDL 문장을실행하면바로커밋되며, 갱신된내용은바로디스크에반영된다 Archive Log File Redo 로그에저장된내용을제 3 의저장장치에반영구적으로저장할수있다. 이러한과정을아카이브 (Archive) 라고하며, 디스크상에로그파일이 로그그룹 2 이전에저장된로그가아카이브가되지않은경우에는로그그룹 2 가아카이브가될때까지대기해야한다. 이때읽기전용이아닌모든트랜잭션은실행이잠시중지된다. 로그그룹 2 가아카이브가되면바로활성화되어로그를저장한다. 또한, 잠시중지되었던트랜잭션도모두다시실행된다. DBA 는이러한일이발생하지않도록로그그룹의개수를충분히설정해야한다. 나 ) NOARCHIVELOG 모드의설정 Redo 로그를사용하는중에아카이브를수행하지않으려면로그아카이브모드를 NOARCHIVELOG 로설정해야한다. NOARCHIVELOG 모드에서는아카이브가수행되지않으며, 로그그룹을순환적으로활성화하기전에아카이브되기를기다리는경우가발생하지않으므로데이터베이스의성능이향상된다. 하지만, 데이터베이스와 Redo 로그자체에문제가발생하여동시에복구할수없는경우라면, 이전에커밋된 9

10 트랜잭션에의해갱신된데이터를모두잃어버리게된다. 따라서, NOARCHIVELOG 모드에서는복구가제한적으로 이루어지므로항상데이터베이스전체를백업할것을 권장한다 Tibero RDBMS 의프로세스는크게클라이언트 프로세스 (Client Process), 서버프로세스 (Server Process) 로나눌수있다. 서버프로세스는다시 4. 티베로프로세스 (Tibero Process) 데이터베이스의목적은물리적저장공간에저장된데이터를실시간으로여러명의사용자가동시에접근하여검색하거나변경하는작업을효율적으로하기위함이다 내부적으로워킹프로세스 (Working Process 또는 Foreground Process), 백그라운드프로세스 (Background Process), 리스너 (Listener) 로나눌수있다. 4.1 클라이언트프로세스 (Client Process) 클라이언트프로세스는세션 (session) 이라는개념을 그림 4.1 Tibero RDBMS 의프로세스구조 사용하여서버의프로세스와통신을관리하는역할을 Tibero RDBMS 는대규모사용자접속을수용하는다중프로세스및다중스레드기반의아키텍처를갖추고있다. 다음은 Tibero RDBMS 의프로세스구조를나타내는그림이다. 담당하고있습니다. 세션 (session) 은클라이언트프로그램의 Tibero RDBM 서버와의연결을의미하여클라이언트프로그램이데이터베이스에접속한시각부터데이터베이스에연결을끊을때까지지속된다. 10

11 워킹스레드 (Working Thread) 는클라이언트 4.2. 워킹프로세스 (Working Process 또는 Foreground Process) 워킹프로세스 (Working Process) 는클라이언트프로세스 (Client Process) 와실제로통신하며사용자의요청을처리하는프로세스이다. 티베로는다수의클라이언트프로세스와연결을수용하기위하여여러개의워킹프로세스를서버기동시에만들고시작한다. 이프로세스의개수는 WTHR_PROC_CNT 초기화파라미터로조절할수있으며, 일단 Tibero RDBMS 가기동된뒤에는변경할수없다. 워킹프로세스의개수가많아질수록사용하는시스템의 CPU 와메모리자원을많이사용하게된다. 따라서동시사용자수와시스템환경을고려하여적절한값을설정해야한다. Tibero RDBMS 는효율적인리소스의활용을위해스레드 (Thread) 기반으로작업을수행한다. 하나의워킹프로세스내에는하나의컨트롤스레드와다수의워킹스레드가존재한다 컨트롤스레드 (Control Thread) 워킹프로세스 (Working Process) 마다하나씩존재하며다음과같은역할을담당한다. Tibero RDBMS 가기동될때초기화파라미터에설정된수만큼워킹스레드를생성한다. 클라이언트의새로운접속요청이오면현재유휴한워킹스레드에클라이언트의접속을할당한다. 워킹스레드가일하고있는중에클라이언트로부터의문장취소 (Statement Cancel) 요청을대신처리해준다. 워킹스레드나감시프로세스로부터온각종시그널처리를담당한다. 프로세스 (Client Process) 와 1:1 로통신하며, 클라이언트프로세스가보내는메시지를받아처리하고그결과를돌려준다. 주로 SQL 파싱, 최적화수행등 DBMS 가하는작업대부분이워킹스레드에서일어난다. 워킹프로세스하나에존재하는워킹스레드개수는초기화파라미터 _WTHR_PER_PROC 로조절할수있으며, 일단 Tibero RDBMS 가기동된뒤에는변경할수없다. 따라서동시사용자수와시스템환경을고려하여적절한값을설정해야한다. 워킹스레드는하나의클라이언트와접속하므로 Tibero RDBMS 에동시접속이가능한클라이언트수는 WTHR_PROC_CNT * _WTHR_PER_PROC 이다. Tibero RDBMS 는세션멀티플렉싱 (Session Multiplexing) 을지원하지않으므로하나의클라이언트접속은곧하나의세션과같다. 그러므로최대세션이생성될수있는개수는 WTHR_PROC_CNT * _WTHR_PER_PROC 를연산한값과같다. 워킹스레드는클라이언트와접속이끊긴다고해도없어지지않으며, Tibero RDBMS 가기동될때생성된이후부터종료할때까지계속존재하게된다. 이러한구조에서는클라이언트와접속을빈번하게발생하더라도매번스레드를생성하거나제거하지않으므로시스템의성능을높일수있다. 반면실제클라이언트의수가적더라도초기화파라미터에설정된개수만큼스레드를생성해야하므로운영체제의리소스를계속소모하는단점은있으나, 운영체제대부분이유휴한스레드하나를유지하는데드는리소스는매우적으므로시스템을운영하는데는별무리가없다 워킹프로세스와워킹스레드의개수 워킹스레드 (Working Thread) 서버기동시에만들어지는워킹프로세스와워킹 스레드의개수는초기화파라미터 WTHR_PROC_CNT 와 11

12 _WTHR_PER_PROC 를이용하여관리자가직접설정할수도있다. 하지만최대허용세션개수를의미하는초기화파라미터 MAX_SESSION_COUNT 를이용하여설정할수도있다. 이경우워킹프로세스당워킹스레드는 10 개로고정하고 MAX_SESSION_COUNT 값에따라서워킹프로세스개수가결정된다. 따라서 MAX_SESSION_COUNT 값을 200 으로설정할경우 20 개의워킹프로세스가생성되고각각의워킹프로세스내 10 개의워킹스레드가생성된다. 그래서최대 200 명의사용자접속을수용하여 200 개세션이동시에존재할수있다. 초기화파라미터 MAX_SESSION_COUNT 도 Tibero RDBMS 가기동된뒤에는변경할수없다. 따라서동시사용자수와시스템환경을고려하여적절한값을설정해야한다 Tier 구성현재 Tibero RDBMS 는다수의프로세스가서로세션정보를공유하면서클라이언트의요청을처리하는자체공유서버구성 (Shared Server Configuration) 은지원하지않는다. 시스템의 CPU 나메모리자원을고려하지않고너무많은수의워킹스레드가동시에작업을수행하려고할때운영체제에과도한부하를일으켜시스템성능이크게저하될수있다. 그러므로대규모시스템을구축할경우에는 Tibero RDBMS 와클라이언트의애플리케이션프로그램사이에미들웨어를설치하여 3-Tier 구조로시스템을구축할것을권장한다 백그라운드프로세스 (Background Process) 백그라운드프로세스 (Background Process) 는사용자와직접적인연결은없으나워킹프로세스나다른백그라운드프로세스의요청할때나정해진주기에따라특정작업을한다. 감시프로세스, 시퀀스프로세스, 로그쓰기프로세스, 체크포인트프로세스, 데이터블록쓰기프로세스등이있다 감시프로세스 (MTHR: Monitor Thread) 감시프로세스의영문약자를보면프로세스가아닌스레드로나타나있지만, 실제로는하나의독립된프로세스이다. 리스너를제외하고 Tibero RDBMS 가기동할때최초로생성되며, Tibero RDBMS 가종료하면맨마지막에프로세스를끝마친다. Tibero RDBMS 가기동할때다른프로세스를생성하거나주기적으로각프로세스의상태를점검하는역할을담당한다. 프로세스의상태를감시하다가만약특정백그라운드프로세스가죽은경우, 서버전체를강제종료시킨다. 특정워킹프로세스가죽는경우초기화파라미터 _TBSVR_STABILITY_LEVEL 에따라처리방법이달라진다. _TBSVR_ 처리방법 STABILITY_LEVEL 0 서버강제종료 1 죽은워킹프로세스의자원정리죽은워킹프로세스의자원 2 정리하고재생성 시퀀스프로세스 (AGENT 또는 SEQW: Sequence writer) 시퀀스캐시 (sequence cache) 의값을디스크에저장하고관리하는역할을담당하고있다. 그외에시스템유지를위해주기적으로처리해야하는 Tibero RDBMS 내부의작업을담당한다. 다음은 SEQW 가주기적은하는일들이다. 실행시켜야할 Job 체크하여워킹스레드에게시킴 dd_cache, pp_cache 내부구조체 gargabe collection 프로세스간의데드락 (deadlock) 상태체크 메모리조절 (Memory Tuner) 관련체크 XA Timeout 체크 Undo 통계자료수집, Undo offline 체크 12

13 인덱스 Auto coalesce 체크하여워킹스레드에게시킴 TAC 로드밸런스정보업데이트 ASH sampling 주기를체크하여워킹스레드에게시킴 로그쓰기프로세스 (LGWR 또는 LOGW: Log writer) 리두로그버퍼는 DML 등에의해변경된데이터베이스블록의변경사항을리두로그레코드로기록하는메모리공간이며그크기는초기화파라미터 LOG_BUFFER 에의해결정된다. 로그쓰기프로세스는리두로그버퍼의있는변경사항을디스크의온라인리두로그파일에기록하는프로세스이다. 따라서로그파일에는데이터베이스의데이터에대한모든변경사항을저장하고있으며빠른트랜잭션처리와복구를위해사용된다. 리두로그버퍼의내용을리두로그파일에쓰는단위는 OS 에따라다를수있으며초기화파라미터 _LOG_BLOCK_SIZE 를이용하여사용자가직접설정할수있다. 리두로그버퍼의내용을리두로그파일에쓰는시점은아래와같다. 버퍼의내용을파일에쓴지 3 초가지났을경우 리두로그버퍼가 1/3 이상사용중인경우 리두로그버퍼가 1M 이상사용중인경우 트랜잭션이 COMMIT 된경우트랜잭션이커밋된겨우커밋레코드도리두로그버퍼에기록되며동시에버퍼내용이디스크의리두로그파일에쓰여진다. 그리고리두로그버퍼의변경사항은 FIFO 순서로디스크에쓰여진다. 따라서커밋레코드가디스크에쓰여질때, 해당트랜잭션과관련된모든리두로그레코드가디스크에기록된다. 하지만데이터베이스버퍼캐시의실제변경된데이터베이스블록은나중에데이터블록쓰기프로세스에의해서디스크에쓰여진다. TSN 은데이터베이스내에서특정시점에커밋된버전을 나타내는데, 각각의커밋된트랜잭션마다유일한 TSN 이부여된다. 안정성을타협하고트랜잭션처리성능을최대로높이기위해서초기화파라미터 COMMIT_FLUSH_REQUEST 나 COMMIT_FLUSH_WAIT 를사용할수도있다. COMMIT_FLUSH_REQUEST 를 N 으로할경우, commit 과함께리두로그를바로즉시파일로쓰지않는다. COMMIT_FLUSH_WAIT 를 N 으로할경우, 리두로그를파일로쓸때쓰는작업이완료되는것을확인하지않는다 로그기록기프로세스 (LOGA: Log Archiver) 데이터베이스의데이터에일어나모든변경내역을완벽하게기록하기위해서리두로그파일바꿀때아카이브로그로복사하는역할을하는프로세스이다. 워킹스레드들이 DML 관련작업을하면서데이터베이스데이터블록들에적용한모든변경벡터 (change vector) 는리두로그버퍼에기록한다. 그리고이리두로그버퍼의리두레코드들은 LOGW 에의해서온라인리두로그파일에쓰여진다. 온라인리두로그파일은한정된크기와개수를가지고있으므로다쓰면가장예전에쓴리두로그레코드를덮어써야한다. 덮어쓰는데까지걸리는시간은온라인리두로그파일의크기와개수, DML 워크로드에따라결정된다. 이것은온라인리두로그파일이가장최근의 DML 관련변경사항만을저장하고있음을의미한다. 모든변경내역을완벽하게기록하기위해서기존리두로그파일을재사용하기위해서덮어쓰기전에그리두로그파일을아카이브로그 (archive log) 로복사해야한다. 이역할을 LOGA 프로세스가담당하고있다. 특정시점에데이터베이스전체백업을하고아카이브로그를남겼다면, 그이후로데이터베이스의데이터가피해를입더라도백업데이터에아카이브로그와온라인리두로그파일를적용하여데이터를복구하는것이가능하다 체크포인트프로세스 (CKPT: Checkpoint process) 13

14 체크포인트는주기적으로혹은클라이언트의요청에따라메모리에있는변경된모든데이터블록을디스크에기록하는작업이다. Tibero RDBMS 에장애가발생하면이를복구하기위해걸리는시간이한계수치를넘지않도록예방하는효과가있다. 이러한체크포인트를관리하는프로세스가체크포인트프로세스이다. 체크포인트주기는초기화파라미터 LOG_CHECKPOINT_TIMEOUT ( 기본값 1800 초 ) 에의해서결정된다. 또한초기화파라미터 LOG_CHECKPOINT_INTERVAL 를사용자가직접설정할경우, 데이터베이스버퍼캐시의수정된블록의개수가 LOG_CHECKPOINT_INTERVAL 를넘으면체크포인트가일어난다. 다음은클라이언트의새로운접속요청이이루어지는순서이다. 1. 현재유휴한워킹스레드가있는워킹프로세스를찾아서클라이언트의접속요청 (1) 을한다. 2. 이때 File descriptor 와함께할당되므로, 클라이언트는서버의내부동작과상관없이마치처음부터워킹스레드에접속한것처럼동작하게된다. 3. 리스너의요청을받은컨트롤스레드 (CTHR: control thread) 는자기자신에속한워킹스레드의상태를검사 (2) 하여현재유휴한워킹스레드에클라이언트의접속을할당 (3) 한다. 4. 할당된워킹스레드는클라이언트와인증절차를 데이터블록쓰기프로세스 (DBWR 또는 BLKW: Data block writer) 데이터블록쓰기프로세스는데이터베이스버퍼캐시의수정된데이터베이스블럭를디스크로쓰는역할을맡고있다. 워킹스레드들이요구하는여유버퍼를미리확보하기위하여 3 초에한번씩 LRU 알고리즘을이용하여수정된데이터베이스블럭을디스크에쓴다. 또한체크포인트프로세스가데이터베이스버퍼캐시의수정된데이터블록을디스크에쓸것을요청하면모든수정된블록을디스크에쓴다. 데이터블록쓰기프로세스는성능향상을위하여 CPU 코어개수에비례하여여러개의프로세스가만들어져함께일을할수도있다. 필요한경우초기화파라미터 DBWR_CNT 를이용하여사용자가직접프로세스개수를설정할수도있다 리스너 (Listener) 리스너는클라이언트의새로운접속요청을받아이를유휴한워킹프로세스에할당한다. 즉, 클라이언트와워킹프로세스간의중계역할을담당하며, 이는별도의실행파일인 tblistener 를사용하여작업을수행한다. 거친후세션을시작 (4) 한다 서버프로세스생성순서 tbboot 명령을 DB 관리자가내린경우, 가장먼저리스너프로세스를만든다. 리스너프로세스로부터 MTHR 프로세스를만들고, MTHR 프로세스가 (WTHR_PROC_CNT +1) 만큼의워킹프로세스와백그라운드프로세스를만든다. 워킹프로세스가하나더추가된이유는관리자의서버종료명령처리등특별한기능을따로처리하기위해서이다. 특별한용도로만세션워킹프로세스가존재하기때문이다. 각각의워킹프로세스는 _WTHR_PER_PROC 만큼의워킹스레드를만든다. 모든백그라운드프로세스와워킹스레드들이제대로생성된것이확인되면리스너가사용자의접속요청을받아들이고워킹스레드들이새로운세션을시작할수있다 워킹프로세스와백그라운드프로세스작동과정다음은워킹프로세스와백그라운드프로세스들이서로연관되어작동하는모습을보여주고있다. 14

15 워킹스레드는클라이언트나 SEQW 가요청하는작업을수행하다가트랜잭션커밋요청이들어오면 LOGW 에게리두로그버퍼에있는내용을로그파일에쓰라고 (log flush) 명령을한다. 워킹스레드에게직접체크포인트요청이들어오거나로그쓰기프로세스 (LOGW) 가로그스위치 (log switch) 를해야할상황이오면체크포인트 5. 티베로메모리 (Tibero Memory) Tibero RDBMS 에서프로세스들이데이터를관리하고질의를처리하기위해서두가지종류의메모리를사용하며아래그림과같은공유메모리 (Shared Memory) 와시스템메모리 (System Memory) 로나뉜다. 프로세스에게체크포인트 (CHECKPOINT) 를요청한다. 체크포인트프로세스는데이터블록쓰기프로세스 (BLKW) 에게현재버퍼캐시의수정된블록을전부디스크에쓰라고요청한다. 로그쓰기프로세스 (LOGW) 는로그스위치 (log switch) 가필요할경우 LOGA 에게아카이브로그 (archive log) 를남기도록요청한다. 그림 5.1 워킹프로세스와백그라운프로세스의작동과정 15

16 인버퍼로나뉜다. 유휴버퍼는유휴리스트 (free list) 로 5.1. 공유메모리 (Shared Memory) 구조공유메모리는 Tibero RDBMS의워킹프로세스들과백그라운드프로세스간에공유해야할메모리로서데이터베이스의데이터나내부공유제어구조체를담고있다. Tibero RDBMS는기동시에고정된크기의공유메모리 (shared memory) 를 OS로부터할당을받아서사용하고서버가종료시에해제를한다. 전체공유메모리 (shared memory) 의크기는초기화파라미터 TOTAL_SHM_SIZE로설정해준다. 이러한공유메모리는기동시에고정된용도로사용되는고정 (fixed) 영역과운영중에쓰이는공유풀 (shared pool) 영역으로나뉜다. 각영역의정확한크기는 v$sga의 FIXED MEMORY 와 SHARED POOL MEMORY 항목을통하여확인할수있다 고정 (Fixed) 영역고정 (fixed) 영역은버퍼캐시 (buffer cache) 영역과그밖의영역으로나뉜다. 버퍼캐시 (buffer cache) 영역버퍼캐시는디스크로부터읽어들여메모리에올라온데이터베이스의데이터블록들을담는버퍼들구성되어있다. 이러한버퍼들은유휴 (free), 수정 (dirty), 사용중 (pinned) 관리되어필요할때디스크로부터읽어들인데이터블록을담는다. 수정된 (dirty) 버퍼는데이터블록의값이수정되었지만아직디스크에쓰지않은버퍼로서 LRU 리스트로관리되어 free 버퍼가부족할시에최근에워킹스레드들로부터가장덜접근된수정된 (dirty) 버퍼가디스크에쓰여지게된다. 사용중인 (pinned) 버퍼는현재특정워킹스레드가쓰고있는버퍼로서유휴버퍼나수정된버퍼와달리다른데이터블록에위해서쓰이지않도록보호가된다. 버퍼캐시 (buffer cache) 의영역의크기는 DB_CACHE_SIZE로설정할수있으며, 특별한설정을하지않으면일반모드에서는 TOTAL_SHM_SIZE의 2/3, TAC 모드에서는 TOTAL_SHM_SIZE의 1/2 로기본값이설정된다. 버퍼캐시 (buffer cache) 영역의정확한크기는 v$sga의 Database Buffers 항목을통하여확인할수있다. redo log buffer 영역버퍼캐시 (buffer cache) 를제외한영역은 redo log buffer 과전역변수를위한공간으로사용된다. 리두로그버퍼는 DML에의한데이터베이스의데이터의변경사항에저장하고있다. 이정보는장애로인하여데이터베이스복구가필요한상황에서변경사항을재적용하는데쓸수있 16

17 1M 이상의공유풀영역이확보가되지않으면기동이안 다. 리두로그버퍼의데이터는 LOGW 에의해서온라인 된다. 리두로그파일에쓰여진다. 리두로그파일의크기는초 기화파라미터 LOG_BUFFER에의해서결정된다. 전역변수를위한영역전역변수를위한공간의크기는기동시에정해지며전체워킹쓰레드개수에비례하나그리크지않다. 이영역의정확한크기는 v$sga 항목중에서 FIXED MEMORY - Database Buffers Redo Buffer 로확인할수있다 공유풀 (Shared Pool) 영역공유풀영역은정해진크기내에서내부 allocator가동적으로할당하여쓰는영역이다. 공유풀영역은워킹스레드간에쿼리에대한 Physical Plan 정보나 Data Dictionary 정보를공유하기위해서주로쓰인다. 또한스레드간의공유자원을보호하기위한구조체를위하여쓰기도한다. 그밖에쓰레드간에공유해야할다양한종류의동적구조체를위하여쓰인다. 공유풀영역은전체 shared memory 크기 (TOTAL_SHM_SIZE) 에서 fixed 영역을뺀나머지영역을차지하게된다. 현재 Tibero RDBMS에서는세션하나당 Shared Memory 크기설정방법현재 Tibero RDBMS에서는 shared memory 크기를운영중에동적으로늘릴수있는기능을지원하고있지않다. 따라서 buffer cache와 shared pool 사용패턴을분석하여전체 shared memory 크기 (TOTAL_SHM_SIZE) 를알맞게정하여야한다. 먼저 buffer cache의크기는주요 workload를돌려본후 APM 리포트의 Buffer Cache Hit율을보고서판단을하면된다. Buffer Cache Hit율이 90 % 이상이라면 buffer cache의크기줄여도좋다. buffer cache hit 율이 90 % 이하라면 buffer cache 크기를늘려주어야한다. buffer cache의크기는 DB_CACHE_SIZE를통해서직접설정하거나 TOTAL_SHM_SIZE를통해서간접적으로설정할수있다 (TOTAL_SHM_SIZE의 2/3 또는 1/2). shared pool 메모리의크기는 workload를돌려본후 v$sga의 SHARED POOL MEMORY 항목의사용률을보고서판단을하면된다. 평균 shared pool 사용률이너무낮으면 shared pool 크기를줄이는것이좋다. 반대로 17

18 평균 shared pool 사용률이너무높으면 shared pool 크 기를늘리는것이좋다. 그리고 shared pool memory를많이사용하여일시적으로메모리가부족하면 ERROR_OUT_OF_SHP(-3002) 에러가발생할수있는데이런경우 alter system flush shared_pool 명령을이용하여 shared pool 공간정리하거나재기동한후에 shared pool 크기를늘려주는것이좋다. shared pool 크기는 DB_CACHE_SIZE를통해서간접적으로만설정할수있다. 제약사항으로는세션당최소 1M 이상의 shared pool 영역이확보가되지않으면부팅이안된다. 즉, 전체워킹쓰레드개수 (MAX_SESSION_COUNT) 가 100이라면최소한 100M 이상의 shared pool 영역의확보되어야한다 System Memory 크기설정방법티베로가워킹스레드들이 SQL 수행하면서할당할수있는전체시스템메모리크기는 EX_MEMORY_HARD_LIMIT를통해서제한을할수있다. EX_MEMORY_HARD_LIMIT은 TOTAL_SHM_SIZE의 20% 로기본값이설정되어있다. 대부분의경우는이설정을그대로사용한다. 예를들어 TOTAL_SHM_SIZE가 4096M 라면 EX_MEMORY_HARD_LIMIT = 4096 * 0.2 = 819.2M 로설정이된다. 워킹쓰레드가쿼리수행에사용하는시스템메모리가부족하면내부적으로디스크이용한쿼리수행을하게되므로쿼리처리성능이떨어질수있다. 따라서시스템메모리 를많이사용하는경우에는 EX_MEMORY_HARD_LIMIT 5.2. 시스템메모리 (System Memory) 구조 Tibero RDBMS의시스템메모리 (System Memory) 는각각의프로세스들이다른프로세스와공유하지않고프로세스내에서만쓰는메모리다. Tibero RDBMS의시스템메모리 (System Memory) 는부팅시에 malloc으로기본점유되는고정 (fixed) 영역과내부 allocator에의해서관리되는 allocator 영역으로나뉜다. Fixed 영역은 signal stack, thread stack, event map 등의정보를담기위한영역으로서부팅시에고정된크기로잡아두고시작하여그크기가워킹쓰레드개수 크기를늘려주는것이좋다. 예를들어, Sort 와같은연산을많이사용하는 workload 는시스템메모리사용량이높다. 이러한 workload 를돌리고난후에 APM 리포트를살펴보면 In- Memory Sort 의비율이낮아지고 v$pgastat 의 ALLOCATED pga memory 와 USED pga memory (from ALLOCATED) 값이높아져서 EX_MEMORY_HARD_LIMIT 값과비슷해질수가있다. 그런경우 EX_MEMORY_HARD_LIMIT 크기를늘려주면성능향상에도움이된다. (MAX_SESSION_COUNT) 에비례한다. 정확한크기는 v$pgastat의 FIXED pga memory 항목을통하여확인할수있다. Allocator 영역은티베로내부 allocator에의해서관리되는메모리영역으로서운영중에필요한메모리를미리할당을받아두고 allocator의관리하에워킹스레드가그영역을할당받아쓰고있다. Allocator가관리하는전체 system memory의크기는필요에따라서동적으로변할수있다. Allocator가관리하는전체크기 system memory 의크기는 v$pgastat의 ALLOCATED pga memory 항목를통해서확인할수있으며, 실제워킹쓰레드가쓰고있는메모리는 v$pgastat의 USED pga memory (from ALLOCATED) 항목을통해확인할수있다. 18

19 c Copyright TIBERO All Rights Reserved. 본문서에서제공하는기술적또는상업적정보에대한저작권은 TIBERO 에있으며, 본문서는 TIBERO 의허락없이타인에의해복제또는다른언어, 수단, 목적으로변형되거나배포될수없다. 본문서는오로지정보의제공만을목적으로하고, 이로인한계약상의직접적또는간접적책임을지지아니하며, 본문서상의내용은구두로제공되거나법적또는상업적인특정한조건을만족시키는것을보장하지는않는다. 본문서의내용은제품의업그레이드나수정에따라그내용이예고없이변경될수있으며, 내용상의오류가없음을보장하지아니한다. TIBERO 상표는한국및기타다른나라에서 TIBERO 의상표로등록된것이다. 기타다른회사명또는상표는다른권리자의상표혹은서비스표일수있다. 문서번호넣으실곳 19