Как работает SQL Database (SQL Azure)?

Содержание Обзор архитектуры SQL Database ............................................................................................................... 2

Сетевая топология ................................................................................................................................... 3

Уровень служб ......................................................................................................................................... 5

Уровень платформы ................................................................................................................................ 6

Обеспечение высокой доступности в SQL Database ................................................................................. 8

Обнаружение сбоев ................................................................................................................................ 8

Реконфигурация ....................................................................................................................................... 8

Отказ основной реплики ..................................................................................................................... 9

Отказ дополнительной реплики ......................................................................................................... 9

Обеспечение масштабируемости в SQL Database .................................................................................. 10

Регулирование производительности ................................................................................................... 10

Балансировка нагрузки ......................................................................................................................... 11

Федерация базы данных ....................................................................................................................... 11

Безопасность .............................................................................................................................................. 12

Рекомендации для разработчиков в среде SQL Database ...................................................................... 12

Подключение и отключение ................................................................................................................. 12

Требование наличия кластерного индекса ......................................................................................... 13

Управление транзакциями ................................................................................................................... 13

Устранение неполадок .......................................................................................................................... 14

Итого ........................................................................................................................................................... 14

Windows Azure предлагает как NoSQL хранилища, так и SQL-реляционные хранилища. NoSQL

хранилища – это, например, Windows Azure Tables (ключ\значение) или BLOB-объекты (двоичные

данные такие, как фото, видео, документы и т.п.). К реляционным хранилищам относится SQL

Database (ранее SQL Azure).

Обзор архитектуры SQL Database SQL Database – это разделяемая облачная база данных, можно сказать, что это Database as Service

(DaaS). В ЦОДах Microsoft установлены серверы SQL Server большой емкости, построенные на

основе стандартного оборудования. Каждый SQL Server в ЦОДе содержит несколько различных

клиентских баз данных (логические базы), т.е. получается shared режим. Для доступа к данным

используется автоматическая балансировка нагрузки и маршрутизация сетевых соединений.

Стоит отметить, что физически или фактически данные сохраняются не в одной базе, а

реплицируются. Данные реплицируются в трех базах данных SQL Server, распределенных по трем

физическим серверам одного ЦОДа: одна основная и две дополнительные реплики. Все операции

чтения и записи выполняются в основной реплике, а любые изменения асинхронно

реплицируются на дополнительные реплики. Эти реплики обеспечивают высокую доступность баз

данных SQL Database. Большинство ЦОДов Microsoft содержат сотни компьютеров с сотнями

экземпляров SQL Server, на которых размещены реплики SQL Database. Крайне низка вероятность

того, что основные и дополнительные реплики баз данных SQL Database будут хранится на одних и

тех же компьютерах.

Логический сервер – это SQL Database сервер, который вы видите на веб-портале управления

Windows Azure. Служба шлюза SQL Database Gateway выполняет функции прокси-сервера,

перенаправляя на логический сервер запросы потока табличных данных (Tabular Data Stream, TDS).

SQL Database Gateway является границей системы безопасности и обеспечивает проверку учетных

данных, соблюдение правил брандмауэра и защиту расположенных за шлюзом экземпляров SQL

Server против атак типа «отказ в обслуживании». Шлюз состоит из множества компьютеров,

каждый из которых принимает запросы на сетевые подключения от клиентов, проверяет

информацию о соединении и передает запрос потока табличных данных соответствующему

физическому серверу, в зависимости от имени базы данных, указанного в соединении.

Физическое распределение баз данных, входящих в состав одного и того же логического

экземпляра SQL Server, означает, что каждое сетевое соединение привязано к одной базе данных,

а не к одному экземпляру SQL Server. Если бы для подключения использовалась команда USE,

поток табличных данных пришлось бы перенаправить на совершенно другой физический

компьютер в центре обработки данных. По этой причине команда USE не поддерживается для

соединений SQL Database.

Сетевая топология Приложение использует уровень клиента для прямого обмена данными с SQL Database. Уровень

клиента может располагаться в локальном центре обработке данных или размещаться в Windows

Azure. Поддерживаются все протоколы, создающие потоки табличных данных для передачи по

сети. Можно применять привычные инструменты и библиотеки для создания клиентских

