I have a SQL Server 2005 database that could only be restored using
Restore Database The_DB_Name
From Disk = 'C:\etc\etc'
With Continue_After_Error
I am told the source database was fine. The restore reports
Warning: A column nullability
inconsistency was detected in the
metadata of index
"IDX_Comp_CompanyId" (index_id = 2)
on object ID nnnnn in database
"The_DB_Name". The index may be
corrupt. Run DBCC CHECKTABLE to verify
consistency.
DBCC CHECKTABLE (Company)
gives
Msg 8967, Level 16, State 216, Line 1
An internal error occurred in DBCC
that prevented further processing.
Contact Customer Support Services.
Msg 8921, Level 16, State 1, Line 1
Check terminated. A failure was
detected while collecting facts.
Possibly tempdb out of space or a
system table is inconsistent. Check
previous errors.
Alter Index IDX_Comp_CompanyId On dbo.Company
Rebuild
gives me
Msg 824, Level 24, State 2, Line 1
SQL Server detected a logical
consistency-based I/O error: incorrect
pageid (expected 1:77467; actual
45:2097184). It occurred during a read
of page (1:77467) in database ID 20 at
offset 0x00000025d36000 in file
'C:\etc\etc.mdf'. Additional messages
in the SQL Server error log or system
event log may provide more detail.
This is a severe error condition that
threatens database integrity and must
be corrected immediately. Complete a
full database consistency check (DBCC
CHECKDB). This error can be caused by
many factors; for more information,
see SQL Server Books Online.
How much trouble am I in?
A corruption in an index is not nearly as bad as a corruption in the base table as an index can be rebuilt.
Compare the table and index definitions between the source and destination databases.
Check the version of both servers as well. (was the backup automatically upgraded when restored to your server)
Drop and recreate the index and rerun the CheckTable.
Related
When I try to create a #temp table, I get this:
A severe error occurred on the current command. The results, if any, should be discarded.
Any ideas how to solve this error? Thank you!
In one of my update queries, I had the same problem. I realized that the problem was from memory leakage.
Restarting MSSQL service will flush tempDb resource and free a large amount of memory. This will solve the problem.
SQL SERVER – Msg 0, Level 11 – A Severe Error Occurred on the Current Command. The results, if Any, Should be Discarded
CHECKLIST for this error
First and foremost, check database consistency. This can be done by running below command in SQL Server
DBCC CHECKDB('database_name');
If you have nailed down to a table, then check table consistency. We can execute below command
DBCC CHECKTABLE('table_name');
Check the LOG folder which contains ERRORLOG and look for any file named ‘SQLDump*’ at the same time when the error was reported. If you find any, you can either contact Microsoft or use the self-service by getting dump analyzed using diagnostic preview.
If you are getting this while using extended stored procedure, then you need to run, debug by running the exact piece of code one by one. Here is one such error which had none of 3 causes.
In case you want to see the error yourself, feel free to use below code
create table #ErrorLog (column1 char(8000))
go
insert into #ErrorLog
exec xp_readerrorlog 'SQL Error'
drop table #ErrorLog
Reference: Pinal Dave (https://blog.sqlauthority.com)
In SQL Server 2008 R2 a temp-table in a stored procedure is defined with 2 varchar fields of length 25 and 50 that are too short for some of the data that is inserted into them. So this error makes perfect sense:
Msg 8152, Level 16, State 14, Procedure XYZ, Line 48
String or binary data would be truncated.
The statement has been terminated.
The trouble is, this error has only just started occurring in our production environment, and this is causing problems. Our UAT environment has lots of data that could also trigger this error, but doesn't.
We could just lengthen the fields in the stored procedure, but we would like to understand what change or setting could have caused this error to start appearing in production. We checked ANSI_WARNINGS and they were FALSE in both environments.
Any ideas would be appreciated.
I've got following error in dbcc checkdb output from our customer for one table (more of very similar lines):
Msg 8964, Level 16, State 1, Line 1
Table error: Object ID 212503619, index ID 1, partition ID 72057594046251008, alloc unit ID
72057594048675840 (type LOB data). The off-row data node at page (1:705), slot 0, text ID 328867287793664 is not referenced.
CHECKDB found 0 allocation errors and 49 consistency errors in table 'X' (object ID 2126630619).
This error was created when running upgrade of our software (if he restores DB from backup and run the upgrade again, the same issue reappears).
My question is - how can I possibly create this kind of error from my app? I always thought that this kind of error must be caused by some environmental (HDD) problem, but I've seen the same issue on the same table on another environment. I tried the same steps as him, but without success.
Thanks!
You're right, this is probably a severe bug in SQL Server. It is not possible to cause corruption using documented and supported T-SQL. To cause corruption you need
hardware problems
OS-level file system problems (filter drivers, ...)
Undocumented commands like DBCC WRITEPAGE
A severe bug
Can you single-step through the upgrade script? If not, try tracing it with SQL Profiler. Find the statement that first makes corruption appear.
Here is a simpler, less noisy command:
DBCC CHECKDB([AdventureWorks2012]) WITH NO_INFOMSGS, ALL_ERRORMSGS
I ran into an error in Sql Server and after resolving it, I am looking for the reason why this was happening.
The situation is that I tried to alter a column in a table like this
Alter Table tblEmployee
Alter Column empDate Date
But while running this script, I get the error -
The statistics 'empDate' is dependent on column 'empDate'.
Msg 4922, Level 16, State 9, Line 1
ALTER TABLE ALTER COLUMN empDate failed because one or more objects access this column.
It turns out that this error was because of a statistic being referenced on this column. I have no script that explicitly creates a statistic, and the error occurred in the production environment, so it must have been auto-created. If it is auto-created, then why isn't Sql Server deleting it by itself? My error was resolved when I dropped the statistic.
I looked at other places and not able to find anything relevant.
I haven't looked hard at SQL statistics for a few versions, but back when, auto-generated statistics had fairly distinctive names (like "_WA_Sys_00000005_00000037"). If your statistics literally had the name "empDate", then it was almost certainly not and auto-created statistics, but something someone created deliberately.
I have a problem with the replication on my machine where I am stuck with a number of subscriptions showing in SSMS that do not exist. I have tried deleting them using the UI in SSMS and also using some T-SQL...but no luck. The publications don't even exist any more (they were on the same machine).
Any ideas on how I could remove them?
More info:
This is the situation I appear to be in where there are 3 subscriptions (that SSMS will not let me look at because 'they do not exist').
You might have some orphaned metadata in the distribution database. If you're no longer publishing any data you might want to try Disabling Publishing and Distribution to remove the orphaned publications and subscriptions.
I find it odd that sp_removedbreplication didn't work... maybe try sp_dropsubscription, and include the ignore_distributor parameter:
declare #yourServer sysname
set #yourServer = ##servername
exec sp_dropsubscription
#publication='UD-ForCMS',
#article='all',
#subscriber=#yourServer,
#destination_db='CMS',
#ignore_distributor=1
I've found sometimes that the system view objects created by the replication can be left hanging. Stopping replication from being manually rebuilt. My solution was to manual drop the system view syncobj. I recommend always dropping the subscriptions and the publication before dropping publication properties above since I've found items get left behind leaving for long term problems.
Msg 2714, Level 16, State 3: There is already an object named
'syncobj_0x3437324238353830' in the database. Msg 21745, Level 16,
State 1, Procedure sp_MSrepl_articleview, Line 272 Cannot generate a
filter view or procedure. Verify that the value specified for the
#filter_clause parameter of sp_addarticle can be added to the WHERE
clause of a SELECT statement to produce a valid query. Msg 3931, Level
16, State 1, Procedure sp_MSrepl_articleview, Line 401 The current
transaction cannot be committed and cannot be rolled back to a
savepoint. Roll back the entire transaction. Warning: The distribution
agent job has been implicitly created and will run under the SQL
Server Agent Service Account.