I'm very sad to say that after 5 ½ years I am leaving Quest and, as a result, this will be my last column for Database Trends and Applications. I have greatly enjoyed writing these articles and I hope you have gained something of interest from them. There really is no better way to gain an understanding of a topic than to research it for a published article, and I would encourage everyone to start a blog and start writing as a personal development priority.
I have been working with SQL Server for more than 10 years now, and my time with Quest has been spent as a consultant visiting hundreds of customer sites, and discussing their environments and matching products to their issues. This has given me a fairly unique insight into how SQL Server is changing. It has also been intriguing to work closely with colleagues from the Oracle world, and seeing how their opinion of SQL Server has changed. They now take it very seriously, something I like to think I have played a positive part in!
The most striking trend I have noticed is the lack of expertise in some environments when using SQL Server. I can confidently say you are extremely unlikely to run an Oracle database without an Oracle DBA. However, in the SQL Server world this practice seems to be commonplace. It became particularly evident with the explosion in SharePoint deployments, which meant SQL Server was now everywhere, often almost completely unmanaged. Depending on how critical SharePoint is to the business, this can be "gotten away with"; however, once management starts using SharePoint, it can quickly become a focal point for their work and needs to be backed up, optimized etc.
I also found many sites (mainly internet start-ups) where there is a large and effective development team and no DBA. There are huge potential issues here, which tend to escalate based on the application's success. As the application scales (with a successful website, hopefully it will, and fast!), a DBA is crucial to help manage scalability, optimizations and effective DR strategy. Downtime in these environments is expensive, and failure to provision DR properly has seen some companies go out of business altogether. Change management tends to run out of control with huge frequency of production deployments with no proper UAT or scalability testing taking place. This can cause very complex issues to arise with no ability to roll back changes, resulting in loss of revenue. These companies tend to bring in a DBA at a later date, but trying to fix the issues retrospectively is significantly more challenging. Implementing change management means a change in working culture, which developers can find difficult. I am firmly of the opinion that a DBA should be involved in the development process to help ensure scalability and sensible database practices from day one. Building sensible indexes when the database is small, for example, is significantly easier than when it is large.
It is also common to find SQL Server DBAs looking after tens, or, in some cases hundreds, of instances. Again, this would be very unusual within an Oracle environment, and is challenging for the SQL Server DBA. Managing multiple instances is an area in which SQL Server is notoriously weak with the native tools. Microsoft obviously recognizes this with the introduction of components like the Management Data Warehouse, but areas like effective scheduling of jobs across instances are still difficult and time-consuming.
I am handing over the SQL Server column to Kevin Kline (www.kevinkline.com, www.twitter.com/kekline), who used to write it before me! Kevin is a hugely experienced database professional, a truly exceptional writer, and a valued colleague and friend. I am sure you will enjoy his future articles as much as I will.
Please let me know any comments or thoughts you have on any of my columns.
Email: iain@iainkick.com, follow me on Twitter: www.twitter.com/iainkick or visit my blog: www.iainkick.com