DBA baru di cloud - Mengelola Azure SQL Database setelah migrasi

Berlaku untuk:Azure SQL Database

Migrasi dari lingkungan yang dikelola sendiri ke PaaS seperti Azure SQL Database bisa menjadi kompleks. Artikel ini menyoroti kemampuan utama Azure SQL Database untuk database tunggal dan terkumpul, membantu Anda menjaga aplikasi tetap tersedia, berkinerja, aman, dan tangguh.

Karakteristik inti Azure SQL Database meliputi:

• Pemantauan database dengan portal Microsoft Azure
• Kelangsungan bisnis dan pemulihan bencana (BCDR)
• Keamanan dan kepatuhan
• Pemantauan dan pemeliharaan database cerdas
• Pergerakan data

Catatan

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

Memantau database menggunakan portal Microsoft Azure

Untuk metrik dan pemberitahuan Azure Monitor, termasuk aturan pemberitahuan yang direkomendasikan, lihat Memantau Azure SQL Database dengan metrik dan pemberitahuan. Untuk informasi selengkapnya tentang tingkat layanan, lihat Gambaran umum model pembelian berbasis DTU dan model pembelian berbasis vCore.

Anda dapat mengonfigurasi pemberitahuan pada metrik performa. Pilih tombol Tambahkan pemberitahuan di jendela Metrik . Ikuti panduan untuk mengonfigurasi pemberitahuan Anda. Anda dapat memperingatkan apakah metrik melebihi ambang batas tertentu atau jika metrik berada di bawah ambang batas tertentu.

Misalnya, jika Anda mengharapkan beban kerja di database Anda bertambah, Anda dapat memilih untuk mengonfigurasi pemberitahuan email setiap kali database Anda mencapai 80% pada salah satu metrik performa. Anda dapat menggunakan ini sebagai peringatan dini untuk mencari tahu kapan Anda mungkin harus beralih ke ukuran komputasi tertinggi berikutnya.

Metrik performa juga dapat membantu Anda menentukan apakah Anda dapat menurunkan ke ukuran komputasi yang lebih rendah. Namun, waspadai beban kerja yang melonjak atau berfluktuasi sebelum membuat keputusan untuk pindah ke ukuran komputasi yang lebih rendah.

Kelangsungan bisnis dan pemulihan bencana (BCDR)

Kelangsungan bisnis dan kemampuan pemulihan bencana memungkinkan Anda untuk melanjutkan bisnis Anda jika bencana terjadi. Bencana itu bisa menjadi peristiwa tingkat database (misalnya, seseorang keliru menghilangkan tabel penting) atau peristiwa tingkat pusat data (bencana regional, misalnya tsunami).

Bagaimana cara membuat dan mengelola cadangan di SQL Database?

Azure SQL Database secara otomatis mencadangkan database untuk Anda. Platform ini mengambil pencadangan penuh setiap minggu, pencadangan diferensial setiap beberapa jam dan cadangan log setiap 5 menit untuk memastikan pemulihan bencana efisien, dan kehilangan data minimal. Pencadangan penuh pertama dilakukan segera setelah Anda membuat database. Cadangan ini tersedia untuk Anda untuk periode tertentu yang disebut periode retensi, yang bervariasi sesuai dengan tingkat layanan yang Anda pilih. Anda dapat memulihkan ke titik waktu mana pun dalam periode retensi ini menggunakan Point in Time Recovery (PITR).

Selain itu, fitur Pencadangan retensi jangka panjang memungkinkan Anda menyimpan file cadangan hingga 10 tahun, dan memulihkan data dari cadangan ini kapan saja dalam periode tersebut. Cadangan database disimpan dalam penyimpanan yang direplikasi secara geografis untuk memberikan ketahanan dari bencana regional. Anda juga dapat memulihkan cadangan ini di wilayah Azure mana pun kapan saja dalam periode retensi. Untuk informasi selengkapnya, lihat Kelangsungan bisnis di Azure SQL Database.

Bagaimana cara memastikan kelangsungan bisnis jika terjadi bencana tingkat pusat data atau bencana regional?

Cadangan database Anda disimpan dalam penyimpanan yang direplikasi secara geografis untuk memastikan bahwa, selama bencana regional, Anda dapat memulihkan cadangan ke wilayah Azure lain. Ini disebut pemulihan geografis. Untuk informasi selengkapnya dan waktu pemulihan geografis, lihat Pemulihan geografis untuk Azure SQL Database.

Untuk database misi penting, Azure SQL Database menawarkan replikasi geografis aktif, yang membuat salinan sekunder yang direplikasi secara geografis dari database asli Anda di wilayah lain. Misalnya, jika database Anda awalnya dihosting di wilayah Azure US Barat dan Anda menginginkan ketahanan bencana regional, buat replika geo aktif database di AS Barat ke AS Timur. Ketika bencana melanda US Barat, Anda dapat melakukan failover ke wilayah US Timur.

