Вопросы и ответы об Управляемом экземпляре SQL Azure

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

Основные различия в синтаксисе и поведении между управляемым экземпляром SQL Azure и SQL Server см. в статье О различиях между T-SQL и SQL Server.

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

Любой клиент имеет право на использование любого уровня служб. Лицензии на выпуски Standard и Enterprise, охваченные Software Assurance, можно выделить в ядро СУБД SQL Server с помощью преимущества гибридного использования Azure (AHB) для уровня служб общего назначения (который включает обновление уровня служб общего назначения следующего поколения, в настоящее время в предварительной версии) или для уровня служб "Критически важный для бизнеса". Преимущество гибридного использования Azure использует следующие коэффициенты обмена: 1 Выпуск Standard = 1 Общего назначения, 1 Корпоративный выпуск = 1 Критически важный для бизнеса, 1 Выпуск Enterprise = 4 Общего назначения и 4 Общего назначения = 1 Enterprise Edition. Дополнительные сведения см. в разделе "Конкретные права гибридного преимущества Azure".

Список поддерживаемых типов подписок см. в статье Поддерживаемые типы подписок.

Управляемые экземпляры можно создавать в большинстве регионов Azure; см. статью Поддерживаемые регионы для управляемого экземпляра SQL. Если вам нужен управляемый экземпляр SQL в регионе, который сейчас не поддерживается, отправьте запрос на поддержку через портал Azure.

Управляемый экземпляр SQL имеет два ограничения по умолчанию: ограничение на количество подсетей, которые можно использовать, и ограничение на количество виртуальных ядер, которые можно подготовить. Ограничения различаются по регионам и типам подписки. Список ограничений региональных ресурсов по типу подписки см. в таблице из ограничения региональных ресурсов. Эти мягкие ограничения могут быть увеличены по требованию. Если требуются дополнительные управляемые экземпляры в текущих регионах, отправьте запрос на поддержку через портал Azure, чтобы увеличить квоту. Дополнительные сведения см. в статье Запрос на увеличение квоты для базы данных SQL Azure.

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

Можно рассмотреть другие варианты миграции в Azure, которые соответствуют вашей рабочей нагрузке: Гипермасштабирование для Базы данных SQL Azure или SQL Server на Виртуальных машинах Azure.

Можно рассмотреть миграцию на SQL Server на Виртуальных машинах Azure или оптимизированное соотношение объема памяти и числа процессоров для Базы данных SQL Azure.

Сведения о дефектах продукта и известных проблемах см. в статье Известные проблемы.

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

Управляемый экземпляр SQL можно подготовить на портале Azure, PowerShell, Azure CLI и шаблонах ARM.

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

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

