Pertanyaan umum (FAQ) tentang Azure SQL Managed Instance

Berlaku untuk:Azure SQL Managed Instance

Artikel ini berisi pertanyaan paling umum tentang Azure SQL Managed Instance.

Catatan

ID Microsoft Entra sebelumnya dikenal sebagai Azure Active Directory (Azure AD).

Fitur yang didukung

Di mana saya dapat menemukan daftar fitur yang didukung pada 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.

Spesifikasi teknis, batas sumber daya, dan batasan lainnya

Di mana saya dapat menemukan karakteristik teknis dan batas sumber daya untuk SQL Managed Instance?

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.

Tingkat layanan apa yang memenuhi syarat untuk saya?

Setiap pelanggan memenuhi syarat untuk tingkat layanan apa pun. Lisensi edisi Standar dan Perusahaan yang tercakup dalam Jaminan Perangkat Lunak dapat dialokasikan ke Mesin Database SQL Server dengan menggunakan Azure Hybrid Benefit (AHB) untuk tingkat layanan Tujuan Umum (yang mencakup peningkatan tingkat layanan Tujuan Umum Next-gen), atau untuk tingkat layanan Business Critical. Azure Hybrid Benefit menggunakan rasio pertukaran berikut: 1 Edisi Standar = 1 Tujuan Umum, 1 edisi Perusahaan = 1 Kritis Bisnis, 1 edisi Perusahaan = 4 Tujuan Umum, dan 4 Tujuan Umum = 1 Edisi Perusahaan. Untuk informasi selengkapnya, lihat Hak tertentu dari Azure Hybrid Benefit.

Jenis langganan apa yang didukung untuk SQL Managed Instance?

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

Wilayah Azure mana yang didukung?

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

Apakah ada batasan kuota untuk penyebaran SQL Managed Instance?

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 regional menurut jenis langganan, lihat tabel dari Batasan sumber daya Regional. Batas lunak ini 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.

Dapatkah saya meningkatkan jumlah batas database (100) pada instans terkelola SQL sesuai permintaan saya?

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.

Di mana saya dapat bermigrasi jika saya memiliki lebih dari 16 TB data?

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.

Di mana saya dapat memindahkan data jika memiliki persyaratan perangkat keras tertentu seperti RAM yang lebih besar hingga rasio vCore atau lebih banyak CPU?

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

Masalah dan Cacat yang Diketahui

Di mana saya dapat menemukan masalah dan cacat yang diketahui?

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

Fitur baru

Di mana saya dapat menemukan fitur terbaru dan fitur dalam pratinjau publik?

Untuk fitur baru dan pratinjau, lihat Yang baru.

Membuat, memperbarui, menghapus, atau memindahkan instans terkelola SQL

Bagaimana cara memprovisikan instans terkelola SQL?

Anda dapat menyediakan instans terkelola SQL dari portal Microsoft Azure, PowerShell, Azure CLI , dan templat ARM.

Dapatkah saya menyediakan instans terkelola SQL dalam langganan yang sudah ada?

Ya, Anda dapat menyediakan instans terkelola SQL dalam langganan yang sudah ada jika langganan tersebut termasuk dalam jenis langganan yang didukung.

Mengapa saya tidak dapat menyediakan instans terkelola SQL di subnet yang memiliki nama yang dimulai dengan digit?

Memulai nama subnet dengan digit adalah batasan saat ini dari komponen dasar yang memverifikasi nama subnet sesuai dengan regex:

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

Semua nama yang lulus regex dan merupakan nama subnet yang valid saat ini didukung.

Bagaimana cara menskalakan instans terkelola SQL saya?

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

Dapatkah saya memindahkan instans terkelola SQL saya dari satu wilayah ke wilayah lain?

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

Bagaimana cara menghapus instans terkelola SQL saya?

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

Berapa lama waktu yang diperlukan untuk membuat atau memperbarui instans, atau memulihkan database?

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

Membuat, memperbarui, menghapus, atau memindahkan database

Bisakah saya menghilangkan dan membuat ulang database pada instans terkelola SQL menggunakan nama database yang sama?

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 penghapusan 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 dihapus, bagian akhir yang tersisa dari log transaksi dicadangkan secara sinkron sebelum operasi penghapusan selesai, seperti yang ditunjukkan pada gambar berikut:

  

  Tidak dapat membuat database dengan nama yang sama hingga tail-log dicadangkan dan operasi penghapusan 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.

Penawaran SQL Managed Instance gratis

Tolong! Saya tidak lagi dapat terhubung ke instans saya!

Kemungkinan Anda kehabisan kredit untuk bulan itu. Buka instans terkelola SQL Anda di portal Microsoft Azure dan periksa statusnya. Lihat apakah instans Anda dalam status terhenti karena kredit yang tidak mencukupi.

Jam vCore saya digunakan lebih cepat dari yang saya harapkan, bagaimana cara melihat apa yang menggunakan jam vCore?

Fungsionalitas ini saat ini tidak tersedia.

Bisakah saya memulihkan database ke instans gratis?

Ya, Anda dapat memulihkan cadangan otomatis dari instans terkelola SQL lainnya, atau Anda dapat Memulihkan cadangan database lokal dengan menggunakan SQL Server Management Studio (SSMS) atau dengan menjalankan RESTORE DATABASE perintah dan menargetkan .bak file dari penyimpanan Azure atau wadah S3.

Apakah penawaran Azure SQL Managed Instance gratis menyediakan instans dengan kualitas lingkungan produksi?

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.

