Same reasons SQL won't automatically take backups or automatically create indexes for you, impossible to decide correctly for all possible situations and guessing wrongly could open MS to liabilities.

Why not?

The scalar function will do the...

This should work as long as you don't have multiple rows being returned from that subquery

SELECT dbo.nomfil.nomcode ,

ISNULL(calc.val, 0) AS ytdper...

SQL will never, under any circumstances, run CheckDB automatically. That would be a very bad thing.

It returns the number of executions since that procedure's plan was...

All I can tell from that is that CheckDB is scheduled to run daily and is running daily.

I would say it's a lot of work, a lot of design required, easy to get wrong.

The better solution would rather be hardware and...

Without seeing the 'six lines' which you refer to, no idea.

A database is attached to a single SQL instance only. To scale out, you'd have to work out how to split the database into multiple databases and change the applications...

Key lookup might be bad....

MyDoggieJessie (4/3/2014)

---

Rather than adding the column to the '"leading edge" you might want to consider adding it to the end of the index...this may help with the overall selectivity of...

I think, as for almost all hints and options, it's a targeted solution to specific problems, not something to be put on every procedure blindly.

If your monitoring for multiple days in a row, I wouldn't use trace. Data volume can get way too high. If it's a small number of procedures you want to...

Could slow down data modifications. It's not something I would run on production except in exceptional circumstances.

To help you we need to see the execution plan (actual), table definitions and index definitions. Otherwise we're just guessing.