Skip to Content
Technical Articles

How to Find which is the Largest Table in SAP?

Introduction

In this current world everything needs to be very fast. In order to make sure SAP is fast we have to make sure the Table size is optimized and so monitoring is very important and based on that Archiving Strategy. This blog will tell you which are fastest growing table so that you can take action on them. This blog will work for SAP ECC and SAP S/4HANA

This blog is inspired by

 

https://help.sap.com/viewer/7f002268f15f44ce928fc182082fc26c/107/en-US/b49c1aa4881f45cc896c58fadf7d2033.html

Solution

Login to SAP and Go To Transaction Code DBACOCKPIT

Now Select Large Tables

Now Hit Apply Selections

Wala we go the Result

 

Conclusion

This blog is very important for anyone moving to SAP S/4HANA and anyone who is in SAP S/4HANA so you can keep track of your storage and performance is not hampered.

 

Below is the video version

 

4 Comments
You must be Logged on to comment or reply to a post.
  • This blog will tell you which are fastest growing table so that you can take action on them.

    No, the blog doesn’t tell us that. It shows how to get a list of tables by size. It’s static information and not evaluation of table growth. There is a separate metric for fastest growing tables and Basis admins should already be aware of it. (Google -> how to check fastest growing tables in sap -> finds lots of information in case someone wants to know.)

    In order to make sure SAP is fast we have to make sure the Table size is optimized and so monitoring is very important and based on that Archiving Strategy.

    To be honest, I’m having trouble understanding this sentence but it seems to allude that space occupied by the database tables directly correlates with the system’s performance. I’m not a Basis admin but I doubt it’s an accurate statement. It’s possible to have a well-performing SAP system with a very large DB and vice versa. At least in ECC, there are usually separate application and DB servers to start with and there is the whole lot more involved in the full picture. Performance is a very complex subject and I believe the difference in architecture between “any DB” used in ECC and in-memory HANA DB would be significant enough to warrant discussing these scenarios separately.

    It seems that you’re very passionate about spreading knowledge. And even though I have a different opinion on the value of these low-effort blogs, we can “agree to disagree”. If you want to keep posting these and some people read them – more power to you, whatever. But I’m afraid in this specific case the blog might actually be spreading misinformation. So I’m wondering what sort of fact checking was involved in writing of this blog? Where did you get this information?

    Matt Fraser – does this make sense to you?

    • Interrelations between table size and system performance can be complex, and in general, no, there is no direct correlation. Appropriate configuration of useful indexes will usually have a much larger impact upon performance than table size. Other factors, such as buffering, disk I/O strategy, etc, also play a role. And yes, whether this is an in-memory database such as HANA vs a traditional relational database such as SQL Server also impacts the relative importance of all these factors.

      That said, it is important to keep an eye on the fastest-growing tables, for various reasons. But, again, fastest-growing is not the same as largest. If left unchecked, they may become the largest, but often they are not. And, the technique here, as Jelena pointed out, finds the largest tables, not the fastest-growing ones.

      Finally… the technique illustrated here seems to be specific to HANA. While we would still use DBACOCKPIT as the point of entry to find this information on another database such as SQL Server, the path within the tool is considerably different. At a conceptual level, it works for both S/4 and ECC, but at a practical level, if it’s ECC then it is database-dependent.