Redgate Evangelist YouTube Channel: Tutorials on Database DevOps -New videos each week – Watch
Redgate Streamed – a 3 day free virtual conference on the Microsoft Data Platform – Watch here
Level Up Your Deployments for SQL Source Control – Watch
Key findings from the 2020 State of Database DevOps Report – Watch
Managing and Automating Test Datasets for DevOps with Jeffrey Palermo – Watch
How to Make Your 2020 Monitoring Strategy a Success, with BMW’s Tony Maddonna – Watch
Essential Practices for High Performing Database DevOps Teams – Watch
Fast and Reliable Development with Redgate Solutions for SQL Server – Watch
Implementing Data Masking for NIST Compliance – 1 hour – Watch
How Developers and DBAs Collaborate in a DevOps World – 40 minutes – Watch
How DevOps Keeps DBAs Safe from Being Automated Out of a Job – 1 hour – Watch
DevOps: What, who, why and how? – 1 hour – Watch
Can This Team Succeed at DevOps? Panel discussion – 1 hour – Watch
am going to post my monstrously big index query.
Why? Because it’s AWESOME. No really, it actually is awesome. At least, if you like that sort of thing. I use some variant of this almost daily, and I tweak it fairly regularly to suit the needs of whatever I’m working on. So it’s a work in progress, but I find it constantly valuable.
Awesome? Oh Really? Why?
This query describes the size, basic definition, location, number of rows, partition status, and enabled/disabled status for all clustered and nonclustered indexes in a database. I typically sort them by descending size, since my primary usage is when a drive space alert fires, or when someone asks one of the million “how much space would it take if we wanted to [x]?” questions.
When you are working with a database which has many indexes that are partitioned over multiple filegroups, which are spread out over multiple drives, this can be very useful when a reindex fails due to a file filling up. Or when you want to estimate how much free space you need to main in a given filegroup in order to be able to reindex the indexes using it.
One reason I started this blog was just the idea of going through my catalog of scripts and reviewing them and sharing out what might be useful to people.
Here is a quick one I put together a while back. I was starting to work with a group of servers [at an unnamed company, always an unnamed company!]. Some of the instances had been configured long ago, and I found some linked servers where passwords had been hardcoded into the login mappings.
This can be a big security vulnerability, particularly if the option has been chosen to map all users to that login, and the login has significant powers on the other end of the linked server….