oracle 11g로의진보된 upgrade방안 - :: · pdf filepage 2 page 2. 목차. 1....

Oracle Korea

Oracle 11g로의 진보된 Upgrade방안

목 차

1. Upgrade/Migration이란?

2. 기대효과

3. 11g New Features

4. 고려사항 및 방법론

가. 논리적 고려사항

나. 물리적 고려사항

다. 구현적 고려사항

라. 방법적 고려사항

5. Upgrade 수행 사례 (Oracle Database Migration Service)

System Migration 배경

성능저하 현상

- Data의 지속적인 증가

- 사용자 수의 증가

시스템 Resource 부족 현상

- CPU, Memory, Disk의 제한 및 한계

현 Architecture의 한계로 유연성이 떨어짐

- 신기술 접목에 대한 대처 능력 떨어짐

- Business 변화로 System의 통/ 폐합 요건 발생

낮은 DBMS Version에 대한 Upgrade 부담.효율적인 운영 문제

- 데이터베이스 관리 어려움 ( Cost 증가)장애 발생시 Database Recovery에 많은 시간 소요 (Failover, Fail back)

1. Migration 이란 ?

시스템을

가동한

후

약

3~4 년

정도

시간이

경과하게

되면

사용자는

다음과

같은

문제점에

직면

합니다.

Migration 이란?제품에

대한

Version Upgrade, Data 이관

작업만이

아닌

성능

향상을

위한

SQL 문

Tuning,

시스템

규모에

맞는

Parameter Tuning, 장애

복구

시나리오

마련

등

기존 시스템에서

취약했던

부분을

반영하여

시스템의

안정성, 가용성, 성능

향상을

구축하는

작업

입니다. .

2. Migration to Oracle 11g의 기대 효과

TCO 감소 (Total Cost of Ownership) , 성능 향상

Real Application Testing OptionAutomatic SQL Tuning AdvisorAutomatic Diagnostic WorkflowPatch AutomationData CompressionFlashback Human ErrorsPartitioning option & Advisor

가용성 및 Security 향상

Real Application clusterData Recovery AdvisorStreamsFlashbackData Guard and snapshot standbySecurity ( FGA, VPD, Secure File)

Operations and Infrastructure Top Concerns

• Convert Physical Standby to Snapshot Standby and open for writes by testing applications

– ALTER DATABASE CONVERT TO SNAPSHOT STANDBY;

• Discard testing writes and catch-up to primary by applying logs

– ALTER DATABASE CONVERT TO PHYSICAL STANDBY;

• Preserves zero data loss – But no real time query or fast failover

• Similar to storage snapshots, but:– Provides DR at the same time– Single copy of storage

Physical Standby Apply Logs

Snapshot Standby Perform Testing

Open Database

Back out Changes

Continuous Redo Shipping

3. Database Replay (Test 환경 Setup )

두번째 방법 : Recovery Manager (RMAN) DUPLICATE command

세번째 방법 : Data Pump Import and Export

첫번째 방법: Snapshot standby

Benefit:•Realistic testing on Production Workload before deployment

Middle Tier

Capture DB Workload

Storage

Oracle DB servers Replay DB

Workload

Oracle Database 10g Production

Oracle Database 11g RAC Test

Storage

3. Database Replay

Capture SQL

Storage

Oracle DB servers

Execute SQL

Queries

ProductionEnvironment

Test (RAC)Environment

Benefit• Test impact of change on SQL performance

Oracle Database 10g Production

Oracle Database 11g RAC Test

Storage

3. SQL Performance Analyzer

3. SQL Performance Analyzer

4. Migration 시 고려 사항 (논리적)

논리적 고려사항

Migration시 허용된 Down Time 시간은 얼마나 되는가?향후 Storage 운영 계획은?- 통/폐합에 따른 Storage 변경

- 성능 및 가용성을 고려한 Disk 재배치

- Data 증가에 따른 size확보 혹은 Data Purge 정책 혹은 Compression 기존 업무 System 과 Interface이상 유무 점검은 어떻게 할 것인가? Oracle 11g New Feature 적용은 어느 범위까지 할 것인가?Migration으로 인한 Down Time 발생시 OLTP 운영방안은 무엇인가?Migration 후 Data 정합성 검증은 어떻게 할 것인가?Migration 후 Application 이상 유무 검증은 어떻게 할 것인가?성능 점검은 어떻게 할 것인가?

4. Migration 시 고려 사항 (물리적)

물리적 고려사항

DB Object 구조는 어떻게 되어있나?- User, Segment type, size , object_type, privilege , column type등….

Migration을 위한 가용 Disk size는 얼마인가

OS 제한 File szie가 존재하는가?

Distribute Database Option의 Operation이 가능한가?

Network Speed는 충분한가?

Down Time을 줄이면서 작업 효율을 위해 가능한 Resource 여유율운? (cpu, memory)

고객사 보안Tool 혹은 system에 대한 관련된 문제는 없는가?

기타 물리적 제약은 없는가?

4. Migration 시 고려 사항 (방법적)

방법적 고려사항

DBMS Upgrade- 정의 : 현재 사용하고 있는 Version을 상위 버전으로 업그레이드함

- 추가 작업 요소

가. Version Up에 따른 기능 점검

