실전 dbms migration 사례및 실무구현 workshop실전dbms data migration...

실전 DBMS Migration 사례 및실무구현 Workshop

강사 : 신 종 근일시 : 2007. 08. 24

2007 Innovative Technology Seminar Learn Oracle From Oracle

2실전 DBMS Data Migration 사례 및 실무구현 Workshop

ContentsContents

I. Migration 기법 및 Solution 종류

II. Advanced Data Migration 기법과 Demo

III. 10g 이기종 Platform Data Migration

IV. RAC로의 Migration 및 Fail-Over 구현

V. 기타내용 및 QnA


I. Migration I. Migration 기법기법 및및 Solution Solution 소개소개

1.1. Migration Migration 수행절차수행절차

2.2. Migration Migration 방법방법 비교비교

3.3. Case Case 별별 Migration Migration 실무사례실무사례

4.4. 기타기타 SolutionsSolutions


– 마이그레이션 준비

• Oracle 9i/10g의 부가 기능들을 파악하고 마이그레이션 방법 선택

• 시스템 요구조건과 가용자원, 새 데이터베이스 위치 확인

• 백업 전략 및 테스트 계획 수립

– 마이그레이션 프로세스 테스트

• 테스트 환경 생성

• 업무용 데이터의 부분 집합들을 테스트 환경의 Oracle9i/10g로 마이그레이션

• 가능할 경우 전체 데이터베이스를 테스트 환경으로 마이그레이션

– 마이그레이션된 테스트용 데이터베이스 테스트

• 업무용 데이터와 테스트용 데이터베이스를 대상으로 동일한 테스트 실시

• 결과를 대조하고 일체의 오동작 기록

• 테스트용 데이터베이스를 대상으로 애플리케이션 테스트

– 소스 데이터베이스 준비와 보존

• 환경 및 시스템 변수 확인

• 데이터베이스 운영(DBA) 권한 확보

• 업무용 데이터베이스 폐쇄

• Migration Utility 실행

Migration 수행절차

II--1. Migration 1. Migration 수행절차수행절차


– 업무용 데이터베이스 마이그레이션

• 업무용 데이터베이스를 대상으로 마이그레이션 순서 진행

• 업무용 데이터베이스 백업

• Oracle9i/10g를 설치하고 Oracle9i/10g 마이그레이션 순서 진행

– 새 업무용 데이터베이스 Oracle9i/10g의 튜닝 및 조정

• 마이그레이션된 데이터베이스 백업 구현 후 작업 수행

• 마이그레이션된 데이터베이스를 테스트하고 결과 대조

• 마이그레이션된 데이터베이스 튜닝, 새 기능들 활성화(필요에 따라)

• 전환날짜를 결정하고 마이그레이션된 데이터베이스 가동


Migration 수행절차


업그레이드 준비

Oracle9i/10g의 부가기능들을 파악하고 업그레이드 전 순서 진행(현재 버전별로, 업그레이드 방법론,

시스템 요구조건, 가용자원, 그리고 새 데이터베이스 위치 확인, 백업 전략 및 테스트 계획 수립)

업그레이드 프로세스 테스트

테스트 환경 생성, 업무용 데이터의 부분 집합을 테스트 환경의 Oracle9i로 업그레이드, 가능할 경우 전체

데이터베이스를 테스트 환경으로 업그레이드

업그레이드된 테스트용 데이터베이스 테스트

업무용 데이터와 테스트용 데이터 베이스를 대상으로 동일한 테스트 실시, 결과를 대조하고 일체의 오동작 기록,

테스트용 데이터베이스를 대상으로 애플리케이션 테스트

데이터베이스 업그레이드 :

데이터베이스 운영(DBA) 권한 확보. 현재의 데이터베이스를 셧다운한 후 백업, Oracle을 설치하고 업그레이드

순서 진행, 업그레이드된 데이터 베이스 백업

업그레이드 후 작업 수행

여타 특정 컴포넌트들을 업그레이드(필요한 만큼), 운영 작업 수행(설명서에 따라), 업그레이드된 데이터베이스를

테스트하고 결과 대조, 업그레이드된 데이터베이스 조정, 새 기능들 활성화(필요한 만큼), 전환날짜를 결정하고

업그레이드된 데이터베이스 가동

Oracle 9i/10g Upgrade 순서



– 데이터 이행을 위한 시스템은 기존 시스템에서 이행될 데이터를 추출(Extracting)하여 새로운 버전의 데이터베이스내의 더미 테이블로 단순 이행(Importing)하고 Mapping 규칙에 따라 최종적인 목적 테이블로 전환(Mapping)하며 이러한 이행 작업 과정에서 데이터 이행 평가 기준을 점검(Balancing)하는 4개 유형의 서브시스템으로 구성합니다.

기존데이터베이스

이행 전환

RDBDummy Table

신 시스템Target Table

점검자료 에러 리스트

에러 리스트

기존 시스템 신 시스템

추출

점검보정

Flat File

DB Link

Application

Data 이행방안 – 1. Data 이행 Image



• 추출(Extracting)

– 자료추출 : 이행 데이터 매핑 결과에 의거하여 기존 버전의 시스템에서 신 시스템으로 이행될 내용을 Flat File

형태로 추출

– 무결성 검증 : 기존 자료 체크리스트에 해당하는 내용을 검증하여 오류 자료를 자동적으로 정정하거나 에러

리스트를 산출

– 이행 평가기준 산출: 데이터 이행의 성공 여부를 판단할 수 있는 주요 항목에 대한 추출 결과를 산출함. 주로

전체 건수, 특정 항목의 합산 결과 등을 자료 추출과정에서 산출하여 최종 자료 전환 결과와 비교함.

• 이행(Importing)

– 테이블 이행 : 추출 단계의 결과인 Flat File을 임시 테이블(Dummy Table)로 단순 Load함

• 전환(Mapping)

– 기본테이블 전환 : 데이터 이행 우선 순위에 의거하여 전체 데이터베이스 중 기본 테이블을 1차적으로 전환함

– 계단형(Cascade) 전환 : 기본 테이블을 참조하여 2차적인 테이블을 전환하며 기존 시스템의 관계형 데이터베이스에는 존재하지 않았던 외래키 등의 자료를 생성함.

– 이행 평가기준 산출 : 추출 과정과 동일한 기준으로 최종적인 데이터 이행 평가 기준을 산출하여 데이터 이행의성공 여부를 평가함.

• 보정(Coordination)

– 비상대책에 해당하는 시스템으로써 데이터 이행 결과 발생된 에러가 추출 단계부터 재작업이 불가능할 경우 에러의 심각도에 따라 신 시스템 내부적으로 제한적인 자료 보정을 수행함.

• 기존 자료 정비

– 정비 대상 자료 파악 : 기존 자료 중에서 프로그램 자체적으로 조치할 수 없는 정비 대상 자료를 파악함.

– 기존 자료 정비 : 정비 대상 자료의 리스트를 산출하여 담당자별로 통보하고 온라인 또는 배치 작업으로 기존

자료를 정비함.

– 정비 결과 점검 : 자료 정비의 결과를 자료 전환 시스템의 테스트 과정에서 검증하여 미비 사항을 보완함.

Data 이행방안 – 2. Data 이행 절차 항목



– 기존 시스템의 확장 및 H/W 교체에 따른 데이터 이행에 있어 데이터는 정확한 Production Database의 생성을위해 정리 작업이 요구되며, 정리를 위한 시간과 인력이 미리 고려되어야 합니다

데이터 평가데이터 평가 데이터 평가결과 분석

데이터 평가결과 분석 데이터 정화데이터 정화

기존시스템기존시스템

데이터정확도/Gap

평가 결과

데이터정확도/Gap

평가 결과

데이터정화작업순서,절차

데이터정화작업순서,절차

정화된데이터

(Oracle)

정화된데이터

(Oracle)

•전체 데이터 정화업무관리자 선정

•분야별 업무 책임자 선정•현 시스템 데이터 분석 지원,현업 참여

•항목별 평가 작업 수행

•평가 결과에 기초한 쟁점 사항 파악•대처 방안 검토•정화작업 순서 및 절차 수립

•시스템 요구 데이터정화 작업 선 수행

•기타 데이터 정화 작업•Cut Over 이전 까지 데이터의정확성을 유지 할 방법 개발

데이터 이행 시 발생되는 문제점• 기존 시스템 데이터 값의 부정확• 부분적인 데이터의 기록 누락• 새로운 기능 추가에 따른 추가적 관리 데이터발생• Data Type의 변환 및 Table의 구성의 수정• Application의 수정 및 실질적 적용

Data 이행방안 – 3. Data 이행 시 고려사항



• SQL * Loader를 이용한 Migration Data 처리

– Oracle DBMS형태 뿐만 아니라 아닌 형태로 존재하는 데이터의 Migration 작업은 SQL*Loader를 이용하여DBMS에서 사용하는 Table로 데이터를 Upload합니다.

ASCII flat File Staging Area

• 기존 시스템의 자료를 신규 시스템의데이터 매핑 포맷으로 변환하는 프로그램 작성하여 Sam File 데이터 생성

• Source 데이터 와 Target 데이터의변환 시 필요한 Check 수행

• SQL*Loader를 이용하여시스템의 임시 테이블인Staging Area에 데이터를 로딩 함.

Data Validation Check

• API를 이용하여Staging Area의 데이터를 신규 시스템에Loading함.

검증 Application을 이용하여 Oracle DBMS 에서사용하는 Table간의 논리적인 Duplication 및Validation 를 수행함.

신규 시스템

FTP/NFS

데이터 검증

기존 시스템기존 시스템

Data 이행방안 – 4. Data 이행 방법



• SQL * Loader (Oracle RDBMS 제공)

– SAM파일을 Database 내의 Table Uploading 하는 Utility 입니다.

– 주로 대량의 데이터를 처리하고자 하는 경우에 사용합니다.

– Parallel 및 Direct Option 등을 제공합니다.

– 이기종간의 데이터 Conversion 및 동 기종에서 데이터 Migration 시에도 활용가능합니다.

기존 시스템 신규 시스템

주요처리내용•초기의 기존 시스템 데이터를 전환할 때 사용•대량의 데이터를 처리할 때 또는 정기적인 데이터의 일괄 전송 시 사용

장점•가장 빠른 성능 보장•SQL 및 DBMS에 대한 기초지식만으로도 바로 활용가능

단점•단 방향 및 자동화된 처리의 어려움•Point-To-Point방식의 인터페이스

필요 Resource•Interface를 위한 별도의 하드웨어가 필요 없음.•SQL*Loader는 9i DBMS 와 함께 기본적으로 제공되는 Software로서 별도의 비용이 필요 없음

FTP Legacy

BatchCollect

Program

전송할SAMFILE

SQL*LoaderPro*c

DBAPI Load

II--1. Migration 1. Migration 수행절차수행절차Data 이행방안 – 4. Data 이행 방법


No Migration 유형 Migration 방법

1 Data Migration- 다양한 환경에 따라 Migration 방법이 상이함.- Archive Mode 인 경우 Down-Time 을 최소화

2 Schema 별 Migration

- 동일 Platform 인 경우 TTS 사용- Tablespace 별 이관인 경우 TTS 사용 (동일 Platform, Character-Set)- 대용량인 경우 DB Link 이용한 Parallel CTAS 사용- Named-Pipe & Multi-thread Exp/Imp 사용 , Data Pump

3 Object Reorganization- Parallel Move 및 Parallel Execution 사용- Online DBMS_REDEFINITON 사용- SQL*Loader , Exp / Imp 등

4File-System raw-deviceASM Non-ASM (F/S, raw)

- OS 의 dd command 사용 (windows – ocopy or windows 용 dd).

- 10g 이상인 경우 DBMS_FILE_TRANSFER 사용. - ASM 으로의 Migration 인 경우 RMAN

5 Single Table Partitioned Table- Direct & Parallel Query 사용- Partition Exchange 및 DBMS_REDEFINITION 사용.

6 Single DB RAC DB- 9i 이하인 경우 수작업- 10g 이상인 경우 CRS/DB 의 addNode.sh 사용- 업무 Partition 및 Load-Balancing / TAF 설정

7 DB Version Upgrade- 동일 Platform 인 경우 Manual Upgrade 사용- 이기종 Platform 인 경우 1번의 Guide 를 따름.

8 Server Migration

- 동일 Platform 인 경우 Data File 또는 RMAN 사용- OS 의 Migration Tool 사용- 신규 Storage 이전시 Hot-Backup 사용하여 Down-Time 최소화- 32bit/64bit 에 유의할 것 (DB 는 Bit 에 무관!!)

9 DR 구성 및 복제- H/W 복제 Tool (True-Copy, SRDF, Shadow-Image, TDMF, Flash-Copy, IP-Stor 등) 사용- Oracle 의 Data Guard 사용- BCP 방법에 따라 구성방법이 다양함

10 Storage Migration- H/W Volume 복제를 통한 실시간 Migration 가능- 이기종 Storage 지원여부- Hot-Backup / RMAN 을 통한 복제

11 Tool 을 이용한 Migration- 이기종 Version 및 DB인 경우 Shareplex 사용- Oracle Workbench Tool 사용- Informatica 등 기타 ETL Tool 사용

12 기타 Migration 방법- Manual Data Unload Loading 사용 (CA Fast-Unload)

- 업무별 Data 분산하여 이관- Snapshot 등을 이용한 방법

II--2. Migration 2. Migration 방법비교방법비교


No As-Is To-Be Migration 방법 장점 단점 제약사항 비고

1 10g (동일 Endian)(HP 10g IBM 10g )

1. IBM 에 신규 DB 생성2. HP IBM 으로 TTS

1. Archive Mode 이면D/T 거의 없음

2. ASM/raw/File 적용동일 Character-Set 동일 Endian

210g (다른 Endian)(Linux 10g Sun 10g)

1. Sun 에 신규 DB 생성2. Linux 에서 Conversion3. Linux Sun 으로 TTS

or Data Pump

1. Archive Mode 이면D/T 거의 없음

2. ASM/raw/File 적용Linux 에 Disk 공간필요 동일 Character-Set

이기종Endian

3 동일 Platform (AIX 4.3.3 8i AIX 5L 10g)

1. 모든 DBF copy2. Manual Upgrade

Archive Mode 이면Hot-Backup 이용

Upgrade 후 N/F 적용동일 Character-Set806/817/920/101 이어야 함.

동일Platform

4 특정 Schema 만(HP 8i HP 8i)

1. 8i 신규 DB 생성2. Meta & TTS

1. D/T 최소화2. Online 중에 가능

해당 Schema 업무 R/O 동일 Platform, Character-Set동일 DB_BLOCK_SIZE

Schema 분리

5 특정 Schema 만(HP 8i/9i HP 9i/10g)

1. 9i/10g 신규 DB 생성2. Meta & TTS

1. D/T 최소화2. Online 중에 가능

해당 Schema 업무 R/O 동일 Platform, Character-SetSchema

분리

6 이기종 Platform/Version (Aviion 8.0 Sun 10g)

1. CTAS on DB Link2. Named-Pipe Exp/Imp

속도가 빠름 Script 준비 및 검증 Network 속도에 영향

7이기종 Platform/Version (대용량 Partitioned Data)

1. 신규 DB 생성2. 각 Partition 별 Migration

Parallel Execution3. Index Parallel Rebuild

ReOrg 효과 Script 준비 및 검증 Network 속도에 영향 DB Link

8 이기종 Platrom/Version (소량 Data)

1. 신규 DB 생성2. Exp / Imp

ReOrg 효과 속도 느림 Disk I/O 에 영향 Exp/imp

9

10

11

** 상기 1~5번까지의 방법은 Archive Mode 인 경우에 Down-Time 을 최소화하여 Data Migration 이 가능함



대상 판단기준 Migration 방법 제약사항 및 비고

