An Azure SQL instance is running at DTU of 399% approx. This is slowing my whol application down.
A worker role started a number of Stored Procedures last night and seems to have sent the processing through the roof.
Is there any way to tell exactly what processes/procedures are causing the high DTU?
Is there any way to end those processes/procedures?
I am new to Azure so appreciate any pointers that may help me to determine the exact cause and cure for my crazy DTU %.
You can use the view sys.dm_exec_requests to see running processes, and sys.dm_exec_query_stats to see stats on queries that have run in the past but still have their plans in cache, including frequency of running and average resource use per query.
These views include a column called SQL_HANDLE which can be used to probe the function sys.dm_exec_sql_text() documented here
(This function can also be joined directly to the first two tables I mentioned -- there are examples in the doc.)
There's a good blog on the topic here
Once you find a running query that you want to kill, you can issue the KILL command, based on the session_id reported in sys.dm_exec_requests, from an interactive query tool or the portal's SQL interface as long as you have admin privileges.
Related
On our Prod Database which is based on Oracle, I want to see the number of queries which get fired.
The reasoning behind is that we want to see the number of network calls we make and the impact firewall could make if we move it to a cloud system.
select sum(EXECUTIONS)
from v$sql
where last_active_time >= trunc(sysdate)-2
and (parsing_schema_name like '%\_RW%' escape '\' or parsing_schema_name = 'TEMP_USER')
and module not in ('DBMS_SCHEDULER')
and sql_text not like '%v$sql%';
Above query doesn't seem very reliable due to SQLs being pushed out of memory which is what the above one returns.
Is there any way to get the number of calls we make on our Oracle DB from the database itself? Logging from all the applications is not a feasible option at the moment.
Thanks!
"we want to see the number of network calls we make and the impact firewall could make if we move it to a cloud system"
The number of SQL statements executed is only tangentially related to the amount of network traffic. Compare the impact of select * from dual with select * from humongous_table.
A better approach might be to talk with your network admin and see what they can tell you about the traffic your applications generate. Alternatively download Wireshark and see for yourself (providing your security team is cool with that).
Just to add some information on V$SQL views:
V$SQLAREA has the lowest retention, and shows the current SQL in memory, parsed, and ready for execution.
V$SQL has better retention, and is updated every 5 seconds after query execution.
V$SQLSTATS has the best retention, and retains SQL even after the cursor has been aged out of the shared pool.
You don't want to run these queries too often on busy production databases, as they can add to shared pool fragmentation.
I have a requirement to generate CPU usage reports for my SQL server for previous 7 days. I will use a graph to represent it.
Also, I have to keep track of top 10 queries which consumed maximum CPU each day.
I got one post below but I have few doubts.
CPU utilization by database?
Doubt:
How I will know that, how was the overall CPU usage yesterday? Do I have to add all the AvgCPU time for distinct queries ran yesterday?
There is no reliable way in Getting cpu usage per day/last 5 days..I see SQLServer has below columns..
select
creation_time,
last_worker_time,
total_worker_time,
execution_count,
last_execution_time
from sys.dm_exec_query_stats
And those reported below on my test instance..
As you can see from Screenshot above..
We can't reliably get ,count of instances a particular query got executed on a particular day..And moreover you will see this entire data gets reset if you restart SQLServer
If you really want to show data on daily basis,you could use perfmon..Here are some tutorials which may help you..
1.Collecting Performance Data into a SQL Server Table
2.Using PerfMon for SQL Server Reporting Services Performance Management
You may also take a look on MS SQL Data collection sets. Easy to deploy, easy to keep necessary data (as long it stored on dedicated DB), and at least its really fits your requirements for top 10 CPU-expensive queries.
You can also slightly modify t-sql for collector agent and target tables on collector server in order to obtain some extra CPU info if you need it.
I'm experiencing periodical Azure SQL Database connection slow downs. As recommended in Wait statistics, or please tell me where it hurts article I ran sys.dm_db_wait_stats (analogue of sys.dm_os_wait_stats for Azure SQL Database) aggregation script which show me that longest waits are of type XE_FILE_TARGET_TVF. Average wait time is 54 seconds.
XE_FILE_TARGET_TVF didn't mentioned in documentation as in any other online resources that I know. I suspect that "XE" means "Extended Events", "TVF" is "table-valued functions", "FILE_TARGET" is probably indicator that something is being written to some file.
So, what kind of wait it is?
Use Azure SQL Database Query Performance Insight for troubleshooting SQL Azure DBs. To begin with, wait stats alone are not a correct performance troubleshooting approach. Read How to analyse SQL Server performance for a more thorough approach, learn to analyze also where the CPU is spent, not only where the elapsed time is spent waiting. Aggregate wait stats are often misleading, filtering out the 'benign' wait stats is a chasing the red lights game.
Unfortunately not everything is actionable in SQL Azure DB environment. Start with the Query Performance Insight to see if you can correlate the performance issues with queries issued by your app. Use the SQL Database Index Advisor to get index recommendations for your workload.
If you cannot find the application problems and suspect this is caused by the platform, you will have to open a support case. Twitting #AzureSupport is very effective in getting help.
To answer your question: a lot of Azure SQL DB monitoring relies on Extended Events and they store data to files. This specific wait stat is unlikely to be related to the cause of your performance problems.
I believe that it's a async process so possibly nothing to worry around and could be a red herring. However I think this is a fabric related task behind the DB. Does this event seem to be consistently causing you issues?
I need to enhance query performance and analyze queries but I am unable to open/see Execution Plan viewer. This is because "SHOWPLAN Permission" is denied in my environment (probably because it stresses the CPU). Anyways, are there alternatives to Execution Plan viewer? Could I get similar types of information via other means?
Also, with or without Execution Plan viewer, does anyone know how to open the Seek Predicates window? (I can't upload picture because apparently I don't have good enough reputation lol)
Thanks so much!
try executing "SET STATISTICS IO ON;" before you run your query.
In the "Messages" pane, it will tell you how many logical page reads (8K each) it is doing on each table. Not the only metric to look at, but very useful nonetheless, for identifying what is slowing down your queries.
I just created a user x with read only permission, logged in as x and was able to do the following:
set showplan_text on
select * from sys.objects
Try and you may find what you need.
I am in the process of upgrading our server from one version to other.So for this purpose i need the detail of all the queries executing in single transaction.
I am enabling trace logs for that but that is a tedious process as it contains system related queries also.AWR reports seems to be not working.
I am using oracle 10/11 g.Is there any other way in sql developer to achieve this goal.
Tracing is the only way to see all statements executed. AWR works by sampling active sessions; this significantly cuts down on the overhead and data yet provides plenty of information for performance tuning. But this means that AWR will miss many queries that run very quickly.
To remove recursive queries you can run the trace file through tkprof with the option sys=no.