10 рекомендаций по обслуживанию SQL Server для приложений SAP

Автор: Такаюки Хосино (Takayuki Hoshino)

Соавтор: Юрген Томас (Juergen Thomas)

Технический редактор: Санджай Мишра (Sanjay Mishra)

SQL Server служит отличной платформой баз данных для приложений SAP. В этой статье приводятся рекомендации по обслуживанию базы данных SQL Server для работы в среде SAP.

1. Ежедневно создавайте полную резервную копию базы данных

• С технической точки зрения ничего не мешает создавать резервные копии баз данных SAP в оперативном режиме. Это означает, что конечные пользователи и исполняемые ночью фоновые пакетные задания могут продолжать использовать SAP-приложения без каких-либо проблем, поскольку резервное копирование SQL Server занимает малый объем ресурсов процессора. Однако при резервном копировании в оперативном режиме потребуется высокая пропускная способность дисковой подсистемы ввода вывода, так как SQL Server займется считыванием в устройство резервного копирования каждого занятого экстента. Также может возникнуть и другая проблема, связанная с тем, что все объекты, необходимые для работы SAP (бизнес-данные, метаданные, приложения ABAP и т. д.), расположены в одной базе данных с именем <SID>. Для создания полной резервной копии такой базы данных обычно требуется несколько часов, и это может стать проблемой, особенно в SQL Server 2000, где резервное копирование журналов транзакций не может выполняться во время резервного копирования базы данных. В SQL Server 2005 этой проблемы не имеется.
• Для более быстрого создания резервных копий в оперативном режиме с использованием технологии SAN в SQL Server предусмотрены интерфейсы для сетей SAN различных поставщиков, что позволяет выполнять резервное копирование путем создания моментального снимка или клонировать базы данных SQL Server. Однако необходимость копировать терабайты данных каждую ночь может вызывать перегрузку инфраструктуры резервного копирования. В качестве альтернативы можно предложить разностное резервное копирование базы данных SAP ежедневно и полное резервное копирование по выходным.

 2. Создавайте резервную копию журнала транзакций каждые 10–30 минут

• В случае аварии на рабочем сервере крайне важно иметь возможность восстановить самое последнее состояние базы данных. Для этого используются оперативные или разностные резервные копии базы данных и дополнительно к ним набор последовательных резервных копий журнала транзакций, в идеальном случае позволяющий получить состояние базы данных в момент времени, максимально приближенный к аварии. Именно поэтому, крайне важно регулярно создавать резервные копии журнала транзакций. Если резервная копия журнала транзакций создается только каждые два часа, то в случае аварии не удастся восстановить зафиксированные транзакции за период не более последних двух часов. Чтобы сократить риск потери большого объема зафиксированных бизнес-транзакций в случае аварии, необходимо достаточно часто создавать резервные копии журнала. Во многих эффективно работающих реализациях приемлемой является частота создания резервных копий каждые 10–30 минут. Более того, в сочетании с механизмом доставки журналов SQL Server можно создавать резервные копии журнала транзакций SQL Server каждые 5 минут или даже каждые 2 минуты. Создание копий журнала транзакций SQL Server с минимальным интервалом в одну минуту может быть организовано с помощью агента SQL Server. Помимо сокращения риска потери бизнес-транзакций, в ходе резервного копирования журнала также проводится усечение данных в журнале транзакций SQL Server, что снижает вероятность его переполнения.

3. Создавайте резервную копию системного раздела при изменениях конфигурации

• После любого изменения конфигурации создавайте резервную копию системного раздела. Для восстановления системных разделов используйте автоматическое восстановление системы (ASR) в Windows Server 2003 или другие средства, например, Symantec Ghost или загрузку по сети SAN.

4. Создавайте резервную копию системных баз данных при изменениях конфигурации

• После любого изменения конфигурации создавайте резервную копию системных баз данных (master, msdb, model). В SQL Server 2005 не нужно выполнять резервное копирование базы данных ресурсов, поскольку она не подвергается изменениям и устанавливается вместе с SQL Server 2005.

5. Периодически выполняйте операцию DBCC CHECKDB (в идеальном случае перед полным резервным копированием базы данных)

