cjsommer.com

T-SQL Tuesday is a monthly blog party for the SQL Server community (or Microsoft Data Platform community. Although it’s called T-SQL Tuesday, it’s not limited to SQL Server database engine only). It is the brainchild of Adam Machanic blog | twitter.

This month’s tsql2sday is being hosted by James Anderson blog |twitter and this month’s theme is “Shipping Database Changes”. For this T-SQL Tuesday, I’d like to hear about your thoughts or experiences with database deployments.

T-SQL Tuesday is a monthly blog party for the SQL Server community (or Microsoft Data Platform community. Although it’s called T-SQL Tuesday, it’s not limited to SQL Server database engine only). It is the brainchild of Adam Machanic blog | twitter.

This month’s tsql2sday is being hosted by Koen Verbeeck blog |twitter and the topic is “The times they are a changing”. Basically, how are you handling the ever changing landscape of the SQL DBA. It’s a brave new world and the days of the point-n-click, drag-n-drop administrator are fleeting. Installing SQL Server. Checking backup. Performing health checks. A Jedi-DBA craves not these things!

If you are a SQL Server professional and are interested in spending a day with a bunch of other like-minded individuals, SQL Saturday is for you. It’s a day chock full of SQL Server related presentations given by other members of the community.

Here is a glimpse of my presentation on SQL Server Automation using PowerShell taken from the SQL Saturday event page.

Another great teaching opportunity landed in my lap this week. I got an email from a coworker looking for some help troubleshooting a SQL connection issue. He had an application server that could not connect to one of our SQL Servers.

We have a fairly complex and secure network environment. Multiple networks across multiple data centers with multiple firewalls in between. Because of this, one of the first things I typically look at is connectivity between application and database servers. The following question/answer session is how I attacked this particular problem, which led me to the actual issue.

Just wanted to put a quick post out there for the people who follow me. I very recently made a switch from Wordpress to Jekyll blogging platform and I am certain it will come with a few hiccups. At the moment I don’t have comments enabled, although I hope to add that feature this weekend. Also I do need to go through all of my posts and make sure images and code snippets all look how they’re supposed to. That will definitely be a work in progress for a bit as I have a number of posts to go through.

This is something that has caused me some grief in my life as a DBA. I hesitate to call it a bug, but this little gottcha resurfaced in a change that was submitted by a teammate just today. So I wanted to share while it was fresh in my mind.

When you script out a SQL Agent Job you’ll notice that the job schedule will have a schedule_uid parameter (providing your job has a schedule). The gottcha lies in that schedule_uid. If you create another job schedule with the same schedule_uid, it will overwrite the schedule for any jobs that are using it. i.e. Any other jobs that are using that schedule_uid will start using the new schedule. Normally I consider UID’s as very unique and chances of a collision are low, but if you do a fair amount of copying jobs between SQL Servers there’s a good chance this will bite you eventually. That’s what happened to us (more than once).

Summit 2013 in Charlotte, NC was my first and I remember it well. I went with 4 other people from my company but I was pretty new to the SQL PASS community (otherwise known as #sqlfamily). As a matter of fact I didn’t even know what #sqlfamily was at this point. I went to all of the PASS sponsored events like the welcome reception, the vendor party and yes the NASCAR party (which being a NASCAR fan was awesome). I went to all of the sessions and generally hung out with the other people from my company. I did get a taste of the after-life a bit, but for the most part I stayed in my comfort zone.

I think the title is fairly descriptive so let me put a little context around it for you. In my SQL Server environment we backup our databases to local disk. Unfortunately we don’t have unlimited storage for backups, which means we have to delete the old backups on a regular basis. A very typical practice in the SQL DBA world.

I was writing a new cmdlet for dbatools.io (Remove-DbaBackup to be released in October) and needed to decide how I wanted users to provide the retention for their SQL backups. I’ve seen a very wide range of backup retention requirements in my career (hours, days, weeks, months, years). I could have coded to the least common denominator of hours and greatly simplified my work, but I wanted to find a more flexible and elegant solution. The last thing I wanted was for people to have to fire up calc.exe, or worse yet having to take off their shoes to figure out how many hours were in a month. This is the function I came up with to create a more user friendly experience with my cmdlet.