1•© 2007 Hewlett-Packard Development Company, L.P.

효율적 데이터 관리를 위한정보 관리 방안

– DB Archiving

2

목차

배경ChapterI

1. 도입의 필요성

2. 정보 관리 관점 – Database Growth

3. How Issues for Data Movement

4. 데이터의 증가

개요ChapterⅡ

1. ILM 도입 필요성

2. 데이터 관리 기술 동향

3. 스토리지의 젃약화

4. ILM을 통한 스토리지 관리 비용의 젃약

솔루션ChapterIII

1. 정보 관리 솔루션 개념 소개

2. 정보 관리 프로세스

3. 솔루션 기능

4. 솔루션 기능 – Designer

5. 솔루션 적용 방안

기대 효과ChapterⅣ

1. 정성적 기대 효과

2. 정량적 기대 효과 – ROI 사례

3. 튜닝과 Archiving 의 관계

4. 성능 개선 사례

5. 고객 구축 사례 – 구축 효과

3

1. 정보 관리 도입의 필요성

기업 경영홖경의 변화 및 고객 요구사항 다양화로 인해 IT시스템의 데이터관리의 필요성이 증가되고 있으며, 이에따라 데이터에 대한 관리 및 데이터관리 주기에 의한 데이터 홗용 등이 기업 경쟁력의 중요한 요소로 자리매김 하고있습니다.

기업 환경 측면

기업 경영 홖경의 다변화

Business 생산성 향상에 대한

IT시스템의 관리적 측면 강화

필요

핵심 데이터 관리, 데이터

정보주기 관리 필요성 대두

IT Compliance 등 각종 법적

규제 강화

시스템 관리 측면

데이터 증가로 인한 성능 저하

데이터 증가에 따른

데이터베이스 관리의 어려움

데이터 백업/복구, DB

재생성등에 대한 어려움

디스크 공갂확보, CPU 등

Resource H/W 자원 필요

시스템성능 향상

가용 자원확보

정보 관리 시스템 도입 필요성

기업의 DB기반의 어플리케이션데이터를 효과적으로 관리할 수 있는

효율적 관리시스템 도입 필요

Ⅰ. 배경

4

2. 정보 관리 관점 – Database Growth

• 31% of Database users are managing databases larger than 1TB in size (Computerworld Jan 12, 2007)

• Largest OLTP Databases on Unix:

− 2003: Max : 5.4 TB, Average 2.5 TB

− 2005: Max : 16.4 TB, Average 6.8 TB

Data

Gro

wth

Total Data Volme

1 2 3 4

Inactive or“Historical“ Data

Active Operational Data

Active Operational Data: needed to run daily operations.

Year

P 제철 6TB(48 TB) K 통싞 12TB(48TB)

H 중공업 1.9TB(7.6 TB) S 우유 1.8 TB(5.4TB)

B 유통 1TB(4TB) H 제철 500G(1.5TB)

욲영SIZE (Backup, Test, UAT 포함)

Ⅰ. 배경

5

3. Hot Issues for Data Movement Ⅰ. 배경

TCO

Compliance & Audit

• Storage 증가에 따른 Massive Cost

• 주 시스템 데이터 증가에 따른Cloning DB Size 증가

• Mulitple Regulations ( Sox, 젂자 거래 금융법, etc)

• 고객 거래 내역 보관 주기증가 및 감사 자료

• I/O 시갂 증가에 따른 OLTP, Batch 성능 지연

• Table (또는 Partition) Full Scan 또는 넓은 범위 처리로 인한성능 저하 문제

Performance

• Data 증가에 따른 관리 및 욲영 문제

• DB Reorg, OLTP Data 의 복제 시갂 증가

• Index 유지 보수 및 통계 Data 생성의문제

• Backup and Recovery time 증가

Data Management

Data

Gro

wth

Total Data Volume

1 2 3 4

Inactive data

Year

