VMWare VMotion isn't going to reboot your server, restart any services or drop caches. The VM stays live during the VMotion, so you shouldn't lose cache or plans, unless the host you are moving to is under severe memory pressure and ballooning is active.
What does happen during VMotion is increased network latency and maybe a dropped ping while migrating, but that effect is completely gone once the migration is over and should not affect CPU usage inside the guest.
However what you need to understand is that the %CPU use inside the guest is the % you are consuming from the pool of resources that has been allocated to you by the hypervisor (not the underlying CPU) so if you move from a host allotting you 4Ghz to a host allotting 2Ghz the CPU usage inside the guest would double.
There are a few performance counters you could monitor inside the guest VM to see the actual CPU time you are getting from the Hypervisor such as:
- % Processor Time
- Effective VM Speed in MHz
- Host processor speed in MHz
- Limit in MHz
See here for a start
Which could give you an idea of the actual MHz you are getting, any limitations imposed by the VMWare configuration etc.
If you have determined the Hypervisor isn't allocating enough cycles to your VM you could set reservations to guarantee a certain amount of MHz or add a cpu weight to the VM giving precedence to your VM over others.
If you have access to esxtop (not the flattened sampled averages charts from vCenter) you should keep an eye on %RDY (indicating your VM has threads waiting for a physical cpu) or %CSTP (indicating co-scheduling issues). For more information read through this yellowbrick post
Since you are saying the host is having other high load VM's you also need to consider that VMWare is trying to allocate resources to the most demanding VM's when configured with defaults. A sudden increase in load in another VM could have dramatic (temporary) effects on your VM's cpu allocation.
Unless there are severe memory pressure issues I don't see how you could get cache flushes unless the new host reclaims a lot of the memory through the balloon driver or dynamic memory settings resulting in cache flushes. Otherwise the machine stays live and memory is copied over in lockstep
What you do is to create your subscription to run only once. Then you go to the agent job it created and copy the step's code. This you can then run in a stored procedure after checking if there are data:
if (select * from table where date = '2018/05/18')
exec [ReportServer].dbo.AddEvent
@EventType='TimedSubscription',
@EventData='xxx data copied from job xxx'
The AddEvent will then execute the report to execute.
Best Answer
I can confirm in SQL Server 2008 R2 Service Pack 3 (v10.50.6000.34), simple parameterized queries do result in the parameterized values being recorded in the audit log.
I setup a simple test rig, as follows.
Create a server audit:
Create a database where we can play with auditing:
Create a table in the database:
Create a database audit spec:
Create a stored procedure and trigger an audit action:
Perform a direct parameterized test:
Finally, run a simple-parameterization test:
The execution plan for the above two simple-parameterized statements shows simple parameterization is working as expected:
Read the audit log, using a cursor and
PRINT
to preserve formatting:Results:
As you can see in the above output, the simple-parameterized statement run-time values were captured in the audit log.