본문 바로가기

기타/생각정리

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] 시퀀스의 옵션에 담긴 의미

1. 시퀀스(Sequence)란? 시퀀스란 영어로 '순서'라는 의미를 갖고 있다. 오라클에서는 시퀀스를 객체로 사용해 자동으로 증가하는 숫자를 사용하는데 이용한다. 2. 시퀀스가 필요한 이유 예를 들어

subbak2.com

 

 

 

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

(추후 내용 추가)

 

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

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

https://subbak2.tistory.com/99

 

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

파티션이 아닌 nonpartitioned 테이블을 파티션화할때 가장 먼저 고려해볼만한 것은 online redefinition이다. 현재 PK에 파티션 기준 컬럼이 포함되어있다면 아래 PROCEDURE를 통해 ONLINE REDEFINITION을 진행하.

subbak2.com

 

5. 인덱스의 남용

(추후 내용 추가)

 

 

6. 테이블 풀스캔 SQL

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

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

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

 

(추후 내용 추가)

 

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

https://subbak2.tistory.com/97

 

[Oracle] 튜닝 최후의 수단 PROFILE

튜닝의 끝은 순정이다. 가장 좋은 SQL 튜닝은 튜닝을 하지 않는 것이라고 생각한다. 데이터 모델링이 잘 되어있고 통계정보도 잘 수집되어 별도의 힌트없이 설계자의 의도대로 플랜이 수행되어

subbak2.com

 

 

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

 

기술 부채와 이율

기술 부채와 이율 인프랩에 합류하고 난뒤부터 일기를 조금씩 쓰고 있다. 시리즈 A 확정 일주일전 (실제 통장에 돈 들어오기 한달전) 에 합류한 시니어 개발자가 겪는 경험들을 남겨두면 좋겠다

jojoldu.tistory.com

 

반응형

'기타 > 생각정리' 카테고리의 다른 글

2023년 04, 05월 회고  (0) 2023.05.30
2023년 03월 회고  (0) 2023.04.03
2023년 02월 회고  (0) 2023.02.19
2023년 01월 회고  (2) 2023.01.27
DBA, 주니어 개발자 공부 방향성  (0) 2022.10.14