1с sql server обнаружил логическую ошибку ввода вывода
← →
Фокс Йожин ( 2011-10-01 16:59 ) [0]
Есть некая таблица MyTable. При выборке SELECT * FROM MyTable получаю ошибку:
SQL Server обнаружил логическую ошибку ввода-вывода, связанную с согласованностью: недопустимый параметр защиты. Она произошла при прочитать страницы (1:1412094) в базе данных с идентификатором 10 по смещению 0x000002b17fc000 файла "D:\Base \BC1\BC1.mdf". Дополнительные сведения см. в журнале ошибок SQL Server и журнале системных событий. Это серьезная ошибка, которая угрожает целостности базы данных и должна быть немедленно исправлена. Выполните полную проверку базы данных на согласованность (DBCC CHECKDB). Эта ошибка может быть вызвана многими причинами; дополнительные сведения см. в электронной документации по SQL Server.
Вычленить диапазон записей из данной таблицы, которые попадают под ошибку и их удалить?
← →sniknik © ( 2011-10-01 17:08 ) [2]
> SELECT * FROM MyTable
SELECT AnyField FROM MyTable
SELECT AnyButNonBiFirstField FROM MyTable
SELECT TOP 1 * FROM MyTable
SELECT * FROM MyTable WHERE KeyField = 11
дают ошибку?
могут быт противоречивые данные (покоцанные) и типа в ключе дублировались. тогда вычислить и удалить, или скопировать обходя в копию таблицы.
← →Фокс Йожин ( 2011-10-01 17:19 ) [3]
> sniknik © (01.10.11 17:08) [2]
SELECT AnyField FROM MyTable - ошибка
SELECT AnyButNonBiFirstField FROM MyTable - ошибка
SELECT TOP 1 * FROM MyTable - нет ошибки
SELECT * FROM MyTable WHERE KeyField = 11 - нет ошибки
> Ega23 © (01.10.11 17:07) [1]
>
>
DELETE? Попробую, но ведь при выборке этого диапазона возникает ошибка.
Ega23 © ( 2011-10-01 17:37 ) [4]
> Попробую, но ведь при выборке этого диапазона возникает
> ошибка.
Выдели этот диапазон.
Например, таблица, ID c 1 по 1000. Битые записи в диапазоне 439-523.
Найди этот диапазон и удали. Либо перенеси в другую таблицу всё, что лежит вне рамок данного диапазона.
sniknik © ( 2011-10-01 17:54 ) [5]
> этого диапазона возникает ошибка.
> SELECT TOP 1 * FROM MyTable - нет ошибки
> SELECT * FROM MyTable WHERE KeyField = 11 - нет ошибки
есть все чтобы вычислить и удалить. операции > < известны? ну, вперед.
если ошибка будет на удалении, то поможет копирование. т.к. up, есть все чтобы вычислить и . скопировать.
← →sniknik © ( 2011-10-01 17:59 ) [6]
+
операция удаления не обязана читать данные. ей достаточно поставить метку.
а уж после этого DBCC CHECKDB сработает, т.к. не будет заморачиваться целостностью удаленного "мусора".
Фокс Йожин ( 2011-10-01 18:31 ) [7]
> sniknik © (01.10.11 17:54) [5]
>
> есть все чтобы вычислить и удалить. операции > < известны?
> ну, вперед.
>
Дык, ключ не понятно как сгенерён.
Делаю:
select top 9230
* from MyTable
order by ID
выбирает нормально, меняю количество на 9231 - ошибка.
> Дык, ключ не понятно как сгенерён.
это ты непонятно как сгенерён. в школе учился?
сколько всего записей? допустим 1000, + допустим ID автоинкремент и соответствует порядку (для примера сойдет), т.е. первая 1 последняя 1000.
берем половину - 500
select * from MyTable where ID select * from MyTable where ID > 500 работает?
допустим ошибка на втором запросе т.е. теперь первая 501 последняя 1000.
берем половину - 750
select * from MyTable where ID > 500 AND select * from MyTable where ID > 750 работает?
и т.д. рекурсия блин. метод половинного деления.
← →Фокс Йожин ( 2011-10-01 21:21 ) [9]
> сколько всего записей? допустим 1000, + допустим ID автоинкремент
> и соответствует порядку (для примера
1. Первичный ключ - символьный
2. LastKey - это последний ключ в выборке первых неглючных 9230 записей, select top 9230 * from . order by ID,
3. Половинное деление подходит, если глючный диапазон - один, а если внутри него есть живые диапазоны, чередующиеся с глючными?
sniknik © ( 2011-10-01 22:16 ) [10]
> 1. Первичный ключ - символьный
и что? больше, меньше не работает? или половину рассчитать не можешь? ну так это не обязательно должна быть половина, дели по не предопределение количеству. всего то проблем больше итераций будет.
> 2. LastKey - это последний ключ в выборке первых неглючных 9230 записей, select top 9230 * from . order by ID
и что?
с order by и без порядок может быть разный.
> 3. Половинное деление подходит, если глючный диапазон - один, а если внутри него есть живые диапазоны, чередующиеся с глючными?
ну так сделай над собой усилие, и ищи в 2х-3-х диапазонах, в скольких понадобится, до записей.
вообще, тебе нужно восстановить или нет? может ну его нафиг, грохни базу и начни все сначала (символьный на искусственный ключ с автоинкрементом не забудь поменять).
sniknik © ( 2011-10-01 22:26 ) [11]
Можно еще попробовать удалить ключи/индексы. на время.
← →Фокс Йожин ( 2011-10-01 22:44 ) [12]
> sniknik © (01.10.11 22:16) [10]
> ну так это не обязательно должна быть половина, дели по
> не предопределение количеству. всего то проблем больше итераций
> будет.
Ничего не понял. Вот ключи из 16 символов: AAABBBCCCDD . 1345FF,
EEBBCCCDD . AA55C, и т.д. Как перебирать диапазоны?
> и что?
> с order by и без порядок может быть разный.
вычленил диапазон с помощью двух запросов select top N . order by ID и select top M . order by ID desc
Сохранил полученные ID во временную таблицу tmp_MyTable
Делаю delete form MyTable where ID not in (select ID from tmp_MyTable)
Т.е. удаляю все записи, кроме тех, что выбрались без ошибки.
Всё равно падает с ошибкой ввода-вывода.
> вообще, тебе нужно восстановить или нет? может ну его нафиг, грохни базу и начни все сначала (символьный
> на искусственный ключ с автоинкрементом не забудь поменять).
>
>
Нужно. База - 1С:УПП. Так что, ни о каких самодельных автоинкрементах не может быть и речи.
sniknik © ( 2011-10-01 22:58 ) [13]
> перебирать диапазоны?
1 < AA < AAA < EE
и т.д.
> Всё равно падает с ошибкой ввода-вывода.
бл. ну что ты делаешь?
> Делаю delete form MyTable where ID not in (select ID from tmp_MyTable)
> Т.е. удаляю все записи, кроме тех, что выбрались без ошибки.
т.е. условие на перебор и сравнение со ВСЕМИ записям, т.е. чтение тех от которых падает (чтобы сравнить).
delete form MyTable where >
← →Фокс Йожин ( 2011-10-01 23:15 ) [14]
> sniknik © (01.10.11 22:58) [13]
Простой тест:
1. делаю
select
* from MyTable where
Выбирает 1 строчку
2. делаю
select
* from MyTable where ID >= 0xAEB0000E0C3BD80911DC4BE92724F491
and ID падает с ошибкой ввода-вывода.
3. делаю
select
* from MyTable where _IDRRef >= "1" and _IDRRef
падает с ошибкой ввода-вывода.
Т.е., падает вообще всегда, когда задаётся диапазон.
Как же тогда перебирать половинным делением.
← →Фокс Йожин ( 2011-10-01 23:18 ) [15]
select
* from ID where ID between "1" and "1"
Тоже падает с ошибкой ввода-вывода
← →Фокс Йожин ( 2011-10-01 23:19 ) [16]
> Фокс Йожин (01.10.11 23:18) [15]
>
> select
> * from ID where ID between "1" and "1"
>
> Тоже падает с ошибкой ввода-вывода
Пардон:
select
* from MyTable where ID between "1" and "1"
Тоже падает с ошибкой ввода-вывода
← →sniknik © ( 2011-10-01 23:34 ) [17]
> Т.е., падает вообще всегда, когда задаётся диапазон.
с 1 операцией больше, или меньше не падает? этого достаточно чтобы выбрать.
> Как же тогда перебирать половинным делением.
тебе предлагали вариант, а не панацею. что делать и зачем делать (искать глючные и удалить), не ищи как не работает ищи как РАБОТАЕТ. у каждого глюка может быть по своему.
p.s. а вообще сдай базу в контору какую нибудь по восстановлению, а то чую делов натворишь, еще хуже станет.
← →Фокс Йожин ( 2011-10-01 23:45 ) [18]
> sniknik © (01.10.11 23:34) [17]
> с 1 операцией больше, или меньше не падает? этого достаточно
> чтобы выбрать.
падает
> p.s. а вообще сдай базу в контору какую нибудь по восстановлению,
> а то чую делов натворишь, еще хуже станет.
Они там, как правило, месяц держат. Да и не факт, что данные будут восстановлены.
Я, вот, хочу те данные,которые выбираются, сохранить в копию, а глючную таблицу дропнуть. Если после всего этого оборотно-сальдовая ведомость сойдётся, то можно сказать, баг пофиксен.
sniknik © ( 2011-10-01 23:50 ) [19]
> Дополнительные сведения см. в журнале ошибок SQL Server и журнале системных событий.
?
Фокс Йожин ( 2011-10-01 23:59 ) [20]
> sniknik © (01.10.11 23:50) [19]
пусто
картман © ( 2011-10-02 03:03 ) [21]
попробуй курсором - а вдруг? или че-нть вроде:
declare @key varchar(скока-то там)
select top 1 @key = id from mytable order by id
while true
begin
select top 1
into new_table
from mytable
where id > @key
order by id
select top 1 @key = id from mytable where id>@id order by id
end;
← →Anatoly Podgoretsky © ( 2011-10-02 10:41 ) [22]
> Фокс Йожин (01.10.2011 18:31:07) [7]
reindex сделал?
← →Фокс Йожин ( 2011-10-02 13:20 ) [23]
> картман © (02.10.11 03:03) [21]
пересоздал таблицу из копии, из тех строк, которые выбирались без падения.
> Anatoly Podgoretsky © (02.10.11 10:41) [22]
> reindex сделал?
Сделал. И реструктуризацию тоже. Теперь вот логическую проверку средствами 1С запустил. Жду результата.
Microsoft SQL Server 2005 Compact Edition Microsoft SQL Server 2005 Developer Edition Microsoft SQL Server 2005 Enterprise Edition Microsoft SQL Server 2005 Enterprise X64 Edition Microsoft SQL Server 2005 Express Edition Microsoft SQL Server 2005 Standard Edition Microsoft SQL Server 2005 Workgroup Edition Microsoft SQL Server 2005 Standard X64 Edition SQL Server 2008 Developer SQL Server 2008 Enterprise SQL Server 2008 Express SQL Server 2008 Standard SQL Server 2008 R2 Datacenter SQL Server 2008 R2 Developer SQL Server 2008 R2 Enterprise SQL Server 2008 R2 Express SQL Server 2008 R2 Express with Advanced Services SQL Server 2008 R2 Standard SQL Server 2008 R2 Standard Edition for Small Business SQL Server 2008 R2 Web SQL Server 2008 R2 Workgroup SQL Server 2012 Developer SQL Server 2012 Enterprise SQL Server 2012 Express SQL Server 2012 Standard SQL Server 2012 Web SQL Server 2012 Enterprise Core SQL Server 2014 Business Intelligence SQL Server 2014 Business Intelligence SQL Server 2014 Developer SQL Server 2014 Developer SQL Server 2014 Enterprise SQL Server 2014 Enterprise SQL Server 2014 Enterprise Core SQL Server 2014 Enterprise Core SQL Server 2014 Express SQL Server 2014 Express SQL Server 2014 Standard SQL Server 2014 Standard SQL Server 2014 Web SQL Server 2014 Web Еще. Меньше
Симптомы
2003-07-24 16:43:04.57 spid63 Getpage: bstat = 0x9, sstat = 0x800 кэша
2003-07-24 16:43:04.57 spid63 номер страницы — и должно быть: objid является и должно быть:
2003-07-24 16:43:04.57 spid63 (1:7040966)/(1:7040966) 2093354622/2039782424
2003-07-24 16:43:04.57 spid63. IAM означает, что страницы выделяется для этого объекта
2003-07-24 16:52:37.67 spid63 ошибка: кодом 605, поступившие, уровень опасности: 21, состояние: 1
2003-07-24 16:52:37.67 spid63 попытке выборки логической страницы (1:7040966) в базе данных, к которым относится «pubs» объект «авторы» не для объекта «заголовки».
2003-07-24 16:52:40.99 spid63 ошибка: 3448, уровень опасности: 21, состояние: 1
2003-07-24 16:52:40.99 spid63 не удается отменить запись журнала (63361:16876:181), для кода проводки (0:159696956) на странице (1:7040977), база данных pubs «» (12 код в базе данных). Сведения о странице: номер LSN = (63192:958360:10), тип = 2. Журнал информации: код операции = 2 контекста 1.
Ошибка spid66 14:31:35.92 2003-07-09: 823, уровень серьезности: 24, состояние: 2
2003-07-09 14:31:35.92 spid66 ввода-вывода (Неверный идентификатор страницы) обнаружена ошибка во время чтения по смещению 0x00000016774000 в файле «h:\sql\MSSQL\data\tempdb.mdf».
Дополнительные сведения
Потерянные записи: Успешного вызова WriteFile API, но операционная система, драйвера или кэширования контроллера не очистить правильно данных на физический носитель несмотря на то, что SQL Server уведомляется о том, что запись выполнена успешно.
Устаревшие чтения: Успешного вызова ReadFile API, но операционная система, драйвера или кэширования контроллера неверно возвращает более старой версии данных.
Например подтвержденной сценарии WriteFile API возвращается как успешный, когда немедленно, успешное чтение того же блока данных возвращает старые данные, включая данные, скорее всего хранятся в оборудовании, чтения кэша. В некоторых случаях эта проблема возникает из-за ошибки чтения кэша. В других случаях записи данных на физический диск записывается никогда не завершится.
SQL Server обнаружил недокументированных OS/аппаратном уровне чтения или записи проблемы на странице базы данных 12 (1:75007)
Номер LSN возвратил (63361:16876:181), номер LSN ожидается (63361:16876:500)
Обратитесь к поставщику оборудования и рассмотреть возможность отключения кэширования для устранения проблемы
На этом этапе чтения кэш содержит более раннюю версию страницы, либо данные неправильно записанная на физический диск. В любом случае (потерянные записи или устаревшие чтения) SQL Server сообщает внешней проблемы с операционной системой, драйвера или оборудования слои.
Если 3448 ошибка возникает при попытке отката транзакции с 605 ошибка или ошибка 823, компьютер под управлением SQL Server автоматически закрывает базу данных и пытается открыть и восстановить базу данных. Первая страница, обнаруживает 605 ошибка или ошибка 823 считается поврежденную страницу, и идентификатор страницы хранятся на компьютере под управлением SQL Server. Во время восстановления (до стадии повтора) при чтении неверный идентификатор страницы в журнале ошибок SQL Server регистрируются основные сведения о заголовок страницы. Это действие имеет большое значение, поскольку она помогает различать ситуации потери записи и чтения устаревших.
Можно увидеть следующие два общих поведений в сценариях устаревшие чтения:
Поведения, упомянутых в предыдущем абзаце означать ошибку чтения кэширования и они часто решить, отключив чтения кэша. Действия, описанные в предыдущем параграфе обычно принудительно недействительности данных в кэше и успешных операций чтения, возникающие Показать физический носитель правильно обновляется. Потерянные записи возникает, когда страницы, считываются обратно по-прежнему старой версии данных, даже после принудительного удаления механизмов кэширования.
Иногда проблема может оказаться для аппаратного кэша. Это может быть проблема с драйвером фильтра. В таких случаях Обзор программного обеспечения, включая средства архивирования и антивирусное программное обеспечение и затем определить наличие проблем с драйвером фильтра.
В некоторых сценариях описаны более подробно в следующих списках:
SQL Server «сортировка» операторы выполняют операции ввода-вывода, главным образом в и из базы данных tempdb . Эти операции ввода-вывода похожи на операции ввода-вывода буфера; Тем не менее они уже созданы для использования логику повторных попыток считывания для решения аналогичных проблем. Новые средства диагностики, описанных в данной статье неприменимы для этих операций ввода-вывода.
Microsoft было отмечено, что причина для следующих сортировки чтение ошибок обычно является устаревшим чтение или потерянные записи:
20:13:31.38 2003-04-01 утверждение SQL Server spid122: файл: < p:\sql\ntdbms\storeng\drs\include\record.inl >, строка = Сбой утверждения 1447 = "m_SizeRec > 0 & & m_SizeRec < = MAXDATAROW".
2003-03-29 09:51:41.12 spid57 сортировки чтения сбой (Неверный идентификатор страницы). PageID = (0x1:0x13e9), dbid = 2, файл = создаваемую e:\program SQL Server\mssql\data\tempdb.mdf. Повторная попытка.
Ошибка spid57 09:51:41.13 2003-03-29: 823, уровень серьезности: 24, состояние: 7
2003-03-29 09:51:41.13 spid57 ошибка ввода-вывода (Неверный идентификатор страницы) во время чтения по смещению 0x000000027d2000 в файле «e:\program создаваемую SQL Server\mssql\data\tempdb.mdf».
* 00931097 Module(sqlservr+00531097) (utassert_fail + 000002E3)
* 005B1DA8 Module(sqlservr+001B1DA8) (RecBase::Resize+00000091)
* 00407EE7 Module(sqlservr+00007EE7) (RecBase::LocateColumn+00000012)
* 00852520 Module(sqlservr+00452520) (mergerow + 000000A4)
* 008522B3 Module(sqlservr+004522B3) (merge_getnext+00000285)
* 0085207D Module(sqlservr+0045207D) (mergenext+0000000D)
* 004FC5FB Module(sqlservr+000FC5FB) (getsorted+00000021)
Перемещение базы данных tempdb на локальный диск без кэширования или отключение чтения кэширования клиентов, которые уже испытали эти ошибки сортировки часто разрешения проблем.
Так как устаревшие чтения или записи потеряны результаты в хранилище данных, не ожидается, может возникать разнообразные варианты поведения. Он может отображаться как отсутствующие данные, но некоторые из наиболее распространенных эффектов отсутствующие данные отображаются в виде повреждения индекса, возникает ошибка 644 или об ошибке 625:
Некоторые клиенты сообщали отсутствующих строк после их выполнения действия подсчета строк. Эта проблема возникает из-за потери записи. Возможно страницы должна была связана в цепочке страниц кластеризованного индекса. Если записи физически потеряно, данные также будут потеряны.
Важно. При появлении любой из вариантов поведения или если подозрительный из подобных проблем, а также отключение кэширования, корпорация Майкрософт настоятельно рекомендует получить последнее обновление для SQL Server и последние имитатор нагрузки ввода-вывода SQL Server. Корпорация Майкрософт также рекомендует выполнять строгая проверка операционной системы и ее связанных конфигураций.
Примечание. Корпорация Майкрософт подтвердила в редких и высокой интенсивностью некоторых аппаратных платформ могут возвращать устаревшие чтения. Если расширенной диагностики показывают возможные устаревшие потери чтения/записи условия, обратитесь к поставщику оборудования для проверки выполните вверх и тестирования с помощью служебной программы SQLIOSim .
SQL Server требует систем, обеспечивающих гарантированную доставку стабильной носитель, как описано в разделе Требования программы стабильности системы ввода -вывода SQL Server. Дополнительные сведения о требованиях к входным и выходным компонент SQL Server database engine содержатся Требования к ввода-вывода ядра базы данных в Microsoft SQL Server.
В этой статье рассказывается, как устранять ошибки, о чем сообщает DBCC CHECKDB команда.
Оригинальная версия продукта: SQL Server
Исходный номер КБ: 2015748
Симптомы
Причина
DBCC CHECKDB проверяет физическую и логическую последовательность страниц базы данных, строк, страниц распределения, связей с индексом, целостности ссылок на таблицу систем и других проверок структуры. Если какие-либо из этих проверок не удастся (в зависимости от выбранных параметров), ошибки будут отчитаться как часть команды.
Решение
Если восстановить из резервного копирования невозможно, у него есть функция для CHECKDB устранения ошибок. Если проблемы системного уровня, такие как аппаратная или файловая система, вызывают развращение данных, эти проблемы необходимо устранить перед восстановлением или восстановлением. Инженеры службы поддержки Майкрософт не могут помочь в физическом восстановлении поврежденных данных, если ремонт не устраняет ошибки согласованности или если резервное копирование базы данных повреждено.
CHECKDB обнаружил 0 ошибок распределения и 15 ошибок последовательности в базе данных "mydb".
repair_allow_data_loss является минимальным уровнем ремонта ошибок, найденных DBCC CHECKDB (mydb).
Рекомендация по ремонту — это минимальный уровень ремонта для устранения всех CHECKDB ошибок. Это не означает, что этот вариант ремонта исправит все ошибки. Кроме того, не все сообщаемые ошибки могут потребовать устранения такого уровня ремонта. Это означает, что не все ошибки, которые были допущены при рекомендации, фактически CHECKDB repair_allow_data_loss привели к потере данных. Необходимо выполнить ремонт, чтобы определить, приведет ли устранение ошибки к потере данных. Один из методов, которые помогут сузить уровень ремонта для каждой таблицы, — это использование для любой таблицы, DBCC CHECKTABLE сообщаемой об ошибке. Это покажет минимальный уровень ремонта для данной таблицы.
Попытка сценарий схемы базы данных,использовать сценарий для создания новой базы данных, а затем использовать инструмент, как BCP или SSIS Экспорт / Импорт мастера экспортировать как можно больше данных из поврежденной базы данных в новую базу данных. Следует помнить, что экспорт из поврежденной таблицы, скорее всего, не удастся. В таких случаях пропустить эту таблицу, перейти к следующей и спасти то, что можно спасти.
После ремонта или завершения экспорта и импорта данных необходимо выполнить ручную CHECKDB проверку данных. Дополнительные сведения можно найти в аргументах DBCC CHECKDB. После ремонта данные могут быть нелогичными. Например, ремонт (особенно вариант) может удалять целые страницы данных, содержащие REPAIR_ALLOW_DATA_LOSS несовместимые данные. В таких случаях таблица с иностранным отношением ключа к другой таблице может оказаться строками, не соответствующими основным строкам ключей в родительской таблице.
Изучение первопричин ошибок согласованности баз данных
Чтобы найти причину возникновения ошибок в согласованности баз данных, рассмотрим эти методы:
- Проверьте журнал Windows системных событий на всех системных уровнях, драйверах или ошибках, связанных с диском.
- Проверьте целостность файловой системы с помощью chkdsk.
- Запустите диагностику, предоставляемую производителями оборудования для компьютерной и/или дисковой системы.
- Работайте с поставщиком оборудования или производителем устройств, чтобы обеспечить:
- Аппаратные устройства и конфигурация подтверждают требования ядро СУБД Microsoft SQL Server ввода и вывода.
- Обновляются драйверы устройств и другие вспомогательные компоненты программного обеспечения всех устройств в пути I/O
Дополнительные сведения
Сведения о синтаксисе и сведениях и параметрах выполнения команды см. в материале DBCC CHECKDB DBCC CHECKDB (Transact-SQL).
Date/Time spid53 Using 'dbghelp.dll' version '4.0.5'
Поток date/Time spid53 **Dump — spid = 0, EC = 0x00000000855F5EB0
Date/Time spid53 ***Stack Dump being sent toFilePath\FileName
Дата и время spid53 * **
Date/Time spid53 *
Date/Time spid53 * BEGIN STACK DUMP:
Date/Time spid53 * Date/Timespid 53
Date/Time spid53 *
Дата и время spid53 * коррупция базы данных DBCC
Date/Timespid53 *
Date/Time spid53 * Input Buffer 84 bytes -
Date/Time spid53 * dbcc checkdb (mydb)
Date/Time spid53 *
Date/Time spid53 * **
Дата и время spid53 * -------------------------------------------------------------------------------
Date/Time spid53 * Short Stack Dump
Date/Time spid53 Stack Signature для свалки 0x00000000000001E8
Код возврата внешнего процесса сброса 0x20002001.Сведения об ошибках были отправлены в отчет об ошибках Watson.
Файлы, используемые для отчетов об ошибках, включают файл SQLDump .txt. Этот файл может быть полезен для исторических целей, так как содержит список ошибок, найденных в CHECKDB в формате XML.
Причина
Эта ошибка говорит о следующем: Windows сообщает об успешном считывании страницы с диска, но SQL Server обнаружил некоторые повреждения страницы. Данная ошибка схожа с ошибкой 823, за исключением того, что ОС Windows ее не обнаружила. Чаще всего это говорит о проблеме с подсистемой ввода-вывода, например сбое жесткого диска, проблемах со встроенным ПО диска, драйверами устройств и т. д. Дополнительные сведения об ошибках ввода-вывода см. в главе 2 документации Майкрософт об основных операциях ввода-вывода в SQL Server.
SQL Server использует API Windows, например ReadFile, WriteFile, ReadFileScatter, WriteFileGather, для операций ввода-вывода. После выполнения этих операций ввода-вывода SQL Server проверяет наличие ошибок, связанных с вызовами этих API. Если при вызове API происходит сбой из-за ошибки операционной системы, SQL Server сообщает об ошибке 823. Возможны ситуации, когда вызов API Windows фактически выполняется успешно, но данные, передаваемые операцией ввода-вывода, могли столкнуться с проблемой логической согласованности. Эти проблемы с логической согласованностью выводятся через ошибку 824.
- Файл базы данных, для которого была выполнена операция ввода-вывода.
- Смещение в файле, где была предпринята попытка выполнить операцию ввода-вывода.
- База данных, которой принадлежит этот файл.
- Номер страницы, включенной в операцию ввода-вывода.
- Была ли это операция чтения или записи.
- Сведения о проверке логической согласованности, которая завершилась ошибкой [тип проверки, фактическое значение и ожидаемое значение, используемое для этой проверки].
Эти проверки логической согласованности являются дополнительными проверками целостности, выполняемыми SQL Server, чтобы гарантировать, что определенные ключевые аспекты данных, вовлеченных в передачу, поддерживались в ходе операции ввода-вывода. К этим проверкам относятся контрольная сумма, обрыв страницы, короткий перенос, неверный идентификатор страницы, устаревшее чтение, ошибка аудита страницы. Характер выполненных проверок зависит от различных параметров конфигурации на уровне базы данных и сервера.
Друзья. Случилось горе-беда, упала база ТиС на SQL. Сразу оговорюсь: База была файловая, но т.к. один из регистров был слишком огромный (известное ограничение 1с 7.7) с июня сего года базу я экспортировал в SQL и всё бы ничего, если бы не моя лень, лень сделать бэкап.
И вот попал: SQL Server обнаружил логическую ошибку ввода-вывода, связанную с согласованностью: неверная контрольная сумма (ожидаемая 0x207589f9; фактическая: 0x21f589f9). Она произошла при прочитать страницы: (1:25392) в базе данных с идентификатором 5 по смещению: 0x0000000c66000 файла: c:\skladsql\skladsql.mdf
Ну и предварительно сделав бэкап, я давай её лечить разными снадобьями:
DBCC CHECKDB ('skladsql', REPAIR_FAST)прочитать страницу (1:25392) и заблокировать ее кратковременной блокировкой типа SH.
тест (IS_OFF (BUF_IOERR, pBUF->bstat)) не удалось. Значения равны 12584969 и -6.
CHECKDB обнаружил 0 ошибок размещения и 1 ошибок согласованности, не связанных ни содним объектом.
CHECKDB обнаружил 0 ошибок размещения и 1 ошибок согласованности в базе данныхDBCC CHECKDB ('skladsql', REPAIR_REBUILD)
прочитать страницу (1:25392) и заблокировать ее кратковременной блокировкой типа SH.
тест (IS_OFF (BUF_IOERR, pBUF->bstat)) не удалось. Значения равны 12584969 и -6.
CHECKDB обнаружил 0 ошибок размещения и 1 ошибок согласованности, не связанных ни содним объектом.
CHECKDB обнаружил 0 ошибок размещения и 1 ошибок согласованности в базе данныхпрочитать страницу (1:25392) и заблокировать ее кратковременной блокировкой типа SH.
тест (IS_OFF (BUF_IOERR, pBUF->bstat)) не удалось. Значения равны 12584969 и -6.
CHECKDB обнаружил 0 ошибок размещения и 1 ошибок согласованности, не связанных ни содним объектом.
CHECKDB обнаружил 0 ошибок размещения и 1 ошибок согласованности в базе данныхDBCC checkdb('skladsql')
ALTER DATABASE skladsql SET SINGLE_USER WITH ROLLBACK IMMEDIATEпрочитать страницу (1:25392) и заблокировать ее кратковременной блокировкой типа SH.
тест (IS_OFF (BUF_IOERR, pBUF->bstat)) не удалось. Значения равны 12584969 и -6.
CHECKDB обнаружил 0 ошибок размещения и 1 ошибок согласованности, не связанных ни содним объектом.
CHECKDB обнаружил 0 ошибок размещения и 1 ошибок согласованности в базе данныхDBCC CHECKALLOC ('skladsql')
прочитать страницу (1:25392) и заблокировать ее кратковременной блокировкой типа SH.
Инструкция проверки прервана из-за неустранимой ошибки.
_____________________========================________________________
Ничего это не дало вообщем. на соседнем форуме: https://www.sql.ru/forum/1330120/pomogite-podnyat-bazu
Всыпали конечно пинка, местами даже правильный маршрут дали.
Что сосбна я сделал: Создал пустую БД и с помощью встроенной утилиты: "Мастер импорта и экспорта данных" я перетащил живые таблицы в чистую базу.
Поле запуска этой новой базы, и проверив что же я потерял. а потерял я только таблицу: Номенклатура, да это печально, но это уже не так и плохо, ведь могло быть гораздо всё хуже.
Перечень повреждённых таблиц:
_1SCONNECT
_1SCONST
_1SCRDOC
_1SSTREAM
DH1731
DH2051
DH2695
DH3504
DH4389
DH9054
DH9125DT1611
DT1774
DT2051
DT3614
DT4389
DT5292
DT9054
DT9125RA2351
RA2964
RA351
RA4314
RA4335
RA438
RA4480RG2351
RG2964
RG351
RG4314
RG4335
RG438
RG4480SC131
SC84
SC9246
SC9249
___===__
Регистры я так понял фиг бы с ними, их можно будет через Тестирование и исправление восстановить.Возможно ли как-то снять пометку с этой страницы и аккуратно построчно выдернуть данные из повреждённых таблиц?
ps. На удивление диск живее все живых, SMART в идеале, также прогонял Victoria, всё гуд.Читайте также: