(Возврат на основную страницу)

Содержание номера за Июль 2009 год

SQL Server
для администраторов

Июль 2009
№ 7 (37)

Алан Сугано

Выполнение SQL Server в виртуальной среде

Омри Бахат

Перемещение таблиц между файловыми группами: лучший способ. Часть 2

Майкл Бэрри

T-SQL функция для поиска практически любой даты

Эндрю Дж. Келли

Повышение производительности за счет параллельной обработки

Брэд МакГи

Как выявить проблемы блокировки с помощью приложения SQL Profiler

Эндрю Дж. Келли

DMV-представление из версии SQL Server 2005 наводит порядок среди индексов

Пол С. Рэндал

Углубленная диагностика с помощью расширенных событий (Extended Events). Часть 1

Выполнение SQL Server в виртуальной среде

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

Виртуальные серверы в противовес физическим

Большинство установленных экземпляров SQL Server не обеспечивают ресурсам своего компьютера постоянную стопроцентную нагрузку. В действительности, многие приложения для SQL Server используют только некоторую долю мощностей. Тенденция такова — загрузка процессора при работе SQL Server бывает высокой на непродолжительные интервалы времени. В настоящее время доступны серверы, оснащенные четырехъядерными процессорами и значительно более быстрыми (по сравнению с прежними интерфейсами) жесткими дисками Serial Attached SCSI (SAS) со скоростью передачи данных до 3 Гб/с, — поистине революционный шаг, настоящий «квантовый скачок» в производительности серверов. Базируясь на высокой производительности серверов нового поколения, виртуализация позволяет существенно повысить эффективность денежных вложений в аппаратное обеспечение.

Преимущества физических серверов-Традиционно SQL Server устанавливается на специально предназначенное для него оборудование, получая тем самым возможность максимально задействовать аппаратные ресурсы. Когда SQL Server выполняется на физическом сервере, ему не приходится участвовать в конкурентной борьбе с другими виртуальными серверами, и в этом случае скорость выполнения будет от 10 до 25 процентов выше, чем для виртуализированного сервера на том же самом «железе». Редакции SQL Server 2005 Standard и Enterprise способны обращаться к максимальному объему памяти, поддерживаемому сервером и операционной системой (далее ОС). К тому же и аппаратный сбой в этом случае отразится на работе только одного сервера SQL.

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

Преимущества виртуальных серверов-Консолидировав на единственном физическом сервере несколько гостевых виртуальных серверов, вы существенно сократите затраты на оборудование и повысите эффективность использования аппаратных ресурсов. Для размещения гостевых виртуальных серверов выбирайте физический сервер, ресурсные потребности «гостей» которого взаимно дополняют друг друга. Например, если установка SQL Server может повлечь значительное увеличение нагрузки по вводу/выводу, запустите его на физическом сервере, остальные виртуальные «гости» которого требуют намного меньше операций такого рода.

Вполне возможно, что за счет перехода к виртуальным серверам снизится стоимость поддержки аппаратного обеспечения, поскольку уменьшится количество обслуживаемых физических серверов. Также сократятся расходы на электроэнергию и упростятся требования к электропитанию. Вероятно, подобное снижение издержек позволит вам перевести все ваши хост­серверы на круглосуточную (24´7) поддержку вместо ограниченной рабочими часами поддержки (8´5), доступной ранее, до перехода на виртуальные сервера. Скорее всего, вам удастся и повысить уровень обслуживания, и к тому же сократить эту статью расходов. Использование виртуальных серверов также упрощает процедуру установки на новые компьютеры, так называемое «голое железо». Конфигурация виртуального оборудования виртуальных серверов остается неизменной, независимо от конфигурации физического оборудования. Следовательно, перенос гостевых виртуальных серверов на другой хост сводится просто к копированию их файлов. (В некоторых случаях перенос виртуальной машины заканчивается требованием новой активации Windows. — Прим. ред.)

Недостатки виртуальных серверов-При помощи таких инструментов, как VMware Server или Microsoft Virtual Server 2005, для каждого из гостевых виртуальных серверов можно выделить приблизительно до 3,8 Гб памяти. VMware ESX Server позволяет выделить до 16 Гб памяти на гостевой виртуальный сервер. SQL Server, которому недостаточно указанных объемов оперативной памяти, вероятно, не слишком подходит для виртуализации. Поскольку все гостевые виртуальные серверы разделяют общие физические ресурсы хост­сервера, производительность неминуемо пострадает, если «гостей» окажется слишком много. Не следует размещать на одном хосте чересчур много гостевых серверов, а также комбинировать виртуальные серверы, являющиеся потенциальными конкурентами за машинные ресурсы.

