콘텐츠로 이동
≡

Administrator

Developer

Tools

External Tools

16. Altibase 진단 모니터링#

이 장에서는 Altibase 데이터베이스의 운영 상태를 확인하고 분석하는 방법에 대해 설명한다.

Altibase 모니터링#

Altibase 데이터베이스의 운영 상태를 확인하기 위해서 메타 테이블과 성능 뷰를 이용할 수 있다. 메타 테이블과 성능 뷰에 대한 자세한 설명은 General Reference > 3장. Altibase Data Dictionary를 참고한다.

모니터링 해야할 주된 개체는 다음과 같다.

세션과 Statement#

Altibase 운영 중 연결되어 있는 세션에 대한 정보를 성능 뷰로 확인한다. 하나의 세션에는 여러 개의 Statement1가 할당될 수 있다. 세션 속성은 세션 별로 다르게 지정될 수 있다.

세션과 Statement에 대한 정보를 저장하는 성능 뷰는 아래와 같다.

  • V$SESSION

    클라이언트에 대응하는 Altibase 서버에 생성된 세션 정보

  • V$STATEMENT

    현재 Altibase 서버의 세션 별 수행 구문(statement)에 대한 정보

데이터베이스(테이블/인덱스) 정보#

전체 데이터베이스에 대한 정보와 각 테이블스페이스, 테이블 및 인덱스 정보를 아래의 메타 테이블과 성능 뷰로 확인할 수 있다.

  • V$DATABASE

    메모리 데이터베이스의 내부 정보

  • V$TABLESPACES

    테이블스페이스 정보

  • SYS_TABLES_

    테이블 정보

  • SYS_INDICES_

    인덱스 정보

메모리 사용량#

Altibase 서버가 운영하면서 사용하는 메모리 영역 정보를 성능 뷰로 확인한다. 여기에는 메모리 테이블스페이스의 데이터(레코드의 예전 버전 포함) 저장 영역 및 인덱스 저장 영역, 질의 처리를 위한 임시 영역, 세션 정보 저장 공간, 메모리 버퍼 풀 등이 포함된다.

아래의 성능 뷰를 통해서 Altibase 서버의 메모리 사용 정보를 확인할 수 있다.

  • V$MEMSTAT

    Altibase 프로세스의 내부 모듈 별 메모리 사용량

  • V$MEMTBL_INFO

    메모리 테이블 정보

  • V$BUFFPOOL_STAT

    버퍼 풀 관련 통계 정보

이중화 상태#

이중화 상태 정보를 성능 뷰로 확인한다. 이중화 관련 쓰레드(Sender/Receiver)의 상태와 이중화 데이터 전송 상태를 확인할 수 있다.

  • V$REPRECEIVER, V$REPRECEIVER_PARALLEL

    이중화 수신자, 수신 쓰레드들의 정보

  • V$REPSENDER, V$REPSENDER_PARALLEL

    이중화 송신자, 송신 쓰레드들의 정보

Altibase 문제상황 분석#

이 절은 Altibase 운영 중 발생할 수 있는 여러 가지 문제 상황에 대한 점검 사항 및 분석 방법에 대해 설명한다.

실제 운영 환경에서는 다양한 형태의 문제가 발생되며 미리 형태를 예측할 수 없는 경우도 있으므로 반드시 여기서 설명하는 바와 같이 진행되는 것은 아니다. 하지만 예측 가능한 범위 내에서 형태별로 나누어 일반적인 방법을 제시하여 문제 상황에 대처할 수 있는 정보를 제공하고자 한다.

예측 가능한 문제 발생 형태는 크게 다음과 같이 생각해 볼 수 있다.

일반적인 문제상황 분석(PBT, Problem Tracking) 절차는 다음과 같다.

[그림 16‑1] 일반적인 문제 분석 절차

Altibase 관리자 로그란 $ALTIBASE_HOME/trc 디렉터리에 생성되고 유지되는 *.log 이름을 가지는 파일의 텍스트 로그이다. 이 디렉터리에는 다음의 트레이스 로그 파일들이 있다.

  • altibase_boot.log
  • altibase_id.log
  • altibase_mt.log
  • altibase_qp.log
  • altibase_job.log
  • altibase_rp.log
  • altibase_sm.log

