I'd have to agree with Damien.

The size limitations you might currently be experiencing with a single content 
DB would be nothing compared to the administrative nightmare (and subsequent 
limitations) you may face with 320 DBs; especially if they're each only housing 
a single site collection.

We went down the same road a few months back and there are pros and cons to 
both sides.

Do you expect these 320 sites to ever reach a size where they themselves would 
become unmanageable? If not, then splitting your current DB into more 
manageable business units (comprising of several related sites) is a nice 
middle of the road option. You can always split again down the track if it's 
really required.

From: ozmoss-boun...@ozmoss.com [mailto:ozmoss-boun...@ozmoss.com] On Behalf Of 
Damien Robinson
Sent: Tuesday, 12 October 2010 3:27 PM
To: ozMOSS
Subject: RE: SharePoint database creation

I'd potentially look at the solution from a different angle (without knowing 
much more than I've read below). Instead of individual site collections (and 
subsequent content db's) for each team site (which seems excessive), you may 
consider breaking site collections up into "business units" instead. i.e. BU 
such as Finance may then be broken into Sales, Accounts, and so on and these 
all share a single content database?

There are caveats however? Or am I way off the mark?



From: ozmoss-boun...@ozmoss.com [mailto:ozmoss-boun...@ozmoss.com] On Behalf Of 
Nigel Hertz
Sent: Tuesday, 12 October 2010 3:01 PM
To: ozMOSS
Subject: SharePoint database creation

Hey all

I've been reading a lot of differing viewpoints on SharePoint database creation 
- auto size, pre size etc. This is all well and good for the main content 
database; however what if you are creating a bunch of databases for teamsites?

The scenario: Our intranet content database is currently around 120Gb. We're in 
the process of a complete rebuild, and as part of this exercise, we're 
"splitting" all of the teamsites out into their own site collections, with 
their own content database for each site collection. (320 teamsites, 320 site 
collections, 320 separate databases)

I was thinking of simply changing the 'model' database, however I've since 
discovered that "SharePoint does NOT use the model database when it creates new 
site databases" so that wouldn't work. Does anyone have any suggestions? 
Creating 320 databases manually doesn't sound like the most fun task in the 
world. Would it work to create a separate 'script' file with all the database 
names (I'm building scripts to do the export / import etc using the object 
model) and then script the creation of the sites directly in SQL instead of 
using "stsadm -o CreateSiteInNewDB" ?

Nigel



*Please ensure that you log all issues or requests with the IT Service Centre. 
When logging calls, please include a detailed description of the problem.*

----------------------------------------------------------------
Nigel Hertz

Software Developer | Information Technology
Stockland
Level 25 | 133 Castlereagh Street | Sydney NSW 2000
T: 02 9035 2617 | F: 02 8988 2617


________________________________
Stockland Notice: If this communication has been sent to you by mistake, please 
delete and notify us.  If it has been sent to you by mistake, legal privilege 
is not waived or lost and you are not entitled to use it in any way. Stockland 
and its subsidiaries reserve the right to monitor e-mail communication through 
its networks.
_______________________________________________
ozmoss mailing list
ozmoss@ozmoss.com
http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss

Reply via email to