Pertanyaan umum (FAQ) tentang SQL Managed Instance

Untuk daftar fitur yang didukung di SQL Managed Instance, lihat Fitur Azure SQL Managed Instance.

Untuk perbedaan sintaks dan perilaku antara Azure SQL Managed Instance dan SQL Server, lihat Perbedaan T-SQL dari SQL Server.

Untuk karakteristik perangkat keras yang tersedia, lihat Perbedaan teknis dalam konfigurasi perangkat keras. Untuk tingkat layanan yang tersedia dan karakteristiknya, lihat Perbedaan teknis antara tingkat layanan.

Setiap pelanggan memenuhi syarat untuk tingkat layanan apa pun. Edisi Standar dan Perusahaan yang dicakup dengan Jaminan Perangkat Lunak dapat ditukar dengan menggunakan Azure Hybrid Benefit (AHB) untuk Tujuan Umum (yang mencakup peningkatan tingkat layanan Tujuan Umum Generasi Berikutnya, saat ini dalam pratinjau) atau tingkat layanan Business Critical menggunakan rasio pertukaran berikut 1 edisi Standar = 1 Tujuan Umum, 1 edisi Enterprise = 1 Bisnis Penting, 1 Edisi Perusahaan = 4 Tujuan Umum, dan 4 Tujuan Umum = 1 Edisi Perusahaan. Untuk informasi selengkapnya, lihat Hak khusus AHB.

Untuk daftar tipe langganan yang didukung, lihat Tipe langganan yang didukung.

Instans terkelola dapat dibuat di sebagian besar wilayah Azure; lihat Wilayah yang didukung untuk SQL Managed Instance. Jika Anda memerlukan instans terkelola di wilayah yang saat ini tidak didukung, kirim permintaan dukungan melalui portal Azure.

SQL Managed Instance memiliki dua batas default: batas jumlah subnet yang dapat Anda gunakan dan batas jumlah vCore yang dapat Anda provisikan. Batas bervariasi di seluruh tipe dan wilayah langganan. Untuk daftar batasan sumber daya kawasan menurut tipe langganan, lihat tabel dari batasan sumber daya regional. Ini adalah batas lunak yang dapat ditingkatkan sesuai permintaan. Jika Anda perlu menyediakan lebih banyak instans terkelola di wilayah Anda saat ini, kirim permintaan dukungan untuk menambah kuota menggunakan portal Azure. Untuk informasi selengkapnya, lihat Meminta peningkatan kuota untuk Azure SQL Database.

Batas 100 database per SQL Managed Instance adalah batas keras yang tidak dapat diubah di tingkat layanan Tujuan Umum dan Bisnis Penting. Anda dapat memiliki hingga 500 database di tingkat layanan Tujuan Umum Next-gen.

Anda dapat mempertimbangkan untuk bermigrasi ke rasa Azure lain yang sesuai dengan beban kerja Anda: Azure SQL Database Hyperscale atau SQL Server di Azure Virtual Machines.

Anda dapat mempertimbangkan untuk bermigrasi ke SQL Server di Azure Virtual Machines atau memori/cpu Azure SQL Database yang dioptimalkan.

Untuk cacat produk dan masalah yang diketahui, lihat Masalah yang diketahui.

Untuk fitur baru dan pratinjau, lihat Yang baru.

Anda dapat memprovisikan instans terkelola dari portal Microsoft Azure, PowerShell, Azure CLI, dan template ARM.

Ya, Anda dapat memprovisikan instans terkelola dalam langganan yang ada jika langganan tersebut termasuk dalam Jenis langganan yang didukung.

