| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: Re: Re: Sizing - RAC, storage subsystem EMC
Hi Arup,
Thanks for the reply.
(was beginning to wonder if my 2 pence was really not worth
it...
Jared..please feel free to ask me and arup to take this
discussion
offline if u find it 'out of context' or 'useless to everybody
else')
RAC is usually 'pushed' as
a solution for 'load balancing' in addition
to its high availablity
that is where
"RAC is nothing to do with the size of the
>database;"
comes in...
cos I personally think the 'real limit of tuning is hit'
due to the size of datasets
(I mean why would i bother with a FTS on dual :) )
Having said that...
Let me think aloud about the High availability thing
what are the failures we are looking at
(lets forget RAC for a moment ;) )
1. Disk failure....
2. Node/CPU failure
Now finally we come down to Node failure in the context of RAC.
Now my question is...what are the 'usual reasons'
for a node failing?
1. Power failure
2. Hardware problems
So finally again we have narrowed down to Hardware issues as the ONLY issues which RAC can address.
My quarrel with oracle (not any of you guys around here ;) )
marketing RAC
as a solution for High availablity is that
it addresses ONLY hardware issues of failed node.
(cos anyway if there is a power failure then both the nodes are
going
to fail...the last I heard was from Oracle ...Oracle wasnt too
comfortable implementing RAC/OPS on geographically remote
locations
which alone I think will justify RAC as a high availablity solution!)
I personally doubt if we lose (or if anyone has lost any
transactions)
due to hardware failures of the NODE (NOT disk subsystems)
cos Oracle database treats it as an instance abort
and does instance recovery
(please correct me if anyone has instances of hardware failures
of nodes creating any serious problems to the database)
Finally we come down to RAC saving us from a maximum down time
of 30min (surely we are in an age where hardware vendors can
surely
offer swappable nodes :) )
Then my honest question to people who have worked on RAC would
be
does this really justify
a. the $/Rs cost (we cant run away from it :( )
b. the agonizing over the 'unique RAC' problems?
Finally, I am really curious to know what type of systems run on RAC which cant afford a down time of 30min do these systems actually run without a boot for years!
cos I vividly remember discounting Oracle database
for 'real time processes'
(like using Oracle database as 'any component' in an
automated workshop type of scenario)
Of course, I am just thinking aloud.
I am not leading a movement here for downsizing :)
and am not holding a brief for anyone :)
Finally, I have a BIG doubt,
this entire 'structure of RAC' stands tall on
a 'small piece of cable' between the 2 nodes
(the private link) on which the heart-beats travel.
My question is what happens if this private link goes off!!!
(of course the same scenario applies to the 2nd link which carries the inter-instance blocks :) )
Just asking cos we really had a situation with OPS
where both the instances used to hang and
we used to be 'back to 30min downtime'
for NO 'good reason' :(
Just wondering if Oracle has fixed it up or Network vendors have grown smarter :(
any information on above will be helpful :)
Thanks
Cyril
On Sun, 25 May 2003 Arup Nanda wrote :
>Cyril,
>
>You don't just recommend RAC just for the heck of it; the choice
>is a
>manifestation of one's business requirements. Your question was
>what could a
>compeling reason behind choosing RAC; I could give a few
>scenarios.
>
>RAC is not a money saving technology; it's a fault tolerant
>architecture.
>Typically, SANs are fairly robust, at least more torelant than
>servers. RAC
>merely reduces your risk of a database failing by distributing
>the load
>across all nodes of RAC. Should a node fail, the other will pick
>up the load
>and continue processing. In a business environment where failure
>has to be
>absolutely minimized, RAC is the answer. This can be addressed to
>some
>extent using standby databases, but you run the risk of losing
>the last few
>transactions that could be present in the online redo logs yet to
>be
>archived. Multimaster database replication offers the redundancy
>too, but in
>an asynch setup you run the same risk of loss of committed
>transactions and
>synch mode operation costs a lot in performance. Besides, standby
>databases
>and replication solutions cost double the disk space, meaning
>money and as
>Rachel pointed out, that means some resistance from the bean
>counters and
>double the amount means double the resistance.
>
>I am not sure I undestand the relationship of huge datasets and
>the use of
>transportable tablespaces and RAC. RAC is nothing to do with the
>size of the
>database; but with the uptime requirement.
>
>About some uses of RAC I have seen where they were absoutely
>necessary were
>insurance comapnies who cannot afford to lose a single
>committed
>transaction. Or take brokerage and finacial services companies
>RAC whose
>requirement is the same. In these cases RAC is the only solution.
>However,
>extremely high uptime requirements, like in a stock market,
>probably dictate
>more robust architecture like the ones offered by Compaq (now HP)
>Himalaya
>severs, extremely fault tolerant but very propietory.
>
>No, I don't work for Oracle, Yahoo or Southwest; but for a
>"small-ish"
>company and our requirements of uptime justify RAC.
>
>Hope this helps.
>
>Arup Nanda
>www.proligence.com
>
>
>
>----- Original Message -----
>To: "Multiple recipients of list ORACLE-L"
><ORACLE-L_at_fatcity.com>
>Sent: Sunday, May 25, 2003 3:23 AM
>
>
> > Hello,
> >
> > For quite some time I have been wondering
> > whether we (the DBAs) need to 'go slow' on 'recommending'
> > RAC (considering the HUGE investments required
> > to get it up and running)
> > in view of the present...'scenario'..
> >
> > Can we have 'some repository' of 'real experiences'
> > (I mean not the type of experiences Oracle Marketing
> > routinely totes up :( )
> > with RAC?
> > (cos I cant believe that there could exist any business
> > which needs to be supported using such costly stuff :(
> > and which does not have a cheaper/better alternative)
> >
> > Can someone please suggest if it is a basic database design
> > flaw which leads to the requirement of such costly
>technologies
> > like RAC in the first place?
> > (I mean if the dataset is huge why not use transportable
> > tablespaces
> > and keep 'regularly purging' the database of 'old data'?)
> >
> > (oh ok..now please dont take it personally and assume
> > that I am nit picking on someone/anyone who is
> > using/recommending RAC
> > ....it is just that I want to explore and understand
> > alternatives!)
> >
> > Can someone point to some 'good reasons'
> > (please do not cut and paste from Oracle documents!!)
> > where RAC
> > was the 'only possible solution available' ?
> >
> >
> > Also in our (the DBA) desire to work with the
> > 'latest and largest' I hope we are not biting Oracle's bait
> > and suggesting solutions with our resumes more in mind ;)
> > than the 'poor hapless customer' :(
> > (having Oracle as a product is bad enough for the customer
> > having a dba around 'usually' is a BIG pain :)) )
> >
> > Arun's comments were interesting...
> > sure BIGGIES like Oracle and yahoo can afford 'costly
> > technology'
> > (cos anyway they must be living on OPM ;) (other people's
>money)
> > !)
> > but what about mid/small sized companies...
> > at the rate Oracle is going with its products...
> > (they have put 'everything' in 9iAS and made it costly :( )
> > I wont be surprised if Mid/small sized companies 'shop
> > elsewhere'
> > and then surely Oracle and yahoo cant be hiring all of us ;)
> >
> > All the above of course are based on my limited knowledge of
> > RAC and a deep skepticism of BIGGIES :(
> > looking for good reasons for correction ;)
> >
> > and if someone from Oracle is listening ;)
> > I wish Oracle would change its attitude (not just logo ;) )
> > to
> > 'software that powers Business' ;)
> > ( we all know how far it 'powered the internet' ;) )
> >
> > Thanks for your time
> >
> > Cyril Thankappan
> >
> > On Sat, 24 May 2003 Rachel Carmichael wrote :
> > >
> > >Here's the thing. Disks are cheap. Maybe. But buying 5 disks
>is
> > >still
> > >cheaper than buying 10 disks. And it is NOT the people who
> > >actually
> > >work with the disks (DBAs, Sysadmins, even developers) who
>have
> > >the
> > >authority to order the disks.
> > >
> > >You need places and floor space to put the disks as well.
>It's
> > >not like
> > >you can just hang them from the ceiling.
> > >
> > >And even more so these days, and it seems most especially in
>the
> > >US
> > >companies, companies are trying to cut costs to the bone (we
>just
> > >went
> > >through an exercise where we practically had to jump
>through
> > >hoops just
> > >to get more memory for a production system which obviously
>needed
> > >the
> > >memory). And cutting costs means as few disks as possible,
>means
> > >reuse,
> > >consolidate and do without.
> > >
> > >It kind of reminds me of one of the sayings my parents (who
>grew
> > >up
> > >during the Great Depression here) have told me of that
>time:
> > >"use it
> > >up, make it do, or do without"
> > >
> > >we're in the "do without" phase
> > >
> > >Rachel
> > >--- Mogens_Nørgaard <mln_at_miracleas.dk> wrote:
> > > > I'm beginning to think that we're having this wonderful
> > >discussion
> > > > about
> > > > RAID-5 time and again because the vendors keep coming up
> > >with
> > > > arguments
> > > > to prove that the general laws of nature don't apply to
>this
> > > > particular
> > > > technology.
> > > >
> > > > In the 50s we had a prime minister here in Denmark that
>said
> > >to the
> > > > assembled parliament: "If that's the facts, then I deny
>the
> > >facts".
> > > > Somehow you have to admire a guy like that.
> > > >
> > > > Since disks are now cheap, how on Earth is it that we
>allow
> > >various
> > > > IO-vendors to bundle cheap disks, expensive cache which
>we
> > >won't
> > > > need,
> > > > and stupid technologies like RAID-5 into a box called
>SAN/NAS
> > >or
> > > > whatever and charge 42 billion units of some real currency
>for
> > >it?
> > > >
> > > > Why don't we take our swords and shotguns and AK-74s
>(that's
> > >the
> > > > small
> > > > calibre), and point them at them until they actually
>just
> > >bundle a
> > > > bunch
> > > > of inexpensive disks into RAID 1+0 which we ALL know is
> > >superior to
> > > > RAID-S, RAID-5 (notice how S looks like 5 - it's no
> > >coincidence).
> > > > It's
> > > > superior to RAID 0+1 even. It doesn't require (the
>expensive)
> > >cache
> > > > either.
> > > >
> > > > One of my wonderful experiences was with a TelCo here,
>where
> > >the
> > > > vendor
> > > > kept saying that they should of course just add cache if
> > >performance
> > > > wasn't sufficient. When they finally reached the 32GB
>(yep,
> > > > thirty-two
> > > > giga-bytes) of cache alone, they gave up, ripped the
>stuff
> > >apart and
> > > > reconfigured it as RAID 0+1 and it finally performed on
>the
> > >small
> > > > writes. We all loved it - except possibly the disk-vendor,
>who
> > >kept
> > > > saying RAID-<some letter that resembles the number 5> was
>of
> > >course
> > > > fantastic, and that they shouldn't listen to all these
>bitter,
> > >old,
> > > > twisted Oracle people who just hated RAID-5 and the likes
>...
> > >ahhh...
> > > >
> > > > just because!
> > > >
> > > > It's got nothing to do with Oracle or not. It's got to do
>with
> > >money
> > > > and
> > > > brains.
> > > >
> > > > RAID 1+0 is the best you can buy.
> > > > RAID 0+1 is almost as good.
> > > > RAID 5 sucks - in all its disguises and permutations -
> > >compared to
> > > > 0+1
> > > > or 1+0.
> > > >
> > > > If RAID-5 is good enough for you, fine. But remember to
>test
> > >the
> > > > good,
> > > > old restore of the backup and time it so that you're
>prepared
> > >if it
> > > > happens. It should of course take about four times as long
>as
> > >the
> > > > backup.
> > > >
> > > > As Connor said (and Cary has said it in his excellent,
>but
> > >futile,
> > > > RAID-5 paper) it's when you really, really need disk
> > >performance that
> > > >
> > > > RAID-5 will let you down.
> > > >
> > > > Yo.
> > > >
> > > > Mogens
> > > >
> > > > Arun Annamalai wrote:
> > > >
> > > > > Hi George.
> > > > >
> > > > > I would recommend go with Raid 5 and its not that one
> > >transaction
> > > > > triggers that many writes as you have
> > >mentioned/calculated.
> > > > > It is all buffered with recovery mechanism.
> > > > >
> > > > > Have you thought about Raid4(Network appliance)
>hardware. (I
> > >am no
> > > > way
> > > > > affliated with Network appliance, except that we use in
>our
> > >site.)
> > > > > Most of the big names use them, such as
> > > > > 1, Yahoo. (you can see network appliance logo when you
> > >logout of
> > > > your
> > > > > yahoo email account)
> > > > > 2. Oracle
> > > > > 3. Southwest airlines.
> > > > >
> > > > > I mean Yahoo, Southwest Airlnes are all heavy
>transaction
> > >oriented
> > > > > shop on a given per minute interval.
> > > > > The most common overhead of SAN is that the throughput
>of
> > >the
> > > > switch
> > > > > that connects your server to the san storage.
> > > > >
> > > > > Also, heard that Net App (best in NAS) is
>colloborating
> > >with
> > > > Hitachi
> > > > > (best in SAN storage) to get the best technology for
>storage
> > >and
> > > > > thoroughput performance. But this might take a while
>or
> > >might
> > > > already
> > > > > be in the market. Check out with your local Hitachi or
> > >Netapp
> > > > > representatives.
> > > > >
> > > > > Hope this helps.
> > > > > -Arun.
> > > > >
> > > > >
> > > > > ----- Original Message -----
> > > > > From: George.Leonard_at_za.didata.com
> > > > > <mailto:George.Leonard_at_za.didata.com>
> > > > > To: Multiple recipients of list ORACLE-L
> > > > > <mailto:ORACLE-L_at_fatcity.com>
> > > > > Sent: Tuesday, May 20, 2003 2:06 AM
> > > > > Subject: Sizing - RAC, storage subsystem EMC
> > > > >
> > > > > Hi all, hope you can give some input ideas.
> > > > >
> > > > >
> > > > >
> > > > > I am in the process of designing a system for a
>client
> > >of ours
> > > > for
> > > > > a proposal
> > > > >
> > > > >
> > > > >
> > > > > The sizing information I have been given is as
> > >follows.
> > > > >
> > > > >
> > > > >
> > > > > 58.1 million tickets/day at 351 bytes per record.
>The
> > >record
> > > > was
> > > > > complete populated (all columns filled to max) in
>a
> > >table and
> > > > then
> > > > > analyzed. Average row size 351 bytes.
> > > > >
> > > > > =~ 19 GB/day. Raw data. Plus overhead (indexes,
>temp
> > >space,
> > > > > rollback, some other data etc) here and there I
>have
> > >requested
> > > > 5 TB.
> > > > >
> > > > >
> > > > >
> > > > > We need to keep records for a month. Table design I
>am
> > >looking
> > > > at
> > > > > is a date partition with a second level hash
>partition.
> > >This is
> > > > so
> > > > > that I can move data in the oldest week/table space
>off
> > >line
> > > > and
> > > > > write them to optical storage for possible retrieval
>at
> > >a later
> > > > > date (requirement).
> > > > >
> > > > >
> > > > >
> > > > > Of course this will be on locally managed table
>spaces
> > >with
> > > > auto
> > > > > storage management for segments.
> > > > >
> > > > >
> > > > >
> > > > > Hardware:
> > > > >
> > > > > The database will be a Oracle RAC 9.2.0.4 on Sun
>cluster
> > >3
> > > > build
> > > > > on 2 x Sun StarFire V880, 4 CPU's, 4 GB RAM each,
> > > > >
> > > > > Connected to an EMC SAN via Fiber Channel
> > > > >
> > > > >
> > > > >
> > > > > I do not have more information about the EMC array
>at
> > >the
> > > > moment.
> > > > > Hitachi has been mentioned. (excuse the spelling)
> > > > >
> > > > >
> > > > >
> > > > > Question I have.
> > > > >
> > > > >
> > > > >
> > > > > I have been asked how many writes the Database will
>be
> > >doing to
> > > > > the SAN per second.
> > > > >
> > > > > I have determined that I should expect about 2000
> > > > tickets/second.
> > > > >
> > > > > The table in question will have 2 indexes.
> > > > >
> > > > >
> > > > >
> > > > > Now following rough guessing I said I should expect
>at
> > >least 16
> > > > > 000 writes/second
> > > > >
> > > > >
> > > > >
> > > > > This was done by say/assuming
> > > > >
> > > > >
> > > > >
> > > > > 2 writes for the redo log files (2 members)
> > > > >
> > > > > 2 writes for the control files (2 control files)
> > > > >
> > > > > 2 writes to index blocks
> > > > >
> > > > > 1 write to undo table space block
> > > > >
> > > >
> > >=== message truncated ===
> > >
> > >
> > >__________________________________
> > >Do you Yahoo!?
> > >The New Yahoo! Search - Faster. Easier. Bingo.
> > >http://search.yahoo.com
> > >--
> > >Please see the official ORACLE-L FAQ: http://www.orafaq.net
> > >--
> > >Author: Rachel Carmichael
> > > INET: wisernet100_at_yahoo.com
> > >
> > >Fat City Network Services -- 858-538-5051
> > >http://www.fatcity.com
> > >San Diego, California -- Mailing list and web
>hosting
> > >services
> >
> >---------------------------------------------------------------------
> > >To REMOVE yourself from this mailing list, send an E-Mail
> > >message
> > >to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru')
>and
> > >in
> > >the message BODY, include a line containing: UNSUB ORACLE-L
> > >(or the name of mailing list you want to be removed from).
>You
> > >may
> > >also send the HELP command for other information (like
> > >subscribing).
> > >
> >
> > ___________________________________________________
> > Impress your clients! Send mail from me @ mycompany.com .
> > Just Rs.1499/year.
> > Click http://www.rediffmailpro.com to know more.
> >
> > --
> > Please see the official ORACLE-L FAQ: http://www.orafaq.net
> > --
> > Author: Cyril Thankappan
> > INET: cyril_thank_at_rediffmail.com
> >
> > Fat City Network Services -- 858-538-5051
>http://www.fatcity.com
> > San Diego, California -- Mailing list and web hosting
>services
> >
>---------------------------------------------------------------------
> > To REMOVE yourself from this mailing list, send an E-Mail
>message
> > to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru')
>and in
> > the message BODY, include a line containing: UNSUB ORACLE-L
> > (or the name of mailing list you want to be removed from).
>You may
> > also send the HELP command for other information (like
>subscribing).
> >
> >
>--
>Please see the official ORACLE-L FAQ: http://www.orafaq.net
>--
>Author: Arup Nanda
> INET: orarup_at_hotmail.com
>
>Fat City Network Services -- 858-538-5051
>http://www.fatcity.com
>San Diego, California -- Mailing list and web hosting
>services
>---------------------------------------------------------------------
>To REMOVE yourself from this mailing list, send an E-Mail
>message
>to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and
>in
>the message BODY, include a line containing: UNSUB ORACLE-L
>(or the name of mailing list you want to be removed from). You
>may
>also send the HELP command for other information (like
>subscribing).
>
-- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Cyril Thankappan INET: cyril_thank_at_rediffmail.com Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).Received on Sun May 25 2003 - 22:27:19 CDT
 |
 |