IBM DB2 (r1)

IBM DB2의 데이터베이스 엔진은 운영 체제 플랫폼에 따라 주로 두 가지 주요 아키텍처로 구분된다. DB2 LUW는 Linux, Unix, Windows 환경을 위한 엔진이며, DB2 for z/OS는 IBM 메인프레임 시스템을 위한 엔진이다. 두 엔진은 모두 관계형 데이터 모델과 SQL 표준을 준수하지만, 각 플랫폼의 고유한 특성과 요구사항에 맞춰 설계되어 내부 아키텍처와 운영 방식에서 차이를 보인다.

DB2 LUW 엔진의 핵심 프로세스는 다음과 같다.

반면, DB2 for z/OS 엔진은 z/OS 운영체제의 하위 시스템(Subsystem)으로 통합되어 동작한다. 데이터베이스 서비스는 주로 데이터 시스템 주소 공간(Data System Address Space)과 관련 시스템 주소 공간들 내에서 실행된다. IMS나 CICS 같은 온라인 트랜잭션 처리 환경과의 긴밀한 통합, 그리고 시스템 자원 관리자(SRM)를 통한 고도화된 워크로드 관리가 특징이다. 또한, 쿼리 병렬화 및 대용량 배치 작업 처리에 매우 최적화되어 있다.

두 엔진 모두 다중 스레드 아키텍처를 채택하여 동시 사용자와 트랜잭션을 효율적으로 처리한다. 그러나 LUW 버전이 독립적인 프로세스와 스레드 모델을 사용하는 데 반해, z/OS 버전은 z/OS의 고유한 작업 제어 블록(TCB) 및 서비스 요청 블록(SRB) 메커니즘을 활용한다. 이 구조적 차이는 설치, 구성, 모니터링, 튜닝 방법론에도 영향을 미친다.

IBM DB2의 스토리지 구조는 데이터를 물리적으로 저장하고 관리하는 체계를 말한다. 기본적인 저장 단위는 페이지이며, 크기는 일반적으로 4KB, 8KB, 16KB, 32KB 중 선택할 수 있다. 이러한 페이지들은 테이블 스페이스라는 논리적 그룹으로 묶여 관리된다. 테이블 스페이스는 다시 컨테이너라고 불리는 물리적 저장 장치(디렉토리, 파일, 장치)에 매핑된다. DB2는 테이블, 인덱스, 대용량 객체(LOB) 데이터를 서로 다른 테이블 스페이스에 저장할 것을 권장하여 성능과 관리 효율성을 높인다.

데이터 접근 성능을 극대화하기 위한 핵심 메모리 구조가 버퍼 풀이다. 버퍼 풀은 데이터베이스가 자주 접근하는 데이터 페이지와 인덱스 페이지를 메모리에 캐싱하는 영역이다. 디스크 I/O는 상대적으로 느리기 때문에, 요청된 데이터가 버퍼 풀에 이미 존재하면 디스크 읽기 없이 빠르게 응답할 수 있다. 각 버퍼 풀은 특정 테이블 스페이스와 연결되어 해당 공간의 데이터를 캐시하는 데 사용된다. 시스템은 LRU 알고리즘과 같은 페이지 교체 정책을 사용하여 버퍼 풀을 관리한다.

버퍼 풀의 구성과 크기는 성능에 지대한 영향을 미친다. 관리자는 데이터베이스의 워크로드와 데이터 특성에 따라 여러 개의 버퍼 풀을 생성하고 크기를 조정할 수 있다. 예를 들어, 자주 조회되는 핵심 테이블이 위치한 테이블 스페이스를 위한 전용 대형 버퍼 풀을 구성하는 것이 일반적이다. 버퍼 풀 히트율은 성능 튜닝의 중요한 지표로, 이 수치가 높을수록 디스크 I/O가 줄어들어 전반적인 성능이 향상된다.

IBM DB2는 데이터 무결성과 지속성을 보장하기 위해 선행 기록 로깅 방식을 채택한다. 모든 데이터 변경 작업은 실제 데이터 페이지가 디스크에 기록되기 전에 먼저 트랜잭션 로그에 기록된다. 이 로그는 주 로그 파일과 보조 로그 파일로 구성되며, 데이터베이스 활동의 모든 변경 사항을 순차적으로 저장한다.

복구 메커니즘은 크게 크래시 복구, 버전 복구, 롤포워드 복구로 구분된다. 크래시 복구는 시스템 장애 발생 시, 커밋되지 않은 트랜잭션은 롤백하고 커밋된 트랜잭션은 로그를 기반으로 재실행하여 데이터베이스를 정확한 상태로 복원한다. 버전 복구는 특정 시점의 백업 이미지를 사용하여 데이터베이스를 백업 당시의 상태로 되돌린다.

