03장. DBCA를 이용한 오라클 데이터베이스 생성

Oracle Database 11g：Ch.03 Creating an Oracle Database.pptx

3장. DBCA를 이용한 오라클 데이터베이스 생성

 

학습 목표

-    DBCA(Database Configuration Assistant)를 이용하여 데이터베이스 생성

-    DBCA를 이용하여 데이터베이스 생성 스크립트 작성

-    DBCA를 이용하여 데이터베이스 디자인 템플릿 관리

-    DBCA를 이용하여 추가 태스크 수행

 

데이터베이스 설계

 

데이터베이스의 논리적 저장 구조가 시스템 성능과 다양한 데이터베이스 관리 작업에 미치는 영향을 고려하는 것은 매우

중요하다. 예를 들어, 데이터베이스에 임의의 테이블스페이스를 생성하기 전에 해당 테이블스페이스가 얼마나 많은 데이터

파일로 구성될 것인지, 각 테이블스페이스에 어떠한 종류의 정보가 저장될 것인지, 데이터 파일이 물리적으로 어떤 디스크

드라이브에 저장되는지를 반드시 알아 두어야 한다. NAS(Network Attached Storage)의 가용성이나 개별 스토리지

네트워크의 대역폭과 같은 정보도 매우 중요하다. 만약, SAN(Storage Area Network)이 사용될 예정이라면, 어떻게 논리적

볼륨을 구성해야 하는지와 스트라이핑 크기를 알아두는 것이 유용하다.

 

데이터베이스 구조의 전체적인 논리적 저장 구조를 설계하는 경우, 해당 데이터베이스가 실제 생성되고 운용될 때, 이

구조가 데이터베이스에 미치는 영향을 고려해야 한다. 또한, 저장 유형 또는 용량으로 인하여 특별한 저장 구조가 필요한

데이터베이스 객체가 요청 될 수도 있다. 분산 데이터베이스 환경에서 이러한 설계 단계는 매우 중요하다. 자주 액세스되는

데이터의 물리적 위치는 애플리케이션의 성능에 큰 영향을 미친다. 설계 단계가 진행되는 동안, 해당 데이터베이스의 백업

전략을 설계한다. 백업의 효율성을 향상시키기 위해 데이터베이스의 논리적 저장 구조 또는 설계를 변경 할 수도 있다.

백업 전략은 다음 과정에서 소개한다.

 

데이터베이스 : 예제

 

데이터베이스의 형태에 따라 특별히 요구되는 인스턴스 및 저장구조가 있다. 오라클 데이터베이스 소프트웨어는 이러한

다양한 형태의 데이터베이스를 생성하기 위한 템플릿을 포함하고 있다. 이러한 예들의 특징은 다음과 같다.

- General purpose : 일반적인 목적 또는 트랜잭션 처리. 예를 들어, 트랜잭션을 처리하고, 중간 정도의 기간 동안 해당 트랜잭션을 저장.

- Custom : 일반적인 목적 또는 Data Warehouse 템플릿으로 적절하지 않는 사용자 정의 데이터베이스용.

이 페이지와 이전 페이지의 정보는 DBA로서 대면하는 것들이다. 이 과정은 이러한 작업에 도움을 주기 위해 설계 되었다.

 

적절한 문자 집합 선택

 

컴퓨터 시스템은 문자를 처리 할 때, 문자의 그래픽 표현 대신 수치 코드를 사용한다. 문자집합은 수치 코드를 컴퓨터 또는

터미널이 표시하고 수식 할 수 있는 문자로 맵핑시킨다. 일반적으로 문자 집합은 특별히 기술된 스크립트를 기반으로

하기 때문에 하나 이상의 언어를 지원 할 수 있다. 그러나, 스크립트 기반 문자 집합은 동일한 스크립트를 기반으로 하는

언어 그룹으로만 제한되는 측면이 있다. 유니버설 문자 집합은 현대 세계의 가장 주요한 스크립트들을 포함하고, 다중 언어

지원을 위한 가장 유용한 솔루션을 제공한다. 유니코드 표준에 대한 정보를 얻으려면 www.unicode.org를 살펴보도록 한다.

 

