SQL Server DBA's should get access to the ACTUAL execution plan, not the ESTIMATED plan. (This would bring it in line with Oracle)
Currently Desktop Performance Analyzer (DPA) shows the ACTUAL plans for Oracle DB's, but only the ESTIMATED plan for Microsoft SQL Server. This means for SQL Server you can't see what plan was actually used. This is of significant interest if you have any performance related issue. We can't see how many full table scans there were, how many actual rows were returned, or actual CPU & IO cost etc.
Some of these are likely to be fairly typical in many environments;
1. When there are performance issues, you can't manually run that SQL statement via SSMS or other tools to get an ACTUAL plan. For example if you have an issue in a Production database, that occurred yesterday, you can't rerun the actual SQL of concern
2. You can't pull the ACTUAL plan from the CACHE because its likely flushed
3. You might not know the parameters/variables used in that run. !,000 may run ok, so what was the ACTUAL plan for that 1 that didn't run ok and was it because it had a lot of rows returned?
4. SQL statements may use multiple plans, so estimated has little value
5. Estimated plan doesn't show ACTUAL row counts, CPU, I/O etc, or actual table/clustered Index scans so hard to problem solve that
6. You can't recreate in a copy of the DB, the server, statistics, or data, or input parameters, may be different
7. You can't compare an actual plan, with another actual plan, if there are "small" code changes that break code (or different plans used) or need to be validated in QA/DEV before deployment
It is much more valuable if DPA had a way to view ACTUAL plans (even if there was some sort of threshold, like > 1 seconds elapsed time)
