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. How to Create Business Rules to Archive and Purge Transactional Data
  9. How to Uninstall Data Archive 5.1
  10. How to Uninstall Data Archive 5.3
  11. How to Use Scripts to Change Database User Passwords in the ILM Repository
  12. IBM DB2 Database Connectivity and Setup for Data Archive
  13. Installing Data Visualization
  14. Integrating Third-Party Schedulers in ILM Engine
  15. Parallel Processing in Data Archive
  16. Seamless Access Configuration for Siebel Applications
  17. Seamless Access Setup for Oracle E-Business Suite
  18. Using the Data Vault Service JDBC Driver to Connect to the Data Vault
  19. Using Multiple Engines in an ILM Environment
  20. Using PowerExchange ODBC Connections in a Data Archive Retirement Project
  21. 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.