You can create additional  databases, but it is a manual process. Many installations have multiple content  databases for each web application.

Any suggestions on how to make our current content  DB more managable then? Ideally, I'd like to break up our current content DB into multiple, smaller DB's and then remove the original DB.

I can’t remember where, but the product team released a non-supported tool to move site collections between content  databases. Does anyone know the location of this tool?

I was looking for that exact thing this week. The closest answer I could come up with was that it was rolled into Keith Ritchie's tools.

I read your article about using a combination of site quotas and site limits to monitor site usage and had an additional  question. Let me provide the following example: each content  database supports 100 sites each with a quota of 200MB. I then deploy three identically configured content databases. Once the site limit on the first content database  is met, will it start deploying them automatically to the second content database and so on?

Yes................................

I thought that the admin had to manually take the database  offline (in sharepoint terms.. not sql.. it just locks it) in order for the next database to begin to be used.

Otherwise, when the first db fills up users get the "out of disk space" or similar message..

I didn’t think so – I thought it was an automatic process

The Microsoft stuff on admining content  databases can be found at

www.microsoft.com/.../stsd03.mspx?mfr=true

I’ve also tested it in a lab just now and it transparently puts new sites into the new database  when the old one is full so it should be fine

The other thing you can do is to create new virtual servers with top level sites and each of these can have their own content  databases

In this was subwebs from those top level sites get created in their own content database  which does give you a way of load balancing

i.e. if you are using wss sites for departments and they create all their stuff under those top level sites you can have each department on their won virtual server and hence in their own content database which might make backups and admin a little easier for you

We go through this process  periodically. We use STSADM to back a Site
Collection. Then we delete it. We restore it with only one Content DB set to
be able to accept new sites.

Keith Ritchie's Site Manager utility in his Sharepoint Utilities 2.5 does it as
well. I believe he explains how to do it in one of his blog entries.

How deep do you go into your analysis of site collection migrations? Ideally, when moving these site collections, I'd like to pay particular attention to those with the highest level of activity over a given period of time. The stagnant site collections could probably stay where they are without worry too much about them growing dramatically.

We didn’t pay a lot of attention to usage, although we probably should have. We have quotas for 100% of our Site Collections, we get a pretty good idea which sites are growing by the requests for their quota to be raised.

Sharepoint will put new sites into content  databases as long as the the current
number is less than the maximum number. You can have more than one content DB
getting new sites. I forget the exact algorthm, but I think Sharepoint adds the
site to the database  with the most open slots (largest difference between
current and max) and then round robins once they are all equal.

If you take the Content DB "offline" in Central Admin, no new sites will go in
regardless of the current and max values.

So it sounds like the last thing I need to do is come up with a decent procedure to move these site collections into the new content  DB's. Thanks for the help!

Any thoughts on the capacity planning behind all of this? Are there any tools that you guys might be able to recommend that can do content DB level analysis and perhaps some trending?

I’ve never tried it but you could try the free tool from quest

http://www.quest.com/sharepoint/

It must be good if its from quest !

You could also try the trial of universal sharepoint manager (I don’t know that I would buy the 2003 version with 2007 just round the corner)

www.idevfactory.com/products/uspm/sitesmgt.aspx

We limit our content  databases to 50 GB. This number, and its reasoning, was
blantantly stolen from a TechEd '05 presentation that Joel Oleson put on.
Basically we can restore 50 GB chunks of data in a time that is reasonable to
make customers wait, should we need to restore something. There are a couple of
other little database  things that make us want things broken up (like the
occasion lock caused by STSADM) but backup  and restore times are our major
concern.

We just keep an eye on them in SQL Enterprise Manager. Once they start getting
over 25 GB we start looking at which sites are active and start making plans to
break things out.

How much interest is there in this topic? With v3 coming up I think this kind
of housekeeping will be important. I think I'm going to pitch an article to
TechNet magazine about how to break up Site Collections and Content databases.

I think there could be quite a bit

As well as backup  and restore times there are also performance considerations for the very few large implementations out there (I work on some with up to 100,000 users) and by placing content  databases on other sql servers we can provide the performance necessary for the solutions (i.e. by splitting the sql workload)

I think what would make an interesting article, is good advice, maybe in a table, of the different backup options available

i.e. when to use spsbackup, spbackup, smigrate, stsadm … what benefits there are to SQL backups (I usually recommend 3rd party software or spsbackup with sql as a last resort)

and what the benefits of each are … i.e. this one keeps permissions, this one lets you turn the file into a cab and get individual documents back

Equally though, 2003 is coming end of life so I can see a huge call for such an article based on 2007 because if you cant get it back quickly and accurately then there’s little point in putting it out and this may give people more comfort in making the move.