This article can also be found in the Premium Editorial Download "Storage magazine: Backup overhaul: From a mainframe to an open-systems environment."
Download it now to read this article plus other related content.
Archiving ERP tablespace data requires specialized tools and a close working relationship with the application's DBA.
Enterprise resource planning (ERP) applications are demanding, consume increasing amounts of storage and computing resources, and usually need to be running 24/7. All of that translates into a complicated backup and recovery environment. ERP applications are typically the first to be replicated for disaster recovery and, in some cases, parts of the application databases are the first to be archived.
An ERP app contains a treasure trove of data intricately tied to numerous critical processes that reflect the overall performance and health of a business. As more data is collected, the storage infrastructure can become strained, creating slower end-user response times, longer batch runs, shrinking backup windows and recovery tests that miss their recovery time objectives. To address this issue, a company will typically upgrade its ERP infrastructure, believing that more spindles, CPUs and I/O will fix the problem. Eventually, those enhancements will lose effectiveness and the company will decide to archive less-important ERP data, which leads to a whole new set of challenges.
To archive ERP data, specific data needs to be surgically extracted from various database columns, rows and tables across multiple tablespaces on multiple physical LUNs and, ultimately, from multiple disks. The extraction must be done at the ERP application
Generally, there are two types of ERP archiving techniques: dynamic archiving and static archiving. Both pull content from a production ERP application to reduce its size, but from a storage perspective they require very different approaches.
This was first published in April 2007