The document discusses archiving historical data from an Oracle Hyperion Financial Management (HFM) application that had grown to 200 GB in size over 10 years. It describes creating a new, smaller "historical" application by keeping only required scenarios and data from the past 2-3 years. This reduced the size of the archived data by 66%, freeing up 161 GB of storage. The document provides guidance on how to define the archive process, migrate data between applications, handle security, reporting and validation of the historical data.

1. The 200 GB diet
or
“how I archived off the
first 10 years of my application!”
Michael Malandra

2. Focus
Services
People
Methodology
Customers
Partnership
15 Years
700+ clients
1000+ projects
About Edgewater Ranzal

3. We offer a full spectrum of EPM/BI Services
Dashboards & Scorecards, Financial
Analytics & Reporting, Operational Analytics,
What-if Analysis, Query & Reporting, Visual
Exploration
Financial performance, Legal,
Segment & Mgmt Reporting, Financial
Close
HFM Optimization, Performance Lab
SOX Compliance Support
Strategic Finance, Planning,
Budgeting, Forecasting, Workforce
Planning, Capital Planning, Project
Financial Planning
Data Integration, Financial Data
Management, Data Warehousing,
Master Data Management &DRM,
ETL Services, Automation
Project/Program Mgmt, EPM
Road Maps, Application
Reviews, Business
Requirements, Process
Change, Documentation
Installation, Upgrades,
Migration, System
Monitoring, Backup and
Recovery, Disaster
Recovery, Load Testing,
Hardware Sizing, Exalytics
Benchmarking
Consolidation
Business
Intelligence
Enterprise
Planning
Infrastructure
Training &
Support Services
Project
Management
Data
Services
Costing &
Profitability
Mgmt
Support Services – Infrastructure &
Application Support Contracts
Key Teach Course Delivery: Planning, Essbase,
Financial Reporting, Smart View, HPCM, HFM,
FDM, DRM, OBIEE
Custom Training Delivery: Process & Reporting
HPCM Standard & Detailed
Models, Waterfall Allocations,
Activity Based Costing,
Customer, Product & LOB
Profitability

4. To Archive or Not Archive?

5. On Average Applications:
that are 2-3 years old can
average 10GB to 15GB
25GB to 50GB are also
common
100GB to 300GB are rare
500GB and 1TB are
mythical…
Too much of a good thing…

6. Determine the current
DB/schema size
Every Scenario/Year
has its own table
1 GB = 1024 MB =
1,073,741,824 Bytes
Data Analysis

7. A large application doesn’t inherently
mean “slow”
Remember - DB and application
performance are independent
● but DB performance can influence app…
Application performance is a function of
data usage
● And rules. And application tier hardware.
Before you begin

8. There is no “Archive Data” feature!
Can HFM do this automatically?
It’s D.I.Y.
But How?But How?

9. Define “Archive”
● Need to access the historical data
● Reduce the data set going forward
Create a second read only “historical”
application
Keep only required scenarios
● Actual, Actual at Budget rates, Actual at Forecast
rates
The patient must minister to
himself…

10. Answer 2 Questions:
1. Will I go to jail
if I delete this
data?
2. Could I be fired
if I delete this
data?
Risk Assessment or Let’s kill all the
lawyers…

11. Case Study: Codename VentiCase Study: Codename Venti
114GB of data in non-essential scenarios
46.5% of the database

12. What’s Done is Done…
Historical application will only contain data
that was reported
Much smaller application that will not expand

13. Tomorrow, and Tomorrow, and…
To restrict the
expansion of the
new application,
institute policies
that will limit size
Keep Forecasts
only 2 years
Other scenarios
will be used as
needed then the
data will be
dropped after 12
months

14. Good Riddance…
Old application was 245GB
New Applications are 83GB
A reduction of 161GB or
66%
Institute policies to prevent
growth for non-essential
scenarios

15. Saying goodbye to old data, now what?
Upgrading??
● If yes, then leverage converted Application for
data validation and create 2 new apps
● If not, can the environment handle another
application?
Benefits of new applications – no junk!
● Invalid records and unnecessary data!
● Keeping only relevant data (smaller applications)
Parting is such sweet sorrow…

16. Two choices:
● Old data in new structure
● Old data in a static structure
A lean and hungry look…
Don’t overthink
history!

17. Application Type: Classic or EPMA?
If EPMA when?
● Start project in EPMA
● or convert later?
Synchronize Applications

18. Beginning balances?
● Do your customs have adjustment members?
● Will your rules work with a new start year?
Historical Data?
● Journals or not? <ECT> can be loaded to
<EC>
● Load in local currency, not in Parent Currency
Questions to Consider?

19. One rule file or two?
● One rule file is easier to maintain but the
current file will need to be updated
● Leverage Hs.ApplicationName()
sAppName = HS.ApplicationName()
If sAppName = “NewApp” Then
Do something…
Else Do something else…
Rules

20. Does the rule file have a start year
variable?
● If yes, create a condition in which the variable
has two options
sAppName = HS.ApplicationName()
If sAppName = “NewApp” Then
nStartYear = “2008”
Else
nStartYear = “1998”
● In not, add an empty year to the beginning of
the application…nStartYear -1
Rules, cont.

21. Multiple Year KPIs
● Will cause some overlap
in years between
applications
Cash flow
● Load entire TB in stub
period (12/2009)
Rules, final thoughts…

22. Who sees the History?
Making the App Read Only
● Make Scenario security classes Read only
● Security Class access is most restrictive to least
restrictive
Users will see the stub year
● Years do not have security
● Over communicate this during Training
and Testing
Security

23. Smart View
● New application connections are
needed
● Communicate via Training and
Testing
Financial Reports
● Can only connect to one
application
● Only certain reports access
the Historical app
Reporting

24. Data Validation
● What level of detail needs to
be validated?
● Tools to use? FDM? Excel?
● Responsibility?
● Data validation can derail your
project if not properly defined!
Something wicked this way comes…

25. Migration Process
● 2 Applications now
● Lifecycle
Management: now
moves data!!!
● Data retention
policy
● Responsibility?
Finance vs. IT
● Define clearly,
please?
Brave New World…

26. Reduced DB
Created a process to limit DB growth
Kept History
Final Thoughts or Dancing Days…

27. Michael Malandra
mmalandra@ranzal.com
Pittsburgh, PA
USA
+1.724.759.8572
www.ranzal.com