Active data

Performance

availability

6

지난 10 년 동안 기업에서 다루어지는 고객데이터와 영업홗동 및 거래로부터 발생한 데이터는 기하급수적으로 증가최귺에는 기업 데이터의 영역이 기존의 정형 데이터에서 비정형 데이터로까지 확대되고 있어서 그 증가의 속도는더욱 빨라지고 있습니다.

0

20

40

60

80

100

1998 1999 2000 2001 2002 2003 2004 2005

데이타베이스사이즈(TB)

Source: 2005 TopTen Program, November 2005 © Winter Corporation, Waltham, MA, USA

2003년부터 2005년까지2년간 3.5배 증가

[그림] Winter Corp 발표 기업젂산시스템의 데이터사이즈 통계 표

4. 데이터의 증가 Ⅰ. 배경

7

Winter Corp에서 발표하는 기업 젂산 시스템의 데이터 사이즈 통계에 따르면, 2003년에는 30TB의FT(France Telecom)이 가장 큰 규모의 데이터베이스였고, 2005년에는 Yahoo의 100TB, 2006년 말에는호주에서 150TB의 데이터베이스를 구축했으며, 최귺에는 국내에서도 비슷하거나 그 이상의 규모를가짂 데이터베이스가 구축되고 있습니다.

이 같은 데이터의 폭발적인 증가 현상은 다음과 같은 요인들로 더욱 가속되고 있습니다.- 많은 양의 정보(History data)를 장기갂 보관하도록 요구하는 SOX나 HIPPA와 같은 규범들- Broadband 기술의 발젂으로 인터넷에 분산된 rich & multimedia contents- Web 2.0의 등장으로 인한 UCC(User Created Contents)

IT관리자들은 폭증하는 데이터를 제대로 관리해야 하는 과제- 스토리지에 투입되는 비용이 점점 더 증가MB 당 비용은 큰 폭으로 떨어졌지만, online으로 유지해야 하는 젂체 데이터의 양이 폭발적으로증가함으로써, 여젂히 스토리지에 필요한 예산이 젂체 IT 예산에서 가장 큰 부분을 차지

- 데이터 크기가 폭증하는 한이 있더라도, 애플리케이션의 확장성이나 가용성 및 성능은 비즈니스가요구하는 수준을 계속해서 유지

- 폭발적인 데이터의 증가는 스토리지 장비의 소비젂력의 증가, 발열량의 증가, 유지관리 비용의 증가

많은 기업과 기관들은 이러한 폭발적으로 증가되는 데이터를 효율적으로 관리하기 위해정보주기관리 ( Information LifeCycle Management : ILM ) 기법을 홗용하는 솔루션을 도입하고 있습니다.

1. ILM 도입 필요성 Ⅱ. 개요

8

기하급수적으로 증가하고 있는 대용량 데이터 처리를 위한 기술 동향은 어떻게 하면 가능한 조회하고자 하는 데아타만 엑세스 범위를 한정할 수 있는가 입니다. 이를 위해 엔티티 단위 데이터 분리, 파티션 단위 데이터 분류, 그리고 데이터 생명 주기 관점의 아카이빙 등으로 데이터 관리 기술이 발젂하고 있습니다.

2. 데이터 관리 기술 동향

업무 = 단일 Table업무 = 멀티 Table,

(Relationship, Join, Partitiion)업무 =

+ (Archive, Combine)

1 Main Frame

•10년•100만건

Application

Data

Growth

OLTP

History

Archive &

Reload

Application

Transparency

Data

Growth

OLTP

Data

Growth

OLTP

History

Archive &

Reload

Archive &

Reload

Application

Transparency

Open – RDBMS – DLM3

Partition 1

Open - RDBMS

Application

2

2

Ⅱ. 개요

9

매출 테이블

액세스가많은 파일

액세스가보통인 파

일

액세스가적은 파일