Dapatkah saya meningkatkan ke instans yang lebih besar atau lebih kuat?

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

Dapatkah saya mengubah opsi pencadangan ke penyimpanan redundan geografis?

SQL Managed Instance gratis hanya mendukung PITR hingga 7 hari. Opsi cadangan lainnya tidak dapat dimodifikasi untuk SQL Managed Instance gratis.

Konvensi penamaan

Dapatkah instans terkelola SQL memiliki nama yang sama dengan instans lokal SQL Server?

Mengubah nama instans terkelola SQL tidak didukung.

Apakah saya dapat mengubah awalan zona DNS?

Ya, zona DNS default pada SQL Managed Instance dapat diganti dengan zona DNS milik Anda sendiri. Namun, bagian nama host dari FQDN untuk instans terkelola SQL, termasuk subzona acak (misalnya: sqlmiFQDN.randomized-subzone sebelum .database.windows.net) 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 SQL saja, atau nama host instans terkelola SQL diikuti dengan nama domain kustom. Alat CliConfg menambahkan alias dalam registri di bawah HKLM\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo atau 'HKLM\SOFTWARE\WOW6432Node\Microsoft\MSSQLServer\Client\ConnectTo, bergantung pada apakah Anda menggunakan versi 64-bit (C:\Windows\System32\cliconfg.exe) atau versi 32-bit (C:\Windows\SysWOW64\cliconfg.exe). Anda juga dapat menambahkan alias menggunakan kebijakan grup atau skrip, tetapi Anda harus menggunakan keduanya untuk memastikan program 32-bit dan 64-bit dapat mengenali alias.
• Gunakan rekaman CNAME di DNS dengan nama host instans terkelola SQL yang menunjuk ke nama domain titik akhir lokal VNet instans terkelola SQL. Dalam hal ini, HostNameInCertificate=<VNet-local endpoint domain name> (disarankan) atau TrustServerCertificate=TRUE diperlukan saat menggunakan autentikasi Microsoft Entra.
• Gunakan catatan A di DNS dengan nama host instans terkelola SQL yang menunjuk ke alamat IP instans terkelola SQL. Menggunakan alamat IP tidak disarankan, karena dapat berubah tanpa pemberitahuan. Dalam hal ini, HostNameInCertificate=<VNet-local endpoint domain name> (disarankan) atau TrustServerCertificate=TRUE diperlukan saat menggunakan autentikasi Microsoft Entra.

Opsi Migrasi

Bagaimana cara memigrasikan Azure SQL Database tunggal atau kumpulan elastis ke SQL Managed Instance?

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 mengonsolidasikan data pada satu instans, atau Anda memerlukan fitur yang didukung secara eksklusif di SQL Managed Instance. Anda dapat memigrasikan data Anda dengan menggunakan fungsi ekspor/impor (BACPAC). Berikut adalah cara lain untuk mempertimbangkan migrasi Database SQL ke SQL Managed Instance:

• Menggunakan Sumber Data Eksternal
• Menggunakan SQLPackage
• Menggunakan BCP

Bagaimana cara memigrasikan database instans saya ke Database Azure SQL tunggal?

Salah satu opsinya adalah mengekspor database ke BACPAC lalu mengimpor file BACPAC. Pendekatan ini direkomendasikan 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.

Bagaimana cara memigrasikan instans SQL Server saya ke SQL Managed Instance?

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

Bagaimana cara memigrasikan dari platform lain ke SQL Managed Instance?

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

Performa

Bagaimana cara membandingkan performa Azure SQL Managed Instance dengan performa SQL Server?

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

Apa yang menyebabkan perbedaan performa antara SQL Managed Instance dan SQL Server?

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

Bagaimana cara menyetel performa instans terkelola SQL saya?

Anda dapat mengoptimalkan performa instans terkelola SQL 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.

Bagaimana cara menyetel performa instans terkelola SQL Tujuan Umum saya lebih lanjut?

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.

Durasi kueri saya terlalu panjang. Bagaimana cara menganalisis statistik tunggu pada instans terkelola SQL saya?

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.

Bagaimana cara mengatasi kesalahan 'MSSQLSERVER_833' di SQL Managed Instance?

MSSQLSERVER_833 menunjukkan bahwa permintaan I/O membutuhkan waktu lebih dari 15 detik untuk diselesaikan. Kesalahan dalam Azure SQL Managed Instance ini terkait dengan kondisi infrastruktur secara keseluruhan, dan bukan beban kerja. Di lingkungan cloud, dan sistem yang menggunakan penyimpanan jarak jauh, terdapat beberapa lapisan arsitektur yang memengaruhi satu permintaan I/O. Perilaku ini diharapkan dan batasan layanan yang diketahui yang biasanya dihasilkan dari masalah jaringan sementara, atau sumber daya penyimpanan Azure menjadi tidak tersedia untuk sementara waktu. Sistem biasanya pulih tanpa intervensi.

Kejadian ini jarang terjadi, dan tidak memengaruhi rata-rata latensi permintaan I/O ke penyimpanan jarak jauh. Bergantung pada beban kerja atau utas yang memulai permintaan I/O, pelanggan mungkin mengamati batas waktu perintah SQL dan peningkatan latensi dalam skenario tertentu, sementara yang lain tidak mungkin mengalami dampak sama sekali. Misalnya, tidak semua permintaan I/O yang berjalan lama memblokir operasi, seperti akses halaman read-ahead yang sering kali tidak terpengaruh.

