Re: EMC SRDF or Advanced Replication????

Pete, Steve,

Just to add another question to this thread regarding EMC's SRDF and synchronous mode of operation for Oracle databases...

After referring to the SRDF documentation and based on my understanding of Oracle concepts, I believe that it is possible to run R1 and R2 in semi- synchronous mode of operation for the volumes that contain Oracle datafiles and archive logs. For other volumes, synchronous mode of operation is required. Do you agree with this?

My reasoning for this is that for datafiles (semi-synchronous), they can be recovered from online redo logs (synchronous). If a write-pending is not propagated to R2, the header for the datafile would reflect a prior state and the online redo log would be used to update the header on recovery. For archive logs (semi-synchronous), if a write-pending is not propagated to R2, the archive log is incomplete. But the archive log is simply a copy of an online redo log, so this does not cause data loss.

Please let me know if I am on the right track or not. Thanks.

I am against using synchronous mode of operation for all volumes because of the performance penalty.

Regards,
Larry Chiu
chiuljnk_at_my-dejanews.com
---
In article <8tWL2.12618$1P.5547_at_news.rdc1.nj.home.com>,   "Steve Graham" <sjgraham_at_mindspring.com> wrote:
> 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
> > > >
> > > >
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > Peter Sharman Email:
> psharman_at_us.oracle.com
> > > > WISE Course Development Manager Phone: +1.650.607.0109
> (int'l)
> > > > Worldwide Internal Services Education (650)607 0109 (local)
> > > > San Francisco
> > > >
> > > > SQL> select standard_disclaimer, witty_remark
> > > > 2 from company_requirements;
> > > >
> > > > Opinions are mine and do not necessarily reflect those of Oracle
> > > > Corporation
> > > >
> > > > "Controlling application developers is like herding cats."
> > > > Kevin Loney, ORACLE DBA Handbook
> > > > "Oh no it's not! It's much harder than that!"
> > > > Bruce Pihlamae, long term ORACLE DBA
> > > >
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > >
> > > >
> >
> > --
> >
> >
> > Regards
> >
> > Pete
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Peter Sharman Email: psharman_at_us.oracle.com
> > WISE Course Development Manager Phone: +1.650.607.0109 (int'l)
> > Worldwide Internal Services Education (650)607 0109 (local)
> > San Francisco
> >
> > SQL> select standard_disclaimer, witty_remark
> > 2 from company_requirements;
> >
> > Opinions are mine and do not necessarily reflect those of Oracle
> > Corporation
> >
> > "Controlling application developers is like herding cats."
> > Kevin Loney, ORACLE DBA Handbook
> > "Oh no it's not! It's much harder than that!"
> > Bruce Pihlamae, long term ORACLE DBA
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> >
>
>

-----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own Received on Tue Apr 20 1999 - 11:24:52 CDT