나. System Resource 적절성 점검

DBMS Migration (운영 중인 DB를 고도화 하는 작업)- 정의 : 운영 중인 DataBase를 고도화 하는 작업

- 추가 작업요소

가. Upgrade의 가, 나 사항 동일

나. 운영중인 application 기능/성능 검증

다. Interface 간 기능/ 성능 검증

라. System Architecture 변경으로 인한 관리 체계 변동

4. Migration 시 고려 사항 (방법)

방법적 고려사항

Migration 방법

1) DBUA, Manual Upgrade2) exp / imp 방법 ( expdp, impdp)2) CTAS (Create Table As Select)3) SQL*Loader4) Mview (Materialized View)

5) 기타 고객 DBMS 환경, Migration요건에 맞는 Oracle Solution 수행

4. Migration 시 고려 사항 (구현)

구현 고려사항

System Resource 및 Parameter

SQL Optimizer & Parameter

Pro*C Compile

Application Interface- JDBC- SQL * NET- Database Link

RAC- CRS Configuration - H/W configuration- Work Load Distribution , TAF

기타

- New Feature 적용인한 고려사항 ( 예 Long type LOB type)

System Resource 및 Parameter

V 8.1.7.4 for AIX 5.2 RSS TRS Private Mem (KB)

ora_pmon_REF817U3 16,508 11,868 4,640

ora_dbw0_REF817U3 13,796 11,868 1,928

ora_ckpt_REF817U3 13,328 11,868 1,460

ora_lgwr_REF817U3 13,304 11,868 1,436

ora_smon_REF817U3 13,256 11,868 1,388

ora_reco_REF817U3 13,192 11,868 1,324

83,384 71,208 12,176

V 9.2.0.7 for AIX 5.2 RSS TRS Private Mem (KB)

ora_pmon_REF9207U 30,016 21,576 8,440

ora_dbw0_REF9207U 27,488 21,576 5,912

ora_ckpt_REF9207U 26,352 21,576 4,776

ora_lgwr_REF9207U 25,728 21,576 4,152

ora_smon_REF9207U 25,640 21,576 4,064

ora_reco_REF9207U 25,316 21,576 3,740

160,540 129,456 31,084

V 10.1.0.4.0 for AIX 5.2 RSS TRS Private Mem (KB)

ora_pmon_REF1014U 48,668 38,696 9,972

ora_dbw0_REF1014U 46,616 38,696 7,920

ora_ckpt_REF1014U 44,448 38,696 5,752

ora_lgwr_REF1014U 44,420 38,696 5,724

ora_smon_REF1014U 45,980 38,696 7,284

ora_reco_REF1014U 44,072 38,696 5,376

274,204 232,176 42,028

V 10.2.0.1.0 for AIX 5.2 RSS TRS Private Mem (KB)

ora_pmon_REF1021U 122,948 110,600 12,348

ora_dbw0_REF1021U 121,304 110,600 10,704

ora_ckpt_REF1021U 118,944 110,600 8,344

ora_lgwr_REF1021U 118,620 110,600 8,020

ora_smon_REF1021U 120,476 110,600 9,876

ora_reco_REF1021U 118,648 110,600 8,048

720,940 663,600 57,340


Memory 영역

OS Kernel 값 변경

- 권고 Kernel 값 설정 및 Process, Open file 개수 적절히 설정

• Problem• 기존의 Rule Base Optimizer를 사용하고 있음.

CBO로 전환하고자 하나 Application의 성능저하 및 여러 문제점이 예상 됨에 따른 막연한 두려움.• Data의 증가 및 사용자의 증가에 따른 성능증가 문제로 새로운 Partition Table,Hash Join의

유용한 기능을 사용하고 싶음.

• 타 시스템과 연계에 많음 문제점. (Oracle 7 과 >= Oracle 9i의 DB Link는 지원하지 않음)• Critical한 업무가 운영되고 있으므로 Down Time의 최소화 요구

• Solution • Migration 방법은 최대한의 Target Version의 기능을 최대한 활용 및 Restructure 방법인 CTAS 사용.• 충분한 응용 Program 테스트

• RBO to CBO에 따른 Parameter설정 Focus :- OLTP는 OLTP의 특징인

Index위주의 Scan으로 처리

- Critical SQL ( Exec Top,주요 업무의 Plan Check에 의한 최적의 Parameter설정 )- Batch job을 CBO의 향상된 기능인

Hash Join 및 Optimal Automatic Workspace(Sort,Hash Memory) 의 사용으로 성능의 개선으로 Best Throughput Target

SQL Optimizer (Rule base Cost base)


• Batch 성능향상 Target : DB Block Size (2KB -> 8KB), db_file_multiblock_read_count (8 to 32), Hash Join (Disable -> Enable), workarea_size_policy (Auto)

• OLTP의 기존 RBO의 Nested Loop형태의 App들을 위한 Target : Optimizer_* Parameter 조정• Optimizer 관련 주요 Parameter

NAME 권장값 내용

db_file_multiblock_read_count 32Full Table Scan시 Read Count

cursor_sharing EXACT 임의의 상수에 대해서 강제적인 Bind변수로의 변경을 사용하지 않음