동일 Endian. TTS 사용. DBF :: dd or DBMS_FILE_TRANSFER. 소량 Data :: Data Pump

. 동일 Character-Set(National Character-Set 동일)

. Data Guard 로 Down-Time 최소화

10g 인 경우

동일 Platform. Manual Upgrade (Engine Upgrade). DBF :: OS File copy . ASM 으로 전환 :: RMAN 사용

. Archive Mode 로 Down-Time 최소화

Partitioned 대용량 Data. DB Link 이용한 CTAS. Partitioned 별 insert ~ select. Exp / Imp 병행

. DB Link 용 Multi Private Network 사용

이기종 Platform/Version- 대용량 Data (예 : 50G 이하)

다른 Endian. TTS 사용. Target Endian 으로 Conversion. DBF :: dd or DBMS_FILE_TRANSFER

. 동일 Character-Set(National Character-Set 동일)

. Data Guard 로 Down-Time 최소화

. DB Link 이용한 CTAS

. Named-Pipe Exp/Imp. DB Link 용 Multi Private Network 사용. Named-Pipe 용 Private Network 사용

이기종Platform/Version

인 경우

이기종 Platform/Version- 소량 Data (예 : 50G 이하)

. Exp / Imp . Exp/Imp Matrix Check

(지원이 되지 않으면 CTAS 로…)

II--2. Migration 2. Migration 방법비교방법비교Migration 방법 선정 Guide (3rd Party Tool 제외)

1. File Copy 를 통한 TTS 방식 :: 초당 60M ~ 120M 전송이 가능하며 Network 속도보다 Storage I/O 에 Dependant 함.DBF가 File-System 인 경우 OS에서 지원하는 Async I/O , Direct I/O 를 사용할 것 !!

2. CTAS 방식 :: Character-Set 이 다른 경우 한글깨짐 현상과 Column 길이가 배수로 늘어나므로 유의할 것 !!3. Named-Pipe 방식 :: 충분한 Swap (Temp) 공간이 필요함.4. Parallel 작업시 :: 정렬되지 않고, 적절한 storage 파라미터 사용, 충분한 Temp 공간 필요, 대량 작업시 Rollback 사용 검토


No As-Is To-Be Direct Upgrade Upgrade Step 비고

1~ 7.3.3 10g R2 NO

먼저 7.3.4 로 Upgrade 8.1.7 8.1.7.4 10g R2

27.3.4 10g R2 NO

Direct Upgrade (but MIG Tool)8.1.7 8.1.7.4 10g R2

38.0.x 10g R2 NO 8.1.7 8.1.7.4 10g R2

48.1.x 10g R2 NO 8.1.7 8.1.7.4 10g R2

58.1.7.4 10g R2 YES Direct Upgrade

69.0.1.x 10g R2 NO 먼저 9.0.1.4 or 9.0.1.5 Upgrade 후

79.0.1.4 or 9.0.1.5 10g R2 YES Direct Upgrade

89.2.0.x 10g R2 NO 먼저 9.2.0.4 이상으로 Upgrade 후

99.2.0.4 이상 10g R2 YES Direct Upgrade

1010.1.0.2 이상 10g R2 YES Direct Upgrade

11

** Direct Upgrade 방식은 신규 S/W 설치후 기존 DBF 를 이용하여 Migration 하는 방법Metalink Note :: 316889.1 참조



II--3. Case 3. Case 별별 Migration Migration 실무사례실무사례

Oracle S/W Upgrade

1) 동일 Platform 인 경우 가장 Simple & Fast 한 방법

- OS Platform 및 Oracle Version 에 Dependant 함 (단, 7.x 과 8.0.X 이후 호환 불가 – ROWID format)- Oracle Engine (Software) 만 Upgrade 를 하며, 기존 DBF 는 그대로 사용한다.- Version 에 따라서는 여러 번 Upgrade 를 해야할 경우가 있다.

(ex: Ver 8.0.5 8.0.6 9.2.0.4 등 ,각 Version 별 Upgrade 시 실행하는 Script 가 다름. )

- Single / RAC 와 무관하며, Bit 와도 무관하다. (즉, 호완이 됨)( Single RAC, 32 bit 64bit )

- Compatible 이 Upgrade 된 이후에는 Downgrade 가 불가하다.(단, 동일 Version 에서의 Release Down-Grade 는 가능함)

2) 일반적인 작업순서

- 기존 Oracle Engine & Data Backup- 신규 Oracle Engine Install & 최신 Patchset- startup migrate ore startup upgrade Mode 에서 Script 실행- Invalid Package Compile 및 Rebuild- 신규 Version 으로 Upgrade 후 New-Feature 는 수동으로 생성 및 적용

(RBS Undo, Dictionary Managed TBS LMT, ASSM 등..)- JAVA Package 설치여부에 따라서 Down-Time 이 결정된다.


데이터 파일 시스템 테이블스페이스

마이그레이션유틸리티Oracle7파일 헤더 블록

Oracle9i데이터딕션너리

Oracle7

장 점

• 자동이고, 최소한의 상호작용 요구

• 여타 방법론보다 상대적으로 작은

디스크 추가공간 요구

• 보다 큰 제어력 제공

단 점

• Oracle7을 Oracle9i로 마이그레이션하는데 국한

• 부분적 마이그레이션 불가능

• 전체 데이터베이스만 마이그레이션 가능

• 오라클을 다른 플랫폼이나 운영체제에

마이그레이션하는 데 이용할 수 없음

Oracle 7 Oracle 9i : Using Migration Utility



Oracle S/W Upgrade – 실무사례- Solaris 2.6 32bit , Single Solaris 2.8 64bit RAC

Cache 8GB

A B A B

a b

ESCON

A B A B

a b

ESCON

A B A B A B A B

a b a b

Fiber Fiber

Unisys

UnisysIX5820

ESCON

SUN E10KSolaris 2.6

SUN E10KSolaris 2.6

SUN Cluster 2.2H/A

SUN 12KSolaris 9

SUN 12KSolaris 9

SUN Cluster 3.0RAC

638GB638GB

M1

M2

WorkNet

???GB???GB

M1M2

WorkNet 신규서버

신규서버

???GB???GB

M1M2

FiberSC-LC Fiber

LC-LC




1. SF12K Server 에 Oracle 9.2.0.4 RAC S/W Install 및 Patchset

2. E10K Oracle Hot-Bakcup Script 작성

alter tablespace BAK begin backup;!dd if=/dev/vx/rdsk/worknet/BAK_1 ibs=4096k |rsh f12k "dd of=/dev/vx/rdsk/worknet/BAK_1 obs=8192k";alter tablespace BAK end backup; .....alter system archive log current;

3. Current Redo & Current Controlfiledd if=/dev/vx/rdsk/worknet/CONTROL01 bs=2048k | rsh f12k "dd of=/dev/vx/rdsk/worknet/CONTROL01 bs=2048k“dd if=/dev/vx/rdsk/worknet/REDO40 bs=2048k |rsh f12k "dd of=/dev/vx/rdsk/worknet/REDO40 bs=2048k";

4. Oracle Migration 순서- Remove Obsolete parameters belows- _system_trig_enabled = false- #JOB_QUEUE_PROCESSES - #AQ_TM_PROCESSES - OPTIMIZER_MODE = CHOOSE- #SNAPSHOT_REFRESH_? - REMOTE_LOGIN_PASSWORDFILE = NONE - #CLUSTER_DATABASE = FALSE in OPS, RAC !!- #RESOURCE_MANAGER_PLAN

SQL> startup migrateSQL> spool upgrade.logSQL> @?/rdbms/admin/u0801070.sql




SQL> @cmpdbmig.sql

SQL> Select comp_name, version, status from dba_registry;

SQL> shutdown immediate. init<SID>.ora- JOB_QUEUE_PROCESSES = 0- AQ_TM_PROCESSES = 0- REMOTE_LOGIN_PASSWORDFILE = EXCLUSIVE- compatible = "9.2.0.0.0"- db_file_multiblock_read_count = 32- pga_aggregate_target = 25165824

SQL> startup migrateSQL> @catpatch.sqlSQL> @?/rdbms/admin/utlrp

5. Enable RAC ModulesSQL> alter database add logfile thread 2 group 4 , 5, 6

2 ('/dev/vx/rdsk/worknet/REDO41','/dev/vx/rdsk/worknet/REDO42')3 size 106954240;

SQL> alter database enable thread 2;

6. After Upgrade- Tablespace Migrate to Local

exec sys.dbms_space_admin.tablespace_migrate_to_local('USERS');exec sys.dbms_space_admin.tablespace_migrate_to_local('INDX');exec sys.dbms_space_admin.tablespace_migrate_to_local('TOOLS');…



장 점

• 그래픽 방식으로 초대

• 자 동 이 고 , 상 호 작 용 거 의 요 구 하 지

않음

• 상대적으로 빠름

• 대량의 디스크 공간 요구하지 않음

단 점

• 자동인 만큼 유연성 떨어짐

• 제어력 낮음

• 전체 데이터베이스만 마이그레이션

• 오라클을 다른 플랫폼이나 운영체제에

마이그레이션하는 데 이용할 수 없음

데이터 파일 시스템 테이블스페이스

Oracle8파일 헤더 블록

Oracle9i데이터딕션너리

Oracle8

Oracle9i

마이그레이션유틸리티 설치

Using DBUA (Upgrade Assistant)


** DBUA :: Oracle 에서 제공하는 Upgrade Tool ($ORACLE_HOME/bin/dbua)사용예 1) 7.3.4 8.0.x Upgrade 시사용예 2) 9i RAC 10g RAC Upgrade 시 등.


Table Reorg Process



1. Verify the Table is Online Redefinition

SQL> exec dbms_redefinition.can_redef_table ('FINANCE', 'RATE');

2. Create an Interim Table

. Create New Partitioned Table ….

. Declare primary key Only

. Oracle copy rows and swap the names

3. Associate the Interim Table with to be Redefined Table

SQL>exec dbms_redefinition.start_redef_table ('FINANCE', 'RATE', 'STAGING');

4. Add Constraints and Indexes

. Create constraints, indexes, triggers and grants

. Create foreign keys with the DISABLE keyword

5. Complete the Online Redefinition

SQL> exec dbms_redefinition.finish_redef_table ('FINANCE', 'RATE', 'STAGING');

** Speed up the Online Redefinition

SQL> exec dbms_redefinition.sync_interim_table ('FINANCE', 'RATE', 'STAGING');

** Abort the Online Redefinition

SQL> exec dbms_redefinition.abort_redef_table ('FINANCE', 'RATE', 'STAGING');



Single Table Partitioned Table 전환시

** 상황 : 급여 작업시 20 장 CPU 를 Full 로 사용중이며, Idle 이 5% 미만여러 개의 Oracle 각 Process 는 4% 점유하고 있다.



Single Table Partitioned Table 전환시

** 해결 : 문제가 되는 급여관련 대용량 Table 을 Partitioned Table 로 전환 & SQL Access Path 를 조정함.

1. Partitioned Table 용 Tablespace 생성

SQL> create tablespace phis_sud_p1 datafile'/data11/DBF/phis_sud_p1.dbf' size 1024Mextent management local segment space management auto;

2. Range + Hash 의 Partitioned 의 Imsi Table 생성

3. 임시 Partitioned Table 로 Buld Insert

set timing on;alter session enable parallel dml;alter table imsi_phis_sud nologging; Archive Mode 인 경우 반드시 !!insert /*+ append parallel(imsi_phis_sud , 16)*/ into imsi_phis_sudselect /*+ parallel (phis_sud 16) */ * from phis_sud;

약 5분 32초 소요 됨. (약 4300 만건)

4. 원본 Table 과 Imsi Table rename

5. 원본 Table 의 PK 및 Index 조정

- DML 시 Index 관련 Buffer Busy Wait 이 다량 발생하므로 PK 도 Partition 함.- Table Partition Key 에 따라 Local / Global Index 로 재 생성

** DBMS_REDEFINITION Package 를 이용하면 On-Line 중에 Single Partitioned Table 로 전환이 가능함.



Hot-Backup 이용



Hot-Backup 이용 : ES40 AS8200

1. AS8200 oracle install & Patch- init<SID>.ora , listener.ora, tnsnames.ora 파일 복사 및 수정

2. ES40 에서 Begin Backup 실시 or 기존 Backup 본 사용SQL> alter system archive log current;SQL> ALTER TABLESPACE SYSTEM BEGIN BACKUP;SQL> !dd if=/dev/rdrd/drd1 bs=4096k | rsh kvmc_as82 "dd of=/dev/rdisk/dsk45a bs=4096k"SQL> ALTER TABLESPACE SYSTEM END BACKUP;

위와 같은 방법으로 모든 데이터 파일에 대해 begin backup, end backup 을 실시 !!

3. AS8200 에서 사용할 Controlfile Script 수정 및 Archived Log 전송- rcp /arch/arch* kvmc_as82:/arch

4. AS8200 에서 Datafile 위치가 바뀐다면 Controlfile 재 생성 및 DB MountSQL> recover database ; ES40 Server 는 업무중에 AS8200 서버에서 Recovery 시작함.

Current Redo or 마지막 Archived log 까지 적용을 함.

6. ES40 DB Down or Read-Only 전환 업무 Down-Time 시작 !!- Redo Log file 전송

SQL> alter system archive log current;SQL> shutdown immediate$ dd if=/dev/rdisk/dsk46d bs=8192k | rsh kvmc_as82 “dd of=/dev/rdisk/dsk5d bs=8192k”

5. AS8200 에서 완전복구 or 불완전복구 실행 Data 손실은 없음 !!- ES40 DB 를 내리고 Current Controlfile 을 복사/전송할 수 있으면 완전복구( recover database; )

ES40 DB 를 내릴 수 없는 상황이라면 Current Controlfile 이 없으므로 불완전 복구 및 Resetlogs DB Open( recover database using controfile … , alter database open resetlogs)

6. 업무 및 HA (fail over ) TEST



RMAN 이용 – 동일 OS , Version , Bit (9.2.x 에서 Test)

1. Host_B oracle install & Patch- init<SID>.ora , listener.ora, tnsnames.ora 파일 복사 및 수정

2. rman 을 이용하여 Host_B Connect% rman target sys/change_on_install@host_b rman/rman@rcat

3. Host_B Instance startup nomountRMAN> startup nomount;

4. Controlfile Restorerun { allocate channel ch1 type disk;

restore controlfile; alter database mount;

}

