Series: Architecting A Database Archiving Solution Part 3: End User Access & Performance Expectations

In my previous blog as part of the series, architecting a database archiving solution, we discussed the major architecture components.  In this session, we will focus on how end user access requirements and expected performance service levels drive the core of an architecture discussion.

End user access requirements can be determined by answering the following questions.  When data is archived from a source database:

  • How long does the archived data need to be retained? The longer the retention period, the more the solution architecture needs to account for potentially significant data volumes and technology upgrades or obsolescence. This will determine cost factors of keeping data online in a database or an archive file, versus nearline or offline on other media such as tape.
  • Does the data need to be accessed in the context of the original business application? If the original application is required to view the data, consider the implications if the application is retired or upgraded. Will the archived data still be viewable in the new application or version? This will impact whether or not archiving the data to a non-database format is an option.
  • How often will data in the archive be accessed after it has been archived and what are the performance expectations? Archive data is an excellent candidate for lower cost infrastructure for storage, reducing the overall cost of managing the data.  If the number of users and the frequency of accessing the archive data will be relatively high, I/O will need to be factored in when selecting the target architecture for the archive data.  It is typical to limit the access to the archive data to a smaller set of super users or administrators.  If few users will be accessing the data, and the number of times the data will be accessed is limited, it is a good candidate for lower cost storage with lower performance characteristics.  If the access is expected to be minimal to none, with practically no users, however, the data may need to be accessed by auditors or legal during an eDiscovery, online access or search-ability may drive the target architecture.
  • Are there any performance expectations on the access speeds for archived data? Even if there are fewer and infrequent users accessing the data, if there is an SLA that dictates a certain performance expectation, this may limit the architect’s option for choosing slower performing infrastructure.

In the next blog post, we will review the archive repository options – archiving to a separate tablespace or schema within a production database, to a separate database instance, to an archive file – XML and ODBC or to the garbage can.

Julie Lockner, Founder, www.CentricInfo.com

This entry was posted in Application ILM, Application Retirement, 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=""> <s> <strike> <strong>