^[a-zA-Z_][^\\\/\:\*\?\"\<\>\|\`\'\^]*(?<![\.\s])$

В настоящее время поддерживаются все имена, которые подтверждаются регулярным выражением и являются допустимыми именами подсетей.

Управляемый экземпляр SQL можно масштабировать с портала Azure, PowerShell, Azure CLI или шаблонов ARM.

Да, вы можете. Инструкции см. в разделе Перемещение ресурсов между регионами.

Управляемые экземпляры SQL можно удалить с помощью портала Azure, PowerShell, Azure CLI или REST API Resource Manager.

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

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

Message database 'backup_restore_db_lkg_native_restore' already exists. Choose a different database name.

Чтобы избежать этой ошибки, проверьте состояние операции удаления перед повторным созданием базы данных с тем же именем. Дополнительные сведения см. в статье sys.dm_operation_status. Когда для операции отобразится состояние Завершено, можно будет восстановить или создать базу данных с тем же именем.

Возникновение такой ошибки вероятно при следующих вариантах использования:

• Если несколько баз данных будут удалены и снова созданы в последовательности с одним и тем же именем в короткий промежуток времени. При удалении базы данных резервное копирование оставшегося заключительного фрагмента журнала выполняется синхронно перед завершением операции удаления, как показано на изображении:

  

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

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

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

Скорее всего, вы закончили кредиты в течение месяца. Перейдите к управляемому экземпляру SQL на портале Azure и проверьте состояние. Проверьте, находится ли экземпляр в остановленном состоянии из-за нехватки кредитов.

Эта функция в настоящее время недоступна.

Да, вы можете восстановить автоматическую резервную копию из хранилища Azure или восстановить резервную копию базы данных с помощью SQL Server Management Studio (SSMS).

Несмотря на ограничения ресурсов, бесплатный управляемый SQL предназначен для тестирования рабочих нагрузок без каких-либо последствий. Производительность при использовании бесплатной Управляемый экземпляр SQL идентична производительности рабочей версии экземпляра.

Бесплатный Управляемый экземпляр SQL предлагает 4 и 8 виртуальных ядер. Если для вашего бизнеса требуется экземпляр с большими ресурсами, создайте полнофункциональный платный Управляемый экземпляр SQL.

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

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

Изменение имени управляемого экземпляра SQL не поддерживается.

Да, зона .database.windows.net DNS управляемого экземпляра SQL по умолчанию может быть изменена самостоятельно. Однако имя узла управляемого экземпляра SQL части полного доменного имени, включая рандомизированную подзону (например sqlmiFQDN.randomized-subzone , до этого .database.windows.net) должно оставаться прежним.

чтобы использовать другую зону DNS, например .contoso.com:

• Для определения псевдонима используйте служебную программу клиентской сети SQL Server (CliConfg). Можно использовать только имя узла управляемого экземпляра SQL или имя узла управляемого экземпляра SQL, за которым следует имя личного домена. Средство CliConfg добавляет псевдоним в реестр HKLM\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo или HKLM\SOFTWARE\WOW6432Node\Microsoft\MSSQLServer\Client\ConnectTo в зависимости от того, используется ли 64-разрядная версия (C:\Windows\System32\cliconfg.exe) или 32-разрядная версия (C:\Windows\SysWOW64\cliconfg.exe). Вы также можете добавить псевдоним с помощью групповой политики или скрипта, но следует убедиться, что 32-разрядные и 64-разрядные программы могут разрешать псевдоним.
• Используйте запись CNAME в DNS с именем узла управляемого экземпляра SQL, указывающим на полное доменное имя управляемого экземпляра SQL. В этом случае TrustServerCertificate=TRUE необходимо использовать проверку подлинности с идентификатором Microsoft Entra (ранее — Azure Active Directory).
• Используйте запись в DNS с именем узла управляемого экземпляра SQL, указывающую НА IP-адрес управляемого экземпляра SQL. Использование IP-адреса не рекомендуется, так как оно может изменяться без уведомления. В этом случае TrustServerCertificate=TRUE требуется при использовании проверки подлинности Microsoft Entra.

Управляемый экземпляр SQL Azure обеспечивает для вычислительной емкости и емкости хранилища производительность тех же уровней, что и другие варианты развертывания Базы данных SQL Azure. Если вы хотите консолидировать данные в одном экземпляре или вам нужна функция, поддерживаемая исключительно в управляемом экземпляре SQL. Данные можно перенести с помощью функций экспорта и импорта (BACPAC). Ниже приведены другие способы, которые следует учитывать при переносе базы данных SQL в управляемый экземпляр SQL.

• Использование внешнего источника данных
• Использование SQLPackage
• Использование BCP

Один из вариантов — экспортировать базу данных в BACPAC, а затем импортировать BACPAC-файл. Этот подход рекомендуется использовать, если база данных меньше 100 ГБ.

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

Как перенести экземпляр SQL Server, см. в статье Руководство по переносу SQL Server в Управляемый экземпляр SQL Azure.

Сведения о миграции с других платформ см. в руководствах по миграции базы данных Azure.

Для сравнения производительности управляемого экземпляра SQL и SQL Server рекомендуется использовать рекомендации по сравнению производительности управляемого экземпляра SQL Azure и SQL Server.

См. статью Основные причины различий в производительности между управляемым экземпляром SQL и SQL Server. Размер файла журнала транзакций может повлиять на производительность Управляемый экземпляр SQL общего назначения. Дополнительные сведения см. в разделе "Влияние размера файла журнала на общее назначение".

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

• Автоматическая настройка обеспечивает наилучшую производительность и стабильность рабочих нагрузок благодаря механизму непрерывной оптимизации производительности на основе искусственного интеллекта и машинного обучения.
• OLTP в памяти повышает пропускную способность, уменьшает задержку для рабочих нагрузок обработки транзакций и позволяет быстрее получить бизнес-аналитику.
• Применение некоторых рекомендаций по настройке приложений и баз данных.
• Если рабочая нагрузка состоит из множества небольших транзакций, то чтобы уменьшить задержку и повысить пропускную способность, в качестве типа подключения вместо прокси-сервера рекомендуется использовать режим перенаправления.

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

См. Анализ статистики ожидания на Управляемом экземпляре SQL. Статистика ожидания — это сведения, которые помогут понять, почему запрос выполняется долго, и определить запросы, ожидающие чего-либо в ядре СУБД.

MSSQLSERVER_833 указывает, что запрос ввода-вывода занимает больше 15 секунд. Эта ошибка в Управляемом экземпляре SQL Azure связана с общими условиями инфраструктуры, а не рабочей нагрузкой. В облачных средах и системах, использующих удаленное хранилище, существует несколько уровней архитектуры, влияющих на один запрос ввода-вывода. Это поведение ожидается и известное ограничение службы, которое обычно приводит к временным сетевым проблемам или ресурсам службы хранилища Azure, которые становятся временно недоступными. Система обычно восстанавливается без вмешательства.

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

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

Если эта ошибка возникает постоянно, рассмотрите возможность проверки шаблонов рабочих нагрузок, производительности хранилища и конфигураций сети. Кроме того, рекомендуется использовать уровень служб "Критически важный для бизнеса", предназначенный для приложений с низкими требованиями к задержке ввода-вывода.

Сведения о всех возможных параметрах мониторинга и оповещений о потреблении и производительности управляемого экземпляра SQL см. в записях блога Параметры мониторинга управляемого экземпляра SQL Azure. Сведения о мониторинге производительности в режиме реального времени для управляемого экземпляра SQL см. в статье Мониторинг производительности в режиме реального времени для управляемого экземпляра SQL Azure.

См. статью Мониторинг и настройка производительности.

См. Мониторинг производительности в режиме реального времени для управляемого экземпляра SQL Azure.

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

Нет, они не поддерживаются. Для мониторинга баз данных можно использовать динамические административные представления и хранилище запросов вместе с Профилировщиком SQL и XEvents.

См. Мониторинг использования ЦП в SQL Server и Azure SQL.

Да. Инструкции см. в статье Создание оповещений для управляемого экземпляра SQL. Дополнительные советы и рекомендации см. в блоге.

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

Размер хранилища для Управляемого экземпляра SQL зависит от выбранного уровня служб (общего назначения, общего назначения, общего назначения или критически важного для бизнеса). Ограничения хранилища этих уровней служб см. в разделе "Ограничения ресурсов".

Минимальный размер хранилища, доступный в экземпляре, составляет 32 ГБ. Хранилище можно увеличивать с шагом 32 ГБ до достижения максимального размера. Первые 32 ГБ предоставляются бесплатно.

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

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

Нет, хранилище резервных копий не вычитается из места хранения управляемого экземпляра SQL. Хранилище резервных копий не зависит от места хранения экземпляра и не ограничивается размером. Хранилище резервных копий имеет ограничения по времени, в течение которого будет храниться резервная копия ваших баз данных экземпляра. Можно задать срок хранения до 35 дней. Дополнительные сведения см. в статье об автоматическом резервном копировании.

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

Да, вы можете создать резервную копию только для копирования в хранилище BLOB-объектов Azure, но ее можно восстановить только в управляемом экземпляре SQL. Дополнительные сведения см. в статье о резервных копиях только для копирования. Однако резервную копию только для копирования сделать невозможно, если база данных шифруется с помощью TDE, управляемых службой, так как сертификат, используемый для шифрования, недоступен. В таком случае используйте функцию восстановления на определенный момент времени, чтобы переместить базу данных в другой управляемый экземпляр SQL или переключиться на управляемый клиентом ключ.

Да, она поддерживается и доступна для версий SQL Server 2005+. Чтобы использовать собственное восстановление, загрузите BAK-файл в хранилище BLOB-объектов Azure и выполните команды T-SQL. Дополнительные сведения см. в статье Собственное восстановление из URL-адреса.

Да, но только sql Server 2022 в течение основного периода поддержки SQL Server 2022. Возможно, в будущем некоторые функции Управляемый экземпляр SQL Azure могут быть введены, которые требуют изменений в формате базы данных, что делает резервные копии несовместимыми с последней версией SQL Server. Для доступа к таким функциям требуется явное согласие.

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

Необходимые правила NSG и UDR описаны в конфигурации подсети, предоставляемой службой, и автоматически устанавливаются службой. Имейте в виду, что эти правила являются только теми, которые нам нужны для обслуживания службы. Чтобы подключиться к управляемому экземпляру SQL и использовать различные функции, необходимо задать другие правила для конкретных функций и поддерживать их.

Как настроить правила NSG для входящего трафика на портах управления?

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

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

Да. После подготовки управляемого экземпляра SQL можно задать группу безопасности сети, которая управляет входящим доступом к порту 1433. Рекомендуется максимально сократить диапазон IP-адресов.

№ Это не поддерживается по нескольким причинам:

• Маршрутизация трафика, представляющего ответ на запрос на входящий трафик, будет асимметричным и не может работать.
• Маршрутизация трафика в служба хранилища Azure будет влиять на ограничения пропускной способности и задержку, поэтому таким образом мы не сможем обеспечить ожидаемое качество и доступность служб.
• Эти конфигурации подвержены ошибкам и не поддерживаются.

Да. Самый простой способ — добавить правило 0/0 в UDR, связанное с подсетью управляемого экземпляра SQL, для маршрутизации трафика через NVA.

Подсеть должна иметь достаточное количество доступных IP-адресов. Сведения о том, как определить размер подсети виртуальной сети для Управляемого экземпляра SQL, см. в статье "Определение требуемого размера и диапазона подсети для Управляемого экземпляра SQL Azure".

Если в подсети, где подготовлен управляемый экземпляр SQL, не хватает IP-адресов , создайте новую подсеть и переместите в него управляемый экземпляр SQL. Рекомендуем также создать подсеть с дополнительными выделенными IP-адресами, чтобы избежать подобных проблем в будущих операциях обновления. Узнайте, как перемещать Управляемый экземпляр SQL Azure между подсетями.

№ Можно использовать пустую подсеть или подсеть, которая уже содержит управляемые экземпляры.

Нет, если в ней есть управляемые экземпляры. Это ограничение сетевой инфраструктуры Azure. Вы можете добавить дополнительное адресное пространство только в пустую подсеть.

Да. Управляемый экземпляр SQL можно переместить в другую подсеть внутри той же виртуальной сети или в другой виртуальной сети в сети. Узнайте, как перемещать Управляемый экземпляр SQL Azure между подсетями.

Это не обязательно. Можно либо создать виртуальную сеть для Управляемого экземпляра SQL Azure, либо настроить существующую виртуальную сеть для Управляемого экземпляра SQL Azure.

№ В настоящее время мы не поддерживаем размещение управляемого экземпляра SQL в подсети, которая уже содержит другие типы ресурсов.

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

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

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

По этой причине доступ к виртуальным сетям и общедоступным конечным точкам должен осуществляться только через связанные доменные имена. Настоятельно не рекомендуется полагаться на неизменяемость ip-адреса, так как это может привести к длительной недоступности в то время как служба работает.

Если требуется статический IP-адрес, доступный за пределами виртуальной сети, можно развернуть брандмауэр Azure с внешним общедоступным IP-адресом и настроить правило NAT для перевода входящего трафика в частную конечную точку управляемого экземпляра SQL. Затем настройте разрешение DNS или настройте псевдонимы клиентов, чтобы клиенты SQL подключались к общедоступному IP-адресу брандмауэра через полное доменное имя управляемого экземпляра SQL.

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

Нет, использование пользовательского порта недоступно. Для локальных конечных точек виртуальной сети Управляемый экземпляр SQL использует номер порта по умолчанию 1433 и для конечных точек общедоступных данных, управляемый экземпляр SQL использует номер порта по умолчанию 3342.

Пиринг между глобальной виртуальной сетью и виртуальная глобальная сеть Azure рекомендуются для подключения двух управляемых экземпляров в разных регионах. Пиринг каналов Express Route является альтернативным вариантом. Если ни один из вариантов в вашей среде недоступен, единственным другим методом подключения является VPN-подключение типа "сеть — сеть". Настройка VPN типа "сеть — сеть" с помощью портал Azure, PowerShell или Azure CLI

Поддержка пиринга глобальной виртуальной сети для вновь созданных виртуальных кластеров была добавлена в Управляемый экземпляр SQL Azure 22 сентября 2020 г. Таким образом, пиринг между виртуальными сетями поддерживается для управляемых экземпляров, созданных в пустых подсетях после 22 сентября 2020 г. Для экземпляров, развернутых до этой даты, поддержка пиринга ограничена сетями в одном регионе из-за ограничений пиринга глобальной виртуальной сети. Дополнительные сведения см. в соответствующем разделе часто задаваемых вопросов о виртуальная сеть Azure.

Чтобы использовать пиринг глобальной виртуальной сети с экземплярами, созданными до сентября 2020 года, учитывая настройку периода обслуживания. Кроме того, попробуйте переместить экземпляр в новую подсеть. Любой из вариантов перемещает экземпляр в новый виртуальный кластер, поддерживающий пиринг глобальной виртуальной сети.

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

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

• Включите прозрачное шифрование данных (TDE) во всех базах данных.
• Выключите среду CLR. Этот параметр также рекомендуется использовать локально.
• Используйте только проверку подлинности Microsoft Entra.
• Получите доступ к экземпляру через привилегированные учетные записи администратора баз данных с низким уровнем.
• Настройте доступ к JiT-Jumpbox для учетной записи системного администратора.
• Включите аудит SQL и интегрируйте его с механизмами предупреждений.
• Включите обнаружение угроз из пакета Microsoft Defender для SQL.
• Примените политику конечной точки службы к подсети, чтобы контролировать исходящий трафик к служба хранилища Azure.
• CREATE EXTERNAL TABLE AS SELECT (CETAS) отключен по умолчанию. Сведения о включении CETAS с помощью параметра конфигурации сервера см. в allowPolyBaseExport разделе CREATE EXTERNAL TABLE AS SELECT (CETAS).

Да. См. раздел "Разрешение частных DNS-имен" в Управляемый экземпляр SQL Azure.

Да. См. раздел "Разрешение частных DNS-имен" в Управляемый экземпляр SQL Azure.

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

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

Да, клиенты могут создавать имена входа, которые являются членами роли sysadmin . Клиенты, которые принимают привилегию sysadmin , также несут ответственность за эксплуатацию экземпляра, что может негативно повлиять на обязательство об уровне обслуживания. Чтобы добавить имя входа в роль сервера sysadmin , ознакомьтесь с проверкой подлинности Microsoft Entra.

Да, Управляемый экземпляр SQL Azure поддерживает прозрачное шифрование данных (TDE). Дополнительные сведения см. в статье Прозрачное шифрование данных для управляемого экземпляра SQL.

Да, Azure Key Vault для сценария BYOK доступен для управляемого экземпляра SQL Azure. Дополнительные сведения см. в статье Прозрачное шифрование данных Azure SQL с ключом, управляемым клиентом

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

Для переноса зашифрованных баз данных TDE можно также использовать Azure Database Migration Service.

Можно выполнить смену предохранителя TDE для управляемого экземпляра SQL с помощью Azure Cloud Shell. Как это сделать см. в статье Прозрачное шифрование данных в управляемом экземпляре SQL с использованием собственного ключа из Azure Key Vault.

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

• Отправить предохранитель сертификата в управляемый экземпляр SQL. Это можно сделать только с помощью PowerShell. Весь процесс см. в примере скрипта.
• Отправить асимметричный предохранитель ключа в Azure Key Vault (AKV) и указать для него управляемый экземпляр SQL. Этот подход напоминает вариант использования TDE с собственным ключом (BYOK), который также использует интеграцию Key Vault для хранения ключа шифрования. Если вы не хотите использовать ключ в качестве средства защиты ключей шифрования и просто хотите сделать ключ доступным для управляемого экземпляра SQL для восстановления зашифрованных баз данных, следуйте инструкциям по настройке BYOK TDE и не установите флажок Сделать выбранный ключ защищенным по умолчанию TDE.

После того как предохранитель шифрования станет доступным для Управляемого экземпляра SQL, можно приступить к стандартной процедуре восстановления базы данных.

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

Можно сэкономить с помощью преимуществ Azure SQL следующими способами.

• Максимально использовать существующие инвестиции в лицензии на локальное развертывание и сэкономить до 55% с преимуществом гибридного использования Azure.
• Зафиксируйте резервирование вычислительных ресурсов и сохраните до 33 процентов с преимуществами резервирования Azure. Объедините это преимущество с преимуществом гибридного использования Azure для экономии до 82 процентов.
• Сэкономить до 55% от цены в прейскуранте с преимуществом цены на разработку и тестирование Azure , которое предлагает скидки для текущих рабочих нагрузок разработки и тестирования.

Чтобы получить право на преимущество зарезервированного экземпляра, нужно выбрать подписку с соглашением Enterprise (номера предложений: MS-AZR-0017P или MS-AZR-0148P) или отдельного соглашения с оплатой по мере использования (номера предложений: MS-AZR-0003P или MS-AZR 0023P). Дополнительные сведения о резервированиях см. в резервирования Azure.

Вы можете отменить и обменять резервирования, а также вернуть вложенные в резервирование средства, но при этом применяются определенные ограничения. Дополнительные сведения см. в статье Self-service exchanges and refunds for Azure Reservations (Самостоятельное выполнение обмена и возмещения средств для резервирований Azure).

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

Это можно сделать с помощью решения Microsoft Cost Management. В списке служб на портале Azure перейдите к разделу Подписки и выберите Анализ затрат.

Выберите параметр Накопленные затраты, а затем выполните фильтрацию по типу ресурса как microsoft.sql/managedinstances.

Вы можете использовать совместимые клиентские средства Майкрософт или сторонних производителей для доступа к Управляемый экземпляр SQL, и вы не будете взимать дополнительные расходы в счете Azure. Однако если для некоторых средств требуется лицензия, вам необходимо иметь лицензирование программного обеспечения. Это требование регулируется отдельными соглашениями, которые у вас есть с каждым производителем инструментов.

Вы получаете столько же места в хранилище резервных копий бесплатно, сколько места было приобретено и зарезервировано в хранилище данных, независимо от установленного срока хранения резервной копии. Если потребление хранилища резервных копий находится в выделенном свободном хранилище резервных копий, автоматические резервные копии в Управляемом экземпляре SQL не являются дополнительными затратами и поэтому бесплатно. Превышение использования хранилища резервных копий над свободным пространством приводит к дополнительным затратам. Дополнительные сведения см. в разделе "Хранилище резервных копий" на странице с ценами. Дополнительную техническую информацию об автоматизированном резервном копировании управляемого экземпляра SQL см. в статье Сведения об использовании хранилища резервных копий.

Затраты на хранилище резервных копий можно отслеживать на портале Azure. Инструкции см. в статье Мониторинг затрат на автоматически создаваемые резервные копии.

Сведения об оптимизации затрат на хранилище резервных копий см. в статье "Точное настройка затрат на хранилище резервных копий" в Управляемом экземпляре SQL.

Чтобы получить более полное представление о преимуществах, затратах и рисках, связанных с развертыванием управляемого экземпляра SQL Azure, можно также ознакомиться с исследованием Forrester: Общее экономическое влияние баз данных управляемого экземпляра SQL Microsoft Azure.

Политика паролей управляемого экземпляра SQL для имен входа SQL наследует политики платформы Azure, применяемые к виртуальным машинам, формируя виртуальный кластер с управляемым экземпляром SQL. На данный момент невозможно изменить любой из этих параметров, так как эти параметры определяются Azure и наследуются управляемым экземпляром SQL.

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

Да, можно управлять CHECK_POLICY и CHECK_EXPIRATION полями на уровне входа. Текущие параметры можно проверить, выполнив следующую команду T-SQL:

SELECT *
FROM sys.sql_logins

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

ALTER LOGIN <login_name> WITH CHECK_POLICY = OFF;
ALTER LOGIN <login_name> WITH CHECK_EXPIRATION = OFF;

(Замените 'test' на требуемое имя для входа и настройте параметры политики и срока действия.)

См. статью Смена сертификатов для Базы данных SQL Azure и управляемого экземпляра SQL.

См. статью Планирование событий обслуживания Azure в управляемом экземпляре SQL.

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

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

Сведения о создании запроса на поддержку Azure см. в статье "Создание запроса на поддержку Azure".

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

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

Нет, обновление уровня служб общего назначения next-gen в настоящее время не поддерживается для пулов экземпляров или экземпляров в пуле.