오라클 데이터베이스는 세 가지 유형의 인코딩 방식 : 단일 바이트, 가변 길이 다중 바이트, 유니버설을 지원한다. 문자

집합은 한번 설정된 후, 나중에 변경하기가 어렵기 때문에 사용자의 비즈니스 요구 사항과 미래를 고려하여 가장 올바른

문자 집합을 선택하여야 한다. 최상의 성능을 위해서는 문자 집합 변환을 생략할 수 있고, 원하는 언어에 대하여 가장

효율적인 Encoding을 수행 할 수 있는 문자 집합을 선택하여야 한다. 단일 바이트 문자 집합은 다중 바이트 문자 집합보다

더 나은 성능을 보여주며 저장 공간의 측면에서 가장 효율적이다. 그러나, 단일 바이트 문자 집합은 지원 가능한 언어의

개수에 제한이 있다. 올바른 데이터베이스 문자 집합을 선택하려면 현재 및 미래의 비즈니스 요구 사항 뿐만 아니라 기술적

요구사항(예를 들어, XML과 Java 표준은 유니 코드를 요구)을 평가하여야 한다. 일반적으로, 유니코드는 가장 유연한 문자

집합이며 미래의 문자 집합 변환을 생략 할 수 있기 때문에 Oracle은 모든 신규 데이터베이스에 대하여 유니코드의 사용을 권장한다.

 

단일 바이트 문자 집합

단일 바이트 문자 집합에서 각 문자는 1바이트를 차지한다. 단일 바이트 7비트 인코딩 방식은 128(2^7)개의 문자를

정의 할 수 있다. 단일 바이트 8비트 인코딩 방식은 256(2^8)개의 문자를 정의 할 수 있다.

 

단일 바이트 방식의 예

7비트 문자 집합

- American Standard Code for Information Interchange(ASCII) 7-bit American(US7ASCII)

 

8비트 문자 집합

- International Organization for Standards(ISO) 8859-1 West European(WE8ISO8859P1)

- DEC 8-bit West European(WE8DEC)

- Extended Binary Coded Decimal Interchange Code(EBCDIC) Code Page 1144 8-bit Italian(I8EBCDIC1144)

다중 바이트 문자 집합

 

가변 길이 다중 바이트 문자 집합은 하나의 문자를 하나 이상의 바이트로 표시한다. 다중 바이트 문자 집합은 아시아 언어

지원을 위해 일반적으로 사용된다. 일부 다중 바이트 인코딩 방식은 최상의 비트값을 이용하여 해당 바이트가 단일

바이트를 나타내는지 아니면 하나의 문자를 표현하기 위한 일련의 연속된 바이트의 일부인지를 나타낸다. 그러나, 다른

문자 인코딩 방식은 다중 바이트 문자 집합으로부터 단일 바이트를 구분해낸다. 디바이스에 의해 보내지는

시프트-아웃(shift- out) 제어 코드는 시프트-인(shift-in) 코드를 만날 때까지 연속된 바이트들을 2바이트 문자로 인식 한다.

시프트-감지(shift-sensitive) 인코딩 방식은 주로 IBM 플랫폼에서 사용된다.

 

유니코드는 모든 언어의 정보를 단일 문자 집합으로 저장 할 수 있는 전세계적인 문자 집합이다.

유니코드는 플랫폼, 프로그램, 언어와 상관 없이 모든 문장에 대하여 고유한 코드를 제공한다.

유니코드 표준은 많은 소프트웨어 및 하드웨어 벤더에 의해 채택되었다. 많은 운영 체제 시스템과 브라우저는 현재

유니코드를 지원한다. 유니코드는 XML, Java, JavaScript, LDAP, WML과 같은 표준에 필요하며, ISO/IEC 10646 표준과 일치한다.

 

가변 길이 다중 바이트 방식의 예

-    Shift-JIS 16-bit Japanese(JA16SJIS)

-    MS Windows Code Page 950 with Hong Kong Supplementary Character Set HKSCS-2001 (ZHT16HKSCS)