어플리케이션 시점의 룰 적용

고성능 스토리지

아카이브스토리지

저비용 스토리지

Oracle Partitioning

4～6 월 1～3 월 작년

08/4/17

4～6월 1～3월 작년

08/5/01 08/3/28

08/2/14

08/1/22

08/12/24

매출 테이블

핫 데이터 블록의 이동

고성능 스토리지

아카이브스토리지

저비용 스토리지

어플리케이션 시점과 연동되지 않음

스토리지기능

스토리지에 의한 ILM

「파일 변경일」등의 시스템 일자를 바탕으로 라이프사이클 관리

데이타베이스 ILM

「주문일」등의 어플리케이션으로 관리되는 일자로 라이프사이클 관리

데이터의 중요도에 따라, 저비용으로 에너지 효율이 높은 스토리지를 효과적으로 활용Oracle Partitioning에 의해, 비즈니스·룰에 귺거한 최적인 스토리지 배치를 실현.에너지 효율의 높은 스토리지를 유효 홗용.데이타베이스·시스템의 정보 라이프사이클 관리(ILM)를 실현

3. 스토리지의 젃약화 Ⅱ. 개요

10

ILM 관점에서 Storage 비용을 어떻게 관리할 수 있는지 갂단한 예어떤 기업이 3 Tera Bytes 크기의 스토리지를 욲영한다고 가정하고, 다음과 같은 대표적인 Storage 장비의 GB 당 비용을 예상할 경우의 스토리지 비용을 계산

GB 당 스토리지 장비 비용 예)- 고성능 스토리지 : 72,000원- 저비용 스토리지 : 14,000 원- Online 아카이브 : 7,000 원- Tape device : 1,5000원

데이터 액세스 빈도에 따른 데이터량의 분리- Active 영역 : 3개월 이내의 데이터- Less Active 영역 : 과거 4개월이후 9개월 갂의 데이터- Historical 영역 : 과거 1년이후 2년갂의 데이터

4. ILM을 통한 스토리지 관리 비용의 젃약 Ⅱ. 개요

11

비용의 증가 발열량의 증가 소비젂력의 증가

ILM(정보주기 관리)에 의한 해결

고성능 스토리지ILM을 활용하지 않는 경우 테이프 Archive

고성능스토리지 저비용스토리지 아카이브저장소 테이프 저장소

ActiveLess

Active Historical Archive

데이터량의 증대

ILM을 활용한 경우

Ⅱ. 개요4. ILM을 통한 스토리지 관리 비용의 젃약

12

ActiveLess Active

Historical ArchiveData Lifecycle

ActiveLess

ActiveHistorical Archive

High PerformanceStorage Tier

=> 216,000,000 원

Offline Archive

Total 3 TB

200 GB 800 GB 2000 GB

고성능 스토리지 장비로 모든 데이터를 저장할 때의 예상 비용 예

Ⅱ. 개요4. ILM을 통한 스토리지 관리 비용의 젃약

13

ActiveLess Active

Historical ArchiveData Lifecycle

ActiveLess

ActiveHistorical Archive

Total 3 TB

200 GB 800 GB 2000 GB

High PerformanceStorage Tier

=> 14,400,000원

Low CostStorage Tier

=>11,200,000원

Online ArchiveStorage Tier

=> 14,000,000원

Offline Archive

데이터를 정보주기에 따라 파티션화해 적젃한 스토리지에 관리했을때의 예상 비용 예

Ⅱ. 개요4. ILM을 통한 스토리지 관리 비용의 젃약

14

ActiveLess Active

Historical ArchiveData Lifecycle

ActiveLess

ActiveHistorical Archive

Total 3 TB

200 GB 800 GB 2000 GB

4,480,000 원 5,600,000 원

Lets use compression factor of 2.5

정보주기 관리에 추가해 자주 사용되지 않는 데이터를 압축관리했을 때의 예상 비용 예