Altibase 서버 비정상 종료 및 재구동 실패 문제#

비정상 종료#

Altibase 프로세스가 비정상적으로 종료할 수 있는 원인으로 다음의 것들을 생각해 볼 수 있다.

  • 가용 메모리 부족
  • 시스템 OS 패닉 상태

이러한 경우 관리자 로그의 에러 메시지를 통해 판단이 가능하며 가용 메모리 부족으로 인해 발생하는 경우를 제외하고는 전문 시스템 엔지니어에게 문의해야 한다.

가용 메모리가 부족한 경우라면 관리자 로그에 Memory allocation failed. 혹은 Unable to invoke the shmget() system function와 같이 메모리 할당 관련 시스템 함수 호출 에러 메시지가 기록된다.

이 경우에는 현재 메모리 사용량을 점검해야 하며, 불필요하게 많이 사용하는 부분을 있는지 확인한다. 이러한 부분이 있다면 해당 부분의 메모리를 해제하여 메모리를 확보하고 과도한 메모리 사용의 원인을 찾아 재발을 방지해야 한다. 만일 불필요하게 사용하는 부분이 없다면 시스템 메모리 업그레이드를 고려해야 한다.

메모리 관련 문제는 다음 절에 나올 메모리 사용량의 문제에서 좀 더 자세히 설명하기로 한다.

Altibase 재구동 실패#

Altibase 재구동 시 실패할 수 있는 원인으로 다음의 것을 생각해볼수 있다.

  • 동일한 서비스 포트 번호(PORT_NO 프로퍼티)를 사용하는 Altibase 프로세스가 이미 존재하는 경우

  • 구동 또는 회복 시 필요한 파일이 없거나 파일에 대한 권한이나 파일 시스템 문제로 인해 접근이 안 되는 경우

    관리자 로그에 파일 접근 관련 에러가 발생한다면 해당 파일들(모든 로그 파일, 모든 로그 앵커 파일, 모든 데이터 파일)이 존재하는지를 확인한다. 파일이 존재하고 접근이 가능함에도 불구하고 에러가 발생한다면 파일이 깨졌을 가능성이 있으며 이 경우 데이터베이스를 새로 생성해야 한다.

  • 시스템 리소스 부족

    시스템 리소스 부족으로 인해 시스템 구동이 실패했다면, 여러 가지 시스템 리소스 중 어떤 리소스가 부족한지를 확인하여 실제 시스템에 적재되어 있는 리소스 가용량을 확인하고 시스템 커널 설정을 확인하여 문제가 있는 부분을 해결해야 한다.

    구동 시 주로 문제가 되는 리소스는 메모리 또는 세마포어이다. 메모리 관련 문제의 경우 시스템 커널 설정에서 한 프로세스 당 사용 가능한 메모리의 크기 및 세그먼트의 최대 크기 등을 확인해 봐야 한다.

    IPC 통신을 하려면 세마포어가 필요하며 이는 Altibase 프로퍼티들 중 IPC_CHANNEL_COUNT와 관련이 있다.

Altibase 서버 응답 시간 문제#

Altibase 서버가 실제로 질의를 처리하고 있지만 응답속도가 매우 늦다면 사용자는 서버가 응답이 없다고 오해할 수 있다.

질의 처리 요청 시 응답이 늦는 경우, 이유는 대부분 테이블을 풀스캔하거나 메모리 부족으로 인해 스와핑이 발생하기 때문이다. 이 경우 세션정보 확인과 시스템 정보를 통해 해당 질의가 실제로 수행 중인지를 확인한다. CPU 사용량이 높거나 가용 메모리가 부족하여 스와핑이 발생한다면 실제로 질의를 처리하고 있는 경우일 가능성이 높다.

자세한 설명은 다음에 나올 응용프로그램 및 쿼리 수행시 문제에서 좀 더 자세히 설명하기로 한다.

또 다른 원인으로는 디스크 여유 공간이 부족하여 데이터 변경이나 입력 시 응답이 없는 경우를 생각할 수 있다. 이러한 경우에는 시스템 관리자 로그에 디스크의 여유 공간이 없음을 알리는 에러 메시지가 남게 되며 디스크 공간이 확보되기 전까지 응답이 없는 상태로 남아있게 된다. 디스크 공간 부족으로 인한 문제 해결 방법은 다음에 나올 디스크 사용량의 문제에서 좀 더 자세히 설명하기로 한다.

