11.5. Оптимизация работы SQL Server

11.5.1. Общие вопросы оптимизации работы SQL Server

Оптимальная архитектура приложений SQL Server 2005, базы данных OLTP и хранилища данных (Data Warehouses), перенос данных из баз данных OLTP в хранилища данных

В предыдущих разделах вы познакомились с основными средствами мониторинга производительности SQL Server 2005. Однако на практике часто нужно не только отслеживать производительность работы SQL Server, но и повышать ее.

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

Конечно, чтобы рабочие таблицы оставались небольшими, необходимо, чтобы старая информация удалялась из них регулярно. Чаще всего используются для способа реализации этой задачи:

q      старая информация с определенной периодичностью (каждую ночь, раз в неделю, месяц, квартал и т. п. — в зависимости от скорости накопления информации) переносится пакетами SSIS в специальную базу данных-хранилище (Data Warehouse). Затем информация, перенесенная в хранилище данных, используется для изготовления отчетов и для создания кубов OLAP (если они используются на предприятии). Это наиболее рекомендуемый способ организации работы с данными на предприятии;

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

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

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

Получить учебные материалы по этому курсу