6. 가장 마지막 SCN 번호를 찾는다. SELECT min(scn) FROM (SELECT max(next_change#) scnFROM v$archived_log GROUP BY thread#);

5. 마지막 SCN 번호까지 DB Recovery 실행run { set until scn = 500; use appropriate SCN for incomplete recovery

allocate channel ch1 type 'sbt_tape'; restore database; recover database; sql "ALTER DATABASE OPEN RESETLOGS";

}

6. 업무 및 HA (fail over ) TEST



Broker

Sync/AsyncProduction Database

Network

Physical Standby Database

OptionalDelay

DIGITAL DATA STORAGE

DIGITAL DATA STORAGE

BackupApply

PhysicalRedo

Logical Standby Database

SQL ApplySync/Async

TransformRedo to

SQL with optional delay

ContinuouslyOpen for Reports

AdditionalIndexes & MVs

II--4. 4. 기타기타 Solutions Solutions –– Data GuardData GuardPhysical vs. Logical Standby


II--4. 4. 기타기타 Solutions Solutions -- ShareplexShareplex



SharePlex 적용 구성도 (RAC)

소스 DB 서버

(LAN / WAN)

SharePlex

data

RedoLog

Queue Queuedatadata

Oracle RAC

타겟 DB 서버

Oracle Non-RAC

SharePlex SharePlex

SQL


서비스 중단 없이 데이터베이스 Migration 가능

운영중인 서버의 O/S나 DBMS등을 버전업 하거나 이기종으로 전환, Migration 할 경우 SharePlex를 이용함으로써 서비스 중단 없이 작업을 할 수 있음

(LAN / WAN)

SharePlex

data

D/B

newD/B

RedoLog Queue Queue

datadata

SharePlex

new DBMS

new O/S

1. 서비스 중단 없이계속 사용

2. 캡처링 계속

4. Upgrade OS,DBMSOr Rebuild D/B

3. Stop Posting5. Install new

SharePlex if need

6. Restart Posting


Replication ::오류만 DB에 반영하지 않음 (비동기방식)

2 Phase Commit ::모두 정상일 때만 DB에 반영 (동기방식)


Migrating F/S on PDC-Based Volumes

** Solaris Platform (Big endian) Linux Platform (Little endian)

0. Using PDC (Portable Data Containers)# vxdg init ora_dg cds=on

1. Check VxFS for Potential Conversion Problems- fscdstask validate Linux /ora_fs

2. Converting a VxFS File SystemSol# umount /ora_fsSol# fscdsconv –f /rcvy/recovery.dat /dev/vx/rdsk/ora_dg/ora_volSol# vxdg deport ora_dg

3. Using a Converted File SystemLnx# vxdg import ora_dgLnx# vxvol –g ora_dg startallLnx# mount –t vxfs /dev/vx/dsk/ora_dg/ora_vol /orafs

II--4. 4. 기타기타 Solutions Solutions –– VeritasVeritas


Migrating F/S on PDC-Based Volumes

9i 이하 동일 Platform & 10g 이기종 Platform Migration 시.

0. 원본 서버에서 Meta 정보만 Export

1. 원본 서버의 Oracle DBF, Dump Volume Deport 신규 서버에 Volume Import 및 Mount

2. 신규 서버에서 Meta 정보를 이용하여 Plug-In & Invalid Object Compile

** 대용량 DBF 신규서버로 이전하는 Down-Time 까지 줄일 수 있음원본 DB 의 복제본을 이용하여 Data Volume 을 이전함.

II--4. 4. 기타기타 Solutions Solutions –– VeritasVeritas


TimeFinderTimeFinder 구현구현 방안방안(1) (1) -- ESTABLISHESTABLISH

1. Full Establish

- 초기 STD Vol.을 BCV Vol.로 복제

2. Incremental Establish

- Full Establish가 최초 이뤄진 후는 변경된Track에 대해서만 Incremental Copy가수행된다

3. 관련 명령어

- #symmir –g bcv_dg –full establish

- #symmir –g bcv_dg est

- #symmir –g bcv_dg query

- #symmir –g bcv1_dg split

운영서버HP-UX

HARAC

Archive Archive

운영서버HP-UX

백업서버HP-UX

Log Log

Data Data

Data Data

Tape장비

DG GroupDG Group

Not Ready

II--4. 4. 기타기타 Solutions Solutions –– EMCEMC


1. TDMF :: OS의 변경된 Block Image 복제 Solution

II--4. 4. 기타기타 Solutions Solutions

2. IPStor :: 이기종 Storage 가상화 및 복제 Solution

3. True-Copy :: EMC, Hitachi, IBM 통합 복제 Solution

4. 기타 NAS , Veritas SnapMirror 등 Solutions…


II. Advanced Migration II. Advanced Migration 기법과기법과 DemoDemo

1.1. Exp / Imp 10Exp / Imp 10배배 빠르게빠르게

2.2. FileFile--System System 과과 rawraw--device device 전환전환

3.3. Partitioned Table MigrationPartitioned Table Migration

4.4. Platform Platform 별별 Direct I/ODirect I/O

5.5. 고객사고객사 실무사례실무사례 소개소개


IIII--1. Exp/Imp 101. Exp/Imp 10배배 빠르게빠르게……

전통적인 Exp Imp :: 51시간 소요

- Down Time이 충분하고 Database 규모가 소규모인 경우(약 100GB이하) 사용 가능한 방법- Source Database를 Full Export한 후 Target Database에 Full Import하는 방법- Export한 File를 Target System으로 Copy 또는 NFS를 이용하여 Import- Export한 File를 임시로 저장할 추가적인 File System이 필요함- Export File의 전송시간을 절약하기 위해 Target System에서 Source DB에 대한 Export를 바로 실행할 수 있음

Source DB

Source DB

TargetDB

TargetDB

Source System Target System

ExportFile

ExportFile

ExportFile

ExportFile

Export ImportFTP/NFS를이용하여 전송

Remote Export



전통적인 Exp Imp :: 51시간 소요


Named Pipe & Multi-Thread :: 4시간 소요

- Named Pipe를 이용하여 Table단위로 Export한 후 Import하는 방법으로 동시에 여러 개의 Table에Export/Import 를 진행함으로써 Database Link를 이용한 방법과 비슷한 수준의 성능을 보장받을 수 있음.

- Database Link를 이용한 방법은 Table별로 Script를 생성해주어야 하나 Parallel Export/Import는 자동화된Tool를 이용하면 Manual하게 Script를 생성할 필요가 없음.

Source DB

Source DB

TargetDB

TargetDB


ExportFile

ExportFile

ExportFile

ExportFile

Export ImportFTP/NFS를이용하여 전송

Remote Export

Source DB

Source DB

TargetDB

TargetDB


Gigabit Network

Named PipeExp file(table)

Exp file(table)

Exp file(table)

Exp file(table)

Exp file(table)

Exp file(table)

Exp file(table)

Exp file(table)

Exp file(table)

Exp file(table)

Exp file(table)

Exp file(table)

Exp file(table)

Exp file(table)

Exp file(table)

Exp file(table)

Exp file(table)

Exp file(table)

Exp file(table)

Exp file(table)

Named Pipe

Named Pipe

Named Pipe

Named Pipe

Named Pipe를 이용한Parallel Exp/Imp

Export Import


IIII--1. Exp/Imp 101. Exp/Imp 10배배 빠르게빠르게……System 환경 – Remote export 가 지원되는 경우

- Source DB :: Linux, Oracle 9i R2- Target DB :: Solaris, Oracle 9i R2

Named Pipe 사용예제

1. TNS_Alias 생성% vi $TNS_ADMIN/tnsnames.ora

REMOTE =(DESCRIPTION =(ADDRESS_LIST =(ADDRESS = (PROTOCOL = TCP)(HOST = Source_DB_IP)(PORT = 1521))

)(CONNECT_DATA =(SERVER = DEDICATED)(SERVICE_NAME = ORCL)

))

2. Named Pipe 생성 Target DB !!% mknod /tmp/exp_pipe p

3. Export / Import Target DB !!% exp ID/PWD@REMOTE file=/tmp/exp_p log=exp_log buffer=10240000 directy=y &% imp ID/PWD file=/tmp/exp_p log=imp_log commit=y feedback=100 indexes=n …

** Source DB 에 export 받은 공간이 없는 경우에도 사용함 !!


System 환경 – Remote Export 가 지원되지 않는 경우

- Source DB :: Linux, Oracle 9i R2- Target DB :: Solaris, Oracle 10g R2

10gR2 에서는 9i DB 에 Remote 로 Export 가 지원되지 않는다.

Named Pipe 사용예제 ( dd 이용 )

1. Named Pipe 생성 & rsh 환경

% mknod /tmp/exp_pipe p Source DB 생성 !!% mknod /tmp/imp_pipe p Target DB 생성 !!

% rsh TARGET “ls –l “

2. Source DB 에서 Export Source DB !!

% dd if=/tmp/exp_p bs=8k | rsh TARGET “dd of=/tmp/imp_p bs=8k” &% exp ID/PWD file=/tmp/exp_p log=exp_log buffer=10240000 directy=y …

3. Target DB 에서 Import Target DB !!

% imp ID/PWD file=/tmp/imp_p log=imp_log commit=y feedback=100 indexes=n …

** 대용량 Data 인 경우 여러 개의 Pipe 를 생성하여 각 Table 별로 parallel 하게 진행한다. ** Source DB 에 export 받은 공간이 없는 경우에도 사용함 !!




echodateecho "BEGIN PART_1_TFN101"echodd if=/ORACLE/REHOSTING/PIPE/PART_1_TFN101 ibs=4k | rsh 신규DB “dd of=/DB00/REHOSTING/PIPE/PART_1_TFN101 obs=8k" &exp rehost/’비밀번호’ file=/ORACLE/REHOSTING/PIPE/PART_1_TFN101 ₩log=/ORACLE/REHOSTING/EXPLOG/exp_PART_1_TFN101.log direct=y feedback=500000 ₩tables=rehost.TFN101

echoecho "END PART_1_TFN101 "dateEcho

echodateecho "BEGIN PART_1_TFN101"echoimp rehost/rehost file=/DB00/REHOSTING/PIPE/PART_1_TFN101 ₩log=/DB00/REHOSTING/IMPLOG/imp_PART_1_TFN101.log commit=y feedback=100000 ₩indexes=n ignore=y statistics=none RESUMABLE_TIMEOUT=1000 RESUMABLE=y full=yechoecho "END PART_1_TFN101"dateecho

exp_01.sh

imp_01.sh

실무사례 소개 – Fund 투자회사



imp_01.sh

실무사례 소개 – Fund 투자회사


Direct & Conventional Path



IIII--2. File2. File--System System 과과 rawraw--device device 전환하기전환하기

OS 별 Reserved size

** Oracle Data File 을 raw-device & File-System 으로 전환할 때 사용하며,특히 File-System 의 Single DB 환경을 raw-device 의 RAC 환경으로 전환시에 사용한다.

** 대부분의 OS 에서 raw device File 로 전환할 경우에는 반드시 Count 값을 주어야 한다.반대의 경우로 File raw device 의 경우 count 가 없더라도 File-System 상에서정확한 DBF Size block 개수만큼 raw device 에 기록한다.

** dd command 로 Read 시에는 skip 을 , Write 시에는 seek 을 사용 !!

Platform OS Reserved Size

Sun Solaris 0

HP-UX 0

IBM AIX 4K mklv –t0 mklv –T

Compaq Tru64 64K

Linux / Sco 0

Windows 0



IBM AIX 사용예

IBM AIX 5L 이후 OS Version 의 Oracle 10g 에서는 LV (raw-device) 생성시에 반드시 다음의 Option 을사용하도록 Recommend 한다.

/usr/sbin/mklv -y 'rac_data01' -T O -w n -s n -r n oravg03 128

즉 해당 Volume 이 Big Volume 을 지원함과 동시에 해당 LV 의 0번째 Offset 부터 사용하여 LV I/O Performance 를 향상시키며, 10g 에서는 –T Option 을 사용하지 않고 Tablespace 를 생성하면 다음의Warning Message 가 뿌려진다.

## alert.log 내용 !!

WARNING: You are creating/reusing datafile /dev/rlvb_CT_D01.WARNING: Oracle recommends creating new datafiles on devices with zero offset. The command "/usr/sbin/mklv -y LVname -T O -w n -s n -r n VGname NumPPs" can be used. Please contact Oracle customer support for more details.Completed: create tablespace CT_TS_D datafile '/dev/rlvb_CT_D01' size 4000m segment space management autoWed May 3 04:21:57 2006create tablespace CT_TS_I datafile '/dev/rlvb_CT_I01' size 1000m autoextend offWed May 3 04:21:57 2006WARNING: You are creating datafile /dev/rlvb_CT_I01.WARNING: Oracle recommends creating new datafiles on devices with zero offset. The command "/usr/sbin/mklv -y LVname -T O -w n -s n -r n VGname NumPPs" can be used. Please contact Oracle customer support for more details.

IBM AIX 사용예

만약 chlv –T O /dev/rac_data01 의 명령을 사용하여 속성을 바꾸게 되면 모든 DBF Header Block 에대한 정보가 0번 Offset 부터 사용하게 되고, 결국 Header block 정보를 읽지못해 Crash 가 되므로 절대바로 수정을 해서는 안된다.!!.

## chlv –T O /dev/rlva_CONTROL01 후...ALTER DATABASE MOUNTFri May 5 18:34:48 2006This instance was first to mountFri May 5 18:34:48 2006ORA-00202: control file: '/dev/rlva_CONTROL01'ORA-27047: unable to read the header block of fileAdditional information: 2ORA-205 signalled during: ALTER DATABASE MOUNT...Fri May 5 18:34:49 2006Reconfiguration started (old inc 2, new inc 4)List of nodes

그러나 File-System 및 기본 Option 인 –t 를 사용하게 되면 AIX LV(logical volume, raw device)의 경우처음 512 Bytes 를 LVCB(logical volume control block)라 하여, AIX LVM(Logical Volume Manager)이제어용으로 사용합니다. AIX Raw Device 를 데이타 파일로 사용시 Oracle 에서는 이 부분을 포함한 처음4096 Bytes 를 사용하지 않는다고 합니다.

즉 Raw Device 의 4097 바이트째 부터 오라클 데이타가 쓰여집니다.



IBM AIX 사용예

위의 차이점은 아래 dbfsize 라는 command 를 통해 확인 할 수 있다.

$ dbfsize /oracle-2/IMSI/rt_test01.dbfDatabase file: /oracle-2/IMSI/rt_test01.dbfDatabase file type: file system with 4K starting offsetDatabase file size: 128000 8192 byte blocks

$dbfsize /dev/rT_TEST01Database file: /dev/rT_TEST01Database file type: raw device without 4K starting offsetDatabase file size: 128000 8192 byte blocks

해당 문서는 다음의 내용을 담고 있으며 File-System 으로 구성된 대용량 Data 를 raw-device 등으로Migration 하거나, 신규 Version-Up 을 할 경우 즉, Single DB RAC 환경으로 Migration 할 경우 실시간으로 F/S raw-device 로 전환이 가능하므로 Down-Time 없이 Data Migration 이 가능하다.

1. F/S raw-device (mklv –t)2. raw-device (mklv –t) F/S3. F/S raw-device (mklv –T)4. raw-device (mklv –T) F/S5. raw-device (mklv –t) raw-device (mklv –t)6. raw-device (mklv –T) raw-device (mklv –T)7. raw-device (mklv –t) raw-device (mklv –T)8. raw-device (mklv –T) raw-device (mklv –t)

기본환경

. OS : AIX localhost 1 5 000B5CBF4C00

. Oracle : 9.2.0.7 64bit (Archive log mode)

. 생성 LV# /usr/sbin/mklv -y 't_test01' –t 'O' oravg 2# /usr/sbin/mklv -y 't_test02' –t 'O' oravg 2# /usr/sbin/mklv -y 'T_TEST01' -T O -w n -s n -r n oravg 2# /usr/sbin/mklv -y 'T_TEST02' -T O -w n -s n -r n oravg 2# chown oracle.dba /dev/rt_test0*# chown oracle.dba /dev/rT_TEST0*

SQL> create tablespace small_t datafile '/oracle-2/IMSI/small_t.dbf' size 100m;SQL> create tablespace big_t datafile '/oracle-2/IMSI/big_t.dbf' size 100m;SQL> create table test.COUNTRIES tablespace small_t

as select * from hr.COUNTRIES;SQL> create table test.DEPARTMENTS tablespace small_t

as select * from hr.DEPARTMENTS;SQL> create table test.JOB_HISTORY tablespace big_t

as select * from hr.JOB_HISTORY;SQL> create table test.locations tablespace big_t as select * from hr.locations;

SQL> select (blocks+1)*8192/4096from dba_data_fileswhere file_name=’/oracle-2/IMSI/small_t.dbf’;

:: 25602



1. F/S raw-device (mklv –t)- 일반 File-System DBF 를 raw-device (mklv –t) 로 Conversion !!

SQL> alter tablespace small_t offline;$ dd if=/oracle-2/IMSI/small_t.dbf of=/dev/rt_test01 bs=4096 seek=125602+0 records in25602+0 records out

SQL> alter database rename file '/oracle-2/IMSI/small_t.dbf' to '/dev/rt_test01';SQL> alter database open;

2. raw-device (mklv –t) F/S- raw-device (mklv –t) 를 일반 File-System DBF 로 Conversion !!

SQL> alter tablespace small_t offline;$ dd if=/dev/rt_test01 of=/oracle-2/IMSI/small_t01.dbf bs=4096 skip=1 count=2560225602+0 records in25602+0 records out

-rw-r----- 1 oracle dba 104865792 May 13 07:36 small_t.dbf-rw-r----- 1 oracle dba 104865792 May 13 07:42 big_t.dbf-rw-r--r-- 1 oracle dba 104865792 May 13 07:48 small_t01.dbf

SQL> alter database rename file '/dev/rt_test01' to '/oracle-2/IMSI/small_t01.dbf';SQL> alter tablespace small_t online;



1. F/S raw-device (mklv –t)- 일반 File-System DBF 를 raw-device (mklv –t) 로 Conversion !!

SQL> alter tablespace small_t offline;$ dd if=/oracle-2/IMSI/small_t.dbf of=/dev/rt_test01 bs=4096 seek=125602+0 records in25602+0 records out

SQL> alter database rename file '/oracle-2/IMSI/small_t.dbf' to '/dev/rt_test01';SQL> alter database open;

2. raw-device (mklv –t) F/S- raw-device (mklv –t) 를 일반 File-System DBF 로 Conversion !!

SQL> alter tablespace small_t offline;$ dd if=/dev/rt_test01 of=/oracle-2/IMSI/small_t01.dbf bs=4096 skip=1 count=2560225602+0 records in25602+0 records out

-rw-r----- 1 oracle dba 104865792 May 13 07:36 small_t.dbf-rw-r----- 1 oracle dba 104865792 May 13 07:42 big_t.dbf-rw-r--r-- 1 oracle dba 104865792 May 13 07:48 small_t01.dbf

SQL> alter database rename file '/dev/rt_test01' to '/oracle-2/IMSI/small_t01.dbf';SQL> alter tablespace small_t online;

3. F/S raw-device (mklv –T)- 일반 File-System DBF 를 Big Volume raw-device (mklv –T) 로 Conversion !!

SQL> alter tablespace big_t offline;$ dd if=/oracle-2/IMSI/big_t.dbf bs=4096 seek=1 of=/dev/rT_TEST01 bs=4096 seek=025602+0 records in25602+0 records out

SQL> alter database rename file '/oracle-2/IMSI/big_t.dbf' to '/dev/rT_TEST01';SQL> alter tablespace big_t online;

4. raw-device (mklv –T) F/S- Big Volume raw-device (mklv –T) 를 일반 File-System DBF 로 Conversion !!

SQL> alter tablespace big_t offline;$ dd if=/dev/rT_TEST01 of=/oracle-2/IMSI/big_t01.dbf bs=4096 seek=0 count=2560225602+0 records in25602+0 records out

-rw-r----- 1 oracle dba 104865792 5월 13일 11:49 big_t.dbf-rw-r--r-- 1 oracle dba 104865792 5월 13일 14:02 big_t01.dbf

SQL> alter database rename file '/dev/rT_TEST01' to '/oracle-2/IMSI/big_t01.dbf';SQL> alter tablespace big_t online;



5. raw-device (mklv –t) raw-device (mklv –t)- raw-device (mklv –t) 를 raw-device (mklv –t) 로 Conversion !!

SQL> alter tablespace small_t offline;

$ dd if=/dev/rt_test02 of=/dev/rt_test01 bs=8k32768+0 records in32768+0 records out

SQL> alter database rename file '/dev/rt_test02' to '/dev/rt_test01';SQL> alter tablespace small_t online;

6. raw-device (mklv –T) raw-device (mklv –T)- Big Volume raw-device (mklv –T) 를 Big Volume raw-device (mklv –T) 로 Conversion !!

SQL> alter tablespace big_t2 offline;

$ dd if=/dev/rT_TEST01 of=/dev/rT_TEST02 bs=409665536+0 records in65536+0 records out

SQL> alter database rename file '/dev/rT_TEST01' to '/dev/rT_TEST02';SQL> alter tablespace big_t2 online;



5. raw-device (mklv –t) raw-device (mklv –t)- raw-device (mklv –t) 를 raw-device (mklv –t) 로 Conversion !!


$ dd if=/dev/rt_test02 of=/dev/rt_test01 bs=8k32768+0 records in32768+0 records out

SQL> alter database rename file '/dev/rt_test02' to '/dev/rt_test01';SQL> alter tablespace small_t online;

6. raw-device (mklv –T) raw-device (mklv –T)- Big Volume raw-device (mklv –T) 를 Big Volume raw-device (mklv –T) 로 Conversion !!

SQL> alter tablespace big_t2 offline;

$ dd if=/dev/rT_TEST01 of=/dev/rT_TEST02 bs=409665536+0 records in65536+0 records out

SQL> alter database rename file '/dev/rT_TEST01' to '/dev/rT_TEST02';SQL> alter tablespace big_t2 online;

7. raw-device (mklv –t) raw-device (mklv –T)- raw-device (mklv –t) 를 Big Volume raw-device (mklv –t) 로 Conversion !!


$ dd if=/dev/rt_test02 skip=1 of=/dev/rT_TEST02 bs=4096 seek=065535+0 records in65535+0 records out

SQL> alter database rename file '/dev/rt_test02' to '/dev/rT_TEST02';SQL> alter tablespace small_t online;

8. raw-device (mklv –T) raw-device (mklv –t)- Big Volume raw-device (mklv –T) 를 raw-device (mklv –T) 로 Conversion !!

SQL> alter tablespace big_t offline;

$ dd if=/dev/rT_TEST01 of=/dev/rt_test01 bs=4096 seek=165536+0 records in65535+0 records out

SQL> alter database rename file '/dev/rT_TEST01' to '/dev/rt_test01';SQL> alter tablespace big_t online;


1. DB Link 생성. 여러 개의 Private 용 Giga Channel 사용…SQL> create public database link MIG …

2. 원본 DB 에서 각 Partition 별로 Query 하는 View 생성SQL> create or replace view t_cust_1

as select * from t_cust_hash partition (par_hash_1);

3. Target DB 에서 Partitioned Table 생성 후 Partition 별로 Insert ~ Selectset timing on;alter session enable parallel dml;alter table cust_1 nologging; Archive Mode 인 경우 반드시 !!

insert /*+ append parallel (cust_1 , 16)*/ into cust_1nologgingselect /*+ parallel (A 16) */ * t_cust_1@REMOTE A;

4. Target DB 에서 Global / Local Index 를 unusable option 으로 생성CREATE INDEX CUST_IDX1 ON CUST (CUSTNO) GLOBAL

PARTITION BY RANGE (CUSTNO) (PARTITION PAR_01 VALUES LESS THAN (‘20’) TABLESPACE TBS_P1,

…PARTITION PAR_MAX VALUES LESS THAN (MAXVALUE) TABLESPACE TBS_Pn)

UNUSABLE;

5. Global / Local Index 를 각 Partition 별로 Parallel RebuildSQL> ALTER SYSTEM SET SKIP_UNUSABLE_INDEXES = TRUE;SQL> ALTER INDEX CUST_IDX1 REBUILD PARTITION PAR_01 PARALLEL 4; ---‘ index1.sqlSQL> ALTER INDEX CUST_IDX1 REBUILD PARTITION PAR_02 PARALLEL 4; ---‘ index2.sql …SQL> ALTER INDEX CUST_IDX1 REBUILD PARTITION PAR_MAX PARALLEL 4; ---‘ index10.sql

IIII--3. Partitioned Table Migration 3. Partitioned Table Migration Partitioned Table Migration


IIII--3. Partitioned Table Migration 3. Partitioned Table Migration SKIP_UNUSABLE_INDEXES

- 10g 에서는 Default 값이 TRUE

- INDEX가 걸려 있는 TABLE에서 TABLE에만 INSERT하는 방법(INDEX DISABLE)

Oracle8 ~9i 에서는 Index가 걸려있는 table에 insert는 disable시키고 table에만 먼저 Insert할 수가 있다. 그 방법을 알아보자.

대량의 DATA를 한꺼번에 INSERT하는 경우에는 TABLE에 걸려있는 INDEX 때문에 속도가 느려지게 된다. INDEX를 DROP하고 INSERT한 후에 다시 생성할수도 있지만 그 경우에도 데이터가 많으므로 INDEX를 다시 생성하는 데에 시간이 오래 걸리게 된다.

Oracle8~9i 에서는 이런 경우 index를 고려하지 않고 insert를 한 후에 index를 rebuild하는 방법을 사용할 수 있다. 대량의 data를 입력할 때에 index에는 입력하지 않으므로 보다 속도가 빠르며 index를 rebuild하는 것은 drop한 후에 다시 생성하는 것 보다 속도가 빠르므로 더 효율적인 방법이 될 수 있다.

이 방법은 Local Index 또는 Global Index 에 대해 관계없이 사용할 수 있다.

- ON-LINE에서 사용하는 방법

1. 먼저 index의 status를 살펴보면

SQL> select index_name, table_name, status from user_indexes;

INDEX_NAME TABLE_NAME STATUS---------------- ------------------ --------I_DEPT DEPT VALID

2. insert를 table의 index인 I_dept 를 unusable 상태로 바꾼다.

SQL> alter index i_dept unusable;SQL> select index_name, table_name, status from user_indexes;

INDEX_NAME TABLE_NAME STATUS--------------- ----------------- --------I_DEPT DEPT UNUSABLE

3. index 가 unusable 인 상태에서는 insert할 수 없으며 다음과 같은 명령어를 실행하여야 insert가 가능하다

SQL> alter session set skip_unusable_indexes = true;SQL> insert into dept values(50,'aaa','aaa');


IIII--3. Partitioned Table Migration 3. Partitioned Table Migration SKIP_UNUSABLE_INDEXES

4. insert를 하는 작업이 모두 끝나면 다음과 같이 index를 rebuild해 준다.

SQL> alter index i_dept rebuild;SQL> select index_name, table_name, status from user_indexes;

INDEX_NAME TABLE_NAME STATUS---------------- ----------------- --------I_DEPT DEPT VALID

- SQL*LOADER에서 사용하는 방법

SQL*LOADER에서는 다음의 COMMAND OPTION으로 이 방법을 사용할 수 있다.

SKIP_UNUSABLE_INDEXES = TRUE ( DEFAULT 는 FALSE )

Loader에서 작업하기 전에 먼저 해당 Index를 Unusable 상태로 바꾼 후에 다음과 같이 sql*loader를 실행한다.

% sqlldr userid=scott/tiger control=dept.ctl skip_unusable_indexes=true

- Data Pump 사용하는 방법

10g Data Pump 에서도 다음의 COMMAND OPTION으로 이 방법을 사용할 수 있다.

SKIP_UNUSABLE_INDEXES = Y (10g 에서 Default 값)

impdp에서 작업하기 전에 먼저 해당 Index를 Unusable 상태로 바꾼 후에 다음과 같이 impdp를 실행한다.

% impdp scott/tiger directory=USR_DATA dumpfile=schema_test.dmp skip_unusable_indexes=Y

[ Network Mode Imp에 ]

% impdp scott/tiger network_link=‘DB_Link 이름’ directory=USR_DATA dumpfile=schema_test.dmp skip_unusable_indexes=Y


IIII--4. Platform 4. Platform 별별 Direct I/ODirect I/O

< Solaris ># mount –o remount,nologging,forcedirectio /oradata1


IIII--5. 5. 고객사고객사 실무사례실무사례 소개소개

대형 포탈 사



대형 포탈 사


III. 10g III. 10g 이기종이기종 Platform MigrationPlatform Migration

1.1. TTS (Transportable TTS (Transportable TablespaceTablespace))

2.2. TTS TTS 이용한이용한 이기종이기종 MigrationMigration

3.3. 이기종이기종 Migration GuideMigration Guide

4.4. TroubleTrouble--shootingshooting


IIIIII--1. TTS (Transportable 1. TTS (Transportable TablespaceTablespace))

1. TSPITR (Tablespace Point-In-Time Recovery)

- 사용자 실수에 의한 Table Level 단위 복구시에 Clone DB 용도- Standby DB 및 Data Guard 복제 구성시

When Use ?

2. Tablespace 단위 Data Migration 시

3. DB 복구시 Read Only 로 DB 가 강제 Open 되는 경우 !!

- System Dictionary View 일부가 손상이 되는 경우 강제 DB Open 시에 R/O 가 될 수 있음- 신규 DB 생성 후 기존 R/O DB 에서 Meta 만 Exp Imp

- Data File 개수가 많은 경우 Controlfile to trace 를 이용하여 해당 순서로 진행하면 됨

AS-IS To-Be 고려사항

8i 8i 1. 동일 Platform

2. 동일 Character-Set

3. 동일 DB_BLOCK_SIZE

8i 9i or 10g

9i 9i or 10g

1. 동일 Platform

2. 동일 Character-Set

10g 10g 1. 동일 Character-Set


1. DB Character Set Check

SQL> select * from sys.props$ where name like '%CHARACTERSET';

2. Transportable TBS 준비 및 Export

Step 1: Transportable 대상인 Portal TBS 가능 여부 확인SQL> exec DBMS_TTS.TRANSPORT_SET_CHECK('PORTAL', TRUE); SQL> select * from sys.transport_set_violations;

Step 2: Transportable Tablespace Set 준비SQL> alter tablespace PORTAL read only; % exp transport_tablespace=y tablespaces=PORTAL tts_full_check=y file=trans.dmp 반드시 SYS 유저로…

만약 EXP-00091: Exporting questionable statistics Error 가 발생을 하면 statistics=NONE 추가하여 exp 할 것!!

3. 해당 DBF Copy to Target DB Server

Step 3: 다른 DB Server 로 해당 DBF copy (or ftp)

4. Import to Target DB Server .

Step 4: Plug In the Tablespace Set 만약 PORTAL 유저가 없으면 생성하여 준다.

% imp transport_tablespace=y tablespaces=PORTAL datafiles='/home1/user19/ORADATA/u05/portal.dbf' file=trans.dmp log=trans.log Imp 시 line: 1 31576 Segmentation fault 인 경우 plan_table 을 drop 한 후 exp imp 할 것!!IMP-00003, ORA-19722 Error 인 경우는 exp 후 DB에 변경사항이 있는 경우이므로 역시 다시 exp imp 하도록 한다.

5. 기타 작업

Step 5: 해당 Tablespace Read WriteSQL> alter tablespace PORTAL read write;

Step 6: Invalid Objects Compile 등.



10g Transportable Tablespace – 동일 Endian- Linux (Little) Windows (Little)

SQL> alter tablespace Users read only;

$ exp tablespaces=users transport_tablespace=y file=exp_ts_users.dmp

OS 의 ftp , rcp 등으로 exp_ts_users.dmp 와 users01.dbf 파일 전송

$ imp tablespaces=users transport_tablespace=y file=exp_ts_users.dmp

datafiles='users_01.dbf'

SQL> alter tablespace Users read write;

1. 해당 Tablespace 를 Read-Only Mode로 변경한다.

2. 해당 Tablespace 를 Export 한다.

3. OS 의 rcp, ftp 등으로 dmp 와 DBF 를 전송한다.

4. 해당 Tablespace Plugging 한다.

5. 해당 Tablespace 를 Read-Write Mode 로 변경한다.

** 8i Version : 동일 Platform (동일 Bit) & 동일 BlockSize (Oracle Blocksize)9i Version : 동일 Platform (동일 Bit) & 이기종 Blocksize 가능

10g Version : 이기종 Platform & 이기종 Blocksize 지원

** 단 DBMS 의 Character-Set 는 동일하여야 한다. (ex: WE8ISO8859P1)



10g Transportable Tablespace – 이기종 Endian- Linux (Little) HP-UX (Big)

$ RMAN> convert tablespace users, maints

2> to platform 'HP-UX (64-bit)'

3> format='/home/oracle/rman_bkups/%N_%f'

4> parallelism = 5;

- Target 서버와 Source 서버의 byte order가 다르면 전송된 데이타를 올바르게 인식할 수 없으므로, 단순 카피 작업으로Data 파일을 이동하는 것이 불가능하다. Oracle 10g RMAN 유틸리티가 Datafile 을 다른 Byte order 로 변환하는 기능을지원한다.

Starting backup at 14-MAR-04…allocated channel: ORA_DISK_5channel ORA_DISK_5: sid=253 devtype=DISKchannel ORA_DISK_1: starting datafile conversioninput datafile fno=00004 name=/usr/oradata/dw10/dw10/users01.dbf…channel ORA_DISK_4: datafile conversion complete, elapsed time: 00:00:01Finished backup at 14-MAR-04

위 과정을 거치면 /home/oracle/rman_bkups 디렉토리에 표준 RMAN 파일 포맷의 파일이 <tablespace_name>_<absolute_datafile_no> 의 파일명으로 생성됩니다. 결국 USERS 테이블스페이스 자체는 전혀 변경되지 않았고, HP-UX 환경을 위한 새로운 파일이 생성되었습니다. 이제 이 파일을 타겟 시스템으로 복사한 뒤 위에서 설명한 것과같은 처리 과정을 거치면 됩니다parallelism = 4위와 같이 하면 네 개의 RMAN 채널이 생성되어 각각 별도의 데이타파일에 대해 변환 작업을 수행합니다. 하지만 parallelism이 정말로 효과를 발휘하는 것은, 많은 수의 테이블스페이스를 한꺼번에 변환할 때입니다



TTS & File-Copy


Source DB

Source DB

TargetDB

TargetDB

Source SystemSUN/HP

Target SystemIBM AIX

Gigabit Network

File 전송DBFDBF

DBFDBF

DBFDBF

DBFDBF

DBFDBF

DBFDBF

DBFDBF

DBFDBF

DBFDBF

DBFDBF

File 전송

File 전송

File 전송

File 전송

File-Copy 를 통한File 전송

1. Manual Upgrade2. New Feature 적용

IIIIII--2. TTS 2. TTS 이용한이용한 이기종이기종 MigrationMigration


• All combinations of ASM and non-ASM file transfers

• ASM to ASM• ASM to O/S file• O/S file to ASM• O/S file to O/S file

IIIIII--2. TTS 2. TTS 이용한이용한 이기종이기종 MigrationMigrationEnhanced Migration Options DBMS_FILE_TRANSFER


1. 준비작업

1) 유저 생성 – Target 인 Sun 에…SUN> create user air identified by air;SUN> grant connect,resource to air;

2) Directory 생성 (Linux, Sun both)Lnx> create or replace directory LNX_DG

as ‘/fw1/oracle10/WORK’;Lnx> grant write on directory LNX to air;SUN> create or replace directory SUN

as ‘/dev/vx/rdsk/racdg’; SUN> grant write on directory SUN to air;

3) DB Link 생성 (DBMS_FILE_TRANSFER 용)SUN> create public database link DB_LINK

connect to air identified by air using ‘SUN’;

4) Sun 에 raw-device 생성#vxassist -g racdg make air01 1200m layout=stripe stripeunit=32k disk1 disk2 disk3

#vxassist -g racdg make air02 2000m layout=stripe stripeunit=32k disk1 disk2 disk3

#vxedit -g racdg set user=oracle10 group=dbamode=660 air01

#vxedit -g racdg set user=oracle10 group=dbamode=660 air02

2. Transportable CheckSUN> exec

dbms_tts.transport_set_check(‘AIR’,TRUE) SUN> select * from sys.transport_set_violations;SUN> alter tablespace air read only;

Linux 2.6.9 (Little)

Oracle 10.2.0.2 32bit‘+DG1/oradata/air01.dbf’‘+DG1/oradata/air02.dbf’

Solaris 2.9 (Big)

Oracle 10.2.0.2 64bit/dev/vx/rdsk/racdg/air01/dev/vx/rdsk/racdg/air02

