Cheers anyway, it's just rather bugging me.

Rich

Aye, thanks SK, but that still leaves me 20 odd gig out of pocket 🙂

Yeah, update stats, updateusage, dbreindex the works.

Looks like the report uses DBCC FILESTATS.

Has anyone ever used dynamically generated temporary stored procs to solve this type of issue?:-D

Excellent link Dave.

I had been going to say I could never get the @x = y or @x is null thing to work effectively - it always ends up scanning...

Now the problem is that the values "value1" and "value2" are in the wrong columns. We must interchange these with each other, putting the data in "value1" in the "value2"...

surely it depends on your system settings... I rather think I would get a failure: can't insert null into non nullable column... 😛

Haha fair enough, sneaky ninja action win.

:hehe:

WilliamD (4/27/2009)

---

Hi RichardB,

that is not Quest's fault, it will most likely be down to slow proc. or I/O problems (you did say they are dev boxes).

I don't think there is...

WilliamD (4/9/2009)

---

1. Either use the Database Snapshot and restore from that: really fast, because only the changes

...

2. Use SQLBackup from Redgate, we use it and it is screaming fast...

Only issue...

sounds interesting.

The main issues I guess would be around identities/autoincrements and anything with password in the call!

Do you have some way of resetting the database after?

What a crap question.

Can someone adjust this, its pretty bad. Plain wrong, in fact.

Fair enough - but if you haven't read the book I thoroughly recommend it 😀

Nice to see some analysis - but I would say that at least in http://kendalvandyke.blogspot.com/2009/02/disk-performance-hands-on-part-6-raid.html the charts are pretty misleading, you have to look hugely closely at the...