롤포워드 복구는 버전 복구와 아카이브 로그를 결합한 고급 기능이다. 전체 백업을 복원한 후, 아카이브된 트랜잭션 로그를 순차적으로 재실행하여 데이터베이스를 장애 발생 직전이나 특정 시점으로 복구할 수 있다. 이 방식을 사용하려면 데이터베이스를 아카이브 로그 모드로 설정해야 한다.

로깅 관련 주요 매개변수로는 LOGFILSIZ(로그 파일 크기), LOGPRIMARY(주 로그 파일 수), LOGSECOND(보조 로그 파일 최대 수) 등이 있다. 이러한 설정은 시스템의 트랜잭션 볼륨과 성능 요구사항에 따라 조정해야 한다. 로그 파일은 순환적으로 재사용되며, 아카이브 로그 모드에서는 가득 찬 로그 파일이 지정된 위치로 자동 복사되어 보관된다[1].

IBM Db2는 엔터프라이즈 환경의 요구사항을 충족하기 위해 고가용성과 재해 복구를 위한 강력한 솔루션을 제공한다. 핵심 기술로는 HADR과 PureScale이 있으며, 각각 다른 아키텍처 접근 방식을 통해 서비스 중단 시간을 최소화하고 데이터의 가용성을 보장한다.

HADR은 주로 Db2 LUW에서 사용되는 기능으로, 한 데이터베이스의 트랜잭션 로그를 실시간으로 스탠바이 서버에 전송하여 복제하는 방식이다. 주 서버(Primary)에서 발생한 모든 데이터 변경 사항은 로그 레코드로 기록되어 스탠바이 서버(Standby)에 적용된다. 이 구조는 다음과 같은 장점을 가진다.

* 자동 장애 조치: 주 서버에 장애가 발생하면, 스탠바이 서버가 자동 또는 수동으로 새로운 주 서버로 승격되어 서비스를 계속한다.

* 읽기 전용 워크로드 오프로딩: 스탠바이 서버를 읽기 전용 쿼리 처리에 활용하여 주 서버의 부하를 분산할 수 있다.

* 원격 재해 복구: 스탠바이 서버를 지리적으로 떨어진 위치에 구성하여 사이트 전체 장애에 대비할 수 있다.

반면, PureScale은 공유 디스크 아키텍처를 기반으로 하는 클러스터 솔루션이다. 여러 데이터베이스 서버(멤버)가 단일 데이터 이미지를 공유하며, 클라이언트의 연결은 자동으로 멤버들에 분산된다. 한 멤버에 장애가 발생해도 다른 멤버들이 작업을 즉시 인계받아 애플리케이션에 거의 중단 없는 서비스를 제공한다. PureScale은 선형적인 확장성을 제공하여 트랜잭션 처리량을 늘리기 위해 멤버를 추가할 수 있다는 점에서 HADR과 차별화된다.

이러한 기술들은 단독 또는 조합하여 사용될 수 있다. 예를 들어, 한 지역에 PureScale 클러스터를 구성하여 고가용성과 확장성을 확보하고, 다른 지역에 HADR 스탠바이를 두어 재해 복구를 준비하는 하이브리드 구성이 가능하다[2].

IBM DB2는 데이터베이스, 인스턴스, 객체 수준에서 다층적인 보안 모델을 제공한다. 접근 제어의 핵심은 인증(Authentication)과 권한 부여(Authorization)로 구성된다. 인증은 사용자나 응용 프로그램의 신원을 확인하는 과정으로, 운영 체제 인증, LDAP 디렉토리 서비스, Kerberos와 같은 외부 보안 플러그인을 활용할 수 있다. 권한 부여는 인증된 신원이 특정 데이터나 명령을 사용할 수 있는 권한을 결정한다.

권한과 특권은 SYSADM, SYSCTRL, SYSMAINT, DBADM과 같은 관리 권한(Authority)과 데이터베이스 객체에 대한 특정 권한(Privilege)으로 구분된다. 예를 들어, `SELECT` ON TABLE `EMP`와 같은 구문으로 특정 테이블에 대한 권한을 부여할 수 있다. 권한은 사용자 또는 그룹에게 직접 부여되거나, 작업을 간소화하기 위해 역할(Role)에 부여된 후 사용자에게 역할을 할당하는 방식으로 관리된다.

데이터 자체를 보호하기 위한 기술도 포함된다. 투명한 데이터 암호화(Transparent Data Encryption, TDE)는 디스크에 저장된 데이터 파일과 백업을 암호화하여 물리적 미디어 유출 시 데이터를 보호한다. 칼럼 수준 암호화는 애플리케이션 내에서 특정 중요한 열(예: 주민등록번호)만을 암호화할 수 있게 한다. 또한, 감사 정책(Audit Policy)을 구성하여 데이터베이스 내에서 발생하는 특정 이벤트(예: 실패한 로그인 시도, 권한 있는 사용자의 데이터 접근)를 추적하고 로깅할 수 있다.

이러한 보안 체계는 역할 기반 접근 제어(RBAC) 원칙과 결합되어, 복잡한 엔터프라이즈 환경에서도 데이터에 대한 최소 권한 원칙을 적용하고 규정 준수 요구사항을 충족시키는 데 기여한다.

성능 최적화는 IBM DB2 시스템의 효율성을 극대화하는 핵심 활동이다. 이는 주로 쿼리 튜닝과 효과적인 인덱싱 전략을 통해 이루어진다. DB2의 옵티마이저는 통계 정보를 바탕으로 쿼리 실행 계획을 생성하는데, 이 통계 정보가 부정확하거나 오래된 경우 비효율적인 계획이 선택될 수 있다. 따라서 `RUNSTATS` 명령을 정기적으로 실행하여 테이블, 컬럼, 인덱스에 대한 최신 통계 정보를 유지하는 것이 필수적이다. 또한, 쿼리 작성 시 불필요한 컬럼 선택을 피하고, 적절한 조인 방법(중첩 루프 조인, 해시 조인, 병합 조인)을 유도하는 힌트를 사용할 수 있다.

인덱싱은 데이터 접근 속도를 획기적으로 높이는 가장 일반적인 방법이다. DB2는 B-트리 인덱스, 클러스터형 인덱스, 비트맵 인덱스 등 다양한 인덱스 유형을 지원한다. 인덱스 설계 시 고려해야 할 요소는 다음과 같다.

성능 문제 분석을 위해 DB2는 `EXPLAIN` 도구를 제공한다. 이 도구는 쿼리의 예상 실행 계획을 시각적 또는 테이블 형태로 보여주어, 풀 테이블 스캔이 발생하는지, 인덱스 스캔이 효율적으로 사용되는지, 정렬 작업이 메모리에서 이루어지는지 등을 확인할 수 있게 한다. 또한, 버퍼 풀과 정렬 힙 같은 메모리 관련 설정을 모니터링하고 워크로드에 맞게 조정하는 것도 전체적인 처리량 향상에 기여한다.

IBM DB2를 설치하기 위해서는 하드웨어, 운영 체제, 소프트웨어 의존성 등 특정 시스템 요구사항을 충족해야 합니다. 요구사항은 선택한 DB2 에디션(예: DB2 Community Edition, DB2 Standard Edition, DB2 Advanced Edition)과 설치 대상 플랫폼(리눅스, 유닉스, 윈도우, 또는 IBM z/OS)에 따라 상이합니다.

일반적인 DB2 LUW(Linux, Unix, Windows) 배포판의 경우, 최소 2GB 이상의 RAM과 수 기가바이트의 디스크 여유 공간이 필요합니다. 구체적인 디스크 공간은 설치 유형(일반, 컴팩트, 사용자 정의)과 설치할 기능(예: 샘플 데이터베이스, 도구)에 따라 달라집니다. 지원되는 운영 체제 버전은 공식 IBM 지원 문서를 확인해야 하며, 예를 들어 레드햇 엔터프라이즈 리눅스, SUSE 리눅스 엔터프라이즈 서버, IBM AIX, 윈도우 서버 등의 특정 메이저 버전 및 서비스 팩을 요구합니다. 또한 JDK(Java Development Kit)의 특정 버전이나 C/C++ 컴파일러, 펄(Perl) 인터프리터 같은 추가 소프트웨어 프리���지이트가 필요할 수 있습니다.

설치 전에 `db2prereqcheck` 또는 `db2setup` 유틸리티를 실행하여 시스템이 모든 필수 조건을 충족하는지 확인하는 것이 좋습니다. 또한, DB2 인스턴스와 데이터베이스가 생성될 파일 시스템의 권한 설정과 네트워크 포트(기본 인스턴스 연결 포트는 50000) 사용 가능 여부도 점검해야 합니다. IBM z/OS 메인프레임 플랫폼의 경우, 별도의 시스템 요구사항과 설치 절차를 따릅니다.

