Bagikan melalui

Dasar-dasar I/O SQL Server

  • Artikel

Berlaku untuk: SQL Server Azure SQL Managed Instance SQL Server di Azure VM

Tujuan utama database SQL Server adalah untuk menyimpan dan mengambil data, sehingga input/output disk intensif (I/O) adalah karakteristik inti dari Mesin Database. Karena operasi I/O disk dapat menggunakan banyak sumber daya dan membutuhkan waktu yang relatif lama untuk diselesaikan, SQL Server berfokus pada membuat I/O sangat efisien.

Subsistem penyimpanan untuk SQL Server disediakan dalam beberapa faktor bentuk, termasuk drive mekanis dan penyimpanan solid state. Artikel ini menyediakan detail tentang cara menggunakan prinsip penembolokan drive untuk meningkatkan I/O Mesin Database.

SQL Server mengharuskan sistem mendukung pengiriman terjamin ke media stabil seperti yang diuraikan di bawah Persyaratan Program Keandalan I/O SQL Server. Untuk informasi selengkapnya tentang persyaratan input dan output untuk Mesin Database SQL Server, lihat Persyaratan Input/Output Disk Mesin Database SQL Server (I/O).

Disk I/O

Manajer buffer hanya melakukan baca dan tulis ke database. Operasi file dan database lainnya seperti membuka, menutup, memperluas, dan menyusut dilakukan oleh manajer database dan komponen manajer file.

Operasi I/O disk oleh manajer buffer memiliki karakteristik berikut:

  • I/O biasanya dilakukan secara asinkron, yang memungkinkan utas panggilan untuk terus memproses saat operasi I/O berlangsung di latar belakang. Dalam beberapa keadaan (misalnya, I/O log yang tidak sejalan), I/Os sinkron dapat terjadi.

  • Semua I/Os dikeluarkan dalam utas panggilan kecuali opsi Afinitas I/O sedang digunakan. Opsi masker I/O afinitas mengikat I/O disk SQL Server ke subset CPU tertentu. Di lingkungan pemrosesan transaksional online (OLTP) SQL Server kelas atas, ekstensi ini dapat meningkatkan performa utas SQL Server yang mengeluarkan I/Os.

  • Beberapa I/Os halaman dicapai dengan I/O pengumpulan sebar, yang memungkinkan data ditransfer ke atau keluar dari area memori yang tidak bersebelahan. Ini berarti bahwa SQL Server dapat dengan cepat mengisi atau menghapus cache buffer sambil menghindari beberapa permintaan I/O fisik.

Permintaan I/O panjang

Manajer buffer melaporkan permintaan I/O apa pun yang beredar setidaknya selama 15 detik. Ini membantu administrator sistem membedakan antara masalah SQL Server dan masalah subsistem I/O. Pesan kesalahan MSSQLSERVER_833 dilaporkan dan muncul di log kesalahan SQL Server sebagai berikut:

SQL Server has encountered ## occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [##] in database [##] (#). The OS file handle is 0x00000. The offset of the latest long I/O is: 0x00000.

I/O panjang dapat berupa baca atau tulis; saat ini tidak ditunjukkan dalam pesan. Pesan I/O panjang adalah peringatan, bukan kesalahan. Mereka tidak menunjukkan masalah dengan SQL Server tetapi dengan sistem I/O yang mendasar. Pesan dilaporkan untuk membantu administrator sistem menemukan penyebab waktu respons SQL Server yang buruk lebih cepat, dan untuk membedakan masalah yang berada di luar kendali SQL Server. Dengan demikian, mereka tidak memerlukan tindakan apa pun, tetapi administrator sistem harus menyelidiki mengapa permintaan I/O membutuhkan waktu begitu lama, dan apakah waktunya dapat dibenarkan.

Penyebab permintaan I/O panjang

Pesan I/O panjang dapat menunjukkan bahwa I/O diblokir secara permanen dan tidak akan pernah selesai (dikenal sebagai I/O yang hilang), atau hanya belum selesai. Tidak dimungkinkan untuk mengetahui dari pesan skenario mana yang terjadi, meskipun I/O yang hilang sering menyebabkan batas waktu kait.

