Sekilas tentang keterbatasan sumber daya Azure SQL Managed Instance

Berlaku untuk:Azure SQL Managed Instance

• Azure SQL Database
• Instans Terkelola Azure SQL

Artikel ini memberikan gambaran tentang karakteristik teknis dan batas sumber daya untuk Azure SQL Managed Instance. Dokumen ini juga memberikan informasi tentang cara meminta kenaikan batas tersebut.

Catatan

Untuk perbedaan fitur yang didukung dan pernyataan T-SQL, lihat Perbedaan fitur dan dukungan pernyataan T-SQL. Untuk perbedaan umum antara tier layanan Azure SQL Database dan SQL Managed Instance, tinjau tier layanan General Purpose dan Business Critical.

Karakteristik konfigurasi perangkat keras

Di bagian ini:

• Dukungan regional untuk perangkat keras seri premium yang dioptimalkan untuk memori dan untuk perangkat keras seri premium dengan penyimpanan 16-TB
• Ruang yang tersedia OLTP dalam memori

Azure SQL Managed Instance memiliki karakteristik dan batas sumber daya yang bergantung pada infrastruktur serta arsitektur yang mendasarinya. Anda dapat menerapkan SQL Managed Instance pada beberapa generasi perangkat keras.

Generasi perangkat keras memiliki karakteristik yang berbeda, seperti yang dijelaskan dalam tabel berikut:

Fitur	Seri Standar (Gen5)	Seri premium	Seri premium dengan memori dioptimalkans
CPU	Prosesor Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake), dan Intel® 8272CL (Cascade Lake) 2,5 GHz	Prosesor Intel® 8370C (Ice Lake) 2,8 GHz	Prosesor Intel® 8370C (Ice Lake) 2,8 GHz
Jumlah vCore vCore=1 LP (hyper-thread)	21 -80 vCore	21 -128 vCore	4-128 vCore
Memori maks (memori/rasio vCore)	5,1 GB per vCore - maksimum 408 GB Tambahkan lebih banyak vCore untuk mendapatkan lebih banyak memori.	7 GB per vCore hingga 80 vCore - maksimum 560 GB	13,6 GB per vCore hingga 64 vCore - maksimum 870,4 GB
Maks. memori OLTP dalam Memori	Batas instans: 0,8-1,65 GB per vCore	Batas instans: 1,1-2,3 GB per vCore	Batas instans: 2,2-4,5 GB per vCore
Penyimpanancadangan instans maks 2	Tujuan Umum: hingga 32 TB4 Bisnis Kritis: hingga 4 TB	Tujuan Umum: hingga 32 TB4 Bisnis Penting: hingga 16 TB3	Tujuan Umum: hingga 32 TB4 Bisnis Kritis: hingga 16 TB

¹ Anda hanya dapat menerapkan instance 2-vCore di dalam pool instance.
² Tergantung pada jumlah vCore.
³Wilayah berikut dapat menyediakan penyimpanan 16 TB, sementara wilayah lain membatasi penyimpanan yang tersedia hingga 5,5 TB.
⁴ 16 TB untuk Tujuan Umum klasik. 32 TB hanya untuk tingkat layanan Tujuan Umum generasi berikutnya

Catatan

Jika bisnis Anda memerlukan ukuran penyimpanan lebih besar dari batas sumber daya yang tersedia untuk Azure SQL Managed Instance, pertimbangkan tingkat layanan Hyperscale Azure SQL Database.

Dukungan regional untuk perangkat keras seri premium yang dioptimalkan untuk memori dan untuk perangkat keras seri premium dengan penyimpanan 16-TB

Dukungan untuk perangkat keras seri premium dengan penyimpanan 16 TB memiliki ketersediaan yang sama dengan dukungan untuk perangkat keras seri premium yang dioptimalkan memori. Untuk mempelajari lebih lanjut, lihat Dukungan Regional untuk perangkat keras seri premium yang dioptimalkan untuk memori dan perangkat keras seri premium dengan penyimpanan 16 TB.

Ruang OLTP yang tersedia dalam memori

Jumlah ruang OLTP dalam memori pada tingkat layanan Business Critical tergantung pada jumlah vCore dan konfigurasi perangkat keras. Tabel berikut mencantumkan batas memori yang dapat Anda gunakan untuk objek OLTP dalam memori.

vCore	Seri Standar (Gen5)	Seri premium	Seri premium dengan memori dioptimalkans
4 vCore	3,14 GB	4,39 GB	8,79 GB
6 vCore	-	6,59 GB	15,32 GB
8 vCore	6,28 GB	8,79 GB	22,06 GB
10 vCore	-	12,11 GB	30,94 GB
12 vCore	-	15,43 GB	39,82 GB
16 vCore	15,77 GB	22,06 GB	57,58 GB
20 vCore	-	28,70 GB	75,34 GB
24 vCore	25,25 GB	35,34 GB	93,09 GB
32 vCore	37,94 GB	53,09 GB	128,61 GB
40 vCore	52,23 GB	73,09 GB	164,13 GB
48 vCore	-	95,34 GB	199,64 GB
56 vCore	-	117,58 GB	244,13 GB
64 vCore	99,9 GB	139,82 GB	288,61 GB
80 vCore	131,68 GB	184,30 GB	288,61 GB
96 vCore	T/A	184,30 GB	288,61 GB
128 vCore	T/A	184,30 GB	288,61 GB

Karakteristik tingkat layanan

