유저 / TIP 설정

1. 관제 데이터베이스 유저 설정

SysMaster DB 8.2에서 관제 데이터베이스 등록 시 유저 정보를 입력하게 된다. 기존에 생성된 유저를 사용할 수 있고, 새로운 유저를 생성해 사용할 수도 있다. 이때 유저에게 필요한 권한은 CONNECT, ALTER SYSTEM, SELECT_CATALOG_ROLE이다. 유저 생성 및 권한 부여는 SYS 계정에서 아래 DDL 및 DCL 문을 사용한다.

CREATE USER [username] IDENTIFIED BY [password];
GRANT CONNECT, ALTER SYSTEM, SELECT_CATALOG_ROLE TO [username];

추가로 TPR Report, ASH Report 기능을 사용하려면 아래 DCL 문을 사용하여 관련 권한을 부여해야 한다.

GRANT EXECUTE ON SYS.DBMS_TPR TO [username];
GRANT EXECUTE ON UTL_TPR TO [username];

SysMasterDB 8.2는 관제 데이터베이스에 테이블 생성이나 데이터 적재를 하지 않는다.

2. 관제 데이터베이스 TIP 설정

관제 데이터베이스에서 SQL 수행 시 생성되는 스탯 정보를 수집하기 위해 'SQL_STAT_HISTORY', 'SQL_STAT_HISTORY_THRESHOLD', 'SQL_STAT_HISTORY_QSIZE' 파라미터를 tip 파일에 추가한다. 각 파라미터에 대한 설명은 다음과 같다.

파라미터	설명	권장 값	동적 수정
SQL_STAT_HISTORY	SQL 실행 정보 생성 여부	Y (필수)	불가능
SQL_STAT_HISTORY_THRESHOLD	SQL 실행 정보 생성 기준 실행 시간 임계치 (예: 100msec 이상 수행된 SQL에 대해서만 실행 정보 생성)	100	가능
SQL_STAT_HISTORY_QSIZE	각 세션마다 저장할 SQL 실행 정보 개수 (1 ~ 10000 사이의 정수)	10	불가능

1. SQL_STAT_HISTORY가 Y인 경우 각 세션에서는 SQL_STAT_HISTORY_THRESHOLD 이상 수행된 SQL 실행 정보를 SQL_STAT_HISTORY_QSIZE 크기의 큐에 저장한다.

2. 큐가 모두 차있을 경우 가장 오래된 SQL 실행 정보부터 큐에서 지운다.

3. TPM Agent에서는 SQLTRACE_FREQ(ms)마다 SQL 실행 정보를 수집하므로,

SQLTRACE_FREQ / SQL_STAT_HISTORY_THRESHOLD ≤ SQL_STAT_HISTORY_QSIZE

로 SQL_STAT_HISTORY_QSIZE를 설정해야 정상적인 상황에 유실되는 정보가 없다. QSIZE의 경우 위에 언급되어 있듯 개수이므로 정수 값이며, 만약 나누기의 결과가 0.01과 같은 소수일 경우 부등호로 인하여 0.01 이상의 정수인 1이상으로 QSIZE를 설정하면 유실이 없다. FREQ의 범위와 QSIZE의 범위는 매뉴얼에 기입된 것을 참고한다.

추가로 부하 상황에서는 권장 값으로 QSIZE를 설정하였더라도 수집 누락이 발생할 수 있는데, 예를 들어 Tibero에 부하가 발생하여 CPU 자원을 TPM Agent가 사용하지 못하게 되는 상황이 발생하면 수집 주기가 예기치 못하게 늘어나게 된다. 만약 기존에 1000ms 마다 수집을 하고 있었는데, CPU 자원을 사용하지 못하여 몇 초간 수집을 2000ms 마다 진행하게 될 수 있다. 이럴 경우 권장 값으로 설정하였더라도 SQL Trace 수집에 누락이 발생할 수 있다. 이럴 경우를 대비하여 권장 값보다 더 많은 QSIZE를 할당하여 대비할 수 있으나, 그만큼 Tibero의 메모리를 사용하게 되므로 상황에 맞게 권장 값 기반으로 QSIZE를 설정하면 된다.

