(Возврат на основную страницу)
Недавно мне довелось беседовать с Дэвидом Шанком (David Shank), руководителем группы разработки документации для SQL Server (Books Online). Он щедро поделился планами на будущее.
Одна из основных целей, которые ставит перед собой Дэвид, — это сокращение времени доставки обновленного комплекта документации пользователям. При этом корректировки на основе замечаний пользователей и их предложений по расширению документации должны быть более гладкими.
Дэвид объяснил, что группа решает трудную задачу — выпускать обновленную версию каждый квартал. В течение жизненного цикла SQL 2000 (более 5 лет) мы видели только несколько обновлений документации, так что попытка перейти на четыре обновления в год — это существенный шаг вперед. Вы можете спросить, действительно ли это необходимо. Я полагаю, что нужно. Данная тактика достойна внимания, учитывая те планы, которые Microsoft строит относительно развития документации (об этом я расскажу далее).
Однако высокая скорость обновления может создать дополнительную нагрузку на организации, которым и так приходится напрягать силы, чтобы держаться на плаву в море информации. Microsoft понимает эти проблемы и всегда старается дать организации возможность самостоятельно принимать решение о том, какая версия документации наилучшим образом отвечает ее потребностям. Каждая новая версия документации будет включать индексированные метки, четко отражающие информацию о новых и откорректированных статьях. В конце каждой статьи будет приводиться краткое описание изменений, облегчающее поиск новой информации. Последующие обновленные версии документации будут сопровождаться списком отредактированных статей, что позволит пользователям быстро разобраться, насколько данная версия им интересна. Первое доступное обновление документации от декабря 2005 года не имеет такого перечня, но включает раздел «New and Updated Books Online Topics», в котором перечисляются все откорректированные или новые статьи.
Далее Дэвид рассказал, что намеревается размещать материал, полученный через механизм обратной связи с пользователями, в течение недели. Полные версии документации, которые можно скачивать, не будут выпускаться еженедельно, но содержимое доступных в Интернете статей будет изменяться еженедельно или даже еще чаще. Дополнительно рассматривается возможность использования RSS для уведомления технических специалистов, которым это необходимо, обо всех изменениях, какими бы мелкими они ни были.
Дэвид особо подчеркнул важность для его группы механизма обратной связи. Подобная возможность появилась еще в версии для SQL Server 2000. Но там она была представлена крошечным значком с изображением конверта, который многие просто не замечали. Теперь же все выполнено гораздо нагляднее. В верхней части страницы находится ссылка «Send Feedback», а в нижней — раздел, позволяющий оценить качество документации по пятибалльной шкале.
И хотя Microsoft не обещает отвечать на каждое сообщение с оценкой качества документации, все сообщения изучаются и замечания должным образом учитываются при внесении корректив. Так, например, Дэвид отметил учебные курсы (Tutorial) в документации на SQL Server 2005 как хороший пример реакции на отзывы пользователей. Очевидно, что на начальном этапе планировали создавать учебные курсы в весьма ограниченном объеме. Однако на этапе бетатестирования продукта по результатам сообщений стало очевидно, что подобные разделы документации являются весьма ценными для пользователей. Как следствие, Microsoft приняла решение о расширении ресурсов на подготовку этой части документации.
В результате документация по SQL Server 2005 — это первый выпуск, в котором учебные курсы стали центральным компонентом всего комплекта. Заголовок первого уровня назван SQL Server 2005 Tutorials, финальная версия документации по SQL Server 2005 включает следующие разделы: Tools, Analysis Services, Data Mining, SQL Server Integration Services (SSIS), Notification Services и Reporting Services. Обновление от декабря 2005 добавляет семь новых и четыре измененных раздела. Их перечень можно найти в разделе «New and Updated Books Online Topics».
Меня также очень заинтересовало упоминание о том, что группа разработки документации рассматривает возможность использования виртуальных образов в качестве дополнения к учебным курсам в составе документации. Это связано с тем, что более или менее сложные разделы курсов часто требуют специально установленной и настроенной среды, в которой пользователь будет работать при прохождении материала курса. Так как не все пользователи обладают достаточной квалификацией или временем, чтобы создать такую среду самостоятельно, использование виртуальных образов существенно поможет делу. Первые шаги в этом направлении уже сделаны, по ссылке http://msdn.microsoft.com/virtuallabs/sql/default.aspx можно получить доступ к виртуальной лаборатории, где предлагается более десятка курсов по разным аспектам функциональности SQL Server.
Большинству администраторов баз данных SQL Server знакомы концепции кластеризации, даже если сами они не проводили кластеризацию. В этой статье Рэнди Пэк обсуждает кластеризацию под управлением Windows Server 2003.
Многие ИТкомпании применяют службы Microsoft Cluster Services (MSCS) для предоставления решений с высокой готовностью, отвечающих насущным требованиям бизнеса. Технология кластеризации созрела и стала развиваться с первых дней выхода версии SQL Server 6.5. С применением Windows Server 2003 Enterprise Edition мы можем реализовывать кластерные решения с восемью узлами в кластере. В этой статье мы обсудим, как может меняться наше представление о них, и еще ряд вопросов, которые нам, администраторам баз данных, необходимо учитывать при создании архитектуры новой кластерной среды. Вероятно, вам знакомы «стандартные» кластеры SQL, представляющие собой конфигурацию двух поддерживаемых серверов (см. «Важность HCL»), организованных в пары «активный/активный» или «активный/пассивный». В конфигурации активный/пассивный на одном сервере работают приложения (в данном случае SQL Server), а другой остается свободным. При возникновении сбоя активного узла службы Microsoft Cluster Services перенесут виртуальный (кластерный) SQL Server на другой узел (резервный) с минимальными прерываниями обработки.
· Раздел электронной документации SQL Server «Отказоустойчивая кластеризация».
· См. на www.microsoft.com/windows2000/techinfo/ howitworks/cluster/newclstr.asp обсуждение различий между кластеризацией под управлением NT4 и Win2K и на www.microsoft.com/windows2000/ techinfo/howitworks/cluster/introcluster.asp обзор кластеризации в Win2K.
· Проверенные рекомендации по конфигурированию Windows Clustering Server Cluster (MSCS) на www.microsoft.com/technet/prodtechnol/windowsNetserver/proddocs/ SCCon_Bp.asp.
· Глава из книги «Работа с кластерами» на www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/sql/proddocs/sql2kint/part3/88628c13.asp?frame=true.
· Глава из книги «Построение кластеров SQL Server 2000» из опубликованной в Интернете книги «Prescriptive Architecture Guide II» на http://www.microsoft.com/resources/documentation/msa/idc/all/solution/enus/pag/pag1/pag1c05.mspx?mfr=true.
· Технические материалы по отказоустойчивой кластеризации на www.microsoft.com/sql/techinfo/administration/2000/failovercluster.asp. Глава по отказоустойчивой кластеризации в SQL2000 SDK на http://msdn.microsoft.com/library/default.asp?url=/library/enus/adminsql/ad_clustering_7t9v.asp.
· Q325106 WebCast (от 21 июня 2002 г.) «Введение в кластеризацию в Microsoft SQL Server 2000» на http://support.microsoft.com/default.aspx? scid=/servicedesks/webcasts/wc051001/wcblurb051001.asp.
· На www.microsoft.com/windows2000/technologies/clustering/default.asp и www.microsoft.com/windows.netserver/techinfo/overview/clustering.mspx технологии кластеризации, включая новинки Windows Server 2003, такие как новый кворумный ресурс под названием «Набор большинства узлов», который позволяет строить кластеры серверов без разделяемого диска в качестве кворумного устройства, поддерживать EFS и кэширование на стороне клиента (CSC), известное также как Offline Files, и создавать виртуальные кластеры, которые можно применять для: 1) конфигурирования разных правил порта для разных кластерных адресов IP, где каждый кластерный адрес IP соответствует вебсайту или приложению, размещенному в кластере NLB; 2) фильтрации трафика, посылаемого определенному вебсайту или приложению на заданном узле кластера; 3) выбора узла в кластере, который будет использован для обслуживания трафика, посылаемого конкретному вебсайту или приложению, размещенному в кластере.
· Посмотрите и послушайте флешдемонстрацию, посвященную работе теневых копий в Windows 2003 Server, на www.microsoft.com/windows2000/technologies/storage/redirvssvdsdemo.asp.
· Q318605 INF: как SQL Server использует сертификаты, когда включен параметр принудительного шифрования протокола. «Для золотого выпуска SQL Server 2000 сначала SQL Server ищет в хранилище сертификатов сертификат с таким же именем, как полностью квалифицированное имя домена (FQDN) того компьютера, на котором работает SQL Server. Если SQL Server развернут на отказоустойчивом кластере, необходимо установить сертификат сервера с помощью FQDN виртуального сервера для всех узлов отказоустойчивого кластера».
·
Q295589 BUG:
исправление несовпадающих двоичных файлов в кластерном виртуальном серве
ре SQL.
· Q320524 BUG: программа установки SQL Server Service Pack 2 может перестать реагировать в среде кластера Windows, если имеется отключенная база данных.
· Q298568 HOWTO: перестройка базы данных MASTER в виртуальном (кластерном) экземпляре SQL Server 2000.
· Q323283 BUG: поставщик WMI SQL не работает при удаленном запросе данных из кластерного SQL Server.
· Q322716 INF: PeopleSoft eBill Payment — Benchmark. (Tехнические материалы — запуск на кластере Compaq ProLiant).
· Q318432 BUG: невозможно подключиться к именованному кластерному экземпляру через брандмауэр.
· Q289683 INF: сообщение об ошибке NoRemapPipes появляется в системном журнале, когда используется SQL Server 2000 на кластере Windows 2000.
В статье Q327518 перечислены наиболее распространенные несовместимые характеристики аппаратных средств, которые могут вызвать проблемы при кластеризации.
· Сбой при установке SQL Server Failover Clustering.
· В решении по кластеризации недостаточно изолированы совместно используемые диск и адаптеры шины узла (HBA) от других устройств на разделяемой шине.
· Контроллер SCSI не поддерживает работу в среде с несколькими инициаторами.
· Адаптер HBA не обрабатывает резервирование, освобождение или возобновление устройства на разделяемой шине должным образом.
· Механизм кэширования в контроллере несовместим с конфигурацией кластера.
· У сетевых адаптеров для взаимодействия внутри кластера слишком большие задержки.
· Контроллер RAID не копирует сведения о конфигурации в контроллеры должным образом.
· Шина PCI неправильно сконфигурирована, неверные адаптеры расставлены на неверных шинах (первичной, вторичной, третичной).
· Контроллеры несовместимы с типом «ресурса физического диска».
· Контролер SCSI не развертывает нужное завершение.
Этот список включает не все вопросы, которые могут быть вызваны неполадками серверного кластера. Ни один из этих аспектов не обнаруживается средствами PSS. Все эти вопросы обычно выявляются при тестировании полного кластерного решения на совместимость с Cluster HCL. Самая последняя версия Cluster HCL доступна на сайте www.microsoft.com/hcl.
Имеется целый ряд важных малоизученных вопросов о том, что происходит в кластерной среде. Для корпорации Microsoft кластер обеспечивает высокую готовность (избыточность) и ничего более — разумеется, не разделение нагрузки и балансировку в динамическом контексте. Важно, что с позиций Oracle кластеризация включает совершенно иные функциональные возможности. В моей фирме мы управляем семью парами кластеров «активный/активный» с SQL 2000 под управлением Win2K, мы развертываем и тестируем приложения на узле кластера точно так же, как на обычном сервере. Мы следуем рекомендациям Microsoft и не смешиваем SQL Server и другие приложения на одном компьютере. Но это придется сделать на время ремонта в случае сбоя сервера, ведь альтернативой будет неработоспособность производственной системы.
Основная проблема в сегодняшней технологии кластеризации заключается не в том, как «это работает», а в том, «во что это обойдется». Да, это довольно дорого, но намного дешевле, чем большая вычислительная машина. И я считаю, что решение по разнородной кластеризации обеспечивает такую надежность, что мы еще увидим, как это приведет к вытеснению больших вычислительных машин.
Это вторая из трех статей об использовании OPENQUERY в союзе с хранимыми процедурами и пользовательскими функциями (смотрите в номере за октябрь 2005 г. первую статью этой серии «Преодоление барьера между хранимыми процедурами и функциями»). В ней автор описывает механизм работы самого OPENQUERY и рассказывает, как обойти ограничения «фазы метаданных» OPENQUERY.
Порой, когда вы собираетесь написать хранимые процедуры SP для автоматизации некоторых задач системного администрирования, вам приходится пожалеть о невозможности соединить результирующий набор системной SP с результатами других SP — или даже команд DBCC — в одном операторе SELECT. Иногда вам надо внедрить пользовательские функции (UDF), чтобы облегчить разработчикам кодирование приложений для баз данных. И какой администратор баз данных не сожалел о невозможности использовать в функциях какуюнибудь (обычно «недокументированную») SP, которая входит в приложение другой фирмы — SAP, MAXIMO (www.mro.com) или Hansen (www.hansen.com), — или просто поддержать пользователей, которые хотят использовать данные в приложениях иных производителей, витринах или хранилищах данных или же обрабатывать их в Web? Сталкиваясь с такими частными системами, вы с болью ощущаете необходимость упаковать их хранимые процедуры непосредственно в функцию или оператор SQL, чтобы лучше поддерживать своих разработчиков и пользователей баз данных.
Это вторая из трех статей, в которых я показываю, как облегчить вызов хранимых процедур SP, расширенных хранимых процедур XP и вызовов DBCC прямо в функции или операторе SQL. В первой статье я представил три очень распространенных случая применения, позиционируя OPENQUERY как единственное жизнеспособное решение для поддержки прямого применения SP, XP и вызовов DBCC в функции или операторе SQL. Здесь я детально изучаю OPENQUERY с формальных позиций, диагностируя его ограничения в поддержке сценариев случаев применения, и продолжаю обсуждение способов обойти ограничения OPENQUERY.
Иногда требуется получить конкретные данные, если они доступны, а если нет, то найти им альтернативу. Трудно сделать это, когда приходится идти по списку альтернатив до тех пор, пока не будет найдено необходимое. Доктор Том Моро исследует два подхода.
Не так давно один читатель задал мне интересный вопрос, относящийся к таблице лиц и таблице их телефонов. У каждого лица может быть несколько разных типов телефонов — домашний, рабочий, сотовый или факс, — но, как правило, по одному каждого типа. Требовалось получить список лиц, указав в нем только по одному телефону для каждого. Интересно, что были заданы приоритеты для телефонов: сначала шел домашний телефон (если он имелся), затем рабочий (если домашний был недоступен) и т. д.
Все чаще и чаще я сталкиваюсь с тем, что разработчики по какимто причинам хотят использовать идентификаторы GUID в качестве первичных ключей, и, что еще хуже, в кластеризованных индексах. Никак не возьму в толк, зачем надо применять GUID. Вопервых, они огромного размера — раза в четыре больше, чем целое, используемое в качестве первичного ключа.
Приведем основные причины, по которым НЕ следует пользоваться GUID.
· Они слишком большие, чтобы стать эффективным индексом. Чем меньше индекс, тем лучше, — это позволяет быстро найти значение ключа. Ни при каких условиях 16байтный индекс не сравнится с 4байтным.
· Их слишком трудно запоминать администраторам баз данных, и потому сложно вникать в вопросы с данными.
· Они не гарантируют уникальность. Вероятность того, что значение GUID будет уникальным, весьма велика, но это не 100%.
· Они слишком быстро приводят к фрагментации таблицы. Поскольку они совершенно случайны, нельзя знать заранее, где произойдет следующая вставка, поэтому кластеризация по этому ключу НЕПРЕМЕННО вызовет фрагментацию.
Поэтому не позволяйте своим разработчикам использовать GUID, особенно в системах, которые вам самим придется сопровождать. Проблема состоит в том, что ничего нельзя менять без твердых цифр и никто не проводил тестирования такого рода вещей. А вот я протестировал! Разница в производительности потрясает. Конечно, найдутся разработчики, которые все же будут настаивать на применении этих идентификаторов, но пусть стараются. Однако одно несомненно — ничего нельзя менять без обоснования в виде реальных цифр. Но теперь вы можете пойти к ним и показать, почему в базах данных лучше обойтись без GUID.
У идентификаторов GUID есть своя ниша, но она, разумеется, не расположена рядом с кластеризованными индексами. Если вам все же приходится хранить GUID, создайте для него столбец гденибудь в конце таблицы, а кластеризованный индекс стройте по ID, а не по нему. Тогда вы сможете обращаться с запросом к нужному GUID, а затем взять соответствующий ему ID и выполнять все, кроме первоначального поиска, по этому маленькому полю ID. Помоему, очень забавно, что разработчики получают требование уникальности, — их мозг попадает в заложники к GUID. Им в голову не приходит ничего иного. Один раз меня даже назвал идиотом один программист, который считал, что логические требования — это самый важный аспект приложения и что учитывать в приложении соображения производительности — кратчайший путь к провалу. Попробуйтека воспользоваться этой логикой и запустите 500 или 1000 одновременно работающих пользователей. А когда ваше приложение встанет, позвоните своему заказчику и скажите ему, что производительность приложения не такая уж важная штука.
У меня все.
Табл. 1
|
Тип данных |
Число пользователей |
Транзакций/с |
Всего выполнено |
Среднее время транзакции |
Максимальное время транзакции |
Фрагментация, % |
|
ID |
100 |
2422 |
619905 |
0,041 |
18,426 |
7,95 |
|
ID |
400 |
3374 |
923871 |
0,118 |
18,426 |
7,94 |
|
GUID |
100 |
245 |
71224 |
0,407 |
18,426 |
46,58 |
|
GUID |
400 |
84 |
24415 |
4,862 |
18,426 |
48,98 |
На базе CTP апреля 2005
В заключительной части статьи о задаче ExecuteSQL, входящей в состав служб интеграции SQL Server Integration Services для версии SQL Server 2005, мы продолжим рассматривать примеры ее применения.
Неразрешимые блокировки (deadlock) стали неизбежным событием в современной архитектуре реляционных СУБД и повседневной реальностью в среде OLTP с большими объемами данных. Но благодаря .NET Common Language Runtime (CLR) у программистов, работающих с SQL Server 2005, появился новый способ обработки ошибок. В этой статье Рон Тэлмейдж показывает, как использовать TRY/CATCH разрешения тупиковых ситуаций.
Язык TSQL прекрасно справляется с доставкой этого сообщения, но не так хорош в предоставлении средств, которые могут предотвратить возникновение данной ошибки. Подозреваю, что практически все администраторы баз данных знакомы с сообщением об ошибке 1205 «deadlock victim»: Transaction (Process ID 52) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction. — Транзакция (процесс с идентификатором 52) попала вместе с другим процессом в тупиковую ситуацию при блокировании ресурсов и была выбрана в качестве жертвы при разрешении этой ситуации. Перезапустите транзакцию.
Когда тупиковая ситуация возникает в вашем коде, неважно, насколько глубоко приложение погружено в хранимые процедуры; выполнение пакета с выбранным в качестве жертвы тупика процессом spid будет остановлено, и клиенту будет послано извещение об ошибке 1205. Несмотря на то, что в сообщении предлагается повторить транзакцию, сделать это из кода TSQL нельзя. Повторный запуск должен производиться из вызывавшего приложения. Ошибку просто нельзя отследить, и бесполезно обращаться к @@ERROR.
(Возврат на основную страницу)