@ Jeffrey

your test - SQL server is virtualized?

@ Mike

i don't belive its the virtualization, because in vsphere the processors haves ca. 40% free resources, so the processors aren't under pressure....

@ Jeffrey

thanks, i hope someone from Microsoft reads this and fixes the bug in the Activity monitor.

I think i have a special non standard configuration on my servers, the same...

next update:

if i watch the CPU in taskmanager, after i openend processes in activity monitor, the vCPUs goes from 10 % to 30%. So it seems that the query don't...

and in the taskmanager of the VM i don't see CPU pressure

the CPU is ca. on 10 % on both VMs...

yes, its a Vmware - server

but than its the first time, that i see a negative effect with Vmware...

@ mike:

the exact RAM values:

the server has 20 GB RAM

SQL has maximum memory set to 17000 MB

so the OS has purely ca. 3 GB of RAM

But an other server with...

update:

the problem is not only with SQL 2014 but with SQL 2017 too

@ MVDBA

it has 20 GB for the OS, 18 GB for the SQL - Server.

I don't think thats a buffer cache issue, because if i execute it after the first...

sorry @ all

"Live Query Statistics" has no correlation to the execution time.

The query sometimes is fast and sometimes it needs above 40 seconds to execute.

It was yesterday for chance, that...

@ Jeffrey:

it's the origninal query that i catched with the profiler:

WITH profiled_sessions as (

SELECT DISTINCT session_id profiled_session_id from sys.dm_exec_query_profiles

)

SELECT

[Session ID] = s.session_id,

[User Process] = CONVERT(CHAR(1), s.is_user_process),

[Login] = s.login_name,

[Database] = case...

Hi Jeffrey,

i noticed the same with SSMS 18.4 and MSSQL 2014.

But the funny thing is, if you execute the query "WITH profiled_sessions as (SELECT DISTINCT session_id profiled_session_id from sys.dm_exec_query_profiles ....