Post reply

Event ID 832

  • August 23, 2009 at 8:36 am

    #213586

    In the past week I see following error, run DBCC and reboot the machine, the error goes away then comes back again. Sometime it shows one or two, sometime it shows a whole page with errors.

    I run memory check on the server (Windows 2003 Std R2 64 bit) but no errors found. The server is a Dell PE1955 blade server.

    Is this a bogus error regarding hardware issue? I find only one hit for event id 832 and MSSQLServer as event source on Google.

    Thanks for your help.

    hdoan

    Event Type:Error

    Event Source:MSSQLSERVER

    Event Category:(2)

    Event ID:832

    Date:8/23/2009

    Time:12:10:24 AM

    User:N/A

    Computer:STPSQL1

    Description:

    A page that should have been constant has changed (expected checksum: 1dcb28a7, actual checksum: 68c626bb, database 13, file 'E:\Program Files\microsoft sql server\MSSQL\data\WSS_Content.mdf', page (1:885961)). This usually indicates a memory failure or other hardware or OS corruption.

    For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

    Data:

    0000: 40 03 00 00 18 00 00 00 @.......

    0008: 08 00 00 00 53 00 54 00 ....S.T.

    0010: 50 00 53 00 51 00 4c 00 P.S.Q.L.

    0018: 31 00 00 00 00 00 00 00 1.......

  • August 23, 2009 at 9:07 am

    #1043361

    When you say it goes away, do you mean you

    - get error in the log

    - run DBCC and there are no errors?

    - reboot

    - get the error again?

    Typically these errors are hardware related and they don't go away. You can deal with some corruption issues (see Paul Randal's blog), but if corrupt data is being written, it could get worse.

    Also, what DBCC command do you run?

  • August 23, 2009 at 9:27 am

    #1043372

    Edit: Removed complete garbage.

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    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

  • August 24, 2009 at 6:28 pm

    #1043952

    Don't confuse this with an I/O error like 823/824. This error says that the page has a page checksum which was valid when the page was read into memory, but when the page was just about to be marked dirty in the buffer pool, it was found to have a bad checksum.

    The page became corrupted in SQL Server's memory by something other than SQL Server. It's either bad memory, an OS bug, or a process outside SQL Server stomping on SQL's memory.

    If you've run memory diagnostics, there's one thing left to do, which you should really do with support from Product Support. There's a trace flag you can turn on to prevent writes to pages in SQL's memory space, but you need to enable it when the instance is started, and it's expensive to have turned on. If that's the route you want to go, you should call Product Support to help you out as that isn't something I'm going to describe on a public forum.

    Thanks

    Paul Randal
    CEO, SQLskills.com: Check out SQLskills online training!
    Blog:www.SQLskills.com/blogs/paul Twitter: @PaulRandal
    SQL MVP, Microsoft RD, Contributing Editor of TechNet Magazine
    Author of DBCC CHECKDB/repair (and other Storage Engine) code of SQL Server 2005

  • August 25, 2009 at 2:53 am

    #1044028

    Paul Randal (8/24/2009)

    This error says that the page has a page checksum which was valid when the page was read into memory, but when the page was just about to be marked dirty in the buffer pool, it was found to have a bad checksum.

    Interesting. Wasn't aware that the checksum was checked any time other than at read.

    Could this be caused by a misbehaving linked server driver or extended proc? I've had before a 3rd party driver scribbling over the thread stacks which caused all sorts of problems.

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    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

  • August 25, 2009 at 2:57 am

    #1044030

    hii this gerybaird and in my view your problem is related to software corporation please update your software.

    Editor's Note: Removed link.

  • August 25, 2009 at 5:08 am

    #1044072

    gery.baird (8/25/2009)

    hii this gerybaird and in my view your problem is related to software corporation please update your software.

    Nonsense.

    Paul Randal
    CEO, SQLskills.com: Check out SQLskills online training!
    Blog:www.SQLskills.com/blogs/paul Twitter: @PaulRandal
    SQL MVP, Microsoft RD, Contributing Editor of TechNet Magazine
    Author of DBCC CHECKDB/repair (and other Storage Engine) code of SQL Server 2005

  • August 25, 2009 at 5:09 am

    #1044073

    @Gail Yup - especially in Enterprise Edition. And yes, anything with write-access to SQL memory can cause this.

    Paul Randal
    CEO, SQLskills.com: Check out SQLskills online training!
    Blog:www.SQLskills.com/blogs/paul Twitter: @PaulRandal
    SQL MVP, Microsoft RD, Contributing Editor of TechNet Magazine
    Author of DBCC CHECKDB/repair (and other Storage Engine) code of SQL Server 2005

  • August 25, 2009 at 6:19 am

    #1044101

    Paul Randal (8/25/2009)

    @Gail Yup - especially in Enterprise Edition. And yes, anything with write-access to SQL memory can cause this.

    Interesting... What, other than in-process drivers and extended stored procs could have a chance of doing this? Unsafe CLR?

    Is there any chance of getting a blog post (or article) on when the checksums are checked and what errors result when they're wrong? I get the impression there's a lot more to them than I thought there was.

    p.s. that post above yours was spam. We're getting it from time to time here, Steve has been notified, he'll probably delete it as soon as he gets the mail

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    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

  • August 25, 2009 at 6:42 am

    #1044114

    Anything with kernel-mode access to the server's memory can corrupt memory wherever it wants.

    Yup - there are a lot to it. Maybe I'll get around to it someday 🙂

    Thanks

    Paul Randal
    CEO, SQLskills.com: Check out SQLskills online training!
    Blog:www.SQLskills.com/blogs/paul Twitter: @PaulRandal
    SQL MVP, Microsoft RD, Contributing Editor of TechNet Magazine
    Author of DBCC CHECKDB/repair (and other Storage Engine) code of SQL Server 2005

  • August 25, 2009 at 8:13 am

    #1044209

    I appeciate that many have responded to this issue. Many thanks to all of you.

    I am not sure this problem had happened before I upgradted the memory from 4 GB to 8 GB or not.

    I removed all old memory modules and intalled new ones in the middle of last month.

    I plan to swap out the memory modules some time this week to prove if the new modules generate the errors.

    hdoan

  • August 25, 2009 at 8:28 am

    #1044220

    Ah - that seems to be the smoking gun - hope that proves to be the issue.

    Paul Randal
    CEO, SQLskills.com: Check out SQLskills online training!
    Blog:www.SQLskills.com/blogs/paul Twitter: @PaulRandal
    SQL MVP, Microsoft RD, Contributing Editor of TechNet Magazine
    Author of DBCC CHECKDB/repair (and other Storage Engine) code of SQL Server 2005

Viewing 12 posts - 1 through 11 (of 11 total)

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