SharePoint Hosting and Development : Hosting (General)

SharePoint and Virtualization - Better Together!

Michael Watson — Tue, 09 Sep 2008 22:50:00 GMT

I'm really excited about virtualization and think it's the best way to streamline deployments and get the most bang for buck out of your hardware. However, there are some important differences between virtual and physical environments that you need to...(read more)

Improving SharePoint with SQL Server 2008

Michael Watson — Tue, 19 Aug 2008 22:00:00 GMT

You might have noticed that SharePoint SP1 now supports SQL Server 2008 :-) http://blogs.msdn.com/sharepoint/archive/2008/08/15/sql-server-2008-support-for-sharepoint-products-and-technologies.aspx http://blogs.msdn.com/mikewat/archive/2008/08/19/sql-server-2008-is-now-officially-supported.aspx...(read more)

Upgrading SharePoint SQL Servers to SQL Server 2008.

Michael Watson — Mon, 11 Aug 2008 23:20:00 GMT

SQL Server 2008 is now released and is supported by WSS 3.0 and MOSS 2007 SP1 and above although we probably won't see a supportability statement anytime soon due to resource constraints with the content folks. I will let you know when the official supportability...(read more)

Database Maintenance Whitepaper just published.

Michael Watson — Fri, 29 Feb 2008 09:36:00 GMT

A very proactive Bill Baer has released his database maintenance whitepaper. There's some great stuff in here straight from MSIT best practices. {updated link - Thanks Shane!} http://go.microsoft.com/fwlink/?LinkId=111531&clcid=0x409...(read more)

Sweet! I've been saying we need this....

Michael Watson — Fri, 25 Jan 2008 03:44:00 GMT

OK, I had nothing to do with this, but it's definitely something I've been talking about. I think a lot of people who think about governance and SharePoint want a way to manage site collections in cohesive units. Now there's a way: http://www.codeplex.com/SPConfigurator...(read more)

SharePoint and Storage

Michael Watson — Sun, 18 Nov 2007 23:39:00 GMT

There is lots of good information on how to optimize storage for SQL, perhaps too much. Some great articles to read for those interested: http://www.microsoft.com/technet/prodtechnol/sql/2005/physdbstor.mspx http://www.microsoft.com/technet/prodtechnol/sql/2005/workingwithtempdb.mspx...(read more)

Restoring SQL Server. Model DB Restore gotcha

Michael Watson — Fri, 26 Oct 2007 04:43:00 GMT

If somebody would have mentioned this, I would have 3 hours back. When recovering SQL server from a situation where you have lost the model database, make sure to remove the data and log files (if any exist) from the original directories before attempting...(read more)

BTW... High Availability/Disaster Recovery and SQL Licensing

Michael Watson — Tue, 31 Jul 2007 02:07:00 GMT

If like me you are looking to eak (sp) every dollar of costs savings out of your deployments take a look at the SQL Server Pricing and Licensing paper at http://www.microsoft.com/sql/howtobuy/sqlserverlicensing.mspx. I'm not sure this is common knowledge or not, (Is it? Please comment) but your passive servers do not need licenses provide that they do not process queries. I will not interpret this in any way as to avoid the wrath of the man. :-) Refer to the paper or your licensing representative for more information.

Database Mirroring vs Log Shipping. Choose Both?

Michael Watson — Sun, 29 Jul 2007 20:31:00 GMT

In a response to my blog entry Database Mirroring and Log Shipping. Which is better? The mysterious Reed Me said:

"Why not do both?

One is HA. One is DR.

It's a no-brainer.

Do both."

I totally agree. In fact, that is exactly what I've been working on for our external customers. Database mirroring will provide high availability inside the datacenter allowing us to forgo clustering and its expensive SAN storage while log shipping will provide DR protection between datacenters.

I would actually rather use asynchronous mirroring between datacenters as failovers are easier to manage, but as noted in my comparison post, you cannot mirror a database more than once. This is why we use log shipping for the "go long" solution. This also just happens to be the same solution that the MS SAP team uses as outlined in their ITShowcase white paper.