I/Os panjang sering menunjukkan beban kerja SQL Server yang terlalu intens untuk subsistem disk. Subsistem disk yang tidak memadai mungkin ditunjukkan ketika:

  • Beberapa pesan I/O panjang muncul di log kesalahan selama beban kerja SQL Server yang berat.
  • Penghitung Monitor Performa menunjukkan latensi disk panjang, antrean disk panjang, atau tidak ada waktu menganggur disk.

I/Os panjang juga dapat disebabkan oleh komponen di jalur I/O (misalnya, driver, pengontrol, atau firmware) terus menunda layanan permintaan I/O lama, demi melayani permintaan yang lebih baru. Ini dapat terjadi di lingkungan yang saling terhubung, seperti iSCSI dan jaringan saluran serat (baik karena kesalahan konfigurasi atau kegagalan jalur). Ini bisa sulit untuk diperkuat dengan alat Monitor Performa karena sebagian besar I/Os segera dilayankan. Permintaan I/O panjang dapat diperburuk oleh beban kerja yang melakukan I/O berurutan dalam jumlah besar, seperti pencadangan dan pemulihan, pemindaian tabel, pengurutan, pembuatan indeks, beban massal, dan nol file.

I/Os panjang terisolasi yang tidak muncul terkait dengan salah satu kondisi sebelumnya dapat disebabkan oleh masalah perangkat keras atau driver. Log peristiwa sistem mungkin berisi peristiwa terkait yang membantu mendiagnosis masalah.

Masalah performa I/O yang disebabkan oleh kueri atau driver filter yang tidak efisien

I/O lambat dapat disebabkan oleh kueri yang tidak ditulis secara efisien, atau tidak disetel dengan benar dengan indeks dan statistik. Faktor umum lain dalam latensi I/O adalah adanya antivirus atau program keamanan lainnya yang memindai file database. Perangkat lunak pemindaian ini mungkin meluas ke lapisan jaringan, yang menambahkan latensi jaringan, pada gilirannya secara tidak langsung memengaruhi latensi database. Meskipun skenario yang dijelaskan sekitar 15 detik I/O lebih umum dengan komponen perangkat keras, latensi I/O yang lebih kecil lebih sering diamati dengan kueri yang tidak optimal atau program antivirus yang salah dikonfigurasi.

Untuk informasi terperinci tentang cara mengatasi masalah ini, lihat Memecahkan masalah performa SQL Server lambat yang disebabkan oleh masalah I/O.

Untuk informasi tentang cara mengonfigurasi perlindungan antivirus di SQL Server, lihat Mengonfigurasi perangkat lunak antivirus untuk bekerja dengan SQL Server.

Menulis penembolokan di pengontrol penyimpanan

Transfer I/O yang dilakukan tanpa menggunakan cache dapat secara signifikan lebih lama dalam drive mekanis, karena laju putar hard drive, waktu mekanis yang diperlukan untuk memindahkan kepala drive, dan faktor pembatasan lainnya. Penginstalan SQL Server ditargetkan pada sistem yang menyediakan pengontrol penembolokan. Pengontrol ini menonaktifkan cache pada disk dan menyediakan cache media yang stabil untuk memenuhi persyaratan I/O SQL Server. Mereka menghindari masalah performa yang terkait dengan pencarian penyimpanan dan waktu tulis dengan menggunakan berbagai pengoptimalan pengontrol penembolokan.

Catatan

Beberapa vendor penyimpanan menggunakan memori persisten (PMEM) sebagai penyimpanan daripada cache, yang dapat meningkatkan performa keseluruhan. Untuk informasi selengkapnya, lihat Mengonfigurasi memori persisten (PMEM) untuk SQL Server di Windows dan Mengonfigurasi memori persisten (PMEM) untuk SQL Server di Linux.

Penggunaan pengontrol penyimpanan penembolokan tulis (juga disebut write-back caching) dapat meningkatkan performa SQL Server. Pengontrol penembolokan tulis dan subsistem penyimpanan aman untuk SQL Server, jika dirancang untuk digunakan dalam lingkungan sistem manajemen database transaksional (DBMS) penting data. Fitur desain ini harus mempertahankan data yang di-cache jika terjadi kegagalan sistem. Menggunakan catu daya eksternal yang tidak dapat diinterupsi (UPS) untuk mencapai hal ini umumnya tidak cukup, karena mode kegagalan yang tidak terkait dengan daya dapat terjadi.

Pengontrol penembolokan dan subsistem penyimpanan dapat aman digunakan oleh SQL Server. Sebagian besar platform server baru yang dibuat khusus yang menggabungkannya aman. Namun, Anda harus memeriksa dengan vendor perangkat keras Anda untuk memastikan bahwa subsistem penyimpanan diuji dan disetujui untuk digunakan di lingkungan sistem manajemen database hubungan transaksional (RDBMS) penting data.

Pengelogan write-ahead

Pernyataan modifikasi data SQL Server menghasilkan penulisan halaman logis. Aliran penulisan ini dapat digamrangkan sebagai dua tempat: log dan database itu sendiri. Untuk alasan performa, SQL Server menuangkan penulisan ke database melalui sistem buffer cache-nya sendiri. Penulisan ke log hanya ditangguhkan sesaat sampai COMMIT waktu. Cache tidak di-cache dengan cara yang sama seperti penulisan data. Karena penulisan log untuk halaman tertentu selalu mendahului penulisan data halaman, log terkadang disebut sebagai log write-ahead (WAL).

Protokol pengelogan write-ahead (WAL)

Istilah protokol adalah cara yang sangat baik untuk menggambarkan WAL. WAL yang digunakan oleh SQL Server dikenal sebagai ARIES (Algoritma untuk Semantik Eksploitasi Pemulihan dan Isolasi). Untuk informasi selengkapnya, lihat Mengelola pemulihan database yang dipercepat.

Ini adalah serangkaian langkah implementasi tertentu dan ditentukan yang diperlukan untuk memastikan bahwa data disimpan dan ditukar dengan benar dan dapat dipulihkan ke keadaan yang diketahui jika terjadi kegagalan. Sama seperti jaringan yang berisi protokol yang ditentukan untuk bertukar data secara konsisten dan terlindungi, wal juga menjelaskan protokol untuk melindungi data. Semua versi SQL Server membuka file log dan data menggunakan fungsi Win32 CreateFile . Anggota dwFlagsAndAttributes menyertakan FILE_FLAG_WRITE_THROUGH opsi saat dibuka oleh SQL Server.

FILE_FLAG_WRITE_THROUGH

SQL Server membuat file databasenya menggunakan FILE_FLAG_WRITE_THROUGH bendera . Opsi ini menginstruksikan sistem untuk menulis melalui cache perantara dan langsung masuk ke penyimpanan. Sistem masih dapat menyimpan operasi penulisan, tetapi tidak dapat dengan malas membersihkannya. Untuk informasi selengkapnya, lihat CreateFileA.

Opsi FILE_FLAG_WRITE_THROUGH memastikan bahwa ketika operasi tulis mengembalikan keberhasilan penyelesaian data disimpan dengan benar dalam penyimpanan yang stabil. Ini selaras dengan spesifikasi protokol Write Ahead Logging (WAL) untuk memastikan data. Banyak perangkat penyimpanan (NVMe, PCIe, SATA, ATA, SCSI, dan berbasis IDE) berisi cache onboard 512 KB, 1 MB, dan lebih besar. Cache penyimpanan biasanya mengandalkan kapasitor dan bukan solusi yang didukung baterai. Mekanisme penembolokan ini tidak dapat menjamin penulisan di seluruh siklus daya atau titik kegagalan serupa. Mereka hanya menjamin penyelesaian operasi penulisan sektor. Karena ukuran perangkat penyimpanan terus bertambah, cache menjadi lebih besar, dan dapat mengekspos data dalam jumlah yang lebih besar selama kegagalan.

