Praktik terbaik umum

Halaman ini berisi tentang praktik terbaik untuk mendapatkan performa, ketahanan, dan ketersediaan terbaik dari Cloud SQL.

Jika terjadi masalah pada instance Cloud SQL, tinjau dokumentasi dukungan berikut saat melakukan pemecahan masalah:

Konfigurasi dan administrasi instance

Praktik terbaik Informasi selengkapnya
Baca dan ikuti pedoman operasional untuk memastikan bahwa instance Anda tercakup dalam SLA Cloud SQL.
Konfigurasikan masa pemeliharaan pada instance utama untuk mengontrol waktu saat update yang mengganggu dapat terjadi. Lihat Masa pemeliharaan.
Jika Anda rutin menghapus dan membuat ulang instance, gunakan stempel waktu dalam ID instance untuk meningkatkan kemungkinan ID instance baru dapat digunakan.
Jangan memulai operasi administratif sebelum operasi sebelumnya selesai.

Instance Cloud SQL tidak menerima permintaan operasi baru hingga operasi sebelumnya selesai. Jika Anda mencoba untuk memulai operasi baru sebelum waktunya, permintaan operasi akan gagal. Operasi ini termasuk memulai ulang instance.

Status instance di konsol Google Cloud tidak menunjukkan bahwa operasi sedang berjalan. Tanda centang hijau hanya menunjukkan bahwa instance berada dalam status RUNNABLE. Untuk melihat bahwa operasi sedang berjalan, buka tab Operasi, lalu periksa status operasi terbaru.

Konfigurasikan penyimpanan untuk mengakomodasi pemeliharaan database yang penting.

Jika setelan instance aktifkan peningkatan penyimpanan otomatis dalam keadaan nonaktif atau setelan batas peningkatan penyimpanan otomatis dalam keadaan aktif, pastikan Anda memiliki minimal 20% dari kapasitas yang tersedia untuk mengakomodasi operasi pemeliharaan database penting apa pun yang dapat dijalankan Cloud SQL.

Agar mendapatkan pemberitahuan saat kapasitas disk yang tersisa kurang dari 20%, buat kebijakan pemberitahuan berbasis metrik pada metrik pemakaian disk dengan posisi di atas nilai minimum dan nilai sebesar .8. Untuk informasi selengkapnya, lihat Membuat kebijakan pemberitahuan berbasis metrik.
Cegah penggunaan CPU yang berlebihan.

Anda dapat melihat persentase CPU yang tersedia yang digunakan instance di halaman detail instance di konsol Google Cloud. Untuk informasi selengkapnya, lihat Metrik. Anda juga dapat memantau penggunaan CPU dan menerima pemberitahuan pada batas yang ditentukan menggunakan Membuat kebijakan pemberitahuan batas metrik.

Untuk menghindari penggunaan yang berlebihan, Anda dapat meningkatkan jumlah CPU untuk instance Anda. Jika ingin mengubah CPU, instance harus dimulai ulang. Jika instance sudah mencapai batas maksimum jumlah CPU, Anda harus melakukan sharding database ke beberapa instance.
Hindari terjadinya kehabisan memori.

Saat mencari tanda-tanda kehabisan memori, Anda sebaiknya menggunakan metrik penggunaan sebagai langkah utama. Untuk menghindari terjadinya error kehabisan memori, sebaiknya upayakan agar metrik ini tetap berada di bawah 90%.

Anda juga dapat menggunakan metrik total_usage untuk mengamati persentase memori yang tersedia yang digunakan instance Cloud SQL, termasuk memori yang digunakan container database dan memori yang dialokasikan oleh cache sistem operasi.

Dengan mengamati perbedaan antara kedua metrik tersebut, Anda dapat mengidentifikasi jumlah memori yang digunakan oleh proses dengan jumlah yang digunakan oleh cache sistem operasi. Anda dapat menggunakan kembali memori dalam cache ini.

Untuk memprediksi masalah kehabisan memori, periksa kedua metrik dan tafsirkan keduanya bersamaan. Jika metrik tampak tinggi, kemungkinan memori instance rendah. Masalah ini dapat disebabkan oleh konfigurasi kustom, ukuran instance yang terlalu kecil untuk workload, atau kombinasi dari faktor-faktor ini.

Skalakan instance Cloud SQL untuk meningkatkan ukuran memorinya. Jika ingin mengubah ukuran memori instance, instance harus dimulai ulang. Jika instance sudah mencapai ukuran memori maksimum, Anda harus melakukan sharding database ke beberapa instance. Untuk mempelajari lebih lanjut cara memantau kedua metrik di konsol Google Cloud, lihat Metrik.
Tetapkan setelan SQL Server agar dapat berfungsi secara optimal untuk Cloud SQL. Lihat setelan SQL Server.
Sesuaikan instance secara optimal untuk pengujian. Tabel berikut menampilkan nilai konfigurasi yang sesuai untuk pengujian.
  • vCPU: 40
  • Memori: 262144 MB
  • MAXDOP: 8
  • Ambang batas biaya untuk paralelisme: 120
  • File tempdb: 8. Ukuran yang sudah ditetapkan mencegah pertumbuhan otomatis.
  • File database pengguna: Autogrow ditetapkan ke 64-128 MB. Ukuran yang sudah ditetapkan untuk mencegah pertumbuhan otomatis.
  • Penyimpanan: >= 4TB untuk IOPS terbaik
Tentukan kapasitas subsistem I/O sebelum men-deploy SQL Server.

Uji berbagai jenis dan ukuran I/O. Ukuran I/O yang dikeluarkan untuk penyimpanan persistent disk, serta berasal dari SQL Server memengaruhi IOPS dan throughput. Workload SQL Server akan di-throttle saat mencapai batas IOPS atau batas throughput. Jenis penyimpanan yang digunakan di Cloud SQL adalah PD SSD. Jenis penyimpanan ini sesuai untuk workload tingkat perusahaan berperforma tinggi.

Sesuaikan VM untuk memaksimalkan performa sebagai berikut:

  • Disk berukuran 4 TB atau lebih memberikan throughput dan IOPS yang lebih besar.
  • vCPU yang lebih tinggi memberikan IOPS dan throughput yang lebih tinggi. Saat menggunakan vCPU yang lebih tinggi, pantau waktu tunggu DB untuk mengetahui adanya paralelisme yang juga dapat meningkat.
  • Untuk performa optimal, I/O dikeluarkan secara paralel untuk mencapai kedalaman antrean I/O yang lebih tinggi.
Cegah fragmentasi indeks dan indeks yang hilang. Atur ulang indeks atau tetapkan jadwal untuk membangun ulang indeks berdasarkan seberapa sering data Anda berubah. Selain itu, tetapkan faktor pengisian yang sesuai untuk mengurangi fragmentasi. Pantau SQL Server untuk menemukan indeks yang hilang yang dapat menawarkan performa lebih baik.
Perbarui statistik secara rutin. Jika statistik sudah tidak berlaku, pengoptimal kueri SQL dapat menghasilkan paket kueri yang kurang optimal. Perbarui statistik, terutama setelah sejumlah besar data diubah. Gunakan penyimpanan kueri untuk memantau dan memecahkan masalah SQL Server yang memiliki paket kueri yang kurang optimal.
Cegah file database menjadi terlalu besar.

Tetapkan autogrow dalam MB, bukan dalam persentase, menggunakan peningkatan yang sesuai dengan persyaratan. Selain itu, kelola pertumbuhan secara proaktif sebelum pertumbuhan otomatis mulai terjadi.

Pastikan juga bahwa fitur Aktifkan peningkatan penyimpanan otomatisruang penyimpanan Cloud SQL dalam kondisi aktif agar Cloud SQL dapat menambahkan ruang penyimpanan saat database atau instance kehabisan ruang.