Selain replikasi geografis aktif, grup failover membantu Anda mengelola replikasi dan failover sekelompok database. Anda dapat membuat grup failover yang berisi beberapa database di wilayah yang sama atau berbeda. Anda kemudian dapat memulai failover semua database di grup failover ke wilayah sekunder. Untuk informasi selengkapnya, lihat Gambaran umum grup failover & praktik terbaik (Azure SQL Database).

Untuk mencapai ketahanan terhadap kegagalan pusat data atau zona ketersediaan, pastikan redundansi zona diaktifkan untuk database atau kumpulan elastis.

Pantau aplikasi Anda secara aktif untuk bencana dan mulai failover ke sekunder. Anda dapat membuat hingga empat replika geografis aktif tersebut di wilayah Azure yang berbeda. Ini akan lebih baik. Anda juga dapat mengakses replika geo aktif sekunder ini untuk akses baca-saja. Ini membantu mengurangi latensi untuk skenario aplikasi yang didistribusikan secara geografis.

Seperti apa pemulihan bencana dengan SQL Database?

Konfigurasi dan manajemen pemulihan bencana dapat dilakukan hanya dengan beberapa langkah di Azure SQL Database saat Anda menggunakan grup replikasi geografis atau failover aktif. Anda masih harus memantau aplikasi dan databasenya untuk bencana regional apa pun dan melakukan failover ke wilayah sekunder untuk memulihkan kelangsungan bisnis.

Untuk informasi selengkapnya, lihat Pemulihan Bencana Azure SQL Database 101.

Keamanan dan kepatuhan

Keamanan dalam SQL Database tersedia di tingkat database dan di tingkat platform. Anda dapat mengontrol dan memberikan keamanan optimal untuk aplikasi Anda sebagai berikut:

• Identitas & autentikasi (autentikasi SQL dan autentikasi dengan ID Microsoft Entra).
• Pemantauan aktivitas (Audit dan deteksi ancaman).
• Melindungi data aktual (Enkripsi data transparan [TDE] dan Always Encrypted).
• Mengontrol Akses ke data sensitif dan istimewa (Keamanan tingkat baris dan Masking data dinamis).

Pertahanan Microsoft untuk Cloud menawarkan pengelolaan keamanan terpusat di seluruh beban kerja yang berjalan di Azure, lokal, dan di cloud lainnya. Anda dapat melihat apakah perlindungan SQL Database penting seperti Audit dan Enkripsi data transparan [TDE] dikonfigurasi pada semua sumber daya, dan membuat kebijakan berdasarkan kebutuhan Anda sendiri.

Metode autentikasi pengguna apa yang ditawarkan di SQL Database?

Ada dua metode autentikasi yang ditawarkan dalam SQL Database:

• Autentikasi Microsoft Entra
• Autentikasi SQL

Autentikasi Windows tidak didukung. ID Microsoft Entra adalah layanan manajemen identitas dan akses terpusat. Microsoft Entra ID menyediakan akses single sign-on (SSO) kepada personel di organisasi Anda. Artinya, kredensial dibagikan di seluruh layanan Azure untuk autentikasi yang lebih mudah.

MICROSOFT Entra ID mendukung autentikasi multifaktor, dan dapat dengan mudah diintegrasikan dengan Windows Server Active Directory. Ini juga memungkinkan SQL Database dan Azure Synapse Analytics untuk menawarkan autentikasi multifaktor dan akun pengguna tamu dalam domain Microsoft Entra. Jika Anda sudah menggunakan Active Directory lokal, Anda dapat menggabungkannya dengan ID Microsoft Entra untuk memperluas direktori Anda ke Azure.

Autentikasi SQL hanya mendukung nama pengguna dan kata sandi untuk mengautentikasi pengguna ke database apa pun di server tertentu.

Jika Anda ...	SQL Database / Azure Synapse Analytics
Menggunakan AD di SQL Server lokal	Federasi AD dengan ID Microsoft Entra, dan gunakan autentikasi Microsoft Entra. Federasi memungkinkan Anda menggunakan akses menyeluruh.
Perlu memberlakukan autentikasi multifaktor	Memerlukan autentikasi multifaktor sebagai kebijakan melalui akses Bersyarat, dan menggunakan autentikasi multifaktor Microsoft Entra.
Masuk ke Windows menggunakan kredensial Microsoft Entra Anda dari domain federasi	Gunakan autentikasi Microsoft Entra.
Masuk ke Windows menggunakan kredensial dari domain yang tidak terfederasi dengan Azure	Gunakan autentikasi terintegrasi Microsoft Entra.
Memiliki layanan tingkat menengah yang perlu tersambung ke SQL Database atau Azure Synapse Analytics	Gunakan autentikasi terintegrasi Microsoft Entra.
Memiliki persyaratan teknis untuk menggunakan autentikasi SQL	Gunakan Autentikasi SQL

