Anyone familiar with SAP knows that there are three characteristics of
the underlying database: it grows, it grows 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.
Code
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.