Untuk informasi selengkapnya tentang dukungan FUA oleh distribusi Linux dan efeknya pada SQL Server, lihat Internal SQL Server Di Linux: Forced Unit Access (FUA).

Integritas transaksi dan pemulihan SQL Server

Integritas transaksional adalah salah satu konsep mendasar dari sistem database relasional. Transaksi dianggap sebagai unit pekerjaan atomik yang sepenuhnya diterapkan atau benar-benar digulung balik. Log transaksi write-ahead SQL Server adalah komponen penting dalam menerapkan integritas transaksi.

Setiap sistem database relasional juga harus berurusan dengan konsep yang terkait erat dengan integritas transaksional, yaitu pemulihan dari kegagalan sistem yang tidak diencana. Beberapa efek dunia nyata yang tidak ideal dapat menyebabkan kegagalan ini. Pada banyak sistem manajemen database, kegagalan sistem dapat mengakibatkan proses pemulihan manual yang panjang yang diarahkan manusia.

Sebaliknya, mekanisme pemulihan SQL Server bersifat otomatis dan beroperasi tanpa intervensi manusia. Misalnya, SQL Server dapat mendukung aplikasi produksi misi penting, dan mengalami kegagalan sistem karena fluktuasi daya sesaat. Setelah pemulihan daya, perangkat keras server akan dimulai ulang, perangkat lunak jaringan akan memuat dan menginisialisasi, dan SQL Server akan dimulai ulang. Saat diinisialisasi SQL Server, SQL Server secara otomatis menjalankan proses pemulihannya berdasarkan data dalam log transaksi. Seluruh proses ini terjadi tanpa campur tangan manusia. Setiap kali stasiun kerja klien dimulai ulang, pengguna akan menemukan semua data mereka ada, hingga transaksi terakhir yang mereka masukkan.

Integritas transaksi dan pemulihan otomatis di SQL Server merupakan kemampuan penghematan waktu dan tenaga kerja yang kuat. Jika pengontrol penembolokan tulis tidak dirancang dengan benar untuk digunakan dalam lingkungan DBMS transaksional penting data, pengontrol dapat membahayakan kemampuan SQL Server untuk memulihkan, sehingga merusak database. Ini dapat terjadi jika pengontrol mencegat penulisan log transaksi SQL Server dan buffer mereka dalam cache perangkat keras pada papan pengontrol, tetapi tidak mempertahankan halaman tertulis ini selama kegagalan sistem.

Menulis penembolokan dan pengontrol perangkat penyimpanan

Sebagian besar pengontrol penembolokan perangkat penyimpanan melakukan penembolokan tulis. Fungsi penembolokan tulis tidak selalu dapat dinonaktifkan.

Bahkan jika server menggunakan UPS, ini tidak menjamin keamanan penulisan cache. Banyak jenis kegagalan sistem dapat terjadi yang tidak diatasi UPS. Misalnya, kesalahan paritas memori, perangkap sistem operasi (OS), atau kesalahan perangkat keras yang menyebabkan reset sistem dapat menghasilkan gangguan sistem yang tidak terkendali. Kegagalan memori dalam cache tulis perangkat keras juga dapat mengakibatkan hilangnya informasi log penting.

Kemungkinan masalah lain yang terkait dengan pengontrol penulisan-penembolokan dapat terjadi pada pematian sistem. Tidak jarang siklus OS atau menghidupkan ulang sistem selama perubahan konfigurasi. Bahkan jika operator yang cermat mengikuti rekomendasi OS untuk menunggu sampai semua aktivitas penyimpanan berhenti sebelum memulai ulang sistem, penulisan cache masih dapat ada di pengontrol. Ctrl++AltDel Ketika kombinasi tombol ditekan, atau tombol reset perangkat keras ditekan, tulisan yang di-cache dapat dibuang, berpotensi merusak database.