SQL Managed Instance memiliki dua tingkat layanan: Tujuan Umum dan Bisnis Penting. Anda dapat memilih untuk menggunakan tingkat layanan Tujuan Umum Next-gen yang ditingkatkan.

Penting

Tier layanan Business Critical menyediakan salinan bawaan tambahan dari SQL Managed Instance (replika sekunder) yang digunakan untuk beban kerja hanya-baca. Jika Anda memisahkan kueri baca-tulis dari kueri hanya-baca, analitik, atau pelaporan, Anda mendapatkan dua kali vCore dan memori dengan harga yang sama. Replika sekunder mungkin terlambat beberapa detik dari instance utama, sehingga dirancang untuk memindahkan beban pelaporan dan analitik yang tidak membutuhkan status data saat ini yang tepat. Dalam tabel berikut, kueri hanya-baca adalah kueri yang berjalan pada replika sekunder.

Di bagian ini:

• Jumlah vCore
• Memori maks
• Ukuran penyimpanan instans maksimum
• Perbandingan karakteristik tingkat layanan
• IOPS dan throughput
• Penyimpanan data dan log
• Pencadangan dan penyimpanan
• Pertimbangan karakteristik tambahan

Jumlah vCores

Pembuatan perangkat keras	Tujuan Umum	Tujuan Umum generasi berikutnya	Kritis Bisnis
Seri Standar (Gen5)	21, 4, 8, 16, 24, 32, 40, 64, 80	4, 8, 16, 24, 32, 40, 64, 80	4, 8, 16, 24, 32, 40, 64, 80
Seri premium	21, 4, 8, 16, 24, 32, 40, 64, 80	4, 6, 8, 10, 12, 16, 20, 24, 32, 40, 48, 56, 64, 80, 96, 128	4, 6, 8, 10, 12, 16, 20, 24, 32, 40, 48, 56, 64, 80, 96, 128
Seri premium dengan memori dioptimalkans	4, 8, 16, 24, 32, 40, 64, 80	4, 6, 8, 10, 12, 16, 20, 24, 32, 40, 48, 56, 64, 80, 96, 128	4, 6, 8, 10, 12, 16, 20, 24, 32, 40, 48, 56, 64, 80, 96, 128

¹ Menyebarkan instans 2-vCore hanya dimungkinkan di dalam kumpulan instans.

Memori maksimum

Pembuatan perangkat keras	Tujuan Umum	Tujuan Umum generasi berikutnya	Kritis Bisnis
Seri Standar (Gen5)	20,4 GB - 408 GB 5,1 GB/vCore	20,4 GB - 408 GB 5,1 GB/vCore	20,4 GB - 408 GB 5,1 GB/vCore pada setiap replika
Seri premium	28 GB - 560 GB 7 GB/vCore	28 GB - 560 GB 7 GB/vCore	28 GB - 560 GB 7 GB/vCore hingga 80 vCore1 pada setiap replika
Seri premium dengan memori dioptimalkans	54,4 GB - 870,4 GB 13,6 GB/vCore	54,4 GB - 870,4 GB 13,6 GB/vCore	54,4 GB - 870,4 GB 13,6 GB/vCore hingga 64 vCore1 pada setiap replika

¹ Rasio memori-ke-vCore hanya tersedia hingga 80 vCore untuk perangkat keras seri premium, dan 64 vCore untuk seri premium yang dioptimalkan memori. Memori maksimum dibatasi pada 560 GB untuk vCore seri premium di atas 80, dan 870,4 GB untuk vCore seri premium yang dioptimalkan memori di atas 64.

Ukuran penyimpanan instans maksimum (dipesan)

Tabel berikut mencantumkan ukuran penyimpanan maksimum berdasarkan jumlah vCore untuk setiap pembuatan perangkat keras dan tingkat layanan:

Pembuatan perangkat keras	Tujuan Umum1	Tujuan Umum generasi berikutnya	Bisnis Kritis2
Seri Standar (Gen5)	- 2 TB untuk 4 vCore - 8 TB untuk 8 vCore - 16 TB untuk ukuran lain	- 2 TB untuk 4 vCore - 8 TB untuk 8 vCore - 16 TB untuk 16, 24 vCore - 32 TB untuk 32, 40, 64, 80 vCore	- 1 TB untuk 4, 8, 16 vCore - 2 TB untuk 24 vCore - 4 TB untuk 32, 40, 64, 80 vCore
Seri premium	- 2 TB untuk 4 vCore - 8 TB untuk 8 vCore - 16 TB untuk ukuran lain	- 2 TB untuk 4, 6 vCore - 8 TB untuk 8, 10, 12 vCore - 16 TB untuk 16, 20, 24 vCore - 32 TB untuk 32, 40, 48, 56, 64, 80, 96, 128 vCore	- 1 TB untuk 4, 6 vCore - 2 TB untuk 8, 10, 12 vCore - 4 TB untuk 16, 20 vCore - 5,5 TB untuk 24, 32, 40, 48, 56 vCore - 5,5 TB atau 16 TB (tergantung wilayahnya) untuk 64, 80, 96, 128 vCore3
Seri premium dengan memori dioptimalkans	- 2 TB untuk 4 vCore - 8 TB untuk 8 vCore - 16 TB untuk ukuran lain	- 2 TB untuk 4, 6 vCore - 8 TB untuk 8, 10, 12 vCore - 16 TB untuk 16, 20, 24 vCore - 32 TB untuk 32, 40, 48, 56, 64, 80, 96, 128 vCore	- 1 TB untuk 4, 6 vCore - 2 TB untuk 8, 10, 12 vCore - 4 TB untuk 16, 20 vCore - 5,5 TB untuk 24 vCore - 5,5 TB atau 8 TB (tergantung wilayahnya) untuk 32, 40 vCore4 - 12 TB untuk 48, 56 vCore - 16 TB untuk 64, 80, 96, 128 vCore

