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.
), here are the updated pics 1 and 2).
