Table of Contents

Search

  1. Preface
  2. Backing Up and Restoring the Data Vault
  3. Configuring Centera as a Remote Data Vault Store
  4. Configuring Data Archive for a Legacy Source Using Legacy Adapters
  5. Data Archive Seamless Access for PeopleSoft
  6. Data Archive Transaction Restore API
  7. Dropping and Truncating Partitions in Data Archive
  8. High Availability Configuration for the Data Archive and File Archive Service Versions 6.1 to 6.3
  9. 0955-High Availability Configuration for the Data Vault Version 6.4 and Later
  10. How to Create Business Rules to Archive and Purge Transactional Data
  11. How to Uninstall Data Archive 5.1
  12. How to Uninstall Data Archive 5.3
  13. How to Use Scripts to Change Database User Passwords in the ILM Repository
  14. IBM DB2 Database Connectivity and Setup for Data Archive
  15. Installing Data Visualization
  16. Integrating Third-Party Schedulers in ILM Engine
  17. Parallel Processing in Data Archive
  18. Seamless Access Configuration for Siebel Applications
  19. Seamless Access Setup for Oracle E-Business Suite
  20. Seamless Access Setup for Oracle R12 in Data Archive
  21. Using the Data Vault Service JDBC Driver to Connect to the Data Vault
  22. Using Multiple Engines in an ILM Environment
  23. Using PowerExchange ODBC Connections in a Data Archive Retirement Project
  24. Discovering Foreign Key Relationships in Enterprise Data Manager

Data Archive How-To Guide

Data Archive How-To Guide

Overview

Overview

Candidates are determined by the data retention policy. For example, a customer may decide to archive everything older than 3 years. So, candidate generation will identify all transactions older than 3 years. These are "candidates" for archive/purge.
Once the candidates have been identified, the next step is to determine if a candidate can be archived and purged - that is, does the candidate pass the business rule(s) for archiving and purging. The end result of Candidate Generation is that it provides a list of transactions that can be archived and purged. This list is used by the engine to archive (copy to stage) and purge (delete from source) the data.
The power of candidate generation is that it tells us WHY a transaction cannot be archived and purged - that is, it tells us what business rules a transaction failed. This helps us in a few ways. In particular we focus on rules where a majority of transactions failed. For example, if 80% of invoices failed the INVOICE IS UNPAID rule, then we can surmise:
  • Maybe this data was converted incorrectly.
  • Maybe the customer doesn’t PAY invoices in this system.
  • Maybe a patch was applied that adversely affected the PAYMENT functionality.
  • Maybe the PAYMENT functionality was implemented incorrectly for this timeframe and not corrected until later.
Identifying these types of causes allows us to MODIFY the rule in lieu of modifying the data. Our preference is to never modify data to pass a business rule.