Невысокая отказоустойчивость — еще один недостаток виртуальных серверов. Сбой аппаратуры ведет к отказу сразу всех гостевых серверов, выполняющихся на хосте. Однако, если вы работаете с VMware Server или Virtual Server 2005 и при этом имеете резервную копию файлов для всех «гостей», то сможете достаточно оперативно оживить «упавшие» виртуальные серверы, восстановив эти файлы на другом хосте.

Размещение гостевых виртуальных серверов

Планируя виртуальную среду, старайтесь подбирать гостевые виртуальные серверы хоста таким образом, чтобы их потребности в аппаратных ресурсах взаимно дополняли друг друга. Например, приложение для SQL Server со множеством хранимых процедур и триггеров, относительно маленькой базой данных и не слишком объемными транзакциями предъявляет значительные требования к производительности процессора, но сравнительно скромные — к дисковым операциям. Такой SQL Server имеет все шансы ужиться в пределах одного хоста с файловым сервером/сервером печати, незначительно нагружающим процессор, но нуждающимся в высокопроизводительных дисковых операциях по обслуживанию файлов. Примите в расчет также количество пользователей, обращающихся к каждому из виртуальных серверов и суточное распределение нагрузки на серверы. Чтобы повысить отказоустойчивость, не собирайте все самые важные виртуальные серверы на единственном хосте. Если ваша серверная среда очень сложна (более 1000 серверов), возможно, вам следует обратиться к специальному ПО для анализа и проектирования серверных систем, например к продуктам компании CiRBA (www.cirba.com/product/product­overview.htm). Выпускаемые ими инструменты помогают автоматизировать планирование и проектирование серверных систем и виртуальной среды, а также настройку производительности гостевых виртуальных серверов и хостов.

Развертывание гостевых виртуальных серверов

Рекомендую вам создать базовые образы для всех типов гостевых виртуальных серверов, которые предполагается использовать. Я выполняю эту операцию в соответствии с инструкцией, приведенной во врезке «Создание базового образа виртуального сервера». Когда базовый образ окажется у вас в распоряжении, для развертывания нового гостевого виртуального сервера выполните следующие шаги:

1.  Скопируйте образ диска виртуального сервера в другую папку.

2.  Переименуйте файл образа диска виртуального сервера, задав имя, отличное от имени файла базового образа (например, «SQL1 C Drive.vmdk» — для VMware Server, «SQL1 C Drive.vhd» — для продукта компании Microsoft).

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

4.  Создайте на хост­сервере новый гостевой виртуальный сервер.

5.  Получив соответствующий запрос, выберите только что скопированный и переименованный образ диска.

6.  Запустите новый гостевой виртуальный сервер.

7.  Настройте для него статический IP­адрес.

8.  Переименуйте гостевой виртуальный сервер, назначив ему постоянное имя.

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

