Kích thước tối đa của cơ sở dữ liệu nội dung SharePoint

Một câu hỏi khác từ việc nói chuyện với các bậc thầy về SharePoint trong khi dạy MCM ngày hôm qua. Nguyên tắc của SharePoint là cơ sở dữ liệu nội dung trên 100 GB không được hỗ trợ. Không đi vào lý do đằng sau những hướng dẫn đó, tôi rất muốn nghe về cơ sở dữ liệu nội dung lớn hơn 100GB và trải nghiệm của bạn với chúng (chủ yếu xoay quanh hiệu suất, khắc phục thảm họa và cung cấp HA).

Bạn đã quản lý được bao xa để đẩy cài đặt SharePoint của mình? Tôi đã nghe những câu chuyện cũ về cơ sở dữ liệu nội dung> 1TB, nhưng tôi muốn nghe từ chính quản trị viên SharePoint.

Cảm ơn cho bất kỳ thông tin bạn có.

Chúng tôi có DB tương ứng là 111 và 102 GB, được sao lưu dưới 30 phút trên mạng GigE. Tôi đã nghe nói rằng các cơ sở dữ liệu lớn hơn có thể có vấn đề với các thủ tục lưu trữ lâu dài, nhưng không thấy trình diễn nào về nó.

Một trích dẫn hay từ whitepaper "Thu nhỏ SharePoint 2007: Architecture Architecture":

"... Điều này thường được gọi là giới hạn kích thước cơ sở dữ liệu nội dung 100GB, trong thực tế, đây không phải là giới hạn thực sự mà là một khuyến nghị. khuyến nghị chủ yếu dựa trên hai yếu tố quan trọng:

1. Các yêu cầu Thỏa thuận cấp độ dịch vụ (SLA) cho một tổ chức nhất định có thể ra lệnh rằng các hoạt động sao lưu cho cơ sở dữ liệu SharePoint phải được thực thi trong một khoảng thời gian giới hạn. Kích thước của cơ sở dữ liệu nội dung sẽ có tác động trực tiếp đến thời gian thực hiện sao lưu đó.

2. Hệ thống con lưu trữ phải đủ mạnh để xử lý các yêu cầu I / O đĩa của giải pháp SharePoint mà nó phục vụ.

Miễn là một tổ chức nhất định có thể giảm thiểu hai cân nhắc này, thì cơ sở dữ liệu nội dung có thể được phép phát triển. Việc triển khai trong thế giới thực đã chứng kiến ​​các triển khai SharePoint thành công đã triển khai các kích thước cơ sở dữ liệu 100GB, 150GB, 200GB, 250GB, 300GB, 350GB và 400GB. "

Đối với việc sử dụng hàng ngày, kích thước cơ sở dữ liệu không quan trọng - hầu hết các truy vấn trả về các mục trong một danh sách và không có vấn đề gì khác trong cơ sở dữ liệu. Tuy nhiên, các hoạt động trên toàn bộ cơ sở dữ liệu sẽ trở nên khó khăn hơn. Sao lưu là ví dụ rõ ràng nhất - chúng sẽ mất nhiều thời gian hơn với cơ sở dữ liệu lớn. Tuy nhiên, miễn là cơ sở dữ liệu không vượt quá những gì có thể sao lưu qua đêm, bạn sẽ ổn thôi - các bản sao lưu được thiết kế để hoạt động lâu và khá đáng tin cậy miễn là bạn không hết dung lượng đĩa.

Trường hợp bạn sẽ gặp phải các vấn đề thực sự là với những việc ít thường xuyên hơn như di chuyển hoặc nâng cấp cơ sở dữ liệu nội dung - chúng có thể cần khoảng 5 lần kích thước cơ sở dữ liệu trong không gian trống và được triển khai bằng các truy vấn có thể thực hiện những việc như tự động kiểm soát.