-    Unicode 4.0 UTF-8 Universal character set(AL32UTF8) – 가변 길이 인코딩 타입이며 ASCII를 포함

-    Unicode(AL16UTF16 – Microsoft Windows 2000과 Windows XP에서 사용되는 유니 코드 의 16비트 인코딩)

 

문자 집합은 어떻게 사용되는가?

 

 

그림 3-1

 

NLS_LANGUAGE 파라미터는 클라이언트 터미널의 문자 인코딩 방식을 정의한다. 서로 다른 클라이언트는 서로 다른

인코딩 방식을 사용 할 수 있다. 해당 클라이언트와 서버간에 전달되는 데이터는 두 개의 인코딩 방식 간에 자동으로

변환된다. 데이터베이스의 인코딩 방식은 클라이언트의 인코딩 방식을 포함하거나 동일하여야 한다. 해당 변환은

클라이언트 애플리케이션에 대해 투명하다. 데이터베이스 문자 집합과 클라이언트 문자 집합이 동일한 경우,

데이터베이스는 송신 또는 수신 된 데이터가 동일한 문자 집합이라고 가정하여 검증 또는 변환을 수행하지 않는다.

클라이언트/서버 환경에서 클라이언트 애플리케이션이 서버와 다른 플랫폼에 존재하고, 해당 플랫폼이 동일한 문자

인코딩 방식을 사용하지 않는다면 문자 집합 변환이 발생 할 수도 있다.

 

클라이언트와 서버간에 전달되는 문자 데이터는 두 인코딩 방식 간에 반드시 변환되어야 한다. 문자 변환은

Oracle Net를 통해 자동 및 투명하게 발생한다.

 

피해야 할 문제들

그림 3-2

 

클라이언트에 NLS_LANGUAGE 파라미터가 올바르게 설정되지 않으면, 보통 유효하지 않은 데이터가 데이터베이스에

입력된다. NLS_LANGUAGE 값은 데이터베이스로 입력되는 데이터의 인코딩에 영향을 미친다.

-    NLS_LANGUAGE 파라미터가 올바르게 설정되면, DB는 Client OS로부터 DB로 입력되는 데이터를 자동으로 변환 할 수 있다.

-    NLS_LANGUAGE 파라미터가 올바르게 설정되지 않으면, 데이터베이스로 입력되는 데이터가 올바르게 변환되지 않는다.

 

예를 들어, 데이터베이스 문자 집합이 AL32UTF8, 클라이언트가 영문 윈도우 운영 체제(코드 페이지 : WE8MSWIN1252)

이고 클라이언트의 NLS_LANG 설정이 AL32UTF8이라고 가정한다. 데이터베이스에 입력되는 데이터는 WE8MSWIN1252

로 인코딩되고, AL32UTF8 데이터로 변환되지 못한다. 그 이유는 클라이언트의 NLS_LANG 설정이 데이터베이스 문자

집합과 일치되지 않기 때문이다. 그러므로, 오라클 데이터베이스는 어떠한 변환도 필요없다고 가정하고 유효하지 않은

데이터가 데이터베이스에 저장된다.

 

DBCA(Database Configuration Assistant)

 

그림 3-3

 

DBCA는 사용자가 다양한 작업을 수행 할 수 있도록 도와준다. 데이터베이스를 생성, 변경, 삭제 하기 위해 DBCA를

사용 할 수 있다. 또한, 사전에 정의한 템플릿의 목록으로부터 데이터베이스를 생성하거나, 새로운 데이터베이스 또는

템플릿을 생성하기 위해 기존 데이터베이스를 샘플로 사용 할 수 있다.

DBCA는 사용자의 요구 사항을 만족하는 데이터베이스를 생성 할 수 있도록 여러 옵션을 제공한다. DBCA는 구성

정보를 입력 할 수 있는 일련의 페이지를 제공한다.

 

대부분의 페이지에서 DBCA는 사용자가 적용 할 수 있는 디폴트 설정 값을 제공한다. DBCA를 사용하여 데이터베이스를

생성하는 절차는 다음과 같다.

1.   오라클 소프트웨어를 설치 할 수 있는 권한을 부여 받은 OS DBA 그룹의 구성원으로 컴퓨터에 로그온한다.