이 외에 다른 문제로 Altibase 서버가 응답이 없는 상태로 남아있다면 전문 시스템 엔지니어에게 문의해야 한다.

디스크 사용량의 문제#

디스크 가용 공간 부족#

Altibase 운영 중에 디스크 공간이 부족하게 되면 Altibase가 더 이상 데이터 변경작업을 하지 않고 멈춰있는 현상이 발생 할 수 있다. 이런 경우 먼저 여러 파일 시스템 중 어떤 곳의 공간이 부족한지를 확인해야 한다.

Altibase가 운영 중에 사용하는 디스크 공간은 다음과 같다.

  • 로그 파일 저장 공간
  • 각 테이블스페이스 파일 저장 공간

Altibase 운영 중에 액티브 로그와 아카이브 로그가 지속적으로 생성되며, 액티브 로그 파일은 Altibase 프로퍼티 파일(altibase.properties)에서 LOG_DIR프로퍼티에 설정된 디렉터리에 저장이 되고, 아카이브 로그 파일은 데이터베이스가 아카이브 로그 모드로 운영될 경우 자동으로 ARCHIVE_DIR 프로퍼티에 설정된 디렉터리에 저장된다. 액티브 로그의 경우는 디스크 공간이 부족하여 더 이상 로그 저장이 불가능해지면 Altibase가 멈추게 된다. 이런 경우 로그 파일과 로그 앵커파일을 지우게 되면 복구가 불가능해지므로 해당 파일 시스템의 크기를 늘리거나 이외에 다른 불필요한 파일을 삭제하여 디스크 공간을 확보해야 한다. 아카이브 로그의 경우에는 설정 파일의 ARCHIVE_FULL_ACTION 프로퍼티 항목의 설정값이 0인 경우 아카이브 로그를 저장하지 않고 계속 운영되게 되며, 1인 경우 해당 파일 시스템의 가용공간이 확보될 때까지 Altibase가 멈춰있게 된다.

LOG_DIR 프로퍼티에 지정된 디렉터리에 로그 파일의 개수가 많아져 로그 저장 공간이 부족해 진 경우 먼저 관리자 로그 파일을 확인하여 체크포인트가 정상적으로 이루어 지고 있는지를 확인해야 하며, Altibase 프로퍼티 파일 내에 CHECKPOINT_INTERVAL_IN_SEC 프로퍼티와 CHECKPOINT_INTERVAL_IN_LOG 프로퍼티의 설정이 적절한지 확인하여야 한다. 만일 체크포인트가 정상적으로 이루어 지고 있음에도 불구하고 아카이브 로그 파일들이 LOG_DIR 프로퍼티에 지정된 디렉터리에 계속 남아 있다면 이중화 전송 상태를 확인해 본다. 이중화 전송이 계속 밀리고 있거나 전송 불가능 상태라면 로그 파일들은 아카이브 되지 않거나 지워지지 않아서 LOG_DIR 프로퍼티에 지정된 디렉터리에 계속 보관되므로 로그 저장 공간이 부족해 질 수 있다.

이중화 관련 문제 해결 방법은 다음에 나올 이중화 문제에서 좀 더 자세히 설명하기로 한다.

메모리 테이블스페이스와 각 시스템 테이블스페이스는 설정 파일내의 MEM_DB_DIR 프로퍼티에 설정된 디렉터리에 저장된다. 테이블스페이스 관련 디스크 부족 현상이라면 이 부분 또는 사용자가 생성한 테이블스페이스 파일이 저장된 공간을 확인해야 한다. 테이블스페이스를 저장하는 파일 시스템은 최소 해당 테이블스페이스가 증가되는 크기 이상의 여유 공간이 있어야 한다.

메모리 테이블스페이스의 저장 공간은 체크포인트가 수행될 때 실제로 디스크에기록이 되기 때문에 메모리 상에 존재하는 테이블스페이스 크기 이상의 디스크 여유 공간이 필요하다.

메모리 사용량의 문제#

