(Meet Don Conrad, affectionately known as Don SQL in the office. This introduction into the SQL arena paves the way for further SQL content from Don.)
Hello, I’m Don Conrad. I’m the Database/Systems Architect for Fpweb.net, a dedicated SharePoint hosting company. Hosting SharePoint sites for customers around the globe is our only business. As a leader in our industry, we host thousands of sites– everything from small Foundation environments to some SharePoint Server Enterprise multi-server farms that demand literally terabytes of disk space.
Hosting for SharePoint, a Microsoft product, also requires SQL Server, another Microsoft product. The underlying architecture for SharePoint fundamentally relies upon- and resides within- SQL Server databases. Curious, that.
I take care of those database servers and have about 20 years of experience doing so. My main job is to help plan, configure, install and administer SQL Server database servers and databases for our various SharePoint hosting customers.
Often times this means baby-sitting them. I occasionally talk to them in warm, quiet and caring tones. Or at least in tones that aren’t that loud.
Even as I write this, I suspect many of you know all that you want to know, and possibly even more than you care to know, about databases in general, and SQL Server in particular. Also many of you have full-time, highly-qualified and well-experienced DBAs.
But then not all of you do. Therefore much of what I’ll be discussing initially will be addressed to you, the select few.
Microsoft SQL Server is a complex, highly-configurable product. But its degree of complexity can also create issues. Occassionally it needs to be tweaked and tuned to give maximum performance in a given environment. What works well in a large environment featuring thousands of users and much online, transaction-processing doesn’t always work that well in a dramatically different environment. Say one where the main processing isn’t a high quantity of small transactions, but rather storing and retrieving large, relatively stable documents.
Perhaps even the experienced DBAs among you might glean a useful idea out of the wisdom I’ll be passing on.
Or heaven forbid, some of you may have found some more effective approaches or insights into SQL Server for SharePoint than I have. (I grit my teeth writing that heresy.) I urge one and all to use this site as a two-way forum. Please, oh please respond to my thoughts. Send in your experiences (I’ll make sure you receive due credit for your ideas, that is unless I can make some money off of them. Just joking.) If the ideas work for me, I’ll even use them and let you know what happens.
In the next several weeks, we’ll be discussing and describing SQL Server in rather basic terms. These words won’t get you a PhD in Database Science. Probably not even a Masters. But hopefully some will be useful, and perhaps give you food for thought.
In this upcoming series of Fpweb.net blog posts, we’ll address:
- A high-level overview of what databases are and how SQL Server fits the mold.
- A brief overview of SQL Server.
- The initial install and configuration of SQL Server. Both a general OLTP environment and in a SharePoint environment. We’ll discuss the how’s and why’s of the differences.
- Backup and restoring options for SQL Server. We’ll discuss the different types of backups and restores. We’ll discuss the pros and cons of the various models. Ideally, we’ll provide enough information to assist all customers in designing the backup process most appropriate for their situation.
- The role of the transaction log, and how it behaves.
- An overview of SQL Server security. I say an overview because its security can be quite complex and customizable.
Over time, I hope you all gain additional understanding of how to make the best use of SQL Server and its various components.
And again, I urge anyone who might not fully agree with my thoughts to let me know of that disagreement. Learning and discussing such differences help all of us better understand and use SQL Server. We’d love to hear what and why each of you do in your situation.
Until the next byte,