Van Laan on Sharepoint and all things Microsoft

Microsoft Product Lifecycle and Version Evaluation

The support lifecycle policy FAQ:

http://support.microsoft.com/gp/lifepolicy

The support lifecycle index:

http://support.microsoft.com/gp/lifeselectindex

Some key notes here are that most versions of Windows Server 2003 are ending mainstream support in mid-to-late 2010.

SQl 2005 support lifecycle:

http://support.microsoft.com/lifecycle/?p1=2855

Mainstream ends 4/2011

Windows Server 2003 Version Evaluation:

http://technet.microsoft.com/en-us/library/cc758523.aspx

Things like you can only address up to 4 GB in Standard, up to 32GB in Enterprise. Or you can only go above quad-proc with Enterprise.

Moving SQL 2005 databases

Moving SQL 2005 databases from an existing, functioning web app with multiple site across multiple content databases

Here’s a shot of the Manage Content databases for the web app screen. As you can see, there’s two site collections on this web app, one in each of the content dbs. The goal is to simply move the dbs in SQL and have Sharepoint keep on trucking happily:

So, we’ll detach the databases, move the files, then reattach them.

(I’ve already detached the first one here. Detaching the second.)

We’ll just drop the active connections:

So, then I cut and paste the db’s (.mdf) and the log files (.ldf) from the default database file location for SQL server to another random place on the c: drive (this should work similarly from drive to drive):

And now, obviously, with the databases detached, the web site does not work:

Now, to reattach the db’s from their new location:

Click Add:

Select the correct db and hit OK. It picked up the .ldf associated with this .mdf just fine:

Click Ok to reattach and the database attached just fine:

Now, I’m going to go try and hit the site collection that resides in this database (http://www.vanlaans.com) and then try to hit the site collection that resides in the other database, which is not yet attached (http://www.vanlaans.com/sites/pub )

Hey, looking good on http://www.vanlaans.com :

Now, to hit the other site collection from the not reattached database:

And it fails:

So, now to reattach the second content db. Done and now to test out the second site collection:

Very good times.

Using the SMS 2003 Toolkit Trace Log Viewer to dynamically watch Sharepoint Server 2007 or SQL Server logs as they’re written

Using the SMS 2003 Toolkit Trace Log Viewer to dynamically watch Sharepoint Server 2007 logs as they’re written

First, go to

Systems Management Server 2003 Toolkit 2

http://technet.microsoft.com/en-us/sms/bb676787.aspx

And download and install the toolkit.

Then you’ll have an option available to run:

Pull it up and browse to your Log file location Path, which you can find by going to Central Administration, Opreations, and select Diagnostic Logging:

I’ve placed them on the D: drive, like this:

But the default value is:

C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\LOGS

Once you’ve browsed there one time, the program will save that location for ease of getting back there.

Anyways, pull it up and you can dynamically watch the Sharepoint Server 2007 Trace Logs get populated on the fly. Red highlights mean errors, yellow means warnings.

Here’s an error:

And you can get the full detail of the line at the bottom. Very useful for troubleshooting specific issues or demonstrating that they can be recreated.

It’s also quite useful for watching your SQL Server 2000 and SQL Server 2005 Logs, too.

If you click the last line at the bottom and highlight it, the program will continue to keep the last line highlighted, moving events up the screen as they come in, effectively giving you a real-time log viewer.

Using Sharepoint 2007 Farm Backup feature to identify all SQL databases in use in your farm

It seems like a fairly obvious thing, but it's actually a bit of a pain to determine every last one of the db's used in your farm installation, especially if you're installing a few different instances , e.g. prod, dev, and test on the same SQL box. One great way to determine all of these is to use the built-in Backup procedure in Sharepoint 2007 Central Administration.

Go to CA, then to Operations, then click Perform A Backup.

You should be presented with every last component in your farm, including all the databases (Type = Content Database, Shared Service Provider db, Search db for Shared Services, Search database for (wss help search server name)).

Yep. For a fully configured farm with separate content databases for My Sites and Team Sites nets you NINE SQL db's. Good times.

Here's a screenshot from SQL Server 2005 Management Studio:

So, this is probably the cleanest SQL install ever. 

So, there you go. There's all your db's.

SQL Best Practices on Sharepoint 2007

So, this will start as a placeholder post that needs to be fleshed out. Here are the questions:

1. Recovery mode - should it be simple or should it be full?
2. If recovery mode is full, what should I do about the size of the log (ldf) file - when does it shrink?
3. What about fragmentation?
4. Should we pre-size the database as opposed to going with defaults (which apparently increments in small chunks, leading to fragmentation).

Current answers are: not that much--

http://blogs.technet.com/josebda/archive/2006/07/31/maintaining-your-moss-2007-sql-databases.aspx

Jose speaks to some of the questions here. Simple mode is fine if you don't need to do point-in-time restores. Recovery mode is better if you need to hit a specific incremental backup for a restore. When an incremental backup is run on the logs, they are truncated. So, we're really talking about a SQL backup issue versus a Sharepoint issue.

http://www.sharepointblogs.com/llowevad/default.aspx

http://www.sharepointblogs.com/llowevad/archive/2007/04/19/sharepoint-database-growth-rates.aspx

Again, a SQL vs Sharepoint backup suggestion. Incremental backups truncate the logs. So, a good solution would be to run weekly full backups from a SQL perspective, and incremental dailies.

Bill Baer's thoughts on Sharepoint and SQL management (look towards the bottom of the post)

http://blogs.technet.com/wbaer/archive/2007/05/08/database-management-concepts-for-large-and-growing-content-databases.aspx

1. There is also some documentation indicating that when using SQL 2005's database mirroring mode for redundancy in a Sharepoint 2007 setup, full recovery mode must be used. Here's the reference:

(need reference)

Basic suggestion seems to be to use full recovery mode and have incremental backups scheduled on the log files to truncate them.

2. (see above)

3. Fragmentation--?

4.  I haven't seen or read anything about pre-sizing the databases helping. Still working on this entire post, though.

(Thanks to Ian.)