Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: RAC versus simplistic load-balancing of replicated databases

Re: RAC versus simplistic load-balancing of replicated databases

From: Joel Garry <joel-garry_at_home.com>
Date: 4 Jun 2003 16:02:14 -0700
Message-ID: <91884734.0306041502.346a984f@posting.google.com>


murphy_at_genome.chop.edu (Kevin Murphy) wrote in message news:<7782b51c.0306040942.2ec3c9a8_at_posting.google.com>...
>
> Q: one person referred to a ram disk. This is interesting to me.
> When using a ramdisk, would you try to disable Oracle's buffering as
> much as possible? When would you use a ram disk as opposed to giving
> Oracle tons of buffer RAM?

I am also interested in this question. I think it is moot, though, since the purpose of a large SGA is to essentially do this, and Oracle's updating protection mechanism is designed around it (that is, the redo logs are important to protect the db from a crash, so at times when you are updating, you want the redos on a (ahem) real fast real disk). But anyways, there are some issues with large SGA on certain unix platforms, so you will have to deal with them during the initial setup, there are specific notes on metalink about this (I haven't done a large linux, so I don't know).

For the curious, here are instructions someone sent me on how hp-ux 11 could do it (I haven't tried it, but looks interesting):

#Modify your kernel to include the "ram" driver:

cd /stand/build

/usr/lbin/sysadm/system_prep -v -s system

vi /stand/build/system

# Edit the system file and add the "ram" driver

mk_kernel -s system

mv /stand/system /stand/system.good

cp /stand/vmunix /stand/vmunix.good

rm -rf /stand/vmunix/dlkm.good

mv /stand/dlkm /stand/dlkm.good

mv /stand/build/system /stand/system

kmupdate

shutdown -y -r 0

# set up the device files and mount the ramdisk:

# create the device files with major 9 (both b and c),

# and minor 0xVSSSSS, where "V" is the volume num,

# and "SSSSS" is the number of sectors in the ram

# disk, each sector is 256 bytes.

mknod /dev/rram1 c 9 0x101000

mknod /dev/ram1 b 9 0x101000 # that's 1MB

mkfs -F hfs /dev/rram1 # no point in VxFS here

mount /dev/ram1 /ramdisk

> Let me know if something seems outrageously wrong with this. It
> really doesn't to me (except for the possible Oracle license
> situation). I'm afraid too many people in the bioinformatics

Definitely check out the license situation! It is not a linear function.

> community are addicted to large clusters, which are mostly required
> for computational purposes rather than data retrieval. And even the
> big bioinformatics groups that are mostly database-focused, such as
> http://www.ensembl.org/, have large setups -- they run their website
> off of six 4-CPU1.25 GHz Alpha ES45's with 16 GB RAM each. They take
> 3 million requests per week, which doesn't seem like very much for
> that amount of hardware. I got a price quote on the Ensembl
> configuration, and it's ~ $100K per machine, not counting the fact
> that they are clustered. (They use mySQL, by the way; maybe that's
> the reason why they need so much power ;-)
>
> There is now no question in my mind that our application can run even
> on a partially populated 4-way machine ... partly because a similar
> precursor site already works in a lame database (4D:
> http://www.4d.com/ -- I don't recommend this product for large-ish
> databases!) on a wimpy Mac OS X box . As you all have pointed out,
> the size of the DB and the fact that it is read-only and updated
> infrequently makes this a no-brainer.

Well, it really depends on what those reads of yours are doing. If very numerous requests for complicated joins of the same data are coming in, Oracle could be a big win. If it's just a bunch of separate full-table summation scans, it might not...

> [1] The rationale for this is that bioinformaticists tend to know
> Perl and write a lot of data filters in it. Perl is a beautiful
> language for manipulating text and getting one-offs done quickly. And
> with a small, underpaid, and/or work-study programming staff
> characteristic of academia, there are good reasons to use as few
> languages as possible.

Amen. Thar be steep learning curves in Oracle.

jg

--
@home.com is bogus.
Large linux SGA:  http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=211424.1
Received on Wed Jun 04 2003 - 18:02:14 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US