hash_area_size 10MHash Join발생시 적절한 Memory를 사용하기 위해. workarea_size_policy를

AUTO로 사용할 경우 참조만 될 것임

hash_join_enabled TRUEHash Join Plan을 Optimizer가 고려한다

optimizer_index_caching 80 Index Scan위주로 Plan이 처리되도록 가중치 지정. Index를 이용한 Nested

Loop를 선호한다. (0 to 100)

optimizer_index_cost_adj 20 Index Scan위주로 Plan이 처리되도록 가중치 지정 (1 to 10000)

optimizer_mode CHOOSEOptimizer Mode를 CHOOSE로

parallel_max_servers 6최대 MAX parallel server 수. CPU * 2 * 2

sort_area_size 4MSort Area Size. Workarea_size_policy를 AUTO로 사용하면 적절히 설정하지만

실제 사용 안됨.

_sort_multiblock_read_count 32 2 -> 32. Temporary쪽에 I/O가 발생했을 때 I/O의 Read단위

pga_aggregate_target 500M Instance내에서 PGA Target. SQL Work 영역으로 사용토록.

( OS memory – SGA ) * 30%정도

workarea_size_policy AUTOSQL Work Area(SORT,HASH)를 자동설정 기능 사용.

SQL Optimizer (Rule base Cost base)


• Problem• 기존의 2KB -> 8KB로 Migration Test 단계

• 같은 CBO(CHOOSE to CHOOSE)로 Migration• Batch Job의 성능은 획기적으로 개선 되었으나 OLTP업무는 상당 부분이 Index가 있음에도 Index를 사용하지 않는 경우도

많아 졌고

많은 부분이 느려졌음.• Batch Job의 성능은 현재 개선된 상태로 유지하고 싶으며, OLTP는 개선이 필요 하며, Application에 대한 Hint의 설정은 너

무 많은

비용이 소요되므로 적용할 수 없음.

• Solution • 9i이상부터는 Automatic Workspace사용기능으로 필요한 Work Memory (Sort,Hash,Bitmap)의 사용에 대한 최적화 기능

으로 충분한 Memory의 사용량의 증가에 따른 Sort,Hash Join의 획기적 성능개선으로 VLDB,DW등과 OLTP등에 모두 만족

할 수 있는 형태로 Optimizer의 기능이 향상되었음.

• Optimizer의 통계정보 운영, 또는 재구성. (DBMS_STATS이용)• Nested Loop등 OLTP를 위한 조정을 위해 OPTIMIZER_INDEX_CACHING, OPTIMIZER_INDEX_COST_ADJ등의

Parameter조정

또는 FIRST_ROWS_n 의 Optimizer로 OLTP 위주의 업무에 적용

SQL Optimizer (8i이하에서 9iR2 이상 Version으로 Upgrade시)


• Problem• Migration 시 Single Table을 Partition Table로 전환 후 RBO로 동작하도록 하기 위한 목적으로 통계정보를 운영하지

않았다.

• 특정시점에 Plan이 변경되어 Batch Job의 실행이 현저히 느려졌다.

• Solution • RBO에서는 New Feature를 지원하지 않으므로 CBO에서만 동작되는 기능이 무엇인지 확인한다.• Partition Table을 사용하면 무조건 CBO로 동작 되며, 통계정보가 없다면 Heuristic Value를 이용하여 통계정보를

만들어 낸다. 그러므로 Data량의 증가에 따라 Plan이 변경될 수 있다. 즉 RBO로 동작될 것이란 생각은 잘못된 경우이다.

• DBMS_STATS를 사용하여 통계정보를 운영한다.• 10g 이상인

경우 Dynamic Sampling기능, 자동적인 통계 수집기능으로 운영의 자동화

SQL Optimizer (Single Partition Table)


• Problem

• 보통의

경우는

정상적이나, 사용자가

조금만

증가하여도

CPU사용량

100%.

• Peak시기동안

업무

Service 중단.

• Application은 MS ASP (ODBC) + Oracle Database

• Tuning Key Point.

• 같은

업무를

사용자가

증가하여

자원고갈이

급속도로

증가된다면

SQL공유문제를

의심할

수

있다.

(특히 ODBC,JDBC,ADO,JSP, VB 등)

• 집중적으로

실행되는

Application은

공유화

형태(Bind변수

사용)로

구성되어야

한다. Literal SQL들은

비공유

되므로

관련

SQL들을 Compile하는 overhead가

있다.

• 모든

DB접속을

위한

App Method들은

공유화

기법을

제공한다.

• Solution

• Application의

비공유

유형의

프로그램을

공유화

형태로

변경한다.

• 차선책으로

변경이

불가능한

경우는

CHRSOR_SHARING=SIMILAR를

이용한다.

SQL Optimizer (비공유 SQL)


• Problem• Open시점은 Application의 Performance가 문제가 없었으며, 급속히 성능저하현상이 나타났으며 Peak시기는

CPU사용량

100%.• Buffer Cache Hit율이 낮아서 Buffer Cache(SGA)를 충분히 늘려줬으나 같은 현상.• 일부 Consulting사는 H/W의 용량의 한계로 판단 함

• Tuning Key Point.• Application이 시스템 open시에는 응답시간에 문제가 없었으나, Data량의 증가에 따른 성능저하가

