| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: DB Refreshes
All the snapshots in a refresh group are processed as a single transaction. The idea behind a refresh group is that you want those particular tables to stay synchronized. Needless to say this can be taxing on your rollback segments.
I don't know what happens if you specify a rollback segment for each snapshot, but I would think what ever is specified in the dbms_refresh.make procedure would override it.
I am not 100% certain on any of this. Corrections are welcomed. My conclusions are based on observations made several years ago.
Ian MacGregor
Stanford Linear Accelerator Center
ian_at_SLAC.sTANFORD.EDU
-----Original Message-----
Sent: Tuesday, August 27, 2002 10:15 AM
To: Multiple recipients of list ORACLE-L
John,
Yes, refresh groups are a given.
I've begun taking the liberty of expecting poster to do some of their own RTFM.
Have you built large refresh groups? Until I here someone's experiences on the matter that state otherwise, I would still think it feasible.
Success would depend on:
I'm making the huge leap of faith that someone would actually experiment with this and determine if it would work for them.
There are some situations where I would much rather have a snapshot than a replicated.
Making the assumptions that 10% or less of the tables actually have DML on them during the course of a day, the server won't be taxed by the additional overhead of updating the snapshot logs, and that the network bandwidth is sufficient, I would expect this to work.
( If on version 8+, trigger execution should not be such a big deal, as it's part of the kernel )
As for snapshots breaking, I'm again assuming that the normal causes of this will be monitored and dealt with. Source server down, space issues, etc, are all things that should be monitored anyway.
I dunno, maybe I'm expecting too much, but I've been surprised at the non-intrusiveness of running several snapshots on a busy and poorly written system.
Jared
John Kanagaraj <john.kanagaraj_at_hds.com>
Sent by: root_at_fatcity.com
08/26/2002 07:30 PM
Please respond to ORACLE-L
To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
cc:
Subject: RE: DB Refreshes
Jared,
I think there are some issues that we need to consider in this particular situation:
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!
> -----Original Message-----
> From: Jared.Still_at_radisys.com [mailto:Jared.Still_at_radisys.com]
> 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 <DWILLIAMS_at_LIFETOUCH.COM>
> Sent by: root_at_fatcity.com
> 08/26/2002 03:13 PM
> Please respond to ORACLE-L
>
>
> To: Multiple recipients of list ORACLE-L
> <ORACLE-L_at_fatcity.com>
> 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.
> dwilliams_at_lifetouch.com
>
> -----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.
> dwilliams_at_lifetouch.com
>
> -----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: DWILLIAMS_at_LIFETOUCH.COM
>
> 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: ListGuru_at_fatcity.com (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: DWILLIAMS_at_LIFETOUCH.COM 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: ListGuru_at_fatcity.com (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: Jared.Still_at_radisys.com 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: ListGuru_at_fatcity.com (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: john.kanagaraj_at_hds.com 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: ListGuru_at_fatcity.com (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: Jared.Still_at_radisys.com 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: ListGuru_at_fatcity.com (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: MacGregor, Ian A. INET: ian_at_SLAC.Stanford.EDU 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: ListGuru_at_fatcity.com (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).Received on Tue Aug 27 2002 - 17:28:47 CDT
 |
 |