• В идеальном случае перед резервным копированием базы данных в оперативном режиме следует выполнять проверку согласованности с помощью DBCC CHECKDB. Однако следует заметить, что операция DBCC CHECKDB требует значительного времени и существенного объема ресурсов. Эта операция сильно нагружает рабочие системы SAP, особенно в базах данных размером более терабайта. На типовом оборудовании с хорошей дисковой подсистемой ввода-вывода, обеспечивающей высокую скорость передачи данных, объем передаваемых данных может достигать уровня 100–150 ГБ/ч. Если принять во внимание подобные объемы данных и тот факт, что многие базы данных SAP имеют размер до 10 терабайт или выше, становится очевидно, что выполнение операции DBCC CHECKDB в рабочей системе не всегда практически оправданно. Поэтому многие пользователи предпочитают не выполнять операцию DBCC CHECKDB. Хотя за последнее десятилетие все аппаратные и программные компоненты стали более надежными, физическое повреждение систем хранения данных по-прежнему возможно. Одной из причин физического повреждения является аварийное отключение электроэнергии в случае, когда для аппаратных компонентов отсутствует резервное питание от аккумуляторов. Другой причиной может быть физическое повреждение соединительных кабелей или компонентов оборудования. В случаях масштабного повреждения единственным решением будет восстановление базы данных SAP из резервных копий и последующее применение журналов транзакций вплоть до самого последнего. Чтобы обнаружить физические повреждения на ранних этапах, проверить надежность метода резервного копирования и сократить отрицательный эффект физических повреждений, необходимо принять следующие меры.
• Регулярно выполняйте операцию DBCC CHECKDB. Эту операцию можно выполнять в изолированной системе, где работает восстановленный образ рабочей среды. В такой системе высокие требования операции DBCC CHECKDB к объему ресурсов и ее длительная работа не будут проблемой, поскольку ее выполнение не повлияет на пользователей в рабочей среде.
• Проверяйте возможность фактического восстановления базы данных SAP из оперативной или разностной копии, а также и по журналу транзакций. Сам факт наличия резервной копии на ленточном носителе еще не означает, что данные на нем находятся в согласованном состоянии, и не гарантирует возможность их считывания. Оборудование ленточных накопителей и ленточные кассеты могут отказать после нескольких лет использования, и не следует допускать такой ситуации, когда данные на лентах есть, но считать их невозможно. Наличие резервной копии в хранилище само по себе не означает возможности восстановления данных в случае аварии. Необходимо также проверять возможность чтения данных с резервной копии.
• Для баз данных объемом в несколько терабайтов поддерживайте вторую копию в наиболее актуальном состоянии, используя для этого доставку журналов или зеркалирование баз данных. Оба этих метода обеспечения высокого уровня доступности осуществляют разделение аппаратных компонентов и, следовательно, позволяют создать физически согласованный образ рабочей базы данных на вторичном узле.

6. Следите ежемесячно за выходящими обновлениями безопасности (и устанавливайте их в случае необходимости)

• Для большинства клиентов SAP самым важным требованием является высокий уровень доступности. Они не могут себе позволить останавливать и перезапускать серверы SAP для установки обновлений безопасности, особенно если по всему миру используется один и тот же экземпляр SAP. Кроме того, перед установкой обновлений безопасности необходимо протестировать совместимость с ними работающих серверов. По этим причинам одним из наиболее подходящих сценариев для пользователей SAP будет тщательное изучение обновлений и сокращение частоты их установки по возможности до нуля. Разумными мерами по повышению безопасности будет фильтрация ненужных пакетов, отключение ненужных служб и т. д.
• Если используется антивирусный монитор, работающий в реальном времени, рекомендуется исключить из списка отслеживаемых файлы баз данных SQL Server (в том числе файлы данных, файлы журналов транзакций, файлы tempdb и других системных баз данных). Если выполняется резервное копирование на диск, также исключите файлы резервных копий баз данных и журналов транзакций.

7. Следите за выходом обновлений для драйверов оборудования и прошивок (и устанавливайте их в случае необходимости)

• Среди стандартных серверов отмечены серьезные проблемы, вызванные ошибками в драйверах оборудования и прошивках. Иногда выявить подобные проблемы в корпорации Майкрософт затруднительно; кроме того, компании-производители в некоторых случаях не обеспечивают достаточный уровень поддержки для пользователей типовых серверов. Поэтому регулярное обновление драйверов и прошивок становится обязанностью клиента. Перед обновлением драйверов на рабочих типовых серверах необходимо тщательно протестировать их в тестовой и изолированной системах. Причиной физического рассогласования данных в базе данных может стать малейшая неточность в драйвере адаптера шины (HBA) или платы SCSI. В этом отношении драйверы и прошивки отличаются от прочих программных компонентов.

8. Еженедельно или ежемесячно обновляйте статистику по самым крупным таблицам

