Then have two sets of packages for reports, when releasing new versions, do them on set 2 whilst normal users are running on set 1. This gives you time to test new versions in production as well. When tests are successful, switch to set 2.
Oh yes, this requires your application/reports to be aware of this "set" architecture. Basically you should have some kind of control table where you state on which set newly executed reports should run. Btw, how can you have constant DML activity and reporting going on when you have suspended your sessions? When your session executes a package and is suspended, the package is still pinned anyway and you cant just replace it on the fly. The baseline is, despite RAC you still one single database and you can't have this kind of online updating without doing some fundamental changes in the app. Tanel. ----- Original Message ----- To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> Sent: Thursday, December 04, 2003 10:19 PM > Can't do ... this is a 2 node RAC, users are connected all the time (basically this app runs ESPN daily business). There is constant DML and reporting activity on the database. > > Raj > -------------------------------------------------------------------------- ------ > Rajendra dot Jamadagni at nospamespn dot com > All Views expressed in this email are strictly personal. > QOTD: Any clod can have facts, having an opinion is an art ! > > > -----Original Message----- > Sent: Thursday, December 04, 2003 2:59 PM > To: Multiple recipients of list ORACLE-L > > > In my opinion you're approaching the problem from wrong end. Something like > standby database, temporary BCV copy or similar sounds safe solution for me. > Or use mechanisms like deferring user reports during upgrades (or check for > some bit's value before running a report etc..) > > Tanel. > > **************************************************************************** ********** > This e-mail message is confidential, intended only for the named recipient(s) above and may contain information that is privileged, attorney work product or exempt from disclosure under applicable law. If you have received this message in error, or are not the named recipient(s), please immediately notify corporate MIS at (860) 766-2000 and delete this e-mail message from your computer, Thank you. > **************************************************************************** **********4 > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: Jamadagni, Rajendra > 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). > -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Tanel Poder 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).
