다른 DBMS를 만났을 때

인덱스가 언제 안 타는지, 실행계획을 어떻게 읽는지, 트랜잭션이 어떻게 꼬이는지는 제품과 무관하게 같은 원리로 동작합니다. 이 문서는 그 위에서 실제로 달라지는 문법만 다룹니다.

버전에 따라 지원 여부가 달라지는 항목이 많습니다. 표에 표기한 최소 버전은 참고용이고, 적용 전에는 운영 중인 버전의 공식 문서를 확인합니다.

이관할 때 가장 먼저 손대야 하는 부분입니다. 문법이 제품마다 완전히 다릅니다.

• 페이징 · Oracle 11g 이하는 ROWNUM 중첩 인라인뷰를 써야 합니다. MSSQL의 OFFSET FETCH 는 ORDER BY 가 필수입니다.
• 행 번호 · ROWNUM 은 Oracle과 Tibero 고유입니다. 이관 시 ROW_NUMBER() 로 바꿔야 합니다.

오류 없이 결과만 달라지는 영역이라 이관 후 검증에서 놓치기 쉽습니다.

• 빈 문자열 · Oracle만 다릅니다. 이관 시 데이터와 조건문 양쪽을 모두 점검해야 하는 대표적인 항목입니다.
• 문자열 결합 · Oracle은 'A' || NULL 이 'A'지만, MSSQL의 'A' + NULL 은 NULL입니다. 문자열 조립 로직이 조용히 깨집니다.
• NULL 대체 · COALESCE 는 네 제품 모두 지원합니다. 이관 가능성이 있으면 처음부터 COALESCE 를 쓰는 편이 낫습니다.
• NULL 정렬 · NULLS FIRST / NULLS LAST 는 Oracle과 PostgreSQL만 지원합니다. MSSQL과 MySQL은 CASE로 정렬 키를 만들어야 합니다.

타입의 정밀도가 달라 이관 시 값이 잘리거나 늘어납니다.

• DATE 타입 · Oracle의 DATE를 다른 제품의 DATE로 그대로 옮기면 시분초가 잘립니다. DATETIME 계열로 매핑해야 합니다.
• 날짜 연산 · Oracle에서 날짜에 숫자를 더하면 일 단위로 더해집니다. 이 관용구는 다른 제품에서 통하지 않습니다.

테이블 정의와 배치 로직을 함께 바꿔야 하는 영역입니다.

• UPSERT · MERGE 를 쓴 배치는 MySQL, PostgreSQL로 옮길 때 전면 재작성이 필요합니다.

Oracle 고유 문법이 많아 단순 치환이 안 되는 부분입니다.

• 차집합 · MINUS 는 Oracle과 Tibero 고유입니다. 구버전 MySQL에는 대체 문법이 없어 NOT EXISTS 로 다시 써야 합니다.
• 계층 쿼리 · CONNECT BY 는 재귀 CTE로 다시 설계해야 합니다. LEVEL, SYS_CONNECT_BY_PATH 같은 부가 기능도 직접 구현해야 합니다.
• 조건 분기 · CASE 는 모든 제품이 지원합니다. DECODE 는 Oracle과 Tibero 전용입니다.

성능 진단 방법은 제품마다 완전히 다릅니다. 개념은 같아도 도구는 새로 익혀야 합니다.

• 실제 계획 · 예상과 실제를 비교하는 방식은 네 제품 모두 같습니다. 튜닝의 사고방식은 그대로 옮겨 갑니다.
• 힌트 · PostgreSQL은 의도적으로 힌트를 지원하지 않습니다. 통계와 쿼리 구조로 푸는 문화라 Oracle에서 넘어가면 접근 방식을 바꿔야 합니다.

공공기관 사업에서는 국산 DBMS 도입 요건 때문에 Tibero를 만나는 일이 잦습니다. Oracle 호환을 전면에 내세우고 있어 대부분의 문법이 그대로 통하므로, 별도 트랙 대신 차이점만 확인하는 방식이 효율적입니다.

다만 문법 호환과 성능 호환은 다릅니다. 같은 쿼리가 같은 실행계획을 탄다는 보장이 없어서, 이관 직후에는 잘 돌다가 데이터가 쌓인 뒤 특정 쿼리만 느려지는 형태로 문제가 드러나는 경우가 있습니다.