Endian 이 다르므로 RMAN으로 Conversion 한 후 DBMS_FILE_TRANSFER 로 이전함.



Solaris 2.9 (Big)

Oracle 10.2.0.2 64bit/dev/vx/rdsk/racdg/air01/dev/vx/rdsk/racdg/air02

Lnx> ftp sunput air.dmp

Lnx> alter tablespace air read write;

6. Plug-In% imp userid=₩'sys/welcome as sysdba₩'

file=air.dmp log=air_i.log ₩transport_tablespace=y ₩datafiles='/dev/vx/rdsk/racdg/air01’,

'/dev/vx/rdsk/racdg/air02’

SUN> alter tablespace air read write;SUN> alter user air default tablespace air;

7. 기타 확인 내용1) 통계정보2) Constraints,Trigger 를 제외한 기타 Procedure,

Function 등, Invalid Object 확인3) 기타 실행계획

3. Exp only Meta% exp userid=₩'sys/welcom as sysdba₩'

file=air.dmp log=air.log ₩transport_tablespace=y tablespaces=air

4. RMAN Convert to Solaris% rman target=/ nocatalogRMAN> CONVERT TABLESPACE air

TO PLATFORM 'Solaris[tm] OE (64-bit)' FORMAT '/fw1/oracle10/WORK/%U';

5. Data Copy 동시 실행 !!Lnx> exec DBMS_FILE_TRANSFER.PUT_FILE

(‘LNX_DG',‘air01.dbf',‘SUN',‘air01',‘DB_LINK') ;Lnx> exec DBMS_FILE_TRANSFER.PUT_FILE

(‘LNX_DG',‘air02.dbf',‘SUN',‘air02',‘DB_LINK') ;

## ASM 은 dd 가 지원되지 않음!!ASM ftp 로 OS Down 후 dd 로 전송가능

Linux 2.6.9 (Little)

Oracle 10.2.0.2 32bit‘+DG1/oradata/air01.dbf’‘+DG1/oradata/air02.dbf’



AIX 5.3

Oracle 10.2.0.2 64bit‘/datadg/rdata_01.dbf’

5. User 생성10g> create user ruser identified by ruser;

6. Tablespace Plug-In% imp userid=₩'sys/welcome as sysdba₩'

file=trans.dmp log=i_trans.log ₩transport_tablespace=y ₩datafiles='/datadg/rdata_01.dbf’

10g> alter tablespace R_DATA read write;10g> alter user ruser default tablespace R_DATA;

7. 기타 확인 내용1) 통계정보2) Constraints,Trigger 를 제외한 기타 Procedure,

Function 등, Invalid Object 확인3) 기타 실행계획

AIX 4.3.3

Oracle 9.2.0.6 32bit‘/oradata/rdata_01.dbf’

1. Transport_Set_Check9i> exec DBMS_TTS.TRANSPORT_SET_CHECK

(‘R_DATA’,TRUE);9i> select * from transport_violations;

2. Tablespace Read Only9i> alter tablespace R_DATA read only;

3. Exp only Meta% exp userid=₩'sys/welcom as sysdba₩'

file=trans.dmp log=trans.log ₩transport_tablespace=y tablespaces=R_DATA

4. Data Copy% rcp or ftp or dd 등으로 전송함.

9i> alter tablespace R_DATA read write;

동일 Platform, Character-Set, National Character-Set 이어야 함 !!.



IIIIII--3. 3. 이기종이기종 Migration GuideMigration Guide

Migration 방법 장 점 단 점 비 고

TTS & File-Copy

(10g 이상)

• 이기종간 Data File 이 호환이 됨

• Down-Time 을 최소화 할 수 있고가장 빠른 Migration 방법

• Raw-device, ASM, File-System 등모든 File 에서 적용 가능함

• File-Copy 시간이 Down-Time !!

• 양쪽 DB가 모두 10g 이상이어야함.

• Archive log mode 이면 Down Time 최소화!!

• (c), (e), (j) 에 적용

Manual Upgrade

(동일 Platform)

• Down-Time 을 최소화 할 수 있고가장 빠른 Migration 방법

• Raw-device, File-System 등 모든File 에서 적용가능함.

• File-Copy 시간이 Down-Time !!

• 806/817/920/101 Version 이어야함.

• 반드시 동일 Platform 이어야 함.

• Upgrade 후 10g R2 New Feature 적용작업이 필요함

• Archive log Mode 이면 Down Time 최소화!!

• (d), (g), (h), (i) 에적용

DB Link CTAS

Ora*Pipe

(50G 이상 DB)

• Migration 성능이 빠름

• Migration을 위한 별도의 Tool이 필요 없음

• 대용량 Table 의 Parallel 처리 !!

• Table별로 Migration Script를 생성해야 함

• Migration검증 Script준비가 쉽지않음

• Down Time이 필요

• (a), (b), (k) 에 적용

Export/Import

(50G 이하 DB)

• Table Re-Org 효과 발생

• Table단위의 Migration Script를 자동화

• 가장 손쉬운 Migration 방법

• Table의 크기가 큰 경우 Migration 시간이 오래 걸릴 수 있음

• Down Time이 필요

• (f) 외 (a), (b) 중 일부

DB Migration 방법 산정 예


구분 (대수) AS-IS To-Be OS AS-IS To-Be DB Version

HP-UX AIX (27)8i 10g R2 (a)

9i 10g R2 (b)

10g R1 10g R2 (c)

9i 10g R2 (d)

10g R1 10g R2 (e)

9i 10g R2 (f)

8i 10g R2 (g)

9i 10g R2 (h)

9i 10g R2 (i)

10g R1 10g R2 (j)

9i 10g R2 (k)

HP-UX AIX (16) HP-UX 11 AIX 5.3 TTS & File-Copy

Linux Linux (4) Linux Linux Manual Upgrade

Solaris AIX (6) Solaris 8 AIX 5.3TTS & File-Copy

Exp / Imp

Win2K Win2K (5) Win 2000 Win 2000 Manual Upgrade

AIX AIX (12) AIX 5.2/4.3.3 AIX 5.3 Manual Upgrade

RAC (2) HP-UX 11 AIX 5.3 TTS & File-Copy

HP-UX Linux (1) HP-UX 11 Redhat 4

Migration 방법

CTAS

HP-UX 11 AIX 5.3CTAS or

Named-Pipe & Exp/Imp

** TTS (Transportable Tablespace) ::

10g 부터는 이기종 Platform 간 DataFile 호환이 가능하여 Data Migration 시간을 획기적으로 줄일 수 있음.

** 8i 이후부터 동일 Platform 인 경우 ::

8i/9i/10gR1 10g R2 로 Upgrade 시에는 10g R2에 새로운 DB 생성후에 원하는 Tablespace

/ Schema 만 Transportable Tablespce 방식의 File-Copy 를 통해 손쉽게 Migration 할 수 있음.

IIIIII--3. 3. 이기종이기종 Migration GuideMigration GuideDB Migration 방법 산정 예


IIIIII--4. Trouble4. Trouble--shootingshootingCompatible 문제 - ORA-600 [qctstc2o1]

8.1.7 DB 를 9.2.0.1 로 Upgrade 하는 도중 startup migrate 하기전에 COMPATIBLE = 9.2.0.0.0 으로 (Default : 8.1.0) 잘못 Setting 하여 DB 를 startup migrate 한 경우에 발생함

alert.log

Fri Mar 04 23:29:57 2005Started recovery atThread 1: logseq 17130, block 2, scn 0.4706768

Recovery of Online Redo Log: Thread 1 Group 3 Seq 17130 Reading mem 0Mem# 0 errs 0: E:₩ORADATA₩SEOULGIS₩REDO03.LOG

Fri Mar 04 23:29:57 2005Ended recovery atThread 1: logseq 17130, block 1370, scn 0.472841658 data blocks read, 13 data blocks written, 1368 redo blocks read

Crash recovery completed successfullySwitching redo format version from 8.1.0.0.0 to 9.2.0.0.0 at change 4728417

** 해결방법event = "10619 trace name context forever, level 1“ init<SID>.ora로 DB Migrate 후 9i Upgrade Script (u0801070.sql, cmpdbmig.sql ) DB Shutdown 후 utlrp.sql 등등을 수행 할 것 !!

alert.log

Sat Mar 05 00:06:58 2005SMON: enabling tx recoverySat Mar 05 00:06:58 2005Database Characterset is KO16KSC5601Updating 8.1.7.0.0 NLS parameters in sys.props$-- adding 9.2.0.1.0 NLS parameters.


Optimizer (Plan 변경) 에 의한 Performance 저하현상

• OLTP의특징

- 목표 :: 신속한 응답시간, 적은 데이타 처리량- 파싱 타임을 최소화하고, SQL 등이 공유될 수 있도록

바인드 변수를 사용해야 한다. - 인덱스의 사용률이 높아야 한다. - 정렬(sorting)을 최소화해야 한다. - Nested Loop Join (FIRST_ROWS_n) 방식으로 많이

유도한다.

• DW의특징

- 목표 :: 최고의 처리량, 방대한 데이타 처리량- 인덱스의 참조는 중요한 사항이 아니다. - 정렬 또는 Aggregate함수 등이 중요한 역할을 한다. - Hash Join 등을 많이 사용하도록 유도한다. - 파싱 타임 등은 그리 중요하지 않으며, 바인드 변수의

사용이 문제가 될 수 있다. - Parallel Query 등의 사용율을 높인다.

• 주요 Tuning Issues

- CBO 에서만 가능한 기능들- Optimizer_Index_Caching (default=0)- Optimizer_Index_Cost_Adj (default=100)- Workarea_Size_Policy (Auto | Manual)- MBRC- 통계정보 (DBMS_STATS)- 시스템통계- Index Clustering Factor- Wait Event 를 통한 진단 및 Tuning- Nested Loop Hash Join- V$SQL_PLAN- Bind 변수 Peeking - tkprof 의 Segment Level 통계정보

IIIIII--4. Trouble4. Trouble--shootingshooting


JDBC Connection 문제

Java Program (JSP, J2EE, EJB,… 등) 으로 개발된 3-Tier 환경인 경우 DB 를 8.1.7.X 9.2.0.X 등의 신규 Oracle Version 으로 Upgrade 한 후 JDBC Driver 과 DBMS 의 Version Compatible 이 일치하지 않아 JDBC 관련 Error 가발생할 수 있다.

alert.log

Wed Nov 30 09:57:48 2005Errors in file /oracle/app/oracle/admin/bms/udump/bms_ora_8663.trc:ORA-00600: 내부 오류 코드, 인수 : [ttcgcshnd-1], [0], [], [], [], [], [], []Wed Nov 30 09:58:09 2005Errors in file /oracle/app/oracle/admin/bms/udump/bms_ora_8880.trc:ORA-00600: 내부 오류 코드, 인수 : [ttcgcshnd-1], [0], [], [], [], [], [], []Wed Nov 30 09:58:11 2005

** 해결방법

1. DBMS Version 에 맞는 JDBC Driver 를 WAS 에 설치 / 사용하도록 한다.- 위 Trace 파일을 열어보면 JDBC Driver 문제가 되는 Client IP 정보가 보인다.

2. DBMS 내부 Character (예. 2byte) 체계와 JDBC 가 처리하는 Character 체계(예. 3byte)가 다르기 때문에 일부 한글등의 글자가 Column 에 정의한 수보다 적게 들어갈 수 가 있으므로, 반드시 JDBC Program 시에는 Manual 을 참고하여 JDBC Program 시 Strings ByteStream 방식으로 Java Source Code 을 하도록 한다.또는 일부 WAS Vendor 에 따라 자체 JDBC Driver 를 제공하기도 한다.

3. ORA-600 이 주로 발생하는 SQL 문장을 Tuning 을 통해 Error 발생 해소과 동시에 전반적인 업무 성능향상이 되는실무사례도 많다.



