Everything is a balance. Just make sure you're breaking down the procs appropriately, not just to arrive at arbitrary small queries. But some degree of nesting, depending on how and...

I don't currently have an availability group set up in order to validate your script.

Probably, but not definitely. Or, more accurately, maybe not as much as you want. It's best to measure your performance to understand what's going wrong and why. Then make changes.

Still trying to figure out what the use-case for multi-statement table-valued user-defined functions is. But, other than that, yes!

Sean Lange (12/9/2014)

---

Here is where I am going to disagree with Gail and Grant. I have worked on a system that had many procs nested like this and it was...

OK, so, the last two make sense, it's waiting on the disk and on the log. The first one suggests CPU use. So, we're kind of back to where we...

Alvin Ramard (12/8/2014)

---

hmmm

That's news to me. A quick Google search found sources that agree with you and others that do not. Since one that agreed was a Microsoft...

No, you can't reset that flag on your own. It's done by running a successful backup. The indications are not that the last backup didn't reset the flag, rather that...

Well, before you rearrange your table structure, are you hitting a problem? I recognize that the existing cluster is not an optimal choice for the clustered index, but, is that...

Because SQL Server doesn't compile a procedure on a line-by-line basis. It compiles the entire procedure, all at once. So, if you have syntax errors, you'll get an error, regardless...

Assuming you've configured the multiple files appropriately (see all the blog posts over at SQLSkills.com on how to do this), no, there is no negative impact combining these two. If...

You can simply open the system_health output file in the Extended Event explorer window, or just browse to the file from the Open File menu and double-click, SSMS will figure...

I do think the risk is small (-ish), but unless we're talking domain hops, most networks these days should be able to handle running the backup across to a shared...

And remember, the conversions, implicit or explicit, are only issues if they occur in HAVING, WHERE, & ON criteria. Data conversion within the SELECT doesn't matter.

You can use the dmv, sys.dm_os_wait_stats. If you query that before and after running your query, you'll get a pretty good idea of what is causing things to slow down...