Dimungkinkan untuk merancang cache tulis perangkat keras, yang memperhitungkan semua kemungkinan penyebab membuang data cache kotor, yang dengan demikian akan aman untuk digunakan oleh server database. Beberapa fitur desain ini akan mencakup mencegat sinyal bus RST untuk menghindari reset pengontrol penembolokan yang tidak terkontrol, pencadangan baterai on-board, dan memori mirrored atau error checking and correcting (ECC). Tanyakan kepada vendor perangkat keras Anda untuk memastikan bahwa cache tulis menyertakan ini dan fitur lain yang diperlukan untuk menghindari kehilangan data.

Menggunakan cache penyimpanan dengan SQL Server

Sistem database adalah yang pertama dan paling bertanggung jawab atas penyimpanan dan pengambilan data yang akurat, bahkan jika terjadi kegagalan sistem yang tidak terduga.

Sistem harus menjamin atomitas dan durabilitas transaksi, sambil memperhitungkan eksekusi saat ini, beberapa transaksi, dan berbagai titik kegagalan. Ini sering disebut sebagai properti ACID (Atomitas, Konsistensi, Isolasi, dan Durabilitas).

Bagian ini membahas implikasi cache penyimpanan. Disarankan agar Anda membaca artikel berikut di Pangkalan Pengetahuan Microsoft untuk klarifikasi lebih lanjut tentang penembolokan dan diskusi mode kegagalan alternatif:

Dokumen berikut ini juga direkomendasikan:

Kedua dokumen ini berlaku untuk semua versi SQL Server yang saat ini didukung.

Solusi penembolokan yang didukung baterai

Sistem pengontrol penembolokan yang ditingkatkan menonaktifkan cache pada disk dan menyediakan solusi penembolokan yang didukung baterai fungsional. Cache ini dapat mempertahankan data di cache selama beberapa hari dan bahkan memungkinkan kartu penembolokan ditempatkan di komputer kedua. Ketika daya dipulihkan dengan benar, data yang tidak ditulis benar-benar dihapus sebelum akses data lebih lanjut diizinkan. Banyak dari mereka memungkinkan persentase cache baca versus tulis ditetapkan untuk performa yang optimal. Beberapa berisi area penyimpanan memori besar. Beberapa vendor perangkat keras menyediakan sistem penembolokan drive yang didukung baterai kelas atas dengan beberapa gigabyte cache. Ini dapat secara signifikan meningkatkan performa database. Menggunakan solusi penembolokan yang didukung baterai memberikan durabilitas dan konsistensi data yang diharapkan SQL Server.

Implementasi subsistem penyimpanan

Ada banyak jenis implementasi subsistem. RAID (array redundan disk independen) dan SAN (jaringan area penyimpanan) adalah dua contoh jenis implementasi subsistem ini. Sistem ini biasanya dibangun dengan drive berbasis SCSI. Ada beberapa alasan untuk ini. Bagian berikut ini secara umum menjelaskan pertimbangan penyimpanan tingkat tinggi.

SCSI, SAS, dan NVMe

Perangkat penyimpanan SCSI, SAS, dan NVMe:

  • Biasanya diproduksi untuk penggunaan tugas berat.
  • Biasanya ditargetkan pada implementasi berbasis server multiuser.
  • Biasanya memiliki rata-rata yang lebih baik untuk tingkat kegagalan daripada implementasi lainnya.
  • Mengandung heuristik canggih untuk membantu memprediksi kegagalan yang akan datang.

Non-SCSI

Implementasi drive lainnya, seperti IDE, ATA, dan SATA:

  • Biasanya diproduksi untuk penggunaan tugas ringan dan sedang.
  • Biasanya ditargetkan pada aplikasi berbasis pengguna tunggal.

Pengontrol berbasis desktop non-SCSI memerlukan lebih banyak bandwidth prosesor utama (CPU), dan sering dibatasi oleh satu perintah aktif. Misalnya, ketika drive non-SCSI menyesuaikan blok buruk, drive mengharuskan perintah host menunggu. Bus ATA menyajikan contoh lain: bus ATA mendukung dua perangkat, tetapi hanya satu perintah yang dapat aktif. Ini membuat satu drive menganggur sementara layanan drive lainnya perintah tertunda. Sistem RAID yang dibangun di atas teknologi desktop semuanya dapat mengalami gejala ini dan sangat dipengaruhi oleh responden terlambat. Kecuali sistem ini menggunakan desain tingkat lanjut, performanya tidak seefisien performa sistem berbasis SCSI.

