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