Thursday, April 22, 2010

SQL Saturday #30: Richmond Virginia

With all the excitement of my first trade show last week, and the mountain of catch-up work waiting when I got back, I forgot to take a moment to talk about SQL Saturday #30 in Richmond, VA. I had the opportunity to deliver my session on “Things You Mom Never Told You About SSMS”, man the SQL Sentry sponsor table and Sit in on a great session about table partitioning called “Loading Data In Real Time” by Mike Femenella.

This was a well organized event, with a great turnout. The folks that attended my session were all very attentive, had some good questions and even had some things to add during and at the end. The event was originally scheduled for January, but wintery weather forced a reschedule to April 10th. There was a great turn out despite that setback, and you really couldn’t tell there had been a setback at all.

In this case, Steve Wright (Twitter) and I got a late start out of Huntersville, NC on Friday, April 9th, and we needed to get back quickly to catch the plane to Las Vegas for SQLConnections Saturday evening. These two circumstances caused us to miss the chance to socialize at the speaker’s dinner and after the event, but I really enjoyed the time we did have there.

My hat is off to Jessica Moss (Blog | Twitter) and her team for a job well done. I am already looking forward to the Richmond, VA event next year.

Until Next Time,

-JRH

Friday, April 16, 2010

A Plea to DBAs: Please Share Your Toys

I spent the first part of this week manning the SQL Sentry booth at the Spring DevConnections conference in Las Vegas. It was a great experience meeting all of the existing and potential customers, learning the problems they face in their day to day professional lives and getting a chance to show off our brand a bit.

DevConnections’ larger theme was a launch event for Visual Studio 2010, .NET 4.0, and Silverlight 4.0. While there were lots of SQL Server professionals, and a dynamite SQL Server based session track, I believe that most would agree there was a heavy showing from the software development community.

While many developers write code every day that runs on SQL Server and related platforms, they are generally not the ones that get to monitor those environments. Those that do get to monitor those environments may tend to keep most of that data on their side of the fence. This is not for any sort of selfish reason though, but probably because it is a lot of data that is just not thought to be relevant to others, or not thought to be relevant enough to spend time passing it around in various formats.

During the event I talked to quite a lot of folks, and it became very obvious that developers were not only interested in seeing things like Top SQL, Blocking and Deadlocks, but they were also very interested in knowing the effects of their code on network, CPU, memory and disk resources. They were excited about seeing the Event Manager calendar that shows SQL Server events in relation to each other under the one context they all share, time, as well. Developers see all of the features listed above as very useful if not vital to providing ongoing support for the applications they plan, build, deploy and support.

SQL Sentry is a full featured enterprise system for assisting with performance optimization for SQL Servers, and some other technologies that may surround SQL Server such as Windows Task Scheduler and Oracle. The current focus being SQL Server based like the DBMS, Analysis Services, SQL Agent and Reporting Services. SQL Sentry makes it easier on DBAs by monitoring lots of things a DBA would normally spend a lot of time gathering manually, and it makes sense to think that since it does things a DBA does, it should also have the same security access that a DBA does. Usually at least sysadmin rights, and quite often Windows admin.

Any DBA reading this might cringe at the thought of developers having that level of security access, and in most places it is just not allowed. That doesn’t mean that developers cannot have access to this valuable information though. The SQL Sentry console application does not communicate directly with the SQL Sentry server. It simply reads data from the SQL Sentry repository. This means that someone using the SQL Sentry console needs nothing more than read access the that one repository database. The repository database even ships with some roles pre-defined to help lock it down even further (more info).

DBAs running SQL Sentry could easily provide the console application to a development group for use in planning, developing and supporting their applications. They could see directly how the target server already behaves and plan accordingly prior to deployment, during development. Every developer I talked to about this immediately saw the value in it.

My moral here is a message to the DBA community. If you run SQL Sentry, or a tool like it, that provides valuable information to DBAs as well as developers, please share your toys with the development team if it is safe to do so. In the case of SQL Sentry it is easy to lock down, and there is no charge for installing additional consoles. There is really nothing to lose. I promise you the offer will be appreciated, and you may even be rewarded by gaining a development team that becomes much more knowledgeable and considerate of your data environment.

Until next time,

-JRH