Mssql 2018: Microsoft SQL Server 2018 Management Studio

Техподдержка: Настройка регулярного резервного копирования БД MS SQL Server

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

Для этого можно использовать либо встроенный в SQL Server планировщик заданий – «SQL Server Agent» (в бесплатную версию не входит), либо стандартный «Планировщик Windows» в сочетании с утилитой SQLCMD.EXE, которая позволяет выполнять запросы к SQL Server из командной строки. В планировщике необходимо создать как минимум семь заданий (по одному на каждый день недели), каждое из которых будет (раз в неделю) заменять один из семи файлов, содержащих соответствующую резервную копию базы данных.

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

• С помощью «Планировщика Windows» (для бесплатной версии)
• С помощью «SQL Server Agent» (в бесплатную версию не входит)

С помощью «Планировщика Windows» (для бесплатной версии)

Чтобы создать задание в «Планировщике Windows» надо:

Запустить программу «Блокнот» (Пуск->Все программы->Стандартные->Блокнот) и ввести следующие две строки, после чего сохранить их в виде командного файла (*.BAT):

SQLCMD -S (local) -E -Q «BACKUP DATABASE AltaSVHDb TO DISK = ‘D:\BACKUP\ AltaSVHDb_monday.bak’ WITH INIT, NOFORMAT, SKIP, NOUNLOAD»

XCOPY D:\BACKUP\ AltaSVHDb_monday.bak \\BACKUP_SERVER\Folder\*.* /Y

где «(local)» – имя сервера (в случае установки именованного экземпляра SQL Server надо указать имя полностью: «ИМЯ_КОМПА\SQLEXPRESS»), «AltaSVHDb» – имя базы данных, «D:\BACKUP\ AltaSVHDb_monday. bak» – имя файла для создания в нем резервной копии (будет различаться по дням недели), «BACKUP_SERVER» – имя компьютера, на который будет выполняться дополнительное копирование, «Folder» – папка на этом компьютере (к ней должен быть предоставлен общий доступ).

Запустить мастер планирования заданий (Панель управления->Назначенные задания->Добавить задание) и нажать кнопку «Далее»:

Нажать кнопку «Обзор» и указать путь к командному файлу (*.BAT), созданному на шаге a):

Указать имя для задания, выбрать вариант запуска «еженедельно» и нажать кнопку «Далее»:

Поставить галочку возле нужного дня недели, а в поле «Время начала» указать время, когда должен запускаться процесс резервного копирования (обычно это делается ночью), затем нажать кнопку «Далее»:

Ввести имя пользователя и пароль (дважды) учетной записи ОС, от имени которой будет выполняться задание, и нажать кнопку «Далее»:

Внимание! Чтобы задание успешно выполнялось необходимо предоставить указанной здесь учетной записи (домена или локального компьютера) права записи в вышеупомянутую папку «\\BACKUP_SERVER\Folder», а также настроить доступ к самому SQL Server.

Нажать кнопку «Готово»

Примечание. Чтобы проверить работоспособность созданного задания, необходимо в списке заданий (Панель управления->Назначенные задания) нажать правой кнопкой мыши на интересующем задании и в контекстном меню выбрать пункт «Выполнить», затем убедиться, что файл резервной копии БД успешно создался по тем путям, которые были указаны на шаге a).

С помощью «SQL Server Agent» (в бесплатную версию не входит)

Чтобы создать задание в «SQL Server Agent» надо:

Запустить утилиту SQL Server Management Studio и подключиться к серверу под учетной записью администратора.

В левой части окна нажать правой кнопкой мыши на разделе «Объекты сервера/Устройства резервного копирования» и в контекстном меню выбрать пункт «Создать устройство резервного копирования»:

В поле «Имя устройства» ввести имя, которое будет ассоциироваться с файлом резервной копии БД, при необходимости изменить путь в поле «Файл» и нажать «ОК»:

В левой части окна нажать правой кнопкой мыши на разделе «Агент SQL Server/Задания» и в контекстном меню выбрать пункт «Создать задание»:

В поле «Имя» ввести имя задания:

На странице «Шаги» нажать кнопку «Создать»:

В появившемся окне ввести имя в поле «Имя шага», проверить, что в поле «Тип» выбрано «Сценарий Transact-SQL (T-SQL)», а в поле «Команда» ввести строку:

BACKUP DATABASE AltaSVHDb TO AltaSVHDb_monday WITH INIT, NOFORMAT, SKIP, NOUNLOAD

где «AltaSVHDb» – имя базы данных, «AltaSVHDb_monday» – имя устройства резервного копирования, созданного на шаге c) (будет различаться по дням недели):

В предыдущем окне нажать кнопку «ОК», в результате на странице «Шаги» должна появиться строка:

Чтобы файл резервной копии БД сразу копировался на другой компьютер в сети необходимо повторить пункты f) – h), в окне «Создание шага задания» выбрав в поле «Тип» значение «Операционная система (CmdExec)», а в поле «Команда» указав строку:

XCOPY D:\MSSQL\BACKUP\AltaSVHDb_monday. bak \\BACKUP_SERVER\Folder\*.* /Y

где «D:\MSSQL\BACKUP\AltaSVHDb_monday.bak» – путь, указанный на шаге c) (будет различаться по дням недели), «BACKUP_SERVER» – имя компьютера, на который будет выполняться копирование, «Folder» – папка на этом компьютере (к ней должен быть предоставлен общий доступ):

Примечание. Чтобы копирование файла успешно выполнялось необходимо запускать «SQL Server Agent» под учетной записью домена Windows, для которой предоставлены права записи в вышеупомянутую папку (см. также «SQL2005_installation.doc» или «SQL2008_installation.doc»), а также настроен доступ к самому SQL Server (см. раздел «Настройка прав доступа к БД», включить эту учетную запись надо в роль «sysadmin» на странице «Серверные роли», а на страницах «Сопоставление пользователей» и «Защищаемые объекты» ничего не делать).

На странице «Расписания» нажать кнопку «Создать»:

Ввести имя в поле «Имя», проверить, что в поле «Тип расписания» выбрано значение «Повторяющееся задание», а в поле «Выполняется» – «Еженедельно». Поставить галочку возле нужного дня недели (остальные снять), а в поле «Однократное задание» указать время, когда должен запускаться процесс резервного копирования (обычно это делается ночью):

В предыдущем окне нажать кнопку «ОК», в результате на странице «Расписания» должна появиться строка:

Нажать кнопку «ОК».

Примечание. Чтобы проверить работоспособность созданного задания, необходимо в разделе «Агент SQL Server/Задания» нажать правой кнопкой мыши на интересующем задании и в контекстном меню выбрать пункт «Запустить задание на шаге», в появившемся окне выбрать первый шаг данного задания и нажать «ОК». Далее появится окно отображающее ход выполнения задания. Если выполнение задания закончится с ошибкой, то подробное описание ошибки можно увидеть вызвав пункт «Просмотр журнала» того же контекстного меню.

Настройка MSSQL для работы с 1С — мифы и реальность

Оптимизируем Microsoft SQL Server 2014 для работы с 1С. ОС — Windows Server 2012 R2. Напишу что нужно сделать, а что не нужно.

Определяю мифичность очень просто, если мне пришлось применить настройку — реальность, не пришлось — миф.

Статья по оптимизация сервера Microsoft SQL Server 2019 для работы с 1С

Устанавливаем последний Service Pack и Cumulative Update — реальность

На текущий момент нужно обновиться до SP3.

MSSQL — устанавливаем Service Pack 3

Обязательно нужно сделать.

Выравнивание разделов — миф

Рекомендуют выравнивать сектора дисков по границе 1024Кб. Не заморачивайтесь, эта рекомендация устарела. Операционная система теперь сама выравнивает раздел как нужно для дисков более 4 ГБ.

HKLM\SYSTEM\CurrentControlSet\Services\VDS\Alignment

Эту настройку не применяем.

Форматирование с размером блока 64Кб

А вот здесь всё очень неявно. Есть статья Best Practice от Microsoft:

https://docs.microsoft.com/ru-ru/archive/blogs/docast/operating-system-best-practice-configurations-for-sql-server

