none
SQL2000 (loshipping fail due to I/O error (torn page) detected during read at offset 0x0000000017e000 in mdf file) RRS feed

  • Question

  • Dear all,

    In our enviroment we have configured logshipping in SQL2000 everything is working file from past 3 years but suddenly today I have check logshipping failed due to below error:-

    ============
    Processed 767 pages for database 'DB_Name', file 'DB_Name_log' on file 1.
    Server: Msg 823, Level 24, State 2, Line 1
    I/O error (torn page) detected during read at offset 0x0000000017e000 in file 'DB_Name.mdf'.

    Connection Broken
    =============

    I have cross check last log file is readable & having full control for sql service account.
    I have also tried with manually restore but still getting same error.
    Service is running.

    please help us this is production..

    reagrds
    ravi


    india
    Tuesday, December 29, 2009 2:00 PM

Answers

  • The KB Article mentioned above has the answer to your question.

    I'm not sure if any other database has consistency issues. It would definitely be a good idea to run Checkdb on all the databases (user and system) on the secondary server to ensure that there are no inconsistencies reported on any other database.
    This posting is provided "AS IS" with no warranties, and confers no rights. My Blog: Troubleshooting SQL
    • Marked as answer by MSSQL DBA Wednesday, December 30, 2009 12:38 PM
    Tuesday, December 29, 2009 3:24 PM

All replies

  • The 823 errors is being reported on the data file and not on the log file. Above message indicates an issue with DB_Name.mdf. 823 error indicates a hardware related issue. I suggest you run a checkdb on the database if this is the primary database. Also, check the windows event logs for system related errors and perform a disk diagnostics check with your hardware vendor. Based on the output of the checkdb, you would be able to proceed further as it will indicate the level of corruption in the database.

    Explanation about 823 message:
    http://support.microsoft.com/kb/828339


    This posting is provided "AS IS" with no warranties, and confers no rights. My Blog: Troubleshooting SQL
    Tuesday, December 29, 2009 2:38 PM
  • Amit,

    this is secondry Db with loading mode..
    all log files available in secondry server...
    sholud I try with full log backup ??
    india
    Tuesday, December 29, 2009 2:49 PM
  • If I understand correctly, your secondary database is not in Read-Only (Standby mode). I would suggest doing the other checks which I mentioned. You would have to break log shipping at this point and reconfigure it. Since the database MDF file has inconsistencies, this secondary database is not a consistent copy of the primary.

    However since this is a secondary database, you can always take a full backup from the primary server and resetup log shipping. Do keep in mind that 823 errors, more often than not, point to a system/hardware level issue which shouldn't be aware. While you are re-setting up your log shipping up, I would suggest getting your server team or vendors involved to perform the necessary health checks on the sever.
    This posting is provided "AS IS" with no warranties, and confers no rights. My Blog: Troubleshooting SQL
    Tuesday, December 29, 2009 2:54 PM
  • thanks for your help..........

    amit can you suggest me what kind of problem will be there @ windows level??

    can we try dbcc checkdb in different Db(in secondry server) having the same location data & log file?

    reagrds


    india
    Tuesday, December 29, 2009 2:59 PM
  • The KB Article mentioned above has the answer to your question.

    I'm not sure if any other database has consistency issues. It would definitely be a good idea to run Checkdb on all the databases (user and system) on the secondary server to ensure that there are no inconsistencies reported on any other database.
    This posting is provided "AS IS" with no warranties, and confers no rights. My Blog: Troubleshooting SQL
    • Marked as answer by MSSQL DBA Wednesday, December 30, 2009 12:38 PM
    Tuesday, December 29, 2009 3:24 PM