필요하면 환경 변수를 설정하고 DBCA를 실행하기 위해 dbca를 입력 한다. Welcome 페이지가 나타나면 Next를

클릭하여 계속 진행한다.

2.   수행할 작업을 선택한다. 이 경우에 Create a Database를 선택하고 Next를 클릭하여 작업을 시작한다.

 

그림 3-4

 

3. Database Templates : 데이터베이스 생성에 사용 될 데이터베이스의 유형을 선택한다. 3 가지 데이터베이스 템플릿

(General Purpose, Transaction Processing, Custom Database, Data Warehouse)이 있으며, 이 템플릿은 데이터 파일을

포함하여 사전에 구성된 데이터베이스를 복사한다. 이 파일들에는 컨트롤 파일, 리두 로그 파일, 여러 테이블스페이스에

대한  데이터  파일들이  포함된다. 각 데이터베이스의 유형에 대한 구성 정보는 Show Details를 클릭하여 확인

할 수 있다. 좀 더 복잡한 환경의 경우, Custom Database 옵션을 선택 할 수도 있다.

4. Database  Identification : database_name.domain_name의 형식으로 Global Database Name을 입력하고, 시스템

식별자(SID)도 입력한다. SID의 디폴트 값은 데이터베이스 이름이며 데이터베이스와 관련된 인스턴스를 고유하게 식별한다.

 

그림 3-5

 

5. Management Options : 데이터베이스가 Oracle Enterprise Manager에 의해 관리될 수 있도록 하려면 이

페이지에서 설정한다. Configure the Database with Enterprise Manager를 선택한다. 또한, 이 페이지는 경보 인지

기능과 일별 디스크 백업 영역의 설정을 구성 할 수 있다. DBCA가 통신 할 Enterprise Manager Grid Control

에이전트를 발견하지 못하면 Register with Grid Control 옵션은 비활성화 된다.

 

참고: 데이터베이스에 대하여 Enterprise Manager를 구성하면 리스너가 설정된다(우리 과정에서는 Oracle Grid

Infrastructure를 설치하는 동안 리스너가 구성되었다).

 

6. Database Credentials : SYS 및 SYSTEM과 같은 관리자 계정에 대한 암호를 지정하기 위해 이 페이지를 사용한다.

우리 과정에서는 모든 관리자 계정에 oracle_4U라는 암호를 사용한다.

 

그림 3-6

 

7. Database File Locations : 데이터베이스가 사용 할 저장 메커니즘(예를 들어, ASM(Automatic Storage Management)

또는 파일 시스템)의 유형을 선택한다. 저장 위치의 경우, 사용자의 요구에 따라 선택한다. 우리 예제에서는 ASM이 저장

메커니즘으로 선택되었고 OMF(Oracle-Managed Files)를 사용한다.

 

Browse 버튼을 클릭하여 사용 가능한 디스크 그룹을 확인한 다음, 가장 적절한 디스크 그룹(위 그림에서는 +DATA가

선택 되었다.)을 선택한다. 디스크 그룹을 선택한 다음, ASM에 대한 ASMSNMP 암호를 제공하여야 한다. 파일 시스템

저장소를 사용하는 경우에도 OMF를 사용 할 수 있으며, 오라클 데이터베이스 내에서 운영 체제의 파일들을 직접 관리

할 필요가 없다. 필요한 경우, Multiplex Redo Logs와 Control Files 버튼을 클릭하여 리두 로그와 컨트롤 파일을

추가로 생성 할 수 있다.

 

파일 위치 변수 : ORACLE_BASE, ORACLE_HOME, DB_NAME, DB_UNIQUE_NAME, SID를 조정 할 수 있는 버튼도 제공된다.

그림 3-7

 

8. Recovery Configuration : 데이터베이스에 대한 복구 옵션을 선택한다. 고속 복구 영역을 구성하려면 Specify Flash

Recovery Area 옵션을 체크하고 고속 복구 영역의 위치와 용량을 지정한다. 위 예제에서는 고속 복구 영역의 위치에

+FRA ASM 디스크 그룹을 사용하도록 설정하였고, 용량은 4452MB이다. 고속 복구 영역의 크기는 데이터베이스의

용량보다 크게 설정하도록 권장한다. 아카이브 및 아카이브 관련 파라미터도 이 화면에서 설정 가능하다.

 

참고 : 플래시 복구 영역은 고속 복구 영역으로 이름이 변경되었지만 일부 오라클 제품에서는 여전히 플래시 복구 영역으로 참조한다.

 

9. Database Content : 이 페이지는 샘플 스키마와 같은 컴포넌트를 선택 할 수 있는 옵션과 데이터베이스가 생성된 후

실행해야 할 사용자 스크립트를 지정 할 수 있는 탭을 제공한다.

 

그림 3-8

 

10. Initialization Parameter : 이 페이지의 탭들은 디폴트 데이터베이스 설정을 변경 할 수 있도록 해준다.

- Memory : 메모리 사용량을 제어 할 수 있는 초기화 파라미터를 이 페이지에서 설정 할 수 있다.

(A) Typical 또는 (B) Custom 메모리 할당 중 하나를 사용한다.

- Sizing : 블록 크기를 지정하려면 바이트 값으로 입력하거나 디폴트를 수락한다.

- Character Sets : 데이터베이스에 사용 할 문자 집합을 설정하기 위해 이 페이지를 사용한다.

- Best Practice Tip : 유니코드는 웹 기술 뿐만 아니라 많은 언어를 지원하여, 최적의 유연성을 제공하므로

오라클은 유니코드를 데이터베이스 문자 집합으로 사용 하도록 권장한다.

- Connection Mode : Dedicated 또는 Shared Server Mode를 선택한다.

All Initialization Parameters 버튼을 클릭하여 모든 초기화 파라미터를 확인하고 수정 할 수 있다.

 

참고 : DB_BLOCK_SIZE와 같은 초기화 파라메터는 데이터베이스가 운용되는 동안에는 반드시 설정되어 있어야 한다.

 

 

그림 3-9 

 

11. Database Storage : 현재 데이터베이스 저장 공간 설정을 확인하고 수정한다. 만약, 데이터베이스에 대하여 사전에 구성된 템플릿 중 하나를

선택하였다면, 컨트롤 파일 또는 데 이터 파일을 추가하거나 제거 할 수 없다.

 

12. Create Options : 다음과 같은 옵션을 사용 할 수 있다. 데이터베이스를 생성하고 데이터베이스 정의를 템플릿으로 저장한 다음, 스크립트로

생성 할 수 있다. 만약, 모든 옵션을 선택하고 Finish를 클릭하면, DBCA는 먼저 데이터베이스 템플릿을 저장하고 지정된 디렉터리에 해당 스크립트를

생성한 다음, 마지막에 데이터베이스를 생성한다.

 

 

그림 3-10

 

13. Finish를 클릭하면 Confirmation 페이지가 표시되어 데이터베이스를 생성하기 전에 모든 구성 정보를 검토 할 수

있도록 해준다. OK를 클릭하면 Confirmation 페이지가 사라지고 데이터베이스가 생성된다.

 

참고 : 데이터베이스 정의를 HTML 파일로 저장 할 수 있다.

 

 

그림 3-11

 

14. DBCA가 완료되면, 다음과 같은 정보를 확인한다.

①   설치 로그 파일의 위치

②   전역 데이터베이스 이름

③   시스템 식별자(SID)

④   서버 파라메터 파일 이름과 위치

⑤   Enterprise Manager URL

 

Password Management를 클릭하여 사용할 데이터베이스 계정의 잠금을 해제한다. 계정의 잠금을 해제하는 경우,

암호를 제공한다. 잠금이 해제되지 않는 모든 계정들은 다음에 필요 할 때, 잠금을 해제 할 수 있다.

 

데이터베이스 디자인 템플릿 생성

 

그림 3-12

 

템플릿은 새로운 데이터베이스를 생성하기 위한 시작점으로서 사전에 정의된 데이터베이스 정의 이다. 만약,