Deteksi masalah integritas database dengan menjalankan DBCC CHECKDB minimal seminggu sekali. DBCC CHECKDB memeriksa integritas semua objek dalam database. Dengan menjalankan DBCC CHECKDB setiap minggunya, Anda dapat memastikan bahwa database Anda tidak rusak. DBCC CHECKDB adalah operasi yang memerlukan banyak resource yang dapat memengaruhi performa instance.
Jangan menjalankan DBCC CHECKDB di server produksi.
Sebaiknya, gunakan salah satu opsi berikut, bukan menjalankan DBCC CHECKDB di server produksi:
  • Clone database dan jalankan DBCC CHECKDB pada database clone.
  • Pulihkan cadangan ke instance lain, lalu jalankan DBCC CHECKDB pada database instance yang dipulihkan. Untuk informasi selengkapnya tentang cara memulihkan instance, lihat Memulihkan instance.

Gunakan cuplikan kode berikut untuk menjalankan DBCC CHECKDB pada database:

  • (Direkomendasikan) Jalankan DBCC CHECKDB dengan EXTENDED_LOGICAL_CHECKS. Pemeriksaan ini menyeluruh, tetapi lebih banyak memerlukan resource. 
          USE DATABASE_NAME
      DBCC CHECKDB WITH EXTENDED_LOGICAL_CHECKS,
      DATA_PURITY,NO_INFOMSGS, ALL_ERRORMSGS
  • Jalankan DBCC CHECKDB dengan PHYSICAL_ONLY: 
          USE DATABASE_NAME
      DBCC CHECKDB WITH PHYSICAL_ONLY,
      NO_INFOMSGS, ALL_ERRORMSGS

Arsitektur data

Praktik terbaik Informasi selengkapnya
Jika memungkinkan, bagi instance besar menjadi instance yang lebih kecil. Jika memungkinkan, menggunakan banyak instance Cloud SQL yang lebih kecil akan lebih baik dibandingkan dengan menggunakan satu instance besar. Mengelola instance monolitik besar memiliki tantangan, tidak seperti saat mengelola instance yang lebih kecil.
Jangan menggunakan terlalu banyak tabel database.

Pertahankan jumlah tabel instance kurang dari 10.000 tabel. Terlalu banyak tabel database dapat memengaruhi waktu upgrade database.

Kolasi database Jika Anda menginstal instance SQL Server baru, memulihkan cadangan database, atau menghubungkan server ke database klien, Anda harus memahami persyaratan lokalitas, tata urutan, serta kasus dan sensitivitas aksen dari data yang dikerjakan. Saat memilih kolasi dari server, database, kolom, atau ekspresi, Anda menetapkan karakteristik tertentu ke data tersebut. Karakteristik ini memengaruhi hasil dari banyak operasi dalam database. Misalnya, saat Anda membuat kueri menggunakan ORDER BY, tata urutan kumpulan hasilnya dapat bergantung pada kolasi yang diterapkan pada database atau ditentukan dalam COLLATE pada level ekspresi kueri. Baca selengkapnya tentang kolasi database dan dukungan unicode.
Desain kueri Untuk performa database atau kueri yang optimal, pastikan Anda tidak menggunakan tabel dalam jumlah besar dalam kueri yang sama (enam belas atau lebih).
Pemantauan kueri Kueri dapat menurun seiring waktu. Penting untuk memantau aplikasi dan kueri Anda dari waktu ke waktu. Salah satu faktor kueri dapat menurun disebabkan oleh hash bailout.
Hash join rekursif atau hash bailout menyebabkan penurunan performa di server Anda. Jika Anda melihat banyak peristiwa hash warning dalam trace, update statistik pada kolom yang digabungkan. Baca selengkapnya tentang hash bailout.

Implementasi aplikasi

