Are scripts like sp_BlitzIndex and the others accurate on restored backups?

Question

I am a developer trying to get a better grasp of things. I am wondering if using the scripts from BrentOzar.com will work on restored backups? For example if I have the DBA give a backup of production, then restore that on my dev box, then run the scripts, will I get accurate information or is vital information lost during that process?

I am guessing that the answer is both yes and no. It looks like a good bit of the information that sp_BlitzIndex provides will work regardless since it seems to be based on the structure of the database. I am not so sure about sp_BlitzCache, etc.

I guess what I am asking is what types of things in these scripts won't work when running them on a restored backup and just as important, why not?

Thanks.

Answer 1

To answer the question of will you get the same results running an analysis such as Brent's sp_Blitz scripts in a non-production environment the answer will lie in what information you are trying to gather and what that information depends on. Take the two examples below as a means of showing the difference in results (or no difference) based on the type information sought.

1) Suppose I am interested in analyzing the indexes in the database to determine if I have duplicate indexes. To do this I would look at the database metadata which would be part of the database structure itself. In this case the results should be the same regardless of environment because the data that is being queried to draw the conclusion is part of the physical database structure. Brent's sp_IndexBlitz does this as one of the steps in its analysis, among others.

2) Suppose I am interested in analyzing an index to find out if the index is utilized. To do this I would examine the DMV (sys.dm_db_index_usage_stats) to determine if the index in question has any scans, seeks, lookups or updates. Using a combination of this data I could then determine if this index is making inserts run slower or is a benefit to select performance in a way that justifies its overhead. In this case though the data will be different in results between production and the non-production environment unless the exact same workload and configuration is running in both environments. Brent's sp_IndexBlitz also performs this same check and will provide the usage details based on the settings specified.

To further clarify on the "why would data be different" which seems to be a sticking point here lets dig in to what DMVs are. A DMV is at high level just an abstraction layer that provides a view of the instrumentation that SQL Server has running. With this being said as mentioned by Tony when SQL Server restarts the data that is within these DMVs is not persisted. For this reason when you perform a backup and restore it is functionally equivalent to a server restart for the purposes of the discussion around DMVs. Once the database has been decoupled from the original host of this instrumentation data the data would be lost unless it was persisted elsewhere. This is mentioned in Microsoft's documentation as shown below:

Remarks

Information returned by sys.dm_db_missing_index_details is updated when a query is optimized by the query optimizer, and is not persisted. Missing index information is kept only until SQL Server is restarted. Database administrators should periodically make backup copies of the missing index information if they want to keep it after server recycling.

From TechNet sys.dm_db_missing_index_details emphasis mine.

Hopefully the above examples have provided some clarity around when and why you would have differences between the environments.

Answer 2

BlitzIndex will return some useful information on a non-production server as it is analyzing various things, some of which have nothing to do with what queries are running. It should be clear to you when viewing the output what is relevant and what is not.

BlitzCache will not return useful information (or not much, at best) on a non-production server unless you run the same queries and load that are on the production server.

To answer your question as to "why not?", run them, review the output, and read the info at the URL returned in the URL column. There is way too much info returned by these tools to give you a line-by-line description of why it would or wouldn't be relevant on a non-production server.