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

Разбиение на разделы в SQL Server 2005

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

Кое-что о разбиении на разделы

В предыдущих версиях SQL Server пользователям были доступны различные варианты разбиения на разделы. Один из них — разбиение на разделы, управляемые приложением (application­managed partitioning), когда приложение решает, куда поместить те или иные данные. По существу, данные распределяются между несколькими таблицами или серверами. Есть и другой метод — разделенные представления (Partitioning Views, PV), появившиеся в SQL Server 2000. В отличие от управляемых приложением разделов, этот подход упрощает концепцию разбиения на разделы и предоставляет единый логический объект, то есть приложение не знает, что данные каким­то образом разбиты. Более того, такие представления могут объединяться с помощью запросов с ключевым словом UNION. Казалось, что этот подход проживет достаточно долго, хотя он и не был самым эффективным. Когда данные запрашиваются из нескольких БД или у нескольких экземпляров или серверов, этот метод носит название распределенных разделенных представлений (Distributed Partitioned Views, DPV). Хотя мы долгое время пользовались этими технологиями, у них есть свои недостатки, о которых стоит упомянуть. Несомненно, что управляемые приложением разделы были привязаны к тому, кто осуществляет вызов, то есть, чтобы перенаправить данные определенному получателю, приходилось писать особый код. Из­за этого не представлялось возможным реализовать общее решение, подходящее для всех случаев. Что касается PV или DPV, их планы запросов непомерно велики, поскольку каждая таблица в представлении является отдельным объектом со своей статистикой, а выполняемые в процессе оптимизации преобразования занимают довольно длительное время. В DPV приходится выполнять дополнительную работу, когда дело доходит до загрузки данных с помощью BCP или других механизмов массовой загрузки. Более того, механизм доступа в SQL Server 2000 был по своей природе по­следовательным и потому менее эффективным. Разумеется, SQL Server 2005 содержит улучшения по всем перечисленным пунктам, а также руководствуется более эффективной моделью разбиения на разделы в целом.

Недокументированное решение по автоматической установке SQL Server 2005

Автоматизировать установку посредством SQL Server 2000 просто, потому что он создает файл setup.iss, который вы можете использовать в качестве входного, но Microsoft изъяла эту возможность из SQL Server 2005. Изучите недокументированную возможность SQL Server 2005, которая предоставляет функциональность, подобную setup.iss.

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

В SQL Server 2000 это выполняется просто, по­скольку процесс установки создает файл setup.iss, который вы применяется как входной при автоматической установке. К сожалению, в SQL Server 2005 данная возможность отсутствует, и никакая другая реализация подобной функциональности не задокументирована.

Тем не менее, недокументированная возможность SQL Server 2005 предоставляет похожий на setup.iss функционал, но вам придется использовать редактор для чтения файла XML и редактирования текстового файла. Это небольшая цена, которую вы платите, когда альтернативой является метод проб и ошибок. Замечу, что вы каждый раз идете на риск, используя недокументированную возможность. Она может быть полностью удалена в последующих версиях, или синтаксис ее применения может полностью поменяться без упоминания об этом.

Я чую параметр!

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

Использование параметров, особенно в более сложных сценариях, способно также привести к проблемам в производительности. Если запросы сложны и/или распределения данных по полям, в отношении которых сравнивается параметр, отличаются, то затраты на выбор различных планов могут варьироваться. План, оптимальный для одного значения параметра, может плохо работать для другого. Оптимизатор запросов также нуждается в оценке избирательности (selectivity) и объемов выдачи (cardinality) предикатов, использующих значение параметра. Опишем подробно, как происходит этот процесс.

Стандартным будет использование среднего числа дубликатов на значение (средняя частота) для оценки того, сколько строк будет отвечать параметру. Для предиката равенства это именно то, что произойдет в основном случае. Однако оптимизатор пытается найти любое заданное значение, доступное во время компиляции запроса, и будет использовать именно это значение для оценки объема выдачи. Такой процесс использования величины параметра для оценки выборки и мощности называется parameter sniffing («вынюхивание параметра»).

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

Компонент SQL Server 2005 Service Broker успешно работает со «старшими родственниками»

Компонент SQL Server 2005 Service Broker (SSB) — это технология обработки асинхронных сообщений (asynchronous messaging), встроенная в SQL Server. Использование SSB-компонента дает сочетание мощных возможностей технологий сообщений, таких как Microsoft Message Queue (MSMQ), с возможностями реляционных баз данных сервера SQL Server, полностью контролируемое с помощью предложений языка запросов Transact SQL.

SSB­компонент поставляется только вместе с версией SQL Server 2005, поэтому использование его могущества совместно с другими технологиями, например с версией SQL Server 2000, может стать для вас маленькой проблемой. Вы могли бы использовать третью технологию, например сервер BizTalk, как связующее звено между SSB­компонентом и другими технологиям; может быть, вариант, обращающийся к внешней активации, тоже подходит, но документация SQL Server Books Online не дает ясного представления о способе реализации такой внешней активации, и к тому же это непростое дело.

Эта статья представляет третий, более простой подход к интеграции SSB­компонента с другими системами — использование новых возможностей платформы .NET 2.0 для создания решения, основанного на простом опросе.

Первый взгляд на SQL Server Everywhere

СУБД SQL Server Everywhere предназначена для однопользовательских сценариев в настольных системах. Она имеет ряд ограничений, но является идеальным решением для простого приложения, которому необходимо обеспечить хранение небольшого объема данных для единственного пользователя.

Годами специалисты, ориентированные на сред­ства разработки от Microsoft, боролись с проблемой: что использовать в качестве базы данных в однопользовательских приложениях с умеренными требованиями, предъявляемыми к хранению данных. Возможности выбора для решения проблемы встроенных баз данных не отличались разнообразием и сводились к СУБД Microsoft Access или механизму MSDE (или его нынешнему «заместителю» — SQL Server Express) либо к не­Microsoft приложениям, например СУБД SQLite или SQLBase. С одной стороны, СУБД Access и вариант SQL Server Express скорее оказываются тяжеловесными, если все, что вам надо, — это простой механизм хранения данных, не создающий трудностей при распространении1. С другой стороны, альтернативные варианты, не принадлежащие Microsoft, требуют присутствия на сцене другого поставщика и заботы о таких вещах, как долгосрочная поддержка и совместимость с изменчивым ландшафтом инструментальных средств разработки, по­ступающих из Редмонда.

Этой осенью должна появиться новая возможность — СУБД Microsoft SQL Server Everywhere. SQL Server Everywhere обеспечивает исключительно легкую (занимает менее 2 Мб дискового пространства), простую с точки зрения распространения, бесплатную базу данных от Microsoft с синтаксисом, который является подмножеством полного варианта языка запросов SQL Server Transact­SQL. Хотя она имеет ряд ограничений, СУБД SQL Server Everywhere является идеальным решением для простого приложения, которому всего лишь необходимо обеспечить хранение небольшого объема данных для един­ственного пользователя, и этот программный продукт стоит внести в ваш список возможных инструментов на будущее.

Папаша Риветт и подозрительная база данных

Блэйк Сэвидж в ужасе взирал на строку сообщения об ошибках в операционном журнале базы данных своего коммуникационного модуля. Вечно этот SQL Server рушился сам и разрушал базу данных в самый неподходящий момент. Без хранящейся в базе данных информации невозможна никакая связь за пределами планеты! Как они вернутся обратно на свой корабль?

Прозрачная маска его шлема Goldfish — последнее слово науки и техники — запотевала по мере того, как Блэйка охватывала паника.

«Капитан, — заорал он в свое фантастическое переговорное устройство двухсторонней связи, — опять тот же случай, черт побери».

«Что могло вызвать такой сбой в чудном хромированном оборудовании, — уныло думал он. — Может быть, это странные кислотные пески Луны Lunix 245B проникли в дисковую систему компьютера».

«Пустяки, — беззаботно произнес капитан Папаша Риветт, плавно вырисовываясь в поле зрения над мягкой поверхностью Луны. — Эта база данных использует полную модель восстановления (full recovery model), значит, просто восстановим ее из самой по­следней работоспособной резервной копии с после­дующим поочередным восстановлением журналов транзакций».

Блэйк неслышно выругался про себя. Где­то далеко над ними курсировал их замечательный межгалактический боевой корабль SS Sicromoft. Там в запертом шкафу в его каюте лежала самая последняя работо­способная резервная копия, надежно упрятанная в упаковку Formica. Он застыл в ужасе перед послед­ствиями этого факта.

«У тебя ведь есть работоспособная резервная копия, верно?» — спросил Папаша, инстинктивно крутанув диск своего электрошокера на отметку «максимальная боль». Наблюдая, как выступают на лбу Блэйка капельки пота, Папаша стиснул зубы и покрепче ухва­тил электрошокер, прежде чем с тяжелым вздохом вернуть оружие в кобуру.

«Ну, правильно, значит, база данных выдает строку DBCC­ошибок, демонстрируя все признаки появления неполной страницы (torn page), и... по какой бы то ни было причине… — произнес он, многозначительно и пристально глядя на Блэйка, — резерв­ной копии нет. Прежде всего сохраняем спокой­ствие. Возможно, ты все­таки сможешь извлечь информацию из этой базы данных. Давай пройдем весь путь, шаг за шагом».

 

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