Oracle 10g R2부터 Group By절에 의한 Grouping Column순으로 Sorting되지 않는 문제 (LMT 인 경우 발생)

9.2.0.8 이전 Version에서는 Order by를 사용하지 않고 Group By만을 사용하여도 자동적으로 Sorting 이 됨.

Oracle 10g R2의 "New in-Memory Sort Algorithm"에 따른 문제점 및 개선점============================================================>>>> Oracle 10g R2 New Feature - New In-Memory Sort Algorithm 이란?--------------------------------------------------------------------------------------------------------1. 새로운 sort 적용 방식

- 기존에는 Sort 알고리즘으로 Sort하였으나 "Hash-based 방식"의 New Feature

2. 성능 개선 효과- 충분한 Memory일 경우 (즉 In-Memory Sort)일 경우 효과적- Sort operation이 기존 방식에 비해 최대 5~10%까지 빠를 수 있다.

3. SORT특징에 따른 개선 효과- 높은 cardinality (Row들의 Distinct가 많은 경우)일 경우 특히 효과적 (HASH방식 이므로)- Faster CPU일 경우 더욱 효과적- 적은 Column을 Select 했을 경우 특히 효과적 (Hash는 Memory부족에 의해 Disk로 내려가면 꽝)

=======================================>>>> New in-Memory Sort Algorithm 의 문제점?-------------------------------------------------------------------"GROUP BY"를 사용한 App가 "ORDER BY"를 기술하지 않더라도 Ordering된 결과를 Display하던 App들이 10g R2로 오면서이 기능이 깨지게 되었고, 반드시 Ordering이 필요하면 "GROUP BY"와 함께 "ORDER BY"를 기술해야 함.

==============================================================================>>>> New in-Memory Sort Algorithm 의 문제점인 "GROUP BY"를 기존 방식으로 사용하기 위해서는?----------------------------------------------------------------------------------------------------------------------------------------1. Optimizer Mode = RULE 일 경우는 발생 안함.2. OPTIMIZER_FEATURES_ENABLE = 10.1 로 함3. init.ora "_gby_hash_aggregation_enabled"=FALSE (New방식 사용 안함)

위의 방식 중 3번의 Hidden Parameter 를 주어도 Group by column 이 두개 이상 오는 경우에는 역시 자동적으로 정렬이 되지 않으므로반드시 ANSI-SQL Guide 를 따라 Order by 를 주어야 한다..

New in-Memory Sort Algorithm은 아주 유용한 방식이므로 App를 수정할 것을 고객들에 권장할 필요가 있음.



IV. RAC IV. RAC 로의로의 Migration Migration 및및 FailFail--Over Over 구현구현

1.1. SwingBenchSwingBench ……

2.2. RAC RAC 성능측정성능측정

3.3. RAC FailRAC Fail--Over Over 구현구현

4.4. RAC RAC 구성구성 GuideGuide

5.5. 기타기타


IVIV--1. 1. SwingBenchSwingBench ……Setup./oewizard


IVIV--1. 1. SwingBenchSwingBench ……Swingbench 실행


IVIV--1. 1. SwingBenchSwingBench ……charbench 부하 발생시


IVIV--1. 1. SwingBenchSwingBench ……ClusterOverview

./clusteroverview ./coordinator

./charbench –co suse –uc 25 –v cpu,disk,tpm,users,trans

./cpumonitor

./charbench –co suse –uc 25 –v cpu,disk,tpm,users,trans

./minibench –cs //rac1/MS949 –dt thin –co suse


IVIV--2. RAC 2. RAC 성능측정성능측정

CluserOverview - Thin



CluserOverview - OCI


IVIV--2. RAC 2. RAC 성능측정성능측정RAC DB – 부하 발생시



Single vs RAC 부하비교 - Single



Single vs RAC 부하비교 - RAC


기본환경 - 구성도

IVIV--3. RAC Fail3. RAC Fail--Over Over 구현구현


** 기본 환경

1. crs_stat -t

db1:/oracle/app/oracle> crs_stat -tName Type Target State Host ------------------------------------------------------------ora....A1.inst application ONLINE ONLINE db1 ora....A2.inst application ONLINE ONLINE db2 ora.EIDBA.db application ONLINE ONLINE db2 ora....B1.inst application ONLINE ONLINE db1 ora....B2.inst application ONLINE ONLINE db2 ora.EIDBB.db application ONLINE ONLINE db2 ora....B1.lsnr application ONLINE ONLINE db1 ora....B1.lsnr application ONLINE ONLINE db1 ora.db1.gsd application ONLINE ONLINE db1 !! ora.db1.ons application ONLINE ONLINE db1 !! ora.db1.vip application ONLINE ONLINE db1 !! ora....B2.lsnr application ONLINE ONLINE db2 ora....B2.lsnr application ONLINE ONLINE db2 ora.db2.gsd application ONLINE ONLINE db2 !! ora.db2.ons application ONLINE ONLINE db2 !! ora.db2.vip application ONLINE ONLINE db2 !!



** Network 구성

. Public IP서비스 IP 인 Public IP 는 MC/Service Guard 의 Network Redundant 기능을 이용하여Primary (lan6) Standby (lan7) 의 HA Configuration 이 되어 있다.즉 lan6 번 NIC 가 down 되면 MC/SG 가 자동으로 lan7 번 NIC 로 IP Fail-Over 가 된다.Oracle CRS 에서도 lan6 :1 의 VIP 가 lan7 :1 로 자동 F/O 가 되기 위해서는 아래의 순서로VIP 를 이중화 해주어야 한다.

## VIP 이중화

srvctl stop database -d RACsrvctl stop nodeapps -n rac1srvctl stop nodeapps -n rac2

## root 유저에서 각 Node 별로 실행한다.srvctl modify nodeapps -n rac1 -o /usr1/home/oraclei/product/10.2.0 ₩

-A rac1-vip/255.255.255.192/lan6₩|lan7srvctl modify nodeapps -n rac2 -o /usr1/home/oraclei/product/10.2.0 ₩

-A rac2-vip/255.255.255.192/lan6₩|lan7srvctl start nodeapps -n rac1srvctl start nodeapps -n rac2srvctl start database -d RAC



** Network 구성

. Private IP Oracle 이 사용할 Inter-Connect IP 는 HP 의 APA (Auto Port Aggregation) 기능을 이용하여lan2 & lan3 번 NIC 가 Trunking 라 불리우며, OS 의 Network 상에는 lan900 이라는 이름으로이중화 (묶여있어)가 되어 있어 2 Channel 을 사용하며, F/O 나 Load Balance 기능이 아니라2 Channel 을 Full Duplex 로 사용할 뿐이다.

. HeartBeatOS 의 ClusterWare 인 MC/Service Guard 가 사용할 HeartBeat 용 Network 은 lan5 & lan1 로2 Channel 을 Full Duplex 로 Packet 전송을 한다. – Ethernet NIC

rac2 [oraclei:/usr1/home/oraclei/goodus]$ netstat –in

IPv4:Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Colllan1 1500 192.168.20.0 192.168.20.8 981 0 1886 0 0 lo0 4136 127.0.0.0 127.0.0.1 43193 0 43193 0 0 lan6:1 1500 211.233.2.192 211.233.2.230 4751 0 100 0 0 lan7* 1500 none none 0 0 0 0 0 lan6 1500 211.233.2.192 211.233.2.228 52314 0 98443 0 0 lan5 1500 192.168.30.0 192.168.30.8 977 0 1882 0 0 lan900 1500 192.168.10.0 192.168.10.8 37568 0 20863 0 0



** Oracle Background Process & Listener Process kill

1. kill –9 <Core B/G - ora_pmon PID>- Oracle 모든 Process 자동 재 시작- TAF 의 Select Session 은 다른 Node 로 자동 Fail-Over 되어 정상적으로 Query 됨 !!- local_listener 설정이 되어 있어야 빠르게 Session Fail-Over 가 됨 !!- WAS 에서는 자동 Re-Connect 되며, Query 는 계속해서 진행됨 !!- VIP 변화 없음!!

2. kill –2 <Non Core Background – cjq0 PID>- 해당 Process 만 자동으로 재 기동이 됨.- Node Fail-Over 없이 자동 재접속됨. - CTF 또는 TAF 의 BASIC 설정시 자동으로 Re-Connect !!

3. kill –9 <Oracle Server Process PID>- Node Fail-Over 없이 자동 재접속됨.- CTF 또는 TAF 의 BASIC 설정시 자동으로 Re-Connect !!- TAF 의 Pre-Connect 설정시 Backup Session 까지 2개의 Session 이 맺어진다. !!

4. alter session kill ‘SID, SERIAL#’- 해당 Session 은 종료 되며, Fail-Over 없음.!!

5. kill -9 <Listener_Pid>- Listener 는 자동 재시작 됨.!!- TAF 의 Select Session 은 다른 Node 로 자동 Fail-Over 되어 정상적으로 Query 됨 !!- local_listener 의 Dynamic Listener 이므로 신규 Client 접속은 다른 Node 로 이루어 짐.- WAS & DB 사이에 L4 or L2 가 있는 경우에는 해당 Instance 가 down 되는 순간에는

Page 표시가 되지 않을 수 있다. 이는 L4 는 Oracle Process down 여부를 Check 하지 못하고

특정 Port (1521) 에 대해서는 Monitoring 및 Balancing 이 되기 때문임.



** Instance Fail-Over Test

1. srvctl stop instance –d EIDBA –I EIDBA1

- Oracle 자동 재 시작되지 않음 !! (CRS 는 정상종료에 대해서는 Re-Start 하지 않음)- TAF 의 Select Session 은 다른 Node 로 자동 Fail-Over 되어 정상적으로 Query 됨 !!- local_listener 의 Dynamic Listener 이므로 신규 Client 접속은 다른 Node 로 이루어 짐.- WAS & DB 사이에 L4 or L2 가 있는 경우에는 해당 Instance 가 down 되는 순간에는

Page 표시가 되지 않을 수 있다. 이는 L4 는 Oracle Process down 여부를 Check 하지 못하고특정 Port (1521) 에 대해서는 Monitoring 및 Balancing 이 되기 때문임.

2. System Rebooting 시 (동시)

- RAC 양쪽 Node 를 On-Line 중에 강제로 Down or Rebooting 을 하는 경우…OS Cluster S/W (MC/Service Guard, HACMP, HACMP, Sun Cluster, VCS, True-Cluster 등)가 Start 가 되면 /etc/inittab 의 respawn 명령에 따라 CRS 와 DB 는 자동으로 모든 Resource들이 Start 가 되어진다.

- VIP 는 두 Node 중 CRSD 가 먼저 Start 되는 쪽에서 양쪽의 VIP 를 띄워서 서비스가 되고,두번째 Node 가 정상적으로 Booting 이 되고, CRS 의 서비스가 Start 가 되면 자동으로 원래의Node 로 Fail-Back 이 된다.



** DB Server 강제 Shutdown 시 $ORA_CRS_HOME/css/log/ocssd2.log

2005-09-22 02:08:52.076 [4] >WARNING: clssnmeventhndlr: Receive failure with node 1, rc=112005-09-22 02:08:52.441 [3] >TRACE: clssnm_skgxncheck: CSS daemon failed on node 12005-09-22 02:08:55.330 [8] >WARNING: clssnmPollingThread: node(1) missed(4) checkin(s)2005-09-22 02:08:56.340 [8] >WARNING: clssnmPollingThread: node(1) missed(5) checkin(s)2005-09-22 02:08:57.350 [8] >WARNING: clssnmPollingThread: Eviction started for node 1, flags 0x0001, state 3, wt4c 02005-09-22 02:09:02.402 [8] >TRACE: clssnmDoSyncUpdate: Initiating sync 152005-09-22 02:09:02.402 [4] >TRACE: clssnmHandleSync: Acknowledging sync: src[2] seq[1] sync[15]2005-09-22 02:09:02.871 [1] >USER: NMEVENT_SUSPEND [00][00][00][04]2005-09-22 02:09:06.441 [8] >TRACE: clssnmEvict: Evicting node 1, birth 10, death 0, killme 12005-09-22 02:09:06.443 [4] >USER: clssnmHandleUpdate: SYNC(15) from node(2) completed2005-09-22 02:09:06.443 [4] >USER: clssnmHandleUpdate: NODE(2) IS ACTIVE MEMBER OF CLUSTER2005-09-22 02:09:06.911 [13] >USER: NMEVENT_RECONFIG [00][00][00][04]2005-09-22 02:09:06.911 [13] >TRACE: clssgmCleanupGrocks: cleaning up grock DBDSLOT type 22005-09-22 02:09:06.912 [13] >TRACE: clssgmCleanupGrocks: cleaning up grock DGDSLOT type 22005-09-22 02:09:06.912 [13] >TRACE: clssgmCleanupGrocks: cleaning up grock DAALL_DB type 22005-09-22 02:09:06.912 [13] >TRACE: clssgmCleanupGrocks: cleaning up grock ocr_crs type 22005-09-22 02:09:06.912 [13] >TRACE: clssgmCleanupGrocks: cleaning up grock IGDSLOTALL type 22005-09-22 02:09:06.912 [13] >TRACE: clssgmCleanupGrocks: cleaning up grock RES ora.dslot.dslot.dslot2.srv type 32005-09-22 02:09:06.912 [13] >TRACE: clssgmEstablishConnections: 1 nodes in cluster incarn 152005-09-22 02:09:06.912 [7] >TRACE: clssgmPeerListener: connects done (1/1)CLSS-3000: reconfiguration successful, incarnation 15 with 1 nodesCLSS-3001: local node number 2, master node number 22005-09-22 02:09:06.985 [13] >TRACE: clssnmpostev: leave event posted, node 1

** 살아있는 2호기에서 1호기의 장애를 감지하고 1호기 노드를 eviction했음을 알 수 있음.


** DB Server 강제 Shutdown 시 $ORA_CRS_HOME/crs/log/kblotdb2.log

2005-09-22 02:09:07.001: Processing MemberLeave2005-09-22 02:09:07.001: [MEMBERLEAVE:717] Processing member leave for kblotdb1, incarnation: 152005-09-22 02:09:07.217: [RESOURCE:717] Not failing resource ora.dslot.dslot.dslot2.srv because it was locked.2005-09-22 02:09:07.218: [RESOURCE:717] X_RES_Unavailable : Resource ora.dslot.dslot.dslot2.srv is locked(File: rti.cpp, line: 812)2005-09-22 02:09:07.351: Attempting to start òra.kblotdb1.vip` on member `kblotdb2`2005-09-22 02:09:35.059: Start of òra.kblotdb1.vip` on member `kblotdb2` succeeded.2005-09-22 02:09:35.194: Attempting to start òra.dslot.dslot.cs` on member `kblotdb2`2005-09-22 02:09:35.755: Start of òra.dslot.dslot.cs` on member `kblotdb2` succeeded.2005-09-22 02:09:35.865: Attempting to start òra.dslot.db` on member `kblotdb2`2005-09-22 02:09:36.319: Start of òra.dslot.db` on member `kblotdb2` succeeded.2005-09-22 02:09:36.323: [MEMBERLEAVE:717] Do failover for: kblotdb12005-09-22 02:09:36.324: [MEMBERLEAVE:717] Post recovery done evmd event for: kblotdb1

** 다음으로 CRS가 1호기에 있던 oracle VIP를 살아있는 2호기로 failover시켰음을 알 수 있음.


** Public Network Fail-Ovet Test

1. lan6 번 1 Line 절체

- Physical IP 는 lan7 로 Fail-Over !!- VIP 도 lan7:1 로 Fail-Over !!- DB Session 의 DB 접속 정상, Select Query 는 계속 실행 됨. !!- telnet session 끊어지지 않음 !!- lan6 복구(연결)시 Physical IP , VIP 는 자동복구 됨.!!

2. lan6 & lan7 번 동시 Down (line 절체)

