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.
Related
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.
I am facing some issues with my stored procedures.
I am having 1 stored procedure for a Stack Bar graph, showing one months data.
Earlier on my local server it was taking more than 40 seconds, so I made some changes and now it takes 4 seconds. The same query when I run on my live server takes more than 40 seconds.
The count of the records are the same as in my local server.
Can anybody tell me what I should do to make it more fast on my live server?
A good start is to run SQL Server Management Studio (SSMS), load up the query, and switch on 'Display Actual Execution Plan', this will show you exactly what SQL is doing with your query. It will also show you a relative '%cost' in relation to the steps in the query. This helps to identify which table/join/aggregate whatever is causing the query to take so long.
I also believe that in the latest version of SSMS it advises which indexes should be added.
Hope this helps.
Rich.
It's complicated question . It's a lot of parameters
Can change time of execution
CPU speed,
Ram,
Indexes
Assuming server will be more powerful in terms of processing power and RAM, indexes is something you would like to look into.
use indexes with your mysql tables and also it may be because of your hosting server's performance. The server may be faced with down time.
I've got two database servers. One is SQL 2000, the other 2008 R2.
The application I'm writing sits mainly on the 2008 server (and thats where all the "writing" takes place)... however it does do quite a bit of looking up on the SQL 2000 instance.
The results are just too slow when joing between the linked servers are just too slow.
The SQL 2000 DB will actually be migrated in a cpl of months... but for now I need to find a better option.
Anyone got any suggestions as to the most efficient way to replicate the tables I need.
I was thinking along the lines of the folowing options:
(a) backup and restore each night
(b) full replication from 2000 - 2008... but will I be able to use the database which is being replicated to?
(c) a sql job which refreshes the tables I need every nn hours
I'm guessing plenty have come across this issue so a little pointer would be greatly appreciated.
Thanks in advance,
Jim
I'd take a look at setting up transactional replication. I've used that technique in the past for exactly the scenario you're describing.
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.
I have a database on ms sql 2000 that is being hit by hundreds of users at a time. There are intense reports using reporting services 2005 hitting the same database.
When there are lots of reports running and people using the database concurrently we see blocking processes to the level that the system starts to give time out to any transaction made after some time in that situation.
Is there a global way of minimize blocking so the transaction can continue to flow.
Use optimistic locking, if updates are not happening often and the database is mainly used for reporting.
SQL Server has quite a pessimistic locking default.
A look into SQL Server Table Hints might get you started.
The reports can use WITH(NOLOCK).
Other possibilities are having the reports run off a read-only replica of the database or running off a datawarehouse version of the database which is optimized for the reporting needs.
Since you are already using NOLOCK hints and READ UNCOMMITTED isolation level for your reports, the investigation needs to turn to the transactional queries coming in. This may get deep. Perhaps applications are keeping transactions open too long. It may also be the case that you have a lot of table scans or range scans in some of the other query volume, and those may be holding shared locks for long-running transactions. Those shared locks will block your writers.
You need to start looking at sp_lock, and seeing what kinds of locks are outstanding, see what locks the blocked queries are trying to obtain, and then examine the queries that are blocking the requestors.
This will help you if you are unfamiliar with SQL Server locking:
Understanding SQL Server 2000 Locking
Also, perhaps you could describe your disk subsystem. It may be undersized.
Thanks everyone for your support. What we do to mitigate the problem was to create a new database whit a logshipping procedure every hour to mantain in sync to the real one. The reports that do no need real time data where point to that database and the ones that needs real time data where restricted so only a few people can access them. The drawbacks whit the method is tha the data will be up to one hour out of sync and we need to create a new server for that purpose only. Also when the loggshipping procedure runs every connetion is drop for a very short period of time but it can be a problem to really long procedures or reports. After this I will verify the querys from the reports so I can understand what can be optimize. Thanks and I will recomend the site to the whole IT department.