I was recently chatting with a coworker, discussing why there is no discrete DROP permission for tables, procedures, etc. The conversation actually came from a #SQLHelp question on SQL Slack that was asked along the lines of “What if I want to let a user … [Read More]
In Year Three, I had a pretty big year. I kind of felt like I had peaked. I had received the Community Influencer of the Year Award and Microsoft MVP Award. Where do you go from there? Mostly, I just wanted to keep up what … [Read More]
Yesterday, I talked about batching deletes, and the day before I talked about how much I like to delete data, and why it’s necessary to do it, despite being a data pack rat. Today, let’s look at just one scenario, and how I like to handle it. In my experience, this is one of the most common purge requirements (and probably the easiest), so first, let’s look at the business requirements.
Yesterday, I wrote about the importance of planning your data purges. Today, let’s look at the simplest requirement for purging data: Keep data for X days after it’s created.
DBAs & Data professionals tend to be digital packrats. My personal Google Drive is filled with random files that I refused to part with–even though it’s of questionable value. I lament that I do not have a copy of every paper I typed in high school or college–and I envy those who do. You never know when you’ll need notes from that meeting 6 years ago, or when you’ll need that funny GIF you created for an inside joke you no longer remember.
The great tabs vs spaces debate is often framed as a matter of opinion or coding style. “As long as you’re consistent, it doesn’t matter.” Keep in mind that unlike your choice in footwear, coding style can’t be personal. I’m going to draw a line in the sand and say that tabs, like Crocs and mullets, are bad style.
SQL Server is great at a lot of things. I spend a lot of time blogging about all the cool things that SQL Server does. But (you knew there was a “but”, didn’t you) SQL Server isn’t great at everything. Lets write about something that … [Read More]
Have you ever forgot to commit a transaction? Maybe you’ve even left for lunch and caused a problem while you were gone. Uncommitted transactions can cause all sorts of problems–not just blocking, but it can affect your Availability Groups & Mirroring, your TempDB version store … [Read More]
During the course of normal processing in a database, blocking happens. Blocking is “by design” because your database is on ACID. In an OLTP database, most of your transactions are short in duration, so we expect blocking to also be short in duration. If blocking … [Read More]
If you’re familiar with supporting the database behind Microsoft Dynamics CRM, you probably know that it’s not the fastest-performing database. Honestly, that shouldn’t be a surprise–it’s not designed to be a screaming-fast database. It’s designed to be a flexible database. Most Customer Relationship Management (CRM) systems … [Read More]