발생되는 형태는 Index 사용의

문제. • Index가 있음에도 불구하고 App에서 Index를 사용하지 않는 경우는 통계정보 및 App의 구조적 문제를 의심한다.• 통계정보의 운영 Pattern을 확인한다.

• Solution • CBO에서는 통계정보에 의해서 Plan들이 결정되므로 정확한 통계정보를 운영한다. (부정확한 통계정보는 없는 것 보다 못하다)

• DBA가 관여 없이 가능한 최적의 운영상태를 유지하기 위해서는 11g로 Migration후 Automatic Optimizer Statistics Collection기능을 이용한다

SQL Optimizer (Application 성능 저하 , Peak시 CPU 100% 사용)


• Problem• DML처리 속도가 느리고, CPU사용량이 높다.• Lock현상도 자주 발생된다

• Tuning Key Point.• 전체시스템에서 Execution이 높은 Top SQL을 검증한다. (V$SQL,11g ADDM 이용)

Top I/O발생 SQL위주로 Tuning한다. (V$SQL, 11g ADDM 이용)• DML의 처리속도가 늦다면 Recursive SQL(호출된 Procedure,Function,Trigger등)을 확인한다.• Index Split 또는 Lock,Wait정보를 확인한다.

• Solution • 시스템의 전체 Buffer I/O 상위를 차지하고 있는 Top I/O발생 Application 확인 및 Tuning• Tuning은 Oracle 11g의 ADDM의 문제의 원인 자동 검색과 Automatic SQL Tuning Advisor등을 활용

SQL Optimizer (DML 처리 속도)


• Problem

• 시스템에

전체

I/O가

높게

발생

• SORT_AREA_SIZE가

64KB로

너무 작게 설정

• Tuning Key Point.

• TEMP Tablespace는

I/O를

거의

발생하지

않도록

할

수

있다.

• 각

SQL마다

필요한

만큼

최적의

Memory를

사용하기

위해서는

9i이상에서는

Automatic Workspace방법을

사용한다.

(WORKAREA_SIZE_POLICY=AUTO.)

• Solution

• SORT_AREA_SIZE를

OLTP기준으로

Application특징을

확인

후

적절히

설정한다. (2MB or 4MB)

• 최선책은

Automatic Workspace방법을

제공하는

9i 또는

10g를

사용하여

Application의

성능을

획기적으로

개선한다.

• 불필요한

Temp I/O를

거의

0% I/O상태로

바꿀

수

있다.

SQL Optimizer (Temp I/O)


• Hold_cursor, Release_cursor

Cursor cache entry Cursor cache entry cursor

Program cursor for SQL statement

HOLD_CURSOR=YES program cursor is permanently

linked to its cache entry.

RELEASE_CURSOR=NO cache entry maintains the . address of its context.

Hold_cursor=Yes

정의 : SQL문장이 실행되어질 때 연관된 cursor와 cursor cache entry간의 link 상태를 control하는 Option. (cursor cache entry는문장을 processing할 때 필요한 정보를 저장하는 곳이다).

Release_cursor=No

정의 : SQL문장이 실행되어질 때 연관된 cursor cache와 private SQL area간의 link를 control하는 Option.

Pro*C Precompile Option

Pro*C Compile


성능비교

DB Process CPU 사용 현황

020406080

100120140160180200

1 13 25 37 49 61 73 85 97 109

121

133

145

157

169

181

193

205

217

229

간격

소요

시간

항목 Hol d _ c u r s o r = Y e s & R e l e a s e _ c u r s o r = N o H o l d _ c u r s o r = N o & R e l e a s e _ c u r s o r = Y e s

DB Process CPU 사용량 (LOCAL) 98 158

Forground Process CPU 사용량

(Applcation Program)

User Call 량 558,426 934,717

Parse Time CPU 0 837

Parse Time Elapsed 0 1107

Parse Count(total) 4 373,895

Hard Parse 0 0

78

183

DB Process CPU 사용현황

0

20

40

60

80

100

120

1 7 13 19 25 31 37 43 49 55 61 67 73 79 85 91 97 103

109

간격

시간


• 성능 비교

Pro*C Compile

11g : URL 참조 http://www.oracle.com/technology/tech/java/sqlj_jdbc/htdocs/jdbc_faq.htm10g Release 1/2 (10.1/10.2) JDBC drivers are certified to work with 10.0.x, 9.2.x, and 8.1.7.x database

releases.

9.2 Oracle JDBC drivers are certified to work with 9.2.x and 8.1.7 database releases.

9.2 Oracle JDBC drivers are not certified to work with older, unsupported database releases, such as 8.0.x and 7.x. (Note : 203849.1)

Summary

9R2

Product Support

8.1.7.3~

8.0.x

SQL*NET

JDBC, JDK11g

Product Support8.1.7.3

~8.0.x

SQL*NET

JDBC, JDK


• JDBC Version Metric

Application Interface

http://www.oracle.com/technology/tech/java/sqlj_jdbc/htdocs/jdbc_faq.htm

SQL*Net은 “Database to Database” or “Database to Client” 간 통신 수단.

DB Version Up시 DDB Operation 하는 (Snapshot, Remote DML, Replication) Product Option에 영향

10g/9i Client Version <-> 8.1.7.4 Database 기본적인 Data Query Operation은 문제 없으나 8.1.7.4 이하 Site에 SQL*Net Client

와 관련된 문제가 발생 되었을 경우 Support 받을 수 없다

10g Client 를 이용한 8.1.7.4 이하 Database Direct Connect은 불가능 하다 (sqlplus, Pro*C 등)

10g Client Program 내에서 dblink를 통해 8.1.7.4 이하 DB Query는 불가능 하다. (Oracle Session Hang-Tuxedo, SQL-Plan,

Function PL/SQL 수정 )

Oracle SQL*Net Version Matrix

ClientVersion 10.2.0 10.1.0 9.2.0 9.0.1 8.1.7 8.1.6 8.1.5 8.0.6 8.0.5 7.3.410.2.0 Yes Yes Yes #5 No EMS No #3 No #3 No #3 No #3 No #310.1.0(#4) Yes Yes Yes Was EMS #2 No #3 No #3 No #3 No #3 No #39.2.0 Yes #5 Yes Yes Was EMS No No Was No No #19.0.1 No Was Was Was Was Was No Was No Was8.1.7 EMS EMS EMS Was EMS Was Was Was Was Was8.1.6 No No No Was Was Was Was Was Was Was8.1.5 No No No No Was Was Was Was Was Was8.0.6 No No Was Was Was Was Was Was Was Was8.0.5 No No No No Was Was Was Was Was Was7.3.4 No No Was Was Was Was Was Was Was Was

Server VersionYes Supported

EMSSupported for customers under ExtendedMaintenance (EMS) only.

Was

Was a supported combination but one of thereleases is no longer covered by any of PremierSupport , Primary Error Correct support orExtended Maintenance Support so f ixes are nolonger possible.

No Has never been Supported


• SQL*NET Version Metric

Application Interface

15 14 13 12 11 10 9 87 6 5 4 3 2 1 0

15 14 13 12 11 10 9 87 6 5 4 3 2 1 0

Public NetworkActive Lan Stand by Lan

Oracle VIPnetwork adapter Oracle VIP

Active Lan Stand by Lan

pnuh102:/oracle/crs/oracle/product/10.2/bin#netstat

-in

IPv4:

Name

Mtu Network Address

Ipkts Ierrs Opkts Oerrs Coll

lan2:801 1500 200.100.1.0 200.100.1.118 48 0 9 0 0

lan3 1500 192.168.200.0 192.168.200.2 19547 0 24594 0 0

lan2* 1500 none none 139 0 129

0 0

lan1 1500 192.168.100.0 192.168.100.2 19554 0 24605 0 0

lan9 1500 200.100.1.0 200.100.1.116 106547 0 186164 0 0

lo0 4136 127.0.0.0 127.0.0.1 361754 0 361754 0 0

lan902* 1500 none none 0 0 0 0 0

lan901 9000 192.168.101.0 192.168.101.2 350454 0 388782 0 0

pnuh102:/oracle/crs/oracle/product/10.2/bin#netstat

-in

IPv4:

Name

Mtu Network Address


lan9:801 1500 200.100.1.0 200.100.1.118 686 0 12 0 0

lan3 1500 192.168.200.0 192.168.200.2 19807 0 24731 0 0

lan2* 1500 none none 139 0 129

0 0

lan1 1500 192.168.100.0 192.168.100.2 19814 0 24742 0 0

lan9 1500 200.100.1.0 200.100.1.116 106915 0 187285 0 0

lan9:802 1500 200.100.1.0 200.100.1.117 0 0 0 0 0

lo0 4136 127.0.0.0 127.0.0.1 365429 0 365429 0 0

lan902* 1500 none none 0 0 0 0 0

lan901 9000 192.168.101.0 192.168.101.2 352703 0 391180 0 0

Lan9 Lan2


RAC – CRS 구성

본

자료

Log는

10gR2임

network adapter

15 14 13 12 11 10 9 87 6 5 4 3 2 1 0

15 14 13 12 11 10 9 87 6 5 4 3 2 1 0

Public Network

IBM

EtherChannel

HP APA ( Auto Port Aggregation )

SUN IPMP ( Trunks )

Oracle VIPOracle VIP

srvctl

stop

nodeapps

-n pnuh101

srvctl

modify

nodeapps

-n pnuh101 -o /oracle/app/oracle/product/10.2 -A 200.100.1.117/255.255.255.0/lan9₩|lan2

srvctl

modify

nodeapps

-n pnuh102 -o /oracle/app/oracle/product/10.2 -A 200.100.1.118/255.255.255.0/lan9₩|lan2

srvctl

start

nodeapps

-n pnuh101

• Best Public Network 구성


RAC – CRS 구성

본

자료

Log는

10gR2임

CRSD:

Engine for HA operation

Manages 'application resources'

Starts, stops, and fails 'application resources' over

Spawns separate 'actions' to start/stop/check application resources

Maintains configuration profiles in the OCR (Oracle Configuration Repository)

Stores current known state in the OCR.

Runs as root

Is restarted automatically on failure

OCSSD:

OCSSD is part of RAC and Single Instance with ASM

Provides access to node membership

Provides group services

Provides basic cluster locking

Integrates with existing vendor clusteware, when present

Can also runs without integration to vendor clustware

Runs as Oracle.

Failure exit causes machine reboot.

EVMD:

Generates events when things happen

Spawns a permanent child evmlogger

Evmlogger, on demand, spawns children

Scans callout directory and invokes callouts.

Runs as Oracle.

Restarted automatically on failure


RAC – CRS 구성

본

자료

Log는

10gR2임

rac1]/u01/home/beta>

ps

-ef

|

grep crs

oracle 1363 999 0 11:23:21 ? 0:00 /u01/crs_home/bin/evmlogger.bin -o /u01

oracle 999 1 0 11:21:39 ? 0:01 /u01/crs_home/bin/evmd.bin

root 1003 1 0 11:21:39 ? 0:01 /u01/crs_home/bin/crsd.bin

oracle 1002 1 0 11:21:39 ? 0:01 /u01/crs_home/bin/ocssd.bin

[opcbsol1]/u01/home/usupport> ./crsstat

HA Resource Target State

-----------

------

-----

ora.V10SN.V10SN1.inst ONLINE ONLINE on opcbsol1

ora.V10SN.V10SN2.inst ONLINE ONLINE on opcbsol2

ora.V10SN.db ONLINE ONLINE on opcbsol2

ora.opcbsol1.ASM1.asm ONLINE ONLINE on opcbsol1

ora.opcbsol1.LISTENER_OPCBSOL1.lsnr ONLINE ONLINE on opcbsol1

ora.opcbsol1.gsd ONLINE ONLINE on opcbsol1

ora.opcbsol1.ons ONLINE ONLINE on opcbsol1

ora.opcbsol1.vip ONLINE ONLINE on opcbsol1

ora.opcbsol2.ASM2.asm ONLINE ONLINE on opcbsol2

ora.opcbsol2.LISTENER_OPCBSOL2.lsnr ONLINE ONLINE on opcbsol2

ora.opcbsol2.gsd ONLINE ONLINE on opcbsol2

ora.opcbsol2.ons ONLINE ONLINE on opcbsol2

ora.opcbsol2.vip ONLINE ONLINE on opcbsol2


RAC – CRS 구성

본

자료

Log는

10gR2임

2. Cluster Interconnect 구성

network adapter L2 switch deviceIBM

EtherChannel

HP APA ( Auto Port Aggregation )

SUN IPMP ( Trunks )

Server A Server B

Active (Service) Line

Standby (Backup) Line

15 14 13 12 11 10 9 87 6 5 4 3 2 1 0

15 14 13 12 11 10 9 87 6 5 4 3 2 1 0


본

자료

Log는

10gR2임

2. Cluster Interconnect 구성

On

metalink

we can find the following about the interconnectNetwork Interconnect

o 100Mbps and Gigabit

NICs

and switches using the UDP protocolo Several proprietary interconnects (see vendor entries for specific info)

o Crossover Cable

o

Crossover Cable is not supported as an Interconnect with 9iRAC/10gRAC on any platform.

proprietary interconnects/interfaces are vendor specific implementation like

Hyperfabric, memory channel or SunFirelink. OS vendorspecific

IPC protocols usually only run over a proprietary interface, such as HMP over theHyperFabric2 interface on HPUX, RDG over memory channel on Tru64, or RSM over Sun

Firelink.Search eg. for HMP/HyperFabric

on the HP web side and you will get tones of information about how to implement and configure this.

The Oracle recommendation on all platforms is using Gigabit

NIC's

and switches with UDP protocol.

-

Regards Roland

MTU Size 는

?

Larger Ethernet Frame Size (Jumbo frames)

For significant performance gains with IP based protocols, the use of Jumbo frames is strongly recommended. However, one needs to ensure that the host

NICs

as well as the switches support the 9K-frame size. A larger Ethernet frame size avoids fragmentation and reassembly

of packets and the corresponding kernel CPU overhead at no significant latency cost for smaller messages.


본

자료

Log는

10gR2임

• Cluster Interconnect Failover

3. RAC & SAN Disk & TAF

pnuh101:/oracle/crs/oracle/product/10.2/log/pnuh101/cssd#netstat -in

Name Mtu Network Address


lan9:801 1500 200.100.1.0 200.100.1.117 52741 0 1446 0 0

lan3 1500 192.168.200.0 192.168.200.1 70123 0 137087 0 0

lan2* 1500 none none 0 0 0 0 0

lan1 1500 192.168.100.0 192.168.100.1 70103 0 137091 0 0

lan9 1500 200.100.1.0 200.100.1.115 126186 0 213989 0 0

lo0 4136 127.0.0.0 127.0.0.1 2074963 0 2074964 0 0

lan902* 9000 192.168.101.0 192.168.101.1 2164 0 2173 0 0

lan901* 9000 none none 795256 0 765517 0 0

lan900* 1500 none none 0 0 0 0

Database Hang -> 15 분

Alert.log

Fri Aug 25 14:14:11 2006

ospid

7535: network interface with IP address 192.168.101.1 is DOWN

Fri Aug 25 14:16:11 2006

15 14 13 12 11 10 9 87 6 5 4 3 2 1 0

15 14 13 12 11 10 9 87 6 5 4 3 2 1 0