Pertimbangan penyimpanan

Ada situasi di mana drive atau array berbasis desktop adalah solusi biaya rendah yang sesuai. Misalnya, jika Anda menyiapkan database baca-saja untuk pelaporan, Anda seharusnya tidak menemukan banyak faktor performa database OLTP saat penembolokan drive dinonaktifkan.

Ukuran perangkat penyimpanan terus meningkat. Biaya rendah, drive kapasitas tinggi dapat menarik. Tetapi ketika Anda mengonfigurasi drive untuk SQL Server dan kebutuhan waktu respons bisnis Anda, Anda harus mempertimbangkan masalah berikut dengan hati-hati:

  • Desain jalur akses
  • Persyaratan untuk menonaktifkan cache pada disk

Hard drive mekanis

Penggerak mekanis menggunakan piring magnetik berputar untuk menyimpan data. Mereka tersedia dalam beberapa kapasitas dan faktor bentuk, seperti IDE, SATA, SCSI, dan Serial Attached SCSI (SAS). Beberapa drive SATA termasuk konstruksi prediksi kegagalan. Drive SCSI dirancang untuk siklus tugas yang lebih berat dan penurunan tingkat kegagalan.

Penembolokan drive harus dinonaktifkan untuk menggunakan drive dengan SQL Server. Secara default, cache drive diaktifkan. Di Windows Server, gunakan tab Perangkat Keras Properti>Disk untuk mengakses tab Kebijakan Properti>untuk mengontrol pengaturan cache drive.

Catatan

Beberapa drive tidak mematuhi pengaturan ini. Drive ini memerlukan utilitas produsen tertentu untuk menonaktifkan cache.

Sistem berbasis IDE dan ATA dapat menunda perintah host ketika mereka melakukan aktivitas seperti penyesuaian blok yang buruk. Hal ini dapat menyebabkan periode aktivitas I/O yang terhenti.

Manfaat SAS termasuk antrean lanjutan hingga 256 tingkat, dan kepala antrean dan antrean di luar urutan. Backplane SAS dirancang dengan cara yang memungkinkan penggunaan drive SAS dan SATA dalam sistem yang sama.

Penginstalan SQL Server Anda tergantung pada kemampuan pengontrol untuk menonaktifkan cache pada disk dan untuk menyediakan cache I/O yang stabil. Menulis data secara tidak berurutan ke berbagai drive bukanlah halangan untuk SQL Server selama pengontrol menyediakan kemampuan penembolokan media yang stabil yang benar. Kompleksitas desain pengontrol meningkat dengan teknik keamanan data tingkat lanjut seperti pencerminan.

Penyimpanan solid state

Penyimpanan solid-state memiliki keunggulan dibandingkan hard drive mekanis (berputar), tetapi rentan terhadap banyak pola kegagalan yang sama dengan media berputar. Penyimpanan solid-state terhubung ke server Anda menggunakan berbagai antarmuka, termasuk NVM Express (NVMe), PCI Express (PCIe), dan SATA. Perlakukan media solid-state seperti yang Akan Anda putar media, dan pastikan bahwa perlindungan yang sesuai diberlakukan untuk kegagalan daya, seperti pengontrol penembolokan yang didukung baterai.

Masalah umum yang disebabkan oleh kesalahan daya meliputi:

  • Kerusakan bit: Rekaman menunjukkan kesalahan bit acak.
  • Penulisan terbang: Catatan yang terbentuk dengan baik berakhir di tempat yang salah.
  • Penulisan shorn: Operasi sebagian dilakukan pada tingkat di bawah ukuran sektor yang diharapkan.
  • Kerusakan metadata: Metadata di FTL rusak.
  • Perangkat tidak responsif: Perangkat tidak berfungsi sama sekali, atau sebagian besar tidak berfungsi.
  • Tidak dapat diserialisasi: Status akhir penyimpanan tidak dihasilkan dari urutan operasi yang dapat diserialisasikan.

512e

Sebagian besar penyimpanan solid-state melaporkan ukuran sektor 512 byte tetapi menggunakan halaman 4 KB di dalam blok penghapusan 1-MB. Menggunakan sektor selaras 512 byte untuk perangkat log SQL Server dapat menghasilkan lebih banyak aktivitas baca/ubah/tulis (RMW), yang dapat berkontribusi pada performa dan keausan drive yang lebih lambat.

Rekomendasi: Pastikan pengontrol penembolokan mengetahui ukuran halaman perangkat penyimpanan yang benar, dan dapat menyelaraskan penulisan fisik dengan infrastruktur penyimpanan solid-state dengan benar.

0xFFFFFFFF

Drive yang baru diformat biasanya menyimpan semua nol. Blok yang dihapus dari perangkat solid-state adalah semua 1, membuat baca mentah dari blok yang dihapus semua 0xFFs. Namun, tidak biasa bagi pengguna untuk membaca blok yang dihapus selama operasi I/O normal.

Stempel pola

Teknik yang kami gunakan di masa lalu adalah menulis pola yang diketahui ke seluruh drive. Kemudian saat kita menjalankan aktivitas database terhadap drive yang sama, kita dapat mendeteksi perilaku yang salah (baca kedaluwarsa / hilang tulis / baca offset yang salah / dll.) ketika pola tiba-tiba muncul.

Teknik ini tidak berfungsi dengan baik pada penyimpanan solid-state. Aktivitas penghapusan dan RMW untuk penulisan menghancurkan pola. Aktivitas pengumpulan sampah penyimpanan solid-state (GC), tingkat keausan, blok daftar proporsional/set-aside dan pengoptimalan lainnya cenderung menyebabkan penulisan memperoleh lokasi fisik yang berbeda, tidak seperti penggunaan kembali sektor media yang berputar.

Firmware

Firmware yang digunakan dalam penyimpanan solid-state cenderung kompleks jika dibandingkan dengan rekan-rekan media yang berputar. Banyak drive menggunakan beberapa inti pemrosesan untuk menangani permintaan masuk dan aktivitas pengumpulan sampah. Pastikan Anda selalu memperbarui firmware perangkat solid-state Anda untuk menghindari masalah yang diketahui.

Membaca kerusakan data dan tingkat keausan

Pendekatan pengumpulan sampah umum (GC) untuk penyimpanan solid-state membantu mencegah kerusakan data baca berulang. Ketika membaca sel yang sama berulang kali, ada kemungkinan aktivitas elektron dapat bocor dan menyebabkan kerusakan pada sel-sel tetangga. Penyimpanan solid-state melindungi data dengan berbagai tingkat kode koreksi kesalahan (ECC) dan mekanisme lainnya.

Salah satu mekanisme tersebut berkaitan dengan perataan keausan. Penyimpanan solid-state melacak aktivitas baca dan tulis pada perangkat penyimpanan. Pengumpulan sampah dapat menentukan hot spot atau lokasi yang mengenakan lebih cepat daripada lokasi lain. Misalnya, GC menentukan bahwa blok telah dalam status baca-saja untuk jangka waktu tertentu dan perlu dipindahkan. Gerakan ini umumnya ke blok dengan lebih banyak keausan, sehingga blok asli dapat digunakan untuk menulis. Ini membantu menyeimbangkan keausan pada drive, tetapi memindahkan data baca-saja ke lokasi yang memiliki lebih banyak keausan dan secara matematis meningkatkan peluang kegagalan, bahkan jika sedikit.

Efek samping lain dari tingkat keausan dapat terjadi dengan SQL Server. Misalkan Anda menjalankan DBCC CHECKDB, dan melaporkan kesalahan. Jika Anda menjalankannya untuk kedua kalinya, ada kemungkinan kecil yang DBCC CHECKDB melaporkan kesalahan tambahan atau pola kesalahan yang berbeda, karena aktivitas GC penyimpanan solid-state mungkin membuat perubahan di antara DBCC CHECKDB eksekusi.

