0

Architecting A Database Archiving Solution Part 2: The Anatomy Of A Database Archiving Solution

Before we can go into more details on how to architect a database archiving solution, let’s review at a high level the major components of a database archiving solution.  In general, a database archiving solution is comprised of four key pieces – application metadata, a policy engine, an archive repository and an archive access layer.
Application Metadata – This component contains information that is used to define what tables will participate in a database archiving activity.  It stores the relationships between those tables, including database or application level constraints and any criteria that needs to be considered when selecting data that will be archived.  The metadata for packaged applications, such as Oracle E-Business Suite, PeopleSoft, or SAP can usually be purchased in pre-populated repositories, such as Informatica’s Application Accelerators for Data Archive to speed implementation times.

Policy Engine – This component is where business users define their retention policies in terms of time durations and possibly other related rules (i.e. keep all financial data for current quarter plus seven years and the general and sub ledgers must have a status of “Closed”).  The policy engine is also responsible for executing the policy within the database, and moving data to a configured archive repository.  This involves translating the policy and metadata into structured query language that the database understands (SELECT * from TABLE A where COLUMN 1 > 2 years and COLUMN 2 = “Closed”).  Depending on the policy, users may want to move the data to an archive (meaning it is removed from the source application) or just create a copy in the archive.  The policy engine takes care of all those steps.

Archive Repository – This stores the database archive records.  The choices for the repository vary and will be determined based on a number of factors typically driven from end user archive access requirements (we will discuss this in the next blog).  Some of these choices include another archive database, highly compressed query-able archive files, XML files to name a few.

Archive Access Layer – This is the mechanism that makes the database archive accessible either to a native application, a standard business reporting tool, or a data discovery portal.   Again, these options vary and will be determined based on the end user access requirements and the technology standards in the organizations data center.

In the next series, we will discuss how End User Access and Performance Requirements impact the selection of these components in further detail.

Julie Lockner, Founder, www.CentricInfo.com

FacebookTwitterLinkedInEmailPrintShare
This entry was posted in Application ILM, Database Archiving and tagged , , , , , , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>