Пять глупых ошибок администраторов БД (DBA)

7 2

 Администраторы БД совершают много ошибок. Когда ошибки касаются производительности, их надо срочно устранять. В этом блоге будем перечислять распространенные ошибки

 Ошибка  №1: Размещение файла  данных и транзакции  БД на одном диске:

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

Ошибка №2: Использование массив RAID-5:

На мой взгляд, следует избегать массив RAID-5. Первая проблема RAID-5 - калькуляция чётности (Parity). Эта операция снижает производительность записи на диск. Вторая проблема RAID-5 заключается в том, что каждая логическая операция записи требует много физической записи. Я рекомендую RAID-10 .

Ошибка №3:Использование нескольких файлов журнала:

Не выгодно использовать несколько файлов журнала в одной БД. Улучшение производительности происходит только за счет изоляции дисков и использования быстрых дисков. Также не рекомендуется включать опцию " Auto growth", хотя для фиксирования размера файла транзакции надо определить оптимальный размер файла, например для БД системы DIRECTUM, я бы порекомендовал 5 Гб, в том случае если используется тип восстановление "Simple mode".

Ошибка №4: Использование одного файла данных для каждого процессора в целях повышения производительности SQL - I/O  операций. Например, если на сервере установлены 2 процессора, то рекомендуется создавать 2 файла данных для каждой БД. Такие рекомендации были очень популярны между администраторами БД (DBA).Опыт работ показал, что они помогают только в случаях с БД Tempdb, но не пользовательской БД (например БД системы DIRECTUM). Для повышения производительности SQL - I/O операцией при работе с пользовательской БД, рекомендуется создавать Filegroups, которые хранятся на разных дисках или массивах.

Ошибка №5: не ограничивать размер памяти, используемой SQL сервером.Очень часто встречал администраторов, которые устанавливают SQL server, и не обращаютвнимание на настройки самого сервера, Minimum и Maximum Memory, по умолчанию Min= 0 и Max=2147483647 Мб ( почти не ограничен),а в этом случае SQL будет использовать всю доступную память, и в результате, ОС и другие установленные на сервере  ПО начинают тормозить.Рекомендуется ограничивать размер памяти, используемой SQL сервером.  Также рекомендуется назначать Minimum Memory ровную Maximum Memory и не забывать об 1Гб как минимум для ОС.

В этом блоге перечисляются только 5 ошибок, но, наверно, есть еще ошибки. Я предлагаю каждому из нас написать о своих глупых ошибках, допущенных при администрировании SQL. Что касается меня, то я когда-то допустил ошибку 1 и 5 ( никому не говорите Подмигивающий). Жду ваших ошибок.

7
Авторизуйтесь, чтобы оценить материал.
Кирилл Нагирный

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

Андрей Клоков

Не знаю насколько частая ошибка, но имела место быть.

В маршруте по входящим письмам есть блок мониторинг, он опрашивает систему на выполнение подзадач с резолюциями по основной задаче. Так вот, чтобы задания приходили быстрее период опроса админ выставил около 5 минут. С ростом количества задач в работе, росла и очеред workflow. Это в свою очередь привело к тому, что задания по задаче могли приходить час и более. А это в свою очередь приводило в ярость пользователей.

Не допускайте подобных ошибок.

 

Авторизуйтесь, чтобы написать комментарий