Bagaimana cara membatasi atau mengontrol akses konektivitas ke database saya?

Ada beberapa teknik yang dapat Anda gunakan untuk mencapai pengelolaan konektivitas yang optimal untuk aplikasi Anda.

• Aturan Firewall
• Titik akhir layanan jaringan virtual
• IP yang Dicadangkan

Firewall

Secara default, semua koneksi ke database di dalam server tidak diizinkan, kecuali (opsional) koneksi yang masuk dari Layanan Azure lainnya. Dengan aturan firewall, Anda dapat membuka akses ke server Anda hanya ke entitas (misalnya, komputer pengembang) yang Anda setujui, dengan mengizinkan alamat IP komputer tersebut melalui firewall. Ini juga memungkinkan Anda untuk menentukan rentang IP yang akan anda berikan izin akses ke server. Misalnya, alamat IP komputer pengembang di organisasi Anda dapat ditambahkan sekaligus dengan menentukan rentang di halaman Pengaturan firewall.

Anda dapat mengonfigurasi aturan firewall di tingkat server atau di tingkat database. Aturan firewall IP tingkat server dapat dibuat menggunakan portal Microsoft Azure atau dengan SQL Server Management Studio. Untuk informasi selengkapnya tentang cara mengatur aturan firewall tingkat server dan tingkat database, lihat Membuat aturan firewall IP di SQL Database.

Titik akhir layanan

Secara default, database Anda dikonfigurasi ke Izinkan layanan dan sumber daya Azure untuk mengakses server ini, yang berarti komputer virtual apa pun di Azure mungkin mencoba menyambungkan ke database Anda. Upaya ini masih harus diautentikasi. Jika Anda tidak ingin database Anda dapat diakses oleh IP Azure apa pun, Anda dapat menonaktifkan Izinkan layanan dan sumber daya Azure mengakses server ini. Selain itu, Anda dapat mengonfigurasi titik akhir layanan jaringan virtual.

Titik akhir layanan memungkinkan Anda mengekspos sumber daya Azure penting hanya ke jaringan virtual privat Anda sendiri di Azure. Opsi ini menghilangkan akses publik ke sumber daya Anda. Lalu lintas antara jaringan virtual Anda ke Azure tetap berada di jaringan inti Azure. Tanpa titik akhir layanan, Anda mengalami perutean paket dengan penerowongan paksa. Jaringan virtual Anda memaksa lalu lintas internet ke organisasi Anda dan lalu lintas Layanan Azure untuk melewati rute yang sama. Dengan titik akhir layanan, Anda dapat mengoptimalkan ini karena paket mengalir langsung dari jaringan virtual Anda ke layanan di jaringan backbone Azure.

IP yang Dicadangkan

Opsi lain adalah menyediakan IP yang dicadangkan untuk komputer virtual Anda, dan menambahkan alamat IP komputer virtual tertentu di pengaturan firewall server. Dengan menetapkan IP yang dicadangkan, Anda terhindar dari masalah karena harus memperbarui aturan firewall dengan mengubah alamat IP.

Port apa yang saya sambungkan ke SQL Database?

SQL Database berkomunikasi melalui port 1433. Untuk tersambung dari dalam jaringan perusahaan, Anda harus menambahkan aturan keluar di pengaturan firewall organisasi Anda. Sebagai pedoman, hindari untuk mengekspos port 1433 di luar batas Azure.

Bagaimana cara memantau dan mengatur aktivitas di server dan database saya di SQL Database?

Pengauditan SQL Database

Audit Azure SQL Database merekam peristiwa database dan menulisnya ke dalam file log audit di Akun Azure Storage Anda. Audit sangat berguna jika Anda berniat untuk mendapatkan wawasan tentang potensi pelanggaran keamanan dan kebijakan, menjaga kepatuhan terhadap peraturan, dll. Ini memungkinkan Anda untuk menentukan dan mengonfigurasi kategori peristiwa tertentu yang menurut Anda perlu diaudit dan berdasarkan itu Anda bisa mendapatkan laporan yang telah dikonfigurasi sebelumnya dan dasbor untuk mendapatkan gambaran umum peristiwa yang terjadi pada database Anda.

Anda dapat menerapkan kebijakan audit ini baik di tingkat database atau di tingkat server. Untuk informasi selengkapnya, Aktifkan Audit Database SQL.

Deteksi ancaman

Dengan deteksi ancaman, Anda mendapatkan kemampuan untuk bertindak berdasarkan pelanggaran keamanan atau kebijakan yang ditemukan dengan mengaudit. Anda tidak perlu menjadi pakar keamanan untuk mengatasi potensi ancaman atau pelanggaran dalam sistem Anda. Deteksi ancaman juga memiliki beberapa kemampuan bawaan seperti deteksi injeksi SQL, yang merupakan cara yang cukup umum untuk menyerang aplikasi database. Deteksi ancaman menjalankan beberapa set algoritma yang mendeteksi potensi kerentanan dan serangan injeksi SQL, dan pola akses database anomali (seperti akses dari lokasi yang tidak biasa atau oleh prinsipal yang tidak dikenal).

