В десятилетней истории 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, мы построим исходя из не нуждающегося в доказательстве утверждения, что любой бизнес имеет дело с данными. Отсюда, логично предложить следующий порядок повествования.

Данные нужно обрабатывать => процессор запросов Microsoft SQL Server 7.0; изменения в языке Transact-SQL

По мере усложнения бизнеса данные оказываются в разных местах => распределенные операции в Microsoft SQL Server 7.0

С данными должны уметь работать различные бизнес-приложения => программные интерфейсы доступа к Microsoft SQL Server 7.0

Данные должны быть надежно защищены => модель безопасности Microsoft SQL Server 7.0

Данные нужно уметь превращать в информацию для принятия управленческих решений => Microsoft OLAP Services for SQL Server 7.0.

Излишне говорить, что немалую роль при использовании любого программного продукта играет простота его освоения и удобство использования, поскольку эти факторы не только способны выработать чисто психологическое расположение к продукту, но и имеют достаточно четкую вещественную оценку в размере расходов на подготовку администраторов и программистов, что позволяет существенно снизить стоимость владения продуктом (TCO). Именно с этого немаловажного аспекта мы приступим к нашему обзору.

Как правило, серверы баз данных, традиционно ассоциирующиеся с обслуживанием корпоративного звена, отличаются сложностью изучения и администрирования. Microsoft SQL Server содержит множество утилит, инструментов, программ-мастеров (wizards), всплывающих автоподсказок и других возможностей, которые позволяют значительно упростить весь цикл работы с сервером, включая его установку, внедрение, управление и использование. SQL Server обеспечивает администраторов полным набором средств тонкой самонастройки для достижения лучшей производительности на имеющихся промышленных приложениях реального времени. Он также способен эффективно работать на автономных однопользовательских настольных системах, предполагая минимум административного вмешательства.

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

SQL Server предлагает администраторам баз данных следующие графические инструменты управления:

SQL Server Enterprise Manager как snap-in компонент централизованной консоли управления Microsoft Management Console (MMC) поддерживает администрирование серверов различных типов (Microsoft SQL Server, Microsoft Transaction Server, Microsoft Message Queue Server, Microsoft Internet Information Server, Microsoft SNA Server и т.д.) Из единой консоли администратор имеет возможность управлять всеми серверами в глобальной сети предприятия. SQL Server Enterprise Manager представляет все объекты SQL Server в виде иерархического дерева компонентов. Как подмножество пользовательского Web-интерфейса MMC он облегчает задачи удаленного администрирования SQL Server"ами, например, через Интернет. SQL Server Enterprise Manager служит главным инструментом администрирования SQL Server. Он позволяет регистрировать индивидуальные сервера и группы серверов, конфигурировать все серверные настройки, создавать и администрировать все базы данных, их объекты (таблицы, представления, процедуры, триггеры, ограничения, логины, пользователи, права и т.д.), определять и выполнять административные задачи на каждом зарегистрированном сервере, вызывать различные программы-мастера (wizards) и т.д.

SQL Server Agent используется для автоматизации часто повторяющихся задач или обработки исключительных ситуаций. Он позволяет запрограммировать выполнение задачи во времени в определенные моменты (на основе расписаний), а также предусмотреть выполнение задачи как реакцию на возникновение какого-то события (alert) без непосредственного участия администратора. Например, если мы имеем журнал транзакций фиксированного размера, он может, очевидно, переполняться. В этом случае мы можем с помощью SQL Server Agent послать оповещение администратору по электронной почте или пэйджинговой связи, а также инициировать очистку журнала с резервным копированием. Традиционно с помощью SQL Server Agent организуется процесс тиражирования. В отличие от SQL Executive в предыдущих версиях каждое задание может состоять из нескольких шагов (пакет операций на T-SQL, ActiveX Script, exe-модуль и т.д.), причем последовательность их выполнения может меняться в зависимости от результатов выполнения предыдущего шага. Задание может состоять из компонент, находящихся на разных серверах, позволяя таким образом автоматизировать процесс мультисерверного администрирования. В этом случае среди нескольких серверов один выбирается главным, он получает уведомления от агентов SQL Server на других серверах и управляет ходом выполнения распределенного задания. Им можно пользоваться интерактивно, а также запрограммировав его действия с помощью объявленных интерфейсов.