SAN Switch 장애

OS log

Aug 25 16:05:07 pnuh101

vmunix: 0/0/6/1/0/4/0:

Fibre

Channel Driver received

Link Dead Notification.

Aug 25 16:05:07 pnuh101

vmunix:

Aug 25 16:05:19 pnuh101

vmunix: 0/0/12/1/0/4/0:

Fibre

Channel Driver received

Link Dead Notification.

Aug 25 16:05:28 pnuh101

vmunix: LVM: Performed a switch for

Lun

ID = 0 (pv

=

0xe0000001fee26000), from raw device 0x1f0a1100 (with priority: 0, and

current flags: 0x40) to raw device 0x1f0c1100 (with priority: 1,

and current

flags: 0x0).

./crsstat ==> Hang ==> Voting Disk 접근 불가

Alert.log

ORA-29702: error occurred in Cluster Group Service operation

LMON: terminating instance due to error 29702


본

자료

Log는

10gR2임

• TAF

3. RAC & SAN Disk & TAF

pnuhsd1=

(DESCRIPTION=

(LOAD_BALANCE=off)

(FAILOVER=on)

(ADDRESS=(PROTOCOL=TCP)(Host=200.100.1.117)(Port=1521))


(CONNECT_DATA=

(SERVICE_NAME= PNUH)

(SERVER=dedicated)

(FAILOVER_MODE=

(BACKUP=pnuhsd2)

(TYPE=select)

(METHOD=basic)

(RETRIES=10)

(DELAY =5))))

pnuhsd2=

(DESCRIPTION=

(LOAD_BALANCE=off)

(FAILOVER=on)



(CONNECT_DATA=

(SERVICE_NAME= PNUH)

(SERVER=dedicated)

(FAILOVER_MODE=

(BACKUP=pnuhsd1)

(TYPE=select)

(METHOD=basic)

(RETRIES=10)

(DELAY =5))))


본

자료

Log는

10gR2임

Database성능 진단

& 신규 요구

분석

ODMS

New Feature 적용을 통한DBMS 성능 향상

최소 비용으로최고의 만족도 구현

운영자의 운영 능력 배양및 시스템 가용성 향상

고성능&

고가용성

정형화된 Workflow를 통한시스템 Down Time 최소화

ODMS

Application Tuning을 통한Response Time 향상

최적화된 시스템 구성 , Tuning 으로 고성능 및 고가용성 확보

1. Oracle Database Migration Services 기대 효과

5. Migration 수행사례

충분한 데이터

Migration 테스트

충분한 데이터

Migration 테스트

충분한 DB Migration 테스트를 통한 작업 시발생될 수 있는 문제점분석 및 최소화

작업 Process의 자동화를통한 人災 최소화

개발장비 및 Migration DB를 이용한 충분한Migration 테스트

충분한 DB Migration 테스트를 통한 작업 시발생될 수 있는 문제점분석 및 최소화

작업 Process의 자동화를통한 人災 최소화

개발장비 및 Migration DB를 이용한 충분한Migration 테스트

완벽한

데이터 정합성 검증

완벽한

데이터 정합성 검증

Rehearsal DB을 이용한신규 Conversion Program Full 테스트기존 Batch결과 및 신규Batch 결과 비교를 통한데이터 검증Migration 이후 데이터정합성 점검 자동화SQL Tuning 및 성능 개선

Rehearsal DB을 이용한신규 Conversion Program Full 테스트기존 Batch결과 및 신규Batch 결과 비교를 통한데이터 검증Migration 이후 데이터정합성 점검 자동화SQL Tuning 및 성능 개선

Down Time 최소화

사전 작업

Down Time 최소화

사전 작업

사전 작업을 통한 시스템Down time 최소화

Migration Job Process의자동화 및 표준화

사전 작업을 통한 시스템Down time 최소화

Migration Job Process의자동화 및 표준화

Down Time 최소화

사후 작업

Down Time 최소화

사후 작업

Down Time 최소화 구현

향상된 성능 보장

Down Time 최소화 구현

향상된 성능 보장

Migration Down Time 최소화 & 운영 System 부하 최소화

2. Oracle Database Migration Services 기본 개념


기존시스템 성능 분석

신기술 접목

신규 시스템 구성 방안

시스템 연동 분석및Transaction 분석

기존시스템 성능 분석

신기술 접목

신규 시스템 구성 방안

시스템 연동 분석및Transaction 분석

운영 환경 구성

Application Program SQL Tuning

DB 구성( 논리적,물리적)

이행테스트 및 이행

시스템 모니터링 방안

RAC 시스템가용성테스트

운영 환경 구성

Application Program SQL Tuning

DB 구성( 논리적,물리적)

이행테스트 및 이행

시스템 모니터링 방안

RAC 시스템가용성테스트

DBMS 모니터링

Application program SQL Tuning

이행 전후 DBMS 성능비교평가

DBMS 모니터링

Application program SQL Tuning

이행 전후 DBMS 성능비교평가

Oracle Database Migration Services Project

1 TASK

Capacity Plan

1 TASK

Capacity Plan2 TASK

Migration Plan

2 TASK

Migration Plan3 TASK

Migration

3 TASK

Migration4 TASK

Tuning

4 TASK

