10g upgrade 실무사례 · data general intel unix hp alpha openvms hp tru64 unix hp-ux itanium...

10g Upgrade 실무사례

세션 1. 10g 업그레이드 계획의 수립 [09:30 ~ 11:00]

세션 2. Upgrade 시 고려사항 및 SQL NF [11:00 ~ 12:00]

세션 3. 10g CBO의 이해 및 통계관리 [13:00 ~ 15:00]

세션 4. 실무 업그레이드 프로젝트 사례 [15:00 ~ 16:00]

세션 5. 11g Upgrade New Features [16:00 ~ 17:00]

목 차

1. 10g 업그레이드 계획의 수립

1.1 10g Upgrade 의 필요성

1.2 업그레이드 세부 계획 수립

1.3 용량관리 (Capacity Planning & Sizing)

1.4 10g Upgrade Manual (사례)


10g New Features의 적용Oracle Database 10g는 자가관리 기능이 크게 향상되어 DBA의 반복적인 작업을간소화 해주고, 최적의 시스템 성능을 보장할 수 있는 다양한 정보를 제공합니다.

Applicationand SQL

Management

StorageManagement

Backup andRecovery

Management

SpaceManagement

Fix Advise

AlertMonitor

CommonInfrastructure

AutomaticManagement

SystemResource

Management

1.1 10g Upgrade 의 필요성(Oracle Policy)

UPGRADE VS. BUSINESS DISRUPTION“기술은 비즈니스 이익을 위하여끊임없이 발전하고 향상되고있습니다. 반면에 IT 운영은 이러한비즈니스 시스템이 상시 구동되기를

바랍니다.”—Activity Cycle Overview: “IT Infrastructure and Operations Executives” Gartner, January 2006

IT EFFICIENCY“IT efficiency 를 증가시키는 것이 IT 결정권자 77% 가 고려하는 가장중요한 부분입니다.”

—Forrester Research, Inc. “CIO’s Must Target Legacy applications with a Maintenance Renaissance”, Phil Murphy, et al, 22 June 2006

MANAGING COST AND RISK“대부분의 회사는 전체 IT 예산 중80% 를 현재의 Operation 을유지하고, 관리하는데 소요 –2005년에는 76% - 오직 20% 만을 새로운 개발작업과, project 에 사용하였습니다.”

Forrester Research, Inc, “CIOs Must Target Legacy Applications with a Maintenance Renaissance”, Phil Murphy, et al, 22 June 2006

HIGH AVAILABILITY

“IT 조직은 미션크리티컬어플리케이션을 위한 계획과 지원에최선을 다하게 되었습니다. 사용자들은가장 중요한 시스템은 수익에직/간접적으로 관련된 것이며, 고객에게서비스를 전달하고 직원의 업무에 영향을

미치는 것이라고 믿습니다.”Source: IDC “Worldwide and U.S. Software Deploy and Support Services 2006-2010 Forecast”, Doc #201977, June 2006

Oracle Server Availability and Certification MATRIX(문서 ID: 공지:223718.1)

1.1 10g Upgrade 의 필요성 [ Oracle Support Policy ]

Product Availability CertificationPlatform Enterprise

EditionStandardEdition

PersonalEdition

Data General Intel Unix ► ►HP Alpha OpenVMS ► ►HP Tru64 Unix ► ►HP-UX Itanium ► ►HP-UX PA-RISC ► ►IBM AIX ► ►IBM NUMA-Q DYNIX/ptx ► ►IBM OS/390 (z/OS) ► ►IBM OS/390 based Linux ► ►IBM zSeries based Linux ► ►Intel Based Server Linux ► ►Linux Itanium ► ►Microsoft Windows 2000 ► ► ►Microsoft Windows NT (Intel) ► ► ►

Microsoft Windows XP ► ► ►Novell NetWare ► ►SGI Unix ► ►Solaris Operating System (Intel) ► ►

Solaris Operating System (SPARC) ► ►UnixWare (SCO) ► ►

OS Product Certified With Version Status Addtl. Info. Components Other Install Issue

5.3 11gR1 64-bit N/A N/A Certified None None None None

6 10gR2 64-bit N/A N/A Certified Yes None None None

5L 10gR2 64-bit N/A N/A Certified Yes None None None

5L 10g 64-bit N/A N/A Certified Yes None None None

Oracle Server Availability and Certification MATRIX(문서 ID: 공지:223718.1)


Client / RDBMSVersion

Windows 2000Support

MinSP

Error Correction Support Ends

DesupportNotice

10.2.010.1.09.2.09.0.18.1.78.1.68.1.58.0.x7.3.4

YesYesYesYesYesYesNo No No

1 1 1 1

31-July-2010 28-February-2009

31-July-2007 31-December-200331-December-200431-October-2001

n/a n/a n/a

Note 161818.1Note 161818.1Note 161818.1Note 201685.1Note 148054.1Note 123178.1

n/a n/a n/a

Min SP = Minimum Service Pack listed in the Oracle installation Guide.

(Click to see Details)

Current Patch Set

Next Patch Set

Premier Support Ends

Extended Support Ends

Notes

11.1.0.X None TBD Aug-2012 Aug-2015 Base release is 11.1.0.6

10.2.0.X 10.2.0.4 TBD Jul-2010 Jul-2013

10.1.0.X 10.1.0.5 None Jan-2009 Jan-2012 10.1.0.5 is the terminal 10.1 Patch Set

9.2.0.X 9.2.0.8 None Jul-2007 Jul-2010First year Extended Support is free for

9.2.0.8 is terminal 9.2 Patch Set.

Oracle Support Policy에 대한 정확한 이해와 확인은 필수 !!!

Oracle 10g Upgrade 세부 계획서

Prepared by J. C. LeeDate : Nov-02-2007

Infra Service Unit DB ConsultingGoodus, Inc.

PIC Leader Head

IS AuthorizationRevision History

1st 2007.10.14 0.5

2nd 2007 10.26 0.8

3rd 2007 11.02 1.0

Final


AGENDA

시스템 구성도 (Architecture/Flow AsAs--Is and ToIs and To--BeBe)

22

33

프로젝트프로젝트 범위범위(Scope of Work)(Scope of Work)

11 프로젝트 목적 (Objects)

구축일정구축일정--전체전체 및및 상세상세(Schedule (Schedule –– Overall and Details) Overall and Details) 44

55 추진조직과추진조직과 R&R (Project Organization and R&R)R&R (Project Organization and R&R)

66

77

88

회의, 보고 와 산출물 (Meeting, Report and Deliverables)

고려사항 (Considerations)

99

필요 자원 과 비용 (HW,SW,HR Requirements and Cost)

향후 일정 (Next Step)

1010 참고사항: 10g New Feature, 구축일정 상세/방법


• 본 프로젝트에서는 다음 네 가지에 초점을 두고 각각의 개선 목표를 향해서 구체적인 방침을 검토, Oracle 업그레이드를포함한 실현가능성 검증과 실행 계획에 대한 방안을 세웁니다.

목 적현상 목표

• Upgrade로 인한 변경사항을

단위, 통합시험으로 Upgrade로인한 Application 영향 최소화

• Oracle 관리 자동화

• DB 자동 진단 / 경보 체계화

• 응답 속도 증가 방식 튜닝으로User 업무 처리 속도 향상

• 10g 새 기능 교육 / 개발 시스템통합 환경 구축으로 개발 시간단축

　 Oracle 10g Upgrade

from 9i

　 10g New Feature 적용

　 Database 성능 향상

　 DBA / Developer 업무 능력향상

• 2007.07 9i 패치 중단

• DB 관리 복잡성 증대

• Application Support 한계

• Application 응답속도 감소

• Database 활용 제약

• DB Security Auditing 제약• DB 보안 강화

프로젝트 목적1.2 업그레이드 세부 계획 수립

• 10g 업그레이드 프로젝트를 통해 아래 범위들을 실현하는 것을 목표로 하고 있습니다.

Database

Availability

• Enterprise Manager(10g Add-on Program) 이용한 중앙 통제 / 자동 관리 체계 구축

• Self-Management 자기관리 시스템 운영

• SGA 메모리 / Space 자동 관리화

• 자동진단 (Automatic Diagnostic) ADDM 시스템 구축

• 자동진단 후 Error Alert & Notification 체계 구축

Database

Performance

• System 성능 초점보다 User 응답시간 단축에 의한 성능 튜닝

• 10g Automatic Workload Repository을 이용한 성능 진단 / 분석

• Optimizer를 통한 SQL 튜닝 자동화

• 개발자에 의한 SQL 성능 분석 환경(10g EM) 구축

Security

• 보안 강화: All User Activity Log

• Auditing으로 인한 시스템 부하 최소화

• Easily Audited Log Monitoring System 구축

Application

Support

• 10g SQL 개발 Guide 작성 / 제공

• Oracle New Feature 개발 적용: Materialized View, IOT, Advanced Scheduling 기능 구현

• External Table, Data-Pump 기능 사용 구현

Backup &

Recovery

• Flash – Time Machine 기능 구현으로 Detailed Row / Table Recovery 구현

• RMAN을 통한 시스템 복구 시간 단축 : 기존 2 ~ 3시간 　 RMAN 30분내

• 백업 관리 자동화

10g Upgrade

• 10g 환경 내 현 Application SQL 시험, 업그레이드 전 영향 평가 후 업그레이드

• 업그레이드로 인한 Application 영향 최소화

• 업그레이드 후 최적화 된 RDBMS 서비스 운영

프로젝트프로젝트 범위범위1.2 업그레이드 세부 계획 수립

• Oracle 업그레이드 영역은 아래의 범위로 상정하고 , 업그레이드의 순서는 EKDB ,IKASS, VICT 순으로 진행 됩니다.

VANTIVEiKASS

Call CenterService System Sales System

IKASS VICT

SCS SCS

SECCStyle

WebPOS

Employee Sales

B&P

ASCPLAZA

BOS

BPEng BOSEOS

EKDB- 보증 관련

- 모델 정보

- 콜 접수 관련

- 주문 정보

- 모델 정보- 보증 정보 관련

iKASSDEV

VICTDEV

EKDBDEV

System Copy

SQL: 1200 건 SQL: 1200건 SQL: 1500 건

시스템 구성도: Application

SECC FIFA

SCS

SECC


iKASS VICT EKDB

• RDBMS의 시스템 Architecture는 프로젝트 후 다음과 같은 그림으로 변경 됩니다.

시스템 구성도: Hardware/Software

AS-IS TO-BE

• SKR6K26(M80)-4WAY, 16GB-EXP320 / 200GB DISK

• IPASDB DEV: PORT 1525• EKDB DEV: PORT 1522• VANTIVE DEV: PORT 1521-IP:192.168.1.107

• ORACLE 10g 10.2.0.3

• SKR6K67(p570)-2WAY, 16GB-DS4800 / 200GB DISK

• IPASDB: PORT 1525•VANTIVE: PORT 1522-IP: 192.168.1.103

• ORACLE 10g 10.2.0.3

• SKR6K67(p570)-2WAY, 16GB- DS 4800 / 200GB DISK

• IPASDB: PORT 1525•VANTIVE: PORT 1522•VANTIVE DEV: PORT 1522-IP: 192.168.1.101

• ORACLE 9i 9.6.0.8

• SKR6K66(6M2)-2WAY, 16GB-Shark / 150GB DISK

• EKDB: PORT 1522-IP:192.168.1.102

• ORACLE 9i 9.6.0.6

• SKR6K82(B80)-2WAY, 8GB-1.5TB DISK

• EKDB DEV:• SSCSK DEV / QAS-IP:192.168.1.106

• ORACLE 9i 9.6.0.6

• Hujitch PRIME-POWER-4WAY, 2GB-64GB DISK

• iKASS DEV:-IP:192.168.1.111

• ORACLE 8i

• SKR6K82(B80)-2WAY, 8GB-1.5TB DISK

• SSCSK DEV / QAS-IP:192.168.1.109

• Hujitch PRIME-POWER-4WAY, 2GB-64GB DISK

• Service N/A• System 유지보수 제외

• SKR6K66(p550)-2WAY, 16GB-Shark / 150GB DISK

• EKDB: PORT 1522-IP:192.168.1.105

• ORACLE 10g 10.2.0.3

<New Oracle 10g Server Farms>


구축일정구축일정--전체전체

Month 2007.11 2007.12 2008.01 2008.02 2008.03 2008.04Oracle Database Week 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4

1. 요구사항 분석

2. 변경 및 단위시험

3. 통합 시험

4. 시험 업그레이드

EKDB

5. 최종 업그레이드



3. 통합 시험


iKASS




3. 통합 시험


VICT


12 주

8 주

8 주


계 획 수 립

환 경구 성

사 전 분 석

SQL 변 경/ 튜 닝

및 단 위

시 험

업 그 레 이 드

시 험 수 행

통 합 시 험

및

시 험 운 영

최 종 이 행계획수립

서버 및 S/W 설치 부수장비 설치

환경 분석 10g 요구사항 분석(10g SQL 표준화)

현 Application SQL 정의 튜닝 대상 / 목표 정의

변경 / 튜닝 SQL 정의

9i SQL Test On 10g 검증 및 보완

Error SQL 변경

단위 시험

변경 결과 적용

결과확인

Test Upgrade 실시(데이터포함)

운영체계 검증일치성 검증정합성 검증

보완 사항 정의 / 보완

시험운영 결과확인

최종 Upgrade 시나리오 작성

최종 Upgrade 및 시스템 가동

NO

YES

데이터 분석

NO

YES

Oracle Test 환경구축

통합시험 및수정보완

•Upgrade 일정 수립•시험계획 수립

• SKR6K26 10g Test DB Setup• SKR6K13 9i Test DB Setup

•기존/목표 환경 분석•Oracle10g 요구사항 파악•Application SQL 추출•튜닝 대상 및 목표 정의

•SQL 10g 환경 내 시험 / 검증•Error / 변경 요구 SQL 추출 및 변경방법 정의•Error / 변경 요구 SQL 변경(Test 9i)•SQL / DB 튜닝(Test 9i)•10g New Feature 시험 / 확인•변경 SQL / 튜닝단위시험(Test 9i/10g)•검증 결과 보완•DB 튜닝 결과 확인(PRD 9i)•변경 SQL 결과 적용(PRD 9i)

• 업그레이드 시험 수행

•정합성 검증•일치성 검증•DB-Application 운영체계 검증•수정보완•시험운영

•최종 업그레이드 시나리오 작성•최종 업그레이드 환경 구축•최종 업그레이드•10g SQL 튜닝

튜닝 작업10g New-Feature

적용 / 시험

단계 수 행 절 차 세 부 내 용

구축수행구축수행 절차절차--전체전체1.2 업그레이드 세부 계획 수립

주요 업무 M+1 M+2 M+3 M+4

Level1 Level2 Level3 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4

계획수립 업그레이드 계획 수립

시험환경

구성서버 및 S/W 설치

10g 업그레이드 요구사항 분석

Application SQL 정의 •9i Application 내 SQL 추출

•튜닝 DB 구조 / SQL 파악사전 분석

튜닝 대상 정의•튜닝 목표 선정

•9i SQL, 10g 환경 내 시험 / Err 추출

•Error SQL 변경 / 개발

• 변경 사항 단위 시험

•검증 및 보완

Error SQL 정의 / 변경

•PRD 9i 적용 / 모니터링

•Bad Performance 대상 추출

•SQL / DB 구조 튜닝

• 튜닝 사항 단위시험

•검증 및 보완

DB 튜닝

•PRD 9i 적용 / 모니터링

•10g New Feature Setup

•운영 시험 / 검증

변경

및

단위시험

10g New Feature 적용

• 운영 매뉴얼 작성

업그레이드

시험 수행9i 에서 10g 업그레이드 시험 수행

통합시험 및 안정화 시험통합시험

시험운영 시험운영

최종 업그레이드 시나리오 작성

최종 업그레이드 환경 구축최종이행

최종 업그레이드 및 시스템 가동

시스템 모니터링 / 최적화

구축구축 일정일정--상세상세(EKDB (EKDB 기준기준))

Total12 주

3 주

6 주

2 주

1 주


• 프로젝트 추진 위원회IS Center

• 프로젝트 리더해당 DB Upgrade 시 DB PI / DBA 강감찬 부장

• 프로젝트 지원-이진철 차장(GoodUS)-강경구 대리(GoodUS)

• 프로젝트 실행 멤버

• EKDB PI-홍길동 과장

• iKASS PI-김유신 대리

• VANTIVE PI-고길동 대리

• Application 변경SYS4YOU 8명

• Security Officer-유관순 과장

프로젝트에서의 역할• 프로젝트 추진위원회-프로젝트 최종 의사 결정기관

• 프로젝트 리더- 프로젝트 전체의 총괄자와 조정자

• 프로젝트 지원-교육지원, 튜닝 지원, 10g 기술지원

• DB PI / 프로젝트 실행 멤버-각 DB별 SQL 시험, 변경, 검증-튜닝 대상 / 목표 선정, 튜닝

• DBA-시험 환경 구성, 10g New Feature 적용, 업그레이드

• Security Officer- 변경 사항 통제 / 승인

• 본 프로젝트에서는 각각의 역할은 다음과 같습니다. 프로젝트를 성공적으로 수행하기 위한 중요한 포인트 중 하나는 자원을 적절히 배분하고 일정에 맞추어 업무를 진행하는 것입니다.

추진조직과추진조직과 R&RR&R

• Application Leader-이순신 차장-김칠복 대리


회의, 보고 와 산출물

• 1.계획수립 • 2.환경구성 • 3.사전 분석

• 4.SQL 변경 / 튜닝 / 적용 • 7.최종 업그레이드

Oracle 10g Upgrade Plan 10g Test Servers 구성도 9i Application SQL 일람 SQL 튜닝대상일람

SQL 튜닝목표 10g 요구분석사항일람 10g SQL 개발표준안 SQL 변경계획

DB 튜닝계획 10g New-Feature 정책계획 SCR Upgrade 시나리오 / 점검표

　

　　

　

　 Report/Mile-Stone

Meeting


필요 자원 과 비용

‘07.10 ‘07.11 ‘07.12 ‘08.01 ‘08.02 ‘08.03 ‘08.04 ‘08.05Resource Role & Responsibility

EC ORACLE CRM ORACLE iKASS ORACLE SUM

S.D.Chang Infra Manager / DBA 0.5 0.5 0.5 0.5 0.5 0.5 3

0.5 0.5 0.5 1.5

0.5 0.5 0.5 0.5 0.5 2.5

T.U.KimSu.K.ParkS.P.Kang

Application Manager- Business Analysis- Change Management- Migration Process 0.5 0.5 0.5 0.5 0.5 0.5 3

0.5 0.5 0.5 0.5 0.5 0.5 3

0.5 0.5 0.5 1.5

K.M.WunSu.K.KimP.Y.Sim

Application Leader- Test / Migration- Support production

0.5 0.5 0.5 0.5 0.5 0.5 3

GoodUs Oracle Leader 0.4( 교육지원포함) 0.3 0.3 1

H.K.Kimn SYS4U Development Leader 0.5 0.5 0.5 0.5 0.5 0.5 3

JAVA SYS4U Development: - 8 persons- System Development

4 4 4 2 2 2 18

( Unit : Man / Month :1=20days)HR Resource

Cost $$$$$$$$$$$$$$$$$$$$$


고려사항

고려요소 시스템 영향 / 중단시간 최소화 방안

시험운영을통한 검증

• 변경된 사항에 대해 Application 에서 DB 이상 유무 파악

• 충분한 시간을 두고 운영시험과 테스트를 바탕으로 변경사항 검증

업그레이드 시기 및작업시간 결정

• 시험운영을 바탕으로 최종 시스템 업그레이드 이행시기를 결정(업무간 연관성 및 중요도에 따른

우선순위 확정)

• 일정한 기간 동안 트랜잭션이 발생하는 시간대를 분석해 업무 트랜잭션 발생이 낮은 시간으로 작업시간결정

DB동기화를 위한

데이터 전환시간의

