데이널 『데이터 ∙ 분석 ∙ 지식소통』::데이터 이행 검증 방법, 정합성, 무결성을 어떻게 보장할까?

데이터 이행 전략을 세우고 실 이행이 이루어지는데요. 이때 중요한 것이 검증입니다. Source 시스템에서 Target 시스템으로 문제없이 이행되었는지 확인하는 것이죠. 이때 검증 체계와 방안을 마련해야 하는데요.

데이터 검증 과정에서 문제가 발견되면, 이행된 데이터를 수정하거나 다시 이행하는 등 조치가 필요합니다. 이 부분을 반복해서 오류가 하나도 없이 준비하는 과정이 이행 테스트입니다.

이 글에서는 Oracle에서 MySQL로의 데이터 이행을 한다고 가정할 때 검증해야 할 항목은 아래와 같습니다. 각 검증 구분별로 하나하나 알아 보겠습니다. 검증 방법의 자동 검증은 프로시저로 등록하여 자동으로 검증하는 부분이고, 수동 검증은 데이터를 샘플링해서 일회성 검증으로 해도 되는 부분입니다.

검증 구분	검증 내용	검증 방법
데이터 정합성 검증	건수 검증	자동 검증
데이터 정합성 검증	값 검증	수동 검증
데이터 형식 검증	타입 검증	수동 검증
데이터 형식 검증	NULL 검증	수동 검증
코드 검증	코드 검증	자동 검증
참조 무결성 검증	RI 검증	자동 검증
업무 규칙 검증	컬럼 값 범위 검증	자동 검증
업무 규칙 검증	데이터 중복 검증	자동 검증
성능 검증	성능 비교 검증	수동 검증
어플리케이션 검증	UI 데이터 검증	수동 검증

데이터 정합성 검증

데이터 정합성 검증은 데이터가 원본과 일치하는지를 확인하는 과정입니다. 이 검증은 이행 후 가장 먼저 해야 할 작업입니다.

1. 건수 검증

Oracle에서 MySQL로 옮긴 후, 각 테이블의 레코드 수가 동일한지 확인합니다. 예를 들어, Oracle에서 users 테이블에 10,000개의 레코드가 있었다면, MySQL의 users 테이블에도 10,000개의 레코드가 있어야 합니다. SQL 쿼리를 사용해 row 수를 비교할 수 있습니다.

-- Oracle
SELECT COUNT(*) FROM user;

-- MySQL
SELECT COUNT(*) FROM user;

2. 값 검증

중요한 컬럼에 대해 샘플링해서 값이 정확히 이행되었는지 확인합니다. 예를 들어, username, email 같은 필드의 값을 직접 비교해 볼 수 있습니다. 샘플링 검증은 모든 데이터를 일일이 비교하는 것이 아니라 특정 인스턴스에 대해 확인하는 방식입니다.

데이터 형식 검증

Oracle과 MySQL은 데이터 타입을 처리하는 방식이 다를 수 있습니다. 따라서 데이터 타입이 올바르게 변환되었는지 확인하는 것이 중요합니다. 특히 clob 타입의 경우 값이 잘린다거나 값이 밀려서 잘못된 데이터가 들어가는 경우도 있습니다.

1. 데이터 타입 검증

Oracle에서의 데이터 타입이 MySQL로 올바르게 변환되었는지 확인합니다. 예를 들어, Oracle의 DATE 형식이 MySQL의 DATETIME 형식으로 제대로 변환되었는지 검토해야 합니다.

-- Oracle에서 DATE 필드 확인
SELECT hire_date FROM emp WHERE emp_id = 101;

-- MySQL에서 동일한 필드 확인
SELECT hire_date FROM emp WHERE emp_id = 101;

2. NULL 처리 검증

Oracle과 MySQL은 NULL 값을 처리하는 방식이 다를 수 있습니다. 이행 과정에서 NULL 값이 예상치 않게 변환되지 않았는지 확인하는 것이 좋습니다.

참조 무결성 검증

Referential Integrity 관계 검증은 데이터베이스의 여러 테이블 간 관계가 올바르게 유지되고 있는지 확인하는 과정입니다. Oracle에서 MySQL로의 데이터 이행 과정에서 RI가 제대로 유지되었는지 검증해야 합니다. 이는 테이블 간 정보 연관성 누락 방지를 위한 검증입니다.

공식적으로는 FK를 꼭 설정해야 하는 것으로 나와 있는데요. 사실 FK를 설정할 경우 속도가 느려지기 때문에 많은 사이트에서 FK는 선택적으로 설정합니다. 대신 데이터 간 관계가 깨질 수 있기 때문에 품질관리 RULE에 등록하거나 애플리케이션에서 발생하지 않도록 프로그래밍합니다. 이는 비즈니스 로직에 중대한 영향을 미칠 수 있기 때문입니다.

