Bagikan melalui

Tanya Jawab Umum Azure SQL Database Hyperscale

Berlaku untuk:Azure SQL Database

Artikel ini menyediakan jawaban atas pertanyaan yang sering diajukan untuk pelanggan yang mempertimbangkan database di tingkat layanan Azure SQL Database Hyperscale, yang akan disebut sebagai Hyperscale saja di sisa FAQ ini. Artikel ini menjelaskan skenario yang didukung Hyperscale dan fitur yang kompatibel dengan Hyperscale.

  • FAQ ini ditujukan untuk pembaca yang memiliki pemahaman singkat tentang tingkat layanan Hyperscale dan ingin pertanyaan dan kekhawatiran spesifik mereka terjawab.
  • FAQ ini tidak dimaksudkan untuk menjadi buku panduan atau menjawab pertanyaan tentang cara menggunakan database Hyperscale. Untuk pengenalan Hyperscale, lihat Azure SQL Database Hyperscale.

Pertanyaan umum

Apakah itu database Hyperscale?

Database Hyperscale adalah database di Azure SQL Database yang didukung oleh hyperscale menskalakan teknologi penyimpanan. Database Hyperscale mendukung hingga 128 TB data dan memberikan throughput dan performa tinggi, serta penskalaan yang cepat untuk beradaptasi dengan persyaratan beban kerja. Konektivitas, pemrosesan kueri, fitur mesin database, dan sebagainya, berfungsi seperti di database lain di Azure SQL Database.

Tingkat komputasi dan model pembelian apa yang mendukung Hyperscale?

Tingkat layanan Hyperscale tersedia untuk database tunggal (baik yang disediakan maupun tanpa server) dan untuk kumpulan elastis menggunakan model pembelian berbasis vCore. Ini tidak tersedia dalam model pembelian berbasis DTU.

Bagaimana tingkat layanan Hyperscale berbeda dari tingkat layanan Tujuan Umum dan Bisnis Kritis?

Tingkat layanan berbasis vCore dibedakan berdasarkan ketersediaan database dan jenis penyimpanan, performa, dan ukuran penyimpanan maksimum, seperti yang dijelaskan dalam perbandingan batas sumber daya.

Siapa yang harus menggunakan tingkat layanan Hyperscale?

Tingkat layanan Hyperscale adalah untuk semua pelanggan yang mencari performa dan ketersediaan yang lebih tinggi, pencadangan dan pemulihan yang cepat, penyimpanan cepat, dan skalabilitas komputasi. Ini termasuk pelanggan yang memulai dari yang kecil dan berkembang, mereka yang menjalankan database misi penting besar, mereka yang pindah ke cloud untuk memodernisasi aplikasi dan pelanggan mereka yang sudah menggunakan tingkat layanan lain di Azure SQL Database.

Dengan Hyperscale, Anda mendapatkan:

  • Ukuran database yang dapat tumbuh dari 10 GB hingga 128 TB, terlepas dari ukuran komputasi.
  • Komputasi sumber daya vCore dari 2 vCore hingga 128 vCore.
  • Pencadangan database cepat terlepas dari ukuran database (cadangan didasarkan pada rekam jepret penyimpanan).
  • Pemulihan database cepat terlepas dari ukuran database (pemulihan berasal dari rekam jepret penyimpanan).
  • Throughput log transaksi yang lebih tinggi terlepas dari ukuran database dan jumlah vCore.
  • Baca Peluasan skala menggunakan satu atau beberapa replika baca-saja, digunakan untuk membongkar beban kerja baca-saja atau sebagai database siaga panas.
  • Meningkatkan skala komputasi dengan cepat, dalam waktu yang konstan, agar lebih mampu untuk mengakomodasi beban kerja yang berat dan kemudian menurunkan skala, dalam waktu yang konstan. Operasi penskalaan membutuhkan waktu satu digit menit untuk komputasi yang disediakan, dan kurang dari satu detik untuk komputasi tanpa server, terlepas dari ukuran database.
  • Opsi untuk membayar apa yang Anda gunakan dengan komputasi tanpa server, di mana komputasi ditagih berdasarkan penggunaan.

Wilayah apa yang saat ini mendukung Hyperscale?

Tingkat layanan Hyperscale tersedia di semua wilayah tempat Azure SQL Database tersedia.

Bisakah saya membuat beberapa database Hyperscale per server?

Ya. Untuk informasi selengkapnya dan batas jumlah database setiap server, lihat Batas sumber daya SQL Database untuk database tunggal dan kumpulan di server.

Apa karakteristik kinerja database Hyperscale?

Arsitektur Hyperscale memberikan performa dan throughput tinggi sekaligus mendukung ukuran database yang besar.

Apa skalabilitas database Hyperscale?

Hyperscale memberikan skalabilitas yang cepat berdasarkan permintaan beban kerja Anda.

  • Meningkatkan/Menurunkan Skala

    Dengan Hyperscale, Anda dapat meningkatkan ukuran komputasi utama pada aspek sumber daya seperti CPU dan memori, lalu menurunkan skala, dalam waktu konstan. Karena penyimpanan bersifat jarak jauh, meningkatkan dan menurunkan skala bukanlah operasi ukuran data.

    Dukungan untuk komputasi tanpa server menyediakan penagihan skala dan penurunan skala dan komputasi otomatis berdasarkan penggunaan.

  • Mempersempit/Memperluas Skala

    Dengan Hyperscale, Anda dapat menggunakan tiga jenis replika sekunder untuk memenuhi persyaratan peluasan skala, ketersediaan tinggi, dan replikasi geografis. Drive ini termasuk:

Pertanyaan lanjutan

Dapatkah saya mencampur database Hyperscale dan non-Hyperscale di server logis SQL yang sama?

Ya, Anda bisa.

Apakah Hyperscale mengharuskan model pemrograman aplikasi saya berubah?

Tidak, model pemrograman aplikasi Anda tetap sama seperti database MSSQL lainnya. Gunakan string koneksi Anda seperti biasa dan cara reguler lainnya untuk berinteraksi dengan database Hyperscale Anda. Setelah aplikasi Anda menggunakan database Hyperscale, aplikasi Anda dapat memanfaatkan fitur seperti replika sekunder.