데이터베이스 생성 과정의 일부로서 템플릿을 생성하지 않았다면, 아무 때나 DBCA를 실행하여 Manage Templates

작업을 선택하면 된다.

 

템플릿을 생성하는 세 가지 방법은 다음과 같다.

①   기존 템플릿으로부터

②   기존 데이터베이스로부터(오직 구조만)

③   기존 데이터베이스로부터(구조 뿐만 아니라 데이터)

 

DBCA는 데이터베이스 디자인 템플릿의 생성을 위한 절차를 안내한다. 만약, 더 이상 특정 템플릿이 필요하지 않다면, 

DBCA의 Template Management 페이지에서 Delete a database template 옵션을 사용한다.

 

참고  :  DBCA를 이용하여 데이터베이스를 생성하면, 사용자가 생성한 템플릿이 Database Templates 목록에 나타난다.

 

데이터베이스 삭제를 위해 DBCA를 사용

그림 3-13

 

터미널 윈도우에서 dbca를 입력하여 DBCA를 실행하고, Welcome 페이지에서 Next를 클릭한다.

데이터베이스를 삭제하려면 다음 단계를 수행한다.

1.   Operations 페이지에서 Delete a Database를 선택한 다음, Next를 클릭한다.

2.   삭제 할 데이터베이스를 선택하고(예제에서는 hist), Finish를 클릭한다.

3.   삭제를 확정하기 위해 Yes를 클릭한다.

4.   삭제가 완료되면, 다른 작업을 수행 할 것인지 여부를 묻는다. 적절히 선택한다.

 

참고 : 삭제 중인 데이터베이스는 오픈되어 운영 중이어야 한다. 그 이유는 DBCA가 데이터베이스에 접속하여 파일

위치를 결정하여야 하기 때문이다. 데이터베이스 삭제 작업에는 데이터 파일, 리두 로그 파일, 컨트롤 파일,

초기화 파라미터 파일의 삭제를 포함한다. DROP DATABASE SQL 명령으로 직접 데이터베이스를 삭제 할 수 있다.

 

 

DROP DATABASE 문장은 모든 컨트롤 파일들과 컨트롤 파일 내에 기록된 그 외의 모든 데이터베이스 파일들을

삭제한다. DROP DATABASE 문장을 성공적으로 사용하려면, 다음과 같은 조건이 모두 만족되어야 한다.

①   데이터베이스는 마운트 및 닫혀 있어야 한다.

②   데이터베이스는 배타적으로 닫혀 있어야 한다.(공유 모드 아님).

③   데이터베이스는 RESTRICT 모드로 시작되어야 한다.

이 문장의 예는 다음과 같다.

STARTUP RESTRICT FORCE MOUNT;

DROP DATABASE;

DROP DATABASE 문장은 아카이브 로그 파일들과 데이터베이스의 복사본 또는 백업본에는 전혀 영향을 미치지 않는다.

그러한 파일들을 삭제하려면 RMAN(Recovery Manager)을 사용하도록 한다. 만약, 데이터베이스가 로(raw) 디스크에

존재한다면, 실제로 디스크 특수 파일들은 삭제되지 않는다.

 

추가 작업을 위한 DBCA 사용

그림 3-14

 

데이터베이스 옵션(예를 들어, Oracle Label Security 또는 Oracle Database Vault)을 구성하기 위해 DBCA를 사용 할

수 있다. 디폴트로 데이터베이스 소프트웨어를 설치하면 모든 옵션이 설치되지 않기 때문에 만약 데이터베이스가

해당 옵션을 사용하여야 한다면 먼저 이러한 옵션들을 설치하여야 한다.

 

퀴즈

DB_BLOCK_SIZE 파라메터는 데이터베이스가 운용되는 동안에는 설정되어 있어야 하고, 절대 변경 할 수 없다.

1. True

2. False

 

퀴즈

DROP DATABASE를 이용하여 데이터베이스를 삭제하려면 데이터베이스는 반드시 다음 상태이어야 한다.

1. RESTRICT 모드로 오픈

2. RESTRICT 모드로 배타적으로 마운트

3. IMMEDIATE 옵션으로 데이터베이스 종료