이전 developerWorks 기사에서 MS SQL Server 2000 스킬을 활용하여 DB2를 학습하는 방법에 대해 소개한 적이 있다. SQL Server보다는 Oracle 쪽에 배경 지식이 많은가? 그렇다면 이 기사를 계속 읽기 바란다. 이 기사에서는 Oracle 11g에 대한 기존 지식을 바탕으로 DB2 9.7을 빠르게 습득할 수 있는 방법을 보여줄 것이다.
DB2 9.7에는 비용 관리와 애플리케이션 개발 단순화에 도움이 되는 새로운 기능이 포함되었다. 압축, pureXML, 관리 효율성 및 성능과 같은 여러 가지 영역에서 많은 부분이 개선되고 향상되었다. 이 기사에서는 DB2 9.7에서 지원되는 새로운 기능을 소개하는 것 외에도, DB2와 Oracle의 기초 개념을 서로 비교하며 설명하는 데 초점을 맞추겠다.
참고: 본 기사의 나머지 부분에서는 "Oracle"과 "DB2"를 각각 Oracle 11g와 Linux, UNIX 및 Windows용 DB2 9.7을 지칭하는 용어로 사용하겠다.
본격적인 논의를 시작하려면 Oracle에서 사용하는 아키텍처와 이를 DB2와 어떻게 비교할 수 있을지 이해할 필요가 있다. 그림 1은 Oracle의 시스템 구조를 보여준다. 이를 DB2의 시스템 구조를 보여주는 그림 2와 비교해보자. 본 기사를 읽으면서 수시로 이 두 그림을 참조하면 이해하는 데 도움이 될 것이다.
그림 1. Linux, UNIX 및 Windows에서의 Oracle 시스템 구조
그림 2. Linux, UNIX 및 Windows 시스템 구조 상의 DB2
인스턴스의 개념은 Oracle과 DB2에서 모두 비슷하다. 두 경우 모두 인스턴스는 백그라운드 프로세스와 공유 메모리의 조합이다. 둘 사이의 주요 차이점은 Oracle에서는 인스턴스당 하나의 데이터베이스만 있을 수 있는 반면, DB2에서는 여러 개의 데이터베이스가 하나의 인스턴스를 공유할 수 있다는 점이다.
Oracle에서는 데이터베이스와 인스턴스 사이에 일대일 대응이 되기 때문에 CREATE DATABASE 명령으로 데이터베이스를 작성하여 인스턴스를 암시적으로 작성한다. 또는 Database Configuration Assistant를 사용하거나 Oracle 9i의 경우 NEW 옵션이 지원되는 ORADIM 유틸리티를 사용하여 시스템에 Oracle 인스턴스를 작성할 수 있다. 또한, SID(System Identifier)나 서비스 이름, 인스턴스 비밀번호, 최대 사용자 수, 시작 모드 등을 포함한 정보를 제공해야 한다. 이와 유사하게, ORADIM 유틸리티에서 DELETE 옵션을 사용하여 인스턴스를 삭제할 수 있다. 이때, SID 또는 서비스 이름을 입력할 필요가 있다. 설치 프로세스 중에 데이터베이스를 새로 작성하지 않는 경우에는 Oracle을 새로 설치할 때 기본 인스턴스가 작성되지 않는다.
DB2에서는 Windows 플랫폼에 제품을 설치하고 나면 "DB" 인스턴스가 기본적으로 작성된다. Linux와 UNIX에서는 기본 인스턴스 이름을 "db2inst1"이라
한다. 같은 시스템에서 다른 인스턴스를 작성하려면 간단히 db2icrt <instance name> 명령을 실행하면 된다.
그림 3은 DB2 Control Center GUI에서 db2icrt 명령으로 작성한 DB2_01이라는 인스턴스를 보여준다.
그림 3. DB2 인스턴스를 보여주는 DB2 Control Center GUI
명령행 인터페이스에서 주어진 DB2 인스턴스를 참조하려면 환경 변수 DB2INSTANCE를 사용한다. 이 변수를 사용하면 모든 명령이 적용되는 현재
활성 인스턴스를 지정할 수 있다. 예를 들어, DB2INSTANCE를 PROD로 설정한 다음 create database MYDB1 명령을 실행하면 PROD
인스턴스와 연관된 데이터베이스가 작성된다. 그 대신 DB2 인스턴스에서 이 데이터베이스를 작성하려면, 우선 DB2INSTANCE의 값을 DB2로 변경해야 한다. 이는 사용자가
인스턴스 간에 전환하려고 할 때도 사용되는 ORACLE_SID(System Identifier)와 유사하다.
작업할 인스턴스를 손쉽게 식별하는 또 다른 방법은 그림 3에 표시된 것처럼 DB2 Control Center GUI를 사용하는
방법이다. 이 도구에서 새로운 인스턴스에 대한 항목을 보려면 Instances를 마우스 오른쪽 단추로 클릭하고 Add를 선택하여
GUI에 인스턴스를 추가해야 할 수도 있다. DB2에서 인스턴스를 삭제하려면 db2idrop <instance name> 명령을 실행하면 된다.
요컨대, Oracle에서는 Database Configuration Assistant를 사용하여 인스턴스를 작성, 수정, 시작, 중지 및 삭제할 수 있는 반면, DB2에서는 비슷한 목적으로 Control Center GUI를 사용할 수 있다. 또한, Oracle 인스턴스는 데이터베이스와 일대일 관계만 가질 수 있지만, DB2에서는 그렇지 않다. DB2 인스턴스에는 여러 데이터베이스가 존재하고 동시에 사용될 수 있다.
Oracle에서는 CREATE DATABASE 명령을 사용하거나 Database Configuration Assistant를 사용하여 데이터베이스를 수동으로 작성할 수 있다. 데이터베이스를 수동으로 작성하려면 OS 변수 설정, 매개변수 파일 준비, 데이터베이스 파일 작성을 포함하여, 일련의 단계를 먼저 수행해야 CREATE DATABASE 명령을 실행할 수 있다.
메타데이터 정보는 기본 테이블과 그에 해당하는 뷰로 구성되는 Data Dictionary에서 저장 및 관리한다. 기본 테이블은 데이터베이스 작성 중에 자동으로 작성되고, catalog.sql 및 catproc.sql 스크립트를 실행하여 뷰를 생성한다.
따라서 Oracle 데이터베이스를 다음 세 가지 파일 유형의 콜렉션으로 본다.
- 데이터 파일: 데이터베이스를 실제로 구현한 실제 데이터를 포함한다. (DB2의 컨테이너와 유사함)
- 다시 실행 파일: DB2의 트랜잭션 로그와 같은 것이다.
- 제어 파일: 데이터베이스 무결성을 유지보수하고 확인하기 위한 정보가 들어 있다.
그림 2에 나타낸 것처럼, DB2에서는 인스턴스에 여러 개의 데이터베이스가 포함될 수 있다. 각각의 데이터베이스는 실제로 폐쇄적이며 독립적인 유닛이다. 각 데이터베이스에는 데이터베이스 작성에 성공했을 때 기본적으로 작성되는 고유의 카탈로그 테이블스페이스, 임시 테이블스페이스 및 사용자 테이블스페이스가 있다. DB2에는 DB2 시스템에서 연결할 수 있는 모든 데이터베이스의 항목을 포함하는 시스템 데이터베이스 디렉토리로 알려진 2진 파일이 있다. 이 디렉토리는 인스턴스 레벨에서 유지된다.
인스턴스가 작성될 때 기본적으로 작성되는 데이터베이스는 없다. 따라서 create database 명령을 사용하여 데이터베이스를 명시적으로 작성해야 한다. 또한, 그림 4와 5에 나타낸 것처럼 Control Center를 사용하여 데이터베이스를 작성할 수 있다.
그림 4. Control Center GUI를 사용하여 DB2 데이터베이스 작성
그림 5. Control Center GUI를 사용하여 DB2 데이터베이스 작성(계속)
그림 5에서는 Show Command를 클릭할 때 어떻게 되는지도 볼 수 있다. 모든 DB2 Control Center GUI 화면에서는 백그라운드에서 실제로 실행되는 SQL문 또는 명령을 볼 수 있다. 이런 명령을 스크립트에 저장하여 나중에 실행하거나, 명령행 프로세서(CLP) 도구 또는 Command Center GUI 도구에서 복사하여 실행할 수 있다. 이들 도구는 각각 Oracle의 SQL*Plus 및 iSQL *Plus와 같은 것이다.
'DROP DATABASE' 명령을 사용하거나 DB2 Control Center GUI에서 DB2 데이터베이스를 삭제할 수 있다. Oracle에는 그런 명령이 없고, 연관된 모든 데이터 파일을 삭제하는 방법으로 데이터베이스를 삭제한다.
한 인스턴스 내부의 데이터베이스는 일반적으로 서로 상호작용하지 않는다. 하지만, 애플리케이션이 둘 이상의 데이터베이스와 상호작용할 필요가 있는 경우에는 페더레이션 지원을 사용하면 된다. 페더레이션에 대한 기사는 참고자료 섹션을 참조한다.
Oracle에서는 데이터가 데이터 파일이라는 파일에 실제로 저장된다. 이는 DB2에서 데이터가 실제로 저장되는 컨테이너와 비슷한 개념이다. 모든 Oracle 데이터베이스에는 SYSTEM이라는 테이블스페이스가 있는데, 이는 데이터베이스 작성 시 Oracle에서 자동으로 작성하는 것이다. 데이터베이스가 작성된 후 사용자, 임시 및 인덱스 데이터에 대해 다른 테이블스페이스가 작성되어야 하며, 이런 테이블스페이스에 사용자를 지정해야 테이블스페이스를 사용할 수 있다.
DB2에서 테이블스페이스는 논리 테이블과 실제 컨테이너 간의 계층으로 사용되는 논리 오브젝트이다. 테이블스페이스를 작성할 때 이를 특정 컨테이너뿐 아니라 특정 버퍼 풀(데이터베이스 캐시)과도 연관할 수 있다. 따라서 성능을 유연하게 관리할 수 있다. 예를 들어, "핫" 테이블이 있는 경우 테이블 자체의 버퍼 풀과 연관된 자체 테이블스페이스에서 "핫" 테이블을 정의할 수 있다. 이는 이 테이블의 데이터를 메모리에 지속적으로 캐시하는 데 도움이 된다.
DB2에서는 CREATE DATABASE 명령의 기본값을 사용할 때 데이터베이스 작성 시 3개의 기본 테이블스페이스가 자동으로 작성된다. 표 1은 기본 DB2 테이블스페이스를 설명한 것이다.
표 1. 데이터베이스를 기본값으로 작성할 때 기본적으로 작성되는 DB2 테이블스페이스
| 테이블스페이스 이름 | 설명 |
|---|---|
| SYSCATSPACE | 메타데이터를 포함한 카탈로그 테이블스페이스 |
| TEMPSPACE1 | 결합 및 정렬과 같은 조작을 수행할 때 사용되는 시스템 임시 테이블스페이스이다. 이 테이블스페이스의 이름을 변경할 수 있다. |
| USERSPACE1 | 이 테이블스페이스는 선택적이며, 테이블 작성 시간에 테이블스페이스가 명시적으로 표시되지 않을 때 사용자 테이블을 저장하는 데 사용될 수 있다. |
DB2의 데이터베이스는 독립적인 유닛이기 때문에, 데이터베이스 사이에서 테이블스페이스가 공유되지는 않는다. 테이블스페이스는 한 데이터베이스 내에서만 알려져 있으므로, 두 개의 다른 데이터베이스가 같은 이름을 가진 테이블스페이스를 가질 수 있다. 그림 2에서 이 점을 확인할 수 있는데, MYDB1 데이터베이스에 MYTBLS라는 이름의 테이블스페이스가 있고 MYDB2 데이터베이스에 같은 이름의 테이블스페이스가 있다.
DB2 테이블스페이스는 SMS(System-Managed Spaces) 또는 DMS(Database-Managed Spaces)로 분류할 수 있다. SMS 테이블스페이스는 운영 체제에 의해 관리되고 디렉토리만 될 수 있다. SMS 테이블스페이스는 필요에 따라 자동으로 증가하므로, SMS는 최소한의 관리로 훌륭한 성능을 제공한다. DMS 테이블스페이스는 DB2에 의해 관리되며 파일 또는 원시 디바이스일 수 있다. 이 유형의 테이블스페이스는 최상의 성능을 감안한 것이지만, 약간의 관리 작업이 필요하다. 예를 들어, 테이블스페이스가 자동으로 증가하지 않으므로 테이블스페이스에 할당하려는 공간을 미리 지정해야 한다.
Oracle에는 스토리지 모델에 SMS 개념이 없지만, 데이터 파일이 DB2 DMS 테이블스페이스와 유사하다. 즉, 테이블스페이스에 데이터 파일을 추가하거나, 데이터 파일의 크기를 증가시키거나, 테이블스페이스를 새로 추가하여 데이터베이스 크기를 증가시킬 수 있다.
아래의 표 2는 Oracle 데이터베이스 또는 테이블스페이스가 DB2 데이터베이스 또는 테이블스페이스에 어떻게 맵핑되는지 보여준다.
표 2. Oracle 데이터베이스와 DB2 데이터베이스 및 테이블스페이스와의 맵핑 관계
| Oracle 데이터베이스 또는 테이블스페이스 | DB2 데이터베이스 또는 테이블스페이스 |
|---|---|
| SYSTEM은 카탈로그(Data Dictionary) 정보를 보유한 테이블스페이스이다. | SYSCATSPACE(카탈로그 테이블스페이스). Oracle에서와 같이, 이 정보는 데이터베이스 레벨에서만 유지된다. |
| Data Dictionary는 (테이블 및 뷰의 형태로 메타데이터를 포함하고) SYSTEM 테이블스페이스 내부에 있다. | (SYSIBM 스키마에 의해 식별되는) System Catalog Table과 (SYSCAT 또는 SYSSTAT 스키마에 의해 식별되는) 시스템 뷰는 SYSCATSPACE 테이블스페이스 내부에 있다. |
| SCOTT 데이터베이스 | SAMPLE 데이터베이스 |
| TEMP 테이블스페이스 | System Temporary 테이블스페이스(기본적으로 tempspace1이라 함) |
| UNDO 테이블스페이스 | N/A |
| USER 테이블스페이스 | 사용자 테이블스페이스. 기본적으로 USERSPACE1은 보통 데이터베이스 작성 후에 작성된다. |
앞서 지적한 바와 같이, Oracle의 데이터 버퍼 개념은 DB2의 버퍼 풀과 같지만 DB2에서는 여러 개의 버퍼 풀이 존재할 수 있다. 사용자가 작성할 수 있는 버퍼 풀의 개수는 미리 정할 수 없으며, 어떤 이름이라도 가질 수 있다.
Oracle에서 블록의 개념은 DB2에서 페이지의 개념과 가장 비슷하다. DB2 페이지의 크기는 4k, 8k, 16k 또는 32k일 수 있다. 테이블 행은 한 페이지에만 표시되도록 맞추어야 하고, Oracle과 같이 다른 페이지까지 넘어갈 수는 없다.
Oracle 오브젝트 이름의 양식은 다음과 같다.
[Schema_name.]object_name[@database]
DB2에서도 오브젝트는 다음과 같이 두 파트의 구조를 가질 수 있다.
Schema_name.object_name
Oracle과 마찬가지로, DB2 스키마 이름은 오브젝트를 로컬에서 그룹화하는 데 사용된다. 하지만, 중요한 차이점은 DB2에서는 스키마 이름이 사용자 ID와 일치하지 않아도 된다는 점이다. IMPLICIT_SCHEMA라는 권한을 가진 사용자는 누구든 존재하지 않는 스키마를 사용하여 오브젝트를 작성할 수 있다. 예를 들어, "Peter"가 IMPLICIT_SCHEMA 권한을 가지고 있고 다음 명령을 실행한다고 해보자.
CREATE TABLE WORLD.TABLEA (lastname char(10))
이 경우, WORLD.TABLEA 테이블이 작성되고 여기서 WORLD는 새로 작성되는 스키마이다. Peter가 스키마를 명시적으로 표시하지 않은 경우에는 연결 ID가 기본적으로 사용되기 때문에 PETER.TABLEA 테이블이 작성된다.
DB2에서는 항상 데이터베이스에 연결한 후 데이터베이스 관련 명령을 실행한다. 따라서 이 아키텍처에서는 오브젝트 이름에 데이터베이스 이름을 포함할 필요가 없다.
테이블, 뷰 및 인덱스는 기본적으로 Oracle과 DB2에서 모두 동일하다.
DB2는 특정 쿼리 또는 워크로드에 대한 인덱스를 권장할 때 사용할 수 있는 Design Advisor라는 유틸리티를 제공한다. db2advis 명령을 사용하여 DB2 Control Center 또는 DB2 CLP에서 Design Advisor를 호출할 수 있다. DB2에서는 인덱스가 테이블 정의에 직접 연결된다. 예를 들어, DMS 테이블스페이스를 사용할 때 다음과 같이 인덱스가 상주할 수 있을지 테이블스페이스를 지정할 수 있다.
CREATE TABLE mytable (col1 integer, col2 char(10)) in tbls1 index in tbls2
위 예제에서는 테이블의 데이터는 'tbls1' 테이블스페이스에 저장되고, 인덱스 페이지는 'tbls2' 테이블스페이스에 저장될 것임을 보여준다. 이는 CREATE INDEX 문에서 인덱스가 있을 테이블스페이스를 지정하는 옵션을 제공하는 Oracle 구문과는 대조를 이룬다.
또한, DB2에서 인덱스가 작성되고 나면 인덱스 정의의 어떤 절도 변경할 수 없다. 변경사항을 구현하려면 인덱스를 삭제하고 다시 작성해야 한다.
Oracle과 마찬가지로, 다른 데이터베이스에 있는 DB2 테이블, 뷰 및 인덱스가 같은 이름을 가질 수 있다. 같은 데이터베이스 내부의 테이블과 뷰는 이름이 달라야 하지만, 이름이 같은 인덱스를 기존 테이블 또는 뷰로 작성하는 것은 허용된다.
스토어드 프로시저, 트리거 및 사용자 정의 함수(UDF)
Java, C, C++, REXX, Fortran 및 COBOL을 포함하여, DB2 프리컴파일러에서 지원하는 언어로 DB2 스토어드 프로시저를 작성할 수 있다. 하지만, 사용 권장 언어는 Oracle의 PL/SQL과 아주 흡사한 SQL PL(SQL Procedural Language)이다. SQL PL 스토어드 프로시저는 작성하기 쉽고 성능이 우수하다. DB2 스토어드 프로시저 개발로 JDBC 드라이버 유형 2 및 4를 사용하는 SQLJ 및 Java도 지원한다. 유형 3은 지원이 중단되었다.
트리거와 함수 개발 시에는 SQL PL의 서브세트인 인라인 SQL/PL을 사용할 수 있다. Data Studio 도구를 사용하여 DB2 스토어드 프로시저와 사용자 정의 함수를 손쉽게 작성, 빌드, 디버그 및 배치할 수 있다.
일반적으로, Oracle은 보통 initSID.ora로 지칭되는 텍스트 파일에 모든 세션과 시스템 관련 매개변수를 저장한다. 그러나 이 텍스트 파일은 지속적이지 못한 특성이 있기 때문에, Oracle에서 Oracle 9i부터 서버에 저장되는 2진 매개변수 파일인 SPFILE(Server Parameter File)을 도입했다. SPFILE은 인스턴스 종료 및 시작 과정에서도 계속 유지된다. initSID.ora 파일이 계속 사용되지만, SPFILE을 사용할 수 없을 때 사용된다. SPFILE을 도입하기 전에는, 매개변수에 영향을 미친 모든 ALTER SYSTEM 및 ALTER SESSION 명령이 그 인스턴스나 세션 중에만 지속되었다. DBA는 데이터베이스 인스턴스의 리바운드를 하려 할 때마다 initSID.ora 텍스트 파일을 수동으로 수정해야 했다. 네트워크 액세스 구성은 일반적으로 리스너의 경우 listener.ora에, 클라이언트 액세스의 경우 tnsnames.ora에 저장된다.
DB2를 사용하는 경우, 구성 매개변수가 인스턴스 레벨에서는 데이터베이스 관리자 구성 파일로 알려진 파일에 저장되고 데이터베이스 레벨에서는 데이터베이스 구성 파일로 알려진 파일에 저장된다. 이런 매개변수는 대부분 동적으로 변경될 수 있다. 즉, 매개변수 값 변경을 적용하기 위해 인스턴스를 중지한 후 다시 시작하거나 데이터베이스에서 모든 연결을 강제 실행할 필요가 없다. DB2가 구성 정보를 저장하는 파일을 직접 편집할 수 없다.
CLP에서 특정 데이터베이스 관리자 매개변수를 수동으로 변경하려면 UPDATE
DBM CFG USING <parameter name> <new value> 명령을 사용한다.
CLP에서 특정 데이터베이스 매개변수를 수동으로 변경하려면 UPDATE DB CFG FOR
<database name> USING <parameter name> <new value> 명령을 사용한다.
이들 명령은 Oracle의 ALTER SYSTEM 및 ALTER SESSION과 같은 것이다. 또는 Control Center를 사용하여 이런 매개변수의 값을 검토하고 변경할 수 있다. 주어진 인스턴스를 마우스 오른쪽 단추로 클릭하고 Configure Parameters를 선택하면 그림 6에 표시된 창이 나타난다.
그림 6. DB2 Database Manager 구성 매개변수(인스턴스 레벨)
데이터베이스 레벨에서 주어진 데이터베이스를 마우스 오른쪽 단추로 클릭하고 Configure Parameters를 선택하면 그림 7에 표시된 창이 나타난다.
그림 7. 데이터베이스 구성 매개변수(데이터베이스 레벨)
DB2에서는 시스템 구성에 사용할 수 있는 많은 매개변수를 제공한다. 하지만, 시스템을 손쉽게 자동으로 구성하려면 사용자가 제공하는 몇 가지 정보를
바탕으로 데이터베이스 관리자 및 데이터베이스 구성 매개변수를 최적의 값으로 설정하는 autoconfigure 명령(또는 Configuration
Advisor GUI)을 사용한다. 그림 8은 Configuration Advisor를 나타낸 것이다.
그림 8. - DB2 Configuration Advisor
구성 파일 외에도, DB2에서는 플랫폼에 특정한 구성을 위해 보통 DB2 Registry 변수도 사용한다. DB2 Registry 변수는 Windows 레지스트리와 전혀 아무런 관계도 없다는 점에 주의하자. 이런 변수를 검토하고 변경하려면 db2set 명령을 사용한다.
연결(네트워크 액세스) 정보는 시스템 데이터베이스 디렉토리, 로컬 데이터베이스 디렉토리 및 노드 디렉토리에 저장된다. 이들은 2진 파일로서 CATALOG 및 UNCATALOG 명령으로만 수정할 수 있다.
다음으로 우리는 메모리 아키텍처, 백그라운드 프로세스 및 스레드를 살펴보고 Oracle 및 DB2에서 이들이 사용되는 방식을 비교하고 대조해본다.
그림 9: Oracle 메모리 아키텍처 및 백그라운드 프로세스
Oracel의 SGA(System Global Area)는 인스턴스에 대한 정보를 저장하는 공유 메모리 영역의 그룹이다. 예로는 명령문 캐시, 다시 실행 로그 버퍼 및 데이터 버퍼 캐시가 포함된다. PGA(Program Global Area) 및 UGA(User Global Area ) 공유 메모리 영역에는 서버 프로세스 및 사용자 세션을 위한 데이터와 제어 정보가 포함된다.
Oracle은 같은 시스템 내에서 여러 개의 인스턴스를 지원하지만 백그라운드 프로세스가 공유되지는 않는다. 예를 들어, 한 시스템에 있는 세 개의 인스턴스에는 세 개의 백그라운드 프로세스 세트가 필요하다. 따라서 일반적으로 같은 시스템 내에는 하나의 데이터베이스, 하나의 인스턴스 그리고 여러 개의 스키마가 있는 것이 좋다.
그림 10: DB2 메모리 아키텍처, 백그라운드 프로세스 및 스레드
DB2와 Oracle은 모두 공유 메모리 영역을 사용하지만, DB2의 메모리 아키텍처는 Oracle과는 약간 다른 방식으로 구현된다. 한 DB2 인스턴스에 둘 이상의 데이터베이스가 포함될 수 있으므로 두 가지 레벨의 구성이 존재한다. 이전 섹션에서 언급한 바와 같이, DBM CFG 파일에서는 인스턴스 레벨 구성을 완료할 수 있고 DB CFG 파일에서는 데이터베이스 레벨 구성을 완료할 수 있다. 두 레벨에서 모두 메모리 사용량에 맞춰 구성 매개변수를 조정할 수 있다. 아래 섹션에서는 DB2의 메모리 구조 및 다른 백그라운드 프로세스에 대해 좀 더 자세히 설명한다.
시작할 때 인스턴스와 데이터베이스에 모두 메모리가 할당되는 Oracle과는 달리, DB2는 다른 레벨에서 메모리를 할당한다. 이는 주로 DB2 인스턴스에 복수의 데이터베이스가 포함될 수 있기 때문이다. DB2에는 다음 세 가지 주 메모리 구조가 있다.
-
인스턴스 공유 메모리: 이것은
db2start명령을 사용하여 인스턴스를 사용할 때 할당되는 데이터베이스 관리자 글로벌 공유 메모리를 가리키며,db2stop명령을 실행하여 인스턴스를 중지할 때까지 할당된 상태로 남는다. - 데이터베이스 공유 메모리: 이것은 데이터베이스를 처음으로 활성화하거나 연결할 때 할당되는 데이터베이스 글로벌 메모리를 가리킨다. 할당되는 메모리에는 버퍼 풀, 잠금 목록, 데이터베이스 힙, 유틸리티 힙, 패키지 캐시 및 카탈로그 캐시가 포함된다.
- 애플리케이션 공유 메모리: 이것은 애플리케이션이 데이터베이스에 연결하고 연결된 클라이언트가 요청한 작업을 수행하는 에이전트에 의해 사용될 때 할당되는 메모리를 가리킨다. 데이터베이스에 연결된 각 애플리케이션에는 자신에게 할당된 메모리가 있으므로, 애플리케이션 공유 메모리에 영향을 미치는 매개변수를 정확하게 구성하는 것이 무엇보다도 중요하다.
DB2 데이터베이스 서버는 데이터베이스 애플리케이션 요청을 처리하거나 디스크에 로그 레코드를 작성하는 것처럼 다양한 태스크를 수행해야 한다. 각각의 태스크는 일반적으로 별도의 EDU(Engine Dispatchable Unit)에 의해 수행된다. Windows, Linux 및 UNIX용 DB2에서는 서버 활동이 스레드의 형태로 수행된다. DB2 스레드 및 프로세스는 다음 레벨에서 작동한다. 다음은 모든 관련 정보를 정리한 목록은 아니지만, 중요한 스레드와 프로세스를 설명한 것이다.
- 인스턴스 레벨: 다음은 인스턴스가 시작될 때 초기화되는 프로세스와 스레드이다.
- DB2 Daemon Spawner(db2gds): 각 인스턴스에 대해 시작되는 글로벌 디먼 프로세서(UNIX에만 있음)
- DB2 System Controller(db2sysc): 주 DB2 프로세스
- DB2 Watchdog(db2wdog): 다른 모든 프로세스의 상위 프로세스
- DB2 Format Log(db2fmtlg): Oracle의 ARCn 프로세스와 유사하게, 로그 경로에서 로그 파일을 미리 할당함
- 자율 컴퓨팅 디먼(db2acd): 상태 모니터, 자동 유지보수 유틸리티 및 관리 태스크 스케줄러를 호스트한다. 이 프로세스를 이전에는 db2hmon이라고 했다.
- 데이터베이스 레벨: 데이터베이스에 연결할 때 초기화되는 프로세스이다.
- DB2 Log Reader(db2loggr): Oracle의 PMON 프로세스의 서브세트와 유사하다. 이 프로세스에서는 롤백, 복구 다시 시작 및 롤포워드 중에 로그 파일을 읽는다.
- DB2 Log Writer(db2loggw): 로그 버퍼에서 디스크의 트랜잭션 로그 파일로 로그를 비운다. Oracle의 LGWR 프로세스와 같다.
- DB2 Page Cleaner(db2pclnr): Oracle의 DBWR 프로세스와 같은 이 프로세스는 페이지를 디스크에서 BP로 이동하기 전에 버퍼 풀을 정리한다.
- DB2 Prefetcher(db2pfchr): 디스크에서 페이지를 검색하여 해당 페이지가 필요하기 전에 버퍼 풀에 위치시킨다.
- DB2 Deadlock Detector(db2dlock): 교착 상태 탐지기 프로세스이다.
- DB2 Self-Tuning Memory Manager(db2stmm): 자율적인 자동 튜닝 메모리 관리 기능을 위한 것이다.
- 애플리케이션 레벨: 데이터베이스에 연결하는 각 애플리케이션에는 애플리케이션과 연관된 애플리케이션 레벨 백그라운드 프로세스의
자체 공유가 있다. 이러한 방법은 다음과 같다.
- DB2 Communication Manager(db2ipccm): 로컬에서 연결된 각각의 클라이언트에 대한 프로세스 간 통신(IPC) 프로세스이다.
- DB2 TCP Manager(db2tcpcm): TCP/IP를 사용하여 연결 중인 원격 클라이언트를 위한 TCP 통신 관리자 프로세스이다.
- DB2 Coordinating Agent(db2agent): 애플리케이션을 대신하여 모든 요청을 처리하는 스레드이다.
- DB2 Pooled Gateway Agent(db2agntgp 및 db2agntgp): 각각 원격 데이터베이스와 로컬 데이터베이스에서 풀링되는 에이전트이다.
DB2의 프로세스에 대한 전체적인 설명을 보려면 'Everything you wanted to know about DB2 processes' 기사를 참조한다.
Oracle에서는 잠금이 수동 또는 자동으로 이루어질 수 있다. Oracle Lock Manager가 행 레벨에서 테이블 데이터를 암시적으로 잠글 수 있거나,
다음 SQL문을 사용하여 트랜잭션 또는 세션 레벨에서 기본 잠금을 대체할 수 있다.
1. SET TRANSACTION ISOLATION LEVEL
2. LOCK TABLE
3. SELECT FOR UPDATE
Oracle은 실행 취소 세그먼트에서 데이터를 실행 취소하여 구현되는 Multi-Version Read Consistency라는 메커니즘을 지원한다.
DB2에서는 커미트되지 않은 읽기(Uncommitted Read), 커서 안정성(Cursor stability), 읽기 안정성(Read stability) 및 반복 가능한 읽기(Repeatable
Read)와 같은 ANSI 표준 격리 레벨을 구현한다. Uncommitted Read 격리 레벨을 사용하지 않는 경우 사용자는 커미트된 데이터만 볼 수 있다. 행 잠금은 격리 레벨에
따라 암시적으로 인식된다. 잠글 수 있는 데이터베이스 오브젝트는 테이블스페이스, 테이블 및 행이지만, 테이블과 테이블스페이스만 명시적으로 잠글 수
있다. 기본 행 잠금을 사용하는 대신 LOCK TABLE 명령을 사용하여 테이블을 잠글 수 있다.
Oracle과는 달리, DB2에서는 잠금이 데이터 페이지가 아니라 메모리에 저장된다. LOCKLIST 데이터베이스 구성 매개변수를 사용하여 잠금에 사용 가능한 메모리를 구성할 수 있는 한편, MAXLOCKS 구성 매개변수는 특정 애플리케이션의 잠금을 위한 최대 메모리 양을 정의한다.
DB2 9.7에서는 잠금 이벤트 보고가 향상되었다. 새로운 잠금 이벤트 모니터는 지정된 지속 시간을 초과하는 잠금 제한시간, 교착 상태 및 잠금 대기에 대한 정보를 수집한다. XML 문서나 데이터베이스 테이블에서 이 데이터에 액세스하거나 Java 기반 도구(db2evmonfmt)를 사용하여 XML 또는 텍스트 문서에서 이 데이터를 읽을 수 있다.
이전에 그랬듯이 기본적으로 커미트된 데이터만 리턴되도록 허용하는 cur_commit라는 데이터베이스 구성 매개변수가 새로
사용되었지만, 리더는 이제 라이터가 행 잠금을 릴리스할 때까지 기다리지 않는다. 그 대신, 리더는 현재 커미트된 버전을 기반으로 하는 데이터, 즉 쓰기 조작이
시작되기 전의 데이터를 리턴한다.
Oracle과 DB2는 모두 기본 및 고급 보안 기능을 갖춘 안전한 데이터베이스이다. Oracle에는 다음과 같이 4가지의 다른 사용자 인증 방법이 있다.
- 데이터베이스: 데이터베이스는 사용자의 식별과 인증을 모두 수행한다.
- 외부: 운영 체제 또는 네트워크 서비스가 인증을 수행한다.
- 글로벌 인증 및 권한 부여: SSL이 전역적으로 사용자를 인증한다.
- 프록시 인증 및 권한 부여: 중간 계층 서버가 인증을 수행한다.
CREATE USER 명령을 사용하여 사용자를 작성할 때 인증 방법이 지정된다. 이런 사용자에 대한 정보가 들어 있는
여러 가지 Data Dictionary 뷰가 있다.
DB2에서는 데이터베이스 내부에 사용자가 존재하지 않고, 운영 체제에서 사용자를 관리한다. 데이터베이스 로그인 정보는 어떤 데이터베이스 테이블에서도 보존되지 않는다. 사용 중인 운영 체제에 상관없이 어떤 사용자든 DB2에 액세스할 수 있겠지만, 지정된 DB2 권한 또는 사용 권한이 부여되지 않은 사용자가 할 수 있는 일은 많지 않다. 권한과 사용 권한의 부여 및 취소는 Control Center GUI를 통해 손쉽게 처리할 수 있다. 우선, 사용 가능한 운영 체제 사용자 또는 그룹에서 Control Center에 사용자 또는 그룹을 추가해야 할 수도 있다.
또한, DB2에서는 "역할"이라는 용어가 사용되지 않는 대신 특정 그룹이나 사용자에게 사용 권한이 부여되는 Oracle의 데이터베이스 역할과 유사한 "권한"이란 용어를 사용한다. DB2에서 지원되는 권한은 SYSADM, SYSCTRL, SYSMAINT, SYSMON, SECADM, DBADM 및 LOAD이다.
SYSADM, SYSCTRL 및 SYSMAINT 권한은 GRANT SQL문을 사용하여 부여할 수 없다. 특정 데이터베이스 관리자 구성 매개변수를 수정해야만 이런 특수한 권한을 설정할 수 있다.
또한, DB2에서는 Oracle의 시스템 및 스키마 오브젝트 사용 권한과 유사한 "특권"이라는 용어를 사용한다. 데이터베이스 특권(연결, 탭 작성 등) 및 데이터베이스 오브젝트 특권(스키마, 테이블, 뷰 등)이 있다. 그림 11은 Control Center GUI에서 얻은 DB2 보안 정보를 보여준다. Change User 창에 표시되는 탭은 대부분 DB2에서 지원하는 특권에 대응된다.
그림 11. DB2 보안
DB2의 인증에서는 사용자 이름 및 비밀번호의 암호화가 이루어질 뿐 아니라, 데이터가 클라이언트와 서버 간의 네트워크를 거쳐 이동할 때 데이터의 암호화도 고려한다. 인증 프로세스의 위치는 데이터베이스 관리자 구성 매개변수 AUTHENTICATION의 값으로 결정된다.
다음은 DB2에 대한 인증을 사용할 때 유효한 옵션이다.
- SERVER_ENCRYPT - 이 값으로 서버에서 인증이 이루어지도록 지정할 수 있다. 연결 중에 지정되는 사용자 ID와 비밀번호는 암호화되어 서버로 전송되며, 여기서 서버 측의 사용자 ID 및 비밀번호와 비교된다. 정확히 일치하는 경우 해당 사용자는 데이터베이스에 액세스가 허용된다.
- KRB_SERVER_ENCRYPT - 서버에서 KERBEROS 인증 또는 암호화된 SERVER 인증 스킴을 허용하는 것으로 지정하는 옵션이다.
- DATA_ENCRYPT - 이 설정은 서버에서 SERVER 인증을 허용하고 클라이언트와 서버 간에 네트워크를 통해 이동하는 데이터가 암호화된다는 점도 지정하는 것이다.
- DATA_ENCRYPT_CMP - 서버가 암호화된 SERVER 인증 스킴과 사용자 데이터의 암호화를 허용하는 것으로 지정하는 옵션이다. 이 인증 유형은 DATA_ENCRYPT 인증 유형을 지원하지 않는 하위 레벨 제품과의 호환성을 고려한 것이다.
- GSS_SERVER_ENCRYPT - 서버가 GSS API 기반 플러그인 인증 또는 암호화된 서버 인증 스킴을 허용하도록 지정하는 옵션이다.
AUTHENTICATION 인스턴스 매개변수를 업데이트하려면(예: DATA_ENCRYPT의 값으로 업데이트) 아래에 표시된 명령을 사용한다.
목록 1. AUTHENTICATION 인스턴스 매개변수 업데이트
UPDATE DBM CFG USING AUTHENTICATION DATA_ENCRYPT
db2stop
db2start
|
DB2는 LBAC(Label Based Access Control) 메커니즘을 제공하여 보안을 더욱 확장한다. LBAC 기능을 사용하면 개별 행 및 테이블 컬럼에 대한 읽기 및 쓰기 액세스를 더욱 세밀하게 제어할 수 있다. DB2에서는 LBAC 오브젝트를 조작하는 데 필요한 보안 관리자 역할(SECADM)이 제공되었다. 오브젝트에 액세스하려는 사용자는 자신에게 부여된 보안 레이블이 있어야 한다. 보안 레이블이 일치되는 경우 액세스가 허용되고, 그렇지 않으면 액세스가 거부된다.
데이터베이스 보안에는 사용 권한과 권한을 넘어선 다른 측면이 있다. 간단히 말해, Oracle과 DB2 사이에는 다음과 같은 몇 가지 차이점과 유사점이 있다.
사용자 인증 및 권한 부여
Oracle에서는 사용자 작성 후 사전에 저장된 암호화된 비밀번호를 사용한다. DB2에서는 사용자 인증을 위한 비밀번호를 지원하고 인증을 위한 기본 운영 사용자를 사용한다. Oracle과 DB2는 둘 다 LDAP(Oracle Internet Directory 및 IBM Directory Server)을 지원한다. 뿐만 아니라, 단일 사인온(SSO)도 둘 다 지원한다.
데이터 암호화
Oracle은 신용카드 번호 및 매우 중요한 비즈니스 데이터와 같이 보안에 민감한 데이터를 암호화할 수 있는 데이터 암호화 기술을 지원한다. 스토리지에서 DB2 데이터를 암호화하기 위한 옵션은 다음과 같다.
- 암호화 및 복호화 기본 제공 함수인 ENCRYPT, DECRYPT_BIN, DECRYPT_CHAR 및 GETHINT를 사용하여 데이터베이스 테이블 내에 있는 데이터를 암호화할 수 있다.
- IBM Database Encryption Expert를 사용하여 기본 운영 체제 데이터 및 백업 파일을 암호화할 수 있다.
- AI 운영 체제에서 DB2 Enterprise Server Edition 시스템을 실행 중이고 파일 레벨 암호화에만 관심이 있는 경우 암호화된 파일 시스템(EFS)을 사용하여 운영 체제 데이터와 백업 파일을 암호화할 수 있다.
네트워크 암호화
Oracle은 Oracle Advanced Security로 네트워크 암호화를 제공한다. Oracle에서는 DES, 3DES 및 RC4 산업 표준 암호화를 사용한다. 클라이언트와 DB2 데이터베이스 사이를 이동 중인 데이터를 암호화하려면 DATA_ENCRYPT 인증 유형 또는 DB2 데이터베이스 시스템의 SSL(Secure Sockets Layer) 지원 기능을 사용하면 된다.
감사 내역
Oracle을 사용하면 사용자 및 오브젝트 관련 내역을 감사할 수 있다. 의심스러운 쿼리를 조사하고 분석하기 위해 로그 마이너를 사용할 수도 있다. DB2에서도 유사한 감사 기능을 제공한다. 그것은 바로 db2audit 유틸리티이다.
이 섹션에서는 Oracle과 DB2의 XML 지원을 비교한다. Oracle 9i Release 2와 함께 제공되는 Oracle XML DB 기능은 관계형 테이블에 작은 조각으로 나뉘거나(분해되거나) CLOB로 저장되는 XMLTYPE 테이블 및 컬럼을 정의하여 XML 저장, 검색 및 스키마를 관리할 수 있는 길을 제시했다. Oracle 10g에서는 몇 가지 XML 문서 관리 방법이 개선되었다. 예를 들어, 다시 가져올 필요 없이 기존 데이터를 맵핑하여 스키마의 변화를 동적으로 반영할 수 있다. Oracle 11G에서는 2진 XML이라는 세 번째 종류의 XML 지원 기능이 도입되었다. 그래서 현재 Oracle에서 XML 데이터를 저장하는 방법은 다음과 같다.
- CLOB(스키마리스 스토리지라고도 함)를 사용하는 구조화되지 않은 스토리지
- XML을 관계형 오브젝트로 맵핑하는 구조적 스토리지
- 2진 XML 스토리지
DB2의 pureXML 기술에서는 XML 문서를 기본적으로 저장한다. 즉, 내부적으로 트리 형식으로 저장한다. 또한, XML 확장, Xquery 및 Xpath와 함께 SQL을 사용하여 관계형 데이터와 XML 데이터에 액세스할 수 있다. XML 문서를 기본적으로 저장하는 것이 더 나은 접근 방식이며, IBM의 연구에 따르면 XML 문서를 검색하여 불러오는 성능이 더 뛰어나고 어떤 프로그램은 코드 행 수가 줄어든 것으로 밝혀졌다. DB2 Control Center, 명령행 프로세서, IBM Data Studio 및 Microsoft Visual Studio용 IBM 데이터베이스 추가 기능에서 DB2 XML 데이터 유형이 지원된다.
데이터베이스에서 pureXML 기능을 사용하려면 데이터베이스를 UNICODE로 작성한다(예: UTF-8 코드 세트 사용). 테이블을 작성하기 전에 UNICODE 데이터베이스를 작성하지 않으면 아래에 표시된 것과 같은 오류가 발생한다.
SQL1239N XML features can only be used in a Unicode database with a single database partition. SQLSTATE=42997 |
DB2는 이전 버전과 같은 방식으로 관계형 데이터를 저장한다. 하지만, XML 데이터는 계층 구조 형식으로 저장된다(XDM(Xquery Data Model)을 사용하여 트리로 저장). XML과 관계형 서비스가 모두 긴밀하게 통합된다. XML 문서를 저장하려면 아래 예제에 표시된 것처럼 사용자가 테이블을 작성하고 새 데이터 유형을 사용하기 위한 열을 지정할 필요가 있다.
목록 2. XML 데이터 유형으로 DB2 테이블 작성
CREATE TABLE T
(ID INT PRIMARY KEY NOT NULL, COMMENT VARCHAR(1000) NOT NULL, DOCUMENT XML)
in ttspace compress yes@
|
XML 문서는 XDM(XQuery Data Model)에서 기본적으로 구문 분석된 계층 구조 형식으로 저장되므로, 변환 또는 맵핑할 필요가 없다. XML 문서 저장에 사용되는 형식은 문서 처리에 사용되는 형식이다. 이는 성능 향상을 꾀하기 위한 것이다.
백업, 복원 및 가져오기와 같은 유틸리티는 다른 테이블과 같이 XML 컬럼을 포함한 테이블에 적용된다. INSERT 문을 사용하거나 DB2 IMPORT 유틸리티를 사용하여 XML 컬럼에 XML 데이터를 삽입할 수 있다. 써드파티에서 받은 XML 문서를 가져오기 전에 미리 정의된 XML 스키마에 대해 이런 문서를 유효성 검증하는 것이 좋다. XML 스키마에 대해 등록하려면 DBA가 REGISTER XML SCHEMA 명령을 실행해야 하며, 등록 프로세스를 완료할 수 있도록 COMPLETE XML SCHEMA로 끝내야 한다. DB2에서는 XML 문서의 서브세트 또는 전체 문서에서 인덱스를 작성할 수 있는 기능도 지원한다. 인덱싱할 특정 요소/속성을 가리키는 인덱스를 작성할 때 XPATH를 지정해야 한다.
DB2를 사용할 때는 다음 네 가지 방법으로 관계형 및 XML 데이터에 액세스할 수 있다.
- 일반 SQL(XQuery가 관련되지 않음)
- SQL/XML, 즉 SQL에 임베드된 XQuery
- 독립형 언어로서의 XQuery(SQL이 관련되지 않음)
- 임베드된 SQL을 포함한 Xquery
DB2 9.7에는 사용자 정의 함수(User Defined Funcion)에 XML 유형에 대한 지원과 같은 XML 기능이 추가로 포함되었다. DB2 9.7에서 향상된 중요한 기능은 LOAD 유틸리티를 사용하여 XML 데이터를 로드할 수 있는 기능이다. 또한, 파티션된 테이블에서는 DB2 V9.7 또는 이전 버전으로 작성한 XML 데이터에 대한 인덱스가 파티션되지 않는다. DB2 버전 9.7 수정팩 1부터는 파티션된 테이블에서 XML 데이터에 대한 인덱스를 파티션되거나 파티션되지 않도록 작성할 수 있다.
보다 심층적인 내용을 살펴보려면 무엇보다도 Query DB2 XML data with XQuery, Query DB2 XML Data with SQL과 같이, IBM pureXML 기능에 대한 developerWorks 기사를 읽어보기 바란다.
Oracle Partitioning에서는 데이터베이스에서 데이터를 파티션으로 배치하는 방법을 제어하는 여러 가지 파티셔닝 전략을 제공한다. 기본적인 전략은 범위, 목록 및 해시 파티셔닝이다.
DB2의 테이블 파티셔닝(범위 파티셔닝이라고도 함)은 Oracle의 파티셔닝과 유사하다. 이 파티셔닝 방법을 사용하면 기본적으로 단일 논리 테이블을 하나 이상의 테이블스페이스에서 여러 개의 실제 스토리지 오브젝트로 구분할 수 있다. 각각의 오브젝트가 '파티션'에 상응하며, 각각의 테이블스페이스에 매우 쉽게 액세스할 수 있는 데이터 범위가 포함될 수 있다.
DB2에서는 여러 가지 방법으로 데이터를 파티셔닝할 수 있고, 같은 데이터에 대해 이런 방법을 동시에 적용할 수 있다. 혼동을 피하기 위해, 이 파티셔닝을 제공하는 서로 다른 방법에 대해 간단히 설명한다.
- 데이터베이스 파티셔닝 - 데이터베이스의 여러 논리 노드에서 키 해시로 데이터 분산(DPF)
- 범위/테이블 파티셔닝(DB2 9에서 지원함) - 한 논리 데이터베이스 파티션 내에 있는 여러 개의 실제 오브젝트에 대해 키 범위별로 데이터 분할
- MDC(MULTI DIMENSIONAL CLUSTERING) - 여러 개의 키 값으로 테이블 또는 테이블의 범위에서 데이터 구성
버전 9.7에서는 데이터로 파티션된 테이블(파티션되지 않은 인덱스라고도 함)에 있는 모든 파티션의 데이터 행을 참조하는 인덱스를 가지거나, 각각의 데이터 파티션에 연관된 인덱스 파티션이 있도록 그 자체가 파티션된 인덱스를 가질 수 있다. 파티션된 테이블에 대해 파티션되지 않은 인덱스와 파티션된 인덱스를 모두 가질 수 있다.
다음은 l_shipdate >= '01/01/2006'과 l_shipdate <= '03/31/2006'이 포함된 행이 테이블스페이스 ts1에 저장되고 l_shipdate >= '04/01/2006'과 l_shipdate <= '06/30/2006'이 포함된 행이 테이블스페이스 ts2에 저장되는 방식으로 customer라는 테이블을 작성하는 예제이다. 더 자세한 설명은 developerWorks 기사 Table partitioning in DB2 9에서 확인할 수 있다.
목록 3. 테이블의 범위 파티셔닝
CREATE TABLE customer (l_shipdate, l_name CHAR(30))
IN ts1, ts2, ts3, ts4, ts5
PARTITION BY RANGE(l_shipdate)
(STARTING FROM ('01/01/2006')
ENDING AT ('12/31/2006')
EVERY (3 MONTHS))
|
Migrate from Oracle or Sybase to DB2 in weeks 기사의 표 1에서 Oracle과 DB2의 파티셔닝 용어를 비교하여 정리한 내용을 볼 수 있다.
Oracle에서는 인덱스, 테이블 및 행 레벨 압축이라는 세 가지 압축 기능을 제공한다. 이런 기능을 잘못 계획하면 성능에 나쁜 영향을 미칠 수 있다.
Oracle에서는 버전 8i 이후로 인덱스 압축 기능이 도입되었다. 압축할 수 있는 인덱스는 비트맵, btree 및 인덱스 구성 테이블이다. 인덱스 압축 기능의 사용법은 간단하다. 예를 들어, 이 압축 기능으로 인덱스를 작성하는 방법은 다음과 같다.
목록 4. 압축을 이용한 인덱스 작성
CREATE INDEX ord_customer_ix_demo
ON orders (customer_id, sales_rep_id)
COMPRESS 1;
|
처음부터 압축 기능을 이용해 작성하지 않은 인덱스의 경우 인덱스를 변경하여 압축할 수 있다. 목록 5는 압축을 포함하도록 인덱스를 변경하는 방법을 보여주는 예제이다.
목록 5. 압축을 이용한 인덱스 변경
alter index ord_customer_ix_demo rebuild compress |
현재, Oracle에서는 압축해야 할 인덱스를 정확히 나타내기 위해 자동화된 관리자를 제공하지 않는다. Oracle CBO에 대한 심층적 지식을 갖춘 숙련된 DBA가 적절히 계획해야 인덱스 압축을 통한 이점을 대부분 올바로 누릴 수 있다.
한편, 테이블 압축 기능은 Oracle 9i 릴리스 2에서 도입되었다. 이 기능을 사용하면 전체 테이블, 테이블 파티션 및 구체화된 뷰를 압축할 수 있다. 모든 파티션이나 일부 파티션에 압축을 적용할 수 있다. 파티션되지 않은 테이블에 테이블 압축을 사용할 수 있지만, OLTP 워크로드에서 파티션되지 않은 테이블에 테이블 압축을 사용하면 삽입 및 업데이트 성능에 나쁜 영향을 미칠 수 있으므로 이는 바람직하지 않다. Oracle 테이블 압축에서는 데이터베이스 블록에서 중복된 값이 제거되고 블록 내에서 압축되지 않은 데이터를 다시 작성하기 위해 정보가 저장된다.
다음 예제는 압축 기능을 사용한 파티션 테이블 작성법을 나타낸 것이다.
목록 6. 압축을 이용한 테이블 작성
CREATE TABLE costs_demo (
prod_id NUMBER(6), time_id DATE,
unit_cost NUMBER(10,2), unit_price NUMBER(10,2))
PARTITION BY RANGE (time_id)
(PARTITION costs_old
VALUES LESS THAN (TO_DATE('01-JAN-2003', 'DD-MON-YYYY')) COMPRESS,
PARTITION costs_q1_2003
VALUES LESS THAN (TO_DATE('01-APR-2003', 'DD-MON-YYYY')),
PARTITION costs_q2_2003
VALUES LESS THAN (TO_DATE('01-JUN-2003', 'DD-MON-YYYY')),
PARTITION costs_recent VALUES LESS THAN (MAXVALUE));
|
테이블을 압축된 테이블로 전환하려면 alter table <table name> move compress를 사용한다. 하지만, 압축된 테이블에서는 열을 추가하거나 삭제할 수 없다.
DB2 9.7에서는 깊은 압축(deep compression)이라고도 하는 행 압축을 통해 여러 행에서 반복되는 패턴의 값을 더 짧은 기호 문자열로 대체하여 데이터 행을 압축한다. DB2 9.7에서 사용 가능한 다양한 데이터 압축 기술 중에서, 행 압축은 스토리지를 가장 많이 절약할 가능성이 있는 기술이다. 행 압축에서는 반복적인 패턴이나 항목과 숫자 키 사이의 맵핑을 저장하는 사전을 작성해야 한다. 지능적인 압축 알고리즘이 적용되어 있어, 디스크 공간 절약 효과가 현저히 나타나지 않을 행은 압축하지 않는다.
Oracle의 키 압축과는 달리, DB2의 행 압축에서는 키를 지정할 필요가 없다.
CREATE TABLE 또는 ALTER TABLE 명령을 통해 개별 테이블 레벨에서 압축이 지원된다. 예를 들면, 다음과 같다.
목록 7. COMPRESSION YES로 테이블 작성/변경
CREATE TABLE Sales COMPRESS YES ALTER TABLE Sales COMPRESS YES |
(테이블 작성 마법사에서 두 번째 단계인) 열 정의 단계 중에 DB2 Control Center를 사용하여 같은 효과를 거두려면 (다음 다이어그램에서 보여주는 것처럼) 패널 아래쪽에 있는 Store table data in a compressed format 선택란을 선택해야 한다.
그림 12. DB2 Control Center - 압축을 이용한 테이블 작성
테이블의 데이터를 압축할 수 있게 된 후, REORG가 수행될 때만 테이블 사전이 빌드된다. 이 사전은 이후에 REORG 조작이 수행될 때마다 업데이트된다. 압축된 데이터는 디스크와 메모리에 모두 보관되고 DB2는 로그 파일에 저장된 사용자 데이터도 압축하여 로그 파일 크기를 줄인다.
파티션된 테이블의 각 파티션에 다른 압축 사전이 있을 수 있고 DPF에 있는 테이블의 각 파티션에 다른 압축 사전이 있을 수 있다.
데이터 행 압축 외에, DB2 9.7에서 제공하는 다른 압축 메커니즘으로는 다음과 같은 것이 포함된다.
- NULL 및 기본값 압축(V8 GA): 가변 길이 열에서 길이가 0인 널 데이터와 시스템 기본값을 위한 압축이다.
- 다차원 클러스터링(V8 GA): 수천 개의 레코드에 대해 하나씩 블록 인덱스 항목을 사용하여 인덱스 압축의 양식을 구현한다.
- 데이터베이스 백업 압축(V8 FP4): 백업 이미지의 크기를 줄이기 위한 압축이다.
- XML 구문 분석
Oracle 11g에서는 몇 가지 튜닝 기능이 개선되었다. Oracle은 다음 튜닝 영역을 자동화했다.
- Redo Logfile Sizing Advisor - 이 기능에서는 잦은 검사점으로 인한 과도한 디스크 I/O를 피하기 위해 최적 크기의 다시 실행 로그 파일을 권장한다.
- Automatic Checkpoint Tuning - Oracle Database는 현재 정상적인 처리량에 많은 영향을 주지 않고 복구 시간을 단축하기 위해 검사점을 자동으로 튜닝할 수 있다. 더 이상 검사점 관련 매개변수를 설정할 필요가 없다.
- Automatic Shared Memory Tuning - Automatic Shared Memory Tuning은 자동 튜닝 알고리즘을 통해 SGA(System Global Area) 메모리 관련 매개변수(버퍼 캐시, 공유 풀)의 구성을 자동화한다. 이 튜닝을 통해 데이터베이스 구성을 단순화하고 사용 가능한 메모리를 가장 효율적으로 사용하고 성능을 개선할 수 있다.
- Transaction Rollback and Recovery Monitoring - 이 기능을 사용하면 트랜잭션 롤백 시간을 예상할 수 있다. 또한, 복구 중인 트랜잭션의 진행 상태를 모니터링하고 평균 트랜잭션 복구 속도를 예상할 수 있다.
- SQL Tuning - SQL Tuning Advisor는 고비용의 SQL문을 자동으로 튜닝한다.
- Automatic Storage Manager - ASM(Automatic Storage Manager)은 관리 또는 Oracle 관련 파일을 단순화한다.
Oracle은 세그먼트 및 실행 취소 관리자와 같은 관리자도 제공한다. 세그먼트 관리자는 한 오브젝트 내에서 공간 단편화의 레벨을 바탕으로 하며, 결과적으로 어떤 오브젝트가 새로운 온라인 축소 조작에 좋은 후보인지 여부를 알려준다. 또한, 이 관리자는 세그먼트의 증가 경향 이력에 관한 보고서를 제공하며, 특히 용량 계획에 요긴한 정보를 제공하는 것으로 입증되었다.
반면, 실행 취소 관리자(Undo Advisor)는 관리자가 플래시 백 및 비 플래시 백 기능에서 모두 실행 취소 테이블스페이스의 크기를 정하면서 올바른 판단을 내리는 데 도움이 된다. 또한, 관리자가 오래된 '스냅샷이 너무 오래됨' 문제점을 피하기 위해 UNDO_RETENTION을 적절히 설정하는 데 도움이 된다.
DB2 9.7에는 환경 관리에 도움이 되는 여러 가지 자율 기능이 있으며, 이를 통해 자동 구성, 자동 복구, 자동 최적화 및 자동 보호할 수 있다. 자율 컴퓨팅은 발생하는 상황을 간파하고 이에 적절히 대응함으로써 데이터베이스 관리자의 컴퓨팅 환경 관리 부담을 없애준다.
DB2 9.7에는 여러 가지 메모리 구성 매개변수의 값을 자동으로 설정하여 메모리 구성 태스크를 단순화하는 Self Tuning Memory Manager라는 자동 튜닝 메모리 기능이 있다. 이 기능을 사용하면 디스패처로 작동하는 자동 튜너가 사용 가능한 메모리 자원을 계산하여 메모리를 소비하는 여러 데이터베이스 소비자에게 자원을 동적으로 분배한다. 자동 튜닝 메모리는 단일 파티션 데이터베이스에만 적용된다.
AUTOCONFIGURE 명령을 사용하면 버퍼 풀 크기, 데이터베이스 구성 및 데이터베이스 관리자 구성 데이터베이스의 초기값을 계산하여 표시할 수 있고, 권장되는 이런 값을 적용하는 옵션이 있다.
자동 스토리지는 디스크 및 파일 시스템에서 데이터베이스의 크기를 자동으로 증가시키고 이에 따라 데이터베이스의 크기도 자동으로 증가시키므로, DBA가 스토리지 컨테이너를 관리할 필요가 없다. DB2 9.7에서 데이터베이스를 작성할 때, 자동 스토리지 관리 기능이 기본적으로 사용된다.
DB2 9.7에는 다음과 같은 유지보수 기능을 자동으로 수행하기 위해 사용되는 자동 유지보수 기능이 있다.
- 필요에 따라 수행되는 전체 데이터베이스 백업 기능을 제공하는 자동 데이터베이스 백업
- 자동 통계 콜렉션. DB2는 어떤 통계가 필요하고 업데이트할 필요가 있는지 판단한 다음, 백그라운드에서 RUNSTATS 유틸리티를 자동으로 실행한다.
- 자동 테이블 및 인덱스 재구성. DB2는 통계가 업데이트된 테이블과 인덱스를 주기적으로 검사하여 테이블 또는 인덱스 재구성이 필요한지 판단하고, 이런 조작이 필요할 때마다 적절히 스케줄링한다.
데이터베이스 작성과 유지보수, 네트워크, 관리 GUI, 성능 튜닝, 데이터 이동 및 백업-복구 도구와 같이 다양한 영역의 도구를 살펴보겠다. 그림 13에서 DB2 9.7 GUI 도구를 보여준다.
그림 13. DB2 9.7 GUI 도구
Oracle 및 DB2 9.7에서 유사한 태스크가 어떻게 수행되는지 살펴보자.
데이터베이스 작성 및 유지보수
Oracle은 데이터베이스 작성을 위한 GUI 도구로서 dbca(Database Configuration Assistant)를 제공한다. 데이터베이스 유지보수를 위해, Oracle은 Oracle Enterprise Manager를 제공한다. DB2 Control Center에서 DB2 데이터베이스를 작성하고 유지보수할 수 있다.
네트워크
Oracle은 네트워크 구성을 위해 netca(Network Configuration Assistant)를 제공한다. 또는 Oracle Network Manager를 사용하여 서비스 이름, 리스너, 프로파일 및 Oracle 이름 서버를 구성할 수 있다. DB2는 CATALOG 명령을 사용하여 노드 및 데이터베이스를 카탈로그한다. DB2 명령행 또는 DB2 Configuration Assistant GUI를 사용하여 카탈로그 작업을 완료할 수도 있다.
관리
Oracle Enterprise Manager는 관리자의 일상적인 태스크를 위한 다양한 관리 기능을 제공한다. DB2 Control Center는 Oracle Enterprise Manager와 유사한 기능을 제공한다. DB2 Control Center와는 별개로, DB2 명령행 프로세서를 사용하여 DDL 및 DML 문을 실행할 수도 있다. 이 유틸리티는 Oracle SQLPLUS 유틸리티와 유사하다. 그림 14에서는 명령행 프로세서를 보여준다.
그림 14. DB2 명령행 프로세서
그림 15에 표시된 것처럼, Command Center에서도 명령을 실행할 수 있다.
그림 15. Command Center GUI(DB2 명령행 프로세서의 GUI 버전)
성능 튜닝
Oracle Enterprise Manager에는 Change Management Pack, Tuning Pack 및 Diagnostic Pack이 포함된다. DB2에서는 성능 튜닝 태스크를 위한 GUI 도구로서 Activity Monitor, Event Analyzer, Health Center, Indoubt Transaction Manager 및 Memory Visualizer를 제공한다.
데이터 이동
Oracle은 구분된 텍스트 형식의 데이터를 로드하기 위해 SQL Loader(sqlldr)를 제공한다. 가져오기(imp)와 내보내기(exp)를 사용하여 논리적 가져오기 및 내보내기를 수행할 수 있다. DB2는 유사한 가져오기, 내보내기 및 로드 유틸리티를 제공한다. DB2는 크로스 플랫폼 데이터 이동을 위해 db2move 유틸리티를 제공한다.
백업 및 복구
Oracle에서는 핫 백업을 위한 옵션으로서 Recovery Manager를 제공한다. DB2에서는 백업 명령이나 DB2 Control Center를 사용하여 데이터베이스를 백업할 수 있다.
Oracle 11g Enteprise Manager에서는 새로운 성능 개요 차트가 제공된다. 향상된 Oracle Enterprise Manager HTML 인터페이스는 모든 데이터베이스 성능 관련 통계에 대한 중앙 액세스 지점을 제공하고 손쉽고 완벽하게 모니터링 및 진단할 수 있도록 해준다.
DB2 9.7과 함께 제공되는 인터페이스와는 별개로, IBM Data Studio(Data Stuidio)라는 Eclipse 프레임워크를 바탕으로 하는 무료 애플리케이션 개발 도구가 있다. Data Stuidio는 DB2 스토어드 프로시저와 사용자 정의 함수를 작성, 편집, 디버깅, 배치 및 테스트하기 위한 원스톱 센터이다. Data Stuidio를 사용하여 SQLJ 애플리케이션을 개발하고 SQL문 및 XML 쿼리를 작성, 편집 및 실행할 수도 있다.
Developerworks 웹 사이트에서 IBM Data Studio를 다운로드할 수 있다.
IBM Data Studio에 대한 세부사항은 developerWorks에서 tutorial 튜토리얼을 참조한다. 예제와 기능에 대한 설명은 developerWorks에서 IBM Data Studio Features and Benefits web page 기사를 참조한다.
이 기사에서는 Oracle 11g에 대한 독자의 기존 지식을 지렛대로 삼아 Linux, UNIX 및 Windows용 DB2 9.7을 소개했다. DB2 아키텍처, 백그라운드 프로세스, 메모리 모델, 보안, 도구 등을 간략히 설명했다. Oracle과 DB2 9 간에는 많은 유사점이 있는데, 원래 알고 있던 지식을 활용하여 DB2 9.7을 올바로 사용할 수 있도록 몇 가지 차이점을 지적했다.
표 3에는 이 기사에서 논의한 Oracle과 DB2 사이의 차이점과 유사점이 요약되어 있다.
표 3. Oracle과 DB2의 개념 요약
| Oracle | DB2 | 설명 |
|---|---|---|
| 인스턴스 | 인스턴스 | DB2 인스턴스에는 여러 개의 데이터베이스가 포함될 수 있음 |
| 데이터베이스 | 데이터베이스 | |
| initSID.ora OR SPFILE | DBM CFG 및 DB CFG | DB2에서는 두 가지 구성 레벨을 사용하는데, 인스턴스 레벨에서는 DBM CFG(Database Manager Configuration), 데이터베이스 레벨에서는 DB CFG(Database Configuration)를 사용한다. Oracle과 마찬가지로, 이런 구성 매개변수 중 다수가 동적으로 변경될 수 있다. |
| 테이블스페이스 | 테이블스페이스 | DB2는 SMS 및 DMS 테이블스페이스를 지원한다. DMS 테이블스페이스는 Oracle의 테이블스페이스와 유사하다. |
| 데이터 블록 | 페이지 | DB2에서 지원하는 페이지 크기는 4k, 8k, 16k, 32k이다. 행의 크기는 이런 페이지 크기에 맞아야 한다. Oracle에서처럼 한 행이 다른 페이지로 넘어갈 수는 없다. |
| 익스텐트 | 익스텐트 | |
| 데이터 파일 | DMS 테이블스페이스 컨테이너 | DMS 테이블스페이스용 컨테이너는 원시 디바이스 또는 파일일 수 있다. |
| 다시 실행 로그 파일 | 트랜잭션 로그 파일 | |
| 데이터 버퍼 | 버퍼 풀 | DB2에는 미리 정의된 버퍼 풀 세트가 없지만, 원하는 만큼 많이 작성할 수 있다. 주어진 페이지 크기의 테이블스페이스를 작성하기 전에 주어진 페이지 크기의 버퍼 풀이 있어야 한다. |
| SGA | 데이터베이스 관리자 및 데이터베이스 공유 메모리 | |
| 데이터 사전 | Catalog | |
| 라이브러리 캐시 | 패키지 캐시 | |
| 대형 풀 | 유틸리티 힙 | |
| 데이터 사전 캐시 | 카탈로그 캐시 | |
| SYSTEM 테이블스페이스 | SYSCATSPACE 테이블스페이스 |
교육
- "Migrate from Oracle or Sybase to
DB2 in weeks"(Data Management Magazine, 2010년 10월) 기사에는 DB2 및 Oracle 용어와 기술을 비교한 유용한 정보가 수록되어 있다.
- "DB2 9.7: Run Oracle applications on
DB2 9.7 for Linux, UNIX, and Windows"(developerWorks, 2010년 5월) 기사에는 DB2 9.7에서 기본적으로 지원되는 Oracle의 SQL 및 PL/SQL 언어가 설명되어 있다.
-
"IBM Data Movement Tool"(developerWorks, 2010년 11월):
원본 데이터베이스에서 DB2로 손쉽게 데이터를 이동할 수 있는 방법을 소개한다.
- "
An inside look at IBM DB2 Advanced Enterprise Server Edition"(developerWorks, 2011년 3월): 최적화, 개발 및 관리 도구와 함께 DB2를 패키지화한
소프트웨어 번들에 대해 알아보자.
- Redbooks®에서 발표한
Oracle to DB2 Conversion Guide: Compatibility Made Easy
는 Oracle-DB2 마이그레이션 안내서이다. 이 안내서에서는 새로운 DB2 Oracle Database 호환성 기능, 신기술, DB2로 이동하기 위한 우수 사례 및 몇 가지 공통
시나리오를 다루는 방법을 설명한다.
- "Everything
you wanted to know about DB2 processes"(developerWorks, 2003년 4월) 기사에서는 DB2가 Linux, UNIX 및 Windows에서 사용하는 프로세스와 그 기능을 자세히
설명한다.
-
IBM Redbooks에서 발표한
Oracle to DB2 Conversion Guide for Linux, UNIX, and Windows는
Oracle에서 DB2로 마이그레이션하기 위한 단계별 안내서이다.
-
developerWorks resource page for DB2 for Linux, UNIX, and Windows를 방문하여 기사와 튜토리얼을 읽고 다른 참고자료와 연계하여 DB2 기술을 확장시키자.
-
커뮤니티용 DB2 Express Edition의 무료 버전인 DB2 Express-C에 관해 배우자.
제품 및 기술
-
DB2 for Linux, UNIX, and Windows의 무료 평가판을 다운로드하자.
-
현재는 DB2를 무료로 사용할 수 있다.
커뮤니티용 DB2 Express Edition의 무료 버전인 DB2 Express-C를 다운로드하자. 이 제품은 DB2 Express Edition과 동일한 핵심 데이터 기능과
애플리케이션 빌드 및 전개를 위한 안정적인 환경을 제공한다.
-
IBM 제품 평가판을 다운로드하고 DB2, Lotus®, Rational®, Tivoli® 및
WebSphere®의 애플리케이션 개발 도구 및 미들웨어 제품을 사용해 볼 수 있다.
토론
- 포럼에 참여하기.
-
developerWorks 블로그를 통해 developerWorks 커뮤니티에 참여하자.

Raul Chong은 IBM Toronto Laboratory의 데이터베이스 컨설턴트로서, 주로 IBM 비즈니스 파트너와 함께 일한다. Raul은 IBM 근무 경력이 6년째인데,그 중 3년은 DB2 9.1 기술 지원 업무, 나머지 3년은 다른 RDBMS에서 DB2 9.1로의 마이그레이션과 데이터베이스 애플리케이션 개발을 전문 분야로 하는 컨설턴트로 일했다.

