Michael Valentine Jones (5/27/2011)

---

Paul Randal address the whole tempdb data file per processor core story here:

A SQL Server DBA myth a day: (12/30) tempdb should always have one data file...

Not being familiar with how Compellent SAN's are configured - I have to wonder if each LUN was carved out of the SAN using separate spindles. Or, as in...

Mark Horton-381871 (5/26/2011)

---

Ok, so a LUN for data and a LUN for Logs, etc. What about a LUN per data file? My Db has 5 data files. ...

Jeffery,

I thought I read that in either SQL Server 2005 or 2008, updating records with fatter varchars no longer caused page splits. That may not be so but I seem...

Jeffrey Williams-493691 (5/20/2011)

---

Lee Crain (5/20/2011)

---

(Referring to the specific circumstances of the original poster) If so, and "IDENTITY INSERT" were set to "OFF", and FILL FACTOR were set to 100%, wouldn't...

TheSQLGuru (5/20/2011)

---

For THIS poster's table (which has PK on identity) I agreed that your statement was correct. But it is NOT generally applicable, and many people read these forums...

TheSQLGuru (5/20/2011)

---

Just a suggestion: If all of your I/O activity on the table consists of insertions of new records and deletions of old records, I would consider setting the fill...

GilaMonster (5/19/2011)

---

p.s. What would you suggest instead of...

Oh, got it. Glad I didn't need to be clubbed over the head with it.

:hehe:

LC

After having read every post in this thread, I have to say that I pretty much agree and maybe even somewhat disagree with all of you. As a software developer...

I've worked with some developers that I am pretty certain were not people. :alien:

:hehe:

LC

Yes. What I am going to suggest that you evaluate will not release space back to the...

Steve Jones - SSC Editor (5/18/2011)

---

It's not intermediate pages, it's that a rebuild of the index creates a duplicate index. Because it's transactional, it builds a new one, uses space...

GilaMonster (5/16/2011)

---

Restart SQL. No need to do anything else, the transaction will finish rolling back during crash recovery (it's just kinda stuck, probably waiting for something it will never get),...

I am missing something.

Are my "SET" statements not assignments?

DECLARE @test_dt DATETIME

SET@test_dt = DATEDIFF(D, 0, GETDATE());

SELECT@test_dt

DECLARE @x DATETIME

SET@x = @test_dt

SELECT@x

Both "SELECT" statements produce the same "timeless" timestamp.

LC