SQL Server Profiler представляет собой программу-перехватчик событий, генерируемых SQL Server. За счет изменений в архитектуре круг этих событий значительно расширился по сравнению с SQL Trace в предыдущих версиях. Есть возможность изменять вид представления данных, характеризующих каждое событие (какие события, какие данные по каждому из событий, порядок следования колонок в данных, группировка, установка фильтров для отлавливания событий только с интересующими параметрами и т.д.), при выводе на экран или записи в файл. Этот файл затем можно "проиграть" на другом сервере, например, резервном, чтобы в спокойной обстановке проанализировать поведение Вашего рабочего сервера. Файл с записью событий можно использовать также как эталонную нагрузку, которая подается на вход Index Tuning Wizard и в соответствии с которой последний настраивает индексы и другие объекты БД для достижения на ней максимальной производительности. SQL Server Profiler можно использовать для отслеживания активности, происходящей на SQL Server в разрезе по приложениям, пользователям и т.д., отладки хранимых процедур, отлавливания худших по производительности запросов, идентификации причин deadlock"ов и других полезных вещей.

SQL Server Performance Monitor предназначен для отслеживания динамики изменений параметров SQL Server в форме обычного Windows NT Performance Monitor: в виде графика, или отчета, записи в журнал или возникновения ситуации alert, когда измеряемый показатель становится больше / меньше заранее заданной величины. Alert может отлавливаться (см. выше - SQL Server Agent) и в ответ на него SQL Server может выполнять то или иное задание. SQL Server определяет 16 относящихся к нему объектов мониторинга SQL Server Performance Monitor, состоящих из группы параметров (counters). Например, объект SQL Server: Databases включает в себя параметры Active Transactions, Transactions/sec, Percent Log Used, Data File(s) Size и т.д., каждый из которых имеет количество экземпляров по числу имеющихся на сервере баз. Существует возможность создания пользовательских объектов. Из одного SQL Server Performance Monitor можно контролировать несколько серверов при наличии соответствующих прав. Записанная в журнал серверная активность может быть экспортирована в таблицу, например, Excel. 1.3 Wizards

Программы-мастера позволяют решать сложные задачи администрирования, проводя пользователя через последовательность экранных форм, на каждой из которых от него требуется выполнить какое-нибудь элементарное действие, например, ответить на заданный вопрос "да" или "нет". Программы-мастера существовали и в предыдущих версиях 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. Поэтому за полным перечнем изменений читатель может обратиться к документации, мы же кратко обрисуем основные группы новых возможностей и некоторые наиболее яркие изменения в каждой.

В переменных и полях поддерживается формат Unicode. Добавились типы nchar, nvarchar и ntext. Максимальная длина ntext составляет 230 - 1 (для типов text/image - 231 - 1). Локальные переменные типов text/ntext объявлять по-прежнему нельзя, но в процедурах можно использовать параметры этих типов. Символ N, поставленный перед строкой, например, N"строка", обозначает Unicode.

Появился тип cursor. Можно объявлять переменные этого типа и использовать его для выходных параметров процедур. По отношению к переменным можно использовать обычные курсорные операторы (OPEN, FETCH, CLOSE, ... ) и функции (sp_cursor_list, sp_describe_cursor, ...). Поля типа cursor объявлять нельзя.

Появился тип uniqueidentifier. Этот тип могут иметь и переменные, и параметры, и поля. Он соответствует тому, что в СОМ называется GUID, т.е. величина, с большой долей вероятности уникальная во Вселенной. Сгенерировать новое значение можно с помощью функции NewID(). Переменные этого типа можно также инициализировать, проконвертировав строчное 20-байтное 16-ричное представление, например, "47346-111-1111111-27201". 4.2 Функции