- telnet 및 기존 DB Session 은 끊어짐 !!- VIP 는 다른 Node 로 Fail-Over !!- 신규 Session 은 다른 Node 로 접속 됨. !!- OS Clusterware Heartbeat 이 별도이므로 System Not-Rebooting…

** VIP 가 정상적으로 Start 되지 않으면 DB Instance 역시 Start 되지 않는다.!!VIP와 dependency를 이루고 있는 resource들이 (listener), asm, isntance 등이 있고,이들은 vip가 정상적으로 구동이 되지 못한다면 시작이 되지 않게 된다..resource에 대한 dependency를 확인하기 위해서는 아래의 명령을 사용한다.

e.g) crs_stat -p ora.rac2.LISTENER_RAC2.lsnr | grep REQREQUIRED_RESOURCES=ora.rac2.vip



** Inter-Connect (Heart-Beat) Fail-Over Test

1. lan2 or lan3 번 1 Line 절체

- 서비스 이상 없이 정상작동 됨.!!

2. lan2 & lan3 번 2 Line 동시 절체

- 인터페이스 down 은 syslog 에 확인 됨. !!- Cluster 상에서 Health Check Fail 발생하지 않음.- Inter-Connect 2 line 이 절체가 되어도 별도의 Heart-Beat Line 을 이용하여서비스 이상 없이 정상작동 됨. !!

3. lan2 & lan3 번 2 Line 동시 절체 와 Heart-Beat Line 절체

- 모든 Session 의 작업은 Hang 상태 임 !!- MissCount 값 (예 : 600초 – 10분) 내에 Line 을 연결하면 서비스 정상 !!- MissCount 값을 초과하면 Manual 상에서는 Master Node 가 아닌쪽이 Evict 가 되어

System Rebooting 이 됨.!!- 실제는 두 Node 중에 불규칙적으로 Rebooting 현상이 발생함.!!



** IBM HACMP & 9i RAC Inter-Connect Fail-Over Test

- Cluster_interconnect를 명시적으로 지정할 경우, 1개의 interconnect만 Active 하며,interconnect의 통신 장애가 발생하면, Instance Down 또는 Hang이 발생한다.

- Cluster_interconnect를 지정하지 않을 경우, 2개의 interconnecr가 Active 하며,(Network 0 = 10.20.20.1, Network 1 = 23.34.81.134)Network 0(10.20.20.1)이 down 될 경우, Network 1(23.34.81.134)으로 fail-over 되며, Network 0(10.20.20.1)이 up 되어도 다시 Network 0으로 fail-over 되지는 않음.

- Cluster_interconnect를 지정하지 않은 상태에서,Network 0(10.20.20.1)이 up 된 후, Instance를 다시 Re-Startup 하여도, Network 0 이 여전히 down 된 것으로 인식하여, Network 1 이 Active 됨.

- Cluster_interconnect(10.20.20.1)를 명시적으로 지정할 경우, 다시 1개의 interconnect(10.20.20.1)만을 정상적으로 Active 시킴.

** Cluster_interconnects (Private Network) 이 down 되어서 재 구동을 하더라도 Oracle RAC 가cluster_interconnect 를 제대로 사용하지 못하므로, 반드시 O/S ClusterWare 를 Re-Start 해야 한다.



** Dead-Lock Test

- 10g RAC 부터는 정확한 Row-Level Locking 을 지원하여 동일Block 의 서로 다른 Row 를동시에 Update 를 하더라도 ORA-60 의 Dead-Lock 이 발생하지 않는다.!!

SCOTT> create table lock_t (no number);SCOTT> insert into lock_t values (1);SCOTT> insert into lock_t values (2);

#Node-1SCOTT> update lock_t set no=3 where no=1;

#Node-2SCOTT> update lock_t set no=4 where no=2;



** TAF – BASIC

$TNS_ADMIN/tnsnames.ora

AP =(DESCRIPTION = (FAILOVER=ON) (LOAD_BALANCE=ON)

(ADDRESS_LIST =(ADDRESS = (PROTOCOL = TCP)(HOST = vip-sc1)(PORT = 1521))(ADDRESS = (PROTOCOL = TCP)(HOST = vip-sc2)(PORT = 1521))

)(CONNECT_DATA =(SERVICE_NAME = AP)(FAILOVER_MODE =(TYPE=SESSION)(METHOD=BASIC)

))

$ sqlplus ID/PWD@APSQL> select instance_name from v$instance;

RAC2SQL> select failover_type, failover_method, failed_over

From v$sessionWhere username=’ID’;

FAILOVER_TYPE FAILOVER_METHOD FAILED_OVERSESSION BASIC NO


** TAF – BASIC

SQL> insert into fan values (1);SQL> commit;

** Oracle Process 강제 Kill !!

$ ps –ef |grep “RAC1 (LOCAL=NO)” | awk ‘{print “kill -9 “ $2 }’ | sh –v

SQL> insert into fan values (1);

ORA-3113 : end-of-file on communication channel

** Insert 다시 시도 !!

SQL> insert into fan values (1);2번째 Node 에서 Verify Automatically Failed-Over !!

SQL> select instance_name from v$instance;RAC2

SQL> select failover_type, failover_method, failed_overFrom v$sessionWhere username=’ID’;

FAILOVER_TYPE FAILOVER_METHOD FAILED_OVERSESSION BASIC YES


** TAF – PRECONNECT

$TNS_ADMIN/tnsnames.ora

ERP =(DESCRIPTION = (FAILOVER=ON) (LOAD_BALANCE=ON)


)(CONNECT_DATA =(SERVICE_NAME = ERP)(FAILOVER_MODE =(BACKUP=ERP_PRECONNECT)(TYPE=SESSION)(METHOD=PRECONNECT)

))

ERP_PRECONNECT =(DESCRIPTION = (FAILOVER=ON) (LOAD_BALANCE=ON)


)(CONNECT_DATA =(SERVICE_NAME = ERP_PRECONNECT)

))



$ sqlplus ID/PWD@APSQL> select instance_name from v$instance;

RAC2SQL> select failover_type, failover_method, failed_over

From v$sessionWhere username=’ID’;

FAILOVER_TYPE FAILOVER_METHOD FAILED_OVER SERVICE_NAMESESSION PRECONNECT NO ERP

** Sample Data Insert !!

SQL> insert into fan values (1);SQL> commit;

** Oracle Process 강제 Kill !!

$ ps –ef |grep “RAC1 (LOCAL=NO)” | awk ‘{print “kill -9 “ $2 }’ | sh –v

SQL> insert into fan values (1);

ORA-3113 : end-of-file on communication channel


** Insert 다시 시도 !!

SQL> insert into fan values (1);2번째 Node 에서 Verify Automatically Failed-Over !!

SQL> select instance_name from v$instance;RAC2

SQL> select failover_type, failover_method, failed_overFrom v$sessionWhere username=’ID’;

FAILOVER_TYPE FAILOVER_METHOD FAILED_OVERSESSION BASIC YES

** TAF 사용시에 listener.ora 에서 GLOBAL_DBNAME 이름은 삭제 할 것!!


IVIV--4. RAC 4. RAC 구성구성 Guide Guide –– RAC Tuning GuideRAC Tuning Guide

1. 업무 Partitioning (-- Avoid Hot Block, Buffer Busy Waits)

2. SQL Tuning

3. Sequence Caching / Use Parallel_Instance_Group (-- Instance_groups=‘Sales’)

4. Partition Large Objects

5. Use Different Block Sizes (-- DW, CRM :: DB_32K_CACHE_SIZE)

6. Tune Instance Recovery ( 60 < FAST_START_MTTR_TARGET <300)in 10.2.0.3 _FAST_START_INSTANCE_RECOVERY_TARGET

7. Avoid DDL

8. Use LMT’s and ASSM (-- DW, DSS :: Use Large Uniform Size)


H/W 구성

P620 6F1(부하 발생 서버)

회원조합 개발용

Fast Ethernet (100Mbps)

HitachiSANRise 2800

대외계개발서버

중앙회 개발용p690 1대

(16CPU, 16GB Mem)

HACMP

HACMP

Fast Ethernet(10/100Mbps)

P620 6F1

DB #2

Fibre channel

HACMP

DB #1

AP #1

AP #4

AP #2

AP #3 DB서버(개발서버)

Web서버(개발서버)

RLA서버

자동화기기

BP#1

성능감시

RLA

관리업무주1) 프로토타이핑 환경

AP 테스트

DB성능감시

Fast Ethernet(100Mbps)

BP#2

통신테스트

관리테스트

자동화기기 신 시스템 Pilot 하드웨어 구성

P620 6F1(부하 발생 서버)

회원조합 개발용

Fast Ethernet (100Mbps)

HitachiSANRise 2800

대외계개발서버

중앙회 개발용p690 1대

(16CPU, 16GB Mem)

HACMP

HACMP

Fast Ethernet(10/100Mbps)

P620 6F1

DB #2

Fibre channel

HACMP

DB #1

AP #1

AP #4

AP #2

AP #3 DB서버(개발서버)

Web서버(개발서버)

RLA서버

자동화기기

BP#1

성능감시

RLA

관리업무주1) 프로토타이핑 환경

AP 테스트

DB성능감시

Fast Ethernet(100Mbps)

BP#2

통신테스트

관리테스트

자동화기기 신 시스템 Pilot 하드웨어 구성

IVIV--4. RAC 4. RAC 구성구성 Guide Guide –– 업무업무 PartitionPartitionRAC H/W 구성도


요망수준평가

분야평가항목 평가요소

최소 적정

RAC Locking

Average Global Cache Get TimeAverage Global Cache Convert Time

20 ~ 30 ms10 ~ 20 ms DBMS 안정성

DBMS 안정성 ( RAC 아키텍쳐 성능 ) 평가 항목 기준 결정 배경

RAC Locking

Oracle에서 권고하는 Oracle 9i에서 발생할 수 있는 Average Global Cache Get Time, Average Global Cache Convert Time의 적정치

IVIV--4. RAC 4. RAC 구성구성 Guide Guide –– 업무업무 PartitionPartitionRAC 성능 – DBMS 안정성


테스트 조건

측정항목

RAC ( 업무 분배 없음) RAC (업무분배 있고, DB Tuning 전 )

Avg global cache get time(ms)Avg global cache convert time(ms)

73.4

91.0

1.3

5.0

0.7

3.2

DB#1:53.4%. DB#2:40.0%

Log file sync,Log file parallel write,Enqueue,Latch free,CPU TIME

DB#1:80.2%, DB#2:66.4%

Global cache cr request,Log file sync,Enqueue,Buffer busy global cache,Buffer busy global CR

Top 5 Timed Events Log file sync,Enqueue,CPU TIMELatch free,Library cache pin

RAC (업무분배 있고, DB Tuning 후 )

CPU DB#1:51.0%. DB#2:33.4%

- 테스트 결과 업무 분배가 없는 RAC 환경에서는 global cache의 lock contention으로 인해 성능저하가

있었고, Application에서 업무 분배를 통해 성능이 향상 되었다.

- disk_async_io 의 값을 default인 true로 줌으로써 disk I/O wait로 인한 성능 저하를 없앴고, Oracle

통계정보를 생성하여 CBO로 index를 사용하게 하여 sql의 execution elapsed time을 줄이므로써

성능을 향상시켰다.

- 결론적으로, RAC환경에서 두 instance간의 global cache에 의한 lock contention을 줄이기 위해

Application에서의 업무 분배는 필수적이라고 볼 수 있다.

DBMS안정성( RAC 아키텍쳐 성능 ) 관련하여 주요 테스트 결과를 요약해 보면 아래와 같다.

IVIV--4. RAC 4. RAC 구성구성 Guide Guide –– 업무업무 PartitionPartitionRAC 성능 – DBMS 안정성


대용량 데이터 관리 및 처리를 위해서 파티션은 필수조건이다.

기존 분산환경에서는 데이터 양적인 측면이나 관리측면에서 월별 파티션이 유리하였는지 모른다.하지만, 앞으로의 통합환경에서는 통합된 대용량 데이터의 처리 성능을 고려한 데이터 저장방식의 과감한결정이 필요할 것이다.이러한 측면에서 데이터 통합시 가장 중점으로 생각해야 할 Factor중의 하나가 바로 대용량 데이터 파티션을생성기준(일자/월별)로 할것이냐, 발생자(고객번호)로 할것이냐의 정책의 결정이 필요하다.

본 장표에서는 기존 월별 파티션을 고객번호 파티션으로 변경적용하였을때 성능측면에서 기존 월별 파티션과비교하고, 적용한 사례를 기반으로 소개함으로써 정책 결정에 대한 힌트를 제공하고자 한다.

본 장표는 현재 진행되고 있는 XX보험 프로젝트를 기반으로 작성되었으며, 데이터 처리시 구조적인 단면을예를 들어 설명하였으며, 특히 RAC환경에서 대량 배치작업 시 경합 및 IO측면에서 우수한 점을 설명하고자하였다.

XX보험시스템에서 고객번호는 증번호이다. 이하 고객번호는 증번호라고 한다.

** 시스템 환경

• DBMS : Oracle Release 9.2.0.7

• O/S : HP-UX 11.11

1.개요

IVIV--4. RAC 4. RAC 구성구성 Guide Guide -- PartitionPartition


2. ROWID 분포도 상의 IO 비교

한 사람의 증번호로 이사람의 보험료 고지내역(청구내역)을 조회하고자 한다고 할때 과연 월별 파티션에서는몇 개의 BLOCK을 IO 해야 할까?증별 파티션으로 되어있을 경우에는 어떤 변화가 일어날까?

아래 간단한 질의 하나로 데이터의 처리 BLOCK수를 COUNT해보았다.

오라클의 ROWID 데이터는 18자리로 앞에서부터 object 6자리, datafile 3자리,block 6자리그리고, 마지막 row 3자리 format 으로 되어있다. 이를 이용하여 같은 특정 증번호(고객번호) 데이터가 몇 개의 BLOCK에 분포되어있는지 살펴보았다.

SQL (block건수조회) 증번호 파티션( TO-BE) 월별 파티션 (AS-IS)

SELECT

substr(rowid,1,15), count(*)

FROM TBBHBA01

WHERE

JUNG_NO = '10010173221'

GROUP BY substr(rowid,1,15);

object_block row건수

----------------------

AAADW1AEGAAAFcw 38

AAADW1AEGAAAFcx 43

AAADW1AEGAAAFcy 31

---------------------

3건 (3 block에 존재)

object_block row건수

----------------------

AAAD+2AEnAAAEZO 1

AAAD+CAEvAAAAR0 1

AAAD+GAEpAAAB/o 1

......중략

AAAMlCAEtAAADSO 1

AAAMlVAEnAAAEP3 1

---------------------

96건 (96 block에 존재)



3. 프로그램 처리 BLOCK으로 본 증번호 파티션의 효과

온라인 단건 검색 온라인 배치

(대장/명부작성)

정기배치

(전국민보험료고지작업)

특정 증번호 단순 검색시 동일BLOCK내에 데이터 존재할 가능성이 높다.

날짜나 특정 지사 소속의 모든 증번호 처리시 ASYNC IO 효과를 볼수 있어 IO 최소화

•처리 BLOCK수 =

cursor fetch건수

(특정 지사 10만건)

* 건별 처리시 7 block

-----------------

최대 70만 block

날짜나 특정지사소속 증번호 처리시 RANDOM IO를 할 수 밖에 없어IO 효율이 떨어져 IO가 많다.


cursor fetch건수

(특정 지사 10만건)

* 건별 처리시 100 block

-----------------

최대 1000만 block

증번호 파티션

전국민 데이터를 증구간별로 병렬 처리시 앞의 온라인 배치 처리 효과 + 입력시 HOT BLOCK경합이 거의 없다.


인덱스 3 blokc

+ 테이블 3 block

+ overhead 1 block

--------------

total 7 block

