Новые функциональные возможности MS SQL Server 2012, которые стоит учитывать при поддержке системы DIRECTUM

13 7

MS SQL Server 2012 является первым серьезным обновлением системы с момента выхода SQL Server 2008 R2. Что касается улучшений, которые появились в MS SQL Server 2012, то вендор делает упор на четырех моментах:

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

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

Компания Microsoft откликнулась на мольбы системных администраторов

1. Автономные базы данных

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

Подробнее об автономных БД можно почитать тут: http://msdn.microsoft.com/ru-ru/library/ff929071.aspx 

2. Поддержка режима Server Core

Режим установки Server Core предназначен для серверных сетевых приложений, обеспечивающих работу сервисных служб, для которых отсутствует необходимость в наличии графического интерфейса. Невозможность функционирования предыдущих версий SQL Server в режиме Server Core не оставляла выбора системным инженерам, приходилось использовать Windows Server с графическим интерфейсом. Появление поддержки режима Server Core (http://msdn.microsoft.com/ru-ru/library/ms143506.aspx) в SQL Server 2012 позволяет реализовать более экономичные и эффективные варианты установки SQL Server, а также снижает потенциальную угрозу безопасности и сокращает количество установок исправлений.

3. Интеграция с Windows Azure

Функциональные возможности SQL Server 2012 позволяют делать резервные копии баз данных на BLOB-хранилище Windows Azure, а также восстанавливать базы данных из этих резервных копий. Но в этой версии SQL Server можно выполнять инструкции BACKUP и RESTORE только с помощью tsql или SMO, функции резервного копирования и восстановления на хранилище WIndows Azure с помощью мастера архивации или восстановления Management Studio недоступны (http://technet.microsoft.com/ru-ru/library/jj919148.aspx).

4. Новые инструменты миграции и обновления

В MS SQL Server 2012 появились инструменты Upgrade Advisor и Distributed Replay, которые позволяют проводить детальный анализ и тестирование приложений SQL Server до их обновления (http://msdn.microsoft.com/en-us/library/bb677622.aspx). Благодаря этому ИТ-специалисты всегда будут знать, как обновление может повлиять на работу приложения. Инструмент SQL Server Migration Assistant (SSMA) позволяет автоматизировать миграцию баз данных других производителей на платформу SQL Server 2012 (http://technet.microsoft.com/ru-ru/magazine/hh334645.aspx).

Повышение производительности СУБД

1. Технология xVelocity

В SQL Server встроена технология xVelocity (http://technet.microsoft.com/ru-ru/library/hh922900.aspx), которая позволяет в разы увеличить производительность хранилищ данных и приложений бизнес-аналитики. Так, за счет использования индекса ColumnStore (колоночного индекса) в xVelocity скорость выполнения запросов к хранилищам данных возрастает в 10-100 раз для соединений типа «звезда» (http://blogs.technet.com/b/dataplatforminsider/archive/2012/03/08/introducing-xvelocity-in-memory-technologies-in-sql-server-2012-for-10-100x-performance.aspx).  

Колоночные индексы позволяют хранить данные по столбцам и в ответ на запросы возвращать только нужные столбцы. Существует статья, в которой приводится довольно полное представление о колоночных индексах и о том, как и в каком случае их рекомендуется использовать: http://www.sql.ru/blogs/t-sql/1495

2. Группы доступности AlwaysOn. 

Самым важным компонентом SQL Server 2012 является новая технология обеспечения высокой доступности базы данных (http://msdn.microsoft.com/ru-ru/library/hh510230.aspx). По сути, группы доступности AlwaysOn представляют собой результат эволюции зеркалирования баз данных. 

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

Из реализованных нововведений необходимо отметить наличие групп доступности (Availability Groups), которые обеспечивают возможность конфигурировать несколько баз данных как единое целое и создавать активный вторичный узел (Active secondary), который разгружает основной сервер для обеспечения таких "фоновых" процессов, как создание резервных копий, отчетов и так далее. Такой подход не только увеличивает производительность системы, но и минимизирует затраты на аппаратное обеспечение. 

К сожалению, технология AlwaysOn доступна только в редакции MS SQL Server 2012 Enterprise (http://blogs.technet.com/b/canitpro/archive/2013/08/20/step-by-step-creating-a-sql-server-2012-alwayson-availability-group.aspx).

Упрощение процесса лицензирования

SQL Server 2012 будет выпускаться в трех основных редакциях: 

  • Enterprise — полнофункциональная версия продукта;
  • Business Intelligence — в данной редакции включены все возможности бизнес-аналитики, но отсутствуют некоторые компоненты обеспечения высокого уровня доступности;
  • Standard — предоставляет основные возможности реляционной модели и бизнес-аналитики.

Также доступны ограниченные редакции: Developer, Express и Compact.

Изменения коснулись также и модели лицензирования. Для SQL Server 2012 применяется новая модель лицензирования, предусматривающая плату за ядро процессора. Для Enterprise возможен только такой вариант лицензирования. Для Business Intelligence предусмотрено лицензирование на сервер с клиентскими лицензиями. Для Standard возможно лицензирование на ядро, либо на сервер с клиентскими лицензиями.

Для подробного изучения вопроса лицензирования MS SQL Server 2012 можно воспользоваться  следующим материалом: http://www.microsoft.com/sqlserver/ru/ru/get-sql-server/licensing.aspx.

Повышаем производительность системы DIRECTUM

Приведем основные рекомендации, позволяющие повысить производительность системы DIRECTUM (Таблица 1). Большинство приведенных рекомендаций имеют общий характер и не зависят от версии MS SQL Server. Рекомендации для MS SQL Server 2012 соответственным образом отмечены.

Таблица 1. Рекомендации по повышению производительности системы DIRECTUM версии 5.0 и выше

Способ повышения производительности

Описание

Применение колоночных индексов (MS SQL Server 2012)

Рекомендуется применять, если:

  • оптимизируется большая таблица с большим объемом данных;
  • большинство запросов соответствует образцу звездообразного объединения или влекут за собой сканирование и агрегацию больших объемов данных;
  • новые данные загружаются в таблицу в нерабочее время, когда нагрузка на СУБД небольшая, перестройка колоночных индексов в MS SQL Server 2012 довольно ресурсоемкий процесс;
  • объем данных таблицы постоянно растет;
  • применение колоночных индексов дало положительные результаты.

Не рекомендуется использовать, если:

  • оптимизируется маленькая таблица с нестабильным объемом данных;
  • большинство запросов простые и точечные;
  • применение колоночных индексов на дало положительных результатов.

Группы доступности AlwaysOn (MS SQL Server 2012)

Рекомендуется использовать, если существующий сервер не справляется с большим количеством запросов по чтению. В настоящее время DIRECTUM 5.0 использует только возможность перераспределения.

Оптимизация настроек СУБД 

1. Задавать верхнюю границу потребляемого СУБД объема памяти. Рекомендуемое значение объема памяти, выделяемого СУБД, берется из разницы между размером ОЗУ и объемом, необходимым для функционирования ОС (порядка 2 Гб).

2. Размещение TempDB на отдельном физическом носителе. В средах с интенсивным использованием SQL производительность повышается за счет обеспечения параллельного выполнения операций записи/чтения базы tempdb с операциями чтения/записи операционной системы.

Оптимизация содержимого БД 

1. Хранить электронные документы в файловом хранилище DIRECTUM . Использование файловых хранилищ приведет к уменьшению объема базы данных, что позволит ускорить операции ввода-вывода(запросы к БД, резервное копирование и т.д). В файловое хранилище рекомендуется помещать редко изменяемые (или редко используемые, устаревшие) документы и документы объемом более 50 Мб.

2. Очистка папок пользователей "Входящие" и "Исходящие". Наличие более 100 ссылок в этих папках существенно повышает нагрузку на СУБД и снижает производительность клиентского приложения DIRECTUM .

3. Использование компоненты Текущий период. Использование данной компоненты при работе в системе ограничивает список записей в справочниках системы. Компонента работает на стороне серверной части и при ее включении ускоряется выборка данных из БД и исчезают накладные расходы на доставку избыточных данных пользователю по сети.

4. Минимизация числа пользователей с правами Администратора. Такие пользователи могут вносить изменения в работу системы независимо друг от друга и, в случае плохой согласованности, действия Администраторов могут привести к появлению брешей в системе безопасности и повлиять на оптимизацию перекрестных вычислений различных модулей.

5. Минимизация числа замещений:

  • уменьшить перечень пользователей, для которых настроено замещение;
  • настроить глубину замещения (установка системы AssistantSubstitutionLevel);
  • использование флага Без наследования, в случае если замещающий должен получить права только пользователя, указанного в карточке замещения, и не должен получать прав тех пользователей, которых замещает пользователь, указанный в карточке замещения.

Замещения приводят к замедлению работы системы при формировании соответствующих таблиц прав, а так же увеличивает общее количество ссылок в папках «Входящие» и «Исходящие».

Настройка компонентов системы DIRECTUM

1. Использование последней версии системы DIRECTUM.

2. Рекомендуется задавать число процессов для службы WorkFlow равным числу аппаратных потоков процессоров (виртуальных ядер), что обеспечит повышение производительности за счет ускорения обработки очереди задач (мультипоточность службы) и снижения конкуренции между процессами службы за процессорное время (равенство числа процессов службы и числа аппаратных потоков процессора).

3. Размещение Сервера Сеансов и Сервиса Workflow на выделенном физическом сервере, отличном от сервера СУБД.

Дисковые массивы

Рекомендуемый размер кластера для дисков, на которых располагается БД и TempDB, 64Кб. Это снижает число обращений к диску для получения данных, а следовательно увеличивается производительность.

 

Вместо заключения

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

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

SQL Server 2012 можно сравнить с гоночным болидом: можно получить большую скорость, но при этом необходимо соблюсти множество условий (идеально ровное покрытие дороги, отсутствие резких поворотов). Стоит, однако, заметить, что производительность бизнес-приложения в частности системы DIRECTUM, может зависеть и от множества других факторов (см. таблицу 1).

1 апреля 2014 года был официально опубликован релиз MS SQL Server 2014, который можно загрузить по следующей ссылке: http://msdn.microsoft.com/en-us/library/bb677622.aspx

Ниже приводится перечень нововведений (согласно http://www.microsoft.com/en-us/download/details.aspx?id=39269): 

Нововведение

Описание

Поддержка in-memory OLTP (Hekaton) 

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

Улучшения технологии AlwaysOn

Группа высокой доступности AlwaysOn теперь включает 8 вторичных реплик (против 4-х в SQL Server 2012).

Интеграция с Windows Azure 

1. В Management Studio появился мастер миграции БД с локального сервера в инфраструктуру Windows Azure.

2. Появилась возможность резервного копирования баз данных на BLOB-хранилище Windows Azure с использованием мастера резервного копирования в Management Studio (SSMS).

Системные улучшения 

1. Колоночные индексы используются в версии SQL Server 2012 в режиме «только чтение». В версии 2014 это ограничение снято, колоночные индексы получили возможность обновляться при внесении изменений в данные, как традиционные индексы.

2. Новый тип управляемого ресурса в Регуляторе ресурсов. Регулятор ресурсов используется для разделения вычислительных мощностей компьютера между различными приложениями, обращающимися к SQL Server. В предыдущих версиях к ресурсам относились память и процессорное время. В новой версии к ним добавились  ввод-вывод.

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

Как видим, SQL Server 2014 устраняет некоторые спорные моменты SQL Server 2012, однако SQL Server 2014 продукт довольно новый и какие-либо серьёзные инвестиции в него делать рано. Необходимо дождаться первого пакета обновлений. Кроме того необходимо подождать официальную поддержку SQL Server 2014 системой DIRECTUM.

13
Авторизуйтесь, чтобы оценить материал.
2
Сергей Шумаков

Андрей, можете более развернуто описать сценарий, при котром рекомендация "3. Размещение Сервера Сеансов и Сервиса Workflow на выделенном физическом сервере, отличном от сервера СУБД." имеет смысл? Например, в конфигурации:

System Model:              ProLiant BL460c Gen8
System Type:               x64-based PC
Processor(s):              2 Processor(s) Installed.
                           [01]: Intel64 Family 6 Model 45 Stepping 7 GenuineIntel ~2000 Mhz
                           [02]: Intel64 Family 6 Model 45 Stepping 7 GenuineIntel ~2000 Mhz
Total Physical Memory:     32 733 MB

Не станет ли сетевой интерфейс узким местом при передаче трафика по запросам к workflow? Проводились ли замеры/исследования по этой части?
P.S. по процессорам - 24 логических процессора, 12 ядер.

Андрей Ардашев

Сергей, благодарю за очень правильный вопрос!

Размещение служб на сервере, физически отделенном от сервера с СУБД, имеет смысл в случае если:

1. имеет место загрузка ЦПУ выше 75% продолжительное время (до от получаса до часа);

2. наблюдается существенная нехватка памяти (интенсивный обмен с кэшем, практически полное "выедание" память существующим процессами);

3. снижение скорости быстродействия дисковой подсистемы сервера (падение скорости чтения/записи, очереди чтения/записи).

Если СУБД существенно не нагружает сервер и службы чувствуют себя нормально (снимаемые показатели в норме), то переносить их на отдельный сервер может и не иметь смысла, но необходимо быть внимательным к пиковым нагрузкам, даже приведенных Вами ресурсов может не хватить.

В случае, если мы разбиваем систему на 2 сервера и более, узким местом также становится сеть, по которой компоненты системы будут взаимодействовать друг с другом. В этом случае также необходимо выбирать более подходящий вариант подключения. При небольшой интенсивности запросов может хватить сети с наиболее распространенными характеристиками (100 мб/с, до 0,01% потерь), в иных случаях может потребоваться  подключать серверы через высокоскоростную сеть по оптическим каналам.

Вариантов причин снижения быстродействия системы очень много, а также может быть огромное число схем размещения служб, физических конфигураций серверов. Расследование низкого быстродействия необходимо производить для каждого конкретного случая. В требованиях к системе DIRECTUM представлены рекомендуемые характеристики для серверов СУБД и служб (которые были получены в результате исследований и нагрузочных тестов) и на них стоит опираться при разработке архитектуры. Также компания DIRECTUM предоставляет возможность клиентам (с действующим абонементом) произвести диагностику общего состояния системы совершенно бесплатно 1 раз в год.

Сергей Шумаков

Андрей, спасибо за развернутый ответ.

В разделе "Оптимизация содержимого БД" возможно не помешает еще один пункт относительно содержимого таблицы SBTask. В архитектуре DIRECTUM не предумотрено механизмов "архивирования" отработатнных заданий и задач, и со временем таблица SBTask обретает внушительные размеры. У нас эта таблица имеет размер 97 ГБ, что составляет 65 % от общего объема БД. А как известно Workflow очень активно работает с именно с SBTask. На мой взгляд в набор инструментов администратора напрашивается механизм зачистки этой таблицы и грамотный тюнинг индексов. Если понаблюдать за missing indexes, то можно увидеть что SBTask будет среди лидеров по количеству запросов, которым не хватает соответствующего индекса.

А раздел "Повышаем производительность системы DIRECTUM" - это IMHO тема для отдельной статьи, м.б. кто-то возьмется за ее написание :)
Про размещение файлов БД вообще и про tempdb в частности, было бы резонно отметить что важно не столько разместить БД на отдельном носителе, сколько обеспечить максимально быструю обработку операций ввода-вывода (уровни RAID, выделение изолированных LUN, увеличение числа шпинделей и т.д.). Два быстрых HDD в зеркале дадут не более 150-200 IOPS на запись, в то время как нарезанный том из 32 шпинделей в RAID10 выдаст не менее 3000 IOPS.

Дмитрий Чепель
В архитектуре DIRECTUM не предумотрено механизмов "архивирования" отработатнных заданий и задач, и со временем таблица SBTask обретает внушительные размеры. У нас эта таблица имеет размер 97 ГБ, что составляет 65 % от общего объема БД

Сергей, да, такая проблема есть. Причина роста таблицы - наличие у задачи XML-схемы (SBTask.WorkflowDescription), которая может занимать от нескольких килобайт до нескольких мегабайт для каждой задачи. В результате при активном использовании Workflow и сложных типовых маршрутов размер таблицы SBTask может с течением времени сильно увеличиться.

В следующей версии DIRECTUM (5.1) хранение схемы маршрута будет оптимизировано. По нашим предварительным оценкам, размер таблицы SBTask уменьшится в 5-15 раз в зависимости от характера данных в конкретной системе.

Руслан Бапин

> В следующей версии DIRECTUM (5.1) хранение схемы маршрута будет оптимизировано.

А не планируется ли ввести версионность типовых маршрутов, если да - то в каком виде?

Дмитрий Чепель

А не планируется ли ввести версионность типовых маршрутов, если да - то в каком виде?

Руслан, пока нет. Именно с точки зрения размера SBTask версионность ТМ большого эффекта не даст (мы смотрели и в эту сторону) - много данных в схеме уникально для конкретного экземпляра задачи.

Дмитрий Чепель
В следующей версии DIRECTUM (5.1) хранение схемы маршрута будет оптимизировано

Мы решили выпустить этот функционал раньше - он доступен в новом обновлении DIRECTUM 5.0.3

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