Apakah ada manfaat untuk mendefragmentasi indeks SQL di lingkungan SAN?

16

Server SQL kami hidup di SAN. Ini berisi puluhan database OLTP, beberapa dengan beberapa tabel yang berisi lebih dari 1 juta catatan.

Kami telah menjalankan skrip pemeliharaan indeks Ola Hallengren setiap minggu, dan itu berjalan selama beberapa jam setiap kali. Berdasarkan ambang fragmentasi, skrip akan mengatur ulang atau mengindeks ulang indeks. Kami telah mengamati bahwa selama pengindeksan ulang, file log menjadi besar yang menyebabkan konsumsi bandwidth yang berlebihan selama pengiriman log.

Kemudian muncul artikel dari Brent Ozar di mana ia mengatakan untuk berhenti mengkhawatirkan indeks SQL :

Hard drive Anda dibagikan dengan server lain yang juga membuat permintaan drive pada saat yang sama, sehingga drive akan selalu melompati tempat untuk mendapatkan data. Mendefrag indeks Anda hanyalah pekerjaan sibuk yang tidak berarti.

Menelusuri pertanyaan ini mengarah ke beragam pendapat, sebagian besar didukung dengan argumen yang tampaknya terlalu singkat atau lemah. Rencana sementara kami adalah menyesuaikan ambang fragmentasi dalam skrip pemeliharaan kami sehingga mengatur lebih sering daripada pengindeksan ulang.

Apa putusan akhir? Apakah bermanfaat untuk men-defrag indeks SQL pada SAN mengingat beban yang terkait dengan menjalankan pekerjaan pemeliharaan mingguan?

sql-server sql-server-2008-r2 index database-recommendation san dev_etter
sumber

Jawaban:

10

Strategi defragmentasi membantu meningkatkan kecepatan pemindaian ke / dari disk .

Berbagai macam pendapat adalah karena strategi defragmentasi ideal lingkungan harus bergantung pada banyak faktor yang berbeda. Ada juga beberapa lapisan potensial fragmentasi dalam permainan.

Mengatakan bahwa basis data Anda disimpan pada SAN tidak cukup informasi. Sebagai contoh:

  • Apakah file database disimpan pada grup RAID fisik yang terpisah atau grup RAID yang sama? Proses lain apa yang aktif pada perangkat yang sama? Apakah file cadangan Anda juga berakhir di sana? Anda mungkin harus bertanya kepada admin SAN Anda untuk informasi ini, karena tidak selalu transparan.

  • Apa pola akses untuk database? OLTP pada umumnya adalah akses acak, tetapi terkadang suatu aplikasi senang memindai tabel dan Anda tidak dapat mengubah perilakunya (aplikasi ISV). Apakah aplikasi itu sebagian besar dibaca, sebagian besar tulis, atau ada di antara keduanya?

  • Ada SLA kinerja yang dimainkan selama periode pemulihan / kegagalan ?

Pos Brent mengasumsikan ada satu kumpulan penyimpanan raksasa dan semuanya berbagi. Ini berarti disk fisik jarang menganggur, dan karenanya sebagian besar akses adalah acak. Jika itu adalah situasi Anda, maka saran itu berlaku, dan saya setuju dengan itu sebagian besar. Meskipun jenis strategi ini jauh lebih mudah untuk dikelola, itu tidak selalu (a) apa yang Anda miliki di lingkungan Anda, atau (b) apa solusi terbaik untuk lingkungan Anda.

Jika pemeliharaan indeks memberatkan, pertimbangkan untuk melakukannya dengan kurang agresif, dan / atau amortisasi biaya selama seminggu (mis. Jalankan pemeliharaan ringan sekali / hari, bukan pemeliharaan berat sekali / minggu).

Anda juga dapat mengaktifkan SortInTempdbopsi untuk berpotensi mengurangi jumlah logging yang terjadi di database pengguna.

Jon Seigel
sumber
Wow, jawaban menyeluruh. Mungkin perlu waktu bagi saya untuk melakukan semua penelitian, tetapi saya tidak ragu bahwa Anda memimpin saya di jalur yang benar. Strategi kami saat ini sebenarnya untuk menjalankan pemeliharaan kurang agresif dari kedua membangun kembali dan sudut pandang reorg, saya pikir saya salah menyatakan bahwa dalam pertanyaan. Dari sana saya akan melakukan penelitian lebih lanjut ke faktor-faktor yang Anda sebutkan.
dev_etter
1
@dev_etter: Saya hanya mencantumkan beberapa faktor; masih banyak lagi. Poin utamanya adalah kalimat pertama. Jika Anda mengingatnya saat memikirkan lingkungan Anda, itu akan mengarahkan keputusan Anda dengan benar. Semuanya bermula dari itu. (Juga, semua ini mengasumsikan tidak ada SSD yang terlibat.)
Jon Seigel
FWIW, saya telah mengabaikan sesuatu sepenuhnya - skrip aktual dalam langkah pekerjaan (bukan sumber) dikonfigurasi untuk mengatasi setiap indeks yang memiliki persentase fragmentasi minimum 1. Saya menabraknya hingga 15 dan juga menabrak ambang batas pembangunan kembali dari 30 ke 35. Pekerjaan sekarang berjalan dalam sedikit lebih dari 3 jam daripada 8. Saran Anda untuk menjadi kurang agresif itu benar. Kesalahan saya terletak pada kenyataan bahwa saya pikir pekerjaan itu sudah dilaksanakan menjadi kurang agresif. Pendekatan ini mungkin yang terbaik untuk kita, masih menyentuh dan pergi tetapi sudah meringankan rasa sakit.
dev_etter
@ JonSeigel Saya sangat setuju dengan jawaban ini. Dalam perjalanan saya, saya melihat sebagian besar DBA berbagi kumpulan tunggal, atau setidaknya array pada tingkat RAID yang sama. Saya telah memiliki DBA hingga pukul 3AM 24x7 hanya untuk mendefrag grup file individual dari 100 + basis data TB ... dan untuk apa sebenarnya? Kami memiliki IO yang benar-benar acak di disk dan latensi adalah 15 ms. Pada titik itu saya harus menunjuk 15ms dan memberitahu pengembang untuk meninggalkan saya sendiri.
ooutwire
2

Idealnya, Anda harus mereorganisasi / mengindeks ulang HANYA untuk indeks yang perlu perhatian, jika tidak Anda membuang-buang sumber daya dan berpotensi menyebabkan masalah lain.

Anda perlu menetapkan garis dasar kinerja dan setiap kali Anda melakukan perubahan, bandingkan perubahan kinerja tersebut dengan garis dasar untuk menentukan apakah perubahan Anda layak diterapkan.

Jimbo
sumber
Strategi langsung kami adalah melakukan hal itu - kami akan mengubah pengaturan untuk minFragmentation dan membangun kembali variabel variabel dalam skrip ini: sqlfool.com/2011/06/index-defrag-script-v4-1
dev_etter
0

Oke, pertanyaannya adalah tentang Indeks Basis Data, yang merupakan konstruksi dari file atau set file. Membaca jawaban di atas akan membuat seseorang percaya bahwa kita berbicara tentang fragmentasi pada tingkat disk dan bukan indeks di dalam file. Subjek yang benar-benar terpisah.

Pendekatan rabun di sini adalah kinerja ketika mengambil data di dalam dan OLTP Database membaik jika Indeks De-terfragmentasi atau Dibangun Kembali. Jawabannya iya! Namun, penting untuk dicatat bahwa fragmentasi disk juga merupakan faktor.

"Biaya" terendah keseluruhan? Lakukan Pemeliharaan Basis Data Anda. Biaya terendah kedua, lepaskan basis data, pindahkan ke tempat lain, format ulang disk Anda dan ikuti praktik terbaik untuk Penyelarasan Disk Partisi http://msdn.microsoft.com/en-us/library/dd758814.aspx . Last but not least, gunakan defragmentor canggih pihak ke-3 seperti Diskkeeper.

Perlu diingat, ini HANYA direkomendasikan untuk penyimpanan tipe NTFS (misalnya OS Windows) dan ini bukan dukungan untuk produk apa pun atau saya tidak berafiliasi dengan Condusiv Technologies atau anak perusahaannya.

IryDBA2791
sumber
2
Anda mungkin ingin menghindari mengatakan, "Jawabannya adalah YA!" ke ruang masalah yang telah dibahas panjang lebar oleh poster lain. Meskipun mungkin benar bahwa kadang-kadang jawabannya adalah "Ya", seperti yang ditunjukkan oleh Brent Ozar dalam posting blognya, itu tidak selalu terjadi.
Max Vernon