В ней явно говорится:

Partition the Disk volumes hosting SQL databases (Data and log) with 64 KB allocation unit size:
A drive can be formatted with different sizes ranging from 512 bytes to 64K sizes with the default being 4KB (4096 bytes). This setting is also called as “Bytes Per Cluster”. The atomic unit of storage in SQL Server is a page which is 8KB in size. Extents are groups of eight 8 KB pages that are physically contiguous to each other for a total of 64 KB. SQL Server uses extents to store data. Hence, on a SQL Server machine the NTFS Allocation unit size hosting SQL database files (Including tempdb files) should be 64K.

Кстати, обратите внимание на другие разделы статьи, возможно, там тоже найдёте для себя что-то полезное.

Казалось бы всё ясно, 64 килобайта — наше всё. Но… Откуда ноги растут? Есть рекомендация от Microsoft с 2008 года:

https://docs.microsoft.com/en-us/previous-versions/sql/sql-server-2008/dd758814(v=sql.100)

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

Note that file allocation unit (cluster) size commonly correlates with common stripe unit sizes. The performance question here is usually not one of correlation per the formula, but whether the cluster size is the NTFS default of 4,096 bytes or has been explicitly defined at 64 KB, which is a best practice for SQL Server.

Снова 64 килобайта — наше всё. Читаем дальше:

An appropriate value for most installations should be 65,536 bytes (that is, 64 KB) for partitions on which SQL Server data or log files reside. In many cases, this is the same size for Analysis Services data or log files, but there are times where 32 KB provides better performance. To determine the right size, you will need to do performance testing with your workload comparing the two different block sizes.

Получается, что SQL сервер ведёт себя лучше при размере кластера 64 килобайта, однако, в некоторых случаях, максимальной производительности удавалось достигать при размере кластера в 32 килобайта.

А теперь добавляем переменных:

• Появились новые типы массивов типа SSD и NVMe.
• Всё чаще SQL сервер устанавливается виртуально или в облаке, где файловая система виртуальной машины живёт внутри файловой системы гипервизора.
• Производители жёстких дисков и RAID контроллеров используют кеширование и дополнительные технологии ускорения работы дисков.

Ещё следует учитывать, что NTFS для разных размеров диска создаёт разные размеры блока. Стандартный размер кластера (лучше использовать это название) в файловой системе NTFS:

• ёмкость до 16 Тб — 4 килобайта
• ёмкость от 16 до 32 Тб — 8 килобайт
• ёмкость от 32 до 64 Тб — 16 килобайт
• ёмкость от 64 до 128 Тб — 32 килобайта
• ёмкость от 128 до 256 Тб — 64 килобайта

Так что если вы не хотите заморачиваться, то ставьте размер блока (кластера) при форматировании 64 килобайта. Однако не факт, что при этом ваш SQL сервер будет работать быстрее. Правильный ответ можно получить только при тестировании производительности.

Присылайте ссылки на статьи, где проводились исследования производительности для разных размеров кластера. Истина где-то там.

Database instant file initialization — частично миф, частично реальность

Рекомендуют включить возможность Database instant file initialization для пользователя, от которого запущена служба Microsoft SQL Server.

Что это за штука?

Во-первых, эта настройка влияет только на файл данных. Когда файл автоматически вырастает, то новый кусок заполняется нулями, в этот момент 1С может тормозить. Instant File Initialization (IFI) позволяет отключить это зануление.

Делается так.

1. Запускаем Local Group Policy Editor:

   gpedit.msc

2. Слева выбираем Local Computer Policy, Computer Configuration, Windows Settings, Security Settings, Local Policies, User Rights Assigment.
3. Тыкаем в Perform volume maintenance tasks.
4. Сюда добавляем юзера, от имени которого запускается SQL Server.

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

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

Давайте проверим, что всё работает. Рекомендуют создать новую БД размером 5 Гб и логом 1 Мб. Вот тут тоже нужно быть внимательным, нужно создавать под тем же пользователем, от которого запускается сервис SQL. Я создам от имени другого пользователя, который тоже в группе Administrators.

