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

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

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

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

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

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

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

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

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

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

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

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

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

Управляемый экземпляр 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 на портале Azure и проверьте состояние. Проверьте, находится ли экземпляр в остановленном состоянии из-за нехватки кредитов.

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

Да, вы можете восстановить автоматические резервные копии из других управляемых экземпляров SQL или восстановить локальную резервную копию базы данных с помощью SQL Server Management Studio (SSMS) или выполнив RESTORE DATABASE команду и нацелив .bak файлы из хранилища Azure или контейнеров S3.

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

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

Бесплатный управляемый экземпляр SQL поддерживает только PITR до 7 дней. Другие параметры резервного копирования не могут быть изменены для бесплатного управляемого экземпляра 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 указывало на доменное имя локальной конечной точки VNet управляемого экземпляра SQL. В этом случае HostNameInCertificate=<VNet-local endpoint domain name> (рекомендуется) или TrustServerCertificate=TRUE требуется при использовании проверки подлинности Microsoft Entra.
• Используйте запись в DNS с именем узла управляемого экземпляра SQL, указывающим на IP-адрес управляемого экземпляра SQL. Использование IP-адреса не рекомендуется, так как оно может изменяться без уведомления. В этом случае HostNameInCertificate=<VNet-local endpoint domain name> (рекомендуется) или 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 хорошей отправной точкой будет статья Лучшие практики по сравнению производительности управляемого экземпляра Azure SQL и 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) во всех базах данных.
• Отключите Common Language Runtime (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. Дополнительные сведения см. в статье Прозрачное шифрование данных с ключом, управляемым клиентом

Да, вы можете. Чтобы перенести зашифрованную базу данных 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 и указать на него управляемый экземпляр SQL. Этот подход напоминает сценарий использования TDE с функцией "приноси свой ключ" (BYOK), который также использует интеграцию с Key Vault для хранения ключа шифрования. Если вы не хотите использовать ключ в качестве средства защиты ключей шифрования и просто хотите сделать ключ доступным для управляемого экземпляра SQL для восстановления зашифрованных баз данных, следуйте инструкциям по настройке BYOK TDE и не установите флажок Сделать выбранный ключ защищенным по умолчанию TDE.

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

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

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

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

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

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

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

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

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

Вы можете использовать совместимые клиентские средства Microsoft или сторонних производителей для доступа к управляемому экземпляру 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".

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

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