(Возврат на основную страницу)
Editorial
Не надо нам революций
Брайан Найт (Brian Knight)
Как вы, возможно, слышали, следующая версия SQL Server (проект под кодовым названием Yukon) получила официальное имя. Эта версия формально будет называться SQL Server 2005 для приведения в соответствие с версией Visual Studio 2005. Объявлен новый цикл производства, что одновременно сдвигает дату выхода очередной бета-версии. Бета 2 будет доступна летом 2004 года, бета 3 — в конце 2004 года, а финальный вариант должен выйти в первой половине следующего года.
Большинство опрошенных пользователей указали, что их не очень огорчает сдвиг сроков выпуска продукта. Общее мнение можно выразить словами «лучше позже, но лучше». Я полностью поддерживаю это мнение, однако, выскажусь против того, как Microsoft планирует выход версий.
SQL Server 2005 будет очень сильно отличаться от SQL Server 2000. Интерфейс поменялся и нововведений слишком много, чтобы их даже перечислить. Те, кто работает с SQL Server сейчас, будут поставлены перед необходимостью многое учить заново. Наиболее сложным будет освоение Data Transformation Services (DTS), которую просто полностью переработали.
Изменений слишком много для одного релиза. Неудивительно, что на ее выпуск понадобилось 5 лет. Теперешние пользователи SQL Server получили пару подачек в виде Notification Services и Reporting Services, но обошлось без промежуточных версий.
Как один из серьезных пользователей SQL Server, я бы предпочел несколько более управляемых версий. Мне бы хотелось видеть новые версии с меньшим числом изменений каждые три года. Итоговый эффект был бы таким же, но не создавалось бы ощущения, что ты перебрал, навалившись на еду у шведского стола, когда некому оттащить.
В моем идеальном мире Microsoft следовало бы выпустить SQL Server 2003, в котором интерфейс разработчика был бы привязан к Visual Studio, внести несколько небольших изменений в процессор обработки данных и существенные изменения в Analysis Services и DTS. В свою очередь SQL Server 2006 мог бы подвергнуться оставшимся нововведениям, не вошедшим в предыдущую версию, и всем существенным модификациям процессора обработки данных и системы хранения, таким как зеркалирование и разделение данных (database mirroring и partitioning).
SQL Server нуждается в обновлениях чаще, чем раз в пять лет. Имея таких конкурентов, как MySQL, Oracle и UDB, наступающих ему за пятки, текущая ситуация с пятилетним производственным циклом не выдерживает критики. Я обеими руками за качество и безопасность, но контроль качества куда проще на автомобиле, чем на сверхзвуковом лайнере.
DB Design & Warehousing
Выполнение запросов к файлам журналов с помощью Log Parser 2.0
Рон Тэлмэйдж (Ron Talmage)
Нечасто удается встретить поистине изящную утилиту, которая, к тому же, оказывается бесплатной. В этой статье Рон Тэлмэйдж представляет очень полезный инструмент — Log Parser 2.0. Фактически можно думать о LP 2.0 как о некотором прототипе того, на что может быть (или будет?) похожа файловая система, если SQL Server заключает ее в себе: оператор SELECT станет применим ко всему.
Все мы хорошо знакомы с выполнением запросов к структурированным данным с помощью SQL-команды SELECT, но когда приходится читать файлы журналов, мы зачастую полагаемся на привычные графические пользовательские интерфейсы — Enterprise Manager (инструмент SQL Server) для чтения журналов SQL Server и SQL Agent или Event Viewer (инструмент Windows) для чтения журналов событий Windows. Недавно я был приятно удивлен, узнав от Линчи Шиа (Linchi Shea), SQL Server MVP и сотрудника «SQL Server Professional», что Microsoft предоставляет бесплатно загружаемый инструмент, Log Parser 2.0, который может использоваться для запросов к широкому кругу файлов журналов с помощью команды SELECT.
Log Parser 2.0 является утилитой командной строки, которая получает строку запроса либо напрямую, либо из файла ввода и возвращающает результат. Cтрока запроса создается в формате оператора SELECT, а выходные данные могут быть представлены в командном окне, таблице SQL Server или в файлах различных форматов (включая XML). Давайте посмотрим на Log Parser 2.0 с точки зрения пользователя SQL Server.
Приложения OLAP для администраторов баз данных. Часть 2
Ричард Мо
Вы действительно считаете, что Microsoft Analysis Services предназначены в основном для бизнес-аналитиков и прочих «облаченных в костюмы»? Подумайте еще. В прошлом месяце Ричард Мо рассказал, как использовать OLAP для мониторинга операций INSERT, UPDATE и DELETE. На этот раз он демонстрирует, как применить его для мониторинга соединений с сервером.
Предоставляемые Analysis Services возможности аналитической обработки в реальном времени (OLAP) являются мощным и интересным дополнением к Microsoft SQL Server — особенно при построении приложений BI (Business Intelligence) для выявления тенденций, составления прогнозов, поиска аномалий и т. д. Однако я не собираюсь давать читателям еще одно руководство по работе с кубами данных. Я предлагаю OLAP администраторам баз данных в качестве рабочего инструмента. В прошлом месяце вы уже видели, как с помощью OLAP осуществлять мониторинг операций INSERT, UPDATE и DELETE. В этом месяце мы рассмотрим, как применять OLAP для мониторинга соединений с сервером. Используя это приложение, можно выяснить, в какие часы наблюдается пик соединений с сервером, какие при этом задействованы учетные записи, и к каким базам данных происходят обращения. Это приложение немного сложнее, чем рассмотренное в прошлом месяце, так как логика работы счетчика соединений отличается от логики счетчика операций со строками.
В кубе определен один базовый показатель — количество соединений — но на нем заданы два вычисляемых члена и введены четыре размерности.
У размерности даты имеются уровни года, месяца и дня.
Размерность времени содержит уровни часов и минут. (Дата и время представлены отдельными размерностями, чтобы можно было просматривать счетчики числа соединений, произошедших в один и тот же час, но в разные дни.)
Размерность баз данных имеет один уровень, соответствующий базам данных, с которыми устанавливаются соединения.
В размерности регистрационного имени введены два уровня — для типа пользователя и имени его учетной записи. Тип пользователя различает учетную запись SQL и доверительную связь (NT).
Осмотрись, прежде чем прыгать
Довольно грустно иметь дело с приложением БД, обладающим столь низкой производительностью, что все намекает на необходимость отказаться от него, чтобы начать работать с другой платформой БД. Однако есть пара моментов, которым стоит уделить внимание, прежде чем так поступить.
SQL Server обладает набором удобных для пользователя инструментов разработки и управления БД, такими как мастеры (wizard) и самонастраивающиеся (self-tuning) свойства. Они весьма полезны для небольших предприятий, ресурсы на разработку в которых весьма ограничены. Также это позволяет программистам компаний проекировать БД, что является бесспорным преимуществом. Но так ли это?
Пару лет назад я управляла проектом по переводу БД DB2, работающей под OS/2, на SQL Server под Windows NT. БД DB2 была крайне плохо спроектирована: она содержала повторяющиеся группы, очень длинные строки и множество неиспользуемой информации. У этого приложения была еще одна проблема: поставщик более не поддерживал клиентские средства. Производительность была ужасной, поэтому было принято решение переделать приложение полностью, используя поддерживаемое программное обеспечение. Первоначально новая БД была спроектирована разработчиком приложений, воображавшим себя администратором БД. К сожалению, результат не очень отличался от исходного приложения, основанного на DB2. К тому же, хранимые процедуры, разработанные программистом, специализирующимся на разработке под VB, были громоздкими и медленными.
Я решила ознакомиться с мнением профессионала, и эта модель была проанализирована администратором БД SQL Server, специализирующимся на разработке БД. Проконсультировавшись с бизнес-аналитиком, он полностью переработал БД. Были созданы новые хранимые процедуры, и код приложения существенно упростился. Теперь пользователи жаловались только на одно: приложение работает слишком быстро. Раньше они успевали выпить чашечку кофе за время выполнения запроса, а новая система требовала совершенно другого режима работы.
Мораль сей басни не в том, что SQL Server быстрее DB2, а в том, что любая хорошо разработанная БД работает быстрее, чем плохо разработанная. Возможна и другая ситуация: если изначальная плохо разработанная БД была бы размещена на SQL Server, а хорошо разработанная — на DB2, то победителем в соревновании представлялась бы DB2.
Как правило, целью любого предприятия является рост, поэтому БД, созданная для небольшой пользовательской базы с ограниченным объемом данных, часто разрастается и поддерживает большее число пользователей и больший объем данных, чем было запланировано изначально. Поскольку от этого страдает производительность, то возникает соблазн перейти на другую СУБД, считающуюся более быстрой (Oracle, например). Ясно, что подобный переход влечет за собой не только установку новой СУБД, о чем я расскажу чуть позже. Но достигнем ли мы своей цели? Да, возможно, но не по той причине (или причинам), что вы думаете. Поскольку нынешнему персоналу не хватает опыта работы с новой СУБД, обычно, чтобы обеспечить плавный переход на нее, к делу привлекаются эксперты. Эксперты, помимо прочего, анализируют состояние текущей БД и дают рекомендации по изменениям, улучшающим производительность на новой системе. Это приводит к корректированию плохой модели и чаще всего к повышению производительности по сравнению со старой системой. Следует задаться вопросом, может ли перестройка существующей БД на имеющейся СУБД привести к тем же результатам, но с меньшими затратами. В большинстве случаев ответом на этот вопрос будет «да».
Programming
Распределенные транзакции объединяют SQL Server и СУБД Oracle
Боб Воткинс (Bob Watkins)
Давно минули времена, когда бизнес связывал себя с решением единственного поставщика. Система планирования ресурсов организации (ERP,enterprise resource planning) может быть построена на СУБД Oracle и работать под UNIX, а система управления взаимосвязи с заказчиками (CRM, customer relationship management) — строиться на SQL Server и работать под Windows 2000.
Если вы являетесь ИТ-консультантом, то для вас недостаточно быть экспертом только в избранной области. По крайней мере, вам необходимо хорошо разбираться в вопросах интеграции вашей базовой технологии с другими.
Одним из примеров подобного типа интеграции являются распределенные транзакции, выполняющие обновления в реальном времени в нескольких БД одновременно, даже если эти БД поддерживаются различными СУБД. Понимание того, как Microsoft SQL Server и Oracle Server могут работать вместе, расширяет ваши возможности как консультанта. Например, если клиент имеет производственную систему на одной СУБД и хранилище данных на другой, знание того, как они взаимодействуют, может повысить для него значимость ваших услуг.
В этой статье я опишу, как настраивать распределенные транзакции, одновременно обновляющие SQL Server и СУБД Oracle.
Терминология
Если вы пытаясь заставить эти СУБД «говорить» друг с другом, то, вероятно, уже встречали следующие термины:
Транзакция — это группа операторов SQL, каждый из которых должен быть успешно выполнен, в противном случае отменяются результаты даже успешно выполненных операторов. Процесс извлечения денег из банкомата, например, состоит из двух частей, составляющих одну транзакцию. Банкомат выдает вам наличные, а банк обновляет свои записи. Если какое-либо из этих действий не будет выполнено, то другое также не должно завершиться.
Распределенная транзакция имеет место, если отдельные операторы в транзакции обновляют различные БД. Каждая из БД должна фиксировать (записывать) свою часть этой транзакции с тем, чтобы транзакция в целом была успешной.
Двухфазная фиксация (Two-phase commit) — это механизм, используемый для координации распределенных транзакций. Каждый сервер, вовлеченный в выполнение этой транзакции, сначала получает запрос на подготовку к ней и, когда будет готов, отвечает. Затем каждому серверу предлагается фактически зафиксировать эту транзакции.
Надежное управление логикой при обработке курсоров
Уот Хьюз (Wat Hughes)
Курсоры SQL Server получают огромное количество отрицательных отзывов, но они выполняют свою работу. Однако многие программисты придерживаются такого стиля управления логикой кода, который подвержен возникновению ошибок в ходе поддержки.
Если быть честным, многие из ошибок в обработке курсоров находятся в примере кода, распространяемом самой Microsoft. Мне встречалось множество циклов, выглядевших следующим образом:
{объявляем и открываем курсор}
fetch next…
while @@fetch_status
= 0
begin
-- делаем что-либо
fetch next…
end
{очищаем курсор }
Источником проблемы является то, что в коде есть два оператора FETCH, тогда как логически желателен только один. Не могу сосчитать, сколько раз меня просили найти ошибку, и я обнаруживал, что кто-то просто изменил один из операторов FETCH и только. А затем этот код не был должным образом проверен. Полагаю, что вы применяете более надежный стиль кодирования управления логикой при использовании курсоров.
Other
Проверка работоспособности или как бьется сердце SQL Server
Мафесами Ананта Кумар (The Mac)
Непременно надо иметь средства мониторинга для контроля служб, выполняющихся на сервере с операционной системой Windows. Однако бюджет небольших организаций не таков, чтобы иметь инструменты мониторинга.
Администраторам баз данных следует сразу же получать извещения, когда один из SQL серверов останавливается, перезапускается или не отвечает. В этой статье я собираюсь обсудить, как проверять все службы SQL Server из одного места и как каждые несколько минут проверять работоспособность экземпляров SQL Server.
Насколько мобильны ваши DTS-пакеты?
Пол Манкенбек (Paul Munkenbeck)
Насколько задача перемещения или копирования DTS-пакетов с одного сервера на другой проста для вас? Кроме явных имен серверов в объектах connection, сколько существует других свойств объектов, о которых нужно побеспокоиться? В этой статье описываются все свойства, которые необходимо проверить, а также предлагается сценарий, помогающий решить эту задачу.
Уверен, что вы проектируете и разрабатываете ваши DTS-пакеты так, чтобы они были, насколько это возможно, более гибкими и мобильными. Если вы создаете ваши пакеты программно, то разрабатываете параметризованную логику и избегаете жесткого кодирования. Если используете графический инструмент DTS Designer, то, вероятно, определяете глобальные переменные для каждого параметра, о котором хотите позаботиться, а также можете применять INI-файлы для предоставления значений периода исполнения. Но что, если вы получили DTS-пакет в наследство от недостаточно аккуратного разработчика, и теперь вам необходимо переместить этот пакет на другой сервер? Существует ли какой-либо способ организовать вашу «охоту» за значениями свойств, которые могут нуждаться в корректировке?
(Возврат на основную страницу)