Не могу выбрать базу данных причина ошибки

Что делать при ошибках базы данных MySQL

Здравствуйте!

Сегодняшняя заметка будет касаться только достаточно «узкой» категории читателей блога — речь пойдет о базах данных MySQL (и ошибках, при работе с ними…).

Вообще, подобные базы данных используются многими движками сайтов (CMS), причем некоторые из них не блещут высокой безопасностью… Кроме этого, к базе MySQL возможен прямой доступ через веб-интерфейс. А если добавить к этому ошибки при копировании и переносе БД (что бывает очень часто), то, разумеется, всё это вкупе создает определенные риски для данных… ????

Собственно, ниже рассмотрим, что можно сделать, если появилась-таки ошибка, что база данных недоступна (или не может быть прочитана, или…). Заранее скажу, что подобные ошибки далеко не всегда означает полную утрату БД, во многих случаях удается сравнительно-легко восстановить работоспособность сайта (интернет-магазина, и пр.).

И так…

*

Несколько рекомендаций, если возникла ошибка с MySQL БД

???? Совет 1

Если вы накануне никак не взаимодействовали с БД (например, не переносили сайт с одного сервера на другой), и всё работало в штатном режиме — возможно, что ошибка недоступности к базе связана с возникшими проблемами на стороне хостинг-компании (⇒ запрос в поддержку…).

Кроме этого, обратите внимание на конфигурационные файлы CMS, отвечающие за доступ к базе данных. Возможно, что с самой БД всё в порядке, а вот путь (или пароль) для доступа к ней указан некорректно…

Например, в такой популярной CMS как WordPress, файлом для настройки доступа к БД явл. wp-config.php.

Параметры MySQL — эту информацию можно получить у хостинг-провайдера

*

???? Совет 2

Еще одна довольно очевидная рекомендация — проверить наличие бэкапа (резервной копии). Даже если вы самостоятельно не делали его — возможно его сделал хостинг-провайдер.

Кроме этого, как только возникла какая-то ошибка с БД — я бы порекомендовал в любом случае сделать ее копию (если это возможно). Вдруг диск начал «сыпаться», и в дальнейшем даже текущая БД исчезнет «на совсем»…

PHP My Admin — экспорт базы данных

*

???? Совет 3

Далее следует попробовать провести восстановление БД встроенными средствами MySQL…

Итак, что нужно сделать в случае, если БД MySQL перестала запускаться:

1. Откройте файл my.cnf и установите следующий параметр: innodb_force_recovery = 1;
2. Перезапустите MySQL следующей командой: /etc/init.d/mysql restart;
3. Сделайте дамп БД и запакуйте его: mysqldump db | gzip > db.sql.gz;
4. Создайте новую БД: mysql -e create database «new_DB»;
5. Импортируйте туда данные: zcat database.sql.gz | mysql new_DB.

***

???? Примечание!

my.cnf — это файл конфигурации MySQL. Чтобы найти файл, используйте команду: locate my.cnf

В Linux’e обычно он находится по такому пути:

/etc/my.cnf

# либо

/etc/mysql/my.cnf

***

Перезапуск MySQL подобным образом не ведет к запуску всех связанных процессов и в некоторых случаях позволяет открыть старую БД.

С помощью указанных команд мы пробуем создать дамп БД, затем импортировать его в новую базу, которую далее можно будет открыть обычным способом.

Если это получается, старую БД можно удалить. Кстати, если способ не помогает, и старая база не запускается, нужно пробовать другие значения параметра innodb_force_recovery, вплоть до 6.

MySQL

При нормальном запуске БД система пытается запустить все процессы, включая и те, которые были завершены аварийно (например, из-за проблем с электричеством).

Благодаря опции innodb_force_recovery можно отключить некоторые параметры, которые мешают штатному запуску БД.

Цифры означают следующее:

1. Запуск MySQL не останавливается, даже если система в процессе запуска обнаруживает поврежденные страницы;
2. Отмена запуска фоновых операций;
3. Отмена попыток отката транзакций;
4. Отказ от расчета статистики и использования сохраненных изменений;
5. Не учитывает логи отката при запуске;
6. Не учитывает параметры ib_logfiles во время запуска.

*

???? Совет 4 (альтернативный способ восстановления БД)

Описанный выше способ довольно эффективен, хотя, к сожалению, может оказаться сложным для некоторых пользователей. Но работа с любым форматом базы данных — это всегда непросто…

Если нет желания редактировать конфиги, открывать командную строку и изучать синтаксис нужных команд, то нужен достаточно простой и дружелюбный в использовании инструмент, например, такой как Recovery Toolbox for MySQL. (????)

Recovery Toolbox for MySQL — скриншот главного окна программы

Пожалуй, это самый простой и эффективный способ восстановления БД MySQL, именно то, что нужно большинству начинающих пользователей. ????

Вариантов, собственно, немного — разобраться со всем самому, потратив несколько дней, или в течение часа восстановить базу данных, продолжить работу и избежать убытков.

Стоит сразу отметить, что Recovery Toolbox for MySQL работает только с копией базы, поэтому никогда не испортит то, что осталось от старой БД. Почувствуйте разницу, копаясь в конфигах и настройках «боевого» сервера, и каждую минуту опасаясь сделать что-то неправильно, что приведет к полному уничтожению того, что еще осталось…

*

???? Как восстановить базу с помощью Recovery Toolbox for MySQL:

Для восстановления поврежденной БД MySQL при помощи этой программы нужно сделать следующее:

1. Скачать Recovery Toolbox for MySQL с офиц. сайта: https://mysql.recoverytoolbox.com/ru/;
2. Установить и запустить программу;
3. Выбрать папку, в которой хранятся файлы поврежденной базы данных MySQL (предварительно создайте копию);
4. Выбрать поврежденную базу данных из списка
5. Запустить анализ выбранной БД;
6. Просмотреть результаты восстановления: таблицы, объекты, индексы;
7. Настроить способ сохранения восстановленных данных;
8. Сохранить данные (доступно в полной версии). Пример на скриншоте ниже. ????

Пример восстановления БД

Программа загружается совершенно бесплатно и устанавливается без регистрации. С помощью Recovery Toolbox for MySQL можно бесплатно просматривать восстановленные данные, оценивать эффективность работы.

Можно даже подсмотреть какие-то изменения и легко внести их руками в «протухший», но еще пригодный к использованию бэкап. Заплатить предложат только в том случае, если потребуется сохранить восстановленные данные, пересоздать базу MySQL и подключить ее к системе.

База восстановлена — сохранить?

*

???? «Пару слов» о безопасности при работе с Recovery Toolbox for MySQL

Самое главное — программа всегда работает только с копией исходной базы, поэтому этот способ восстановления намного надежнее, чем вносить изменения в конфиги БД и смотреть, что из этого получится. Помните, попытка ремонта БД на «продакшн» сервере может окончательно добить ее, такое бывает даже у опытных админов…

Также стоит отметить, что Recovery Toolbox for MySQL не использует сторонние подключения. В процессе восстановления (может занять довольно продолжительное время, в зависимости от размеров исходной базы данных) ПО не использует доступ к Интернет.

Проконтролировать отсутствие подозрительных подключений можно разными способами, самым простым из которых является физическое отключение сетевого кабеля.

Есть способ чуть сложнее: установить анализатор сетевого траффика (советую WireShark, NetLimiter) и проверить, не идут ли подозрительные пакеты от Recovery Toolbox for MySQL.

???? В помощь!

Как запретить программе доступ к интернету (блокировка входящего/исходящего трафика)

Конечно, этот способ предполагает некий здоровый энтузиазм, желание познать новое (мануалы на WireShark совсем немаленькие) и, самое главное, наличие свободного времени…

*

Дополнения по теме — не помешают!

Всем успехов!

????

Пост по заметкам

от компании Recovery Toolbox

Полезный софт:

• Видео-Монтаж

• Отличное ПО для создания своих первых видеороликов (все действия идут по шагам!).

  Видео сделает даже новичок!

• Ускоритель компьютера

• Программа для очистки Windows от «мусора» (удаляет временные файлы, ускоряет систему, оптимизирует реестр).

Источник

Устранение ошибок единообразия баз данных, о них сообщила проверка DBCC

