Archiving as a Cure for Database Crashes

Interminable queries, transaction time-outs... symptoms of an overweight database. Drew Robb examines how proper planning and a tailored archiving strategy boosted one company's database performance and its bottom line.
Posted October 25, 2004
By

Drew Robb

Drew Robb


(Page 1 of 2)

Letting a database grow without action can lead to disaster. Transactional performance can suffer to the point where people are screaming about access rates or their queries timing out. And if you do run out of disk space, your whole system could crash.

"Our overweight database was months away from crashing due to exceeding our production disk space capacity," said Larry Cuda, global data archiving and migration project leader at Kennametal Inc. "Management determined that we could no longer just keep throwing more disks at the problem."

stock 
photography
"If you don't archive, and have an overweight database, transactions that used to take one second can take you six seconds." - Larry Cuda, global data archiving and migration project leader, Kennametal Inc.
What happens is that databases become loaded up with inactive records. As system bloat continues, transactions and queries take longer and longer.

It can get to the point where you enter a query, go for a coffee, return to your desk and the application is still churning. One obvious solution is database archiving: you move all inactive records to another platform and leave only current and recent traffic in the database.

Paring Down the Database

Kennametal Inc. is a large metal cutting tool company with 13,500 employees based in Latrobe, PA. The company has an HP UX 64-bit environment for a series of SAP ERP applications (sales and distribution, materials management, production and planning, financial and controlling) as well as its Oracle 8.1 database. Its SAP database, already well over 2 TB, was swelling at a rate of 27 GB per month. And that began to cause serious issues.

"If you don't archive, and have an overweight database, transactions that used to take one second can take you six seconds," said Cuda. "You are also vulnerable to time outs or even system outages as a large database requires too much processing to read through millions of inactive records."

Further, this can also put the company at risk during backup. The bigger the size of the database, the more time it takes to backup/restore. During those activities, you are vulnerable to an outage or a power surge that can ruin the data. If the backup wasn't completed, you could have lost a whole day's transactions, for example.

Kennametal pared their database down to the essentials using a database archiving tool called eCONtext by IXOS Software AG (Germany). Kennametal chose this system for its archiving as well as its optical imaging capabilities. The company actually takes an optical image of invoices and delivery notes at their point of creation. This amounts to 80 million documents that are optically imaged onto WORM CDs to satisfy country-specific legal requirements. When the system was first implemented, it took seven months round the clock to take an image of everything.

"This is a cost avoidance mechanism as you don't need to keep these documents on paper," said Cuda.

Continued on Page 2.


Page 1 of 2

 
1 2
Next Page





0 Comments (click to add your comment)
Comment and Contribute

 


(Maximum characters: 1200). You have characters left.