Welcome to my first blog post of my good friend Ed Leighton-Dick’s (b|t) #SQLNewBlogger Challenge! A few weeks ago, he challenged new #SQLFamily bloggers to commit to writing 4 blog posts in April – 1 per week. The response has been tremendous and I am excited to read everyone’s posts.
Today, I’m going to write about how I’ve been using my sp_helpExpandView tool. I joined a new company in 2015, and their environment has many nested views. These views are a significant contributing factor to their performance issues. In order to address these performance issues, I am spearheading a project to consolidate nested view code. The first key step is untangling each view.
Why Are Nested Views Bad?
In brief, heavy usage of nested views will force the Query Optimizer to work through even more steps when creating a query execution plan. Each query within each nested view must be parsed. Keep in mind that when generating plans, the Query Optimizer only has a limited amount of time. It will not generate the “best possible” plan for your query, but a “good enough” plan. And often times that “good enough” plan is still a poor execution plan.
Imagine how much work SQL Server must do to put together a plan consisting of 5 JOIN operations. Now what if each of those objects were nested views, which contained their own set of JOINs. And underneath those, more JOINs. It can go on and on and on.
How Can sp_helpExpandView Help Me?
This is where sp_helpExpandView comes into play. I wrote it to aid in identifying every single object that a particular view makes reference to. My environment has views that are nested 7 levels deep. Another colleague who tried my tool shared that he was de-tangling a nested view that has 31 JOINs, plus sub-queries and UDFs!!!
When you run sp_helpExpandView against a view, with horizontal output, you can quickly see how many layers of nesting your view contains. You’ll be able to identify all objects that are referenced.
Another thing to look for is whether any tables are referenced multiple times, due to being referenced in different sub-views. The Query Optimizer may not be able to consolidate the repeated references, which could result in an execution plan that repeatedly references the same object unnecessarily.
Can I Check My Entire Database’s Codebase At Once?
sp_helpExpandView works great against a single view, but what if you are not quite sure where to start? Maybe your database has dozens or even a couple hundred views?
To help tackle that, I’ve written a companion script that executes sp_helpExpandView against all views on a database.
Tool – sp_helpExpandView All Views
This script saves each individual view’s output into a single table, then dynamically pivots the entire resultset to present it in horizontal format. I then export the entire resultset into Excel, which allows me to quickly skim, filter, and analyze my entire database with ease!
How Did This Help Me?
When I ran my companion script in Dev, I found that 2/3’s of our views were nested views! I was able to catalogue and prioritize which views’ complexity based on number of levels and number of objects referenced. Visually showing this output to my developers also helped them to realize how much work SQL Server was being forced to do. Because all of the other objects were abstracted away in the nested views, my developers didn’t fully realize and appreciate all of the objects they were querying when referencing one of these views.
Call To Action!
Does your environment contain nested views? Do you even know? Try out sp_helpExpandView and run the companion script (not in Production please). The results may surprise you!
Don’t Forget Everyone Else!
Be sure to read other posts by other #SQLNewBlogger participants! Use this Twitter Search to help you find them quickly!
Every Byte Counts 