• 09/25/2020
• Чтение занимает 5 мин

В этой статье

В этой статье вводится, как устранять ошибки, о них сообщает команда DBCC CHECKDB.

Исходная версия продукта: SQL Server

Исходный номер КБ: 2015748

Симптомы

При выполнении DBCC CHECKDB (или других аналогичных команд, таких как CHECKTABLE) в SQL Server ERRORLOG:

Дата и время spid53 DBCC CHECKDB (mydb), выполненные MYDOMAINtheuser, обнаружили 15 ошибок и восстановлены. Время: 0 часов 0 минут 0 секунд. Моментальный снимок внутренней базы данных имеет разделенную точку LSN = 00000026:0000089d:0001 и первое LSN = 00000026:0000089c:0001. Это только информационное сообщение. Никаких действий пользователя не требуется.

В этом сообщении показано, сколько ошибок единообразия базы данных было найдено и сколько было восстановлено (если с командой использовался параметр восстановления). Это сообщение также записи в журнал событий приложений Windows в качестве сообщения уровня информации с eventID=8957 (даже если сообщение об ошибках сообщается как сообщение информационного уровня).

Информация в сообщении начинается со слова «внутренний снимок базы данных…». Отображается только в том случае, если база данных DBCC CHECKDB была в сети, в которой база данных не находится в _USER режиме. Это необходимо, потому что для сетевой базы данных DBCC CHECKDB внутренний снимок базы данных используется для создания согласованного набора данных для проверки.

В этой статье не будет рассмотрено, как устранить каждую конкретную ошибку, сообщаемую DBCC CHECKDB, а общий подход в случае сообщений об ошибках. Любая ссылка на CHECKDB в этой статье также применима и DBCC CHECKTABLE CHECKFILEGROUP не заявима.

Причина

DBCC CHECKDB проверяет физическую и логическую согласованность страниц базы данных, строк, страниц выделения, связей индексов, целостности системной таблицы и других проверок структуры. Если какие-либо из этих проверок не будут с ошибками (в зависимости от выбранных параметров), в команде будут выявиться ошибки.

Причины этих проблем могут отличаться в зависимости от повреждения файловой системы, связанных с аппаратным обеспечением, проблем с драйверами, поврежденных страниц в памяти или проблем с SQL Server Engine. Дополнительные сведения о том, как найти причину сообщений об ошибках, можно найти в разделе «Решение».

Решение

Первое, лучшее решение, если DBCC CHECKDB сообщает об ошибках согласованности, — это восстановление из известной хорошей резервной копии. Однако если восстановление из резервной копии невозможно, функция CHECKDB предоставляет функцию для устранения ошибок. Если проблемы системного уровня, такие как файловая система или оборудование, могут быть причиной этих проблем, рекомендуется сначала исправить их перед восстановлением или запуском восстановления.

При запуске DBCC CHECKDB предоставляется рекомендация, которая указывает минимальный параметр восстановления, необходимый для устранения всех ошибок. Эти сообщения могут выглядеть следующим образом:

CHECKDB обнаружил 0 ошибок выделения и 15 ошибок согласованности в базе данных «mydb».

repair_allow_data_loss это минимальный уровень восстановления ошибок, найденных в DBCC CHECKDB (mydb).

Рекомендация по восстановлению — это минимальный уровень восстановления для устранения всех ошибок в CHECKDB. Это не означает, что этот параметр восстановления фактически исправит все ошибки. Кроме того, не для всех сообщений об ошибках может потребоваться этот уровень восстановления для устранения ошибки. Это означает, что не все ошибки, о которые сообщает CHECKDB, когда это repair_allow_data_loss рекомендуется, будут привести к потере данных. Необходимо выполнить восстановление, чтобы определить, приведет ли разрешение ошибки к потере данных. Один из способов сузить уровень восстановления для каждой таблицы — использовать DBCC CHECKTABLE для любой таблицы, сообщая об ошибке. Здесь будет отдано минимальное количество восстановлений для заданной таблицы.

Чтобы найти причину возникновения ошибок согласованности базы данных, рассмотрите указанные здесь методы.