Menggunakan peningkatan tingkat layanan Tujuan Umum Next-gen dapat membantu mengurangi masalah ini, karena meningkatkan performa dan keandalan tanpa biaya tambahan. Pelanggan didorong untuk menjelajahinya untuk meningkatkan kualitas layanan.

Jika kesalahan ini terjadi terus-menerus, pertimbangkan untuk meninjau pola beban kerja, performa penyimpanan, dan konfigurasi jaringan. Selain itu, pertimbangkan untuk menggunakan tingkat layanan Business Critical yang dirancang untuk aplikasi dengan persyaratan latensi I/O rendah.

Pemantauan, Metrik, dan Peringatan

Apa saja opsi untuk memantau dan memperingatkan untuk instans terkelola SQL saya?

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.

Bagaimana cara memantau performa instans terkelola SQL saya?

Lihat Pemantauan dan penyetelan performa.

Bagaimana cara memantau performa real time instans terkelola SQL saya?

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

Apakah saya dapat menggunakan Profiler SQL untuk pelacakan performa?

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

Apakah SQL Database Advisor dan Query Performance Insight didukung untuk database SQL Managed Instance?

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

Bagaimana cara memantau penggunaan CPU pada instans terkelola SQL saya?

Lihat Pemantauan penggunaan CPU di SQL Server dan Azure SQL.

Apakah saya dapat membuat peringatan metrik di SQL Managed Instance?

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

Bisakah saya membuat pemberitahuan metrik pada database dalam instans terkelola SQL?

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

Ukuran penyimpanan

Berapa ukuran penyimpanan maksimum untuk SQL Managed Instance?

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

Berapa ukuran penyimpanan minimum yang tersedia untuk instans terkelola SQL?

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.

Apakah saya dapat menambah ruang penyimpanan yang ditetapkan untuk sebuah instans, secara terpisah dari sumber daya komputasi?

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

Bagaimana cara mengoptimalkan performa penyimpanan saya di tingkat layanan Tujuan Umum?

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

Mencadangkan dan memulihkan

Apakah penyimpanan cadangan dikurangi dari penyimpanan instans terkelola SQL saya?

Tidak, penyimpanan cadangan tidak dikurangi dari ruang penyimpanan instans terkelola SQL 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.

Bagaimana cara melihat kapan pencadangan otomatis dibuat pada instans terkelola SQL saya?

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

Apakah cadangan sesuai permintaan didukung?

Ya, Anda dapat membuat cadangan penuh khusus salinan di Azure Blob Storage mereka, tetapi hanya dapat dipulihkan ke instans terkelola SQL. Untuk detailnya, lihat Pencadangan salin-saja. 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 titik waktu untuk memindahkan database ke instans terkelola SQL lain, atau beralih ke kunci yang dikelola pelanggan.

Apakah pemulihan asli (dari file .bak) ke SQL Managed Instance didukung?

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.

Apakah pemulihan asli dari SQL Managed Instance ke SQL Server didukung?

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.

Keberlangsungan bisnis

Apakah database sistem saya direplikasi ke instans sekunder dalam grup failover?

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.

Persyaratan jaringan

Apa batasan NSG masuk/keluar saat ini pada subnet instans terkelola SQL?

Aturan NSG dan UDR yang diperlukan didokumenkan dalam konfigurasi subnet yang dibantu layanan, dan secara otomatis ditetapkan oleh layanan. Perlu diingat bahwa aturan ini hanyalah yang kita butuhkan untuk mempertahankan layanan. Untuk menyambungkan ke instans terkelola SQL dan menggunakan fitur yang berbeda, Anda perlu mengatur aturan khusus fitur lainnya, dan memeliharanya.

Bagaimana cara menetapkan aturan NSG untuk akses masuk pada port manajemen?

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

Apakah saya bisa mendapatkan rentang IP sumber yang digunakan untuk lalu lintas manajemen masuk?

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

Apakah saya dapat mengatur NSG untuk mengontrol akses ke titik akhir data (port 1433)?

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

Apakah saya dapat mengatur NVA atau firewall lokal untuk memfilter lalu lintas manajemen keluar berdasarkan FQDN?

Tidak. Ini tidak didukung karena beberapa alasan:

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

Dapatkah saya mengatur NVA atau firewall untuk lalu lintas nonmanagemen keluar?

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

Berapa banyak alamat IP yang saya butuhkan untuk instans terkelola SQL?

Subnet harus memiliki jumlah alamat IP yang tersedia yang memadai. Untuk menentukan ukuran subnet jaringan virtual untuk SQL Managed Instance, lihat Menentukan ukuran dan rentang subnet yang diperlukan untuk Azure SQL Managed Instance. Dengan pengujian konektivitas internal otomatis diaktifkan, setiap grup VM memerlukan 8 alamat IP (naik dari 6).

Mengapa saya melihat upaya masuk yang gagal dari AzureSQLConnectivityChecker?

Azure SQL Managed Instance menjalankan pengujian konektivitas internal otomatis untuk memantau keandalan layanan. Salah satu pengujian ini memvalidasi konektivitas end-to-end dengan mencoba masuk dengan kredensial yang diketahui gagal (AzureSQLConnectivityChecker). Ini adalah perilaku yang diharapkan dan bukan masalah keamanan. Login yang gagal muncul sekitar setiap 10 detik dalam log audit, Peristiwa yang Diperluas, dan log kesalahan SQL. Untuk detail tentang cara mengidentifikasi dan memfilter entri ini, lihat Mengamati login yang gagal yang disebabkan oleh pengujian end-to-end.