예측 및 최소화

• 시험운영 기간 동안 데이터 전환에 걸리는 시간을 분석하여 데이터 전환 시간을 최소화

장애 시 비상계획• 데이터 이행 후 가동 전 테스트를 통해 장애 사항이 발생하면 장애의 원인을 분석하여 중요도에 따라 기존 서버로의 복귀를 결정하여 시스템 중단시간을 최소화

• 기존 9i와 10g를 업그레이드 시점에는 공존, 문제 발생 시 즉각 복귀 가능 환경 마련

최소화업무진행상태

진행상태

시험

운영

고려요소

시험운영을통한 검증

업그레이드 시기,작업시간 결정

데이터 전환 시간예측 및 최소화

장애 시

비상계획

시험 장비 설치

SQL 변경 요소 추출

SQL 변경 / 튜닝

변경사항 시험

어플리케이션점검

시험 업그레이드최종 업그레이드 기동전 테스트 10g 시스템 가동

서비스 중단기존 DB 정상 서비스 신규 DB 정상서비스

기존서버로의 복귀

시스템 시험운영

시스템 모니터링/

최적화

개발 시스템 Copy

업그레이드 이후

완전 백업

시스템 중단 최소화 방안


10g New Feature 적용 : 가용성

• Oracle 10g부터 제공되는 자가관리 데이터베이스 시스템의 여러 방식을 이용하여 이전 수작업으로 진행하던 관리 방식을

중앙에서 자동으로 관리함으로 복잡한 관리 업무를 효율화 할 수 있습니다. DB 관련 전 작업은 Web에서 구현됩니다.

• 데이터 파일 사용량 점검 / Alert• OS Setup 연계 자동 확장

SGA 자동관리

SPACE 자동관리

통계정보자동관리

AWR

EnterpriseManager

자동진단시스템

ErrorError

Mail 경보

SMS 경보

• 메모리 Pool 자동 관리• 메모리 권고자 EM 기록

• 통계정보 업데이트 자동 수행• System/Table 모니터링

Alert System

Error Check

Storage Check

10g New Feature 10g New Feature 적용적용 여부여부 결정결정1.2 업그레이드 세부 계획 수립

Resource Manager

InstanceMonitoring

EnterpriseManager

Mail 경보

SMS 경보

Alert System

CheckCheck

• 모니터링 내역 Setup• Threshold Setup

• Resource 사용 통제• Resource 사용 내역 기록

CPU Monitoring

. 10g New Feature 적용 : 성능관리•Oracle 10g가 제공하는 시스템 모니터링은 9i에서 Command에 의해 Text로 점검하던 방식에서 자동으로 성능 관련 정보를

취합하고 자동진단, Alert 기능을 통해 자동 관리 RDBMS 목적을 달성할 수 있습니다.

임계 값 초과시

1.2 업그레이드 세부 계획 수립 10g New Feature 10g New Feature 적용적용 여부여부 결정결정

10g New Feature 적용 : 보안• Oracle 10g에서 강화된 Audit 기능을 이용하여 Audit에 의해 발생하는 시스템 부하를 최소화 하면서 GISS에서 권고하는모든 유저 활동에 대한 Activity Log를 유지 / 관리 할 수 있으며 보다 강화된 보안 환경이 구축 됩니다.

• Audit Policy 적용AuditService

파일: 2007.10.01~ 10.10

파일: 2007.10.11~ 10.20

파일: 2007.10.21~ 10.30

TSM Backup

• SQL Check• User & Time Check

필요 시 DEV 시스템 내 복구

• 과거 Data Check 시 전체 복구필요 없음

• 신속한 필요 데이터 복구 가능

Script 이용자동 Audit Table

Export

DEV

　 Action


10g New Feature 적용 : Application Support• 9i에서는 제공되지 않았던 DB 성능 모니터링을 통해서 Application DB 의 성능 상태를 확인 할 수 있으며 이는 개발자에게보다 안정되고 신속한 개발 환경을 제공합니다.

Support SQL튜닝

AutomaticWorkloadRepository

EnterpriseManager

• SQL 튜닝 어드바이저: Tuning을 위한 조치사항 제안

• SQL 수행 계획 향상 가능성분석

SQL Tuning Advisor

SQL Performance Check

• 성능 정보 통계 취합


10g New Feature 적용 : 백업 및 복구•10g에서는 장애나 실수로 발생된 Data 손실에 대해 전체 Database 복구 없이 Row 단위, Table 단위로 복구 기능을 제공하여 데이터 복구가 가능하며 RMAN 기능을 이용, 백업과 복구를 수행함으로 빠른 백업 및 복구 환경이 구성됩니다.

FlashBack

RMAN(백업 / 복구)

Data Data DropDrop

Flash Recovery

Area

TSM Backup

EnterpriseManager

Mail 경보

SMS 경보

Alert System

CheckCheck

백업 실패

Data 복구

EM Backup/Recovery Solution


구축구축 일정일정--상세상세: : 환경구성환경구성

환 경구 성

서버 및 S/W 설치 부수장비 설치Oracle Test 환경구축• SKR6K26 10g Test DB Setup• SKR6K13 9i Test DB Setup

M+1 M+2 M+3 M+4

1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4

• SKR6K26(M80)-4WAY, 16GB-EXP320 300G DISK

• EKDB: PORT 1522-IP:192.168.1.106

• ORACLE 10g 10.2.0.3

• SKR6K13(6M2)-4WAY, 16GB-EXP320 300G DISK

• EKDB: PORT 1522-IP:192.168.1.103

• ORACLE 9i 9.6.0.6

• SKR6K66(6M2)-2WAY, 16GB-Shark / 150GB DISK

• EKDB: PORT 1522-IP:192.168.1.106

• ORACLE 9i 9.6.0.6

<Oracle 9i, 10g TEST Servers>

BACKUP

LATEST DATARESTORE

EXPORT/IMPORTTEST 9i / 10g DATA동기화


구축구축 일정일정--상세상세: : 사전분석사전분석사 전 분 석

환경 분석 10g 요구사항 분석(10g SQL 표준화)

현 Application SQL 정의 튜닝 대상 / 목표 정의데이터 분석

•기존/목표 환경 분석•Oracle10g 요구사항 파악•Application SQL 추출: EKDB 1445건•튜닝 대상 및 목표 정의

Target Task-List Attendant Output

10g 요구사항

분석

• Arrangement 9i SQLs Needed to Change On 10g

• Arrangement 10g Compatibility and Interoperabilty Issue

• 10g SQL Standard 개발 Guide 작성

• DBA

• Developer

• 굿어스

• 10g 요구 과제 일람

• SQL 개발 Guide

Application SQL 정의

• 9i Application SQL 추출

- Data-Dictionary 내 V$ Table 추출

- 사용자 단위로 분리 추출( 예: b2cts, b2bts)으로 개발자 할당

- SQL 실행계획 포함 SQL Tuning 대상 선정 용이 제공

• DBA

• Developer • Application SQL 일람

튜닝 대상 정의

• 각 업무 Flow 분석 / SQL 추출

• 업무 단위 별 응답시간 산출

• Top SQL / DB 구조 분석

• System Resource 별 사용현황 분석

• DBA

• Developer

• 굿어스

• 튜닝 대상 SQL / DB

구조 일람

튜닝 목표 정의• 업무 Flow 별 목표 응답 시간 선정

• 시스템 Performance 튜닝 목표 선정

• DBA

• Developer

• 굿어스

• 튜닝 목표 일람

M+1 M+2 M+3 M+4

1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4


구축구축 일정일정--상세상세: : SQL SQL 변경변경 / / 튜닝튜닝 / / 단위시험단위시험 ((계속계속))

SQL 변 경/ 튜 닝

및 단 위

시 험

변경 / 튜닝 SQL 정의

9i SQL Test On 10g 검증 및 보완

Error SQL 변경

단위 시험

변경 결과 적용

결과확인

SQL 튜닝

•SQL 10g 환경 내 시험 / 검증•Error / 변경 요구 SQL 추출 및 변경방법 정의•Error / 변경 요구 SQL 변경(Test 9i)•SQL / DB 튜닝(Test 9i)•10g New Feature 시험 / 확인•변경 SQL / 튜닝단위시험(Test 9i/10g)•검증 결과 보완•DB 튜닝 결과 확인(PRD 9i)•변경 SQL 결과 적용(PRD 9i)

NO

YES

10g New-Feature

적용 / 시험

M+1 M+2 M+3 M+4

1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4


9i SQL TEST

On 10g • Developer

• 변경 SQL 일람

- Error SQL

- Incorrect SQL

9i TEST

10g TEST

Test 결과

Test 결과 변경 필요 SQL정의

　 input

　 output

　 check

　 extract & change

10g 요구 사항 일람

10g SQL 표준안

•Application SQL 일람



• DB 튜닝• DBA

• Developer

• 굿어스

• Tuning 계획

• 10g New

Feature 적용

• Enterprise Manager(10g Add-on Program) 이용한

중앙 통제 / 자동 관리 체계 구축

• 자동진단 (Automatic Diagnostic) ADDM 시스템 구축

• 자동진단 후 Error Alert & Notification 체계 구축

• 개발자에 의한 Application 분석 환경(10g EM) 구축

• 보안 강화: All User Activity Log

• Flash – Time Machine 기능 구현으로 Detailed Row /

Table Recovery 시스템 구현

• RMAN을 통한 시스템 복구 시간 단축 / 자동화

• DBA

• 굿어스

• 10g New-Feature

운영 매뉴얼

9i TEST•튜닝 대상 일람

•튜닝 목표

　 tuning

　 check

• Tuning 계획 (SQL,DB구조)

구축구축 일정일정--상세상세: : SQL SQL 변경변경 / / 튜닝튜닝 / / 단위시험단위시험 ((계속계속))1.2 업그레이드 세부 계획 수립


• 단위

시험 /

적용

• DBA

• Developer

• Security

Officer

• System Change

Request

9i TEST• 튜닝 계획

•변경 SQL 내역서

9i PRD

10g TEST

•각 관계자 / 현업

•Security Officer 승인

　 change

　 applicationtest

　approve

　 application　approve

•System ChangeRequest

구축구축 일정일정--상세상세: : SQL SQL 변경변경 / / 튜닝튜닝 / / 단위시험단위시험 ((계속계속))1.2 업그레이드 세부 계획 수립

업 그 레 이 드

시 험 수 행

통 합 시 험

및

시 험 운 영

Test Upgrade 실시(데이터포함)

운영체계 검증일치성 검증정합성 검증

보완 사항 정의 / 보완

시험운영 결과확인

YES

통합시험 및수정보완

NO

• 업그레이드 시험 수행

•정합성 검증•일치성 검증•DB-Application 운영체계 검증•수정보완•시험운영

M+1 M+2 M+3 M+4

1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4

최 종 이 행

최종 Upgrade 시나리오 작성

최종 Upgrade 및 시스템 가동

•최종 업그레이드 시나리오 작성•최종 업그레이드 환경 구축•최종 업그레이드•10g SQL 튜닝

1.2 업그레이드 세부 계획 수립 구축구축 일정일정--상세상세: : SQL SQL 변경변경 / / 튜닝튜닝 / / 단위시험단위시험 ((계속계속))

“정보시스템 용량산정 기술 및 프레임워크 연구 보고서” [ 한국정보사회진흥원 2007. 07.]“정보시스템 용량산정 기술 및 프레임워크 연구 보고서” [ 한국정보사회진흥원 2007. 07.]

구 분 산 정 근 거

CPU

* 기본 분당 트랜잭션(tpm-C)

* Peak Time 보정율

* 어플리케이션 복잡성 보정율

* 시스템 소프트웨어 부하 보정율

* 확장대비 보정율 - 사용자 및 트랜잭션 증가율을 감안한 여유율 확보

Memory

* 메모리기본 메모리 소요량

- 시스템 영역, 사용자, 상용 소프트웨어 등이 요구하는 메모리 소요량

* 개발 어플리케이션이 요구하는 메모리 소요량

* 향후 사용자 및 트랜잭션 증가율을 감안한 메모리 여유율

* 기타 추가 부하에 따른 메모리 소요량

Disk

* 시스템 및 SWAP 영역의 디스크 사용량

* 화일 시스템 오버헤드를 고려한 디스크 여유분

* 어플리케이션 및 데이터 영역

* 화일 시스템 오버헤드를 고려한 디스크 여유분

* 데이터베이스 오버헤드를 고려한 디스크 여유분

* Array RAID 1+0 방식 적용 시의 디스크 사용분

[ 용량 산정 근거 ]


구 분 산 정 수 식

CPUCPU 용량(tpmC) = 동시사용자 수 * 트랜잭션 수 * 기본 TPC보정치

* Peak Time 보정치 * CPU 부하 보정치 * 응용프로그램 복잡도 보정치 * 네트워크 보정치

* 클러스터 보정치 * 여유율 보정치

Memory

메모리 용량(MB) = {OS 및 기본영역 + 프로세스 수 * 응용 프로그램

보정치} * 버퍼 캐쉬 보정치 * 클러스터 보정치

* 여유율 보정치

+ {데이터베이스 공유 메모리 }

Disk

내장디스크 용량(MB) = {시스템 OS영역 + 응용프로그램 영역

+ 상용 소프트웨어 영역} * SWAP 영역


외장디스크 용량(MB) = {DB영역 + 백업영역} * RAID 영역


[ 용량 산정 근거 ]

“정보시스템 용량산정 기술 및 프레임워크 연구 보고서” [ 한국정보사회진흥원 2007. 07.]“정보시스템 용량산정 기술 및 프레임워크 연구 보고서” [ 한국정보사회진흥원 2007. 07.]


구 분 입력값 범위 일반값 산 정 근 거

동시 사용자 수

- 동시에 발생하는 처리건 수의 30%

- 동시 사용자수는 접속자의 40%

- 접속사용자는 전체 사용자의 70%

트랜잭션 처리수 3(단수) ~ 7개(복잡) - 1명이 1분 동안 발생한 트랜잭션의 수

기본 TPMC보정20%(소규모)

~30%(대규모)

1.2 - 시스템 규모에 따라 보정

Peak Time 보정20%(단순)

~30%(복잡)

1.2 - 업무가 폭주하는 경우 고려하는 보정

데이터베이스

크기보정

표 참조 1.3 - 트랜잭션이 처리하는 데이터 크기

- 트랜잭션이 처리하는 레코드 수

어플리케이션

복잡도 보정

표 참조 1.1 - 프로그램의 복잡한 정도에 따라 적용트랜잭션 종류, 테이블 수

사용자 복잡성 보정표 참조 1 - 접속 사용자 수

- 동시 사용자 수

어플리케이션

구조 보정

표 참조 1 - 요구되는 응답시간(Response Time)

- 어플리케이션 구성 방법(2~3Tier)

어플리케이션

부하 보정

표 참조 1 - BMT가 아닌 실제 사용자 운영 환경 보정

네트워크 보정10 % 1.1 - 네트워크 대역폭으로 인한 지연 보완

클러스터 보정30%(단순)

~50%(복잡)

1 - 클러스터 환경에서 장애 발생시를 위한 보정

여유율 보정20% ~ 50% 1.3 시스템의 안정된 운영을 위한 보정

[ OLTP 용량산정 기준 ]

일반값은 보정률을 최고치, 최저치, 최빈치로 분류하였을 때, 최빈치에 해당하는 값임.일반값은 보정률을 최고치, 최저치, 최빈치로 분류하였을 때, 최빈치에 해당하는 값임.


10.0+8.5+7.0+1000+

8.5+76.25.31000

7.5+6.45.64.84300

5.85.14.43.62.92.21.4100

43.32.621.330

3.632.41.81.210

2.21.71.13

21.511

~300+~300~100~30~10~3~1~0.3DB size

Rows

데이터베이스 크기에 따라 가중치는 DB에 속한 가장 큰 테이블의 레코드 건수와 전체 DB의 볼륨을 고려하여 결정한다. 같은 크기의 DB 경우에는 건수가 많은 쪽이, 같은 건수라면 DB 볼륨이 큰쪽이 큰 가중치를 갖게 되며, 증가량의 비율 건수는 50% 단위 증가로 크기는 10% 증가 단위로 설정하였다. 그러나 실제 업무 시스템에 대한 세부적인 분석을 근거로 정확한 값이 도출되지 않을경우, 가중치의 적용이 어려우므로 용량 산정자는 일반값인 1.3을 적용 한다.

[ 데이터베이스 크기의 가중치 ]


응

용

의

형

태

종 류

분석 작업

복잡 Trx 유형

보통 Trx 유형

단순 Trx 유형

단순갱신

단순검색

35+

5.7+

3.0+

3.0+

2.0+

0.9+

40

3.82.61.7

0.80.70.6

1.51.21

18.0+

2.9

2.2

30

9.0+

2.1

1.7

2010

4.5+

1.5

1.3

비 고테이블 개수

어플리케이션 복잡성 테이블은 어플리케이션 또는 트랜잭션의 성격과 해당 어플리케이션에 관계된 주

요 테이블의 개수에 의한 비중치를 나타낸다. 어플리케이션의 유형은 서로 다른 부하를 주며, 테이블

의 수도 부하에 상당한 영향을 미치게 된다. 특히 분석적인 어플리케이션에 관계된 테이블이 많은 경

우 조인(Join) 등의 부하가 급격히 증가된다. 어플리케이션 복잡성 테이블에 사용된 어플리케이션은

주로 수강신청, 교육수강, 시험 업무를 중심으로 한 것이다. 어플리케이션 복잡성 보정을 위한 구체적

인 수치는 상기 표와 같다. 한편, 정확한 업무 예측은 어렵지만 검색 : 변경을 50:50로 적용하고 배치

와 리포트성 작업의 분석 쿼리를 고려할 때, 4.5+의 보정치를 적용할 수 있다.

[ 어플리케이션 복잡도 보정치 ]


4.5+3.5+3.21000+

3.52.92.62.41000

3.02.42.22500

1.91.71.6300

1.51.31.2100

1.21.1130

접속사용자수

(832명)

5000+500030001000300100비고

전체사용자수(1189.2명)크기

사용자 복잡성 테이블은 접속사용자(Connection Users)와 전체 대상자(Total Users)의 규모에 따른 비

중치를 나타내며 세부적인 적용기준은 다음 표와 같다. 접속 사용자는 해당 어플리케이션을 사용할 수 있

는 사용자를 말하며, 트랜잭션 발생유무에는 관계하지 않는다. 전체 대상자는 프로그램을 이용하는, 즉 업

무를 수행하는 모든 사용자이다. 접속 사용자의 증가에 따라 가중치를 조정하는 것은 새로이 접속 요청을

할 수 있는 가능성을 고려한 것이다. 실제 시스템의 부하 증가는 접속 요청 시에 매우 증가되기 때문이다.

따라서 동일한 접속 사용자 수(832명=1189.2명의 70%) 환경도 접속 가능 사용자의 수에 따라 가중치를

차등 적용하게 된다. 따라서, 이 두 대상자를 고려한 사용자 복잡도 보정치는 2.4를 환산할 수 있다.

[ 사용자 복잡도 보정치 ]


0.50.60.815+

0.6~0.70.7~0.811.1~1.55

0.8~1.10.9~1.21.2~1.51.3~2.33

Database OnlyAppl. Logic 포함Database OnlyAppl. Logic 포함

Direct User ConnectionFront-End Server 사용항목

응답

시간(초)

어플리케이션 구조 보정은 어플리케이션 로직을 동일 서버에 포함하는지의 경우와 요구되는 응답 시간에

따른 비중치를 말한다. Direct User Connection은 2-Tier Client/Server 구성과 같이 DB 업체 또는 표준화

된 DB 접근 미들웨어를 사용하는 것으로 상위의 네트웍 계층에서 동작하므로 부하가 증가한다. Front-

End Server의 사용은 3-Tire Client/Server 구성과 같이 User Connection의 부하를 감소시켜 주며, 특별

한 부하발생 가능성이 적기 때문에 가중치를 1이하로 적용한다. 응답시간은 최종 사용자의 입장에서 본 것