приложений, использующих данные в облаке.

Уровень служб Уровень служб состоит из компьютеров, на которых размещены службы шлюзов, обеспечивающие

маршрутизацию, выделение ресурсов, измерение показателей и выставление счетов. Эти службы

поддерживаются четырьмя группами компьютеров.

Интерфейсный кластер содержит физические компьютеры шлюза. Компьютеры прикладного

уровня авторизуют запросы к серверу и к базе данных, а также управляют выставлением счетов.

Компьютеры служебной платформы осуществляют мониторинг работоспособности экземпляров

SQL Server в ЦОД и управляют ими. Компьютеры основного кластера отслеживают, какие реплики

каких именно баз данных физически существуют в каждом экземпляре SQL Server в ЦОД.

Пронумерованные линии рабочих процессов на рисунке отражают процедуру проверки и

создания клиентского соединения:

1. Шлюз в интерфейсном кластере, получивший запрос на новое входящее соединение для

передачи потока табличных данных (TDS), может установить соединение с клиентом.

Синтаксический анализатор с минимальным набором поддерживаемых функций

проверяет допустимость полученной команды для передачи базе данных. Команды типа

CREATE DATABASE недопустимы, так как должны обрабатываться прикладным уровнем.

2. Шлюз выполняет процедуру подтверждения SSL для клиента. Если клиент отказывается

использовать протокол SSL, шлюз разрывает соединение. Необходимо обеспечивать

полное шифрование трафика. Синтаксический анализатор протокола также содержит

средство защиты от атак типа «Отказ в обслуживании», отслеживающее запросы с IP-

адресов. Если с IP-адреса или диапазона адресов приходит чрезмерное количество

запросов, то последующие попытки соединения с этих адресов будут отклонены.

3. Указанные пользователем имя сервера и учетные данные для входа должны быть

проверены. Проверка на уровне брандмауэра обеспечивает соединение только с IP-

адресами из заданных диапазонов.

4. После проверки сервера основной кластер сопоставляет используемое клиентом имя базы

данных с внутренним именем базы данных. Основной кластер — это набор компьютеров,

обрабатывающих сведения о сопоставлении. При работе в SQL Database понятие раздел

имеет совершенно иной смысл, чем при работе с локальными экземплярами SQL Server. В

среде SQL Database раздел является частью базы данных SQL Server в ЦОД, которая

сопоставляется с одной базой данных SQL Database. Например, на рисунке каждая база

данных содержит три раздела, поскольку в каждой из них размещены по три базы данных

SQL Database.

5. После обнаружения базы данных выполняется проверка подлинности имени

пользователя; если проверка завершается ошибкой, соединение разрывается. Шлюз

проверяет наличие базы данных, к которой хочет подключиться пользователь.

6. Новое подключение может быть выполнено после проверки всех параметров соединения.

7. Новое соединение устанавливается непосредственно между компьютером пользователя и

внутренним серверным узлом.

8. После установления соединения шлюз выступает в качестве прокси-сервера для пакетов,

передаваемых между клиентом и платформой обработки данных.

Уровень платформы Уровень платформы состоит из компьютеров, на которых размещены физические базы данных

SQL Server в ЦОД. Эти компьютеры называются узлами данных. На рисунке изображена

внутренняя организация узлов данных. Каждый узел данных состоит из одного экземпляра

сервера SQL Server. Каждый из этих экземпляров имеет одну пользовательскую базу данных,

разбитую на разделы. Каждый раздел содержит одну клиентскую базу данных SQL Database,

представленную в виде основной или дополнительной реплики.

База данных SQL Server типового узла данных может содержать до 650 разделов. Эти базы данных,

размещенные в ЦОД, управляются так же, как локальные базы данных SQL Server. Разница лишь в

том, что регулярное техническое обслуживание и резервное копирование выполняются

специалистами центра обработки данных. Все базы данных, размещенные на узле данных,

используют один и тот же файл журнала. Это повышает производительность ведения журнала с

помощью последовательных групповых операций ввода-вывода. В отличие от локальных баз

данных, журналы баз данных SQL Database хранятся в предварительно выделенном и обнуленном

дисковом пространстве. Это позволяет избежать пауз записи при автоматическом увеличении