Tingkat isolasi transaksi apa yang menjadi default dalam database Hyperscale?

Pada replika utama, tingkat isolasi transaksi default READ COMMITTED dengan opsi database READ_COMMITTED_SNAPSHOT (RCSI) diaktifkan. Pada replika sekunder, tingkat isolasi SNAPSHOT. Ini sama seperti di database Azure SQL lainnya.

Dapatkah saya membawa lisensi saya di tempat atau iaaS SQL Server ke Hyperscale?

Dengan harga baru yang disederhanakan berlaku sejak 15 Desember 2023, harga komputasi telah dikurangi untuk database Hyperscale yang baru dibuat, semua database Hyperscale tanpa server, dan semua kumpulan elastis Hyperscale. Dengan harga baru yang disederhanakan, Anda tidak perlu menerapkan Azure Hybrid Benefit (AHB) untuk mendapatkan penghematan yang setara. Azure Hybrid Benefit (AHB) hanya dapat diterapkan ke database tunggal Hyperscale yang lebih lama (dibuat sebelum 15 Desember 2023) hyperscale dengan komputasi yang disediakan. Untuk database lama tersebut, AHB hanya berlaku hingga Desember 2026, setelah itu database tersebut juga akan ditagih sesuai harga baru yang disederhanakan.

Untuk informasi selengkapnya, lihat blog harga Hyperscale dan Azure SQL Database Hyperscale - harga yang lebih rendah dan disederhanakan.

Beban kerja seperti apa hyperscale dirancang untuk?

Hyperscale berfungsi dengan baik untuk semua jenis beban kerja, termasuk beban kerja OLTP, Hibrid (HTAP), dan Analitis (pasar data).

Bagaimana cara memilih antara Azure Synapse Analytics dan Azure SQL Database Hyperscale?

Jika saat ini Anda menjalankan kueri analitik interaktif menggunakan SQL Server sebagai gudang data, Hyperscale adalah opsi yang bagus karena Anda dapat menghosting gudang data kecil dan menengah (seperti beberapa TB hingga 128 TB) dengan biaya yang lebih rendah, dan Anda dapat memigrasikan beban kerja gudang data SQL Server Anda ke Hyperscale dengan perubahan kode T-SQL minimal.

Jika Anda menjalankan analitik data dalam skala besar dengan kueri kompleks dan tingkat penyerapan berkelanjutan yang lebih tinggi dari 100 MiB/dtk atau menggunakan Gudang Data Paralel (PDW), Teradata, atau gudang data Pemrosesan Paralel Besar-Besaran (MPP) lainnya seperti Azure Synapse Analytics, maka Microsoft Fabric bisa menjadi pilihan terbaik.

Tingkat penyerapan atau pembuatan log adalah 150 MiB/dtk per database untuk perangkat keras memori seri premium dan seri premium yang dioptimalkan dari Azure SQL Database Hyperscale. Untuk perangkat keras seri standar, laju log maksimum adalah 100 MiB/dtk per database. Untuk kumpulan elastis, laju log maksimum adalah 150 MiB/dtk per kumpulan untuk perangkat keras yang dioptimalkan memori seri premium dan premium, dan 125 MiB/dtk per kumpulan untuk perangkat keras lainnya.

Pertanyaan komputasi Hyperscale

Dapatkah saya menjeda komputasi saya kapan saja?

Tidak untuk saat ini. Namun, Anda dapat menskalakan komputasi dan jumlah replika turun untuk mengurangi biaya selama waktu nonpeak, atau menggunakan tanpa server untuk menskalakan komputasi secara otomatis berdasarkan penggunaan.

Dapatkah saya menyediakan replika komputasi dengan RAM tambahan untuk beban kerja intensif memori saya?

Untuk beban kerja pembacaan, Anda dapat membuat replika bernama dengan ukuran komputasi yang lebih tinggi (lebih banyak core dan memori) daripada yang utama. Untuk informasi selengkapnya tentang ukuran komputasi yang tersedia, lihat Penyimpanan Hyperscale dan ukuran komputasi.

Dapatkah saya menyediakan beberapa replika komputasi dengan ukuran yang berbeda?

Untuk beban kerja pembacaan, hal ini dapat dicapai dengan menggunakan replika bernama.

Berapa banyak replika Read Scale-out yang didukung?

Anda dapat menskalakan jumlah replika sekunder high availability antara 0 dan 4 menggunakan portal Microsoft Azure atau REST API. Selain itu, Anda dapat membuat hingga 30 replika bernama untuk banyak skenario peluasan skala pembacaan. Setiap replika bernama dapat memiliki replika sekunder hingga 4 HA.

Untuk ketersediaan tinggi, apakah saya perlu menyediakan replika komputasi tambahan?

Dalam database Hyperscale, ketahanan data disediakan pada tingkat penyimpanan. Anda hanya perlu satu replika (utama) untuk memberikan ketahanan. Jika replika komputasi gagal atau sedang dalam pemeliharaan, replika baru dibuat secara otomatis tanpa kehilangan data.

Namun, jika hanya ada replika utama, dibutuhkan satu atau dua menit untuk membuat replika baru, vs. detik dalam kasus ketika replika sekunder HA tersedia. Replika baru awalnya akan memiliki cache dingin, yang dapat mengakibatkan latensi penyimpanan yang lebih tinggi dan mengurangi performa kueri segera setelah failover.

Untuk aplikasi penting misi yang memerlukan ketersediaan tinggi dengan dampak failover minimal, Anda harus menyediakan setidaknya satu replika sekunder HA untuk memastikan replika siaga panas tersedia untuk berfungsi sebagai target failover.

Pertanyaan ukuran dan penyimpanan data

Berapa ukuran database maksimum yang didukung dengan Hyperscale?

Ukuran maksimum database Hyperscale tunggal saat ini adalah 128 TB, terlepas dari ukuran komputasi. Ukuran maksimum database dalam kumpulan elastis Hyperscale saat ini adalah 100 TB.