특정 증번호 검색이라도 월별 파티션에 나누어져 있으므로 여러파티션을 읽어야 하므로 IO가 많다.

전국민 데이터의 병렬 처리시 매번 마지막 월별 파티션의 마지막 일자에 데이터가 몰리는 HOT BLOCK 및 IO경합이 발생함


인덱스 3 blokc

+ 테이블 96 block

+ overhead 1 block

----------------

total 100 block

월별 파티션



4. RAC 글로벌 Contention 측면에서의 효과 (대량 병렬 배치 처리시)

증번호 파티션 월별 파티션

RAC에서 node간의 lock단위는 row 단위에서 block단위로 lock escalation이 발생한다.

증구간 별 병렬 처리시 각 프로세스마다 sort된 증번호를 각각 순차적으로 처리하므로 동일 block을 동시에read/write 혹은 write/write하는 경합이 거의 발생하지않는다.

정기 보험료 고지작업 수행시간 : 40분

현행 시스템의 RAC구조가 아니지만,

월별 파티션으로 그대로 갈 경우 현처리 프로세스대로지사별로 병렬 처리하여 거의 100% RANDOM IO를 발생시키고, 같은 block의 global CR request 가 빈번하고, 동일 block의 read/write, write/write 경합이 빈번할것으로 예상된다.

현행 정기 보험로 고지작업 수행시간 : 70 시간

node1 node2 node3 node4 node1 node2 node3 node4

Hot Block

Global lock경합



1. Oracle RAC Architecture의 부하

Oracle RAC Architecture는 공유 Disk에 있는 데이터를 여러 서버(Node)가 서로 동시에 Access할 수 있는 구조이

다. 따라서, 단일 Resource에 대한 경합이 발생하며 이러한 경합때문에 Application의 성능저하가 발생한다. 이는

Oracle의 Cache Fusion이 Block 단위의 데이터를 Interconnector(Ethernet)을 통해 이동 시키기 때문이다.

자격/보험료 통합AP서버

직장서버 지역서버1자격서버 지역서버2

자격/직장Take-Over Take-Over

RAC 구성 서버

Partition

동일한업무가동일한데이터에대해서로다른서버에서 Update요청을했을때 Row 단위가아닌

Block단위의경합이발생함

실제경합범위(Block단위)

Data Block들이Cache Fusion 하여

Ethernet을통해이동하기때문에

Network 지연발생

4개 DB Node가데이터의정합성을 맞추기위한통신부하Network을통한 Block전달을기다리는부하서로다른서버가동일 Row에대한 Update를처리하기위해Block 단위의 Locking 처리필요단순한 Read의경우에도특정서버에 Block혹은 Data File에대한 Ownership이없을경우Cache Fusion을통해 Block을읽어오기위해타서버와통신후다른서버의 Buffer에있는지Check해야하기때문에지연발생

IVIV--4. RAC 4. RAC 구성구성 Guide Guide –– Data PartitionData Partition


2. 업무 Partitioning

이러한 RAC간의 경합을 최소화 하기 위해 될 수 있는 한, 단일 서버가 접근하는 데이터의 범위를 독립시키는 것이

좋다. 가장 명확한 데이터 범위의 분리는 서버에 할당되는 업무를 분리함으로써 가능하며, 이를 업무

Partitioning이라고 한다.



Take-Over Take-Over

RAC 구성 서버

Partition

자격업무(TBJG)는자격서버에서가장빈번히일어남직장서버는직장보험료업무(TBBM)가가장빈번히일어남지역서버는지역보험료업무(TBBH)가가장빈번히일어남서버별로업무를분리하여주처리서버를둠으로써서버가접근하는데이터의범위가한정됨따라서, Node간 Block 이동이현저히줄어들게되고, Update로인한 Node간경합도현저히줄어들수있음. 단, 지역업무의경우지역1서버및지역2 서버가동일한업무를동일한데이터범위에대해수행케되어경합및성능저하우려가있음.직장보험료및지역보험료에서자격을참조하는업무가많으나대부분조회하는것들이므로 Update로인한서버경합이발생할우려가적음.

자격(TBJG)

직장(TBBM)

지역(TBBH)

직장보험료및지역보험료의 READ 참조

지역보험료업무간경합발생



지역(TBBH)

3. 데이터 Partitioning (온라인)

온라인 Transaction의 경우 지역 DB의 경우 동일한 데이터에 대해 두 대의 서버가 동일한 업무로 동시에 접근하게

되어 RAC Node간 Lock 경합등의 우려가 있다. 이런 경합을 줄이기 위해 지역 DB 1,2에 접근하는 Transaction의

성격을 분리하여, Node간 경합을 최소화 하도록 설계한다.



Take-Over Take-Over

RAC 구성

서버

Partition

단일테이블을 Partition Table로설계단일서버가접근하는 Partition을업무적으로분리지역 DB 1,2에대한온라인상의접근을 Read와 Update성을구별하여수행지역 DB1에서만 Update 성Transaction 수행Read 성 Transaction은부하정도에따라 DB1과 DB2에나누어수행

자격(TBJG)

직장(TBBM)

지역(TBBH)

증번을기준으로 Data

Partition

지역고지테이블지역고지테이블PART 1 PART 2 PART 3 PART 4

(증00001~ 09999)

(증10000~ 19999)

(증20000~ 29999)

(증30000~ 39999)

Read Only

Update, Read

Read Transaction만이지역서버 2 DB에접근가능

Read 및 Update Transaction 접근 Node간 Lock에

의한지연최소화

단일 Table에대한 IO분산



지역(TBBH)

3. 데이터 Partitioning (배치)

배치의 경우, 지역데이터를 Partitioning기법을 도입 단일 서버가 접근하는 데이터의 범위를 제한해야 하며, 이

를 통해 업무 Partition을 하여 Node간 Cache Fusion에 따른 부하 경감 및 I/O분산효과를 얻을 수 있다.



Take-Over Take-Over

RAC 구성

서버

Partition

단일테이블을 Partition Table로설계단일서버가접근하는 Partition을업무적으로분리증 00000 ~ 19999구간은지역서버1을통해접근증 20000 ~ 99999까지는지역서버2를통해접근Node간증구간분리점(예에서

20000)은배치프로그램선작업( 전체건을읽어서지역DB1에서수행되어야할구간과지역DB2에서수행되어야할구간은구분)을통해결정됨.접근하는데이터영역이나뉘어져있기때문에 Node간 Cache Fusion에대한부하경감효과2개의서버를통해단일테이블을분리하여접근하기때문에 테이블에대한 I/O 분산효과

자격(TBJG)

직장(TBBM)

지역(TBBH)

증번을기준으로 Data

Partition

지역고지테이블지역고지테이블PART 1 PART 2 PART 3 PART 4

(증00000~ 09999)

(증10000~ 19999)

(증20000~ 29999)

(증30000~ 99999)

(증20000~99999)(증 0000~19999)

증 20000~99999 구간은지역서버

2로접근하여업무처리

증 00000 ~ 19999구간은지역서버 1로

접근하여업무처리Node간 Cache

Fusion 부하경감

단일 Table에대한 IO분산



V. V. 기타내용기타내용 및및 QnAQnA

1.1. 기타내용기타내용

2.2. QnAQnA


VV--1. 1. 기타내용기타내용 –– Parallel RecoveryParallel RecoveryRollback Monitoring

Transaction Rollback 시 시간측정하기 위해서는…

- 9i :: select used_urec from v$TRANSACTION;- 10g :: select time_remaining from v$session_ops where sid =‘ ‘;

SQL> set serveroutput on size 999999SQL> exec print_table(’select * from v$session_longops where sid = 9′)

SID : 9 SERIAL# : 68OPNAME : Transaction RollbackTARGET : TARGET_DESC : xid:0×000e.01c.00000067SOFAR : 10234 TOTALWORK : 20554UNITS : Blocks START_TIME : 07-dec-2003 21:20:07LAST_UPDATE_TIME : 07-dec-2003 21:21:24TIME_REMAINING : 77 ELAPSED_SECONDS : 77CONTEXT : 0MESSAGE : Transaction Rollback: xid:0×000e.01c.00000067 :10234 out of 20554 Blocks done USERNAME : SYSSQL_ADDRESS : 00000003B719ED08SQL_HASH_VALUE : 1430203031 SQL_ID : 306w9c5amyanrQCSID : 0

남은 시간 :: 지금까지 소요 시간이 77초이니까 77 * ( 10234 / (20554-10234) ) ≈ 77 seconds.Tx Down 시 최종적으로 실행중이던 트랜잭션은 다음 인스턴스 재시작시 자동으로 롤백, 그 때 오라클에서는 Parallel 로 죽어버렸던 Session 들을병렬적으로 복구할 수 있음.관련되는 View :: V$FAST_START_TRANSACTIONS (복구 트랜잭션들), V$FAST_START_SERVERS (병렬 서버)

복구에 참여하는 서버의 숫자 보기 ::select rcvservers from v$fast_start_transactions;

만약 결과가 1 이면 Serially 복구 중, RECOVERY_PARALLELISM (복구시 사용되는 서버 프로세스의 수) 를 0 이나 1 을 제외한 값으로 설정하고, ALTER SYSTEM SET FAST_START_PARALLEL_ROLLBACK = HIGH 를 하면 CPU개수의 4배로 병렬 서버를 만들어 최대한 빨리 복구를 하게 됨(보통 2배로 해서 병렬 작업 하며 CPU 1개당 병렬 프로세스 2개씩 하는게 일반적임)


주관사단계 업무 고객사

DBA 개발자

기존 대상 시스템 업무 및 주요업무

실행계획 파악● ● ● △

Case 별 Data Migration 시간 및 방법 산정 ● ● N/A △

성능 및 이슈 파악 / 해결 ● ● ● △

DB Stress 및 성능 테스트 ● ● ● N/A

ORACLE 비고

● N/A

● N/A

N/A

N/A

N/A

N/A

N/A

●

N/A

N/A

●

○

●

N/A

N/A

●

●

●

●

●

●

●

●

●

●

●

●

●

○DB Software Version 및 Patch Level 파악 △

N/A

테스트는 고객사, 수정은 주관사

Oracle New Feature 적용여부 결정 ● △ 테스트는 고객사, 수정은 주관사

새로운 개발 환경 구축 ○ △

시스템 Cut-Off ● △

단위 / 연계 / 통합 테스트 및 오류 사항 수정 ● △ 테스트는 고객사, 수정은 주관사

N/A

△

N/A

△

△

N/A

△

N/A

N/A

Data 검증방안 파악 및 Capacity Planning

이행 Case 선정 및 이행 시나리오 작성

DB Software Install & Patch Apply ○

최고성능을 위한 DB 환경 구성 및 Setup ○

이행 테스트

단계

Case 별 상세 Data Migration Plan 작성 ●

DB Software Install & Patch Apply ○

Data Migration ○

이행 단계 Data 검증 ●

운영 시스템 모니터링 및 튜닝

이행 전/후 성능비교

●

●

●

이행 준비

단계

○

안정화 단계

※ DBA Role & Responsibility

이행에 관련된 시스템 작업은 제안사가 주로 수행을 하며, 기존 시스템에 대한 파악에 대한 지원과 테스트의 경우는 POSCO가 주도적으로

수행을 하게 됩니다. 또한 이슈 발생 시 POSCO와 제안사 그리고 Oracle이 합심해서 이슈를 해결해야 하며, 필요 시 개발자를 투입하여 오류

프로그램에 대한 수정작업을 수해해야 합니다.

VV--1. 1. 기타내용기타내용 –– DBA R&RDBA R&R


임시 스토리지 : 기존 스토리지임시임시 스토리지스토리지 : : 기존기존 스토리지스토리지

데이터M

igration

Migration Planning

(Migration 준비)

Migration

(Migration 실시)

Verify (Migration 검증)

온라인 데이터 Migration을 위한 사전 준비를 수행하는 단계로써, 고려사항은 다음과 같습니다. 준비과정으로 발생하는 다운타임과 전체 서비스의 영향을 최소화 시키기 위한 신속한 준비작업 완료

Migration 수행 후 문제 발생 시 기존 스토리지로 Roll Back과 준비작업 최소화를 위한 효율적인 SANCabling 필요

TDMF S/W를 이용하여 온라인 데이터 Migration을 진행하는 과정입니다.

TDMF의 Monitoring Tool을 이용하여 Migration의 성능 및 결과를 모니터링하는 단계입니다.

고객과 합의된 검증 시나리오에 따라 Migration 결과를 검증하는 단계로써, 고려사항은 다음과 같습니다. 볼륨 Access 및 서비스에 대한 검증을 단 시간 내에 최적화하기 위한 시나리오 사전 검증검증 후 즉시 서비스 재개

Monitoring

(Migration 모니터링)

Migration Planning

임시 스토리지 데이터

Migration 세부 계획 확정

Migration 사전 준비

H/W(SAN환경) 환경 사전 구성S/W(TDMF)설치 후Volume구성

데이터 Migration

Online데이터 Migration

사후 작업

데이터 확인 및 검증

임시 SAN환경 및 TDMF제거

임시 스토리지 구성을 위하여 기존 스토리지에 있는 데이터의 Online Migration을 위해서는TDMF S/W를 이용한 Migration

방법을 제안합니다.

VV--1. 1. 기타내용기타내용 –– Storage Data Storage Data 이행이행


임시 스토리지 -> 기존 스토리지임시임시 스토리지스토리지 --> > 기존기존 스토리지스토리지

Hittachi & HP XP256 IBM EMC

IBM HP

IBM

IBM IBM

Online데이터 Migration

TDMF TDMF TDMF TDMF TDMF TDMF TDMF TDMF TDMF TDMF

1. 기존 데이터들의 Copy 2. Update 데이터들의 비 동기 Copy3. Migration Source 데이터 정합성 유지

TDMF TDMF

이행 방안

기존 시스템 환경에서 HP & IBM 서버와 다양한 Hittachi, HP XP256, IBM, EMC 스토리지, Internal disk를 모두 사용하고 있는환경에서의 다운타임을 최소화하며 새로운 제안 시스템 환경의 스토리지 환경 구축.

임시 IBM 스토리지 대여 장비로 TDMF를 이용하여 S/W 방식의 온라인 데이터 Migration 환경 구성으로 이행작업을 위한 준비작업 완성

Active Volume

In-Active Volume

임시 SAN 환경

다양한 벤더의 스토리지를 사용하고 있는 환경에서 온라인 데이터 Migration 수행을 위해 IBM TDMF 솔루션을 통하여 안정

적으로 임시 스토리지로 구성



VV--1. 1. 기타내용기타내용 –– DBF Naming RuleDBF Naming Rule


VV--1. 1. 기타내용기타내용 –– 33rdrd Application F/OApplication F/OOracle Clusterware is …

a. kill -9 ‘LGWR Process’ , kill -9 ‘listener PID’ Restart Automatically !!kill -9 ‘oracle.exe’ , kill ‘tnslsnr.exe’ by Windows Task Manager Restart Automatically !!

b. kill ‘httpd’ , kill ‘telnetd’ Restart Automatically by restart attempts !!

c. When a Node dies VIP fails over to a different node !!Fail the VIP or VIP NIC device VIP fails over to a different node !!

10g Release 2 is Protect 3rd Party Applications !!

** Oracle Clusterware 를 사용하여 Single Instance 환경의 HA 기능도 제공하며 Single Node / Local FileSystem을 ASM 또는 Cluster FileSystem 인 OCFS등으로 전환하여 High Availability 기능을 이용할 수 있다.

** 10g R1 까지 지원되지 않던 Non-Oracle Application 의 Failure Protect 기능이10g R2 부터 가능해졌으므로 본 문서는 위의 기능을 Test 함.


VV--2. QnA2. QnAQnA

감 사 합 니 다

Learn Oracle From Oracle2007 Innovative Technology Seminar

실전 dbms migration 사례및 실무구현 workshop실전dbms data migration...

Documents