How do I see the currently executing SQL statements in SQL Server? I've poked around in SQL Server Management Studio, but I don't see anything "canned".
Profiler will log, and allow you to view, all activity on the server, if that's what you're looking for.
http://msdn.microsoft.com/en-us/library/ms187929.aspx
The active connections can be listed with the built in stored procedures sp_who and sp_who2. At least one of them (don't remember which one right now) shows executing commands on the exact time when the sp is run.
As mentioned in another answer, sql server profiler is a great tool which gives much more detail and logging of activity. The sp:s just provides a quick overview.
Activity Monitor (in SSMS under Management) is a GUI version of sp_who2. To identify the T-SQL being executed, run DBCC Inputbuffer and the SPID, eg,
DBCC inputbuffer(54)
SQL Server DMV's are great for finding information like this. For example the sys.dm_exec_connections table will show you a lot about the user connected to your database.
If it is of interest, our Cotega service has the ability to do an analysis of your database and show you this as well as a lot of other things (such as top queries by CPU, IO, etc) which is available to even the free accounts.
I hope that helps.
Related
I am using a DB2 v10.5, and I am pushing messages into the database I created using a gateway. Is there a way to check the DB2 sql logs for actual SQL operation executed?, ie how many rows were fetched etc? While googling, I find these logs inside the DB2 server in the DIAGPATH /db2/db2inst1/sqllib/db2dump/ but I don't see any SQL messages in there.
I have been checking DB2 guides as well but any ideas to help me on this is greatly appreciated. Thank you.
Activity event monitoring
Briefly:
It acts like "logger" for executed statements. The information is written to the tables of such an event monitor for sessions with such a "logging" enabled.
There is also the package cache. This holds aggregate metrics for all executions of a statement that are still in the package cache (entries get evicted from the cache as newer statement arrive). MON_GET_PKG_CACHE_STMT
You can also use the Db2 Database Management Console which is
A new browser-based console that helps you administer, monitor, manage and optimize the performance of IBM Db2 for Linux, UNIX and Windows databases.
and which itself collects data via functions such as MON_GET_PKG_CACHE_STMT and Activity Event Monitors
The tempdb of my instance grew huge eating up all the available disk space and causing applications to go down. Had to restart the instance in emergency. However, I want to investigate and dig deep as to what caused the temp db to grow huge all of sudden. What were the queries, processes that casued this? Can someone help me to pull the required info. I know I wont get much of historical Data from the SQL serevr. I do have the Idera SQL Diagnostic Manager(third party tool) deployed. Any help to use the tool would be really appreciated.
As for postmortem analysis, you can use the tools already installed on your server. For future proactive analysis, you can use SQL traces directly in SQL Profiler, or query the traces using SQL statements.
sys.fn_trace_gettable
sys.trace_events
You can also use an auditing tool that tracks every event that happened on a SQL Server instance and databases, such as ApexSQL Comply. It also uses SQL traces, configures them automatically,and processes captured information. It tracks object and data access and changes, failed and successful logins, security changes, etc. ApexSQL Comply loads all captured information into a centralized repository.
There are several reasons that might cause your tempdb to get very big.
A lot of sorting – if this requires more memory than your sql server has then it will store all temp results in tempdb
DBCC commands – if you’re frequently running commands such as DBCC CheckDB this might be the cause. These functions store its results in temp db
Very large resultsets – these are also using temp db to run properly
A lot of heavy transactions such as bulk inserts
Check out this article for more details http://msdn.microsoft.com/en-us/library/ms176029.aspx on how to troubleshoot this.
AK2,
We have Idera DM tool as well. If you know the time frame around what time your tempdb was used heavily you can go to History on the Idera tool to see what query was running at that time and what lead to the server to hose... On the "Tempdb Space used OverTime" you would usually see a straight line or a graph but at the time of heavy use of tempdb there's a pike and a straight drop. Referring to this time-frame you can check into Sessions>Details too see the exact query and who was running the query.
In our server this happens usually when there is a long query doing lots of join. or when there is an expensive query involving in dumping into temp table / table variable.
Hope this will help.
You can use SQL Profiler. Please try the link below
Sql Profiler
Are there SQL commands that I could use to extract performance monitoring data from MS SQL 2005, such as:
transactions per second
page reads/writes
connections (##CONNECTIONS gives the total, but what about current)
physical reads
locks and blocks
other counters that might be interesting?
You want to look at Dynamic Management VIews (DMVs), introduced with SQL 2005.
This is a really great document from MS that gives you an overview as to how to use DMVs troubleshoot performance issues:
http://download.microsoft.com/download/1/3/4/134644fd-05ad-4ee8-8b5a-0aed1c18a31e/TShootPerfProbs.doc
The best way of seeing what's going on under the hood in SqlServer is to use the Performance Monitor built into windows, click Admin Tools -> Performance. If you haven't used it before the trick is to start it, then click the + icon at the centre top of the window, a dialog opens with 100s of different measures that you can then chart,.watch, or log.
SQL Server has loads of counters that you check out, what all the data means is of course a different question. This solution doesn't integrate with TSQL or Management Studio, but it is the best way of finding out what's going on.
A great place to learn how to performance tune SQL Server is Brent Ozar's website.
It includes details of how to use Performance Monitor, DMV's and how to data mine and interpret the results.
http://www.brentozar.com/sql-server-performance-tuning/
I'd like to know what stored procedures are currently running to diagnose some performance problems. How can I find that out?
Very useful script for analyzing locks and deadlocks: http://www.sommarskog.se/sqlutil/aba_lockinfo.html
It shows procedure or trigger and current statement.
I think you can do execute sp_who2 to get the list of connections, but then you'll need to run a trace through SQL Profiler on the specific connection to see what it's executing. I don't think that works with queries that are already running though.
DBCC INPUTBUFFER will show you the first 255 characters of input on a spid (you can use sp_who2 to determine the spids you're interested in). To see the whole command, you can use ::fn_get_sql().
You can use SQL Profiler to find that out.
EDIT:
If you can stop the app you are running, you can start SQL Profiler, run the app and look at what's running including stored procedures.
Using Enterprise Manager, you can open the Management tree section, and choose Current Activity -> Process Info. Double clicking on a Process ID will show you what that process is running. If it's a stored procedure, it will not show you the parameters. For that it would be better to use Brian Kim's suggestion of using the SQL Profiler.
I am trying to optimize some stored procedures on a SQL Server 2000 database and when I try to use SQL Profiler I get an error message "In order to run a trace against SQL Server you have to be a member of sysadmin fixed server role.". It seems that only members of the sysadmin role can run traces on the server (something that was fixed in SQL Server 2005) and there is no way in hell that I will be granted that server role (company policies)
What I'm doing now is inserting the current time minus the time the procedure started at various stages of the code but I find this very tedious
I was also thinking of replicating the database to a local installation of SQL Server but the stored procedure is using data from many different databases that i will spend a lot of time copying data locally
So I was wondering if there is some other way of profiling SQL code? (Third party tools, different practices, something else )
Your hands are kind of tied without profiler.
You can, however, start with tuning your existing queries using Query Analyzer or
any query tool and examining the execution plans. With QA, you can use
the Show Execution Plan option. From other tools you can use the
SET STATISTICS PROFILE ON / OFF
In query analyser:
SET STATISTICS TIME ON
SET STATISTICS IO ON
Run query and look in the messages tab.
It occurs to me this may require same privileges, but worth a try.
There is a workaround on SQL 2000 to obfuscate the Profiler connection dialogue box to limit the sysadmin connection to running traces only.
SQLTeam
Blog