База создалась мгновенно. На всякий случай попробую создать базу размером 50 Гб, место есть. Да, моментально на диске пропало 50 Гб и БД создалась быстро.

Вывод:

Instant File Initialization (IFI) работает из коробки, если пользователь, под которым работает сервис SQL входит в группу Administrators сервера.

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

Lock pages in memory — реальность

Рекомендуют установить разрешение на Lock pages in memory (блокировку страниц в памяти) для пользователя, от которого запущена служба Microsoft SQL Server. Эта политика Windows определяет, какие учетные записи могут сохранять данные в физической памяти, чтобы система не отправляла страницы данных в виртуальную память на диске.

1. Запускаем Local Group Policy Editor:

   gpedit.msc

2. Слева выбираем Local Computer Policy, Computer Configuration, Windows Settings, Security Settings, Local Policies, User Rights Assignment.
3. Тыкаем в Lock pages in memory.

4. Видим, что политика не настроена. Можно добавить сюда пользователя, от имени которого работает SQL Server, я просто добавляю сюда группу Administrators.

Эту настройку применяем. Нужно учитывать, что потребление оперативки возрастёт.

Power Option: High performance — реальность

Да, это реальность. По умолчанию план электропитания в Windows Server 2012 R2 — Balanced.

https://support.microsoft.com/en-au/help/2207548/slow-performance-on-windows-server-when-using-the-balanced-power-plan

В некоторых случаях, Microsoft не уточняет в каких, на сервере может из-за этого снижаться производительность. Переключаем план на High performance.

Эту настройку применяем.

Сжатие содержимого — миф

Рекомендуют проверить, что галка, отмеченная на картинке выше, снята. Имеется в виду папка, где лежат файлы БД. По умолчанию она снята — рекомендация миф.

Индексация файлов — миф

По умолчанию галка Allow files in this folder to have contents indexed in addition to the file properties стоит:

Казалось бы, надо снимать. Подумаем, эта галка указывает службе индексации, что содержимое нужно обработать. Зачем на сервере индексировать содержимое? А стоит ли вообще служба индексации по умолчанию? Проверяем:

А служба поиска не установлена! Ну и забиваем на все эти галки. Эту настройку не применяем.

Исключить файлы БД из систем резервного копирования — миф

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

Во-первых, не отделяйте мух от котлет. Не держите приложение 1С и SQL Server на одном сервере. MSSQL должен жить отдельно. И резервироваться он должен средствами MSSQL. И зеркалироваться.

Эту настройку не применяем.

Резервирование и обслуживание — реальность

Ссылки:

Maintenance Plans — резервное копирование и обслуживание баз данных в Microsoft SQL Server 2014

Настройка зеркалирования в Microsoft SQL Server 2014

Эту настройку применяем.

Настройка памяти — реальность

Да, память для MSSQL нужно настраивать. По умолчанию сиквел жрёт всё что может, системе начинает не хватать. Как итог — тормоза. Нужно выделить SQL серверу строго определённое количество памяти и пусть не рыпается.

Повторюсь:

Не держите приложение 1С и SQL Server на одном сервере. MSSQL должен жить отдельно.

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

MSSQL — настройка памяти

Эту настройку применяем.

Настройка процессора — реальность

Настроим проц.

MSSQL — настройка процессора

Эту настройку применяем.

Расположение файлов данных — реальность

Файлы данных и файлы журналов транзакций желательно размещать на разных дисковых массивах. Если один из массивов быстрее, то лог нужно разместить там.

Эту настройку по возможности применяем.

Разбить tempdb на несколько файлов по количеству процессоров — миф

Миф обыкновенный:

https://www.sqlskills.com/blogs/paul/a-sql-server-dba-myth-a-day-1230-tempdb-should-always-have-one-data-file-per-processor-core/

Эту настройку не применяем.

Перенести tempdb в RAM — реальность

Сам протестировал, добился 10-кратного прироста скорости чтения-запись для tempdb.

MSSQL — переносим tempdb на RAM диск

Эту настройку по возможности применяем.

Установить параметр Max degree of parallelism = 1 — частично миф, частично реальность

