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

Содержание номера за Октябрь 2003 год

 

Editorial

Приготовьтесь к выходу СУБД Yukon

Роджер Дженнингс (Roger Jennings)

Новая версия SQL Server сулит повышение производительности труда разработчиков и уменьшение загрузки администраторов БД.

Для следующих решений: SQL Server Yukon Beta, Visual Studio .NET Whidbey Beta, InfoPath Beta, SQL Server Reporting Services Beta.

Следующий выпуск Microsoft SQL Server, имеющий кодовое название Yukon, призван изменить перспективу систем управления реляционными базами данных (СУБД) компании Microsoft. Yukon обещает объединить преимущества чистых XML- и объектно-ориентированных баз данных в полностью программируемую инфраструктуру реляционной БД.

Новая служба Reporting Services, поддержка форм ввода данных InfoPath (прежде — XDocs) и улучшения Transact-SQL (T-SQL) дополняют собой набор новых функций Yukon. В конце февраля текущего года на конференции VSLive! в Сан-Франциско Дэвид Кэмпбелл (David Campbell), руководитель группы разработки ядра SQL Server компании Microsoft, представил .NET-разработчикам новую СУБД. В этой статье я проанализирую основной доклад Кэмпбелла «Базы данных будущего: анонс Yukon и других технических достижений» с точки зрения ИТ-управления и администрирования БД SQL Server. Дополнительные детали о некоторых новых возможностях Yukon взяты из записей проводимых ранее интерактивных обсуждений, посвященных SQL Server.

Подобно Windows Server 2003, СУБД Yukon пережила затянувшийся период созревания. В пресс-релизе компании Microsoft за февраль 2000 года содержится первое официальное упоминание о Yukon, как о кодовом имени для следующей версии SQL Server. В ходе своей презентации на Конференции Профессиональных Разработчиков (Professional Developer’s Conference, см. раздел Ссылки) 21 октября 2001 года Пол Флесснер (Paul Flessner) сделал первоначальный обзор Yukon. Он упомянул возможность собственных НТТР-соединений в СУБД Yukon, тип данных XML и XQuery processor, а также продемонстрировал функции IntelliSense инструмента SQL Workbench с кодом хранимой процедуры на С#, запущенной в среде исполнения Common Language Runtime (CLR), встроенной в .NET Framework. Эрик Руддер (Eric Rudder), главный вице-президент по этой платформе и привлечению к ней разработчиков, объявил на конференции VSLive! в Сан-Франциско, что следующий полный выпуск Visual Studio под кодовым названием Whidbey, будет совмещен с выходом СУБД Yukon (см. раздел Ссылки). Можно ожидать выхода бета-версий Yukon и Whidbey в этом году и передачи их в производство не раньше 2004 года. SQL Server 2000 поступил в производство 7 августа 2000 года. Четыре года между выпусками SQL Server — долгое время, особенно если принять в расчет, что 20 ноября 2002 года SQL Server отпраздновал свою десятую годовщину.

При обновлении производственных серверов до СУБД Yukon, а также связанном с ним приобретением лицензий на использование Whidbey и обучением групп .NET-разработчиков ИТ-руководство сталкивается с очевидным вопросом о возможности возврата инвестиций (ROI, return on investment). Универсальная подписка MSDN позволяет «постучать по шинам» Yukon, но ваше правление наложит постатейное вето на основные ИТ-расходы в условиях нынешней экономии. Те, кто перешел на SQL Server 2000 и Windows 2000, возможно, к настоящему времени уже несколько раз возместили свои начальные затраты, но многие организации продолжают использовать SQL Server 7.0 и 6.5 на серверах Windows NT. Инерция, а не движение — вот физический принцип, управляющий современными инфраструктурами операционных систем и баз данных. Основной задачей компании Microsoft, по крайней мере, в этом десятилетии является преодоление нежелания проводить обновления для всех линий своих продуктов.

Рассматриваем бета-версию СУБД Yukon

Если ваша организация приняла XML в качестве языка для интеграции корпоративных приложений (EAI, enterprise application integration), а службы XML Web service для передачи сообщений между приложениями через брандмауэр, то заложите расходы на приобретение Windows Server 2003 и Yukon в бюджет 2004 или 2005 года. Выделите разработочные и административные ресурсы для работы с готовящейся к выходу бета-версией СУБД Yukon. Шесть новых возможностей Yukon должны гарантировать приемлемый уровень возврата инвестиций, направляемых на обновление.