¹ Di tingkat layanan Tujuan Umum, tempdb menggunakan penyimpanan SSD lokal.

² Di tingkat layanan Business Critical, tempdb berbagi penyimpanan SSD lokal dengan file data dan log. Ukuran tempdb dapat tumbuh hingga ukuran penyimpanan instans yang saat ini tersedia.

³ Hanya wilayah utama yang dapat menyediakan penyimpanan 16 TB untuk perangkat keras seri premium untuk nomor CPU vCore ini. Wilayah yang lebih kecil membatasi penyimpanan yang tersedia hingga 5,5 TB.

⁴ Hanya wilayah utama yang dapat menyediakan penyimpanan 8 TB untuk perangkat keras yang dioptimalkan memori seri premium untuk nomor VCore CPU ini. Wilayah yang lebih kecil membatasi penyimpanan yang tersedia hingga 5,5 TB.

Perbandingan karakteristik tingkat layanan

Fitur	Tujuan Umum	Tujuan Umum generasi berikutnya	Kritis Bisnis
Ukuran database maksimum	Hingga ukuran instans yang tersedia saat ini (tergantung pada jumlah vCore).	Hingga ukuran instans yang tersedia saat ini (tergantung pada jumlah vCore).	Hingga ukuran instans yang tersedia saat ini (tergantung pada jumlah vCore).
Ukuran database maks tempdb	Dibatasi hingga 24 GB/vCore (96-1.920 GB) dan ukuran penyimpanan instans yang tersedia saat ini. Tambahkan lebih banyak vCore untuk mendapatkan lebih banyak tempdb ruang. Ukuran file log dibatasi hingga 120 GB.	Dibatasi hingga 24 GB/vCore (96-1.920 GB) dan ukuran penyimpanan instans yang tersedia saat ini. Tambahkan lebih banyak vCore untuk mendapatkan lebih banyak tempdb ruang. Ukuran file log dibatasi hingga 120 GB.	Hingga ukuran penyimpanan instans yang tersedia saat ini.
Jumlah maksimum tempdb file	128	128	128
Jumlah maksimum database per instans	100 database pengguna, kecuali batas ukuran penyimpanan instans telah tercapai.	500 database pengguna	100 database pengguna, kecuali batas ukuran penyimpanan instans telah tercapai.
Jumlah maksimum file database	280 per instans, kecuali ukuran penyimpanan instans atau batas ruang alokasi penyimpanan Azure Premium Disk telah tercapai.	4.096 file per database	32.767 file per database, kecuali batas ukuran penyimpanan instans telah tercapai.
Ukuran file data maksimum	Ukuran maksimum setiap file data adalah 8 TB. Gunakan setidaknya dua file data untuk database yang lebih besar dari 8 TB.	Hingga ukuran instans yang tersedia saat ini (tergantung pada jumlah vCore).	Hingga ukuran instans yang tersedia saat ini (tergantung pada jumlah vCore).
Ukuran file log maksimum	Terbatas pada 2 TB dan ukuran penyimpanan instans yang saat ini tersedia.	Terbatas pada 2 TB dan ukuran penyimpanan instans yang saat ini tersedia.	Terbatas pada 2 TB dan ukuran penyimpanan instans yang saat ini tersedia.
Data/Log IOPS (perkiraan)	500 - 7500 per file * Meningkatkan ukuran file untuk mendapatkan lebih banyak IOPS	Penyimpanan yang dipesan * 3 - hingga batas VM. 300 dalam kasus penyimpanan cadangan 32 GB, 64 GB, dan 96 GB. Batas VM tergantung pada jumlah vCore 6400 IOPS untuk VM dengan 4 vCore - 80 K IOPS untuk VM dengan 128 vCore	16 K - 320 K (4000 IOPS/vCore) Tambahkan lebih banyak vCore untuk mendapatkan performa IO yang lebih baik.
Throughput data (perkiraan)	100 - 250 MiB/dtk per file * Meningkatkan ukuran file untuk mendapatkan performa IO yang lebih baik	IOPS / 30 MBps - hingga batas VM. 75 MBps dalam kasus penyimpanan cadangan 32 GB, 64 GB, dan 96 GB.	Tidak terbatas.
Batas throughput tulis log (per instans)	4,5 MiB/dtk per vCore Maks 120 MiB/dtk per instans 22 - 65 MiB/dtk per DB (tergantung pada ukuran file log) * Meningkatkan ukuran file untuk mendapatkan performa IO yang lebih baik	Seri standar: 4,5 MiB/dtk per vCore Maks 120 MiB/s Seri premium dan Seri premium memori yang dioptimalkan: 4,5 MiB/dtk per vCore Maks 192 MiB/dtk	Seri standar: 16 MiB/s per vCore Maks 160 MiB/s Seri premium dan Seri premium memori yang dioptimalkan: 16 MiB/s per vCore Maks 192 MiB/dtk
Latensi IO penyimpanan (perkiraan1)	5-10 mdtk	3-5 mdtk	1-2 mdtk
OLTP dalam memori	Tidak didukung	Tidak didukung	Tersedia, ukuran tergantung pada jumlah vCore
Sesi maksimum	30000	30000	30000
Pekerja konkuren maks	105 * jumlah vCore + 800	105 * jumlah vCore + 800	105 * jumlah vCore + 800
Menggunakan replika baca-saja untuk membongkar beban kerja kueri baca-saja	0	0	1 (termasuk dalam harga)
Isolasi komputasi	Tidak didukung karena instans Tujuan Umum mungkin berbagi perangkat keras fisik dengan instans lain	Tidak didukung karena instans Tujuan Umum Next-gen mungkin berbagi perangkat keras fisik dengan instans lain	seri Standar (Gen5): Didukung untuk konfigurasi dengan 64 vCore atau lebih seri Premium: Didukung untuk konfigurasi dengan 64 vCore atau lebih Seri premium memori yang dioptimalkan: Didukung untuk konfigurasi dengan 64 vCore atau lebih
Replika untuk ketersediaan	Simpul siaga untuk ketersediaan tinggi	Simpul siaga untuk ketersediaan tinggi	Empat replika ketersediaan tinggi, 1 juga merupakan replika skala baca
Replika baca-saja dengan grup failover diaktifkan	Satu replika baca-saja tambahan. Dua total replika yang dapat dibaca, yang mencakup replika utama.	Satu replika baca-saja tambahan. Dua total replika yang dapat dibaca, yang mencakup replika utama.	Dua replika baca-saja tambahan, tiga replika baca-saja total. Empat total replika yang dapat dibaca, yang mencakup replika utama.
Harga/tagihan	vCore, penyimpanan khusus, dan penyimpanan cadangan dikenai biaya. IOPS tidak dikenakan biaya	vCore, penyimpanan cadangan, penyimpanan cadangan, dan IOPS (melalui kuota gratis) dikenakan biaya.	vCore, penyimpanan khusus, dan penyimpanan cadangan dikenai biaya. IOPS tidak dikenakan biaya.
Model diskon	Reservasi Azure Azure Hybrid Benefit - Azure SQL Database & SQL Managed Instance (tidak tersedia pada langganan dev/test) Langganan Dev/Test berbayar dan bayar sesuai penggunaan	Reservasi Azure Azure Hybrid Benefit - Azure SQL Database & SQL Managed Instance (tidak tersedia pada langganan dev/test) Langganan Dev/Test berbayar dan bayar sesuai penggunaan	Reservasi Azure Azure Hybrid Benefit - Azure SQL Database & SQL Managed Instance (tidak tersedia pada langganan dev/test) Langganan Dev/Test berbayar dan bayar sesuai penggunaan

