SQL Server обнаружил логическую ошибку ввода-вывода, связанную с согласованностью
рейд интеловский псевдожелезный, ошибок нет.
база ЗУП была временно помещена на этот не боевой сервер, теперь понадобилась.
Есть более ранний бэкап MSSQL но без новых нужных данных.
не выгружается DT:
дамп SQL делается, но не грузиться на другой MS SQL сервер:
Починка DB не проходит:
DBCC CHECKDB (N'ZUP', REPAIR_REBUILD) WITH NO_INFOMSGS
Вывожу первую строку из каждой таблицы,
Где получаю ошибку, пытаюсь чинить таблицу
одну починил, сейчас вторую не могу починить _Reference418 (Справочник.ПризПодарокПрисоединенныеФайлы) - без записей 100%
не могу её также и переименовать/удалить, чтобы скопировать с предыдущего бэкапа.
Что можно сделать?
база ЗУП была временно помещена на этот не боевой сервер, теперь понадобилась.
Есть более ранний бэкап MSSQL но без новых нужных данных.
не выгружается DT:
Ошибка СУБД:
Microsoft SQL Server Native Client 10.0: SQL Server обнаружил логическую ошибку ввода-вывода, связанную с согласованностью: неправильная контрольная сумма (ожидаемая: 0x43510069; фактическая: 0x8b788068). Она произошла при прочитать страницы (1:89373) в базе данных с идентификатором 6 по смещению 0x0000002ba3a000 файла "D:\SQL!\ZUP.mdf". Дополнительные сведения см. в журнале ошибок SQL Server и журнале системных событий. Это серьезная ошибка, которая угрожает целостности базы данных и должна быть немедленно исправлена. Выполните полную проверку базы данных на согласованность (DBCC CHECKDB). Эта ошибка может быть вызвана многими причинами; дополнительные сведения см. в электронной документации по SQL Server.
HRESULT=80004005, SQLSrvr: SQLSTATE=HY000, state=2, Severity=18, native=824, line=1
дамп SQL делается, но не грузиться на другой MS SQL сервер:
System.Data.SqlClient.SqlError: Не удалось продолжить просмотр с NOLOCK вследствие перемещения данных. (Microsoft.SqlServer.SmoExtended)
Починка DB не проходит:
DBCC CHECKDB (N'ZUP', REPAIR_REBUILD) WITH NO_INFOMSGS
Сообщение 8921, уровень 16, состояние 1, строка 2
Проверка отменена. В процессе сбора фактов была обнаружена ошибка. Возможно, база данных tempdb достигла предела памяти, или системная таблица не согласована. Проверьте предыдущие ошибки.
Вывожу первую строку из каждой таблицы,
Скрытый текст |
|---|
use ZUP
go
DECLARE @SchemaName NVARCHAR(MAX);
DECLARE @TableName NVARCHAR(MAX);
DECLARE @SqlCommand NVARCHAR(MAX);
-- Define the list of tables to loop through
DECLARE TableCursor CURSOR LOCAL FAST_FORWARD FOR
SELECT s.name, t.name
FROM sys.tables t
INNER JOIN sys.schemas s ON t.schema_id = s.schema_id;
OPEN TableCursor;
FETCH NEXT FROM TableCursor INTO @SchemaName, @TableName;
WHILE @@FETCH_STATUS = 0
BEGIN
-- Build your dynamic SQL statement for the current table
print @TableName
SET @SqlCommand = N'SELECT COUNT(*) FROM ' + QUOTENAME(@SchemaName) + '.' + QUOTENAME(@TableName);
-- Execute it
EXEC sys.sp_executesql @SqlCommand;
-- Fetch the next table
FETCH NEXT FROM TableCursor INTO @SchemaName, @TableName;
END
-- Clean up resources
CLOSE TableCursor;
DEALLOCATE TableCursor; Показать |
Где получаю ошибку, пытаюсь чинить таблицу
USE ZUP
DBCC CHECKTABLE ('_Enum1371',repair_allow_data_loss)
GOодну починил, сейчас вторую не могу починить _Reference418 (Справочник.ПризПодарокПрисоединенныеФайлы) - без записей 100%
Сообщение 824, уровень 24, состояние 2, строка 1
SQL Server обнаружил логическую ошибку ввода-вывода, связанную с согласованностью: неправильная контрольная сумма (ожидаемая: 0x37a16fe9; фактическая: 0xe56790d0). Она произошла при прочитать страницы (1:89376) в базе данных с идентификатором 6 по смещению 0x0000002ba40000 файла "D:\SQL!\ZUP_MT.mdf". Дополнительные сведения см. в журнале ошибок SQL Server и журнале системных событий. Это серьезная ошибка, которая угрожает целостности базы данных и должна быть немедленно исправлена. Выполните полную проверку базы данных на согласованность (DBCC CHECKDB). Эта ошибка может быть вызвана многими причинами; дополнительные сведения см. в электронной документации по SQL Server.
не могу её также и переименовать/удалить, чтобы скопировать с предыдущего бэкапа.
Что можно сделать?
Найденные решения
Остальные ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Добрый день.
(1)
truncate table может быть попробовать на этой таблице?
Или средствами 1С ТиИ запустить?
Ну и диски в рейде проверить, не ребилдился ли он недавно.
(1)
одну починил, сейчас вторую не могу починить _Reference418 (Справочник.ПризПодарокПрисоединенныеФайлы) - без записей 100%
truncate table может быть попробовать на этой таблице?
Или средствами 1С ТиИ запустить?
Ну и диски в рейде проверить, не ребилдился ли он недавно.
(3) Тогда ТиИ или средствами 1С попробовать реструктуризацию запустить. Добавить реквизит булевный справочнику, реструктуризация, удалить его, снова реструктуризация... смотрим, изменилось ли что-нибудь.
Расширений лишних нет в базе?
Расширений лишних нет в базе?
(10)
Ну, написать генерилку T-SQL скрипта, что бы хотя бы сравнить кол-во записей в табличках.
Пока можно предположить, что ТиИ удалило "дефрагментацию данных".
Кстати, как часто производилось обслуживание БД, в частности rebuild/reorganize index?
да и данных там немного.
Ну, написать генерилку T-SQL скрипта, что бы хотя бы сравнить кол-во записей в табличках.
Пока можно предположить, что ТиИ удалило "дефрагментацию данных".
Кстати, как часто производилось обслуживание БД, в частности rebuild/reorganize index?
(12)
Можно получить "приблизительное" кол-во записей из метаданных, не сильно отличное от реального числа. (правда если не обновлялась статистика, то тут может быть большая разница)
(12)
При желании таблица может легко распухнуть в 2 раза - это особенности гуида в кластерном индексе.
в битой базе не выцепишь количество строк в битых таблицах
Можно получить "приблизительное" кол-во записей из метаданных, не сильно отличное от реального числа. (правда если не обновлялась статистика, то тут может быть большая разница)
SELECT
t.name AS table_name,
p.rows AS row_count
FROM sys.tables t
JOIN sys.partitions p ON t.object_id = p.object_id
WHERE t.name = 'имя_таблицы'
AND p.index_id IN (0, 1);(12)
никогда, но там и активности особой не было.
При желании таблица может легко распухнуть в 2 раза - это особенности гуида в кластерном индексе.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот