Ukuran maksimum database konten SharePoint

Pertanyaan lain dari berbicara dengan guru SharePoint saat mengajar MCM kemarin. Pedoman SharePoint adalah bahwa basis data konten di atas 100GB tidak didukung. Tanpa mengetahui alasan di balik pedoman itu, saya tertarik untuk mendengar tentang basis data konten yang lebih besar dari 100GB dan pengalaman Anda dengannya (terutama seputar kinerja, pemulihan bencana, dan penyediaan HA).

Seberapa jauh Anda berhasil mendorong instalasi SharePoint Anda? Saya telah mendengar kisah-kisah dari> 1TB basis data konten, tetapi saya ingin mendengar sendiri dari admin SharePoint.

Terima kasih atas info yang Anda miliki.

Kami memiliki DB di 111 dan 102GB, yang didukung dalam waktu kurang dari 30 menit pada jaringan GigE. Saya telah mendengar bahwa database yang lebih besar dapat memiliki masalah dengan prosedur tersimpan yang sudah berjalan lama, tetapi tidak melihat adanya demonstrasi.

Kutipan yang bagus dari kertas putih "Scaling SharePoint 2007: Storage Architecture":

"... Ini biasanya disebut sebagai" batasan ukuran basis data konten 100GB ". Faktanya, ini bukan batasan yang sebenarnya melainkan sebuah rekomendasi. Database SQL Server telah melakukan penskalaan jauh melampaui 100GB selama bertahun-tahun sekarang. Secara praktis, rekomendasi didasarkan terutama pada dua faktor penting:

1. Persyaratan Perjanjian Tingkat Layanan (SLA) untuk organisasi tertentu dapat menentukan bahwa operasi cadangan untuk database SharePoint harus dapat dieksekusi dalam jumlah waktu terbatas. Ukuran basis data konten akan berdampak langsung pada berapa lama waktu yang diperlukan untuk menjalankan cadangan itu.

2. Subsistem penyimpanan harus cukup kuat untuk menangani persyaratan I / O disk dari solusi SharePoint yang dilayaninya.

Selama suatu organisasi dapat memitigasi dua pertimbangan ini, maka basis data konten dapat tumbuh. Implementasi dunia nyata telah melihat keberhasilan penyebaran SharePoint yang telah mengimplementasikan ukuran basis data 100GB, 150GB, 200GB, 250GB, 300GB, 350GB, dan 400GB. "

Untuk penggunaan sehari-hari, ukuran basis data tidak begitu penting - sebagian besar kueri mengembalikan item dalam satu daftar dan tidak masalah apa pun yang ada di database. Namun, operasi yang bekerja pada seluruh basis data akan menjadi lebih sulit. Cadangan adalah contoh yang paling jelas - mereka akan membutuhkan waktu lebih lama dengan database besar. Namun, selama database tidak melebihi apa yang dapat didukung dalam semalam Anda akan baik-baik saja - cadangan dirancang untuk berjalan lama dan cukup dapat diandalkan selama Anda tidak kehabisan ruang disk.

Di mana Anda akan mengalami masalah nyata adalah dengan hal-hal yang kurang sering seperti memindahkan atau meningkatkan basis data konten - ini dapat membutuhkan sekitar 5 kali ukuran basis data di ruang kosong dan diimplementasikan menggunakan kueri yang dapat melakukan hal-hal seperti pemicu autogrow yang tidak terkendali.

Kami memiliki databse konten yang berukuran 300 GB. Tidak ada masalah dengan cadangan setelah beralih ke Kecepatan Lite. Sebelum beralih, kita akan melihat penurunan kinerja yang serius dengan situs web.

Sebagai catatan, kami TIDAK ingin memiliki Content DB sebesar ini. Kami memiliki persyaratan bisnis khusus seputar berbagi konten yang akan sangat sulit diimplementasikan jika kami meletakkan konten dalam kumpulan situs terpisah.

Ketika kami pertama kali ditayangkan kami memiliki masalah penguncian besar dengan database selama penggunaan puncak. Kami melacak ini kembali untuk menggunakan objek CrossListQueryCache di SharePoint. Kami berubah dari menggunakan API itu dan itu memperbaiki banyak kinerja kami.

Saya menulis artikel blog kecil dengan informasi lebih lanjut di sini .

Kami masih melihat masalah penguncian dengan jenis pembaruan tertentu (menghapus gumpalan> 20 MB), mengubah nama web (ini dapat menyebabkan pembaruan ke banyak catatan di tabel AllUserData. Kami bekerja dengan Dukungan MS pada kasus-kasus tertentu (yaitu menghapus item besar dari keranjang sampah) Ini telah ditelusuri kembali ke cara prosedur tersimpan tertentu di SharePoint menghapus data, tetapi kami belum memiliki solusi.

Secara pribadi saya pikir masalah terjadi setelah Anda mendapatkan begitu banyak catatan di tabel AllUserData dan cara paling mudah bagi MS untuk berkomunikasi ini kepada orang-orang adalah dengan mengatakan tetap di bawah 100 GB.

Saya sarankan ping orang-orang di MS IT ... Saya telah mendengar dari catatan bahwa mereka memiliki DB SharePoint Content> 800 GB.

Perusahaan kami memiliki database saat ini di 140Mb. Kami mengalami kinerja lambat dalam satu daftar tertentu yang telah dibiarkan tumbuh hingga 1,5Gb yang berisi lampiran termasuk beberapa versi lampiran. (Ngomong-ngomong, saya baru sekitar 2 bulan). Kami sekarang merencanakan migrasi dan sepertinya ingin bermigrasi ke SP 2010 menggunakan alat Metalogix bisa memakan waktu berhari-hari untuk diselesaikan berdasarkan pengujian kami. Kami adalah database yang dirancang dengan buruk, portal yang dirancang buruk yang sekarang memiliki kita yang harus mengelolanya dengan masalah nyata.

Kami memiliki situs cadangan yang kami gunakan yang merupakan salinan tepat dari lingkungan produksi kami. Tetapi perangkat keras adalah perangkat keras TUA kami setelah pembaruan perangkat keras terakhir - Perangkat keras lama untuk Pengembangan, baru untuk produksi. Namun beberapa area lingkungan pengembangan kami tidak dapat digunakan karena masalah kinerja yang memaksa beberapa pengembangan dalam daftar besar harus dilakukan dalam produksi. Aduh, Aduh, Aduh ....

Itu salah. Tidak ada batasan tentang ukuran. Mereka merekomendasikan untuk tidak memiliki basis data yang besar tetapi hanya untuk membuat manajemen basis data lebih mudah dan meminimalkan waktu cadangan / pengembalian. Kita dapat mengatakan bahwa batasan ukuran itu tergantung pada infrastruktur infra-SQL Anda saja.