Praktik terbaik Informasi selengkapnya
Gunakan praktik pengelolaan koneksi yang baik, seperti penggabungan koneksi dan backoff eksponensial. Menggunakan teknik ini akan meningkatkan penggunaan resource pada aplikasi dan membantu Anda tetap berada dalam batas koneksiCloud SQL. Untuk informasi dan contoh kode selengkapnya, lihat Mengelola koneksi database.
Uji respons aplikasi Anda terhadap update pemeliharaan yang dapat terjadi sewaktu-waktu selama masa pemeliharaan. Coba pemeliharaan mandiri untuk menyimulasikan update pemeliharaan. Selama pemeliharaan, instance Anda akan menjadi tidak tersedia untuk beberapa saat, serta koneksi yang ada akan dihentikan. Menguji peluncuran pemeliharaan dapat membantu Anda untuk lebih memahami cara aplikasi dalam menangani pemeliharaan terjadwal dan seberapa cepat sistem dapat pulih.
Uji respons aplikasi Anda terhadap failover yang dapat terjadi sewaktu-waktu. Anda dapat memulai failover secara manual menggunakan konsol Google Cloud, gcloud CLI, atau API. Lihat Memulai failover.
Hindari transaksi besar. Pertahankan agar transaksi tetap kecil dan singkat. Jika memerlukan update database yang besar, lakukanlah dalam beberapa transaksi yang lebih kecil, bukan satu transaksi besar.
Jika menggunakan Proxy Auth Cloud SQL, pastikan Anda menggunakan versi terbaru. Lihat Menjaga agar Proxy Auth Cloud SQL selalu dalam keadaan terbaru.

Impor dan ekspor data

Praktik terbaik Informasi selengkapnya
Percepat proses impor untuk instance berukuran kecil. Untuk instance kecil, Anda dapat meningkatkan CPU dan RAM instance untuk sementara guna meningkatkan performa saat mengimpor set data besar.
Jika Anda mengekspor data untuk diimpor ke Cloud SQL, pastikan Anda menggunakan prosedur yang tepat. Lihat Mengekspor data dari server database yang dikelola secara eksternal.

Pencadangan dan pemulihan

Praktik terbaik Informasi selengkapnya
Lindungi data Anda dengan fungsi Cloud SQL yang sesuai.

Pencadangan dan ekspor adalah cara untuk memberikan redundansi dan perlindungan data. Keduanya saling melindungi dari berbagai skenario dan saling melengkapi dalam strategi perlindungan data yang tangguh.

Pencadangan ringan; fungsi ini memberikan cara untuk memulihkan data pada instance ke kondisi semula saat Anda mengambil pencadangannya. Namun, pencadangan memiliki beberapa batasan. Jika instance dihapus, cadangannya juga akan terhapus. Anda tidak dapat mencadangkan satu database atau tabel. Jika region tempat instance berada tidak tersedia, Anda tidak dapat memulihkan instance dari cadangan tersebut, bahkan di region yang tersedia.

Proses ekspor memerlukan waktu lebih lama karena file eksternal dibuat di Cloud Storage yang dapat digunakan untuk membuat ulang data Anda. Ekspor tidak akan terpengaruh jika Anda menghapus instance. Selain itu, Anda hanya dapat mengekspor satu database atau bahkan tabel, tergantung pada format ekspor yang dipilih.

Saat menggunakan fitur cadangan ekspor pada instance SQL Server Enterprise atau Standard, hindari membuat file arsip GZ karena file ini akan mencoba mengompresi cadangan yang sudah terkompresi secara native oleh SQL Server.

Lindungi instance dan cadangan dari penghapusan yang tidak disengaja.

Instance Cloud SQL yang dibuat di konsol Google Cloud atau melalui Terraform mampu mencegah penghapusan yang tidak disengaja secara default.

Gunakan fitur ekspor di Cloud SQL untuk mengekspor data Anda sebagai perlindungan tambahan. Gunakan Cloud Scheduler dengan REST API untuk mengotomatiskan pengelolaan ekspor. Untuk skenario lanjutan selengkapnya, gunakan Cloud Scheduler dengan Cloud Functions untuk melakukan otomatisasi.

Setelan SQL Server

Beberapa setelan SQL Server direkomendasikan untuk Cloud SQL. Topik berikut menjelaskan tentang beberapa rekomendasi tersebut.

Setelan konfigurasi global

Setelan Rekomendasi
max worker threads Mempertahankan nilai default 0. Setelan ini menentukan jumlah thread yang tersedia untuk SQL Server berdasarkan jumlah CPU. Nilai ini otomatis dihitung oleh mesin SQL Server saat proses startup.