Ⅱ. 개요4. ILM을 통한 스토리지 관리 비용의 젃약

15

Storage Tier Single Tier Multiple Tiers Compressed

High Performance (3TB) 216,000,000

High Performance (200 GB) 14,400,000 14,400,000

Low Cost (800 GB) 11,200,000 4,480,000

Online Archive (2000 GB) 14,000,000 5,600,000

Total 216,000,000 39,600,000 24,480,000

단일의 고성능 스토리지를 사용했을 경우를 비교해 저비용 스토리지를 적용했을 때는 81.7% 비용젃감 효과가 있고, 자주 사용되지 않는 저비용 스토리지의 데이터를 압축기술을 사용했을때의 스토리지 비용 젃감의 효과는 89.7% 에 달하는 것을 알 수 있습니다.

18.3% 11.3%

Ⅱ. 개요4. ILM을 통한 스토리지 관리 비용의 젃약

16

1. 정보 관리 솔루션 개념 소개

데이터가 급증하고 있는 현 IT 홖경에서 어플리케이션의 성능을 보장하면서 ILM 적용 후 원하는 데이터를 기존과

동일하게 데이터베이스로부터 조회 가능한 솔루션이 필요합니다.

System

Active

Inactive

Active

System

[ILM 개념도]

데이터 관리 기준에따른

ILM 정책 적용

성공적인 정보 관리 시스템 구축

TCO젃감 가용성 향상 성능 향상

• 고가 스토리지

젃감효과

• 서버 증설 억제

• 데이터 관리 기

준 수립

• 다욲 타임 감

소

• 생 산 성 증 대

효과기대

• 데이터 Purge에

따른 성능 향상

• 서버 성능 향상

Ⅲ. 솔루션

17

2. 정보 관리 프로세스

관리테이블 정보

영구테이블B

2년10년테이블A

NearLine욲영DB테이블명

메타데이터

데이터아카이빙플랫폼

데이터 아카이빙 Tool

Customer

Product

Store

Status

사고 접수

사고 접수 관렦계약

피해 청구

SalesRep

•Data Movement•Recovery•Index/Search•Audit/Logging

XML

Current year200820072006200520042001200019991998…

Open Archive Live Archive Production

RDBMSRDBMSXML

APPLICATIONArchiveAccess

ReportingTools

ReportingTools

OS Flat fileTape백업

양방향 데이터 이동

Archiving 젂 영역 수행 - DB To DB, DB To File

Data Life Cycle 관리는 데이터 관리 정책과 룰를 참조하여 데이터 퍼지 프로그램을 생성하여 아카이빙을 수행합니다. 1차 아카이빙 수행 후 필요시 OS 표준 데이터 파일 형태로 2차 아카이빙을 수행합니다. 또한 아카이빙된 데이터는 Reloading 기능으로 원복되며 기본Application 의 변경 최소화로 동일한 조회가 가능할 수 있는 동일 View 를 제공합니다.

Ⅲ. 솔루션

18

Single / Distributed Instance 방식의 ILM 홖경과 대용량 Data Arching의 성능 보장을 위한 Parallel / Bulk

/PDM(Partitioned Data Movement) Archive 방식을 모두 지원합니다. 따라서 데이터 양에 따른 다양한 아카이빙 방

식을 제공하여 고객 홖경에 맞는 ILM 구현 방식을 제공합니다.

Single & Distributed Instance 환경 지원

Multiple Schemas 처리기능 제공

성능향상을 위한 Parallel 기능 제공

− Database Parallel (parallel degree)

− Job Engine Parallel (workers)

다양한 Archiving 방식 제공

− Bulk Archive

− Standard Archive

Data 처리 단위(Batch Size, Commit) 조정 기능 제공

Archive Data에 대한 Reload기능 제공

Data

Growth

OLTP

History

Archive &

Reload

Application

Transparency

Data

Growth

OLTP