Berapa ukuran log transaksi dengan Hyperscale?

Di Hyperscale, log transaksi praktis tidak terbatas, dengan batasan bahwa bagian aktif log tidak boleh melebihi 1 TB. Bagian aktif log dapat tumbuh karena transaksi yang berjalan lama, atau karena pemrosesan Change Data Capture tidak mengikuti tingkat perubahan data. Hindari transaksi panjang dan besar yang tidak perlu untuk tetap di bawah batas ini. Selain pembatasan ini, Anda tidak perlu khawatir kehabisan ruang log pada sistem yang memiliki throughput log tinggi. Namun, tingkat pembuatan log mungkin dikurangi untuk terus menulis beban kerja secara agresif. Tingkat pembuatan log 150 MiB/dtk untuk perangkat keras yang dioptimalkan memori seri premium dan seri premium, dan 100 MiB/dtk untuk perangkat keras lainnya.

Apakah skala tempdb saya saat database saya tumbuh?

Database tempdb Anda berada di penyimpanan SSD lokal dan berukuran proporsional dengan ukuran komputasi (jumlah core) yang Anda sediakan. Ukuran tempdb tidak dapat dikonfigurasi dan dikelola untuk Anda. Untuk menentukan ukuran tempdb maksimum untuk database Anda, lihat Penyimpanan dan ukuran komputasi Hyperscale.

Apakah ukuran database saya secara otomatis tumbuh, atau apakah saya harus mengelola ukuran file data?

Ukuran database Anda secara otomatis bertambah saat Anda menyisipkan/menyerap lebih banyak data.

Berapa ukuran database terkecil yang didukung Hyperscale?

10 GB. Database Hyperscale dibuat dengan ukuran awal 10 GB dan tumbuh sesuai kebutuhan.

Dengan kenaikan apa ukuran database saya tumbuh?

Setiap file data tumbuh sebesar 10 GB. Beberapa file data dapat tumbuh secara bersamaan.

Apakah penyimpanan di Hyperscale lokal atau terpencil?

Di Hyperscale, file data disimpan di penyimpanan standar Azure. Data sepenuhnya disimpan di penyimpanan SSD lokal, di server halaman yang bersifat jarak jauh untuk menghitung replika. Selain itu, replika komputasi memiliki cache data pada SSD lokal dan memori, untuk mengurangi frekuensi pengambilan data dari server halaman jarak jauh.

Bisakah saya mengelola atau mendefinisikan file atau grup file dengan Hyperscale?

Tidak. File data ditambahkan secara otomatis ke grup file PRIMARY. Alasan umum untuk membuat grup file tambahan tidak berlaku dalam arsitektur penyimpanan Hyperscale, atau di Azure SQL Database secara lebih luas.

Bisakah saya memberikan topi keras pada pertumbuhan data untuk database saya?

Tidak.

Apakah penyusutan database didukung?

Ya, database dan operasi penyusutan file didukung di Azure SQL Database Hyperscale.

Apakah kompresi data didukung?

Ya, sama seperti di database Azure SQL DB lainnya. Ini termasuk kompresi baris, halaman, dan penyimpan kolom .

Jika saya memiliki tabel besar, apakah data tabel tersebar di beberapa file data?

Ya. Halaman data yang terkait dengan tabel tertentu dapat disebar ke beberapa file data, yang semuanya merupakan bagian dari grup file yang sama. Mesin database MSSQL menggunakan strategi pengisian proporsional untuk mendistribusikan data melalui file data.

Pertanyaan migrasi data

Bisakah saya memindahkan database saya yang sudah ada Azure SQL Database ke tingkat layanan Hyperscale?

Ya. Untuk bukti konsep (POC), kami sarankan Anda membuat salinan database Anda dan memigrasikan salinan tersebut ke Hyperscale.

Waktu yang diperlukan untuk memindahkan database yang ada ke Hyperscale terdiri dari waktu untuk menyalin data, dan waktu untuk memutar ulang perubahan yang dibuat di database sumber saat menyalin data. Waktu penyalinan data disesuaikan dengan ukuran data. Waktu untuk memutar ulang perubahan lebih pendek jika pemindahan dilakukan selama periode aktivitas tulis rendah.

Anda dapat mengonversi Azure SQL Database yang sudah ada ke Hyperscale di portal Microsoft Azure, Azure CLI, PowerShell, dan Transact-SQL. Untuk informasi selengkapnya, lihat Mengonversi database yang sudah ada ke Hyperscale. Kemampuan untuk mengonversi database non-Hyperscale yang direplikasi secara geografis ke Hyperscale menggunakan T-SQL, REST API, PowerShell, atau Azure CLI saat ini adalah fitur pratinjau.

Migrasi terbalik ke tingkat layanan Tujuan Umum memungkinkan pelanggan yang baru saja memigrasikan database yang ada di Azure SQL Database ke tingkat layanan Hyperscale untuk pindah kembali, jika Hyperscale tidak memenuhi kebutuhan mereka. Sementara migrasi terbalik dimulai oleh perubahan tingkat layanan, pada dasarnya ini merupakan operasi ukuran data antara arsitektur yang berbeda. Demikian pula dengan migrasi ke Hyperscale, migrasi terbalik lebih cepat jika dilakukan selama periode aktivitas tulis rendah. Untuk informasi selengkapnya, lihat Migrasi terbalik dari Hyperscale.

Bisakah saya memindahkan database Hyperscale saya ke tingkat layanan lain?

Jika sebelumnya Anda telah memigrasikan Azure SQL Database yang ada ke tingkat layanan Hyperscale, Anda dapat melakukan migrasi terbalik ke tingkat layanan Tujuan Umum dalam waktu 45 hari sejak migrasi awal ke Hyperscale. Jika Anda ingin memigrasikan database ke tingkat layanan lain, seperti Business Critical, lakukan migrasi balik terlebih dahulu ke tingkat layanan Tujuan Umum, lalu modifikasi tingkat layanan. Migrasi terbalik adalah operasi ukuran data.

