If you reach that limit you have to use the good old principles that were developed for OPS - data partitioning, etc. Which is why the 7.3 OPS manual is so important to keep. They're moving the technical stuff out of the RAC manuals in order to make it more simple - or make it look more simple. Fine with me :-))).
If you use those good, old principles as much as you can from the beginning you will have better scaleability regardless. If you don't, you might be lucky and not need it.
Mogens
Paul Baumgartel wrote:
At Oxford you are running Oracle8i, correct? Do you believe that application partitioning is as important with 9i and cache fusion as it is in 8i?--- Mladen Gogala <[EMAIL PROTECTED]> wrote:Has anyone seen/run/stumbled over similar beast, if so - does it"fly"or it "stinks"?Depends on the application system. RAC is a bit more tolerant, but you still want to minimize the block exchange between the nodes. Application system must be "functionally partitioned", meaning that related data should be accessed from the same node. Example: let's imagine that we have health care application system which has elements like members/groups/providers, claims and drug utilization/ 3rd party vendors. Each of the listed groups is a complex application system accessing several hundreds of related tables. Good thing would be to put each of the listed application groups on its own node with the 4th node reserved for batch processing. If block exchange is frequent and DLM has a lot of work to do, then "flying" means "free falling until you hit the ground".P.S. I've looked at number of metalink articles and found none yet to "scratch" this specific "itch" of mine. Oracle RAC on Win2K is for some bizarre reason REQUIREMENT.Requirement by who? It usually helps to make a business case for a specific configuration and benchmark it to see whether the performance is satisfactory. Let me suggest a little benchmark: 4 clustered, beefed up PC boxes vs. a single, 16-CPU IBM P690 with the latest "960" CPUs and AIX 5.2. You can benchmark price and performance. I'd be very intrigued to find out the outcome. It is very hard to predict it properly (wink, wink).-- Mladen Gogala Oracle DBA -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Mladen Gogala INET: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).===== Paul Baumgartel, Adept Computer Associates, Inc. [EMAIL PROTECTED] __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
