On RAC if you lose the db be it 64 nodes or 2 - you're done Disk is not cheap? 6.3 TB from DELL on a spiffy MD3000 is $16,000....list.. T-e-r-a-b-y-t-e-s. Might put be back $10,000 with a typical discount On Thu, May 21, 2009 at 3:51 AM, Nuno Souto <dbvision@xxxxxxxxxxxx> wrote: > David Kurtz wrote,on my timestamp of 21/05/2009 2:14 AM: > >> It is supported, but it is not recommended by PeopleSoft/Oracle. >> > > My take on that is very few people have even bothered trying > it and neither Oracle nor Peoplesoft ever encouraged it. > > Which flies in the face of the "run lots of apps on a single > instance with RAC", "server consolidation" and all > the other yadda-yadda of Oracle marketing... > > > There are a number of drawbacks including and not limited to: >> * You have to back and restore the databases together. The only to backup >> and restore one of several PeopleSoft databases in the same Oracle >> database >> would be via export/import. >> > > You have to back all instances anyway, so > having to back up one large instance or two smaller ones > makes no difference whatsoever. > > > * If the database goes down, then all the PeopleSoft systems become >> unavailable. >> > > True. But is that still the case if it is on RAC? > > > * If all the databases are in the same database server then the same >> database parameters apply to all. You cannot control them separately. >> > > > True. But with login triggers, it is simplicity itself > to set different parameters for each session connecting > as each schema owner/psdbowner. I do this regularly to > run multiple applications in the same instance, each on > its schema. Why should it be different for Peoplesoft? > > > In the end there is very little saving to be made, and it is at the price >> of >> considerable complication and loss of flexibility. >> I simply would not do it. >> > > Disagree. UNDO and temp disk space are not trivial or > "little" savings. Further, RAC is a common push from Oracle: > to have multiple RAC instances on multiple RAC clusters > is simply prohibitive from the licensing and hardware > resources point of view. > And no: disk is most definitely NOT cheap. > > Unfortunately, no one is taking the right message > to the PPS/Oracle responsible people. Maybe a few > public outings will change that? > > -- > Cheers > Nuno Souto > in sunny Sydney, Australia > dbvision@xxxxxxxxxxxx > > -- > //www.freelists.org/webpage/oracle-l > > >