One thing to note is that failovers can be complicated to manage when combining mirroring and log shipping. This is because your mirroring principal server is also your log shipping primary server, however, during a mirroring failover your primary role does not automatically follow the principal role. You can either manage this manually like the MS SAP team does or you can automate. If you're like me you don't want to be playing around in SQL after a failover making automation very attractive.

Database mirroring and log shipping. Which is better?

Michael Watson — Sat, 28 Jul 2007 11:51:00 GMT

You may ask yourself and others this question all the time. I have heard the question a lot. The quick answer...it depends. I think both are great, however, your situation may make one more attractive than the other.

Here's a quick list of the main benefits of each technology as well as some limitations:

Database Mirroring benefits:

Instantaneous synchronization of changes
Easy setup and maintenance
Automated failover (in High Availability Mode)
Easy to perform failover
Fast failover. (if no transactions are queued)
Applications can be mirroring aware using failover partner parameter in connection string

Database Mirroring limitations:

Limited number of databases can be mirrored per SQL instance. (however, this number is higher than the 10 you see plastered everywhere, but really depends on your hardware)
Mirrored database cannot be queried, backed up, or basically touched in any way (snapshot can be taken however)
Only supports one to one server pairings
Cannot mirror a database more than once
Synchronous mirroring is intolerant to latency and bandwidth constraints (Asynchronous mirroring has no problems with latency or bandwidth)

Log Shipping benefits:

Very flexible - Independent jobs govern backup/copy/restore behavior
Delay of restore job can protect from database corruption
Log shipped database can be queried. (in standby mode)
Log shipping allows multiple standby databases
Perhaps more tolerant to latency than sychronous mirroring.
Doesn't affect performance of primary server
Easy setup

Log Shipping limitations:

No automated failover
Cannot synchronize faster than once a minute
Failover is more complicated than mirroring
Harder to view status of log shipping

File Shares vs. SharePoint

Michael Watson — Sun, 10 Dec 2006 03:56:00 GMT

I had a series of interesting conversations over the last few days with a storage server colleague about hosted file shares. He and his team hypothesized that a hosted share service would “cannibalize” our hosted SharePoint offering. Here’s my response to his notion that file shares and SharePoint compete against each other:

“It’s not about how SharePoint and File Shares compete, but about how SharePoint is not the right mechanism for certain scenarios and file shares fill that gap. File Shares are all about storing data, but SharePoint is all about connecting people to information. SharePoint is not the replacement for file shares. SharePoint is the UI that makes data accessible and useful no matter where it’s stored. In the future, SharePoint will store some amount of data, maybe all of it on file shares, but in the end SharePoint is not concerned with how data is stored. Rather, it exposes data to users in logical ways and helps those users interpret data to formulate information.”

So what are the scenarios where file shares make more sense than SharePoint as a storage technology, you ask? There are really only a few I can think of:

Databases and concurrently accessed application files – I’m not sure why you would store databases or application files on SharePoint. They have no collaborative value and any application using these files would likely connect to these files using a LAN protocol and not http.
Backups and dumps – Again, these have no collaborative value. I guess it’s possible that you may want a list of these files. In that case, you could store these files on a file share and use one of the share view web parts or build an application that indexes the share and stores the metadata in a list.
Files larger than 100MB – While it’s possible to store large files on SharePoint, I think File Shares are better at it. Often bandwidth constraints prevent users from completing uploads and downloads of really large files over the net. Again, you can store large files on shares and link to these files using SharePoint.
Large sets of files – The scenario here is that you want to store lots of related files in the same SharePoint folder. For example, maybe your organization creates an hourly report and wants to store many years worth of these reports in the same SharePoint folder. If they absolutely refused to organize this data in a hierarchal fashion, it would be best to store this data on a file share. While technically you could store this data on SharePoint, best practice suggests that you should limit any single folder to less than 2000 items. This is because management of large lists can become cumbersome and upgrades can be a challenge. Not that large file shares perform much better IMHO J