안녕하세요. DB2 및 XpertMon 사용자 여러분!
㈜ 아이티엑스퍼트그룹 DB 사업부입니다.
이번에는 2회에 걸쳐서 Oracle 9i 와 DB2 UDB for Linux, UNIX and Windows V8를
비교해 보겠습니다.
크게 두 가지로 나누어서 다룰 예정인데, 첫째는 시스템 구조와 object에 대해서이고,
둘째는 메모리 아키텍쳐와 Locking , 잠금방법이 될 것입니다.
이번에는 시스템 구조와 object에 대해서 살펴보도록 하겠습니다.
Leveraging your Oracle 9i skill to learn DB2 UDB for Linux, UNIX and Windows V8
이 과정에서는 Oracle 9i Release 2를 간단히 Oracle로, DB2 UDB for Linux, UNIX and
Windows Version 8을 간단히 DB2 로 줄여서 쓰도록 하겠습니다.
시스템 구조 개요
시작하기에 앞서 오라클의 구조에 대해 이해하고 DB2 와 비교해 볼 필요가 있습니다.
아래 그림.1은 오라클의 시스템 구조를 나타냅니다. DB2의 구조를 나타내는 그림.2 와
비교해 보시고 참고하시기 바랍니다.
그림.1 Oracle System structure on Linux, UNIX and Windows Version 9.2
그림.2 DB2 UDB system structure on Linux, UNIX, and Windows Version 8
INSTANCE
인스턴스의 개념은 Oracle과 DB2가 유사합니다.
양쪽 모두 인스턴스는 백그라운드 프로세스와 공유메모리의 조합입니다.
주요 차이점이라면 Oracle은 인스턴스당 단 하나의 데이터베이스만이 존재할 수 있는데
반해 DB2는 한 인스턴스에 여러개의 데이터베이스가 존재할 수 있다는 점입니다.
데이터베이스와 인스턴스간의 1대1 관계에 의해, Oracle에서는 CREATE DATABASE 명령을
수행하면 인스턴스는 별도의 생성명령 없이 생성됩니다. 그 외에도 Oracle 9i의
"NEW" 옵션을 주어 ORADIM 유틸리티를 사용하거나, Database Configuration Assistant를
사용해서 인스턴스를 생성할 수도 있습니다.
생성 시 System Identifier(SID)나 서비스 명, 인스턴스 암호, 최대 사용자수,
startup mode 등을 주어야 합니다.
삭제할 때도 생성할 때와 비슷하게 ORADIM 유틸리티를 사용할 수 있는데,
이 때는 "DELETE"옵션을 사용합니다. 삭제 시에도 SID나 서비스 명을 입력해야 합니다.
데이터베이스의 생성 없이 Oracle의 신규 설치 시에는 기본 인스턴스는 생성되지 않습니다.
DB2에서는, 윈도우 플랫폼에 제품을 설치하면 DB2라는 기본 인스턴스가 생성됩니다.
Linux와 UNIX의 기본 인스턴스명은 'db2inst1' 입니다. 같은 머신에 다른 인스턴스를
생성하려면, 다음의 명령을 수행하면 됩니다.
db2icrt
그림.3 은 윈도우에서의 기본 인스턴스인 DB2와 db2icrt로 생성된 다른 두 개의
인스턴스를 DB2 제어센터에서 본 화면입니다.
그림.3 > DB2 UDB Control Center GUI showing DB2 UDB instances
명령창 환경에서 주어진 DB2 인스턴스를 참조하려면, DB2INSTANCE 환경변수를 사용하십시오.
이 변수를 통해 모든 명령어가 적용될 현재 활성화된 인스턴스를 지정할 수 있습니다.
만약, DB2INSTANCE를 PROD로 설정하고 db2 create database MYDB1 명령을 수행하면,
PROD 인스턴스에 MYDB1이라는 데이터베이스가 생성됩니다.
데이터베이스를 PROD인스턴스가 아닌 DB2 인스턴스에 생성하고 싶으면,
DB2INSTANCE 변수를 DB2로 지정하시면 됩니다. 이것은 Oracle에서 사용자가 인스턴스를
이동할 때 사용하는 ORACLE_SID(System Identifier)와 유사합니다.
사용할 인스턴스를 지정하는 다른 방법으로는 제어센터를 사용하는 방법이 있습니다.
제어센터에 새로운 인스턴스를 추가하기 위해서는 "Instances" 항목에서 오른쪽 클릭을
하면 나타나는 메뉴에서 "Add" 를 선택합니다.
인스턴스를 삭제하려면
db2idrop 명령을 수행하면 됩니다.
요약하면, Oracle에서는 인스턴스를 생성, 수정, 시작, 중지, 삭제하는데 Database
Configuration Assistant를 사용하는데 반해, DB2 에서는 제어센터를 사용하여 비슷한
작업을 수행 할 수 있습니다. 그리고 Oracle에서는 인스턴스와 데이터베이스가 1:1의
관계를 가지는데 반해, DB2는 한 인스턴스에 여러개의 데이터베이스를 생성 할 수 있습니다.
Database
Oracle에서는 CREATE DATABASE 명령이나 Database Configuration Assistant를 통해서
데이터베이스를 생성할 수 있습니다. 데이터베이스를 수동으로 생성하기 위해서는
CREATE DATABASE 명령을 수행하기에 앞서 OS 변수 설정, 파라미터 파일 준비,
password 파일 생성등의 작업이 우선 수행되어야 합니다.
메타데이터들은 데이터 사전에 의해 저장되고 관리되는데, 이것들은 기본 테이블과 뷰로
구성됩니다. 기본 테이블은 데이터베이스 생성시에 자동으로 생성되고, 뷰는
catalog.sql, catproc.sql 스크립트를 수행할 때 작성됩니다.
Oracle 데이터베이스는 3가지 파일 타입의 집합으로 볼 수 있습니다.
- Data File : 실제 데이터, 데이터베이스의 물리적 구현사항 (DB2의 컨테이너와 유사)
- Redo File : DB2의 트랜잭션 로그와 동일
- Control File : 데이터베이스의 integrity를 관리하고 확인하는데 사용하는 정보를 담고 있습니다.
그림.2 에서와 같이 DB2 에서는 하나의 인스턴스 안에 여러 개의 데이터베이스가
존재할 수 있습니다. 각각의 데이터베이스는 완전히 독립된 단위로서 데이터베이스가
생성될 때 기본으로 함께 생성되는 카탈로그 테이블 스페이스, 임시테이블 스페이스,
그리고 사용자 테이블 스페이스를 개별적으로 가집니다. DB2는 DB2 머신에서 접속할 수
있는 데이터베이스 목록이 들어있는 system database directory 라는 바이너리 파일을
갖고 있습니다. 이 디렉토리는 인스턴스 단위로 유지됩니다.
인스턴스가 생성될 때, 기본으로 생성되는 데이터베이스는 없습니다.
데이터베이스는 CREATE DATABASE 명령을 통해 명시적으로 생성해 주어야 합니다.
다음의 그림.4, 그림.5와 같이 제어센터를 통해서도 데이터베이스를 생성할 수 있습니다.
그림.4 Creating a DB2 UDB database using the Control Center GUI
그림. 5 Creating a DB2 UDB database using Control Center GUI (continued)
그림.5 에서 "Show Command" 버튼을 클릭하면 어떤 명령이 수행되는지 확인 할 수 있습니다.
DB2의 제어센터에서는 백그라운드로 수행되는 작업의 SQL 문장이나 명령문을 볼 수 있습니다.
이러한 명령문은 추후 실행을 위해 스크립트로 저장할 수 있으며, 명령문을 복사하여
명령행 처리기나 명령센터에서 수행 할 수도 있습니다.
이러한 툴은 Oracle의 SQL*Plus 와 iSQL*Plus 와 같은 기능을 합니다.
DB2 데이터베이스는 DROP DATABASE 명령을 통해서, 또는 제어센터를 사용하여 삭제될
수 있습니다. Oracle에는 그런 명령문이 없고, 다만 관련된 데이터파일을 모두 삭제하는
것으로 데이터베이스도 삭제됩니다.
일반적으로 한 인스턴스안에 있는 데이터베이스들은 서로 상호작용을 하지 않습니다.
하지만 만약 응용프로그램이 하나 이상의 데이터베이스가 서로 상호작용을 요구한다면,
이런 요구사항은 federation 지원기능을 활성화함으로써 충족시킬 수 있습니다.
Containers, table spaces, bufferpools and pages
Oracle에서 데이터는 물리적으로 데이터 파일이라고 하는 파일에 저장됩니다.
이것은 DB2 에서 데이터가 물리적으로 저장되는 컨테이너와 유사합니다.
Oracle 데이터베이스에는 데이터베이스가 생성될 때 자동으로 생성되는 SYSTEM이라는
테이블 스페이스가 있습니다. 이 외에도 사용자, 임시, 인덱스 데이터를 위한 테이블
스페이스가 필요하므로, 데이터베이스 생성 후 사용자는 이 테이블 스페이스를 생성 후
테이블들을 적절한 테이블 스페이스에 지정해 주어야 합니다.
DB2에서 테이블 스페이스는 논리 테이블과 물리 컨테이너간의 연결을 맺어주는 논리적
오브젝트입니다. 테이블 스페이스를 생성할 때, 컨테이너 뿐만 아니라 버퍼풀까지
지정해 줄 수 있습니다. 이는 성능관리를 유연하게 해 줍니다. 예를 들면, 굉장히 자주
사용되는 테이블이 있을 경우에 해당 테이블을 자신만의 테이블 스페이스에 자신만의
버퍼풀을 사용하도록 지정할 수 있습니다. 이렇게 함으로써 해당 테이블의 데이터가
연속적으로 메모리에 캐시되어 있을 수 있습니다.
DB2 에서는 CREATE DATABASE 명령을 기본 옵션으로 수행할 때 생성되는 3개의 기본
테이블 스페이스가 있습니다. 표.1 에 DB2의 기본 테이블 스페이스에 대한 설명이 있습니다.
| 테이블 스페이스 | 설명 |
| SYSCATSPACE | 메타데이터를 저장하는 카탈로그 테이블 스페이스 |
| TEMPSPACE1 | join 과 sort 가 일어나는 시스템 임시 테이블 스페이스, 이름은 변경할 수 있습니다. |
| USERSPACE1 | 이 테이블 스페이스는 선택사항이며, 테이블 생성시 저장될 테이블 스페이스를 지정하지 않을 경우 기본으로 사용됩니다. |
표.1 DB2 UDB table spaces created by default when a database is created with default values
DB2에서는 데이터베이스가 독립된 단위이기 때문에 테이블 스페이스는 데이터베이스 간에
공유되지 않습니다. 테이블 스페이스는 한 데이터베이스 안에서만 인식되기 때문에,
다른 데이터베이스에 같은 이름의 테이블 스페이스가 있어도 상관 없습니다.
그림. 2 에서 MYDB1 데이터베이스와 MYDB2 데이터베이스에 같은 이름의 테이블 스페이스
MYTBLS가 각각 존재하는 것을 볼 수 있습니다.
DB2의 테이블 스페이스는 SMS(시스템 관리 공간)와 DMS(데이터베이스 관리 공간)로
구분됩니다. SMS 테이블 스페이스는 OS에 의해 관리되고, 디렉토리 형태만이 가능합니다.
SMS는 필요할 경우 자동으로 크기가 증가되어 최소한의 관리로 좋은 성능을 냅니다.
DMS 테이블 스페이스는 DB2에 의해 관리되고, 파일이나 raw device가 사용됩니다.
DMS는 성능은 가장 뛰어나지만, 몇 가지 관리가 요구됩니다.
예를 들면, 자동으로 용량이 증가되지 않기 때문에, 테이블 스페이스에 공간을 사전에
미리 할당해 주어야 합니다.
Oracle의 스토리지 모델에는 SMS 같은 개념은 없습니다. Oracle의 데이터파일은 DB2의
DMS 테이블 스페이스와 유사합니다. 테이블 스페이스에 데이터파일을 추가하든지,
데이터파일의 크기를 늘려준다든지, 새로운 테이블 스페이스를 추가하여 데이터베이스의
크기를 증가시킬 수 있습니다.
표.2는 Oracle 과 DB2 간의 데이터베이스와 테이블 스페이스를 비교해 놓은 것입니다.
| Oracle Database or tablespace | DB2 UDB Database or tablespace |
| SYSTEM은 카탈로그(Data Dictionary)정보를 담고 있는 테이블 스페이스입니다. | SYSCATSPACE(카탈로그 테이블 스페이스)
Oracle처럼 이 정보는 데이터베이스 단위에서 유지됩니다. |
| Data Dictionary (테이블이나 뷰의 형태로 메타데이터를 저장)는 SYSTEM 테이블 스페이스에 위치합니다. | 시스템 카탈로그 테이블(SYSIBM 스키마)와 시스템 뷰(SYSCAT / SYSSTAT 스키마) 는 SYSCATSPACE 테이블 스페이스에 위치합니다. |
| SCOTT 데이터베이스 | SAMPLE 데이터베이스 |
| TEMP 테이블 스페이스 | System Temporary 테이블 스페이스(TEMPSPACE1) |
| UNDO 테이블 스페이스 | 없음 |
| USER 테이블 스페이스 | 사용자 테이블 스페이스 (일반적으로 데이터베이스 생성 후 USERSPACE1 이 생성됩니다) |
표.2 How Oracle database map to DB2 UDB database and table spaces
이전에도 언급했지만, Oracle의 데이터 버퍼 개념은 DB2의 버퍼풀과 같지만, DB2 에서는
여러 개의 버퍼풀을 허용합니다. 사용할 수 있는 버퍼풀의 개수에 대해 미리 정해진
값은 없으며, 아무 이름이나 지정할 수 있습니다.
Oracle의 블록 개념은 DB2 의 페이지와 유사합니다. DB2의 페이지는 4K, 8K, 16K, 32K의
크기가 가능합니다. 테이블의 1 row는 오직 한 페이지 안에 들어갈 수 있어야 하며,
Oracle 처럼 다른 페이지에 걸쳐질 수는 없습니다.
Object Names
Oracle의 오브젝트 명은 다음의 형태로 구성됩니다.
[Schema_name.]object_name [@database]
DB2 에서 오브젝트 명은 다음과 같이 두 부분으로 이루어 집니다.
Schema_name.object_name
Oracle 에서와 같이 DB2 에서도 스키마는 오브젝트를 논리적으로 그룹화하는데 사용됩니다.
중요한 차이점이라면 DB2 에서는 스키마와 사용자 ID가 일치할 필요가 없다는 것입니다.
IMPLICIT_SCHEMA 권한을 가진 사용자는 기존에 없는 스키마로 새로운 오브젝트를
생성할 수 있습니다. 예를 들어, iteg라는 사용자가 IMPLICIT_SCHEMA 권한을 가지고
있고, 다음 명령을 수행한다고 할 경우를 생각해 보겠습니다.
CREATE TABLE WORLD.TABLEA (lastname char(10))
이 경우, WORLD.TABLEA 가 생성되는데 WORLD라는 스키마는 새로이 생성된 스키마입니다.
만약 iteg 사용자가 스키마를 명시적으로 지정하지 않았다면, connection ID가 기본으로
사용되어 ITEG.TABLEA가 생성될 것입니다.
DB2 에서는 데이터베이스에 명령을 수행하기 전에 데이터베이스에 접속을 해야 하므로,
오브젝트명에 데이터베이스 명을 포함시킬 필요는 없습니다.
Tables, views and indexes
테이블, 뷰, 인덱스는 기본적으로 Oracle이나 DB2나 같습니다.
DB2에서는 특정 쿼리나 워크로드에 대해 인덱스를 추천하는 Design Advisor라는
유틸리티를 제공합니다. 명령창에서 db2advis 명령을 수행하거나 제어센터를 통해서
실행됩니다. DB2 에서 인덱스는 테이블 정의에 직접 관련됩니다.
예를 들어, DMS 테이블 스페이스를 사용하는 경우, 인덱스가 위치할 테이블 스페이스를
다음과 같이 지정할 수 있습니다.
CREATE TABLE mytable ( col1 integer , col2 char(10) ) in tbls1 index in tbls2
위의 예에서 테이블의 데이터는 'tbls1' 테이블 스페이스에 저장되고, 인덱스 데이터는
'tbls2' 테이블 스페이스에 저장되게 됩니다. Oracle 에서 CREATE INDEX 명령에 인덱스
데이터가 저장될 테이블 스페이스를 지정하는 것과는 상반되는 내용입니다.
또한 DB2에서는 인덱스 정의에 대한 변경이 불가능합니다. 따라서 인덱스 정의에 대한
변경을 수행하기 위해서는 인덱스를 삭제하고 재 생성해야 합니다.
Oracle와 DB2 모두 다른 데이터베이스에서는 테이블, 뷰, 인덱스가 같은 이름을 가질
수 있습니다. 같은 데이터베이스 안에서라면 테이블이나 뷰는 다른 이름을 가져야
하지만 인덱스는 기존에 있는 테이블이나 뷰의 이름과 같은 이름을 사용할 수 있습니다.
Stored Procedures, Triggers and User-Defined Functions (UDFs)
Oracle환경에서 스토어드 프로시저, 트리거, 함수를 생성하고 사용하는 방법은 다양합니다.
객체지향(OO) procedural extension인 PL/SQL은 데이터 조작(DML), flow control,
변수 및 상수 선언, 프로시저와 함수의 선언과 테이블과 varray 와 같은 객체지향
데이터타입 정의 등을 지원합니다. Oracle은 자체의 엔진에 JVM을 통합시킬 수 있습니다.
SQLJ를 사용해서 스토어드 프로시저, 함수와 트리거들을 생성, 저장 및 실행 할 수 있습니다.
Oracle은 JDBC 드라이버도 타입 1~4까지 지원합니다.
DB2 에서도 DB2 UDB 프리컴파일러가 지원하는 Java, C, C++, REXX, Fortran, Cobol 등의
언어로 스토어드 프로시저를 작성할 수 있습니다. 하지만 Oracle의 PL/SQL과 거의 흡사한
SQL Procedural language(SQL PL)을 사용할 것을 권장하고 있습니다.
SQL PL 스토어드 프로시저를 개발하기 위해서는 우선 C로 변환하기 위해 C 컴파일러가
필요합니다. 스토어드 프로시저를 C 로 구현하는 것은 코드가 한번만 컴파일 되기
때문에(특히 unfenced 모드에서 수행할 경우) 성능상의 이익을 주지만 개발 시스템에
컴파일러가 필요하게 됩니다. DB2 에서는 차후에는 C 컴파일러 없는 스토어드 프로시저를
지원할 예정입니다. DB2 스토어드 프로시저 개발은 SQLJ와 JDBC 드라이버 타입 1~4를
통한 자바를 지원합니다.
트리거와 함수는 inline SQL/PL 을 통해 C 컴파일러 없이 개발이 가능합니다.
SQL PL문장의 서브 셋은 이런 방법으로 지원됩니다. DB2에서는 DB2 UDB 개발센터를
사용하면 스토어드 프로시저와 사용자 정의 함수를 생성, 빌드, 디버그 및 적용을 쉽게
할 수 있습니다.
Configuration Files
전통적으로 Oracle은 모든 세션과 시스템 관련 파라미터를 일반적으로 initSID.ora 라고
하는 텍스트 파일에 저장합니다. 하지만 이 텍스트파일이 지속성이 없는 이유로
Oracle 9i 부터는 서버에 저장되는 파라미터를 바이너리로 저장하는 서버 파라미터
파일(SPFILE)을 소개했습니다. 이 파일은 인스턴스를 shutdown 과 startup 동안 유지됩니다.
initSID.ora 파일도 SPFILE이 사용 불가능할 때 여전히 사용됩니다. SPFILE이 소개되기
전에 파라미터에 영향을 주는 ALTER SYSTEM이나 ALTER SESSION 명령은 해당 인스턴스나
세션 동안만 유지되었습니다. 데이터베이스 인스턴스를 rebind 하려면, DBA가
initSID.ora 파일을 수동으로 수정해주어야 했습니다. 네트워크 접속 설정은 기본적으로
리스너쪽은 listener.ora 파일에, client 쪽은 tnsnames.ora 파일에 저장됩니다.
DB2 에서는 인스턴스 단위의 구성 매개변수는 database manager configuration file에,
데이터베이스 단위의 구성 매개변수는 database configuration file에 저장됩니다.
이들 중 대부분은 변경 값을 적용하기 위해 인스턴스를 재 시작하거나 데이터베이스의
모든 접속을 끊을 필요 없이 동적으로 변경됩니다.
명령 창에서 특정 database manager parameter를 변경하려면 다음 명령을 수행하십시오.
UPDATE DBM CFG USING
명령 창에서 특정 database parameter를 변경하려면 다음 명령을 수행하십시오.
UPDATE DB CFG FOR USING
이 명령문은 Oracle의 ALTER SYSTEM 및 ALTER SESSION 명령과 같습니다.
XpertMon을 통해서도 이러한 파라미터를 조회하고 수정할 수 있습니다. XpertMon의
CFG 창에서 DBM 및 DB CFG를 조회, 수정 할 수 있습니다.
다음 그림은 XpertMon에서 DBM CFG 및 DB CFG를 조회한 화면입니다.
그림. 6 DB2 UDB Database Manager configuration parameters (instance level).
그림.7 Database configuration parameters (database level)
DB2에서는 시스템을 구성하는데 사용하는 다양한 매개변수를 제공합니다. 하지만 시스템을
자동으로 구성하는 간편한 방법을 원한다면, autoconfigure 명령이나 Configuration
Advisor GUI를 사용하십시오.
autoconfigure 명령은 사용자가 제공한 정보를 사용하여
database manager configuration parameter 와 database configuration parameter를
최적의 값으로 설정해 줍니다.
그림.8 은 Configuration Advisor 의 화면입니다.
그림. 8 DB2 UDB Configuration Advisor
configuration file 외에도 DB2 에는 DB2 레지스트리 변수라는 것이 있습니다.
레지스트리 변수는 플랫폼-지정 설정을 위한 것입니다. 참고로, DB2 레지스트리 변수는
윈도우 레지스트리와 전혀 관련이 없습니다.
접속정보(네트워크 접속)는 .System database directory, local database directory 와
node directory에 저장됩니다. 이 파일들은 바이너리 파일들로 CATALOG 와 UNCATALOG
명령으로만 수정됩니다.
XpertMon for DB2 UDB V2
DB 사업부
Tel : 02-2108-1458
Fax : 02-2108-1459
Mobile : 011-896-6545
E-mail :
hjlee@iteg.co.kr
URL :
http://iteg.co.kr
