база данных ок повреждена что это значит
Help, my database is corrupt. Now what?
Поврежденная база данных — это, наверное, один из худших ночных кошмаров большинства администраторов баз данных. Результатом повреждения являются простои, вопли менеджеров и всякие другие неприятные штуки.
В этой статье я объясню что нельзя делать с поврежденной базой данных и опишу кое-что из того, что должно быть сделано, некоторые виды повреждений и как их можно исправить.
Как обнаружить, что база данных повреждена
SQL Server detected a logical consistency-based I/O error: incorrect checksum (expected: 0xfdff74c9; actual: 0xfdff74cb). It occurred during a read of page (1:69965) in database ID 13 at offset 0x0000002229a000 in file ‘D:\Develop\Databases\Broken1.mdf’.
Attempt to fetch logical page 1:69965 in database 13 failed. It belongs to allocation unit 72057594049069056 not to 281474980642816.
Основная проблема заключается в том, что если проверки целостности базы данных не производятся на постоянной основе, то повреждение может быть обнаружено спустя часы, дни и даже месяцы, после того, как оно образовалось, в тот момент, когда уже сложно будет что-то исправить.
Я не буду описывать ситуацию когда база данных перешла в состояние «suspect» («подозрительная» в русской редакции SQL Server — прим. переводчика). Описание всевозможных причин почему база данных может перейти в «suspect» и множества вариантов исправления этого — тема отдельной статьи, если не книги.
Что делать если база данных все-таки повреждена
Не паниковать
Самое важное, при обнаружении повреждения БД — это не паниковать. Любые принимаемые решения должны быть тщательно взвешаны, во внимание должны быть приняты все возможные факторы. Чертовски просто ухудшить ситуацию приняв не до конца обдуманное решение.
Не отсоединять базу данных
В большинстве случаев, когда SQL Server обнарживает повреждение базы данных, это означает, что в БД на самом деле есть поврежденные страницы. Попытка убедить SQL Server что это не так, путем отсоединения (detach) и повторного присоединения (attach) БД, бэкапа и последующего восстановления, перезапуска службы SQL Server, либо перезагрузки сервера, не приведет к тому, что ошибка исчезнет.
Если база данных повреждена и SQL Server обнаружит это при присоединении, он не сможет присоединить ее. Есть несколько способов заставить его увидеть эту БД, но намного лучше просто не отсоединять ее.
Не перезапускать SQL Server
Точно так же, как при отсоединении-присоединении, перезапуск службы SQL Server не сможет исправить обнаруженные ошибки (если они есть).
Перезапуск службы может сделать ситуацию хуже. Если SQL Server обнаружит ошибки во время выполнения фазы восстановления (recovery) БД после перезапуска, он пометит ее как «suspect», что сильно усложнит процесс восстановления БД.
Не начинать восстановление сразу
У вас может возникнуть соблазн просто запустить DBCC CHECKDB с одним из «восстановительных» параметров (обычно допускающими потерю данных) и надеяться, что все станет лучше (по моему опыту — первое что рекомендуют на «непрофильных» форумах по SQL Server — запустить DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS — прим. переводчика). Во многих случаях запуск такого восстановления не рекомендуется. Он не гарантирует исправления всех ошибок и может привести к недопустимой потере данных.
Такое восстановление — это последний шаг при исправлении ошибок. Оно должно быть запущено только если у вас уже нет другого выбора, но никак не в первую очередь.
Запустить проверку целостности
Для того чтобы решить как исправить базу данных, мы точно должны знать что именно повреждено. Единственный способ, которым мы можем это выяснить — запустить DBCC CHECKDB с параметром All_ErrorMsgs (в SQL Server 2005 SP3, SQL Server 2008 SP1 и в более старших версиях, этот параметр включен по умолчанию, указывать его не обязательно). Помните, что если вы запустите DBCC CHECKDB без параметра No_InfoMsgs, в выводе этой процедуры будет информация о количестве строк и страниц в каждой таблице, что вряд ли будет вас интересовать при анализе ошибок.
DBCC CHECKDB может долго выполняться на больших БД, но необходимо дождаться пока эта процедура не закончит работу. Грамотная стратегия восстановления может быть построена только при наличии информации обо всех проблемах в БД.
Найти причину
После того как ошибки исправлены, работу нельзя считать законченной. Если причина этих ошибок не установлена, они могут возникнуть снова. Обычно, основной причиной ошибок являются проблемы с подсистемой ввода-вывода, но они также могут быть вызваны неправильной работой «низкоуровнего ПО» (вроде антивируса), действиями человека, либо багами самого SQL Server.
Что дальше
Дальнейшие действия по исправлению ошибок целиком и полностью зависят от результатов выполнения CheckDB. Чуть дальше я покажу несколько наиболее часто возникающих ошибок (учтите, что эта статья не претендует на звание полного описания всевозможных ошибок).
Описанные ошибки располагаются по возрастанию уровня серьезности — от наименее серьезных к наиболее серьезным. В общем-то, для наиболее серьезных ошибок, находимых CheckDB, есть описание доступных методов их резрешения.
Если у вас вдруг обнаружится ошибка не описанная в статье, обратите внимание на последний раздел — «Поиск помощи».
Неверная информация о свободном месте на странице
Msg 2508, Level 16, State 3, Line 1
The In-row data RSVD page count for object «Broken1», index ID 0, partition ID 76911687695381, alloc unit ID 76911687695381 (type In-row data) is incorrect. Run DBCC UPDATEUSAGE.
Msg 8914, Level 16, State 1, Line 1
Incorrect PFS free space information for page (1:26839) in object ID 181575685, index ID 1, partition ID 293374720802816, alloc unit ID 76911687695381 (type LOB data). Expected value 0_PCT_FULL, actual value 100_PCT_FULL.
Эта ошибка появляется, когда PFS-страница (Page Free Space), которая учитывает насколько заполнены страницы в БД, содержит некорректные значения. Эта ошибка, как и упомянутая ранее, не является серьезной. Алгоритм, по которому определялось насколько заполнены страницы, в SQL Server 2000 не всегда отрабатывал правильно. Для решения этой проблемы нужно запустить DBCC CHECKDB с параметром REPAIR_ALLOW_DATA_LOSS и, если это единственная ошибка в БД, никакие данные, на самом деле, не пострадают.
Повреждение только некластерных индексов
Msg 8941, Level 16, State 1, Line 1
Table error: Object ID 181575685, index ID 4, page (3:224866). Test (sorted [i].offset >= PAGEHEADSIZE) failed. Slot 159, offset 0x1 is invalid.
Msg 8942, Level 16, State 1, Line 1
Table error: Object ID 181575685, index ID 4, page (3:224866). Test (sorted[i].offset >= max) failed. Slot 0, offset 0x9f overlaps with the prior row.
В этом случае, повреждение может быть полностью исправлено удалением поврежденных некластерных индексов и повторным их созданием. Перестроение индекса (ALTER INDEX REBUILD) в режиме on-line (и иногда в off-line) читает страницы старого индекса для создания нового и, следовательно, завершится с ошибкой. Поэтому, необходимо удалить старые индексы и создать их заново.
Именно это сделает DBCC CHECKDB с параметром REPAIR_REBUILD, но база данных при этом должна быть в однопользовательском режиме. Вот почему обычно лучше вручную выполнить эти операции, чтобы с базой данных можно было продолжать работать, пока индексы будут пересоздаваться.
Если у вас недостаточно времени на то, чтобы пересоздать нужные индексы и в наличии есть «чистый» (не содержащий в себе ошибок) полный бэкап и бэкапы журнала транзакций с неразорванной цепочкой журналов, вы можете восстановить поврежденные страницы из них.
Повреждение LOB-страниц
Msg 8964, Level 16, State 1, Line 1
Table error: Object ID 181575685, index ID 1, partition ID 72057594145669120, alloc unit ID 72057594087800832 (type LOB data). The off-row data node at page (1:2444050), slot 0, text ID 901891555328 is not referenced.
Ошибка говорит о том, что существуют LOB-страницы (Large OBject), на которые не ссылается ни одна страница с данными. Такое может произойти, если ранее был поврежден кластерный индекс (или куча) и его поврежденные страницы были удалены.
Если CheckDB говорит только о таких ошибках, то можно запускать DBCC CHECKDB с параметром REPAIR_ALLOW_DATA_LOSS — эти страницы будут уничтожены. Поскольку у вас все равно нет страниц с данными, которые ссылаются на эти страницы, бОльшей потери данных уже не будет.
Ошибки, связанные с выходом за пределы допустимого диапазона
Msg 2570, Sev 16, State 3, Line 17
Page (1:1103587), slot 24 in object ID 34, index ID 1, partition ID 281474978938880, alloc unit ID 281474978938880 (type «In-row data»). Column «modified» value is out of range for data type «datetime». Update column to a legal value.
Эти ошибки показывают, что в столбце есть значения выходящие за пределы допустимого диапазона. Это может быть значение типа datetime, предполагающее, что с полуночи прошло больше 1440 минут, строка-Unicode, в которой количество байт не делится на 2, или float/real с неверным значением точности.
Проверка на эти ошибки не выполняется по умолчанию, для баз данных обновленных с версии SQL Server 2000 или более ранних, если перед этим ни разу не выполнялась команда DBCC CHECKDB со включенным параметром DATA_PURITY.
CheckDB не сможет исправить эти ошибки, поскольку неизвестно какие значения поставить взамен неправильных. Исправление таких ошибок не требует особых усилий, но выполняется вручную. Неправильные значения должны быть заменены на что-нибудь приемлимое. Основная проблема — это поиск неверных значений. В этой статье базы знаний есть пошаговая инструкция.
Повреждение кластерного индекса или кучи
Server: Msg 8976, Level 16, State 1, Line 2
Table error: Object ID 181575685, index ID 1, partition ID 76911687695381, alloc unit ID 76911687695381 (type In-row data). Page (1:22417) was not seen in the scan although its parent (1:479) and previous (1:715544) refer to it.
Server: Msg 8939, Level 16, State 1, Line 2
Table error: Object ID 181575685, index ID 0, page (1:168576). Test (m_freeData >= PAGEHEADSIZE && m_freeData
Не работают Одноклассники: как восстановить приложение?
На данный момент приложением Одноклассники пользуется больше 100 миллионов человек. Его популярность связана с мобильностью и удобством. Вам больше не нужно иметь под рукой стационарный компьютер, чтобы пообщаться с другом, проверить новостную ленту или загрузить фотографии. Все действия можно выполнять из любого уголка планеты при наличии интернета и телефона или планшета. Но даже в программе иногда бывают сбои. Пользователи могут столкнуться с приостановкой работы софта. Как поступить в этом случае? Как можно восстановить приложение Одноклассники? Расскажем ниже.
Частые ошибки и проблемы с приложением Одноклассники
Рассмотрим часто возникающие ошибки с мобильным софтом ОК и расскажем, что с ними делать:
«Приложение ОК приостановлено», что это значит и что делать?
С этой ошибкой чаще всего сталкиваются владельцы устройств на базе Андроид (более подробно о приложении Одноклассники на Андроид читай по ссылке). Почему приложение ОК приостановлено?
Прежде чем прибегать к последнему способу устранения ошибки убедитесь, что причина сбоя идет не со стороны Одноклассников. Возможно, на платформе проводятся технические работы.
Заключение
В большинстве возникающих ситуаций с приложением Одноклассники можно справиться, перезагрузив или переустановив его. Если проблемы возникают часто, то стоит проверить работоспособность самого устройства.
Как использовать Одноклассники с ПК? Устанавливаем приложение
Приложение Одноклассники на Айфон: где скачать и бесплатно установить?
Существует ли бесплатное приложение Одноклассники на ноутбук
Не работает Ютуб на ПК. Исправляем ситуацию
Ошибка «К сожалению, чат больше недоступен Telegram»: что делать?
Причины повреждения базы данных
Самый ценный актив любого бизнеса это информация накопленная за весь период его существования, к которой относятся данные клиентов, контактные данные, таблицы заказов, каталоги товаров, служебная переписка, контент и многое другое. При чем не важно, онлайн или оффлайн работает сам бизнес, в любом случае как правило, вся информация хранится в цифровой базе данных. И каким бы это странным не казалось, и не очевидным для многих менеджеров и управляющих компанией, потерять весь бизнес можно в оно мгновение — потерять информацию, что хранится в базе данных.
Установлено, что большинство предприятий, переживших крупную необратимую потерю корпоративных данных, прекращают свое существование в течение трех лет после такого инцидента. Мысль о возможной катастрофе неприятна для ИТ- и бизнес-менеджеров, поэтому они часто не принимают серьезных предупредительных мер.
Люди разделяются на две категории, тех кто не делает бекап и тех кто уже делает.
По этому стоит заранее позаботиться о резервном копировании всей важной информации, более того желательно иметь дублирующую резервную копию, на случай если первая также будет утеряна. Как показывает практика, бывает и такое. Помимо этого, периодически следует проводить восстановление(restore) данных из резервной копии на тестовый сервер чтобы убедиться, что резервная копия в порядке и данные из нее восстанавливаются нормально. Бывали случае когда система резервного копирования работала, но сохраняла не все данные, что разумеется стало известным только тогда, когда эти самые данные понадобились. Всегда делайте бекап, а лучше два!
Причины повреждения базы данных
После того как становится известно о том, что база данных повреждена, в первую очередь возникает вопрос, как такое могло произойти? Что послужило причиной повреждения базы данных? Причин по которым это может произойти, несколько.
1) Отключение питания сервера. Одна из самым часто встречающихся причин, даже с использованием источников бесперебойного питания (UPS, RAID-контроллеры с аккумуляторами), нет стопроцентной гарантии бесперебойной работы сервера.
2) Дефекты оборудования.
Память — в случае использования не качественной памяти RAM, возможно повреждение данных хранящихся в ней, и как следствие запись таких данных в базу. Факт порчи данных обнаруживается только при следующей попытки считать их.
Диски — аналогичная ситуация может произойти с жестким диском, не смотря на то, что современное серверное оборудование очень качественное и имеет встроенные механизмы предотвращения порчи данных, а также автоматическое восстановления их, потеря данных все же не исключена. Еще одной причиной потери данных являться отсутствие свободного места на жестком диске. Если не следить за работой сервера, за всеми его показателями и ресурсами, может произойти совершенно всё, в том числе и отсутствие свободного места на жестком диске и как следствие отсутствие возможности записать данные, или прерванная запись данных с повреждением текущих и потеря новых.
Контроллеры — в случае сбоя в их работе возможны различные непредвиденные последствия, включая запись данных не туда, куда следовало бы, и как следствие повреждение или потеря их.
3) Сбой программного обеспечения. Потеря или порча данных также может возникать из-за сбоев в работе или ошибок в программном обеспечении, причем не только в том которое работает напрямую с бузой данных, но и в любом другом ПО установленном на сервере. Бывали случае когда стороннее программное обеспечение, повреждало файлы базы данных. По этой причине, следует всегда использовать самую последнюю актуальную версию ПО.
4) Повреждение индексов и таблиц базы данных. Данное обстоятельство может привести к повреждению всей базы данных и потери её содержимого. Причины повреждения самих же индексов и таблиц аналогичны описанным в предыдущих пунктах.
5) Человеческий фактор. Еще одна очень важная причина потери данных, это вмешательство в работу системы не квалифицированного сотрудника, или попытка самостоятельно изменить конфигурацию оборудования и программного обеспечения, не имея определенных знаний. Также возможны действия со стороны пользователя, такие как удаление файлов, выключение или перезагрузка служб и сервизов операционной системы и так далее.
Выводы.
Если ваш бизнес зависит от информации хранящейся на сервере, в базе данных, то следует заблаговременно позаботиться о их резервном копировании. Также следует периодически отслеживать показатели ресурсов сервера и прочего оборудования, которое может повлиять на его работу. Своевременно производить обновление программного обеспечения, а также пользоваться услугами квалифицированных специалистов.
База данных повреждена без всяких веских причин 🙁
База данных повреждена без всяких веских причин 🙁
Сообщение Andres_2003 » 14 янв 2011, 23:45
Re: База данных повреждена без всяких веских причин 🙁
Сообщение Andres_2003 » 15 янв 2011, 00:05
Re: База данных повреждена без всяких веских причин 🙁
Сообщение Andres_2003 » 15 янв 2011, 08:12
Re: База данных повреждена без всяких веских причин 🙁
Сообщение Andres_2003 » 15 янв 2011, 09:14
Re: База данных повреждена без всяких веских причин 🙁
Сообщение Andres_2003 » 15 янв 2011, 09:27
Re: База данных повреждена без всяких веских причин 🙁
Сообщение Andres_2003 » 15 янв 2011, 12:29
Re: База данных повреждена без всяких веских причин 🙁
Сообщение Keepsoft » 15 янв 2011, 13:42
Вам не показалось. При разработке 5 версии «Домашней бухгалтерии» большое внимание было уделено оптимизации работы программы и ускорению ее загрузки и работы. Увеличение скорости работы 5 версии «Домашней бухгалтерии» особенно ощутимо, если база данных содержит много записей. Например, на базе данных, содержащей порядка 20 тысяч записей, скорость загрузки программы увеличилась в 5 раз, а скорость переиндексации базы данных увеличилась в 25 раз. Теперь увеличение размера базы данных практически никак не влияет на скорость загрузки программы.
Re: База данных повреждена без всяких веских причин 🙁
Сообщение Andres_2003 » 15 янв 2011, 15:34
Re: База данных повреждена без всяких веских причин 🙁
Сообщение Keepsoft » 15 янв 2011, 16:34
Re: База данных повреждена без всяких веских причин 🙁
Сообщение Andres_2003 » 15 янв 2011, 17:35
Что делать если поврежден файл базы данных 1С 8.3?
Как говорил один политический деятель (ныне покойный): «Никогда ничего подобного не было – и вот опять!». Скакнуло напряжение – и появилось сообщение о том, что файл базы данных 1Cv8.1CD – обычное дело для БД 8.3, 8.2. «1С» пишет, что база повреждена, что делать в такой ситуации? Ниже приведены несколько вариантов действий для восстановления данных в платформе «1С:Предприятие» из серии «Пока ждем админа».
Восстанавливаем из бэкапа файл базы данных 1С
Если вы читали наши материалы об администрировании «1С:Бухгалтерии 8.3» и в частности о создании бэкапов, то резервное копирование настроено у вас правильно и под руками имеется соответствующий файл. В таком случае если повреждена база 1с 8.3 что делать понятно: просто восстановить ИБ.
Создаем пустую БД, выгружаем в нее бэкап и открываем ее в режиме конфигуратора.
Далее выбираем раздел «Администрирование» в главном меню и даем команду «Загрузить информационную базу».
Когда откроется окно, следует указать путь к самой свежей по дате резервной копии и дать команду «Открыть». Система отреагирует соответствующим образом, сообщив о том, что по загрузке конфигуратор будет закрыт, а несохраненные данные в открытых окнах будут утрачены. Это не должно нас пугать, поскольку мы копируем бэкап пустую базу. Смело соглашаемся, нажав «Да».
После завершения выгрузки ИБ и закрытия режима конфигуратора произойдет запуск «1С:Предприятие 8.3» в режиме пользователя.
Чистим кэш базы данных 1С
Банальный, но действенный способ, особенно когда у одного пользователя все «ОК», зато у другого отображается «роковая» ошибка. Вообще кэш надо чистить регулярно, чисткой кэша «лечатся» и ошибки конфигурации, и программные, и аппаратные проблемы. Реализовать это можно тремя способами – вручную, путем удаления базы, параметром ClearCache, спецутилитами, но для рядового пользователя второй способ проще.
Находим файл ИБ – это просто установить по пути, который отображается, если выбрать нужную нам базу, закрыть «1С», скопировать файл.
Создав новую папку, добавляем туда скопированный файл:
В окно запуска добавляем новую базу:
Поскольку в новом каталоге кэша уже не будет, то база запустится нормально. Или, что тоже не исключено, снова вылезает роковое сообщение о том, что база 1С повреждена что делать?
Встроенное средство восстановления файла базы данных 1С
Внимание: при системном подключении все пользователи должны покинуть систему, в противном случае снова появится сообщение о неполадках. Далее отыскиваем полезный инструмент, спецутилиту chdbfl.exe, которая, как правило, располагается:
Открываем утилиту, указываем ей путь к поврежденной базе данных, выставляем галочку, давая команду «Исправлять обнаруженные ошибки». Нажимаем «Выполнить».
Если проверка выявит список исправлений, то они будут выведены на экран. Впрочем, база данных будет восстановлена и тогда, если ошибок не будет выявлено.
Также помогает решить проблему перезапуск SQL-сервера, при котором перезапишутся все временные документы, но этот способ все-таки можно рекомендовать лишь самым опытным пользователям. Если вы видите сообщения наподобие того, что имеет место ошибка выделения памяти, то имеет смысл все-таки вызвать специалиста, аттестованного «1С».