Dump sql: Дамп MySQL базы данных • Сам себе администратор
Дамп MySQL базы данных • Сам себе администратор
Несколько полезных приемов, которые позволят вам значительно ускорить работу с резервным копированием и восстановлением баз данных. Конечно дамп MySQL можно делать и с помощью стороннего ПО, того же phpMyAdmin, но встроенными утилитами самого сервера БД это удобнее и быстрее.
Делаем резервную копию (он же дамп, он же бекап)
Все данные одной базы
mysqldump -u USER -pPASSWORD DATABASE > dumpname.sql
mysqldump -u USER -pPASSWORD DATABASE > dumpname.sql |
USER
– логин пользователя, PASSWORD
– пароль. Обратите внимание, что между -p
и PASSWORD
нет пробела.
Все данные нескольких определенных баз
Добавляем параметр --databases
или -B
mysqldump -u USER -pPASSWORD —databases DATABASE1 DATABASE2 DATABASE3 … > dumpname.sql
mysqldump -u USER -pPASSWORD —databases DATABASE1 DATABASE2 DATABASE3 . .. > dumpname.sql |
USER
– логин пользователя, PASSWORD
– пароль. Обратите внимание, что между -p
и PASSWORD
нет пробела.
Данные всех баз
Указываем ключ --all-databases
или -A
.
mysqldump -u USER -pPASSWORD —all-databases > dumpname.sql
mysqldump -u USER -pPASSWORD —all-databases > dumpname.sql |
USER
– логин пользователя, PASSWORD
– пароль. Обратите внимание, что между -p
и PASSWORD
нет пробела.
Дамп только структуры базы данных MySQL
За это это отвечает параметр --no-data
или -d
.
mysqldump —no-data -u USER -pPASSWORD DATABASE > dumpstruct.sql
mysqldump —no-data -u USER -pPASSWORD DATABASE > dumpstruct.sql |
Дамп определенных таблиц
mysqldump -u USER -pPASSWORD DATABASE TABLENAME1 TABLENAME2 . . > dumpstruct.sql
mysqldump -u USER -pPASSWORD DATABASE TABLENAME1 TABLENAME2 .. > dumpstruct.sql |
Сразу архивируем дамп MySQL
mysqldump -u USER -pPASSWORD DATABASE | gzip > dumpname.sql.gz
mysqldump -u USER -pPASSWORD DATABASE | gzip > dumpname.sql.gz |
Добавляем дату и время к дампу
mysqldump -u USER -pPASSWORD DATABASE | gzip > `date +dumpname.%Y%m%d_%H%M%S.sql.gz`
mysqldump -u USER -pPASSWORD DATABASE | gzip > `date +dumpname.%Y%m%d_%H%M%S.sql.gz` |
Восстанавливаем дамп MySQL
Заливаем все данные
mysql -u USER -pPASSWORD < dumpname.sql
mysql -u USER -pPASSWORD < dumpname.sql |
Заливаем данные в конкретную базу
mysql -u USER -pPASSWORD DATABASE < dumpname. sql
mysql -u USER -pPASSWORD DATABASE < dumpname.sql |
Заливаем данные из заархивированного дампа
gunzip < dumpfile.sql.gz | mysql -u USER -pPASSWORD DATABASE
gunzip < dumpfile.sql.gz | mysql -u USER -pPASSWORD DATABASE |
Распространенные ошибки, возникающие при создании дампа MySQL
Error 2013: Lost connection to MySQL server during query …
Error 2013: Lost connection to MySQL server during query … |
Ошибка связана с тем, что не хватает времени для выполнения операции. Для исправления в конфигурационном файле /etc/my.cnf в секции [mysqldump] увеличьте значение параметров wait_timeout=600
и interactive_timeout=600
. Значение времени подберите под ваши условия.
Error 2020: Got packet bigger than ‘max_allowed_packet’ bytes when dumping table . ..
Error 2020: Got packet bigger than ‘max_allowed_packet’ bytes when dumping table … |
Ошибка связана с тем, что объем вносимых данных превышает разрешенный. Решается 2-я способами:
- добавить параметр
--max_allowed_packet=128M
к нашим командам - Добавить параметр
max_allowed_packet=128M
в секцию [mysqldump] конфигурационного файла /etc/my.cnf
Соответственно, размер данных указываем тот, который нам необходим.
Error 2006: MySQL server has gone away
Error 2006: MySQL server has gone away |
Данная ошибка может быть связана, как с недостаточным значение параметра wait_timeout
, так и с маленьким размером max_allowed_packet
. Решения собственно уже приведены.
Читайте также
Что такое дамп базы данных и как его создать – База знаний Timeweb Community
Перенос сайта с одного сервера на другой может оказаться непростой задачей для многих пользователей. Это связано с тем, что, помимо обычного перемещения файлов, необходимо также выполнить экспорт и импорт базы данных. В таких случаях используется специальный файл под названием дамп. Поговорим в сегодняшней статье, что это такое и как его сделать.
Что такое дамп базы данных
Дамп (англ. dump – сбрасывать) – файл, включающий в себя содержимое памяти компьютера или базы данных. В нашем случае это файл с расширением .sql. Он содержит особые данные, благодаря которым можно легко воссоздать копию БД.
Копирование базы данных может быть полезно, когда нужно выполнить:
- Перенос данных на другой хостинг. Не нужно повторно создавать БД и вносить в нее все данные руками. Достаточно создать дамп и импортировать его в новый проект.
- Резервное копирование. Отличный способ для экспериментов с веб-сайтом или сервером: вносите корректировки в базу данных и не бойтесь, что произойдет сбой. В случае неисправности всегда можно будет все восстановить из дампа.
Помимо этого, дамп может заполнить не только пустую базу, но и заменить содержимое ранее созданной. Давайте перейдем к практической части и посмотрим на наглядном примере, как все это можно организовать.
Создаем дамп базы данных MySQL
Существует несколько способов создания дампов: через консольное окно или с помощью phpMyAdmin. Рассмотрим последовательно каждый из методов, а также попробуем восстановить БД из дампа.
Способ 1: Консольное окно MySQL
Удаленное подключение к хостингу по SSH разрешает работать с информационными хранилищами. Выбор данного протокола обусловлен его высокой безопасностью, так как вся информация передается в зашифрованном виде без возможности перехвата трафика.
Для подключения вы можете воспользоваться такими программами, как PuTTY и WinSCP – они распространяются в бесплатном доступе. Остановимся на первой утилите и посмотрим, как с ее помощью можно сделать дамп базы данных MySQL.
- Открываем официальный сайт Putty и загружаем оттуда последнюю версию программы.
- Устанавливаем к себе на компьютер PuTTY и запускаем ее. Первым делом переходим в раздел «Connection» и находим там подраздел «Tunnels». В нем изменяем следующие параметры: указываем 336 в строке «Source port» и прописываем localhost:3306 в «Destination». В завершение нажимаем на кнопку «Add» — это действие позволит нам добавить созданный порт.
- Переходим в раздел «Sessions» — там вводим свой адрес или домен, в нижней части жмем на «Open».
- Вводим логин и пароль для подключения к БД.
Обратите внимание, что если на компьютере функционирует сервер с БД, то соединение через порт 3306 будет некорректно. В таких случаях рекомендуется использовать другие значения, например, 3307, 3308 и так далее.
Теперь мы можем переходить к удаленному администрированию БД: создадим дамп базы данных MySQL. Для этого введем в консоль следующий запрос:
mysqldump -uDataBase -pPASSWRD DataBase_NAME > FileName
- -uDataBase — имя базы в формате типа -u[root]
- -pPasswrd — пароль от базы в формате типа -p[123456]
- DataBase_NAME — имя БД
- FileName — название файла
В целях безопасности рекомендуется вообще не использовать логин и пароль. В таком случае команда примет следующий вид:
mysqldump -u -p DataBase_NAME > FileNameToSave
Для понимания можете взглянуть на пример с использованием пользователя и пароля:
mysqldump -uAdmin -p123456789 WordPressDB > WordPressDump.sql
Таким образом будет создан файл WordPressDump.sql, содержащий в себе все нужные данные для точного копирования. Посмотрим, как этот файл импортировать в проект через консоль:
mysql -uUSER -pPASSWRD -f DataBase_NAME < FileNameToEnter
Аналогично подставляем свои данные в команду и в итоге получаем:
mysql -uWordPressDB -p123456789 -f WordPressDB < WordPeressDump.sql
Также при импорте мы можем указать кодировку — для этого достаточно добавить ключ default-character-set. В итоге код преобразуется:
mysql -uAdmin -p123456789 -f --default-character-set=cp1251 WordPressDB < WordPeressDump.sql
Вот такими несложными действиями можно сделать копирование через консольное окно. Теперь давайте «покопаемся» в phpMyAdmin и выполним в нем копирование БД.
Способ 2: Инструмент phpMyAdmin
PhpMyAdmin по умолчанию предустановлен на каждой CMS. Доступ к нему осуществляется через личный кабинет пользователя на хостинге либо через локальный веб-сервер на домашнем ПК.
Подключаемся к phpMyAdmin и экспортируем БД:
- Открываем личный кабинет хостинга, на котором установлен веб-ресурс, и переходим в phpMyAdmin. На Timeweb это выполняется через раздел «База данных MySQL». Если вы используете локальный сервер на OpenServer, то достаточно в панели задач кликнуть правой кнопкой мыши по его иконке, перейти в меню «Дополнительно» и выбрать «PhpMyAdmin».
- Вводим логин и пароль, в результате чего попадаем в систему phpMyAdmin. В левой части выбираем БД для копирования и кликаем по ней левой кнопкой мыши.
- Переходим в раздел «Экспорт» и выбираем метод экспорта. Первый минимизирован – получится обычная БД без особых настроек, второй разрешает вносить важные уточнения. Например, мы можем удалять таблицы, изменять кодировку, добавлять особые параметры формата и многое другое. Перед сохранением файла указываем его формат и только потом нажимаем на кнопку «Вперед».
После этого нам будет предложен выбор места сохранения файла. В последующем мы сможем его использовать через вкладку «Импорт». Для этого достаточно загрузить файл и указать подходящую для него кодировку:
В заключение стоит сказать, что дамп базы данных – это незаменимый файл, без которого не обходится ни один серверный переезд. Используйте его для переноса базы на хостинге или с локальной машины, а также для создания резервных копий. Удачи!
Как импортировать и экспортировать базы данных в MySQL и MariaDB
Введение
Эта статья в первую очередь рассчитана на новичков в администрировании, тех, кто хочет научиться самостоятельно производить импорт и экспорт баз данных. Зачем вам может это понадобится? Допустим, вы хотите самостоятельно сделать бэкап, чтобы в дальнейшем при необходимости восстановить определенную версию базы данных. Или вам нужно сделать перенос сайта на другой сервер либо в другую среду разработки. В общем, причин может быть множество, поэтому понимание того, как сначала сделать, а потом импортировать резервную копию, лишним не будет.
Для того, чтобы выполнить все дальнейшие действия, у вас должны быть:
а) доступ к серверу на базе Linux, на котором работает MySQL/MariaDB;
б) название базы данных и данные доступа к ней.
Используем консоль
Экспорт
Для того, чтобы произвести экспорт, мы будем использовать утилиту mysqldump. При помощи нее осуществляется работа с текстовыми файлами базы данных. Итак, вы должны знать название базы данных, а также иметь доступ (логин и пароль) к аккаунту, который имеет, по крайней мере, доступ read only (только для чтения).
Для экспорта базы данных введите вот такую команду:
mysqldump -u имя_пользователя -p название_БД > data-dump.sql
в которой нужно ввести имя пользователя с необходимым доступом, название нужной вам базы данных, а также data-dump. sql – файл в текущей директории, куда будут сохранены данные.
После ввода этой команды вы не увидите никакого вывода на экране, однако вы можете проверить содержимое файла data-dump.sql для того, чтобы убедиться, что теперь он является резервной копией вашей базы данных.
Содержимое файла должно выглядеть примерно так, как показано ниже. В документе будет указано название базы данных (в данном случае MySQL), ее название и другие данные.
-- MySQL dump 10.13 Distrib 5.7.16, for Linux (x86_64) -- -- Host: localhost Database: database_name -- ------------------------------------------------------ -- Server version 5.7.16-0ubuntu0.16.04.1
Если во время процесса экспорта будут какие-нибудь ошибки, утилита mysqldump выведет на экран сообщение о них.
Импорт
Для того, чтобы импортировать существующий файл в MySQL или MariaDB, вам нужно начать с создания новой базы данных. Именно в нее вы затем загрузите содержимое резервной копии.
Сначала подключитесь к базе данных в качестве root-пользователя (либо другого пользователя, который сможет создать новую базу данных):
После того, как вы подключились к консоли MySQL, создайте новую базу данных (в данном случае new_database):
mysql> CREATE DATABASE new_database;
После этого на экране появился следующий вывод:
Output Query OK, 1 row affected (0.00 sec)
Теперь для выхода из консоли MySQL нажмите CTRL+D. Далее переходите к самому импорту. Сделать это можно, введя вот такую команду:
$ mysql -u имя_пользователя -p new_database < data-dump.sql
Команда очень похожа на команду экспорта, вам нужно ввести имя пользователя, название новой базы данных, куда вы будете импортировать данные (в качестве примера new_database), и название самого файла, который вы собираетесь импортировать (data-dump.sql).
Если команда выполнена корректно, то никакого вывода на экране вы не увидите; на экране могут отобразиться только сообщения о каких-то ошибках. Как и в случае с экспортом, проверить, точно ли все прошло успешно, вы можете путем подключения к MySQL и просмотра данных. Сделать это можно, к примеру, используя команды USE и SHOW. Команда use определяет, какая база данных будет использоваться в дальнейших запросах. Введите:
И тогда при всех последующих запросах в данном сеансе автоматически будет использоваться эта база данных. Данную установку можно изменить, использовав команду use с названием другой базы данных.
Что касается команды show, то она используется для того, чтобы посмотреть информацию о самих базах данных, о таблицах, столбцах, которые они содержат, а также о состоянии сервера.
Допустим, нам нужно посмотреть, список таблиц в базе. Для этого вводим:
Хотите увидеть список столбцов в какой-то определенной таблице? Используйте команду SHOW COLUMNS FROM и название нужно вам таблицы:
SHOW COLUMNS FROM название_таблицы
Статистику по работе сервера можно получить в ответ на команду:
mysql> SHOW GLOBAL STATUS;
Используем phpMyAdmin
Экспорт и импорт баз данных можно также делать через phpMyAdmin. В общем и целом, пожалуй, это даже более простой путь, чем использование консоли.
Экспорт
Зайдите в phpMyAdmin и выберите базу данных, с которых вы хотите работать.
Далее выберите вкладку «Экспорт» и, в зависимости от своих предпочтений, быстрый или обычный метод экспорта. Второй подойдет для тех, кто хочет самостоятельно выставить все настройки.
После внесения нужных изменений нажмите «Вперед» и выберите, куда хотите поместить созданный файл. Все, экспорт базы данных был успешно выполнен.
Импорт
Выполнить импорт базы данных тоже совсем несложно. Как и в предыдущем случае, в списке слева выберите нужную вам базу данных, а затем перейдите во вкладку «Импорт».
Выберите файл для импорта на вашем компьютере и проверьте настройки. Скорее всего, они подойдут для импортирования вашего файла, но при желании их можно изменить. Нажмите кнопку «Вперед» — и будет выполнен импорт файла. Вы увидите надпись вроде такой:
Импорт успешно завершён, выполнено 32 запроса.
Ниже в красной рамке могут идти сообщения о возникших ошибках (например, о дублировании).
В списке слева вы можете выбрать базу данных, с которой работали, и посмотреть имеющиеся файлы, а также их содержимое (и изменить их).
Заключение
Выбор подходящего метода экспорта и импорта баз данных зависит только от вас и ваших предпочтений – кому-то проще работать в консоли, а для кого-то понятнее phpMyAdmin. Главное, нужно регулярно делать бэкапы, в том числе и ваших баз данных.
Кстати, полезную информацию о базах данных я также нашел в Справочном центре Timeweb.
Генерируем «правильный» SQL дамп / Хабр
В процессе разработки с использованием MySQL часто приходится делать дамп базы данных для сохранения ее в репозиторий (деплоя на сервер и т.д.).
Существуют разные клиенты для работы с MySQL:
— MySQL Front
— PHPMyAdmin
— Aqua Data Studio
— EMS SQL manager
и так далее.
Проблема
В каждом из перечисленных существует функция экспорта схемы базы и её данных в файл. Попросту говоря — создания дампа БД. Но вот незадача! Каждый из иструментов генерирует SQL код со своим форматированием. К примеру, некоторые даже не вставляют ENGINE=MyISAM DEFAULT CHARSET=… в выражении CREATE TABLE, то же самое и с DROP TABLE IF EXISTS. Одним словом, наблюдается эффект «лебедь, рак и щука».
Затруднения возникают, если в команде несколько разработчиков — вероятнее всего каждый из них привык пользоваться каким-то одним инструментом. Попытки заставить девелоперов применять какой-то определенный клиент могут привести к священным войнам («я к этому привык, я не хочу другое.., а это вообще отстой!»). Возможно, кому то проблема покажется надуманной, но в моей практике такое было. Да и что делать, если люди работают на разных операционных системах? SQL менеджеры у них тоже будут разные.
Итак, нужен способ генерации дампа в каком то унифицированном формате. Ожидаемая выгода:
- возможность легко сравнивать изменения sql файлов в репозитории (если ревизии в одном формате, это проще. Не так ли?)
- возможность дальнейшего парсинга SQL кода (например, в инсталляторе приложения)
- автоматизация сего действия
- независимость от ОС
- указание кодировки
- возможно что-то еще:)
Решение
Отказаться от каких либо сторонних инструментов для генерации дампа.
В дистрибутиве MySQL существует набор полезных утилит, в том числе и известная многим mysqldump. Ниже можно увидеть BAT-файл, который используя данную утилиту генерирует правильный SQL дамп.
Правильный — в данном контексте означает «соответствующий оговоренному формату». В любом случае, не хочу подвергать сомнению корректность работы родной утилиты от MySQL 🙂
@echo off
rem author afi
echo =========================================
echo SQL generator
echo Output files :
echo scheme.sql - Scheme of database
echo data.sql - Data for database
echo =========================================
rem по умолчанию UTF-8
set ENCODING=utf8
IF «%1» == «» goto ERROR
IF «%2» == «» goto ERROR
IF «%3» == «» goto ERROR
IF «%4» == «» goto ERROR
IF NOT «%5» == «» (
set ENCODING=»%5″
)
goto get
:get
echo Generating scheme for DB: %1
mysqldump —host=%1 —password=%4 -u %3 —disable-keys —add-drop-table —default-character-set=%ENCODING% —no-data —result-file=scheme. sql %2
echo Generating data for DB: %1
mysqldump —host=%1 —password=%4 -u %3 —disable-keys —default-character-set=%ENCODING% —no-create-info —extended-insert=false —result-file=data.sql %2
goto END
:ERROR
echo Please, define parameters. Example:
echo gensql.bat host_name database_name mysql_user mysql_password [encoding]
goto END
:END
echo =========================================
@pause
Теперь все заботы сводятся к запуску скрипта с параметрами: gensql.bat host_name database_name mysql_user mysql_password [encoding]
, где encoding — выходная кодировка данных. Необязательный параметр, по умолчанию utf8.
В результате, получаем 2 файла:
scheme.sql — содержит схему БД, т.е. скрипт создания таблиц, ограничений, вьюшек и пр.
data.sql — содержит дамп данных
Сделать bash-вариант скрипта, думаю не составит труда тем, кому он может понадобиться.
Cнятие и установка дампа в MySQL (mysqldump) — tips & tricks / Песочница / Хабр
В теории
В теории все просто — MySQL из коробки имеет утилиту mysqldump, которая позволяет снять копию базы в виде набора SQL инструкций.
В реальности все гораздо хуже. Дело в том, что mysqldump криво работает с кодировками, отличными от Latin1. Тоесть экспортировать базу в UTF8 следуя официальной документации (man mysqldump), тоесть с указанием —default-character-set=utf8, и импортировать ее потом обратно — не представляется возможным. Кодировка будет битая в следствии «двойного преобразования», выполняемого утилитой mysqldump — пруфлинк
Собственно, по ссылке выше есть и рецеп. Суть его в том, что нужно экспортировать базу и затем импортировать ее в Latin1 вне зависимости от того, какая реально кодировка используется. При этом конечно нужно вычестить из *.sql файл инструкции SET NAMES…
Еще один важный момент, который следует учесть. Как правило мы снимаем дамп базы с именем A и пытаемся накатить его на базу с именем B. Соответственно, возможны коллизии из за того, что в созданном после экспорта файле в SQL запросах и командах СУБД будет присутствовать упоминание A. Нужно заменить все вхождения A на B, ниже под катом будет пример как это сделать средствами VIM.
И на последок, перед загрузкой дампа старую базу лучше полностью отчистить. Сделать это можно по-разному, я же для себя нашел удобным маленький shell-скрипт (drop_all.sh), который автоматизирует для меня эту работу:
#!/usr/local/bin/bash
MUSER="$1"
MPASS="$2"
MDB="$3"
HOST="$4"
# Detect paths
MYSQL=$(which mysql)
AWK=$(which awk)
GREP=$(which grep)
if [ $# -ne 4 ]
then
echo «Usage: $0 {MySQL-User-Name} {MySQL-User-Password} {MySQL-Database-Name} {MySQL-Host}»
echo «Drops all tables from a MySQL»
exit 1
fi
TABLES=$($MYSQL -h $HOST -u $MUSER -p$MPASS $MDB -e ‘show tables’ | $AWK ‘{ print $1}’ | $GREP -v ‘^Tables’ )
for t in $TABLES
do
echo «Deleting $t table from $MDB database. ..»
$MYSQL -h $HOST -u $MUSER -p$MPASS $MDB -e «SET FOREIGN_KEY_CHECKS = 0;drop table $t;SET FOREIGN_KEY_CHECKS = 1;»
done
Итак, алгоритм
Последовательность шагов такова:
1) Снимаем дамп.
bash> mysqldump -h {host} -u {user} -p{password} --default-character-set=latin1 -N {dbname} > latin_dump.sql
2) Открываем получившийся в итоге файл и осуществляем замену. Сохраняем изменения.
bash> vi latin_dump.sql
:%s/dbname/dbname2/g
3) Чистим базу перед загрузкой дампа.
bash> ./drop_all.sh {user} {password} {dbname2} {host}
4) Загружаем дамп.
bash> mysql --force -h {host} -u {user} -p{password} --default-character-set=latin1 -D {dbname2} < latin_dump.sql
Дамп и восстановление базы данных MySQL
Дамп и восстановление базы данных MySQL довольно просто и удобно делать удаленно через SSH или прямо через консоль сервера. Удаленно, это можно делать используя программы Putty/Kitty. Также указанные ниже примеры Вы можете выполнять и на Windows запустив командную строку ‘cmd‘. Ниже приведены примеры о том, как создавать дампы базы данных MySQL и затем восстанавливать их при необходимости, например для Вашего сайта, интернет-магазина или какого либо другого проекта.
Создание дампа базы данных MySQL
Для того, чтоб выполнять данные команды, подключитесь удаленно к Вашему серверу через SSH используя одну из перечисленных выше программ. После подключения и авторизации к серверу/хостингу, Вы можете вводить приведенные ниже команды.
# Бекап одной базы данных в файл dump_file.sql
mysqldump -uroot -p your_base > dump_file.sql
# На windows дамп лучше всего создавать немного другой командой, которая предотвращает
# случайное затирание строк дампа из за конвертации символов перевода строки ‘\r\n’ в ‘\n’
mysqldump -uroot -p your_base -r dump_file_utf8.sql
# Если Вам нужен бекап только отдельных таблиц, а не всей базы данных
# (указываем наименования таблиц через пробел после названия базы данных)
mysqldump -uroot -p your_base TABLE1 TABLE2 TABLE3 > dump_file. sql
# Если нужно создать бекап только структуры базы данных без самих данных
mysqldump -uroot -p —no-data your_base > dump_file.sql
# Бекап всех баз данных в файл текущая_дата.gz
mysqldump -uroot -p —all_databases | gzip -c > ‘date «+%Y-%m-%d»‘.gz
# Бекап, где для каждой записи создается отдельный INSERT
# и с явным указанием кодировки базы данных UTF-8
mysqldump -uroot -p —default-character-set=utf8 your_base —extended-insert=FALSE | gzip -c > ‘date «+%Y-%m-%d»‘.gz
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
| # Бекап одной базы данных в файл dump_file.sql mysqldump -uroot -p your_base > dump_file.sql
# На windows дамп лучше всего создавать немного другой командой, которая предотвращает # случайное затирание строк дампа из за конвертации символов перевода строки ‘\r\n’ в ‘\n’ mysqldump -uroot -p your_base -r dump_file_utf8. sql
# Если Вам нужен бекап только отдельных таблиц, а не всей базы данных # (указываем наименования таблиц через пробел после названия базы данных) mysqldump -uroot -p your_base TABLE1 TABLE2 TABLE3 > dump_file.sql
# Если нужно создать бекап только структуры базы данных без самих данных mysqldump -uroot -p —no-data your_base > dump_file.sql
# Бекап всех баз данных в файл текущая_дата.gz mysqldump -uroot -p —all_databases | gzip -c > ‘date «+%Y-%m-%d»‘.gz
# Бекап, где для каждой записи создается отдельный INSERT # и с явным указанием кодировки базы данных UTF-8 mysqldump -uroot -p —default-character-set=utf8 your_base —extended-insert=FALSE | gzip -c > ‘date «+%Y-%m-%d»‘.gz |
В приведенном выше примере, для создания бекапа используется утилита mysqldump, которая входит в состав mysql. Далее указываются параметры для создания бекапа базы данных, которые разберем подробнее:
- -u – параметр указывает логин, который будет использоваться для подключения к базе данных. В примере мы используем логин root, который нужно указать в этом параметре без пробела! В результате у нас это выглядит как -uroot
- -p – параметр указывает что нужно ввести пароль для указанного логина. Мы его оставили пустым, в результате чего пароль нужно будет ввести после нажатия “Enter” при выполнении команды. Тем не менее, можно указать пароль сразу же здесь, как и в параметре логина, без пробела после -p, однако этот способ не является безопасным, так как консоль сохраняет Ваши команды в лог файл и если Вы его регулярно не очищаете, то он может быть просмотрен злоумышленником.
- your_base – вместо этой строки в примере, вам необходимо указать реальное имя Вашей базы данных, для которой Вы создаете бекап.
- > – оператор который показывает направление действия, т.е. как бы указывает, что вы собираетесь сделать запись из базы в файл.
- dump_file.sql – это название Вашего файла .slq в которую нужно сохранить Вашу базу данных. Он указывается через пробел после оператора ‘>’. Вы можете задать любое другое имя. Например, чтобы в имени система автоматически вставила текущее время, достаточно указать строку вида:
после этой строки в примере указывается расширение файла ‘.gz‘. В результате будет создан файл вида ‘2014-11-15.gz‘.Внимание! Если Вы указываете только имя файла, то он будет сохранен в той же директории, относительно которой Вы выполняете данную команду. Т.е. если Вы видите в строке приглашения ввода команд что-то вроде [root@dvs home]#, где root@dvs это логин и имя сервера, то файл будет создан в директории /home. Чтобы изменить сохранение файла по другому пути, укажите вместо имени полный путь для сохранения файла, например: /var/www/backup/dump_file.sql.
- Во втором примере, вместо оператора ‘>‘ используется оператор ‘|‘, который указывает на необходимость выполнения дополнительной команды gzip c параметром ‘-c‘ которая позволяет сразу же запаковать дамп в архив, а только затем сохранить его в файл вида ‘2014-11-15. gz‘, о чем сообщает оператор ‘>‘.
- Параметр –no-data позволяет создать дамп только структуры базы данных без самих данных. В некоторых случаях довольно полезно, когда данные не нужны.
- Параметры –default-character-set=utf8 и –extended-insert=FALSE. Первый позволяет Вам явно указать кодировку, которая используется этой базой данных, тем самым избежать сохранение базы в неверной кодировке Вместо utf8 можно указать любую другую кодировку, например cp1251. Второй параметр позволяет указать, что при экспорте для каждой записи необходимо создать отдельную команду INSERT. В некоторых случаях это может потребоваться при частичном восстановлении данных из дампа.
Восстановление базы данных из файла дампа MySQL
Теперь рассмотрим с Вами обратный процесс восстановления базы данных из файла дампа. Данное действие выполняется при помощи программы mysql. Рассмотрим сразу же пример.
# Восстанавливаем базу данных your_base из файла дампа dump_file
mysql -uroot -p your_base < dump_file. sql
| # Восстанавливаем базу данных your_base из файла дампа dump_file mysql -uroot -p your_base < dump_file.sql |
Здесь также используются параметры ‘-u‘ и ‘-p‘, которые указывают на логин и пароль для подключения к базе данных аналогично утилите mysqldump, рассмотренной в предыдущем примере. После этого идет название базы данных, а также файла, из которого необходимо восстановить данные. Между ними ставится оператор ‘<‘ который указывает направление, что мы хотим импортировать данные в базу из файла.
PostgreSQL: Документация: 10: 25.1. Дамп SQL
Идея этого метода дампа состоит в том, чтобы сгенерировать файл с командами SQL, которые при отправке обратно на сервер воссоздают базу данных в том же состоянии, в котором она была во время дампа. PostgreSQL предоставляет для этого служебную программу pg_dump. Базовое использование этой команды:
pg_dumpdbname
>файл дампа
Как видите, pg_dump записывает свой результат в стандартный вывод.Ниже мы увидим, чем это может быть полезно. В то время как приведенная выше команда создает текстовый файл, pg_dump может создавать файлы в других форматах, которые обеспечивают параллелизм и более детальный контроль восстановления объекта.
pg_dump — обычное клиентское приложение PostgreSQL (хотя и очень умное). Это означает, что вы можете выполнить эту процедуру резервного копирования с любого удаленного хоста, имеющего доступ к базе данных. Но помните, что pg_dump не работает с особыми разрешениями. В частности, он должен иметь доступ для чтения ко всем таблицам, для которых вы хотите создать резервную копию, поэтому для резервного копирования всей базы данных вам почти всегда нужно запускать ее как суперпользователь базы данных.(Если у вас нет достаточных прав для резервного копирования всей базы данных, вы все равно можете резервировать части базы данных, к которым у вас есть доступ, используя такие параметры, как -n
или schema
-t
. ) table
Чтобы указать, с каким сервером базы данных должен связаться pg_dump, используйте параметры командной строки -h
и host
-p
. Хостом по умолчанию является локальный хост или то, что указано в переменной среды port
PGHOST
.Точно так же порт по умолчанию указывается переменной среды PGPORT
или, в противном случае, компилированным по умолчанию. (Удобно, что сервер обычно будет иметь такое же встроенное значение по умолчанию.)
Как и любое другое клиентское приложение PostgreSQL, pg_dump по умолчанию подключается к имени пользователя базы данных, которое совпадает с именем пользователя текущей операционной системы. Чтобы отменить это, укажите параметр -U
или установите переменную среды PGUSER
.Помните, что соединения pg_dump подчиняются обычным механизмам аутентификации клиентов (которые описаны в главе 20).
Важным преимуществом pg_dump перед другими методами резервного копирования, описанными ниже, является то, что вывод pg_dump обычно можно повторно загрузить в более новые версии PostgreSQL, тогда как резервное копирование на уровне файлов и непрерывное архивирование сильно зависят от версии сервера. pg_dump также является единственным методом, который будет работать при переносе базы данных на другую архитектуру компьютера, например, при переходе с 32-битного на 64-битный сервер.
Дампы, создаваемые pg_dump, внутренне согласованы, то есть дамп представляет собой моментальный снимок базы данных на момент начала работы pg_dump. pg_dump не блокирует другие операции с базой данных во время ее работы. (Исключениями являются те операции, которые должны работать с монопольной блокировкой, например большинство форм ALTER TABLE
.)
25.1.1. Восстановление дампа
Текстовые файлы, созданные pg_dump, предназначены для чтения программой psql.Общая форма команды для восстановления дампа —
.
psqldbname
<файл дампа
, где файл дампа
— это файл, выводимый командой pg_dump. База данных dbname
не будет создана этой командой, поэтому вы должны создать ее самостоятельно из template0
перед выполнением psql (например, с createdb -T template0
). psql поддерживает параметры, аналогичные pg_dump, для указания сервера базы данных для подключения и имени пользователя для использования.См. Справочную страницу по psql для получения дополнительной информации. Дампы нетекстовых файлов восстанавливаются с помощью утилиты pg_restore. dbname
Перед восстановлением дампа SQL все пользователи, владеющие объектами или которым были предоставлены права доступа к объектам в базе данных дампа, должны уже существовать. В противном случае при восстановлении не удастся воссоздать объекты с исходным владельцем и / или разрешениями. (Иногда это то, что вам нужно, но обычно это не так.)
По умолчанию скрипт psql продолжит выполнение после обнаружения ошибки SQL.Возможно, вы захотите запустить psql с переменной ON_ERROR_STOP
, настроенной для изменения этого поведения, и иметь выход psql со статусом выхода 3, если возникает ошибка SQL:
psql --set ON_ERROR_STOP = ondbname
<файл дампа
В любом случае у вас будет только частично восстановленная база данных. В качестве альтернативы вы можете указать, что весь дамп должен быть восстановлен как одна транзакция, поэтому восстановление будет либо полностью завершено, либо полностью откат.Этот режим можно указать, передав в psql параметры командной строки -1
или --single-transaction
. При использовании этого режима помните, что даже незначительная ошибка может откатить восстановление, которое уже выполнялось в течение многих часов. Однако это может быть предпочтительнее ручной очистки сложной базы данных после частично восстановленного дампа.
Способность pg_dump и psql записывать или читать из каналов дает возможность выгружать базу данных напрямую с одного сервера на другой, например:
pg_dump -hhost1
dbname
| psql -hhost2
имя_бд
Важно
Дампы, создаваемые pg_dump, относятся к template0
.Это означает, что любые языки, процедуры и т. Д., Добавленные через template1
, также будут сброшены pg_dump. В результате при восстановлении, если вы используете настроенный шаблон template1
, вы должны создать пустую базу данных из template0
, как в примере выше.
После восстановления резервной копии целесообразно запустить ANALYZE для каждой базы данных, чтобы оптимизатор запросов имел полезную статистику; см. Раздел 24.1.3 и Раздел 24.1.6 для получения дополнительной информации. Дополнительные советы по эффективной загрузке больших объемов данных в PostgreSQL см. В Разделе 14.4.
25.1.2. Использование pg_dumpall
pg_dump выгружает только одну базу данных за раз, и он не выгружает информацию о ролях или табличных пространствах (потому что они являются общекластерными, а не для каждой базы данных). Для поддержки удобного сброса всего содержимого кластера базы данных предоставляется программа pg_dumpall. pg_dumpall выполняет резервное копирование каждой базы данных в данном кластере, а также сохраняет данные всего кластера, такие как определения ролей и табличных пространств. Базовое использование этой команды:
pg_dumpall> файл дампа
Полученный дамп можно восстановить с помощью psql:
psql -f файл дампа
postgres
(На самом деле, вы можете указать любое имя существующей базы данных для начала, но если вы загружаете в пустой кластер, то обычно следует использовать postgres
.) При восстановлении дампа pg_dumpall всегда необходимо иметь доступ суперпользователя к базе данных, так как это требуется для восстановления информации о роли и табличном пространстве. Если вы используете табличные пространства, убедитесь, что пути к табличным пространствам в дампе подходят для новой установки.
pg_dumpall работает, отправляя команды для воссоздания ролей, табличных пространств и пустых баз данных, а затем вызывает pg_dump для каждой базы данных. Это означает, что, хотя каждая база данных будет внутренне согласованной, моментальные снимки разных баз данных не синхронизируются.
Данные всего кластера можно сбросить отдельно, используя параметр pg_dumpall --globals-only
. Это необходимо для полного резервного копирования кластера при запуске команды pg_dump для отдельных баз данных.
25.1.3. Работа с большими базами данных
Некоторые операционные системы имеют ограничения на максимальный размер файла, что вызывает проблемы при создании больших выходных файлов pg_dump. К счастью, pg_dump может записывать данные в стандартный вывод, так что вы можете использовать стандартные инструменты Unix для решения этой потенциальной проблемы.Есть несколько возможных методов:
Использовать сжатые дампы. Вы можете использовать свою любимую программу сжатия, например gzip:
pg_dumpdbname
| gzip>имя_файла
.gz
Перезарядка с:
gunzip -cfilename
.gz | psqlимя базы данных
или:
catfilename
.gz | gunzip | psqlимя базы данных
Используйте split
. Команда split
позволяет разделить вывод на файлы меньшего размера, приемлемые по размеру для базовой файловой системы. Например, чтобы сделать куски размером 1 мегабайт:
pg_dumpdbname
| split -b 1m -filename
Перезарядка с:
catfilename
* | psqlимя базы данных
Используйте собственный формат дампа pg_dump. Если PostgreSQL был собран в системе с установленной библиотекой сжатия zlib, пользовательский формат дампа будет сжимать данные по мере их записи в выходной файл.Это создаст размер файла дампа, аналогичный использованию gzip
, но имеет дополнительное преимущество, заключающееся в том, что таблицы можно восстанавливать выборочно. Следующая команда выводит базу данных в настраиваемом формате дампа:
pg_dump -Fcdbname
>filename
Дамп нестандартного формата не является сценарием для psql, его необходимо восстановить с помощью pg_restore, например:
pg_restore -dимя_бд
имя_файла
Подробности см. На справочных страницах pg_dump и pg_restore.
Для очень больших баз данных вам может потребоваться объединить split
с одним из двух других подходов.
Используйте функцию параллельного дампа pg_dump. Чтобы ускорить создание дампа большой базы данных, вы можете использовать параллельный режим pg_dump. Это приведет к сбросу нескольких таблиц одновременно. Вы можете контролировать степень параллелизма с помощью параметра -j
. Параллельные дампы поддерживаются только для формата архива «каталог».
pg_dump -jчисло
-F d -fout.директория
dbname
Вы можете использовать pg_restore -j
для параллельного восстановления дампа. Это будет работать для любого архива в режиме «пользовательский» или «каталог», независимо от того, был ли он создан с помощью pg_dump -j
.
Справка по команде Linux mysqldump и примеры
Обновлено: 04.05.2019, Computer Hope
В Unix-подобных операционных системах, работающих под управлением MySQL, команда mysqldump «выгружает» базу данных MySQL или набор баз данных для резервного копирования или передачи на другой сервер SQL.
Описание
Клиент mysqldump — это служебная программа, которая выполняет логическое резервное копирование, создавая набор операторов SQL, которые можно запускать для воспроизведения исходных объектов схемы, табличных данных или того и другого. Он выгружает одну или несколько баз данных MySQL для резервного копирования или передачи на другой сервер SQL. Команда mysqldump также может генерировать вывод в CSV, другом тексте с разделителями или в формате XML.
mysqldump требует как минимум привилегию SELECT для дампа таблиц, SHOW VIEW для дампа представлений, TRIGGER для сброшенных триггеров и LOCK TABLES , если параметр —single-transaction не используется.Для некоторых параметров могут потребоваться другие привилегии, как указано в описании параметров.
Чтобы перезагрузить файл дампа, у вас должны быть те же привилегии, которые необходимы для создания каждого из выгруженных объектов путем выполнения операторов CREATE вручную.
mysqldump вывод может включать в себя инструкции ALTER DATABASE , которые изменяют параметры сортировки базы данных. Их можно использовать при сбросе сохраненных программ, чтобы сохранить их кодировки символов. Чтобы перезагрузить файл дампа, содержащий такие операторы, требуется привилегия ALTER для затронутой базы данных.
Вопросы производительности и масштабируемости
mysqldump Преимущества включают удобство и гибкость просмотра или даже редактирования вывода перед восстановлением. Вы можете клонировать базы данных для разработки и работы администраторов баз данных или создавать небольшие вариации существующей базы данных для тестирования. Он не предназначен в качестве быстрого или масштабируемого решения для резервного копирования значительных объемов данных. При больших размерах данных, даже если этап резервного копирования занимает разумное время, восстановление данных может быть очень медленным, потому что воспроизведение операторов SQL включает дисковый ввод-вывод для вставки, создания индекса и т. Д.
Для крупномасштабного резервного копирования и восстановления более подходит физическая резервная копия, чтобы скопировать файлы данных в их исходном формате, который можно быстро восстановить:
- Если ваши таблицы в основном являются таблицами InnoDB, или если у вас есть смесь таблиц InnoDB и MyISAM, лучшим инструментом может быть команда mysqlbackup продукта MySQL Enterprise Backup (который не является бесплатным). Он обеспечивает лучшую производительность для резервного копирования InnoDB, а также может выполнять резервное копирование таблиц из MyISAM и других механизмов хранения; и предлагает множество удобных вариантов для различных сценариев резервного копирования.
- Если ваши таблицы в основном являются таблицами MyISAM, рассмотрите возможность использования вместо них mysqlhotcopy , для большей производительности, чем mysqldump операций резервного копирования и восстановления.
mysqldump может извлекать и выгружать содержимое таблицы строка за строкой, или он может извлекать все содержимое из таблицы и буферизовать его в памяти перед тем, как сбросить его. Буферизация в памяти может быть проблемой, если вы выгружаете большие таблицы. Чтобы вывести таблицы построчно, используйте опцию —quick (или —opt , которая включает —quick ).Параметр —opt (и, следовательно, —quick ) включен по умолчанию, поэтому для включения буферизации памяти используйте —skip-quick .
Если вы используете последнюю версию mysqldump для создания дампа для перезагрузки на очень старый сервер MySQL, используйте параметр —skip-opt вместо параметра —opt или —extended- вставить опцию .
Вызов mysqldump
Существует три основных способа использования mysqldump .Его можно использовать для дампа набора из одной или нескольких таблиц, для дампа набора из одной или нескольких полных баз данных или для дампа всего сервера MySQL. Эти три использования, соответственно, показаны здесь:
mysqldump [параметры] db_name [tbl_name ...]
mysqldump [параметры] --databases имя_базы_данных ...
mysqldump [параметры] --all-databases
Чтобы выгрузить целые базы данных, не называйте таблицы после db_name ; или используйте параметр —databases или —all-databases .
Синтаксис
mysqldump [ опции ] [ db_name [ tbl_name ...]]
Опции
mysqldump поддерживает следующие параметры, которые можно указать в командной строке или в группах [mysqldump] и [клиент] файла параметров.
Варианты подключения
--bind-address = ip_address | На компьютере с несколькими сетевыми интерфейсами эту опцию можно использовать для выбора интерфейса, используемого при подключении к серверу MySQL.Эта опция поддерживается, начиная с MySQL 5.6.1. |
- сжатие -C | Сжать всю информацию, передаваемую между клиентом и сервером, если оба поддерживают сжатие. |
--default-auth = плагин | Используемый подключаемый модуль проверки подлинности на стороне клиента. |
--host = имя_хоста -h имя_хоста | Дамп данных с сервера MySQL на указанном хосте.Хост по умолчанию: |
drush sql: дамп для drush 9.x
Drush Commands
Дом
Связаться с нами
Друша 8
7
6
9
партия- партия: процесс партия-процесс
тайник- кэш: getcg
cache-get
- кеш: clearcc
очистка кеша
- кэш: setcs
cache-set
- cache: rebuild
- кэш: getcg
config- конфигурация: pullcpull
config-pull
- конфигурация: getcget
config-get
- config: setcset
config-set
- config: editcedit
config-edit
- config: deletecdel
config-delete
- config: statuscst
config-status
- config: exportcex
config-export
- config: importcim
config-import
- конфигурация: pullcpull
ядро- ядро: topictopic
основная тема
- ядро: initinit
core-init
- ядро: редактировать
- ядро: rsyncrsync
core-rsync
- ядро: статус
- ядро: global-optionscore-global-options
- ядро: выполнить
- ядро: croncron
core-cron
- core: требования
- ядро: topictopic
развиваться- разработка: reinstalldre
devel-переустановить
- devel: hook
- devel: event
- devel: tokentoken
маркер разработки
- разработка: uuiduuid
devel-uuid
- разработчик: услуги
- разработка: reinstalldre
документы- docs: readmedocs-readme
- docs: bisectdocs-bisect
- docs: bashrcdocs-bashrc
- docs365 config:
s-config
s-config: configdocs -365 -exporting
- docs: aliasesdocs-aliases
- docs: bootstrapdocs-bootstrap
- docs: crondocs-cron
3oc75s 90s90doc Уязвимости SQL-инъекций для дампа вашей базы данных — Java, SQL и jOOQ.
Угроза, создаваемая внедрением SQL, сильно недооценивается даже многими старшими разработчиками и архитекторами программного обеспечения. Большинство людей не подозревают о том, что из-за одной-единственной уязвимости может оказаться под угрозой целый сервер даже в самой отдаленной части логики. Эта статья даст пугающее представление о потенциальной серьезности уязвимостей SQL-инъекций.
Что такое SQL-инъекция?
Статья в Википедии о SQL-инъекции гласит:
SQL-инъекция — это метод внедрения кода, используемый для атаки приложений, управляемых данными, при котором вредоносные операторы SQL вставляются в поле ввода для выполнения.
Другими словами, если веб-сайт или другой программный объект имеет уязвимость, злоумышленник может «внедрить» произвольные фрагменты кода SQL для выполнения на сервере. Простой и популярный пример такой уязвимости — это когда динамический оператор SQL напрямую встраивает пользовательский ввод, как это делает следующий код Java:
Переменная заголовка может вводиться пользователем, например поле HTML. Ничто не препятствует тому, чтобы вводимые пользователем данные были фрагментами кода SQL, которые имели бы идеальный синтаксический смысл.Например:
Легко видеть, что при подстановке этого «заголовка» в предыдущий оператор SQL всегда будут выбираться все фильмы. Еще один известный пример того, как это может пойти не так, — это знаменитая лента Little Bobby Tables от xkcd.
Автоматизация поиска уязвимостей
Приведенное выше введение показывает, что SQL-инъекция возможна и довольно проста в использовании вручную, если исходный код на стороне сервера хорошо известен. Однако поиск такой уязвимости в огромном приложении с тысячами операторов SQL — это большая работа.Кроме того, существует гораздо более тонкие уязвимости, чем очевидный поиск по шаблону. sqlmap — это инструмент с открытым исходным кодом под лицензией GPLv2 для автоматизации такого поиска.
Предположим, у нас есть простое приложение RESTful, написанное на Java с использованием Jetty и JAX-RS, запрашивающее базу данных MySQL Sakila, которая обнаруживает указанную выше уязвимость по этому URL-адресу:
http: // localhost: 8080 / sql-инъекция-примеры / уязвимые-сервисы / фильмы / чужой
alien — это значение @PathParam, переданное этому методу, который возвращает все фильмы с названием% alien%:
Теперь давайте загрузим sqlmap и дадим ему работать с указанным выше URL:
python sqlmap.ру -u localhost: 8080 / sql-инъекция-примеры / уязвимые-сервисы / фильмы /
Обратите внимание, что sqlmap реализован в Python 2.x. Когда мы позволяем этому запускаться, мои журналы SQL на стороне сервера показывают мне, что выполняется пара интересных SQL-запросов:
sqlmap пытается внедрить всевозможные фрагменты, которые помогли бы ему определить, является ли уязвимый запрос детерминированным, является ли URL-адрес стабильным, какой это тип сервера базы данных, если уязвимость находится внутри подзапроса, можно ли добавлять предложения UNION и т. Д. .Это также хорошо отображается в выводе журнала sqlmap stdout:
Выполнив 59 HTTP-запросов (из которых 41 привел к ошибке HTTP 500), sqlmap смог определить природу уязвимости моего оператора SQL, а также определить сервер и версию базы данных.
Данные сброса
Это пока не так уж и впечатляет. Обладая большим знанием SQL и творчеством, я мог бы сам в этом разобраться. Но sqlmap предлагает множество других интересных режимов работы, которые можно увидеть в руководстве пользователя.Воспользуемся средствами навигации по базе данных. Для этого мы добавим параметр –dbs к тому же URL:
.
Python sqlmap.py -u localhost: 8080 / sql-инъекция-примеры / уязвимые-сервисы / фильмы / --dbs
Это немедленно сбросит следующие базы данных:
Обратите внимание, что sqlmap регистрирует все, что узнает, в локальной базе данных SQLite, поэтому количество HTTP-запросов может быть как можно меньшим. Это важно для злоумышленника, так как частые состояния HTTP 404 или 500 в конечном итоге вызовут внимание обслуживающего персонала на стороне сервера.
Но как он нашел настоящие имена баз данных с помощью моего уязвимого оператора SQL? В три этапа:
- Он отправил первое заявление, чтобы проверить, существует ли еще уязвимость
- Он отправил второй оператор, чтобы узнать, сколько существует баз данных (8)
- Он отправил третий оператор, чтобы узнать имя каждой базы данных
Давайте посмотрим на шаг 2. Выполняется следующий запрос:
Поскольку sqlmap ранее обнаружил, что моя наивная реализация сервера просто сбрасывает следы стека ошибок HTTP 500, он знал, что может сгенерировать следующее сообщение об ошибке MySQL и передать интересующую информацию, скрытую внутри этого сообщения:
ком.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Повторяющаяся запись qnfwq8qdmiq1 для ключа group_key
Функция SQL concat обертывает число 8 двумя однозначно идентифицируемыми строками. С помощью аналогичного запроса и предложения MySQL LIMIT имена баз данных можно затем извлекать одно за другим, например база данных Сакила:
com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Повторяющаяся запись qnfwqsakilaqdmiq1 для ключа group_key
Опять же, интересующая информация заключена между разделителями.
Выгрузка данных без трассировки стека
Очевидно, что дамп трассировки стека в продуктивной системе — действительно плохая идея, так как вы никогда не должны давать злоумышленнику никаких намеков о том, как работает ваша система. Давайте попробуем изменить наше приложение так, чтобы оно отображало простое сообщение об ошибке 500 Internal Server Error:
Нет проблем для sqlmap. Когда я повторно запускаю свою предыдущую команду сброса базы данных, sqlmap генерирует все имена баз данных буква за буквой. Теперь, когда у него нет возможности выводить сообщение об ошибке в HTTP-ответах, он может выполнять только двоичный поиск по каждой букве схемы и видеть, производит ли какой-либо данный поиск по-прежнему обычный список фильмов Sakila или пустой список:
Приведенный выше запрос проверяет, имеет ли первая схема (LIMIT 0, 1) буква выше, чем код ASCII 120 (ORD) в позиции 13 (MID).Это намного медленнее и более заметно в журналах сервера, чем раньше, но все же может дать результат.
Выгрузка данных без отображения вывода пользовательского интерфейса
Что делать, если уязвимость находится глубоко в нашем приложении и никогда не производит вывод пользовательского интерфейса? Давайте снова изменим нашу службу, выполнив уязвимый запрос, но не вернув никаких данных:
Мой файл журнала показывает мне, что sqlmap выполняет намного больше SQL-операторов, и даже подтверждение наличия уязвимости в данном URL-адресе занимает больше времени, поскольку sqlmap теперь использует двоичный поиск с задержками.Вот как sqlmap подтверждает наличие уязвимости:
Как видно, указанные выше запросы выполняются в течение N или N + 5 секунд, где N — количество времени, которое занимает фактический запрос. Если N достаточно стабильно, можно выполнить двоичный поиск на основе задержки для обнаружения букв в именах баз данных.
Сброс конфиденциальных данных
Предыдущие разделы показали, что уязвимость почти всегда можно использовать автоматически. У злоумышленников есть время. Они могут запустить свой сценарий в течение недели, чтобы sqlmap выгрузил полную схему вашей базы данных.Но на этом угроза не заканчивается. После того как имена таблиц и столбцов станут доступными, все эти таблицы также можно будет выгрузить. Сбросим таблицу фильмов:
Python sqlmap.py -u localhost: 8080 / sql-инъекция-примеры / уязвимые-сервисы / фильмы / --дамп –Т пленка
Это занимает очень много времени, так как каждая строка и каждый столбец выбираются с помощью по крайней мере одного запроса. Но в итоге я получаю хороший CSV-файл с полным содержимым. Нет необходимости говорить, что это может быть информация о кредитной карте вашего приложения или другие конфиденциальные или секретные данные.
Произвольный запрос
Вы думаете, что заметите, если кто-то сбросит всю вашу схему? Злоумышленнику в этом нет необходимости. Помните, что они уже могли извлекать имена схем, таблиц и столбцов. Теперь они могут выборочно выполнять произвольные запросы как таковые:
Python sqlmap.py -u localhost: 8080 / sql-инъекция-примеры / уязвимые-сервисы / фильмы / --sql-query = ”ВЫБРАТЬ a.first_name, a.last_name, count (*) ИЗ фильма f ПРИСОЕДИНЯЙТЕСЬ film_actor fa USING (film_id) ПРИСОЕДИНЯЙТЕСЬ к актеру и ИСПОЛЬЗУЮЩЕМУ (идентификатор_актера) ГРУППА ПО АКТЕР_ИД, аfirst_name, a.last_name ORDER BY count (*) DESC LIMIT 1 ”
Вышеупомянутый запрос найдет актера, сыгравшего в большинстве фильмов:
Не все запросы синтаксически можно внедрить во все уязвимости во всех СУБД. Но пример Little Bobby Tables — это не то, чего хотят большинство злоумышленников: причинение ущерба вашей системе. Большинство злоумышленников не хотят, чтобы их видели, чтобы они могли незаметно украсть ваши данные.
Другие функции sqlmap
sqlmap не останавливается на достигнутом.sqlmap позволяет переключать пользователей базы данных, выясняя пароли root или DBA с помощью грубой силы. Как только вы получите доступ к пользователю или роли с более высокими грантами и в зависимости от реальной СУБД, sqlmap также позволит вам:
- Загрузить и выполнить сценарий SQL
- Внедрение и выполнение пользовательских пользовательских функций
- Чтение или запись файлов в файловой системе сервера базы данных
- Откройте оболочку в операционной системе сервера базы данных
- Управление реестром Windows сервера баз данных
На менее серьезном замечании, sqlmap может быть отличным инструментом администрирования сервера баз данных, если вы забыли учетные данные своей собственной локальной среды разработки базы данных!
Противодействие
В принципе, полностью предотвратить уязвимости, связанные с SQL, практически невозможно.SQL — это динамически интерпретируемый язык, поэтому он гораздо более уязвим для внедрения кода, чем статические языки, такие как Java. В частности, он чрезвычайно уязвим, так как обычно выполняется динамический SQL на основе критериев ввода данных пользователем, например критериев поиска. Очевидно, что и другие языки, интерпретируемые на стороне сервера, также уязвимы, но SQL также является одним из самых популярных языков.
Однако, приняв правильные меры, злоумышленнику будет очень сложно найти уязвимость и использовать ее, не заметив сначала их действий.Помните, что чем меньше информации вы отображаете, тем больше времени занимает sqlmap и тем больше следов он оставляет в журналах вашего сервера, чтобы даже проверить наличие уязвимости.
Вот несколько мер, которым вы должны следовать и применять в своей команде:
Никогда не доверяйте вводу пользователя
Первое и самое главное: никогда не доверяйте вводу пользователя. Даже если ваше приложение используется только 10 пользователями из одной компании через интрасеть, ваша база данных может содержать зарплаты или другие конфиденциальные данные, и злонамеренный сотрудник может сбросить эти данные.
Обратите внимание, что вводу пользователя нельзя доверять и в других сценариях, например при доступе к файловой системе.
Используйте как можно меньше пользовательского ввода
Вы должны не только не доверять пользовательскому вводу, вы также должны использовать как можно меньше пользовательского ввода непосредственно в вашем SQL. Например, если пользователи могут сделать выбор в раскрывающемся списке HTML. Вместо того, чтобы просто встраивать значение параметра HTTP POST в ваш оператор SQL, сначала проанализируйте его и инкапсулируйте в соответствующий заранее определенный тип.В Java хорошим соответствием опциям HTML может быть тип enum.
Вы знаете свои данные лучше всего, и поэтому вам следует проверять все вводимые пользователем данные на сервере сразу после их получения.
Использовать переменные связывания
Постарайтесь выразить ваши операторы SQL как можно более статично. Конкатенация строк SQL позволяет младшим разработчикам легко допускать ошибки. Если вы руководитель группы инженеров, вы обязаны помочь членам своей команды избежать таких ошибок.
Самый простой способ предотвратить SQL-инъекцию — использовать переменные связывания. Драйверы JDBC (если вы работаете с Java) и базы данных содержат очень мало ошибок в этой области, так что потоковая передача переменных привязки к базе данных не приведет к возникновению какой-либо уязвимости, которую можно легко использовать.
Использовать инструменты статического анализа кода
Если вы используете Java и JDBC напрямую, вы можете обнаружить некоторые уязвимости с помощью инструментов статического анализа кода, таких как FindBugs ™ или Alvor.Очевидно, что такие инструменты могут обнаруживать SQL-инъекцию только тогда, когда операторы SQL «относительно статичны». Если вы распределите создание строки критериев SQL по нескольким модулям кода, инструмент статического анализа кода не сможет обнаружить уязвимости.
Использовать sqlmap
sqlmap не обязательно является инструментом для злонамеренных действий. Это бесплатно и с открытым исходным кодом, доступным по лицензии GPLv2. Вы можете использовать его в своих тестовых наборах непрерывной интеграции для обнаружения регрессий SQL-инъекций.Поскольку вы очень хорошо знаете свое собственное программное обеспечение, вы можете настроить sqlmap с различными параметрами, которые дадут ему «фору», поскольку ему не нужно будет выяснять, работаете ли вы с MySQL, PostgreSQL, Oracle и т. Д.
Применить абстракцию SQL
В дополнение к очень низкоуровневому API (JDBC в Java, собственные функции в PHP и т. Д.), Большинство платформ также имеют множество высокоуровневых API, которые абстрагируют язык SQL не на основе строк. Однако не обманывайтесь, думая, что абстракция языка SQL сама по себе защищает вас от внедрения кода.Популярные фреймворки, такие как Hibernate или JPA, используют языки запросов на основе строк, такие как HQL или JPQL. Эти языки менее уязвимы, чем SQL, потому что они менее выразительны. Но они все еще уязвимы!
В .NET примером абстракции SQL, не основанной на строках, является LINQ-to-SQL. В Java примерами являются SQLJ, JPA CriteriaQuery или jOOQ. Наш предыдущий пример запроса будет преобразован в эти:
Статический SQL с SQLJ Статически типизированный LINQ-to-SQL с LINQ Статически типизированный JPQL с запросом критериев JPA Статически типизированный SQL с jOOQ
Помимо того, что SQL-инъекция намного безопаснее за счет принудительного использования переменных связывания, статически типизированные внутренние предметно-зависимые языки также помогают предотвратить синтаксические ошибки.В случае jOOQ это дополнительно поддерживается генератором исходного кода jOOQ, который будет генерировать литералы Java для таблиц и столбцов.
Тщательно продумайте GRANT базы данных и политики безопасности
Не используйте вслепую пользователя root MySQL без разумного пароля для всего (или пользователя postgres в PostgreSQL, или пользователя dbo в SQL Server и т. Д.). Создайте хорошо продуманную стратегию безопасности, при которой пользователям предоставляется доступ только к тем элементам, к которым им действительно нужно получить доступ.
Часто хорошей идеей также является добавление дополнительного уровня косвенного доступа к безопасности внутри вашей базы данных с помощью представлений базы данных. Например, веб-пользователям предоставляется доступ к нескольким представлениям только для чтения, а не непосредственно к таблицам. Это позволит вам динамически ограничивать, кто и какими данными может манипулировать.
Эта мера не предотвратит SQL-инъекцию, но сведет к минимуму возможный ущерб, который злоумышленник может нанести после проникновения в вашу систему.
Использовать межсетевые экраны
Если вы разрабатываете веб-приложение, вы можете выбрать один из множества брандмауэров, которые имеют некоторые функции защиты от SQL-инъекций.Помимо простого сопоставления с образцом на основе регулярных выражений (что на самом деле не является надежным или полезным), такой сервер ввода также должен поддерживать две очень мощные функции, которые помогут вам предотвратить ошибки при приеме пользовательского ввода через параметры HTTP GET и POST:
- Шифрование URL-адресов: все URL-адреса приложений зашифрованы и никогда не передаются клиенту. Таким образом, невозможно вмешаться в параметры GET. Параметры GET даже невозможно распознать. Недостатком этой функции является тот факт, что может быть довольно сложно реализовать современное многофункциональное Интернет-приложение на основе JavaScript, потому что… вы не можете изменять параметры GET.
- Защита формы: все допустимые значения, которые могут быть выбраны в форме, известны серверу ввода и проверяются с помощью зашифрованного хэша. Это делает невозможным вмешательство в значения HTML
Примером сервера входа, реализующего вышеуказанное, является Airlock швейцарской компании Ergon Informatik AG.
Другие меры
Было проведено много исследований на тему мер противодействия SQL-инъекциям. Интересные публикации:
Заключение
Даже с недавними альтернативными моделями хранения данных и доступа, которые стали известны как NoSQL, SQL как язык запросов и взаимодействия с базами данных по-прежнему практически не вызывает проблем. Основные поставщики SQL внедряют все более совершенные функции в стандарт SQL. SQL здесь, чтобы остаться.
Тем не менее, многие команды разработчиков не знают о масштабах этой угрозы. В миллионах строк кода приложения этого может быть достаточно, если одна уязвимость SQL обнаружена злоумышленником, работающим с автоматическими инструментами, такими как sqlmap. Такой объект может извлекать все данные из вашей базы данных и / или выполнять вредоносный код на ваших серверах. Это может привести к захвату сервера.
В обязанности архитектора программного обеспечения или технического руководителя входит минимизация риска создания уязвимостей SQL-инъекций, поскольку даже опытные разработчики могут случайно создать такую уязвимость.Самая простая и эффективная мера — по возможности использовать связываемые переменные и статический SQL. Более сложные контрмеры могут быть достигнуты путем интенсивного обучения, проверки, тестирования и использования серверов входа.
Как анализировать дамп стека SQL-сервера
Как производственный администратор базы данных SQL Server, в какой-то момент вам придется иметь дело с дампом стека. Дамп стека — это файл, который записывается на диск с расширением «.mdmp», когда SQL Server обнаруживает рабочее состояние, которое не имеет встроенной ошибки для обработки.Он содержит стеки вызовов и информацию о памяти потоков, запущенных, когда возникла эта ситуация, и сделано для того, чтобы его можно было использовать для устранения неполадок постфактум.
Причина возникновения этого типа состояния ошибки довольно сильно варьируется, и она может варьироваться от проблем с планированием ЦП, проблем с микросхемами ОЗУ, очень большой задержки ввода-вывода, драйверов связанного сервера и т. Д. В худшем случае дамп стека может вызывает серьезную нестабильность системы и может вызвать отказоустойчивость кластера или перезапуск службы SQL Server.В этом сообщении блога мы сосредоточимся на анализе довольно распространенного состояния планировщика невыполнения требований.
Поскольку Microsoft владеет исходным кодом SQL Server, они лучше всего подходят для устранения этих необработанных условий. Однако это не означает, что мы не можем сами провести некоторый анализ и во многих случаях получить твердое представление о том, что вызывает проблему. Таким образом, знание того, как проводить этот анализ, может иметь решающее значение для поиска быстрых обходных путей, пока вы работаете со службой поддержки Microsoft, чтобы найти основную причину и постоянное исправление.
А теперь перейдем к практической части и приступим!
- Первое, что вам нужно сделать, это получить дамп стека для анализа. Если вы уже сталкивались с этим в своей системе, вы можете найти файлы .mdmp в каталоге журнала, где находится SQL ERRORLOG.
- Перейдите по этой ссылке, загрузите и установите инструменты отладки для Windows. Тот, который нас интересует, называется WinDbg. Есть несколько способов получить инструменты в вашей системе. Я лично загрузил Windows SDK ISO, а затем во время установки выбрал только «Инструменты отладки для Windows».
- Откройте WinDbg (в моем случае он находился в C: \ Program Files \ Windows Kits \ 10 \ Debuggers \ x64), перейдите в File — Open Crash Dump.
-
Теперь инструмент распознал, что этот файл является дампом стека, и что есть ценная информация.
Мы можем проверить, что дамп был сгенерирован из-за состояния «невыдающийся планировщик» и WinDbg обнаружил «сохраненное в нем интересующее исключение».
-
На данный момент мы не можем видеть много деталей, потому что у нас нет общедоступных символов для SQL Server на машине анализа.Общедоступные символы — это файлы, предоставляемые разработчиком программного обеспечения (в данном случае Microsoft), которые предоставляют высокоуровневую информацию о исполняемом файле, чтобы иметь возможность выполнять этот тип отладки. Например, в случае с SQL Server мы хотим видеть имена методов внутри кода C ++. Существуют также частные символы, которые предоставляют еще больше информации, например имена локальных переменных или информацию о строке исходного кода, но они доступны только разработчику приложения, в данном случае поддержке Microsoft.
-
Чтобы получить символы, которые мы загрузим с сервера Microsoft, перейдите в командную строку WinDbg и введите следующее:
.sympath srv * c: \ debugsymbols * https: //msdl.microsoft.com/download/symbols;
Эта команда установит путь символов для инструмента в c: \ debugsymbols и укажет ему на загрузку их с общедоступного URL символа Microsoft.
Чтобы загрузить символы, введите:
. Перезагрузка / ф
Инструмент начнет загрузку файлов и может выдать некоторые ошибки, если не сможет найти символы для некоторых DLL. Это нормально, пока он смог найти символы для SQL Server.
На этом этапе рекомендуется сохранить эту конфигурацию в рабочей области, чтобы нам не приходилось вводить ее каждый раз. Для этого просто зайдите в File — Save Workspace и дайте ему имя. В следующий раз вы можете открыть WinDbg, открыть рабочую область, а затем аварийный дамп, и вам не нужно будет перезагружать символы.
Вернувшись к командному экрану, мы можем проверить, что символы для SQL Server доступны, запустив:
лмвм sqlservr
Мы можем видеть в выводе, что действительно найдено совпадение в наших символах для модуля, упомянутого в дампе, в данном случае основного исполняемого файла SQL Server sqlservr.исполняемый.
Он также предоставляет точную информацию о версии для SQL Server. Например, на приведенном выше снимке экрана указана версия 11.0.6594, которая представляет собой пакет обновления 3 для SQL Server 2012, накопительное обновление №4. Конечно, вы всегда можете получить информацию с самого сервера, но если все, что у вас есть, это файл, то это альтернативный
способ получить его. Знание точной информации о версии важно, поскольку дамп мог быть сгенерирован ошибкой, специфичной для данной версии. -
Хорошо, теперь у нас все готово, но с чего начать анализ содержимого дампа? Имейте в виду, что в дампе есть информация обо всех потоках, активных на момент создания дампа. Однако нас интересует только цепочка, которая действительно вызвала проблему. Самый простой способ начать — позволить WinDbg проанализировать дамп, посмотреть, найдет ли он исключение, и перенаправить вас в этот контекст.
Для этого введите следующую команду:
! Анализировать –v
Эта команда покажет, где найдено исключение, и стек вызовов с ним.
В данном случае я получил:
ntdll! NtWriteFile + 0xa
KERNELBASE! WriteFile + 0xfe
kernel32! WriteFileImplementation + 0x36
sqlmin! DiskWriteAsync + 0xd9
sqlmin! FCB :: AsyncWrite + 0x19a
sqlmin! RecoveryUnit :: GatherWrite + 0xc2
sqlmin! BPool :: LazyWriter + 0x549
sqlmin! Lazywriter + 0x204
sqldk! SOS_Task :: Param :: Execute + 0x21e
sqldk! SOS_Scheduler :: RunTask + 0xa8
sqldk! SOS_Scheduler :: ProcessTasks + 0x29a
sqldk! SchedulerManager :: WorkerEntryPoint + 0x261
sqldk! SystemThread :: RunWorker + 0x8f
sqldk! SystemThreadDispatcher :: ProcessWorker + 0x372
sqldk! SchedulerManager :: ThreadEntryPoint + 0x236
kernel32! BaseThreadInitThunk + 0xd
ntdll! RtlUserThreadStart + 0x1d
Существует предостережение относительно невыполненных дампов планировщика.Иногда стек, который вы анализируете, может быть не тем, который не дает результатов. Причина этого в том, что к моменту создания дампа задача могла действительно быть выполнена. Чтобы прикрыть этот сценарий, SQL Server копирует ошибочный стек на глобальный адрес, доступ к которому мы можем найти в дампе. Это команда для перехода к этой структуре:
.cxr sqlmin! G_copiedStackInfo + 0X20
Эта команда .cxr используется для установки контекста отладчика на конкретный адрес, который мы знаем заранее в этом случае.Вы можете подумать, откуда я придумал этот специальный контекст copiedStackInfo. По правде говоря, это всего лишь знания, которые ходят по Интернету и основаны на информации, опубликованной собственной группой поддержки Microsoft. Например, вы можете увидеть здесь одно сообщение в блоге.
Попав в этот контекст, я получаю стек вызовов с помощью этой команды:
Кс 100
Команда K отображает стек вызовов текущего контекста, буква c означает, что мы хотим, чтобы вывод был «чистым» и отображал только имена модулей и функций.Наконец, 100 означает, что мы хотим видеть до 100 вызовов в стеке. Для этого конкретного дампа оба стека были одинаковыми, однако в других сценариях все могло быть иначе.
-
Теперь, когда стек вызовов доступен, давайте посмотрим, как его читать. Во-первых, помните, что это стек, поэтому метод, вызываемый последним, на самом деле находится наверху. Чтобы следовать логической последовательности событий, нам нужно читать снизу вверх.
В этом конкретном стеке вызовов мы можем видеть следующую последовательность событий:
Планировщик не уступает, выполняя ленивую очистку записи, чтобы очистить грязные страницы и записать их в файл.Затем мы рассматриваем дисковую подсистему, которая либо слишком медленная, либо становится перегруженной, когда это происходит. Обладая этой информацией, мы можем начать рассматривать эти различные факторы, чтобы попытаться облегчить ситуацию:
Давайте посмотрим на другой случай, на этот раз это была ситуация «Тайм-аут блокировки». Давайте посмотрим на шаги:
-
Я открываю рабочее пространство, созданное в предыдущем примере, а затем открываю дамп. Вот результат:
Вверху мы видим тип дампа как «Тайм-аут блокировки» и снова видим, что в нем хранится «интересующее исключение».
-
Мы можем проверить, что символы снова получили, и вот что мы получили:
Мы можем сказать, что по версии это SQL Server 2005 SP4.
-
Мы запускаем! Анализируем –v, и это сгенерированный стек вызовов:
kernel32! RaiseException
sqlservr! CDmpDump :: Дамп
sqlservr! CImageHelper :: DoMiniDump
sqlservr! StackTrace
sqlservr! LatchBase :: DumpOnTimeoutIfNeeded
sqlservr! LatchBase :: PrintWarning
sqlservr! _Chkstk
sqlservr! LatchBase :: AcquireInternal
sqlservr! KeyRangeGenerator :: GetNextRange
sqlservr! IndexDataSetSession :: GetNextRangeForChildScan
sqlservr! IndexDataSetSession :: SetupNextChildSubScan
sqlservr! IndexDataSetSession :: GetNextRowValuesInternal
sqlservr! RowsetNewSS :: FetchNextRow
sqlservr! CQScanTableScanNew :: GetRow
sqlservr! CQScanNLJoinTrivialNew :: GetRow
sqlservr! CQScanNLJoinNew :: GetRowHelper
sqlservr! CQScanNLJoinNew :: GetRowHelper
sqlservr! CQScanSortNew :: BuildSortTable
sqlservr! CQScanSortNew :: OpenHelper
sqlservr! CQScanNLJoinNew :: Открыть
sqlservr! CQScanNew :: OpenHelper
sqlservr! CQScanXProducerNew :: Открыть
sqlservr! FnProducerOpen
sqlservr! FnProducerThread
sqlservr! SubprocEntrypoint
sqlservr! SOS_Task :: Param :: Execute
sqlservr! SOS_Scheduler :: RunTask
sqlservr! SOS_Scheduler :: ProcessTasks
sqlservr! SchedulerManager :: WorkerEntryPoint
sqlservr! SystemThread :: RunWorker
sqlservr! SystemThreadDispatcher :: ProcessWorker
sqlservr! SchedulerManager :: ThreadEntryPoint
-
Стек вызовов выдает следующую последовательность шагов:
— Тема получила задание
— параллельная операция запрашивает сканирование таблицы
— поток запрашивает ряд ключей для работы на
— запрашивается защелка для получения диапазона, и время ожидания истекает
Возвращаясь к журналу ошибок SQL Server примерно во время дампа, у нас есть такие сообщения:
Истекло время ожидания защелки: класс «ACCESS_METHODS_SCAN_RANGE_GENERATOR», идентификатор 00000002042630D0, тип 4, задача 0x00000000055F8B08: 7, время ожидания 300, флаги 0x1a, задача-владелец 0x00000000049B7C18.Продолжаем ждать.
Мы знаем, что ACCESS_METHODS_SCAN_RANGE_GENERATOR — это тип защелки, используемый для распределения работы во время параллельных сканирований, поэтому и журнал, и дамп подтверждают проблему.
-
Альтернативный способ навигации по дампу — поиск в дампе определенной строки. Для этого мы можем использовать команду X:
X *! * DoMiniDump *
Я использую символ * в качестве подстановочного знака, чтобы указать WinDbg заглянуть внутрь любого модуля ( *! ) и найти функцию, содержащую эту строку ( * DoMiniDump * ).Конечно, я получаю такой результат:
00000000`01f6c0d0 sqlservr! CImageHelper :: DoMiniDump
Итак, теперь мы знаем точное имя функции, которое хотим, и можем найти его с помощью этой команды:
! Findstack sqlservr! CImageHelper :: DoMiniDump
И получаем такой результат:
Резьба 054, 1 кадр (а) соответствует
* 15 000000000fc5aba0 0000000001f6f797 sqlservr! CImageHelper :: DoMiniDump + 0x413
Из этого результата мы знаем, что поток, создавший дамп, был №54.Итак, мы переходим к этому потоку с помощью этой команды:
~ 54 с
Символ ~ — это команда для выполнения действия, связанного с потоком, 54 — это номер потока, который нам нужен, а буква s говорит отладчику сделать этот поток текущим.
Наконец, как и в предыдущем примере, мы можем запустить kc 100 и получить стек вызовов, который я упоминал на шаге № 3 выше.
-
Учитывая то, что мы обнаружили, этот случай определенно выглядит как ошибка, связанная с параллелизмом, но по крайней мере мы знаем, что она вызвана операцией параллельного сканирования.Хотя мы получили исправление от службы поддержки, мы могли бы применить обходные пути, чтобы избежать параллельного сканирования посредством индексации, настройки запроса или выполнения запроса без параллелизма на данный момент.
Итак, мы видели пример для «невыполненного планировщика» и «таймаута блокировки», но вы можете применить аналогичный процесс для анализа других типов дампа, таких как «планировщик тупиковых ситуаций», «необработанное исключение» и «нарушение прав доступа».