Tuning

이행 관련 Master Plan

Software Compatibility

개발 환경 구성

이행 AP 작성 및 테스트

Data 이행 방안 마련

이행 관련 Master Plan

Software Compatibility

개발 환경 구성

이행 AP 작성 및 테스트

Data 이행 방안 마련

3. Oracle Database Migration Services 수행 프로세스


4. Oracle Database Migration Services 수행 TASKTASK 수행 항목 수행 내용 항목수 소계

Capacity Plan 시스템 연동 분석 및

Transaction 분석• Transaction 연동 Flow 및 User Interface 파악 3

10신기술 접목 • 업무에 따른 New Feature 접목 및 적용 방안 마련 4신규시스템구성 방안 • System Architecture 변경에 따른 문제점 파악 3

Migration Plan 이행 관련 Master Plan • 이행 Master Plan 작성 및 일정 확정 3

48

S/W Compatibility • Oracle Version 별 Compatibility Check 8

개발 환경 구성 • 개발 환경 구성 8이행 Application Program 작성, 테스트

• 이행 관련 Program 작성 및 테스트 8

Data 이행 방안 마련 • 시스템 이행 적용 시기 및 방안 마련 4Object 이관 대상 구분 • New Feature 적용 대상 Object 확정 5Object 이관 준비 • 각종 프로그램 작성 6Object 이관 방법정의 • Object 이행을 위한 방법 및 대안 검토 6

Migration 운영 서버환경 구성 • OS Parameter 설정 검토 및 Oracle Parameter 검토 14

63

Application Tuning • 문제 Application Program Tuning 4I/O 물리적 구성 • Disk Volume 구성 검토 및 확정 ( 시스템 가용성 , 성능 테스트 ) 6DB 환경 구성(논리적) • Object 별 Disk Storage Parameter 설정 10이행테스트 및 이행 • Data 이행 총괄 테스트 및 Data 이행 7

시스템 Monitoring 방안 • System Monitoring 방안 및 시나리오 작성 3

비상운용 시스템 (이행 기간중) • 비상 운영 시스템 도입 여부 결정 및 구축 6

기존 시스템 Back을 위한 시나

리오 작성• 기존 시스템 Back을 위한 문제점 파악 및 Plan 수립 3

Tuning 및 안정화 시스템 Monitoring 및 Tuning • 운영시스템 모니터링 3 3

수행 항목수 (총계) 124개 항목


5. TASK 별 Oracle Database Migration Services 수행 사례1212월월1111월월

11월월 22월월 33월월

OperationNew Sys.

Data Migration Test(개발서버)

Data Migration Test (운영서버) 01.17~02.25

1차 Data Migration정합성 체크

통합 TEST Final Test

설치사전작업완료

유지보수시행

기계실환경구성

개발서버설치

운영서버설치

03.02

1010월월

S4

BMT사전 준비

SYSTEMBMT

10.20

S3

BMT System

결과검토

S2S1

Hardware 선정

10.11 10.31 11.30

12.13

개발DB 설치

12.11

개발서버설치

S6

12.14

S7

개발DB Open

S5

New Server 설치

02.14

3차 DB Migration

Test

01.09 01.19

1차 DB Migration

Test

OP

9i/10g MIGDB Open

02.18

FinalDB Patch

DB사후이관

03.02

DATABASE

SYSTEM

11.08 11.15 12.11 01.19 02.12

P2 P3 P4P1

OP

OP

S8

12.14

S9

01.10~01.17

DB Setup성능

테스트

New System

Setup 완료

01.26

2차 DB Migration

Test

S11

P7

OP

1차 10gRehearsalDB Open

S13 OP

2차 10gRehearsalDB Open

01.28

2차 Data Migration정합성 체크

01.21~22

S10

NEW DB Migration1차 TEST (8.0-> 9i)

01.17~18 S12

NEW DB Migration2차 TEST (8.0-> 9i)

01.24~25

NEW DB Migration10.2.0.2

02.12~13

S152.26~28

DB사전이관

S1

OP

02.18

FinalOS Patch

S15

NEW DB Migra tion 지원

02.12~13

01.19

1차 DB Migration

지원

01.26

2차 DB Migration

지원

12.11 12.14

OPS2

01.09

01.16

OP

시스템Stress테스트

S3

01.10~01.16

New시스템Open

시스템

Tuning / DR 시스템 구축 지원

01.18~01.30 OPS15

01.18 01.30

S14

P501. 09

P6 P8

02.26


신규서버(8CPU:Dual Core, 24Gb)

WEB서버

#2, 백업서버의

CPU, 메모리를

통합한

이관작업

전용

시스템

기존운영DB서버

#1E10K

CPU:20(330Mhz)M/M: 8Gb

디스크장치

(신규

운영)기존운영DB서버

#1E10K

CPU:12(330Mhz)M/M: 8Gb

기존

운영

StorageA3500

36GB*48EA18GB*48EA

(physically 2592GB)

scsi

scsi

Gigabit 전용

N/W

Gigabit 전용

N/W

SAN S/W

6. TASK 별 Oracle Database Migration Services 수행 사례


oracle 11g로의진보된 upgrade방안 - :: · pdf filepage 2 page 2. 목차. 1....

Documents