a52988de   
   XPost: microsoft.public.sqlserver.server   
   From: sqlmvpnooospam@shadhawk.com   
      
   Have you checked the SQL Agent for any scheduled jobs that may kick off at   
   10:00PM?  What about on the windows scheduler? There is obviously something   
   happening on the server at that time and we can tell you what that is but we   
   can tell u that it is not SQL Server doing anything on it's own.   
      
   --   
      
   Andrew J. Kelly   SQL MVP   
   Solid Quality Mentors   
      
   "tom12010"  wrote in message   
   news:78ebb92b-0f52-4168-a54a-b30ae272e18c@c10g2000yqi.googlegroups.com...   
   > Every night at about 10 pm (2000 hours) on our SQL 2005 since about   
   > 7/21 or so we have got this recurring error in our SQL server logs:   
   >   
   > 07/22/2010 22:00:34,spid2s,Unknown,SQL Server has encountered 1   
   > occurrence(s) of I/O requests taking longer than 15 seconds to   
   > complete on file [D:\LOGS\UNI_MMMMM_Log.ldf] in database [UNI_MMMMM]   
   > (5).  The OS file handle is 0x000006C8.  The offset of the latest long   
   > I/O is: 0x0000001752dc00   
   >   
   > The OS file handle is always the same, the offset is always different.   
   > The spid number is always the same.   
   >   
   > This SQL server is the backend for our timekeeping software, and this   
   > event is coincidental with the timekeeping software having nightly   
   > issues at 10 pm.   
   >   
   > My research shows this can happen on physical SQL servers with many   
   > disk writes or disk contention, or with insufficient log file space.   
   >   
   > Neither of these conditions apply -- the SQL server is a virtual   
   > server on a LUN with very light activity at 1000 pm, the log file   
   > allocation is 2 GB for a 500+ MB database. We did not create the log   
   > file allocation, a consultant did this without telling us that the log   
   > file allocation would be a fixed size, and I have not figured out how   
   > to change the log file. I checked the log file allocation and it   
   > certainly does not appear filled up.   
   >   
   > The only event of note since this started is that MS Updates were   
   > performed on the server on 7/19/10 and this issue began on 7/21 after   
   > the VM was migrated to ESX 4.1, which should not have caused any   
   > issues since ESX isn't a database etc.   
   >   
   > Any suggestions, ideas, etc. will be very welcome.   
   >   
   > Thank you, Tom   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)