May 20, 2011 - Max depth exceeded when dereferencing c0-e1 에러

CRUD 매트릭스

업무 프로세스와 데이터간 상관 분석표는 행은 업무 프로세스로, 열은 엔티티 타입으로 구성되며 행과 열이 만나는 교차점에 발생 및 이용에 대한 상태를 표시한다. 일반적으로 생성(Create), 이용(Read), 수정(Update), 삭제(Delete)로 나누어 표현하여 이를 CRUD 매트릭스라고도 부른다.

Create: 하나의 업무기능이 하나의 데이터를 생성하는 관계 
Read: 하나의 업무기능이 업무수행의 목적을 달성하기 위하여 데이터를 참조하는 관계 
Update: 하나의 업무를 수행하는 과정에서 데이터가 수정/갱신되는 관계 
Delete: 하나의 업무를 수행하는 과정에서 데이터가 삭제되는 관계 

여지까지 개발하면서 해본적없는 업무. 한번 해두면 언젠가는 도움이 될 거 같다.

단순히 하나의 프로세스에 사용되는 DB테이블에서 어떤식으로 Select(Read) , Insert(Create), Update, Delete 되는지 목록을 뽑는 듯 싶다.

CRUD MATRIX를 이용함으로써 프로젝트에서 얻을 수 있는 장점

▶ 분석 단계의 데이터 모델과 프로세스 모델에 대한 작업을 검증하는 역학을 한다.
▶ 시스템 구축 다녜에서 애플리케이션을 개발하는 데 필요하고 중요한 산출물이 된다.
▶ 테스트 단계에서 개발한 애플리케이션을 객관적인 자료를 사용하여 테스트하는 데도 중요한 역할을 한다.
▶ 전체 업무의 인터페이스를 파악할 수 있다.

Mar 22, 2011 - BEA-001128_Connection for pool 'DB' closed.

  1. 실제 여유 용량이 5% 남음
<BEA-310002> <5% of the total memory in the server is free>
Description : Free memory in the server has changed
Action : no action required
  1. 구성에 따라서 예정된 데이터 정리 작업을 실행함
Description : Scheduling data retirement tasks as per configuration
Action : no action required

<BEA-320140> <Scheduling data retirement tasks as per configuration.>

3.

Description : Processed configuration and scheduled data retirement tasks.
Action : no action required
<BEA-320143> <Scheduled 0 data retirement tasks as per configuration.>
  1. DB 가 connection closed 처리됨.
<BEA-001128> <Connection for pool "DB" closed.>
<중략> 해당 문제는 대략 1분~2분 사이에 잠깐의 PoolDisable 현상이 나는 골치아픈 문제였습니다. 워낙 접속하는 클라이언트가 많다보니 1분 정도의 PoolDisable 현상에서도 2천~9천건 가까운 에러가 발생하는데, 해당 문제는 DB 과부하로 5분 정도의 지연 현상이 생겼고, 그때, DB의 transaction 과 웹로직의 Shrink Frequency 와 뭔가 맞지 않는 설정이 있지 않은가 의심했습니다. 서버의 웹로직의 Shrink Frequency 는 300초 즉 5분으로 설정되어있는데, 해당 시간이 지나면 끊고나서 재접속시키고 있습니다. 결과적으로 DeadLock 이 발생하였고, Shrink Frequency 의 설정값 5분을 초과하면서 DeadLock 이 떨어지기 전에 PoolDisable이 발생한 것으로 추측하며, 해당 옵션을 수정하였습니다. ----- # 참조 ----- * [BEA Weblogic AS 9.2 close pool connections](http://forums.oracle.com/forums/thread.jspa?threadID=928446 )

Mar 4, 2011 - 오라클 RBO 에 대한 설명

RBO 란 (Rule-Based Optimizer) 의 약자로
하나의 SQL에 대한 여러 개의 execution plan 가운데 가장 높은 순위의 execution plan을 항상 사용하도록 하는 법입니다. (Rank Rule 사용.)

  • 경험적으로 순위가 매겨진 오퍼레이션에 기초한 실행계획을 선택합니다.
  • SQL 문을 실행하기 위한 방법이 하나 이상있다면, 규칙기준 접근 방식은 순위가 높은 오퍼레이션을 이용합니다.
  • 순위가 높은 오퍼레이션은 순위가 낮은 오퍼레이션보다 빨리 실행됩니다.
  • 수립될 실행계획이 예측 가능하기 때문에 사용자가 원하는 처리 경로로 유도하기 쉽습니다.

다만 오라클 10G 부터는 RBO 에 대한 지원 자체가 중단되었기 때문에 그로 인해 우리 서버의 경우 DBA가 자체적으로 ‘통계’ 수집작업을 하도록 결정되었습니다.

통계내역은 이주 월요일밤부터 수집된 내역을 퍼블리싱 하였고,
모든 테이블이 대상으로 하였고, 작업시 오라클 SQL AREA 가 프러싱 되어 하드 파싱이 다량 발생하였지만,
시스템에 무리를 줄 수준은 아니었으며,
현재 OTLP성 작업에는 실행시 이상이 없는 걸로 파악되었으며,
지속적인 테스트를 하고 있는 중입니다.


참조