Bagaimana jika tidak ada cukup alamat IP untuk melakukan operasi pembaruan instans?

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.

Apakah saya memerlukan subnet kosong untuk membuat instans terkelola SQL?

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

Apakah saya dapat mengubah rentang alamat subnet?

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

Dapatkah saya memindahkan instans terkelola SQL saya ke subnet lain?

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.

Apakah saya memerlukan jaringan virtual kosong untuk membuat instans terkelola SQL?

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

Dapatkah saya menempatkan instans terkelola SQL dengan layanan lain di subnet?

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

Konektivitas

Dapatkah saya tersambung ke instans terkelola SQL saya menggunakan alamat IP-nya?

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

Dapatkah instans terkelola SQL saya memiliki alamat IP statis?

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

Dalam situasi yang jarang terjadi tetapi perlu, kita mungkin melakukan migrasi online instans terkelola SQL 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 SQL. Layanan instans terkelola SQL tidak menyediakan dukungan alamat IP statis, dan berhak untuk mengubah alamat IP tanpa pemberitahuan, sebagai bagian dari siklus pemeliharaan reguler.

Untuk alasan ini, titik akhir VNet-lokal dan publik hanya boleh diakses melalui nama domain terkait. Kami sangat menyarankan untuk tidak bergantung pada ketidakberubahan alamat IP mereka karena hal tersebut dapat menyebabkan ketidaktersediaan yang berkepanjangan meskipun layanan berfungsi dengan baik.

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 SQL. Kemudian, siapkan resolusi DNS atau konfigurasikan alias klien sehingga klien SQL terhubung ke alamat IP publik firewall melalui nama domain instans terkelola SQL yang sepenuhnya memenuhi syarat.

Apakah SQL Managed Instance memiliki titik akhir publik?

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.

Bisakah saya menentukan port kustom untuk titik akhir data SQL?

Tidak, penggunaan port kustom tidak dimungkinkan. 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.

Apa cara yang disarankan untuk menghubungkan instans terkelola yang ditempatkan di wilayah yang berbeda?

Peering jaringan virtual global 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

Apakah SQL Managed Instance mendukung Global VNet Peering?

Dukungan untuk peering jaringan virtual global 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 instance yang disebarkan sebelum tanggal ini, dukungan peering terbatas pada jaringan dalam wilayah yang sama karena pembatasan pada peering jaringan virtual global. Untuk informasi selengkapnya, tinjau bagian yang relevan dari tanya jawab umum Azure Virtual Networks.

Untuk menggunakan peering jaringan virtual global dengan instans yang dibuat sebelum Sept 2020, pertimbangkan konfigurasi jendela pemeliharaan. Atau, pertimbangkan untuk memindahkan instans ke subnet baru. Salah satu opsi memindahkan instans ke kluster virtual baru yang mendukung peering jaringan virtual global.

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

Mengurangi risiko eksfiltrasi data

Bagaimana saya dapat mengurangi risiko eksfiltrasi data?

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). Pengaturan ini juga direkomendasikan secara lokal.
• 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).

DNS

Bisakah saya mengonfigurasi pemecah masalah DNS kustom untuk SQL Managed Instance?

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

Bisakah saya melakukan refresh DNS?

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

Ubah zona waktu

Dapatkah saya mengubah zona waktu untuk instans terkelola SQL yang ada?

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

Solusinya termasuk membuat instans terkelola SQL baru dengan zona waktu yang tepat lalu melakukan pencadangan dan pemulihan manual, atau yang kami sarankan, melakukan pemulihan titik waktu lintas instans.

Enkripsi keamanan dan database

Apakah peran server sysadmin tersedia untuk SQL Managed Instance?

Ya, pelanggan dapat membuat login yang merupakan anggota peran sysadmin . Pelanggan yang mengambil hak istimewa sysadmin juga bertanggung jawab untuk mengoperasikan instance, yang dapat berdampak negatif pada komitmen SLA. Untuk menambahkan login ke peran server sysadmin , lihat Autentikasi Microsoft Entra.

Apakah Enkripsi Data Transparan didukung untuk SQL Managed Instance?

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

Dapatkah saya menggunakan model "bawa kunci Anda sendiri" untuk TDE?

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

Apakah saya dapat memigrasikan database SQL Server terenkripsi?

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

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

Bagaimana cara mengonfigurasi rotasi pelindung TDE untuk SQL Managed Instance?

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.

Apakah saya dapat memulihkan database terenkripsi saya ke SQL Managed Instance?

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 dengan konsep 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 untuk SQL Managed Instance untuk memulihkan database terenkripsi, ikuti instruksi untuk menyiapkan BYOK TDE, dan jangan centang 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.

Model pembelian dan keuntungannya

Model pembelian apa yang tersedia untuk SQL Managed Instance?

SQL Managed Instance menawarkan model pembelian berbasis vCore.

Manfaat biaya apa saja yang tersedia untuk SQL Managed Instance?

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.
• Berkomitmen pada reservasi untuk sumber daya komputasi dan hemat hingga 33 persen dengan manfaat Reservasi Azure. Gabungkan manfaat ini dengan manfaat Azure Hybrid 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.

Siapa yang berhak atas manfaat Instans Cadangan?

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 Reservasi Azure.

Apakah mungkin untuk membatalkan, menukar, atau mengembalikan dana reservasi?

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

