Каковы плюсы и минусы сценариев Ола против использования плана обслуживания?

9

Не могли бы вы помочь мне понять плюсы и минусы использования решения Ola вместо плана обслуживания? Я подготовил презентацию на основе SQL Pass ( http://www.pass.org/DownloadFile.aspx?File=ebae1b31 ), которую я представлю.

Я также готовлю несколько сценариев, которые не рассматриваются в решении Ola, а в плане обслуживания. Не могли бы вы все помочь мне объяснить это более технически?

Кстати, мы управляем почти 150+ серверами (микс 2008/2012/2014/2016) с помощью решения Ola как минимум на 75% из них. Мне понравилась эта статья Брента Озара. Но в одном из комментариев Брент порекомендовал использовать основанное на сценариях решение для числа серверов, которые у нас есть. https://www.brentozar.com/archive/2012/04/maintenance-plans-roombas-suck-good-way/

sql-server ola-hallengren

— похлопывание
источник

Мы говорим о резервном копировании, обслуживании индекса / статистики, проверке коррупции или обо всём выше перечисленном?

— nkdbajoe

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

— Пэт

2

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

— Цзяо

У вас есть какие-либо данные, чтобы показать, что они лучше или вы просто делаете то, что считаете лучше? Лучший способ решить эту проблему - получить данные о производительности, чтобы показать, почему метод лучше

— Джо У

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

— Ален

13

Я написал здесь

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

Чтобы добавить больше,

Техническое решение Ola широко распространено в сообществе и крупных организациях .
Его открытый исходный код и проблемы могут быть подняты на github / questions с вероятностью очень быстрого его исправления.
Он гибкий и масштабируемый (даже если вы хотите развернуть его на сотнях серверов, просто используйте Install-DbaMaintenanceSolution из dbatools.)
Microsoft потребовалось почти десять лет, чтобы исправить GUI плана обслуживания, который был сам по себе глючным :-)
имеет обширную документацию и часто задаваемые вопросы и постоянно обновляется для размещения новых версий SQL Server.
в предварительной версии вы даже можете запускать резервные копии параллельно.
для решения по обслуживанию индекса вы можете даже рассчитать время, например, если он выполняется более X раз, прервите его.

— Кин Шах
источник

5

Одним из основных преимуществ решения на основе сценариев является простота развертывания, что особенно важно в вашем случае, поскольку у вас более 150 серверов. Попытка развернуть несколько планов обслуживания (т. Е. Как минимум 2, один для системных баз данных и один для пользовательских баз данных) на 150 серверах был бы кошмаром. Поддерживать их когда-то на месте так же много хлопот.

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

В нашем случае у нас есть около 40 экземпляров SQL в нашей среде DEV, и мы используем модифицированные сценарии Ola с функцией множественных подключений SSMS, чтобы иметь возможность развертывать изменения в режиме обслуживания на всех 40 экземплярах одним щелчком мыши. Любые особые случаи обрабатываются нашими модификациями.

— Майк
источник

3

Я не уверен на 100% в его сценариях, но пользовательские сценарии намного лучше планов обслуживания. Встроенные планы будут перестраивать каждый индекс таблицы независимо от степени фрагментации. Если у вас есть Always On, это создаст шторм трафика.

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

В прошлый раз, когда я использовал планы обслуживания, у меня была таблица строк на 300 миллионов, и Always On будет отставать на несколько часов, когда начинается перестройка индекса и возникают проблемы с переполнением журнала транзакций. Вернулись к сценариям и все прошло.

— Alen
источник

1

Первоначально я написал свой собственный для SQL 2005 примерно в 2007 году. Я использовал то, что книги имели в качестве основы, и немного изменил его. В то время казалось, что большинство людей используют планы, а теперь, похоже, все изменилось. И до того, как я начал делать вещи для DBA, у предыдущего DBA были свои скрипты для SQL 2000. Единственное, что я отличал, это то, что я перестроил все. Быстрее перестроить что-либо более чем на 20% или 30%, чем реорганизовать. Для резервных копий мы всегда использовали сторонние продукты

— Ален

1

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

— SQLDBAWithABeard
источник

0

Планы техобслуживания в большинстве случаев будут хорошими. Сценарии Олы Хелленгрена в большинстве случаев будут отлично работать.

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

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

Если он работает с базами данных более 20 лет, он уже написал свои собственные сценарии обслуживания. Примерно в то время, когда вы учились водить машину, вероятно, появился какой-то молодой панк в грузовых шортах и сальто, которые были похожи на «эй, старый хулиган, планы обслуживания лучше - и стягивай штаны, ты выглядишь смешно! ».

Затем произошла, вероятно, 4-летняя битва, когда юный и здоровый ребёнок включался в план обслуживания, когда мог. Теперь этот другой молодой панк с узкими джинсами и причудливым галстуком-бабочкой говорит ему вернуться к сценариям. Этого достаточно, чтобы поседеть.

Три вещи для рассмотрения:

Действительно ли эти примеры превосходства Hallengrenite применимы к вашей среде?

Это вызовет у вас реальную проблему, если он использует планы обслуживания?

Если вы убедите его использовать сценарии Хелленгрена и возникнет проблема, сможет ли он решить ее самостоятельно или ему придется вам позвонить?

— Джеймс
источник

Ответьте на первые два вопроса Да. Мы уже видели проблемы с планами обслуживания, и я решил их с помощью решения Ola. На рабочем сервере также было задание сжать журнал (??), которое я немедленно отключил. Третий вопрос, я не знаю. Я не уверен, сможет ли он решить проблемы, созданные самим Планом обслуживания. Когда я спросил его, если мы видим проблемы с этим, что мы должны сделать? Его ответом было позвонить в службу поддержки Microsoft. (??)

— Пэт

@ Пэт, ааа, похоже, он достиг своего предела по принципу Питера. Будьте осторожны, стараясь сделать его лучше - он вряд ли оценит помощь.

— Джеймс