The size of your vCenter Server Database is largely based on the amount events/tasks and performance statistics that you retain for your vSphere environment. You can view and edit these settings by going to the vCenter Server "General" settings as shown in the screenshot below (documentation here and here):
A common misconception when changing any one of these retention policies, especially when decreasing the amount of data to be retained, is that the existing data would be purged immediately to comply with the new settings. This is actually not the case and for data that is applicable for removal, there are a set of purge jobs that run on a specific schedule to perform the clean up. Below is the schedule in which these database jobs run for each of the data types:
Performance Statistics:
- Daily Level - Once every 30 minutes starting at 00:00 (e.g. 00:00, 00:30, 01:00, etc.)
- Weekly Level - Once every 2 hours starting at 01:45 (e.g. 01:45, 03:45, 05:45, etc. )
- Monthly & Yearly Level - Once a day at 02:15
Events and Tasks:
- Once a day at 00:15
For customers that are looking for immediate results and reclaim storage from within their VCDB, you can take a look at the following VMware KB 1025914 which outlines the specific instructions. This can especially be useful if you are looking to perform a Windows vCenter Server to vCenter Server Appliance Migration and wish to reduce the overall amount of data that is being copied over from your existing environment.
Recently I shrunk our Windows vCenter 5.5 MSSQL DB from 140GB to 32GB. (and temporarily grew the transaction log to 412GB...) Apart from historical growth of several years, I purged a massive contamination of login/logout events from vShield Manager, in both the VPX_EVENTS and VPX_EVENTS_ARG tables. The fear of not being able to modify/repair the vCenter DB after migration to VCSA keeps me from migrating to VCSA. Do I have a point or is there nothing to worry about?
Hi Marcel,
I don't think you have anything to worry about. First off, I've heard of some of these "verbose" types of entries which should have been fixed if they've been identified by VMware as a defect, especially for older releases of vSphere and their respective solutions. As an end user, you should not have to go into the DB and clean these things up, we should and ensure we do the right amount of logging/etc. Secondly, simply moving to the VCSA does not prevent you from being able to purge some of these more common tables which we document in a KB. We definitely would like to be able to control such functionality via UI/APIs rather than direct SQL calls and its something we continue to look to improve upon. Its not secret, that the VCSA is the future direction for VMware and with vSphere 6.5, we've done a lot to improve on not only the scalability/feature parity from Windows but we've also added VCSA-only capabilities like giving you further insights into the DB so you know what is being stored/etc.
Hello. Thanks for posting this. Very helpful. I have one question.I have a embedded database which is 100% full. If I run the following commands will it will only clear the performance statisics & Events and Tasks shown in your example?
# service vmware-vpxd stop
# /usr/sbin/vpxd -b
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2013047
No, this will clear/reset your ENTIRE VCDB as mentioned in the KB you've linked to. This is not the same procedure as what I've mentioned
There is an other kb article (https://kb.vmware.com/kb/2110031). Does this do the same cleaning as kb1025914?