RE: DB Refreshes

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:

• number of tables that actually see many changes
• frequency of refresh
• how much DML is done on the source system during a refresh period
• network bandwidth

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:

• 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: 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).