В закладке Advanced есть возможность установить параметр Max degree of parallelism. Кто-то рекомендует ставить 1, чтобы запретить параллельные запросы. Смысл в том, что один толстый запрос может сожрать все процессоры и помешать другим пользователям. С другой стороны, запущенная на ночь обработка могла бы выполняться быстрее при использовании нескольких процессоров. Давайте поступим иначе — ограничим половиной процессоров. У меня их 8, ставлю 4.

https://docs.microsoft.com/ru-ru/sql/database-engine/configure-windows/configure-the-max-degree-of-parallelism-server-configuration-option?view=sql-server-2014

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

Прирост файлов БД — реальность

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

По умолчанию прирост 10%, это никуда не годится. Если база 500 гигабайт, то одномоментно отобранные 50 Гб места могут негативно сказаться на работе.

Ставим прирост 200 Мб.

Эту настройку применяем.

Флаги трассировки — реальность

4199 — включает исправления оптимизатора из фиксов.

https://blogs.msdn.microsoft.com/psssql/2015/06/16/identifying-sql-server-2014-new-cardinality-estimator-issues-and-service-pack-1-improvement/

1118 — использовать разные страницы памяти.

Запускаем SQL Server Configuration Manager. SQL Server Services. SQL Server — правой кнопкой свойства. Вкладка Startup Parameters. Добавляем -T1118 и -T4199.

Для применения потребуется перезапустить SQL сервер.

Эту настройку применяем.

Сетевые протоколы — реальность

Протокол «Named pipes» необходимо отключить.

Запускаем SQL Server Configuration Manager. SQL Server Network Connfiguration. Protocols for MSSQLSERVER (наш инстанс). Делаем Named Pipes — Disabled.

Эту настройку применяем.

Отключение DFSS — миф

DFSS по умолчанию устанавливается на терминальный сервер. При чём тут SQL? Отключать нечего.

Эту настройку не применяем.

советов по навигации по документам SQL Server — SQL Server

• Статья
• 24.01.2023
• 6 минут на чтение

В этой статье приведены некоторые советы и рекомендации по навигации в пространстве технической документации SQL Server.

Центральная страница

Центральную страницу SQL Server можно найти по адресу https://aka.ms/sqldocs, и она является точкой входа для поиска соответствующего содержимого SQL Server.

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

Автономная документация

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

Если вы хотите создать PDF-файл, выберите ссылку Download PDF , расположенную внизу каждого оглавления.

Символы TOC

Записи в оглавлении (TOC), имеющие > в конце записи, означают, что вы перейдете к технической документации с другим оглавлением.

Записи в оглавлении, отмеченные >> , означают, что вы будете перенаправлены на другой веб-сайт.

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

Поиск оглавления

Вы можете искать записи в оглавлении, используя поле поиска с фильтром вверху:

Фильтр версий

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

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

Хлебные крошки находятся под заголовком и над оглавлением и указывают, где находится текущая статья в оглавлении. Это не только помогает задать контекст для типа контента, который вы читаете, но также позволяет вам вернуться вверх по дереву оглавления:

Навигация по разделу статьи

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

Что означают параметры «Применимо к»

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

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