Petugas keamanan atau administrator lain yang ditunjuk akan menerima pemberitahuan email jika ancaman terdeteksi di database. Setiap pemberitahuan memberikan detail aktivitas mencurigakan dan rekomendasi cara menyelidiki dan mengurangi ancaman lebih lanjut. Untuk mempelajari cara mengaktifkan Deteksi ancaman, lihat Mengaktifkan deteksi ancaman.

Bagaimana cara melindungi data saya secara umum di SQL Database?

Enkripsi menyediakan mekanisme yang kuat untuk melindungi dan mengamankan data sensitif Anda dari penyusup. Data terenkripsi Anda tidak berguna bagi penyusup tanpa kunci dekripsi. Dengan demikian, ia menambahkan lapisan perlindungan ekstra di atas lapisan keamanan yang telah ada di SQL Database. Ada dua aspek untuk melindungi data Anda di SQL Database:

• Data Anda yang tersimpan dalam file data dan log
• Data Anda dalam penerbangan

Di SQL Database, secara default, data Anda dalam keadaan diam di data dan file log pada subsistem penyimpanan sepenuhnya dan selalu dienkripsi melalui Enkripsi data transparan [TDE]. Cadangan Anda juga dienkripsi. Dengan TDE, tidak ada perubahan yang diperlukan di sisi aplikasi Anda yang mengakses data ini. Enkripsi dan dekripsi terjadi secara transparan; seperti namanya.

Untuk melindungi data sensitif Anda dalam penerbangan dan saat tidak aktif, SQL Database menyediakan fitur yang disebut Always Encrypted. Always Encrypted adalah bentuk enkripsi sisi klien yang mengenkripsi kolom sensitif dalam database Anda (sehingga berada dalam ciphertext ke administrator database dan pengguna yang tidak sah). Server menerima data terenkripsi sejak awal.

Kunci untuk Always Encrypted juga disimpan di sisi klien, sehingga hanya klien yang berwenang yang dapat mendekripsikan kolom sensitif. Server dan administrator data tidak dapat melihat data sensitif karena kunci enkripsi disimpan di klien. Always Encrypted mengenkripsi kolom sensitif dalam tabel secara menyeluruh, dari klien yang tidak sah ke disk fisik.

Always Encrypted mendukung perbandingan kesetaraan, sehingga DBA dapat terus mengkueri kolom terenkripsi sebagai bagian dari perintah SQL mereka. Always Encrypted dapat digunakan dengan berbagai opsi penyimpanan kunci, seperti Azure Key Vault, penyimpanan sertifikat Windows, dan modul keamanan perangkat keras lokal.

Karakteristik	Selalu Terenkripsi	Enkripsi data transparan
Jangkauan enkripsi	Ujung-ke-ujung	Data diam
Server dapat mengakses data sensitif	No	Ya, karena enkripsi adalah untuk data tidak aktif
Operasi T-SQL yang dizinkan	Perbandingan kesamaan	Semua area permukaan T-SQL tersedia
Perubahan aplikasi diperlukan untuk menggunakan fitur	Minimal	Minimal
Granularitas enkripsi	Tingkat kolom	Tingkat database

Bagaimana cara membatasi akses ke data sensitif di database saya?

Setiap aplikasi memiliki data sensitif dalam database yang perlu dilindungi agar tidak terlihat oleh semua orang. Personel tertentu dalam organisasi perlu melihat data ini, namun orang lain seharusnya tidak dapat melihat data ini. Dalam kasus seperti itu, data sensitif Anda perlu ditutupi, atau tidak diekspos sama sekali. SQL Database menawarkan dua pendekatan tersebut untuk mencegah pengguna yang tidak sah dapat melihat data sensitif:

• Masking data dinamis adalah fitur masking data yang memungkinkan Anda membatasi paparan data sensitif dengan menutupinya ke pengguna yang tidak memiliki hak istimewa pada lapisan aplikasi. Anda menentukan aturan masking yang dapat membuat pola masking (misalnya, untuk hanya menampilkan empat digit terakhir SSN ID nasional: XXX-XX-0000 dan menutupi sebagian besar dengan X karakter) dan mengidentifikasi pengguna mana yang akan dikecualikan dari aturan masking. Masking terjadi secara cepat dan ada berbagai fungsi masking yang tersedia untuk berbagai kategori data. Masking data dinamis memungkinkan Anda untuk secara otomatis mendeteksi data sensitif dalam database Anda dan menerapkan masking ke dalamnya.