Database yang dibuat di tingkat layanan Hyperscale tidak dapat dipindahkan ke tingkat layanan lain.

Pelajari cara membalikkan migrasi dari Hyperscale, termasuk batasan untuk migrasi terbalik dan kebijakan cadangan yang terpengaruh.

Apakah saya kehilangan fungsionalitas atau kemampuan setelah migrasi ke tingkat layanan Hyperscale?

Ya. Beberapa fitur Azure SQL Database tidak didukung di Hyperscale. Jika beberapa fitur ini diaktifkan untuk database Anda, migrasi ke Hyperscale dapat diblokir, atau fitur-fitur ini berhenti berfungsi setelah migrasi. Untuk detailnya, lihat Batasan yang diketahui.

Bisakah saya memindahkan database SQL Server lokal saya, atau database SQL Server saya di komputer virtual cloud ke Hyperscale?

Ya. Anda dapat menggunakan banyak teknologi migrasi yang ada untuk bermigrasi ke Hyperscale, termasuk replikasi transaksional, dan teknologi pemindahan data lainnya (Salin Massal, Azure Data Factory, Azure Databricks, SSIS). Lihat juga Azure Database Migration Service, yang mendukung banyak skenario migrasi.

Apa waktu henti saya selama migrasi dari lingkungan mesin lokal atau virtual ke Hyperscale, dan bagaimana cara meminimalkannya?

Waktu henti untuk migrasi ke Hyperscale sama dengan waktu henti saat Anda melakukan migrasi database ke tingkat layanan Azure SQL Database lainnya. Anda dapat menggunakan replikasi transaksional untuk meminimalkan migrasi waktu henti untuk database yang berukuran hingga beberapa TB. Untuk database yang sangat besar (10+ TB), Anda dapat mempertimbangkan untuk menerapkan proses migrasi menggunakan Azure Data Factory, Spark, atau teknologi pemindahan data massal lainnya.

Berapa banyak waktu yang dibutuhkan untuk membawa data dalam jumlah X ke Hyperscale?

Hyperscale mampu mengonsumsi hingga 150 MiB/dtk data baru/yang diubah, tetapi waktu yang diperlukan untuk memindahkan data ke database di Azure SQL Database juga dipengaruhi oleh throughput jaringan yang tersedia, kecepatan baca sumber, jenis beban (massal vs baris demi baris), dan tujuan tingkat layanan database target.

Dapatkah saya membaca data dari penyimpanan blob dan melakukan pemuatan cepat (seperti Polybase di Azure Synapse Analytics)?

Anda dapat membuat aplikasi klien membaca data dari Azure Storage dan memuat data ke dalam database Hyperscale (seperti yang bisa Anda lakukan dengan database lain di Azure SQL Database). Saat ini Polybase tidak didukung di Azure SQL Database. Sebagai alternatif untuk menyediakan beban cepat, gunakan Azure Data Factory.

Anda juga dapat membaca data secara massal dari penyimpanan Azure Blob menggunakan BULK INSERT atau OPENROWSET: Contoh Akses Massal ke Data di Azure Blob Storage.

Model pemulihan sederhana atau dicatat massal tidak didukung di Hyperscale. Model pemulihan penuh diperlukan untuk memberikan ketersediaan tinggi dan pemulihan pada waktu tertentu. Namun, arsitektur log Hyperscale memberikan tingkat penyerapan data yang lebih baik dibandingkan dengan tingkat layanan Azure SQL Database lainnya.

Apakah Hyperscale memungkinkan penyediaan beberapa simpul untuk menelan data dalam jumlah besar secara paralel?

Tidak. Hyperscale adalah arsitektur multi-pemrosesan simetris (SMP) dan bukan pemrosesan paralel besar-besaran (MPP) atau arsitektur multi-master. Anda dapat membuat beberapa replika untuk meluaskan skala beban kerja baca-saja.

Apakah Hyperscale mendukung migrasi dari sumber data lain seperti Amazon Aurora, MySQL, PostgreSQL, Oracle, DB2, dan platform database lainnya?

Ya. Azure Database Migration Service mendukung banyak skenario migrasi.

Ketika saya mengonversi database ke Hyperscale, kapan penagihan Hyperscale dimulai?

Penagihan hyperscale setelah konversi dimulai hanya setelah cutover selesai.

Ketika saya mengonversi ke Hyperscale, dapatkah saya mengontrol gangguan pada database saya?

Ya. Saat memulai konversi, Anda memiliki opsi untuk menentukan sifat cutover. Ini bisa otomatis, segera setelah siap, atau dimulai secara manual ketika Anda siap. Untuk informasi selengkapnya, lihat Mengonversi database ke Hyperscale. Anda dapat memulai cutover secara manual melalui portal Microsoft Azure, PowerShell, Azure CLI, atau T-SQL. Anda hanya akan mengalami waktu henti dalam waktu singkat, umumnya kurang dari satu menit, selama cutover akhir ke Hyperscale.

Pertanyaan keberlangsungan Bisnis dan Pemulihan Bencana

SLA apa yang disediakan untuk database Hyperscale?

Lihat SLA untuk Azure SQL Database. Sebaiknya tambahkan replika sekunder high availability untuk beban kerja penting. Hal ini memberikan failover yang lebih cepat, dan mengurangi potensi dampak performa segera setelah failover.

Apakah cadangan database dikelola untuk saya Azure SQL Database?

Ya.

Apakah Hyperscale mendukung Zona Ketersediaan?

Ya, Hyperscale mendukung konfigurasi zona redundan. Setidaknya satu replika sekunder HA dan penggunaan penyimpanan zona-redundan atau geo-zona-redundan diperlukan untuk mengaktifkan konfigurasi zona redundan untuk Hyperscale.

Apakah Hyperscale mendukung kumpulan elastis?

Ya. Untuk informasi selengkapnya, lihat Kumpulan elastis Hyperscale dan Blog: Kumpulan Elastis Hyperscale sekarang tersedia secara umum.

Seberapa sering cadangan database diambil?

