DBA baru di cloud - Mengelola Azure SQL Database setelah migrasi

Berlaku untuk: Azure SQL Database

Berpindah dari lingkungan tradisional dengan pengelolaan kontrol mandiri ke lingkungan PaaS pada awalnya bisa tampak sedikit merepotkan. Sebagai pengembang aplikasi atau DBA, Anda ingin mengetahui kemampuan inti platform yang akan membantu Anda membuat aplikasi Anda selalu tersedia, berperforma baik, aman dan tangguh - selalu. Artikel ini bertujuan untuk melakukan hal itu. Artikel ini secara ringkas mengatur sumber daya dan memberi Anda beberapa panduan tentang cara terbaik menggunakan kemampuan kunci Azure SQL Database dengan database tunggal dan terkumpul untuk mengelola dan menjaga aplikasi Anda berjalan secara efisien dan mencapai hasil yang optimal di cloud. Audiens umum untuk artikel ini adalah mereka yang:

• Sedang mengevaluasi migrasi aplikasi mereka ke Azure SQL Database - Memodernisasi aplikasi Anda.
• Sedang dalam proses migrasi aplikasi mereka - Skenario migrasi yang sedang berlangsung.
• Baru-baru ini menyelesaikan migrasi ke Azure SQL Database - DBA baru di cloud.

Artikel ini membahas beberapa karakteristik inti Azure SQL Database sebagai platform yang dapat Anda gunakan dengan mudah saat bekerja dengan database tunggal dan database terkumpul di kumpulan elastis. Berikut ini:

• Memantau database menggunakan 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. Lihat artikel model pembelian berbasis DTU dan model pembelian berbasis vCore untuk informasi selengkapnya tentang tingkat layanan.

Anda dapat mengonfigurasi pemberitahuan pada metrik performa. Pilih tombol Tambahkan pemberitahuan di jendela Metrik . Ikuti panduan untuk mengonfigurasi pemberitahuan Anda. Anda memiliki opsi untuk mengaktifkan pemberitahuan jika metrik melebihi ambang batas tertentu atau jika metrik berada di bawah ambang 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, seperti biasa, jika terjadi bencana. 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

Anda tidak membuat cadangan di Azure SQL Database dan itu karena Anda tidak perlu. SQL Database secara otomatis mencadangkan database untuk Anda, sehingga Anda tidak perlu lagi khawatir tentang penjadwalan, pengambilan, dan pengelolaan cadangan. Platform ini mengambil cadangan penuh setiap minggu, cadangan 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" dan bervariasi sesuai dengan tingkat layanan yang Anda pilih. SQL Database memberi Anda wewenang untuk memulihkan ke titik waktu kapan pun dalam periode penyimpanan ini menggunakan Pemulihan Berdasar Titik Waktu (PITR).

Selain itu, fitur Retensi Jangka Panjang (LTR) memungkinkan Anda untuk memegang file cadangan Anda untuk jangka waktu yang lebih lama secara khusus, hingga 10 tahun, dan memulihkan data dari cadangan ini pada titik mana pun dalam periode tersebut. Selain itu, cadangan database disimpan dalam penyimpanan replikasi geografis untuk memastikan ketahanan dari bencana regional. Anda juga dapat memulihkan cadangan ini di wilayah Azure mana pun kapan saja dalam periode retensi. Lihat Gambaran umum kelangsungan bisnis untuk mempelajari selengkapnya.

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. RPO (Tujuan Titik Pemulihan) untuk pemulihan geografis umumnya < adalah 1 jam dan ERT (Perkiraan Waktu Pemulihan) - beberapa menit hingga jam.

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 menyediakan cara mudah untuk 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 Grup failover.

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 sangat berguna untuk 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 mempelajari selengkapnya, lihat Pemulihan Bencana Azure SQL Database 101.

Keamanan dan kepatuhan

SQL Database sangat serius dalam menangani keamanan dan privasi. Keamanan dalam SQL Database tersedia di tingkat database dan di tingkat platform dan paling mudah dipahami ketika dikategorikan ke dalam beberapa lapisan. Pada setiap lapisan Anda dapat mengontrol dan memberikan keamanan optimal untuk aplikasi Anda. Lapisan-lapisan itu adalah:

• Identitas & autentikasi (autentikasi dan autentikasi SQL dengan ID Microsoft Entra (sebelumnya Azure Active Directory).
• Pemantauan aktivitas (Audit dan deteksi ancaman).
• Melindungi data aktual (Enkripsi Data Transparan [TDE] dan Always Encrypted [AE]).
• 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 dalam 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. Dengan ini, Anda dapat dengan mudah memberikan akses menyeluruh (SSO) ke personel di organisasi Anda. Artinya, kredensial dibagikan di seluruh layanan Azure untuk autentikasi yang lebih sederhana.

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 Microsoft, dan menggunakan autentikasi multifaktor Microsoft Entra.
Masuk ke Windows menggunakan kredensial Microsoft Entra Anda dari domain federasi	Gunakan autentikasi terintegrasi Microsoft Entra.
Sedang masuk ke Windows menggunakan kredensial dari domain yang tidak terfederasi dengan Azure	Gunakan autentikasi terintegrasi Microsoft Entra.
Memiliki layanan tingkat menengah yang perlu terhubung 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 VNet
• IP yang Dicadangkan

Firewall

Firewall mencegah akses ke server Anda dari entitas eksternal dengan hanya mengizinkan akses entitas tertentu ke server Anda. Secara default, semua koneksi ke database di dalam server tidak diizinkan, kecuali koneksi (opsional7) 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 mempelajari selengkapnya 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 VNet.

Titik Akhir layanan (SE) memungkinkan Anda mengekspos sumber daya Azure penting anda hanya ke jaringan virtual privat Anda sendiri di Azure. Dengan demikian, Anda pada dasarnya menghilangkan akses publik ke sumber daya Anda. Lalu lintas antara jaringan virtual Anda ke Azure tetap berada di jaringan inti Azure. Tanpa SE, Anda mendapatkan perutean paket 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 inti 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 pada

Port 1433. SQL Database berkomunikasi melalui port ini. 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

Dengan SQL Database, Anda dapat mengaktifkan Audit untuk melacak peristiwa database. Audit SQL Database merekam peristiwa database dan menuliskannya ke dalam file log audit di Akun Azure Storage Anda. Audit sangat berguna jika Anda ingin 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 di database Anda. Anda dapat menerapkan kebijakan audit ini baik di tingkat database atau di tingkat server. Panduan tentang cara mengaktifkan audit untuk server/database Anda, lihat: Mengaktifkan Audit SQL Database.

Deteksi ancaman

Dengan deteksi ancaman, Anda mendapatkan kemampuan untuk bertindak atas pelanggaran keamanan atau kebijakan yang ditemukan oleh Audit dengan sangat mudah. Anda tidak perlu menjadi pakar keamanan untuk mengatasi potensi ancaman atau pelanggaran dalam sistem Anda. Deteksi ancaman juga memiliki beberapa kemampuan bawaan seperti deteksi SQL Injection. SQL Injection adalah upaya untuk mengubah atau membahayakan data dan cara yang cukup umum untuk menyerang aplikasi database secara umum. Deteksi ancaman menjalankan beberapa set algoritma yang mendeteksi potensi kerentanan dan serangan injeksi SQL, serta 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 tidak digunakan dalam data dan file log
• Data Anda yang sedang aktif

Dalam SQL Database, secara default, data tidak aktif anda dalam data dan file log pada subsistem penyimpanan akan 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 yang aktif dan tidak aktif, SQL Database menyediakan fitur yang disebut Always Encrypted (AE). AE 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. AE mengenkripsi kolom sensitif dalam tabel secara menyeluruh, dari klien yang tidak sah ke disk fisik. AE mendukung perbandingan kesetaraan hari ini, 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	Always Encrypted	Transparent Data Encryption
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	Sangat Minimal
Granularitas enkripsi	Tingkat kolom	Tingkat database

Bagaimana cara membatasi akses ke data sensitif di database saya

Setiap aplikasi memiliki data sensitif tertentu 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. Salah satu contohnya adalah upah karyawan. Manajer akan membutuhkan akses ke informasi upah untuk laporan langsung mereka namun, anggota tim individu tidak boleh memiliki akses ke informasi upah rekan-rekan mereka. Skenario lain adalah pengembang data yang mungkin berinteraksi dengan data sensitif selama tahap pengembangan atau pengujian, misalnya, SSN pelanggan. Informasi ini lagi tidak perlu diekspos ke pengembang. 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 visibilitas data sensitif dengan menutupinya dari 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 dari ID SSN nasional: XXX-XX-0000 dan menandai sebagian besar sebagai Xs) 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 utama untuk Always Encrypted (enkripsi sisi klien) dan Enkripsi Data Transparan (enkripsi saat istirahat). 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 platform - SQL Database.
• Atau dengan Anda menggunakan Azure Key Vault sebagai penyimpanan kunci.