Функции, возвращающие информацию о метаданных: DATABASEPROPERTY(), FILEPROPERTY(), OBJECTPROPERTY(), COLUMNPROPERTY(), INDEXPROPERTY(), ... Функции по работе с датами: DAY(), MONTH(), YEAR(). Кроме того, арифметические операнды + / - применимы при работе с датами.

Функции по работе с текстом: REPLACE(), NCHAR(), UNICODE(). Функция SUBSTRING() применима для полей text/ntext. Функция QUOTENAME() автоматически расставляет скобки, кавычки и иные разделительные символы, возвращая должным образом оформленный SQL-идентификатор, что особенно удобно, когда сама оригинальная строка также содержит разделители.

Функции по работе с полнотекстовым поиском: CONTAINSTABLE(), FREETEXTTABLE(), FULLTEXTCATALOGPROPERTY(), ...

Статистические функции STDEV(), STDEVP(), VAR(), VARP().

Функции, обслуживающие задачи безопасности: IS_MEMBER(), IS_SRVROLEMEMBER(), SUSER_SID(), SUSER_SNAME(), ...

Функции по работе с гетерогенными запросами: OPENROWSET(), OPENQUERY(). Функции по работе с курсорами - CURSOR_STATUS(). Служебные функции. @@LOCK_TIMEOUT - возвращает время (в миллисекундах), в течение которого сессия ждет освобождения данных, заблокированных другой транзакцией; TRIGGER_NESTLEVEL() - определяет текущий уровень вложенности триггеров и т.д. 4.3 Операторы

В оператор ALTER DATABASE добавлены возможности добавления, модификации и удаления файлов и файловых групп. Добавлены операторы ALTER PROCEDURE, ALTER TRIGGER и ALTER VIEW.

Появилась возможность отключения ограничений в таблице (см. CHECK | NOCHECK CONSTRAINTS в ALTER TABLE), что позволяет реализовать ссылочную целостность в триггерах, временно отключая FOREIGN KEY.

CREATE CURSOR - появилась возможность создания локальных курсоров, видимых только в пределах той процедуры (триггера, батча), где они были созданы.

Добавлена опция DROP COLUMN в операторе ALTER TABLE. Также появилась возможность создавать вычисляемые поля.

CREATE STATISTICS строит статистику распределения по заданным полям (без необходимости создания индекса).

CREATE TRIGGER позволяет создавать множественные триггеры на одну таблицу. Например, некая таблица может иметь два триггера на INSERT, три на UPDATE и один на DELETE для более четкого разделения логики в триггерах. Триггеры могут вызываться рекурсивно.

DBCC SHRINKFILE, DBCC SHRINKDATABASE ликвидируют пустоты, сокращая размер как отдельного файла в составе базы, так и всей базы данных целиком.

Операторы DML, естественно, обогатились новыми опциями, связанными с принудительным указанием типа связи (join hints), режима блокировки и т.д. В оператор SELECT был добавлен предикат TOP [PERCENT] [WITH TIES]. В отличие от установки SET ROWCOUNT в предыдущих, этот предикат непосредственно встраивается в план выполнения, так как интуитивно понятно, что оптимальный план для запроса, выбирающего все записи из большой таблицы, и для запроса, выбирающего первые 10 записей, будут в общем случае отличаться. WITH TIES, как следует из названия, довыводит хвосты. Т.е. в нашем примере WITH TIES выведет еще несколько оставшихся (если есть) записей, у которых значение выражения в ORDER BY такое же, как у 10-й записи, на которой обрывал выдачу простой TOP.

О новых хранимых процедурах и других усовершенствованиях 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 могут использоваться следующие основные методы.