-- RI 검증
-- 주문(order) 테이블의 고객번호(cust_num)는 고객(customer)의 고객번호(cust_num)에 모두 있어야 한다.

SELECT COUNT(*)
FROM order o
LEFT OUTER JOIN customer c ON o.cust_num = c.cust_num
WHERE c.cust_num IS NULL
;

위 쿼리를 통해 RI 검증을 할 수 있고 관계가 없는 row가 있는지 확인할 수 있습니다. 만약 있다면 원인을 파악하고 처리해야 합니다.

업무 규칙 검증

업무 규칙 검증은 데이터가 비즈니스에서 요구하는 특정 규칙을 충족하는지 확인하는 단계입니다. Oracle에서 사용되던 비즈니스 로직이 MySQL에서도 동일하게 작동하는지 검증해야 합니다.

1. 컬럼 범위 검증

특정 컬럼 값이 올바른 범위 내에 있는지 확인합니다. 예를 들어, 나이(age) 필드가 0보다 큰지, 제품 가격(price)이 음수가 아닌지 등을 확인합니다.

-- 컬럼 범위 검증
-- 사용자(user) 테이블의 나이는 0살보다 더 커야 한다.

SELECT COUNT(*)
FROM user WHERE age < 0
;

2.데이터 중복 검증

이행 과정에서 중복 데이터가 생성되지 않았는지 확인합니다. MySQL의 경우 PK를 생성하고 이행하는 것이 더 유리하기 때문에 생성하는 과정에서 중복 데이터에 대해서는 error가 나올 것입니다. 그 외에 PK가 아닌 경우도 업무상 중복이 있으면 안 되는 경우 확인할 수 있습니다. 예를 들어, email 칼럼에 중복된 값이 없는지 검증할 수 있습니다.

-- 중복 데이터 검증
-- email 컬럼의 값은 중복(2건 이상) 발생해서는 안 된다.

SELECT email, COUNT(*)
FROM user
GROUP BY email
HAVING COUNT(*) > 1
;

성능 검증

데이터 이행 후 시스템의 성능이 유지되거나 향상되었는지 확인합니다. MySQL에서 데이터가 잘 작동하는지, 쿼리 응답 시간이 적절한지 검토합니다.

Oracle에서 실행되던 주요 쿼리들이 MySQL에서도 동일한 성능을 보이는지 비교합니다. 필요한 경우 인덱스 설정 등을 조정해 성능을 최적화할 수 있습니다.

애플리케이션 검증

이행된 데이터가 애플리케이션이나 사용자 인터페이스에서 올바르게 표시되는지 확인해야 합니다. 이 과정에서는 데이터를 사용하는 모든 애플리케이션이 제대로 작동하는지 확인합니다.

애플리케이션 담당자는 담당 UI에서 데이터가 올바르게 나타나는지 확인합니다. 예를 들어, 사용자가 데이터 필터링이나 검색을 할 때 예상한 대로 결과가 나오는지 검증합니다.

로그 및 검증 리포트

이행 검증 작업 중 자동 검증의 경우 프로시저 또는 쉘 프로그램으로 개발합니다. 결과 로그를 테이블로 쌓게 구성할 수 있습니다. 이렇게 발생한 로그 결과를 검토할 수 있습니다. 이행 과정에서 어떤 문제가 있었는지, 어느 부분이 오래 걸리는지 분석이 가능합니다. 이는 향후 발생할 수 있는 문제를 예방합니다.

검증 리포트는 아래와 같은 형식으로 제공할 수 있는데요. 설계하기에 따라 더 상세하게 관리할 수도 있으나 기본적인 예시이니 참고하시기 바랍니다.

작업
SEQ

프로시저명

검증구분

소스테이블명

타겟테이블명

타겟컬럼명

소스컨수

타겟건수

오류건수

검증시작시간

검증종료시간

소요시간(분)

검증결과

SP_EMP_01

건수 검증

EMP

2000

2024-08-20 10:10:23

2024-08-20 10:12:29

2.1

정상

SP_EMP_02

코드 검증

EMP

EMP_TY_CD

2000

2024-08-20 10:10:23

2024-08-20 10:15:29

5.1

오류

SP_CUST_01

건수 검증

CUST

35000

2024-08-20 10:11:23

2024-08-20 10:14:22

3.0

정상

SP_ORDER_01

RI 검증

CUST

ORDER

24000