Tidak ada cadangan log transaksional yang lengkap, berbeda, dan tradisional untuk database Hyperscale. Sebagai gantinya, terdapat snapshot penyimpanan reguler dari file data, dengan irama snapshot terpisah untuk setiap file. Log transaksi yang dihasilkan disimpan apa adanya untuk periode retensi yang dikonfigurasi. Pada waktu pemulihan, catatan log transaksi yang relevan diterapkan ke snapshot penyimpanan yang dipulihkan. Terlepas dari irama rekam jepret, ini menghasilkan database yang konsisten secara transaksional pada titik waktu yang ditentukan dalam periode retensi, tanpa kehilangan data. Akibatnya, cadangan database di Hyperscale berjalan terus menerus.

Apakah Hyperscale mendukung pemulihan point-in-time?

Ya.

Apa itu Tujuan Titik Pemulihan (RPO)/Tujuan Waktu Pemulihan (RTO) untuk pemulihan database di Hyperscale?

RPO untuk pemulihan titik waktu adalah 0 mnt. Sebagian besar operasi pemulihan titik waktu selesai dalam 60 menit terlepas dari ukuran database. Waktu pemulihan bisa lebih lama untuk database yang lebih besar, dan jika database mengalami aktivitas penulisan yang signifikan sebelum dan hingga titik pemulihan tepat waktu. Mengeluarkan pemulihan setelah perubahan baru-baru ini redundansi penyimpanan dapat mengakibatkan waktu pemulihan yang lebih lama karena pemulihan dapat menjadi operasi ukuran data dalam hal ini, dan waktu pemulihan mungkin sebanding dengan ukuran database.

Apakah pencadangan database mempengaruhi kinerja komputasi pada replika utama atau sekunder saya?

Tidak. Cadangan dikelola oleh subsistem penyimpanan, dan menggunakan rekam jepret penyimpanan. Mereka tidak memengaruhi beban kerja pengguna.

Bisakah saya melakukan pemulihan geografis dengan database Hyperscale?

Ya. Pemulihan geografis didukung sepenuhnya jika penyimpanan geo-redundan atau geo-zona-redundan digunakan. Penyimpanan geo-redundan adalah default untuk database baru. Tidak seperti pemulihan berdasar waktu, pemulihan geo memerlukan operasi ukuran data. File data disalin secara paralel, sehingga durasi operasi ini utamanya tergantung pada ukuran file terbesar dalam database, bukan pada ukuran database total. Waktu pemulihan geografis secara signifikan lebih singkat jika database dipulihkan di wilayah Azure yang dipasangkan dengan wilayah database sumber. Untuk informasi selengkapnya, lihat Pemulihan geografis untuk Azure SQL Database.

Bisakah saya menyiapkan replikasi geografis atau menggunakan grup failover dengan database Hyperscale?

Ya. replikasi geografis dan grup failover dapat disiapkan untuk database Hyperscale.

Bisakah saya mengambil cadangan database Hyperscale dan memulihkannya ke server lokal saya, atau di SQL Server di VM?

Tidak. Format penyimpanan untuk database Hyperscale berbeda dari versi SQL Server yang dirilis, dan Anda tidak mengontrol cadangan atau memiliki akses ke cadangan tersebut. Untuk mengeluarkan data Anda dari database Hyperscale, Anda dapat mengekstrak data menggunakan teknologi pergerakan data apa pun seperti Azure Data Factory, Azure Databricks, SSIS, dll.

Apakah saya akan dikenakan biaya penyimpanan cadangan di Hyperscale?

Ya. Berlaku mulai 4 Mei 2022, pencadangan untuk semua database baru dikenakan biaya berdasarkan penyimpanan cadangan yang digunakan dan redundansi penyimpanan yang dipilih pada tarif yang diambil di halaman harga Azure SQL Database. Untuk database Hyperscale yang dibuat sebelum 4 Mei 2022, cadangan hanya akan dikenakan biaya jika retensi cadangan diatur menjadi lebih besar dari tujuh hari. Untuk mempelajari selengkapnya, lihat Pencadangan Hyperscale dan redundansi penyimpanan.

Bagaimana saya dapat mengukur ukuran penyimpanan cadangan di database Hyperscale saya?

Untuk detail tentang cara mengukur ukuran penyimpanan cadangan, lihat Pencadangan Otomatis.

Bagaimana saya mengetahui berapa tagihan cadangan saya?

Untuk menentukan tagihan penyimpanan cadangan Anda, ukuran penyimpanan cadangan dihitung secara berkala, dan dikalikan dengan tingkat penyimpanan cadangan dan jumlah jam sejak perhitungan terakhir. Untuk memperkirakan tagihan cadangan Anda selama jangka waktu tertentu, kalikan ukuran penyimpanan cadangan yang dapat ditagih untuk setiap jam dalam periode tersebut dengan tarif penyimpanan cadangan, dan jumlahkan semua jumlah per jam. Guna mengkueri metrik Azure Monitor yang relevan untuk beberapa interval per jam secara terprogram, gunakan REST API Azure Monitor. Penagihan cadangan di tingkat komputasi tanpa server sama seperti di tingkat komputasi yang disediakan.

Bagaimana beban kerja saya memengaruhi biaya penyimpanan cadangan?

Biaya cadangan lebih tinggi untuk beban kerja yang menambahkan, memodifikasi, atau menghapus data dalam volume besar dalam database. Sebaliknya, beban kerja yang sebagian besar bersifat baca-saja mungkin memiliki biaya cadangan yang lebih kecil.

Bagaimana cara meminimalkan biaya penyimpanan cadangan?

Untuk detail tentang cara meminimalkan biaya penyimpanan cadangan, lihat Pencadangan Otomatis.

Dapatkah saya memulihkan database Hyperscale saya ke tingkat layanan lain, atau sebaliknya?

Saat ini, pencadangan tingkat layanan non-Hyperscale (Dasar/Standar/Premium/Tujuan Umum/Kritis Bisnis) tidak dapat dipulihkan secara geografis ke tingkat layanan Hyperscale dan sebaliknya. Untuk mengonversi database non-Hyperscale ke database Hyperscale, ubah tingkat layanan setelah pemulihan.

