October 30, 2009 at 11:02 am
Hi,
We have SQL Server 2005 Developer edition x86 with SP3. We have 4 GB Memory and Max memory is set to 3.5 GB.
I'm getting IO requests taking longer time for MSDB database. I did not understand why MSDB database only having this problem. What are the items I need to look for?
009-10-28 23:23:50.19 Server Using 'dbghelp.dll' version '4.0.5'
2009-10-28 23:24:20.75 Server ***Unable to get thread context - no pss
2009-10-28 23:24:20.75 Server * *******************************************************************************
2009-10-28 23:24:20.75 Server *
2009-10-28 23:24:20.75 Server * BEGIN STACK DUMP:
2009-10-28 23:24:20.75 Server * 10/28/09 23:24:20 spid 0
2009-10-28 23:24:20.75 Server *
2009-10-28 23:24:20.75 Server * Non-yielding Scheduler
2009-10-28 23:24:20.75 Server *
2009-10-28 23:24:20.75 Server * *******************************************************************************
2009-10-28 23:24:32.00 Server Stack Signature for the dump is 0x000001CE
2009-10-28 23:26:33.13 Server External dump process return code 0x20000001.
External dump process returned no errors.
2009-10-28 23:26:33.14 Server Process 2:0:0 (0x71c) Worker 0x0084E0E8 appears to be non-yielding on Scheduler 0. Thread creation time: 12900888855375. Approx Thread CPU Used: kernel 0 ms, user 0 ms. Process Utilization 0%. System Idle 93%. Interval: 70002 ms.
2009-10-28 23:35:53.25 Server Process 57:0:0 (0xcd4) Worker 0x2429C0E8 appears to be non-yielding on Scheduler 1. Thread creation time: 12901271030243. Approx Thread CPU Used: kernel 0 ms, user 0 ms. Process Utilization 0%. System Idle 94%. Interval: 70002 ms.
2009-10-28 23:36:38.25 Server Process 75:0:0 (0xc44) Worker 0x4CFDA0E8 appears to be non-yielding on Scheduler 0. Thread creation time: 12901271185044. Approx Thread CPU Used: kernel 0 ms, user 0 ms. Process Utilization 0%. System Idle 93%. Interval: 70002 ms.
2009-10-28 23:36:53.25 Server Process 57:0:0 (0xcd4) Worker 0x2429C0E8 appears to be non-yielding on Scheduler 1. Thread creation time: 12901271030243. Approx Thread CPU Used: kernel 0 ms, user 0 ms. Process Utilization 0%. System Idle 93%. Interval: 130004 ms.
2009-10-28 23:37:38.26 Server Process 75:0:0 (0xc44) Worker 0x4CFDA0E8 appears to be non-yielding on Scheduler 0. Thread creation time: 12901271185044. Approx Thread CPU Used: kernel 0 ms, user 0 ms. Process Utilization 0%. System Idle 93%. Interval: 130019 ms.
2009-10-28 23:37:53.26 Server Process 57:0:0 (0xcd4) Worker 0x2429C0E8 appears to be non-yielding on Scheduler 1. Thread creation time: 12901271030243. Approx Thread CPU Used: kernel 0 ms, user 0 ms. Process Utilization 0%. System Idle 93%. Interval: 190021 ms.
2009-10-28 23:43:43.46 Server Process 0:0:0 (0x720) Worker 0x009EC0E8 appears to be non-yielding on Scheduler 1. Thread creation time: 12900888855375. Approx Thread CPU Used: kernel 0 ms, user 0 ms. Process Utilization 0%. System Idle 92%. Interval: 70017 ms.
2009-10-28 23:44:43.47 Server Process 0:0:0 (0x720) Worker 0x009EC0E8 appears to be non-yielding on Scheduler 1. Thread creation time: 12900888855375. Approx Thread CPU Used: kernel 0 ms, user 0 ms. Process Utilization 0%. System Idle 93%. Interval: 130019 ms.
2009-10-28 23:45:43.47 Server Process 0:0:0 (0x720) Worker 0x009EC0E8 appears to be non-yielding on Scheduler 1. Thread creation time: 12900888855375. Approx Thread CPU Used: kernel 0 ms, user 0 ms. Process Utilization 0%. System Idle 94%. Interval: 190021 ms.
2009-10-28 23:52:23.03 spid3s SQL Server has encountered 1 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [d:\Program Files\Microsoft SQL Server\MSSQL\data\msdblog.ldf] in database [msdb] (4). The OS file handle is 0x00000810. The offset of the latest long I/O is: 0x00000000905000
2009-10-29 00:00:07.89 spid21s This instance of SQL Server has been using a process ID of 1720 since 10/24/2009 1:14:26 PM (local) 10/24/2009 8:14:26 PM (UTC). This is an informational message only; no user action is required.
2009-10-29 00:04:43.40 spid3s SQL Server has encountered 1 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [d:\Program Files\Microsoft SQL Server\MSSQL\data\msdblog.ldf] in database [msdb] (4). The OS file handle is 0x00000810. The offset of the latest long I/O is: 0x0000000090c000
2009-10-29 00:18:21.85 spid3s SQL Server has encountered 1 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [d:\Program Files\Microsoft SQL Server\MSSQL\data\msdblog.ldf] in database [msdb] (4). The OS file handle is 0x00000810. The offset of the latest long I/O is: 0x00000000912c00
Thanks
November 1, 2009 at 2:34 am
could you plz give me some inputs..
many thanks
November 1, 2009 at 10:08 am
I would make sure you run a DBCC checkdb in msdb.
November 1, 2009 at 11:06 pm
Steve,
I have ran the below query in my Server and I did not get any errors
dbcc checkdb (msdb) with no_infomsgs
Results: Command(s) completed successfully.
November 2, 2009 at 3:19 am
You have the times in the log, I would check to see what jobs are running at thart time. I would also check to see what else you have running, such as message queues, service broker. any type of auditing. Have a look at the tables in msdb, is there any that are big. also is the msdb database/log bigger than normal.
--------------------------------------------------------------------------------------
[highlight]Recommended Articles on How to help us help you and[/highlight]
[highlight]solve commonly asked questions[/highlight]
Forum Etiquette: How to post data/code on a forum to get the best help by Jeff Moden[/url]
Managing Transaction Logs by Gail Shaw[/url]
How to post Performance problems by Gail Shaw[/url]
Help, my database is corrupt. Now what? by Gail Shaw[/url]
November 2, 2009 at 11:42 am
I have encountered the I/Os taking longer than 15 seconds problem. If it is like our problem this is not a SQL Server issue. It has something to do with the disks, or the pieces and parts that go to it. It is almost impossbile to track down. We had three different SANS... our server in question was on a very, very old one and was out of support, we migrated it to the next oldest one and these problems showed up. After weeks of debugging we finally just migrated to the brand new SAN and the problem went away.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply