Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

ERROR 823: I/0 error (torn page) detected during read at the offset 0x00000000182e000 in file D:\program files\microsoft\SQL server\MSSQL\data\msdbdata.mdf Expand / Collapse
Author
Message
Posted Wednesday, October 3, 2007 3:01 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Saturday, October 6, 2007 9:41 AM
Points: 1, Visits: 5
In our server suddenly we are getting this problem and we couldnt solve this

ERROR 823: I/0 error (torn page) detected during read at the offset 0x00000000182e000 in file D:\program files\microsoft\SQL server\MSSQL\data\msdbdata.mdf


thanks in advance

cheers

v.kanagaraj kumar
Post #406081
Posted Wednesday, October 3, 2007 11:43 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Yesterday @ 5:00 PM
Points: 1,388, Visits: 6,268
Do you have a backup of msdb?
There was an I/O error in the past that caused the torn page

Torn_page_detection:
This recovery option allows SQL Server to detect incomplete I/O operations caused by power failures or other system outages.

When set to ON, this option causes a bit to be reversed for each 512-byte sector in an 8-kilobyte (KB) database page when the page is written to disk. If a bit is in the wrong state when the page is later read by SQL Server, the page was written incorrectly; a torn page is detected. Torn pages are usually detected during recovery because any page that was written incorrectly is likely to be read by recovery.

Although SQL Server database pages are 8 KB, disks perform I/O operations using a 512-byte sector. Therefore, 16 sectors are written per database page. A torn page can occur if the system fails (for example, due to power failure) between the time the operating system writes the first 512-byte sector to disk and the completion of the 8-KB I/O operation. If the first sector of a database page is successfully written before the failure, the database page on disk will appear as updated, although it may not have succeeded.

Note Using battery-backed disk caches can ensure that data is successfully written to disk or not written at all.

If a torn page is detected, an I/O error is raised and the connection is killed. If the torn page is detected during recovery, the database is also marked suspect. The database backup should be restored, and any transaction log backups applied, because it is physically inconsistent.

By default, TORN_PAGE_DETECTION is ON.
Post #406343
Posted Thursday, October 4, 2007 3:11 AM
SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 2:48 PM
Points: 5,976, Visits: 12,887
AN 823 error suggests a H\W error, so make sure your server guys check the disk out....

---------------------------------------------------------------------

Post #406656
Posted Saturday, October 6, 2007 9:34 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Tuesday, June 16, 2009 7:15 AM
Points: 16, Visits: 104
Thats right , this is generally due to a hardware error.I would suggest that you run dbcc checkdb to see if the database msdb has errors and correcting it along with check with the hardware guys
Post #407697
Posted Tuesday, April 30, 2013 10:36 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Monday, December 16, 2013 1:13 AM
Points: 24, Visits: 74
Hi,
Pls i'm having the same torn page error and i can't seem to solve it. I don't have a backup of my msdb database. This is what i have tried so far as suggested by other people.

I have ran sqlservr -c -T 3608, moved/renamed the msdbdata.mdf and msdblog.ldf files, run instmsdb to recreate the msdb database. and restarted the server without trace 3608.

So ple help, this didn't work...
Post #1448138
Posted Tuesday, April 30, 2013 12:09 PM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 1:36 AM
Points: 42,488, Visits: 35,556
Please post new questions in a new thread and include the full output of
DBCC CHECKDB (<Database Name>) WITH NO_INFOMSGS, ALL_ERRORMSGS




Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #1448184
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse