Skip to Content

David Dobrin posted a treatise on Solution Manager (I’m quoted, and identified as “the” expert on using Solution Manager for performance tuning, just so you know that David knows me, and overestimates my skill set…).  I’m going to dive into one point here, that of decreasing storage costs.


A comment was made to his blog, asking the question (and I’m paraphrasing) “how do I get rid of garbage in my system(s)?”  I thought I knew the generally-accepted-practice answer, and that has the initials ILM, but the thread went off into a completely different direction, whereby a little-known, little-used, and probably little-impact feature of Solution Manager is touted as the answer to all your storage problems.  Here’s where I’d swear, if I did that, so use your imagination.


But first, some background.  David, and a few dozen others, were given briefings by SAP on the wonders of their software road map.  I skipped that conference, for reasons I won’t go into here.  The problem I see is that too few real-life, hands-on customers attended.  I know that Tony de Thomasis was there, but I’m guessing Tony didn’t weigh in on this subject.  There’s a SUGEN ( press release back in 2009 that talks about parts of the KPI index, the fourth being “total cost of ownership”, and part of that being storage costs.  I’m not going to go into any more detail, since the texts I have located online are marked “confidential” for reasons that are beyond me.


So, back to storage.  Everyone knows disks are cheap.  Except that enterprise scale databases take up a lot of disk.  And they grow like weeds.  We had a 100GB system a decade ago, and thought that was huge.  Now, there are systems that grow that much in less than a month.  Clearly, reining in this accelerating impact will go straight into your costs.  Not so clear, is how one achieves this.  Fortunately, SAP has published a how-to guide for information life cycle management for many years, and it’s chock full of how not to grow in the first place, how to get rid of deadwood, and how to run a business-class archiving program.  When I ask people at my conference sessions about this publication, few hands are typically raised.  So it is no wonder that if someone offers them the Solution Manager blue pill, they’ll take it without faltering.


I searched for one of the tables mentioned in the answer to the space question (“CNVCDMCCA_OBJS”) and got 0 hits on Google, 0 hits on SDN, and but 6 SAP Notes, all dated within the past year.  If you asked 100 Basis or database administrators what this table is, and what it does, you might get 2 that know anything about it (until now that is).  Well, what is it?  It’s a place to store information about your custom tables.  Do your custom tables take up a lot of room in your database?  Can they simply be eliminated?  I have my doubts.  But let’s look at code first, data second.


One area that I thought Solution Manager would help with concerns custom code, no longer in use.  You know, the report you wrote for that customer a decade ago, who has since figured out that BW gets the information faster and easier.  But you’re afraid to delete that code, since you only hear about the reports that don’t work; the ones that just keep running are no source of complaints.  And when you get to an upgrade, or an SAP patch, or a Unicode conversion, knowing dead code that can be purged  can save a lot of test cycles.  So how much room does that code take up?  I looked at an R/3 system, specifically the source (and object) tablespaces PSAPEL620D, PSAPEL620I, PSAPES620D, and PSAPES620I.  They take up less than 2% of the entire database space, and they don’t grow much.  Assuming half the code was custom (not SAP delivered, which is probably more like 99.99%), and half of the custom code was unused (a stretch, maybe), that means you could get rid of one-half of one percent of your SAP storage space.  Hardly a killer elevator (or twitter) speech for a project commitment, right?


But, no, as it turns out, this isn’t about custom *code*, it’s about custom *objects*.  Well, that should help a lot, right?  Well, maybe, but how could it have made any impact on any large customer installations if the KPIs that talk about it are confidential, one of the tables that drive it has ZERO visibility in the places us worker bees talk about this stuff, and the relevant SAP notes are freshly minted? It’s not like we just jump on every note that’s published, throw them into our systems and start executing new code without thinking.


I’m going to quote part of the answer David was given:


This makes it possible to identify the tables that have no, or just a few, entries and are likely to be not in use.


Stop.  Think.  Okay?


We’re talking about storage costs, with systems growing by gigabytes *per day*.  What possible impact will it have on that growth curve, to find custom tables that are not in use?  I’m baffled.


All right; two pictures below – the first shows a cumulative “used” space picture (not allocated, which is what you pay for, but used, which is what you can clean up, maybe), with a red line pointing to the largest of the source code tablespaces.  In this case, it’s the 25th largest space in the system.  How much of that is garbage?  Well, probably very little.


The second picture shows the growth of that space, in kilobytes, over a one year period.  The DB02 transaction shows this (if all is working in your system), and no Solution Manager needed.  Flat enough not to worry about buying more storage anytime soon.


If it were me, I’d be looking for the tables that are growing the fastest.  Find those that the business doesn’t need after legally sufficient periods of time.  Get them out of your system.


I’d also be looking at the different database vendors tools for compression, which in fact, we presented on at the just concluded ASUG / Sapphire conference.  We’re shrinking our systems, and while we use Solution Manager on occasion to find outliers or surprises, it’s not the console of choice in looking for deadwood.




To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. John Appleby
    Couldn’t resist.

    I’m with you, I don’t see how Solman can help here. Reducing SAP database sizes is a slightly sad pastime of mine. Basically I do this:

    1) Reduce the size of big tables

    Like you say, especially those that are growing. DB02 is your friend, it tells you all you need to know. Search SAP notes (706478 is my favourite) and delete, archive, whatever.

    2) Compress the database

    DB2, Oracle 11g and MSSQL 2008 can all shave 30-70% off your database size by using row or page level compression. Depending on what you use, you may get a CPU usage increase. I’d publicise my own blogs on this but I don’t like it when people self-publicise on my blogs.

    Anyhow my point is this is a manual task. Maybe Solman can help by getting people to setup the standard basis tasks so that IDOC tables etc. are cleared down. That would be nice.


  2. David Dobrin
    Thanks, Jim, for shedding an expert’s light on the subject.  As you know, SAP claims that the Sol Man has already provided significant benefit by reducing the growth of disk space at customers that have used it.  It is not clear to any of us how that is achieved.  SAP tells me offline that there is an answer; I will report back on whatever non-confidential things I have learned.

    Note that the passage in my blog that you quote was not written by me.  I am quoting Jürgen Mahler from SAP. 

    1. Jim Spath Post author

        I’m glad you are trying to shed light here.  It’s frustrating that “best practices” for saving money are hidden away as confidential business information.  I didn’t mean to imply that you were the source of the incomplete (or even incorrect) answer; when I said “part of the answer David was given” I meant you were told this.  I could not verify firsthand how you learned it.



  3. Benjamin Rouger

    I think you are refering to the wrong Solution Manager functionnality for DB management.

    The one you are talking about is the CDMC (Custom Development Management Cockpit) which aim is to get rid of all the custom objects in your systems in order to simplify upgrades and Support Packages implementations.

    The Solution Manager functionnality for managing the DB is called Data Volume Management Cockpit (DVM Cockpit)and is available in SMD (I think). SAP says it gives you a lot of functionnalities to manage your DB (here is a presentation, but I didn’t have the time to test it.

    Maybe this functionnality will be the answer to your needs.

    Benjamin Rouger

    1. Jim Spath Post author

        When you say “you are refering to the wrong Solution Manager functionnality [sic]” let’s be clear that neither David Dobrin nor myself suggested that the development cockpit has anything to do with space management.  He got that answer from SAP contacts, and quoted them.  I wrote the blog partly to point out this is the wrong answer.

        So far, in over 10 years of using Solution Manager, there haven’t been many features I have seen to manage databases.  Highlight possible growth, or bad code, yes, but those were added well after database vendors and administrators provided features to do that.  As I’ve pointed out elsewhere, my company has been archiving data for 10 years, and Solution Manager had nothing to do with that.

        The main point of my blog was to suggest that there are established key performance indicators related to enterprise support costs, and that those metrics are obscure (marked as confidential or shared under nondisclosure agreement), and they seem to rely on ties to tools like Solution Manager that are newly developed, and are thus not widely adopted.  That makes it challenging for people to understand and act.

        I glanced at the slides you referenced on the Data Volume Management Cockpit.  Very pretty.  Do you have any reference customers who have installed this software, actually used it for a period of time, and can share the decrease in total cost of ownership from the project?  If so, I will set them up for webcast, or more likely, a presentation at the 2011 ASUG annual conference.


      1. Benjamin Rouger
        Hello Jim,

        Sorry if I misunderstood your blog, I really though you were refering to CDMC as a tool for DB management.
        Sorry about that.

        As for the Data Volume Management Cockpit, It seems pretty, as you said, but I didn’t have the time to implement it yet in one of my customer SSM. I hope I will soon and will keep you up to date.


      2. David Hull

        Coincidentally, I’ll be going through a DVM session with SAP on ERP and BW in the next week. I’d be glad to share my results with you.


      3. Benjamin Rouger

        Sorry if I misunderstood your blog, I really though at the time you were refering to CDMC as the DB management tool of SSM.

        As for the DVM Cockpit, I hope I will implemenent it soon at one of my customer SSM. I will keep you up to date if I have any feedbacks.


        1. Jim Spath Post author

            No problem; the original source of confusion may have been the way David Dobrin posed his questions, or the poorly thought-through answers he has been getting.  Again, I trace this back to the hidden KPIs, and the motivators for those metrics, as regards enterprise support costs and choices.

            I am entirely in favor of code management, including performance reviews, dead code elimination, and the occasional rewrite-from-scratch exercise, as well as data volume management.  I’ve done both of these as part of my work over the years.  So far, Solution Manager has not helped in either aspect much, but I would not go so far as to say it has been no help.

            As for the Data Volume Management cockpit, I got a sneak peek at SAP TechEd 2010 plans, and that looks like a highly likely session.  However, that event is a few months off, and implementation would be even later for many of us.  Your experiences, as well as those of David Hull and other early adopters, can help smooth the road for the rest of the pack.


  4. David Dobrin
    First some clarification and maybe an apology. In my treatise on the SolMan, I reported that the SolMan did provide some clear, known benefits, basing my conclusion partly on figures that SAP provided to me at the Inflencers Summit.  These figures came from the SUGEN/SAP benchmarking study of Enterprise Support.

    When I mentioned that one of the main, clear benefits was reduction in the growth of disk space, a reader of my blog asked, “How does the Sol Man do this?” More generally, can you tell me how it does garbage collection?” I referred the question to SAP, and I got an answer about garbage collection, which Jim then reacted to above. 

    So I went back to SAP and asked them how the numbers that they gave me were calculated.  They told me that the program in the future will be managed by SUGEN and suggested that I reach out to SUGEN.

    This makes me feel pretty dumb.  I try to articulate a fairly clear position about what the Sol Man does, based on numbers that SAP gave me about the results of a program that SAP was co-sponsoring, and when I ask where the numbers came from and how they were calculated, SAP does not want to say. I will continue to pursue it, but at this point, the numbers appear to have roughly the same status as BP’s estimates of the oil flow. You can believe them if you want, and it’s reasonable to believe that at some point, somebody at SAP believed them.  But no one is going to stand behind them.

    I will have more to say about this in my blog.


Leave a Reply