• Keamanan tingkat baris memungkinkan Anda mengontrol akses di tingkat baris. Artinya, baris tertentu dalam tabel database berdasarkan pengguna yang mengeksekusi kueri (keanggotaan grup atau konteks eksekusi) akan disembunyikan. Pembatasan akses dilakukan pada tingkat database alih-alih di tingkat aplikasi, untuk menyederhanakan logika aplikasi Anda. Anda mulai dengan membuat predikat filter, memfilter baris yang tidak diekspos dan kebijakan keamanan berikutnya menentukan siapa yang memiliki akses ke baris ini. Terakhir, pengguna akhir menjalankan kueri mereka dan, tergantung pada hak istimewa pengguna, mereka melihat baris terbatas tersebut atau tidak dapat melihatnya sama sekali.

Bagaimana cara mengelola kunci enkripsi di cloud?

Ada opsi manajemen kunci untuk Always Encrypted (enkripsi sisi klien) dan Enkripsi data transparan (enkripsi saat tidak aktif). Disarankan agar Anda memutar kunci enkripsi secara teratur. Frekuensi rotasi harus sesuai dengan peraturan organisasi internal dan persyaratan kepatuhan Anda.

Transparent Data Encryption (TDE)

Ada hierarki dua kunci di TDE - data di setiap database pengguna dienkripsi oleh kunci enkripsi database unik database (DEK) AES-256 simetris, yang pada gilirannya dienkripsi oleh kunci master RSA 2048 asimetris unik server. Kunci master dapat dikelola:

• Secara otomatis oleh Azure SQL Database
• Atau dengan Menggunakan Azure Key Vault sebagai penyimpanan kunci

Secara default, kunci master untuk TDE dikelola oleh Azure SQL Database. Jika organisasi Anda ingin mengontrol kunci master, Anda dapat menggunakan Azure Key Vault sebagai penyimpanan kunci. Dengan menggunakan Azure Key Vault, organisasi Anda memegang kontrol atas penyediaan kunci, rotasi, dan kontrol izin. Rotasi atau penggantian tipe kunci master TDE terjadi secara cepat, karena hanya mengenkripsi ulang DEK. Untuk organisasi dengan pemisahan peran antara keamanan dan manajemen data, admin keamanan dapat menyediakan materi kunci untuk kunci utama TDE di Azure Key Vault dan memberikan pengidentifikasi kunci Azure Key Vault kepada administrator database untuk digunakan mengenkripsi saat diam di server. Key Vault dirancang sed sehingga Microsoft tidak melihat atau mengekstrak kunci enkripsi apa pun. Anda juga mendapatkan manajemen kunci terpusat untuk organisasi Anda.

Selalu Terenkripsi

Ada juga hierarki dua kunci di Always Encrypted - kolom data sensitif dienkripsi oleh kunci enkripsi kolom (CEK) AES 256, yang pada gilirannya dienkripsi oleh kunci master kolom (CMK). Driver klien yang disediakan untuk Always Encrypted tidak memiliki batasan pada panjangnya CMK. Nilai terenkripsi CEK disimpan di database, dan CMK disimpan di penyimpanan kunci terpercaya, seperti Penyimpanan Sertifikat Windows, Azure Key Vault, atau modul keamanan perangkat keras.

• CEK dan CMK dapat diputar.

• Rotasi CEK adalah operasi ukuran data dan dapat memakan waktu tergantung pada ukuran tabel yang berisi kolom terenkripsi. Oleh karena itu, sangat bijaksana untuk merencanakan rotasi CEK yang sesuai.

• Rotasi CMK, bagaimanapun, tidak mengganggu performa database, dan dapat dilakukan dengan peran yang dipisahkan.

Diagram berikut menunjukkan opsi penyimpanan kunci untuk kunci master kolom di Always Encrypted:

Bagaimana cara mengoptimalkan dan mengamankan lalu lintas antara organisasi saya dan SQL Database?

Lalu lintas jaringan antara organisasi Anda dan SQL Database umumnya dirutekan melalui jaringan publik. Namun, Anda dapat mengoptimalkan jalur ini dan membuatnya lebih aman dengan Azure ExpressRoute. ExpressRoute memperluas jaringan perusahaan Anda ke platform Azure melalui koneksi privat. Dengan demikian, Anda tidak melalui Internet publik. Anda juga mendapatkan pengoptimalan keamanan, keandalan, dan perutean yang lebih tinggi yang diterjemahkan ke latensi jaringan yang lebih rendah dan kecepatan yang lebih cepat daripada yang biasanya Anda alami melalui internet publik. Jika Anda berencana mentransfer potongan data yang signifikan antara organisasi Anda dan Azure, menggunakan ExpressRoute dapat menghasilkan manfaat biaya. Anda dapat memilih dari tiga model konektivitas berbeda untuk koneksi dari organisasi Anda ke Azure:

• Kolokasi Pertukaran Cloud
• Semua-ke-semua
• Poin-ke-poin

