Maintenance tip: cleanup of the old Content Packs
After each Content Pack is deployed we will have the residual old CPs which are left on the UCMDB Server disk and DB.
There is an older KM on how to clean an improper CP zip file at https://softwaresupport.softwaregrp.com/doc/KM00583740
From here we can see that whatever we have on the disk in UCMDBServer\content\content_packs we will also have in the content_packs table. Whenever we copy a new CP zip file in that directory we will see in the mam.packaging.log a corresponding log entry that the zip file is being uploaded to the DB, in the content_packs table.
We never clean this table and we can never go back to a previous CP as the CP deployment flow is irreversible.
This means that over time we can get a lot of garbage and useless baggage in the CP directory and DB table.
On the disk
Here we can guess that the initial version for this UCMDB intance was 10.10 with Content Pack 14, this was 6 years ago. The total count for all these CP versions is 5.1 GB
The same zip files will be present in the content_packs table
So the same 5.1GB of zip files are in the DB and only the last CP version is useful, around 300MB out of 5.1GB.
The old CP versions will never be used and they are already accessible for download from https://marketplace.microfocus.com/itom/content/ud-content-packs
There is no need to keep on the disk and in the DB all the previous CP versions.
The clean up procedure is quite simple:
- stop the UCMDB server or all the UCMDB servers in the HA cluster. This means a complete shutdown of the UCMDB servcive.
- truncate the content_packs DB table so it will be empty.
- delete from CUMDBServer\content\content_packs all teh CP zip files except the current CP version.
- start the UCMDB server
- monitor the mam.packaging.log file for the event when the CP zip file that wasn't deleted will be uploaded to the DB
- check the content_pack directory and DB table that you have only one CP zip file, the one that wasn't deleted
The zip files will be synced to the DB table. If the server(s) are down then nothing can be synced from or to the DB table.
Truncating the DB table means that when the UCMDB server will be up again it will be forced to upload in the DB table whatever the server has on the disk. By deleting everything on the disk except the current CP zip file we are controlling what we upload to the DB table.
In the end we will have only the current zip file on the disk and in the DB table.
This is useful for some extra space on the disk and , more important, provide some needed flexibility on the DB level.
EMEA CMS Technical Success