OLE DB - стратегический набор интерфейсов доступа к данным, описывающих основные функции по хранению, обработке и возвращению данных в соответствии с моделью СОМ. Рекомендуется для решения низкоуровневых задач и достижения максимальной производительности. OLE DB-провайдер SQL Server 7.0 напрямую взаимодействует с протоколом TDS.

ADO (ActiveX Data Objects) - инкапсулирует основную функциональность OLE DB в виде довольно тонкой IDispatch-обертки для того, чтобы Automation-средства разработки могли использовать OLE DB.

ODBC - стандартный API (набор функций) доступа к реляционным данным. SQL Server 7.0 поставляется с новой версией собственного производительного 32-разрядного ODBC-драйвера. К разновидностям, инкапсулирующим ODBC, относятся RDO (Remote Data Objects) - надстройка для придания более дружественного интерфейса, и DAO (Data Access Objects) - еще более толстая надстройка, включающая даже собственный реляционный механизм (Jet).

Embedded SQL for C - прекомпилятор, преобразующий SQL-подобные команды в тексте программы на С в соответствующие вызовы DB-Library.

DB-Library - унаследованный API доступа к SQL Server из С и Visual Basic. В версии 7.0 поддерживается по соображениям совместимости с ранее созданными пользовательскими приложениями, но развиваться, по-видимому, уже не будет.

Кроме этого, SQL Server 7.0 предоставляет дополнительные интерфейсы, которые в той или иной мере опираются на вышеперечисленные (в основном, OLE DB и ODBC) и которые можно рассматривать как своеобразные заготовки для решения задач более узкого назначения.

SQL-DMO (Distributed Management Objects) - набор Automation-объектов, описывающих административную модель SQL Server 7.0. Идеальный инструмент для выполнения программным путем действий, которые вы обычно производите интерактивно в SQL Server Enterprise Manager.

SQL-NS (NameSpace) - объектная модель для написания программ, обращающихся к компонентам интерфейса SQL Server Enterprise Manager. Может быть использована из Visual С++, Visual Basic и т.п.

Элементы управления и интерфейсы репликации. Мы упоминали их в главе, посвященной распределенным операциям.

Программные интерфейсы cлужбы преобразования данных (DTS). DTS используется для очистки и унификации данных перед тем, как поместить их в хранилище, но может быть применена просто для преобразования при их перекачке из одного OLE DB-источника в другой.

Объекты Microsoft Search и Microsoft Repository имеют достаточно самостоятельное значение, могут применяться в отрыве от SQL Server и потому здесь рассматриваться не будут.

Напомним, что в состав 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 удаляет ранее установленные полномочия, независимо от их разрешительного или запрещающего характера.

Известны три модели представления хранилищ:

ROLAP (relational OLAP) - первичные данные и агрегаты хранятся в реляционной СУБД. Такой подход обеспечивает сохранение инвестиций в реляционные технологии, но оставляет желать лучшего по производительности.

MOLAP (multidimensional OLAP) - первичные данные и агрегаты хранятся в виде истинно многомерной структуры. Этот подход обеспечивает улучшенную производительность и сжатие данных.

HOLAP (hybrid OLAP) - первичные данные для куба продолжают оставаться в реляционном хранилище, в то время как агрегаты вычисляются в высокопроизводительный многомерный куб. Подобный подход сохраняет преимущества MOLAP-подхода в плане использования промежуточных агрегатов, но не требует неизбежного при этом перекачивания детальных данных в куб.

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-языков программирования.

Материал данного раздела опирается на книгу "Inside Microsoft SQL Server 6.5", автор Ron Soukup, вышедшую в издательстве Microsoft Press в 1997 г. (см. The Evolution of Microsoft SQL Server: 1989 to 1996).

27 марта 1987 г. президент Microsoft Джон Ширли и сооснователь и президент Sybase Марк Хоффман подписывают договор, по которому Microsoft получает эксклюзивные права на продажи продукта под названием DataServer производства Sybase для OS/2 и других разрабатываемых Microsoft операционных систем. Sybase получает возможность расширить сферы своего влияния с UNIX и VMS на настольные платформы.