ExpressRoute juga memungkinkan Anda untuk meningkatkan bandwidth Anda secara sementara hingga dua kali lipat dari batas yang Anda beli tanpa biaya tambahan. Dimungkinkan juga untuk mengonfigurasi konektivitas lintas wilayah menggunakan ExpressRoute. Untuk daftar penyedia konektivitas ExpressRoute, lihat Mitra ExpressRoute dan Lokasi Peering. Artikel berikut ini menjelaskan ExpressRoute secara lebih rinci:

• Pengantar tentang ExpressRoute
• Prasyarat
• Alur kerja

Apakah SQL Database mematuhi persyaratan peraturan apa pun, dan bagaimana hal itu membantu kepatuhan organisasi saya sendiri?

SQL Database mematuhi berbagai kepatuhan peraturan. Untuk melihat kumpulan komppliansi terbaru yang telah dipenuhi oleh SQL Database, kunjungi Pusat Kepercayaan Microsoft dan tinjau komprotasi yang penting bagi organisasi Anda untuk melihat apakah SQL Database disertakan di bawah layanan Azure yang sesuai. Meskipun SQL Database disertifikasi sebagai layanan yang sesuai, SQL Database membantu kepatuhan layanan organisasi Anda tetapi tidak secara otomatis menjaminnya.

Pemantauan dan pemeliharaan database cerdas setelah migrasi

Setelah memigrasikan database ke SQL Database, Anda harus memantau database Anda (misalnya, memeriksa seperti apa penggunaan sumber daya atau pemeriksaan DBCC) dan melakukan pemeliharaan rutin (misalnya, membangun kembali atau mengatur ulang indeks, statistik, dll.). SQL Database menggunakan tren historis dan metrik dan statistik yang direkam untuk secara proaktif membantu Anda memantau dan memelihara database Anda, sehingga aplikasi Anda berjalan secara optimal selalu. Dalam beberapa kasus, Azure SQL Database dapat secara otomatis melakukan tugas pemeliharaan tergantung pada pengaturan konfigurasi Anda. Ada tiga faset untuk memantau database Anda di SQL Database:

• Pemantauan dan pengoptimalan performa
• Pengoptimalan keamanan
• Pengoptimalan biaya

Pemantauan dan pengoptimalan performa

Dengan Wawasan Performa Kueri, Anda bisa mendapatkan rekomendasi yang disesuaikan untuk beban kerja database Anda sehingga aplikasi Anda dapat terus berjalan pada tingkat optimal. Anda juga dapat menyiapkannya sehingga rekomendasi ini diterapkan secara otomatis dan Anda tidak perlu repot-repot melakukan tugas pemeliharaan. Dengan SQL Database Advisor, Anda dapat secara otomatis menerapkan rekomendasi indeks berdasarkan beban kerja Anda. Ini disebut Penyetelan Otomatis. Rekomendasi akan berubah saat beban kerja aplikasi Anda berubah untuk memberi Anda saran yang paling relevan. Anda juga mendapatkan opsi untuk meninjau rekomendasi ini secara manual dan menerapkannya atas kebijaksanaan Anda.

Pengoptimalan keamanan

SQL Database memberikan rekomendasi keamanan yang dapat ditindaklanjuti untuk membantu Anda mengamankan data dan deteksi ancaman untuk mengidentifikasi dan menyelidiki aktivitas database mencurigakan yang dapat menimbulkan utas potensial ke database. Penilaian kerentanan adalah layanan pemindaian dan pelaporan database yang memungkinkan Anda memantau status keamanan database Anda dalam skala besar dan mengidentifikasi risiko keamanan dan menyimpang dari garis dasar keamanan yang Anda tentukan. Setelah setiap pemindaian, daftar langkah yang dapat ditindaklanjuti dan skrip remediasi yang disesuaikan disediakan, dan laporan penilaian yang dapat digunakan untuk membantu memenuhi persyaratan kepatuhan.

Dengan Microsoft Defender untuk Cloud, Anda mengidentifikasi rekomendasi keamanan di seluruh papan dan dengan cepat menerapkannya.

Pengoptimalan biaya

Platform Azure SQL menganalisis riwayat pemanfaatan di seluruh database di server untuk mengevaluasi dan merekomendasikan opsi pengoptimalan biaya untuk Anda. Analisis ini biasanya membutuhkan waktu beberapa minggu aktivitas untuk menganalisis dan membangun rekomendasi yang dapat ditindaklanjuti.

Anda mungkin menerima pemberitahuan banner di server Rekomendasi biaya Azure SQL Anda. Untuk informasi selengkapnya, lihat Kumpulan elastis membantu Anda mengelola dan menskalakan beberapa database di Azure SQL Database, dan Merencanakan dan mengelola biaya untuk Azure SQL Database.

Bagaimana cara memantau performa dan pemanfaatan sumber daya di SQL Database?

Anda dapat memantau performa dan pemanfaatan sumber daya di SQL Database menggunakan metode berikut:

pengamat database