Продукт	Модель развертывания	Описание
Сервер SQL	Локально 1 , Виртуальные машины Azure 3 , Контейнеры Linux 1	Это SQL Server, над которым у вас есть полный контроль. Вы можете установить SQL Server в Windows или Linux, развернуть его в контейнере Linux или развернуть на виртуальной машине Azure или другой платформе виртуальных машин. Возможно, вы ранее называли это продукт в штучной упаковке . Поддерживаемые версии SQL Server зависят от вашего лицензионного соглашения, но для целей этой документации мы имеем в виду SQL Server 2016 (13.x) и более поздние версии. Документацию по SQL Server 2014 (12.x) и более ранним версиям см. в разделе Предыдущие версии документации по SQL Server. Чтобы узнать, какие версии SQL Server поддерживаются в настоящее время, см. раздел Варианты прекращения поддержки SQL Server. Важно: Не включает поддержку Azure SQL. Если статья относится к продуктам Azure SQL, эти продукты будут перечислены отдельно в разделе «Относится к».
База данных SQL Azure	Полностью управляемый 2	База данных SQL Azure — это отдельная база данных или часть эластичного пула. База данных SQL — это полностью управляемый механизм базы данных «платформа как услуга» (PaaS), который выполняет большинство функций управления базой данных, таких как обновление, установка исправлений, резервное копирование и мониторинг, без участия пользователя.
Управляемый экземпляр Azure SQL	Полностью управляемый 2	Управляемый экземпляр Azure SQL — это полностью управляемый экземпляр базы данных. Управляемый экземпляр SQL сочетает в себе широчайшую совместимость ядра базы данных SQL Server со всеми преимуществами полностью управляемой и вечнозеленой платформы как услуги (PaaS). Управляемый экземпляр SQL имеет почти 100-процентную совместимость с последним ядром базы данных SQL Server (Enterprise Edition). Важно: Хотя Управляемый экземпляр SQL имеет много общих функций с SQL Server, существуют некоторые несовместимости, особенно до SQL Server 2022 (16.x).
Azure Synapse Analytics	Полностью управляемый 2	Azure Synapse Analytics — это служба корпоративной аналитики, которая ускоряет получение информации из хранилищ данных и систем больших данных. Azure Synapse Analytics объединяет лучшие технологии SQL, используемые в корпоративных хранилищах данных, технологии Spark, используемые для больших данных, обозреватель данных для анализа журналов и временных рядов, конвейеры для интеграции данных и ETL/ELT, а также глубокую интеграцию с другими службами Azure, такими как Power BI, Cosmos DB и AzureML. Функции Azure Synapse SQL обеспечивают масштабируемую архитектуру для обработки данных в виде выделенных пулов SQL (ранее называвшихся SQL DW) и бессерверных пулов SQL.
Аналитическая платформа (PDW)	Локальная, полностью управляемая 2	Microsoft Analytics Platform System (APS) — это платформа данных, предназначенная для хранения данных и аналитики больших данных, которая предлагает глубокую интеграцию данных, высокоскоростную обработку запросов, масштабируемое хранилище и простое обслуживание ваших комплексных решений бизнес-аналитики. В Analytics Platform System размещается хранилище параллельных данных SQL Server (PDW) — программное обеспечение, которое запускает хранилище данных с массовой параллельной обработкой (MPP).
Azure SQL Edge	Подключенный режим с использованием Azure IoT Edge или отключенный режим в контейнере Linux	Azure SQL Edge — это оптимизированный механизм реляционной базы данных, предназначенный для развертываний IoT и IoT Edge. Он предоставляет возможности для создания высокопроизводительного уровня хранения и обработки данных для приложений и решений IoT. Он использует тот же механизм базы данных, что и SQL Server, и включает дополнительные функции временных рядов и аналитики.
База данных Azure для MariaDB	Полностью управляемый 2	Служба реляционной базы данных на основе механизма базы данных с открытым исходным кодом MariaDB. Полностью управляемая база данных как услуга (DBaaS), которая может обрабатывать критически важные рабочие нагрузки с предсказуемой производительностью, безопасностью, высокой доступностью и динамической масштабируемостью.
База данных Azure для MySQL	Полностью управляемый 2	Служба реляционной базы данных, основанная на движке базы данных MySQL с открытым исходным кодом. Полностью управляемая база данных как услуга (DBaaS), которая может обрабатывать критически важные рабочие нагрузки с предсказуемой производительностью, безопасностью, высокой доступностью и динамической масштабируемостью.
База данных Azure для PostgreSQL	Полностью управляемый 2	Служба реляционной базы данных на основе ядра базы данных PostgreSQL с открытым исходным кодом. Полностью управляемая база данных как услуга (DBaaS), которая может обрабатывать критически важные рабочие нагрузки с предсказуемой производительностью, безопасностью, высокой доступностью и динамической масштабируемостью.

¹ Может быть Azure ARC с поддержкой

² Платформа как услуга (PAAS)

³ Инфраструктура-AS-AS-Service (AAAS)