IBM Db2 설치 후, 데이터베이스 서비스를 운영하기 위한 첫 번째 단계는 인스턴스를 생성하는 것이다. 인스턴스는 독립적인 메모리 영역과 프로세스 집합을 가지는 관리 단위이며, 하나의 서버에 여러 인스턴스를 생성하여 환경을 분리할 수 있다. 인스턴스 생성은 `db2icrt` 명령어를 사용하여 수행하며, 인스턴스 소유자 사용자와 그룹을 지정해야 한다. 생성된 인스턴스 내부에는 시스템 카탈로그 테이블, 디폴트 버퍼 풀, 로그 파일을 관리하는 여러 데이터베이스 관리 파일이 위치한다.

인스턴스가 준비되면, 실제 데이터를 저장할 데이터베이스를 생성한다. 데이터베이스 생성은 `CREATE DATABASE` 명령을 사용한다. 이 명령을 실행하면 지정된 스토리지 경로에 물리적 구조가 만들어진다. 주요 구성 요소는 다음과 같다.

데이터베이스 생성 시 코드 페이지, 테리토리, 기본 테이블스페이스의 페이지 크기와 경로 등을 정의할 수 있다. 예를 들어, 대용량 데이터를 처리할 경우 더 큰 페이지 크기(예: 32KB)를 사용하는 것이 유리하다. 데이터베이스가 생성되면 `CONNECT TO <데이터베이스명>` 명령으로 연결하여 SQL 작업을 시작할 수 있다. 인스턴스와 데이터베이스의 생성 및 초기 구성은 이후 성능과 관리 효율성에 지속적인 영향을 미치므로, 워크로드와 시스템 자원을 고려하여 신중하게 계획해야 한다.

IBM DB2의 백업 및 복원 작업은 데이터의 무결성과 지속성을 보장하는 핵심 운영 관리 기능이다. 백업은 데이터베이스 또는 테이블스페이스의 전체 또는 일부를 특정 시점의 상태로 보관 이미지를 생성하는 과정이다. 복원은 이 백업 이미지를 사용하여 데이터를 이전 상태로 되돌리는 과정으로, 하드웨어 장애, 사용자 오류, 논리적 손상 등 다양한 상황에서 데이터 손실을 최소화한다.

백업 작업은 주로 `BACKUP DATABASE` 명령을 통해 수행되며, 백업의 유형과 세분화 수준에 따라 여러 방식으로 구분된다. 주요 백업 유형은 다음과 같다.

복원(`RESTORE DATABASE`) 및 전진 복구(`ROLLFORWARD DATABASE`) 작업은 백업 이미지와 트랜잭션 로그를 결합하여 데이터베이스를 특정 시점으로 복구한다. 복원 작업은 백업 이미지를 지정된 위치로 적용하는 단계이며, 전진 복구는 복원된 백업 시점 이후에 기록된 로그를 재적용하여 데이터베이스를 최신 상태 또는 특정 시간점으로 되돌린다. 로그 파일의 보관 정책과 관리가 복구 가능성의 핵심 요소이다.

효율적인 백업 전략은 복구 시간 목표(RTO)와 복구 시점 목표(RPO)를 기반으로 설계된다. 예를 들어, 매주 전체 백업과 매일 증분 백업을 조합하거나, 고가용성을 위한 로그 쉬핑(log shipping) 기술을 활용할 수 있다. 또한 IBM Db2 백업 압축 기능을 사용하면 저장 공간과 백업 창 시간을 절약할 수 있다.

IBM DB2의 운영 상태를 실시간으로 점검하고 성능 문제를 진단하기 위해 다양한 모니터링 도구를 제공한다. 대표적인 명령줄 기반 도구로는 db2top이 있으며, 그래픽 사용자 인터페이스를 제공하는 도구로는 IBM Data Studio에 포함된 Health Center가 있다.

db2top은 유닉스 및 리눅스 환경에서 주로 사용되는 강력한 실시간 성능 모니터링 유틸리티이다. 이 도구는 터미널에서 실행되며, 데이터베이스 관리자에게 동적인 시스템 뷰를 제공한다. 주요 모니터링 항목은 다음과 같다.

Health Center는 DB2 데이터베이스의 상태를 시각적으로 모니터링하고 건강 상태를 평가하는 GUI 도구이다. 이 도구는 구성된 임계값을 기준으로 시스템을 지속적으로 분석하며, 잠재적인 문제(예: 로그 파일 공간 부족, 불량한 쿼리 실행 계획)가 감지되면 경고 또는 알림을 생성한다. 관리자는 이러한 정보를 바탕으로 성능 저하의 원인을 신속하게 파악하고 사전 예방 조치를 취할 수 있다.

이 외에도 DB2는 성능 뷰와 관리 뷰라는 시스템 카탈로그 테이블과 뷰를 제공하여, 사용자가 표준 SQL 쿼리를 실행하여 역사적 성능 데이터를 수집하고 분석할 수 있도록 지원한다. db2pd 및 db2mtrk와 같은 명령줄 유틸리티도 특정 문제를 깊이 있게 진단하는 데 활용된다.

