[SharePoint] Max content database

[badFISH]

Het probleem
Wij gebruiken SharePoint MOSS 2007 met SQL 2005 om projecten op buitenlocaties mee te ontsluiten. Wij slaan alle informatie, dat wil zeggen email, correspondentie, tekeningen, contracten etc. op deze SharePoint.
Deze project SharePoint is in feite 1 site collection met zijn eigen content database.
Om SharePoint gebruikersvriendelijker en extra functionaliteit toe te voegen gebruiken we buiten Organice als schil over de SharePoint.
Nu is het dus zo dat deze site collections snel zeer groot worden. We zitten nu al op 1 project op 65 GB.
We verwachten dat nieuw op te starten projecten uiteindelijk op de 250GB uit zal komen.
Nu wordt er op internet en bij onze ICT afdeling vaker gesproken over een max. van 100GB voor de content database. Dit zou betekenen volgens deze richtlijn dat het nieuwe project in 3e (2x 100GB + 1x 50 GB) verdeeld moet worden.

Oplossing ICT afdeling
Ga met managed paths werken. Hierbij lijkt de site uit 1 site collection te bestaan maar in feite kunnen er meerdere site collections in 1 project gemaakt worden. Hierdoor zou een groot project in 2 of meerdere site collections te knippen zijn.
Echter werkt dit voor Organice niet omdat dit pakket niet over meerdere sites documenten kan versturen en registraties kan bijhouden. Ook de verwijzingen van de lookup's die gelijk over alle sites moeten zijn moeten dan op een of andere manier over deze sites gesynchroniseerd moeten worden.

Oplossing leverancier Organice
Die zoeken het in een extern pakket AvePoint DocAve Extension Archiver
Hierbij wordt de informatie i.p.v. in de SQL opgeslagen op de file-server met een link in de SQL. Dit maakt het mogelijk dat projecten veel groter kunnen worden immers de informatie staat op de file-server en in de SQL staan alleen maar verwijzingen.
Het probleem is nu een beetje dat ieder zijn eigen strategie wilt blijven volgen. Onze ICT zegt dus wij gaan de oplossing van Organice niet uitvoeren omdat de SharePoint een cluster server is, bestaande uit 4 front-end servers die allemaal aangepast moeten worden. De oplossing die onze ICT zelf aandraagt gaat dus ook niet werken met ons product wat we gebruiken.

Onze vragen
Is het limiet van 100 GB voor 1 content database met daarbij 1 site collection echt een limiet of zijn er ontwikkelingen op dit gebied?
Nu is onze vraag zijn er nog meer technische oplossingen mogelijk/denkbaar (bijv. meerdere content databases voor 1 site collection etc, SQL 2008, MOSS2010 etc)?
Of heeft iemand nog andere slimme ideeën?

[dj_vibri]

... Eventjes helemaal opnieuw want had compleet verkeerde info. gegeven....

Een "WEB APPLICATION" definieert een Content Database, waarna je per web application verscheidene site collections aanmaakt, welke op hun beurt in deze Content DB geplaatst worden.

Je kan dus zoals bij onze sharepoint-projecten het volgende hanteren:

Project A --> Web app: ProjA / Site Collection: X, Y en Z / Content DB: ProjA
Project B --> Web app: ProjB / site Collection: a,b / Content DB: ProjB

Je kan natuurlijk ook hiervoor gebruik maken van meerdere SQL Servers waardoor je de Content DB's kunt verspreiden over meerdere servers....

[ Voor 53% gewijzigd door dj_vibri op 19-05-2009 13:25 . Reden: foutieve info... ]

[pasz]

badFISH schreef op dinsdag 19 mei 2009 @ 09:33:
Nu wordt er op internet en bij onze ICT afdeling vaker gesproken over een max. van 100GB voor de content database. Dit zou betekenen volgens deze richtlijn dat het nieuwe project in 3e (2x 100GB + 1x 50 GB) verdeeld moet worden.

Ik vind dit een erg wazige bron. Ik heb ook wel eens op internet gelezen dat er een roze olifant op de maan leeft. Kun je niet gewoon microsoft bellen met dit soort vragen.

Een SQL server DB van 100 gieg mag toch geen probleem zijn ? Of is de hardware niet goed genoeg ?

[F_J_K]

pasz schreef op dinsdag 19 mei 2009 @ 13:36:
Ik vind dit een erg wazige bron. Ik heb ook wel eens op internet gelezen dat er een roze olifant op de maan leeft. Kun je niet gewoon microsoft bellen met dit soort vragen.

Een SQL server DB van 100 gieg mag toch geen probleem zijn ? Of is de hardware niet goed genoeg ?

Hoewel 'bronnen' zonder bronvermelding inderdaad altijd met een dosis gezond verstand moeten worden gezien, komt overal die 100GB langs.
Bijv http://blogs.msdn.com/sha...nning-and-monitoring.aspx noemt 100GB als best practice (en geeft wat tips).

Ook in diverse boeken (tenminste de eerste twee die ik bekeek, Essential SharePoint 2007 en Microsoft SharePoint 2007 unleashed) wordt 100GB genoemd als slimme bovengrens. Zonder overigens andere opzetten te noemen, anders dan losse content DB's gebruiken.

[badFISH]

Zoals F_J_K al zei, wordt de 100GB grens vaker genoemd.
Bijvoorbeeld op de technet van Microsoft zelf; http://technet.microsoft.com/en-us/library/cc262787.aspx wordt geadviseerd het onder de 100 GB te houden vanwege de performance.

De oplossing om een project over meerdere site collections te verdelen gaat dus niet met Organice samenwerken. De wens is dus 1 site collection die verbonden is met meerdere content databases (lijkt me niet mogelijk), de SQL kleiner maken door bestanden ergens anders te plaatsen (AVEpoint oplossing),... maar misschien zijn er nog meer mogelijkheden om alles toch op 1 site collection te houden, 200+ Gb op te slaan.
Als iemand hier nog tips voor heeft of andere mogelijke oplossingen dan horen we het graag

Bedankt voor het meedenken zover!

[Glorix Jim]

Eén sitecollectie leeft in één contentdatabase. Het is dus niet mogelijk om een sitecollectie over meerdere contentdatabases te verspreiden. De limiet van 100gb is er om performance en backup/restore probelemen te voorkomen. Het kost bijvoorbeeld wat tijd om een database van 500gb te backuppen en te restoren. Aangezien een database van SharePoint niet heel erg relationeel en genormaliseerd is opgezet krijg je ook vaker te maken met SQL blocking omdat er teveel wordt gevraagd van de database (gebruikers, index, timerjobs, etc).

Dus.. in theorie kan een contentdatabase zo groot worden als je zelf wilt maar de praktijk wijst uit dat het een contentdatabase van 50gb een best practice is.

Je ICT afdeling wat meer SharePoint cursussen nodig denk ik.. je hoeft namelijk maar op één plek in SharePoint aan te geven dat je gebruik wilt maken van 'managed paths'. SharePoint zorgt zelf dat deze configuratie wordt opgeslagen op elke server die in de 'farm' zit.

Dan over Organize..
1) Waarom kan Organize niet over meerdere sitecollecties gaan met hun oplossing? Lijkt me een vrij grote beperking.. Er zijn al tools uit die je contenttypes kunnen synchroniseren over sitecollecties heen. En voor bepaalde aggregaties kan je gebruik maken van de MOSS search (of Search Server als je alleen WSS hebt).

2) Waarom is er uberhaupt gekozen voor zo'n informatie architectuur? Lijkt me niet heel schaalbaar namelijk..

[Anoniem: 232786]

Die 100GB hoef je overigens niet als grens te nemen. Ik heb een SP site collection van 400GB draaien die het goed doet. Het hangt heel erg van het aantal gebruikers af. Maar een waarschuwing, als je het later wilt splitsen in kleinere site collections heb je een probleem want dat is niet simpel en is zeer tijdrovend. Het voordeel in mijn bedrijf is dat de gebruikers over de hele wereld redelijk eerlijk verdeeld zijn dus er is een lage piekload.

[Glorix Jim]

Anoniem: 232786 schreef op donderdag 25 juni 2009 @ 12:16:
Die 100GB hoef je overigens niet als grens te nemen. Ik heb een SP site collection van 400GB draaien die het goed doet. Het hangt heel erg van het aantal gebruikers af. Maar een waarschuwing, als je het later wilt splitsen in kleinere site collections heb je een probleem want dat is niet simpel en is zeer tijdrovend. Het voordeel in mijn bedrijf is dat de gebruikers over de hele wereld redelijk eerlijk verdeeld zijn dus er is een lage piekload.

Wat heb je voor backup/restore strategie?

[MaZo]

Die 100 GB per content database is geen harde limiet. De echte harde limiet is SQL server. M.a.w. je kunt nog wel even vooruit. De limiet wordt puur geadviseerd met het oog op backup / restore (en niet eens zo zeer met performance), en de bijbehorende restore tijden.

Een web application kan meerdere content databases hebben, net zoals één content database meerdere site collections kan hebben. Eén site collection kan echter maar één content database beslaan.

Eén site collection van 250 GB is prima, maar e.e.a. hangt af van je requirements.
Zo worden veel zaken geconfigureerd op site collectie niveau (search scopes, navigatie, security, site quotas, etcetera) geconfigureerd. Maak dus een nieuwe site collecties aan zodra:

• De gesplitte content niet gedeeld zal moeten worden met andere site collecties.
• De gesplitte content unieke beveiligingsvereisten heeft i.t.t. andere site collecties.
• Je SLA beschikbaarheid vereist die verschilt met die van andere site collecties.
• Governing policies, guidelines en best practices zullen verschillen van andere site collecties.
• Deze in een andere taal (variations) moet zijn dan de overige content.