Использование и настройка псевдонимов (server alias)

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

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

Возник, однако, другой вопрос. В случае, когда на компьютере установлен SQL Server Client Tools (на машине разработчика есть с вероятностью 99%) все просто: запускаем SQL Server Configuration Manager, идем в раздел SQL Native Client Configuration, далее Aliases. А если этого пакета нет (на сервере - не редкость)? Как быть? Вариантов несколько:

• "для слабаков": установить SQL Server Client Tools и получить SQL Server Configuration Manager
• "для простых админов": в комплекте с клиентскими библиотеками SQL Server идет утилита cliconfg.exe (находится в папке Windows\systems32 так что можно вызывать из командной строки), в которой можно сконфигурировать не только псевдоним, но и много чего еще
• "для хардкорных админов": воспользоваться Power Shell и SMO (используя объект Microsoft.SqlServer.Management.Smo.Wmi.ServerAlias) - правда для этого придется установить на компьютер PowerShell (в Server 2008 и новее есть всегда) и собственно SMO

Рекомендуемый вариант - "для админов". Или "для хардкорных админов" (возможно с вариациями) - если нужно чтобы настройка происходила автоматически и/или была повторяемой.

За деталями отсылаю к MSDN и документации по PowerShell. А еще рекомендую блог SQL Protocols - такой подробной информации о протоколах SQL Server и решении проблем с соединением вы больше нигде не найдете.

HTH

Ускорение SMO v.10: дело не в запросах

Мне все никак не дает покоя причина увеличение скорости работы SMO v.10 (см. здесь). Все думал: ну ничего себе, насколько, оказывается, можно эффективно (или неэффективно) работать с метаданными! Возникло сильное желание узнать: как нужно и как не нужно делать.

Разбор полетов начал с профайлера (слева - версия 10, справа - 9):

Говоря по-простому: на уровне запросов к базе не поменялось ничего. По содержанию. А вот форма немного изменилась. Если в версии 9 все запросы генерировались динамически (т.е. для каждого объекта создавался свой запрос), то в версии 10 используются запросы с явной параметризацией, что по-идее существенно облегчает работу сервера - не надо на каждый запрос создавать новый план выполнения. Мониторинг сервера во время создания скриптов базы с помощью dbbuilder показывает, следующее:

• для SMO v.9 практически на каждый запрос создается новый план выполнения (даже для однотипных запросов), повторного использования планов не происходит;
• для SMO v.10 план типовых запросов в большинстве случаев используется повторно.

В целом ожидаемо. Но дальше начинается интересное. Если проанализировать статистику выполнения этих запросов (суммарное время выполнения, общая нагрузка на подсистемы ввода/вывода и загрузка процессора), то обнаруживается, что разница между версиями во-первых не так уж и велика, а во-вторых, по "чистому времени выполения запросов" она даже не в пользу новой версии (v9: 19.5 s, v.10: 26 s).

Так что версию о том, что причина ускорения кроется в эффективности/неэффективности самих запросов (или способа их выполнения) скорее всего нужно отбросить.

Начал было "ковыряться" в коде SMO, но что-то пока без особого успеха (слишком уж его много).

Чисто для себя решил выяснить разницу по производительности (измеренную на уровне приложения) между параметризированными запросами и динамически сгенерированным SQL. Для простых запросов эта разница составляет около 20%, что тоже неплохо.

Пару слов о Sql Server Management Objects (SMO) (v.9 и v.10)

На днях повысил версию SMO. Причин на то было две: категорически не устраивала работа SMO v.9 с полнотекстовыми индексами и хотелось добавить поддержку SQL Server 2008 (что в любом случае требовало SMO v.10). Но обо всем по-порядку.

Когда появилась настоятельная необходимость добавить в dbbuilder поддержку полнотекстовых объектов (каталогов и индексов), то первым (вполне очевидным) решением было обратиться к SMO и при генерации скриптов сохранять еще пару типов объектов. При создании базы проблем возникнуть не должно было. Но на деле оказалось, что в SMO v.9 есть такая "особенность": при создании скрипта для полнотекстового индекса в него всегда добавляется USING [<исходная БД>]. Причем эта "фича" гнездится в самом коде SMO (спасибо, Reflector) и на нее не влияют ScriptingOptions равно как и порядок создания скриптов. В результате мы всегда получаем скрипты, которые непригодны к использованию сразу после генерации и требуют ручной "доработки напильником" (удаления USING), что нехорошо.

Поругавшись про себя решил посмотреть: а как обстоит дело в SMO v.10? Оказалось что хорошо обстоит: баг (или фичу) починили (или убрали) и теперь скрипты получаются такие, какие и дОлжно. В ходе тестовых запусков обнаружил, что задачи по генерации скриптов/созданию базы стали выполняться быстрее. Решил проверить и с еще большим удивлением обнаружил, что таки да, таки что-то произошло: SMO v.10 работает значительно быстрее v.9. Сравнительные (усредненные по двум запускам) результаты для некоторой базы данных (141 таблица, 194 хранимых процедуры, 2 триггера, 10 пользовательских функций и 5 представлений) приведены в таблице ниже.

	SMO v.9	SMO v.10
Создание новой (пустой) базы	0:24	0:20
Генерация скриптов	8:35	0:58

Признаюсь: меня сильно впечатлило увеличение скорости генерации скриптов почти на порядок.

А теперь ложка дёгтя: SMO как-то очень забавно работает с SQL Server Express. Если я попытаюсь через SMO обратиться к полнотектовому каталогу базы данных, работающей на SQL Server Express with Advanced Services (в котором есть Full-text search), то получу исключение "SQL Server Express не поддерживает Full-Text". Отлично, просто отлично! Но этот самый Full-text, к счастью, работает вне зависимости от того, что на этот счет "думает" SMO.

Надеюсь кому-то поможет.

AlexS