으로 서버와 사용자간의 네트웍 지역을 감안하여 가중치를 조정하도록 한다. WAN이 포함된 환경은 동일

한 응답성을 얻기 위하여는 시스템의 처리가 빨라야 하므로 가중치를 높게 결정해야 한다. 일반적인 응답

시간(3초 이내)과 Application 구성환경을 고려하여 2.3의 보정치를 환산하여 적용할 수 있다.

[ 어플리케이션 구조 보정치 ]


23Heavy

1.52Normal

1.31.7Light Job 내용이 명확한 경우 가중치를

사용하지 않고 파악된 부하량

(tpmC 기준)을 가산

11None

비 고서로 다른 데이터동일한 데이터크기

추가적인 로드 테이블은 온-라인 작업을 수행하는 Peak time에 배치 작업등을 수행하여야 하는

경우의 비중치를 말한다. 정해진 온-라인 업무 외에 부가적인 작업이 처리되는 경우 그에 필요한

처리능력을 보정하는 단계이다. 즉 배치성 업무(리포팅, 백업 등)나 외부시스템을 사용하는 경우

등이 해당된다. 한편, 보정치를 적용하기 어렵거나 개략적인 적용을 수행하고자 하는 경우, 일반

값인 1을 적용할 수 있다. 현 시스템 구성상 Batch Job이 동시에 수행되며, Batch 수행자가 1명

이상인 상황이고, 동일 데이터에 대한 Locking이 발생하고 있으며, OLTP업무에 대한 접근 통제자

이기 때문에 2의 Normal 보정치를 적용할 수 있다.

[ 어플리케이션 부하 보정치 ]


[ OLTP 산정항목 및 보정치 ]

SQL> select * from v$resource_limit; - 최대 접속 유저 333명 을 기준으로 역 산정함.


현 시스템의 최대 접속자 333명을 기준으로 동시 트랜잭션 사용자를 산출하여 적용한 결과 78040.08 tpmC 용량이 산정됨. (이것은 현재 분석된 Undo segment사용기반의 DML 량 80229.13 Txn과 유사한 산출 결과임.)따라서, 현재의 POWER4 1450Mhz CPU를 적용할 경우 4EA(tpmC 85472.8) : 가 필요함.

Target System에 대한 용량산정은 필수 !!

현 시스템의 최대 접속자 333명을 기준으로 동시 트랜잭션 사용자를 산출하여 적용한 결과 78040.08 tpmC 용량이 산정됨. (이것은 현재 분석된 Undo segment사용기반의 DML 량 80229.13 Txn과 유사한 산출 결과임.)따라서, 현재의 POWER4 1450Mhz CPU를 적용할 경우 4EA(tpmC 85472.8) : 가 필요함.

Target System에 대한 용량산정은 필수 !!

[ CPU 용량 산정(최종) ]






1.4 10g Upgrade Manual (사례)첨부1.10g upgrade manual (complete checklist).doc


2.1 ANSI 1999 표준 SQL의 준수

2.2 10g Hash Group By의 적용

2.3 Rule 힌트 쿼리의 처리

2.4 실행계획 변화에 대한 대처 방안

2.5 기타 위험요소들

2.6 Scalar Sub-Query의 유용한 적용

2.7 확장된 DML 및 DDL의 기능

세션 2. Upgrade 시 고려사항 및 SQL NF




2.4 Connect By.. Order siblings 절의 문제

2.5 SQL*Net 프로토콜의 호환문제

2.6 기타 업그레이드 이후 발생하는 문제

2.7 10g SQL New Features

1999 죠인 문법은 다음과 같은 두 가지 이유로 Oracle에서 지원하는 죠인과 다르다.

1999 문법에서는 FROM 절에 죠인의 유형을 명시적으로 표기한다.

죠인 조건은 WHERE 절에서의 검색 조건과 구분되며, ON 절을 이용해서 표기한다.

추가된 죠인 유형은 다음과 같이 5가지로 나뉜다.

CROSS 죠인

NATURAL 죠인

USING 절을 사용한 죠인

전체 또는 양측 OUTER 죠인

OUTER 죠인에 대한 임의 죠인 조건


SQL JOIN :1999 ANSI 표준 규약

CROSS Join

CROSS 죠인은 두 개 테이블 사이의 카텐시안 프로덕트(Cartensian Product)를 생성한다.

문장에 대한 문법은 다음과 같다.

SELECT <column list> FROM <table > CROSS JOIN <table>;

실제 EMP 테이블과 DEPT 테이블에서 CROSS 죠인을 수행하는 SQL문장은다음과 같다.

SQL> SELECT e.ename, e.deptno, d.deptno, d.dname FROM emp e CROSS JOIN dept d;

SQL JOIN :1999


Natural Join

NATURAL 죠인은 같은 이름을 갖는 두개의 테이블의 모든 컬럼에 기반한다.모든 일치하는 컬럼에서 값이 동일한 두개의 테이블의 레코드를 선택한다.같은 이름을 갖는 두개의 테이블이 다른 데이터타입을 가지고 있다면 에러가 발생한다.만약 ‘SELECT * …’ 문장이 사용된다면 질의 결과에서 중복된 컬럼은 한번만 나타난다.테이블 이름 또는 별명(Aliase)은 NATURAL 죠인에서 죠인 컬럼으로 사용될 수 없다.

NATURAL 죠인의 문법은 다음과 같다.SELECT <column_list> FROM <table> NATURAL JOIN <table>;

SQL> SELECT ename, deptno, deptno, dname FROM emp NATURAL JOIN dept;

이 NATURAL 죠인을 Oracle 9i이전에 지원하던 형태로 바꾸면 다음과 같다.SQL> SELECT e.ename, e.deptno, d.deptno, d.dname

FROM emp e, dept dWHERE e.deptno = d.deptno;

SQL> SELECT e.ename, e.deptno, d.deptno, d.dname FROM emp e NATURAL JOIN dept d;

ERROR at line 1:ORA-25155: column used in NATURAL join cannot have qualifier

SQL JOIN :1999


USING 절을 이용한 죠인문 생성하기

NATURAL 죠인의 경우에는 동일한 컬럼이름을 가지고 있는 컬럼이라도 데이터 타입이다를 경우에는 에러를 발생한다.

따라서, 이경우에 이들 컬럼들에 대해서 이퀴-죠인(Equi-Join)을 사용하도록 USING 절에서 명시해주도록 SQL문을 변경할 수 있다.

단, USING 절에서 참조되는 컬럼의 경우에는 SQL문장에서 테이블 명 또는 별명과 같은한정자(Qualifier)를 사용해서는 안되며, NATURAL과 USING절은 같이 사용될 수 없다.

문법은 아래와 같다.

SELECT <column_list> FROM <table_name> JOIN <table_name> USING <column_name>;

SQL> SELECT ename, deptno, dname FROM emp JOIN dept USING(deptno);

SQL JOIN :1999


On 절을 이용한 죠인 생성하기

NATURAL 죠인 조건의 경우 기본적으로 동일한 이름을 갖는 모든 컬럼의 이퀴죠인이지만, 임의의 죠건을 명시하거나 또는 죠인에 대한 컬럼을 명시하는데는 ON 절을 이용하게 된다.

따라서, 다른 필터 조건 예를 들면 WHERE절과 테이블의 죠인 조건을 분리하는 역할을 하게 된다. 또한, 이해하기가 위운 SQL문장을 작성할 수가 있게 된다.

문법은 USING 절을 이용하는 것과 유사하며, 다만 ON을 사용한다는 것이다.

SELECT <column_list> FROM <table_name1> JOIN <table_name2> ON <join_condition>

JOIN <table_name3> ON <join_condition> JOIN ….;

예를 들어, EMP란 테이블과 DEPT란 테이블의 죠인 컬럼이름이 각각 emp_deptno와 deptno와 같이상이 한 경우에는 USING 절이나 NATURAL죠인을 이용할 수 없게 되므로, 이경우에 ON절을 이용해서 SQL문을 작성하는 예와 결과는 다음과 같다.

SQL> SELECT e.ename, e.emp_dept, d.deptno, d.dname FROM temp_emp e JOIN temp_dept d ON (e.emp_deptno = d.deptno) ;

SQL JOIN :1999


A AAB 111B AAC 123C ABA 222 D ABB 233E ABC 143

A 10 AAB 10 ABC 10 AC

OOOOO

OOOXX

TAB1 TAB2

A AAB 111 A 10 AA

B AAC 123 B 10 ABC ABA 222 C 10 ACD ABB 233E ABC 143

원하는 결과

KEY FLD1 FLD2 KEY COL1 COL2

SQL JOIN :1999 (Outer Join의 정확한 의미)

SELECT X.KEY, X.FLD1, X.FLD2, Y.KEY, Y.COL1, Y.COL2

FROM TAB1 X, TAB2 YWHERE X.KEY = Y.KEY(+)AND X.FLD1 > 'AAA'AND Y.COL1 = 10 ;


FROM TAB1 X, TAB2 YWHERE X.KEY = Y.KEY(+)AND X.FLD1 > 'AAA'AND (Y.COL1 = 10 OR

Y.COL1 IS NULL);


FROM TAB1 X, TAB2 YWHERE X.KEY = Y.KEY(+)AND X.FLD1 > 'AAA'AND Y.COL1(+) = 10 ;

(Inner Table)(Outer Table)

OUTER 조인이 가진 기능은 조인된 로우 중에서 상대방의 컬럼 값이 NULL 이라 할지라도 이를 TRUE로 인정하여 해당 로우를 걸러내지 않도록 하는 것이다.

조인되는 두 컬럼 중에 모든 데이터를 표시하고 싶은 쪽은 그대로 두고 데이터가 부족한 쪽의 컬럼에 (+) 기호를 붙인다.

(기준 테이블이 어느 쪽이냐?)


INNER 대 OUTER 죠인

NATURAL 죠인과 같은 INNER 죠인의 경우에는 매치되는 레코들만을 얻게 되지만, 매치되는레코드 뿐 만 아니라, 매치되지 않는 레코드까지는 얻는 것이 OUTER 죠인이다.

또한 좌 OUTER 죠인과 우(RIGHT) OUTER 죠인을 모두 적용한 FULL OUTER 죠인을 지원한다.먼저 좌(LEFT) OUTER 죠인의 문법은 다음과 같다.

SELECT <column_list> FROM <table_name1> LFET OUTER JOIN <table_name2> ON <join_condition>;

예를 들어, EMP 테이블과 DEPTNO를 LEFT OUTER죠인을 하는 SQL문을 실행한 결과는 다음과같다.

SQL> SELECT e.ename, e.emp_deptno, d.deptno, d.dname FROM emp e LEFT OUTER JOIN dept d ON (e.emp_deptno = d.deptno);

위의 결과문을 Oracle 9i이전의 SQL문으로 작성한다면 아래와 같은 SQL문이 된다.

SQL> SELECT e.ename, e.emp_deptno, d.deptno, d.dname FROM emp e , dept d

WHERE e.emp_deptno = d.deptno(+);

SQL JOIN :1999 기존의 outer join 문법(+) 은 10g에서 실행되지 않을 수 있음. (특히, 서브쿼리 내에서)


RIGHT OUTER 죠인SQL> SELECT e.ename, e.emp_deptno, d.deptno, d.dname

FROM emp e RIGHT OUTER JOIN dept d ON (e.emp_deptno = d.deptno);

(Oracle 9i이전의 SQL문)SQL > SELECT e.ename, e.emp_deptno, d.deptno, d.dname

FROM emp e ,dept dWHERE e.emp_deptno(+) = d.deptno;

FULL OUTER 죠인SQL> SELECT e.ename, e.emp_deptno, d.deptno, d.dname

FROM emp e FULL OUTER JOIN dept d ON (e.emp_deptno = d.deptno);

(Oracle 9i이전의 SQL문)SQL> SELECT e.ename, e.emp_deptno, d.deptno, d.dname

FROM emp e , dept d WHERE e.emp_deptno = d.deptno(+)UNIONSELECT e.ename, e.emp_deptno, d.deptno, d.dname FROM emp e , dept d

WHERE e.emp_deptno(+) = d.dep

SQL JOIN :1999


복합 죠인 생성하기

ON 절에 서브 질의문, AND/OR, [NOT]EXISTS와 [NOT] IN을 이용하여 좀 더 복잡한 형태의 질의문을 생성할 수 있다.

현재 보너스를 지급하고 있는 사원에 대해서 사원이름과, 부서번호, 부서명을 출력하는SQL문과 결과는 다음과 같다.

SQL> SELECT e.ename , e.deptno, d.deptno, d.dname

FROM emp e JOIN dept d

ON (e.deptno = d.deptno)

AND e.ename IN (SELECT ename FROM bonus);

SQL JOIN :1999


ENAME DEPTNO DEPTNO DNAME---------- ---------- ---------- --------------ALLEN 30 30 SALESWARD 30 30 SALESMARTIN 30 30 SALESBLAKE 30 30 SALESTURNER 30 30 SALESJAMES 30 30 SALES

6 rows selected.

Execution Plan----------------------------------------------------

0 SELECT STATEMENT Optimizer=CHOOSE1 0 TABLE ACCESS (BY INDEX ROWID) OF 'DEPT'2 1 NESTED LOOPS3 2 TABLE ACCESS (BY INDEX ROWID) OF 'EMP'4 3 INDEX (RANGE SCAN) OF 'EMP_DEPTNO_IDX' (NON-UNIQUE)5 2 INDEX (RANGE SCAN) OF 'DEPT_DEPTNO_IDX' (NON-UNIQUE)

SQL> SELECT e.ename , e.deptno, d.deptno, d.dname

FROM emp e, dept d WHERE e.deptno = d.deptnoAND e.deptno = 30;

SQL> SELECT e.ename , e.deptno,d.deptno, d.dname

FROM emp e JOIN dept d ON (e.deptno = d.deptno)

WHERE e.deptno = 30;

SQL JOIN :1999 (구문 비교)

FROM 절에는 Join에 관련된 내용들을 명시적으로 기술한다. (Table 명, 조인방법, 연결조건 등)

WHERE 절에는 순수하게 집합의 범위를 줄이는 조건, 즉, Predicates (Non-Join 조건)만을 기술한다. 실제로 ANSI 표준에서는 WHERE절 대신 AND를 이용하여 표시하는것을 권장하지만, WHERE절을 이용하여 명시적으로 집합의 범위를 줄이는 조건임을인지하는 것도 가능하다.


CASE 표현식에서 스칼라 서브질의 사용하기

스칼라 서브 질의들은 DECODE와 CASE 표현식들에 대한 표현의 일부와 조건에 모두 사용될 수 있다.

예를 들어, EMP 테이블의 사원 중에 BONUS 테이블에 등록된 사원의 이름을 검색하는 SQL문은 다음과 같다.

SQL> SELECT ename, sal,(CASE WHEN ename IN (SELECT ename FROM bonus)

THEN 'Paid'END) AS paid_status

FROM emp;

스칼라 서브질의(Scalar Subqueries)


함수에서 스칼라 서브질의 사용하기스칼라 서브질의는 Oracle에서 제공하는 함수, 사용자 정의 함수와 타입 생성자에서 입력 인자

로 사용될 수 있다.

SQL> SELECT empno, SUBSTR((select b.ename from bonus b where e.ename = b.ename),1,3)AS ename, sal

FROM emp;


SELECT 리스트에서 스칼라 서브 질의 사용하기

Oracle 9i에서부터 SELECT 절에 스칼라 서브질의를 지원한다.

예를 들어, EMP 테이블과 DEPT 테이블에 대해서 ename, empno, dname을 SELECT절에서스칼라 서브질의를 사용하여 얻는 SQL문과 결과는 다음과 같다.

SQL> SELECT e.ename, e.empno, (SELECT d.dname FROM dept d deptno = e.deptno) AS dname

FROM emp e;


WHERE 절에서 스칼라 서블 질의 사용하기

Oracle 9i의 SQL에서는 또한 WHERE 절에서 스칼라 서브 질의를 사용할 수 있다.

SQL> SELECT e.ename, e.empno, e.deptnoFROM emp e

WHERE (( SELECT b.ename FROM bonus b WHERE b.ename = e.ename)IN (SELECT ename FROM emp));


ORDER BY절에서 스칼라 서브 질의 사용하기

Oracle 9i의 SQL에서는 정렬을 명시하는 ORDER BY절에서 스칼라 서브질의를 사용 가능.

EMP테이블에서 선택한 결과를 DEPT 테이블의 dname으로 정렬하는 예.

SQL> SELECT e.ename, e.empnoFROM emp e

ORDER BY (SELECT d.dname FROM dept d WHERE e.deptno = d.deptno);


명시적 기본값을 사용하는 것은 컬럼 기본 값을 요구하는 곳에서 DEFAULT 를 사용할 수 있는 것으로SQL 1999에 순응한다.

DEFAULT가 사용되는 두 가지 유형은 다음과 같다.

삽입문장(INSERT )

갱신문장(UPDATE)

바인드 변수

명시적 기본값을 사용하는 예는 아래와 같다.

INSERT INTO emp(empno, ename, deptno) VALUES (1000,’Mike’, DEFAULT);

UPDATE emp SET deptno = DEFAULT WHERE ename = ‘Mike’;

INSERT INTO emp(empno, ename, deptno) VALUES (1000, ’Dura’, :deptno_var);

만약 테이블을 생성할 때 컬럼의 DEFAULT 값을 설정하지 않았다면 널(NULL)이 들어가게 된다.

명시적 기본 값의 장접은 좀 더 나은 데이터의 무결성을 제공하며, 응용프그램을 작성할 때 “hard coding”을 피할 수 있다. 또한 사용자에게 보다 친숙하고 유연한 인터페이스를 제공한다.

명시적 기본값(Explict Defaults)에 대한 개요


Oracle 10g R2부터 Group By절에 의한 Grouping Column순으로 Sorting되지 않는 문제에대한 접근 방식입니다. 기존의 고객이 Order by를 사용하지 않고 Group By만을 사용하였다면문제를 제기할 수 있을 것입니다. 이러한 문제에 대한 대처방식입니다.

Oracle 10g R2 New Feature - New in-Memory Sort Algorithm 이란?

1. 새로운 sort 적용 방식- 기존에는 Sort알고리즘으로 Sort하였으나 10g R2부터는 "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로 내려가면 속도는 매우 느려짐)

Group By절에 의한 Grouping Column순으로 Sorting되지 않는 문제

(Oracle 10g R2부터)


1. 기존 Sorting 알고리즘(<=10g R1)은 Sort방식을 사용하므로 "GROUP BY"절을 사용할 경우Grouping절로 Ordering된 결과를 Display했음. (물론 Parallel등의 처리일 경우는 다름)

SQL> select deptno,count(*) from emp group by deptno;DEPTNO COUNT(*)

---------- ----------10 3 <<<<< DISPLAY값이 Grouping Column순으로 나옴.20 530 6

| Id | Operation | Name |----------------------------------------| 0 | SELECT STATEMENT | || 1 | SORT GROUP BY | | <<<<<<<<<<<<<<<<<<<< Sort Operation이 나왔음| 2 | TABLE ACCESS FULL | EMP |

Statistics----------------------------------------------------------

1 recursive calls0 db block gets7 consistent gets6 physical reads0 redo size

523 bytes sent via SQL*Net to client385 bytes received via SQL*Net from client

2 SQL*Net roundtrips to/from client1 sorts (memory) <<<<<<<<<<<<<<<<<<<< Sort Operation이 나왔음0 sorts (disk)3 rows processed

New in-Memory Sort Algorithm 의 문제점?


2. 10g R2부터는 Sorting 알고리즘이 HASH방식을 사용. 그러므로 "GROUP BY"절을 사용할경우 Grouping절로 Ordering된 결과를 Display못 할 수도 있음. (거의 대부분 못함)

SQL> select deptno,count(*) from emp group by deptno;DEPTNO COUNT(*)

---------- ----------30 6 <<<<< DISPLAY값이 Grouping Column순으로 나오지 않음.20 510 3

| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |---------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 3 | 9 | 4 (25) | 00:00:01 || 1 | HASH GROUP BY | | 3 | 9 | 4 (25) | 00:00:01 | | 2 | TABLE ACCESS FULL| EMP | 14 | 42 | 3 | (0) | 00:00:01 |

Statistics----------------------------------------------------------


523 bytes sent via SQL*Net to client385 bytes received via SQL*Net from client

2 SQL*Net roundtrips to/from client0 sorts (memory) <<<<<<<<<<<<<<<<<<<< Sort Operation이 사용되지 않음.0 sorts (disk)3 rows processed

New in-Memory Sort Algorithm 의 문제점?


1. Optimizer Mode가 RULE일 경우는 발생 안함.2. OPTIMIZER_FEATURES_ENABLE를 10.1 로 함3. init.ora "_gby_hash_aggregation_enabled"=FALSE (New방식 사용 안함)

위의 방식 중 3번이 해당 기능 만 막으므로 가장 많이 사용될 것임.

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

SQL> set autotrace onSQL> alter session set "_gby_hash_aggregation_enabled"=FALSE

Session altered.SQL> select deptno,count(*) from emp group by deptno;

DEPTNO COUNT(*)---------- ----------

10 320 530 6

Execution Plan----------------------------------------------------------Plan hash value: 15469362

| Id | Operation | Name |-----------------------------------| 0 | SELECT STATEMENT | || 1 | SORT GROUP BY | || 2 | TABLE ACCESS FULL | EMP |

New in-Memory Sort Algorithm 의 문제점인 "GROUP BY"를기존 방식으로 사용하기 위해서는?


1. 따라서, /*+ RULE */ 힌트 처리된 SQL에 대해서는 10g 테스트 서버에서

의도한 플랜으로 실행계획이 풀리는 지를 확인하여야 하며

2. 만일, 의도한 대로 풀리지 않을 경우 튜닝을 통하여 최적화 시켜야 함.

(대부분의 경우 10g에서 /*+ RULE */ 힌트를 제거한 경우 이전보다 개선되는 경우가

90% 이상임)

3. 10g에서 /*+ RULE */ 힌트를 그대로 사용할 경우의 문제점은 CBO가 만들어 낼 수 있는

최상의 Access Path를 고려하지 못한다는 것임.

4. /*+ RULE */ 힌트를 제거한 후 CBO가 스스로 만들어 낸 PLAN이 더 나빠지는 경우는

10 g 버전에 맞는 힌트를 적용하거나, 새로운 Access Path를 제공하여야 함.

• 실제로 10.2.0.3.0 PatchSet을 적용하는 경우 기존의 Rule 힌트에 의하여 유지 되어 왔던

Plan은 그대로 유지되는 가능성이 높아졌음.

10g New Version에서는 기존 버전에서 /*+ RULE */ 로 힌트 처리된 구문이의도대로 처리되지 않고, CBO의 장점을 활용할 수 없는 상황이 발생함.

2.3 RULE 힌트 쿼리의 처리











2.4 Connect By.. Order Siblings By절의 문제




특히, order siblings by 절이 사용된 쿼리의 경우 제대로 소트되지 않는 문제가 있음.

(V9I) Oracle 9i의 Hierarchical query의 ORDER SIBLINGS BY CLAUSE

PURPOSE : Oracle 9i의 NF, ORDER SIBLINGS BY 절을 Hierarchical query에 사용하는 예를 통하여 특정 컬럼을 기준으로 Ordering된형태로 display하는 방법을 보여준다.

Explanation : Hierarchical query를 구현할 때 ORDER BY 절을 사용하는 것은 Oracle 7.1 버젼부터 가능한 것이었다. 그러나, 순서대로 ordering되지 않고 특정 컬럼(emp table의 ename)을 기준으로 ordering하기를 원한다면 <Bulletin:10373>처럼procedure를 작성하여야만 하였다. 9i 에서는 ORDER BY 절 대신에 ORDER SIBLINGS BY 절을 사용하여 바로 정렬할 수 있다.

1)Ordering 하기 전의 emp table의 Hierarchical query

SQL> select rpad(' ', LEVEL*5) || ename "ename", empno, mgr, job from emp start with job='PRESIDENT’ connect by prior empno=mgr;

ename EMPNO MGR JOB------------------------- ------ ------ ---------------

KING 7839 PRESIDENTJONES 7566 7839 MANAGER

SCOTT 7788 7566 ANALYSTADAMS 7876 7788 CLERK

FORD 7902 7566 ANALYSTSMITH 7369 7902 CLERK

BLAKE 7698 7839 MANAGERALLEN 7499 7698 SALESMANWARD 7521 7698 SALESMANMARTIN 7654 7698 SALESMANTURNER 7844 7698 SALESMANJAMES 7900 7698 CLERK

CLARK 7782 7839 MANAGERMILLER 7934 7782 CLERK

14 rows selected.

10g New Version에서는 기존 버전(9i 이전 버전) 에서 사용하는 connect by 절이 제대로 실행되지 않을 수 있음.


2) 9i의 new feature인 Hierarchical query를 사용하여 Ordering한 경우

SQL> col ename format a25SQL> select rpad(' ', LEVEL*5) || ename "ename", empno, mgr, job

from empstart with job='PRESIDENT'connect by prior empno=mgr

order siblings by ename;

ename EMPNO MGR JOB------------------------- ------ ------ ---------------

KING 7839 PRESIDENTBLAKE 7698 7839 MANAGER

ALLEN 7499 7698 SALESMANJAMES 7900 7698 CLERKMARTIN 7654 7698 SALESMANTURNER 7844 7698 SALESMANWARD 7521 7698 SALESMAN

CLARK 7782 7839 MANAGERMILLER 7934 7782 CLERK

JONES 7566 7839 MANAGERFORD 7902 7566 ANALYST

SMITH 7369 7902 CLERKSCOTT 7788 7566 ANALYST

ADAMS 7876 7788 CLERK14 rows selected.



SQL> SELECT LPAD (' ', LEVEL * 2,'*'),E.EMPNO,E.MGR,E.DEPTNO,E.JOB,LEVEL,SUM ( E.SAL ) OVER ( PARTITION BY E.DEPTNO ) SAL_OVER_DEPT

FROM EMP ESTART WITH MGR IS NULLCONNECT BY PRIOR EMPNO = MGRORDER SIBLINGS BY EMPNO

/ORDER SIBLINGS BY EMPNO*ERROR at line 11:ORA-30929: ORDER SIBLINGS BY clause not allowed here



SQL> SELECT LPAD (' ', LV * 2,'*'),EMPNO,MGR,DEPTNO,JOB,LV,SUM ( SAL ) OVER ( PARTITION BY DEPTNO ) SAL_OVER_DEPT

FROM ( SELECT ROWNUM RN, LEVEL LV, E.* FROM EMP ESTART WITH MGR IS NULL

CONNECT BY PRIOR EMPNO = MGRORDER SIBLINGS BY EMPNO

)ORDER BY RN/

LPAD('',LV*2,'*') EMPNO MGR DEPTNO JOB LV SAL_OVER_DEPT-------------------- ---------- ---------- ---------- --------- ---------- -------------* 7839 10 PRESIDENT 1 8750*** 7566 7839 20 MANAGER 2 10875***** 7788 7566 20 ANALYST 3 10875******* 7876 7788 20 CLERK 4 10875***** 7902 7566 20 ANALYST 3 10875******* 7369 7902 20 CLERK 4 10875*** 7698 7839 30 MANAGER 2 9400***** 7499 7698 30 SALESMAN 3 9400***** 7521 7698 30 SALESMAN 3 9400***** 7654 7698 30 SALESMAN 3 9400***** 7844 7698 30 SALESMAN 3 9400***** 7900 7698 30 CLERK 3 9400*** 7782 7839 10 MANAGER 2 8750***** 7934 7782 10 CLERK 3 8750

14 rows selected.

10g New Version에서는 connect by 절이 있는 쿼리 블록을 Sub-Query로 처리하면 의도했던 대로 실행됨.


Oracle 10g 로 업그레이드 후 SQL*NET 지원 문제

[ Client / Server / Interoperability Support Between Different Oracle Versions ]

참조 : Metalink 문서 ID : 207303.1


https://metalink.oracle.com/help/korean/Search/search.html#file

https://metalink.oracle.com/help/korean/Search/search.html#file

Oracle 10g 로 업그레이드 후 Objects 가 이유없이 disable 되는 Toad 버전 문제

1. 10g (10.2.0.2.0) 이상 버전으로 업그레이드 한 후 개발자들이 TOAD 8.6.0 이전버전을

사용하는 경우 위 문제가 발생함.

2. Toad 에서 schema browser를 이용하여 procedure, function, view .. 등의 객체를 클릭하거나, 상태를 확인하려고 하는 경우 자동으로 해당 객체가 invalid 상태로 빠져서disable 되는 문제가 발생함.

3. 이 경우 Toad 버전을 8.6.1 이상의 버전으로 업그레이드해야만 해당 문제가 해결됨.

When Oracle patched version 10.2.0.1 with version 10.2.0.2 the structure of the ALL_ARGUMENTS view changed, causing Toad 8.6.0 or earlier to state: "IN" is not a valid integer value when selecting procedures in the Schema Browser or loading them into the Procedure Editor. Toad 8.6.1 remedies this problem.


INSERT...SELECT 문을 단일 DML 문에 포함시키면 여러 테이블에 행을 삽입할

수 있습니다.

다중 테이블 INSERT 문을 데이터 웨어하우징 시스템에 사용하면 운용 중인 하

나 이상의 소스에서 대상 테이블 집합으로 데이터를 전송할 수 있습니다.

다음을 비교해 보면 이 기능이 제공하는 성능 향상 효과를 확인할 수 있습니

다.

•단일 DML과 다중 INSERT...SELECT 문의 비교

•단일 DML과 IF...THEN 구문을 사용한 다중 삽입 절차의 비교

Oracle9i에서는 다음과 같은 유형의 다중 테이블 INSERT 문을 사용할 수 있습

니다.

무조건 INSERT

조건 ALL INSERT

조건 FIRST INSERT

피벗 INSERT

다중 테이블 INSERT 문 개요


EMPLOYEES 테이블에서 EMPLOYEE_ID가 200보다 큰 사원의

EMPLOYEE_ID, HIRE_DATE, SALARY 및 MANAGER_ID 값을 선택합

니다.

다중 테이블 INSERT를 사용하여 이 값을 SAL_HISTORY 및

MGR_HISTORY 테이블에 삽입합니다.INSERT ALL

INTO sal_history VALUES(EMPID,HIREDATE,SAL)INTO mgr_history VALUES(EMPID,MGR,SAL)SELECT employee_id EMPID, hire_date HIREDATE,

salary SAL, manager_id MGR FROM employeesWHERE employee_id > 200;

8 rows created.8 rows created.

무조건 INSERT ALL


EMPLOYEES 테이블에서 EMPLOYEE_ID가 200보다 큰 사원의

EMPLOYEE_ID, HIRE_DATE, SALARY 및 MANAGER_ID 값을 선

택.

SALARY가 $10,000보다 많으면 조건 다중 테이블 INSERT 문을

사용하여 SAL_HISTORY 테이블에 이 값을 삽입.

MANAGER_ID가 200보다 크면 조건 다중 테이블 INSERT 문을 사

용하여 MGR_HISTORY 테이블에 이 값을 삽입.

조건 INSERT ALL

INSERT ALLWHEN SAL > 10000 THENINTO sal_history VALUES(EMPID,HIREDATE,SAL)

WHEN MGR > 200 THEN INTO mgr_history VALUES(EMPID,MGR,SAL) SELECT employee_id EMPID,hire_date HIREDATE,

salary SAL, manager_id MGR FROM employeesWHERE employee_id > 200;



EMPLOYEES 테이블에서 DEPARTMENT_ID, SUM(SALARY) 및

MAX(HIRE_DATE)를 선택합니다.

SUM(SALARY)가 $25,000보다 많으면 조건 FIRST 다중 테이블 INSERT를사용하여 SPECIAL_SAL에 이 값을 삽입합니다.

첫번째 WHEN 절이 참이면 이 행에 대해서 이후의 WHEN 절을 건너뜁니다.

첫번째 WHEN 조건을 만족하지 않는 행은 조건 다중 테이블 INSERT를 사

용하여 HIRE_DATE 열의 값에 따라 HIREDATE_HISTORY_00, HIREDATE_HISTORY_99 또는 HIREDATE_HISTORY 테이블에 삽입합니다.

조건 FIRST INSERT


INSERT FIRSTWHEN SAL > 25000 THENINTO special_sal VALUES(DEPTID, SAL)

WHEN HIREDATE like ('%00%') THENINTO hiredate_history_00 VALUES(DEPTID,HIREDATE)

WHEN HIREDATE like ('%99%') THENINTO hiredate_history_99 VALUES(DEPTID, HIREDATE)

ELSEINTO hiredate_history VALUES(DEPTID, HIREDATE)SELECT department_id DEPTID, SUM(salary) SAL,

MAX(hire_date) HIREDATEFROM employeesGROUP BY department_id;


조건 FIRST INSERT


비관계형 데이터베이스 테이블 SALES_SOURCE_DATA에서 다음

형식으로 판매 레코드 집합을 받았다고 가정합니다.

EMPLOYEE_ID, WEEK_ID, SALES_MON, SALES_TUE, SALES_WED, SALES_THUR, SALES_FRI

이 레코드를 다음과 같이 일반적인 관계형 형식으로

SALES_INFO 테이블에 저장하려고 합니다.

EMPLOYEE_ID, WEEK, SALES

피벗 INSERT를 사용하면 비관계형 데이터베이스 테이블의 판매

레코드 집합을 관계형 형식으로 변환할 수 있습니다.

피벗 INSERT


INSERT ALLINTO sales_info VALUES (employee_id,week_id,sales_MON)INTO sales_info VALUES (employee_id,week_id,sales_TUE)INTO sales_info VALUES (employee_id,week_id,sales_WED)INTO sales_info VALUES (employee_id,week_id,sales_THUR)INTO sales_info VALUES (employee_id,week_id, sales_FRI)SELECT EMPLOYEE_ID, week_id, sales_MON, sales_TUE,

sales_WED, sales_THUR,sales_FRI FROM sales_source_data;


피벗 INSERT


Conditional UPDATE and INSERT Statements

MERGEINTO product_change pc -- destination table 1 USING products p -- source/delta table ON (p.prod_id = pc.prod_id) -- join conditionWHEN MATCHED THEN UPDATE -- update if joinSET pc.prod_new_price = p.prod_list_priceWHERE p.prod_status <> 'obsolete'

WHEN NOT MATCHED THEN -- insert if not joinINSERT (pc.prod_new_price)VALUES (p.prod_list_price)WHERE p.prod_status <> 'obsolete';


Optional DELETE Clause

MERGEINTO product_change pc -- destination table 1USING products p -- source/delta tableON (pc.prod_id = p.prod_id) -- join conditionWHEN MATCHED THEN UPDATE -- update if joinSET pc.prod_new_price = p.prod_list_price ,

pc.prod_new_status = p.prod_status DELETE WHERE (pc.prod_new_status = 'obsolete')

WHEN NOT MATCHED THEN -- insert if not joinINSERT (pc.prod_id, pc.prod_new_price,

pc.prod_new_status)VALUES(p.prod_id, p.prod_list_price,

p.prod_status)


일반 함수

이들 함수에는 모든 데이터 유형을 사용할 수 있으며 널도 사용할

수

있습니다. (ANSI 1999 표준에 의하여 추가된 기능)

NVL (expr1, expr2)

NVL2 (expr1, expr2, expr3)

NULLIF (expr1, expr2)

COALESCE (expr1, expr2, ..., exprn)

LNNVL (expr1)


SELECT last_name, salary, commission_pct,NVL2(commission_pct,

'SAL+COMM', 'SAL') incomeFROM employees WHERE department_id IN (50, 80);

NVL2 함수 사용

1 2

12


SELECT first_name, LENGTH(first_name) "expr1", last_name, LENGTH(last_name) "expr2",NULLIF(LENGTH(first_name), LENGTH(last_name)) result

FROM employees;

NULLIF 함수 사용

…

1

23

1 2 3


SELECT last_name,COALESCE(commission_pct, salary, 10) comm

FROM employeesORDER BY commission_pct;

COALESCE 함수 사용

…

COALESCE 함수가 NVL 함수보다 좋은 점은 여러 대체 값을 사용할 수 있다는 점입

니다.

첫번째 표현식이 널이 아닌 경우 해당 표현식을 반환

하며, 널인 경우에는 나머지 표현식에 대해 COALESCE 함수를 적용합니다.


1. emp 테이블에서 commission 이 500 보다 작은 사람들의 수를 계산한다.

SQL> SELECT COUNT (*) FROM emp WHERE comm < 500COUNT(*)

----------2

2. 하지만, commission 을 못받는 사람을 포함해서(comm is null),commissin 이 500 보다 작은 사람들의 수를 계산하기 위해서는아래와 같이 LNNVL 함수를 쓴다.

SQL> SELECT COUNT (*) FROM emp WHERE LNNVL(comm >= 500)

COUNT(*)----------

12

LNNVL 함수 사용LNNVL 함수가 LNNVL 함수는, 조건식에 주어지는 항의 한쪽 혹은 양쪽에 NULL 값이 나타날 경

우에, 조건식을 평가하는 간결한 방법을 제공한다. LNNVL 함수는 where 절에만 사용할 수 있다.

LNNVL 함수는 조건식을 파라미터로 가지며, 조건식이 FALSE 나 UNKNOWN 일 경우에 TRUE 를 반

환하고, 조건식이 TRUE 일 경우에 FALSE 를 반환한다. LNNVL 함수는 잠재적으로 NULL 값이 나

올 수 있는 상황에서 NULL 값을 처리하기 위해 사용할 수 있다.


세션 3. 10g CBO의 이해 및 통계관리

3.1 CBO 환경에서의 튜닝 방향

3.2 Cost Based Optimizer의 작동원리

3.3 통계정보의 수집 및 관리

3.4 통계정보 관리를 통한 튜닝 사례

3.5 Clustering Factor 개선을 통한 튜닝 사례

3.6 10g CBO 환경에서의 튜닝 사례

왜 우리는 CBO의 작동원리를 알아야 하는가?

OPTIMIZER가 아주 잘못된 실행계획을 생성하여 어떤 문제가발생했을 때, 그 문제를 제대로 파악하고 올바른 해결책을제시하기 위함이다. !

SQL에 몇 개의 힌트를 추가하거나 쿼리문을 일부 다시 작성하여당장의 문제를 해결할 수는 있지만 그런 접근법을 사용하게 되면여기 저기서 동일한 방식의 조치를 취해야 한다.

반면에 CBO의 근본적인 동작을 교정하면 한 번 조치로 문제가발생하는 모든 경우를 해결할 수 있다.

-- Jonathan Lewis [Cost-Based Oracle Fundamentals]


CBO가 고민하는 영역

1.Selectivity and Cardinality2.Access Path3.Join

1.Table Scan2.Selectivity의 계산 방법

3.B-tree Index4.Bitmap Index5.Clustering Factor6.Histogram7.Query Rewrite8.Joint method9.Join Order10. 10053 Trace


진정한 튜닝 전문가는..

스스로 튜닝을 잘하기 이전에 OPTIMIZER가 그 능력을 최대한발휘할 수 있도록 환경을 조성해 주는 조력자가 되어야 한다.

어떤 쿼리를 어떤 힌트를 사용하면 문제를 즉시 해결할 수있다는 식의 접근 방법보다는 당장 100점은 아닐지라도, OPTIMIZER가 평균 90점 수준으로 문제를 해결할 수 있도록 우선환경을 조성하고, 부족한 10%는 필요에 따라 사용자가 채울 수있도록 하는 전략이 필요하다.


COST 란 무엇인가? ..

OPTIMIZER가 SQL 구문이 수행되는 데 소요될 최적의 시간을추정하여 하나의 수치로 표현한 것.

CBO는 GIGO 다!!

CBO 가 범하는 오류의 6가지 주요 원인1. 비용모델이 몇 가지 잘못된 가정을 포함하고 있다. bug 성

2. 데이터 분포에 대한 통계정보가 있기는 하지만, 잘못 이해될 수 있다.

3. 데이터 분포에 대한 통계정보가 없다.4. 하드웨어 성능 특성을 모른다.5. 현재의 작업 부하를 모른다.6. 실행 코드 안에 버그가 있다.


Select ….. From emp where…..

Parser

Query Rewriter

(Transformer)

PlanGeneratorEstimator

Cost Model:cost,

selectivity,cardinality

Row SourceGeneratorData

Dictionary

SQLExecution

Query Optimizer

Join order

Best PlanEstimate

SQL Query

Parsed Query

Transformed Query

CBO (Cost Base Optimizer)


1. Parsing 단계

파싱(parsing) 단계는 SQL 구문(syntax)와 의미(semantics) 검사를 수행한다. 예를 들어, SQL 구문이 정확한 지를 검사하고, 참조된 테이블에대해 사용자의 접근권한 등을 검사한다. SQL 문장은 파싱트리(parsing tree) 형태로 변형되어옵티마이저에게 넘겨진다.

2. 옵티마이져(Query Optimizer)

위 그림에서 점선형태의 사각형으로 표시된 부분이 옵티마이져의 주요 구성요소를 보여주고있는데, 각 구성요소의 역할은 아래와 같다.

3.질의 변환(Query Rewriter)질의 변환(Query Rewriter 또는 Transformer) 단계는 파싱 트리(Parsed Tree)를 받아들여서질의 변환을 수행한다. 더 나은 실행계획을 찾을 수 있는 SQL 문으로 변환함으로써 질의의 수행 처리 속도를 높이는 데, 그 목적이 있다.

4. 실행계획 생성(Plan Generator)와 Estimator오라클 옵티마이져는 실행계획 생성과 비용산정 모듈을 수행하기 앞서, 질의에서 사용된 모든 테이블들과 각 테이블에 정의된 인덱스들에관한 기본적인 통계정보들(예를들면, 테이블의블록 개수, 로우 평균 길이, 인덱스의 높이, 인덱스 리프 블록의 수 등..)과 각 테이블에 대한 다양한 액세스 경로(예를 들면, Full table scan, index scan 등..)에 대한 비용 정보를 미리 마련하여, Cost Model을 준비하고 있다. 이러한 일련의 정보를 바탕으로 옵티마이져는최적의 실행 계획을 생성하여 “Best Query Plan”을 작성한다.

Costing 개념의 진화

8i 옵티마이저는 단순히 I/O 서브시스템에 대한 요청 횟수를 추정하고, 가장 적은요청횟수를 요구하는 실행계획을 선택한다.

9i CPU Costing이라는 기능을 도입. 전형적인 Single Block I/O의 읽기 응답시간과Multi Block I/O의 읽기 응답시간, 그리고, 전형적인 Multi Block I/O의 요청크기를데이터베이스에 저장하여 비용계산식에 활용함.

10g Offline Optimizer 등장. Offline Optimizer는 주요 통계 정보를 생성한 후 일종의 프로파일 형태로 저장하고, Online Optimizer는 이 정보로 데이터 값 간의 상관관계로 인한 비용 계산의 오류를방지할 수 있음.

CPU Costing Model에 따른 비용 계산식

COST = ( #SRds*sreadtim + #MRDS *mreadtim + #CPUCycles/cpuspeed ) / sreadtim

#SRDs Single Block I/O의 요청 횟수

#MRDs Multi Block I/O의 요청 횟수#CPUCycles CPU Cycle 수

sreadtim Single Block I/O의 응답시간mreadtim Multi Block I/O의 응답시간

cpuspeed 초당 CPU cycle 수 오류가 분명 있다. (원인은 이전 버젼과의 호환성 문제????)


실행 계획 중 cost가 가장 적은 실행계획 선택

컬럼별 데이터 분포에 대한 통계정보(=히스토그램) 사용

복잡한 관계표현에서 때로 잘못된

실행 계획을 수립할 수도 있는데,

이런 경우 hint를 사용하여 수정하도록 함

오브젝트에 대한 통계정보를 기준으로

실행계획을 작성하므로 통계정보가 제대로

생성되어 있지 않을 경우, 응용프로그램의

성능에 악영향을 미치게 되므로 주의

Cost engine은 I/O cost, Network cost,

CPU cost 등도 고려하도록 설계되어 있음

CBO는 Query Transformer, Estimator, Plan Generator로 구성되어 있음

※ 통계정보 : 테이블의 데이터 건수, 평균 길이, 컬럼 별 distinct 값의 수, 인덱스 leaf node 의 depth 등이 저장

CBO (Cost Base Optimizer)


CBO에서만 가능한 기능들

테이블 및 인덱스의 Partitioning인덱스 구성 테이블 (Index-organized table)Reverse key 인덱스

Function-based 인덱스

SELECT 문장에서의 SAMPLE 절병렬 Query 및 병렬 DMLStar Join 및 Star 변형

Optimizer 확장

Materialized View를 이용한 Query rewriteEnterprise Manager progress meter해쉬 Joinbitmap 인덱스 및 bitmap Join 인덱스

인덱스 skip scan 알고리즘


CBO에 영향을 주는 파라미터들3.2 Cost Based Optimizer의 작동원리

OPTIMIZER_MODE

OPTIMIZER_FEATURES_ENABLE

CURSOR_SHARING

DB_FILE_MULTIBLOCK_READ_COUNT

SORT_AREA_SIZE, HASH_AREA_SIZE, PGA_AGGREGATE_TARGET

HASH_JOIN_ENABLED

OPTIMIZER_INDEX_CACHING

OPTIMIZER_INDEX_COST_ADJ

OPTIMIZER_MAX_PERMUTATIONS

PARTITION_VIEW_ENABLED

QUERY_REWRITE_ENABLED

STAR_TRANSFORMATION_ENABLED

<CBO 통계의 수집>

통계 정보

생성

• CBO에서 응용프로그램의 성능과 접한 관계가 있음

• 많은 resource를 필요로 하는 일이므로 트랜잭션이 없는 시점을 이용

• 오라클 10g의 경우 통계정보가 없다면 ‘다이나믹 샘플링’이 적용됨

통계 정보

생성 방법

• dbms_stats 패키지 이용 [권장]

empty blocks, chained rows에 대한 통계정보는 생성되지 않음(analyze 이용)

• analyze command 이용

• 테이블의 크기가 클 경우, 통계정보 생성 시간 과다를 피하기 위해‘estimate’ 옵션을 적용하고 parallel 로 생성

• Estimate시 sample size는 20% 정도에서 시작하도록 하고, 만약sample size가 50% 이상이라면 Compute Statistics 와 동일

• 테이블에 대한 모니터링 기능을 enable 해놓았을 경우, 변경 row가 일정수준을 넘어선 테이블에 대해서만 통계정보를 재생성 하도록 할 수 있음.하지만 해당 작업을 하기 위해서는 SMON이 주기적으로 변경 사항을 추적해야 하므로 시스템에 추가적인 부하가 발생할 수 있음

통계 내용

확인

• 통계정보 생성 후의 결과는 dictionary view(USER/ALL/DBA_TABLES,

USER/ALL/DBA_INDEXES 등)에서 확인

Costing 에 가장 직접적인 영향을 미치는 통계정보의 관리


히스토그램 생성

• 조건절에 많이 사용되는 컬럼 중 highly skewed data 분포를 가진 컬럼에 생성

히스토그램이 유용하지 않은 경우

• Data가 균등하게 분포되어 있는 경우

• Where 절에 사용되지 않거나, bind variable로 사용될 경우

• 값이 unique하고 ‘equal-join’으로 사용될 경우

히스토그램

Column Value Count of Rows

10 10

20 1050

30 126

40 567

50 248

10 5020 30 40

Number of buckets = 50

10 5020 30 40

Width-Balanced Histogram


히스토그램 (Height-Balanced Histogram)


Statistics on Dictionary Objects

GATHER_DATABASE_STATS(OPTIONS=>'GATHER AUTO')

GATHER_SCHEMA_STATS('SYS')

GATHER_DICTIONARY_STATS

GATHER_FIXED_OBJECTS_STATS CREATEALTER

DROPWorkload DDLs


dbms_stats.set_param('CASCADE',

'DBMS_STdbms_stats.gather_table_stats('sh' -- schema,'customers' -- table, null -- partition, 20 -- sample size(%), false -- block sample?,'for all columns' -- column spec, 4 -- degree of parallelism,'default' -- granularity , true ); -- cascade to indexesATS.AUTO_CASCADE'); dbms_stats.set_param('ESTIMATE_PERCENT','5'); dbms_stats.set_param('DEGREE','NULL');

User Table Statistics 수집 (DBMS_STATS.GATHER_TABLE_STATS)


Statistics Gathering: Manual Approaches

• Dynamic sampling : For highly volatile tables

BEGIN DBMS_STATS.DELETE_TABLE_STATS('OE','ORDERS'); DBMS_STATS.LOCK_TABLE_STATS('OE','ORDERS'); END;

BEGIN DBMS_STATS.GATHER_TABLE_STATS('OE','ORDERS'); DBMS_STATS.LOCK_TABLE_STATS('OE','ORDERS'); END;

• For objects modified in batch operations: Gather statistics as part of the batch operation

• For new objects: Gather statistics immediately after object creation

• Manual statistics collection:


Locking Statistics

• Prevents automatic gathering• Is used primarily for volatile tables

- Lock without statistics implies dynamic sampling.- Lock with statistics is for representative values.

EXECUTE DBMS_STATS.LOCK_TABLE_STATS

('owner name', 'table name');

EXECUTE DBMS_STATS.LOCK_SCHEMA_STATS

('owner name');

SELECT stattype_locked

FROM dba_tab_statistics;


History of Optimizer StatisticsGATHER_STATS IMPORT_STATS SET_STATS

DBA_TAB_STATS_HISTORY

Newstatistics

Oldstatistics

DBA_OPTSTATS_OPERATIONS

31days

RESTORE_TABLE_STATS

Operationdate

• RESTORE_*_STATS()• PURGE_STATS()• ALTER_STATS_HISTORY_RETENTION()


A. 현상A. 현상

Execution Plan--------------------------------------------------------------------------------

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=19 Card=1 Bytes=101)1 0 TABLE ACCESS (FULL) OF ‘SCOTT.TOP_EMP' (Cost=19 Card=1 Bytes=101)

SELECT *FROM wbhbdba.TOP_EMPWHERE TOP_SA_ID = '110098114000'

① WHERE 조건 컬럼의 index가 있음에도 불구하고 Full Scan을 하여 수행 성능이 좋지 않음

② 해당 테이블 및 인덱스에 대한 통계 정보가 오래 전 것으로 되어있음

< 실행계획 분석 >

B. 문제점 및 개선방안B. 문제점 및 개선방안

Execution Plan--------------------------------------------------------------------------------

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=19 Card=1 Bytes=101)1 0 TABLE ACCESS (FULL) OF ‘SCOTT.TOP_EMP' (Cost=19 Card=1 Bytes=101)

통계정보 생성을 이용한 튜닝 사례 (1/2)


통계정보 생성 프로시져를 수행하여 해당 테이블 및 인덱스에 대한 통계정보를 생성함

(2.1초 0.1초로 수행시간이 줄어 듦)

-통계정보 생성 프로시져

EXEC DBMS_STATS.GATHER_TABLE_STATS (ownname=>’SCOTT’,

tabname=>‘TOP_EMP',

estimate_percent=>dbms_stats.auto_sample_size,

method_opt=>'FOR ALL COLUMNS SIZE AUTO',

cascade=>TRUE );

C. 튜닝결과C. 튜닝결과

SELECT *FROM SCOTT.TOP_EMPWHERE TOP_SA_ID = '110098114000'

Execution Plan--------------------------------------------------------------------------------

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=101)1 0 TABLE ACCESS (BY INDEX ROWID) OF ‘SCOTT.TOP_EMP' (Cost=2 Card=1 Bytes=101)2 1 INDEX (RANGE SCAN) OF ‘SCOTT.IX_TOP_EMP_SA_ID_2' (NON-UNIQUE) (Cost=1 Card=1)

통계정보 생성을 이용한 튜닝 사례 (2/2)


SELECT INTERFACE_ID,

ORDER_LINE_ID LINE_ID,

REFERENCE_LINE_ID

FROM OTS_SO_FILE_I

WHERE TRANSFER_FLAG = 'N'

AND REFERENCE_LINE_ID IS NOT NULL

AND ORDER_LINE_ID IS NOT NULL

ORDER BY INTERFACE_ID

Call Count CPU Time Elapsed Time Disk Query Current Rows------- ------ -------- ------------ ---------- ---------- ---------- ----------Parse 1 0.010 0.003 0 0 0 0Execute 1 0.000 0.000 0 0 0 0Fetch 2 41.960 150.857 469257 471161 0 3------- ------ -------- ------------ ---------- ---------- ---------- ----------Total 4 41.970 150.860 469257 471161 0 3

Rows Row Source Operation------- ---------------------------------------------------

0 STATEMENT3 SORT ORDER BY 3 TABLE ACCESS FULL OTS_SO_FILE_I

Transfer Flag 값 건수 전체 대비 비율(%)

A 3437488 11.663

N 1751 0.006

Y 26033111 88.331

총 건수 29472350

2.1 인덱스

< OTS_SO_FILE_I 테이블 내TRANSFER_FLAG 값 분포 현황 >

사례. SKEWED COLUMN의 문제 해결– (현상)


약 3천만건 정도의 OTS_SO_FILE_I(인터페이스용 테이블)을 full scan 하면서 IO량 과다 발생

① 필요 인덱스 부재

- TRANSFER_FLAG 의 값의 개수는 3가지로 Normal Index로 구성시 인덱스로서의 큰 효용성은

떨어짐

- 인터페이스 테이블의 특성상 Flag가 ‘N’인 값을 사전에 조회 한 다음, 필요 데이터에 대

하여 Update를 수행하므로 전체 건수 중 1%도 차지 않는 N에 대한 조회 시에는 인덱스를

통한 스캔이 보다 유리함

< 수행성능 분석 >

필요 인덱스 부재로 인하여 액세스 량 과다 발생

컬럼 내 Unique한 값의 개수가 매우 적으나 업무 특성상 전체 대비 1% 미만의 데이터에 대한

조회가 대부분이므로 해당 컬럼에 대하여 인덱스를 생성하여 Full Scan을 제거하고 액세스량

을 감소시키도록 함

2.1 인덱스

사례. SKEWED COLUMN의 문제 해결– (문제점 분석)


- OTS_SAL_INFO_I 테이블에 추가 인덱스 생성

OTS_SO_FILE_I_N01 : TRANSFER_FLAG

- 해당 인덱스를 Flag 값이 N인 경우에 취사할 수 있도록 해당 컬럼(transfer_flag)에 히스토그램 추가 생성



0 STATEMENT0 SORT ORDER BY 0 TABLE ACCESS BY INDEX ROWID OTS_SO_FILE_I

3390 INDEX RANGE SCAN OTS_SO_FILE_I_N01 (Object ID 26040)

transfer_flag값이 N인 경우, ots_file_i_n01 인덱스를 이용함으로써 IO량이 감소하였으며 이에 따라응답속도 150초->8초로 감소함

2.1 인덱스

사례. SKEWED COLUMN의 문제 해결– (튜닝 결과)


튜닝 전

select PROMO_NUM,PROMO_NAME, PROMO_DESC, START_DATE, END_DATE, NOTICE_DATE,

CRE_DATE, URL, PRISE_NUM, STATUS, rownum no

from

( SELECT /*+ ordered use_nl( a b ) index_desc(a lgec_mkt_user_ix1) */

B.PROMO_NUM, B.PROMO_NAME, B.PROMO_DESC,

TO_CHAR(B.START_DATE,'yyyy/mm/dd') START_DATE,

TO_CHAR(B.END_DATE, 'yyyy/mm/dd') END_DATE,

TO_CHAR(B.NOTICE_DATE,'yyyy/mm/dd') NOTICE_DATE,

TO_CHAR(A.CREDATE,'yyyy/mm/dd') CRE_DATE,

B.URL, A.PRISE_NUM,

DECODE(SIGN(SYSDATE - b.END_DATE), '1', 'END','ING') STATUS,

rownum no

FROM LGEC_MKT_USER A,

LGEC_MKT B

WHERE A.PROMO_NUM = B.PROMO_NUM

AND B.DBSTS != 'D'

AND B.USE_TYPE='E'

AND A.CREDATE BETWEEN ADD_MONTHS(SYSDATE, -3) AND SYSDATE

AND B.MALL_GB = 'S'

AND A.ECUSERID = 236500923 )

WHERE no > 1 AND no <= 20

3.5 Clustering Factor 의 개선을 통한 튜닝 사례

Call Count CPU Time Elapsed Time Disk Query Current Rows------- ------ -------- ------------ ---------- ----------Parse 1 0.000 0.000 0 0 0 0Execute 1 0.000 0.000 0 0 0 0Fetch 3 0.010 0.092 0 2256 0 19------- ------ -------- ------------ ---------- ----------Total 5 0.010 0.093 0 2256 0 19

Elapsed Time for Client(sec.): 0.100Misses in library cache during parse: 0Optimizer goal: RULEParsing user: STORE (ID=163)


0 STATEMENT19 COUNT (cr=2256 r=0 w=0 time=92114 us)19 VIEW (cr=2256 r=0 w=0 time=92097 us)47 COUNT (cr=2256 r=0 w=0 time=91524 us)47 NESTED LOOPS (cr=2256 r=0 w=0 time=91499 us)

234 TABLE ACCESS BY INDEX ROWID LGEC_MKT_USER (cr=1784 r=0 w=0 time=89252 us)3524 INDEX RANGE SCAN DESCENDING LGEC_MKT_USER_IX1 (cr=15 r=0 w=0 time=3177 us)OF LGEC_MKT_USER_IX1

47 TABLE ACCESS BY INDEX ROWID LGEC_MKT (cr=472 r=0 w=0 time=1816 us)234 INDEX UNIQUE SCAN LGEC_MKT_PK (cr=238 r=0 w=0 time=758 us)OF LGEC_MKT_PK (UNIQUE)

문제점 및 개선사항

LGEC_MKT_USER 테이블은 8천7백만건으로 이벤트(프로모션) 이후 정리해도 되는 테이블임.따라서, 테이블을 백업한 후, 최근 데이터 천만건 정도를 유지한 후 테이블의 CLUSTERING FACTOR를 향상시키기 위하여Re-org 하여야 함.Re-org 컬럼 순서는 자주 Access하는 PROMO_NUM, ECUSERID, CREDATE 순서로 정렬하여 재구성하는 것이 권장됨.


① CREATE TABLE "TEMP_LGEC_MKT_USER" AS SELECT * FROM LGEC_MKT_USER WHERE 1=2 TABLESPACE ETCDATA

② INSERT /*+ APPEND */ INTO TEMP_LGEC_MKT_USERSELECT * FROM LGEC_MKT_USER WHERE CREDATE > TO_DATE('20051204','YYYYMMDD') -- 데이터 정리ORDER BY PROMO_NUM, ECUSERID, CREDATE; -- 해당 인덱스를 위한 CLUSTERING

FACTOR 향상

③ ALTER TABLE LGEC_MKT_USER RENAME TO ORG_LGEC_MKT_USER;

④ ALTER TABLE TEMP_LGEC_MKT_USER RENAME TO LGEC_MKT_USER;

⑤ 인덱스 생성 및 CONSTRAINTS 추가

⑥ STORED PROCEDURE 재생성 (또는 COMPILE)

튜닝(Table Re-Org.) 절차


튜닝후********************************************************************************Call Count CPU Time Elapsed Time Disk Query Current Rows------- ------ -------- ------------ ---------- ---------- ----------Parse 1 0.000 0.000 0 0 0 0Execute 1 0.000 0.000 0 0 0 0Fetch 3 0.010 0.010 0 874 0 19------- ------ -------- ------------ ---------- ---------- ----------Total 5 0.010 0.010 0 874 0 19

Misses in library cache during parse: 0Optimizer goal: RULEParsing user: STORE (ID=163)


0 STATEMENT19 COUNT (cr=874 r=0 w=0 time=10192 us)19 VIEW (cr=874 r=0 w=0 time=10180 us)43 COUNT (cr=874 r=0 w=0 time=9717 us)43 NESTED LOOPS (cr=874 r=0 w=0 time=9694 us)223 TABLE ACCESS BY INDEX ROWID LGEC_MKT_USER (cr=424 r=0 w=0 time=7575 us)

2361 INDEX RANGE SCAN DESCENDING LGEC_MKT_USER_IX1 (cr=11 r=0 w=0 time=1882 us)OF LGEC_MKT_USER_IX1 43 TABLE ACCESS BY INDEX ROWID LGEC_MKT (cr=450 r=0 w=0 time=1742 us)

223 INDEX UNIQUE SCAN LGEC_MKT_PK (cr=227 r=0 w=0 time=715 us)OF LGEC_MKT_PK (UNIQUE)

튜닝 전 (초) 튜닝 후 (초) 조치사항

0.093(Blocks 2256)

0.010 (Blocks 874)

Table Re-Org 작업을 통하여 Clustering Factor를 개선함.


Clustering Factor의 이해

정의 : Indicates the amount of order of the rows in the table based on the values of the index.- If the value is near the number of Table blocks, then the table is very well ordered. In this case, the index entries in a single leaf block tend to point to rows in the same data blocks. - If the value is near the number of rows, then the table is very randomly ordered. In this case, it is unlikely that index entries in the same leaf block point to rows in the different data blocks.

[ Best Clustering Factor ]



[ Worst Clustering Factor ]



SQL> create table t1 asselect trunc((rownum-1)/15) n1, rpad('x', 215) v1from all_objects where rownum <= 3000;

SQL> create table t2 asselect mod(rownum,200) n1, rpad('x',215) v1from all_objects where rownum <= 3000;

　 t1, t2 모두 0~199 까지의 값이 15건씩 분포한다.

SQL> create index t1_idx1 on t1(n1);SQL> create index t2_idx1 on t2(n1);

SQL> analyze table t1 compute statistics;SQL> analyze table t2 compute statistics;

SQL> select * from t1 where n1 = 45;

Execution Plan----------------------------------------------------------

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=15 Bytes=3315)1 0 TABLE ACCESS (BY INDEX ROWID) OF 'T1' (Cost=2 Card=15 Bytes=3315)2 1 INDEX (RANGE SCAN) OF 'T1_IDX1' (NON-UNIQUE) (Cost=1 Card=15)



SQL> select * from t2 where n1 = 45;15 rows selected.

Execution Plan----------------------------------------------------------

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=12 Card=15 Bytes=3315)1 0 TABLE ACCESS (FULL) OF 'T2' (Cost=12 Card=15 Bytes=3315)

Statistics----------------------------------------------------------


1128 bytes sent via SQL*Net to client425 bytes received via SQL*Net from client2 SQL*Net roundtrips to/from client1 sorts (memory)0 sorts (disk)15 rows processed



SQL> select /*+ index(t2 t2_idx1) */ * from t2 where n1 = 45;

Execution Plan----------------------------------------------------------

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=16 Card=15 Bytes=3315)1 0 TABLE ACCESS (BY INDEX ROWID) OF 'T2' (Cost=16 Card=15 Bytes=3315)2 1 INDEX (RANGE SCAN) OF 'T2_IDX1' (NON-UNIQUE) (Cost=1 Card=15)

Statistics----------------------------------------------------------

8 recursive calls0 db block gets

240 consistent gets0 physical reads0 redo size

1128 bytes sent via SQL*Net to client425 bytes received via SQL*Net from client2 SQL*Net roundtrips to/from client1 sorts (memory)0 sorts (disk)15 rows processed



SQL> select table_name, index_name, clustering_factor from user_indexes;

TABLE_NAME INDEX_NAME CLUSTERING_FACTOR-------------------- ------------------------------ -----------------------------------------------

T1 T1_Idx1 94 T2 T2_Idx1 3000

SQL> SELECT INDEX_NAME, TABLE_NAME, DISTINCT_KEYS, AVG_LEAF_BLOCKS_PER_KEY, AVG_DATA_BLOCKS_PER_KEY, CLUSTERING_FACTOR,NUM_ROWS

FROM USER_INDEXESWHERE TABLE_NAME IN ('T1','T2');

INDEX_NAME TABLE_NAME DISTINCT_KEYS AVG_LEAF_BLOCKS_PER_KEY AVG_DATA_BLOCKS_PER_KEY CLUSTERING_FACTOR NUM_ROWS--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

T1_IDX1 T1 200 1 1 94 3000T2_IDX1 T2 200 1 15 3000 3000

SQL> SELECT TABLE_NAME,NUM_ROWS,BLOCKS,AVG_ROW_LEN FROM USER_TABLES

WHERE TABLE_NAME IN ('T1','T2');

TABLE_NAME NUM_ROWS BLOCKS AVG_ROW_LEN------------------------------ ---------------------------- --------------- ---------------------

T1 3000 103 222T2 3000 103 222









3.6 10g CBO환경에서의 튜닝 사례

SELECT VP.*, C.*FROM VAS_PROFILE VP,

CALL_FORWARD C,VEP_USER U,ABSTRACT_USER AU

WHERE VP.ID = C.IDAND AU.ID = U.IDAND U.ID = VP.USER_IDAND VP.ENABLED = 'Y'AND ( AU.I_E164 = '1001015482051'

OR EXISTS ( SELECT 1FROM VAS_PROFILE VP2,

DID DWHERE VP2.ID = D.ID

AND U.ID = VP2.USER_IDAND D.DID_NUMBER = '827079011033' ) )

Call Count CPU Time Elapsed Time Disk Query Current Rows

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

Parse 1 0.000 0.003 0 0 0 0

Execute 1 0.000 0.003 0 0 0 0

Fetch 2 0.020 0.011 0 1022 0 2

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

Total 4 0.020 0.017 0 1022 0 2



0 STATEMENT2 CONCATENATION (cr=1022 pr=0 pw=0 time=8555 us)1 NESTED LOOPS (cr=1006 pr=0 pw=0 time=8550 us)1 NESTED LOOPS (cr=1003 pr=0 pw=0 time=10579 us)

142 HASH JOIN (cr=14 pr=0 pw=0 time=3235 us)146 TABLE ACCESS FULL CALL_FORWARD (cr=4 pr=0 pw=0 time=54 us)913 TABLE ACCESS FULL VAS_PROFILE (cr=10 pr=0 pw=0 time=64 us)1 PARTITION HASH ITERATOR PARTITION: KEY KEY (cr=989 pr=0 pw=0 time=6702 us)1 INDEX UNIQUE SCAN IDX_VEPUSER_ID PARTITION: KEY KEY (cr=989 pr=0 pw=0 time=6064 us)(Object ID 62620)1 NESTED LOOPS (cr=710 pr=0 pw=0 time=4169 us)

142 TABLE ACCESS BY INDEX ROWID DID (cr=284 pr=0 pw=0 time=2008 us)142 INDEX RANGE SCAN IDX_DID_NUMBER (cr=142 pr=0 pw=0 time=1185 us)(Object ID 52650)1 TABLE ACCESS BY INDEX ROWID VAS_PROFILE (cr=426 pr=0 pw=0 time=1901 us)

142 INDEX UNIQUE SCAN IDX_VASPROFILE_ID (cr=284 pr=0 pw=0 time=1093 us)(Object ID 52778)1 TABLE ACCESS BY INDEX ROWID ABSTRACT_USER (cr=3 pr=0 pw=0 time=21 us)1 INDEX UNIQUE SCAN IDX_ABSTRACT_USER_PK (cr=2 pr=0 pw=0 time=15 us)(Object ID 52607)1 NESTED LOOPS (cr=16 pr=0 pw=0 time=194 us)4 NESTED LOOPS (cr=13 pr=0 pw=0 time=138 us)1 NESTED LOOPS (cr=10 pr=0 pw=0 time=98 us)1 TABLE ACCESS BY INDEX ROWID ABSTRACT_USER (cr=3 pr=0 pw=0 time=43 us)1 INDEX RANGE SCAN IDX_ABSTRACTUSER_IE164 (cr=2 pr=0 pw=0 time=28 us)(Object ID 52606)1 PARTITION HASH ITERATOR PARTITION: KEY KEY (cr=7 pr=0 pw=0 time=52 us)1 INDEX UNIQUE SCAN IDX_VEPUSER_ID PARTITION: KEY KEY (cr=7 pr=0 pw=0 time=45 us)(Object ID 62620)1 NESTED LOOPS (cr=710 pr=0 pw=0 time=4169 us)

142 TABLE ACCESS BY INDEX ROWID DID (cr=284 pr=0 pw=0 time=2008 us)142 INDEX RANGE SCAN IDX_DID_NUMBER (cr=142 pr=0 pw=0 time=1185 us)(Object ID 52650)1 TABLE ACCESS BY INDEX ROWID VAS_PROFILE (cr=426 pr=0 pw=0 time=1901 us)

142 INDEX UNIQUE SCAN IDX_VASPROFILE_ID (cr=284 pr=0 pw=0 time=1093 us)(Object ID 52778)0 TABLE ACCESS BY INDEX ROWID VAS_PROFILE (cr=0 pr=0 pw=0 time=0 us)0 INDEX RANGE SCAN IDX_VASPROFILE_USERID (cr=0 pr=0 pw=0 time=0 us)(Object ID 52777)0 TABLE ACCESS BY INDEX ROWID CALL_FORWARD (cr=0 pr=0 pw=0 time=0 us)0 INDEX UNIQUE SCAN IDX_CALL_FORWARD_ID (cr=0 pr=0 pw=0 time=0 us)(Object ID 52635)


SELECT VP.*, C.*FROM VAS_PROFILE VP,CALL_FORWARD C,VEP_USER U,ABSTRACT_USER AU

WHERE VP.ID = C.IDAND AU.ID = U.IDAND U.ID = VP.USER_IDAND VP.ENABLED = 'Y'AND AU.I_E164 = '1001015482051'

UNION ALL

SELECT VP.*, C.*FROM VAS_PROFILE VP,CALL_FORWARD C,VEP_USER U,ABSTRACT_USER AU

WHERE VP.ID = C.IDAND AU.ID = U.IDAND U.ID = VP.USER_IDAND VP.ENABLED = 'Y' AND EXISTS (

SELECT 1FROM VAS_PROFILE VP2,DID D

WHERE VP2.ID = D.IDAND U.ID = VP2.USER_IDAND D.DID_NUMBER = '827079011033' )

Call Count CPU Time Elapsed Time Disk Query Current Rows

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

Parse 1 0.000 0.004 0 0 0 0

Execute 1 0.000 0.002 0 0 0 0

Fetch 2 0.000 0.001 0 30 0 2

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

Total 4 0.000 0.007 0 30 0 2



0 STATEMENT2 UNION-ALL (cr=30 pr=0 pw=0 time=149 us)1 NESTED LOOPS (cr=14 pr=0 pw=0 time=125 us)4 NESTED LOOPS (cr=11 pr=0 pw=0 time=168 us)1 NESTED LOOPS (cr=6 pr=0 pw=0 time=76 us)1 TABLE ACCESS BY INDEX ROWID ABSTRACT_USER (cr=4 pr=0 pw=0 time=51 us)1 INDEX RANGE SCAN IDX_ABSTRACTUSER_IE164 (cr=3 pr=0 pw=0 time=37 us)(Object ID 52606)1 PARTITION HASH ITERATOR PARTITION: KEY KEY (cr=2 pr=0 pw=0 time=22 us)1 INDEX UNIQUE SCAN IDX_VEPUSER_ID PARTITION: KEY KEY (cr=2 pr=0 pw=0 time=12 us)(Object ID 62620)4 TABLE ACCESS BY INDEX ROWID VAS_PROFILE (cr=5 pr=0 pw=0 time=98 us)4 INDEX RANGE SCAN IDX_VASPROFILE_USERID (cr=3 pr=0 pw=0 time=57 us)(Object ID 52777)1 TABLE ACCESS BY INDEX ROWID CALL_FORWARD (cr=3 pr=0 pw=0 time=41 us)1 INDEX UNIQUE SCAN IDX_CALL_FORWARD_ID (cr=2 pr=0 pw=0 time=25 us)(Object ID 52635)1 NESTED LOOPS (cr=16 pr=0 pw=0 time=527 us)4 NESTED LOOPS (cr=13 pr=0 pw=0 time=456 us)1 NESTED LOOPS (cr=9 pr=0 pw=0 time=413 us)1 NESTED LOOPS (cr=7 pr=0 pw=0 time=398 us)1 VIEW VW_SQ_1 (cr=5 pr=0 pw=0 time=375 us)1 HASH UNIQUE (cr=5 pr=0 pw=0 time=373 us)1 NESTED LOOPS (cr=5 pr=0 pw=0 time=58 us)1 TABLE ACCESS BY INDEX ROWID DID (cr=2 pr=0 pw=0 time=31 us)1 INDEX RANGE SCAN IDX_DID_NUMBER (cr=1 pr=0 pw=0 time=19 us)(Object ID 52650)1 TABLE ACCESS BY INDEX ROWID VAS_PROFILE (cr=3 pr=0 pw=0 time=25 us)1 INDEX UNIQUE SCAN IDX_VASPROFILE_ID (cr=2 pr=0 pw=0 time=17 us)(Object ID 52778)1 PARTITION HASH ITERATOR PARTITION: KEY KEY (cr=2 pr=0 pw=0 time=19 us)1 INDEX UNIQUE SCAN IDX_VEPUSER_ID PARTITION: KEY KEY (cr=2 pr=0 pw=0 time=13 us)(Object ID 62620)1 INDEX UNIQUE SCAN IDX_ABSTRACT_USER_PK (cr=2 pr=0 pw=0 time=12 us)(Object ID 52607)4 TABLE ACCESS BY INDEX ROWID VAS_PROFILE (cr=4 pr=0 pw=0 time=80 us)4 INDEX RANGE SCAN IDX_VASPROFILE_USERID (cr=2 pr=0 pw=0 time=18 us)(Object ID 52777)1 TABLE ACCESS BY INDEX ROWID CALL_FORWARD (cr=3 pr=0 pw=0 time=35 us)1 INDEX UNIQUE SCAN IDX_CALL_FORWARD_ID (cr=2 pr=0 pw=0 time=21 us)(Object ID 52635)


세션 4. 실무 업그레이드 프로젝트 사례

4.1 SQL 의 자동 개선 사례(9i to 10g)

4.2 Rule 힌트 쿼리의 개선 사례

4.3 10g에서 자주 나타나는 Bitmap Plan

4.4 Remote 조인 쿼리의 튜닝

4.5 Function Based Index의 활용사례

4.6 10053 Event New Features

4.7 Plan Exchange 방법

UPDATE B2BI_ORDERDETAIL

SET SHIPPINGSENDYN = 'S'

WHERE ORDERNO IN (

SELECT /*+ ordered use_nl(a b c) */ DISTINCT B.ORDERNO

FROM B2BI_SHIPPING_VIEW A,

B2BI_ORDERMASTER B,

B2BI_ORDERDETAIL C

WHERE A.SENDERORDERNUMBER = B.SALESORDERNO

AND B.ORDERNO = C.ORDERNO

AND A.ITEMSEQ = C.ITEMSEQ

UNION

SELECT DISTINCT A.ORDERNO

FROM B2BI_ORDERMASTER A,

B2BI_ORDERDETAIL B,

B2BI_T_ORDERMASTER C

WHERE B.ORDERNO = A.ORDERNO

AND A.SALESORDERNO = C.SENDERORDERNUMBER

AND A.PROCESSSTATUS = '03'

AND A.SHIPPINGTYPE = '0'

AND A.ERROROCCUR = 'N'

AND B.SHIPPINGSENDYN IN ('S'))

4.1 SQL 의 자동 개선 사례1 (9i to 10g)

AND ITEMSEQ IN (

SELECT /*+ ordered use_nl(a b c) */ DISTINCT A.ITEMSEQ

FROM B2BI_SHIPPING_VIEW A,

B2BI_ORDERMASTER B,

B2BI_ORDERDETAIL C

WHERE A.SENDERORDERNUMBER = B.SALESORDERNO

AND B.ORDERNO = C.ORDERNO

AND A.ITEMSEQ = C.ITEMSEQ

UNION

SELECT DISTINCT B.ITEMSEQ

FROM B2BI_ORDERMASTER A,

B2BI_ORDERDETAIL B,

B2BI_T_ORDERMASTER C

WHERE B.ORDERNO = A.ORDERNO

AND A.SALESORDERNO = C.SENDERORDERNUMBER

AND A.PROCESSSTATUS = '03'

AND A.SHIPPINGTYPE = '0'

AND A.ERROROCCUR = 'N'

AND B.SHIPPINGSENDYN IN ('S'))

ORDER_DETAIL 배치(점심시간에 수행) - 매일 점심시간에 수행되는 배치 프로그램으로 한 시간 이상 수행되어13시 이후 업무에 지장을 주는 쿼리임

조치 : 10g 로 업그레이드 이후 힌트( ORDERED, USE_NL) 제거함.


실제 플랜에서는 꼭 필요한 부분만 Access 하는 형식으로 10g 옵티마이져에 의해 자동 변경됨.

10g CBO 환경으로 업그레이드 배치성 쿼리에 대한 지침.

1.9i 이전 버전에서 과도한 Logical/Physical I/O의 발생과 매우 긴 Elapsed Time이 발생하는 Batch 성 쿼리의 경우 10g 로업그레이드 이후 적용되어 있는 힌트를 모두 제거한다. (이 때, Statistics_Level을 Typical 이상으로 설정하여 정확한 통계 정보를항상 확보하여야 함)2.힌트 제거 시 일반적으로 대부분의 Batch 성 SQL은 개선되지만, 개선되지 않는 일부 SQL에 대해서는 10g CBO환경에 맞는Manual 튜닝을 적용하여야 한다.


튜닝 전 (초) 튜닝 후 (초) 조치사항

한 시간 이상 수행

(Blocks 결과안나옴)

1.342

(Blocks 101704)

힌트(ordered, use_nl) 제거

　 NL의 오버헤드가 hash join으로 풀리면서 해소됨.

*************************************************************************************

Compile Time : 2008/02/23 07:00:21

Trace File Name : /oracle/ECDB/admin/ECORCL/udump/ecorcl_ora_2093504.trc

Trace Version : Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production

Environment : Array Size = 1000

Long Size = 80

********************************************************************************

SELECT COUNT(*)

FROM ( SELECT /*+ use_nl(a b c) */

A.FILEDATE , A.LINENO, A.SHOPCODE, B.SHOPNAME,

A.PRODUCTID, C.SEQNO PRODUCTNAME, A.SIDATE,

A.SETINV , A.DISPLAYINV , A.STOCK , A.ERRORYN

FROM GVDSTANDARDINV A, ARMSHOP B, CS.PRODUCT C

WHERE A.SHOPCODE = B.SHOPCODE

AND B.ACTIVE = 'Y'

AND A.PRODUCTID = C.PRODUCTID

AND A.FILEDATE BETWEEN '20080215000000’ AND '20080222235999'

)


상거래 DB를 10g로 업그레이드 한 이후 160초 이상 걸리는 쿼리 OLTP 성격의 쿼리


Misses in library cache during parse: 0Optimizer goal: ALL_ROWSParsing user: B2BTS (ID=56)


0 STATEMENT1 SORT AGGREGATE (cr=2578611 pr=0 pw=0 time=165039714 us)

499596 NESTED LOOPS (cr=2578611 pr=0 pw=0 time=175873019 us)499596 NESTED LOOPS (cr=2079013 pr=0 pw=0 time=172875418 us)

107 INDEX FULL SCAN ARMSHOP_IDX01 (cr=1 pr=0 pw=0 time=661 us)OF ARMSHOP_IDX01 (NONUNIQUE)499596 TABLE ACCESS BY INDEX ROWID GVDSTANDARDINV (cr=2079012 pr=0 pw=0 time=165263918 us)71069507 INDEX RANGE SCAN GVDSTANDARDINV_IDX01 (cr=428858 pr=0 pw=0 time=71072568 us)OF

GVDSTANDARDINV_IDX01 (NONUNIQUE)499596 INDEX UNIQUE SCAN PK_PRODUCT (cr=499598 pr=0 pw=0 time=2473793 us)OF PK_PRODUCT (UNIQUE)

◑ 문제점 및 개선사항- use_nl( a b c) 힌트로 인하여 Nested loop join의 overhead가 커짐- GVDSTANDARDINV (5천만건) 테이블이 where 절에 filedate 조건을 가지고 있음에도 불구하고 후행테이블로 풀림.


조치 : USE_NL 힌트 제거


Misses in library cache during parse: 0Optimizer goal: ALL_ROWSParsing user: B2BTS (ID=56)


0 STATEMENT1 SORT AGGREGATE (cr=19485 pr=0 pw=0 time=2475697 us)

499596 HASH JOIN (cr=19485 pr=0 pw=0 time=3016834 us)17742 INDEX FAST FULL SCAN PK_PRODUCT (cr=53 pr=0 pw=0 time=64 us)OF PK_PRODUCT (UNIQUE)499596 HASH JOIN (cr=19432 pr=0 pw=0 time=2002122 us)

107 INDEX FULL SCAN ARMSHOP_IDX01 (cr=1 pr=0 pw=0 time=451 us)OF ARMSHOP_IDX01 (NONUNIQUE)664201 TABLE ACCESS BY INDEX ROWID GVDSTANDARDINV (cr=19431 pr=0 pw=0 time=1992658 us)664201 INDEX RANGE SCAN GVDSTANDARDINV_IDX01 (cr=4009 pr=0 pw=0 time=1328444 us)OF

GVDSTANDARDINV_IDX01 hash join으로 풀리면서 독립적으로 수행됨.


튜닝 전 (9i) 튜닝 전 (10g) 튜닝 후 (10g) 조치사항

165.040

(Blocks 2578611)

2.475

(Blocks 19485)힌트 제거

SELECT T1.CENTER, T1.ORDERNO, T1.PARTNO, T1.REQNO, T1.SEQNO, T1.FOCCOD, T1.PARTDESC, T1.USEMODEL, T1.REPLPRTNO, T1.TECHNO, T1.ORDQTY, T1.SUPQTY, T1.SALESTYPE, T1.PACKAGEFLAG, T1.REQQTY, T1.REMAINQTY, T1.RECEIPTCENTER, T1.LASTCOST, T1.BRETAILPRICE, T1.HBRETAILPRICE,DECODE(T1.CENTYPE, 'C', DECODE(T2.CENTER, NULL, T1.CRETAILPRICE, T1.LASTCOST), T1.CRETAILPRICE) CRETAILPRICE,DECODE(T1.CENTYPE, 'C', DECODE(T2.CENTER, NULL, T1.HCRETAILPRICE, T1.LASTCOST), T1.HCRETAILPRICE) HCRETAILPRICE,

T1.ORDTYPE, T1.CENTERCOD, T1.ORDDATE, T1.RECEIPTNO, T1.LOCCOD1, T1.GENTYPE ,T1.REPAIRTOOL

FROM ( SELECT /*+ RULE */A.CENTER, A.ORDERNO, A.PARTNO, A.REQNO, A.SEQNO, A.FOCCOD, C.PARTDESC, C.USEMODEL,NVL(C.REPLPRTNO,'N') REPLPRTNO,B.USERID TECHNO,B.REQDATE,A.ORDQTY,A.SUPQTY, B.SALESTYPE,B.PACKAGEFLAG,A.REQQTY,(A.REQQTY-A.SUPQTY) REMAINQTY,B.RECEIPTCENTER,DECODE(F.CENTYPE,'C',ROUND(C.CDEALERPRICE/C.PACKINGUNITQTY),

'E',ROUND(C.BDEALERPRICE/C.PACKINGUNITQTY),ROUND(D.LASTCOST/C.PACKINGUNITQTY)) LASTCOST,ROUND(C.BRETAILPRICE/C.PACKINGUNITQTY) BRETAILPRICE,ROUND(C.BRETAILPRICE/C.PACKINGUNITQTY+49,-2) HBRETAILPRICE,(C.OW_PRICE1/C.PACKINGUNITQTY) CRETAILPRICE,(C.OW_PRICE1/C.PACKINGUNITQTY) HCRETAILPRICE,DECODE(A.ORDTYPE,'E','E','I') ORDTYPE, B.CENTERCOD,NVL(E.ORDDATE,TO_DATE('19000101','YYYYMMDD')) ORDDATE,B.RECEIPTNO, D.LOCCOD1,E.GENTYPE, F.CENTYPE,NVL(C.REPAIRTOOL,'N') REPAIRTOOL

FROM RP_PARTREQ_DETAIL A, RP_PARTREQ_HEAD B, RP_PART_MST C, RP_INVENTORY_MST D, RP_PART_ORDER E,CM_CENTER_MST F

WHERE A.CENTER = B.CENTER AND A.REQNO = B.REQNOAND A.PARTNO = C.PARTNO AND A.CENTER = D.CENTER AND A.PARTNO = D.PARTNOAND A.CENTER = E.CENTER(+) AND A.ORDERNO = E.ORDERNO(+)AND A.CENTER = F.CENTER AND A.CENTER = 'AC’AND B.SALESTYPE = 'CA’ AND A.STATUS = 'RQ’AND A.BOFLAG = 'BK’ AND A.BOFINISHDATE IS NULL

ORDER BY B.REQDATE,ORDTYPE ) T1,SV_RPR_TRANREQ T2

WHERE T1.RECEIPTCENTER = T2.TOCENTER(+) AND T1.RECEIPTNO = T2.RCVRECEIPTNO(+)ORDER BY T1.REQDATE


OLTP성 쿼리 중 가장 많은 실행횟수를 보이는 쿼리의 튜닝 사례


Misses in library cache during parse: 1Optimizer goal: RULEParsing user: IPASS (ID=23)


0 STATEMENT73 NESTED LOOPS OUTER 73 VIEW 73 SORT ORDER BY 73 TABLE ACCESS BY INDEX ROWID CM_CENTER_MST 147 NESTED LOOPS 73 NESTED LOOPS 73 NESTED LOOPS 73 NESTED LOOPS OUTER 73 NESTED LOOPS

260801 TABLE ACCESS BY INDEX ROWID RP_PARTREQ_HEAD 260801 INDEX RANGE SCAN RP_PARTREQ_HEAD_IDX03 OF RP_PARTREQ_HEAD_IDX03 (NONUNIQUE)

73 TABLE ACCESS BY INDEX ROWID RP_PARTREQ_DETAIL172 INDEX RANGE SCAN RP_PARTREQ_DETAIL_IDX02 OF RP_PARTREQ_DETAIL_IDX02 (NONUNIQUE)69 TABLE ACCESS BY INDEX ROWID RP_PART_ORDER 69 INDEX UNIQUE SCAN PK_RP_PART_ORDER OF PK_RP_PART_ORDER (UNIQUE)73 TABLE ACCESS BY INDEX ROWID RP_INVENTORY_MST 73 INDEX UNIQUE SCAN PK_RP_INVENTORY_MST OF PK_RP_INVENTORY_MST (UNIQUE)73 TABLE ACCESS BY INDEX ROWID RP_PART_MST 73 INDEX UNIQUE SCAN PK_RP_PART_MST OF PK_RP_PART_MST (UNIQUE)73 INDEX RANGE SCAN CM_CENTER_MST_IDX01 OF CM_CENTER_MST_IDX01 (NONUNIQUE)0 TABLE ACCESS BY INDEX ROWID SV_RPR_TRANREQ 0 INDEX RANGE SCAN SV_RPR_TRANREQ_IDX01 OF SV_RPR_TRANREQ_IDX01 (NONUNIQUE)

문제점 및 개선 방향

- Rule 힌트가 적용되어 있는 쿼리로 10g 버전으로업그레이드 호환문제가 발생할 가능성 있음.

- Rule 힌트를 제거하여 CBO가 최적의 Access Path를스스로 찾게 함.


10g에서 RULE 힌트를 제거한 경우



0 STATEMENT73 SORT ORDER BY (cr=953 pr=0 pw=0 time=17650 us)73 NESTED LOOPS OUTER (cr=953 pr=0 pw=0 time=17902 us)73 NESTED LOOPS (cr=953 pr=0 pw=0 time=16135 us)73 NESTED LOOPS (cr=732 pr=0 pw=0 time=11388 us)73 NESTED LOOPS OUTER (cr=511 pr=0 pw=0 time=7074 us)73 NESTED LOOPS (cr=302 pr=0 pw=0 time=5710 us)94 NESTED LOOPS (cr=18 pr=0 pw=0 time=1305 us)1 TABLE ACCESS BY INDEX ROWID CM_CENTER_MST (cr=2 pr=0 pw=0 time=186 us)1 INDEX RANGE SCAN CM_CENTER_MST_IDX01 (cr=1 pr=0 pw=0 time=88 us)OF CM_CENTER_MST_IDX01 94 TABLE ACCESS BY INDEX ROWID RP_PARTREQ_DETAIL (cr=16 pr=0 pw=0 time=935 us)94 INDEX RANGE SCAN RP_PARTREQ_DETAIL_BTX01 (cr=4 pr=0 pw=0 time=353 us)OF RP_PARTREQ_DETAIL_BTX01 (NONUNIQUE)73 TABLE ACCESS BY INDEX ROWID RP_PARTREQ_HEAD (cr=284 pr=0 pw=0 time=3403 us)94 INDEX UNIQUE SCAN PK_RP_PARTREQ_HEAD (cr=190 pr=0 pw=0 time=1855 us)OF PK_RP_PARTREQ_HEAD 69 TABLE ACCESS BY INDEX ROWID RP_PART_ORDER (cr=209 pr=0 pw=0 time=2287 us)69 INDEX UNIQUE SCAN PK_RP_PART_ORDER (cr=140 pr=0 pw=0 time=1371 us)OF PK_RP_PART_ORDER (UNIQUE)73 TABLE ACCESS BY INDEX ROWID RP_INVENTORY_MST (cr=221 pr=0 pw=0 time=2750 us)73 INDEX UNIQUE SCAN PK_RP_INVENTORY_MST (cr=148 pr=0 pw=0 time=1574 us)OF PK_RP_INVENTORY_MST 73 TABLE ACCESS BY INDEX ROWID RP_PART_MST (cr=221 pr=0 pw=0 time=3185 us)73 INDEX UNIQUE SCAN PK_RP_PART_MST (cr=148 pr=0 pw=0 time=1621 us)OF PK_RP_PART_MST (UNIQUE)0 TABLE ACCESS BY INDEX ROWID SV_RPR_TRANREQ (cr=0 pr=0 pw=0 time=1329 us)0 INDEX RANGE SCAN SV_RPR_TRANREQ_IDX01 (cr=0 pr=0 pw=0 time=369 us)OF SV_RPR_TRANREQ_IDX01

- 10g Optimizer에 의하여 Driving Table이 변경되었으며, RP_PARTREQ_DETAIL 테이블을 ACCESS할 때, RP_PARTREQ_HEAD_IDX03 인덱스 대신RP_PARTREQ_DETAIL_BTX01 이용하고 있음.

- RULE 힌트를 제거해도 개선되지 않는 경우가 있지만, 다른 방법으로 튜닝하는 것이 RULE 힌트를 사용하는것보다 효율적이다.

튜닝 전 (9i) 튜닝 전 (10g) 튜닝 후 (10g) 조치사항

2.911(Blocks 531,508)

0.020(Blocks 953)

7.4 MBRule 힌트만 제거함.


SELECT "MODELNAME","SALESMODELNAME"

FROM "SV_MODEL_MST" "SV_MODEL_MST"WHERE "MODELNAME"='VPL-FX40'

OR "SALESMODELNAME"='VPL-FX40/90'


Misses in library cache during parse: 1Optimizer goal: CHOOSEParsing user: IPASS (ID=24)


0 STATEMENT2 TABLE ACCESS FULL SV_MODEL_MST


DB 전체에서 자원 사용률 TOP 10 에 포함되는 쿼리임


MODELNAME 컬럼으로는 인덱스가 있지만, SALESMODELNAME컬럼으로는 인덱스가 없으므로OR 로 인한 문제가 발생함.SV_MODEL_MST 테이블에 SALESMODELNAME컬럼에 각각 인덱스를 생성함.

SQL> create index IPASS.SV_MODEL_MST_IDX04 on IPASS.SV_MODEL_MST(SALESMODELNAME) tablespace IPASS_SV_IDX;

SQL> analyze index SV_MODEL_MST_IDX04 compute statistics;




0 STATEMENT1 TABLE ACCESS BY INDEX ROWID SV_MODEL_MST 1 BITMAP CONVERSION TO ROWIDS 1 BITMAP OR 0 BITMAP CONVERSION FROM ROWIDS 0 INDEX RANGE SCAN SV_MODEL_MST_IDX01 OF SV_MODEL_MST_IDX01 (NONUNIQUE)1 BITMAP CONVERSION FROM ROWIDS 1 INDEX RANGE SCAN SV_MODEL_MST_IDX04 OF SV_MODEL_MST_IDX04 (NONUNIQUE)

현상 분석

- 9i R2 이후 버전에서 증가하기 시작하는 Bitmap Conversion 형태의 플랜은 적은 량의 Logical I/O를 추구하며- Where 절의 OR, Not 조건 등에서도 좋은 Access Plan 을 만들어낸다.- 그러나, Index 전략의 부재로 대부분의 Index가 single column으로 구성되는 경우 Bitmap Plan이 항상 좋은 결과

를 가져오지는 않는다. (이 때는 Index Design Chart를 그려보고 전략적인 인덱스 구성을 재설계 하여야 함) ( 3-3 사례 설명 )


SELECT count(*)FROM SV_PICKUP_ORDER AWHERE A.STATUS NOT IN ('2', '090', '100')AND (EXISTS (SELECT 1

FROM VSONYKOR_GET@HLCDBWHERE SUPER_CUST_CD = 249384AND ORD_NO = ORDERNO)

OR EXISTS ( SELECT 1FROM VSONYKOR_PUT@HLCDBWHERE SUPER_CUST_CD = 249384AND ORD_NO = ORDERNOAND TRS_STAT_CD=2))



0 STATEMENT1 SORT AGGREGATE

281 FILTER 674 TABLE ACCESS FULL SV_PICKUP_ORDER 267 REMOTE 14 REMOTE

4.4 Remote Join 쿼리의 튜닝

10g 에서도 OPTIMIZER는 Remote 테이블에 대한 통계 정보를 정확하게 알수 없으므로 튜닝은 튜너의 몫이 됨다.


REMOTE 테이블에 대한 EXISTS 체크시 OR 조건이 사용되면 성능이 떨어질수 있음.

문장을 EXISTS 가 아닌 JOIN 형태로변경하고, OR를 UNION으로 분리하여성능을 개선시킴

select count(*)from ( SELECT A.*

FROM SV_PICKUP_ORDER A, VSONYKOR_GET@HLCDB BWHERE A.ORDERNO = B.ORD_NOAND A.STATUS NOT IN ('2', '090', '100')AND B.SUPER_CUST_CD = 249384

UNIONSELECT A.*FROM SV_PICKUP_ORDER A, VSONYKOR_PUT@HLCDB CWHERE A.ORDERNO = C.ORD_NOAND A.STATUS NOT IN ('2', '090', '100')AND C.SUPER_CUST_CD = 249384AND C.TRS_STAT_CD=2)



0 STATEMENT1 SORT AGGREGATE

281 VIEW 281 SORT UNIQUE 297 UNION-ALL 283 HASH JOIN 2666 REMOTE 　 리모트 테이블이 드라이빙 되면서 WHERE 절의 C.SUPER_CUST_CD = 249384 조건이 선행됨.675 TABLE ACCESS FULL SV_PICKUP_ORDER 14 HASH JOIN 125 REMOTE 　 리모트 테이블이 드라이빙 되면서 WHERE 절의 B.SUPER_CUST_CD = 249384 조건이 선행됨.675 TABLE ACCESS FULL SV_PICKUP_ORDER

4.4 Remote Join 쿼리의 튜닝문장을 조인 형태로 수정하고 OR를 Union으로 풀어서 튜닝함.


REMOTE 테이블 Access시 네트워크Overhead 를 최소화할 수 있는 방향으로 튜닝하여야 함.

좋은 조건(SUPER_CUST_CD = 249384)을 가지고 있는 리모트 테이블이 드라이빙 됨.

( 4-2 사례 설명)

SELECT nvl(B.POINT, '0') POINT, nvl(A.MEMO_CNT, '0') MEMO_CNTFROM ( SELECT COUNT(RECEIVE_ID) MEMO_CNT

FROM CS_RECEIVE_MSGWHERE LOWER(RECEIVE_ID) = 'ao_admin'AND DEL_FLAG = 'N' ) A,

( SELECT SUM(C.POINT) POINTFROM IPASS.GM_USER_MST A, CS_POINT_LOG B, CS_POINT CWHERE A.USERID = B.GAIN_USERAND B.POINT_SEQ = C.POINT_SEQAND LOWER(A.USERID) = 'bpyjwon' ) B



0 STATEMENT1 MERGE JOIN CARTESIAN 1 VIEW 1 SORT AGGREGATE 40 TABLE ACCESS FULL CS_RECEIVE_MSG 1 FIRST ROW 1 VIEW 1 SORT AGGREGATE 0 HASH JOIN 17 TABLE ACCESS FULL CS_POINT 0 NESTED LOOPS

119923 TABLE ACCESS FULL CS_POINT_LOG 0 INDEX UNIQUE SCAN PK_GM_USER_MST OF PK_GM_USER_MST (UNIQUE)

현상 분석

- where 절의 좌변이 lower 함수에 의하여 변경될 수 밖에없는 상황이므로 Function Based Index를 추가하여야 함.


SQL> create index cs_receive_msg_idx01 on CS_RECEIVE_MSG(LOWER(RECEIVE_ID)) tablespace IPASS_RP_PKX;SQL> create index GM_USER_MST_IDX03 on GM_USER_MST(LOWER(USERID)) tablespace IPASS_CM_IDX;




0 STATEMENT1 MERGE JOIN CARTESIAN 1 VIEW 1 SORT AGGREGATE 40 TABLE ACCESS BY INDEX ROWID CS_RECEIVE_MSG 40 INDEX RANGE SCAN CS_RECEIVE_MSG_IDX01 OF CS_RECEIVE_MSG_IDX01 (NONUNIQUE)1 FIRST ROW 1 VIEW 1 SORT AGGREGATE 0 HASH JOIN 0 NESTED LOOPS 1 TABLE ACCESS BY INDEX ROWID GM_USER_MST 1 INDEX RANGE SCAN GM_USER_MST_IDX03 OF GM_USER_MST_IDX03 (NONUNIQUE)0 INDEX RANGE SCAN CS_POINT_LOG_IDX01 OF CS_POINT_LOG_IDX01 (NONUNIQUE)0 TABLE ACCESS FULL CS_POINT

Function Based Index의 추가


Function Based Index의 활용 예.컬럼의 중간부분의 검색

SQL> create index from_ioc_idx on orders(SUBSTR(ship_id, 5, 3));

SQL> create index repair_ord_idx on orders(SUBSTR(ship_id, 3, 2), ord_date);

조인 연결고리 컬럼이 대응하지 않는 경우의 해결

SQL> select …………

From item_group x, items y