Во-первых, Yukon включает XML в качестве собственного типа данных SQL Server. Способность сохранять и запрашивать XML-документы в реляционной БД будет приобретать все большее значение по мере перехода к достижениям XML. Например, вам может потребоваться заархивировать сторонние SOAP-за-просы и ответные сообщения для строгого соблюдения обязательств или в целях аудита. Поддержка расширений XPath и XQuery к T-SQL, возможно, в большей степени устранит потребность организации инвестировать специализированные хранилища XML-данных. (Можно ожидать, что производители специализированных XML-баз данных будут решительно оспаривать этот вывод.)

Во-вторых, Yukon поддерживает хранимые процедуры, функции и триггеры, написанные на C# и Visual Basic .NET. Встроенная в Whidbey среда исполнения CLR позволяет вам переместить вычислительно интенсивные операции со среднего уровня на уровень данных. «Приблизиться к данным, чтобы уменьшить время ожидания» — вот один из ключевых руководящих принципов Microsoft, продемонстрированный в ходе представления СУБД Yukon. Хранимые процедуры T-SQL настолько близки к данным, насколько это возможно, поэтому администраторы БД должны ограничивать подобный CLR-подход по отношению к сложным процедурам, которые не могут быть обработаны на T-SQL.

В-третьих, в БД можно определить и получить доступ к сложным пользовательским типам данных (user-defined type, UDT), описанных на C# или VB.NET. Члены класса используют типы данных SQL Server, соответствующие типам данных CLR, поддерживающих троичную логику (three-valued logic) (реализация INullable обрабатывает значения NULL). Заполнение и манипулирование встроенными экземплярами объектов минимизирует время ожидания и улучшает производительность.

В-четвертых, разработчики могут перемещать код доступа к данным со среднего уровня на уровень данных, просто заменяя SqlClient на новый управляемый провайдер данных SqlServer (и наоборот). Эта функция позволяет ускорить и упростить сравнение производительности и масштабируемости уровня данных и среднего уровня.

В-пятых, Yukon допускает создание встроенных локальных служб XML Web service. Их собственные HTTP-стеки удаляют Internet Information Services (IIS) из канала SOAP-сообщений, приводя к дополнительному повышению производительности. Однако перед тем как рассматривать перемещение локальных (интранет) служб на уровень данных, стоит убедиться, что ваши разработчики являются экспертами в асинхронном программировании служб Web service. Не отвечающие конечные точки (endpoint) SOAP могут тратить дорогие ресурсы сервера СУБД, ресурсы же среднего уровня обычно менее дорогостоящие. Используйте расширенные службы XML Web service, применяющие цифровые подписи и/или шифрование на среднем уровне (см. раздел Ссылки).

И в заключение, инструмент SQL Server Workbench полностью интегрирован в выпуск Whidbey Visual Studio .NET и предоставляет удобные функции (такие как IntelliSense для параметров хранимых процедур) для сокращения затрат на написание кода уровня данных или среднего уровня (см. рис. 2). Глубокая связь с Visual Studio .NET позволяет выполнять сквозную отладку и профилирование. Интеграция SQL Server Workbench с Analysis Services, Reporting Services и Visual SourceSafe, несомненно, приведет к повышению производительности труда разработчиков и минимизирует проблемы управления версиями.

Если ваша организация не примкнула к массовому увлечению XML и службами Web service или перенесла разработку новых проектов в VS.NET, обоснование перехода с вашей текущей версии SQL Server или конкурирующей СУРБД на Yukon, возможно, будет приводить в уныние. Организации, работающие с SQL Server 6.5 или 7.0 на сервере Windows NT, могут получить немалый рост производительности, перейдя на Windows Server 2003 и Yukon. В этом случае, бесспорно, потребуется обновление или замена аппаратного обеспечения сервера, хотя, вероятно, вы сможете объединить серверы, чтобы минимизировать стоимость управления, поддержки и лицензирования. Потенциальным источником дополнительного возврата инвестиций является уменьшение стоимости администрирования с помощью возможностей самонастройки и инструментов управления Yukon. Оценка требуемых инвестиций без учета стоимости фирменных лицензий и определение роста производительности и уменьшения затрат без практической проверки в условиях производственной нагрузки являются, в лучшем случае, рискованными. Благоразумие подсказывает подождать официального документа Microsoft по возврату инвестиций и полной стоимости владения (TCO, total cost of ownership) и аналитических обзоров, перед тем как ставить свою карьеру на СУБД Yukon.

Другим потенциальным препятствием развертыванию Yukon является реакция «только через мой труп» многих ИТ-менеджеров и администраторов БД, вызванная перспективой того, что коды среднего уровня или интерфейсная часть C#- или VB.NET-кода будет «гарцевать» внутри «их» баз данных. Подготовка разработчиков (особенно для написания защищенного, надеж-
ного кода) и дисциплина — вот путь к неизбежному отказу от собственнического «моя база данных». К программированию в .NET Framework быстро привыкаешь, поэтому разработчики без развитых навыков работы с T-SQL будут склонны к написанию большинст-
ва или всех процедур на C# или VB.NET. Выполнение эффективного перехода с одного только T-SQL на смесь языков требует управленческого решения о том, когда CLR-подход станет целесообразным.

