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

Содержание номера за Август 2007 год

SQL Server 2008 (Katmai) — новые возможности для ИТ-профессионалов

Не так давно SQL Katmai получил официальное название SQL Server 2008. Вышедшая в июне сборка community technology preview (CTP) — первый публично доступный вариант сервера, объявленный на конференции TechEd 2007. Microsoft публично подтвердила свое намерение выпустить продукт в 2008 году,  но не предоставила никакой дополнительной информации. Можно предположить, что продукт будет выпущен в первой половине 2008 года.

Июньская сборка (SQL Server 2008 June CTP) официально поддерживается на 32­ и 64­разрядных версиях следующих операционных систем: Server 2003 SP1 или SP2, Vista Business, Vista Enterprise и XP SP2. Более подробно о требующейся среде установки можно прочитать здесь: http://connect.microsoft.com/SQLServer/Downloads/DownloadDetails.aspx?DownloadID=6835. Обратите внимание, что SQL Server 2008 в список не входит. Я смог установить CTP на Beta3, но похоже, что не все там работает.

С выходом июньской CTP пользователи получают возможность познакомиться с новой функциональностью, необходимой для работы жизненно важных приложений, и применить глобальные настройки в рамках всей организации. По сути дела, июньский выпуск закладывает основу для использования основанной на политиках системы управления, позволяющей администраторам сократить время, которое тратится на задачи управления. Для разработчиков хранилищ данных предлагается набор расширений платформы Business Intelligence, позволяющих получать актуальные данные посредством технологии Change Data Capture и команды MERGE, кроме того, появилась возможность разработки масштабируемых решений Analysis Services средствами новой среды разработки.

Платформа разработки критически важных приложений

Declarative Management Framework (DMF)

Декларативное управление (Declarative Manage­ment) — новая среда управления, базирующаяся на политиках и предоставляющая следующие возможности:

•     Обеспечение соответствия системной конфигурации разработанным политикам.

•     Предотвращение/отслеживание изменений в системе посредством разработки соответствующих политик.

•     Сокращение расходов на владение (total cost of ownership) за счет упрощения административных процедур.

Глобальное покрытие

Change Data Capture (CDC)

•     Change Data Capture (CDC) — это универсальный компонент, который асинхронно отслеживает изменения в БД и отображает эти изменения через удобный для использования реляционный интерфейс.

•     Посредством этого интерфейса потребители смогут легко отслеживать изменения в зависимости от своих конкретных потребностей и забирать измененные данные, используя T­SQL или иные средства доступа к данным.

Команда MERGE

•     Часто встречающиеся сценарии работы с хранилищами данных предполагают вставку или модификацию информации. С появлением команды MERGE SQL Server 2008 позволяет выполнить вставку или обновление в рамках одной команды:

merge t1 as t1a
using (select * from t2) as t2a (keyfld, charfld)
on
(t1a.keyfld = t2a.keyfld)
when not matched then insert (keyfld, charfld)
   values (keyfld, charfld)
when matched and t1a.keyfld = 3 then delete
when matched
   then update set t1a.charfld = t2a.charfld;

Поддержка VSTA для Script Task и Script Component в рамках SSIS

•     Автоматическая миграция — существующие script­компоненты в SQL Server 2005 будут автоматически использовать новую среду разработки на VSTA, что делает простой миграцию существующих разработок.

•     Поддержка C# — наряду с существующей поддержкой VB.Net включена поддержка разработки SSIS пакетов на C#.

•     Отладка — в новой среде полностью доступны стандартные средства отладки Visual Studio.

Оптимизация соединений в схеме «звезда»

•     Для повышения производительности в рамках стандартных сценариев использования хранилищ данных реализована оптимизация соединений в БД, построенной по схеме «звезда». При этом оптимизатор распознает соединения, характерные для схем хранилища данных.

Дополнительные возможности проектирования измерений хранилищ данных. Расширена поддержка оптимальных приемов «Best Practices»

•     Расширение пользовательского интерфейса создания и редактирования измерений для направления пользователей в сторону соблюдения оптимальных приемов.

•     Эти изменения включают: Finish Attribute Re­la­ti­onship Designer, структуру измерения (представление отношений атрибутов), усовершенствование Мастеров, для приведения их в соответствие с оптимальными приемами, упрощение создания композитных ключей и AMO предупреждения (касающихся всех объектов, не только измерений).

Продуктивность разработчиков

Табличные параметры