¹ Ini adalah rentang rata-rata. Meskipun sebagian besar durasi permintaan IO akan berada di bawah bagian atas rentang, outlier yang melebihi rentang dimungkinkan.

IOPS dan throughput

IOPS dan throughput adalah karakteristik sistem file IO.

IOPS dan throughput berbeda menurut tingkat layanan dengan cara berikut:

• Di tingkat layanan Business Critical , throughput tidak terbatas.
• Di tingkat layanan Tujuan Umum , throughput tergantung pada ukuran file.
• Di tingkat layanan Tujuan Umum Next-gen , throughput diskalakan secara proporsional dengan jumlah IOPS yang dialokasikan untuk instans.

Bagian berikut menjelaskan karakteristik IO berdasarkan tingkat layanan secara lebih rinci.

IOPS dan throughput di tingkat layanan Tujuan Umum

Di tingkat layanan Tujuan Umum, setiap file database mendapatkan IOPS dan throughput khusus yang bergantung pada ukuran file. File yang lebih besar mendapatkan lebih banyak IOPS dan throughput.

Tabel berikut ini memperlihatkan karakteristik IO file database di tingkat layanan Tujuan Umum :

Ukuran file	>=0 dan <=129 GiB	>129 dan <=513 GiB	>513 dan <=1025 GiB	>1025 dan <=2049 GiB	>2049 dan <=4097 GiB	>4097 GiB dan <=8 TiB
IOPS per file	500	2.300	lima ribu	7.500	7.500	7.500
Throughput per file	100 MiB/detik	150 MiB/detik	200 MiB/detik	250 MiB/detik	250 MiB/detik	250 MiB/detik

Jika Anda melihat latensi IO tinggi pada beberapa file database atau Anda melihat bahwa IOPS/throughput mencapai batas, Anda dapat meningkatkan peforma dengan meningkatkan ukuran file.

Ada juga batas tingkat instans pada throughput tulis log maks (lihat tabel sebelumnya untuk nilai, misalnya 22 MiB/dtk), sehingga Anda mungkin tidak dapat mencapai file maks di seluruh file log karena Anda mencapai batas throughput instans.

IOPS dan throughput di tingkat layanan Tujuan Umum Generasi Berikutnya

Tingkat layanan Tujuan Umum Next-gen memiliki karakteristik IOPS berikut:

• IOPS minimum yang dijamin: Setiap instans dijamin minimal 300 IOPS, terlepas dari penyimpanan yang dipesan.
• Skala IOPS dengan penyimpanan yang dipesan: Untuk setiap penyimpanan cadangan 1GB, Anda mendapatkan 3 IOPS bawaan. Misalnya, jika Anda memiliki penyimpanan cadangan 1024 GB, Anda mendapatkan 3072 IOPS yang ditetapkan.
• IOPS tambahan: Anda dapat meningkatkan jumlah IOPS di atas nilai bawaan hingga batas.
• Batas IOPS maksimum per jumlah vCore: Setiap konfigurasi vCore memiliki batas IOPS maksimum, seperti yang ditunjukkan oleh IOPS maksimum per tabel vCore.

