User: What was that record before it was updated?
Me: I don't know. Maybe I could restore a backup?
User: Really? You have to do all that? It is just one record.
Me: (under my breath) Yes, a record YOU updated.
If you have ever had a conversation like this you know how difficult it can be to implement auditing of records as they change. With temporal tables, a new feature, we have the ability to track point in time information about a record without the huge expense of setting up auditing and tracking. While you won't want to use this on every table, when there are tables with sensitive data you want to audit from time to time, this feature will come in handy. We are happy to have Randolph back on the program with us to talk about this new feature.
The shownotes for today’s episode is found at http://sqldatapartners.com/2017/07/25/episode-106-temporal-tables/ and have fun on the SQL trail.
How can you tell when a change is enough of a change? How do you know you didn’t make too big of a change? Steve and I discuss some thoughts around what you might look for when you make certain changes. Some of the components we cover include Max degree of parallelism, cxpackets, virtual log files, the number of log files for a database, backup retention and memory.
The shownotes for today’s episode is found at http://sqldatapartners.com/2017/07/18/enough/ and have fun on the SQL trail.
Do you have any experience with [Insert random technology]? Your heart starts to race and your palms get a little sweaty. You don’t want to say no–we’re tech folks–we know stuff, but there are so many new things to learn! How are you supposed to keep up with it all? In this episode, we chat with Eugene Meidinger about his thoughts on keeping up and his ideas on the most important learning components.
The show notes for today's episode can be found at http://sqldatapartners.com/2017/07/07/keeping-up-with-technology/ and we hope to see you on the SQL trail.
When we write our queries to the database, SQL Server has to go and figure out the best way to go and bring back the data you asked for. A query plan is created to help SQL Server remember how to get the data for this query. It takes time to make these queries, so the database wants to limit the number of times it has to create the plans so it will try to reuse the plan as much as possible.
Our topic for today's episode is query plan reuse and the pros and cons with this concept. We will also touch on the concept of parameter sniffing--a technique SQL Server uses to try and figure out the best values to use for the execution plan with the hopes the plan will help the most queries. Special thanks to James Youkhanis for the suggestion.
The shownotes for today’s episode is found at http://sqldatapartners.com/2017/07/04/episode-103-plan-reuse/ and have fun on the SQL trail.