2015 in Review

With 2015 coming to a close, so does my first year of blogging. Technically though, I started this blog around February, so I’m still a couple of months shy of a full year. I’m glad that I started along this path. It’s definitely gotten me to study some topics and practice writing.

My original plan was to write two posts a week, every week. That would have put me at around 100 posts for the year. I didn’t even get close to that, but I did manage to average about two a month. That’s not terrible, but I hit a few weeks where I just couldn’t bring myself to write. I also helped train two new DBAs this year.  Coming up with fun challenges for them took a lot of time out of my normal blogging schedule.

Hopefully next year I can write 1.5x as many blogs as this year. I’d like to set the goal of writing twice as many blogs as I did this year, but after my initial lofty goal, I think I should set my sights on something a bit more realistic.

As for blog views, initially I had very few, and in the grand scheme of the internet my views are still abysmally low, but for almost no advertisement, I feel they are respectable. Consistently my most popular posts were anything related to PowerShell automation, which people found through desperate google attempts. Each of my TSQL Tuesday posts saw a lot of traffic for the month they were published in as well.

Finally, I also started a Twitter account this year. My number of followers is still only a handful, but I cannot expect much since my posts are few and far between and far from exciting. I’m not much of a social media person. It seems I’m not just an introvert in real life, but online too.

Here’s to a strong 2016 with lots of blogs, tweets, and learning!

Here’s an excerpt:

A San Francisco cable car holds 60 people. This blog was viewed about 1,600 times in 2015. If it were a cable car, it would take about 27 trips to carry that many people.

Click here to see the complete report.


T-SQL Tuesday #73 Naughty or Nice?

TSQL2sDay150x150_388014A5This month’s topic for T-SQL Tuesday is hosted by Bradley Ball (blog | twitter) with the subject of server environments.

As you work with SQL Server look around you. Is your environment Naughty or Nice? If it is Naughty what’s wrong with it? What would you do to fix it? Do you have a scrooge that is giving you the Christmas chills? Perhaps you have servers of past, present, and future haunting you. Maybe you are looking at SQL Server 2016 like some bright shining star in the east.

I won’t discuss my current environment, but I do have a frightening story of SQL past.

At a previous employer, I worked in a hastily built environment that never had the benefit of a DBA or Database Architect during setup.  The company started small, so originally they used Microsoft Access to house all their data. At some point, the tiny IT department migrated all the data over to a SQL Server database, but they still ran an Access front end.  The migration was done by people who were not concerned about normalization.  The goal was to move the data, structure was a tertiary concern at best. Many sins were committed in that database, and as the years went by and the data grew, the sins became more apparent.

Querying became a nightmare.  The number of nested functions, within nested functions, within nested stored procedures, was exhausting. I remember finding a procedure that had 14 levels of nested objects. I had to keep notes of object names as I delved in, trying to understand what was happening in that query. I’m still not certain I understood it all.

The real problem though, was that every user also had Excel reports that were direct connections to the database. The wait times were high from all the external hits to SQL Server, but the connection strings…oh the connections strings…

Every single user connected to the database via the SA account. Which was not renamed.  At least the password (which was from the beginning of time) was moderately complex.  However, each user could display the connection string to the database in plain text with a bit of poking around. There was no limit to the mayhem they could commit.

Since every user was connecting as SA, the only identification possible was by IP address. And since everyone always locks their computer in small company… it was not the best method for identifying a nefarious user.

I did try to get the SA password changed and the account locked down, but it was an arduous process. The old database was delicate, but even more unknown were all the individual reports and local connection interfaces created over the years. Interrupting business was frowned on more than the unlikely possibility of a user misusing the SA account. A few changes got made, but until the database and user interface was rebuilt from the ground up, nothing was actually solved.

Security is a major concern, and something like a global server admin account should always be kept tightly controlled, no matter the company size or trust level.