How can I manual immediately trigger the database retention policy of vSphere Server 4.x ?
I also have tryed the MS-SQL Script from KB 1025914 but it does´t purge the tables VPX_EVENT_ARG, VPX_EVENT.
This two tables need the most space in the DB.
However at VC3.5 I use the script of KB 1000125
and it purge the tables VPX_EVENT_ARG, VPX_EVENT.
How can I reach this goal with a compatible script for vSphere Server 4.x ?
re-index and take a look at your transaction logs as well as think about going from full recovery mode to simple.
I forget to mention that I use MS-SQL Server 2005 Express. The problem is the 4 GB DB limit.
If you have to run SQL scripts to clean up, then do the "database retention policy" settings actually do anything?
The DB was at 12.9GB with the default of infinite. I changed it to 720 days with the plan of reducing that a step at a time out of curiosity. It grew and is now 13.3GB. I just now set them to 180 days. I'll ask our DBA to do the purge/shrink but then what's the point of the setting?
side note: the DB sizing utility lists ~2GB for the setup. Statistics level 1.
I'll ask our DBA to do the purge/shrink but then what's the point of the setting?
Good question, our database is around 300GB, just for the LOG. the main database is around 80GB, so 400GB for both. Not REAL big, but big enough. That's an interesting point. I just changed our policy recently for 90 days to keep this file from getting out of control, and wondered the same thing.
I believe there SHOULD be a script in the vCenter folder someplace that does trigger it... but I don't know that anyone has actually TESTED it. I might have to try it...
Of course it actually COULD be working, the database itself does NOT shrink unless you do it with a SQL command. So you won't see the database is actually smaller until you perform the steps. So maybe the data is actually gone, but database size does not reflect until AFTER the database is shrunk.
Mine is set to 90 days now. Our DBA has shrunk the DB a few times. Each time it shrinks by half but by the following morning it is back up where it was. I haven't watched it closely enough to see if it grows gradually or all at once. He hasn't run the 1025914 script with the delete option actually on. Hopefully we'll be doing that tomorrow.
Found that the DB had a space reservation set along with Auto Grow, thus why the DB kept going right back up. Lowered the reservation and turned off auto grow. Doesn't explain why the DB space used is more than 3x the size of VMWare's estimator with only a 90day retention, but it is progress.