Tingkat layanan Tujuan Umum Next-gen memiliki karakteristik throughput berikut:

• Throughput minimum yang dijamin: Setiap instans dijamin minimal 75 MB/dtk throughput, terlepas dari jumlah vCore.
• Skala throughput dengan IOPS: Throughput diskalakan secara proporsional dengan jumlah IOPS yang dialokasikan untuk instans, menggunakan rumus throughput (MB/s) = IOPS / 30. Misalnya, instans yang dialokasikan dengan 3.000 IOPS menerima throughput 100 MB/dtk.
• Batas throughput maksimum per jumlah vCore: Setiap konfigurasi vCore memiliki batas throughput maksimum, seperti yang ditunjukkan throughput maksimum per tabel vCore. Setelah IOPS yang diperlukan disediakan untuk mencapai batas ini, mengalokasikan IOPS tambahan meningkatkan kapasitas IOPS tetapi tidak meningkatkan throughput lebih lanjut. Misalnya, instans 4 vCore (maks 6.400 IOPS) mencapai batas throughput 145 MB/dtk pada 4.350 IOPS. Menskalakan IOPS dari 4.350 hingga 6.400 menyediakan lebih banyak IOPS ke instans, tetapi throughput tetap dibatasi pada 145 MB/dtk. Untuk meningkatkan throughput maksimum, tambahkan lebih banyak vCore.

Tabel berikut menunjukkan IOPS dan throughput maks per jumlah vCore yang dialokasikan untuk instans di tingkat layanan Tujuan Umum Next-gen:

Jumlah vCore	IOPS Maks	Throughput maksimum (MB/s)
4	6.400	145
6	9.600	217
8	12.800	290
10	16.000	367
12	19.200	445
16	25.600	600
20	32.000	665
24	38.400	730
32	51.200	865
40	64.000	1,152
48	76.800	1,152
56 - 128	80.000	1,200

Harga IOPS dalam Tujuan Umum Next-gen

Saat menggunakan IOPS tambahan, pertimbangkan hal berikut:

• IOPS tambahan dikenakan biaya per IOPS/bulan
• IOPS yang dapat ditagih dihitung dengan rumus berikut: Billable IOPS = Total IOPS - default IOPS.

Misalnya, jika Anda memiliki instans 4 vCore bayar sesuai penggunaan dengan 6400 IOPS, Anda dikenakan biaya untuk:

• 4 vCore
• Lisensi SQL untuk 4 vCore
• 1024 GB penyimpanan yang dipesan
• 3328 IOPS (6400 - (1024*3) = 3328 IOPS)yang dapat ditagih .

IOPS dan throughput di tingkat layanan Business Critical

Di tingkat layanan Business Critical, IOPS yang tersedia ditentukan oleh jumlah vCore menggunakan rumus 4000 IOPS/vCore. Karena tingkat layanan Business Critical menggunakan penyimpanan lokal untuk file data dan log, throughput tidak terbatas.

Tabel berikut mencantumkan IOPS maks yang tersedia di tingkat layanan Business Critical berdasarkan jumlah vCore:

Jumlah vCores	Kritis Bisnis
4	16.000
6	24.000
8	32.000
10	40.000
12	48.000
16	64.000
20	80.000
24	96.000
32	128.000
40	160.000
48	192.000
56	224,000
64	256.000
80	320,000
96	320,000
128	320,000

Penyimpanan data dan log

Faktor-faktor berikut memengaruhi jumlah penyimpanan yang digunakan untuk data dan file log. Faktor-faktor ini berlaku untuk tingkat Tujuan Umum dan Kritikal Bisnis.

• Di tingkat layanan Tujuan Umum, tempdb menggunakan penyimpanan SSD lokal, dan biaya penyimpanan ini sudah termasuk dalam harga vCore.
• Dalam tingkat layanan Business Critical, tempdb berbagi penyimpanan SSD lokal dengan data dan file log, dan tempdb biaya penyimpanan sudah termasuk dalam harga vCore. Anda dapat mengukur tempdb hingga ukuran penyimpanan instans yang saat ini tersedia.
• Anda harus menentukan ukuran penyimpanan maksimum untuk SQL Managed Instance dalam kelipatan 32 GB.

Penting

Di kedua tier layanan, Anda membayar untuk ukuran penyimpanan maksimum yang dikonfigurasi untuk SQL Managed Instance.

Untuk memantau total ukuran penyimpanan instans yang digunakan untuk Azure SQL Managed Instance, gunakan metrikstorage_space_used_mb. Untuk memantau ukuran penyimpanan data individual dan file log yang dialokasikan dan digunakan saat ini dalam database dengan menggunakan T-SQL, gunakan tampilan sys.database_files dan FILEPROPERTY(... , 'SpaceUsed') fungsi.

Petunjuk / Saran

Dalam beberapa keadaan, Anda mungkin perlu menyusutkan database untuk mengklaim kembali ruang yang tidak digunakan. Untuk informasi selengkapnya, lihat DBCC SHRINKFILE.

Pencadangan dan penyimpanan

Penyimpanan untuk pencadangan database dialokasikan untuk mendukung kemampuan pemulihan titik waktu (PITR) dan retensi jangka panjang (LTR) dari SQL Managed Instance. Penyimpanan ini terpisah dari penyimpanan data dan file log, dan ditagih secara terpisah.

