2-5. OAM을 위한 Database의 구성

OAM Client Framework – 목차

■ 운용관리에 관한 이론적 고찰
1-1. OAM의 정의  1-2. EMS의 정의  1-3. OAM 표준화 동향  1-4. 3GPP 32 Series

■ OAM 프레임워크
2-1. OAM 프레임워크 필요성  2-2. OAM 시스템의 구성  2-3. OAM 요구사항  2-4. OAM 배포 아키텍쳐  2-5. OAM을 위한 Database의 구성 2-6. OAM 인터페이스  2-7. 구성 관리  2-8. 장애 관리  2-9. 성능 관리  2-10. 보안 관리

■ OAM 클라이언트 프레임워크
3-1. OAM Client 프레임워크 개요  3-10. 효과분석  3-2. 개발방법  3-3. 요구사항  3-4. 산출물 정의  3-5. 개발환경  3-6. 아키텍쳐 3-7. UI 정의  3-8. 프레임워크의 개발  3-9. 프레임워크를 사용한 개발

2-5. OAM을 위한 Database의 구성

OAM 기능을 수행하기 위한 많은 데이터들은 Database를 사용하여 처리된다. 구성 관리를 위한 데이터는 File이나 Database에 저장되어 시스템의 재기동시 메모리에 올려서 사용하게 된다. 시스템에서 발생한 장애 기록, 성능 기록 등은 Database에 저장되어 차후 통계 보고서를 작성시 사용된다. 보안 관리를 위한 운영자 정책 등은 Database에 저장되어 접근 제어시 활용되고, 운용자의 실행 이력등은 Database에 저장되어 운용 이력을 추적시 사용된다. 이처럼 Database는 OAM의 기본 기능을 지원하기 위한 필수적인 요소이며, OAM을 위한 Database가 최적의 성능으로 동작하기 위해서는 OAM Data의 특성을 파악하여야 한다.

시스템의 OAM Agent가 수집한 성능 정보와 장애 정보는 주로 주로 삽입(Insert)와 조회(Select) 작업만이 발생한다. 따라서 Update, Delete로 인한 단편화, 행 이주, 행 연결등의 문제점보다는 Select를 위한 성능에 초점을 맞추어야 한다. 많은 관계형 데이터베이스에서 SQL문을 실행하기 위하여 비용 기준 옵티마이져(Cost-Based Optimizer)를 사용하며, 최적화된 실행 계획을 위해서는 Data에 대한 최신의 분석 정보가 충분해야 한다. 이를 위해 Histogram으로 테이블을 분석하면 선택도(Selectivity)에 따른 최적화된 실행 계획을 산출할 수 있다. 하지만 분석 정보를 생성하기 위해서는 시스템의 부하가 생기므로 Data의 검색이 많은 특정 항목에 대해서 선별적으로 분석하여야 하며, 오라클의 DBMS_JOB과 같은 스케쥴러를 사용하여 야간에 분석작업을 수행하여야 한다.[주:주종면, “알기 쉽게 해설한 오라클 SQL 튜닝 & 서버 튜닝”]

OAM Agent가 수집한 시스템의 정보는 지속적으로 데이터가 발생하지만, OAM 클라이언트를 위한 조회(Select) 작업은 주로 최근의 Data에 초점이 맞추어 진다. 따라서 과거의 데이터까지 포함하는 넓은 범위를 순차적으로 범위 스캔(Range Scan)하여 역순으로 정렬해야 한다면 많은 부하가 발생한다. 따라서 최근의 데이터에 대한 액세스를 최적화하기 위해서는 Index를 생성시 Decending Index를 사용하거나 INDEX_DESC와 같은 힌트를 적용하여 부분 범위(Partial Range) 처리하여 성능을 높일 수 있다.

많은 조회(Select) 작업은 운용자가 OAM 클라이언트를 조작하여 발생한다. 운용자는 통계를 조회하기 위해 기간, 항목 등의 검색 조건을 입력하고 OAM 클라이언트에서는 정해진 절차에 따라 쿼리를 조합하거나 저장 프로시져(Stored Procedure)를 호출한다. 운용자가 입력한 다양한 검색조건은 쿼리문의 Whrer절에서 사용되므로 OAM 클라이언트에서 자주 사용되는 검색 조건은 항목은 결합 인덱스(Composite Index) 또는 함수 기준 인텍스(Function-Based Index)로 생성하여 조회의 성능을 높일 수 있다.[주:이화식, “새로쓴 대용량 데이터베이스 솔루션 I”]

OAM Data에 관한 갱신(Update) 작업은 자주 발생하지 않으나, 테이블 설계에 따라 장애 정보가 해제(Clear)되었을때 관련된 값들을 갱신하는 경우가 있을 수 있다. 발생된 장애의 해제시 해제시간, 해제사유, 운용자 조치등을 기존 행에 갱신할 때  저장 공간이 부족하여 행 전체가 새로운 블록으로 이주하는 현상이 발생할 수 있다. 이는 주로 해제사유 또는 운용자 조치와 같은 문자열이 저장되는 VARCHAR2 타입의 컬럼에서 자주 발생할 수 있으며, 행 이주(Row Migration) 현상이 자주 발생한다면 조회(Select)시 검색 속도가 떨어지는 원인이 될 수 있다. 따라서 VARCHAR2에 대한 갱신(Update)되는 컬럼은 입력되는 데이터의 크기에 따라 오라클의 PCTFREE와 같은 데이터 블록에 대한 속성을 조절하여야 한다.

위에서 살펴본 바와 같이 Database에서의 조회, 추가, 갱신, 삭제 작업은 OAM 클라이언트와 밀접한 관계가 있으므로, Database를 설계 시 운용자가 주로 관심을 가질 데이터의 종류와 OAM 클라이언트의 동작 방식에 대한 고려가 필요하다.

CC BY-NC-ND 2.0 KR

이 저작물은 크리에이티브 커먼즈 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용할 수 있습니다. 크리에이티브 커먼즈 라이선스

저작권과 관련된 파일요청 및 작업요청을 받지 않습니다.

댓글 남기기