Altibase 운영 중 가용메모리가 부족해 진다면 응답시간이 매우 느려질 수 있으며 Altibase가 비정상적으로 종료될 수 있다. 이런 경우 Altibase가 사용하고 있는 메모리 영역을 검사하여 해당 크기가 적절한지를 판단하고 불필요하게 사용되고 있는 부분을 제거해야 한다. 만일 불필요하게 사용하고 있는 영역이 없다면 메모리 증설을 고려 하여야 한다.

Altibase가 운영 중에 사용하는 메모리 공간은 크게 나누어 보면 다음과 같다.

  • 메모리 테이블스페이스
  • 임시 메모리 공간
  • 메모리 버퍼

메모리 테이블스페이스에는 메모리 테이블의 실제 레코드 및 MVCC 를 지원하는데 필요한 레코드의 이전 버전들이 저장된다.

임시 메모리 공간은 메모리 테이블에 생성된 테이블의 인덱스 저장, 메모리 테이블 조회 시 레코드를 임시로 정렬, 세션들의 정보를 저장하는 용도 등으로 사용된다.

메모리 버퍼는 디스크 테이블 레코드에 대한 연산 및 정렬 등을 위해 사용되는 공간이다.

메모리 과다 사용이 의심된다면 일정기간 동안 생성되는 문장(statement)의 개수와 임시 메모리 영역의 크기, 메모리 테이블스페이스의 사용량, 및 메모리 테이블의 인덱스 크기 등을 모니터링 하여 증가량을 확인하여야 하며 이와 함께 ps나 top과 같은 시스템 모니터링 명령으로 프로세스의 크기가 지속적으로 증가되는 지 확인해 보아야 한다.

Altibase가 처음 가동된 이후에 일정 기간 동안은 임시 메모리 영역 할당, 여러 이전 버전의 레코드 생성, 및 세션 정보의 증가로 인해 메모리 사용량이 증가할 수 있는데, 이는 정상이다.

그러나 만일 일정 기간 운영 이후에도 지속적으로 증가한다면 메모리 누수와 같은 이상이 있는지를 의심해 볼 수 있으며 이러한 경우 전문 시스템 엔지니어에게 문의를 해야 한다.

CPU 사용량의 문제#

갑자기 Altibase의 CPU 사용량이 늘었다면 다음과 같은 상황들을 의심해 볼 수 있다.

  • 메모리 테이블 질의 처리 시 인덱스를 사용하지 못함
  • 디스크 테이블 질의 처리 시 디스크 사용 과다
  • 메모리 부족으로 인한 스와핑 발생

시스템 성능 모니터링 도구를 이용하여 메모리 사용량을 확인하고 가용 메모리가 부족하여 스와핑이 발생한다면 추가 메모리를 확보해야 한다. 이에 대한 내용은 메모리 사용량의 문제에서 자세히 설명하였다.

메모리 부족 상항이 아니고 질의 처리 시 메모리 테이블 전체 스캔이나 디스크 테이블에서 디스크를 과다하게 사용한다면 해당 쿼리나 테이블 등을 튜닝하여 해결이 가능하다.

이에 대한 내용은 다음에 나올 응용프로그램 및 쿼리 수행시 문제에서 좀 더 자세히 설명하기로 한다.

이중화 문제#

이중화 관련하여 발생 할 수 있는 문제는 다음과 같은 것들이 있다.

  • 이중화 시작 실패
  • 이중화 반영 속도가 매우 느림
  • 이중화 중인 테이블의 레코드 건수가 서로 틀림

이중화 전송에 문제가 발생되면 로그 저장 공간에 아카이브 로그 파일이 계속 남아있게 되어 가용 공간이 부족해지고 이로 인해 서비스가 안되고 Altibase가 멈춰있는 현상이 발생될 수 있다.

이중화 관련 문제가 발생했다면 먼저 관리자 로그 파일에 이중화 관련 에러 메시지가 기록되어 있는지 확인하고 해당 내용을 전문 엔지니어에게 전달해야 한다.

한쪽 시스템에 장애가 발생하고 장애 상황이 장시간 지속되면 이중화 데이터 전송을 하지 못하여 로그 저장 디렉터리의 가용 공간이 부족해 지는 현상이 발생한다. 따라서 단시간 내에 문제 해결이 어려울 경우에는 이중화를 중단하고 이중화 객체를 삭제하여 현재 운영중인 시스템에 문제가 생기지 않도록 하는 것을 고려해야 한다. 이런 경우 장애 상황이 해제된 이후 장애 발생 시스템의 데이터 복구 작업이 추가적으로 필요하다. 데이터 복구 방법으로는 iLoader 도구를 이용하는 방법과 이중화를 SYNC 모드로 구동하는 방법이 있다.

