The "traditional" 2-node architecture (dbTier + appsTier [admin/CM] on one host and appsTier [forms/web] on the other) was essentially an outgrowth of the old single tier architecture. When the front-end (forms/web) got "heavier" and scalability was required, it was moved off to a separate box. The idea being that additional capacity could be added by "scaling out" (adding additional forms/web tier nodes) without increasing the size of the RDBMS server. The enabling factor there being (usually) private LANs between the nodes. The concurrent managers were kept on the same box as the database for two main reasons. First, the nature of the concurrent manager processes was thought to create significant network I/O going to the database. Secondly, when you had multiple forms/web tiers, putting the concurrent managers on them meant you'd have to configure parallel concurrent processing. (I'm not sure when that feature was introduced). Multiple nodes is now especially popular with the advent of the "commodity hardware" (read: "cheap hardware") based Linux OS on the scene. Unfortunately, due largely to hardware restrictions, Linux can't currently achieve the same level of "inside the box" SMP scalability that the "big iron" Unix vendors can. Fortunately, that degree of SMP scalability is really only important on the database tier. Some will argue that "you can scale with RAC". But the fact is that RAC, while it does have some scalability features, will never be able to achieve the same degree of "linearity" as inside-the-box SMP. So this brings us to one of Oracle's generally recommended architectures for the E-Business suite. dbTier: "big Iron" Unix (Solaris and the like) to achieve SMP scalability appsTiers: Linux (single or multiple boxes, shared applications filesystem). additional: hardware load-balancer (F5 BigIP, etc.) if there are 2 or more "forms/web" nodes. By going with this architecture, you have the "best of both worlds". While it *is* a heterogenus architecture, since ONLY the database is on Solaris (for example), it doesn't introduce the patching headaches that you'd have if the "appsTier" components were on different platforms. You get the large scale SMP scalability (quite linear up to significant numbers of CPUs) where it matters most (dbTier). You get to REDUCE your database licensing costs (since the box is ONLY doing dbTier, you'd need [perhaps marginally] less capacity, therefore fewer CPUs [potentially]) on that node. You also get the "commodity hardware" advantages of using Linux on the appsTier where scaling by adding boxes doesn't matter much. As with any multi-node configuration (for any application), you'll want to have high speed (gigabit these days) switch *private* LANs between the nodes for optimal performance. -- James On Fri, May 30, 2008 at 7:23 AM, Luis Freitas <lfreitas34@xxxxxxxxx> wrote: > > I am using 11.5.10 > > Regards, > Luis > > --- On Fri, 5/30/08, Pravin RC <pravinrc@xxxxxxxxx> wrote: > > From: Pravin RC <pravinrc@xxxxxxxxx> > Subject: Re: 2 node Architecture > To: ora-apps-dba@xxxxxxxxxxxxx > Date: Friday, May 30, 2008, 2:24 AM > > well, thats true, again which version of oracle u are using? > > On Fri, May 30, 2008 at 3:05 PM, Luis Freitas <lfreitas34@xxxxxxxxx> wrote: >> >> Hi, >> >> It was usual on the old days of 11.0, when network was 100Mbits to keep >> the CM/Reports and DB on the same node. >> >> Nowadays as gigabit ethernet is common I have seen many installations >> with only the DB on one node, and everything else on the other, so you only >> have to apply patches to one node. >> >> This depends on processor power too, CM/reports are CPU intensive, so >> if you dont have much cpu power or memory on the second node you may want to >> keep the CM/Reports on the database node to distribute the load. >> >> Regards, >> Luis >> >> --- On Fri, 5/30/08, Pravin RC <pravinrc@xxxxxxxxx> wrote: >> >> From: Pravin RC <pravinrc@xxxxxxxxx> >> Subject: Re: 2 node Architecture >> To: ora-apps-dba@xxxxxxxxxxxxx >> Date: Friday, May 30, 2008, 1:50 AM >> >> the only reason i can see is the network trafic, otherwise u can run all >> the services on different nodes. >> >> On Fri, May 30, 2008 at 12:25 PM, k srinivas <k.sridba@xxxxxxxxx> wrote: >>> >>> Hi DBAs, >>> >>> In Multinode setup with 2 nodes,usually we go for >>> >>> DB/CM/Report server one one node >>> and >>> Forms/Web server on second node >>> >>> Whts the logic behind DB/CM/Report sever on same node. >>> >>> Thanks in advance. >>> >>> >> >> >> -- >> Affectionately Yours >> Pravin R C > > > > -- > Affectionately Yours > Pravin R C > --------------------------------------------------------------------- James J. Morrow | Senior Oracle Applications DBA morrow.james <at> gmail <dot> com