Pertanyaan performa

Berapa banyak throughput tulis yang dapat saya dorong dalam database Hyperscale?

Batas throughput log transaksi adalah 100 MiB/dtk untuk ukuran komputasi Hyperscale apa pun. Kemampuan untuk mencapai tingkat ini tergantung pada beberapa faktor, termasuk tetapi tidak terbatas pada jenis beban kerja, konfigurasi dan performa klien, dan memiliki kapasitas komputasi yang memadai pada replika komputasi utama untuk menghasilkan catatan log pada tingkat ini. Tingkat penyerapan atau pembuatan log adalah 150 MiB/dtk per database untuk perangkat keras memori seri premium dan seri premium yang dioptimalkan dari Azure SQL Database Hyperscale. Untuk perangkat keras seri standar, laju log maksimum adalah 100 MiB/dtk per database. Untuk kumpulan elastis, laju log maksimum adalah 150 MiB/dtk per kumpulan untuk perangkat keras yang dioptimalkan memori seri premium dan premium, dan 125 MiB/dtk per kumpulan untuk perangkat keras lainnya.

Berapa banyak IOPS yang saya dapatkan pada komputasi terbesar?

Latensi IOPS dan IO bervariasi tergantung pada pola beban kerja. Jika data yang diakses di-cache di penyimpanan SSD lokal pada replika komputasi, Anda akan melihat performa IO serupa seperti di tingkat layanan Business Critical atau Premium.

Apakah throughput saya terpengaruh oleh cadangan?

Tidak. Komputasi dipisahkan dari lapisan penyimpanan. Ini menghilangkan dampak performa cadangan.

Apakah throughput saya terpengaruh saat saya menyediakan replika komputasi tambahan?

Karena penyimpanan dibagikan dan tidak ada replikasi fisik langsung yang terjadi antara replika komputasi primer dan sekunder, throughput pada replika utama tidak terpengaruh secara langsung dengan menambahkan replika sekunder. Namun, tingkat log untuk beban kerja tulis berkelanjutan dan agresif mungkin terbatas pada primer untuk memungkinkan log berlaku pada replika sekunder dan server halaman untuk mengejar ketinggalan. Hal ini menghindari performa pembacaan yang buruk pada replika sekunder dan pemulihan yang lama setelah failover ke replika sekunder high availability.

Apakah Hyperscale sangat cocok untuk kueri dan transaksi yang intensif sumber daya, jangka panjang, dan transaksi?

Ya. Namun, sama seperti di database Azure SQL lainnya, koneksi mungkin dihentikan oleh kesalahan sementara yang sangat jarang, yang dapat membatalkan kueri yang berjalan lama dan mengembalikan transaksi. Salah satu penyebab kesalahan sementara adalah ketika sistem dengan cepat menggeser database ke node komputasi yang berbeda untuk memastikan ketersediaan sumber daya komputasi dan penyimpanan yang berkelanjutan, atau untuk melakukan pemeliharaan terencana. Sebagian besar peristiwa konfigurasi ulang selesai dalam waktu kurang dari 10 detik. Aplikasi yang terhubung ke database Anda harus dibangun untuk mengantisipasi dan mentolerir kesalahan sementara yang jarang terjadi ini dengan menerapkan logika coba lagi. Selain itu, pertimbangkan untuk mengonfigurasi jendela pemeliharaan yang sesuai dengan jadwal beban kerja Anda untuk menghindari kesalahan sementara karena pemeliharaan terencana.

Bagaimana cara mendiagnosis dan memecahkan masalah kinerja dalam database Hyperscale?

Untuk sebagian besar masalah performa, terutama yang tidak berakar pada performa penyimpanan, langkah-langkah diagnostik dan pemecahan masalah MSSQL umum berlaku. Untuk diagnostik penyimpanan khusus Hyperscale, lihat diagnostik pemecahan masalah performa SQL Hyperscale.

Bagaimana batas memori maksimum dalam tanpa server dibandingkan dengan komputasi yang disediakan?

Jumlah maksimum memori yang dapat ditingkatkan oleh database tanpa server adalah 3 GB/vCore kali jumlah maksimum vCore yang dikonfigurasi dibandingkan dengan lebih dari 5 GB/vCore kali jumlah vCore yang sama dalam komputasi yang disediakan. Tinjau batas sumber daya Hyperscale tanpa server untuk detailnya.

Bagaimana priming berkelanjutan menguntungkan pelanggan?

Priming berkelanjutan membantu mempertahankan pemanfaatan RBPEX (Ekstensi Kumpulan Buffer Tangguh) yang lebih tinggi, yang mengarah ke performa yang lebih baik. Ini memastikan database sekunder selalu siap untuk mengambil alih tanpa penundaan, meningkatkan waktu failover dan keandalan sistem secara keseluruhan.

Tingkat komputasi apa yang mendukung priming berkelanjutan?

Priming berkelanjutan tersedia pada perangkat keras seri premium tingkat komputasi Hyperscale yang disediakan dan perangkat keras seri premium yang dioptimalkan memori. Priming berkelanjutan saat ini tidak tersedia untuk tingkat komputasi tanpa server Hyperscale.

Apakah priming berkelanjutan mendapat manfaat replika bernama?

Replika bernama tidak mendapat manfaat dari priming berkelanjutan.

Pertanyaan skalabilitas

Berapa lama waktu yang dibutuhkan untuk meningkatkan atau menurunkan skala replika komputasi?

Meningkatkan atau menurunkan skala di tingkat komputasi yang disediakan biasanya memakan waktu hingga 2 menit, terlepas dari ukuran data. Di tingkat komputasi tanpa server, di mana komputasi secara otomatis diskalakan berdasarkan permintaan beban kerja, waktu penskalaan biasanya subdetik, tetapi kadang-kadang dapat memakan waktu selama saat menskalakan komputasi yang disediakan.

Apakah database saya offline saat operasi penskalaan atas/bawah sedang berlangsung?

Tidak. Database tetap online selama operasi peningkatan atau penurunan skala.