일상 유지보수 작업은 IBM DB2 데이터베이스 시스템의 안정성, 성능 및 데이터 무결성을 장기적으로 보장하기 위한 필수적인 활동이다. 이러한 작업은 주기적으로 또는 특정 이벤트에 따라 수행되며, 데이터베이스 관리자(DBA)의 핵심 업무에 해당한다.

주요 일상 유지보수 작업에는 데이터베이스 및 테이블스페이스의 상태 점검, 통계 정보 갱신, 로그 파일 관리, 그리고 데이터 재구성이 포함된다. `db2pd`나 `db2top` 같은 모니터링 도구를 사용하여 버퍼 풀 히트율, 잠금(Lock) 대기 상황, 디스크 사용량 등을 정기적으로 확인한다. 특히, 쿼리 성능에 직접적인 영향을 미치는 테이블 및 인덱스에 대한 통계 정보는 `RUNSTATS` 명령을 통해 주기적으로 갱신해야 최적의 실행 계획을 유지할 수 있다. 또한, 트랜잭션 로그 파일이 가득 차는 것을 방지하기 위해 로그 아카이빙과 정리가 필요하다.

데이터 조각화를 관리하는 작업도 중요하다. 테이블에 대한 빈번한 갱신(UPDATE) 및 삭제(DELETE) 작업이 반복되면 데이터가 물리적으로 조각나고 저장 공간이 비효율적으로 사용될 수 있다. 이를 해결하기 위해 `REORG` 명령을 사용하여 테이블과 인덱스를 재구성한다. 이 작업은 성능을 회복하고 디스크 공간을 확보하는 데 도움을 준다. 유지보수 작업의 일정과 이력을 관리하기 위해 DB2 작업 센터(DB2 Task Center)를 활용하거나 사용자 정의 스크립트를 작성하여 자동화하는 것이 일반적이다.

IBM DB2는 표준 SQL을 지원하며, 데이터 정의, 조작, 제어를 위한 포괄적인 명령어 집합을 제공한다. DB2의 SQL 구현은 ANSI SQL 및 ISO SQL 표준을 준수하면서도 DB2 특유의 확장 기능을 포함한다. 주요 SQL 문법 범주로는 데이터 조회를 위한 SELECT 문, 데이터 조작을 위한 INSERT, UPDATE, DELETE 문, 그리고 데이터베이스 객체 관리를 위한 CREATE, ALTER, DROP 문 등이 있다. DB2는 또한 윈도우 함수, 공통 테이블 표현식(CTE), MERGE 문과 같은 고급 SQL 기능을 지원하여 복잡한 비즈니스 로직과 분석 쿼리를 효율적으로 처리할 수 있다.

SQL/PL(SQL Procedural Language)은 DB2에 저장 프로시저, 사용자 정의 함수, 트리거를 작성하기 위한 절차적 확장 언어이다. SQL/PL은 SQL 문장 내에 변수 선언, 조건문(IF-THEN-ELSE), 반복문(LOOP, WHILE), 예외 처리 등의 절차적 로직을 포함할 수 있게 한다. 이를 통해 애플리케이션 로직을 데이터베이스 서버 측으로 옮겨 네트워크 트래픽을 줄이고 성능을 향상시킬 수 있다. SQL/PL 코드는 `CREATE PROCEDURE`, `CREATE FUNCTION` 문을 사용하여 데이터베이스에 저장된다.

SQL과 SQL/PL의 주요 사용 사례를 비교하면 다음과 같다.

개발자는 CLP(Command Line Processor)나 IBM Data Studio와 같은 도구를 사용하여 SQL 및 SQL/PL 스크립트를 작성하고 실행할 수 있다. DB2는 또한 다른 프로그래밍 언어와의 통합을 위해 JDBC, ODBC, .NET 데이터 제공자 등의 인터페이스를 제공하여, 애플리케이션 내에서 SQL과 SQL/PL 루틴을 호출하는 것을 용이하게 한다.

응용 프로그램이 IBM DB2 데이터베이스와 통신하기 위해서는 표준화된 연결 인터페이스를 사용한다. 가장 일반적인 방법은 JDBC와 ODBC 드라이버를 활용하는 것이다. JDBC는 자바 기반 응용 프로그램을 위한 API이며, ODBC는 주로 C, C++, .NET 프레임워크, 그리고 다양한 플랫폼의 애플리케이션에서 사용되는 데이터베이스 접속 표준이다.

JDBC 연결을 구성하려면 먼저 DB2가 제공하는 JDBC 드라이버 JAR 파일을 응용 프로그램의 클래스패스에 추가해야 한다. 이후 `DriverManager.getConnection()` 메서드를 호출할 때 DB2 전용 연결 URL을 사용한다. 연결 URL의 일반적인 형식은 `jdbc:db2://호스트명:포트/데이터베이스명`이다. 드라이버는 Type 2(로컬 연결)와 Type 4(순수 자바 네트워크 연결)를 모두 지원하여 환경에 맞게 선택할 수 있다. 연결 설정 시 사용자 ID, 비밀번호 외에도 다양한 연결 속성을 지정하여 성능과 동작을 제어할 수 있다.

ODBC를 통한 연결은 운영 체제 수준의 ODBC 드라이버 관리자와 DB2용 ODBC 드라이버를 필요로 한다. 먼저 드라이버 관리자를 사용하여 데이터 원본(DSN)을 구성해야 한다. DSN은 데이터베이스 서버의 호스트 주소, 포트, 대상 데이터베이스 이름, 인증 정보 등을 포함한다. 구성이 완료되면 응용 프로그램은 이 DSN 이름을 참조하여 표준 ODBC API 호출을 통해 DB2에 연결한다. ODBC는 SQL 문의 실행과 결과 집합 처리를 위한 일관된 함수 집합을 제공한다.

두 연결 방식 모두 트랜잭션 관리, 저장 프로시저 호출, LOB 데이터 처리와 같은 고급 기능을 지원한다. 최신 버전의 드라이버는 보안 강화를 위해 SSL/TLS 암호화 연결을 필수로 권장하며, 연결 풀링을 통한 성능 최적화도 일반적으로 사용된다.

저장 프로시저는 데이터베이스 서버 내에 저장되어 클라이언트 응용 프로그램에 의해 호출될 수 있는 일련의 SQL 문과 제어 로직(예: 조건문, 반복문)을 포함하는 이름이 부여된 프로그램 객체이다. 주로 비즈니스 로직을 캡슐화하거나 복잡한 트랜잭션을 처리하며, 네트워크 트래픽을 줄이고 실행 성능을 향상시키는 데 사용된다. DB2는 SQL Procedural Language(SQL/PL)라는 자체 절차적 언어를 지원하여 저장 프로시저를 작성한다. 또한 Java, C, COBOL과 같은 외부 언어로 작성된 프로시저도 생성하고 등록할 수 있다.

사용자 정의 함수(UDF)는 하나의 값을 반환하는 프로그램 모듈로, 스칼라 함수와 테이블 함수로 구분된다. 스칼라 함수는 단일 행 연산에 사용되며 SELECT 리스트나 WHERE 절 등에서 일반 내장 함수처럼 호출된다. 테이블 함수는 결과 집합을 테이블 형태로 반환하므로 FROM 절에서 사용할 수 있다. 함수는 저장 프로시저와 마찬가지로 SQL/PL 또는 외부 언어로 작성된다. 주요 차이점은 저장 프로시저가 CALL 문으로 호출되고 결과를 출력 매개변수나 결과 집합으로 반환할 수 있는 반면, 함수는 표현식의 일부로 사용되며 반드시 단일 값을 반환해야 한다는 점이다.

생성된 저장 프로시저와 함수는 시스템 카탈로그 테이블에 메타데이터가 저장되며, 적절한 권한을 가진 사용자가 실행할 수 있다. 관리자는 `CREATE PROCEDURE`와 `CREATE FUNCTION` 문을 사용하여 이를 생성한다. 성능 관점에서, 저장 프로시저는 사전 컴파일되고 최적화된 실행 계획을 캐시할 수 있어 동일한 코드를 반복 실행할 때 효율적이다. 함수는 쿼리 내에서 사용될 때 해당 쿼리의 최적화 과정에 통합된다.

DB2의 주요 발전은 코드네임 'Viper'로 알려진 DB2 9 버전에서 시작되었다. 2006년에 출시된 이 버전은 IBM이 인포믹스와 XML 데이터베이스 기술을 통합한 결과물로, 관계형 데이터와 XML 데이터를 동일한 테이블 내에서 네이티브 형태로 저장하고 처리하는 'pureXML' 기술을 최초로 도입했다[6]. 이는 당시 SQL과 XQuery를 함께 사용할 수 있게 하여 하이브리드 데이터 모델 지원의 기준을 제시했다.

DB2 10 버전(코드네임 'Galileo')은 2012년에 공개되어 성능과 효율성에 중점을 두었다. 핵심 개선 사항으로는 '멀티템퍼럴 테이블' 기능을 들 수 있다. 이 기능을 통해 애플리케이션 변경 없이도 데이터의 시간적 변천을 자동으로 추적하고 과거 특정 시점의 데이터 상태를 쿼리할 수 있게 되었다. 또한, '스토리지 최적화'를 통해 압축 알고리즘이 향상되고 메모리 내 처리 성능이 개선되어 같은 하드웨어에서 더 많은 작업 부하를 처리할 수 있게 되었다.