В 1988 г. Microsoft заключает соглашение с Ashton-Tate, производителем dBase, в то время бесспорным лидером на рынке СУБД для персональных компьютеров, о совместной маркетинговой поддержке портации Sybase DataServer на OS/2. Ashton-Tate обязуется разработать dBase IV Server Edition - клиентскую часть будущего сервера баз данных.

Конец 1988 г. Выходит бета-версия продукта Ashton-Tate/Microsoft SQL Server. Она поставляется под названием NDK (Network Development Kit).

Май 1989 г. Выход Ashton-Tate/Microsoft SQL Server 1.0. Успех носит довольно сдержанный по двум причинам - пользователи не спешат мигрировать с MS-DOS на OS/2 и единственным средством разработки остается С. Клиентская часть от Ashton-Tate так и не увидела свет. Соглашение между Microsoft и Ashton-Tate прекращает свою работу.

Лето 1990 г. Выход Microsoft SQL Server 1.1. Помимо мелких усовершенствований, сделан исключительно удачный ход - в качестве клиентской платформы поддерживается Microsoft Windows 3.0, выпущенная в мае того же года. Значение этого шага было настолько велико, что вначале его практически никто не оценил. Microsoft продолжает рассматривать SQL Server всего лишь как один из способов продвижения LAN Manager и OS/2.

Начало 1991 г. Microsoft подписывает дополнительное соглашение с Sybase, по которому получает read-only права на исходные коды SQL Server.

Тогда же. Резко возрастает количество независимых производителей программного обеспечения, пишущих под SQL Server 1.1, а следовательно, и предложение разнообразных приложений, утилит и инструментов для него же. Продажи начинают повышаться. Microsoft признает неудачной проделанную Sybase портацию DB-Library с UNIX на MS-DOS (после загрузки редиректора, драйвера сетевой карты и DB-Library пользователю остается 50 К памяти) и пишет практически с нуля свою версию, в 5 раз менее требовательную к памяти.

Май 1991 г. Microsoft и IBM объявляют о прекращении совместной разработки OS/2.

Середина 1991 г. Microsoft получает от Sybase разрешение непосредственно исправлять ошибки в коде SQL Server. Sybase оставляет за собой право одобрить или отвергнуть эти исправления, а также контроль общего направления развития кода.

Тогда же. Выход Microsoft SQL Server 1.11. Рост продаж сменяется застоем. Продукт позиционируется для рабочих групп из 50 и менее пользователей, что, в принципе, устраивает конкурентов, но никоим образом не удовлетворяет Microsoft. Лучшей масштабируемости не удается достичь в силу внутренних архитектурных ограничений OS/2 1.0 (16-разрядность, отсутствие асинхронного ввода/вывода, ...). Принимается решение о разработке новой версии для 32-разрядной OS/2 2.0 производства IBM.

Март 1992 г. Завершение совместных работ Microsoft и Sybase по переносу UNIX-версии SQL Server 4.2 на OS/2. Как результат - выход 16-разрядной версии SQL Server 4.2 для OS/2 1.3 (Tiger). Специалистами Microsoft дописаны клиентские библиотеки для MS-DOS, Windows и OS/2 и графический инструмент администрирования. В версию 4.2 включены возможности создания серверных хранимых процедур, онлайновый ленточный backup, улучшенная языковая поддержка, оператор UNION и т.д.

Середина 1992 г. Выход OS/2 2.0 от IBM задерживается. Тем временем в Microsoft полным ходом идут работы над созданием собственной принципиально новой 32-разрядной операционной системы, первоначально, OS/2 3.0, которая на стадии разработки получает имя NT.

Тогда же. В результате заключенного с Sybase соглашения, Microsoft обретает право переноса версии 4.2 на Windows NT. Sybase включает Windows NT в число операционных систем для System 10.

Конец 1992 г. Принято решение о прекращении дальнейших разработок SQL Server под OS/2. Windows NT становится стратегической платформой для SQL Server.

