I had the same issue after the upgrade. I rebooted VC, nothing. I waited 2 days, rebooted again and everything was ok. I can't really give any real explaination to why the stats were missing, but wait a bit a try a reboot.
Did you trash and start clean with your VC database during the upgrade?
Could be there is no historic data for it to display.
What kind of object are you selecting for data anyway? a host, VM, cluster, or is the problem on all objects?
What version of SQL are using to host your DB? Before the upgrade did you have resource pools or aything configured? And if so.... were they present after the upgrade?
It was an upgrade with no overwrite of the database. Either way the upgrade was done last Monday so we should have some level of historical data in there by now.
It is happening with every object from datacenters on down.
SQL 2000 all roles, and resource pools are still present after the upgrade. There is no indication that the database was trashed.
Do you get your graphs when you connect your VIC to an individual esx host?
Did you ever get this fixed? I am having exactly the same problem here. We have a mix of ESX 3.0.2 and 3.5 servers and our VIC was upgraded from 2.0 to 2.5 with the option of keeping stat history.
After working with VMware support the problem was the SQL jobs for rolling up the historical information were missing/corrupted. So the end result was we uninstalled VirtualCenter. Restored the database back to a point prior to the upgrade to VC 2.5. Then reran the VC upgrade making sure to migrate everything from the database.
After that was completed we were once again able to access the historical data.
I've the same issues with VC 2.5.0 and SQL Server 2000. Please check the existence of categories or jobs for stats rollup in msdb database.
I think the missing or corruption of the jobs are depending on the update history and the miss of dbowner rights on the msdb database during the first VC installation.
Querys to check existence of job and categorie in msdb database
SELECT * FROM msdb.dbo.syscategories WHERE name = N'Stats Rollup';
SELECT * FROM msdb.dbo.sysjobs WHERE name = N'Past Week stats rollup';
My problem or question is an solution to fix this problem without a restore of the database back to a point prior the upgrade to VC 2.5 (db version 3) and rerun the db upgrade (db version 4).
You are correct the problem resulted from the SQL Select statements getting wiped out. I worked with VMware for about 2 weeks trying to come up with a way to rebuild those select statements. However we weren't successful and we resolved the issue by restoring our database from just prior to the upgrade to 2.5. Then we re-ran the upgrade process making sure to move over the historical information. This was also after confirming the proper permissions on the SQL database.
The upgrade took forever while upgrading the historical data. But after that was completed the SELECT statements were back in place and we started gathering historical data once again. During all of this the SQLAGENT service was running.
I found this to be the case as well. What I found was we have 2 NICS on the VC. For whatever reason one of the NICS was intermittent between the VC and SQL Database, so when I was clicking on historical rather than real time, I saw "unable to display". I eventually fixed/replaced the NIC and everything is good now. It could be that traffic between the VC and DB server is interrupted somehow.
The msdb is used to create the agent jobs and not much else.
NOTE: before you run any scripts your VC login must have Owner rights on msdb as described in the permissions kb 1003052 for all the same reasons.
Do you have the three agent jobs? There should be:
Past stats Day rollup
Past stats Month rollup
Past stats Year rollup
If not, you can find them in your install dir at "C:\Program Files\VMware\Infrastructure\VirtualCenter Server" as "job_schedule<1,2,3>_mssql.sql"
To run them open SQL Manager (studio) as your VCuser (not SA or Administrator), open query analizer, paste the first script, select your VCDB and execute the script. Do this for the other two scripts.
If you have the jobs, make sure they are running as your VCuser.
If you have the jobs and things still don't work, check your VC stored procedures, I have the following listed under VCDB/Programmability/Stored Procedures:
Also, what user context are they running under? they are listed as user.delete_stats_proc.
If you are missing any of them you can find them in the same directory as the job scripts as
delete_stats_proc = delete_stats_proc_mssql.sql
load_stats_proc = load_stats_proc_mssql.sql
purge_stats1_proc = purge_stat1_proc_mssql.sql
purge_stats2_proc = purge_stat2_proc_mssql.sql
purge_stats3_proc = purge_stat3_proc_mssql.sql
stats_rollup1_proc = stats_rollup1_proc_mssql.sql
stats_rollup2_proc = stats_rollup2_proc_mssql.sql
stats_rollup3_proc = stats_rollup3_proc_mssql.sql
Run them in the same way as the jobs described above.
I have two more I think were installed from VC2.0.x because they don't exist in the VC dir.
Let us know what your investigation finds.
This was really helpful to me, a repair install wasn't creating the jobs even when my perms were set.
One more step I had to take though was to change the target of the steps to be my VC database. They were attempting to target master.