Getting started with SAP data archiving: Answers to FAQs

As more organizations confront aging SAP systems, SAP data archiving projects are coming up on the radar. Archiving data can help enhance the performance of databases, applications and free up infrastructure resources for other projects like upgrades to ECC 6.0.

In this podcast, SAP data archiving expert Nick Parkin of Proceed Archiving Solutions answers some of the most frequently asked questions about getting started with an SAP data archiving project. Parkin has been working as an SAP technical consultant since 1996, and for the last five years has focused on database performance and how organizations can improve storage use and performance with data archiving.

Listeners will learn:

• When it's time to consider data archiving

•  

• What size database warrants an SAP data archiving project

•  

• The pros and cons of buying additional storage to increase performance

•  

• Whether data archiving makes it difficult for users to access data

•  

• How long a project typically takes

•  

  SAP Data Archiving FAQs

  Play now: You must have Adobe Flash Player 7 or above to view this content.See https://www.adobe.com/products/flashplayer to download now.

  Download for later: SAP data archiving FAQ • Internet Explorer: Right Click > Save Target As • Firefox: Right Click > Save Link As

   

  Podcast transcript

  Editor's note: The following Q/A is a transcript based on the podcast with Nick Parkin. Please contact [email protected] with any questions.

  SearchSAP.com: Nick, some users say they don't need to archive their data because there's not a large enough volume of data in their database. Is this true?

  Nick Parkin: That's a bit of a yes/no answer, really. I think for an SAP customer that's got a small database, say for instance 200 GB, and they're growing at, say, 1% a month, I basically would say don't bother archiving. But if you look at that, in three years time, that database would have grown to 286 GB. But if you take a slightly larger database, say 500 GB, and they're growing 2% a month, in three years that becomes a terabyte. Unless that growth is at 4% a month, it then becomes 2.1 TB over three years. So, basically, if you have a very small database and it's growing at a very small rate per month, I'd say don't bother. But if you have a medium-sized database growing from 2 to 5% a month, I say definitely do archiving.

  SearchSAP.com: Another common question we hear is, "Storage hardware is so much cheaper now, why don't I just go buy myself some more storage rather than archive my data?" What are some of the pitfalls to doing this?

  Nick Parkin: That may solve the immediate problem, if you just go out and buy more disc storage. But to give a real-life example, we've got a telecom company in the U.K. with an 8 TB database. They needed to do a hardware refresh after five years and they're moving from Informix to Oracle. When they looked at that 8 TB, it would actually take them four to five days to actually move the data, and the business couldn't be down that long, so they had to drastically reduce that database size down to about 3 TB. Again, the larger the database, if you have a disaster, it can take a number of days to recover. We have a very large customer over here with 27 TB of data sitting on an Oracle database, and basically Oracle told them if they actually had to recover, it would take three and a half days, and when you're running a 24/7 operation, that's not a very good thing. So you can always put more disc storage in, but that's going to cause you problems in the future, maybe because of a disaster recovery or when doing a hardware refresh.

  SearchSAP.com: Does data archiving make it difficult for users to access the data?

  Nick Parkin: No, not at all. For most modules of SAP, such as FICO, MM and SD, the users won't notice any data difference getting any data back using the same transactions they used for the live data. The only thing that they won't be able to do is key in to that data because it's read-only. For some other modules, like Project System, the data may not come back exactly in the same format, and they would have to give a more technical view of the data. But generally, the user isn't really going to notice any difference from the live system.

  SearchSAP.com: Many of our readers are pursuing upgrades to SAP ECC 6.0. If a lot of people say, "We've got to focus on this upgrade project right now; we can't have another project going on," is there a way to tie data archiving in with this project, or should they be thought of as two separate projects?

  Nick Parkin: I think that anybody going from R/3 4.6 or 4.7 to ECC 6.0 should basically look at an archiving project as part of their upgrade project. As you go from 4.6c to 4.7, what the users will notice is anything between a 15 to 25% disc storage requirement for adding actually no data. So running a data archiving project can have two benefits: Firstly, it helps stabilize your disc storage, and secondly, as the upgrade process does not have to go through too much data, the upgrade process runs through much more quickly. We've talked to a lot of customers who are upgrading to ECC 6.0, and some of the customers are also doing a Unicode conversion at the same time, and if you do a data archiving project, this can actually speed up the conversion by 25%.

  SearchSAP.com: What about so-called "young SAP users"? Should they think about archiving their data . . . customers who have been only running it for a couple of years?

  Nick Parkin: Unfortunately, only about one in every six customers archive from day one. Most customers will leave it at least five years of live running before they start archiving. One of the benefits of archiving from day one is that, firstly, the people who have configured the system are still around, making the archiving project much easier, as information about the system design is readily available. Also, they can stabilize both the database growth and performance from day one, and if you leave it for five years, it will probably take you at least six months to do catch-up runs before you can start archiving on, say, a quarterly basis. So I would tell any new customer that they should start an archiving project literally as part of the initial information.

  SearchSAP.com: How long does an archive project typically take?

  Nick Parkin: An archiving project runs exactly the same as any other SAP project, with a blueprint phase, which will be something like 20 to 30 days followed by the realization phase, which, for each module you're archiving, will be around about 15 days. So for a project, archiving from, say, SAP FICO, MM and SD, total days will be between 65 and 75 over a six-month period.

  SearchSAP.com: Do you have any additional advice when it comes to data archiving?

  Nick Parkin: I suppose the earlier a customer starts archiving the better. The longer you leave it, the more difficult it becomes. And what lots of people do, is once they have started archiving, they think, "That's it, I've archived my data; it's gone to somewhere else onto a content server." But typically what will happen is that the archive will become a lot larger than the live system over time. And most people forget about that. It's not just about archiving for the live system, you must think about how you look after the archives on an ongoing basis as well.