Июль 1993 г. Выпуск Microsoft Windows NT 3.1. Через 30 дней выходит первая 32-разрядная версия Microsoft SQL Server для Windows NT. Это была не просто портация OS/2-версии 4.2 на новую операционную систему. Ядро SQL Server в значительной степени переписано на Win32 API для повышения производительности.

Сентябрь 1993 г. Большинство рекордных результатов по производительности принадлежат системам на UNIX и не превосходят 100 транзакций в секунду. Compaq публикует результаты официальных TPC-B тестов. На машине с двумя процессорами Pentium 66 Microsoft SQL Server показывает рекорд в 226 транзакций в секунду. Удельная стоимость за транзакцию в секунду составляет при этом 440 долл.- показатель, существенно ниже удельной стоимости производительности для систем на миникомпьютерах и мэйнфреймах.

Конец 1993 г. Закончена миграция пользовательской базы с OS/2 на Windows NT. Sybase публикует анонс о разработке System 10 для OS/2. Обостряется конкуренция между Sybase и Microsoft, сегменты рынка которых по серверам баз данных все больше сближаются.

12 апреля 1994 г. Microsoft и Sybase прекращают совместную работу над SQL Server. Microsoft получает право самостоятельно перерабатывать и развивать SQL Server.

14 июня 1994 г. Microsoft объявляет о планах post-Sybase развития SQL Server (SQL95).

Октябрь 1994 г. Выпуск первой бета-версии Microsoft SQL Server 6.0. Добавлены возможности тиражирования, скроллируемые курсоры, SQL Enterprise Manager (Starfighter) и др.

14 июня 1995 г. Запуск в производство Microsoft SQL Server 6.0. Доля Microsoft на рынке серверов баз данных изменилась с 15 до 18%.

Декабрь 1995 г. Выпуск первой бета-версии Microsoft SQL Server 6.5. Включены дополнительные утилиты администрирования (SQL Trace), публикации данных на Web-сервере (SQL Web Assistant), тиражирования ODBC-подписчикам, восстановления данных на определенный момент времени, поддержка сервера горячего резерва, MS DTC, хранимые процедуры OLE Automation, дополнения в Transact-SQL (insert ... exec, cube / rollup) и др.

Апрель 1996 г. Запуск Microsoft SQL Server 6.5 в производство.

Декабрь 1996 г. Выход Microsoft Transaction Server 1.0 (Viper), сочетающего функциональность монитора транзакций и брокера объектных запросов.

Май 1997г. Microsoft демонстрирует работу виртуальной банковской системы, «клиентами» которой выступает четверть населения земного шара. Входе эксперимента показан результат - миллиард транзакций в день. При построении системы использовались 20 серверов Microsoft SQL Server 6.5 и 5 серверов Microsoft Transaction Server.

Июнь 1997 г. Выход первой бета-версии Microsoft SQL Server 7.0 (Sphinx).

Октябрь 1997 г. Выход сервера очередей сообщений Microsoft Message Queue Server 1.0 (Falcon) и вскоре после этого - Microsoft Transaction Server 2.0 (Sherpa).

Декабрь 1997 г. Выход Microsoft SQL Server 6.5 Enterprise Edition. Среди добавленной функциональности - поддержка двухузловых отказоустойчивых кластеров Microsoft Cluster Server (Wolfpack), в том числе в режиме active-active, 8 процессоров, 3GB адресного пространства, Microsoft English Query и т.д.

Тогда же. Выход второй бета-версии Microsoft SQL Server 7.0.

Июнь 1998 г. Выход третьей бета-версии Microsoft SQL Server 7.0.

16 Ноября 1998 г. представлен Microsoft SQL Server 7.0.

18 Ноября 1998 г. Microsoft SQL Server 7.0 признан лучшим продуктом, представленным на выставке COMDEX/Fall"98 (Best of Show), и лучшим в категории бизнесс-приложений (Best Productivity Software).