размера файлов журнала.

Еще одним отличием управления журналами в центре обработки данных SQL Database является

необходимость кворумной фиксации. Это означает, что основная реплика и как минимум одна из

дополнительных реплик должны подтвердить факт записи файлов журнала, прежде чем

транзакция будет считаться зафиксированной.

На рисунке показано, что каждый из компьютеров узла данных содержит набор процессов, также

называемых структурой. Процессы структуры служат для решения следующих задач:

Обнаружение сбоев: контроль доступности основных или дополнительных реплик; если они

становятся недоступными, может быть запущен агент реконфигурации.

Агент реконфигурации: управляет повторным созданием основных или дополнительных реплик

после сбоя узла.

1. Определение местоположения диспетчера разделов: обеспечивает отправку сообщений

для диспетчера разделов.

2. Регулирование нагрузки на ядро: препятствует монопольному использованию логическим

сервером ресурсов узла или превышению его физических ограничений.

3. Кольцевая топология: управляет объединенными в логическое кольцо компьютерами

кластера; каждый компьютер имеет двух соседей, способных обнаружить его аварийное

отключение.

Обеспечение высокой доступности в SQL Database Платформа Microsoft SQL Database обеспечивает доступность баз данных подписчиков на уровне

99,9%. Это достигается благодаря использованию потребительского оборудования, которое

допускает простую и быструю замену в случае отказа компьютера или накопителя, а также за счет

управления репликами каждой из баз данных SQL Database (поддерживаются одна основная и две

дополнительные реплики).

Обнаружение сбоев Необходимо выявлять не только случаи полного отказа компьютеров, но и тенденции медленного

снижения производительности компьютеров и нарушения обмена данными с ними. Изложенная

выше концепция кворумной фиксации позволяет решать эти проблемы. Во-первых, транзакция не

считается зафиксированной, если основная реплика и по крайней мере одна дополнительная

реплика не подтверждают запись транзакции в журнал. Во-вторых, если основная и

дополнительная реплика подтверждают успешную запись, могут быть обнаружены небольшие

сбои, не препятствующие фиксации транзакции, но способные привести к серьезным проблемам.

Реконфигурация Процедура замены поврежденных реплик называется реконфигурацией. Реконфигурация может

потребоваться при аппаратных сбоях или аварийном завершении работы операционной системы,

а также в случае возникновения неполадок экземпляра SQL Server. Реконфигурация также

используется при обновлении операционной системы, сервера SQL Server или платформы SQL

Database.

Отслеживание работоспособности каждого узла выполняется шестью аналогичными узлами,

размещенных в разных стойках. Эти узлы называются соседями. Сбой фиксируется одним из

соседей отказавшего узла. Для каждой базы данных, которая хранила реплику на сбойном узле,

выполняется процедура реконфигурации. Каждый компьютер содержит реплики сотен баз данных

SQL Database, некоторые из которых являются основными, а некоторые — дополнительными.

Поэтому в случае отказа узла выполняются сотни операций реконфигурации. При обработке сотен

ошибок, вызванных отказом узла, приоритизация не используется. Диспетчер разделов

случайным образом выбирает реплику для обработки, после завершения операций над ней

выбирает следующую, и так до тех пор, пока не будут обработаны все реплики с отказавшего узла.

Если узел отключается по причине перезагрузки, это считается чистым сбоем, поскольку соседи

узла получают сообщение об исключительной ситуации.

Другим возможным вариантом является прекращение обмена данными с компьютером по

неизвестной причине, когда фиксируется неопределенная ошибка. В этом случае применяется

процедура арбитража, позволяющая достоверно определить факт отказа узла.

Кроме определения отказа отдельной реплики, система выявляет и устраняет последствия отказов

целых узлов. Узел состоит из целого экземпляра SQL Server с несколькими разделами,

содержащими реплики до 650 различных баз данных. Одни реплики являются основными, другие

— дополнительными. В случае отказа узла над каждой из затронутых баз данных выполняется

описанная ранее процедура. Для некоторых баз с отказавшими основными репликами процесс

арбитража выбирает новую основную реплику из существующих дополнительных реплик, а для

других баз данных с отказавшими дополнительными репликами создается новая дополнительная

реплика.

