Управление производительностью баз данных

Управление производительностью  баз данных. 

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

      Производительность  сСУБД определяется несколькими  параметрами.

      Рейтинг tpc (transactions per cent). Для тестирования производительности применяются различные средства, и существует множество тестовых рейтингов. Одним из самых популярных и объективных является tpc-анализ производительности систем. Фактически tpc анализ рассматривает композицию СУБД и аппаратуры, на которой эта СУБД работает. Показатель tpc это отношение количества запросов обрабатываемых за некий промежуток времени к стоимости всей системы.

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

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

      Transaction Processing Performance Council, TPC (Совет по обработке транзакций, http://www.tpc.org) - независимая некоммерческая организация, созданная для исследования обработки транзакций и производительности СУБД и распространения объективной и воспроизводимой информации о производительности в тестах TPC для компьютерной индустрии. Кроме оценки производительности, в рамках тестов TPC рассчитывается относительный критерий производительность/стоимость, позволяющий оценить стоимость программного и аппаратного обеспечения и стоимость владения системой в ходе ее эксплуатации. разные периоды развития индустрии существовали различные модификации тестов TPC.

      Наиболее распространенной версией является TPC-C. Именно его результаты чаще всего приводят в своих презентациях производители серверов и СУБД. Наилучшие результаты по производительности показали  СУБД DB2 9.7  ОС AIX Version 6.1 (tpmC = 10,366,254)

      Oracle 10g Database Standard Edition на Oracle Solaris 10 09/10  (tpmC =   30,249,688). Результаты по Sybase ASE.

       Sybase ASE 15.0.3  на ОС Red Hat Enterprise Linux Adv Platform 5 Update (tpmC =     276,383), Sybase Adaptive Server Enterprise v12.5   ОС HP UX 11.i 64-bit   (tpmC =     140,239), Sybase SQL Anywhere 11.0   ОС Microsoft Windows 2003 x64 Standard R2 SP2 (tpmC =  20,705). Очевидно, что при таких оценках производительности наиболее значимой становится работа администратора и разработчиков, возрастает необходимость оптимального проектирования баз данных.

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

      Также возможна ситуация, когда какой-либо пользователь в хоте выполнения некоторой операции на своем приложении накладывает блокировку на объект базы данных и не снимает ее, например, по причине сбоя приложения. При этом другие пользователи не могут обратиться к этому объекту. Просмотреть информацию о блокировках для всех процессов можно при помощи системной хранимой процедуры sp_lock. В случае необходимости можно принудительно закрыть соединение при помощи команды KILL, передав ей идентификатор процесса.

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

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

      На  вопрос, нужно ли оптимизировать код SQL или нет, могут дать ответ несколько запросов.

1. Просмотр запущенных на сервере процедур  
select 
   sp.spid, 
   suser_name(suid)    as 'Пользователь', 
   pp.DBName           as 'БД', 
   sp.program_name     as 'Приложение', 
   sp.hostname         as 'Компьютер', 
   pp.ObjectName       as 'Процедура', 
   sp.cmd              as 'Команда', 
   sp.status           as 'Статус', 
   sp.linenum          as 'Строка', 
   sp.cpu              as 'ЦПУ', 
   sp.physical_io      as 'Ввод/Вывод', 
   CONVERT(varchar(8),DATEADD(ms,       DATEDIFF(ms,sp.loggedindatetime,GETDATE()), 
                                   CONVERT(datetime,CONVERT(date,sp.loggedindatetime)) 
                              ),108) as 'Время работы', 
   pp.ContextID        as 'Вложенность', 
   ISNULL(pp.OwnerName,'sa') as 'Автор', 
   mps.SQLText         as 'Запрос' 
from 
   master..monProcessProcedures pp, 
   master..sysprocesses         sp, 
   master..monProcessSQLText    mps 
where 
   pp.KPID = sp.kpid AND 
   sp.kpid *= mps.KPID AND 
   pp.SPID != @@spid 
order by 
   sp.physical_io desc , 
   sp.spid, 
   pp.ContextID, 
   mps.LineNumber, 
   mps.SequenceInLine

2. Особенно стоит обратить внимание на этот запрос.

select 
       SPID, 
       ISNULL(object_name(ProcedureID, DBID), "UNKNOWN") as 'Процедура' , 
       ISNULL(db_name(DBID), "UNKNOWN") as 'БД', 
       LineNumber as 'Строка', 
       CpuTime as 'Расход процессора', 
       CONVERT( decimal (18,2 ), ROUND( ( LogicalReads * 4.0 ) / 1024, 2 ) ) as 'Логическое чтение, МБ', 
       StartTime as 'Время запуска' 
 from 
       master..monSysStatement

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

SET showplan ON и

SET fmtonly ON

SET showplan ON отображает шаги выполнения для каждого запроса в пакете, ключи и индексы, используемые при выполнении запроса, порядок соединения и специальные стратегии оптимизатора.

SET fmtonly ON  используется для получения планов запросов в хранимых процедурах, без их фактического выполнения. 

      Для увеличения производительности клиентских приложений необходимо оптимизировать подключения к серверу. Подключиться к Sybase ASE можно разными способами.

1. Используя средство разработки PowerBuilder. В продукт включены "Родные" драйвера Sybase, что позволяет обеспечивать достаточно быстрое подключение в серверу.
2. Подключение по OLE DB – наиболее рекомендуемый и современный вариант. Если клиентская часть реализована под Windows, а особенно с использованием средств разработки Microsoft, подключение с использованием OLE DB наиболее быстрый способ. При подключениях такого типа полностью используются возможности COM-технологий. Кроме того, по сравнению с ODBC приходится производить меньшее количество преобразований. Выигрыш в скорости особенно заметен в случаях, когда с сервера на клиентский компьютер передается большое количество информации (например, при создании больших отчетов)
3. Также используется подключение с использованием соединения  ODBC. Такое подключение обеспечивает существенно более низкую производительность, но оказывается незаменимым, когда речь идет о создании linked server на MS SQL Server для серверов Sybase.

И еще  одно замечание об оптимизации подключений. Если клиентов очень много и время  установки соединения становится неприемлемым (типичная ситуация для call-центра), то имеет смысл подумать о промежуточном сервере для обслуживания подключений пользователей

22 сентября 2011г., Москва. —  Sybase, Inc., компания в составе SAP (NYSE: SAP) и лидер отрасли корпоративного и мобильного программного обеспечения, объявила о выпуске в продажу Sybase® Adaptive Server Enterprise® (ASE) 15.7. Sybase ASE 15.7 — это экономически эффективная система управления реляционными базами данных (РСУБД), предназначенная для обработки очень больших массивов данных и поддержки самых требовательных приложений. Благодаря новым передовым возможностям сжатия ASE 15.7 позволяет более компактно хранить большие массивы данных и ускоряет ввод-вывод, позволяя современным предприятиям увеличить количество проводимых транзакций и одновременно обслуживаемых пользователей, не прибегая к инвестициям в дополнительные вычислительные мощности и ресурсы хранения.

«В ASE 15.7 Sybase реализовала  значительные усовершенствования в  части оптимизации хранения данных и повышения продуктивности разработчиков, — заявил Карл Улофсон (Carl Olofson), вице-президент IDC по исследованиям. — Новые возможности  должны дополнительно снизить и без того впечатляюще низкую совокупную стоимость владения ASE».

Богатый новыми возможностями выпуск Sybase ASE 15.7 является продолжением развития модельного ряда ASE 15x и представляет собой оптимальную  платформу для SAP® Business Suite. Таким образом, новый продукт не только служит мощной платформой баз данных для приложений SAP, но и позволяет пользователям предыдущих версий Sybase ASE легко задействовать новые функции без необходимости выполнять апгрейд СУБД.

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

«Стремительное  увеличение объемов корпоративной  информации ставит новые задачи в области администрирования баз данных, — отметил Брайан Винк (Brian Vink), вице-президент по продуктам для баз данных Sybase, компании в составе SAP. — Клиентам необходима СУБД, сохраняющая простоту управления даже в условиях непрерывного увеличения масштабов информационных систем. Реализованные в ASE 15.7 усовершенствования обеспечивают улучшенное быстродействие, повышенную готовность и сокращение стоимости управления большими массивами данных, характерными для современных транзакционных систем, используемых при решении ответственных задач».