SQL_STAT_HISTORY_QSIZE와 데이터베이스 내 총 세션 개수에 정비례하여 공유 메모리의 사용량이 증가한다. 따라서 SQL_STAT_HISTORY 를 N에서 Y로 변경하는 경우, 증가할 메모리 사용량을 TOTAL_SHM_SIZE 에 더해주어야 한다. 데이터베이스의 안정성을 위해 (증가할 메모리 사용량) + TOTAL_SHM_SIZE 결과에 3~5% 가량을 추가로 더해주어 최종 TOTAL_SHM_SIZE 값으로 사용하는 것을 권장한다.

그리고 TOTAL_SHM_SIZE 로 인해 자동으로 값이 변경되는 DB_CACHE_SIZE의 경우, 이로 인한 영향도를 최소화하기 위해 SQL_STAT_HISTORY 가 N이었던 시점의 값으로 설정해주어야 한다.

SQL_STAT_HISTORY_QSIZE=1 인 경우 한 세션에서 사용하는 SQL STAT HISTORY 관련 메모리는 약 231,000 bytes 이기에, 해당 값에 총 세션 수 (MAX_SESSION_COUNT + WTHR_PER_PROC)(MGWP와 FGWP를 모두 포함한 값) 와 SQL_STAT_HISTORY_QSIZE 를 곱하는 식으로 총 사이즈를 계산할 수 있다.

MAX_SESSION_COUNT=500, WTHR_PER_PROC=10, SQL_STAT_HISTORY_QSIZE=10, TOTAL_SHM_SIZE=3500M의 경우, SQL STAT_HISTORY=Y 시 약 231,000 × ( 500 + 10 ) × 10 = 1,178,100,000 bytes = 1,123.52 MB 사용한다.

TOTAL_SHM_SIZE 의 경우, ( 3500 + 1124 ) × 1.03 ~ 1.05 = 4,763 ~ 4,855 MB 로 설정한다.

3. libtpmstat.so 라이브러리

TPM Agent에서 Tibero로부터 정보를 수집하기 위해서는 libtpmstat 라이브러리가 필요하다. 관제 데이터베이스에 279651 패치가 적용되어 libtpmstat 라이브러리가 있는 경우에는 Tibero 환경 변수 설정 과정을 통해 해당 라이브러리를 사용할 수 있다.

만약 관제 데이터베이스에 libtpmstat 라이브러리가 없는 경우에는 해당 데이터베이스에 맞는 라이브러리를 추가로 배포해야 한다. 이때 배포된 libtpmstat.so 파일을 TPM Agent 디렉터리로 이동시킨 후 TPM Agent 라이브러리 경로 설정을 통해 해당 라이브러리를 사용할 수 있다.

libtpmstat.so 라이브러리 파일의 배포를 위하여 관제 데이터베이스 패치 목록과 정확하게 동일한 패치가 되어있는 관제 데이터베이스 빌드를 통하여 libtpmstat.so 빌드를 해야 한다. 예를 들어, Tibero 6에 [1번 패치], [2번 패치], [3번 패치] 세 개의 패치가 되어 있는 곳과 [1번 패치], [3번 패치] 두 개의 패치가 되어 있는 곳이 있다면, [1번 패치], [2번 패치], [3번 패치]가 적용된 Tibero에서 빌드한 libtpmstat.so 파일과 [1번 패치], [3번 패치]가 적용된 Tibero에서 빌드한 libtpmstat.so 파일 두 개 모두 각각 빌드해서 배포해야 한다.

추가로 libtpmstat.so 라이브러리 빌드 시, Tibero 바이너리 빌드 시 적용하였던 모든 빌드 플래그들을 동일하게 적용하여 라이브러리 빌드를 진행하여야 한다. 예를 들어 NET_BACKUP 빌드 플래그를 적용하여 Tibero 바이너리를 빌드하여 배포했다면, 라이브러리 배포 시에도 해당 플래그를 넣고 libtpmstat.so 라이브러리 빌드를 진행하여야 한다.