September 15, 2004 at 2:34 pm
Hello Everyone!
It seems that we can no longer create indices reliably on many of our larger tables (for example, 14M rows, 18857816 KB data size, 4768136 KB index size). We intermittently receive various errors when attempting to create simple indices:
SQL Server Assertion: File: <recbase.cpp>, line=1378
Failed Assertion = 'm_offBeginVar < m_SizeRec'.
and
SQL Server Assertion: File: <p:\sql\ntdbms\storeng\drs\include\record.inl>, line=1447
Failed Assertion = 'm_SizeRec > 0 && m_SizeRec <= MAXDATAROW'.
both occurred today while attempting to recreate some indices. Before any indices were attempted to be created, a DBCC check reported the table was healthy. After each failure, the table was healthy. These are straighforward CREATE INDEX <idxName> ON <tblName> ( <colName> ) ON '<FILEGROUP>' commands, no WITH SORT IN TEMPDB, etc. We have plenty of disk space and the files are set to autogrow when needed.
Each of these commands, when they fail, if we run them again, they succeed. Because of this, we suspect some flaky memory thing, but who knows?!
Any ideas on what could be going on? We are beginning to lose confidence in SQL Server.
Thanks ahead of time for any assist.
Allen
HP NetServer LH4, quad PIII Zeon 550s, 3GB RAM, 2GB (fixed) allocated to SQL Server, SQL Server 2000 SP3, Windows Server 2003 Standard, 2048KB minimum query memory
September 15, 2004 at 3:27 pm
Allen,
I've not run into those assertions, and although somebody else may ring in with some experience specific to the problems you are seeing, I would encourage you to file a support request with PSS. Assertion failures always smell like bugs to me, and support for fixing a bug is always free.
Good luck,
Chris
September 16, 2004 at 3:06 am
I would echo Chris's advice. You should contact PSS regardless of anything else you do.
It may also be worth looking at your autogrow parameters. Try to work out the likely space increment that would be needed during your index rebuilds. The autogrow parameters should be set to allow the additional space to be grabbed in a single attempt.
If SQL works out, say, it needs 50MB more space to complete an atomic operation and autogrow is set to 10MB, SQL will normally return a misleading 'disk full' message. This is because autogrow processing is only invoked once per growth request, and if not enough space is obtained SQL gives the 'disk full' message instead of retrying.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
September 16, 2004 at 6:30 am
You wouldn't happen to have a bit field in the index, would you? We encountered a bug in this scenario in an app ported from FoxPro. The bug has been fixed since. The latest SP will rectify the problem if this is the case...
HTH
September 16, 2004 at 6:36 am
No bit columns present in the table. Indices are all non-compound, built on basic datatype columns; i.e. INT, CHAR(1) and a couple of VARCHARs.
Anyone had experience contacting PSS and requesting support? How long to resloution? This is a production box and we have grinded to a halt right now.
Thanks!
Allen
September 16, 2004 at 7:03 am
To get PSS support, phone your local Microsoft office. If that is not the right number they will give it to you. When you get to PSS, you will either need an established support agreement number you can quote, or a credit card number that can be charged (we use a CC). You will also need to know the build level of your OS and of SQL.
It normally takes 2 to 4 hours after the initial call before a product specialist will contact you. Often they will want you to e-mail them SQL dumps, so it is good to have these available at where you e-mail from. Depending on the nature of the problem, the product specialist may get back to you within an hour with a possible fix, or you may need to wait overnight.
If the fix is downloadable from the public website, you will normally be charged for the support call. If it is not publicly available, the call is normally free and any charges already taken from your CC will be refunded. (This is my understanding...).
If the problem is new and a fix has to be coded, the call is definitely free, but you may have to wait a while for the fix.
You may contact the product specialist as many times as needed about the same problem without any additional charge being made. The few times I have had to contact PSS, I have found them to be very helpful and quick to respond.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
September 16, 2004 at 8:08 am
If it's a production server, that's all the more reason to take it to PSS. And when opening the incident, make sure that they know you have a Level 1, production-outage, "911," "Red Alert," "Defcon 5" kind of problem (or whatever you would call it). Although there's no guarantee that PSS can fix your problem right away, a lot of these people are really good.
Also, if the first analyst you speak with doesn't demonstrate that they can understand your problem within a fairly short amount of time, it's also OK (again, especially with a production server) to request that the case be escalated to the next tier. By "first analyst," I am not referring to the first person you talk to if you phone in the incident - that person is more of a clerk than an analyst. I mean the first person who is trying to help resolve the problem, not just collect information about it. Give that person a chance because they may be able to help you, but the people in the deeper tiers are usually outstanding.
If you are not sure how to contact them, there is a link for PSS (labeled Microsoft Professional Support) at http://www.microsoft.com/sql/support/default.asp.
Cheers,
Chris
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply