you can search for the white paper on their site, forgot where it is

or pm me with your email...

interesting, might explain our challenges in replication we had

one other one is SQLMAIL, it's no more and will not work. in 64 bit only dbmail will work

emc says that for performance they recommend to scale out instead of using dedicated disks

i never understood this thing of having a tiny c drive and installing every app on d

some people watch too much Monk

i would create tempdb files on a separate RAID1 volume and limit the growth of the ones on the c drive

there is no right answer and it's all CYA

where i work DBA's always took care of the SQL servers down to doing windows updates and installing windows, sql, etc. but...

ask your SAN vendor since they all have different ways to configure their SAN's

colin Leversuch-Roberts (2/27/2008)

---

I just noticed you mentioned SAS - watch out for sata drives in your SAS trays! Sata and sas drives spin slower usually 7.2k and 10k this...

we are migrating to a new DMX next week

EMC told us that when you put devices on LUN's mix and match with high I/O apps to low I/O apps for...

we do have a clustered index and always did

it used to be the identity column that's the PK and we changed it the index to be on the non-pk column

PK...

two different issues

SAN will let you manage your storage centrally and you can replicate the data to another SAN at the storage level without worrying about mirroring or log shipping

colin Leversuch-Roberts (2/25/2008)

---

you do want to go 64bit, forget x32. As for the rest I agree with Steve it's just difficult to know. I will disagree about NIC's there...

yes

we used to have a clustered index on the PK column which is just an identity column and now we switched it to a non-PK column which is a bigint...

our index redesign is done and i'm still seeing these issues

next step i'm going to try the pad index option

if you can connect by IP it's not a firewall or connection problem, but probably a DNS resolution issue