• Проверьте журнал системных событий Windows на все системные ошибки, связанные с драйвером или диском.
• Проверьте целостность файловой системы с помощью chkdsk.
• Запустите диагностику, предоставляемую изготовителями оборудования для компьютера и/или дисковой системы.
• Работайте с поставщиком оборудования или изготовителем устройства, чтобы обеспечить:
  • Аппаратные устройства и конфигурация подтверждают требования к Microsoft SQL Server ввода и вывода яда баз данных.
  • Обновляются драйверы устройств и другие вспомогательные программные компоненты всех устройств в пути к I/O
• Рассмотрите возможность использования такой совмести, как SQLIOSim, на том же диске, что и базы данных, которые сообщили об ошибках согласованности. SQLIOSim — это средство, независимое от SQL Server Engine, для проверки целостности I/O для дисковой системы. SQLIOSim SQL Server 2008 и не требует отдельной загрузки.
• Проверьте все другие ошибки, о SQL Server таких как нарушения доступа или утверждения.
• Убедитесь, что в базах данных используется PAGE_VERIFY CHECKSUM этот параметр. Если сообщается об ошибках контрольных контрольных объемов, это индикаторы того, что ошибки согласованности произошли после того, как SQL Server на диск записаны страницы, чтобы дисковая система была тщательно проверена, дополнительные сведения об ошибках контрольных объемов см. в подсистеме устранения неполадок Msg 824 в SQL Server.
• Найди ошибки Msg 832 в ERRORLOG. Это индикаторы того, что страницы могут быть повреждены, пока они находятся в кэше, прежде чем они будут записаны на диск. Дополнительные сведения см. в SQL Server msg 832.
• Попробуйте восстановить «чистую» резервную копию базы данных (без ошибок из CHECKDB) и резервные копии журнала транзакций, которые охватывают время, когда произошла ошибка. Если вы можете «повторить» эту проблему, восстановив «чистую» резервную копию базы данных и журналы транзакций, обратитесь за помощью в службу технической поддержки Майкрософт.
• Ошибки , которые могут быть проблемой при вставке приложения или обновлении недопустимых данных в таблицы SQL Server данных. Дополнительные сведения об устранении неполадок, которые могут быть допущены при утечке данных, см. в подсети DBCC Error 2570 в SQL Server 2005.

Дополнительная информация

Подробные сведения о синтаксисе DBCC CHECKDB и сведения/параметры выполнения команды см. в DBCC CHECKDB (Transact-SQL).

При обнаружении ошибок с помощью CHECKDB дополнительные сообщения, такие как следующие, будут отобралены в ERRORLOG для создания отчетов об ошибках:

/ spid53 Using ‘dbghelp.dll’ version ‘4.0.5’

/ spid53 **Dump thread — spid = 0, EC = 0x00000000855F5EB0

/ spid53 **_Stack Dump being sent toFilePathFileName

/ spid53 _ *

/ spid53 *

Дата и время spid53 * BEGIN STACK DUMP:

/ spid53 * /spid 53

/ spid53 *

/ spid53 * DBCC database corruption

/spid53 *

/ spid53 * Input Buffer 84 bytes —

/ spid53 * dbcc checkdb(mydb)

/ spid53 *

/ spid53 * **

Дата и время spid53 * ——————————————————————————-

/ spid53 * Short Stack Dump

/ spid53 Stack ature for the dump is 0x00000000000001E8

Код возврата процесса внешнего дампа spid53 даты и времени 0x20002001.

Сведения об ошибке были отправлены в отчет об ошибках Watson.

Файлы, используемые для отчетов об ошибках, включают <nnn> TXT-файл SQLDump. Этот файл может быть полезен для исторических целей, так как содержит список ошибок, найденных в CHECKDB в формате XML.

Чтобы узнать, когда DBCC CHECKDB в последний раз запускался без ошибок, обнаруженных для базы данных (последняя известная очистка CHECKDB), проверьте в журнале SQL Server ERRORLOG следующее сообщение для базы данных или системной базы данных (это сообщение записано как сообщение уровня информации в журнале событий приложений Windows с eventID = 17573):

/ spid7s CHECKDB for database ‘master’ finished without errors on/22:11:11.417 (local ). Это только информационное сообщение; никаких действий пользователя не требуется

Источник