Error during Reindex step of a Maintenance plan

Question

Post reply

Error during Reindex step of a Maintenance plan

Tom Nollan

Newbie

Points: 3
More actions
December 20, 2004 at 9:47 am

#87601

We are receiving an Error:
2004-12-18 20:37:31.47 spid57    Error: 823, Severity: 24, State: 2
2004-12-18 20:37:31.47 spid57    I/O error 1450(Insufficient system resources exist to complete the requested service.) detected during read at offset 0x000019a4fe0000 in file 'J:\mssql\jde_PRODUCTIONdata.mdf'..
While doing the Reindex step of our maintenance plan. We run the DBCC CHECKDB statement and it does not come up with any problems.
2004-12-18 16:42:32.06 spid57    DBCC CHECKDB (JDE_PRODUCTION) executed by OFFICE\sqladmin found 0 errors and repaired 0 errors.
The reindex runs for a little over three hours then errors out. Any ideas on how to get the Reindex to run successfully or how to figure out what is causing this error?
The database is around 200 GB in size.
SQL Server 2000 Sp3 w/Hotifxes running on Windows Advanced Server W/6 cpu and 5 GB of RAM

Viewing 6 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic. Login to reply

Snail Newbie Points: 1 More actions · Answer 1

Every time we reindex our database without a previous log backup, if the log file is almost full, we get this error.

Tom Nollan Newbie Points: 3 More actions · Answer 2

We actually switch our database to Simple mode before performing this step so we don't create a large log file. One of our tables is around 50 GB in size and grows by about .5 GB a week. We also have an alert to backup the log file if it gets more than 80% full and it is not firing. Any other ideas?

bbdpres SSCommitted Points: 1876 More actions · Answer 3

Don't you still have to backup the log with TRUNCATE_ONLY after switching? Easiest test would be through DBCC SQLPERF(LOGSPACE).

Tom Nollan Newbie Points: 3 More actions · Answer 4

We have never backed up our log first. This plan has run for over a year with no problems.

bbdpres SSCommitted Points: 1876 More actions · Answer 5

Based on what you can find in the Knowledge Base, I'd be led to believe that you might have a disk subsystem that's failing on heavy utilization. That or it's just masked by some other system strain. Have you looked through the event log on the server during those timeframes? How about scheduling perfmon and watch for high utilization (disk queuing, CPU, processor queues, memory/paging, etc.)?