1

Slavomir PenickaProject Manager, IBM Czech Republic

Oracle E-Business Suite Data Growth

Performance, Costs and ILM Challenges

VODAFONE CZ

2

Agenda of the Presentation

• Vodafone Group & Vodafone Czech Republic

• Vodafone's OEBS environment

• The challenges encountered

• Search for a solution

• Selection of Applimation Archive

• How does it works ?

• How was it implemented ? (Analysis, Strategy, Archive cycles, access layers)

• Achievements & Challenges

• Future Plans

3

Vodafone Group

• Vodafone was formed in 1984 as a subsidiary of Racal ElectronicsPlc.

• It was fully demerged from Racal Electronics Plc and became an independent company in September 1991, at which time it changed its name to Vodafone Group Plc.

• 61,672 employees around the world

• Vodafone reaches 200 million customers (January 2007).

• Group revenue of Ł29.4 billion from continuing operations. Mobile telecommunications revenue increased to Ł28.1 billion, representing growth of 9.3%

4

Vodafone in Czech Republic

• Original company Oskar was founded in 1999 as a third mobile operator on the market

• On June 1, 2005, Oskar became a member of the Vodafone family.

• More than 2000 employees

• Over 2.5 million customers (26% of market)

• The Czech mobile market penetration reached 112%

• Revenue EUR 730 mios

• Main benefits are lots of new roaming partners around the world,wide range of services coming from global company

• February 1, 2007 : AD&M project - outsourcing of some IT activities to IBM.

5

Vodafone's Oracle E Business Suite

• OEBS live since September 2000

• OEBS version : 11.5.10 (DB 9i)

• OEBS modules in use at Vodafone : GL, AR, AP, CE, FA, PO, INV, OM

• DB Size : over 400GB (in 2006)

• Vodafone had two development environments, which was insufficient from a SOX point of view. Additionally, our VOILA project required additional environments.

• Import of SAZKA files (from 2004) leading to the increase of data growth per month (20GB). Performance impacted.

6

Vodafone's Oracle E Business Suite

7

The challenges encountered

• Vodafone had two non-production OEBS environments, still SOX required another as pre-prod

• High cost for storage space, cost for 240 GB increasing per year was 350 000CZK (16500USD) needed for the three current environments.

• Impossibility to find space for DB restoring in case of HW failure or necessity to restore data (audit)

• Due to slow system, financial department has issues during the month closing (they feel more and more pressure with shorter deadlines)

• Clone of production environment takes more than 2 days

• VOILA project required 4 more development and testing environments

8

The challenges encountered

• Problematic long-time running maintenance for ex. gather schema statistics

9

20

40

60

80

100

0 3 6 9 12 15 18 21 24 …

Time (months)

Size (GB)

Active Data

Inactive Data

0

Active versus Inactive data

The challenges encountered

10

The challenges encountered

Simply, if we did nothing we could be in situation like that:

11

Search for a solution

Applimation• Product Informia Archive is especially designed (also) for Oracle

EBS

• Due to candidate generation rules ensures data consistency

• Possibility to display archived data through standard application/interfaces (no necessary another GUI or reports)

Solution from Oracle• Based on Oracle Discoverer, without particular solution for EBS

• Archiving rules and reports displaying data would be made according to customer requirements during the project implementation

• Disadvantage - longer time needed for implementation, higher costs, data displaying in another application (Oracle Discoverer)

12

Selection of Applimation Archive

• Achieving 2 times higher reduction of data in first year with Applimation

• No need special training for users to be able work with Archive with Applimation

• The using out of the box solution rather than custom development of solution

• The Oracle implementation and support costs was approximately 30% higher than for Applimation

13

AM_RELOC2001

AM_HISTORY

2001

2002

2003

2004

Production Archive / History

2001

1. Archive 2001 Data to Relocation Area

2. Purge 2001 Data from Production

3. Merge 2001 Data to Online Archive

4. Validate; Drop Relocation Area

5. Resize tables/indexes based on purged data

2002

2003

2004

Optional process following archive

How does it work ?

14

Active Data

First : Perform a “Data Growth Analysis” (DGA) results

How is it implemented ? Analysis Phase

15

Active Data

Define Our Archive Strategy with Business Community

How is it implemented ? Archive Strategy

Retention PolicyWhich modules ? AR and GL

Cut-off line between Prod and Archive ? 2 years live data

FrequencyHow often do we wish to Archive ? Yearly

User AccessDo we give access to all users ? Selected only

Which kind of access ? Combined

16

BEFORE & AFTER THE ARCHIVE 1/2Table Name Before Removed After % Removed

GL_BALANCES 20 578 068 10 272 830 10 305 238 49,92%GL_IMPORT_REFERENCES 269 613 130 96 791 490 172 821 640 35,90%GL_JE_BATCHES 48 076 35 260 12 816 73,34%GL_JE_HEADERS 272 791 185 620 87 171 68,04%GL_JE_LINES 277 871 809 102 216 610 175 655 199 36,79%

AR_ADJUSTMENTS_ALL 60 51 9 85,00%AR_BATCHES_ALL 17 394 10 691 6 703 61,46%AR_CASH_RECEIPT_HISTORY_ALL 94 414 275 36 547 500 57 866 775 38,71%AR_CASH_RECEIPTS_ALL 47 239 517 18 319 569 28 919 948 38,78%AR_DISTRIBUTIONS_ALL 218 972 118 69 304 080 149 668 038 31,65%AR_MISC_CASH_DISTRIBUTIONS_ALL 32 170 355 14 494 180 17 676 175 45,05%AR_PAYMENT_SCHEDULES_ALL 30 813 182 7 676 300 23 136 882 24,91%AR_RATE_ADJUSTMENTS_ALL 21 19 2 90,48%AR_RECEIVABLE_APPLICATIONS_ALL 45 203 591 11 533 140 33 670 451 25,51%RA_BATCHES_ALL 1 292 838 454 64,86%RA_CUST_TRX_LINE_GL_DIST_ALL 47 180 400 11 562 610 35 617 790 24,51%RA_CUSTOMER_TRX_ALL 15 724 015 3 843 035 11 880 980 24,44%RA_CUSTOMER_TRX_LINES_ALL 31 456 375 7 693 270 23 763 105 24,46%Total 1 131 576 469 390 487 093 741 089 376 34,51%

17

BEFORE & AFTER THE ARCHIVE 2/2

18

How to access the relocated data ?

Creating the Access Layer

19

2002

2003

2004APPS

APPS_combo

APPS_hist

Production Archive / History

APPS: Current Only

APPS_HIST: Archive Only

APPS_COMBO: Current + Archive

Db Link

Data Access Options

SeamlessAccess Layer

AM_HISTORYUnionView

Seamless Data Access layer

Creating the Access Layer

20

Architecture Overview

SUN

sd01er03

Machine Type: Sun V880Memory: 16GBCPU’s: 8 CPU

Storage Type: EMCSize(GB): 677GB

E-business suite 11.5.10

AM_AGENT

SID : APM_PRODSID : PRD11

Database version : 9.2.0.5

AM_OWN

Tablespaces:AM_AGENT_D 1000MAM_AGENT_X 1000M

AM_AGENT

APPS

AM_RELOC

Applimationrepository

Agent HistorySchema

AMARCHIVE

AMQUERY

Database version : 9.2.0.5

E-business suiterepository

Informia ArchiveEngine repository

Temporary relocation area –used during archivepurge process

Access Layer to Archive Only

Access Layer tocombined date

System ERP instance Applimation instance

Tablespaces:AM_HISTORY_D 10000MAM_HISTORY_X 1000M

AM_HISTORY

History DataSchema

21

Kick-Off

Kick-OffTechnicalSessions

ValidateDGA

20-apr-2006

Project Timeline

Install Run Sample CyclesCreateData

Access

PlanNext

Steps

Module 1

Module 2

Module 3

TrainArchive User

ReviewBusiness

Rules

Conference Room Pilot

Installation and Training

09-may-2006

Refine

CycleTesting

ApproveBusiness

Rules

~ 6 Weeks

Simulate

DataAccessVerif.

Prod.Sims

Hardware/SoftwareConfigs

Setups

~ 6 Weeks

Deploy

GO-LIVE

25-sep-2006

Global Project Overview

22

Relocation of seldom-used data from your ERP system to an Online Archive Database

Seamless Data Access allows users to access both current and archived data using the standard ERP application interfaces

The process is fully driven by meta-data

Archiving in Summary

23

Achievements & Challenges

• Our expectations were fulfilled in most of the areas (performance, disk space, SOX)

• We was not able to make our development environments as small asexpected by cloning from production only due to production archiving strategy.

• Excellent implementation –very well documented solution.

• Engineer staff were very helpful - all questions were addressed

• Flexible support – most issues were solved promptly

• At the beginning we have some problems with combined views –performance/bugs – the problems was fixed very soon.

• One of the most straightforward implementations

24

Future plans

• Archiving of further OEBS modules (June 2007)

• Order Management (ONT)

• Inventory (INV)

• Inactive customer data removal

• Keeping invoices in Archive due to Tax law

• Removal customer data from Live database