DBA School – only a couple of seats now remain
[Register Here] or [Get More Information]
Featured Article(s)
Moving SQL Server logins with SQL Server Integration Services 2008
In this article I describe a generic scenario of how you may transfer login(s) from SQL Express 2005 to SQL Server 2008. After migrating data from one server to another you may need to transfer one or more logins so that users of the transferred data can access their data on the new server. The logins transfered are initially disabled and set with a random password. It is the task of the administrator to enable and change passwords for the transferred logins.
SSWUG Fall vConference – HUGE Savings until 8/15
Extreme early-bird registration savings on the Fall vConference are available now. They end on Saturday, but you can get access to the entire conference – more than 75 sessions, live tracks (each day) SQL Server, Business Intelligence information and more. You get access to the entire conference for price. We’ve removed the disciplines and opened it up for areas. You can get a lot more information here, at the site.
[ Register Here ] or check out the vConference details here at the site. All-new sessions, all new content, the live track, the return of the Chris and Steve show and much more.
Some Final Thoughts on SharePoint
Carmelo writes in about SharePoint with all-too-familiar points: "First, the DBA team is a complete afterthought when it comes to Sharepoint.
I have had to setup alerts to tell me when a database is added or *restored* to a server. I routinely find databases with configuration options set incorrectly that left unchecked cause problems. The two biggest are SIMPLE recovery mode and AUTOCLOSE = ON. The first causes failed log backups with the loss of point in time recovery. The second causes performance issues impacting the entire server. Many times these databases are developed and maintained on SQL Express and developers are unaware of inherent differences. The Sharepoint team operates in a complete vacuum and believes they should have complete autonomy with *their* databases. This should not be a tug-of-war but it should be a team-effort.
Second, when poor database performance occurs the DBA and the SQL Server are blamed. Of course "it worked in test." This is not a new phenomenon but frustrating none the less. DBA involvement with application database development provides on the job training for the developers and makes them better at their job. In the same way, DBA’s now understand the intent of application processes and are better able to help tailor the proper data structures.
Both of these issues point out that DBA involvement is *required* for database issues. Sharepoint is just another application using a database, and standard software development rules and separation of duties *should* still apply. In a small shop where one person does it all, ensure the proper training is available for all facets of Sharepoint implementation (Sharepoint Development and Admin, SQL Server Admin, Windows Admin). In larger shops, we should all use specialization as a team building strength, and not to create barriers between disciplines."
Interestingly, I think SQL Server 2008 R2 will help with a lot of this with the server-management work that’s been done. By having appropriate policies set up and monitoring servers, you’ll be able to go a long way to at least knowing that new things are happening on the system. You’ll then be able to apply your best practices and policies to those new databases. Of course this doesn’t answer the departmental systems, where the servers aren’t in a managed set of servers, but rather "out there" in the wild.
I think the huge lesson in all of this is to be proactive. Get out there with departments, look solutions and ways to work together on identifying what needs to happen. What you haven’t seen are the emails with people writing in afraid to approach their IT department with their SharePoint installation questions and ideas. These folks are almost literally hiding the fact that they’re doing SharePoint because of a fear of what might happen if they weren’t able to manage it. At the same time, upkeep, management and troubleshooting are not their forte’ generally and things are much better working as teams, rather than split-up groups.
Featured White Paper(s)
Open Database Connectivity
Database connections are the lifeblood of enterprise applications, administrating the secure and steady flow of information b… (read more)