• PITR:Di tingkat Tujuan Umum dan Kritis Bisnis, pencadangan database individual disalin ke penyimpanan geo-redundant (RA-GRS) akses baca secara otomatis. Ukuran penyimpanan meningkat secara dinamis saat cadangan baru dibuat. Penyimpanan digunakan oleh pencadangan penuh, diferensial, dan log transaksi. Konsumsi penyimpanan tergantung pada tingkat perubahan database dan periode penyimpanan yang dikonfigurasi untuk pencadangan. Anda dapat mengonfigurasi periode retensi terpisah untuk setiap database antara 1 hingga 35 hari untuk SQL Managed Instance. Jumlah penyimpanan cadangan yang sama dengan ukuran data maksimum yang dikonfigurasi disediakan tanpa biaya tambahan.

• LTR:Anda juga memiliki opsi untuk mengonfigurasi penyimpanan cadangan penuh jangka panjang hingga 10 tahun. Jika Anda menyiapkan kebijakan LTR, cadangan ini disimpan dalam penyimpanan RA-GRS secara otomatis, tetapi Anda dapat mengontrol seberapa sering cadangan disalin. Untuk memenuhi persyaratan kepatuhan yang berbeda, Anda dapat memilih periode retensi yang berbeda untuk cadangan mingguan, bulanan, dan tahunan. Konfigurasi yang Anda pilih menentukan berapa banyak penyimpanan yang digunakan untuk pencadangan LTR. Untuk informasi selengkapnya, lihat Retensi jangka panjang - Azure SQL Database dan Azure SQL Managed Instance.

Pertimbangan karakteristik tambahan

• Ukuran penyimpanan instans yang tersedia saat ini merupakan perbedaan antara ukuran instans yang dicadangkan dan ruang penyimpanan yang digunakan.

• Ukuran file data dan log di dalam database pengguna dan sistem disertakan dalam ukuran penyimpanan instans yang dibandingkan dengan batas ukuran penyimpanan maksimum. Gunakan tampilan sistem sys.master_files untuk menentukan total ruang yang digunakan oleh database. Log kesalahan tidak bertahan dan tidak disertakan dalam ukuran. Cadangan tidak disertakan dalam ukuran penyimpanan.

• Throughput dan IOPS di tingkat Tujuan Umum juga bergantung pada ukuran file, dan tidak secara eksplisit dibatasi oleh SQL Managed Instance.

• IOPS instans maksimum bergantung pada tata letak file dan distribusi beban kerja. Sebagai contoh, jika Anda membuat file 7 x 1-TB dengan IOPS maks 5 K masing-masing dan tujuh file kecil (lebih kecil dari 128 GB) dengan masing-masing 500 IOPS, Anda bisa mendapatkan 38500 IOPS per instans (7x5000+7x500) jika beban kerja Anda dapat menggunakan semua file. Beberapa IOPS juga digunakan untuk pencadangan otomatis.

• Anda dapat membuat replika lain yang dapat dibaca di wilayah Azure yang berbeda menggunakan grup failover

• tempdbNama file tidak boleh memiliki lebih dari 16 karakter.

Temukan informasi selengkapnya tentang batas sumber daya di kumpulan Azure SQL Managed Instance dalam artikel ini.

Memori fleksibel

Secara default, jumlah memori yang dialokasikan untuk Azure SQL Managed Instance adalah nilai statis yang ditentukan oleh jumlah vCore yang dipilih. Fitur memori fleksibel memungkinkan Anda mengubah jumlah memori yang dialokasikan ke instans terkelola SQL Anda tanpa mengubah jumlah vCore. Fitur ini berguna untuk beban kerja yang memerlukan lebih banyak memori daripada alokasi default untuk sejumlah vCore tertentu.

Fitur memori fleksibel tersedia di tingkat layanan dan konfigurasi penyebaran berikut pada perangkat keras seri Premium :

• Tujuan Umum generasi berikutnya: instance redundan lokal dan redundan zona . Memori fleksibel umumnya tersedia (GA) untuk instance redundan lokal dan saat ini sedang dalam pratinjau untuk instance zone-redundant. Instansi Next-gen General-Purpose yang redundant zona memerlukan penyimpanan Azure Elastic SAN zone-redundant (ZRS), yang tidak tersedia di beberapa wilayah multi-zona yang mendukung redundansi zona untuk SQL Managed Instance. Untuk ketersediaan Elastic SAN ZRS, lihat Buat dan terapkan Azure Elastic SAN.
• Bisnis Penting: instans redundan lokal dan zona-redundan . Memori fleksibel umumnya tersedia (GA) untuk tingkat layanan Business Critical.

Anda dapat mengubah jumlah memori yang dialokasikan ke instance yang dikelola SQL Anda kapan saja untuk instance baru dan yang sudah ada dengan menggunakan portal Azure atau REST API. Perubahan alokasi memori berlaku untuk semua database dalam instance dan melakukan failover instance sebagai langkah operasi terakhir. Periksa durasi operasi manajemen untuk menentukan perkiraan waktu operasi selesai.

Gunakan panel Compute + storage di portal Azure untuk mengubah alokasi memori, atau properties.memorySizeInGB nilai panggilan Managed Instance - Create or Update REST API yang dimulai dengan versi preview 2024-08-01. Tentukan alokasi memori dalam gigabyte (GB).

Saat mengalokasikan memori, Anda dapat memilih antara nilai minimum dan maksimum, dan juga menentukan rasio memori terhadap vCore. Nilai minimum dan maksimum tergantung pada jumlah vCores yang Anda pilih untuk instance tersebut. Rasio memori-ke-vCore adalah persentase dari total memori yang dialokasikan untuk instans.