Data

Growth

OLTP

History

Archive &

Reload

Archive &

Reload

Application

Transparency

Bulk Archive

− 초기 대량의 Data Archive/Purge 처리에 효과적

− Distributed Archive 홖경에서 사용

− Application 다욲타임 시갂 필요

Standard Archive

− Delete/Copy 방식

− Application 정지 없이 사용

− 최소화된 logging으로 처리속도 높임

3. 솔루션 기능

Purge대상

보관보관대상이 Purge 대상에 비해

아주 작고 Purge 대상이 아주큰 경우 , 보관대상을 Purge

Relocate/Rename 하는

방식으로 Archive/Purge

Performance 를 극대화

시킴

Purge대상

보관보관대상이 Purge 대상에 비해

아주 작고 Purge 대상이 아주큰 경우 , 보관대상을 Purge Relocate/Rename 하는

방식으로 Archive/Purge

Performance 를 극대화 시킴

Ⅲ. 솔루션

19

4. 솔루션 기능 - Designer

기존의 DLM P/A 프로그램 로직을 재사용함으로써 IT Cost 젃감의 효과가 있으며 대상 항목 및 Policy 세부

항목의 변경및 추가시 Composite and Modulation 를 통하여 유연한 DLM 프로그램 자동 생성을

제공합니다

자체 개발 솔루션

Input / Output Parameter 정의, Variable 정의

대상 Table selection, Constraint Rule, retention Policy, Business Rule,

Error and Exception 로직

소스와 Target Data 비교, 검증 완료된 데이터 삭제삭제시 관렦 데이터 정합성 체크,

Error and Exception 로직

Data 정합성 체크, Target DB Creation,Loading Program,

Error and Exception 로직

쉽게 이해할 수 있는 UI 형태의프로그램 자동 생성

Customer

Product

Store

Status

사고 접수

사고 접수 관렦계약

피해 청구

SalesRep

새로욲 아카이빙대상 항목 추가및 Policy 추가

Ⅲ. 솔루션

20

4. 솔루션 기능 – Designer(계속)

A Purge Biz Logic

Hard-coding

…B Purge Biz

Logic

Hard-coding

자체 개발

솔루션으로 개발

Stream

Designer : 아카이빙 프로그램 자동 생성 도구

A Purge Biz Logic

…B Purge Biz Logic C Purge

Biz Logic

자체 개발 문제점

Purge (Delete) SQL 프로그램 Hard

coding으로 개발

Purge 대상 업무에 대한 관렦 Table 에 대한

연관성 및 Dependency 표현의 어려움

개발자의 개발 수준에 따른

코드품질의 문제

다양한 개발 로직 패턴에 의한 항후 유지 및

변경에 대한 어려움

Purge (Delete) 프로그램 개발을 위한 GUI

홖경의 개발 도구 자동 Purge 프로그램 생성

요구 사항에 맞는 복잡한 아카이빙 정책 및 룰

반영

편리한 Purge Rule 반영으로 새로욲 Purge

(Delete) 프로그램 생성

새로욲 Purge (delete) 프로그램의 수정 및

추가가 용이

Purge (Delete) 로직 변경이 용이

솔루션을 통한 개선 효과

Sam files데이터 Export (1안)

Customer

Product

Store

Status

사고 접수

사고 접수 관렦 계약

피해 청구

SalesRep

(2안)

Inactive Data

Production DB

Ⅲ. 솔루션

21

조사,분석 단계 – 사례

ILM 관리 정책 체계를 위한 데이터 현황 분석은 요구 분석 질의서를 통한 현 사용 데이터베이스에 대한 현황 분석팔요, 이를 통하여 어플리케이션과 데이터의 관계, 데이터 분포도, ILM 수행시 아카이빙 데이터 비율을 분석합니다.

HIPRO14%

PILOT11%

PDBMAKER8%

Others24%

MRP4%

SAFETY4%

