- Kevin Feasel
- Tracy Boggiano
Notes: Questions and Topics
Trying SQL Server 2022
Our first topic of the night was a quick discussion about SQL Server 2022, including some of the features forthcoming and how to try it out. If you haven’t tried it yet, the easiest approach at the moment would be to grab the 2022 CTP container. But if you want to try out the Windows version on a VM, that’s another good approach.
The next topic was around CVE-2022-29143, which affects all versions of SQL Server since 2014 (but probably not 2012?). As of the time of recording, there wasn’t much information available on this issue, as it was not an issue in the wild and sounds like the problem was discovered by Microsoft themselves or a customer and not a third-party security researcher. That means no cool websites, exciting names, fancy logos, or mascots.
Still, patch your servers.
SSISDB in Full Recovery Mode?
Our third topic came from an e-mail by friend of the show Mark Gordon, who ran into a SQL Server instance whose SSISDB was in Full recovery mode while pretty much every other database was in Simple. In this segment, we talked a bit about why having SSISDB in Full recovery mode may (or more likely, will not) matter. The short version: it’s probably not too important as long as you take regular database backups. But if you have it in Full recovery mode, that certainly doesn’t harm things.
Indexed Views in SQL Server
Our final topic came from Mike, who wasn’t able to make it to the show. He asked about materialized views, a concept in Oracle, and what the SQL Server equivalent is. The closest equivalent is indexed views, so I talked about them. One thing I just glanced upon but didn’t go into detail over was that indexed views are indeed different from Oracle (and PostgreSQL)’s concept of materialized views. SQL Server’s indexed views are truer to the concept of views-as-tables, in the sense that any update to the underlying tables also necessarily updates the indexed view. There is no concept of deferring updates or running them on demand. This means that you won’t get stale data from an indexed view but also means that they can be the cause of performance issues when the underlying tables are sufficiently busy.