•     Во многих случаях в хранимую процедуру или функцию необходимо передать структурированные данные (набор строк). Эти данные могут использоваться для прямого заполнения или модификации таблицы или для более сложных манипуляций. Табличные параметры позволяют упростить передачу такого рода параметров через строго типизированные табличные переменные:

-- USE AdventureWorks;
-- GO

/* Create a table type. */
CREATE TYPE LocationTableType AS TABLE
( LocationName VARCHAR(50)
, CostRate INT );
GO

/* Create a procedure to receive data
   for the table-valued parameter. */
create PROCEDURE usp_InsertProductionLocation1
    @TVP LocationTableType READONLY
    AS
    SET NOCOUNT ON
        SELECT *, 0, GETDATE()

        FROM  @TVP;
        GO

/* Declare a variable that references the type. */
DECLARE @LocationTVP
AS LocationTableType;

/* Add data to the table variable. */
INSERT INTO @LocationTVP (LocationName, CostRate)
    SELECT [Name], 0.00
    FROM
    [AdventureWorks].[Person].[StateProvince];

/* Pass the table variable data
   to a stored procedure. */
EXEC usp_InsertProductionLocation1 @LocationTVP;
GO

Июньская сборка построена на надежном основании, заложенном еще SQL Server 2005, и является продолжением усилий разработчиков в таких направлениях, как управляемость и репликация. Для получения полного списка новых возможностей мы отправляем вас к документу «Microsoft SQL Server 2008 Product Overview», который можно получить на сайте Microsoft (www.microsoft.com/sql/techinfo/whitepapers/sql2008Overview.mspx).

Примеры БД для SQL Server 2008 можно скачать отсюда — http://www.codeplex.com/MSFTDB­Prod­Samples/Release/ProjectReleases.aspx?ReleaseId=4605.

Выявляем виновника: серверные курсоры API

В этой статье автор рассказывает о серверных курсорах API (API Server Cursor): что это такое и как определить, что распределенный запрос использует такой курсор, а также приводит пример простого распределенного запроса, не использующего серверный курсор API.

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

Что такое серверный курсор API

OLE DB провайдер для SQL Server (SQLOLEDB) использует два метода получения результатов распределенного запроса от удаленного сервера. Результирующий набор по умолчанию получает от удаленного сервера результаты запроса в рамках одного пакета. Другой метод использует для этого особый вид курсора — серверный курсор API.

Как SQLOLEDB использует серверные курсоры API

