If DBCC printed error messages, contact your system administrator: operand type clash on index rebuild - indexing

Question: I'm using SQL Server 2016 and have a table with encrypted columns using Always Encrypt. I had to make some changes to the table. So, I had to drop and re-add the table. The table has one index, the clustered index.
When I rebuild my indexes on the table specifying the name of the index it is fine:
DBCC DBREINDEX ('[case]', PK_Case_1,90);
The result is..
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Completion time: 2021-07-30T17:52:21.6183694-04:00
But, if I run it for all indexes on the table, I get...
DBCC DBREINDEX ('[case]', ' ',90);
Msg 206, Level 16, State 2, Line 3
Operand type clash: nvarchar(max) encrypted with (encryption_type = 'DETERMINISTIC', encryption_algorithm_name = 'AEAD_AES_256_CBC_HMAC_SHA_256', column_encryption_key_name = 'CEK_Auto1', column_encryption_key_database_name = 'DBNAME') is incompatible with varchar
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Completion time: 2021-07-30T17:53:06.1301441-04:00
So, I looked to see what other indexes there may be and it only shows the one...
USE DBNAME
EXEC sp_helpindex '[Case]'
index_name index_description, index_keys
PK_Case_1 clustered, unique, primary key located on PRIMARY CaseID
I ran dbcc checkdb(DBNAME,repair_allow_data_loss) - and there are no errors.
Re-ran DBREINDEX and it the result are the same. Any ideas as to where these mixed results are coming from?
--UPDATE SOLVED--
The issue was not a hidden index, it was the statistics. I dropped the statistics and rebuilt the index the error no longer appears. I'm guessing that one of the statistics was referencing an old datatype.

You can rebuild a clustered index online or offline. Here, we will discuss the steps to rebuild an index online using the SQL Server Management Studio. The detailed steps are as follows:
In SSMS, from the Object Explorer box, click the plus sign to expand the SQL database containing the table on which you need to rebuild an index online.
Expand the database table on which you want to rebuild the index online.
Expand the Indexes folder, right-click the index you wish to rebuild
online, and select Properties.
Select Options under Select a page.
Select Allow online DML processing, and choose True from the list,
and then click OK.
Right-click the index to be rebuilt online, and then select Rebuild.
When the ‘Rebuild Indexes’ dialog box opens, make sure that the
correct index is listed in the Indexes to rebuild the grid. Click OK.

Unless NO_INFOMSGS is specified (the table name must be specified), DBCC DBREINDEX always returns:
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Link reference:
https://learn.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-dbreindex-transact-sql?view=sql-server-ver16

Related

Delete primary index of a database table programmatically

I need to delete a Primary key indexes on some database tables. Afterwards indexes will be re-created. Meanwhile some calculation will be performed.
I have following SQL Commands:
DROP INDEX "SAPSR3"."KNA1~0";
that are working correctly.
But once called within ABAP program:
EXEC SQL.
DROP INDEX SAPSR3.KNA1~0
ENDEXEC.
The message "SQL error 911 occurred when executing Native SQL" has been raised.
I've also tried with:
CALL FUNCTION 'RSDG_KEY_INDEX_DEL'
EXPORTING
i_tablnm = lv_tblname. " containing "KNA1"
This also doesn't work.
Is there any FM or similar way to perform such activity?
I also tried:
EXEC SQL.
DROP INDEX KNA1~0
ENDEXEC.
What you tried, in the SQL console (DROP INDEX "SAPSR3"."KNA1~0";), and in the ABAP program (DROP INDEX SAPSR3.KNA1~0), are not written identically as you can see!
I have just tried in ABAP below the version that you tried in the SQL console, and it dropped the index as intended!
EXEC SQL.
DROP INDEX "SAPSR3"."KNA1~0"
ENDEXEC.
So, why, in your ABAP attempt, did you remove the double quotes around the index name? (and also for the scheme name, but I guess it has less undesired effect).
In the SQL console, I'm really not sure that DROP INDEX SAPSR3.KNA1~0 works! Because there is the special "tilde" character, you need to add double quotes around the index name, the following is the minimal working syntax: DROP INDEX SAPSR3."KNA1~0".

SQL Server- The provided statistics stream is corrupt

