ApsaraDB RDS：Masalah ruang disk penuh RDS SQL Server

Analisis

Total penyimpanan data, yang sama dengan total ukuran file data, terdiri dari penyimpanan data yang dialokasikan dan penyimpanan data yang belum dialokasikan:

• Penyimpanan data yang dialokasikan mencakup penyimpanan data yang digunakan dan yang tidak digunakan. Penyimpanan data yang tidak digunakan hanya dapat dialokasikan ke catatan baru di tabel atau indeks yang sama. Penyimpanan ini tidak dapat langsung dialokasikan ke objek database lainnya.

• Penyimpanan data yang belum dialokasikan terdiri dari ekstent yang belum dialokasikan. Setiap ekstent menyediakan penyimpanan kontigu sebesar 64 KB. Penyimpanan ini tidak terkait dengan objek database. Anda dapat mengecilkan file data untuk melepaskan penyimpanan data yang belum dialokasikan.

Dalam kebanyakan kasus, jika jumlah data Anda terus bertambah, penyimpanan data yang belum dialokasikan akan kecil. Dalam situasi ini, Anda tidak dapat mereklaim sejumlah besar penyimpanan data dengan mengecilkan file data. Sebelum mengecilkan file data, kami sarankan Anda mengoptimalkan dan mereklaim penyimpanan data yang telah dialokasikan.

Reklaim penyimpanan data

Anda dapat menggunakan salah satu metode berikut untuk mereklaim penyimpanan data:

• Arsipkan file data

  Hapus file data historis yang jarang diperiksa, migrasikan file tersebut ke instance RDS lain, atau arsipkan file tersebut. Ini mengurangi jumlah data yang disimpan di instance RDS Anda.

  Metode ini secara efektif mengurangi peningkatan konsumsi penyimpanan data. Namun, metode ini memiliki persyaratan untuk struktur objek database dan logika aplikasi Anda. Metode ini juga memerlukan kerja sama dengan desainer dan pengembang aplikasi.

• Kompres file data

  Jika instance RDS Anda menjalankan SQL Server 2016 atau lebih baru, atau SQL Server Enterprise Edition sebelum SQL Server 2016, fitur kompresi data tersedia. Fitur ini mendukung kompresi baris dan kompresi halaman. Anda dapat mengaktifkan fitur ini pada tabel individu, indeks, atau partisi. Untuk informasi lebih lanjut, lihat Kompresi Data.

  Rasio kompresi data berkisar antara 10% hingga 90% dan bervariasi berdasarkan skema, tipe data kolom, dan distribusi nilai numerik. SQL Server menyediakan prosedur tersimpan khusus sp_estimate_data_compression_savings yang dapat membantu Anda mengevaluasi berapa banyak ruang penyimpanan data yang dapat dihemat dengan mengaktifkan kompresi pada tabel atau indeks tertentu.

  Catatan

  • Untuk memodifikasi pengaturan opsi kompresi tabel atau indeks, Anda harus menjalankan operasi bahasa definisi data (DDL). Jika Anda menjalankan operasi ini pada tabel besar, tabel-tabel tersebut akan terkunci untuk waktu yang lama. Ini dapat mengganggu beban kerja Anda. Kami sarankan Anda memodifikasi pengaturan opsi kompresi selama jam-jam non-puncak.

  • Instance RDS SQL Server Enterprise dapat mengatur parameter ONLINE ke ON, dan kemudian melakukan operasi modifikasi dengan dampak minimal terhadap operasi bisnis normal.

  • Kompresi data meningkatkan overhead CPU. Evaluasi kelayakan kompresi data pada instance RDS Anda berdasarkan kebutuhan bisnis Anda. Kami sarankan Anda mengaktifkan fitur kompresi data hanya pada tabel besar.