Для управления серверными курсорами API SQL­OLEDB применяет системные хранимые процедуры SQL Server. Дополнительную информацию по управлению серверными курсорами вы можете найти в разделе «API Server Cursors (http://msdn2.microsoft.com/en­gb/library/aa172588(SQL.80).aspx)» в SQL Ser­ver 2000/2005 Books Online.

Как с помощью SQL Server Profiler выявить применение серверных курсоров API

SQL Server Profiler перехватывает события, происходящие на SQL Server. В разделе «Detailed Analysis Process» в седьмой главе (Chapter 7 http://www.microsoft.com/technet/prodtechnol/sql/2000/mainta­in/sqlops7.mspx) SQL Server 2000 Operations Guide вы найдете подробные инструкции по трассировке и анализу полученных результатов. Как я упоминал ранее, управление серверным курсором API осуществляется с помощью системных хранимых процедур, поэтому ситуацию, когда вместо результирующего набора по умолчанию подключение использует серверный курсор API, выявить довольно легко. Перед началом работы с SQL Server Profiler убедитесь, что он подключен к удаленному (связанному) серверу, на который ссылается распределенный запрос. В противном случае вы не сможете отслеживать происходящие на удаленном сервере операции. В моем сеансе трассировки я использовал следующие события (с их помощью я получил результаты, на которые буду ссылаться ниже):

•     Stored Procedures — SP:Completed;

•     Stored Procedures — SP:StmtCompleted;

•     Stored Procedures — RPC:Completed;

•     T­SQL — SQL:StmtCompleted.

Событие Stored Procedures — RPC:Completed отлавливает системные хранимые процедуры для управления серверным курсором API.

Недостающее звено LINQ

Реализованный в СУБД Visual FoxPro (VFP) язык управления данными Data Manipulation Language (DML) — это одна из самых неотразимых особенностей VFP. Это также та функция, которой наиболее очевидно не хватает VFP-разработчикам в языках программирования платформы .NET, таких как C# и Visual Basic. Впрочем, Language Integrated Query (LINQ) — вот новый язык запросов, предназначенный для .NET-разработчиков, и та новая возможность, которая появится в будущих релизах C# 3.0 и Visual Basic 9.0  и восполнит нехватку.

Возможности ядра языка LINQ покажутся очень знакомыми разработчикам, использующим Visual FoxPro. Язык LINQ позволяет исполнять SELECT­предложения как элемент основных языков платформы .NET, C# и Visual Basic. Каждый, кто знаком с командами запросов, используемыми в Visual FoxPro, или с SELECT­синтаксисом языка T­SQL, обнаружит привычные коман­ды и возможности. Однако целью создания языка LINQ не является точное воспроизведение функций СУБД VFP/SQL Server. Напротив, язык LINQ обеспечивает множество уникальных возможностей, которые значительно превышают возможности простых запросов данных. Следовательно, знание других языков запросов выигрышно для тех разработчиков, которые хотят воспользоваться преимуществом языка LINQ, но в то же время я рекомендую не сосредотачиваться исключительно на проблеме того, являются ли какие­то вещи в точности идентичными стандартному SELECT­синтаксису. Язык LINQ — это самостоятельный язык со своими возможностями и в определенной степени иным синтаксисом.

Обзор функциональных возможностей

Так что же именно делает язык LINQ? Позвольте мне сформулировать это таким образом: когда, уже довольно давно, я впервые свел близкое знакомство с языком LINQ, Андерс Хейлсберг (Anders Hejlsberg) («отец» языка C#) поведал мне, что задача заключалась в создании таких возможностей, которые позволяли бы формировать и исполнять запросы внутри языков C# и Visual Basic и которые могли бы «обращаться с запросами ко всему, что имеет структуру». А что это такое — то, что «имеет структуру»?

Ну что ж, оказывается, в языках C# и Visual Basic таких вещей совсем немало. Прежде всего, разумеется, данные. Это означает, что вы можете использовать язык LINQ для того, чтобы обращаться с запросами к источникам данных, таким, например, как наборы данных DataSet модели ADO.NET или таблицы и представления сервера SQL Server. Но язык LINQ может запрашивать гораздо больше этого. XML­код также «имеет структуру». Язык LINQ позволяет обращаться с запросами к любым XML­источникам данных, включая XML­файл или XML­строку, хранящуюся в оперативной памяти. Объекты также обладают структурой. И разумеется, среда .NET — это сплошные объекты. По сути дела, оказывается, что LINQ является механизмом, который обращается с запросами преимущественно к объектам, а возможности, которые используются для обращения с запросами к «другим» вещам, таким как данные или XML­код, — это надстройка над этим механизмом запросов объектов.

Quaere Verum — сканирование кластерных индексов. Часть 1

Случалось с вами когда-нибудь такое: вы настолько были в чем-то уверены, что даже и не думали проверять, а правда ли это. Все казалось столь очевидным, и вдруг вы понимаете, что ошибались? Так вот,  со мной недавно был такой случай…

Прежде чем я раскрою подробности, мне хотелось бы выразить свою глубочайшую признательность Любору Коллару (Lubor Kollar) и Шрикумару Рангарайану (Srikumar Rangarajan), которые помогли мне докопаться до самой сути и разъяснили функциональное поведение, которое я не смог бы объяснить самостоятельно. Кроме того, Любор дал мне отличную консультацию и совет!

Протестировано для версий сервера SQL Server: 2000 Dev/SP4, 2005 Dev/SP1

Я начну с того, что задам вам простой, как кажется, вопрос. Дана таблица T1 с кластерным индексом по столбцу col1; гарантируется ли, что следующий запрос вернет данные, упорядоченные в соответствии с порядком кластерного индекса?

SELECT * FROM T1;

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

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

Мне хотелось бы заострить внимание на том, как этот вопрос рассматривается с точки зрения стандарта ANSI SQL. Участие стандарта в его решении ограничивается следующим: такой запрос возвращает множество, и поскольку множество не предусматривает упорядочивания его записей, то результат считается допустимым независимо от того порядка, в котором возвращаются записи. Если вы хотите обеспечить гарантированное возвращение упорядоченного результата, вы должны указать опцию ORDER BY. Для сервера SQL Server из сказанного вытекают следующие следствия: он может применять те методы неупорядоченного или упорядоченного доступа, которые сочтет подходящими.

Руководства планов (Plan guide) в SQL Server 2005

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

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

В SQL Server 2005 есть новая функция — руковод­ство планов (Plan Guides), которая может помочь в некоторых случаях, когда вы не контролируете запрос с плохой производительностью. В сущности, руководство плана позволяет на лету добавлять или изменять подсказки в запросах (query hints) прямо перед запуском запроса.

Вот как это работает:

•     Когда приложение посылает SQL Server код, оптимизатор запросов сначала проверяет этот код, чтобы определить, не содержится ли в кеше готовый план для этого запроса. Если это так, то при выполнении запроса будет использоваться текущий план выполнения из кеша.

•     Если совпадений не найдено, код ищется в специальной внутренней таблице, чтобы определить, существует ли для него руководство плана.

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

•     План запроса компилируется и помещается в кеш.

•     Запрос выполняется с подсказками, указанными в руководстве плана. Предполагается, что теперь запрос должен выполняться гораздо быстрее.

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

Руководства планов можно применять к запросам в трех различных ситуациях:

•     Руководство плана для объектов (Object Plan Guide). Используется для запросов, выполняющихся в контексте хранимых процедур, скалярных функций, табличных функций с множественными выражениями и триггеров DML. Идентифицирует объекты по имени.

•     Руководство плана для SQL­кода (SQL Plan Guide). Используется для запросов, выполняющихся в контексте одиночных выражений Transact­SQL и пакетов. Запрос определяется на основе совпадения кода.

•     Руководство плана для шаблонов (Template Plan Guide). Используется для запросов, которые следуют определенной форме параметризации. Этот вариант затрагивает целый класс запросов. Если указан параметр TEMPLATE, то можно использовать только подсказку PARAMETERIZATION {FORCED | SIMPLE}, поэтому функции этого типа руководств очень ограничены.

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

•     {HASH | ORDER} GROUP;

•     {CONCAT | HASH | MERGE} UNION;

•     {LOOP | MERGE | HASH} JOIN;

•     FAST number_rows;

•     FORCE ORDER;

•     MAXDOP number_of_processors;

•     OPTIMIZE FOR ( @variable_name = literal_constant ) [ ,…n ];

•     RECOMPILE;

•     ROBUST PLAN;

•     KEEP PLAN;

•     KEEPFIXED PLAN;

•     EXPAND VIEWS;

•     MAXRECURSION number;

•     USE PLAN <xmlplan>.

Для создания руководств планов и управления ими применяют две хранимые процедуры:

•     sp_create_plan_guide;

•     sp_control_plan_guide.

Давайте кратко рассмотрим каждую из них.

Знакомьтесь — Боб Дорр!

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

Вас приветствует «Spotlight Behind SQL Server» — новая серия публикаций портала SQLServerCentral.com. Пока мы «росли» и все больше времени уделяли серверу SQL Server, мы потихоньку установили ряд контактов внутри фирмы Microsoft, включая тех ее сотрудников, которые занимаются разработкой этого продукта. И решили попытаться взять интервью у Microsoft’овцев, имеющих отношение к серверу SQL Server. Над версией SQL Server 2005 работает множество людей, и наша задача — побеседовать в конечном итоге со всеми.

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

Недавно нам удалось перехватить Боба Дорра (Bob Dorr) после конференции PASS, где он вел очень интересную секцию, посвященную внутреннему устройству механизма базы данных сервера SQL Server.

 SSC (SQL Server Central): Каков Ваш официальный титул и за что Вы отвечаете в фирме Microsoft?

Боб: Senior SQL Server Escalation Engineer (старший инженер службы поддержки SQL Server).

SSC: По Вашим наблюдениям — какой компонент версии SQL Server 2005 вызывает наибольшее число обращений в службу поддержки?

Боб: До появления версии SQL Server 2005 в общем объеме обращений в службу поддержки продукта (Product Support Services, PSS) доминировал механизм баз данных. В предыдущих релизах мы часто обнаруживали одну или две ошибки, которые быстро оказывались в центре внимания и преобладали в общем объеме обращений до тех пор, пока их не исправляли. В случае версии SQL Server 2005 мы этого не наблюдаем. Версия SQL Server 2005 является исключительно качественным продуктом, и обращения по поводу механизма баз данных разбросаны по нескольким направлениям продукта.

Если вы рассматриваете объем обращений в сравнении с объемом продаж, он не вызывает удивления, поскольку объем обращений следует стандартной отраслевой кривой. Мы сделали большой шаг вперед с точки зрения набора интеллектуальных средств анализа данных (BI stack) (службы SSIS, поддержка OLAP, службы Report Services), и наряду с ростом объема продаж этих систем значительно вырос объем обращений по поводу их работы и использования.

Мы предприняли строго регламентированный подход к решению проблем, связанных с версией SQL Server 2005. Наряду с этим служба поддержки PSS и команды разработчиков проанализировали отчеты утилиты Dr Watson и информацию о кодах обращений. Каждый случай обращения в службу поддержки получает код, соответствующий признаку неисправности, и устанавливается соответствие между этими признаками неисправности и областями применения продукта. Для каждой основной области применения продукта (мы называем ее «pipeline» — «канал») назначается Program manager, менеджер по сопровождению и инженер по сопровождению: мы называем такое организационное образование «красная зона» (Red Zone). Каждый месяц сотрудники службы PSS и подразделения разработки, курирующие данный «канал», встречаются и выявляют те доработки, в которых нуждается продукт, потребности в документации, устанавливают необходимость внесения DCR­изменений (Design Change Request, запрос на изменение дизайна) в файлы, идентифицируют ошибки, а также предпринимают другие необходимые действия. Раз в квартал каждый «канал» отчитывается перед руководством высшего звена службы поддержки PSS и подразделения разработки и предоставляет графики решения неотложных проблем.

 SSC: Есть ли такое обстоятельство, учет которого всеми DBA-администраторами позволит сократить количество обращений в службу поддержки?

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

Я думаю, наш текущий объем критичных обращений по поводу SQL Server составляет 80 в месяц. Из них добрых 40% или более того относятся к вещам типа «кто­то повредил таблицу, и мне необходимо вернуть данные» или «у меня произошел сбой диска, и мне необходимо вернуть данные». Как правило, это такие проблемы, которые создают себе сами пользователи и которые только усугубляются при отсут­ствии резервной копии.

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

 SSC: На какой стадии служба PSS включается в процесс разработки SQL Server?

Боб: Этот процесс формировался на протяжении ряда лет. Когда я в 1994 году начал работать в фирме Microsoft, SQL­команда была весьма немногочисленной и едва завершила формальный переход из фирмы Sybase. В те дни внимание уделялось не столько новым возможностям продукта, сколько тому, чтобы добиться хорошей работы того, что у нас уже имелось. Однако с каждым следующим продуктом подключение службы PSS к процессу разработки происходило чаще и на более ранних стадиях. Сегодня мы оба, Боб Ворд (Bob Ward) и я, занимаемся главным образом тем, что работаем с командой разработки над теми обратными откликами, которые были получены для текущих и новых продуктов. Кроме того, остальная часть команды поддержки также участвует в этом процессе по своим специализированным направлениям. Мы несколько раз в год бываем в Сиэтле, общаемся с разными разработчиками, изучаем проекты, ставим вопросы и решаем их. Для версии SQL Server 2005 вся команда поддержки, работающая в США, так же как и многие специалисты по поддержке из подразделений, работающих в других странах, прошла обучение на двухнедельных курсах. Многие из нас за несколько лет прошли обучение на нескольких курсах.

Мы, как ни удивительно, проверяем и комментируем различные спецификации и имеем решающий голос в отношении этих документов. Например, мы успешно представили для процесса разработки спецификацию, определяющую возможность обеспечить поддержку продукта (supportability specification). Эта спецификация охватывает все вопросы: от текста сообщений об ошибках до возможностей трассировки. Служба PSS является главным инициатором подписания этого документа, гарантирующего, что заказчик и служба PSS смогут обеспечить поддержку данного продукта.

Некоторые более конкретные примеры, с которыми вы, возможно, знакомы, — это ошибка 17883, контрольные суммы и предупреждения о блокировках операций ввода­вывода (stalled I/O warnings). Каждый из этих случаев насчитывает огромное количество «сигналов», полученных службой PSS, и огромное количество совещаний с командой разработки. Команда разработки оказывает нам действенную помощь при анализе и разрешении периодически возникающих проблем. Заказчики сталкивались с блокировками и повреждениями, причину которых служба PSS постоянно находила в областях, выходящих за рамки SQL Server. Фирма Microsoft изучила закономерности и провела работу с командой разработки с тем, чтобы представить такие решения, которые могли бы быстро указать истинную причину проблем такого рода. Было столько замен, что решение проблем, связанных с ошибкой 17883 и предупреждением о блокировке ввода­вывода, не стали откладывать до выхода версии SQL Server 2005, а включили как дополнение в сервисный пакет для версии SQL Server 2000.

 SSC: Служба PSS оказывает содействие в определении приоритетов при решении вопроса о том, какие ошибки получат исправления в сервисных пакетах и/или в «заплатках» Hotfixes?

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

Около двух лет назад отвечающая за SQL Server CSS­команда (Customer Service & Support, служба поддержки и обслуживания заказчиков) наняла нам в помощь инженера­статистика. После того как каждый случай обращения получает свое решение, мы присваиваем этому обращению код в соответствии с областью применения/признаком неисправности продукта. Статистик провел всесторонний анализ этих данных и предоставил ключевые параметры, такие как количество проблем, выраженное в днях, усредненное время их решения, усредненные трудозатраты на решение этих проблем, расходы фирмы Microsoft и т. д. У этой службы есть, кроме того, способ, позволяющий ассоциировать признаки неисправности с индексом убытков заказчика (customer pain index). Все эти данные объединяются с QFE­данными (quick fix engineering — безотлагательные дополнения, исправляющие ошибки) для соответствующих областей применения продукта, а также с отчетами утилиты Dr Watson с тем, чтобы можно было составить основной список.

Затем «белый ящик» сервера SQL Server разбивается на «каналы». Например, службы SSIS, поддержка OLAP, Механизм баз данных, Производительность. Каждый «канал» собирается несколько раз в месяц для обсуждения статистических тенденций, QFE­запросов и оставшихся открытыми случаев, которые трудны для разрешения. На основе этих данных создается приоритетный список проблем и определяется, что именно подлежит исправлению.

Этот список представляется на совместном ежеквартальном деловом совещании CSS­команды и подразделения разработки SQL Development. В этом совещании участвует руководитель службы поддержки SQL, главные управляющие службы поддержки SQL, Боб Ворд и я сам. В нем также участвует вице­президент по разработке SQL, руководители групп разработки и лица, ответственные за «канал» со стороны разработчиков. Это совещание носит название «RedZone» («красная зона»). Такого типа формат используется для всех наших основных продуктов. Каждая группа сообщает о том, что они собираются исправлять, а также представляет те показатели, которых они собираются достигнуть, например сокращение объема обращений, сокращение расходов на поддержку и прочее, и отчитывается о том, что было сделано в течение квартала.

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

Такой подход позволяет нам действовать разумно с точки зрения бизнеса, но избежать просчетов, связанных с учетом одних только статистических показателей и игнорированием того, что мы определяем как исправления по принципу «да что там долго думать».

 SSC: Какова численность команды поддержки SQL Server в Техасе?

Боб: Вся служба поддержки в Техасе занимает два четырехэтажных здания. Это собственно служба поддержки, лаборатории и подразделение, занимающееся продажами. С точки зрения численности сотрудников подразделение, занимающееся SQL Server в штате Техас, начиная примерно с 1998 года, является самым крупным в США, но подразделение, находящееся в Шарлотте в штате Северная Каролина, обычно идет с нами бок о бок. Та часть подразделения, которая занимается собственно поддержкой SQL Server, насчитывает около 40 человек и примерно половина из них — это штат, отвечающий за эскалацию проблем. Без сомнения, в Техасе мы располагаем самой большой командой эскалации в мире.

 SSC: Как давно Вы работаете с SQL Server?

Боб: Я начал работать с SQL Server на платформе OS/2 в фирме State Farm в начале 1990­х. Я входил в команду, которая занималась разработкой системы Catastrophe System (CAT) фирмы State Farm. Это было одно из первых подразделений фирмы State Farm, которое работало на ПК. Проект системы CAT предусматривал использование сервера OS/2, на котором функционирует СУБД SQL Server, и клиентов, работающих под управлением Windows for Workgroup. Эта система была написана на языках программирования C/C++ с использованием DOS, библиотеки Panel screen library. Все комплектовалось на паллетах на складе (бумага, столы, персональные компьютеры, принтеры, модемы, системы резервного копирования на магнитную ленту.) Если бы где­нибудь пронесся ураган, туда была бы отправлена эта система. Фирма State Farm могла бы задействовать гараж, несколько комнат в гостинице или даже трейлер. Система устанавливалась монтажниками, которых посылали для организации узла.

У нас было только восемь разработчиков на всю систему, поэтому мы работали на всех направлениях. Я писал ассемблерный код для управления лентопротяжным устройством и пакетной загрузки необходимых данных. Мы занимались программированием задач географической привязки с помощью продукта Map View, который должен был быть связан с системой. Настройка запросов, обработка резервных копий, сервис удаленного доступа (RAS) к региональным мейнфреймам, и мне даже пришлось изучить команды принтера HP PCL, чтобы обеспечить операции по подготовке счетов и автоматических писем. В кратчайшие сроки я очень хорошо познакомился со многими техноло­
гиями.

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

Однако моей страстью оставались SQL Server и клиент­серверное программирование. Что в итоге привело меня в октябре 1994 года в службу поддержки SQL Server в фирму Microsoft. В 1996 году я «дорос» до ведущего инженера (technical lead), а в 1998 году присоединился к команде эскалации. С тех пор я увлечен решением трудных проблем и улучшением продукта для заказчиков.

 SSC: Расскажите нам немного о своем прош­лом, как вы начали заниматься компьютерами?

Боб: Я всегда был в восторге от компьютеров и чисел. Пока я рос, мои родители владели агентством по продаже сельскохозяйственных машин. Когда я был в шестом классе, они приобрели Commodore (по­моему, модель 8510, но это было давно). Помню, у него была система сдвоенных дисководов для гибких дисков 5 1/4 — последнее слово техники того времени. У моих родителей была книга по программированию и возможность использовать язык программирования basic, и я в тот же вечер напечатал свое имя (повторяющиеся буквы в стиле баннера складывались в слово «B O B» высотой 11 дюймов) на старом 9­игольчатом принтере. Я создавал собственные игры и помогал родителям в работе со складскими программами и с программой VisiCalc.

Когда я поступил в среднюю школу, то «дорос» до собственного компьютера. Это был Mac с 8­ или 9­дюймовым черно­белым экраном, «все­в­одном». Я познакомился с компиляторами для языков программирования Lightspeed Pascal и C — и как с цепи сорвался. Прошел через ряд модификаций и в итоге получил цветной экран; чего я только на нем ни делал… Правда, мой учитель английского языка в средней школе как­то сказал мне, что у меня под рукой всегда должна быть программа проверки правописания; она бы мне пригодилась.

Я учился в колледже Midland Lutheran College во Фремонте, штат Небраска. Как ни странно, начал я с того, что занялся бухгалтерским учетом предприятий. Я стал посещать некоторые занятия, которые были связаны с компьютерами: СУБД DB2, язык программирования Cobol, и в итоге обнаружил, что изучаю ассемблер. Я работал в местном продуктовом магазине (фирмы Hy­Vee) начальником ночной смены. Как только они узнали, что я что­то понимаю в компьютерах, я начал обновлять данные о ценах, создавать резервные копии и исполнять отчеты. Потихоньку я улизнул от бухгалтерии, и она утратила свое значение в моей жизни, а главным для меня стали компьютеры.

Приступив к обучению в колледже, я начал удаленно работать на фирму, которая располагалась в Плано, штат Техас, и занималась разработкой клиент­серверной системы для торговцев машинами. Так случилось, что мои родители перешли на использование этой системы. Я отвечал за сопроводительную документацию. Мне пришлось провести реинжиниринг большого объема C­кода и подготовить различные сопроводительные руководства. Эта система работала только на ПК, поэтому я быстро изучил эмуляторы, файловые и двоичные форматы, взаимодей­ствие Mac с PC и другие подобные во­просы.

Закончив в 1991 году колледж, я оказался в подразделении, которое занималось разработкой, в фирме State Farm. Сначала я попал в отдел модульного тестирования и отвечал за всевозможные технологии, обеспечивающие установку и выпуск продукта. В то время фирма State Farm использовала систему HP All­Base, работавшую на мейнфреймах в региональных вычислительных центрах. Я должен был программировать и сопровождать массу разнообразных процедур, позволяющих разработчикам надлежащим образом выполнять тестирование. Программировал на языках Cobol, Pascal и C, в зависимости от требований проекта. Работая с этой командой, я изучил средства и каркасы тестирования. Разработал инструментальное средство покрытия кода, которое должно было автоматически формировать тестовые планы. Я написал утилиту JetForms для преобразования PCL­кода для Mac в PCL­код для PC, которая использовалась для автоматического составления стандартных писем. Программировал подпрограммы сжатия и многое другое.

Работая в команде тестирования, я также занимался разработкой для Mac и PC дома, используя СУБД FoxPro. Со своим другом Дугом Райтом (Doug Wright) я создавал приложение для фирмы, занимавшейся обустройством жилья, которое должно было объединять их каталоги материалов и данные продаж. Как теперь представляется, есть определенная ирония в том, что когда я присоединился к фирме Microsoft, многие из старейших инженеров службы поддержки SQL Server, как оказалось, пришли туда из команды, занимавшейся FoxPro. Большая часть этих ребят сейчас по­прежнему числится в штате службы поддержки SQL Server.

Пока создавалось это FoxPro­приложение, я выяснил, что меня не устраивает производительность, и самостоятельно научился использовать потоки на Mac. По сути дела я написал элементарный многопоточный механизм баз данных, используя версию языка программирования Lightspeed C для Mac, который в конечном итоге внедрил. Взглянув сегодня на свою старую методику распределения по потокам, я, вероятно, пришел бы в ужас. Я столько узнал в фирме Microsoft о синхронизации потоков, барьерах памяти, взаимных блокировках, ошибках шины и о многом другом.

В 1992 году я перешел в CAT­команду и начал приключение с SQL Server, узнавая все, что только можно о SQL Server и, в конечном итоге, о новой платформе NT. В 1994 году фирма State Farm сделала выбор не в пользу NT­решения, поэтому вместе с тремя другими членами CAT­команды я присоединился к находящемуся в штате Техас подразделению службы поддержки фирмы Microsoft; и с тех пор я здесь. Это замечательно, что у меня есть возможность помогать заказчикам, но я стремлюсь к тому, чтобы применять свои знания. По­прежнему программирую утилиты, например ReadTrace, OStress, SQLIOStress, SQLIOSim и другие, которые повышают эффективность работы нашей команды.

 SSC: С кем лучше всего работается в фирме Microsoft?

Боб: Есть два инженера, с которыми я провожу каждый день и без которых мне не обойтись. Мы все здесь уже по 11 и более лет, и мы очень хорошо сработались. Они стали моей семьей. Что касается команды разработчиков, я по­прежнему отчасти неравнодушен к той ее части, которая занимается механизмом баз данных, но замечателен весь SQL­коллектив. Впрочем, в группе, занимающейся механизмом баз данных, много сотрудников, ранее работавших в службе поддержки SQL Server, а также ветеранов. Есть компания разработчиков ядра механизма баз данных, которые занимаются этим продуктом так же или почти так же давно, как и я. Я хорошо их знаю, нам легко общаться друг с другом, и мы одинаково мыслим. Очень приятно работать со знакомыми ребятами, которые, так же как и я, стремятся сделать хорошую вещь.

 SSC: Мы все слышали истории о тех или иных личностях из фирмы Microsoft. Вы можете рассказать о чем-нибудь, что Вас поразило или удивило, когда Вы впервые приступили к работе в Редмонде?

Боб: Самое замечательное в фирме Microsoft — это то, что каждый стремится быть самим собой. Когда я работал в фирме State Farm, мы должны были носить костюм и галстук. Я вырос в Айове, в фермерском городке, где в выпускном классе средней школы было 12 учеников. Я всегда был настроен на строгий подход к делу. Когда я появился в Microsoft, там считалось, что если вы в костюме и при галстуке, то вы пришли на собеседование. Ребята в шортах с прической «конский хвост», бесплатная газировка за счет Microsoft, все это изрядно ошеломляло.

Я думаю лучшая история — это мой первый рабочий день в октябре 1994 года. Я явился, и был препровожден на мое рабочее место. Получил какие­то инструкции по поводу того, как настроить свои персональные компьютеры (несколько, на всех других работах я имел только один компьютер, а сейчас у меня их пять штук на рабочем столе). Через час или около того мой менеджер вручил мне бесплатную футболку. (Знать бы мне тогда, что бесплатные футболки будут регулярно появляться пару раз в год и мне больше никогда не придется покупать их для работы). После чего сказал мне, что команда собирается пойти пообедать и поиграть в боулинг, а затем — на внеочередное совещание. Просто так совпало, что поводом для этого внеочередного совещания был визит СтиваБ (SteveB — Стив Баллмер). В первый рабочий день я обзавелся новым рабочим столом с персональными компьютерами, бесплатно пообедал, поиграл в боулинг и меня взяли на совещание со Стивом Баллмером. Я понимал, что этот день можно было считать не показательным в смысле нагрузки, но начало было отличное.

 SSC: Чем любит заниматься Боб, когда не работает с SQL Server?

Боб: Я люблю быть с семьей, поскольку я существо домашнее. У меня есть рыболовное судно, и я пользуюсь им при каждой возможности. Дети и собака любят проводить время на воде, поэтому мы с женой часто пакуем прохладительное и тент и отправляемся в выходные куда­нибудь на озеро.

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