none
Receiving a fatal error 3624 @pageref.cpp:913 inserting into an empty table

    Question

  • Hi guys,

    I'm using Integration Services to insert rows into a SQL Server 2008 table, and I'm receiving an error - only when the table is empty before the insert.  I use SSIS quite frequently, and this is the first time I've seen this kind of issue.  Since I'm getting some internal errors that seem related to the engine in the reports, I figured I'd post here for ideas.

    Here's the dump from the Agent job that runs the package:

    Executed as user: CORP\_DWAdmin_Service. Microsoft (R) SQL Server Execute Package Utility  Version 10.0.2531.0 for 64-bit  Copyright (C) Microsoft Corp 1984-2005. All rights reserved.    Started:  8:38:29 PM  Error: 2010-10-11 20:39:14.14     Code: 0xC0202009     Source: Insert New Records DIM_CUSTOMER [6]     Description: SSIS Error Code DTS_E_OLEDBERROR.  An OLE DB error has occurred. Error code: 0x80004005.  An OLE DB record is available.  Source: "Microsoft SQL Server Native Client 10.0"  Hresult: 0x80004005  Description: "Warning: Fatal error 3624 occurred at Oct 11 2010  8:39PM. Note the error and time, and contact your system administrator.".  An OLE DB record is available.  Source: "Microsoft SQL Server Native Client 10.0"  Hresult: 0x80004005  Description: "Location:  pageref.cpp:913  Expression:  IS_OFF (BUF_MINLOGGED, m_buf->bstat) || pageModifyType != PageModifyType_Contents || GetPagePtr ()->IsTextPage ()  SPID:   105  Process ID:  1948".  End Error

    Thanks in advance for ideas.  Again - if I insert a single record with SSMS as opposed to SSIS, then the IS package will work just fine...

    What other logs/info can I look at to see what this might really mean?

    (SQL version: Microsoft SQL Server 2008 (SP1) - 10.0.2531.0 (X64)   Mar 29 2009 10:11:52   Copyright (c) 1988-2008 Microsoft Corporation  Standard Edition (64-bit) on Windows NT 6.0 <X64> (Build 6002: Service Pack 2) )

    (What follows is additional information that mrdenny prompted me for on Twitter's #sqlhelp.)

    Here's a (uninformative to me) dump from the SQL Server logs.

    Just ran DBCC CHECKDB with no options and it reported no issues.


    Todd McDermid's Blog Talk to me now on
    Tuesday, October 12, 2010 3:28 PM

All replies

  • Tony - not sure why you think either of those bug fixes will help.

    Todd - looks to be another way that http://support.microsoft.com/kb/968740 can occur. You're on vanilla SP1 and this bug was fixed in CU3. Google is your friend.


    Managing Director, SQLskills.com (http://www.sqlskills.com/blogs/paul), SQL MVP, Microsoft Regional Director, Contributing Editor of TechNet and SQL Server Magazines, Author of 2005 DBCC CHECKDB/repair, Course author/instructor of Microsoft Certified Master - Database.
    Tuesday, October 12, 2010 7:06 PM
    Moderator
  • Sorry - I BINGed.  Should I not do that again? ;)

    But even so, I'm not (intentionally, at least) compressing anything, nor am I (intentionally) requesting an index rebuild.  Not knowing what's going on internally, I could accept that the engine is performing a rebuild before or on the first insert to the table... but I don't know why it would try to compress pages if I didn't turn that on.  If I issue a:

    SELECT * 
    FROM sys.dm_db_index_operational_stats(NULL, NULL, NULL, NULL) 
    WHERE page_compression_attempt_count > 0
    
    

    I get no records returned...

    If I run into the problem again with the other table, I'll apply SP2... even though neither CU3 or SP2 mentions that KB directly or indirectly AFAICT...


    Todd McDermid's Blog Talk to me now on
    Tuesday, October 12, 2010 7:35 PM
  • Tony - not sure why you think either of those bug fixes will help.

    Todd - looks to be another way that http://support.microsoft.com/kb/968740 can occur. You're on vanilla SP1 and this bug was fixed in CU3. Google is your friend.


    Managing Director, SQLskills.com (http://www.sqlskills.com/blogs/paul), SQL MVP, Microsoft Regional Director, Contributing Editor of TechNet and SQL Server Magazines, Author of 2005 DBCC CHECKDB/repair, Course author/instructor of Microsoft Certified Master - Database.

    These are what came up when I googled the error number...
    Please click "Mark As Answer" if my post helped. Tony C.
    Wednesday, October 13, 2010 4:26 PM
  • Looks like you are getting is an assertion ......could you please check the errorlog file and also check if any MDMP file is being generated in the same folder where errorlog is located ....
    Abhay Chaudhary OCP 9i, MCTS/MCITP (SQL Server 2005, 2008, 2005 BI) ms-abhay.blogspot.com/
    Wednesday, October 13, 2010 5:16 PM
  • Hi Todd,

     

    I have noticed that error message has mentioned error 3624. I have executed “SELECT * FROM sys.messages WHERE message_id=3624” in SQL Server Management Studio and get the following result:

    A system assertion check has failed. Check the SQL Server error log for details. Typically, an assertion failure is caused by a software bug or data corruption. To check for database corruption, consider running DBCC CHECKDB. If you agreed to send dumps to Microsoft during setup, a mini dump will be sent to Microsoft. An update might be available from Microsoft in the latest Service Pack or in a QFE from Technical Support.

    As said above, this issue might be caused by a software bug or data corruption. Therefore I would like to recommend that you execute DBCC CHECKDB to check if the database is corrupt.

     

    If anything is unclear, please let me know.


    Regards,
    Tom Li
    Thursday, October 14, 2010 8:50 AM
    Moderator
  • Hi,

    I also have the same error with an empty table.

    When running an SSIS package, it fails after inserting 10500 rows with the same message.

    If I remove the transaction handling of the package, it runs fine.

    I can also input a dummy row to the destination table before running the package with transaction handling on, and it runs fine..

     

    Seems like a bug to me?!

     

    Regards,

    Jon

    Tuesday, January 18, 2011 3:15 PM
  • Sorry for leaving this thread dormant for so long - but I'm finally back to reloading my data warehouse from scratch, and I'm getting this error again.

    Running DBCC CHECKDB results in no errors detected - I can post the entire resultset if that would help, just let me know.

    I do have the stack dump as well - will providing that help?  (Oh, I see I already posted it in my OP.)

    Similar to Five-O, I am using MS DTC within SSIS to manage transactions on the insert...

    I'm going to try an update to SP2, and post results.


    Todd McDermid's Blog Talk to me now on
    Thursday, April 14, 2011 3:19 AM