Большинство реплик базы данных SQL Database должно подтверждать фиксацию. В настоящее

время пользовательские базы данных поддерживают три реплики. Поэтому кворумная фиксация

реплики требует подтверждения транзакции двумя другими репликами. Хранилище метаданных,

входящее в состав компонентов шлюза ЦОД, поддерживает пять реплик. Ему требуются три

подтверждения для проведения кворумной фиксации. Основному кластеру, который

поддерживает семь реплик, необходимо подтверждение четырех из них для фиксации

транзакции. Информация основного кластера может быть восстановлена даже в случае отказа

всех семи реплик. Существуют механизмы автоматизированного восстановления основного

кластера при столь масштабных отказах.

Отказ основной реплики Все операции чтения и записи сначала выполняются в основной реплике. Поэтому отказ основной

реплики выявляется незамедлительно и препятствует дальнейшему выполнению работы. При

переконфигурации в случае отказа основной реплики диспетчер разделов выбирает одну из

дополнительных реплик и назначает ее основной. Как правило, в качестве новой основной

реплики выбирается дополнительная реплика на узле с наименьшей рабочей нагрузкой.

Процедура присвоения дополнительной реплике статуса основной не вызывает простоя базы

данных и не заметна для большинства пользователей. Шлюз передаст клиентскому приложению

сообщение об отключении, после чего приложение должно незамедлительно выполнить попытку

повторного подключения. Распространение информации о новой основной реплике по всем

серверам шлюза может занять до 30 секунд. Поэтому рекомендуется попробовать подключиться

повторно несколько раз, делая небольшие паузы после каждой неудачной попытки.

Отказ дополнительной реплики При отказе дополнительной реплики у базы данных остается только две реплики для кворумной

фиксации. Процедура реконфигурации схожа с процедурой, которая выполняется после отказа

основной реплики, когда статус одной из дополнительных реплик повышается до основной. В

обоих случаях остается только одна дополнительная реплика. После короткого ожидания

диспетчер разделов пытается определить, носит ли этот отказ постоянный характер, чтобы создать

новую дополнительную реплику.

В некоторых случаях, например при отказе или обновлении операционной системы, отказ

дополнительной реплики может иметь кажущийся характер. Неработоспособность

дополнительной реплики на отказавшем узле может быть всего лишь временной. Поэтому

мгновенного создания новой реплики не происходит. Если дополнительная реплика возвращается

в рабочее состояние, выполняются команды проверки данных (checkdisk и т. п.) для

подтверждения работоспособности реплики.

Если реплика остается в нерабочем состоянии в течение более двух часов, диспетчер разделов

приступает к созданию новой реплики для ее замены. В некоторых случаях такое фиксированное

время ожидания не является оптимальным решением, например при отказе компьютера по

причине невосстановимого аппаратного сбоя. Новые выпуски платформы SQL Database, возможно,

будут содержать функции определения различных типов отказов реплик, а также иметь

возможность более оперативного устранения последствий невосстановимых сбоев.

Если произошел невосстановимый сбой узла, то для создания новой дополнительной реплики

выбирается один из компьютеров кластера, имеющий достаточное место на диске и запас

производительности процессора. Этот компьютер используется для размещения новой

дополнительной реплики. База данных копируется из основной реплики, затем эта копия

подключается к существующей конфигурации. Время, необходимое для копирования всего

содержимого базы данных, служит ограничивающим фактором для максимального размера

управляемых баз данных SQL Database.

Все компьютеры в ЦОД представляют собой потребительские вычислительные системы с со

средним уровнем производительности и качества комплектующих. На момент написания статьи —

32 ГБ оперативной памяти, восьмиядерным процессор и 12 дисков. Стоимость подобной системы

составляла около $3500. Экономичная и доступная конфигурация упрощает быструю замену

компьютеров в случае неустранимых сбоев. В среде Windows Azure используется одинаковое

потребительское оборудование. Это делает все компьютеры в ЦОДе взаимозаменяемыми,

независимо от того, используются они для поддержки SQL Database или Windows Azure.

Итого, распределение реплик баз данных по различным серверам и эффективные алгоритмы

присвоения дополнительным репликам статуса основных гарантируют доступность даже при

