Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> c.d.o.server -> Re: EMC SRDF or Advanced Replication????
Hi Pete,
I guess what I'm getting at here, is I need something that is straight
forward
and reliable. If my lowest common denominator dictates that I'll
potentially have to manage
a replication/snapshot environment via a telnet session, then I would rather
become
very familiar with that method alone...e.g., scripts. So, my main concern
is I
don't have the luxury of dealing with a *petulant* piece of functionality
that is
finicky and difficult to manage. That's really what I'm looking for
feedback on...can
I rely on replication/snapshots when the going gets tough?
Your feedback is welcomed:-)
Regards,
Steve
Pete Sharman <psharman_at_us.oracle.com> wrote in message
news:36FFB793.A3A22589_at_us.oracle.com...
> Steve
>
> Are you attempting here to do a **scheduled** cutover? That's the way it
reads,
> so let me make two sets of comments. Firstly, if this is a scheduled
cutover, I
> wouldn't be dialing in at 3:30 am to do the work. I like my sleep, and
I'm not
> the most accurate typist at that hour of the morning! If you want to
schedule a
> cutover, what I would do is script it, rather than do it manually at the
time
> you want to cutover, then schedule it in some way (depends on what
scheduler
> you're using - cron, OEM, ...). My comment about the typing reflects the
naming
> of the procedures you need to execute. Whoever created them took great
joy in
> making the names of the procedures (and the data dictionary views for that
> matter) as long as they possibly could (DBA_REPRESOLUTION_STATISTICS sort
of
> springs to mind here). If you don't have access to Replication Manager,
it can
> still be handled. After all, when replication first came out we didn't
have the
> GUI front end, so we all had to type lots!
>
> Secondly, if it's not a scheduled cutover, there should actually be little
for
> you to do. If the primary database dies, the secondary database is
already up
> and running. The work comes when you want to swap them back again.
>
> HTH.
>
> Pete
>
> Steve Graham wrote:
>
> > Pete,
> >
> > Thanks for the response. A follow-up question for you: From an
> > administration standpoint, it
> > seems like using updateable snapshots or replication could turn into
just an
> > amazing nightmare.
> > In theory, I would like to believe all the *claims* regarding advanced
> > replication or snapshots,
> > however how easy/difficult is it in real-life to coordinate all the
areas of
> > the snapshot/replication
> > methodology? For example, if I have to cut over to the failover
database at
> > 3:30am, and don't have
> > access from my telnet session at home to the GUI replication manager,
and
> > have to run scripts that
> > access the replication API, is this fairly easy to do, or very complex?
> >
> > Thanks in advance,
> >
> > Steve
> >
> > Pete Sharman <psharman_at_us.oracle.com> wrote in message
> > news:36FC2197.704DBF87_at_us.oracle.com...
> > > Steve
> > >
> > > Been there done that, but I don't have an answer for you. It's not
just
> > > the transactions per minute that has a bearing here, but the overall
data
> > > volume. It's a lot easier to do 3000 transactions that change 1 byte
than
> > > 3000 that change 200 bytes.
> > >
> > > The only answer with these sort of decisions is volume test, volume
test,
> > > volume test. Remember SRDF is supported in synchronous mode, and that
the
> > > version of Oracle you run has a big bearing too (8.1 has greater
> > > throughput than 8.0, which likewise has greater throughput than 7.3).
> > >
> > > HTH.
> > >
> > > Pete
> > >
> > > Steve Graham wrote:
> > >
> > > > Fellow Gurus,
> > > >
> > > > Would you use SRDF or Replication for a failover system,
> > > > that had to keep current on approximately 2000-3000 transactions
> > > > per minute. Oracle8 on Solaris 2.6 is the platform. All
transactions
> > > > would be propagated over whatever network bandwidth is necessary, I
> > > > could conceivably do it either way, looking for feedback from people
> > > > who've 'been there done that'.
> > > >
> > > > Regards,
> > > >
> > > > Steve
> > >
> > > --
> > >
> > >
> > > Regards
> > >
> > > Pete
> > >
> > >