Поиск по сайту:

Кто живет надеждой, рискует умереть голодной смертью (Б. Франклин).

5 вещей, о которых следует помнить при выполнении SQL-запросов в производственной базе данных4 мин для чтения

FavoriteLoadingДобавить в избранное
1 Звезда2 Звезды3 Звезды4 Звезды5 Звезд (1 оценок, среднее: 5,00 из 5)
Загрузка...
20 октября 2020
5 вещей, о которых следует помнить при выполнении SQL-запросов в производственной базе данных
Вы когда-нибудь сталкивались с ситуацией, когда некоторые из ваших безобидно выглядящих действий вызывали производственные проблемы, и это было слишком много? Что ж, мы надеемся, что нет, потому что это, конечно, не из приятных впечатлений. Одно из таких безобидных действий – выполнение SQL-запросов к производственным базам данных. У нас было это в прошлом, в самом начале карьеры, когда мы удалили некоторые конфигурации как дубликаты, но через неделю обнаружили, что они перестали публиковать сообщения для одного из нижестоящих. Когда вы работаете в сложных системах с таким количеством компонентов, миллионами строк кода, тысячами конфигураций и множеством баз данных с сотнями таблиц, вы должны быть очень осторожны со всем, что вы делаете.

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

В любом случае, все это предыстория, потому что сегодня мы собираемся поделиться с вами некоторыми советами при выполнении запросов к производственным или действующим базам данных, чтобы предотвратить производственные проблемы. Поскольку многие Java-разработчики не являются экспертами по SQL, но они пишут SQL-запросы , хранимые процедуры и взаимодействуют как с тестовыми, так и с производственными базами данных, существует большая вероятность, что их безобидные на вид действия могут вызвать производственные проблемы.

В то же время в прошлом году был один такой инцидент, когда запрос SELECT разработчика заблокировал какой-то производственный процесс. Безобидный на вид запрос SELECT удерживает блокировку одной из таблиц, которая была необходима процессу, пытающемуся обновить и вставить данные в ту же таблицу.

Разработчик запускает запрос в конце дня и забыл об этом, а на следующее утро обнаруживает, что какая-то важная работа не завершена, и они выполняются с прошлой ночи. В конце концов, были задействованы администраторы баз данных, и они отключили соединение, блокирующее задание, и все было восстановлено.

 

Читать  MySQL. Комментарии в глубину

5 вещей, которые следует учитывать при выполнении запросов SQL к производственным базам данных

Что ж, это один из крайних случаев, когда разработчик забывает отменить запрос, когда это занимало много времени, но вероятность того, что произойдет что-то подобное, довольно высока, особенно если у вас есть производственный доступ и вы мало знаете о блокировке в база данных. Лучше всего улучшить свои знания об уровне блокировки и изоляции, но на всякий случай вы можете также следовать следующим советам при выполнении запросов SQL в производственной среде:

 

1) Всегда запрашивать с опцией NOLOCK

Это может вызвать производственную проблему, если какое-то задание также выполняется и пытается обновить ту же таблицу, которую вы запрашиваете. Запуская NOLOCK, вы снижаете риск блокировки и взаимоблокировки, например

SELECT IdName, Address from Employee with (NOLOCK) where Id2

 

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

Возможны грязные чтения. Однако стоит отметить, что этот параметр применяется только к оператору SELECT и доступен для Microsoft SQL Server.

 

2) Запустите запрос на резервном или дополнительном сервере базы данных

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

 

3) Проверьте свои запросы в UAT/тестовой базе данных перед запуском в производственной среде

Это то же самое правило, о котором мы могли сказать вам раньше, объясняя команды UNIX. Подобно команде UNIX, которую вы должны протестировать на промежуточных таблицах перед запуском на производственных машинах, вы также должны сначала запустить свой запрос в среде QA или UAT, прежде чем запускать их в производственной среде. Это не только дает вам хорошее представление о том, чего ожидать, но также избавляет вас от синтаксических ошибок и случайных ошибок при производстве.

Читать  MySQL Shell AdminAPI. Что нового в 8.0.20?

 

4) Не прикасайтесь к производственной базе данных в рабочие часы

Если вы работаете в системе с определенными рыночными часами, например, на фондовых биржах, которые работают с 9 утра до 4 вечера, вам следует избегать касания производственной базы данных в течение этого периода и выполнять запросы только в нерабочее время. В рыночные часы в БД происходит много активности, и всегда есть большая вероятность, что ваши безобидные запросы SELECT могут им помешать.

 

5) Внимательно проверьте свой SQL-запрос

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

Вот и все о некоторых важных советах, которые следует помнить при запросе к производственной базе данных. Вы также должны узнать больше о том, как база данных выполняет ваш SQL-запрос, например, как работает индекс, как работает блокировка, сканирование таблицы, сканирование строки, блокировка на уровне таблицы или блокировка на уровне строки и т. д. Если вы хорошо знаете эти основы, вы можете предсказывать поведение ваших запросов более детерминированно и потенциально избегать неприятных сюрпризов.

Спасибо, что прочитали эту статью, если вам нравятся эти простые советы по безопасности при выполнении SQL-запросов в производственной среде, поделитесь, пожалуйста, со своими друзьями и коллегами. Это очень помогает.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Читайте также

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам:

Заполните форму и наш менеджер перезвонит Вам в самое ближайшее время!

badge
Обратный звонок 1
Отправить
galka

Спасибо! Ваша заявка принята

close
galka

Спасибо! Ваша заявка принята

close