Configuring storage for ERP


This article can also be found in the Premium Editorial Download "Storage magazine: The hottest storage technology for 2007."

Download it now to read this article plus other related content.

DB2's new 'Viper' release offers more SAP support

Requires Free Membership to View

Up to 60% of SAP customers have deployed SAP applications on Oracle databases, according to Noel Yuhanna, a senior analyst at Forrester Research Inc., Cambridge, MA. Because large enterprise resource planning (ERP) systems are usually chosen to operate with highly scalable, enterprise-performance workhorse databases like Oracle, it isn't surprising that other database vendors are trying to make a dent in Oracle's SAP market share.

IBM Corp.'s new DB2 release (code-named "Viper"), which was introduced in the summer of 2006, has integrated features for SAP. One of the more important features of Viper is that it includes an XML storage engine in addition to a relational storage engine. Philip Howard, research director, data at Bloor Research in the U.K., says "... performance comparisons by early adopters of Viper indicate performance gains on queries of 100 times or more, development benefits of between four and 16 times ... the ability to add fields to a schema in a matter of minutes as opposed to days."

Howard says that in addition to the XML storage engine, the new release of Viper will include new data compression capabilities such as row compression. IBM believes its compression techniques will result in savings of approximately 35% to 80%. Because there are special SAP facilities included with the new Viper release, the savings could be on the higher end.

Of course, other database vendors contend that their databases are best suited for the midtier market. In an Accenture white paper called "Coming of Age: SAP on Microsoft," the claim is made that companies can reap a huge cost benefit by using SQL Server instead of other databases (such as Oracle and DB2) that are traditionally viewed as the back-end databases of choice for ERP systems. By using commodity, Intel-based servers running Windows and SQL Server, Accenture claims some companies can potentially save 20% to 70% on hardware costs. In fact, Accenture states that "at certain clients, we have identified up to 70% savings on database and operating system licensing and administration costs." It's also interesting to note that Accenture claims that the top shipping platform for SAP over the past three years has been Windows, and not a Unix-based operating system.

Protecting a database from data corruption requires an almost Einstein-like ability to manipulate time. Once a database has been corrupted, it must be reset to an earlier point in time. Like a storage array that can take a snapshot, or a file system that can journal every change, most database applications journal every transaction through a group of redo logs and archives. While each database brand has a unique method for achieving this goal, in general, every transaction is logged so that it can be reapplied or removed if required (see "DB2's new 'Viper' release offers more SAP support"). Marry this capability to the cloning capability in most storage arrays, and you have a highly available and highly recoverable application.

Point-in-time recovery
The steps to accomplish a point-in-time recovery are easy to document, but the execution of the task within a functioning data center can be a challenge. The following is the basic sequence of events:

  1. Stop all updates to the database

  2. Create a copy of the data on secondary media

  3. Allow updates to database
This seems like a simple process, and it can be if you can take the database offline for several hours every night. Because that's typically not an option, it's important to examine these steps in more detail.

Stop all updates to the database. "Stop" may be too strong a word to use when describing Step one. If we truly stop all updates, then end users see the ERP application as unavailable and that's typically not acceptable. Most databases have the ability to suspend updates to the primary table space--also referred to as putting the database in backup mode. During this time, the updates to the primary tablespace are suspended and the database application starts to create a secondary journal of updates that will be reapplied once the suspended mode is complete.

This was first published in December 2006

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: