Manage Repository Storage Space
As the repository is used, it can collect a great deal of obsolete or unused object. As all of this content is live and indexed, it can have an impact on performance and can push the database to its maximum allocation. There are a number of features provided to aid in managing and eliminating this unwanted clutter.
As with any relational database applications, it is very difficult to measure the space used by an application concept as it is dispatched in many tables (as opposed to a file system). This is actually virtually impossible by design in the case MM where there are 4 levels of complexity:
- The meta-meta-model which is a simple ERA / object model implemented in the repository database by a only a few tables.
- itself used to implement the meta-models (profiles) for various technologies such as relational databases, data lakes, data integration, business intelligence, etc.
- themselves used to implement the model instances such as the finance staging database, the data warehouse, etc.
- themselves dispatched under multiple versions with incremental harvesting based on multi-model resuse between versions. For example the first versions will have all schemas of the data warehouse, but the successive versions will only import the schema that changed, reusing the others from previous versions. Deleting the first version will not delete the space reused for schemas of newer versions.
Steps
- Deleted unused test and sandbox type content .
- Delete unused configuration versions
- Delete unused model versions .
- Ensure that all model Imports are performed with incremental harvesting (where available)
- Delete operation logs .
- Turn off the system wide debug logging .
- Run Database maintenance .
- Compress the database .
Did this page help you?
If you find any issues with this page or its content – a typo, a missing step, or a technical error – let us know how we can improve!