Published: 11 Jul 2008
| As someone who has managed storage in an SAP environment for more than a decade, Steve Baucum remembers when you still had to dial Germany in the middle of the night for tech support.
"SAP was the first application we moved to SAN storage," recalls Baucum, manager of Unix support at Memphis-based Methodist Healthcare Corp., a network of seven hospitals that runs about 40TB of storage. "We started in 1996," he says. "At the time, SAP consultants were very expensive and rare. A person with SAP experience was worth millions of dollars. It was a big risk."
Back then, Methodist Healthcare first tested SAP on its new IBM ESS SAN, and it spit out "reams of logs," recalls Baucum. "Initially, it did burn up a lot [of storage], but now it has pretty much stabilized at about 600GB." Without much customization or many changes, the hospital's current SAP system, which sits on top of an Oracle database, doesn't devour more than its share of storage.
"It's stabilized now and it's actually a minor player on our SAN," says Baucum. The hospital runs financials--HR, accounting, payroll--for about 15,000 employees on SAP.
With SAP, you'll always have several versions of your database running, says Joshua Greenbaum, principal at Enterprise Applications Consulting, Berkeley, CA. "If you've got 100GB of data, you'll wind up storing about 300GB," he says. "Then you have to consider how data is indexed. You may have 10GB of data, but the index--the meta data--is often as big as the initial storage."
Now a newly introduced SAP appliance, a column-based, in-memory database system called the SAP Business Intelligence Accelerator (BIA), could have a large impact on the connection between SAP and storage, says Greenbaum. SAP is hoping to give customers another viable option to running SAP on Oracle databases, and Greenbaum believes the column-based system has the potential to extend beyond the analytical environment and eventually impact storage.
"It requires significantly less storage than a traditional database," he says. Standard databases are relational systems that organize data into tables made up of vertical columns and horizontal rows. Column-based systems sort of flip the tables on their side, compressing the data and easing data warehouse queries by storing table tags (such as customer name) only once.
SAP says its column-based data compression technology allows for the storage of relational data in a pre-indexed format. "The thing about these column-based systems is that they really start to change the tenor of what constitutes an acceptable storage environment for strategic data," says Greenbaum. "The guy who gets an analysis in a minute is going to beat the guy who takes a day. It has a unique potential for changing the overall profile of storage."
Currently, BIA technology still applies mainly to analytics not storage. (If the column-based technology sounds familiar, you're probably thinking of Sybase's IQ Accelerator, which was a breakthrough for data warehousing back in 1994.)
Several SAP partners have introduced products to help customers with storage challenges. For example, the product literature for NetApp's ReplicatorX for SAP tells users: "In SAP environments, activities such as application patch testing, performance and data integrity testing, and user training environments often require multiple copies of SAP components." It goes on to say that all of those redundancies do a number on storage resources and IT staff.
But does the SAP of today truly have a larger impact on your storage system than other enterprise resource planning (ERP) applications? To answer that fairly, you'd have to test it against another ERP system that combines 10TB of disparate data into a single, new location, says Naeem Hashmi, a longtime ERP consultant who's now VP of knowledge management and informatics at Waltham, MA-based Fresenius Medical Care North America, a global company that runs a mix of SAP and other enterprise applications. Hashmi swears SAP doesn't impact storage in any way that other large ERP systems don't.
"People are surprised when they see it all under one umbrella," he says. "Let's say you have 10TB of storage, for example. Typically, that's on separate applications. When you implement that all into SAP, it should be 7TB." (Hashmi is counting on your consolidation to eliminate redundant information in every application as you redefine your data and business processes.)
"It's very different for the operations people who are now managing data backup for one large chunk of data," he adds.