BELOW IS THE DBCC ERR:-
Table error: page (1:735428) allocated to object ID
2025058250, index ID 0, partition ID 132714217473000, alloc unit ID
132724217472000 (type In-row data) was not seen. The page may be invalid or may
have an incorrect alloc unit ID in its header.
There are 75408262 rows in 744739 pages for object
"tblancellationHistory".
CHECKDB found 0 allocation errors and 1 consistency
errors in table 'tblCancellationHistory' (object ID 2025058250).
TO KNOW THE OBJECT, ANYWAY ITS ALREADY MENTIONED IN THE ERROR MSG :
USE
go
SELECT au.allocation_unit_id, OBJECT_NAME(p.object_id) AS
table_name, fg.name AS filegroup_name,
au.type_desc AS allocation_type, au.data_pages, partition_number
FROM sys.allocation_units AS au
JOIN sys.partitions AS p ON au.container_id = p.partition_id
JOIN sys.filegroups AS fg ON fg.data_space_id = au.data_space_id
WHERE au.allocation_unit_id = (allocation_unit_id
ORDER BY au.allocation_unit_id
au.type_desc AS allocation_type, au.data_pages, partition_number
FROM sys.allocation_units AS au
JOIN sys.partitions AS p ON au.container_id = p.partition_id
JOIN sys.filegroups AS fg ON fg.data_space_id = au.data_space_id
WHERE au.allocation_unit_id = (allocation_unit_id
ORDER BY au.allocation_unit_id
Once you get the Object name try the following ,
DBCC CHECKTABLE(TABLENAME, REPAIR_REBUILD)
The above dont have any impact on data, so there is no data loss.
If that dint solve the purpose, we have to opt for DATA LOSS
DBCC CHECKTABLE(TABLENAME, REPAIR_ALLOW_DATA_LOSS)
Make sure we have enough permission to run the above.
If it dint solve we need to contact microsoft, hopefully it will resolve.