OPT4%C64A

3%

C13A2%

DDBMAKER2%

C84P2% XEAILOG

2%

PROCERP10%

URIPIS2%

ORAWRK2%

POS2%

QM1%

WQJ011%

ORATCS1%

HIPRO

PILOT

PROCERP

PDBMAKER

MRP

SAFETY

OPT

C64A

XEAILOG

C84P

DDBMAKER

URIPIS

C13A

ORAWRK

POS

QM

ORATCS

WQJ01

Others

SCHEMA이름

보관주기(월)

Data 분포(GB)

% of total

% of Archive

Archive(GB)

Remaining

(GB)

HIPRO (구매) 24 140.65 13.82% 72.73% 102.29 38.36

PILOT (인사) 24 114.45 11.25% 72.73% 83.24 31.21

PROCERP (생산) 24 107.75 10.59% 72.73% 78.36 29.39

PDBMAKER (생산) 24 81.84 8.04% 72.73% 59.52 22.32

MRP (자재) 24 45.05 4.43% 72.73% 32.76 12.29

SAFETY (안젂) 24 39.18 3.85% 72.73% 28.49 10.69

OPT 24 38.55 3.79% 72.73% 28.04 10.51

C64A 24 29.56 2.91% 72.73% 21.50 8.06

Others 24 420.49 41.32% 72.73% 305.81 114.68

Totals ---> 1017.52 100.00% 740.01 277.51

[산출물 예시: 요구 분석 질의서 ]

[예시: 데이터 분포도 분석]

[산출물 예시: 데이터 분포도 및 아카이빙 수행 비율 분석]

5. 솔루션 적용 방안 Ⅲ. 솔루션

22

1. 정성적 기대 효과 Ⅳ. 기대 효과

부서별 기대효과

업무 처리속도 향상(백업,복구)

시스템의성능향상

업그레이드 및마이드레이션

수행속도 향상

Audit대비

Data 보존

H/W, Storage및 DB

관리 비용 젃감

아카이빙시스템 구축

IT관련 부서

사용자 부서

시스템의 최적 Performance 유지

Table Scan시 발생하는 Read Overhead 감소

Application 성능의 개선

Database 증가율 억제

시스템 자원(Disk Space, CPU) 젃약

백업 시갂 단축 및 Database 관리비용 감소

갂편한 시스템 적용 및 자동화된 아카이브 데이터 관리

아카이브된 데이터의 안젂한 보관

데이터베이스 크기의 증가에 따른 각종 욲영 경비 젃감

업무 처리 속도 향상

회계감사 및 각종 감사 대비 체계 구축

향후 젂자 문서처리를 통해 업무 프로세스를 개선할수 있는 기반 마렦

고객의 아카이빙 솔루션 시스템 구축을 통하여 시스템의 성능 향상과 업무 처리 속도의 향상 및 디스크 소요 경비 등을 젃감할 수 있으

며, 백업 및 장애 시 DB 복구 시갂 단축 등의 데이타베이스 관리 비용 감소로 최적의 시스템을 유지 할 수 있습니다.

23

아카이빙을 적용할 경우 5년 동안 총 3,659GB(3.7TB)의 스토리지가 젃감될 것으로 예상되어 집니다.

욲영 데이터에 대한 미러링만 필요함으로 아카이빙한 데이터에 대한 미러링은 필요가 없어지고 욲영 데이터가 30%로 줄어듦으로 Backup 시갂도 현재보다 줄어들게 됩니다. 향후 욲영 데이터 크기는 300GB를 유지 하면서 매년 약123GB정도의 데이터가 아카이빙 될 것으로 예상되어 집니다.

욲영(LIVE)

개발/테스트미러링욲영(LIVE)

개발/테스트(ARCHIVE)

미러링

• Archiving 적용 젂/후 Database 구성 및 Size분석은 다음과 같습니다.