Отдадим должное T-SQL

Несмотря на акцент в маркетинге на CLR-функции СУБД Yukon, Microsoft не оставляет без внимания и T-SQL. Я еще вернусь к некоторым из наиболее важных новых функций T-SQL, не связанных напрямую с XML или встроенным CLR.

Вы можете получить несколько активных результирующих наборов в единственном соединении. Реакцией разработчика на это заявление на конференции VSLive! в Сан-Франциско были следующие слова: «Наконец-то!». Также в качестве входных параметров можно использовать массивы. Массив параметров упрощает процедуру, добавляющую несколько строк и столбцов, таких как элементы строки order или invoice. (Кэмпбелл не упомянул об этом в своем основном докладе на VSLive!. Гордон Манджоне (Gordon Mangione), вице-президент корпорации, отвечающий за разработку SQL Server, рассказал об этой возможности в интерактивном обсуждении SQL Server (см. раздел Ссылки).

Совершенствование типов данных также сулит новые преимущества. В типе данных Varchar(max) длина строки может теперь превышать 8К (определяемые размером страницы), поэтому администраторы БД могут определять ширину столбца, предписывающую переход к типу данных text. Разделение типа данных datetime на два типа данных — date и time — уменьшает количество байтов в столбце, если вам требуется только один из этих элементов, и устраняет необходимость предоставлять значения даты, если вы заинтересованы только во времени.

Оповещение о запросе (query notification) приводит к автоматическому изменению уведомлений. Менеджерам, администраторам БД и Web-приложениям зачастую необходимо знать, когда запросы к относительно постоянным данным возвращают различные результирующие наборы. Например, исправление какой-либо ошибки в оперативном каталоге требует немедленного обновления во всех кэшированных копиях. Регистрация приводит к автоматическим оповещениям при изменении результирующего набора. По словам Кэмпбелла, незамедлительное обновление в кэшах данных является «чрезвычайно эффективным».

SQL Server Notification Services (в настоящее время добавленная в SQL Server 2000) будет встроена в СУБД Yukon (см. раздел Ссылки). Оповещение о запросе и Notification Services, являющиеся отдельными технологиями, работают «рука об руку». Yukon, возможно, выиграет от включения дополнительных инструментов и/или мастеров, упрощающих настройку и управление Notification Services.

СУБД Yukon допускает выполнение рекурсивных за-просов. Новые ключевые слова WITH и RECURSIVE стандарта ANSI SQL3 допускают линейную рекурсию для запросов в стиле потомок/предок (descendant/ancestor), таких как спецификации.

И в заключение, администраторы БД или разработчики могут писать пользовательские агрегаты (UDA, user-defined aggregate) на T-SQL или VS.NET, чтобы активировать определенные составные выражения для поддержки глубинного анализа данных (data mi-ning) и рекурсивных запросов. Кроме того, Yukon разрешает обработку структурированных исключений (structured exception). Блок TRY...CATCH перехватывает срывы транзакций и делает написание других кодов обработки ошибок более простым.

Упомянутые ранее добавления в T-SQL вместе с новым инструментом управления SQL Server Workbench сулят значительное упрощение использования SQL Server и повышение производительности администраторов БД.

Том Риссо (Tom Rizzo), менеджер группы маркетинга SQL Server компании Microsoft, продемонстрировал возможности InfoPath как клиента служб XML Web service СУБД Yukon. Он ссылался на InfoPath как на «часть Office 11», но официальное определение Microsoft для InfoPath утверждает, что это «новый продукт семейства Microsoft Office». (Преждевременно опубликованная на сайте MSDN, а затем удаленная версия Office 2003 beta 2 включала в себя InfoPath.) Office InfoPath 2003 (официальное имя) является основанным на XML инструментом для разработки и визуализации форм. Он использует XML Schema (XSD) для проверки достоверности данных и XSL Transformations (XSLT) для создания XHTML-кода с целью отображения и обновления данных (см. раздел Ссылки).

InfoPath обрабатывает любые XML-данные, для которых у вас имеется XSD-схема. Если схемы нет, InfoPath сделает все наилучшим образом для получения схемы из структуры XML-документа. Документы Web Services Definition Language (WSDL) для document/literal служб XML Web service СУБД Yukon включают схему, поэтому создание простой формы для отображения и обновления данных потребует только серии операций типа «укажи и щелкни» или «перетащи и брось» для добавления HTML-элементов, получения данных и обновления служб. InfoPath может также соединяться напрямую с результирующим набором реляционного запроса или таблицей с помощью ActiveX Data Objects (ADO), сохранять данные как локальный XML-документ для автономного редактирования, а затем передавать изменения в БД по новому соединению.

Создаем гибкие отчеты

Microsoft объявила о скором выходе SQL Server Reporting Services за день до основного доклада Кэмпбелла (см. раздел Ссылки). Служба Reporting Services объединяет каталог отчетов (report catalog) SQL Server или Microsoft SQL Server 2000 Desktop Engine (MSDE), сервер отчетов и компонент представления отчета (report control), размещаемый в приложении, визуализирующем отчет. Сервер отчетов включает в себя подсистему рендеринга (rendering engine), а также службы обработки данных, составления расписаний, доставки и безопасности (см. рис. 3). Встроенная интерпретирующая машина создает отчеты в форматах XML, HTML, Excel, PDF или специально отформатированные отчеты. Отчеты могут обновляться через запланированный интервал времени и доставляться по электронной почте. NT LanMan (NTLM) или Passport security обеспечивают аутентификацию и авторизацию при доступе по сети.

Конструктор отчетов (report designer) интегрирован с VS.NET и SQL Workbench; он поддерживает источники данных SqlClient, OLE DB и ODBC и может вы-ступать в качестве клиента службы XML Web service. Разработчики могут перетаскивать и бросать поля из источника данных в окно конструктора и использовать панель инструментов VS.NET для добавления в отчет диаграмм. Если у получателя нет полной версии (или версии с ограничением по времени) Office Web Components, то служба получает отчеты в статическом формате (например PDF) и интерпретирует диаграммы как растровые изображения. Reporting Services является динамической службой, поэтому параметризованные отчеты и отчеты с последовательным уточнением (drill-down) данных создаются достаточно просто. Выход бета-версии был запланирован на первую половину 2003 года, поэтому слишком рано говорить, что Reporting Services будет конкурировать по гибкости и точности с отчетами Access и по силе и размаху с Crystal Reports 9. Однако могу поспорить, что Reporting Services станут серьезными соперниками обоим продуктам. Microsoft не обнародовала своей программы лицензирования, поэтому в настоящее время не ясно, будут ли Reporting Services являться частью СУБД Yukon, дополнением к SQL Server 2000 или отдельно лицензируемым продуктом (или всем вышеперечисленным одновременно).

Исходные коды InfoPath и Reporting Services не зависят от СУБД Yukon. Оба продукта могут соединяться с SQL Server или MSDE 2000, а InfoPath работает с доку-
ментами служб XML Web service, созданных средствами VS.NET 1.0 или 1.1 или Microsoft SOAP Toolkit 3.0. Разработчики программировали InfoPath на языках сценариев JScript или VBScript и XSLT. Reporting Services являются самодостаточными, а вот конструктор отчетов требует наличия VS.NET. Похоже, что после выпуска СУБД Yukon как InfoPath, так и Reporting Services приобретут определяемые ею улучшения.

Будет ли версия SQL Server Yukon оцениваться как законченная, объектно-реляционная «универсальная база данных», вобравшая в себя большинство или все возможности и производительность Oracle 9i и IBM DB2 UDB 8.1? Говорить об этом даже в качестве предположения, безусловно, преждевременно. Стоит подождать, пока Microsoft окончательно соберет вместе функции Yukon в заключительной бета-версии и отладит все эти части в одном или двух выпусках release candidate. Также разумно не спешить спорить о том, увеличит ли Yukon долю Microsoft в сегменте рынка СУБД масштаба предприятий и сохранится ли репутация SQL Server как лидера по соотношению «производительность/цена» во всех секторах бизнеса реляционных БД (с возможным исключением бесплатно или практически бесплатно распространяющихся Linux/MySQL или PostgreSQL). Конечно, Microsoft может одержать верх над всеми конкурирующими СУБД выпуском аналога MSDE для Yukon. Однако до настоящего времени не появилось намеков на то, будет ли выпущена версия MSDE для Yukon в качестве преемника MSDE 2000, но, возможно, это верное предположение.

Ссылки:

Лучшие приемы работы по передаче журналов

Рон Тэлмэйдж (Ron Talmage)

На ноябрьской, 2002 года, конференции PASS (Professional Association for SQL Server — профессиональная ассоциация по SQL Server)
в Сиэтле, Рон Тэлмэйдж сделал блестящую презентацию на тему передачи журналов (log shipping). (Если вы присоединились к PASS, то у вас есть доступ ко всем трудам не только этого саммита, но также и к материалам конференций, прошедших в предыдущие годы — www.sqlpass.org.) Он экспромтом ответил на такое количество вопросов аудитории, что я попросил его обобщить уроки, полученные им при использовании технологии передачи журналов.

Не забывайте, что теоретически можно настроить передачу журналов на любой БД SQL Server 7.0 или 2000 — даже на той, что работает «под крышей» другого продукта.

Передача журналов является проверенной временем техникой передачи данных из БД основного сервера на сервер «горячего» резерва. SQL Server 2000 обеспечивает дружественный пользователю интерфейс не только для ее настройки, но и мониторинга. В статье приведены некоторые рассуждения, которые стоит принять во внимание при планировании передачи журналов.

Терминология, относящаяся к передаче журналов

Передача журналов — это просто автоматизированный способ синхронизации БД резервного сервера с БД основного. Идея заключается в том, чтобы «передавать», то есть резервировать, копировать и загружать, файл журнала транзакций с одной базы данных в копию БД на резервном сервере. Чем короче интервал между резервированием, копированием и загрузкой, тем «горячее» резервная БД. Как правило, передача журналов осуществляется попарно — между двумя серверами, — поэтому нет необходимости различать сервер и БД. Если выполняется резервное копирование более одной базы данных на каком-либо сервере, то у вас окажется более одной пары передачи журналов. Поскольку обычно пары создаются между двумя различными серверами, сервер (базу данных), для которого выполняется резервное копирование, принято называть основным (-ой) (primary) сервером (базой данных), а сервер (базу данных), на котором выполняется восстановление, — резервным (-ой) (secondary).

Целью передачи журналов является поддержание БД резервного сервера в состоянии готовности, позволяющем ему занять место основного сервера, если тот выйдет из строя или будет выключен из работы по какой-либо причине. Можно выполнять передачу журналов от одной БД к другой и на одном сервере, но это лишено всякого смысла. В этом случае, если основной сервер выйдет из строя, вы также утратите и ваш резервный сервер!

Фактически процесс передачи журналов построен на базе возможностей резервного копирования и восстановления SQL Server. В передаче журналов нет ничего, что нельзя было бы выполнить вручную. Насколько вам известно, нет препятствий для выполнения вручную операций резервирования, копирования и восстановления журналов транзакций. Однако тогда этот процесс не будет называться «передачей журналов», поскольку не будет выполняться автоматически. Многие администраторы БД имеют свои, специально написанные на T-SQL, решения по передаче журналов, но компания Microsoft в редакциях SQL Server 2000 Enterprise и Developer Editions предоставляет поддерживаемую утилиту для передачи журналов.

Преимущества передачи журналов

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

Передача журналов в SQL Server 2000 Enterprise Edition

Утилита передачи журналов в SQL Server 2000 Enterprise Edition использует мастер Database Maintenance Plan wizard для установки и мониторинга. В дополнение к основному и резервному серверам, он добавляет утилиту мониторинга, действующую на третьем сервере — сервере мониторинга (monitor server). Основной и резервный сервер записывают на сервере мониторинга свои действия по резервированию, копированию и загрузке журналов. На центральном сервере мониторинга можно регистрировать информацию о многих парах серверов, между которыми налажена передача журналов, что дает возможность контролировать всю активность и создавать предупреждения, если какое-либо событие передачи журналов провалится. Как правило, сервер мониторинга создается отдельно от основного и резервного сервера, но необязательно. Его также можно поместить либо на основной, либо на резервный сервер (по умолчанию мастер Database Maintenance Plan wizard помещает его на основной). Если вы не хотите задействовать третий сервер, организуйте мониторинг на резервном сервере, а не на основном. Тогда, даже если основной сервер выйдет из строя, вы будете продолжать получать предупреждения от мониторинга. (При размещении мониторинга на отдельном сервере для его работы достаточно наличия SQL Server 2000 Standard Edition. Enterprise Edition необходим для работы основного и резервного сервера.)

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

Создание сценариев передачи журналов в SQL Server 2000 поддерживается не полностью в основном потому, что не существует поддерживаемого способа создания сценария Database Maintenance Plan. (На самом деле, это относится только к части Maintenance Plan, выполняющей резервирование журнала транзакций. Вы можете использовать хранимую процедуру передачи журналов для управления процессами копирования и загрузки и эти процедуры задокументированы в справочной системе Books Online.)

Передача журналов в SQL Server 2000 Standard Edition

Если вы используете редакцию SQL Server 2000 Standard Edition, то все равно можете использовать передачу журналов. Возьмите утилиту передачи журналов, поставляемую вместе с Back Office Resource Kit 4.5
(издательство Microsoft Press дало ему прозвище BORK), или используйте Simple Log Shipper, поставляемую в составе SQL Server 2000 Resource Kit, — также от Microsoft Press.

При работе с утилитой из Back Office для организации передачи журналов на SQL Server 2000 просто добавьте SET QUOTED_IDENTIFIER OFF в верхнюю часть сценария log_ship_sprocs.sql, и он будет прекрасно компилироваться и работать. А работая с утилитой Simple Log Shipper из SQL Server 2000 Resource Kit, можно модифицировать sp_ApplyStandByLog.sql, чтобы использовать новую возможность ROLLBACK IMMEDIATE оператора ALTER DATABASE, позволяющую убедится, что все пользователи будут отключены от БД перед восстановлением журнала.

Одной передачи журналов недостаточно

БД SQL Server хранит немало информации о самой себе, но передача журналов в нее не входит. Даже если резервный сервер содержит все данные основного сервера, на него необходимо кое-что скопировать для гарантии того, что резервный сервер на самом деле сможет заменить основной в случае аварии. SQL Server 2000 Books Online содержит инструкции для передачи регистрационных имен для входа в систему и их разрешений с основного на резервный сервер1 . Но регистрационные имена — только часть этой работы.

Ресурсы, посвященные передаче журналов

Если БД master содержит пользовательские системные сообщения (в таблице sysmessages) или пользовательские хранимые процедуры и функции, то необходимо убедиться, что они также переданы на резервный сервер. Кроме того, на основном сервере могут быть созданы задания SQL Agent, DTS-пакеты и определения связанных серверов, которые также должны существовать на резервном сервере. Это верно и для хранимых процедур или функций, выполняющих перекрестные вызовы баз данных, так что, возможно, вам придется выполнять копирование более чем с одной БД.

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

Динамические DTS-пакеты

Фил МакКормэк (Phil McCormack)

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

В прошлом году я был вовлечен в работу над проектом, для которого потребовалось создать 23 независимых интерфейса к внешним системам. Очевидно, что некоторые из этих интерфейсов были к одной и той же системе (главным образом, Oracle), только несколько нуждались в ежедневном доступе, в то время как остальные — в доступе раз в неделю или месяц. Как правило, внешним источником являлась Oracle, но нам также требовались отдельные интерфейсы к FoxPro, Excel, SQL Server и ASCII.

Проект имел две среды разработки: текущую и для старого выпуска. Для тестирования также использовались две среды: для тестируемого проекта и для проверки на приемлемость для пользователя. Реальная эксплуатация осуществлялась в единственной среде. Для каждого интерфейса в каждой из сред должны были существовать разные исходные и целевые БД. Например, наша система тестирования должна была соединиться с системой тестирования Oracle, наша среда разработки — с их средой разработки и т.д. Я посчитал, что 23 статических DTS-пакета для каждой из сред дадут в общей сложности 115 DTS-пакетов. Изменение в одном из этих пакетов потребует внесения аналогичных изменений во все среды, включая эксплуатационную (при выпуске программного обеспечения это приходилось делать не раз за 12 месяцев).

Сначала я сосредоточился на системах Oracle и, чтобы упростить задачу, определил, что могу остановиться только на двух БД, исходной и целевой, так чтобы ядро каждого из этих интерфейсов составляла единственная задача по преобразованию данных. Мой план состоял в том, чтобы манипулирование данными через хранимые процедуры выполнялось как отдельный шаг задания (job step) SQL Agent.

Поэтому мой дизайн высокого уровня для этих интерфейсов заключался в том, чтобы запустить первым шагом задания в SQL Agent простой DTS-пакет, состоящий из единственного оператора SELECT, выполняемого на системах Oracle, за которым следовал бы другой шаг задания, выполняющий хранимые процедуры для манипулирования импортируемыми данными. Однако у меня по-прежнему оставалась одна большая проблема — число сред и число интерфейсов.

Я не хотел создавать каких-либо физических DTS-пакетов на сервере, поскольку при переносе интерфейсов с одного сервера на другой требуется выполнить по крайней мере три изменения: по одному изменению в исходной и целевой БД и одно в операторе SELECT, используемом для этого преобразования. Так я пришел к идее создания динамического DTS-пакета. Используя DTS API, COM+ и единственную таблицу SQL Server для хранения информации о пакете, я смог разработать решение, описываемое мною в данной статье.

Обозреваем ваш SQL-ландшафт

Дэвид Бреннан (David Brennan)

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

Не стоит и говорить о том, что вы, как SQL-администратор, должны быть знакомы не только со всеми серверами, находящимися на вашем попечении, но также со всеми размещенными на них БД. Вашей обязанностью также является оповещение разработчиков о любых добавлениях, изменениях или удалениях в любой из структур этих БД. По мере того, как объект БД изменяется, разработчику требуются свежие метаданные, а также описание назначения объекта. Очевидно, что вы (или разработчики) можете собрать эту информацию с помощью Enterprise Manager, но, насколько известно, полная информация об объекте не хранится (чтобы облегчить вам жизнь) в одном месте. Инструменты сторонних производителей, такие как Erwin компании Computer Associates, ER/Studio или Describe компании Embarcadero и собственная разработка Visio Enterprise компании Microsoft предоставляют возможное решение, однако требуют существенных затрат времени и денег. Кроме того, сначала придется убедить ваших разработчиков изучить, а затем использовать эти сторонние инструменты. Это неудобство, являющееся следствием отсутствия у SQL Server полноценного центра-
лизованного хранилища метаданных, стало абсолютно очевидным при выполнении последнего задания в составе группы разработчиков, начавших разработку нового Web-приложения.

В этой статье я опишу основанное на ASP Web-приложение, созданное мною для сведения воедино атрибутов объекта на одной Web-странице. Я преднамеренно разработал его так, чтобы весь код доступа к данным содержался в исполняемом на сервере сценарии, а выполняемые на клиенте сценарии сводились к минимуму. Также я использовал две различные объектные модели — ADO и SQL-DMO, чтобы привести примеры работы с каждым из этих различных источников метаданных. Это приложение использует элемент управления ActiveX — TreeView — и требует, чтобы на сервере, на котором запущен IIS, был установлен по крайней мере Query Analyzer.

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

Опции, влияющие на поведение блокирования SQL Server

Кевин Клайн (Kevin Kline), Байя Павлиашвили (Baya Pavliashvili)

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

Если вследствие блокирования у вас возникают проблемы, сначала попытайтесь переписать ваши хранимые процедуры, проанализируйте еще раз стратегию построения индексов и продумайте изменение вашей модели данных. Затем, если вы перепробовали все другие ресурсы и не получили желаемого результата, попробуйте использовать в качестве последнего средства указания блокирования (locking hint) и опции оператора SET.

Настройка запросов через указания блокирования

Указания процессору запросов (query hint) инструктируют SQL Server, как запросить и реализовать блокировки способом, отличным от поведения по умолчанию. Фактически, термин указание является явным преуменьшением. Принято считать, что указание является чем-то вроде дружеского совета, но указания процессору запросов являются скорее директивой, чем предложением. У SQL Server нет выбора: после моего распоряжения оптимизатору запросов (query optimizer) использовать указание он будет, как верный слуга, твердо придерживаться этого порядка. SQL Server не станет обсуждать мое предложение или называть меня тупицей, даже если выполнение за-проса с моим указанием — ужасная идея. Поэтому я рекомендую тщательно проверять ваши запросы как с использованием этих указаний, так и без них, перед тем как разворачивать ваше приложение в реальной среде эксплуатации.

После такого «пылкого» инструктажа, вы, вероятно, подумаете, что указания блокирования нужны только на случай крупных проблем. Но это не совсем так. Использование указаний блокирования поможет вам значительно улучшить производительность вашего приложения! Кроме того, никогда не помешает попробовать различные варианты, а потом уже выбирать лучший путь.

Большинство указателей блокирования используются с оператором SELECT. Хорошим примером использования указателя NOLOCK является ситуация, когда вы запускаете отчет, которому не обязательно быть на 100% точным. Если он работает с изменяющимися таблицами, эти изменения могут привести к тому, что оператор SELECT вынужден будет ждать завершения других транзакций. Если вы используете указатель NOLOCK, то ваш запрос не будет ждать: он прочтет «незафиксированные» записи и будет готов намного быстрее.

Иногда может потребоваться найти указатели блокирования для операторов INSERT, UPDATE и DELETE. Например, если вы хотите быть абсолютно уверены, что никто не сможет изменить записи, когда выполняется ваш оператор UPDATE, то используйте указатель UPDLOCK. По умолчанию SQL Server сначала накладывает разделяемые блокировки (shared lock), а затем поднимает их до UPDLOCK, когда все готово для фиксации UPDATE-транзакции. Использование UPDLOCK переопределяет это поведение, гарантируя, что данные будут полностью заблокированы на все время транзакции.

Как известно, блокировка — это компромисс между способностью обслуживать множественные запросы и использованием ресурсов. Я видел приложение, использующее указатель ROWLOCK с каждым из операторов INSERT, UPDATE и DELETE. Идея заключалась в том, чтобы убедить SQL Server блокировать каждый раз отдельные строки, таким образом уменьшая вероятность блокирования. Запомните: если SQL Server не имеет достаточных ресурсов для того, чтобы выполнить ваш запрос, то он будет ждать до тех пор, пока этот ресурс не освободится. Если ваш запрос «сожрет» каждый байт в оперативной памяти, доступной для SQL Server, тогда у сервера не останется достаточно памяти для других задач. Поэтому взвесьте все за и против и используйте указатель ROWLOCK осторожно.

Интеграция SQL Server 2000 с Active Directory

Марцин Полихт (Marcin Policht)

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

Active Directory — это служба каталогов, основанная на протоколе LDAP, впервые появившаяся в Windows 2000 (ее обновленная версия доступна как часть платформы Windows 2003, выпущенной 24 апреля 2003). Она обеспечивает основанную на контейнерах иерархическую организацию объектов, отображающую разные элементы доменов, таких как пользователи, группы, принтеры или компьютеры (а также их неотъемлемые свойства). Внутренний механизм репликации и возможность существования многих основных контроллеров домена (multimaster) делают ее масштабируемой и мощной. Кроме того, она имеет набор функций, присущих любой службе каталогов, таких как возможности углубленного поиска и расширяемость.

Интеграция SQL Server 2000 с Active Directory, по существу, означает, что SQL-серверы, их компоненты и атрибуты (такие как публикации репликаций, кубы и объекты data mining) могут быть зарегистрированы в Active Directory. Это не только облегчает поиск в масштабах организации тех возможностей, в которых могут быть заинтересованы клиенты, разработчики или приложения, но также активизирует функциональную прозрачность, делающую эти возмож-
ности независимыми от их физического расположения (что бывает особенно полезным, когда специальные функциональные возможности необходимо перенести на другой компьютер).

Конфигурирование Query Analyzer

Том Моро (Tom Moreau)

Обращались ли вы когда-нибудь с запросом на расширение функциональных возможностей какого-либо приложения по адресу sqlwish@microsoft.com? Да, это делали многие из нас, и порой наши просьбы, как это ни странно, удовлетворялись. Прочтите, как Том Моро описывает свой последний опыт обращения с подобным запросом.

Если хотите, можете называть меня неизлечимым оптимистом, но для меня не было чем-то необычным послать электронное письмо по адресу sqlwish@microsoft.com. (по этому адресу можно направлять запросы к команде SQL Server с предложениями по улучшению продукта). Не так давно я отправил письмо по поводу Query Analyzer, после того как обнаружил, что могу увеличить шрифт в панели запроса (query pane), а вот в панели результатов (results pane) у меня это не получается.

Я хотел увеличить шрифты, чтобы сделать проводимые презентации более понятными для моих слушателей. Мне показалось довольно странным, что это можно сделать это в одной панели и нельзя в другой. Ответ от Герта Дрэперса (Gert Drapers), дизайнера ин-фраструктуры управления SQL Server, пришел быстро. Он сообщил, что такая особенность действительно существует, и объяснил, как добиться того, что мне требовалось. После чего упомянул (думаю, чтобы возбудить мой аппетит), что знает способы переключения между этими опциями в считанные секунды. Меня это «зацепило» и я попросил его раскрыть секрет, что он и сделал.

Если вы откроете окно Options в меню Tools и щелкните вкладку Fonts, то получите информацию о самом шрифте, а также о его размере и цвете для разных частей Query Analyzer. Список Category подскажет, какую часть Query Analyzer вы настраиваете. Например, панель запроса упоминается как Editor. Панель результатов соответствует двум категориям: Results Text и Results Grid/Open Table. Существуют, конечно, и другие вкладки этого диалогового окна, позволяющие устанавливать значения умолчания для различных элементов интерфейса.

Кроме того, шрифт для различных частей Query Analyzer можно изменить, щелкнув правой кнопкой мыши нужную часть и выбрав Font из контекстного меню.

Когда Query Analyzer будет выглядеть так, как вам хочется, можно щелкнуть кнопку ОК, и все будет прекрасно, пока вам не понадобиться пойти на презентацию и снова заняться изменениями его внешнего вида. Для этого вам потребуется пройти через все это упражнение еще раз и опять изменить ваши настройки. Ясно, что после презентации вы захотите восстановить прежние настройки. Похоже, подобные занятия могут отразиться на вашей производительности…

Не буду больше запугивать вас, а лучше расскажу, как упростить решение этой задачи. Вкладка General диалогового окна Options содержит две кнопки — Load и Save. Именно здесь можно сохранить вашу конфигурацию в файл, а затем загрузить ее, когда потребуется (расширение файла по умолчанию .sqc). Вы сможете переключаться между разными конфигурация-
ми. Все, что нужно сделать, — это создать одну конфигурацию для вашей нормальной работы и еще одну для специальных мероприятий, таких как презентации. Вы спрашиваете, а как же SQL7? Сожалею, но вы не сможете сохранить вашу конфигурацию в SQL7 — эта функция появилась только в SQL 2000.

Но выход есть всегда. Query Analyzer — это приложение isqlw.exe, и если вы пороетесь в справочной системе Books Online, то обнаружите, что для нее существуют параметры командной строки, подобные тем, что есть у isql.

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

Hosted by uCoz