Chúng tôi có một cơ sở dữ liệu nội dung có kích thước 300 GB. Không có vấn đề với sao lưu sau khi chuyển sang Lite Speed. Trước khi chuyển đổi, chúng ta sẽ thấy sự suy giảm hiệu suất nghiêm trọng với các trang web.

Đối với bản ghi, chúng tôi KHÔNG muốn có một DB nội dung lớn như vậy. Chúng tôi có các yêu cầu kinh doanh cụ thể xung quanh việc chia sẻ nội dung sẽ rất khó thực hiện nếu chúng tôi đưa nội dung vào các bộ sưu tập trang web riêng biệt.

Khi chúng tôi lần đầu tiên đi vào hoạt động, chúng tôi đã gặp sự cố khóa lớn với cơ sở dữ liệu trong thời gian sử dụng cao điểm. Chúng tôi đã lần theo dấu vết này để sử dụng đối tượng CrossListQueryCache trong SharePoint. Chúng tôi đã thay đổi từ việc sử dụng API đó và nó đã sửa rất nhiều hiệu suất của chúng tôi.

Tôi đã viết lên một bài viết blog nhỏ với nhiều thông tin hơn ở đây .

Chúng tôi vẫn thấy các sự cố khóa với một số loại cập nhật nhất định (xóa các đốm màu> 20 MB), đổi tên web (điều này có thể gây ra các bản cập nhật cho nhiều bản ghi trong bảng AllUserData. Chúng tôi đang làm việc với Hỗ trợ MS về các trường hợp cụ thể ). Những điều này đã được bắt nguồn từ cách các thủ tục được lưu trữ cụ thể trong SharePoint đang xóa dữ liệu, nhưng chúng tôi chưa có giải pháp.

Cá nhân tôi nghĩ rằng các vấn đề xảy ra sau khi bạn nhận được rất nhiều hồ sơ trong bảng AllUserData và cách dễ dàng để MS truyền đạt điều này đến mọi người là nói ở mức dưới 100 GB.

Tôi đề nghị ping mọi người tại MS IT ... Tôi đã nghe được rằng họ có SharePoint Content DB> 800 GB.

Công ty chúng tôi có cơ sở dữ liệu hiện tại là 140Mb. Chúng tôi đang gặp hiệu suất chậm trong một danh sách cụ thể đã được phép tăng lên 1,5Gb, có chứa tệp đính kèm bao gồm nhiều phiên bản tệp đính kèm. (Tôi chỉ mới ở đó khoảng 2 tháng). Chúng tôi hiện đang lên kế hoạch di chuyển và có vẻ như việc chuyển sang SP 2010 bằng công cụ Metalogix có thể mất nhiều ngày để hoàn thành dựa trên các thử nghiệm của chúng tôi. Của chúng tôi là một cơ sở dữ liệu được thiết kế kém, cổng thông tin được thiết kế kém mà bây giờ có những người trong chúng ta phải quản lý nó với các vấn đề thực sự.

Chúng tôi có một trang web sao lưu mà chúng tôi sử dụng là bản sao chính xác của môi trường sản xuất của chúng tôi. Nhưng phần cứng là phần cứng OLD của chúng tôi sau bản cập nhật phần cứng cuối cùng của chúng tôi - Phần cứng cũ để phát triển, mới cho sản xuất. Tuy nhiên, một số lĩnh vực trong môi trường phát triển của chúng tôi không sử dụng được do các vấn đề về hiệu suất buộc một số phát triển trong danh sách lớn phải được thực hiện trong sản xuất. Ouch, Ouch, Ouch ....

Điều đó là sai. Không có giới hạn về kích thước. Họ khuyên bạn không nên có cơ sở dữ liệu lớn mà chỉ để quản lý cơ sở dữ liệu dễ dàng hơn và giảm thiểu thời gian sao lưu / khôi phục. Chúng tôi có thể nói rằng giới hạn kích thước nó chỉ phụ thuộc vào cấu trúc SQL của bạn.