|
|
СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ #03/98
|
|
В десятилетней истории Microsoft SQL Server выход версии 7.0 можно охарактеризовать, пожалуй, как наиболее значительный рывок к мощной и в то же время масштабируемой СУБД и унифицированным средствам обработки информации. Ее разработка велась на протяжении двух с половиной лет и ставила своей основной задачей обеспечение эффективности и надежности в широком диапазоне системных сред: от настольных до клиент-серверных и многоуровневых масштаба корпорации. Создание сервера баз данных, адресуемого крупному корпоративному бизнесу, потребовало длительного и тщательного тестирования. 1-я бета-версия продукта появилась в июне 1997 года и была распространена среди 200 независимых производителей программного обеспечения и аппаратных платформ. 2-я бета-версия, вышедшая в декабре 1997 года, была разослана 3000 тестерам. На заключительном, третьем этапе (июнь 1998 года) бета-версия была помещена на Web-сервер Microsoft, и подключиться к процессу тестированию смогли все желающие.
Microsoft SQL Server 7.0 будет распространяться в трех основных редакциях: SBS, стандартной и корпоративной. Корпоративная редакция устанавливается только на Windows NT Enterprise Edition и включает в себя такие дополнительные особенности, как поддержка до 32 процессоров, возможность установки на кластер MSCS и адресация расширенной памяти. В OLAP Services при этом можно создавать определяемые пользователем разбиения. Стандартная редакция работает на платформах Microsoft Windows Small Business Server и Microsoft Windows NT Server стандартной и корпоративной редакции. Количество поддерживаемых процессоров ограничено четырьмя. SBS-версия имеет ограниченный размер базы данных (10 Гбайт) и не включает OLAP Services. Количество одновременных пользователей в ней ограничено 50. Наконец, пользователи, обладающие лицензией per seat на любую из вышеперечисленных редакций, могут установить настольную редакцию Microsoft SQL Server 7.0. Настольная редакция предназначена для работы на Windows 95/98, Windows NT Workstation, Windows NT Server и Windows NT Enterprise. В отличие от остальных редакций она не имеет возможностей внутризапросного параллелизма, поддержки легковесных потоков (fibers), опережающего чтения (read ahead), полнотекстового поиска и некоторых других. Настольная редакция не может выступать издателем в транзакционной репликации (хотя может быть подписчиком) и не включает OLAP Services (хотя может использовать PivotTable Service).
Наш дальнейший рассказ об основных изменениях, произошедших в SQL Server, мы построим исходя из не нуждающегося в доказательстве утверждения, что любой бизнес имеет дело с данными. Отсюда, логично предложить следующий порядок повествования.
Излишне говорить, что немалую роль при использовании любого программного продукта играет простота его освоения и удобство использования, поскольку эти факторы не только способны выработать чисто психологическое расположение к продукту, но и имеют достаточно четкую вещественную оценку в размере расходов на подготовку администраторов и программистов, что позволяет существенно снизить стоимость владения продуктом (TCO). Именно с этого немаловажного аспекта мы приступим к нашему обзору.
Как правило, серверы баз данных, традиционно ассоциирующиеся с обслуживанием корпоративного звена, отличаются сложностью изучения и администрирования. Microsoft SQL Server содержит множество утилит, инструментов, программ-мастеров (wizards), всплывающих автоподсказок и других возможностей, которые позволяют значительно упростить весь цикл работы с сервером, включая его установку, внедрение, управление и использование. SQL Server обеспечивает администраторов полным набором средств тонкой самонастройки для достижения лучшей производительности на имеющихся промышленных приложениях реального времени. Он также способен эффективно работать на автономных однопользовательских настольных системах, предполагая минимум административного вмешательства.
SQL Server версии 7.0 обладает способностью переконфигурировать себя автоматически во время работы. Если нагрузка на сервер возрастает, он будет динамически привлекать дополнительные ресурсы (например, память, отведенная серверу как приложению). При снижении нагрузки SQL Server возвращает ресурсы операционной системе. Это происходит также, если в операционной системе запускаются другие приложения. SQL Server обнаруживает дополнительные запросы на виртуальную память и высвобождает часть занятой под себя памяти, чтобы уберечь систему от интенсивного пэйджинга. Аналогичным образом происходит работа с дисковыми ресурсами: SQL Server может автоматически увеличивать или сжимать файл базы данных при добавлении или удалении записей. Выбор между тем, какие параметры серверной настройки будут определяться динамически, а какие - устанавливаться вручную, зависит от администратора. Если база данных сравнительно невелика, задачи рутинны или администратор малоопытен, можно возложить администрирование целиком на SQL Server. В случае объемных промышленных баз и сложных приложений искушенный администратор может полностью взять управление на себя.
SQL Server предлагает администраторам баз данных следующие графические инструменты управления:
Программы-мастера позволяют решать сложные задачи администрирования, проводя пользователя через последовательность экранных форм, на каждой из которых от него требуется выполнить какое-нибудь элементарное действие, например, ответить на заданный вопрос "да" или "нет". Программы-мастера существовали и в предыдущих версиях SQL Server (например, Database Maintenance Plan Wizard), однако в версии 7.0 их число значительно возросло. В SQL Server Enterprise Manager их входит свыше 20. По специфике решаемых задач они сгруппированы по темам: Database, Data Transformation Services, Maintenance и Replication и охватывают широкий круг самых разнообразных административных функций, начиная от регистрации сервера, создания базы данных, логина, хранимой процедуры и т.п. и заканчивая настройкой индекса, задачами мультисерверного администрирования (см. SQL Server Agent) и построением профиля трассировки (см. SQL Server Profiler). Мастера очень пригодятся при отстутствии у начинающего администратора достаточных навыков работы или при решении трудоемких, но рутинных по своей природе задач.
Фундаментальной единицей хранения данных в SQL Server является страница. В версии 7.0 размер всех типов страниц увеличился с 2 до 8К, что позволило увеличить максимальную длину записи до 8060 байт. Соответственно возросли предельные длины переменных типов char, nchar, varchar, nvarchar, binary, varbinary - 8000 (с 255). Количество полей в таблице стало составлять 1024 (по сравнению с 250 в предыдущей версии). Протяжение (extent) составляет 8 последовательных страниц и служит базовой мерой, по которой объектам базы данных выделяется пространство памяти. В SQL Server 7.0 допустимы смешанные протяжения (mixed extents), которые могут делить между собой до 8 объектов, что позволяет более экономно использовать ресурсы. Изменился формат хранения BLOB-полей типа text, ntext и image. Во-первых, на одной странице, выделяемой под значения этих типов, могут храниться несколько таких значений в случае их небольшой длины, что опять-таки позволяет более экономно расходовать дисковое пространство. Во-вторых, вместо двусвязного списка эти страницы теперь образуют сбалансированное дерево (B-Tree), чем достигается более быстрый поиск фрагментов текста внутри длинных полей. В качестве указателя записи при наличии кластерного ключа используется теперь именно кластерный ключ (плюс uniquifier, если этот ключ не уникален), а не Row ID (RID). При вставках в середину таблицы кластерный ключ, в отличие от RIDa (представляющего собой номер файла, номер страницы и номер слота соответствующей записи на этой странице) остается постоянным и не требует волны обновлений указателей на листовых страницах некластерных индексов. При отстутствии кластерного индекса за указатели берутся RIDы, но тогда вставки происходят только в конец.
Ушли понятия устройства (device) и сегмента (segment). Хранение данных стало более тесно привязано к файлам операционной системы. Каждая база данных включает один первичный (primary) файл, содержащий стартовую информацию о хранении данных в базе, возможно, несколько вторичных файлов, хранящих данные, не поместившиеся в первичном файле, и один или несколько log-файлов для хранения журнала транзакций. Один файл не может более принадлежать нескольким базам данных. Данные и журнал транзакций теперь в обязательном порядке хранятся в отдельных файлах. Как мы уже упоминали выше, файлы баз данных получают возможность автоматически расти по мере необходимости либо в заранее заданных пределах, либо пока есть свободное место на диске. Для удобства администрирования файлы могут объединяться в группы. При создании объекта базы ему можно в явном виде указать, какой группе файлов он будет принадлежать. Если группа включает три файла, расположенных каждый на своем отдельном диске, и мы создаем индекс, который назначается данной группе, то это означает, что индекс будет физически "размазан" по этим трем дискам. Журналы транзакций никогда не являются частью никакой файловой группы.
Операции он-лайнового резервного копирования / восстановления (backup / restore) стали работать намного быстрее и оказывать меньшее влияние на производительность сервера по обслуживанию пользовательских запросов. Под он-лайновым резервным копированием мы понимаем резервное копирование открытых и используемых баз. SQL Server 7.0 применяет промышленный стандарт нечеткого копирования (fuzzy bаckup), который состоит в том, что протяжения (extents) копируются без последующей синхронизации пользовательских изменений, которые происходят за время резервного копирования. Эти изменения попадают в журнал транзакций, кусок которого, относящийся к периоду резервного копирования, копируется вместе с данными. При восстановлении эти транзакции накатываются на резервную копию данных, приводя их в целостное состояние. Резервное копирование может происходить на диск, ленточное устройство или в поименованный канал (named pipe). Во всех случаях используется стандартный формат резервного копирования MTF (Microsoft Tape Format), позволяющий чередовать на одном и том же носителе резервные копии данных SQL Server и Windows NT. Можно осуществлять полное или дифференциальное резервное копирование всей базы данных, отдельных входящих в нее файлов или файловых групп, а также отдельное резервное копирование журнала транзакций. Дифференциальное резервное копирование (differential backup) включает копии всех страниц принадлежащих базе объектов, модифицированных с момента последнего полного резервного копирования. Предполагается, что дифференциальное копирование должно происходить чаще полного, но реже резервного копирования журнала транзакций. При восстановлении базы на другом сервере теперь нет необходимости предварительно создавать базу данных. Создание базы происходит автоматически как часть процесса восстановления. Опция FOR LOAD оставлена в 7.0 для обратной совместимости. Прерванные операции резервного копирования / восстановления при возобновлении продолжают выполнение не с самого начала, а от точки предыдущего останова. Резервное копирование / восстановление может быть выполнено как из SQL Server Enterprise Manager, так и командами Transact-SQL.
Отдельные файлы баз данных можно переносить с сервера на сервер без необходимости их резервного копирования / восстановления - см. хранимые процедуры sp_attach_single_file_db и sp_attach_db.
Улучшилась также функциональность операций по проверке целостности (DBCC) и массивной загрузке данных (bcp). Команды DBCC были перепроектированы для достижения повышенной производительности. BСР теперь может осуществлять проверку ограничений (constraints) и вызывать срабатывание триггеров. BCP использует интерфейсы OLE DB для взаимодействия с SQL Server, поддерживает все типы данных и стала намного быстрее. Стали более эффективными способы загрузки данных в таблицы с определенными на них индексами.
В предыдущих версиях уровни изоляции REPEATABLE READ и SERIALIZABLE приводили к одинаковым эффектам. В SQL Server 7.0 их поведение приведено в соответствии со стандартами: первый допускает появление фантомов среди записей, блокированных на протяжении транзакции, второй - запрещает. Для обеспечения должного эффекта был введен новый режим блокировки - блокирование по диапазону ключей.
Блокировка уровня записи стала доступна для всех типов транзакций, а не только операций вставки, как это было в версии 6.5.
Для увеличения количества одновременно работающих пользователей и минимизации риска их взаимного блокирования в SQL Server 7.0 была реализована стратегия динамической блокировки, когда масштаб блокировок автоматически определяется на стадии компиляции плана запроса или даже может корректироваться в ходе выполнения, если обратное не указано пользователем (динамическая эскалация / деэскалация масштаба).
В SQL Server 7.0 процессор запросов полностью отделен от механизма хранения и рассматривает таковой лишь в качестве одного из многих OLE DB-достижимых источников данных. Это позволяет процессору запросов работать с гетерогенными запросами, когда одним оператором SQL обрабатываются данные, принадлежащие не только разным серверам SQL Server 7.0 или 6.х, но и находящиеся на серверах других производителей, например, Oracle, в настольных СУБД (MS Access, MS Visual FoxPro, ...), табличных редакторах (MS Excel, ...), либо вообще нереляционных (файловая система, электронная почта, ...). С помощью соответствующих OLE DB-провайдеров в SQL Server 7.0 был реализован полнотекстовый поиск по полям строчных и текстовых типов, внутри файлов операционной системы и документов, опубликованных на Web-сервере.
Как известно, ранние версии SQL Server поддерживали межзапросный параллелизм, когда обслуживание пользовательских сессий велось на разных потоках. Наряду с этим, SQL Server 7.0 обладает возможностью внутризапросного параллелизма, когда выполнение одного запроса ведется одновременно на нескольких потоках. Таким образом, если аппаратная платформа оснащена несколькими процессорами (CPU), работа по обслуживанию запроса будет разделяться между процессорами. Это позволяет значительно ускорить обработку массивных аналитических запросов.
Как подчеркивалось во Введении, SQL Server 7.0 Enterprise Edition позиционируется Microsoft в качестве сервера баз данных для крупных корпораций. В соответствии с этой целью, процессор запросов был существенно перепроектирован исходя из необходимости обработки больших объемов данных и сложных запросов, характерных для OLAP-приложений и систем поддержки принятия решения. В него были добавлены новые технологии построения связей между таблицами (merge join, hash join, hash team и их разновидности), а также дополнительные стратегии оптимизатора при обработке ROLAP-хранилищ, построенных по звездной схеме или "снежинке", такие как декартово произведение измерений, преобразование к semi-join и т.д. В отличие от предыдущих версий, где только один из индексов мог использоваться при обработке запроса, процессор запросов SQL Server 7.0 рассматривает сразу все доступные индексы, более того, он умеет выполнять теоретико-множественные операции над индексами, такие как пересечение, объединение, разность для обработки предикатов AND, OR, NOT IN и т.д. В частности, это позволяет SQL Server"у динамически построить покрывающий индекс за счет объединения имеющихся и ускорить выполнение запроса, за счет того, что чтение можно ограничить листовым уровнем индекса.
Улучшенная модель оценки стоимости запроса и усовершенствования периода компиляции существенно повысили качество планов. Например, если таблицы Т1, Т2, Т3 связываются между собой по одному атрибуту в порядке (Т1, Т2), (Т2, Т3), то оптимизатор "понимает", что из свойства транзитивности вытекает также (Т1, Т3) и, если эта связь дешевле, заменит ею одну из явно заданных. Другой пример - автопараметризация запросов. Выполнив серию запросов вида select * from member where member_no=1, select * from member where member_no=2, select * from member where member_no=3, ..., мы обнаружим, что количество планов в кэше, увеличившись после первого запроса, затем остается постоянным. Это значит, что SQL Server неявно использует запрос вида sp_executesql N"select * from member where member_no=@var", N"@var int", 3, в чем можно убедиться, посмотрев select * from master..syscacheobjects. В кэше, как мы видим, теперь могут храниться не только планы хранимых процедур, но и обычных запросов, как прекомпилированных (prepared), так и поступающих по ходу дела (ad hoc). Точные текстовые совпадения приведут к использованию уже имеющейся в кэше копии плана, независимо от того, от какой сессии приходит запрос, так как контексты соединений хранятся отдельно от собственно планов.
Для хранимой процедуры план компилируется на основе параметров, переданных ей в момент первого выполнения и исходя из состояния данных в этот момент. Это легко увидеть с помощью DBCC MEMUSAGE("PROCEDURE"): план появится там не после CREATE PROCEDURE, а в момент EXECа. Очевидно, что в ходе пользовательской активности данные могут меняться, так что план станет не очень оптимальным. SQL Server 7.0 автоматически без участия администратора выполняет перекомпиляцию плана при:
1) внесении каких-либо изменений в структуру таблицы или представления, от которых зависит процедура;
2) внесении значительного числа изменений в данные (характеризуется определенным приростом transaction log;
3) обновлении статистики на какие-то из полей (неважно, пользователем или самим сервером);
4) удалении индекса на таблицу, от которой зависит sp. В то же время создание нового индекса не вызывает перекомпиляцию процедуры, даже если процедура могла бы от него сильно выиграть. Ручная перекомпиляция осуществляется с помощью sp_recompile - не вызывает компиляцию немедленно, а только говорит процессору запросов, что в момент следующего вызова план процедуры требуется перестроить. Того же можно добиться непосредственно: EXEC ... WITH RECOMPILE. Наконец, можно сказать SQL Server"у, чтобы для данной процедуры он строил новый план всякий раз, как мы ее вызываем. Это делается с помощью опции WITH RECOMPILE операторов CREATE/ALTER PROC и имеет смысл в том случае, если процедура работает с нетипичными или временными часто меняющимися данными. Планы таких процедур вообще не хранятся в кэше. Особо заметим, что перекомпиляция всех хранимых процедур происходит также при вызове sp_dbcmptlevel. Эта процедура устанавливает совместимость поведения для базы данных SQL Server 7.0 с версией 6.0 или 6.5, включая соответствие синтаксиса.
В версии 7.0 план является разделяемым (shared), что позволяет многим пользователям работать одновременно с единственной копией плана в памяти и существенно экономит процедурный кэш. План запроса не будет разделяться при различии параметров настройки сред окружения пользовательских сессий, могущих повлиять на ход выполнения запроса. Например,
user1: user2: set ansi_warnings on set ansi_warnings off select * from authors select * from authorsдаст две копии плана, так как в первой сессии арифметическое переполнение должно вызывать генерацию сообщения об ошибке и откат транзакции, а во второй - возвращать значения null.
SQL Server 7.0 по умолчанию создает самообновляющуюся статистику. Тем не менее, если вы хотите вручную следить за поддержкой актуальности, вы можете отключить самообновление с помощью sp_autostats "tbl", "OFF" [,"ix_name"] или вызвав UPDATE STATISTICS ... NORECOMPUTE. Оптимизатор предупреждает в плане выполнения запросов об отсутствии необходимой статистики. Контекстное меню шага в графическом SHOWPLAN позволяет тут же ее создать. В версии 7.0 более нет нужды строить индексы по некоторым полям только для того, чтобы иметь статистику распределения в этих колонках, так как появилась возможность создания статистики по неиндексированным полям. Кроме того, статистика более не ограничена одной страницей (distribution page), а хранится в виде image-поля, на которое указывает sysindexes.statblob. Она приводит к более точным оценкам за счет усовершенствованных алгоритмов интерполяции. Для ее построения оптимизатор по умолчанию пользуется случайной равномерной выборкой, а не всем множеством значений ключей. Задать мощность выборки в количестве записей или процентах от их общего числа можно при обновлении статистики: UPDATE STATISTICS ... WITH SAMPLE <число> {ROWS | PERCENT}. Эта опция удобна тем, что позволяет добиться хороших результатов при оценке запросов без значительных временных затрат на обновление статистики. Если же нам необходимо построить максимально достоверную статистику путем перебора всех записей в таблице, необходимо выбрать опцию WITH FULLSCAN.
Показ плана выполнения запроса возможен в трех режимах: сокращенном текстовом, полном текстовом и графическом. Графический план представляет каждый шаг выполнения иконкой со всплывающей подробной информацией об аргументах, количестве возвращаемых записей и т.д. Условная стоимость показывается в процентах, а именно, какую долю составляет каждый шаг от общей стоимости запроса. Если в батч входят несколько запросов, то процентные доли условной стоимости показываются для каждого запроса, позволяя быстро определять узкие места в коде. Ранее мы уже упоминали Index Tuning Wizard, позволяющий быстро оптимизировать объекты Вашей базы под эталонную нагрузку (workload), заданную либо в виде журнала SQL Server Trace, либо в виде SQL-кода. Более быструю, но менее комплексную оценку оптимального индекса, в частности, для одного конкретного запроса, дает Index Analyzer в составе SQL Query Analyzer.
Даже простое перечисление новых хранимых процедур, функций, типов данных и операторов заняло бы у нас слишком продолжительное время, поскольку практически каждая новая черта из тех, что мы перечислили или коснемся ниже, имеет свое отражение в Transact-SQL. Поэтому за полным перечнем изменений читатель может обратиться к документации, мы же кратко обрисуем основные группы новых возможностей и некоторые наиболее яркие изменения в каждой.
О новых хранимых процедурах и других усовершенствованиях Transact-SQL читатель может узнать, обратившись к документации Microsoft SQL Server 7.0, например, Books On-Line, раздел "New Features in Microsoft Transact-SQL".
В SQL Server 7.0 включены следующие виды тиражирования: 1) слиянием (merge replication), 2) мгновенных снимков данных (snapshot replication), 3) транзакций (transactional replication), 4) транзакций с обновлением на подписчике (updating subscriber), 5) через DTC. Здесь они перечислены в порядке возрастания транзакционной целостности и, соответственно, уменьшения степени автономности хостов. DTC (Distributed Transaction Coordinator), очевидно, известен читателям, которые могли с ним познакомиться в составе SQL Server 6.5 или Microsoft Transaction Server. Он работает по протоколу двухфазной фиксации OLE 2PC и обеспечивает максимальную целостность данных при условии постоянной доступности членов транзакции. Передача мгновенных снимков данных и транзакций являются разновидностями тиражирования по принципу "издатель-подписчик", широко использовавшемуся в предыдущих версиях SQL Server. В версии 7.0 мы имеем дело с двумя существенно новыми видами тиражирования, которые рассмотрим чуть более подробно.
Этот вид тиражирования можно рассматривать как модификацию транзакционного тиражирования по принципу "издатель-подписчик", при которой подписчик, как следует из названия, получает возможность обновлять оттиражированные на него данные, при этом обновления, сделанные на подписчике, отражаются на издателе. Неверно называть этот вид "multimaster update", так как несмотря на обновляющие права подписчика, у данных все равно остается один владелец - издатель. Подписчик производит обновление с помощью 2PC-транзакции, членами которой являются он и издатель. Издатель, в свою очередь, распространяет эти изменения остальным подписчикам. Этот процесс удобно представлять себе как 2PC-струйку (trickle) с подписчика на издатель и последующий каскад (cascade) на остальных подписчиков. Так как 2PC-транзакция происходит практически мгновенно, а публикация изменений через дистрибутора допускает временную задержку, то подписчик может попытаться изменить данные, которые были изменены другим подписчиком или непосредственно на издателе, но эти изменения до данного подписчика еще не дошли. В этом случае издатель как владелец данных обнаруживает конфликтную ситуацию и откатывает транзакцию.Обнаружение конфликтов производится с помощью поля timestamp. Если в таблице его не существовало, оно будет автоматически добавлено в момент определения публикации.
Тиражирование слиянием отличается максимальной автономностью издателя и подписчиков. Каждый из них имеет право вносить изменения в публикуемые данные независимо от других. Время от времени, измененные данные рассылаются всем остальным участникам публикации. При этом не имеет значения транзакционная история изменений, интерес представляет лишь суммарный накопленный эффект. Данные идентифицируются уникально при помощи поля типа ROWGUID. При получении изменений каждый сайт сравнивает значение generation (версии данных) между прибывшими и отосланными значениями. Разрешение конфликтов производится в соответствии со временем изменений и приоритетами узлов, которые разрешено изменять. Для разрешения конфликтов в случае сложных алгоритмов согласования имеется возможность запрограммировать свой собственный метод при помощи предоставленных ActiveX-интерфейсов.
Подписчиками SQL Server 7.0 могут выступать ранние версии Microsoft SQL Server, Oracle, IBM DB2 (MVS, AS/400) и другие средства управления данными, доступные через ODBC или OLE DB. В состав SQL Server 7.0 входят ActiveX-элементы управления SQL Distribution Control и SQL Merge Control, которые позволяют управлять тиражированием непосредственно из приложений на Visual Basic, Visual C++, Visual J++ и других средств разработки. Публикации и статьи можно создавать непосредственно в том же приложении при помощи SQL-DMO, либо подготовить заранее в SQL Server Enterprise Manager. Примеры использования упомянутых элементов управления устанавливаются вместе с SQL Server 7.0.
Гетерогенные источники могут участвовать в тиражировании не только в роли подписчиков, но и как издатели. Вообще, любое приложение, отвечающее интерфейсу Replication Distributor Interface может выступать в качестве издателя для SQL Server 7.0. Этот СОМ-интерфейс, использующий модель OLE DB-соединения, описан в документации на SQL Server. Пользовательское приложение-издатель, написанное на C/С++ и реализующее этот интерфейс, может выступать в роли шлюза между внешним источником и SQL Server 7.0.
Поддерживается тиражирование через Интернет. ODBC-соединение с подписчиком при этом осуществляется по TCP/IP или Multiprotocol. Домашняя директория FTP должна быть установлена в рабочий каталог репликации. Допускаются анонимные подписчики.
В SQL Server 7.0 "родным" интерфейсом доступа, т.е. тем, при помощи которого процессор запросов взаимодействует с механизмом хранения, является OLE DB. DB-Library поддерживается путем эмуляции через OLE DB. При разработке приложений, работающих с SQL Server 7.0 могут использоваться следующие основные методы.
Кроме этого, SQL Server 7.0 предоставляет дополнительные интерфейсы, которые в той или иной мере опираются на вышеперечисленные (в основном, OLE DB и ODBC) и которые можно рассматривать как своеобразные заготовки для решения задач более узкого назначения.
Напомним, что в состав Visual Studio входит отладчик для хранимых процедур SQL Server.
Архитектура безопасности SQL Server 7.0 гораздо лучше, чем в предыдущих версиях, интегрирована с моделью Windows NT и обеспечивает повышенную гибкость. Права в базе данных могут быть назначены непосредственно пользователям и группам Windows NT. Роли SQL Server могут включать не только пользователей и группы Windows NT, но и роли и пользователей SQL Server. Пользователь SQL Server может быть членом нескольких ролей. Это позволяет администратору баз данных управлять правами на объекты SQL Server как для групп Windows NT, так и для ролей SQL Server, а не на уровне индивидуальных учетных записей пользователей. Включены предустановленные роли на уровне базы данных и сервера, такие как dbcreator, db_owner, securityadmin и др. Это дает возможность гибче распоряжаться полномочиями и надежнее разграничивать права доступа, чем использование логина системного администратора.
В SQL Server 7.0 поддерживаются также прикладные роли, которые используются, например, когда доступ некоторого пользователя к данным необходимо ограничить рамками данного конкретного приложения. Другие способы доступа к серверу, включая, например, SQL Server Query Analyzer, будут для него невозможны. Прикладные роли не имеют членов. Они являются неактивными по умолчанию и активизируются приложением, устанавливающим соединение с сервером баз данных. В момент активизации соединение утрачивает какие-либо другие ассоциированные с ним права, и до момента закрытия будет иметь права, назначенные прикладной роли.
При попытке установить соединение с SQL Server сначала происходит аутентификация пользователя. Этот процесс может выполняться средствами Windows NT или SQL Server. Стандартного режима безопасности в смысле версии 6.5 больше не существует - остались только интегрированный и смешанный. К командам назначения и отзыва полномочий GRANT и REVOKE теперь добавилась еще одна - DENY. Она назначает негативные полномочия, явно указывая, что пользователь не имеет права выполнять указанные действия (эффект, эквивалентный двойному REVOKE при наличии гранта в версии 6.5). Команда REVOKE удаляет ранее установленные полномочия, независимо от их разрешительного или запрещающего характера.
Известны три модели представления хранилищ:
Microsoft OLAP Services for SQL Server (известные также под кодовым названием проекта Plato) поддерживают все три из вышеназванных способов построения хранилищ.
В OLAP Services реализован алгоритм определения оптимального множества агрегатов, от которого могут быть вычислены другие агрегаты. Этот алгортим включен в состав Storage Design wizard, который оптимизирует соотношение между производительностью системы и дисковым пространством, занятым под агрегаты, в зависимости от того, сколькими мегабайтами Вы готовы пожертвовать, либо какой процент от максимально возможной производительности Вас устраивает. Существуют варианты более тонкой настройки множества агрегатов в соответствии с реальной нагрузкой на систему. Например, Usage-Based Optimization wizard строит структуру агрегатов так, чтобы минимизировать время ответа на наиболее часто поступающие запросы. В сочетании с эффективными алгоритмами сжатия, а также тем фактом, что Plato, по определению, не хранит пустые ячейки куба, оптимизация структуры множества предвычисленных агрегатов сводит практически на нет влияние синдрома "взрывного роста данных", характерного для большинства OLAP-технологий.
Для наполнения кубов могут браться данные из любого OLE DB-источника. Очистка и унификация перед погружением может производиться с помощью служб преобразования данных (DTS). Элементарной единицей службы преобразования выступает пакет. Пакет может состоять из одного или нескольких элементарных шагов. В качестве шага (так же, как и для SQL Server Agent) может выступать SQL-скрипт, исполняемый модуль, ActiveX-скрипт и т.д. Логика выполнения шагов также может ветвиться в зависимости от результатов предыдущих шагов. Пакеты хранятся на SQL Server или в Microsoft Repository. После пополнения новыми данными куб может быть переобработан полностью или произведен дифференциальный пересчет, при котором обрабатываются только последние добавленные данные.
Допускаются вычисляемые меры и члены измерений. В качестве формул могут выступать MDX-запросы (MDX - многомерное расширение к SQL), математические формулы, пользовательские функции (UDF) и т.д. Каждый член измерения может иметь дополнительные свойства. Например, артикул товара может иметь соответствующие значения размера, цвета, фактуры и т.д. Общее измерение, произведенное по одному из таких свойств, носит название виртуального измерения.
Куб можно разбить на несколько отдельных физических частей. Каждая такая часть, именуемая разбиением (partition) может иметь любой из перечисленных режимов организации, храниться на самостоятельном физическом носителе и иметь свою структуру агрегатов. С помощью разбиений куб может быть распределен по нескольким OLAP-серверам, что значительно ускоряет обработку запросов к объемным хранилищам высокой размерности. Наоборот, разбиения можно сливать друг с другом. Например, поквартальные разбиения могут быть объединены в один годовой куб. Виртуальные кубы есть аналог view union над кубами. Если в одном кубе мы храним информацию по проведенным маркетинговым мероприятиям, а в другом - данные о продажах и хотим оценить влияние первых на вторые, создание виртуального куба позволит это сделать, не забирая дополнительного дискового пространства.
Как и сервера баз данных, OLAP Services использует серверный кэш, где хранятся недавно или наиболее часто используемые пользовательские запросы, метаданные и данные. Кроме этого, клиентские приложения имеют возможность организовать кэш на стороне клиента. Эта идея представляется вполне рациональной, в особенности если учесть, что, как правило, клиентские рабочие станции в системах поддержки принятия решений - довольно мощные по производительности и ресурсам, а большая часть запросов в приложениях повторяется. Компонент PivotTable(r) Service позволяет использовать находящиеся в клиентском кэше данные для ответов на запросы, которые в этом случае не будут пересланы на сервер. Например, поступает запрос на общую сумму продаж за год, а в клиентском кэше уже хранятся аналогичные данные по четырем кварталам. PivotTable Service обладает многими из возможностей OLAP-сервера, что дает возможность эффективно распределить нагрузку между клиентом и сервером и минимизировать сетевой траффик.
Поддерживается возможность записи в куб (write-back) и запросов типа "что-если". Инициированные пользователями изменения записываются в отдельную таблицу, ассоциированную с кубом, и применяются всякий раз при чтении данных, так что пользователь видит их так, как если бы они в самом деле изменились. Администратор имеет право аннулировать изменения.
Как и в SQL Server 7.0 безопасность в OLAP Services построена на использовании ролей, в которые могут быть добавлены реальные группы и пользователи Windows NT.
Администрирование OLAP Services осуществляется через OLAP Manager, который, как и SQL Server Enterprise Manager, представляет собой snap-in в ММС.
Средства программирования и интерфейсы доступа проще всего пояснить на примере аналогий с SQL Server 7.0. Аналогом Transact-SQL выступает, как мы уже заметили, MDX. OLE DB 2.0 включает в себя набор многомерных расширений OLE DB for OLAP. Соответственно, то же, но в виде дуальных интерфейсов, называется ADO MD. Аналогом SQL-DMO служат DSO (Decision Support Objects). Наконец, расширить список встроенных функций можно, создавая и регистрируя пользовательские библиотеки функций с помощью VC++, VB и любых других Automation-языков программирования.
Алексей Шуленин, Microsoft, системный инженер, тел. 967-85-85.Материал данного раздела опирается на книгу "Inside Microsoft SQL Server 6.5", автор Ron Soukup, вышедшую в издательстве Microsoft Press в 1997 г. (см. The Evolution of Microsoft SQL Server: 1989 to 1996).
|
|