We have been using the same database (SQL Server 2005 Express) for both Update Manager and vCenter. It is not a good practice but it is inherbited.
We find that the database has already reached the limit of 4GB. We would like to create another database for Update Manager and remove related tables from the existing database.
Your advice is sought.
I finally find that the size of VPX_HIST_STAT1 table takes up most of the space.
I have attempted to truncate that table but not successful (I have already stopped vCenter Server service). Is there any suggestion ?
Thanks for your advice.
I did follow the instruction but for unknown reason, the VPX_HIST_STAT1 table still occupy 3.2GB. (I have deleted rows and attempted to truncate the table).
Update manager is usually pretty tiny. I think even after you move it to a seperate database you will still hit the limit. VMWare has scripts you can grab from a KB article to wipe your historical statistics, but I wouldn't recommend trying to truncate your statistics.
I think the best option is to move to a 'real' database. How many hosts do you have in your environment?
Otherwise I believe SQL2008R2 express is supported on 4.1, which has a 10GB limit instead. Also if you do decide to truncate your stats make sure you go to vCenter Settings->Statistics and reduce the statistics level. Again if this environment is anything but a lab I would get a real database.
There are 5 ESX hosts + 1 ESXi host. There are only around 20 VMs.
According to the estimate in vCenter, it only takes 0.5GB of space.
I do run the script and only today's statistics is kept. However, to my dismay, the VPX_HIST_STAT1 table occupies around 3.2 GB in size.
Moreover, although SQL Server 2008 R2 Express is not on the compatiblity list, I tried and it works.