Re: Database Block Size

Hi Dave,

I suggest that you ignore that EMC advice. There is a maximum of 4 cache allocations in the EMC cache per physical disk.

@   Regards,
@   Steve Adams
@   http://www.ixora.com.au/
@   http://www.christianity.net.au/

-----Original Message-----
From: "Dave A" <dave_and_vanna_at_hotmail.com>

We are setting up a very high transaction database(OLTP) on EMC that currently resides on raw. Block sizes are the least of my concerns :-)

I told EMC that I wanted them to give me recommendations on database layout given that I have a handful of tables (about 300mb each) that are subject to constant, multiple full table scans due to the application being...well, a typical out of the box app.

EMC's advice was to put all of the "hot" tables onto the same disk! The logic was that this will cause thier caching algorithm to see that disk as needing to be put into memory and kept there.

We will also be using Veritas's QIO and from what they said, we should not worry about what objects are on what disk, but to strip e across all disks thereby having "automatic" load balancing.

Whichever route I take, one thing is for sure, times are a changin!

--
Dave A


"Nuno Souto" <nsouto_at_nsw.bigpond.net.au.nospam> wrote in message
news:39ed7a95.1663057_at_news-server...


> On Tue, 17 Oct 2000 15:49:35 +0200, "Frank" <frankbo_at_interaccess.nl>

> wrote:

>

> >Will go for 8k on Unix as from now on. Cooked, that is.

>

> Take it easy when using EMC boxes and/or Veritas.  That may change the

> ground rules. You may have to do some digging in the doco to find out

> the real block size for cooked.

>

> >BTW, I come across many (well...) sysops that are _very_ reluctant to

> >start off with raw fs. Cannot convince them always.

>

> Most of the "old salts" remember the pain it was to administer raw

> partitions in UNIX. Mostly not true anymore, due to the good crop of

> LVM's in the last few years.  But once burned, twice shy.  Very few

> new sysops even know what raw means. They just blame the EMC boxes.

> Most unfortunate...

>

>

> >Any war stories on terrible performing dbms's on cooked fs, that flash on

> >raw?

> >--

>

> Yes. But it was in AIX and about 5 years ago, so I dunno how relevant

> that would be today.  I can't see why, the basic principle of

> bypassing the cooked after-processing is still there.  But I reserve

> my opinion on this until I get a chance of trying it again by myself.

>

> Cheers

> Nuno Souto

> nsouto_at_nsw.bigpond.net.au.nospam

> http://www.users.bigpond.net.au/the_Den/index.html