만일 이중화 객체 삭제가 어려운 경우 로그 저장 디렉터리의 가용 공간을 지속적으로 확인하여 모자란 경우 확보를 해주어야 한다.

마찬가지로 이중화 네트워크 라인에 문제가 발생했다던지 이중화에 문제가 생겨 장시간 이중화가 연결되지 못하는 경우에도 동일한 조치가 필요하다.

응용프로그램 및 쿼리 수행시 문제#

응용프로그램 및 쿼리 수행에 관한 문제 발생시 크게 다음 두 가지 상황을 생각해 볼 수 있다.

  • 응용프로그램에서 Altibase로의 접속 실패
  • 응용프로그램에서 Altibase로 쿼리 요청 이후 멈추어 있거나 정해진 시간 동안 처리하지 못하여 타임아웃 발생

Altibase 접속 실패#

응용프로그램에서 접속이 실패한다면 Altibase 질의 처리 도구인 iSQL을 이용하여 접속을 시도해서 정상적으로 접속이 되는지 확인한다. Altibase에서는 접속시 4가지의 접속 방식을 제공하기 때문에 (TCP/IP, socket domain, IPC, IPCDA) 응용프로그램에서 사용하고 있는 접속 방식을 사용하여 시험해봐야 한다.

접속 방식을 설정하는 방법은 ISQL_CONNECTION 환경변수를 지정하여 가능하다. (TCP, UNIX, IPC, IPCDA)

만일 iSQL로 접속이 성공한다면 응용프로그램 안에서 접속정보 설정 시 문제가 있는 것이므로 해당 부분의 오류를 찾아 해결하면 되며, 접속이 성공하지 못한다면 다음 사항들을 고려해 볼 수 있다.

  • 현재 서버에 접속된 세션 수가 MAX_CLIENT Altibase 프로퍼티의 설정값을 초과함.
  • 접속 방식이 IPC 방식인 경우 IPC 방식으로 접속된 세션 수가 IPC_CHANNEL_COUNT 설정값을 초과함.

응답이 없거나 타임 아웃으로 인해 세션이 끊어짐#

질의 처리시 수행 속도가 느려 응답이 없는 경우 다음과 같은 상황을 생각해 볼 수 있다.

  • 메모리 가용량이 부족하여 스왑핑이 발생
  • 테이블을 풀 스캔하여 처리 성능이 저하
  • 특정 테이블에 락을 요청하고 기다리고 있는 상태

먼저 시스템 성능 모니터링 도구를 이용하여 CPU 사용량과 메모리 사용량을 점검하여 메모리 부족 상황인지를 판단해야 하며 만일 메모리가 부족한 상황이라고 판단되면 위의 메모리 사용량의 문제를 참고한다.

메모리가 부족한 상황이 아니면서 CPU 사용량이 높다면 현재 처리 중인 쿼리 중 테이블 풀 스캔을 유발하는 쿼리가 있는지를 확인해야 한다.

현재 수행 중인 쿼리 목록을 확인하려면 iSQL로 서버에 접속하여 V$STATEMENT 성능 뷰의 QUERY 칼럼을 조회하면 된다.

수행 중인 쿼리 중 의심되는 쿼리를 선정하여 실행 계획을 확인하고 문제가 있다면 튜닝을 해야 한다.

쿼리 튜닝에 대한 자세한 내용은 Performance Tuning Guide 참조한다.

위의 두 경우에 해당하지 않는다면 락을 기다리고 있는 상태를 의심할 수 있다. 현재 락 정보를 V$LOCK 과 V$LOCK_WAIT 성능 뷰로 확인하고 특정 세션이 불필요하게 락을 획득하고 있는 상태로 지속되고 있다면 해당 세션을 강제로 종료하여 해결할 수 있다.

  1. Statement는 하나의 SQL문을 처리하기 위해 내부적으로 사용되는 객체이며 하나의 statement는 하나의 SQL문을 처리한다. ↩