одновременном отказе 15% всех компьютеров ЦОДа. То есть в случае выхода из строя до 15% всех

компьютеров уровень поддерживаемой рабочей нагрузки не снизится.

Обеспечение масштабируемости в SQL Database Одним из наиболее значимых преимуществ размещения баз данных в среде SQL Database

являются встроенные функции обеспечения масштабируемости. При необходимости можно

добавить дополнительные базы данных. Два компонента SQL Database обеспечивают

масштабируемость за счет постоянного отслеживания рабочей нагрузки на каждом из узлов.

Первый компонент — Engine Throttling (регулировщик нагрузки на ядро), который защищает

сервер от перегрузки. Второй компонент — Load Balancer (балансировщик нагрузки), который

следит за тем, чтобы сервер не работал постоянно в режиме повышенной производительности.

Регулирование производительности Каждый из серверов SQL Server в ЦОДе используется несколькими клиентами одновременно.

Существует вероятность того, что приложение подписчика вызовет перегрузку сервера и нарушит

работоспособность целого экземпляра SQL Server. Например, в режиме полного восстановления

операция вставки большого числа строк, особенно содержащих крупные объекты, способна

заполнить журнал транзакций и весь диск, на котором размещен журнал. Кроме того, каждый

экземпляр SQL Server совместно использует компьютер с другими критически важными

системными процессами, которые нельзя лишать ресурсов. Важнейшим из них является процесс

поддержки структуры, отслеживающий состояние системы и обеспечивающий доступ к среде SQL

Database.

Для защиты ресурсов ЦОДа от излишней нагрузки, нарушающей работоспособность компьютеров,

нагрузка на каждый компьютер отслеживается компонентом Engine Throttling (регулировщик

нагрузки на ядро). Кроме того, отслеживается каждая реплика базы данных. Это позволяет

контролировать статистические показатели, значения которых должны находиться в заданных

пределах: размер журнала, длительность операций записи в журнал, уровень использования

процессора, фактические ограничения на размер физической базы данных и размер

пользовательской базы данных SQL Database. В случае превышения предельных значений база

данных SQL Database может отклонять запросы на чтение и запись в течение 10 секунд подряд.

Превышение ограничений на использование ресурсов может приводить к тому, что база данных

SQL Database будет отклонять все запросы на чтение и запись (в зависимости от типа ресурса).

Балансировка нагрузки В настоящее время нельзя гарантировать производительность среды SQL Database, несмотря

гарантию ее доступности. Одной из причин является проблема поддержки

многопользовательского доступа: множество клиентов со своими базами данных SQL Database

совместно используют один и тот же экземпляр SQL Server и один и тот же компьютер.

Невозможно предсказать уровень рабочей нагрузки, который будет затребован каждым из

соединений подписчиков. Тем не менее обеспечение высокой производительности является

критически важным аспектом, который учитывался при разработке инфраструктуры SQL Database.

Службы балансировки нагрузки SQL Database оценивают загрузку каждого из компьютеров в

центре обработки данных.

При добавлении новой базы данных SQL Database в кластер, балансировщик нагрузки определяет

места размещения новых реплик (основной и дополнительной), учитывая текущий уровень

рабочей нагрузки на компьютеры.

Если один из компьютеров перегружен, балансировщик нагрузки может переместить основную

реплику на менее нагруженный компьютер. Простейший способ — переключение основной и

дополнительной реплики базы данных SQL Database, производительность которой снижена. Это

переключение способно мгновенно повысить производительность, так как все операции чтения и

записи производятся в основной реплике.

Федерация базы данных Федерация позволяет масштабировать слой баз данных аналогично принципам масштабирования

middle-tier или front-end. Если просто, то федерация разбивает одну большую базу на несолько

более маленьких по определенному принципу. Обычно этот принцип выбирается таким образом,

чтобы сделать маленькие базы независимыми друг от друга (минимизировать кросс-обращения).

Фактические федерация позволяет следующее:

1. Преодолеть ограничение в 150 Гб на размер одной базы в SQL Database.

2. Повысить общую производительность системы за счет того, что каждый член федерации

обычно располагается на различных физических серверах.

3. Реализовать мультитенантность.

Дополнительную информацию по шардингу и федерации можно найти на следующих ресурсах:

