(Возврат на основную страницу)
Майкл Оти (Michael Otey)
На июньской конференции Tech Ed старший вице-президент
компании Microsoft Пол Флес-снер (Paul Flessner) объявил о том, что появление
очередной версии SQL Server — Yukon, — первоначально запланированное на конец
этого года, а затем перенесенное на первую половину 2004 года, состоится не
ранее второй половины следующего года. Сама отсрочка выхода продукта не является
чем-то особенным: сможете ли вы припомнить какой-либо продукт Microsoft,
выпущенный вовремя?
Но о столь значительной, более чем на год, отсрочке компания объявляет нечасто.
С точки зрения заказчика, подобная отсрочка — вещь неплохая. Она свидетельствует о том, что Microsoft потребовалось дополнительное время на выпуск качественного продукта, что дает многим предприятиям сферы информационных технологий некоторую передышку до выхода новой версии СУБД. Например, из 767 человек, ответивших на проведенный в августе онлайновый опрос журнала SQL Server Magazine, 33 процента используют SQL Server 7.0 наряду с SQL Server 2000, а 7 процентов продолжают работать только с SQL Server 7.0. Из 56 процентов респондентов, сообщивших, что их организации используют исключительно SQL Server 2000, многие, похоже, только сейчас достигли «оптимального периода» в жизненном цикле продукта. После первоначального внедрения и выполнения последующих задач по миграции, они лишь начинают в полной мере использовать все преимущества расширенных функциональных возможностей SQL Server 2000.
И хотя задержка выпуска Yukon является хорошей новостью для многих заказчиков, сама компания Microsoft столкнулась с некоторыми существенными финансовыми и рыночными проблемами, связанными с ней. SQL Server является третьим по величине серверным продуктом Microsoft, доход от которого (согласно компании Gartner) за 2002 год исчисляется 1,2 млрд. долларов, вырученных за обновление продукта имеющимися заказчиками и за вложение средств в расширенные функциональные возможности SQL Server 2000 новыми клиентами. Перенесение срока выхода Yukon, несомненно, будет стоить компании немалых денег, лишая выручки за обновление и, возможно, замораживая рынок новых продаж SQL Server, поскольку многие из потенциальных заказчиков ожидают появления более свежего выпуска. Кроме того, Microsoft не выпускала новой версии SQL Server уже более 2 лет. С момента выхода SQL Server 2000 компании IBM и Oracle выбросили на рынок СУБД масштаба предприятий усовершенствованные версии своих продуктов. Кроме того, наблюдается развитие рынка недорогих СУБД, отмеченное новым выпуском mySQL с открытым исходным кодом и с набором компонентов управления, обладающих поразительным сходством с инструментом SQL Server Enterprise Manager.
К счастью, Microsoft надежно защищена в той области, где отсрочка выхода продукта могла бы оказаться самой болезненной — в сфере business intelligence. Business intelligence является одной из наиболее стремительно растущих областей на рынке СУБД, и 3–4 года без значимых улучшений — слишком большой срок. Но реализованное Microsoft интегрирование OLAP Services с SQL Server 7.0 и Analysis Services с SQL Server 2000 позиционирует SQL Server как явного лидера на рынке в сфере business intelligence. И даже после выхода новых версий своих продуктов компаниям IBM и Oracle еще предстоит пройти значительный путь, чтобы догнать функциональные возможности business intelligence в SQL Server.
Хотя запаздывание выхода Yukon имеет финансовые последствия и означает отставание SQL Server в состязании версий, все же я аплодирую Microsoft за то, что она взяла отсрочку. Основная масса сообщества SQL Server еще не готова к новому выпуску, и SQL Server 2000 еще не исчерпала всех своих возможностей. И что наиболее важно, выпуск не полностью готового продукта — это худшее, что можно себе представить. SQL Server компании Microsoft всегда был продуктом высочайшего качества, и поддержание этого стандарта является чрезвычайно важным.
Том Моро (Tom Moreau)
Некоторые из вас помнят время, когда резервное копирование и восстановление SQL Server называлось выгрузкой (dump) и загрузкой (load). Но не только оно претерпело изменения по сравнению с «античными» версиями SQL Server. В этой статье доктор Том Моро рассматривает опцию STANDBY оператора RESTORE.
В качестве MVP (Most Valuable Professional) по SQL Server мне приходится отвечать на массу вопросов в открытых группах новостей (фактически, именно поэтому я и стал MVP). Одна из поднятых тем была связана с тем, что позволяет делать и как работает опция STANDBY оператора RECOVER. Думаю, обзор этой опции, а также процесса восстановления в целом окажется достаточно поучительным.
Так же, как и в ранних версиях SQL Server, вы можете выполнять полное резервное копирование и резервное копирование журнала транзакций (см. врезку «BACKUP: синтаксис»). После появления SQL 7.0 к этому списку добавилось дифференциальное резервное копирование, копирование файлов и групп файлов. Однако восстановление резервных копий (см. врезку «RESTORE: синтаксис») требует некоторого обдумывания и планирования, и чем тщательнее вы отнесетесь к нему, тем лучше. Итак, прежде чем начать обсуждение опции STANDBY, я хотел бы воспользоваться удобным случаем для обзора опций RECOVERY и NORECOVERY.
Опцией по умолчанию является RECOVERY. В этом случае SQL Server выбирает все незавершенные транзакции и откатывает их. Другими словами, любые страницы данных, затронутые в ходе выполнения этих незавершенных транзакций, будут восстановлены в том состоянии, в котором они находились до начала транзакций. После этого БД пребывает в согласованном состоянии, и вы получаете доступ к данным как для чтения, так и для записи.1 К сожалению, применив опцию RECOVERY, вы больше не сможете восстановить журналы транзакций (подробнее об этом — позже).
Опция NORECOVERY работает как раз наоборот. Любые страницы данных, затронутые незавершенными транзакциями, остаются без изменений. В результате БД находится в несогласованном состоянии, и вы даже не имеете доступа к ней. Все, что вы можете сделать, — это:
восстановить журнал транзакций — первый, выполненный после резервной копии, только что восстановленной вами;
восстановить дифференциальную резервную копию;
восстановить БД.
Рон Тэлмэйдж (Ron Talmage)
Если вы с нетерпением ждали очередных статей Рона Тэлмэйджа, посвященных стандартам, соглашениям и практическим советам, не па-дайте духом. Просто он посчитал свое новое открытие заслуживающим внимания, правда, отнюдь не в качестве передового опыта. Следите за его будущими статьями, действительно рассказывающими о лучших приемах работы.
Недавно ко мне пришел разработчик с интересной проблемой: он хотел изменить определение столбца таблицы с NULL на NOT NULL, используя сценарий, генерируемый с помощью диалогового окна Design Table в Enterprise Manager. Каким оказался результат? Он удалил свои данные! «Этого не может быть», — подумал я. Но когда он рассказал мне о своих действиях, стало ясно, что в коде, создаваемом диалоговым окном Design Table в Enterprise Manager, существует серьезная недокументированная проблема — классический пример плохого приема работы с T-SQL!
В этой статье Дэвид Бреннан проделал замечательную работу по обобщению технических приемов максимизации использования параметров с помощью искусного применения Null, IsNull и CASE.
Одной из главных проблем, с которыми сталкиваются разработчики приложений, является понимание того, как создавать повторно используемый код и обеспечить его эффективность. Популярный прием заключается в создании динамического SQL-оператора, который может принимать в расчет необязательные параметры, динамические параметры, а также параметры с изменяющейся размерностью.
Пол Манкенбек (Paul Munkenbeck)
Полагаю, что подобно Полу Манкенбеку многие из вас экспериментировали с новой возможностью SQL Server 2000 — именованными экземплярами и, возможно, управляли установкой нескольких копий SQL Server на один и тот же компьютер. Это просто, не так ли? Но выполняли ли вы это на работающем сервере и смогли ли приспособить именованные экземпляры к вашим административным процедурам?
Недавно мне потребовалось создать две отдельные среды — инструментальную среду и среду контроля качества, но в моем распоряжении имелся только один сервер. В подобной ситуации казалось очевидным использовать преимущество именованных экземпляров SQL Server 2000, поэтому я раскрыл стандартную документацию по серверу и приступил к работе. На то время я еще не осознавал, сколько моих административных процедур и сценариев потребуется скорректировать, чтобы снабдить их копиями эти экземпляры.
Как работают именованные экземпляры
Что же такое именованный экземпляр? Говоря упрощенно, это отдельная копия ядра БД SQL Server, которая может быть запущена параллельно другим копиям на одном и том же компьютере. С точки зрения клиента, это выглядит так, как если бы это был автономный, независимый сервер.
Том Моро (Tom Moreau)
На этот раз доктор Том Моро выступает с провокационным
названием, не так ли?
Хотя, если серьезно, в каждой его статье содержатся полезные уроки, поэтому
насладитесь ощущением первооткрывателя.
Вы, возможно, уже в курсе, что я не могу обойтись без групп новостей Usenet (а теперь еще и Google, см. http://groups.google.com/googlegroups/deja_announcement.html). И это не только потому, что мне нравится помогать людям (а это мне действительно нравится). Возможно, в большей мере это объясняется моей любовью к разгадыванию головоломок. Например, недавно одна из участниц группы новостей очень хотела поменять местами первичные ключи таким образом, чтобы первый получил значение второго, второй — третьего, а третий — значение первого. Это предполагало обновление нескольких строк из одной и той же таблицы.
Ее попытки оказались неудачными. И хотя она опубликовала свои данные, я решил работать в БД Northwind, поскольку хорошо знаком с ней. Интуиция — вам знакомо это слово? Однажды я встретил авиационного инженера, который рассказал мне об аксиоме проектирования, гласящей: «Если в чем-то сомневаетесь, лучше не используйте». Подобный подход применим и при разработке программного обеспечения. Существуют способы избежать явных транзакций для многострочных обновлений в одной таблице.
Фил МакКормэк (Phil McCormack)
Эта статья стала результатом «затяжного» спора между Филом и некоторыми из его коллег. Надеюсь, он простит нас, если мы представим, что дебаты были достаточно горячими. В своей статье Фил описывает проведенный им простой эксперимент с целью убедить упрямых коллег (в особенности одного) в том, что параллелизм в обработке запросов, несомненно, работает.
Один парень утверждает, что симметричная мультипроцессорная обработка (SMP, Symmetrical Multiprocessing) не работает, другой же заявляет, что работает. Простая ситуация, послужившая для нас отправной точкой (чтобы оторваться от преследования, скажу, что аргумент в пользу того, что симметричная мультипроцессорная обработка действует, на сегодняшний день уже не вызывает сомнений). Все последующее является кратким изложением нашего эксперимента.
Возьмите простой кусочек кода SQL, содержащий конструкцию GROUP BY. Получите общую стои- мость (total cost) этого запроса, а затем меняйте Cost for Query Parallelism так, чтобы ваш сервер или учитывал ее или игнорировал при параллельном выполнении. Используйте Performance Monitor (PerfMon) для мониторинга активности процессора и статистики ввода – вывода.
(Возврат на основную страницу)