2016년에 출시된 DB2 11 버전(코드네임 'Cancun')은 가용성과 운영 효율성을 한층 높였다. '온라인 스키마 변경' 기능이 강화되어 인덱스 생성이나 테이블 변경 작업을 시스템 가동 중에 더욱 원활하게 수행할 수 있게 되었다. 보안 측면에서는 '행 및 열 수준 접근 제어' 기능이 도입되어 세분화된 데이터 보호가 가능해졌다. 또한, 쿼리 실행 계획의 안정성을 높이고 블루믹스 클라우드 환경과의 통합을 본격적으로 지원하기 시작했다. 이 버전들은 지속적으로 인 메모리 처리 기술을 발전시켜 트랜잭션 처리와 분석 워크로드의 성능을 극대화하는 방향으로 진화했다.

IBM Db2는 다양한 사용자 요구와 예산에 맞춰 여러 상용 에디션과 무료 커뮤니티 에디션을 제공한다. 각 에디션은 기능 세트, 성능 확장성(예: 코어 수 제한), 그리고 고급 기능의 포함 여부에서 차이를 보인다.

주요 에디션은 다음과 같이 구분된다. Db2 Community Edition은 비상업적 용도나 소규모 개발/테스트 환경을 위한 무료 에디션이다. 표준적인 관계형 데이터베이스 기능과 SQL을 지원하지만, 코어 수나 메모리 사용에 제한이 있으며 고급 가용성 기능은 포함되지 않는다. Db2 Standard Edition은 중소규모 부서별 애플리케이션을 대상으로 한다. 기본적인 고가용성 구성과 암호화, 압축 기능을 포함하며, 라이선스는 서버의 프로세서 코어 수를 기준으로 한다. Db2 Advanced Edition은 대규모 데이터 웨어하우징, 트랜잭션 처리, 그리고 통합 분석 작업을 위한 최상위 에디션이다. 인메모리 기술(BLU Acceleration), 고급 압축, 그리고 가장 포괄적인 보안 및 가용성 기능(예: PureScale, HADR)을 모두 제공한다.

에디션별 핵심 차이점을 요약하면 아래 표와 같다.

이 외에도 특정 하드웨어 플랫폼(예: IBM Power Systems)에 최적화된 에디션이나, 클라우드 전용 구독 모델이 별도로 존재한다. 사용자는 처리할 데이터의 규모, 필요한 가용성 수준, 그리고 예산에 따라 적절한 에디션을 선택한다.

Db2 on Cloud는 IBM이 제공하는 완전 관리형 클라우드 데이터베이스 서비스이다. 이 서비스는 IBM Cloud, AWS, Microsoft Azure 등 주요 퍼블릭 클라우드 플랫폼에서 제공되며, 사용자는 인프라 관리 부담 없이 IBM DB2의 핵심 기능을 활용할 수 있다. 서비스 형태는 데이터베이스 엔진, 스토리지, 백업, 패치 적용, 모니터링 등이 모두 플랫폼 측에서 관리되는 DBaaS 모델을 따른다. 사용자는 구독 기반으로 용량과 성능 계층을 선택하여 신속하게 데이터베이스 인스턴스를 프로비저닝하고, 애플리케이션 개발에 집중할 수 있다.

주요 기능으로는 자동화된 백업과 특정 시점 복구, 기본 제공되는 암호화, 그리고 탄력적인 스케일링이 포함된다. 고가용성을 위해 다중 가용 영역에 걸친 배포 옵션을 제공하며, HADR 기술을 클라우드 환경에 적용한 구성도 지원한다. 관리 콘솔이나 CLI를 통해 데이터베이스 성능 모니터링, 사용자 접근 권한 관리, 로그 확인 등의 운영 작업을 수행할 수 있다.

Db2 on Cloud는 하이브리드 클라우드 환경을 중시하는 전략의 일환으로, 온프레미스에 구축된 Db2 데이터베이스와의 원활한 통합을 지원한다. IBM Data Gateway나 CDC 기술을 이용하여 클라우드와 온프레미스 간의 데이터 동기화 및 연계를 가능하게 한다. 또한, 머신 러닝 및 AI 기능과의 통합, JSON과 같은 현대적 데이터 형식에 대한 네이티브 지원을 통해 클라우드 네이티브 애플리케이션 개발을 촉진한다.

