I have written a procedure that runs a bunch of select into statements from remote linked servers.
These servers have been known to simply hang and not respond for some reason, however my insert into statement will continue endlessly.
Is there a way in SQL server I can monitor the destination table to see if data is going in? I am not using transactions. When I try to select from the destination table, it must be locked because it is basically sitting there waiting. I changed my isolation level to READ UNCOMMITTED and can get a select on the table, but the count isn't moving, so I am assuming the data goes in batches?
I am running a tcpdump on the remote server and can see the packets flowing through, just hoping there is an easier way to see it through MSSQL somewhere.
Any advise appreciated!
SQL profiler is your friend.
open SSMS and goto Tools -> SQL Server Profiler. Then setup the criteria, and there are ALOT OF THEM. I always start big and whittle it down.
Some advise, make sure you know what the account is that is being used to execute the statement. As well, only run it for no more than 10-20 mins, cause these Profiler files can eat up 100GB/session in minutes. While looking for the statement, only start it before you execute the statement and stop it after you get the result and then find your statement information and then refine the Profiler for what you need.
Related
How to run the same query multiple times in SQL Server?
Simple example, I have a query
select * from sys.databases
I wanted to run it N times, because I wanted to return the data in a dashboard in "real time", until I stopped the execution, the select would need to continue running "example: as SQL Server Profiler does, while I don't stop, it keeps bringing the information in the screen".
What would be the best way for this type of situation?
Remembering that the query and SQL Server profiler are just examples.
create a job and insert your query to run, and under the schedule set the timings to execute your query.
Because your dashboard code must poll the dbms every so often to get the latest data, you must decide how often as part of your system design.
Once a minute? That is very often to poll the data. But only you can decide how out-of-date your dashboard users will tolerate.
Whatever you do, avoid promising "real time" if you possibly can. We programmers can't deliver on that promise with polling the database.
My boss and I have been trying to see what sort of auditing plan we could try for our stored procedures. Currently there're two external applications taking information from our database through stored procedures and we're interested in auditing when they're being executed, and what values are passed as parameters. So far what I've done is simply create a table for the stored procedures one of the apps is using, and as they use the same input parameters, have one column per parameter. Obviously this isn't the best choice, but we wanted to get quick info to see if they were running batch processes and when they were running them. I've tried SQL Server Audit, but it doesn't catch the parameters unless you're executing a SP in a query.
SQL Server Profiler will do this for you; its included for free. Setup a trace and let it run.
You can also apply quite a bit of filtering to the trace, so you don't need to track everything; you can also direct the output to a file, or sql table for later analysis. This is probably your best bet for a time limited audit.
I think I've used the SQL Server Profiler (http://msdn.microsoft.com/en-us/library/ms181091.aspx) in the past to audit SQL execution. It's not something you would run all the time, but you can get a snapshot of what's running and how it's being executed.
I haven't tried using them, but you might look at event notifications and see if they will work for you.
From BOL
Event notifications can be used to do the following:
Log and review changes or activity occurring on the database.
I currently have a SQL Server 2005 set up and has been running successfully for quite a long period of time without any issues.
As of this morning our website applications have been attempting to perform udpates on various rows. However, every time an update happens the data never gets updated in the database.
Our application's code hasn't been changed in any way, and there appears to be no errors of any kind.
Is there anything in SQL Server that can prevent updates from being performed on a database? Can the size of transaction logs prevent data from being updated on a SQL Server database? Or anything at all that can cause this strange behaviour?
We had similar behaviour on one of our servers and it was due to the log file being on a hard drive that had run out of disk space - so worth checking that.
Also check that the Autogrowth limits haven't been reached:
While running the SQL Profiler on a client site I noticed getmyrunningjobs running over and over bogging down their system in the morning from about 5:30 am to 6:30am. I know it runs all the time but for some reason it appears to run 4 times in a row every couple of seconds in the morning. I'm not really sure what it is used for, though I've read a lot on SQL Profiler, I can't find much on SQL Report Server.
Can I stop or change the frequency or is there something else going on that I can check? Also, what is Tablockx, and is this related?
Thanks. Any help appreciated!
To answer your secondary question, TABLOCKX is a SQL Server table hint that applies an exclusive table lock. I'd think this would be related to your problem only if something is holding the lock for an unusually long time during the timeframe you indicated.
I have a database with a rather large number of tables, about 3500, and an application that needs to access a table list.
On a particular server this takes over 2.5 min to return.
EXEC sp_tables #table_type="'TABLE'"
I know there are faster ways to do that but sadly I'm not in a position to modify the application and need to find a way to push it below 30 seconds so the application doesn't throw timeout errors.
So. What, if anything, can I do to improve the performance of this sp within sql server?
I have seen these stored procedures run slow if you do not have the GRANT VIEW DEFINITION permission set on your user account. From what I read, this will cause a security check to occur slowing down the query.
Maybe a SQL guru can comment on why, if this does help your problem.
Well, sp_tables is system code and can't be changed (could workaround in SQL Server 2000, not SQL Server 2005+)
Your options are
Change the SQL
Change command timeout
Bigger server
You've already said "no" to the obvious solutions...
You need to approach this just like any other performance problem. Why is it slow? Namely, where does it block? Disk IO? CPU? Network? Lock contention? The scientific method is to use a methodology like Waits and Queues, or its newer SQL 2008 equivalent Troubleshooting Performance Problems in SQL Server 2008. The lazy way is to simply check the wait_type, wait_time and wait_resource columns in sys.dm_exec_requests for the session executing the sp_tables call. Once you find out what is blocking the execution, you can proceed accordingly.
If I'd venture a guess, you'll discover contention as the cause: other sessions are locking table's metadata exclusively and thus block the execution of sp_tables, which has to wait until all operations in front of it finish.