Thanks a lot, Tim. Enjoyable reading. Much appreciated. Just to clarify what data modeling vendor might mean by "RAC-aware" model: In one of the draft suggestions they had "activity" class tables that would record all major steps in the system like registration, signing a contract, inventory replenishment etc. This class of tables would be inevitably DMLed from different nodes in active/active deployment and it would probably present "bottleneck" much like AOL or FND schemas in your example with Oracle Apps
Another thing that I saw on the draft ERD was "event" entity with exclusive arc to 7 (seven!) others. Same thing. On the final one it's broken down into two event_sales and event_inventory. While it's easily can be abstracted to a single entity (similar attributes) they separated them into two presumably to minimize data shuffles over interconnect. Isn't it kind of "segregation" (if I am not mistaken the term Oracle doco seems to use is "application segmentation" http://download-west.oracle.com/docs/cd/A97630_01/rac.920/a96598/ebizapps.htm#22163)? Tim, I appreciate your "mutual failover" suggestion, but I am afraid it wouldn't work here as these 30+ apps would be totally merged and at these point cease to exist as separate schemas. Now to the cool stuff :) Your idea of the middle tier "data-routing" seems very interesting. Is it like app server having two data sources defined (one for each node) and issuing DMLs based on some sort of criteria? Would it be too much to ask you elaborate on this? Is it "one table gets rows inserted from one node with even ids (assuming sequence based artificial PK) and rows with odd ids from another node" type of scenario (or something similar like based on type/group/code/whatever but the same table DMLed from different nodes based on data ranges)? Or am I totally off base here? Tim, thanks again for your help! --- Tim Gorman <[EMAIL PROTECTED]> wrote: > comments inline... > ______________________________________________________________________ Post your free ad now! http://personals.yahoo.ca -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Boris Dali 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).
