Skip to Content

How to reduce the size of tables SACONT01 and SASACONT1 in Solution Manager

I’ve decided to write this blog post after noticing in the last years that many customer often are curious about the size and content of tables SACONT01 and SASACONT1. These tables commonly present a high amount of content, which makes  people concerned about it.

The SACONT01 table basically contains documents content, which belong to SAP Solution Manager and are stored using Knowledge Warehouse. It’s content resumes to documents in area IWBSOLAR.

These documents are created and managed in the Implementation area( SOLAR01, SOLAR02, etc.) and depending on the usage of projects, this table can grow very big. As long the documents are being created and managed, every version of these documents is stored(you may access older versions through document’s history of changes), that is the main reason for the table growth.

Also, even if you don’t use projects and has never created a project, this table will grow as long as you keep implement ST-ICO packages. This package delivers content for the implementation area, and one example is the BPR(Business Process Repository) content. This includes many previously built business scenarios and documents for usage in projects.

Now, regarding table SASACONT1, it is very similar to SACONT01 but it is specifically for roadmap content. It handles the content created for roadmaps and content delivered by ST-ICO as well, more specifically documents.

In summary, both tables are directly related to the implementation area of Solution Manager and can grow a lot depending on the usage of this area and the amount of content created.

Now the question is: “How to reduce these tables size?”

As We’re dealing basically with documents in both cases, there are a few options that can have a very positive impact on these tables size.

Firstly, there are some very useful reports that can help in this case:

SOLMAN_DOCU_VERSION_ARCHIVE: This report basically moves document versions into    another content category. As mentioned in note  1360988, This report moves all document versions of the selected status values that were changed last by a person other than “SAP”, except for the most recent version in each language. As mentioned before, for each version of a document, there is a physical version of it and this can occupy a lot of space since there is basically one physical document for each version of it. I suggest to read the note 1360988 which explains in more details this report and how to use it.


SOLMAN_DOCU_VERSION_DEL: This report works in similar way as the previous one but instead of moving the document’s older versions to another content, it’ll delete these versions. For this report I recommend to read the note  1360436 as it explains this report in more details and how to use it.


SOLMAN_UNUSED_DOCUMENTS: This is another very useful report I strongly recommend. This report searchs for documents that are unused. A Document is considered unused when it is not assigned to any project but it still exists physically. In Summary, unused documents are basically documents  that were created in the implementation area but the users removed it’s assignment and they are not being used anywhere anymore. For further instructions on how to use this report I suggest the notes 1331124 and 923203.


Note: The reports above affects only documents in area IWBSOLAR.

The above solutions will only affect the table SACONT01. For roadmaps area, SASACONT1, there is no corresponding report so far, so you have to ask yourself a question.

Do you have a large number of own roadmaps?

If not the size of this table will be mainly determined by the roadmap documents contained in ST-ICO. Unfortunately if you would delete unused roadmaps this would not delete the  documents. There will be a deletion report in future but it is not available so far.

However it is planned to reduce the size of future support packages of ST-ICO by deleting unused or outdated roadmap documents. This would be a solution if there is not an acute problem with table space but only concerns of further growing.

And last but not least, the usual way to reduce the size of these tables is move the content to an external content server, which can be a complicated solution but the one I would mainly suggest.

In transaction OCA0 you can change the customizing of a content repository and assign an external content server instead of the currently maintained DB table. This is explained in note 546685 and the detailed steps are contained in note 710711.

Please have in mind that the usage of implementation area generates a lot of content when and there is also many content delivered via ST-ICO. In summary, these tables will always have a lot of content, so again, it is highly recommended to take into account the use of an external content.

I hope this information helps to solve your doubts and reduce these tables size.

Additional Info:

  • 1773780 – How to check if a document was successfully archived by SOLMAN_DOCU_VERSION_ARCHIVE

In case you’re interested, I’ll be posting more content in my personal blog from now on.

You must be Logged on to comment or reply to a post.
  • Hi Fabricius,

    There are a hole lot of options visible after running the report SOLMAN_DOCU_VERSION_ARCHIVE like target category of document and target category of URL document which is a comprehesive list.

    Is there a way to select all and archive?



    • Hi Ankit,

      I didn't find any way to select all the categories, but this would not be the best choice. Actually it would be better in this case to focus on these two categories:

      SOLAR01 Documents in Solution Architect
      SOLARURL URL in the Solution Architect

      Basically, these are the ones directly related to the whole area of implementation and test workbench. I think it wouldn't be a good idea to select all the categories because it will then gather basically documents from all areas, and I'm not sure if there is any particularity  in the way these other areas handle their documents.

      Also, as far as  I remember now from top of my mind,  these two categories are the only ones that affect the mentioned tables.

      Kind regards,


      • Hi Fabricius,

        Thanks for the reply.

        The PSAPSR3 tablespace on Solution Manager has been increasing at a very fast pace, with daily growth of more than 200 MBs.

        This is despite the standard reorg, update jobs running on the system.

        The major contributors on this growth are LOB segments, any suggestions?



        • Hi Ankit,

          This table is from a complete different area. I have no knowledge about it's content. I would only suggest to check the parameters.

          This note should help you:

          #1171650 - Automated Oracle DB parameter check

          kind regards,


  • Hi Fabricius, 

    excellent post,  I have a question, where are stored the documents attached to service request (incidents, tickets, support notifications)?  How can I evaluated the size used by this type of documents?

    thanks in advance.

    • Hello there,

      This is a little bit different. I don't have much deep knowledge in that area but I can say that for the old transaction types that used also the basis message it was rather different than the new ones that uses CRM.

      Regarding the basis notification:
      Here the SAP Office functionality is used to save the attachments.
      This is linked to the basis message via GOS (Generic Object Services)

      Regarding the CRM notification:

      The attachments are saved in the Content Management. You can see also function module CRM_DNO_ORDER_MAINTAIN, Form crm_attachment_create to understand it better.

      I'm not sure on where physically these files are stored and which tables are involved but I hope the information I've got can help you.

      kind regards,


      edit: correcting typos