Secara default, kunci master untuk Enkripsi Data Transparan dikelola oleh layanan SQL Database untuk kenyamanan. Jika organisasi Anda ingin mengontrol kunci master, ada opsi untuk 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.

Always Encrypted

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 ini memperlihatkan opsi penyimpanan kunci untuk tombol master kolom di Always Encrypted

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

Lalu lintas jaringan antara organisasi Anda dan SQL Database umumnya akan dialihkan melalui jaringan publik. Namun, jika Anda memilih untuk mengoptimalkan jalur ini dan membuatnya lebih aman, Anda dapat melihat ke Azure ExpressRoute. ExpressRoute pada dasarnya memungkinkan Anda memperluas jaringan perusahaan Anda ke platform Azure melalui koneksi privat. Dengan demikian, Anda tidak melalui Internet publik. Anda juga mendapatkan keamanan, keandalan, dan pengoptimalan perutean yang lebih tinggi yang berarti ke latensi jaringan yang lebih rendah dan kecepatan yang jauh lebih cepat daripada yang biasanya Anda dapatkan 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:

• Lokasi Bersama Cloud Exchange
• Semua-ke-semua
• Poin-ke-poin

ExpressRoute juga memungkinkan Anda untuk meningkatkan kecepatan hingga 2x batas bandwidth yang Anda beli tanpa biaya tambahan. Dimungkinkan juga untuk mengonfigurasi konektivitas lintas wilayah menggunakan ExpressRoute. Untuk melihat 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 kepatuhan terbaru yang telah dipenuhi oleh SQL Database, kunjungi Microsoft Trust Center dan telusuri paling detail tentang persyaratan yang penting bagi organisasi Anda untuk melihat apakah SQL Database disertakan di bawah layanan Azure yang sesuai. Penting untuk dicatat bahwa 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 akan ingin 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.). Untungnya, SQL Database cerdas dalam arti bahwa ia menggunakan tren riwayat lalu metrik dan statistik yang direkam untuk membantu Anda memantau dan memelihara database Anda secara proaktif, sehingga aplikasi Anda selalu berjalan optimal. 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 yang optimal - selalu. 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-langkah yang dapat disesuaikan dan skrip remediasi disediakan, serta 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.
• Kumpulan elastis adalah salah satu opsi seperti itu. Untuk informasi selengkapnya, lihat Kumpulan elastis membantu Anda mengelola dan menskalakan beberapa database di Azure SQL Database.
• Untuk informasi selengkapnya, lihat 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: Membuat pengamat database untuk memantau Azure SQL (pratinjau)
• Membuat dan mengonfigurasi pengamat database (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 peringatan.

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 kueri TERTINGGI 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 memperhatikan masalah performa: Bagaimana perbedaan metodologi pemecahan masalah SQL Database saya dengan SQL Server

Sebagian besar teknik pemecahan masalah yang akan Anda gunakan untuk mendiagnosis masalah kueri dan performa database tetap sama. Bagaimanapun, cloud digerakkan oleh mesin database yang sama. Namun, platform - Azure SQL Database telah dibangun dalam 'kecerdasan'. Itu dapat membantu Anda memecahkan masalah dan mendiagnosis masalah performa dengan lebih mudah. Kecerdasan tersebut juga dapat melakukan beberapa tindakan korektif atas nama Anda dan dalam beberapa kasus, secara proaktif memperbaikinya - secara otomatis.

Pendekatan Anda terhadap pemecahan masalah performa dapat secara signifikan mendapat manfaat dengan menggunakan fitur cerdas seperti Wawasan Performa Kueri (QPI) dan Database Advisor bersama-sama dan sehingga perbedaan metodologi berbeda dalam hal itu - Anda tidak perlu lagi melakukan pekerjaan manual untuk menggiling detail penting yang mungkin membantu Anda memecahkan masalah di tangan. 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. SQL Database Advisor memberi Anda rekomendasi tentang hal-hal yang mungkin membantu Anda meningkatkan performa keseluruhan secara umum seperti - indeks yang hilang, indeks yang jatuh, parameterisasi 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, pertimbangkan Anda memiliki aplikasi ramai yang sensitif terhadap latensi jaringan. Dalam hal ini, aplikasi Anda menderita karena akan ada banyak permintaan singkat bolak-balik ("ramai") antara aplikasi dan server dan pada jaringan yang padat, lalu lintas bolak-balik ini bertambah dengan cepat. Untuk meningkatkan performa dalam hal ini, Anda dapat menggunakan Kueri Batch. Menggunakan batch sangat membantu Anda karena sekarang permintaan Anda diproses dalam batch; dengan demikian, membantu Anda mengurangi latensi bolak-balik 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 dapat terpengaruh karena database Anda kelaparan sumber daya. Bisa jadi Anda mungkin perlu mengubah ukuran komputasi dan/atau tingkat layanan berdasarkan tuntutan beban kerja yang berkembang dan menyusut.

Untuk serangkaian rekomendasi komprehensif untuk menyetel masalah performa, lihat: Penyetelan database Anda.

Bagaimana cara memastikan bahwa 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 perbedaan antara, lihat Membandingkan model pembelian berbasis vCore dan DTU dari Azure SQL Database.

Untuk memastikan Anda berada di ukuran komputasi yang tepat, Anda dapat memantau konsumsi sumber daya kueri dan database Anda, baik dalam 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 mencatat bahwa bahkan selama jam sibuk Anda, Anda tampaknya tidak menggunakan sumber daya sebanyak; 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 membaca 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 menggunakan beberapa teknik cerdas yang memungkinkannya untuk menangani kelas tertentu dari kerusakan data secara otomatis dan tanpa kehilangan data. Teknik-teknik ini dibangun pada layanan dan dimanfaatkan oleh layanan ketika dibutuhkan. Secara teratur, cadangan database Anda di seluruh layanan telah diuji dengan memulihkannya dan menjalankan DBCC CHECKDB padanya. Jika ada masalah, SQL Database akan secara proaktif mengatasinya. Perbaikan halaman otomatis dimanfaatkan untuk memperbaiki halaman yang rusak atau memiliki masalah integritas data. Halaman database selalu diverifikasi dengan pengaturan CHECKSUM default yang memverifikasi integritas halaman. SQL Database secara proaktif memantau dan meninjau integritas data database Anda dan, jika masalah muncul, mengatasinya dengan prioritas tertinggi. Selain itu, Anda dapat memilih untuk secara opsional menjalankan pemeriksaan integritas Anda sendiri sesuai keinginan Anda. 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 sebagai penerbit dan Azure SQL Database sebagai 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