• Defragmentasi indeks

  Jika tingkat fragmentasi dalam indeks tinggi, data dasar indeks mengonsumsi jumlah penyimpanan yang tidak normal. Dalam kasus ini, Anda dapat mendefragmentasi indeks untuk mengurangi jumlah penyimpanan data yang digunakan.

  Lihat Tingkat Fragmentasi dalam Indeks: Masuk ke Konsol ApsaraDB RDS dan pilih Autonomy Services > Performance Optimization. Kemudian, klik tab Index Usage. Pada tab ini, Anda dapat melihat fragmentasi indeks di berbagai tabel. Selain itu, Anda dapat melihat saran yang diajukan oleh layanan otonomi untuk membangun ulang atau mengorganisir ulang indeks.

  Catatan

  • Tingkat fragmentasi dalam indeks mewakili persentase halaman yang urutan logikanya tidak sesuai dengan urutan fisik di dalam indeks. Persentase ini berbeda dari persentase ruang penyimpanan kosong di halaman indeks. Dalam kondisi normal, indeks dengan tingkat fragmentasi tinggi kemungkinan besar akan didedefragmentasi untuk mereklaim ruang penyimpanan.

  • Jika Anda ingin menganalisis rata-rata persentase ruang penyimpanan kosong per halaman dalam indeks, Anda dapat menanyakan tampilan sistem sys.dm_db_index_physical_stats dalam mode SAMPLED atau DETAILED. Kemudian, Anda dapat melihat nilai-nilai di kolom avg_page_space_used_in_percent dari hasil yang dikembalikan. Untuk informasi lebih lanjut, lihat sys.dm_db_index_physical_stats (Transact-SQL). Sistem membaca banyak halaman indeks selama query. Jika Anda mendefragmentasi indeks selama query, kinerja instance RDS Anda mungkin menurun. Kami sarankan Anda mendefragmentasi indeks selama jam-jam non-puncak.

  • Bangun Ulang Indeks

    Metode ini memberikan hasil optimasi yang lebih baik dan efisiensi eksekusi yang lebih tinggi untuk tingkat fragmentasi tinggi. Secara default, tabel terkunci selama eksekusi. Di Edisi Enterprise, Anda dapat mengatur parameter ONLINE ke ON untuk menghindari penguncian tabel jangka panjang.

    Penting

    Untuk indeks besar, operasi pembangunan ulang dapat menyebabkan peningkatan signifikan dalam ruang penyimpanan database dan ukuran log dalam waktu singkat. Biasanya, sebelum melakukan operasi pembangunan ulang indeks, instance RDS Anda perlu menyediakan setidaknya dua kali ukuran indeks yang dibangun ulang sebagai ruang yang tersedia. Oleh karena itu, pastikan bahwa instance Anda memiliki ruang penyimpanan yang cukup tersedia.

    Lihat Ruang Penyimpanan Instance RDS: Buka halaman Basic Information halaman detail instance RDS. Di bagian Instance Resources, lihat ukuran total ruang penyimpanan dan ukuran ruang penyimpanan yang digunakan dari instance.

    ALTER INDEX <IX_YourIndexName> ON <YourTableName> REBUILD WITH (ONLINE = ON);

    Setelah perintah dieksekusi, sistem akan secara asinkron mengumpulkan kembali data di latar belakang, yang membutuhkan waktu. Anda dapat mengklik tombol Recollect untuk mengumpulkan data terbaru secara manual, dan setelah pengumpulan data selesai, klik Export Script untuk mengunduhnya secara lokal untuk memastikan status reklaim indeks.

    

  • Organisasi Ulang Indeks

    Metode ini cocok jika tingkat fragmentasi rendah. Namun, efektivitas optimasi tidak sebaik metode pembangunan ulang indeks.

Kecilkan file data

Jika penyimpanan yang tersedia masih tidak mencukupi setelah Anda mencoba semua solusi yang disarankan, Anda dapat menggunakan salah satu metode berikut untuk melepaskan penyimpanan data:

