In one of my April 2008’s posts I noticed a standard SAP R/3 / ECC application tables which may potentially grow rapidly and then they may cause problems. I mentioned in there some tables from other SAP solutions like CRM, SCM, MDM, APO, PI, etc. In today’s post I would like to focus on BW big tables.
• BW statistics data: RSDDSTATAGGR, RSDDSTATAGGRDEF, RSDDSTATCOND, RSDDSTATDELE, RSDDSTATDM, RSDDSTATEVDATA, RSDDSTATHEADER, RSDDSTATINFO, RSDDSTATLOGGING
• PSA error logs: RSERRORHEAD, RSERRORLOG
• BW staging engine tables: RSMONMESS, RSSELDONE
• BW workbook tables: RSRWBSTORE
• Temporary BW tables: /BI0/0*
• RSBMNODES – “Hierarchical Log: Nodes”; If e.g. it takes a long time to set a DTP request to 'green' after it has been processed it is caused by large volume of data in this table. Since BI system in production a quite long time you got a lot of logs in it then you have a huge amount of entries in this table.
• RSBERRORLOG (Logs for Incorrect Records) – stores error handling logs due to following and other reasons:
• Warnings that are created during master data uploads for duplicate records
• Single record error messages in customer-specific transformation routines
Table is accumulated a numerous error messages records for a DTP requests. In most cases this is due to many errors while BW is processing data and InfoPackage (IP) or Data Transfer Package (DTP) is setup in way that every data duplicity needs to be recorded.
So here it is, yes really it has 151 milions of records. I took me a half an hour to get this pop up window.
So here it is, yes really it has 151 milions of records. I took me a half an hour to get this pop up window.
Since the fact tables of the InfoCubes are usually one of the biggest tables in a SAP NetWeaver BW you can observe their volume as well. Table names have following naming conventions:
/BIC/F* - for fact table before cube compression
/BIC/E* - for fact table after cube compression