Tabel berikut menunjukkan nilai memori minimum dan maksimum untuk fitur memori fleksibel:

vCore	RAM Min (GB)	RAM Maks (GB)	Nilai RAM API yang didukung	Rasio min	Rasio maks	Rasio yang didukung
4	28	48	28, 32, 40, 48	7	12	7, 8, 10, 12
6	42	72	42, 48, 60, 72	7	12	7, 8, 10, 12
8	56	96	56, 64, 80, 96	7	12	7, 8, 10, 12
10	70	120	70, 80, 100, 120	7	12	7, 8, 10, 12
12	84	144	84, 96, 120, 144	7	12	7, 8, 10, 12
16	112	192	112, 128, 160, 192	7	12	7, 8, 10, 12
20	140	240	140, 160, 200, 240	7	12	7, 8, 10, 12
24	168	288	168, 192, 240, 288	7	12	7, 8, 10, 12
32	224	384	224, 256, 320, 384	7	12	7, 8, 10, 12
40	280	480 (empat ratus delapan puluh)	280, 320, 400, 480	7	12	7, 8, 10, 12
48	336	480 (empat ratus delapan puluh)	336, 384, 480	7	10	7, 8, 10
56	392	448	392, 448	7	8	7, 8
64	448	448	448	7	7	8
80	560	560	560	7	7	8
96	560	560	560	5,83	5,83	5,83
128	560	560	560	4.38	4.38	4.38

Penetapan Harga

Saat Anda menggunakan fitur memori fleksibel, pertimbangkan detail berikut:

• Anda membayar memori ekstra per GB per jam.
• Memori yang dapat ditagih menggunakan rumus ini: Billable memory = Total memory - default memory.

Misalnya, jika Anda menggunakan instance 4 vCore bayar sesuai penggunaan dengan memori 40 GB, Anda membayar untuk:

• 4 vCore
• Lisensi SQL untuk 4 vCore
• 12 GB memori yang dapat ditagih (40 GB - (4*7) = 12 GB).

Wilayah yang didukung

Anda hanya dapat membuat SQL Managed Instance di wilayah yang didukung. Untuk membuat SQL Managed Instance di wilayah yang saat ini tidak didukung, kirim permintaan dukungan melalui portal Azure.

Jenis langganan yang didukung

SQL Managed Instance saat ini hanya mendukung penerapan pada jenis langganan berikut:

• Perjanjian Enterprise (EA)
• Bayar sesuai penggunaan
• Penyedia Cloud (CSP)
• Perusahaan Dev/Test
• Dev/Test bayar sesuai penggunaan
• Langganan dengan kredit Azure bulanan untuk pelanggan Visual Studio
• Coba Gratis
• Azure Untuk Siswa
• Azure Dalam Terbuka
• Paket Azure

Keterbatasan sumber daya wilayah

Catatan

Untuk informasi terbaru tentang ketersediaan wilayah untuk langganan, pertama-tama periksa pilih wilayah.

Jenis langganan yang didukung dapat berisi sumber daya dalam jumlah terbatas per wilayah. SQL Managed Instance memiliki satu batas default per wilayah Azure (yang dapat Anda tingkatkan sesuai permintaan dengan membuat permintaan dukungan khusus di portal Azure) tergantung pada jenis langganan:

• Batas unit vCore: Jumlah maksimum unit vCore per generasi perangkat keras yang dapat Anda terapkan di semua instance dalam satu wilayah. Satu GP vCore menggunakan satu unit vCore dan satu BC vCore membutuhkan empat unit vCore. Jumlah total instans tidak terbatas selama berada dalam batas unit vCore.

Catatan

Batas tersebut adalah pengaturan default dan bukan batasan teknis. Anda dapat meningkatkan batas sesuai permintaan dengan membuat permintaan dukungan khusus di portal Azure jika Anda membutuhkan lebih banyak instance di wilayah saat ini. Sebagai alternatif, Anda dapat membuat instans baru dari Azure SQL Managed Instance di wilayah Azure lain tanpa mengirim permintaan dukungan.

Tabel berikut ini memperlihatkan batas regional default untuk jenis langganan yang didukung (batas default dapat diperluas menggunakan permintaan dukungan):

Jenis langganan	Batas default untuk unit vCore 1
CSP	960 (1440 di beberapa wilayah2)
EA	960 (1440 di beberapa wilayah2)
Pengembangan/Pengujian Perusahaan	320
Bayar sesuai penggunaan	320
Pengembangan/Pengujian Prabayar	320
Azure Pass	64
Percikan Biz	64
BizSpark Plus	64
Microsoft Azure Sponsorship	64
Jaringan Mitra Microsoft	64
Visual Studio Enterprise (MPN)	64
Visual Studio Enterprise	32
Visual Studio Enterprise (BizSpark)	32
Visual Studio Professional	32
Platform MSDN	32

¹ Dalam merencanakan deployment, pertimbangkan bahwa tingkat layanan Business Critical (BC) membutuhkan kapasitas vCore empat (4) kali lebih besar dibandingkan tingkat layanan General Purpose (GP). Misalnya: 1 GP vCore = 1 unit vCore dan 1 BC vCore = 4 vCore. Untuk menyederhanakan analisis konsumsi Anda terhadap batas default, rangkum unit vCore per generasi perangkat keras di semua instance di wilayah tempat SQL Managed Instance diterapkan dan bandingkan hasilnya dengan batas unit vCore untuk jenis langganan Anda. Batas maksimum jumlah unit vCore berlaku untuk setiap langganan per generasi perangkat keras di suatu wilayah.