Kesalahan OS 665 dan defragmentasi

Media berputar perlu menjaga blok di dekat satu sama lain untuk mengurangi pergerakan kepala drive dan meningkatkan performa. Penyimpanan solid-state tidak memiliki kepala fisik, yang menghilangkan waktu pencarian. Banyak perangkat solid-state dirancang untuk memungkinkan operasi paralel pada blok yang berbeda secara paralel. Ini berarti bahwa defragmentasi media solid-state tidak perlu. Aktivitas serial adalah pola I/O terbaik untuk memaksimalkan throughput I/O pada perangkat penyimpanan solid-state.

Catatan

Manfaat penyimpanan solid-state dari fitur trim , perintah tingkat sistem operasi (OS) yang menghapus blok yang dianggap tidak lagi digunakan. Di Windows, gunakan alat Optimize Drives untuk mengatur jadwal mingguan untuk mengoptimalkan drive.

Rekomendasi:

  • Gunakan pengontrol yang sesuai dan didukung baterai yang dirancang untuk mengoptimalkan aktivitas tulis. Ini dapat meningkatkan performa, mengurangi tingkat keausan drive dan fragmentasi fisik.

  • Pertimbangkan untuk menggunakan sistem file ReFS untuk menghindari batasan atribut NTFS.

  • Pastikan ukuran pertumbuhan file berukuran tepat.

Untuk informasi selengkapnya tentang pemecahan masalah kesalahan OS 665 karena berkaitan dengan fragmentasi, lihat Kesalahan OS 665 dan 1450 dilaporkan untuk file SQL Server.

Kompresi

Selama drive mempertahankan niat media yang stabil, kompresi dapat memanjangkan umur drive dan mungkin secara positif memengaruhi performa. Namun, beberapa firmware mungkin sudah mengompresi data secara kasat mata. Ingatlah untuk menguji skenario penyimpanan baru sebelum menyebarkannya ke lingkungan produksi Anda.

Ringkasan

  • Pertahankan prosedur dan proses pencadangan dan pemulihan bencana yang tepat.
  • Selalu perbarui firmware Anda.
  • Dengarkan lebih dekat panduan manufaktur perangkat keras Anda.

Pertimbangan cache dan SQLIOSim

Untuk mengamankan data Anda sepenuhnya, Anda harus memastikan bahwa semua penembolokan data ditangani dengan benar. Dalam banyak situasi, ini berarti Anda harus menonaktifkan penembolokan tulis drive.

Catatan

Pastikan bahwa mekanisme penembolokan alternatif dapat menangani beberapa jenis kegagalan dengan benar.

Microsoft melakukan pengujian pada beberapa drive SCSI dan IDE menggunakan utilitas SQLIOSim . Utilitas ini mensimulasikan aktivitas baca/tulis asinkron berat ke perangkat data dan perangkat log yang disimulasikan. Untuk informasi dan detail selengkapnya tentang SQLIOSim, lihat Menggunakan utilitas SQLIOSim untuk mensimulasikan aktivitas SQL Server pada subsistem disk.

Banyak produsen PC memesan drive dengan cache tulis dinonaktifkan. Namun, pengujian menunjukkan bahwa ini mungkin tidak selalu terjadi, jadi Anda harus selalu mengujinya sepenuhnya. Jika Anda memiliki pertanyaan tentang status penembolokan perangkat penyimpanan Anda, hubungi produsen dan dapatkan utilitas atau pengaturan jumper yang sesuai untuk menonaktifkan operasi penembolokan tulis.

SQL Server memerlukan sistem untuk mendukung pengiriman terjamin ke media yang stabil, seperti yang diuraikan di bawah Persyaratan Program Keandalan I/O SQL Server. Untuk informasi selengkapnya tentang persyaratan input dan output untuk Mesin Database SQL Server, lihat Persyaratan Input/Output Disk Mesin Database SQL Server (I/O).

Konten terkait