24x7 против ночного времени

Где я могу найти ресурсы о том, как лучше перейти к работе 24x7? Как крупные компании с большими базами данных достигают этого? Наши ночные работы, такие как

1. очистить старые данные
2. переиндексации
3. обновить статистику

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

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

Первое, что вы захотите определить, это то, что многие операции выполняются круглосуточно и без выходных. Вы можете использовать это время для выполнения технического обслуживания, чтобы уменьшить помехи, которые вы будете иметь в базе данных. Во-вторых, вам нужно будет зарезервировать некоторое время для полного отключения (для таких вещей, как пакеты обновления или миграция базы данных), поэтому вам нужно будет согласовать полное окно обслуживания с вашим руководством. Для конкретных предметов вам нужно будет рассмотреть и спланировать каждый из них, а также соответствующим образом использовать ваши инструменты. Важным моментом является то, что вы должны ПЛАНИРОВАТЬ каждый из них. Любые примеры, которые я привожу, очень «ваши мили могут отличаться».

Резервные копии

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

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

Индекс / ведение статистики

Это наиболее распространенный тип активного обслуживания, с которым вам придется иметь дело. Вы не можете избежать этого, но вы можете смягчить воздействие. Первоначальное эмпирическое правило заключается в том, что вы должны выполнять обслуживание только тех объектов, которые в этом нуждаются. Общие рекомендации - перестраивать только те фрагменты, которые фрагментированы более чем на 30% и содержат более 1000 страниц . Если у вас есть автоматическое обновление статистики , это будет обрабатывать большую часть вашего обслуживания статистики, но ночная работа по поддержанию синхронизации не плохая идея.

Если у вас есть Enterprise Edition, у вас также есть доступ к некоторым другим параметрам для управления обслуживанием. Прежде всего, это перестроение индексов в сети , которое позволит вам перестраивать индексы, пока они еще используются (по сути, он строит индекс бок о бок, а затем заменяет его). Вы также можете использовать секционирование для «больших» таблиц, чтобы сократить необходимое время перестроения.

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

Проверки согласованности DBCC

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

• PHYSICAL_ONLY- Запуск этой опции проверит ваши базы данных на физическом уровне страницы и позволит избежать более инвазивной полной проверки. Это будет охватывать выявление наиболее вероятных видов коррупции.
• Проверка восстановленной копии. Если у вас есть место, вы можете восстановить базу данных в другом экземпляре и запустить проверку DBCC для восстановленной копии. Это расскажет ту же историю о вашей действующей базе данных, но вы, очевидно, не будете вмешиваться в активность. Некоторые другие альтернативы здесь - это запуск DBCC для копии журнала или зеркальной базы данных.

Этот пост содержит более подробную информацию о ваших возможностях.

Пакетные работы / ETL

Это действительно сводится к тому, как вы разрабатываете свои процессы. Ваш ETL всегда может вмешиваться в действующие таблицы OLTP (как и любое другое приложение), поэтому следует помнить о некоторых ключах:

• Запланируйте такую ​​работу вокруг вашего другого обслуживания и в периоды низкой активности.
• Правильный размер работы, чтобы она была как для производительности, так и для того, чтобы пакет не был таким большим, чтобы он блокировал ваш стол на несколько часов. Примеры концов спектра: строка за агонизирующей строкой (RBAR) против удаления из одного миллиона строк.
• Используйте таблицы этапов и автономно обрабатывайте данные, где это необходимо. Прикасайтесь к живому материалу только тогда, когда это абсолютно необходимо.

Вывод

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

Дополнительные ресурсы:

Рекомендации по обслуживанию SQL-навыков VLDB