• Metode 1: Kecilkan file data dalam batch. Kami sarankan Anda mengecilkan 5 GB file data sekaligus. Contoh kode:

  DECLARE @dbName NVARCHAR(128) = 'YourDatabaseName'  -- Nama database
  DECLARE @fileName NVARCHAR(128)  -- Nama file data
  DECLARE @targetSize INT = 1024   -- Ukuran target (MB)
  DECLARE @shrinkSize INT = 5120   -- Ukuran file data yang Anda kecilkan sekaligus (MB), kami sarankan 5GB sekaligus
  DECLARE @currentSize INT         -- Ukuran saat ini
  DECLARE @sql NVARCHAR(500)       
  DECLARE @waitTime INT = 10      -- Waktu tunggu setelah setiap operasi pengecilan dalam detik
  
  -- Dapatkan nama file data
  SELECT @fileName = name
  FROM sys.master_files
  WHERE database_id = DB_ID(@dbName)
  AND type_desc = 'ROWS'
  
  -- Loop pengecilan
  WHILE 1 = 1
  BEGIN
      -- Dapatkan ukuran file saat ini
      SELECT @currentSize = size/128
      FROM sys.database_files
      WHERE name = @fileName
      
      -- Keluar jika ukuran target tercapai
      IF @currentSize <= @targetSize
      BEGIN
          PRINT 'Pengecilan selesai, ukuran saat ini: ' + CAST(@currentSize AS VARCHAR(20)) + 'MB'
          BREAK
      END
      
      -- Hitung ukuran setelah operasi pengecilan ini
      DECLARE @newSize INT = @currentSize - @shrinkSize
      IF @newSize < @targetSize
          SET @newSize = @targetSize
          
      -- Jalankan operasi pengecilan
      SET @sql = 'DBCC SHRINKFILE (N''' + @fileName + ''', ' + CAST(@newSize AS VARCHAR(20)) + ')'
      PRINT 'Menjalankan pengecilan: ' + @sql
      EXEC (@sql)
      
      -- Tunggu beberapa saat sebelum melanjutkan
      PRINT 'Menunggu ' + CAST(@waitTime AS VARCHAR(10)) + ' detik sebelum melanjutkan...'
      WAITFOR DELAY '00:05:00'
  END

• Metode 2: Jalankan perintah DBCC SHRINKFILE untuk mengecilkan file data individual dan melepaskan penyimpanan data yang belum dialokasikan ke sistem operasi. Untuk informasi lebih lanjut, lihat Kecilkan Database dan DBCC SHRINKFILE (Transact-SQL).

  DBCC SHRINKFILE(<File ID>, <Ukuran file yang diharapkan setelah pengecilan dalam MB>)

  Perluas untuk Melihat Contoh Kode

  Pada contoh yang ditunjukkan di atas, ukuran sebuah ekstent adalah 64 KB. Total ukuran file data adalah (1673344 x 64)/1024 = 104584 MB, dan ruang yang dialokasikan adalah (1313432 x 64)/1024 = 82089.5 MB, yang berarti bahwa setelah kompresi, total ukuran file data tidak bisa kurang dari 82089.5 MB. Oleh karena itu, untuk mengurangi total ukuran file data ini menjadi 90000 MB, Anda dapat menjalankan perintah berikut:

  DBCC SHRINKFILE(1, 90000)

FAQ

Lihat penggunaan penyimpanan log

Pengambilalihan kembali penyimpanan log relatif sederhana. Anda dapat menggunakan perintah DBCC SQLPERF(LOGSPACE) atau layanan otonomi untuk melihat persentase penggunaan penyimpanan log dalam file log database. Jika persentase penyimpanan yang digunakan tinggi, memperkecil file log hampir tidak akan berpengaruh. Anda dapat menanyakan Tampilan sistem sys.databases dan memeriksa informasi keluaran di kolom log_reuse_wait dan log_reuse_wait_desc untuk menentukan alasan mengapa ruang tidak dapat diambil kembali.

Perkecil log transaksi

Setelah operasi pemampatan selesai, Anda dapat pergi ke halaman Monitoring And Alerts dari instance RDS Anda untuk melihat penggunaan penyimpanan log terbaru.

Analisis

Penyimpanan file sementara adalah jumlah penyimpanan yang digunakan oleh database sistem tempdb. Database sistem tempdb hanya menggunakan model pemulihan SIMPLE. Dalam kondisi normal, ukuran total file log dalam database sistem tempdb kecil. Namun, ukuran total file data dalam database sistem tempdb dapat meningkat secara signifikan dalam waktu singkat. Sebagai contoh, jika Anda membuat banyak tabel sementara, menggabungkan tabel besar, atau mengurutkan data, ukuran total file data dalam database sistem tempdb bertambah.

Solusi

• Cegah peningkatan konsumsi penyimpanan di tingkat aplikasi. Sebagai contoh, kurangi tabel sementara yang tidak perlu, kurangi kueri yang memerlukan penggabungan tabel besar, dan jangan jalankan transaksi besar.

• Mulai ulang instance RDS Anda selama jam sepi. Setelah dimulai ulang, jumlah penyimpanan yang digunakan oleh database sistem tempdb berkurang menjadi ukuran saat instance dibuat.

Analisis

Penyimpanan file lainnya mengacu pada ruang yang digunakan oleh sqlserver.other_size, mastersize, modelsize, msdbsize, dan file serupa lainnya. Dalam kebanyakan kasus, file-file ini berukuran kecil. Namun, file-file ini dapat mengonsumsi sejumlah besar ruang penyimpanan dalam skenario berikut:

• Banyak file errorlog ada, dan ukuran file log kesalahan telah bertambah menjadi beberapa GB atau bahkan lebih besar.

• File dump memori dihasilkan ketika terjadi pengecualian parah.

Solusi

1. Anda dapat pergi ke halaman Monitoring And Alerts dari instance RDS Anda dan klik tab Standard Monitoring untuk melihat ruang penyimpanan yang digunakan oleh file-file ini. Untuk informasi lebih lanjut tentang metrik, lihat Lihat Pemantauan Standar.

   

2. Jika errorlog mengonsumsi banyak ruang penyimpanan, Anda dapat membersihkan log kesalahan di halaman Log Management. Untuk informasi lebih lanjut, lihat Kelola Log.

   Catatan

   Jika file lain (seperti sqlserver.other_size) menggunakan terlalu banyak ruang, silakan hubungi helpdesk. Mereka akan membantu Anda mengidentifikasi penyebab dan menyelesaikan masalah tersebut.