Setelan database yang akan diubah

Untuk performa database SQL Server yang optimal, tetapkan setelan SQL Server berikut seperti yang disarankan di bawah ini.

Setelan Rekomendasi
cost threshold for parallelism

Setelan ini adalah ambang batas yang digunakan pengoptimal SQL untuk menjalankan kueri menggunakan paralelisme. Nilai default 5 dapat menyebabkan terlalu banyak kueri yang dijalankan secara paralel sehingga meningkatkan waktu tunggu database pada thread paralel. Untuk mengurangi jenis pertentangan ini, tingkatkan nilainya.

Nilai diabaikan jika maxdop ditetapkan ke 1.

max degree of parallelism (MAXDOP)

Untuk mengurangi waktu tunggu database yang disebabkan oleh paralelisme, sesuaikan nilai ini berdasarkan rekomendasi tertentu tentang jumlah prosesor logis yang tersedia. Ukur performa dengan saksama jika menetapkan opsi ini ke 1.

optimize for ad hoc workloads

Hindari menyimpan rencana sekali pakai dalam jumlah besar dalam cache rencana. Guna meningkatkan efisiensi cache rencana untuk workload yang berisi banyak batch ad hoc pemakaian tunggal, tetapkan opsi ini ke 1.

tempdb

Tetapkan ukuran tempdb agar tidak perlu autogrow. Semua file dalam tempdb harus memiliki ukuran dan kumpulan pertumbuhan file yang sama.

Jenis waktu tunggu database untuk pertentangan tempdb muncul sebagai PAGELATCH_UP. Untuk mengurangi pertentangan, tambahkan lebih banyak file.

Jika jumlah prosesor kurang dari atau sama dengan 8, gunakan jumlah file yang sama dengan prosesor logis. Jika jumlah prosesor lebih besar dari 8, gunakan 8 file data. Jika pertentangan berlanjut, tingkatkan jumlah file sebanyak 4 kali hingga tidak ada pertentangan lagi.

Tergantung pada workload, Anda mungkin juga ingin mengubah setelan berikut.

Setelan Rekomendasi
Close Cursor on Commit Enabled Nilai defaultnya adalah off. Artinya, kursor tidak akan otomatis tertutup saat Anda meng-commit transaksi.
Default Cursor Opsi ini mengontrol cakupan kursor yang digunakan dalam kode T-SQL. Jika Anda mengubah setelan ini, evaluasi kode aplikasi untuk menemukan dampak apa pun yang merugikan.
Page Verify Opsi ini memungkinkan SQL Server menghitung checksum untuk halaman database sebelum ditulis ke disk dan menyimpan checksum di header halaman. Saat halaman dibaca kembali, checksum dikomputasi ulang untuk memverifikasi integritas halaman. Nilai yang direkomendasikan adalah checksum.
Parameterization Nilai defaultnya adalah simple. Dengan parameterisasi sederhana, SQL Server dapat mengganti nilai literal dalam kueri dengan parameter. Microsoft memberikan panduan cara mengubah nilai ini dan menggunakannya dengan panduan paket.

Setelan database yang perlu dipertahankan

Untuk performa database SQL Server yang optimal, pertahankan nilai default dari setelan SQL Server berikut.

