Featured Article(s)
Molecular MDX: Working with Time: First and Last Periods, Part 1
Part 1: Join BI Architect Bill Pearson as he introduces a subseries of articles focused on the retrieval of data from the perspective of time. In this article, we explore the OpeningPeriod() and ClosingPeriod() functions to select “first” and “last” time periods to meet various business needs.
SharePoint – How Are You Handling It?
I had a surprising conversation with Thomas LaRock (Twitter @SQLRockstar) yesterday (Weds) about working with SharePoint from a DBA standpoint. Specifically, it started off as a "be aware of SharePoint and what it installs so you can support it" discussion and pretty quickly turned into a separation of church and state discussion about application vs. SQL Server support.
Thomas has some clear and well-founded opinions about managing your applications and your database servers. Essentially (and this is my interpretation of our talk overall, not putting words in his mouth), his view is that a DBA should be focused on the management of the database server. More specifically, a DBA should *not* be working with SharePoint at any level specific to SharePoint. But, before everyone gets all up in arms about the SharePoint thing, it’s really more than that, and this is where he started to change my mind. If you take a step back, SharePoint is just another application running on top of SQL Server. So, not only should you not be messing with SharePoint (assuming you have the resources to have split personnel on your systems), but other applications are beyond the range of the DBA as well. DBAs should be focused on the database, providing for the systems, recoverability and so-on.
Interesting. My original premise was frankly very much in the other direction. That, as a DBA, you needed to be aware of and supporting the SharePoint installation. Not necessarily because you needed something new on your plate, but rather more that it was inevitable that you’ll be working with it (SharePoint) and that you’ll want to be able to intelligently support it. Thomas? Not so fast. Sure, be able to backup the database, recover it, etc. But tuning, tweaking and supporting web parts? Not so much. Clearly things could get out of hand quickly in having to support not only the core SharePoint installation, but the add-on components, the applications talking to it. Of course by extension, this would suggest that you take on other application support as well. Things quickly get out of hand.
The reality is that many shops are making the DBA also take on the role of SharePoint administrator. "It has a database, it must be yours to manage!" Perhaps drawing the line at the storage portions, recoverability, capacity management and the like… perhaps focusing there will help retain some sanity if you have the people to help split things up. I do think you should understand the requirements and growth of your SharePoint installation, but I can surrender to the concept that it’s not ideal to take on application support if you have the option.
I’m not sure we all have the option though. How do you approach this? Has SharePoint become the departmental database of the day ala’ Access where it just shows up and you are expected to work with it, or are you seeing more caution than that?
Did You Know?
Did you know that you can set up DDL (data definition language) Triggers to capture and manage schema change events? You can set up triggers on your schema so that if someone tries to modify a definition, the trigger will fire and can log the change, prevent the change or modify the change. Check out DDL Triggers in books online for additional information, or here’s a link to more information.
Featured Script
Collect Table Sizes
This proc will collect in a Admin DB table all the table sizes in the db it is run against… (read more)