It's entirely possible for the stats to be perfectly accurate and the plan terrible. As in this case, there's more to estimation than just the stats.

Figuring out whether the plan...

Firstly, determine whether it's a problem that needs something to be done about.

Cardinality estimator assumes that, when there are multiple predicates, they are completely independent (if one affects half the table and the other affects 10% of the table then the combination...

Without seeing the execution plan, not really.

Shrinking the log shouldn't, by itself, cause performance problems.

Once you've monitored for a while (few days, week), run some queries on the saved data, see what the max used space...

Completely pointless and a waste of time.

The reason the...

charipg (10/20/2014)

---

db is in simple recovery model, log file is around 80GB,there is not much freespace to shrink file, trying to truncate but its not release the space.

SELECT [name],...

Nope. Simple recovery uses the log just like full/bulk logged does.

I seem to recall they were never released. I know there was at least one version where the symbols weren't released, think it was R2.

Maddave (10/17/2014)

---

Surely, all the other databases would only be affected if they had to autogrow at exactly the same time as when the disk was filled by the database with...

Did anything happen between when you ran CheckDB and when you ran CheckTable? Anything like an index rebuild or similar?

Not alone, no.

Is this related to http://www.sqlservercentral.com/Forums/Topic1625741-2799-1.aspx?

Safety net.

Autogrow allows for the log to not fill up if something happens to prevent log reuse. Something like an active transaction, unusually large data modification (eg archiving), failed log...

If you're running the Profiler GUI, absolutely, and you're lucky if that's all it does.

Views are just saved select statements. They have no data storage.

When you query a view, all SQL does is query the tables that the view references to get the data...