Quantcast
Channel: sqlconcept.com »» SQL Server in time
Viewing all articles
Browse latest Browse all 2

Performance tuning in a secure shared SQL Server environment

0
0

I received a very interesting question by email just now and I would like to give the answer here.

I am not sure if the author is OK with me quoting the entire question, hence I will paraphrase it:

We have our databases on a SQL Server instance shared with other databases and for security reasons we cannot have full permissions to query all DMVs for performance tuning. What can we do?

 

Here comes the answer:

  1. On a ‘big picture’ level what concerns me in this case is the setup. Let me explain why: each SQL Server instance comes together with performance measurement tools:
    • DMVs on an instance level
    • DMV’s on a database level
    • instance counters for Perfmon
  2. Each SQL Server instance also provides a possibility to host many databases, and by security layers rules, these databases can co-exist on the same instance and in a secure environment.

    The problem comes from the Perfmon counters and the DMVs on an instance level permissions.

    The ideal solution in this case would be to get your databases in a separate instance, dedicated only to them. This may not be viable, however.

  3. The DMV performance soup:
  4. Why is this a problem? This is a problem, because the DMVs are quite clumsy by design. The permissions you need for the DMVs are as follows:

     

    GRANT VIEW SERVER STATE to login
    GRANT VIEW DATABASE STATE to user

    Also, if you are granted VIEW SERVER STATE, then you will be seeing all performance data from the instance.

    Unfortunately, the instance level DMVs were designed in a way that all performance information is mixed in a big soup bowl and you either consume it or you don’t. :)

  5. The DMVs are clumsily placed in time:
  6. Another problem with DMVs is that they return either point in time values or some summary blob between the instance start and NOW. In other words, the problem is that the DMVs do not provide history or trending info naturally. In order to get this data, you have to get some extra work done.

  7. Also, the tempdb situation is quite messy – all of the databases on the instance are using a single tempdb (regardless of how many files it has) and in case of tempdb contention, you will need proper permissions to access and debug the problem.

 

Ok, I think this was enough theory, now let’s get to some solutions:

  1. As I said, the optimal way to solve this problem with performance measurement would be to get your databases on their own instance, but this is not always possible, I know.
  2. Another way would be to ask your security admin to grant you View State on server and database levels. But then again – you will have to work hard to get trending, and to segregate the performance information which concerns your databases from the rest of the databases.
  3. Another way to get some performance information is to explore the Perfmon counters; keep in mind, though, that you can’t specify the Database as a delimiting parameter for all SQL Server counter classes, i.e. most perfmon counters are on a server-wide level, and not on a database level.
  4. Another way to get performance information is to use Extended Events in SQL Server 2008, but keep in mind that this works from 2008 and up. Extended events are indeed a great way to explore very detailed information about database performance.

 

What can I say, unless you get a separate instance, in your current security context it will be quite hard for you to extract proper and valuable performance information. Still not impossible, though.

Bonus material:

Here are couple queries which give you information on CPU and IO per database and ad-hoc queries. Of course you need proper permissions for them.

-- CPU use per database
 
select SUM(total_worker_time) as TotalCPU
 
,       case when db_name(dbid) is null then 'Adhoc Queries' else  db_name(dbid) end as db_name
 
from sys.dm_exec_query_stats s1
 
cross apply sys.dm_exec_sql_text(sql_handle) as  s2
 
GROUP BY db_name(dbid)
 
--IO use per database
 
select SUM(total_logical_reads + total_logical_writes) as  total_io
 
,       case when db_name(dbid) is null then 'Adhoc Queries' else  db_name(dbid) end as db_name
 
from sys.dm_exec_query_stats s1
 
cross apply sys.dm_exec_sql_text(sql_handle) as  s2
 
GROUP BY db_name(dbid)

Viewing all articles
Browse latest Browse all 2

Latest Images

Trending Articles



Latest Images