Pengamat database mengumpulkan data pemantauan beban kerja mendalam untuk memberi Anda tampilan terperinci tentang performa, konfigurasi, dan kesehatan database. Dasbor di portal Azure menyediakan tampilan panel kaca tunggal dari estate Azure SQL Anda dan tampilan terperinci dari setiap sumber daya yang dipantau. Data dikumpulkan ke penyimpanan data pusat di langganan Azure Anda. Anda dapat mengkueri, menganalisis, mengekspor, memvisualisasikan data yang dikumpulkan, dan mengintegrasikannya dengan sistem hilir.

Untuk informasi selengkapnya tentang pengamat database, lihat artikel berikut ini:

• Memantau beban kerja Azure SQL dengan pengamat database (pratinjau)
• Mulai cepat: Buat pemantau untuk memantau Azure SQL (pratinjau)
• Membuat dan mengonfigurasi pengamat (pratinjau)
• Pengumpulan data dan himpunan data pengamat database (pratinjau)
• Menganalisis data pemantauan pengamat database (pratinjau)
• Tanya Jawab Umum pengamat database

portal Azure

portal Azure memperlihatkan pemanfaatan database dengan memilih database dan memilih bagan di panel Gambaran Umum. Anda dapat memodifikasi bagan untuk menampilkan beberapa metrik, termasuk persentase CPU, persentase DTU, persentase IO Data, persentase Sesi, dan persentase ukuran Database.

Dari bagan ini, Anda juga dapat mengonfigurasi peringatan berdasarkan sumber daya. Peringatan ini memungkinkan Anda untuk menanggapi kondisi sumber daya dengan email, ketik ke titik akhir HTTPS/HTTP atau lakukan tindakan. Untuk informasi selengkapnya, lihat Membuat pemberitahuan untuk Azure SQL Database dan Azure Synapse Analytics menggunakan portal Microsoft Azure.

Tampilan manajemen dinamis

Anda bisa mengkueri tampilan manajemen dinamis sys.dm_db_resource_stats untuk menampilkan riwayat statistik konsumsi sumber daya dari satu jam terakhir dan tampilan katalog sistem sys.resource_stats untuk menampilkan riwayat selama 14 hari terakhir.

Insight performa kueri

Wawasan performa kueri memungkinkan Anda melihat riwayat kueri yang memakan sumber daya teratas dan kueri yang berjalan lama untuk database tertentu. Anda dapat dengan cepat mengidentifikasi TOP kueri berdasarkan pemanfaatan sumber daya, durasi, dan frekuensi eksekusi. Anda dapat melacak kueri dan mendeteksi regresi. Fitur ini mengharuskan Penyimpanan Kueri diaktifkan dan aktif untuk database.

Saya melihat masalah performa: Bagaimana metodologi pemecahan masalah SQL Database saya berbeda dari SQL Server?

Sebagian besar teknik pemecahan masalah yang akan Anda gunakan untuk mendiagnosis masalah performa kueri dan database tetap sama: mesin database yang sama mendukung cloud. Azure SQL Database dapat membantu Anda memecahkan masalah dan mendiagnosis masalah performa dengan lebih mudah. Ini juga dapat melakukan beberapa tindakan korektif ini atas nama Anda dan dalam beberapa kasus, secara proaktif memperbaikinya secara otomatis.

Pendekatan Anda terhadap pemecahan masalah performa dapat sangat bermanfaat dengan menggunakan fitur cerdas seperti Wawasan Performa Kueri (QPI) dan Database Advisor secara bersamaan. Dengan demikian, pendekatan metodologi berubah, di mana Anda tidak perlu lagi melakukan pekerjaan manual untuk merinci detail penting yang dapat membantu Anda menyelesaikan masalah. Platform melakukan kerja keras ini untuk Anda. Salah satu contohnya adalah QPI. Dengan QPI, Anda bisa menelusuri semuanya sampai ke tingkat kueri dan melihat tren historis dan mencari tahu kapan tepatnya kueri mengalami kemunduran. Database Advisor memberi Anda rekomendasi tentang hal-hal yang mungkin membantu Anda meningkatkan performa keseluruhan secara umum, seperti indeks yang hilang, menghilangkan indeks, membuat parameter kueri Anda, dll.

Dengan pemecahan masalah performa, penting untuk mengidentifikasi apakah itu hanya aplikasi atau database yang mendukungnya, yang memengaruhi performa aplikasi Anda. Seringkali masalah performa terletak pada lapisan aplikasi. Bisa jadi arsitektur atau pola akses data. Misalnya, bayangkan Anda memiliki aplikasi yang banyak berkomunikasi dan sensitif terhadap latensi jaringan. Dalam hal ini, aplikasi Anda menderita karena akan ada banyak permintaan singkat bolak-balik ("cerewet") antara aplikasi dan server dan pada jaringan yang padat, dan perjalanan pulang-pergi ini bertambah cepat. Untuk meningkatkan performa dalam hal ini, Anda dapat menggunakan Kueri Batch, yang membantu mengurangi latensi pulang pergi dan meningkatkan performa aplikasi Anda.

Selain itu, jika Anda menyadari degradasi dalam performa keseluruhan database Anda, Anda dapat memantau tampilan manajemen dinamis sys.dm_db_resource_stats dan sys.resource_stats untuk memahami CPU, IO, dan konsumsi memori. Performa Anda mungkin terpengaruh jika database Anda kelaparan sumber daya. Anda mungkin perlu mengubah ukuran komputasi dan/atau tingkat layanan berdasarkan tuntutan beban kerja yang berkembang dan menyusut.

Untuk panduan lengkap dalam mengoptimalkan masalah kinerja, lihat Mengoptimalkan database Anda.

Bagaimana cara memastikan saya menggunakan tingkat layanan dan ukuran komputasi yang sesuai?

SQL Database menawarkan dua model pembelian yang berbeda: model DTU yang lebih lama dan model pembelian vCore yang lebih mudah beradaptasi. Untuk informasi selengkapnya, lihat Membandingkan model pembelian berbasis vCore dan DTU dari Azure SQL Database.

Anda dapat memantau konsumsi sumber daya kueri dan database Anda dalam kedua model pembelian. Untuk informasi selengkapnya, lihat Memantau dan menyetel performa. Jika Anda menemukan bahwa kueri/database Anda secara konsisten berjalan panas, Anda dapat mempertimbangkan untuk meningkatkan skala ke ukuran komputasi yang lebih tinggi. Demikian pula, jika Anda tampaknya tidak menggunakan sumber daya sebanyak selama jam sibuk, pertimbangkan untuk menurunkan skala dari ukuran komputasi saat ini. Anda dapat mempertimbangkan untuk menggunakan Azure Automation untuk menskalakan database SQL Anda sesuai jadwal.

Jika Anda memiliki pola aplikasi SaaS atau skenario konsolidasi database, pertimbangkan untuk menggunakan kumpulan Elastis untuk pengoptimalan biaya. Kumpulan elastis adalah cara yang bagus untuk mencapai konsolidasi database dan pengoptimalan biaya. Untuk informasi selengkapnya tentang mengelola beberapa database menggunakan kumpulan elastis, lihat Mengelola kumpulan dan database.

Seberapa sering saya perlu menjalankan pemeriksaan integritas database untuk database saya?

SQL Database dapat menangani kelas kerusakan data tertentu secara otomatis dan tanpa kehilangan data. Teknik bawaan ini digunakan oleh layanan ketika kebutuhan muncul. Pencadangan database Anda di seluruh layanan diuji secara teratur dengan memulihkannya dan menjalankan DBCC CHECKDB pada pencadangan tersebut. Jika ada masalah, SQL Database akan secara proaktif mengatasinya.

Perbaikan halaman otomatis digunakan untuk memperbaiki halaman yang rusak atau memiliki masalah integritas data. Halaman database selalu diverifikasi dengan pengaturan default CHECKSUM yang memverifikasi integritas halaman. SQL Database secara proaktif memantau dan meninjau integritas data database Anda dan mengatasi masalah saat muncul. Anda dapat secara opsional menjalankan pemeriksaan integritas Anda sendiri sesuai kebutuhan. Untuk informasi selengkapnya, lihat Integritas Data di SQL Database.

Pergerakan data setelah migrasi

Bagaimana cara mengekspor dan mengimpor data sebagai file BACPAC dari SQL Database menggunakan portal Microsoft Azure?

• Ekspor: Anda dapat mengekspor database Anda di Azure SQL Database sebagai file BACPAC dari portal Microsoft Azure:

  

• Impor: Anda juga dapat mengimpor data sebagai file BACPAC ke database Anda di Azure SQL Database menggunakan portal Microsoft Azure:

  

Bagaimana cara menyinkronkan data antara SQL Database dan SQL Server?

Anda memiliki beberapa cara untuk mencapai hal ini:

• Sinkronisasi Data: Fitur ini membantu Anda menyinkronkan data dua arah antara beberapa database SQL Server dan SQL Database. Untuk sinkronisasi dengan database SQL Server, Anda perlu memasang dan mengonfigurasi agen sinkronisasi di komputer lokal atau komputer virtual dan membuka port TCP keluar 1433.

• Replikasi Transaksi: Dengan replikasi transaksi, Anda dapat menyinkronkan data Anda dari database SQL Server ke Azure SQL Database dengan instans SQL Server menjadi penerbit dan Azure SQL Database menjadi pelanggan. Untuk saat ini, hanya penyetelan ini yang didukung. Untuk informasi selengkapnya tentang cara memigrasikan data Anda dari database SQL Server ke Azure SQL dengan waktu henti minimal, lihat Menggunakan Replikasi Transaksi

Konten terkait

• Memantau dan menyetel performa di Azure SQL Database dan Azure SQL Managed Instance