Haruskah saya mengharapkan koneksi terputus saat operasi penskalakan sedang berlangsung?

Penskalaan komputasi yang disediakan ke atas atau ke bawah menghasilkan koneksi yang dihilangkan saat failover terjadi di akhir operasi penskalaan. Dalam komputasi tanpa server, penskalaan otomatis biasanya tidak mengakibatkan koneksi terputus, tetapi dapat terjadi sesekali. Menambahkan atau menghapus replika sekunder tidak mengakibatkan penurunan koneksi pada replika primer.

Apakah penskalaan naik dan turun dari replika komputasi otomatis atau operasi yang dipicu pengguna akhir?

Penskalaan dalam komputasi yang disediakan dilakukan oleh pengguna akhir. Penskalaan otomatis dalam komputasi tanpa server dilakukan oleh layanan.

Apakah ukuran database tempdb dan cache SSD komputasi saya juga bertambah saat komputasi ditingkatkan?

Ya. Database tempdb dan ukuran cache SSD komputasi pada simpul komputasi ditingkatkan secara otomatis saat jumlah inti ditingkatkan. Untuk detailnya, lihat Penyimpanan dan ukuran komputasi Hyperscale.

Dapatkah saya menyediakan beberapa replika komputasi utama, seperti sistem multi-master, di mana beberapa kepala komputasi utama dapat mendorong tingkat konkurensi yang lebih tinggi?

Tidak. Hanya replika komputasi utama yang menerima permintaan baca/tulis. Replika komputasi sekunder hanya menerima permintaan baca-saja.

Pertanyaan Peluasan Skala Baca

Apa jenis replika sekunder (peluasan skala baca) yang tersedia di Hyperscale?

Hyperscale mendukung replika Ketersediaan Tinggi (HA), replika bernama, dan geo-replika. Lihat replika sekunder Hyperscale untuk detailnya.

Berapa banyak replika sekunder high availability yang dapat saya provisikan?

Antara 0 hingga 4. Jika Anda ingin menyesuaikan jumlah replika, Anda dapat melakukannya menggunakan portal Microsoft Azure atau REST API.

Bagaimana cara menghubungkan ke replika sekunder high availability?

Anda dapat terhubung ke replika komputasi baca-saja tambahan ini dengan mengatur properti ApplicationIntent di string koneksi Anda ke ReadOnly. Setiap koneksi yang ditandai dengan ReadOnly secara otomatis dirutekan ke salah satu replika sekunder HA, jika ada. Untuk detailnya, lihat Menggunakan replika baca-saja untuk memindahkan beban kerja kueri baca-saja.

Bagaimana cara memvalidasi apakah saya berhasil tersambung ke replika komputasi sekunder menggunakan SQL Server Management Studio (SSMS) atau alat klien lainnya?

Anda dapat menjalankan kueri T-SQL berikut: SELECT DATABASEPROPERTYEX ('<database_name>', 'Updateability'). Hasilnya adalah READ_ONLY jika Anda terhubung ke replika sekunder baca-saja, dan READ_WRITE jika Anda terhubung ke replika utama. Konteks database harus diatur ke nama database Anda, bukan ke master database.

Apakah saya dapat membuat titik akhir khusus untuk replika sekunder high availability?

Tidak. Anda hanya dapat terhubung ke replika sekunder high availability dengan menentukan ApplicationIntent=ReadOnly. Namun, Anda dapat menggunakan titik akhir khusus untuk replika bernama.

Apakah sistem melakukan penyeimbangan beban cerdas dari beban kerja baca-saja pada replika sekunder HA?

Tidak. Koneksi baru dengan niat baca-saja dialihkan ke replika sekunder high availability arbitrer.

Apakah saya dapat menaikkan/menurunkan skala replika sekunder high availability secara terpisah dari replika utama?

Tidak dalam tingkat komputasi yang disediakan. Replika sekunder high availability digunakan sebagai target failover high availability, sehingga replika sekunder high availability harus memiliki konfigurasi yang sama seperti yang replika utama agar memberikan performa yang diharapkan setelah failover. Dalam tanpa server, komputasi diskalakan secara otomatis untuk setiap replika KETERSEDIAAN TINGGI berdasarkan permintaan beban kerja individualnya. Setiap sekunder HA masih dapat menskalakan otomatis ke inti maks yang dikonfigurasi untuk mengakomodasi peran pasca-failover-nya. Replika bernama memberikan kemampuan untuk menskalakan setiap replika bernama secara independen.

Apakah saya mendapatkan ukuran tempdb yang berbeda untuk komputasi utama dan replika sekunder HA saya?

Tidak. Database Anda tempdb dikonfigurasi berdasarkan ukuran komputasi yang disediakan; replika sekunder HA Anda berukuran sama, termasuk tempdb, sebagai komputasi utama. Pada replika bernama, tempdb diukur sesuai dengan ukuran komputasi replika, sehingga bisa lebih kecil atau lebih besar dari tempdb pada replika utama.

Bisakah saya menambahkan indeks dan tampilan pada replika komputasi sekunder saya?

Tidak. Replika komputasi database Hyperscale berbagi penyimpanan, yang berarti bahwa semua replika komputasi melihat tabel, indeks, dan objek database lainnya yang sama. Jika Anda menginginkan indeks tambahan yang dioptimalkan untuk dibaca di sekunder, Anda harus menambahkannya di primer. Anda masih dapat membuat tabel sementara (nama tabel diawali dengan # atau ##) pada setiap replika sekunder untuk menyimpan data sementara di database tempdb. Tabel sementara bersifat baca-tulis.

Berapa banyak penundaan yang akan terjadi antara replika komputasi primer dan sekunder?

Latensi data sejak transaksi dilakukan pada primer hingga waktu yang dapat dibaca pada sekunder tergantung pada tingkat pembuatan log saat ini, ukuran transaksi, beban pada replika, dan faktor lainnya. Latensi data umum untuk transaksi kecil berada dalam puluhan milidetik, namun tidak ada batas atas pada latensi data. Data pada replika sekunder tertentu selalu konsisten secara transaksi, sehingga transaksi yang lebih besar membutuhkan waktu lebih lama untuk disebarkan. Pada titik waktu tertentu latensi data dan status database mungkin berbeda untuk replika sekunder yang berbeda. Beban kerja yang perlu segera membaca data tersebut harus berjalan pada replika utama.

Dapatkah replika bernama digunakan sebagai target failover?

Tidak, replika bernama tidak bisa digunakan sebagai target failover untuk replika utama. Tambahkan replika HA untuk replika utama untuk tujuan tersebut.

Bagaimana cara mendistribusikan beban kerja baca-saja di seluruh replika bernama milik saya?

Karena setiap replika bernama dapat memiliki tujuan tingkat layanan yang berbeda dan dengan demikian digunakan untuk kasus penggunaan yang berbeda, tidak ada cara bawaan untuk mengarahkan lalu lintas baca-saja yang dikirim ke primer ke sekumpulan replika bernama. Misalnya, Anda dapat memiliki delapan replika bernama, dan Anda mungkin ingin mengarahkan beban kerja OLTP hanya ke replika bernama 1 hingga 4, sementara beban kerja analitik Power BI menggunakan replika bernama 5 dan 6, dan beban kerja ilmu data menggunakan replika 7 dan 8. Bergantung pada alat atau bahasa pemrograman mana yang Anda gunakan, strategi untuk mendistribusikan beban kerja tersebut dapat bervariasi. Untuk contoh pembuatan solusi perutean beban kerja agar backend REST dapat diskalakan, tinjau sampel peluasan skala OLTP.

Dapatkah replika bernama berada di wilayah yang berbeda dari wilayah replika utama?

Tidak, karena replika bernama menggunakan server halaman yang sama dari replika utama, mereka harus berada di wilayah yang sama. Namun, jika Anda membuat replika geografis untuk replika utama di wilayah yang berbeda, Anda dapat membuat replika bernama untuk geo-replika.

Dapatkah replika bernama memengaruhi ketersediaan atau kinerja replika utama?

Replika bernama tidak dapat memengaruhi ketersediaan replika utama. Replika bernama dalam keadaan normal tidak mungkin memengaruhi performa replika utama, tetapi dapat terjadi jika ada beban kerja intensif yang berjalan. Sama seperti replika HA, replika bernama tetap sinkron dengan replika utama melalui layanan log transaksi. Jika replika bernama, karena alasan apa pun, tidak dapat mengonsumsi log transaksi dengan cukup cepat, ia mulai meminta replika utama untuk mengurangi tingkat pembuatan lognya, sehingga dapat mengejar ketinggalan. Meskipun perilaku ini tidak berdampak pada ketersediaan utama, perilaku ini dapat memengaruhi performa beban kerja tulis pada primer. Untuk menghindari situasi ini, pastikan replika bernama Anda memiliki headroom sumber daya yang cukup - terutama CPU - untuk memproses log transaksi tanpa penundaan. Misalnya, jika primer memproses banyak perubahan data, disarankan untuk memiliki replika bernama dengan setidaknya ukuran komputasi yang sama dengan yang utama untuk menghindari menjenuhkan CPU pada replika dan memaksa primer untuk melambat.

Apa yang terjadi pada replika bernama jika replika utama tidak tersedia, misalnya, karena pemeliharaan terencana?

Replika bernama masih tersedia untuk akses baca-saja, seperti biasa.

Bagaimana cara meningkatkan ketersediaan replika bernama?

Secara default, replika bernama tidak memiliki replika KETERSEDIAAN TINGGI sendiri. Replika bernama failover memerlukan pembuatan replika baru terlebih dahulu, biasanya membutuhkan waktu sekitar 1-2 menit. Namun, replika bernama juga bisa memanfaatkan ketersediaan yang lebih tinggi dan failover yang lebih singkat disediakan oleh replika HA. Anda dapat menambahkan replika HA untuk replika bernama di portal Microsoft Azure, atau menggunakan parameter ha-replicas dengan AZ CLI, atau parameter HighAvailabilityReplicaCount dengan PowerShell, atau properti highAvailabilityReplicaCount dengan REST API. Jumlah replika HA dapat diatur selama pembuatan replika bernama dan dapat diubah kapan saja setelah replika bernama dibuat. Harga replika HA untuk replika bernama sama dengan replika HA untuk replika utama.

Jika Always Encrypted diaktifkan pada database Hyperscale, akan memutar Kunci Master Kolom (CMK) pada database utama juga memperbarui kunci pada replika sekunder?

Ya. Kunci Master Kolom disimpan dalam database pengguna dan dapat divalidasi dengan menjalankan kueri SELECT * FROM sys.column_master_keys. Replika bernama dan replika sekunder ketersediaan tinggi membaca data dari server halaman/lapisan penyimpanan yang sama dengan database Hyperscale utama. Kedua jenis replika disinkronkan dengan database Hyperscale utama melalui layanan log. Perubahan kunci dianggap sebagai transaksi dan secara otomatis direplikasi ke semua replika sekunder.

Bisakah saya menentukan nama replika bernama yang terkait dengan nilai di kolom replica_id di sys.dm_database_replica_states?

Tidak saat Anda mengkueri sys.dm_database_replica_states pada replika utama. Namun, Anda dapat menyambungkan ke replika bernama untuk menentukan ID replikanya dan detail lainnya menggunakan kueri sampel berikut:

  SELECT replica_id,
         DB_NAME() AS named_replica_database_name,
         synchronization_state_desc,
         log_send_queue_size / 1024.0 / 1024.0 AS log_send_queue_size_gb,
         last_sent_time,
         last_received_time,
         last_commit_time,
         redo_queue_size / 1024.0 / 1024.0 AS redo_queue_size_gb,
         redo_rate,
         secondary_lag_seconds
  FROM sys.dm_database_replica_states
  WHERE is_local = 1
        AND
        replica_id = DATABASEPROPERTYEX(DB_NAME(), 'ReplicaID');

Konten terkait

Untuk informasi selengkapnya tentang tingkat layanan Hyperscale, lihat Tingkat layanan Hyperscale.