IBM은 Db2를 컨테이너 환경에서 실행할 수 있도록 지원하며, 특히 Kubernetes와의 통합을 적극적으로 추진하고 있다. 이는 하이브리드 클라우드 및 멀티 클라우드 전략에 부합하는 현대적인 배포 모델을 제공하는 것을 목표로 한다. Db2는 공식 Docker 이미지를 제공하여 개발자와 관리자가 로컬 개발, 테스트, 또는 프로덕션 환경에 Db2 인스턴스를 빠르게 배포할 수 있게 한다.

Db2의 Kubernetes 지원은 주로 IBM Db2 Operator를 통해 이루어진다. 이 오퍼레이터는 Kubernetes 클러스터 내에서 Db2 데이터베이스의 수명 주기 관리를 자동화하는 소프트웨어 확장이다. 오퍼레이터를 사용하면 사용자는 선언적인 방식(예: YAML 파일)으로 데이터베이스 인스턴스의 구성을 정의할 수 있으며, 오퍼레이터는 해당 상태를 유지하기 위해 필요한 파드(Pod), 서비스(Service), 영구 볼륨(Persistent Volume) 등의 Kubernetes 리소스를 생성하고 관리한다. 이를 통해 복잡한 수동 구성 작업을 줄이고, 확장성과 고가용성을 보다 쉽게 구현할 수 있다.

컨테이너화된 Db2의 주요 배포 시나리오와 이점은 다음과 같다.

이러한 접근 방식은 기존의 물리적 또는 가상 머신 기반 설치에 비해 유연성과 이식성을 크게 향상시킨다. 그러나 데이터의 지속성(Persistence) 관리, 네트워킹 구성, 보안 정책 적용 등 운영 상의 새로운 고려사항이 발생하며, 이를 위해 Kubernetes의 영구 볼륨 클레임(PVC)과 네트워크 정책 같은 기능을 적절히 활용해야 한다. IBM은 Db2 Warehouse와 같은 제품에도 컨테이너 기반 배포 옵션을 제공하며, 지속적으로 Kubernetes 생태계에 대한 지원을 강화하고 있다.

IBM DB2, Oracle Database, Microsoft SQL Server는 엔터프라이즈 관계형 데이터베이스 관리 시스템 시장의 주요 경쟁 제품이다. 이들은 모두 트랜잭션 처리, 데이터 웨어하우징, 고가용성 솔루션을 제공하지만, 역사적 배경, 핵심 아키텍처, 라이선스 정책, 운영 체제 지원 측면에서 뚜렷한 차이점을 보인다.

가장 두드러진 차이는 개발 배경과 주 플랫폼이다. Oracle Database는 다양한 유닉스 계열 시스템과 Linux, Windows를 광범위하게 지원하는 크로스 플랫폼 제품으로 시작했다. Microsoft SQL Server는 Windows 운영 체제와 긴밀하게 통합되어 해당 생태계에 최적화된 솔루션이다. 반면 DB2는 IBM 메인프레임 시스템(예: z/OS)과의 깊은 연계성으로 유명하며, DB2 for LUW(Linux, UNIX, Windows) 버전을 통해 오픈 시스템 시장에도 진출했다. 라이선스 모델과 비용 구조도 상이하다. Oracle은 프로세서 코어 수나 사용자 수를 기준으로 한 복잡한 라이선싱과 높은 유지보수 비용으로 알려져 있다. Microsoft SQL Server는 일반적으로 코어 기반 라이선싱을 사용하며, Windows Server 라이선스와의 번들 형태가 흔하다. IBM DB2는 고정된 사용자 수나 가상 프로세서 코어(vCPU)를 기준으로 한 비교적 단순한 라이선스 옵션을 제공하며, 커뮤니티 에디션을 통한 무료 사용도 가능하다[8].

기술적 특징으로는 고가용성과 확장성 접근 방식이 다르다. Oracle은 Real Application Clusters를 통해 공유 디스크 아키텍처 기반의 활성-활성 클러스터링을 제공한다. Microsoft SQL Server는 주로 Always On 가용성 그룹을 이용한 공유 무(shared-nothing) 아키텍처의 고가용성 및 재해 복구 솔루션을 강조한다. IBM DB2는 고가용성 재해 복구를 통한 로그 기반 복제와, DB2 PureScale을 통한 공유 디스크 기반의 거의 무제한에 가까운 확장성을 두 가지 축으로 제공한다. 내장 프로그래밍 언어도 차이점을 보이는데, Oracle은 PL/SQL, SQL Server는 T-SQL, DB2는 SQL/PL을 각각 사용한다. 표준 SQL 준수도와 최적화 기능은 세 제품 모두 매우 높은 수준이지만, 특정 벤더 고유의 확장 구문과 성능 힌트는 호환되지 않는다.