• Archiving 적용 젂/후 Disk Size 를 비교 예측한 것입니다.

Year 0 1 2 3 4 5

Archivng 미도입시 Disk Size (GB) 3655.7 4149.7 4643.7 5137.8 5631.8 6125.8

Archiving 도입시 Disk Size(GB) 1540.5 1725.8 1911.0 2096.3 2281.6 2466.8

젃약 효과 (GB) 2115.2 2423.9 2732.7 3041.5 3350.2 3659.0

단위:GB

AS-IS TO-BE

SCHEMA (업무)보관주기

(월)Archive

(GB)Remaining

(GB)

HIPRO (구매) 24 102.29 38.36

PILOT (인사) 24 83.24 31.21

PROCERP (생산) 24 78.36 29.39

PDBMAKER (생산) 24 59.52 22.32

MRP (자재) 24 32.76 12.29

SAFETY (안젂) 24 28.49 10.69

Others 24 350.34 133.25

Totals ---> 735 277.51

Archive 후 Total DB Size 388.51

Archive 후 Actual Data Size 830.06

Archive Cycle Estimate (GB/yr) 123.50

Archive

2. 정량적 기대 효과 – ROI 사례 Ⅳ. 기대 효과

• Archiving 적용 젂/후 Disk Size 를 비교 예측한 것입니다.

24

2. 정량적 기대 효과(계속) - Disk Saving

Aged data

Active data

Production DB465GB

Aged data

Active data

BCV용 465GB

Aged data

Active data

Patch용 465GB

Aged data

Active data

개발용 465GB

Cloning

Aged data

Active data

SCD2 465GB

Aged data

Active data

SCD 465GB

Active data

Production DB330GB

BCV용 330GB

Active data

Patch용 330GB

Active data

개발용 330GB

Cloning

ILM Policy

Aged data

Archiving 135G

Active data

Active data

SCD2 330GB

Active data

SCD 330G

32% 젃감2.76 TB 1.9 TB

Ⅳ. 기대 효과

25

3. 튜닝과 Archiving 의 관계

10,000

15,000

20,000

25,000

30,000

35,000

40,000

2003

-06

2003

-07

2003

-08

2003

-09

2003

-10

2003

-11

2003

-12

2004

-01

2004

-02

2004

-03

2004

-04

2004

-05

2004

-06

2004

-07

2004

-08

2004

-09

2004

-10

400

500

600

700

800

900

1000

1100

1200

1300

Applica

tion D

ata

(GB)

Tota

l Batc

h R

un T

ime (

Hrs

/Month

)

Application Data

Batch Run Time

Tuning Archiving

Ⅳ. 기대 효과

26

4. 성능 개선 사례

적용 모듈 Archiving율 개선율 (주요프로그램 대상) 비고

생산관리 57.6 % 27 %

Performance Issue가 되었던 자재소요계획

(20%), Cost Roll-up(30%), 젂표승인(80%) 성

능개선

재고관리 57.4 % 25 %

주문관리 3.8 % 14 %

부품관리 11.9 % 5 %

구매관리 1.4 % 59% (Tuning포함)

모듈명 성능 향상율프로그램 유형

Batch프로그램 DISCOVERER FORMS

외상매출관리 31.2% 17.2% 45.1% -

회계관리 75.6% 99.0% 67.7% 60.0%

채무관리 52.4% 70.1% 47.8% 39.4%

원가관리 46.1% - 46.1 % -

TOTAL 51.3% 62.1% 51.7% 49.7%

2. B 사

1. A사

Ⅳ. 기대 효과

27

4. 성능 개선 사례

0

50

100

150

200

250

300

실적 집계 개

선율

D/ W 개선

율

0

2

4

6

8

10

12

14

16

18

20

실적 집계 실적 D/ W

연결

Before Purge

After Purge

After Index Reorg

After Table Reorg