Tagihan untuk Azure SQL Managed Instance dan penyimpanan cadangan

Apa saja opsi harga SQL Managed Instance?

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

Bagaimana cara melacak biaya penagihan untuk instans terkelola SQL saya?

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.

Apakah saya dapat menggunakan Microsoft atau alat pihak ketiga (pengembang dan lainnya) untuk mengakses SQL Managed Instance tanpa biaya tambahan?

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. Persyaratan ini diatur oleh perjanjian terpisah yang Anda miliki dengan setiap produsen alat individual.

Berapa biaya pencadangan otomatis?

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 bagi Anda, dan oleh karena itu gratis. 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.

Bagaimana cara memantau biaya penagihan untuk konsumsi penyimpanan cadangan saya?

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

Bagaimana cara mengoptimalkan biaya penyimpanan cadangan saya pada instans terkelola SQL?

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

Kasus penggunaan hemat biaya

Di mana saya dapat menemukan kasus penggunaan dan penghematan biaya yang dihasilkan dengan SQL Managed Instance?

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

Kebijakan kata sandi apa yang diterapkan untuk login SQL Managed Instance SQL?

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

Penting

Platform Azure dapat mengubah persyaratan kebijakan tanpa memberi tahu layanan yang mengandalkan kebijakan tersebut.

Apa kebijakan platform Azure saat ini?

Setiap login harus menetapkan kata sandinya saat masuk, dan mengubahnya setelah mencapai batas usia maksimum.

Kebijakan	Setelan Keamanan
Usia kata sandi maksimum	42 hari
Usia kata sandi minimum	Satu hari
Panjang kata sandi minimum	14 karakter
Kata sandi harus memenuhi persyaratan kompleksitas	Diaktifkan

Apa itu kebijakan penguncian login?

Nilai penguncian yang diamati berikut berlaku untuk login SQL Managed Instance. Gunakan nilai-nilai ini untuk mengukuran logika percobaan ulang dan perilaku mundur di aplikasi Anda.

Kebijakan	Setelan Keamanan
Ambang penguncian akun	10 upaya login gagal
Durasi penguncian akun	10 menit
Mengatur ulang penghitung penguncian akun setelah	10 menit

Penting

Nilai lockout ini diamati dari platform Azure yang mendasarinya dan disediakan sebagai referensi. Platform Azure dapat mengubah persyaratan kebijakan tanpa memberi tahu layanan yang mengandalkan kebijakan tersebut.

Apakah dimungkinkan untuk menonaktifkan kompleksitas kata sandi dan kedaluwarsa di SQL Managed Instance pada tingkat login?

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 nama login yang diinginkan dan sesuaikan nilai kebijakan dan kedaluwarsa.)

Pembaruan layanan

Apa perubahan CA Root untuk Azure SQL Database & SQL Managed Instance?

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

Apa yang dimaksud dengan peristiwa pemeliharaan terencana untuk SQL Managed Instance?

Lihat Merencanakan untuk kejadian pemeliharaan Azure di SQL Managed Instance.

Saya tidak dapat lagi melihat gelombang fitur November 2022 di portal Azure. Mengapa?

Perubahan dan kapabilitas yang diperkenalkan dalam gelombang fitur November 2022 kini tersedia untuk semua instans secara default. Karena mengambil tindakan terpisah untuk mendaftarkan instans tidak lagi diperlukan, opsi yang menyebutkan gelombang fitur November 2022 dihapus dari portal Microsoft Azure.

Umpan balik dan dukungan Azure

Di mana saya dapat menyampaikan ide saya untuk meningkatkan 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.

Bagaimana cara membuat permintaan dukungan Azure?

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

Peningkatan tingkat layanan Tujuan Umum generasi berikutnya

Bisakah saya mengaktifkan redundansi zona untuk instance SQL General Purpose Next-gen yang dikelola oleh saya?

Ya. Redundansi zona untuk tingkat layanan General Purpose generasi berikutnya saat ini sedang dalam tahap pratinjau. Versi pratinjau juga mendukung memori fleksibel untuk instans redundan zona pada perangkat keras seri Premium. Untuk informasi lebih lanjut, lihat Konfigurasikan redundansi zona.

Bisakah saya mengaktifkan upgrade General Purpose generasi berikutnya untuk instance pool saya?

Tidak, peningkatan tingkat layanan General Purpose generasi berikutnya saat ini tidak didukung untuk pool instans maupun instans di dalam pool.

Berlaku untuk:Azure SQL Managed Instance

Artikel ini berisi pertanyaan paling umum tentang Azure SQL Managed Instance.

Catatan

ID Microsoft Entra sebelumnya dikenal sebagai Azure Active Directory (Azure AD).

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. Lisensi edisi Standar dan Perusahaan yang tercakup dalam Jaminan Perangkat Lunak dapat dialokasikan ke Mesin Database SQL Server dengan menggunakan Azure Hybrid Benefit (AHB) untuk tingkat layanan Tujuan Umum (yang mencakup peningkatan tingkat layanan Tujuan Umum Next-gen), atau untuk tingkat layanan Business Critical. Azure Hybrid Benefit menggunakan rasio pertukaran berikut: 1 Edisi Standar = 1 Tujuan Umum, 1 edisi Perusahaan = 1 Kritis Bisnis, 1 edisi Perusahaan = 4 Tujuan Umum, dan 4 Tujuan Umum = 1 Edisi Perusahaan. Untuk informasi selengkapnya, lihat Hak tertentu dari Azure Hybrid Benefit.

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 SQL di wilayah yang saat ini tidak didukung, kirim permintaan dukungan melalui portal Microsoft 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 regional menurut jenis langganan, lihat tabel dari Batasan sumber daya Regional. Batas lunak ini 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 menyediakan instans terkelola SQL dari portal Microsoft Azure, PowerShell, Azure CLI , dan templat ARM.

