(Возврат на основную страницу)
Editorial
Microsoft детализирует будущее Windows Server
Мэри Джо Фолей (Mary Jo Foley)
На конференции WinHEC компания Microsoft превозносила потенциал готовящихся к выходу 64-битных продуктов Windows Server. А разработчики восполнили те пробелы, о которых Microsoft не захотела говорить.
Если вам хочется узнать о перспективах 64-битных настольных систем, познакомьтесь сначала с планами компании Microsoft относительно 64-битных серверов.
В заключительный день конференции Windows Hardware Engineering Conference (WinHEC) компания поделилась своей стратегией по развитию платформы Windows Server.
Несмотря на то, что официальные лица компании не раскрывают каких-либо подробностей по поводу Windows Server 2003 Update (промежуточного выпуска Windows Server под кодовым названием R2, ожидаемого в следующем году), они рассказали о том, что в настоящее время Microsoft реализует проектные решения по аппаратному обеспечению, намеченные для Longhorn Server, выход которого намечен на 2006-2007 гг., через несколько месяцев после Longhorn-клиента.
«До 2005 года мы ожидаем, что практически все серверы станут обладать 64-битными возможностями», — отметил в своем выступлении Джим Ливингстон (Jim Livingston), главный менеджер программы из команды разработчиков Windows Server компании Microsoft.
Ливингстон сообщил, что Microsoft отслеживает три тенденции, влияющие на разработку ее серверных продуктов. Он сказал, что компания рассматривает 64 бита как массовую серверную платформу для всего — от простых машин до мощнейших серверов, и отметил, что Microsoft ожидает экспоненциального роста числа сокетов (socket) или процессоров, поддерживаемых всеми категориями серверов, а также числа ядер (core) или потоков, поддерживаемых каждым процессором. Ливингстон предположил, что в недалеком будущем секционирование (partitioning) распространится на все семейства серверов.
Microsoft предсказывает, что предметом массового спроса для серверных платформ начального и среднего уровня в этот временной интервал будут четырех-сокетные серверы, поддерживающие 16 и более потоков. Microsoft определяет в качестве верхней границы среднего уровня серверов в период 2006-2007 гг. компьютеры с восемью сокетами и 32 и более потоками.
Ливингстон сообщил посетителям WinHEC, что по мнению Microsoft, 1000-сокетные компьютеры появятся в обозримом будущем относительно времени выхода Longhorn.
Что Редмонд спрятал в рукаве?
Итак, что Редмонд спрятал в рукаве, чтобы реализовать преимущества всей вычислительной мощи? Прежде всего, по словам Ливингстона, это продукт 2005 года — Microsoft Virtual Server (MVS), появление которого запланировано на июнь текущего года. MVS 2005 базируется на технологии виртуального сервера Connectix, приобретенного компанией Microsoft в прошлом году.
MVS 2005 предусматривает поддержку до 64 виртуальных машин, запущенных на единственном сервере. Ливингстон повторил: Microsoft ожидает, что ее заказчики, несомненно, будут использовать MVS для помощи в переходе на новые операционные системы и приложения. Со временем, когда Microsoft добавит в MVS поддержку X64, он также будет позволять пользователям выполнять 32-битные приложения на 64-битных компьютерах.
Ливингстон отметил, что внутренне Microsoft запускает Longhorn-клиент и Longhorn-сервер в среде MVS.
Следующим будет Windows Server 2003 Service Pack 1 (SP1), которая должен появиться в конце этого года.
SP1 будет включать поддержку многих функций безопасности, которые также войдут в Windows XP Service Pack 2 – например, такие как блокировка (lock down) RPC (remote-procedure-call) и DCOM (Distributed Component Object Model). Он также послужит основанием для выпуска 64-битных расширений (Extension) компании Microsoft, которые планируется выпустить одновременно с SP1.
SP1 добавит к Windows Server 2003 Standard Edition поддержку IA 64 и процессоров X64. В Windows Server 2003 Enterprise Edition SP1 добавит поддержку 32 Гб оперативной памяти для 32-битных систем и 1024 Гб для 64-битных систем (а также поддержку систем Х64). В Windows Server 2003 Datacenter Edition он добавит поддержку 1024 Гб оперативной памяти для 64-битных систем, а также как поддержку систем Х64.
«Среда универсальных вычислительных машин (Mainframe) не становится лучше. В конечном счете мы захватим ее и заменим ее», — предсказал Ливингстон.
Но что с готовым к употреблению R2?
Ливингстон старательно избегал любых упоминаний промежуточного выпуска Windows Server 2003 — R2, ожидаемого в следующем году.
Другие официальные представители Microsoft публично заявляли, что R2 включит исправление ошибок, внесенных Microsoft в Windows Server 2003 с момента выхода этого продукта в апреле прошлого года. Они также сказали, что он будет включать некоторые из 12—15 «функциональных пакетов» (feature pack) для Windows Server, выпущенные компанией в прошлом году. Эти функциональные пакеты включают такие вещи, как Group Policy Management Console, Active Directory Application Mode и SharePoint Services. Представители компании умолчали, какие еще изменения ожидаются в R2.
Но разработчики, претендующие на осведомленность в сетевом графике Microsoft, говорили, что R2 будет содержать усовершенствованные технологии безопасности с помощью изолирования сети (network-quarantine), упоминавшиеся Microsoft в прошлом как часть сетевого графика по безопасности компании.
Элементарные возможности изолирования сети уже встроены в Windows Server 2003. Но изолирование сети в R2, по словам разработчиков, продвинулось на шаг вперед, обеспечивая проверку «здоровья» всех клиентских компьютеров с помощью запуска антивирусов и других сценарных проверок на системах до того, как им разрешается подключиться к корпоративной сети через частную виртуальную сеть или DHCP. Если клиент подвергается изоляции, то он получает доступ к заплатам и другим модификациям/службам для возвращения ему допустимого состояния здоровья.
Разработчики сообщили, что, вероятно, R2 также будет включать технологию служб терминалов следующего поколения под кодовым названием Bear Paw (медвежья лапа), над которой Microsoft уже работает.
Согласно источникам Microsoft Watch, Microsoft рассматривает Bear Paw в качестве продукта для предприятий среднего уровня, который позволит новым пользователям приобретать опыт, такой как публикация приложений и инициализация, бесшовный доступ к приложениям, портальный стиль доступа к приложениям и другие сценарии без создания VPN. Среди других запланированных функций Bear Paw будет удаленная публикация приложений; добавления к terminal server portal и terminal server proxy; а также сквозная (pass-through) аутентификация.
Источники среди разработчиков добавляют, что одним из ключевых сценариев Microsoft, основанных на использовании Bear Paw, возможно, является особое внимание к развертыванию и управлению серверов-ветвей (branch-server). Они утверждают, что Microsoft разрабатывает нечто, называемое branch management framework (каркас управления ветвями). По словам источников, через эту структуру (ветвь/центр) компании будут способны обеспечивать своих пользователей централизованным конфигурированием, мониторингом и выявлением неисправностей приложений.
DB Design & Warehousing
Работаем с гигантами
Том Моро (Tom Moreau)
В идеальном случае данные являются равномерно распределенными, но реальность, как правило, навязывает свои условия. В данной статье доктор Том Моро обсуждает асимметричные данные и то, как эффективно работать с ними для оптимизации производительности.
В последней своей командировке я столкнулся с ситуацией, когда более 30 процентов данных принадлежали одному владельцу и даже не были загружены. Как вы понимаете, это разновидность асимметрии, которая могла повлиять на план исполнения запроса и поведение блокировок, поэтому было важным привести в порядок физическую модель данных.
Существовало два подхода, к которым я мог прибегнуть. Либо сосредоточиться на настройке индексирования для единственной таблицы, либо использовать горизонтальное секционирование, помещая огромную массу данных в одну таблицу, а остаток в другую, уделяя серьезное внимание индексированию. В данной статье мы рассмотрим каждый из этих подходов, начиная со сценария, использующего единственную таблицу.
Чтобы проиллюстрировать эффект от подобной асимметрии данных, я создал таблицу Customers. Я сгенерировал асимметричные данные, основываясь на двухзначных кодах штатов, с 40-процентным преимуществом в количестве данных для штата Калифорния (California) и давая каждому из оставшихся штатов меньшее количество в диапазоне от 0,5 до 7 процентов. (Пожалуйста, не обижайтесь, если ваш штат не появится в этом списке или если его относительный вес не будет соответствовать действительности. Просто я хотел получить некоторые числа, вес одного из которых намного превышает вес любого другого. Файл полного сценария для создания этой таблицы вы найдете на сопровождающей журнал дискете. Прежде всего, я создал таблицу Customers, содержавшую около 1,4 миллиона строк. Я поместил таблицу в ее собственную БД SkewSingle1 и создал кластерный индекс для столбца StateCode. Также я поместил ограничение primary key на столбец CustomerID, а некластерный индекс — на LastName.
Затем, чтобы гарантировать точное сопоставление, я взял содержимое таблицы Customers и повторно создал ее в другой БД — SkewSingle2. На этот раз я создал кластерный индекс для LastName. Разумеется, первичный ключ остался на CustomerID, а некластерный индекс я поместил на LastName. Теперь, имея эти две таблицы, мы готовы выполнить некоторые тестовые запросы.
Публикация ваших Data Dictionary и Data Model
Питер Чен (Peter Chen)
В этой статье Питер Чен показывает, как вы и ваши пользователи могут использовать ASP.NET и бесплатный инструмент Visio Viewer для организации поиска в оперативном словаре данных (data dictionary) SQL Server.
Ищете ли вы уже повод сдаться и приняться за изучение .NET? Как вы поступите, если столкнетесь с одним из следующих трех сценариев?
Сценарий #1: Бизнес-аналитик приходит в ваш офис и хочет узнать подробности об отдельном поле некоего окна приложения. Кто обладает правами вносить в него изменения? Какая таблица и столбец соответствуют ему в БД? Существуют ли какие-либо контрольные следы его обновлений?
Сценарий #2:Ваш менеджер хочет, чтобы вы создали отчет (немедленно), но в двух различных таблицах существуют столбцы данных со сходными именами, и вы не уверены, какой из них нужно использовать. Вы вздыхаете, поскольку не были привлечены к разработке исходного проекта и вам не хочется пускаться в новый (непредвиденный) этап археологических раскопок в программном обеспечении.
Сценарий #3: Вы просто модифицировали БД и хотите послать заинтересованным сторонам печатную версию новой модели данных (data model).
Звучит знакомо? Если вы заинтересованы в неплохом решении для этих трех сценариев, тогда эта статья — для вас. Я не собираюсь рассказывать о разработке хранилища метаданных — только о том, как публиковать их.
Тут же возникает вопрос, что такое метаданные. Стандартное определение (данные о данных) не очень практично. Я предпочитаю представлять метаданные как сведения о производстве или технологических процессах и элементах данных вашей информационной системы. Администраторы БД, вероятно, рассматривают метаданные как вид информации, хранимой в системных таблицах SQL Server. Итак, какое отношение это имеет к администраторам БД и/или разработчикам? Поскольку лучшие метаданные — это те, что находятся в головах создавших БД проектировщика и разработчика приложений, безусловно, эта информация с трудом доступна другим людям, нуждающимся в ней. И только хранилище помогает извлечь некоторые из этих сведений.
Programming
Опасности миллисекундной арифметики
Рон Тэлмейдж (Ron Talmage)
Вот еще одна замечательная статья, в которой Рон Тэлмейдж делится с читателями своим опытом. «Я столкнулся с этой проблемой в последние выходные», — пояснил он в электронном письме, сопровождающем статью. «Что?!! — удивитесь вы. — Рон работает в выходные?» Да, а на какое еще время можно планировать системные миграции?
Все мы знаем, как SQL Server хранит данные типа datetime: дата плюс время с точностью до миллисекунды, не так ли? На самом деле не до миллисекунды, а до 3 миллисекунд. Фактически и это не вполне верно. Возможно, вы знаете, что время в SQL Server разделено на интервалы по 3 миллисекунды (то есть «тикает» каждые 3 миллисекунды), но и это еще не все. В данной статье мы рассмотрим, как SQL Server хранит время в миллисекундах и округляет миллисекунды в данных типа datetime.
Проблема: «уникальные» строки
Если честно, то я никогда не имел проблем с миллисекундами в данных, содержащих данные типа datetime, главным образом потому, что очень немногие приложения зависят от столь точного временного разбиения. Однако недавно я работал с данными, сохранявшими время с точностью до секунды. Кроме того, эти данные содержали дублированные строки. Из 41 миллиона строк в таблице приблизительно 168 тысяч было дубликатами (!), и число дубликатов в наборе колебалось от 2 до 100.
Эта таблица имела первичный ключ, но он был создан для столбца с типом данных integer и обладал свойством identity. Этот первичный ключ был «суррогатным», не имеющим реального значения или роли, кроме обеспечения уникальности каждой строки. Естественный ключ, или ключ, основанный на значениях в этих данных, который делал бы каждую строку уникальной, включал значения datetime, время в которых хранилось с точностью до секунды. С самого начала разработчики не позаботились об уникальности естественного ключа с помощью ограничения unique, поэтому в таблицу непредумышленно вносились дубликаты естественного ключа. Позднее ограничение unique было дополнено параметром WITH NOCHECK, гарантировавшего, что все новые данные будут уникальными по естественному ключу, но существующие дубликаты удаляться не будут.
В ходе последней миграции данных мы решили, что можем либо убрать дублированные строки из таблицы (например удаляя результаты старых отчетов и сводок), либо просто сделать эти строки уникальными, а затем привести данные в порядок. Поскольку очистка данных не входила в список задач миграции, мы предпочли вариант с обеспечением уникальности строк таблицы. Так как данные типа datetime не хранили значений с точностью до миллисекунд, я решил добавить к дублированным строкам каждого набора возрастающие значения в миллисекундах.
Первоначально я решил увеличить значение времени в каждой последующей строке на величину, кратную 3 миллисекундам. Поэтому в каждом наборе дубликатов я добавил 3 мс к значению datetime первой строки, 6 мс — второй, 9 мс — третьей и т. д. Увы, это не сработало. Сначала я подумал, что проблема заключалась в коде, но затем понял, что все дело в том, как SQL Server сохраняет значения в миллисекундах.
Деревья в SQL Server
Р. Л. Паркер (R. L. Parker)
Многие приложения — как коммерческие, так и созданные для собственного использования — имеют дело с иерархическими данными, структурированными в форме дерева. Однако из-за их рекурсивной природы моделирование, программирование и отображение деревьев могут показаться излишне сложными. И хотя SQL Server не предоставляет собственной поддержки иерархических данных (например, как это делает Oracle с помощью своей конструкции START WITH...CONNECT BY), не составляет труда добавить ее самостоятельно. Р. Л. Паркер объясняет, как сделать это.
Если вы не вполне уверены, что понимаете, что я подразумеваю под иерархическими данными, структурированными в форме дерева, давайте рассмотрим таблицу Employees из БД Northwind. В этой таблице начальник для служащего Northwind определяется с помощью значения в столбце ReportsTo. Это упрощает нахождение тех, кто отчитывается перед данным менеджером. Если EmployeeID для менеджера по имени Mary имеет значение 1, то те, кто подотчетен ей, идентифицируются следующим образом:
SELECT FirstName, LastName, EmployeeID
FROM Employee,
WHERE ReportsTo = 1
Но, возможно, Mary является менеджером среднего звена. Допустим, вы также хотите знать, кто отчитывается перед служащими, которые подчинены ей, и т. д. рекурсивно, до тех пор пока вы не достигните нижнего уровня дерева, на котором расположен Dilbert. Давайте остановимся на этом — мы сюда еще вернемся.
Программирование на T-SQL. Часть 1: определение переменных и логика IF...ELSE
Грегори Э. Ларсен (Gregory A. Larsen)
Это первая статья из серии, посвященной различным аспектам программирования на T-SQL. Для того чтобы создавать хранимые процедуры или писать небольшие сценарии для Query Analyzer, необходимо знать основы программирования на T-SQL.
Здесь я расскажу вам об определении переменных и использовании логики IF...ELSE.
Локальные переменные
Как и в любом другом языке программирования, T-SQL позволяет определять переменные и присваивать им значения. Переменная хранит один кусочек информации, например число или строку символов. Переменные могут использоваться для целого ряда вещей. Вот перечень наиболее распространенных вариантов их применения:
для передачи параметров хранимым процедурам или функциям;
для контроля за выполнением цикла;
для проверки истинности или ложности условия в операторе IF;
для программного контроля условий в операторе WHERE.
В SQL Server переменной обычно называется локальная переменная с надлежащей областью видимости. Областью видимости локальной переменной является только пакет (batch), хранимая процедура или блок кода, в котором эта переменная определена. Локальная переменная определяется с помощью оператора T-SQL DECLARE. Имя локальной переменной должно начинаться со знака @ в качестве первого символа ее имени. Для локальной переменной может декларироваться любой системный или пользовательский тип данных. Вот типичное объявление целочисленной переменной, названной @CNT:
DECLARE @CNT INT
(Возврат на основную страницу)