In the initial post, we talked about some very basic items to get you up and running with temporal tables. In part 2, I’ll cover a few more things to think about and implement when working with temporal tables.
In the first post, we looked at altering an existing table to be a temporal table. Now we will look at what is involved in making a table be a temporal table from the very beginning.
Temporal tables were a new feature in SQL Server 2016. They allow for the tracking of changes without having to set up change tracking, change data capture or triggers. For certain uses, they are not a replacement for something like change data capture, but would work if the purpose is simply having a record of changes. Temporal tables can also be used for auditing changes to data as well as point-in-time analysis where users might want to compare data changes over time, or even at a specific point in time.
I recently needed to configure log shipping for multiple databases at once as part of a migration project. I turned to PowerShell to do this.
But before we get to that part, this post assumes that you’ve done the upfront work to create shares for the backups to write to and for the backups to be copied to. This will involve providing the right permissions for the SQL Server service accounts involved in Log Shipping. If you are not familiar with this, that’s perfectly fine. Check out this article in MS Docs first.
I recently was thrust into a conundrum. I suddenly found myself in need of a speaker for a recent SQL Server Meetup this month. My co-organizer and I had one week to find a presenter, set up a new Meetup, and then publicize so people outside of Meetup would know about it. I decided that was too short notice to go out to Twitter and ask for volunteers to speak.
Dear readers, it’s been a little while since my last blog post. Life is busy and so I’ve been away for a little bit. I am hoping to get back into the swing of things with more blogging though.
I would love to hear from you. Reach out to me via email, [email protected], or on Twitter.
I am telling my story about steps I took to handle burnout, but I want to put a disclaimer at the beginning. I am not a mental health professional. Do not construe anything I say to be professional mental health advice.
I’ve always wanted to be a high impact person. I want my life to count for something. I think most people want that. In the United States, where the idea of “living the American dream” is prominent, this desire to make a difference and to live the dream often leads to people living life by going as fast as possible. By late 2020 I found myself doing that. I found myself going in too many directions.
So, I realize it’s now almost April of 2021 when I’m posting this. Normally this sort of post would come out in January for the previous year. However, I have a reason for this being late and I’ll actually post about that separately.
In mid-2020 I decided to give my blog more attention. there were a number of reasons for this. First, I’d already spent a fair amount of money over the years on hosting and related things so I didn’t want to waste that. Second, I really wanted to try to start giving back to the SQL Server community. I have been the recipient of a lot of learning and help through a number of regular, and occasional, bloggers. I have also purchased and mostly read my fair share of SQL Server books, which was another way I had been helped by the community. Third, I wanted a place to record my own troubleshooting and learning so when I needed to do something again, I would have a record of what to do. By the way, I have seen this repeatedly listed as a reason that someone blogs.
I currently manage 5 AlwaysOn Availability Groups. Two are on SQL Server 2014 and overdue for an upgrade, while three of them are on SQL Server 2017. From time to time I have run into a couple of different situations that I needed to troubleshoot and I want to tell you where to look and what to check on in these scenarios. I can’t possibly tell you about everything that could go wrong, but I can tell you about my experience with AlwaysOn Availability Groups and let you decide if that experience helps you or not.
Query Store came out in SQL Server 2016. It was the next evolution of Microsoft’s attempts to provide valuable performance data. In this post you’re going to learn a bit about the history of native monitoring in SQL Server, why you should be using the Query Store, as well as how to view the information made available in SQL Server Query Store. This post is just an overview meant to get you to jump into using the feature. This feature is rich enough that someone can present on it easily for an entire day.
Over the last 9 weeks I took you on a journey of skills and career topics related to being a SQL Server DBA. We looked at the Production DBA. We saw skills and career topics from the beginning to mid-career to Senior DBA. Then we looked at the Development DBA and their skills and career development needs. Finally there was a wrap up post.
To make it easier for everyone to get to these posts, I decided to bring them all together on a single page.