ruyfigueiredo (9/30/2008)

---

The problem is that the log files increase a lot.

I have an database with 250MB and a Log File with 24GB.

After i reconfigure the Autogrowth i have to made...

On top of what these guys have very correctly told you, put a limit on the growth of the database so that it won't fill the drive. A full file...

You'll have to drop all foreign key constraints against the table first by using

ALTER TABLE OtherTableName DROP CONSTRAINT ConstraintName against all the related tables. Then you can use ALTER...

You have to have a way to differentiate which value belongs with which row. I know this is probably not exactly what you're looking for, but something like this is...

With these estimated plans, there's almost no difference. Some of the estimated costs are slightly different and the location of the table scan of 'RO' changes between the two, but...

I guess I don't understand the question. The storage engine does the data retrieval, including sorting and aggregating the data, as you said. What is the concern with where this...

The proc doesn't look so complicated that a RECOMPILE would take six seconds... Hmmm.... You may have to go to old-fashioned tuning. What do the execution plans look like?

It sounds like parameter sniffing. Try adding WITH RECOMPILE to the procedure and then run it again. That won't help tune it, but it will prevent you getting a bad...

If it's ASAP, look it up in Books Online. That's what the documentation is for.

It really depends on whether or not you're calling a scalar or table valued function.

A scalar...

Funny that we both fixed the JOIN as well as putting in the IF.

Well, normally I'd say to stay out of my head, but since you posted first, I'll try...

jlp3630 (9/29/2008)

---

Is there anyway to "short-circuit" a query? The following query generates the same "actual execution plan" regardless of the @brand_id value (null or non-null value):

DECLARE @brand_id INT;

SET @brand_id =...

Exactly right.

It also brings up nullability, which should be used as sparingly as you can.

Oh, and files and file placement. Minimum, split the data and the log to two different drives. After that, it depends on the types of drives you're working with, the...

Unless there's a very good reason for it, most tables should have a clustered index. Be sure that, even if the database is normalized, it has appropriate primary and foreign...

I'd suggest running a trace while the events are occurring. Collect the data out to a file. You can then import it back into a table on a different server...