Если базовые образы созданы корректно, то вы развернете новый сервер за четверть часа. Затем вы сможете установить SQL Server или другие необходимые приложения. В идеале, образы размещаются в сетях хранения данных SAN (Storage Area Network) или на других файловых серверах с возможностью общего доступа, — тогда к ним будет удобно обращаться со вновь установленных хост­серверов. Чтобы ускорить процесс установки, имеет смысл обзавестись ISO­образами установочных компакт­дисков для SQL Server (и других прложений). Должным образом настроенные базовые образы сберегут вам не менее часа на сервер, и даже значительно больше, если планируется установка дополнительного аппаратного обеспечения. (В приведенном плане пропущен один очень важный пункт. Очевидно, что простого копирования базового образа недостаточно, так как получится виртуальная машина с тем именем, что и базовый образ, что недопустимо в сетевом окружении, она будет иметь тот же SID, что также не приемлемо. Поэтому простого размножения не получится и потребуется выполнить ряд дополнительных действий, например, как описано здесь: http://blogs.technet.com/megand/articles/357570.aspx. — Прим. ред.)

Советы по конфигурированию аппаратного обеспечения

Серверы последнего поколения, оснащенные четырехъядерными процессорами и жесткими дисками SAS, обеспечивают качественно новую мощность и потому идеально подходят на роль хост­серверов, принимающих виртуальных «гостей». Приведенные ниже советы по конфигурированию аппаратного обеспечения помогут вам оптимизировать производительность гостевых виртуальных серверов.

Память хост­сервера-Подберите подходящую оперативную память как для хост­сервера, так и для гостевых виртуальных серверов. Большинство хост­серверов должны иметь как минимум 8 Гб памяти. Убедитесь, что хост­серверная ОС поддерживает обращение ко всей его физической памяти. 32­разрядная версия Windows Server 2003 Standard Edition способна адресовать только 4 Гб памяти, но 64­разрядная версия той же редакции адресует уже 32 Гб.

ОС хост­сервера-Если вы решили использовать в качестве ОС хост­сервера Windows Server, стоит обратиться к 64­разрядным версиям Windows 2003. Редакция Windows 2003 Standard x64 поддерживает 32 Гб оперативной памяти, а редакция Windows 2003 Enterprise x64 — 1 Тб. Для работы с 64­разрядными гостевыми виртуальными серверами ОС хост­сервера обязательно должна быть 64­разрядной, но и 32­разрядные гостевые сервера предпочтительнее размещать на хостах под управлением 64­разрядной версии Windows 2003, — это позволит добиться выигрыша в производительности. На сегодняшний день картина такова, —  VMware Server и ESX Server поддерживают 64­разрядные гостевые виртуальные серверы, но Virtual Server 2005 обслуживает только 32­разрядных «гостей».

Процессор-Чтобы добиться лучшей производительности виртуальных серверов, применяйте четырехъядерные процессоры. Как правило, четырехъядерные процессоры быстрее аналогичных двухъядерных примерно на 50 процентов. Если какой­либо из запланированных вами гостевых виртуальных серверов является 64­разрядным, убедитесь, что процессор поддерживает 64­разрядную виртуализацию. В число процессоров, поддерживающих 64­разрядных виртуальных гостей, входят AMD Athlon 64 (начиная с ревизии D), AMD Opteron (начиная с ревизии E), AMD Turion 64 (начиная с ревизии E), AMD Sempron с поддержкой 64­разрядных вычислений, начиная с ревизии D (экспериментальная поддержка) и процессоры с поддержкой Intel Extended Memory 64 Technology (EM64T) и Virtual Technology (VT). Перед тем как устанавливать 64­разрядные гостевые виртуальные серверы на хост­сервер, оснащенный процессорами Intel, необходимо включить поддержку аппаратной виртуализации в BIOS хоста.

Конфигурирование жестких дисков хост­сервера-К виртуализированному SQL Server применимы те же основные правила конфигурирования жестких дисков, что и к выполняющемуся на физическом сервере. Хост, на котором предполагается разместить SQL Server, должен быть оснащен как минимум одним массивом RAID 1 для журналов транзакций и массивами RAID 5 или RAID 10 для файлов данных. Если экземпляр SQL Server обслуживает базы значительного объема, имеет смысл разнести их журналы транзакций и файлы данных по RAID­массивам. Запись в журналы транзакций ведется последовательно, поэтому для них предпочтительнее применять массивы RAID 1, более эффективные при последовательной записи. Массивы RAID 5 и RAID 10 демонстрируют лучшую производительность на файлах произвольного доступа, следовательно являются хорошим выбором для хранения файлов данных. Установив 64­разрядную версию SQL Server 2005, вы также сможете ускорить выполнение. Если ожидается, что гостевые виртуальные серверы будут существенно нагружать диски, обратите внимание на конфигурацию, приведенную в табл. 1. В соответствии с этой таблицей на хост­сервер можно установить десять физических жестких дисков — два для первого массива RAID 1, два для второго массива RAID 1 и шесть дисков под массив RAID 10. Используйте на сервере диски типа SAS, а не Serial ATA (SATA) или IDE.

Надстройки (дополнительные средства) гостевых виртуальных серверов (а именно, VMware Tools или Microsoft Virtual Machine Additions). Следует устанавливать надстройки практически сразу после установки ОС виртуального сервера. Это позволит значительно улучшить общую производительность гостевых виртуальных серверов.

Диски SCSI для гостевых виртуальных серверов. При конфигурировании виртуального сервера в качестве типа его дисков всегда указывайте SCSI, независимо от типа жестких дисков, установленных на хост­сервере.

Поиск вирусов. Настройте антивирус, выполняемый на хост­сервере так, чтобы поиск вирусов в файлах гостевых виртуальных серверов был отключен.

Стратегии резервного копирования

По сравнению с резервным копированием SQL Server, установленного на физическом сервере, резервное копирование виртуализированного SQL Server имеет свои характерные трудности и, напротив, преимущества. Для серверов, обслуживающих жизненно важные приложения баз данных, я обычно создаю полную резервную копию раз в день, а разностные или добавочные дампы журналов сбрасываю на ленту или диск в течение рабочего дня ежечасно. Одно из главных достоинств виртуализированного SQL Server состоит в том, что для получения резервной копии образа достаточно просто скопировать файлы гостевого виртуального сервера, размещенные на хосте. Если вы используете ESX Server, то можете выполнить резервное копирование любого гостевого виртуального сервера, не останавливая его, при помощи инструментов Consolidated Backup от компании VMware или esxRanger от компании Vizioncore.

Если же вы работаете с Virtual Server 2005 или VMware Server, то перед созданием резервной копии гостевой виртуальный сервер придется каждый раз останавливать. К счастью, имеется возможность создать сценарий для автоматизации всего процесса — остановки гостевых виртуальных серверов, выполнения резервного копирования и перезапуска «гостей». Я обычно настраиваю резервное копирование так, чтобы получать резервные копии образов всех гостевых виртуальных серверов раз в неделю. Подробнее о стратегиях резервного копирования виртуальных серверов вы можете прочитать в статье www.windowsitpro.com/Article/ArticleID/95309/95309.html.

Аварийное восстановление

В основу сценария аварийного восстановления можно положить репликацию файлов образов виртуальных серверов на специально предназначенный для восстановления удаленный ресурс. Чтобы настроить автоматическую репликацию файлов на удаленный компьютер, воспользуйтесь встроенным в Windows 2003 R2 средством DFS Replication (DFSR, где DFS — Distributed File System (Распределенная файловая система)). Поскольку файлы образов виртуальных серверов с течением времени изменяются довольно медленно, то для их репликации очень хорошо подходят входящие в DFSR протокол удаленного разностного сжатия (Remote Differential Compression (RDC)) вкупе со средством межфайловой репликации (Cross­File Replication). Межфайловая репликация, дублируя файлы на удаленный ресурс, использует информацию об исходных локальных файлах. Посредством протокола RDC реплицируются только изменения файлов, что существенно ускоряет процесс. Таким образом, технология DFSR позволит вам реплицировать файлы гостевых виртуальных серверов относительно быстро, даже если они будут постоянно расти и в отдаленной перспективе станут довольно большими.

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

Перемещение таблиц между файловыми группами: лучший способ. Часть 2*

DOWNLOAD

См. Омри Бахат. Перемещение таблиц между файловыми группами: лучший способ. Часть 1 // SQL Server для администраторов. 2009. № 6.

T-SQL функция для поиска практически любой даты

DOWNLOAD

Возникала ли у вас потребность в поиске определенных дат при работе с Microsoft SQL Server 2005 или Microsoft SQL Server 2000, например, определить дату первого вторника следующего месяца или дату следующего выходного дня? Часто ли вам приходится определять, выпадает ли дата, возвращенная из запроса, на выходной день или на рабочий? Если это так, то решение Майкла Бэрри — для вас. Его решение использует T-SQL функцию Dates и таблицу Calendar.

При работе над проектами все мы пишем классный код, которым, как мы думаем, будет полезно поделиться с другими. Лучший в мире код — позаимствованный код, поскольку он бесплатный и закаленный в действующих проектах. В прошлом году я нашел код, создающий таблицу Calendar. Как подсказывает ее имя, эта таблица содержит календарные данные, которые вы можете изменять по своему усмотрению. Я создал функцию Dates для поиска практически любой информации в таблице Calendar. Например, вы можете использовать мою функцию для следующих целей:

•    Найти первый вторник следующего месяца;

•    Определить, выпадает ли полученная из запроса дата на рабочий или выходной день;

•    Создать рекуррентную функциональность, как в Microsoft Outlook.

Повышение производительности за счет параллельной обработки

Меня часто спрашивают, какое значение следует присвоить параметру максимальная степень параллелизма (Max Degree of Parallelism (MAXDOP)) в той или иной среде SQL Server. По-видимому, параллелизм относится к тем аспектам SQL Server, которые прояснены недостаточно, вследствие чего администраторы оказываются не готовыми к принятию осмысленных решений по настройке. Настало время приподнять завесу над этой тайной.

Большинство специалистов знакомо с основами параллелизма — выполняя запрос пользователя, SQL Server способен одновременно использовать сразу несколько процессоров. По умолчанию, для выполнения любой части запроса SQL Server может задействовать все процессоры системы или же столько процессоров, сколько поддерживает конкретная редакция сервера, — в предположении, что использование параллельной обработки вообще принесет пользу. Если посредством простенького INSERT вставляется единственная строка, у ядра SQL Server есть единственное решение — использовать не более одного потока или процессора, сколько процессоров не имелось бы в наличии. Но для запроса, требующего интенсивного сканирования индекса, SQL Server, скорее всего, попытается разбить выполнение на несколько потоков и подключить к работе над запросом все доступные процессоры. Таким образом, важно осознать следующее, — несмотря на то, что SQL Server способен использовать все доступные процессоры, имеется несколько факторов, определяющих, сколько процессоров будет вовлечено в обработку на самом деле.

Что такое MAXDOP?

Одним из таких факторов является параметр MAX­DOP, позволяющий ограничить число процессоров, которые могут быть задействованы одновременно для единственного пользователя или процесса. По умолчанию значение MAXDOP равно 0. Это означает, что при описанных выше условиях будут использованы все доступные процессоры. Как вы далее увидите, существует несколько способов изменить этот параметр.

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

Как выявить проблемы блокировки с помощью приложения SQL Profiler

В прошлом у многих разработчиков и администраторов БД SQL Server имелись собственные излюбленные диагностические хранимые процедуры для анализа проблем блокировки, но начиная с версии SQL Server 2005, удачной оказывается идея использовать для решения всех таких проблем, за исключением самых сложных, приложение SQL Profiler. Это приложение позволяет получить отчет о блокированных процессах, из которого вы можете узнать, в чем заключается проблема, а также получить ценное указание относительно того, как ее исправить.

Несмотря на то что взаимоблокировки должны быть такими событиями, которые встречаются редко, наличие некоторого определенного их количества — нормальное явление для SQL Server. Другими словами, сервер SQL Server часто намеренно не позволяет одному процессу обращаться к объекту, если этот объект заблокирован другим процессом. Это значит, что дальнейшая работа второго процесса будет блокирована до тех пор, пока первый процесс не снимет блокировку с объекта, доступ к которому нужен второму процессу.

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

Тем не менее, далеко не все структуры данных, индексация таблиц и код приложений являются совершенными, и администраторам БД достаточно часто приходится наблюдать блокировки, длящиеся 10 секунд, 60 секунд, даже 6 000 секунд. Понятно, такого рода блокировка существенно повлияет на производительность сервера SQL Server и его пользователей. Поскольку мы являемся администраторами БД и разработчиками, нам необходимо иметь возможность выявлять такого типа проблемы блокировки, чтобы можно было их устранить или минимизировать частоту их появления.

В версиях SQL Server 2000 и младше задача выявления проблем блокировки не принадлежала к числу легко решаемых. Одним из вариантов решения было использование диспетчера Enterprise Manager для просмотра существующих подключений с целью обнаружения какой­либо блокировки, или использование команд sp_who или sp_who2. Будучи человеком с амбициями, вы могли бы написать какой­то программный код для извлечения данных о блокировке из системных таблиц.

В версии SQL Server 2005 ситуация улучшилась. Помимо среды Management Studio, хранимых процедур и системных таблиц у нас также есть представления административного управления (DMV) и даже набор отчетов Performance Dashboard. Однако важнее всего то, что у нас есть новое событие профилировщика SQL Server Profiler — событие Blocked Process Report (отчет о блокированных процессах). Это событие выполняет серьезную работу, помогая вам выявить проблемы блокировки и, вместе с тем, обеспечивает большую часть информации, необходимой для разрешения этой проблемы.

DMV-представление из версии SQL Server 2005 наводит порядок среди индексов

DOWNLOAD

Сколько раз к вам обращались с вопросом: «Как мне избавиться от всех этих индексов, которые не используются?» Если вы принадлежите к той части администраторов БД, которая составляет большинство, вам и самому нередко приходилось сталкиваться с этим вопросом на практике или даже изучать его. В версии SQL Server 2000 удаление неиспользуемых индексов — задача, решить которую почти невозможно: для этого требуется многочасовой анализ и глубокое понимание того, как функционируют все и каждая в отдельности таблицы в ваших базах данных. Версия SQL Server 2005 до некоторой степени избавляет нас от этой проблемы и существенно облегчает ношу, поскольку в нее включено представление, которое входит в набор динамических административных представлений (Dynamic Management View, DMV) и как нельзя лучше подходит для решения указанной задачи, — представление sys.dm_db_index_usage_ stats. Давайте вкратце рассмотрим, что оно собой представляет, и заставим его работать в вашей среде.

Углубленная диагностика с помощью расширенных событий (Extended Events). Часть 1

DOWNLOAD

Во всем мире администраторы БД SQL Server испытывают трудности, которые, как кажется, никогда не исчезнут. Эти трудности создает диагностика, проводимая чаще всего для того, чтобы выявить какого­либо рода проблему производительности. Даже в те прикладные системы, разработка и тестирование которых велись самым тщательным образом, со временем будут внесены изменения, способные привести к возникновению серьезных проблем производительности.

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

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

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

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

(Возврат на основную страницу)