Where x.class1||x.class2||x.class3 = y.group_cd

……………………

SQL> create index group_cd_idx on item_group(class1||class2||class3);

158


일자 컬럼이 분할된 경우의 해결

SQL> Where sal_yyyy >= ‘2006’ and sal_mm >= ‘12’ and sal_dd >= ‘10’ (X)SQL> Where sal_yyyy||sal_mm||sal_dd >= ‘20061210’ (0)SQL> create index sal_date_idx on sal(sal_yyyy||sal_mm||sal_dd);

데이터 타입이 상이한 조인 컬럼

Dept 테이블의 deptno 컬럼은 number 타입인데, emp 테이블의 deptno 컬럼은 Varchar2일 경우 조인시 상당한 오버헤드를 감수해야 한다.SQL> create index emp_dept_idx on emp(to_number(deptno));

조인 컬럼이 경우에 따라 달라지는 경우의 조인

Dept 테이블의 deptno 컬럼은 number 타입인데, emp 테이블의 deptno 컬럼은 Varchar2일 경우

조인시 상당한 오버헤드를 감수해야 한다.SQL> From sales s, departments d

Where d.deptno=(CASE WHEN sal_type=1 THEN sal_dept ELSE agent_no END ) AND d.location = ‘PUSAN’

……………………SQL> create index deptno_idx on Sales (CASE WHEN sal_type=1 THEN sal_dept ELSE agent_no END);

159


대/소문자 공백이 혼재된 컬럼의 검색

SQL> create index ename_upper_idx on employees (UPPER(ename));

SQL> create index ename_upper_idx on employees (UPPER(REPLACE(ename, ‘ ‘));

공백제거 후 대문자화

NULL 값의 치환SQL> create index end_date_idx on account_history (NVL(end_date, ‘99991231’));

SQL> where :input_date BETWEEN start_date AND NVL(end_date, ‘99991231’)

SQL> create index end_start_idx on account_history (NVL(end_date, ‘99991231’), start_date);

접두사(prefix)를 채워서 검색SQL> Create index call_number_idx on call_data

(DECODE(SUBSTR(call_number, 1, 3), ‘018’, ‘ ‘ , ‘016’)||call_number);

160


복잡한 계산 결과의 검색SQL> Create index order_amount_idx on order_items(ITEM_CD, (order_price – nvl(order_discount, 0) * order_count));SQL>SELECT /*+ INDEX_DESC(x order_amount_idx) */ *

From order_items xWhere x.item_cd = :b1

and ROWNUM < 100;

Execution Plan===============================================================================SELECT STATEMENT Optiomizer = FIRST_ROWSCOUNT (STOPKEY)

TABLE ACCESS (BY INDEX ROWID) OF ‘ORDER_ITEMS’

INDEX (RANGE SCAN DESCENDING) OF ‘ORDER_AMOUNT_IDX’

기간, 컬럼 길이 검색SQL> Create index term_idx on activities (expire_date - start_date);SQL> Create index source_length on print_media (text_length(source_text));

161


SELECT child_part AS child_part ,lpk AS lpk

FROM (SELECT DISTINCT child_part AS child_part ,

decode( :as_override_lpk , 'Y' , '%' , lpk ) AS lpk ,'ISS' AS req_type

FROM tissod WHERE obu = :as_obu AND child_part LIKE decode( :as_part_no , 'ALL' , '%' , :as_part_no )

AND lpk LIKE decode( :as_override_lpk , 'Y' , '%' , decode( :as_lpk , 'ALL' , '%' , :as_lpk ) )

AND SUBSTR( prep_dept , 1 , 1 ) IN ( 'G' , 'D' , 'N' , 'S' , 'K' , 'L' , 'M' )

AND filter = 'N' AND NVL(exp_iss_qty,0) > NVL(iss_qty,0) + NVL(rep_part_iss_qty,0) AND bom_level <> 0 AND bom_seq <> 0

.

.

.

2.1 인덱스

SQL 구문 ▶ 현상 ▶ 문제점 및 개선방안 ▶ 튜닝 결과

사례. Function-Based 인덱스를 이용한 튜닝 - (1/5)

162


2.1 인덱스

• 너무 오래 걸려서 중간에 중지함

call count cpu elapsed disk query current rows------- ------ -------- ---------- ---------- ---------- ---------- ----------Parse 1 0.00 0.00 0 0 0 0Execute 1 0.00 0.00 0 0 0 0Fetch 1 210.81 973.46 820735 1577609 0 0------- ------ -------- ---------- ---------- ---------- ---------- ----------total 3 210.81 973.46 820735 1577609 0 0

Misses in library cache during parse: 1Optimizer goal: RULEParsing user id: 37 (PMS)

Rows Execution Plan------- ---------------------------------------------------...

0 SORT (UNIQUE)0 FILTER0 TABLE ACCESS GOAL: ANALYZED (BY INDEX ROWID) OF 'TISSOD'

1605913 INDEX GOAL: ANALYZED (RANGE SCAN) OF 'ISSOD_OBU_LPK_CHILD_EXPDATE_I' (NON-UNIQUE)

0 SORT (UNIQUE)0 FILTER...

사례. Function-Based 인덱스를 이용한 튜닝 – (2/5)


163


① 조건에 사용된 각 컬럼에 대해 조회를 해본 결과 null 값이 없으므로 필요 없는 NVL을 제거하고,

조건에 맞는 function index를 생성하여 속도가 개선되도록 수정함

① data가 매우 많은 tissod 테이블을 접근 시, 비효율적인 인덱스를 사용하여 속도가 매우 오래 걸림

② 건수를 많이 줄여주는 조건은 다음 조건입니다.

NVL( exp_iss_qty , 0 ) > NVL( iss_qty , 0 ) + NVL( rep_part_iss_qty , 0 )

< 실행계획 분석 >

< 인덱스 정보>

ISSOD_OBU_LPK_CHILD_EXPDATE_I : OBU, LPK, CHILD_PART, EXP_ISS_DATEISSOD_QTY_CHILD_FILTER_I: SIGN(EXP_ISS_QTY - REP_PART_ISS_QTY - ISS_QTY ), CHILD_PART, filter, exp_iss_date

<인덱스 구성 컬럼 표현>

NVL( exp_iss_qty , 0 ) > NVL( iss_qty , 0 ) + NVL( rep_part_iss_qty , 0 ) exp_iss_qty - iss_qty - rep_part_iss_qty > 0

SIGN(exp_iss_qty - iss_qty - rep_part_iss_qty) = 1

CREATE INDEX PMS.ISSOD_QTY_CHILD_FILTER_I

ON PMS.TISSOD ( SIGN(EXP_ISS_QTY - REP_PART_ISS_QTY - ISS_QTY ), CHILD_PART, filter, exp_iss_date)

TABLESPACE PMS_IDX

2.1 인덱스



164


건수를 많이 줄이는 조건에 맞는 function index를 생성하여 속도가 개선되도록 수정함1

SELECT child_part AS child_part ,lpk AS lpk

FROM (SELECT /*+ index(tissod ISSOD_QTY_CHILD_FILTER_I) */

DISTINCT child_part AS child_part ,decode( :as_override_lpk , 'Y' , '%' , lpk ) AS lpk ,'ISS' AS req_type

FROM tissod WHERE obu = :as_obu AND child_part LIKE

decode( :as_part_no , 'ALL' , '%' , :as_part_no ) AND lpk LIKE decode( :as_override_lpk , 'Y' , '%' ,

decode( :as_lpk , 'ALL' , '%' , :as_lpk ) ) AND SUBSTR( prep_dept , 1 , 1 ) IN

( 'G' , 'D' , 'N' , 'S' , 'K' , 'L' , 'M' ) AND filter = 'N' AND SIGN(EXP_ISS_QTY - REP_PART_ISS_QTY - ISS_QTY ) = 1AND bom_level <> 0 AND bom_seq <> 0

...

1

2.1 인덱스


SQL 구문 ▶ 현상 ▶ 문제점 및 개선방안 ▶ 튜닝 결과(1/2)

165


call count cpu elapsed disk query current rows------- ------ -------- ---------- ---------- ---------- ---------- ----------Parse 1 0.00 0.00 0 0 0 0Execute 1 0.00 0.00 0 0 0 0Fetch 3 6.52 25.99 9024 27995 6 27------- ------ -------- ---------- ---------- ---------- ---------- ----------total 5 6.52 25.99 9024 27995 6 27

Rows Execution Plan------- ---------------------------------------------------

.

..

1315 SORT (UNIQUE)7578 FILTER7578 TABLE ACCESS (BY INDEX ROWID) OF 'TISSOD'8086 INDEX (RANGE SCAN) OF ISSOD_QTY_CHILD_FILTER_I' (NON-UNIQUE)2353 SORT (UNIQUE)

146779 CONCATENATION146779 FILTER

.

..

Function Index를 사용하여 973초 이상 수행되던 SQL이 25.99초로 감소함

2.1 인덱스


SQL 구문 ▶ 현상 ▶ 문제점 및 개선방안 ▶ 튜닝 결과(2/2)

166


Diagnose hint usagePurpose : Starting with 10g development has rewritten the code that handle the hint usage in the CBO. Before 10g

is was not possible to see why a hint was not used. Now there is a way with a 10053 event output to get more information about the hint usage.

Dumping Hints ============= atom_hint=(@=1E1003B0 err=0 resol=1 used=0 token=454 org=1 lvl=2 txt=ALL_ROWS )

This shows that a all rows hint was used and the err is 0 is means the hint is accepted.If the hint could not be used than there are different errors code. As example

4.6 10053 EVENTS New Features

Dumping Hints ============= atom_hint=(@=1E249C2C err=4 resol=1 used=0 token=83 org=1 lvl=3 txt=INDEX ("EMP" "HUGO") ) atom_hint=(@=1E249DA0 err=4 resol=1 used=0 token=448 org=1 lvl=3 txt=FULL ("EMP") )

select /*+ full(emp) index( emp, hugo) */ count(*) from emp

alter session set events '10053 trace name context forever, level 1';

alter session set events '10053 trace name context off';

It Gives Output…

0 ACCEPT_qkshtError, /* hint accepted without errors */1 PARSE_qkshtError, /* parse error */2 USED_qkshtError, /* hint was used */3 INTERNAL_qkshtError, /* internally generated hint is being cleared */4 SIBLING_qkshtError, /* hint conflicts with another in sibling qbc */5 PARENT_qkshtError, /* hint overridden by another in parent qbc */6 MODE_qkshtError, /* conflicting optimizer mode hints */7 DUPLICATE_qkshtError, /* duplicate hint */8 NOJOINS_qkshtError, /* all join methods are excluded by hints */9 NOINDEX_qkshtError, /* index specified in the hint doesn't exist */

10 NOIXPARALLEL_qkshtError, /* index specified in hint cannot be parallelized */11 ANDEQINDC_qkshtError, /* incorrect number of indexes for AND_EQUAL */12 PARTVIEWSETUP_qkshtError, /* partition view set up */13 IOTFULLEQFFS_qkshtError, /* FULL hint is same as INDEX_FFS for IOT */14 INVALIDIOTACC_qkshtError, /* access path is not supported for IOT */15 NOPUSHVIEW_qkshtError, /* hint on view cannot be pushed into view */16 NOPULLVIEW_qkshtError, /* hint is discarded during view merging */17 MTBDUPTAB_qkshtError, /* duplicate tables in multi-table hint */18 NOARRVECREAD_qkshtError, /* conditions failed for array vector read */19 CONFLQBNAME_qkshtError, /* same QB_NAME hints for different qbcs */20 IGN_OPT_EMBEDDED_qkshtError, /* rejected by IGNORE_OPTIM_EMBEDDED_HINTS */21 POSINTEGER_qkshtError, /* specified number must be positive integer */22 POSNUMBER_qkshtError, /* specified number must be positive number */23 POSFRACTION_qkshtError, /* specified number must be >= 0 and <= 1 */24 NODYNSAMP_qkshtError, /* specified number must be >= 0 and <= 1 */25 SERIALONLY_qkshtError, /* hint is only valid for serial SQL */26 SLAVEONLY_qkshtError, /* hint is only valid for slave SQL */27 DYNSAMPONLY_qkshtError, /* hint is only valid for dyn. samp. query */28 UPJOINIXONLY_qkshtError, /* hint is only valid for update join ix qry */29 OPTESTNOVAL_qkshtError, /* opt_estimate() without value list */30 OPTESTCONFLICT_qkshtError, /* opt_estimate() with conflicting values spec */31 NOTRANSFORMATION_qkshtError, /* hint overridden by NO_QUERY_TRANSFORMATION */32 QBNAMETOOLONG_qkshtError, /* hinted query block name is too long */33 UNRESOLVED_BMTREE_qkshtError, /* hinted bitmap tree wasn't fully resolved */34 INVALID_BMTREE_qkshtError /* bitmap tree specified was invalid */

4.6 10053 EVENTS New Features [Error codes reason for err in atom_hint ]

select SO_CASE.SOCASEID,……………………… (Many Select list)SO_CONTACT.SONOTES,SO_CONTACT.SOPHONE1,SO_CONTACT.SOPHONE2,SO_CONTACT.SOFAX1

from SO_CASE ,SO_CONTACT

where SO_CASE.SOCONTACTID = SO_CONTACT.SOCONTACTIDand ((SO_CONTACT.SOLASTNAME='*더미*')

and (SO_CASE.SWDATECREATED BETWEEN to_date('20080315', 'YYYYMMDD') and to_date('20080316', 'YYYYMMDD') + .99999)and (SO_CASE.SOCONDITION<>'완료'))



0 STATEMENT168 TABLE ACCESS BY INDEX ROWID SO_CASE (cr=86134 pr=85141 pw=0 time=25636158 us)

405808 NESTED LOOPS (cr=1287 pr=1037 pw=0 time=5687168 us)120 TABLE ACCESS BY INDEX ROWID SO_CONTACT (cr=82 pr=0 pw=0 time=8415 us)120 INDEX RANGE SCAN SO_CONTACT_IDX01 (cr=4 pr=0 pw=0 time=2303 us)OF SO_CONTACT_IDX01 (NONUNIQUE)

405687 INDEX RANGE SCAN SO_CASE_IDX01 (cr=1205 pr=1037 pw=0 time=1189100 us)OF SO_CASE_IDX01 (NONUNIQUE)

********************************************************************************

OUTLINE을 이용한 Package 프로그램의 튜닝 사례


select /*+ LEADING(SO_CASE) USE_HASH(SO_CASE SO_CONTACT) */ SO_CASE.SOCASEID,……………………… (Many Select list)SO_CONTACT.SONOTES,SO_CONTACT.SOPHONE1,SO_CONTACT.SOPHONE2,SO_CONTACT.SOFAX1



and (SO_CASE.SWDATECREATED BETWEEN to_date('20080315', 'YYYYMMDD') and to_date('20080316', 'YYYYMMDD') + .99999)and (SO_CASE.SOCONDITION<>'완료'))


Misses in library cache during parse: 1Optimizer goal: ALL_ROWSParsing user: SONY (ID=57)


0 STATEMENT168 HASH JOIN (cr=1060 pr=0 pw=0 time=33709 us)1005 TABLE ACCESS BY INDEX ROWID SO_CASE (cr=978 pr=0 pw=0 time=18228 us)1005 INDEX RANGE SCAN SO_CASE_IDX02 (cr=6 pr=0 pw=0 time=2122 us)OF SO_CASE_IDX02 (NONUNIQUE)120 TABLE ACCESS BY INDEX ROWID SO_CONTACT (cr=82 pr=0 pw=0 time=2480 us)120 INDEX RANGE SCAN SO_CONTACT_IDX01 (cr=4 pr=0 pw=0 time=429 us)OF SO_CONTACT_IDX01 (NONUNIQUE)

문제는 이 패키지 프로그램의 유지보수 업체가 도산하여 소스 프로그램에서 힌트를 적용할 수 없다는 것. !!



◑ OUTLINE을 적용하는 방법

Let's call the SQL statement to optimize 'ORIGINALSQL' 1. Find the hints to optimize the original SQL statement.

Let's call the same SQL statement with hints 'HINTEDSQL' 2. Create the OUTLINE for ORIGINALSQL 3. Create the OUTLINE for HINTEDSQL 4. Exchange the OUTLINE plan between the two OUTLINES 5. Drop the OUTLINE for HINTEDSQL 6. Now the OUTLINE plan for ORIGINALSQL is the same as the execution plan of HINTSQL which uses HINTs.

① SYS 유저로DATABASE 는 QUERY_REWRITE_ENABLED=TRUE, USE_STORED_OUTLINES=TRUE로 설정되어야 함.SQL> alter system set query_rewrite_enabled=true;System altered.SQL> alter system set use_stored_outlines = true;System altered.

② SYS 유저로SQL> grant create any outline to scott;Grant succeeded.SQL> grant drop any outline to scott;Grant succeeded.



③ SCOTT 유저로CREATE OR REPLACE OUTLINE ORIGINALSQL ONselect SO_CASE.SOCASEID,

……………………… (Many Select list)SO_CONTACT.SONOTES,SO_CONTACT.SOPHONE1,SO_CONTACT.SOPHONE2,SO_CONTACT.SOFAX1



and (SO_CASE.SWDATECREATED BETWEEN to_date('20080315', 'YYYYMMDD') and to_date('20080316', 'YYYYMMDD') + .99999)and (SO_CASE.SOCONDITION<>'완료'));

CREATE OR REPLACE OUTLINE HINTEDSQL ONselect /*+ LEADING(SO_CASE) USE_HASH(SO_CASE SO_CONTACT) */

SO_CASE.SOCASEID,……………………… (Many Select list)SO_CONTACT.SONOTES,SO_CONTACT.SOPHONE1,SO_CONTACT.SOPHONE2,SO_CONTACT.SOFAX1



and (SO_CASE.SWDATECREATED BETWEEN to_date('20080315', 'YYYYMMDD') and to_date('20080316', 'YYYYMMDD') + .99999)and (SO_CASE.SOCONDITION<>'완료'));



④ SYS 유저로UPDATE OUTLN.OL$HINTSSET OL_NAME=DECODE(OL_NAME,'HINTEDSQL','ORIGINALSQL','ORIGINALSQL','HINTEDSQL') WHERE OL_NAME IN ('ORIGINALSQL','HINTEDSQL'); commit;

⑤ SCOTT 유저로drop outline hintedSQL;

⑥ 확인SQL> explain plan for

힌트가 적용되지 않은 ORIGINAL SQL 을 실행한다.-----------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost |-----------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 198 | 54252 | 12750 || 1 | FILTER | | | | || 2 | HASH JOIN | | 198 | 54252 | 12750 || 3 | TABLE ACCESS BY INDEX ROWID| SO_CASE | 8291 | 1846K| 12530 || 4 | INDEX RANGE SCAN | SO_CASE_IDX12 | 17412 | | 164 || 5 | TABLE ACCESS BY INDEX ROWID| SO_CONTACT | 197 | 9062 | 189 || 6 | INDEX RANGE SCAN | SO_CONTACT_IDX01 | 197 | | 4 |-----------------------------------------------------------------------------------



튜닝 전 (9i) 튜닝 후 (9i) 튜닝 후 (9i/10g) 조치사항

77.399 초

(Blocks 86134)

0.056 초

(Blocks 1060)OUTLINE을 적용함.

세션 1. 10g 업그레이드 계획의 수립 [09:30 ~ 11:00]

세션 2. Upgrade 시 고려사항 및 SQL NF [11:00 ~ 12:00]

세션 3. 10g CBO의 이해 및 통계관리 [13:00 ~ 15:00]

세션 4. 실무 업그레이드 프로젝트 사례 [15:00 ~ 16:00]

세션 5. 11g Upgrade New Features [16:00 ~ 17:00]

목 차

세션 5. 11g Upgrade New Features

5.1 Oracle 11g Database Replay의 소개

첨부2. 참조

수고하셨습니다

10g upgrade 실무사례 · data general intel unix hp alpha openvms hp tru64 unix hp-ux itanium...

Documents