• В SQL Server предусмотрены два параметра для обновления статистики: auto create statistics и auto update statistics. Оба параметра по умолчанию включены. Компания SAP рекомендует оставить их включенными. Возможны случаи, когда автоматическое обновление статистики не позволяет добиться удовлетворительной производительности. В частности, такой случай произошел в SAP BW. Проблема была устранена с помощью функциональности SAP BW, которая описана в SAP-ноте OSS #849062. Имейте в виду, что автоматическое обновление статистики выполняется только для таблиц, содержащих более 500 строк. В исключительных случаях, когда рост данных происходит в одном направлении, рекомендуется регулярно выполнять по расписанию явное обновление статистики для отдельных столбцов таблицы. Однако не следует обновлять общую статистику вручную. Если в результате анализа проблем с производительностью обнаружено, что их причиной является недостаточно актуальная статистика для какого-то индекса или столбца, решить эти проблемы часто помогает простое увеличение частоты обновления статистики для этого индекса или столбца.

9. Перестройте или дефрагментируйте самые важные индексы

• Влияние реорганизации таблиц и индексов на производительность зависит от того, размещвются ли страницы индекса на SSD, от типа выполняемого запроса и доступной пропускной способности дискового ввода-вывода в системе. Если рассматривать ситуации (1) средняя плотность страниц <80 % или (2) фрагментация логического сканирования > 40 % как безусловный повод начать реорганизацию, это может обернуться бессмысленной потерей времени и ресурсов по следующим причинам:
• некоторые таблицы очередей SAP всегда будут отображаться как сильно фрагментированные;
• запросы, считывающие одну строку или небольшое число строк (а таковыми являются большинство запросов SAP), не получают выигрыш от реорганизации таблиц;
• если на сервере базы данных имеется достаточно ресурсов памяти и пропускной способности ввода-вывода для SQL Server, отрицательный эффект фрагментации таблиц может быть невелик.
• Многие пользователи никогда не проводят реорганизацию таблиц с целью повышения производительности запросов. Однако некоторые пользователи выполняют реорганизацию таблиц, чтобы сжать их после архивации данных SAP. Не все таблицы организуются и сортируются с учетом критериев архивирования. Поэтому может возникнуть ситуация, когда после удаления 25 % таблицы ее размер уменьшится только на 10 %. Чтобы освободить больше местапосле архивирования, можно для участвующих в архивировании таблиц запустить операцию DBCC INDEXDEFRAG. Операция DBCC INDEXDEFRAG выполнит сжатие данных, содержащихся на страницах таблицы. Операция DBCC INDEXDEFRAG считает отдельной транзакцией каждое перемещение группы строк на одну страницу. Поэтому запуск DBCC INDEXDEFRAG вызовет выполнение большого числа небольших транзакций. В случае создания индекса, напротив, вся задача создания индекса считается одной большой транзакцией. Операция DBCC INDEXDEFRAG потребляет небольшой объем ресурсов процессора, однако создает серьезную нагрузку на дисковую подсистему ввода-вывода. Поэтому не следует одновременно запускать слишком много команд DBCC INDEXDEFRAG. Для крупных таблиц не следует проводить полную реорганизацию путем повторного создания кластеризованных индексов, поскольку этот процесс вызывает большое число операций с журналом транзакций.
• Если для размещения файлов баз данных используется диск или массив SSD дисков, необходимось в дефрагментации может стать существенно ниже.

10. Используйте средство мониторинга работоспособности для контроля производительности, доступности и т. д.

• Продолжительность незапланированных простоев зависит от скорости, с которой администраторы получают сведения о сбоях системы, и о времени, через которое они могут приступить к процессу восстановления. Администраторы SAP должны знать, что механизм автоматического перехода на другой ресурс в службах кластеров (Майкрософт) или зеркалирование базы данных позволяет обеспечить постоянную доступность системы. Однако переход на резервный ресурс вызывает откат открытых транзакций на стороне базы данных, который в свою очередь приведет к откату бизнес-транзакций на стороне SAP. Прерывание таких цепочек процессов и недоступность данных могут привести к серьезным последствиям (например, в случае расчета платежной ведомости). Поэтому отслеживание состояния системы и оповещение о случаях переключения на резервный ресурс крайне важны для скорейшего перезапуска прерванных бизнес-процессов SAP.

В документе SAP и Microsoft SQL Server 2005: рекомендации по обеспечению высокого уровня доступности, производительности и масштабируемости (на английском языке) (5,5 МБ) более подробно описаны рекомендации по настройке SAP в SQL Server 2005.