1с sql server обнаружил логическую ошибку ввода вывода
Ну, и давай я её чекать: DBCC CHECKDB ('skladsql', REPAIR_REBUILD)
Результата это особо не принесло, но при подключении через 1с, теперь появился доступ в конфигуратор, хотя толку нет совершенно. бэкап базы в файл слить не даёт.
SQL версии 2005 установлен, система Windows XP
И самое главное: Бэкапов нет. я эту базу из файловой в скулы перетащил только месяц назад, и ещё не добрался до бэкапоффф.
Да мой косяк, признаю. если удастся поднят базу, сразу же резервное копирование да каждый день!
НО реалии таковы, результаты исполнения команд лечоб:
DBCC CHECKDB ('skladsql', REPAIR_FAST)
прочитать страницу (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 ошибок согласованности в базе данных
прочитать страницу (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.
Да друзья, признаю что сам дурак, и из-за меня развалился союз. но тем не менее.
Есть ли вариант найти этот злосчастный косяк в базе.
Я честно гуглил, признаюсь. и 70% людей ссылаются на неисправный ХДД, но я почесав репу подумал: А может быть, ибо компу уже лет 15 примерно, тут всё может быть.
Захожу поглазеть на SMART, а там всё красиво. Загоняю в VICTORIA, а там всё идеально, диск как с магазина, даже выше 50ms нет задержек и скорость ниже 90mb/s не падает, прям удивительный диск.
Отключений электроэнергии не было (хотя до этого очень часто было и ИБП на данной машине отсутствовал, и база рубилась как только могла и в любое время жизни, а ей хоть бы х. и заводилась без проблем), а вчера вот я лично закрыл 1с, и выключил комп, всё гладко-ровно было.
Но вот беда.
Друзья помогайте-выручайте. базе исполняется 8 лет, если её потерять, это будет потеря-потерь..
Клянусь на святой клавиатуре, как поднимем базу сразу сделаю свёртку (ибо 6 гигов это не шутки), и настрою бэкапы.
Заранее благодарен, о великие гуру SQL
ps. Чуть не забыл, сейчас база при подключении 1с и вводе пароля. выдаёт:
SQL STATE 25000
Native: 0
Message: [Microsoft][ODBC SQL Server Driver]Недопустимое состояние транзакции
жмём ОК
SQL STATE 08S01
NATIVE: 0
Message: [Microsoft][ODBC SQL Server Driver] Ошибка связи
можно посмотреть что за страница и к какому объекту относится
dbcc page - IndexId & ObjectId
похоже, что за этим "проверка системных таблиц: объект с идентификатором 5." скрывается sys.sysrowsets
а что выдаст DBCC CHECKCATALOG ?
Я так понимаю, 1с - 7.7 и сама база открывается? Тогда проще скопировать данные в новую чистую базу
Я так понимаю, 1с - 7.7 и сама база открывается? Тогда проще скопировать данные в новую чистую базу
не надо чистую конфу, надо прям по инструкции. "чистая конфа" развернется заново и создаст новые названия таблиц. Часть может совпасть со старыми, часть - нет и придется ловить эти несоответствия.
После шага 4 надо зайти в конфигуратор новой базы - и дальше по инструкции.
не надо чистую конфу, надо прям по инструкции. "чистая конфа" развернется заново и создаст новые названия таблиц. Часть может совпасть со старыми, часть - нет и придется ловить эти несоответствия.
После шага 4 надо зайти в конфигуратор новой базы - и дальше по инструкции.
Всё допетрил зачем создавать константу, чтобы платформа поняла что было какое-то изменение и дала возможность создать заново метафайлы и т.д.
На 4 шаге в конфигураторе будет загружена конфигурация из MD, а в базе будет пустота. Самый простой способ заставить 1С создать структуру таблиц по MD и DDS - вызвать реструктуризацию. Самый простой способ её вызвать - добавить новый объект, например, константу, в саму конфигурацию (в режиме конфигуратора), а затем сохранить изменения. Если 1с будет ругаться на отсутствие администратора - надо будет добавить нового пользователя 1С (в конфигураторе) с правами администратора. Это то, что я навскидку помню.
Все это уже относится к особенностям запуска 1С и в тематику форма помещается со скрипом.
Ну а дальше, когда пустые таблицы в новой базе будут готовы, можно будет перелить данные из старых таблиц:
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.
Вот некоторые дополнительные сведения об этой проблеме.
Я использовал в качестве примеров API ReadFile и WriteFile . Это также относится к Точечная диаграмма и сбор сведений о деятельности.
Мы рассмотрели некоторые из этих проблем в последнее время (июль 2003) в системах на базе Compaq и HP на базе смарт-SCSI и HP SANsin дополнение к Intel RAID-контроллеров.
Мы видели эту проблему в SQL Server 2000 Пакет обновления 3 (760) и более поздней версии построения, но видел подобных сценариях до SQL Server 2000 SP3.
SQLIOStress был обновлен для повышения интенсивности в поисках этих условий.
Отдела разработки SQL Server выполняется обновление других служебных программ, чтобы помочь в обнаружении проблем.
Корпорация Майкрософт распространяет исправления Microsoft SQL Server 2008 как один загружаемый файл. Так как исправления являются накопительными, каждый выпуск содержит все исправления и все исправления безопасности, которые были включены в предыдущие 2008 SQL Server исправления выпуска.
Проблемы
Ошибка msg 605, 21 уровень состояние 3, строка 1Attempt для выборки логической страницы (1:225) в базе данных 2. Он принадлежит к 281474980315136 единицы размещения не для 504403158513025024.
Msg 601, уровень 12, состояние 3, процедура procedure имя, номер строкине удалось продолжить просмотр с NOLOCK вследствие перемещения данных.
Запрос конструкцию, которая может приводить к этим ошибкам выглядит следующим образом:
Решение
Исправление этой уязвимости первого выпуска накопительного обновления 3. Дополнительные сведения о том, как получить этот накопительный пакет обновления для SQL Server 2008, щелкните следующий номер статьи базы знаний Майкрософт:
960484 Накопительный пакет обновления 3 для SQL Server 2008Примечание. Поскольку построения являются накопительными, каждый новый выпуск исправление содержит все исправления и все исправления, входившие в состав предыдущих SQL Server 2008 выпуска исправлений. Мы рекомендуем рассмотреть применение последнего выпуска исправления, содержащего это исправление. Дополнительные сведения см. в следующей статье базы знаний Майкрософт:
956909 SQL Server 2008 выполняет построение, выпущенных после выпуска SQL Server 2008После установки этот накопительный пакет обновления, необходимо включить флаг трассировки 4135. Чтобы сделать это, можно добавить -T4135 параметра запуска. Или можно использовать инструкцию dbcc traceon(4135) для конкретного сеанса.
Обходное решение
Чтобы обойти эту проблему, добавьте столбец с кластеризованного первичного ключа и свойство identity во временной таблице. Например выполните следующую инструкцию, чтобы изменить временной таблицы:
Статус
Корпорация Майкрософт подтверждает наличие этой проблемы в своих продуктах, которые перечислены в разделе "Применяется к".
Дополнительная информация
960484 Накопительный пакет обновления 3 для SQL Server 2008
Сведения о SQL Server 2008 R2 анализатора соответствия Рекомендациям
Ссылки
Правило SQL Server 2008 R2 анализатора соответствия Рекомендациям
Примечание. Можно включить флаг трассировки 4135 или флаг трассировки 4199 Включение данного исправления. Флаг трассировки 4135 был представлен в накопительный пакет обновления 3 для SQL Server 2008. Флаг трассировки 4135 доступен также в Пакет обновления 1 для SQL Server 2008, Пакет обновления 2 для SQL Server 2008 и SQL Server 2008 R2. Флаг трассировки 4199 был введен в накопительный пакет обновления 7 для SQL Server 2008, накопительный пакет обновления 7 для SQL Server 2008 Пакет обновления 1 и накопительный пакет обновления 1 для SQL Server 2008 R2. Дополнительные сведения о флаге трассировки 4199 щелкните следующий номер статьи базы знаний Майкрософт:
974006 Флаг трассировки 4199 добавляется к элементу управления, несколько изменений оптимизатор запросов, сделанных в группе несколько флагов трассировки Так как исправление для этой проблемы включает в себя сочетание построения исправления и флага трассировки, чтобы активировать его, предоставляются вместе в следующей таблице показаны различные сценарии и рекомендуемые действия для выполнения для каждого сценария.Дополнительные сведения о последней версии сборок SQL Server щелкните следующий номер статьи базы знаний Майкрософт:
957826 Где найти сведения о последней версии SQL Server формирует
Call stack information
Ссылки
Дополнительные сведения о списке сборок, доступных после выпуска SQL Server 2008 щелкните следующий номер статьи базы знаний Майкрософт:
956909 SQL Server 2008 выполняет построение, выпущенных после выпуска SQL Server 2008Дополнительные сведения о добавочных модель обслуживания для SQL Server щелкните следующий номер статьи базы знаний Майкрософт:
935897 Модель обслуживания изменений, используемая рабочей группой SQL Server, предоставляет модель ISM для распространения исправлений обнаруженных проблемДополнительные сведения о схеме именования для обновления SQL Server щелкните следующий номер статьи базы знаний Майкрософт:
822499Новая схема присвоения имен пакетам обновлений программного обеспечения Microsoft SQL ServerДля получения дополнительных сведений о терминологии обновлений программного обеспечения щелкните следующий номер статьи базы знаний Майкрософт:
824684 Стандартные термины, используемые при описании обновлений программных продуктов Майкрософт
Author (SME): bruceye
Writer: ericzha
Tech Reviewer: bruceye; wcarroll
Editor: v-janhal
Делаю проверку рабочей базы - ошибок не обнаружено.
CHECKDB found 0 allocation errors and 0 consistency errors in database 'Prod_DB'.
Из связи фулл + новый ночной дифф восстановление без ошибок. А вот попробовал добавить сегодняшние логи и опять ошибка, теперь на логе в 9 утра
Msg 824, Level 16, State 2, Line 12
SQL Server обнаружил логическую ошибку ввода-вывода, связанную с согласованностью: неверный идентификатор страницы (ожидаемый 1:3105792; фактический 1:3491112). Она произошла при прочитать страницы (1:3105792) в базе данных с идентификатором 29 по смещению 0x000005ec800000 файла "E:\Data\test1234.mdf". Дополнительные сведения см. в журнале ошибок SQL Server и журнале системных событий. Это серьезная ошибка, которая угрожает целостности базы данных и должна быть немедленно исправлена. Выполните полную проверку базы данных на согласованность (DBCC CHECKDB). Эта ошибка может быть вызвана многими причинами; дополнительные сведения см. в электронной документации по SQL Server.
Спасибо всем за ответы!
Восстановил на продуктиве в новую базу "проблемный" бекап от 04.02.2020, опять падает на логе в промежутке 7-8 утра.
Msg 824, Level 16, State 2, Line 11
SQL Server обнаружил логическую ошибку ввода-вывода, связанную с согласованностью: неверный идентификатор страницы (ожидаемый 1:3105792; фактический 0:0). Она произошла при прочитать страницы (1:3105792) в базе данных с идентификатором 16 по смещению 0x000005ec800000 файла 'G:\Data\Test1234.mdf'. Дополнительные сведения см. в журнале ошибок SQL Server и журнале системных событий. Это серьезная ошибка, которая угрожает целостности базы данных и должна быть немедленно исправлена. Выполните полную проверку базы данных на согласованность (DBCC CHECKDB). Эта ошибка может быть вызвана многими причинами; дополнительные сведения см. в электронной документации по SQL Server.
Вы слишком высокого мнения о людях в желтом, ничего подобного они не пишут.
Если Вам интересно как сервер приложений 1С взаимодействует с базой - запустите Profiler и ознакомьтесь.
Я верю в коллег:)
Как-то привык, что или база нормальная или битая и начинаются танцы с бубнами: починки с потерей данных\восстановление последнего нормального состояния базы с заливкой данных заново\экспорт данных в другую таблицу.
Я уже вообще не понимаю, что творится.
Проверял сегодня ещё раз старые бекапы. Фулл от 02 + дифф от 03. На тесте вчера восстанавливал из этих бекапов и ошибок checkdb не находил. Сегодня из этого же бекапа пробовал на рабочем сервере в новую базу и ошибки были. Восстанавливаю ещё раз на тесте - нормально. Ради проверки восстановил вообще на другой машине с другими дисками - те же ошибки. Проверяю скрипты на тесте и других серверах. Похожие. Пример скрипта:
Либо, как Вам писали - см. работоспособность операционной системы, SQL-сервера, СХД .
Читайте также: