ИТ Блог. Работа с базой данных (MySQL, CouchDB, MariaDB, MongoDB)
Вы когда-нибудь сталкивались с ситуацией, когда некоторые из ваших безобидно выглядящих действий вызывали производственные проблемы, и это было слишком много? Что ж, мы надеемся, что нет, потому что это, конечно, не из приятных впечатлений. Одно из таких безобидных действий — выполнение SQL-запросов к производственным базам данных. У нас было это в прошлом, в самом начале карьеры, когда мы удалили некоторые конфигурации как дубликаты, но через неделю обнаружили, что они перестали публиковать сообщения для одного из нижестоящих. Когда вы работаете в сложных системах с таким количеством компонентов, миллионами строк кода, тысячами конфигураций и множеством баз данных с сотнями таблиц, вы должны быть очень осторожны со всем, что вы делаете.
Часто нет реального способа выполнить тестирование, подобное производственному, поэтому лучше всего сохранить ваши изменения как можно более изолированными и ограниченными.
В любом случае, все это предыстория, потому что сегодня мы собираемся поделиться с вами некоторыми советами при выполнении запросов к производственным или действующим базам данных, чтобы предотвратить производственные проблемы. Поскольку многие Java-разработчики не являются экспертами по SQL, но они пишут SQL-запросы , хранимые процедуры и взаимодействуют как с тестовыми, так и с производственными базами данных, существует большая вероятность, что их безобидные на вид действия могут вызвать производственные проблемы.
В то же время в прошлом году был один такой инцидент, когда запрос SELECT разработчика заблокировал какой-то производственный процесс. Безобидный на вид запрос SELECT удерживает блокировку одной из таблиц, которая была необходима процессу, пытающемуся обновить и вставить данные в ту же таблицу.
Разработчик запускает запрос в конце дня и забыл об этом, а на следующее утро обнаруживает, что какая-то важная работа не завершена, и они выполняются с прошлой ночи. В конце концов, были задействованы администраторы баз данных, и они отключили соединение, блокирующее задание, и все было восстановлено.
Что ж, это один из крайних случаев, когда разработчик забывает отменить запрос, когда это занимало много времени, но вероятность того, что произойдет что-то подобное, довольно высока, особенно если у вас есть производственный доступ и вы мало знаете о блокировке в база данных. Лучше всего улучшить свои знания об уровне блокировки и изоляции, но на всякий случай вы можете также следовать следующим советам при выполнении запросов SQL в производственной среде:
Это может вызвать производственную проблему, если какое-то задание также выполняется и пытается обновить ту же таблицу, которую вы запрашиваете. Запуская NOLOCK, вы снижаете риск блокировки и взаимоблокировки, например
SELECT Id, Name, Address from Employee with (NOLOCK) where Id= 2
Когда вы запускаете свой запрос с подсказкой NOLOCK, он указывает механизму запросов не выдавать разделяемые блокировки и не соблюдает эксклюзивные блокировки. Когда вы используете опцию NOLOCK, можно прочитать незафиксированную транзакцию или набор страниц, которые откатываются в середине чтения.
Возможны грязные чтения. Однако стоит отметить, что этот параметр применяется только к оператору SELECT и доступен для Microsoft SQL Server.
По возможности всегда выполняйте запрос на резервном или дополнительном сервере, а не на основном сервере. Только в том случае, если вы просто не можете использовать вторичный сервер, потому что считаете, что данные не являются наиболее актуальными для первичного использования, но суть в том, чтобы не касаться первичного или главного сервера в рабочие часы.
Это то же самое правило, о котором мы могли сказать вам раньше, объясняя команды UNIX. Подобно команде UNIX, которую вы должны протестировать на промежуточных таблицах перед запуском на производственных машинах, вы также должны сначала запустить свой запрос в среде QA или UAT, прежде чем запускать их в производственной среде. Это не только дает вам хорошее представление о том, чего ожидать, но также избавляет вас от синтаксических ошибок и случайных ошибок при производстве.
Если вы работаете в системе с определенными рыночными часами, например, на фондовых биржах, которые работают с 9 утра до 4 вечера, вам следует избегать касания производственной базы данных в течение этого периода и выполнять запросы только в нерабочее время. В рыночные часы в БД происходит много активности, и всегда есть большая вероятность, что ваши безобидные запросы SELECT могут им помешать.
Если вы работаете не в одиночку и у вас есть несколько членов команды, вы всегда можете попросить своих коллег провести четырехглазную проверку запроса, который вы хотите запустить в производственной среде. Еще лучше, если вы можете просмотреть свои запросы от администраторов баз данных.
Вот и все о некоторых важных советах, которые следует помнить при запросе к производственной базе данных. Вы также должны узнать больше о том, как база данных выполняет ваш SQL-запрос, например, как работает индекс, как работает блокировка, сканирование таблицы, сканирование строки, блокировка на уровне таблицы или блокировка на уровне строки и т. д. Если вы хорошо знаете эти основы, вы можете предсказывать поведение ваших запросов более детерминированно и потенциально избегать неприятных сюрпризов.
Спасибо, что прочитали эту статью, если вам нравятся эти простые советы по безопасности при выполнении SQL-запросов в производственной среде, поделитесь, пожалуйста, со своими друзьями и коллегами. Это очень помогает.
(1 оценок, среднее: 5,00 из 5)
Загрузка...