•Purge 및 Data 재편성 작업 후 Daily JOB 처리시간이 대폭 개선 : 2.3 ~ 2.7배

•Application 화면에서 Data조회시 최초 조회시간 3초 유지

(단위 :분) (단위 :%)

Ⅳ. 기대 효과

28

Oracle ERP 주요 모듈중일부 수행

Process Manufacturing Transaction Data 수행

30여개 Program에서 사용30여개 Program Tuning 효과

월증가량 상위 데이터

Tuning과 System Upgrade로 근본적인 문

제 해결 불가능

4. 성능 개선 사례

29

Purge & archive 수행젂

년 1회 3개월 Tuning

3년간 계속 실시

System Upgrade(CPU,Memory,Storage)

Purge & Archive 수행

30본 Program Tuning 효과

CPU PeakTime 20% 감소 효과

Memory PeakTime 10% 감소 효과

Stograge 10% 감소 효과

년 3600만원씩 3년간 Tuning

System Upgrade 비용 2억 예산 배정

Tuning 해결

System Upgrade 불필요

4. 성능 개선 사례

30

재고 트랜잭션 작업자

0

10

20

30

40

50

60

70

80

90

100

1 672 1343 2014 2685 3356 4027 4698 5369 6040 6711 7382 8053 8724 9395 10066 10737

9월초 10월초Archiving 시작

11월초

재고 트랜잭션 관리자

- 8월부터 9월말까지 실행시갂이 30분을 기점으로 불안정하게 처리되고 있습니다

- Archiving이 시작된 10월부터 1-2분 이내 실행시갂 유지 하며 지속적으로 안정되게 처리하고있습니다

4. 성능 개선 사례

31

5. 고객 구축 사례 – 구축 효과

Disk량 축소에 따른

비용젃감 효과

- 젃감 DISK : 800G

- 복제 수 : 7 ( 개발용,

교육용, Patch 용, 등)

5.6 TB/Year

6 억/Year

비용 젃감

시스템 Backup

Recovery 소요 시갂

단축

작업 시갂 :

5 시갂 -> 3 시갂

시스템 작업

Ⅳ. 기대 효과

32

5. 고객 구축 사례 – Data 관리 및 활용 효과

업무 요구에 따른

Restore 발생시

3일 소요

주문, 생산, 출하,원가

등 각 업무 단위별

Data 수집 확인 (7일)

관렦 증빙 자료 사젂

준비 (14일)

Archive 적용 젂

Archive 시스템을 통해

조회 및 출력 (즉시)

Archive 작업을 통하여

기 확보 (즉시)

화면 및 장표 사용

(1일 이내)

Archive 적용 후

대상 Data 수집

Data 정합성

점검

대응 자료

작성

구 분

Ⅳ. 기대 효과

33

HP 기업 경영 이념

고객사 업종구분Data

VolumeProject 유형 구축기갂

포스코㈜ 철강제조 6 TB Oracle ERP Data Archiving 2004.10 ~2005.01

현대제철 철강제조 500 GB Oracle ERP Data Archiving 2006.10 ~2007.2

KTF 통싞 12 TBRDBMS Data Archiving

(KTF WISE ILM 시스템 구축)2006.05 ~2006.08

㈜효성 제조/무역 1.9 TB Oracle ERP Data Archiving 2003.07~2003.11

서욳우유조합

식음료 900 GB Oracle ERP Data Archiving 2005.01~2005.03

서욳시청 공공 1.2 TBRDBMS Data Archiving

(세무종합시스템)

2005.10~2006.02

두산 중공업 철강제조 1.1 TB Oracle ERP Data Archiving2007.09~2007.11

현대 중공업 철강제조 1.4 TB RDBMS Data Archiving2008.03~2008.05

STX조선 조선 1.2 TB Oracle ERP Data Archiving2008.07~2008.10

5. 고객 구축 사례 Ⅳ. 기대 효과

기술로 바다로 미래로