Jared, I think there are some issues that we need to consider in this particular situation:
* The parsing, housing (storing in shared_pool and flushing out least used) as well as execution of triggers for replication of 2092 tables places a huge load on the Db as well as on the shared pool (latching, etc., rowcache requirements, etc.) This is not trivial. * Granted the reporting db is open and available with upto date (replicated) data as against a nightly refresh. However, one needs to use refresh groups (which provides a consistent set of snapshot information) in order to enable consistent reporting. And who knows how 2092 tables will be divvied up in refresh groups... And who's going to maintain this when snapshots break and are rebuilt (whcih breaks the refresh group....) * Who is going to manage the DDL on these 2092 databases? A SAN mirror based refresh would be the best bet in this case, and it looks like a SAN is available here.... Just a thot! John Kanagaraj Oracle Applications DBA DBSoft Inc (W): 408-970-7002 Disappointments are inevitable in Life, but discouragement is optional. You decide! ** The opinions and statements above are entirely my own and not those of my employer or clients ** > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Monday, August 26, 2002 4:48 PM > To: Multiple recipients of list ORACLE-L > Subject: RE: DB Refreshes > > > Dennis, > > I'd think that call would depend on the amount of activity > that is taking > place on the tables. > > Replicating 2092 tables for read only access shouldn't be > that difficult. > > I wouldn't try it with OEM. Building a set of scripts to > generate the > replication > SQL is not too hard. As long as the refreshes don't impose > too large a > drain on network resources, I can't foresee any problems. > > The biggest drain of course is building the initial > snapshots. That may > take some time. > > Though that is a lot of tables, it may be that only a small > percentage of > them are regularly DML'd. > > Have you tried snapshotting a large number of tables? I > haven't, so maybe > you've run into problems I have yet to see. > > I've found snapshots to be very low maintenance, once implemented. > > Jared > > > > > > > DENNIS WILLIAMS <[EMAIL PROTECTED]> > Sent by: [EMAIL PROTECTED] > 08/26/2002 03:13 PM > Please respond to ORACLE-L > > > To: Multiple recipients of list ORACLE-L > <[EMAIL PROTECTED]> > cc: > Subject: RE: DB Refreshes > > > Gulamabbas - If you're looking for minimal work, and must keep 2,092 > tables > synchronized, I would take a hard look at the methods besides > snapshots. > Just my 2 cents worth. > Dennis Williams > DBA > Lifetouch, Inc. > [EMAIL PROTECTED] > > -----Original Message----- > Sent: Monday, August 26, 2002 2:08 PM > To: Multiple recipients of list ORACLE-L > > > > Thanks for the response Dennis, I got a very good idea from > your email, > here > is my situation our OLTP DB is 24/7 but the reporting DB has to be > refreshed > on a nightly basis thus I can consider the snapshot. The only > problem I > see > with this, I will have to have a snapshot for over 2092 > tables. Will have > to > read more about snapshot documentation and how best to > implement this. We > are planning to use RMAN for backups/restores so maybe that could be > another > option. We have 2 separate servers one for the OLTP and 2nd > for the DSS > sharing the SAN. > > > Any other suggestions/comments more than welcomed > > > Thanks > > > > DENNIS WILLIAMS wrote: > > > Gulamabbas - I was in agreement with you until you said > "minimal work". > Funny. I am going to list some alternatives for you to > consider, but the > best alternative will depend on 1) how large is your OLTP > database, 2) how > active is the data i.e., how many transactions are involved, > 3) can the > reporting database be stand-alone, or does its data need to > be integrated > with other data? > > a) Snapshots, replication. Good if the OLTP database isn't > too active, but > it can impose a load on the production system. If you can wait and > resynchronize the databases at night when activity is lower, > this will > help. > There are other alternatives along these lines, but these > work best if > there > is minimal update activity. > b) RMAN DUPLICATE command can recover the database with > minimal impact on > the OLTP database. > c) Hot backup / clone. If you are using o.s. hot backups, t! > ! hese can > recreate > a cloned database on the reporting system. > d) Transportable tablespaces. > e) Oracle standby database. Apply the archive logs from the > OLTP database > at > night, switch it to being a reporting database during the day. With > Oracle9i, you can do both simultaneously which means your reporting > database > can function as an current standby for production. > > Dennis Williams > DBA > Lifetouch, Inc. > [EMAIL PROTECTED] > > -----Original Message----- > Sent: Monday, August 26, 2002 11:28 AM > To: Multiple recipients of list ORACLE-L > > > > Hello All > > I am in need to know/leanr about the database refreshes. Here is my > situation. We have OLTP database which is 24/7 and we need to > provied to > the > client a copy of the same OLTP database refreshed daily for their > reporting > puposes. Any ideas/suggestions how best can I do this, with > minimal work? > I > am currently reading about ORACLE Snapshots. We are running > ORACLE 8! ! > .1.7.3.0 > on Tur64 Unix. > > Thanks > > > > > > Gulamabbas Sikiladha > 1315-2850 Cedarwood Dr > Ottawa, Ontario > Canada > K1V 8Y4 > Tel : (613) 260 0336 > > > > > _____ > > Do You Yahoo!? > Yahoo! > Finance - Get real-time stock quotes > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.com > -- > Author: DENNIS WILLIAMS > INET: [EMAIL PROTECTED] > > Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 > San Diego, California -- Public Internet access / Mailing Lists > -------------------------------------------------------------------- > 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 com! ! mand for other information (like > subscribing). > > > > Gulamabbas Sikiladha > 1315-2850 Cedarwood Dr > Ottawa, Ontario > Canada > K1V 8Y4 > Tel : (613) 260 0336 > > > > > _____ > > Do You Yahoo!? > Yahoo! <http://rd.yahoo.com/finance/mailsig/new/*http://finance.yahoo.com> Finance - Get real-time stock quotes -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: DENNIS WILLIAMS INET: [EMAIL PROTECTED] Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- 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.com -- Author: INET: [EMAIL PROTECTED] Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- 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.com -- Author: John Kanagaraj INET: [EMAIL PROTECTED] Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- 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).