I am trying to add statistics to a table that I already created. When I tried to run it, it throws an error:
The provided statistics stream is corrupt
This is my query for an example of a stats:
IF NOT EXISTS (SELECT *
FROM sys.stats
WHERE name = N'_WA_Sys_00000027_3C69FB99'
AND object_id = object_id(N'[dbo].[PromotionEvent]'))
CREATE STATISTICS [_WA_Sys_00000027_3C69FB99]
ON [dbo].[PromotionEvent]([CRMCode])
WITH STATS_STREAM = 0x010000000100000000000000000000008B95918100000000C4040000000000008404000000000000E7020000E7000000480000000000000008D0000090D4B94007000000AB7FBA0034A60000BA29000000000000BA290000000000000000803FD9899D3D00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000B0000000B0000000100000010000000ACB7283D00E8264600E02446ACB7283D000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000013000000000000000000000000000000E1020000000000001003000000000000180300000000000058000000000000006B00000000000000AA00000000000000E90000000000000028010000000000006701000000000000A601000000000000E50100000000000024020000000000006302000000000000A202000000000000100010000000EE42000000000000803F040000300010000000803F0000803F0000803F04000001003F00320046003200300043003100350037002D0034003500330044002D0045003600310031002D003800300010000000803F000000000000803F04000001003F00330036003300380043003300300039002D0033003500330044002D0045003600310031002D003800300010000000803F000000000000803F04000001003F00330046003600350039003300440044002D0030003400330044002D0045003600310031002D003800300010000000803F000000000000803F04000001003F00350045003000320030003800460044002D0034004200330044002D0045003600310031002D003800300010000000803F000000000000803F04000001003F00380045003400370044003100310045002D0034003000330044002D0045003600310031002D003800300010000000803F000000000000803F04000001003F00410030003100310033003100330039002D0034004500330044002D0045003600310031002D003800300010000000803F000000000000803F04000001003F00410045003400460037004200440046002D0033003100330044002D0045003600310031002D003800300010000000803F000000000000803F04000001003F00430041003300360044003000340031002D0038003700330043002D0045003600310031002D003800300010000000803F000000000000803F04000001003F00430045003600410039003200320042002D0034003700330044002D0045003600310031002D003800300010000000803F000000000000803F04000001003F00450044004500340043003300310039002D0034003800330044002D0045003600310031002D003800FF010000001A0200002002000002000000280000002800000000000000000000000000000001000000060000000000BA29000000000000
GO
Why do I get this error? Is it because the stream is too long? How do I fix this?
I have to stick with this stream because I am doing data archiving so the stats must have similar name.
Thanks
try to run DBCC CHECKDB against your DB, it looks like you have corrupted system table with ID 60 holding information about object in your DB.
jaromora;
go
Try to use
DBCC CHECKTABLE(YourTableName, REPAIR_REBUILD )
While performing above operation ensure that your database is in a single user mode.
If this doesn't work then you can try to drop the primary key of the table and recreate it.
Also if the issue is still not resolved then; the last option would be:
DBCC CHECKTABLE(YourTableName, REPAIR_ALLOW_DATA_LOSS)

Error when trying to publish database to Azure without clustered indexes

I'm getting the following error when trying to publish my database to my Azure site:
17:13:29: Could not publish the site. Unable to publish the database. For more information, see "http://go.microsoft.com/fwlink/?LinkId=205387"
17:13:29: Error detail:
17:13:29: An error occurred during execution of the database script. The error occurred between the following lines of the script: "332" and "334". The verbose log might have more information about the error. The command started with the following:
17:13:29: "INSERT [dbo].[DBStatus] ([LastIndex], [LastUpdated"
17:13:29: Tables without a clustered index are not supported in this version of SQL Server. Please create a clustered index and try again. http://go.microsoft.com/fwlink/?LinkId=178587
17:13:29: Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_SQL_EXECUTION_FAILURE.
This link explains the error: http://blogs.msdn.com/b/sqlazure/archive/2010/04/29/10004618.aspx
Is there an easy way to convert my database to have clustered indexes or should I just choose a host with SQL Server 2012 hosting?
I wouldn't change your hosting option simply due to this. Add the clustered indexes.
There is a tool called SQL Database Migration Wizard which can analyze a SQL database and make a migration script and even move the data. One of the things it will do is suggest a clustered index on tables that don't have them. However, like any tool, make sure you look at what it is suggesting and see if it makes sense in your scenario.
My suggestion is to look at the tables that do not have a clustered index and determine a reasonable index to create. A tool like the one above can make suggestions, but they are just suggestions and may not be exactly what your table would benefit from.
The requirement for clustered indexes for Azure SQL Database comes from the fact that they replicate the data in triplicate and the clustered indexes makes that a faster process.
I've done these steps:
1- Get a list of Tables without Primary Key by running this query:
USE DatabaseName;
GO
SELECT SCHEMA_NAME(schema_id) AS SchemaName,name AS TableName
FROM sys.tables
WHERE OBJECTPROPERTY(OBJECT_ID,'TableHasPrimaryKey') = 0
ORDER BY SchemaName, TableName;
GO`
2- Create Alert table scripts for all tables, add them a Identity field and make it Primary by scripts like this:
ALTER TABLE [dbo].[tableName] ADD identityFieldName BIGINT IDENTITY;
ALTER TABLE [dbo].[tableName] ADD CONSTRAINT PK_Table_identityFieldName_1 PRIMARY KEY CLUSTERED (identityFieldName);
Repeat above query for all tables that does not have Primary Key

DBCC CHECKDB in SQL Azure

I'm trying to truncate a table in SQl Azure:
TRUNCATE TABLE dbo.Product;
and getting error:
Msg 608, Level 16, State 1, Line 1 No catalog entry found for
partition ID 0 in database 830. The metadata is inconsistent. Run DBCC
CHECKDB to check for a metadata corruption.
DBCC CHECKDB is unsupported in SQL Azure.
What can I do?
Drop and recreate the table?
Maybe, there are better ideas?
ok, small piece of information for you SQL Server and Windows Azure SQL Database are not the same...
WASD are TDS based upon SQL Server technology, hence the fact that somethings aren't possibel in WASD.
to see which things work or don't work in WASD check here : http://msdn.microsoft.com/en-us/library/windowsazure/ee336253.aspx
another thing is that when you have any foreign keys available truncate will not be allowed and according to me that's the reason why it fails
check this MSDN Forum thread for more info : http://social.msdn.microsoft.com/Forums/windowsazure/en-US/ceeae474-fb19-4282-a56b-c0718f06e9ab/sql-azure-identity-reseed

SQL Server attach and detach database

I am getting the following error on a different machine which is maintained by IT.
Could not find row in sysindexes for database ID 40, Object ID 1,
Index ID 1. RUN DBCC Checktable on sysindexes.
I am able to attach and detach the database on my laptop.
I tried DBCC Checktable (SYSINDEXES) and it gives an error
Cannot find a table or object with the name Sysindexes.
Any idea on how can I troubleshoot this issue?
Is your table temporary table.If so
http://support.microsoft.com/kb/269282/EN-US/
says
Change the non-clustered index that you created on the temporary table to a clustered index.
-or-
Do not use the non-clustered index on a temporary table.