DBA가 발견하고 해결해야 할 기술부채

 

 

* 기술부채 (Technical debt) :

현 시점에서 더 쉬운 방식을 사용하는 대신, 추후에 발생하는 재작업 비용을 반영하는 소프트웨어 개발의 관점

https://en.wikipedia.org/wiki/Technical_debt

 

먹고 살다보면 현실과 타협하게되는 무수한 순간이 찾아온다.

시간과 인력의 제약으로, 또는 그 핑계로 운영DB에 긴급 반영하게 되는 경우는 

일반 프로그램보다 DB에 훨씬 더 많은 순간 찾아온다. 

 

 

온라인 SQL이 밀리면 위험을 감수하고 인덱스를 생성하기도 하고, 

프로그램 반영시 누락된 DB 오브젝트에 대한 DDL을 날리고, 

플랜의 변경을 감수하고 즉시 통계정보를 수집하기도 한다.

 

 

이러한 긴급 반영은 개발/운영자의 실수 때문일수도 있고,

DBA가 평소에 기술부채를 쌓아놔서 일수도 있으며, 

프로젝트 수행시 일정이 늦춰지면서 생기는 어쩔수 없는 선택에 의함일수도 있다. 

 

이러한 긴급반영 또는 DB장애를 방지하기 위해 

DB 관점에서 평소에 생각해 볼 기술부채들을 계속해서 업데이트 하려고 한다.

 

 

1. Function, Procedure, Trigger 남용

온라인 트랜잭션이 적거나 사내에서 간단하게 사용하는 서비스의 경우, 

DBMS의 Function, Procedure, Trigger를 사용하는 것은 적절한 선택이 될 수 있다.

 

프로그램 개발의 공수와 규모를 줄일 수 있고, 

전략적으로 비즈니스 로직 중 일부를 DB에서 관리함으로써 

어플리케이션 개발자 (Ex> 외주 개발자 등)에게 권한과 정보를 한정적으로 제공할 수 있다.

 

그러나,

1) 테이블의 수정이 발생할 경우 dependency가 있는 Object들은 Compile이 필요하다.

    → Compile이 안 되는 경우 재생성이 필요하고 이러한 과정 중 장애가 발생할 수 있다.

2) 테이블 리오그를 하는 경우 dependency를 사전에 등록하더라고 스위치 과정에서 에러가 발생할 수 있다.

 

그래서 개인적으로 비즈니스 로직과 관련된

Function, Procedure, Trigger는 DBMS에 아예 없는게 낫다고 생각한다.

 

 

2. DBMS_SCHEDULER_JOBS

프로그램 개발의 공수를 줄인다는 이유로 비즈니스 로직을 구현하는 배치 프로그램을 

DBMS_SCHEDULER_JOBS에 등록해 사용하는 경우도 있다.

 

Function, Procedure, Trigger 등 보다는 온라인 영향도는 적겠지만, 

개발/운영자가 배치 프로그램을 효과적으로 관리하기 위해서 

DBMS_SCHEDULER_JOBS 보다는

Spring batch 등 다른 방법으로 배치 프로그램을 구현하는게 낫다고 생각한다.

 

 

3. 시퀀스 최댓값

시퀀스의 최댓값이 있고 Nocycle 옵션이 있는 경우, 시퀀스를 최댓값까지 사용한 경우

시퀀스 채번이 불가하고 장애가 발생할 수 있다.

 

시퀀스는 보통 PK 컬럼 중 하나로 사용하므로, 

초반 설계를 잘못하는 경우 시퀀스, 테이블 컬럼 Type, 프로그램 VO 필드 Type 등 연쇄적으로 수정해야하는 경우가 발생한다.

 

주기적으로 시퀀스의 MAX_VALUE와  LAST_NUMBER를 비교해서 임계치에 도달할 경우, 

적절한 조치가 필요하다. 

 

/* 확인 쿼리 예시 */
SELECT ROUND(A.LAST_NUMBER/A.MAX_VALUE, 2), A.LAST_NUMBER, A.MAX_VALUE, A.*
FROM DBA_SEQUENCES A
WHERE A.SEQUENCE_OWNER = :시퀀스오너
ORDER BY 1 DESC;

 

https://subbak2.tistory.com/16

[Oracle] 시퀀스의 옵션에 담긴 의미

 

 

 

4. 보관주기가 있는 논파티션 테이블

(추후 내용 추가)

 

PK 컬럼 중 파티션 기준 컬럼이 없고 프로그램 수정이 힘들때,

논파티션 → 파티션 테이블로 생각해볼만한 방법 : 

https://subbak2.tistory.com/99

[Oracle] 가상컬럼을 통한 파티션 테이블 관리

 

5. 인덱스의 남용

(추후 내용 추가)

 

 

6. 테이블 풀스캔 SQL

신규 테이블을 사용하는 SQL의 경우 힌트가 없어도 성능은 빠를 수 밖에 없다.

하지만, 데이터가 쌓일수록 SQL의 플랜이 중요해지는데, 일정한 성능 확보를 위해서는 

튜닝을 통해 힌트를 고정해놓는게 필요하다.

 

(추후 내용 추가)

 

긴급 튜닝이 필요한 경우 생각해볼만한 방법 : 

https://subbak2.tistory.com/97

[Oracle] 튜닝 최후의 수단 PROFILE

 

 

7. Not Null / Nullable 병행

대부분의 경우 코딩 컨벤션을 통해 프로그래밍 규칙을 정하고 DB도 원칙을 통해 오브젝트를 관리해야한다.

하지만 여러가지 이유로 그 원칙이 무시되면서

(Ex> 개발 / 운영 업체가 다른 상태에서 인수인계만 급박하게 진행되는 등)

 

단일 테이블 내에서 컬럼별로 Not Null / Nullable 등 옵션이 혼재되거나, 

Default 값의 존재/부재가 혼재하면서 프로그램 오류를 발생시킬 수 있다.

 

보통 이런 경우 개발/검증/운영계의 DB 오브젝트가 상이한 경우도 있어, 

시간이 날때마다 최소한 개발-검증-운영계 오브젝트는 일관되게 맞춰놓는게 필요하다.

 

 

8. 기준정보와 DB의 불일치

메타 정보와 실제 DB 오브젝트간의 불일치. CDC 등 평소에 관리하기 힘든 옵션으로 인해 장애를 유발할 수 있다.

 

 

9. 통계정보의 부재

대부분의 DB는 통계정보를 기반으로 CPU cost를 계산하고 Optimizer는 그를 기반으로 SQL의 플랜을 세워 

그 플랜대로 데이터를 읽는다.  (CBO - Cost Base Optimizer 방식)

 

통계정보가 수집되지 않은 경우 SQL에 힌트나 프로파일이 적용되어있지 않다면, 

데이터가 많더라도 인덱스 스캔을 하지 않고 풀스캔을 하는 등 

Cost 계산을 실제와 다르게 하게되고 적절하지 않은 플랜으로 DB 장애를 유발할 수 있다. 

 

 

10. 슬로우 쿼리 외면

현실적으로 가장 많이 쌓게 되는 기술부채

 

 

 

* 글 작성을 시작하게 된 이유 : 

https://jojoldu.tistory.com/682

기술 부채와 이율