Setelan Nilai default yang akan dipertahankan
Auto Close False. Jika diaktifkan, setelan ini akan membuka dan menutup koneksi, serta mengosongkan prosedur setelah masing-masing terhubung. Setelan ini dapat menyebabkan penurunan performa dalam database yang sering diakses.
Auto Shrink False. Jika diaktifkan, setelan ini dapat menyebabkan fragmentasi database dan indeks, serta masalah performa lainnya. Beberapa di antaranya dibahas di blog SQL Server ini.
Date Correlation Optimization Enabled False. Jika diaktifkan, pengoptimal dapat menemukan dan mengoptimalkan hubungan antara tanggal di dua tabel terkait. Pelacakan dalam SQL Server dapat disertai dengan beberapa overhead performa.
Legacy Cardinality Estimation False. Dalam beberapa kasus, SQL Server tidak dapat menghitung kardinalitas secara akurat saat setelan ini diaktifkan.
Parameter Sniffing ON. Identifikasi parameter dari tabel database dapat membantu membuat rencana eksekusi untuk digunakan kembali. Jika tabel memiliki data yang didistribusikan secara tidak merata, rencana eksekusi yang dihasilkan dapat menyebabkan masalah performa. Dengan data tersebut, gunakan opsi lain dari Query Store, bukan ubah setelan ini.
Query Optimizer Fixes False. Jika diaktifkan, performa estimator kardinalitas SQL Server dapat terpengaruh. Jika Anda memilih untuk mengaktifkannya, uji untuk memastikan tidak adanya regresi kueri.
Auto Create Statistics True. Opsi ini memungkinkan SQL Server membuat statistik kolom tunggal yang dapat meningkatkan perkiraan kardinalitas pada paket kueri.
Auto Update Statistics True. Opsi ini memungkinkan SQL Server memperbarui statistik yang sudah tidak relevan menggunakan nilai minimum kompilasi ulang berdasarkan kardinalitas tabel.
Auto Update Statistics Asynchronously False. Jika diaktifkan, opsi ini akan mengarahkan pengoptimal kueri SQL agar menggunakan statistik yang sudah tidak berlaku untuk eksekusi kueri saat ini, sambil memperbarui statistik secara asinkron agar bermanfaat untuk workload mendatang.

Namun, jika Anda mengharapkan waktu respons yang dapat diprediksi pada kueri yang sering dijalankan atau jika aplikasi Anda sering mengalami waktu tunggu permintaan klien saat menunggu update statistik, pertimbangkan untuk mengaktifkan opsi ini dan menonaktifkan Auto Update Statistics.

Target Recovery Time (Seconds) 60. Setelan ini menetapkan batas atas waktu pemulihan database dengan lebih sering atau lebih jarang mengosongkan halaman kotor dari kumpulan buffer ke disk. Untuk workload yang sangat transaksional, nilai yang lebih rendah pada setelan ini dan IOPS penyimpanan yang mendekati nilai maksimum, dapat menyebabkan bottleneck performa.

Setelan flag trace

Flag trace di SQL Server digunakan untuk menetapkan karakteristik tertentu, mengubah perilaku database SQL Server, atau masalah debug SQL Server.

Beberapa flag trace SQL Server didukung di Cloud SQL, serta dapat ditetapkan menggunakan flag database. Berikut adalah setelan yang direkomendasikan.

Flag trace Direkomendasikan
1204 Yes, kecuali untuk server yang menghabiskan banyak workload dan menghasilkan banyak deadlock.

Menampilkan resource dan jenis kunci yang mengalami deadlock dan perintah yang saat ini terpengaruh.
1222 Yes, kecuali untuk server yang menghabiskan banyak workload dan menghasilkan banyak deadlock.
1224 No. Setelan ini dapat mengakibatkan penggunaan memori yang lebih besar dan menyebabkan tekanan memori pada database.
2528 No. Pemeriksaan paralel objek adalah setelan default dan direkomendasikan. Tingkat paralelisme otomatis dihitung oleh mesin database.
3205 No. Tape drive untuk pencadangan adalah fitur pada Cloud SQL untuk SQL Server.
3226 No, kecuali jika Anda sering memerlukan pencadangan, seperti pencadangan TLOG.
3625 No. Karena tidak memiliki akses administrator sistem, akun root mungkin tidak dapat melihat semua pesan error.
4199 No. Setelan ini memengaruhi estimator kardinalitas dan dapat menyebabkan regresi kueri.
4616 No. Batasan ini menurunkan keamanan pada peran aplikasi. Diperlukannya validasi berdasarkan persyaratan aplikasi.
7806 Yes. Jika server database menjadi tidak responsif, koneksi admin khusus (DAC) dapat menjadi satu-satunya cara untuk membuat koneksi pada diagnostik.

Langkah selanjutnya

Untuk informasi selengkapnya tentang praktik umum oleh mesin database, lihat: