My old laptop is faster then my PROD :)

Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

All Forums

SQL Server 2000 Forums

SQL Server Administration (2000)

My old laptop is faster then my PROD :)

Author

Topic

evilDBA
Posting Yak Master

155 Posts

Posted - 2007-10-04 : 16:36:21

Take the script I provide and execute it several times on any database. Take the best result (it returns the elapsed time in ms)

On my old laptop I get about 600ms. On the best PROD server I had 430ms - but it was with a standard RAID drives.

On any SAN EMC system it was a real nightmare. 800, 900, in some cases 1800ms!

Yes, I know why: because SAN EMC and other companies like it have a very good marketing. They manipulate with throughput numbers, but for SQL server, especially for the OLTP systems, reactivity is much more important.

They claim that 'our IO systems are so smart, that you can put LOG and FILES on the same drive'. And usually, there is no choice.

People who buy servers are hosting listen to that marketing blah-blah-blah and we, DBAs, need much later deal with high Disk Queue values.

If you can , provide the execution times of my script here. May be you have a good IO system and I was just so unlucky?

---------------------

set nocount on
GO
create table _Ptest (n int identity, k int not null, v varchar(128))
GO
insert into _Ptest (k,v) select 1, 'this is a test'
GO
declare @t datetime, @n int
set @t=getdate()
set @n=16
while @n>0 begin
  insert into _Ptest (k,v) select k+n,v from _Ptest
  set @n=@n-1
  end
checkpoint
select datediff(ms,@t,getdate())
GO
drop table _Ptest

SwePeso
Patron Saint of Lost Yaks

30421 Posts

Posted - 2007-10-04 : 17:05:28

I can post the result, but I would have to kill you later

E 12°55'05.25"
N 56°04'39.16"

rmiao
Master Smack Fu Yak Hacker

7266 Posts

Posted - 2007-10-04 : 17:59:40

We always separate data from log on SAN.

Haywood
Posting Yak Master

221 Posts

Posted - 2007-10-04 : 18:17:51

Wether SAN's perform well for databases or not all depends on the design.

I've seen them designed for OLTP speed and like DAS, you end up wasting a LOT of space on spindles (really expensive spindles in the case of FC attached SAN drives) - but your databases run like scalded cats**.

I've also seen them designed for managment of an infrastructure and the spindle sharing across the LUN's is a major killer.

** No cat's were actually scalded in the process of determining how fast the HP 1024 SAN really was. ;)

rmiao
Master Smack Fu Yak Hacker

7266 Posts

Posted - 2007-10-04 : 18:21:47

Agree, and also depends on if you can convince your SAN guys.

Haywood
Posting Yak Master

221 Posts

Posted - 2007-10-04 : 18:27:20

Fortunatly, where I was working on the XP1024, they were very concerned with database performance and not ease of server management. I didn't have to do much convincing of them. However, current employer is a bit of a different story...

Since moving to a brand-spanky-new EMC DMX 3 with one and half cabinets of disk, I've already watched my peak IO drop from 200MB/s to around 140MB/s.

evilDBA
Posting Yak Master

155 Posts

Posted - 2007-10-05 : 06:45:26

>We always separate data from log on SAN.

Are you sure that they are *really* separated?

I mean, if you have I: and G: both pointed towards the same SAN, aren't they using the same physical channel and the same queue inside the driver?

Any numbers to share, colleagues? Feel free to use a brainwashing machine from "Men in Black" if that info is confidential :)

rmiao
Master Smack Fu Yak Hacker

7266 Posts

Posted - 2007-10-06 : 00:18:26

Of course since we work with SAN guys together to configure arrays.

Subscribe to SQLTeam.com

SQLTeam.com Articles via RSS

SQLTeam.com Weblog via RSS

- Advertisement -

Resources