1. Шардинг с SQL Database — этот документ является руководством по построению

приложений, в архитектуру которых заложено горизонтальное разбиение данных,

называемое шардинг (sharding). Данные в нем разносятся между несколькими

физическими базами данных, что обеспечивает масштабируемость приложения или

сервиса по мере его роста и увеличения объема данных.

2. Первое знакомство с федерациями SQL Database – это статья дает ответ на вопрос что же

такое федерации в базах данных SQL Database и зачем необходима федерация.

3. Федерации в SQL Database – подробное описание реализации федерации в SQL Database.

Безопасность Большинство вопросов безопасности баз данных SQL Database решается на уровне. Как и при

доступе к локальной базе данных, для подключения к базе данных SQL Database пользователь

должен иметь учетную запись и пароль. SQL Database поддерживает только стандартные средства

безопасности. Поэтому каждую учетную запись необходимо создавать в явной форме.

На каждом сервере SQL Database можно настроить брандмауэр так, чтобы он пропускал трафик

только с указанных IP-адресов. По умолчанию список разрешенных IP-адресов пуст. Это позволяет

сократить риск атак типа «отказ в обслуживании» (denial-of-service, DoS). Все данные,

передаваемые между клиентами и SQL Database, необходимо шифровать с помощью SSL. Клиенты

должны использовать для подключения параметр Encrypt = True, что позволяет устранить угрозу

атак типа «злоумышленник в середине». Для дополнительного снижения риска DoS-атак можно

воспользоваться службой DoSGuard, отслеживающей ошибки входа с одних и тех же IP-адресов за

определенный период времени и блокирующей доступ ко всем ресурсам с этих IP-адресов.

Рекомендации для разработчиков в среде SQL Database Несмотря на то что разработка приложений SQL Server для среды SQL Database весьма схожа с

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

различий.

Подключение и отключение При использовании облачной базы данных, в том числе и SQL Database, нужно быть готовым к

обработке неожиданных разрывов соединения, включая обработку подобных ситуаций в

программном коде. Лучший способ обработки разрыва соединения — повторное установление

соединения и выполнение команд или запросов, которые завершились сбоем — это принцип retry

logic.

Если причиной разрыва соединения являются неполадки сети, среда SQL Database не может

вернуть приложению значащее сообщение об ошибке перед завершением сеанса. При попытке

повторного использования этого соединения (аналогично созданию пула соединений с SQL Server)

вы получите сообщение об ошибке протокола транспортного уровня.

Как и другие базы данных, среда SQL Database время от времени разрывает соединения по

причине ошибок, нехватки системных ресурсов и прочих временных неполадок. В этих ситуациях

среда SQL Database всегда пытается возвратить конкретное сообщение об ошибке, если со

стороны клиентского соединения отправлен активный запрос. Однако не всегда возможно

сообщить клиентскому приложению об ошибке, если с его стороны нет запросов, ожидающих

выполнения. Например, если при работе с базой данных при помощи SQL Server Management

Studio не отправлено ни одного активного запроса в течение 30 минут, время ожидания сеанса

истечет. Так как активных запросов нет, среда SQL Database не может вернуть сообщение об

ошибке.

Требование наличия кластерного индекса В отличие от SQL Server каждая таблица базы данных SQL Database должна иметь кластерный

индекс. При объявлении первичного ключа таблицы по умолчанию создается кластерный индекс

столбца основного ключа (или нескольких столбцов, в зависимости от вида ключа). Кластерный

индекс первичного ключа не является единственным способом создания кластерного индекса.

Иногда это не лучшее решение. Кластеризованные индексы сортируют и хранят строки данных в

таблице на основании значений их ключей. Для каждой таблицы может существовать лишь один

кластерный индекс, так как сами строки данных можно сортировать только в одном порядке.

Необходимо контролировать наличие кластерного индекса у каждой таблицы.

SQL Database не поддерживает создание HEAP-таблиц. HEAP-таблицей является любая таблица, у

которой нет кластерного индекса. Это правило справедливо только для баз данных SQL Database.

Временные таблицы располагаются в базе данных tempdb, которая входит в состав

обслуживающих экземпляров SQL Server в центре обработке данных. Эти таблицы могут быть

