Anyone familiar with SAP knows that there are three characteristics of the underlying database: it grows, it grows...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
quickly, and it will keep on growing! The way that most companies deal with this scenario is to buy more disk space, because as we've all heard, "disk space is cheap." Well, cheap is a relative term, especially when you look at the other costs you incur when you allow your database to grow unchecked.
A few costs associated with growing databases
Let's look at the other effects of a growing database.
- Poor system performance
From a technical perspective, the more data you have in any given table, the larger the associated index trees grow. This hurts the performance of programs because the database has to read through many blocks of data to locate the pointer to the data you are looking for. If you want to quantify this cost, multiply the increase in dialog response time by the average number of dialog steps per user per specified time frame. For example: Assume an extra .5 seconds times 2000 users with 100 dialog steps per hour (not a large amount). This could result in a loss of almost 28 person/hours of productivity per 8-hour shift. For a 7x24 operation, that could result in a loss of more than 30,000 person/hours per year! Ouch!!!
- Poor database performance
One of the ways that a database delivers good performance is by using a data buffer- a large chunk of RAM where data is stored when read.This limited area of memory is flushed using an LRU (least recently used) algorithm, which allows frequently used data to be accessed about 1000 times more quickly than if it had to be accessed on disk. If we force the system to read larger volumes of data, this buffer will have less room for the frequently accessed data and performance will suffer. Many companies will also purchase additional RAM in an effort to alleviate this issue but that is only a temporary "fix" that still does not address the underlying problem.
- Longer DB backup runtimes
Most SAP installations do online backups, which drastically affect system performance while running. It's a simple calculation: the more data to be backed up, the longer it takes to do the backup, the more your application performance is affected.
- Longer system downtime
In the event of a system failure, the amount of time necessary to get the database restored, recovered, and up and running becomes longer as your database size increases. Have you done any estimates on the cost of downtime lately?
The list could go on and on, but I have limited space for this column, so let's look at the data. Over the course of time, the amount of data that most users examine on a regular basis is relatively finite. Except for trend analysis reporting, 95% of data accessed was generated within the last 12-18 months. This means that if your installation has been live for 5 years, you're rarely looking at almost 80% of your data! This directly translates into system overhead. Your database administrator is backing up data that no longer changes! This data cannot be deleted from the system for various reasons (legal, business, tax, or users might need it some day).
The Solution: SAP data archiving
SAP Data Archiving is a functionality that is included in every R/3 system at no additional charge. It allows you to get your old data out of your database while retaining the ability to view the data. The data is stored in secure files outside of the database. To manage these files in an efficient, secure manner, you may need to utilize a third party storage management system.
SAP recommends that you start archiving data as soon after go-live as reasonable. The longer a company waits to do archiving, the more system resources are strained to achieve your archiving goals. Unfortunately, most companies think of data archiving like some people think of the dentist. They avoid it until the pain is too much to bear; then they realize that the cure is more painful than if they had started taking care of themselves much earlier. Data archiving jobs require quite a bit of resources from both the database engine and the application server. This becomes a huge issue if your system resources are already strained.
SAP offers three classes related to your archiving project: BC660 gives you the details of Data Archiving and how to run an archiving project. BC670 is an ABAP course that teaches your developers how to create custom archive objects and reports. BC680 teaches you about DART(Data Retention Tool).
DART is not data archiving but very often a DART project is closely related to an archiving project. DART is a tool that delivers functionality to assist in meeting the data requirements for IRS tax audits.
Don't wait until the pain is too much to bear (read that "system collapse"). Get your company started on data archiving as soon as possible. Think of it as preventative medicine for your database.
Whether you've just decided to become an independent SAP consultant or you've been one for a while, you know your clients expect you to have expert knowledge of the rapidly evolving SAP landscape. They want you to know the newest product features and functionality. And they want you to have that expertise now.
That's where we come in. SAP Educational Services knows that independent consultants need to get classes and certifications at times and places that make sense. We offer the latest mySAP.com courses at conveniently scheduled times and places across North America. We have an Education Help Desk ready to help you define what courses you need and when best to take them. And we offer our in-depth Solution Academies, providing the intensive training and case studies you need and the SAP Certification your clients expect.
Let us show you how we can help ensure your success. Call the Education Help Desk at 1-TRN-SAP1 and declare your independence.