² batas vCore yang lebih besar tersedia di wilayah berikut: Australia Timur, Timur AS, Timur AS 2, Eropa Utara, Selatan Tengah AS, Asia Tenggara, Inggris Selatan, Eropa Barat, Barat AS 2.

Penting

Jika batas vCore Anda adalah 0, itu berarti batas regional default untuk jenis langganan Anda belum ditetapkan. Anda juga dapat menggunakan permintaan peningkatan kuota untuk mendapatkan akses langganan di wilayah tertentu dengan prosedur yang sama - memberikan nilai vCore yang diperlukan.

Batas vCore regional default dapat dikurangi atau ditangguhkan jika terjadi keterbatasan kapasitas regional.

Periksa batas kuota vCore dan penggunaan dengan PowerShell

Gunakan API Subscription Usages - Get REST untuk mengambil batas kuota vCore saat ini dan konsumsi untuk Azure SQL Managed Instance dalam langganan dan wilayah. Query setiap generasi perangkat keras secara terpisah dengan menentukan nama penggunaannya:

Pembuatan perangkat keras	Nama penggunaan
Seri Standar (Gen5)	SubscriptionSQLManagedInstanceStandardSeriesVCoreQuota
Seri premium	SubscriptionSQLManagedInstancePremiumSeriesVCoreQuota
Seri premium dengan memori dioptimalkans	SubscriptionSQLManagedInstancePremiumSeriesMemoryOptimizedVCoreQuota

Jalankan skrip berikut dalam sesi PowerShell dengan modul Az terpasang, atau di Azure Cloud Shell menggunakan PowerShell. Akun Anda memerlukan izin untuk membaca penggunaan langganan, seperti peran Pembaca yang ditetapkan pada lingkup langganan.

Ganti <subscription-id> dengan ID langganan Anda, atur $location ke nama wilayah Azure (misalnya, eastus), dan atur $usageName ke salah satu nilai di tabel sebelumnya. Jika Anda sudah masuk melalui Cloud Shell, hilangkan .Connect-AzAccount

$subscriptionId = "<subscription-id>"
$location = "eastus"
$usageName = "SubscriptionSQLManagedInstanceStandardSeriesVCoreQuota"

Connect-AzAccount -ErrorAction Stop | Out-Null
Set-AzContext -SubscriptionId $subscriptionId -ErrorAction Stop | Out-Null

$path = "/subscriptions/$subscriptionId/providers/Microsoft.Sql/locations/$location/usages/${usageName}?api-version=2025-01-01"
$response = Invoke-AzRestMethod -Method GET -Path $path -ErrorAction Stop

if ($response.StatusCode -ne 200) {
    throw "Unable to retrieve quota usage. HTTP $($response.StatusCode): $($response.Content)"
}

$response.Content | ConvertFrom-Json -ErrorAction Stop | ConvertTo-Json -Depth 10

Contoh keluaran (kutipan; nilainya ilustratif):

{
  "name": "SubscriptionSQLManagedInstanceStandardSeriesVCoreQuota",
  "properties": {
    "currentValue": 80,
    "limit": 320,
    "unit": "SubscriptionSQLManagedInstanceStandardSeriesVCoreQuota"
  }
}

Dalam contoh ini, properties.currentValue adalah kuota konsumsi saat ini: 80 unit vCore. properties.limit adalah batas kuota saat ini: 320 unit vCore. Kuota yang tersisa adalah limit - currentValue, atau 240 unit vCore, untuk perangkat keras seri standar dalam langganan dan wilayah yang ditentukan.

Seperti yang dijelaskan sebelumnya dalam bagian ini, setiap vCore Tujuan Umum mengonsumsi satu unit vCore, dan setiap vCore Business Critical mengonsumsi empat unit vCore. Ulangi permintaan dengan perangkat keras yang berbeda $usageName atau $location untuk memeriksa generasi perangkat keras atau wilayah lain. Untuk meningkatkan batas, lihat Minta kenaikan kuota.

Penting

Nama penggunaan yang sebelumnya digunakan VCoreQuota , yang mewakili satu kuota regional yang dibagikan di semua generasi perangkat keras, kini dihentikan dan digantikan dengan kuota khusus generasi perangkat keras. Gunakan nama penggunaan yang tercantum dalam tabel sebelumnya untuk mengambil batas kuota dan konsumsi untuk setiap generasi perangkat keras.

Meminta penambahan kuota

Jika Anda membutuhkan lebih banyak instance di wilayah Anda saat ini, kirim permintaan dukungan untuk memperpanjang kuota dengan menggunakan portal Azure. Untuk informasi selengkapnya, lihat Meminta peningkatan kuota untuk Azure SQL Database dan SQL Managed Instance.

Catatan

Mulai Agustus 2026, jenis permintaan kuota SQL Managed Instance berubah. Kuota subnet tidak lagi berlaku, dan kuota vCore kini diatur cakupan per generasi perangkat keras. Untuk informasi lebih lanjut, lihat tipe permintaan kuota SQL Managed Instance.

Konten terkait

• Apa itu Azure SQL Managed Instance?
• harga SQL Managed Instance
• panduan mulai cepat
• SLA untuk Azure SQL Managed Instance
• Referensi konfigurasi yang dapat dimodifikasi untuk Azure SQL Managed Instance