(Возврат на основную страницу)
Клинт Баултон (Clint Boulton)
Компания Microsoft продолжает приоткрывать завесу тайны с новой версии Yukon СУБД SQL Server, представляя новые улучшенные возможности технологии администрирования баз данных.
В 2003 году на ежегодной конференции PASS (Professional Association for SQL Server, профессиональной ассоциации SQL Server) в Сиэтле были анонсированы усовершенствованные инструменты SQL Server по извлечению, изменению и загрузке (ETL, extract, transform and load). Они были разработаны c целью сокращения ручных настроек, выполняемых администраторами БД, что ставит эти программные функции в один ряд с заявленными технологиями управления СУБД Oracle 10G.
Компания Oracle, никогда прежде не замеченная в стремлении упрощать управляемость своих продуктов, обещает провести значительные усовершенствования в этой области в предстоящем выпуске новой версии СУБД, ожидаемом в конце 2003 года. Многие настройки, связанные с колебаниями требований к вычислительным ресурсам, будут автоматизированы на программном уровне. Этот вопрос оказался в центре внимания на встрече финансовых аналитиков компании, прошедшей на прошлой неделе в Нью-Йорке.
Несмотря на то, что компании IBM и Microsoft не столь открыто критикуются за управляемость их СУБД, усовершенствования Oracle по части простоты использования программного обеспечения произвели на некоторых аналитиков сильное впечатление, и они отметили, что это может подтолкнуть IBM и Microsoft выйти на рынок с более сильными функциями управления своих продуктов.
До настоящего времени IBM и Microsoft работали по собственным расписаниям технологических улучшений своих продуктов, но теперь аналитики прогнозируют, что три ведущие компании на рынке СУБД будут продолжать подгонять друг друга в развитии технологий баз данных.
А пока Гордон Манджони (Gordon Mangione), вице-президент компании Microsoft по SQL Server, продолжил тему, начатую на конференции профессиональных разработчиков PDC, и подробно рассказал о достижениях в области Data Transformation Services (DTS) компании Microsoft.
Манджони пообещал, что когда этот продукт будет представлен в следующем году, мир увидит полную переработку исходной архитектуры DTS. Это обеспечит администраторов БД более мощными новейшими функциями ETL.
Механизм ETL перемещает данные из одной БД в другую, сначала прочитывая (извлекая) их, затем подготавливая для другой БД (преобразуя) и, наконец, помещая (загружая) их в новое расположение. Это может оказаться трудной задачей, особенно если объем перемещаемых данных будет большим.
Манджони сказал, что новая архитектура DTS упрощает процесс ETL за счет добавления средств графической отладки и встроенных преобразований, таких как размытый поиск (fuzzy lookup), что предоставляет разработчикам массу преимуществ с точки зрения эффективности. Манджони прогнозирует, что это повысит производительность и масштабируемость, а также обеспечит поддержку транзакций, «возможность повторного запуска, обработку ошибок данных и очистку данных».
Интегрирование новых данных может оказаться дорогостоящим делом, что делает эти новейшие средства ETL привлекательными для менеджеров по информатизации, придающих значение себестоимости. Цель заключается в привлечении крупных компаний.
Служба DTS интегрирована с Analysis Services, Reporting Services и Web-службами компании Microsoft. Новый DTS API для разработчиков означает, что DTS может быть расширена с помощью индивидуальных источников данных, преобразований, заданий workflow и других объектов.
Манджони рассказал о стремлении компании к улучшению существующей отлаженной версии СУБД SQL Server 2000. Результат этого — Best Practices Analyzer (BPA), инструмент, призванный помогать администраторам БД в разработке приложений SQL Server, отличающихся более высоким качеством и простотой в управлении.
Рекомендации по конфигурированию варьируются в пределах от доступности и резервного копирования/восстановления до управления и производительности. BPA может находить конфигурации, использующие нерекомендуемые опции.
Том Моро (Tom Moreau)
В мире OLTP (On-Line Transaction Processing) скорость — это все. Ужасные песочные часы являются персоной нон грата и даже ваш самый капризный пользователь не заслуживает их появления (ну разве что иногда). В этой статье доктор Том Моро исследует нормализацию и ее влияние на производительность. В качестве бонуса он поясняет, как создавал довольно реалистичную базу данных test и что узнал на «завтраке с Биллом», состоявшемся в августе.
Недавно я интервьюировал претендента на должность администратора БД для нашего проекта. Я спросил его о нормализации и он ответил так: «Нормализуй до тех пор, пока это не причиняет вреда. Денормализуй до тех пор, пока это работает». «Находчивый», — подумал я. Этот вопрос был задан неспроста. Дело в том, что работая с OLTP-приложением (сидя у заказчика) мы столкнулись с проблемами производительности.
Процесс выявления неисправностей заставил меня сосредоточился на БД, особенно на ее физической схеме. Некоторые из таблиц содержали повторяющиеся группы (repeating group) — явное нарушение первой нормальной формы (1NF, First Normal Form). Повторяющиеся группы — это таблица в таблице, как правило, список. Примером повторяющейся группы может служить список нескольких телефонных номеров. Хотя использование повторяющихся групп кажется более удобным, однако существует цена, которую приходится за это платить. Вот небольшой (и нормализованный) список:
• шире строки и, таким образом, меньше строк на странице;
• необходимость обработки пустых значений;
• дополнительные индексы;
• отсутствие условия для расширения;
• сложность обеспечения уникальности через повторяющиеся группы;
• усложненные поиски на повторяющихся группах, особенно для агрегирования;
• меньшая производительность выполнения UPDATE/DELETE/INSERT;
• необходимость доработки кода программы.
В том случае, если выполняется сканирование всей таблицы, наличие более широких таблиц становится существенным недостатком. Меньшее количество строк на странице приводит к необходимости чтения большего количества страниц, что требует дополнительных затрат времени. Если же сканирование проводится для поиска данных, которые даже не содержатся в повторяющихся группах, то вы впустую тратите ресурсы системы.
Пол Сторер-Мартин (Paul Storer-Martin)
В заключительной части своего блестящего учебного пособия Пол Сторер-Мартин описывает, как можно создавать расширенные хранимые процедуры в качестве управляемых сборок (managed assembly) в SQL Server 7.0 и 2000. По утверждению Пола, полученные результаты «поражают воображение», поскольку это, по существу, распространяет понятие расширенных хранимых процедур на область всей инфраструктуры классов .NET и индивидуальных компонентов, написанных на любом из языков .NET.
Исторически ODS (Open Data Services) использовались либо для создания расширенных хранимых процедур, либо как шлюзовые приложения (gateway application), позволяющие службам, не входящим в SQL Server, иметь его «фасад». Подобная шлюзовая функциональность в настоящее время канула в лету, но по-прежнему много говорится о написании ваших собственных расширенных хранимых процедур. Расширенные хранимые процедуры — это просто функции, реализованные с помощью ODS API и упакованные в Win32 DLL. И поскольку обычно они разрабатываются с помощью C/C++, то имеют доступ ко всему Win32 API и любым другим компонентам или библиотекам, с которыми может быть сопряжен выбранный вами инструмент разработчика.
В части 1 мы рассмотрели основы использования ODS для создания расширенных хранимых процедур. Теперь пришло время расширить эту модель в область .NET.
Линчи Шиа (Linchi Shea)
Проверка хранимых процедур на соответствие логическим стандартам кодирования является важной частью работы многих администраторов БД. В этой статье Линчи Шиа представляет сценарий, написанный на Perl, который может использоваться для сканирования файлов сценариев хранимых процедур и создания отчетов, выявляющих любые нарушения стандартов кодирования. Также рекомендуем прочесть статью Рона Тэлмэйджа (Ron Talmage) «Лучшие приемы работы с хранимыми процедурами».
Одно из моих заданий помогает администраторам БД анализировать хранимые процедуры. Детальный анализ кода, такой как его критический разбор, зачастую кажется весьма утомительным, но только такой подход может обеспечить появление кода наивысшего качества. По меньшей мере, я просматриваю хранимые процедуры на наличие явных нарушений установленных стандартов кодирования. Вероятно, подобная проверка легче всего автоматизируется и является наименее интересным аспектом анализа хранимых процедур. Я с большим удовольствием трачу время, проверяя разработку запросов и индексов или выясняя, можно ли преобразовать курсор в более производительный, ориентированный на наборы (set-oriented) SQL-запрос.
Не так давно я спросил себя — и это был не риторический вопрос: «Могу ли я автоматически проверить хранимые процедуры на наличие нарушений стандартов кодирования?» Если использовать правильные инструменты, то написать программу для выявления нарушений большинства общих рекомендуемых стандартов кодирования — задача нетрудная и не требующая больших затрат времени. Своим инструментом я избрал язык программирования Perl, и в результате работы появился написанный на нем сценарий, который я назвал reviewSP.pl.
Рауль Шарма (Rahul Sharma)
Осиротевший сеанс (orphaned session) — это сеанс, остающийся открытым на стороне сервера после отключения пользователя. Не путайте осиротевшие сеансы с осиротевшими пользователями. Осиротевшие пользователи появляются при выполнении резервного копирования БД и восстановления ее на другой системе, на которой учетные записи этих пользователей не сконфигурированы.
Осиротевшие сеансы возникают в том случае, если клиент не имеет возможности освободить сетевое соединение и оно сохраняется после его завершения. Когда клиент отключается должным образом, Windows закрывает соединение и уведомляет об этом SQL Server. Если SQL Server обрабатывает команду клиента, то он обнаружит закрытое соединение только после завершения этого сеанса. Аварийно завершенные клиентские приложения или приложения, процессы которых были уничтожены (например, из Task Manager), прерываются Windows NT немедленно и редко приводят к появлению осиротевших сеансов.
Одной из обычных причин возникновения осиротевших сеансов является внезапное отключение питания клиентского компьютера или его выключение без выполнения надлежащей процедуры. Осиротевшие сеансы также могут быть следствием «зависших» приложений, никогда не завершающихся окончательно и приводящих к появлению «мертвых» соединений (dead connection). Windows не узнает, что это «мертвое» соединение, и будет продолжать уведомлять SQL Server об этой операции как об активной. SQL Server в свою очередь будет сохранять этот сеанс открытым и продолжать ждать команду от клиента.
Проблемы осиротевших соединений
Открытый сеанс занимает одно из сетевых соединений SQL Server. Максимальное число соединений ограничено числом лицензий на подключение клиента (CAL, Client Access License) сервера, следовательно, осиротевшие сеансы могут лишить других клиентов возможности подключиться к серверу.
Еще важнее, что открытый сеанс занимает ресурсы сервера и может оставлять открытые курсоры, временные таблицы или наложенные блокировки. Эти блокировки могут препятствовать другим соединениям выполнять полезную работу и иногда становятся результатом нагромождения блокировок. В особенно серьезных случаях это может привести к полной остановке работы SQL Server.
Решения проблемы
Sysprocesses (или такая хранимая процедура, как sp_who) дает информацию о существующих сеансах. Возможные осиротевшие сеансы могут быть выявлены, если статус процессов, связанных с ними — awaiting command (в ожидании команды), а интервал времени, определенный вычитанием last_batch из GETDATE() больше, чем стандартный для этих процессов. Если известно, что узел, инициировавший сеанс, отключен, то это осиротевший сеанс.
Windows периодически проверяет сеансы, чтобы удостовериться в их активности. Если сеанс не отвечает, он закрывается, и SQL Server уведомляется об этом. Частота этих проверок зависит от сетевого протокола и настроек реестра. По умолчанию Windows NT выполняет такую проверку через один или два часа, в зависимости от используемого протокола. Эти конфигурационные настройки могут быть изменены в реестре системы.
Чтобы закрыть осиротевшие сеансы SQL Server, используйте команду KILL. Тогда все ресурсы, удерживаемые сеансом, будут освобождены. Если осиротевшие сеансы становятся проблемой, можно изменить настройки реестра Windows так, чтобы увеличить частоту проверки активности сеансов клиентов. Изменение этих настроек влияет на другие соединения приложений, поэтому перед тем, как вносить какие-либо изменения, следует принять во внимание приведенные ниже соображения.
(Возврат на основную страницу)