Ya, Anda dapat menyediakan instans terkelola SQL dalam langganan yang sudah ada jika langganan tersebut termasuk dalam jenis langganan yang didukung.

Memulai nama subnet dengan digit adalah batasan saat ini dari komponen dasar yang memverifikasi nama subnet sesuai dengan regex:

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

Semua nama yang lulus regex dan merupakan nama subnet yang valid saat ini didukung.

Anda dapat menskalakan instans terkelola SQL dari portal Microsoft 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 SQL melalui portal Microsoft Azure, PowerShell, Azure CLI , atau REST API Resource Manager.

Waktu yang diharapkan untuk membuat instans terkelola SQL baru atau untuk mengubah tingkat layanan (vCore, 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 penghapusan 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 dihapus, bagian akhir yang tersisa dari log transaksi dicadangkan secara sinkron sebelum operasi penghapusan selesai, seperti yang ditunjukkan pada gambar berikut:

  

  Tidak dapat membuat database dengan nama yang sama hingga tail-log dicadangkan dan operasi penghapusan 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.

Kemungkinan Anda kehabisan kredit untuk bulan itu. Buka instans terkelola SQL Anda di portal Microsoft Azure dan periksa statusnya. Lihat apakah instans Anda dalam status terhenti karena kredit yang tidak mencukupi.

Fungsionalitas ini saat ini tidak tersedia.

Ya, Anda dapat memulihkan cadangan otomatis dari instans terkelola SQL lainnya, atau Anda dapat Memulihkan cadangan database lokal dengan menggunakan SQL Server Management Studio (SSMS) atau dengan menjalankan RESTORE DATABASE perintah dan menargetkan .bak file dari penyimpanan Azure atau wadah S3.

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 hanya menawarkan opsi 4 dan 8 vCore. Jika bisnis Anda memerlukan instans dengan lebih banyak sumber daya, pertimbangkan untuk meningkatkannya ke SQL Managed Instance berbayar sepenuhnya.

SQL Managed Instance gratis hanya mendukung PITR hingga 7 hari. Opsi cadangan lainnya tidak dapat dimodifikasi untuk SQL Managed Instance gratis.

Mengubah nama instans terkelola SQL tidak didukung.

Ya, zona DNS default pada SQL Managed Instance dapat diganti dengan zona DNS milik Anda sendiri. Namun, bagian nama host dari FQDN untuk instans terkelola SQL, termasuk subzona acak (misalnya: sqlmiFQDN.randomized-subzone sebelum .database.windows.net) 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 SQL saja, atau nama host instans terkelola SQL diikuti dengan nama domain kustom. Alat CliConfg menambahkan alias dalam registri di bawah HKLM\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo atau 'HKLM\SOFTWARE\WOW6432Node\Microsoft\MSSQLServer\Client\ConnectTo, bergantung pada apakah Anda menggunakan versi 64-bit (C:\Windows\System32\cliconfg.exe) atau versi 32-bit (C:\Windows\SysWOW64\cliconfg.exe). Anda juga dapat menambahkan alias menggunakan kebijakan grup atau skrip, tetapi Anda harus menggunakan keduanya untuk memastikan program 32-bit dan 64-bit dapat mengenali alias.
• Gunakan rekaman CNAME di DNS dengan nama host instans terkelola SQL yang menunjuk ke nama domain titik akhir lokal VNet instans terkelola SQL. Dalam hal ini, HostNameInCertificate=<VNet-local endpoint domain name> (disarankan) atau TrustServerCertificate=TRUE diperlukan saat menggunakan autentikasi Microsoft Entra.
• Gunakan catatan A di DNS dengan nama host instans terkelola SQL yang menunjuk ke alamat IP instans terkelola SQL. Menggunakan alamat IP tidak disarankan, karena dapat berubah tanpa pemberitahuan. Dalam hal ini, HostNameInCertificate=<VNet-local endpoint domain name> (disarankan) atau 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 mengonsolidasikan data pada satu instans, atau Anda memerlukan fitur yang didukung secara eksklusif di SQL Managed Instance. Anda dapat memigrasikan data Anda dengan menggunakan fungsi ekspor/impor (BACPAC). Berikut adalah cara lain untuk mempertimbangkan migrasi Database SQL ke SQL Managed Instance:

• Menggunakan Sumber Data Eksternal
• Menggunakan SQLPackage
• Menggunakan BCP

Salah satu opsinya adalah mengekspor database ke BACPAC lalu mengimpor file BACPAC. Pendekatan ini direkomendasikan 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 Azure Database.

Untuk perbandingan performa antara instans terkelola SQL 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 kinerja General Purpose SQL Managed Instance. Untuk informasi selengkapnya, lihat Dampak ukuran file log pada Tujuan Umum.

Anda dapat mengoptimalkan performa instans terkelola SQL 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.

MSSQLSERVER_833 menunjukkan bahwa permintaan I/O membutuhkan waktu lebih dari 15 detik untuk diselesaikan. Kesalahan dalam Azure SQL Managed Instance ini terkait dengan kondisi infrastruktur secara keseluruhan, dan bukan beban kerja. Di lingkungan cloud, dan sistem yang menggunakan penyimpanan jarak jauh, terdapat beberapa lapisan arsitektur yang memengaruhi satu permintaan I/O. Perilaku ini diharapkan dan batasan layanan yang diketahui yang biasanya dihasilkan dari masalah jaringan sementara, atau sumber daya penyimpanan Azure menjadi tidak tersedia untuk sementara waktu. Sistem biasanya pulih tanpa intervensi.

Kejadian ini jarang terjadi, dan tidak memengaruhi rata-rata latensi permintaan I/O ke penyimpanan jarak jauh. Bergantung pada beban kerja atau utas yang memulai permintaan I/O, pelanggan mungkin mengamati batas waktu perintah SQL dan peningkatan latensi dalam skenario tertentu, sementara yang lain tidak mungkin mengalami dampak sama sekali. Misalnya, tidak semua permintaan I/O yang berjalan lama memblokir operasi, seperti akses halaman read-ahead yang sering kali tidak terpengaruh.

Menggunakan peningkatan tingkat layanan Tujuan Umum Next-gen dapat membantu mengurangi masalah ini, karena meningkatkan performa dan keandalan tanpa biaya tambahan. Pelanggan didorong untuk menjelajahinya untuk meningkatkan kualitas layanan.

Jika kesalahan ini terjadi terus-menerus, pertimbangkan untuk meninjau pola beban kerja, performa penyimpanan, dan konfigurasi jaringan. Selain itu, pertimbangkan untuk menggunakan tingkat layanan Business Critical yang dirancang untuk aplikasi dengan persyaratan latensi I/O rendah.

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. Namun, sebaliknya, Anda harus mempertimbangkan Extended Events untuk pelacakan aktivitas 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 Pemantauan penggunaan CPU di 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 SQL. Metrik pemberitahuan untuk database individual dalam instans terkelola SQL tidak tersedia.

Ukuran penyimpanan untuk SQL Managed Instance tergantung pada tingkat layanan yang dipilih (Tujuan Umum, Tujuan Umum Generasi Berikutnya, atau Kritis Bisnis). 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 reservasi instans maksimum dalam Tabel.

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

Tidak, penyimpanan cadangan tidak dikurangi dari ruang penyimpanan instans terkelola SQL 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 dilakukan pada instans terkelola SQL, tinjau Memantau aktivitas pencadangan.

Ya, Anda dapat membuat cadangan penuh khusus salinan di Azure Blob Storage mereka, tetapi hanya dapat dipulihkan ke instans terkelola SQL. Untuk detailnya, lihat Pencadangan salin-saja. 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 titik waktu untuk memindahkan database ke instans terkelola SQL lain, 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 didokumenkan dalam konfigurasi subnet yang dibantu layanan, dan secara otomatis ditetapkan oleh layanan. Perlu diingat bahwa aturan ini hanyalah yang kita butuhkan untuk mempertahankan layanan. Untuk menyambungkan ke instans terkelola SQL dan menggunakan fitur yang berbeda, Anda perlu mengatur aturan khusus fitur lainnya, dan memeliharanya.

Bagaimana cara menetapkan aturan NSG untuk akses masuk pada port manajemen?

SQL Managed Instance bertanggung jawab untuk menetapkan aturan pada port manajemen. Aturan diatur melalui fungsionalitas bernama konfigurasi subnet berbantuan 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 SQL disediakan, Anda dapat mengatur NSG yang mengontrol akses masuk ke port 1433. Disarankan agar Anda 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.
• Mengalihkan lalu lintas ke Azure Storage akan dipengaruhi oleh kendala throughput dan latensi, sehingga kami tidak akan dapat memberikan kualitas dan ketersediaan layanan yang diharapkan.
• Konfigurasi ini rawan kesalahan dan tidak dapat didukung.

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

Subnet harus memiliki jumlah alamat IP yang tersedia yang memadai. Untuk menentukan ukuran subnet jaringan virtual untuk SQL Managed Instance, lihat Menentukan ukuran dan rentang subnet yang diperlukan untuk Azure SQL Managed Instance. Dengan pengujian konektivitas internal otomatis diaktifkan, setiap grup VM memerlukan 8 alamat IP (naik dari 6).

Azure SQL Managed Instance menjalankan pengujian konektivitas internal otomatis untuk memantau keandalan layanan. Salah satu pengujian ini memvalidasi konektivitas end-to-end dengan mencoba masuk dengan kredensial yang diketahui gagal (AzureSQLConnectivityChecker). Ini adalah perilaku yang diharapkan dan bukan masalah keamanan. Login yang gagal muncul sekitar setiap 10 detik dalam log audit, Peristiwa yang Diperluas, dan log kesalahan SQL. Untuk detail tentang cara mengidentifikasi dan memfilter entri ini, lihat Mengamati login yang gagal yang disebabkan oleh pengujian end-to-end.

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 SQL dalam subnet yang sudah berisi jenis sumber daya lainnya.

Tidak, ini tidak didukung. Nama host instans terkelola SQL terhubung ke load balancer yang berada di depan kluster virtual instans terkelola SQL. Karena satu kluster virtual dapat menghosting beberapa instans terkelola, koneksi tidak dapat dirutekan ke instans terkelola SQL 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 untuk instans terkelola SQL yang menjamin alamat IP statis.

Dalam situasi yang jarang terjadi tetapi perlu, kita mungkin melakukan migrasi online instans terkelola SQL 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 SQL. Layanan instans terkelola SQL tidak menyediakan dukungan alamat IP statis, dan berhak untuk mengubah alamat IP tanpa pemberitahuan, sebagai bagian dari siklus pemeliharaan reguler.

Untuk alasan ini, titik akhir VNet-lokal dan publik hanya boleh diakses melalui nama domain terkait. Kami sangat menyarankan untuk tidak bergantung pada ketidakberubahan alamat IP mereka karena hal tersebut dapat menyebabkan ketidaktersediaan yang berkepanjangan meskipun layanan berfungsi dengan baik.

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 SQL. Kemudian, siapkan resolusi DNS atau konfigurasikan alias klien sehingga klien SQL terhubung ke alamat IP publik firewall melalui nama domain instans terkelola SQL 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, penggunaan port kustom tidak dimungkinkan. 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.

Peering jaringan virtual global 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 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 instance yang disebarkan sebelum tanggal ini, dukungan peering terbatas pada jaringan dalam wilayah yang sama karena pembatasan pada peering jaringan virtual global. Untuk informasi selengkapnya, tinjau bagian yang relevan dari tanya jawab umum Azure Virtual Networks.

Untuk menggunakan peering jaringan virtual global dengan instans yang dibuat sebelum Sept 2020, pertimbangkan konfigurasi jendela pemeliharaan. Atau, pertimbangkan untuk memindahkan instans ke subnet baru. Salah satu opsi memindahkan instans ke kluster virtual baru yang mendukung peering jaringan virtual global.

Lihat cara memeriksa apakah peering jaringan virtual global didukung untuk 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). Pengaturan ini juga direkomendasikan secara lokal.
• 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 SQL disediakan untuk pertama kalinya. Mengubah zona waktu instans terkelola SQL yang ada tidak didukung. Untuk detailnya, lihatBatasan zona waktu.

Solusinya termasuk membuat instans terkelola SQL baru dengan zona waktu yang tepat lalu melakukan pencadangan dan pemulihan manual, atau yang kami sarankan, melakukan pemulihan titik waktu lintas instans.

Ya, pelanggan dapat membuat login yang merupakan anggota peran sysadmin . Pelanggan yang mengambil hak istimewa sysadmin juga bertanggung jawab untuk mengoperasikan instance, 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 untuk BYOK (Bring Your Own Key) 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. Kemudian, ambil cadangan database lengkap dan pulihkan ke instans terkelola SQL.

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 dengan konsep 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 untuk SQL Managed Instance untuk memulihkan database terenkripsi, ikuti instruksi untuk menyiapkan BYOK TDE, dan jangan centang 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.
• Berkomitmen pada reservasi untuk sumber daya komputasi dan hemat hingga 33 persen dengan manfaat Reservasi Azure. Gabungkan manfaat ini dengan manfaat Azure Hybrid 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 Reservasi Azure.

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. Persyaratan ini diatur oleh perjanjian terpisah yang Anda miliki dengan setiap produsen alat individual.

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 bagi Anda, dan oleh karena itu gratis. 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 biaya penyimpanan cadangan pada SQL Managed Instance.

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 ke VM yang membentuk kluster virtual yang memegang instans terkelola SQL. Saat ini, tidak dimungkinkan untuk mengubah salah satu pengaturan ini karena pengaturan ini ditentukan oleh Azure dan diwarisi oleh instans terkelola SQL.