Ini adalah batasan saat ini pada komponen dasar yang memverifikasi nama subnet terhadap regex ^[a-zA-Z_][^\/:*?"<>|`'^]*(?<![.\s])$. Semua nama yang lulus regex dan merupakan nama subnet yang valid saat ini didukung.

Anda dapat menskalakan instans terkelola Anda dari portal Azure, PowerShell, Azure CLI atau templat ARM.

Ya, Anda bisa. Untuk mengetahui petunjuknya, lihat Memindahkan sumber daya di seluruh wilayah.

Anda dapat menghapus instans terkelola melalui portal Microsoft Azure, PowerShell, Azure CLI atau REST API Resource Manager.

Waktu yang diharapkan untuk membuat instans terkelola baru atau untuk mengubah tingkat layanan (vCores, penyimpanan), tergantung pada beberapa faktor. Lihat Operasi Manajemen.

Memulihkan setiap database dijamin selama seluruh periode retensi yang ditentukan - bahkan database yang dibuat lalu dihapus hanya setelah beberapa detik. Ketika database dibuat, dihapus, atau dipulihkan, cadangan diambil pada interval yang berbeda untuk menyimpan data sehingga dimungkinkan untuk memulihkannya selama periode retensi yang diberikan. Jika database dihilangkan sebelum operasi pencadangan selesai, operasi penghilangan mungkin diblokir dengan kesalahan berikut:

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

Untuk menghindari kesalahan ini, periksa status operasi penghilangan sebelum membuat kembali database dengan nama yang sama. Untuk informasi selengkapnya, harap lihat sys.dm_operation_status. Setelah status operasi menunjukkan Selesai, dimungkinkan untuk MEMULIHKAN atau MEMBUAT database dengan nama yang sama.

Kasus penggunaan umum berikut cenderung mengalami kesalahan ini:

• Jika beberapa database dihilangkan dan dibuat lagi dengan nama yang sama dalam waktu singkat berturut-turut. Ketika database dihilangkan, ujung ekor yang tersisa dari log transaksi dicadangkan secara sinkron sebelum operasi penghilangan selesai, seperti yang ditunjukkan pada gambar:

  

  Tidak mungkin untuk membuat database dengan nama yang sama sampai log ekor dicadangkan dan operasi penghilangan selesai. Sifat operasi penghilangan yang berurutan menempatkan database yang dihilangkan secara berurutan dalam waktu singkat ke dalam antrian, yang dapat memperpanjang proses penghilangan database dan menunda kemungkinan membuat yang baru menggunakan nama yang sama.

• Jika database dipulihkan dan dihilangkan sebelum cadangan penuh dibuat. Ketika database dipulihkan, langkah pertama dari proses pemulihan adalah mengambil cadangan penuh baru dari database. Jika Anda mencoba memulihkan database, lalu menghilangkannya segera sebelum pencadangan penuh selesai, Anda tidak akan dapat menghilangkan database dan membuat database lain dengan nama yang sama sampai pencadangan penuh diambil, dan operasi penghapusan database selesai. Tergantung pada ukuran database, cadangan penuh dapat memakan waktu berjam-jam.

Ada kemungkinan langganan Anda tidak memenuhi syarat untuk SQL Managed Instance gratis. Jika tidak, ada batas satu instans gratis per langganan. Anda perlu menghapus instans gratis yang ada untuk membuat instans lain. Jika Anda baru saja menghapus instans gratis, diperlukan waktu hingga satu jam agar banner penawaran gratis muncul kembali.

Kemungkinan Anda kehabisan kredit untuk bulan itu. Buka instans terkelola SQL Anda di portal Azure dan periksa status untuk melihat apakah instans Anda dalam keadaan dihentikan karena kredit yang tidak mencukup.

Fungsionalitas ini saat ini tidak tersedia.

Ya, Anda dapat memulihkan cadangan otomatis dari penyimpanan Azure, atau Anda dapat Memulihkan cadangan database dengan menggunakan SQL Server Management Studio (SSMS).

Terlepas dari keterbatasan sumber daya, SQL Managed gratis dirancang untuk memungkinkan Anda menguji beban kerja tanpa dampak apa pun. Performa yang Anda alami saat menggunakan SQL Managed Instance gratis identik dengan performa versi produksi instans.

SQL Managed Instance gratis menawarkan opsi 4 dan 8 vCore. Jika bisnis Anda memerlukan instans dengan lebih banyak sumber daya, buat SQL Managed Instance berbayar sepenuhnya.

Opsi pencadangan tidak dapat diubah untuk SQL Managed Instance gratis.

Saat ini, langganan Siswa tidak memenuhi syarat. Untuk langganan yang memenuhi syarat, tinjau prasyarat penawaran SQL Managed Instance gratis.

Mengubah nama instans terkelola tidak didukung.

Ya, zona DNS default SQL Managed Instance .database.windows.net dapat diubah dengan zona DNS Anda sendiri. Tetapi, bagian nama host instans terkelola dari FQDN nama host instans terkelola harus tetap sama.

Untuk menggunakan zona DNS lain dan bukan default, misalnya, .contoso.com:

• Gunakan Utilitas Jaringan Klien SQL Server (CliConfg) untuk menentukan alias. Anda dapat menggunakan nama host instans terkelola saja, atau nama host instans terkelola diikuti dengan nama domain kustom. Alat CliConfg hanya menambahkan alias dalam registri di bagian "HKLM\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo" atau "HKLM\SOFTWARE\WOW6432Node\Microsoft\MSSQLServer\Client\ConnectTo" tergantung jika Anda menggunakan versi 64-bit (C :\Windows\System32\cliconfg.exe) atau versi 32-bit (C:\Windows\SysWOW64\cliconfg.exe), sehingga hal ini dapat dilakukan menggunakan kebijakan grup atau juga skrip. Gunakan keduanya untuk memastikan program 32-bit dan 64-bit dapat menyelesaikan alias.
• Gunakan data CNAME dalam DNS dengan nama host instans terkelola yang mengarah ke FQDN instans terkelola. Dalam hal ini, TrustServerCertificate=TRUE diperlukan saat menggunakan autentikasi dengan MICROSOFT Entra ID (sebelumnya Azure Active Directory).
• Gunakan data A dalam DNS dengan nama host instans terkelola yang mengarah ke alamat IP instans terkelola. Menggunakan alamat IP tidak disarankan, karena dapat berubah tanpa pemberitahuan. Dalam hal ini, TrustServerCertificate=TRUE diperlukan saat menggunakan autentikasi Microsoft Entra.

Azure SQL Managed Instance menawarkan tingkat performa yang sama setiap komputasi dan ukuran penyimpanan seperti opsi penyebaran lainnya dari Azure SQL Database. Jika Anda ingin menggabungkan data pada satu instans, atau Anda hanya memerlukan fitur yang didukung secara eksklusif di SQL Managed Instance, Anda dapat memigrasikan data Anda dengan menggunakan fungsionalitas ekspor/impor (BACPAC). Berikut adalah cara lain untuk mempertimbangkan migrasi Database SQL ke SQL Managed Instance:

• Menggunakan Sumber Data Eksternal
• Menggunakan sqlpackage.exe
• Menggunakan BCP

Salah satu opsinya adalah mengekspor database ke BACPAC lalu mengimpor file BACPAC. Ini adalah pendekatan yang disarankan jika database Anda lebih kecil dari 100 GB.

Replikasi transaksional dapat digunakan jika semua tabel dalam database memiliki kunci utama dan tidak ada objek OLTP dalam memori di database.

Untuk memigrasikan instans SQL Server Anda, lihat Panduan SQL Server ke Azure SQL Managed Instance.

Untuk informasi migrasi tentang migrasi dari platform lain, lihat Panduan Migrasi Database Azure.

Untuk perbandingan performa antara instans terkelola dan SQL Server, titik awal yang baik adalah artikel Praktik terbaik untuk perbandingan performa antara Azure SQL Managed Instance dan SQL Server.

Lihat Penyebab utama perbedaan performa antara SQL Managed Instance dan SQL Server. Ukuran file log transaksi dapat memengaruhi performa General Purpose SQL Managed Instance. Untuk informasi selengkapnya, lihat Dampak ukuran file log pada Tujuan Umum.

Anda dapat mengoptimalkan performa instans terkelola Anda dengan:

• Penyetelan otomatis memberikan performa puncak dan beban kerja yang stabil melalui penyetelan performa berkelanjutan berdasarkan AI dan pembelajaran mesin.
• OLTP dalam memori yang meningkatkan throughput dan latensi pada beban kerja pemrosesan transaksional dan memberikan wawasan bisnis yang lebih cepat.
• Menerapkan beberapa praktik terbaik untuk penyetelan aplikasi dan database.
• Mengalihkan jenis koneksi dari proksi ke mode pengalihan untuk latensi yang lebih rendah dan throughput yang lebih tinggi, jika beban kerja Anda terdiri dari banyak transaksi kecil.

Untuk meningkatkan performa pada instans Tujuan Umum, pertimbangkan untuk meningkatkan ukuran file data. Untuk mengoptimalkan performa penyimpanan pada instans Tujuan Umum, lihat Panduan praktik terbaik Storage untuk tingkat Tujuan Umum.

Lihat Menganalisis statistik tunggu pada SQL Managed Instance. Statistik tunggu adalah informasi yang dapat membantu Anda memahami mengapa durasi kueri panjang dan mengidentifikasi kueri yang menunggu sesuatu di mesin database.

Untuk semua opsi yang mungkin untuk memantau dan memperingatkan konsumsi dan performa SQL Managed Instance, lihat posting blog opsi pemantauan Azure SQL Managed Instance. Untuk pemantauan performa secara real time untuk SQL Managed Instance, lihat Pemantauan performa secara real time untuk Azure SQL Managed Instance.

Lihat Pemantauan dan penyetelan performa.

Lihat Pemantauan performa secara real time untuk Azure SQL Managed Instance.

Ya, SQL Profiler didukung di SQL Managed Instance. Untuk informasi selengkapnya, lihat SQL Profiler. Tetapi, sebaliknya, Anda harus mempertimbangkan Extended Events untuk aktivitas "pelacakan" dengan dampak yang lebih kecil pada instans yang dipantau. Untuk informasi selengkapnya, lihat Extended Events.

Tidak, mereka tidak didukung. Anda bisa menggunakan DMV dan Query Store bersama dengan SQL Profiler dan XEvents untuk memantau database Anda.

Lihat Memantau penggunaan CPU di halaman SQL Server dan Azure SQL.

Ya. Untuk mengetahui petunjuknya, lihat Membuat pemberitahuan untuk ISQL Managed Instance. Untuk tips dan trik lainnya, lihat blog.

Anda tidak dapat, metrik pemberitahuan hanya tersedia untuk instans terkelola. Memperingatkan metrik untuk database individual dalam instans terkelola tidak tersedia.

Ukuran penyimpanan untuk SQL Managed Instance tergantung pada tingkat layanan yang dipilih (Tujuan Umum, Tujuan Umum Generasi Berikutnya, atau Bisnis Penting). Untuk batasan penyimpanan tingkat layanan ini, lihat Batas sumber daya.

Jumlah minimum penyimpanan yang tersedia dalam satu instans adalah 32 GB. Penyimpanan dapat ditambahkan dengan kenaikan 32 GB hingga ukuran penyimpanan maksimum. 32 GB pertama gratis.

Ya, Anda dapat membeli penyimpanan add-on, secara independen dari komputasi, sampai batas tertentu. Lihat Penyimpanan khusus instans maks dalam Tabel.

Untuk mengoptimalkan kinerja penyimpanan, lihat Praktik terbaik penyimpanan dalam Tujuan Umum.

Tidak, penyimpanan cadangan tidak dikurangi dari ruang penyimpanan instans terkelola Anda. Penyimpanan cadangan independen dari ruang penyimpanan instans dan ukurannya tidak terbatas. Penyimpanan cadangan dibatasi oleh periode waktu untuk mempertahankan pencadangan database instans Anda, dapat dikonfigurasi hingga 35 hari. Untuk detailnya, lihat Pencadangan otomatis.

Untuk melacak kapan pencadangan otomatis telah dilakukan pada instans terkelola SQL, tinjau Memantau aktivitas pencadangan.

Ya, Anda dapat membuat pencadangan penuh salinan-saja di Azure Blob Storage, tetapi pencadangan penuh salinan-saja hanya dapat dipulihkan ke instans terkelola. Untuk detailnya, lihat Pencadangan khusus salin. Namun, pencadangan khusus salinan tidak mungkin jika database dienkripsi oleh TDE yang dikelola layanan karena sertifikat yang digunakan untuk enkripsi tidak dapat diakses. Dalam kasus seperti itu, gunakan fitur pemulihan dari waktu tertentu untuk memindahkan database ke instans terkelola lainnya, atau beralih ke kunci yang dikelola pelanggan.

Ya, ini didukung dan tersedia untuk versi SQL Server 2005+. Untuk menggunakan pemulihan asli, unggah file .bak Anda ke Azure blob storage dan jalankan perintah T-SQL. Untuk informasi selengkapnya, lihat Pemulihan asli dari URL.

Ya, tetapi hanya untuk SQL Server 2022, selama periode dukungan mainstream SQL Server 2022. Ada kemungkinan bahwa, di masa mendatang, beberapa fitur Azure SQL Managed Instance mungkin diperkenalkan yang memerlukan perubahan pada format database, membuat cadangan tidak kompatibel dengan versi terbaru SQL Server. Akses ke fitur tersebut memerlukan keikutsertaan eksplisit.

Database sistem tidak direplikasi ke instans sekunder dalam grup failover. Oleh karena itu, skenario yang bergantung pada objek dari database sistem tidak mungkin pada instans sekunder kecuali objek dibuat secara manual pada sekunder. Untuk penanganan masalah, lihat Mengaktifkan skenario tergantung pada objek dari database sistem.

Aturan NSG dan UDR yang diperlukan didokumentasikan di sini, dan secara otomatis ditetapkan oleh layanan. Perlu diingat bahwa aturan ini hanyalah yang kita butuhkan untuk mempertahankan layanan. Untuk menyambungkan ke instans Anda dan menggunakan fitur berbeda, Anda perlu mengatur aturan khusus fitur tambahan, yang perlu Anda pertahankan.

SQL Managed Instance bertanggung jawab untuk menetapkan aturan pada port manajemen. Yang dicapai melalui fungsionalitas bernama konfigurasi subnet yang dibantu layanan. Hal ini untuk memastikan arus lalu lintas manajemen yang tidak terganggu dalam rangka pemenuhan SLA.

Ya. Anda dapat menganalisis lalu lintas yang masuk melalui grup keamanan jaringan Anda dengan mengonfigurasi log aliran Network Watcher.

Ya. Setelah instans terkelola disediakan, Anda dapat mengatur NSG yang mengontrol akses masuk ke port 1433. Disarankan untuk mempersempit rentang IP-nya sebanyak mungkin.

Tidak. Ini tidak didukung karena beberapa alasan:

• Merutekan lalu lintas yang mewakili respons terhadap permintaan manajemen masuk akan asimetris dan tidak dapat berfungsi.
• Lalu lintas perutean ke Azure Storage akan dipengaruhi oleh kendala dan latensi throughput sehingga dengan cara ini kami tidak akan dapat memberikan kualitas dan ketersediaan layanan yang diharapkan.
• Konfigurasi ini rawan kesalahan dan tidak dapat didukung.

Ya. Cara paling sederhana untuk mencapai hal ini adalah dengan menambahkan aturan 0/0 ke UDR yang terkait dengan subnet instans terkelola untuk merutekan lalu lintas melalui NVA.

Subnet harus memiliki alamat IP yang tersedia dalam jumlah yang memadai. Guna menentukan ukuran subnet VNet untuk SQL Managed Instance, lihat Menentukan ukuran dan rentang subnet yang diperlukan untuk Azure SQL Managed Instance.

Jika tidak ada cukup alamat IP di subnet tempat instans terkelola SQL Anda disediakan, buat subnet baru dan pindahkan instans terkelola SQL ke dalamnya. Kami menyarankan agar subnet baru dibuat dengan lebih banyak alokasi alamat IP agar masalah serupa dapat dihindari pada operasi pembaruan di masa mendatang. Pelajari cara memindahkan Azure SQL Managed Instance di seluruh subnet.

Tidak. Anda dapat menggunakan subnet kosong atau subnet yang sudah berisi instans terkelola.

Tidak, jika terdapat instans terkelola di dalamnya. Ini adalah keterbatasan infrastruktur jaringan Azure. Anda hanya diizinkan untuk menambahkan ruang alamat tambahan ke subnet kosong.

Ya. Instans terkelola SQL dapat dipindahkan ke subnet lain di dalam jaringan virtual yang sama atau di jaringan virtual yang berbeda dengan cara online. Pelajari cara memindahkan Azure SQL Managed Instance di seluruh subnet.

Ini tidak diperlukan. Anda dapat Membuat jaringan virtual untuk Azure SQL Managed Instance atau Mengonfigurasi jaringan virtual yang ada untuk Azure SQL Managed Instance.

Tidak. Saat ini kami tidak mendukung penempatan instans terkelola di subnet yang sudah berisi jenis sumber daya lainnya.

Tidak, ini tidak didukung. Nama host instans terkelola memetakan ke load balancer di depan kluster virtual instans terkelola. Karena satu kluster virtual dapat menghosting beberapa instans terkelola, koneksi tidak dapat dirutekan ke instans terkelola yang tepat tanpa menentukan namanya. Untuk informasi selengkapnya tentang arsitektur klaster virtual SQL Managed Instance, lihat Arsitektur konektivitas klaster virtual.

Saat ini, hanya titik akhir privat ke instans terkelola yang menjamin alamat IP statis.

Dalam situasi yang jarang terjadi tetapi perlu, kita mungkin melakukan migrasi online instans terkelola ke kluster virtual baru, atau grup komputer virtual yang berbeda dalam kluster virtual, karena perubahan tumpukan teknologi yang bertujuan untuk meningkatkan keamanan dan keandalan layanan. Migrasi ke grup komputer virtual atau kluster virtual baru menghasilkan perubahan alamat IP yang dipetakan ke nama host instans terkelola. Layanan instans terkelola tidak menyediakan dukungan alamat IP statis, dan berhak untuk mengubah alamat IP tanpa pemberitahuan, sebagai bagian dari siklus pemeliharaan reguler.

Untuk alasan di atas, titik akhir VNet-lokal dan publik hanya boleh diakses melalui nama domain terkait. Kami sangat mencegah kekekalan mengandalkan kekekalan alamat IP mereka karena melakukannya dapat menyebabkan ketidaktersediaan yang berkepanjangan saat layanan sehat.

Jika Anda memerlukan alamat IP statis yang dapat dijangkau dari luar jaringan virtual, Anda dapat menyebarkan Azure Firewall dengan alamat IP publik frontend dan mengonfigurasi aturan NAT untuk menerjemahkan lalu lintas masuk ke titik akhir privat instans terkelola. Kemudian, siapkan resolusi DNS atau konfigurasikan alias klien sehingga klien SQL terhubung ke alamat IP publik firewall melalui nama domain instans terkelola yang sepenuhnya memenuhi syarat.

Ya, titik akhir publik dapat diaktifkan untuk mengaktifkan lalu lintas masuk dari Internet untuk mencapai SQL Managed Instance. Untuk informasi selengkapnya, lihat Menggunakan SQL Managed Instance dengan titik akhir publik dan Mengonfigurasi titik akhir publik di SQL Managed Instance.

Tidak, menggunakan port kustom tidak tersedia. Untuk titik akhir VNet-lokal, SQL Managed Instance menggunakan nomor port default 1433 dan untuk titik akhir data publik, SQL Managed Instance menggunakan nomor port default 3342.

Baik peering jaringan virtual global (peering VNet) dan Azure virtual WAN adalah metode yang direkomendasikan untuk menghubungkan dua instans terkelola di wilayah yang berbeda. Peering sirkuit Express Route adalah opsi alternatif. Jika tidak ada opsi yang dimungkinkan di lingkungan Anda, satu-satunya metode konektivitas lainnya adalah koneksi VPN Situs-ke-Situs. Mengonfigurasi VPN Situs-ke-Situs dengan menggunakan portal Azure, PowerShell, atau Azure CLI

Dukungan untuk peering jaringan virtual global (peering VNet) untuk kluster virtual yang baru dibuat ditambahkan ke Azure SQL Managed Instance pada 22 September 2020. Dengan demikian, peering jaringan virtual didukung untuk instans terkelola yang dibuat dalam subnet kosong setelah 22 Sep 2020. Untuk instans yang disebarkan sebelum tanggal ini, dukungan peering terbatas pada jaringan dalam wilayah yang sama karena kendala peering jaringan virtual global. Untuk informasi selengkapnya, tinjau bagian yang relevan dari tanya jawab umum Azure Virtual Networks.

Untuk menggunakan peering VNet global dengan instans yang dibuat sebelum Sept 2020, pertimbangkan untuk mengonfigurasi jendela pemeliharaan atau memindahkan instans ke subnet baru karena salah satu opsi akan memindahkan instans ke kluster virtual baru yang mendukung peering jaringan virtual global.

Lihat cara memeriksa apakah peering jaringan virtual global didukung pada kluster virtual jika diperlukan.

Untuk mengurangi risiko eksfiltrasi data, pelanggan disarankan untuk menerapkan serangkaian pengaturan dan kontrol keamanan:

• Aktifkan Enkripsi Data Transparan (TDE) di semua database.
• Menonaktifkan Common Language Runtime (CLR). Cara ini juga direkomendasikan di tempat.
• Gunakan autentikasi Microsoft Entra saja.
• Akses instans dengan akun DBA dengan hak istimewa rendah.
• Mengonfigurasi akses jumpbox JIT untuk akun sysadmin.
• Aktifkan audit SQL, dan integrasikan dengan mekanisme pemberitahuan.
• Aktifkan Deteksi Ancaman dari rangkaian Pertahanan Microsoft untuk SQL.
• Terapkan kebijakan titik akhir layanan ke subnet untuk mengontrol lalu lintas keluar ke Azure Storage.
• CREATE EXTERNAL TABLE AS SELECT (CETAS) dinonaktifkan secara default. Untuk mengaktifkan CETAS melalui allowPolyBaseExport opsi konfigurasi server, lihat CREATE EXTERNAL TABLE AS SELECT (CETAS).

Ya. Lihat Mengatasi nama DNS privat di Azure SQL Managed Instance.

Ya. Lihat Mengatasi nama DNS privat di Azure SQL Managed Instance.

Konfigurasi zona waktu dapat diatur saat instans terkelola disediakan untuk pertama kalinya. Mengubah zona waktu instans terkelola yang ada tidak didukung. Untuk detailnya, lihatBatasan zona waktu.

Penanganan masalah termasuk membuat instans terkelola baru dengan zona waktu yang tepat lalu melakukan pencadangan dan pemulihan manual, atau apa yang kami rekomendasikan, melakukan pemulihan dari waktu tertentu lintas-instans.

Ya, pelanggan dapat membuat login yang tergabung dalam peran sysadmin. Pelanggan yang menganggap hak istimewa sysadmin juga berasumsi bertanggung jawab untuk mengoperasikan instans, yang dapat berdampak negatif pada komitmen SLA. Untuk menambahkan login ke peran server sysadmin, lihat Autentikasi Microsoft Entra.

Ya, Azure SQL Managed Instance mendukung Transparent Data Encryption (TDE). Untuk penjelasannya, lihat Enkripsi Data Transparan untuk SQL Managed Instance.

Ya, skenario Azure Key Vault for BYOK tersedia untuk Azure SQL Managed Instance. Untuk detailnya, lihat Enkripsi Data Transparan dengan kunci yang dikelola pelanggan.

Ya, Anda bisa. Untuk memigrasikan database SQL Server terenkripsi, Anda perlu mengekspor dan mengimpor sertifikat yang ada ke SQL Managed Instance, lalu mengambil cadangan database lengkap dan memulihkannya ke instans terkelola.

Anda juga bisa menggunakan Azure Database Migration Service untuk memigrasikan database terenkripsi TDE.

Anda dapat memutar pelindung TDE untuk SQL Managed Instance menggunakan Azure Cloud Shell. Untuk mengetahui petunjuknya, lihat Enkripsi Data Transparan di SQL Managed Instance menggunakan kunci Anda sendiri dari Azure Key Vault.

Ya, Anda tidak perlu mendekripsi database Anda untuk memulihkannya ke SQL Managed Instance. Anda perlu memberikan sertifikat/ kunci yang digunakan sebagai pelindung kunci enkripsi pada sistem sumber ke SQL Managed Instance untuk dapat membaca data dari file cadangan terenkripsi. Ada dua cara yang mungkin bisa dilakukan:

• Unggah pelindung sertifikat ke SQL Managed Instance. Ini dapat dilakukan menggunakan PowerShell saja. Contoh skrip menjelaskan seluruh proses.
• Unggah pelindung kunci asimetris ke Azure Key Vault dan arahkan SQL Managed Instance. Pendekatan ini menyerupai kasus penggunaan TDE bring-your-own-key (BYOK) yang juga menggunakan integrasi Key Vault untuk menyimpan kunci enkripsi. Jika Anda tidak ingin menggunakan kunci sebagai pelindung kunci enkripsi, dan hanya ingin membuat kunci tersedia bagi SQL Managed Instance untuk memulihkan database terenkripsi, ikuti instruksi untuk mengatur BYOK TDE, dan jangan periksa kotak centang Jadikan kunci yang dipilih sebagai pelindung TDE default.

Setelah Anda membuat pelindung enkripsi tersedia untuk SQL Managed Instance, Anda dapat melanjutkan prosedur pemulihan database standar.

SQL Managed Instance menawarkan model pembelian berbasis vCore.

Anda dapat menghemat biaya dengan manfaat Azure SQL dengan cara berikut:

• Maksimalkan investasi yang ada dalam lisensi lokal dan hemat hingga 55 persen dengan Azure Hybrid Benefit.
• Berkomitmenlah pada reservasi untuk sumber daya komputasi dan hemat hingga 33 persen dengan Manfaat Instans Tercadangkan. Gabungkan ini dengan Azure Hybrid benefit untuk penghematan hingga 82 persen.
• Hemat hingga 55 persen dibandingkan harga daftar dengan Azure Dev/Test Pricing Benefit yang menawarkan potongan harga untuk beban kerja pengembangan dan pengujian yang sedang berlangsung.

Agar memenuhi syarat untuk mendapatkan manfaat Instans tercadangkan, jenis langganan Anda harus merupakan perjanjian perusahaan (nomor penawaran: MS-AZR-0017P atau MS-AZR-0148P) atau perjanjian individual dengan harga bayar sesuai permintaan (nomor penawaran: MS-AZR-0003P atau MS-AZR-0023P). Untuk informasi selengkapnya tentang reservasi, lihat Manfaat Instans Tercadangkan.

Anda dapat membatalkan, menukar, atau mengembalikan dana reservasi dengan batasan tertentu. Pelaari lebih lanjut - Pertukaran dan pengembalian dana layanan mandiri untuk reservasi Azure.

Untuk menjelajahi opsi harga SQL Managed Instance, lihat Halaman harga.

Anda dapat melakukannya menggunakan solusi Microsoft Cost Management. Navigasi ke Langganan di portal Azure dan pilih Analisis Biaya.

Gunakan opsi Akumulasi biaya lalu filter menurut tipe Sumber Daya sebagai microsoft.sql/managedinstances.

Anda dapat menggunakan alat klien Microsoft atau pihak ketiga yang kompatibel untuk mengakses SQL Managed Instance, dan Anda tidak akan dikenakan biaya tambahan apa pun pada faktur Azure Anda. Namun, jika beberapa alat memerlukan lisensi, Anda diharuskan memiliki perangkat lunak berlisensi hukum. Hal ini diatur oleh perjanjian terpisah yang Anda miliki dengan masing-masing produsen alat.

Anda mendapatkan jumlah ruang penyimpanan cadangan gratis yang sama dengan ruang penyimpanan data khusus yang dibeli, terlepas dari periode retensi yang ditetapkan. Jika konsumsi penyimpanan cadangan Anda berada dalam ruang penyimpanan cadangan gratis yang dialokasikan, pencadangan otomatis pada SQL Managed Instance tidak dikenakan biaya tambahan untuk Anda, oleh karena itu tidak akan dikenakan biaya. Melebihi penggunaan penyimpanan cadangan di atas ruang kosong menghasilkan biaya tambahan. Lihat bagian Penyimpanan cadangan pada halaman harga untuk detailnya. Informasi teknis selengkapnya tentang pencadangan otomatis SQL Managed Instance tersedia di Penjelasan penggunaan penyimpanan cadangan.

Anda dapat memantau biaya untuk penyimpanan cadangan melalui portal Azure. Untuk mengetahui petunjuknya, lihat Memantau biaya untuk pencadangan otomatis.

Untuk mengoptimalkan biaya penyimpanan cadangan Anda, lihat Menyempurnakan penyetelan cadangan pada SQL Managed Instance.

Studi kasus SQL Managed Instance:

• Komatsu
• KMD
• PowerDETAILS
• Semua naskah

Untuk mendapatkan pemahaman yang lebih baik tentang keuntungan, biaya, dan risiko yang terkait tentang menyebarkan Azure SQL Managed Instance, tersedia juga studi Forrester: Dampak Ekonomi Keseluruhan dari database Microsoft Azure SQL Managed Instance.

Kebijakan kata sandi SQL Managed Instance untuk login SQL mewarisi kebijakan platform Azure yang diterapkan pada VM yang membentuk klaster virtual yang memegang instans terkelola. Saat ini tidak dimungkinkan untuk mengubah pengaturan ini karena pengaturan ini ditentukan oleh Azure dan diwarisi oleh instans terkelola.

Setiap info masuk harus menetapkan kata sandi info masuk pada kredensial masuk, dan mengubah kata sandi info masuk setelah mencapai masa pakai maksimum.

Ya, dimungkinkan untuk mengontrol bidang CHECK_POLICY dan CHECK_EXPIRATION di tingkat login. Anda dapat memeriksa pengaturan saat ini dengan menjalankan perintah T-SQL berikut:

SELECT *
FROM sys.sql_logins

Setelah itu, Anda dapat memodifikasi pengaturan login tertentu dengan mengeksekusi :

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

(Ganti 'test' dengan ID masuk yang diinginkan dan sesuaikan nilai kebijakan dan kedaluwarsa.)

Lihat Rotasi sertifikat untuk Azure SQL Database & SQL Managed Instance.

Lihat Merencanakan untuk kejadian pemeliharaan Azure di SQL Managed Instance.

Anda dapat memilih fitur SQL Managed Instance baru atau membuat ide peningkatan baru di Forum Internet Umpan Balik SQL Managed Instance. Dengan cara ini Anda dapat berkontribusi pada pengembangan produk dan membantu kami memprioritaskan potensi peningkatan kami.

Untuk mempelajari cara membuat permintaan dukungan Azure, lihat Cara membuat permintaan dukungan Azure.

Semua wilayah, penawaran, dan jenis langganan mengaktifkan gelombang fitur mulai November 2023.

Gelombang fitur tersedia untuk instans dalam subnet yang memenuhi syarat. Jika Anda tidak melihat fitur baru, kemungkinan subnet tempat instans terkelola SQL Anda disebarkan tidak memenuhi syarat.