HEAP-таблицами.

При создании дополнительных некластерных индексов для таблиц, имеющих кластерные

индексы, эти дополнительные индексы ссылаются на табличные данные с помощью кластерного

ключа. В SQL Server некластерный индекс HEAP-данных использует для ссылки на эти данные их

физические адреса. Несколько баз данных SQL Database могут храниться в одной базе данных SQL

Server. Поэтому использование ссылок на физические адреса хранения данных заметно снизило

бы гибкость системы SQL Database.

Все индексы в SQL Server и SQL Database хранятся в виде сбалансированных деревьев. Базовые

технологии обеспечения высокой доступности и репликации в среде SQL Database основаны на

репликации последовательностей сбалансированных деревьев. Эта структура позволяет

проводить техническое обслуживание компьютеров независимо друг от друга. Система получает

преимущества оптимизированного ввода-вывода, которые невозможно обеспечить при работе с

HEAP-таблицами.

Управление транзакциями Среда SQL Database поддерживает локальные транзакции с помощью обычных команд Transact-

SQL, которые полностью соответствуют аналогичным командам SQL Server.

Параметры настройки баз данных SQL Database обеспечивают изоляцию моментальных снимков.

Параметры READ_COMMITTED_SNAPSHOT и ALLOW_SNAPSHOT_ISOLATION имеют значение ON. По

умолчанию в SQL Server и SQL Database установлен уровень изоляции READ COMMITTED. Так как

параметр базы данных READ_COMMITTED_SNAPSHOT также используется, транзакции в среде SQL

Database проходят в режиме оптимистического параллелизма. Нельзя изменить параметры базы

данных SQL Database. Однако можно управлять уровнем изоляции, передавая команду SET

TRANSACTION ISOLATION LEVEL перед началом транзакции. Пользователь не может изменить

значение по умолчанию (READ COMMITTED) при использовании оптимистического параллелизма

и задать значение SQL Server по умолчанию (READ COMMITTED) при использовании

пессимистического параллелизма. Единственным способом реализации механизма работы,

который применяется в SQL Server по умолчанию, является использование специального приема

блокировки WITH (READCOMMITTEDLOCK) при работе с каждой таблицей в каждой из транзакций.

Устранение неполадок Пользователь не может управлять физическим выделением ресурсов или конфигурацией

используемых компьютеров и файлов баз данных. Поэтому система предъявляет минимальные

требования к необходимости устранения неполадок. Может понадобиться устранять неполадки

при обнаружении низкой производительности обработки запросов или проблем параллельной

обработки (например, при блокировке). Уровень изоляции баз данных SQL Database по

умолчанию установлен READ COMMITTED SNAPSHOT. Поэтому пользователю не придется решать

серьезные проблемы блокировки.

Приемы устранения неполадок, связанных с блокировкой или неоптимальными планами

выполнения, практически аналогичны в SQL Database и SQL Server. Как и в SQL Server, некоторые из

основных инструментов устранения неисправностей доступны в виде представлений

динамического управления (dynamic management view, DMV). Однако SQL Database поддерживает

лишь некоторую часть представлений динамического управления, предоставляемых SQL Server, а

некоторые из доступных представлений динамического управления имеют другой механизм

работы. Например, в SQL Server для просмотра содержимого многих представлений

пользователям требуется разрешение VIEW SERVER STATE, а в среде SQL Database пользователям

необходимо разрешение VIEW DATABASE STATE. В SQL Server представления sys.dm_tran_locks,

sys.dm_exec_requests и sys.dm_exec_query_stats отображают подробные сведения о процедурах и

запросах всего экземпляра сервера. В среде SQL Database эти представления возвращают только

информацию о базе данных SQL Database. Дополнительные сведения о поддерживаемых

представлениях динамического управления см. в разделе «Метаданные».

Итого Итого, получаем, что SQL Database — это специально спроектированная облачная реляционная

база данных, рассчитанная на масштабирование, отказоустойчивость и использования в один клик

(или совсем рядом с одним кликом). С точки зрения сравнения SQL Database и SQL Server, SQL

Database не является точной копией SQL Server, но постепенно наиболее интересные возможности

SQL Server становятся доступными и в SQL Database (например, облачный SQL Reporting).