Penting

Platform Azure dapat mengubah persyaratan kebijakan tanpa memberi tahu layanan yang mengandalkan kebijakan tersebut.

Setiap login harus menetapkan kata sandinya saat masuk, dan mengubahnya setelah mencapai batas usia maksimum.

Kebijakan	Setelan Keamanan
Usia kata sandi maksimum	42 hari
Usia kata sandi minimum	Satu hari
Panjang kata sandi minimum	14 karakter
Kata sandi harus memenuhi persyaratan kompleksitas	Diaktifkan

Nilai penguncian yang diamati berikut berlaku untuk login SQL Managed Instance. Gunakan nilai-nilai ini untuk mengukuran logika percobaan ulang dan perilaku mundur di aplikasi Anda.

Kebijakan	Setelan Keamanan
Ambang penguncian akun	10 upaya login gagal
Durasi penguncian akun	10 menit
Mengatur ulang penghitung penguncian akun setelah	10 menit

Penting

Nilai lockout ini diamati dari platform Azure yang mendasarinya dan disediakan sebagai referensi. Platform Azure dapat mengubah persyaratan kebijakan tanpa memberi tahu layanan yang mengandalkan kebijakan tersebut.

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 nama login 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.

Perubahan dan kapabilitas yang diperkenalkan dalam gelombang fitur November 2022 kini tersedia untuk semua instans secara default. Karena mengambil tindakan terpisah untuk mendaftarkan instans tidak lagi diperlukan, opsi yang menyebutkan gelombang fitur November 2022 dihapus dari portal Microsoft Azure.

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.

Ya. Redundansi zona untuk tingkat layanan General Purpose generasi berikutnya saat ini sedang dalam tahap pratinjau. Versi pratinjau juga mendukung memori fleksibel untuk instans redundan zona pada perangkat keras seri Premium. Untuk informasi lebih lanjut, lihat Konfigurasikan redundansi zona.

Tidak, peningkatan tingkat layanan General Purpose generasi berikutnya saat ini tidak didukung untuk pool instans maupun instans di dalam pool.