Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: I/O contention with external process reading the oracle logs (online redo logs)

RE: I/O contention with external process reading the oracle logs (online redo logs)

From: Aponte, Tony <AponteT_at_hsn.net>
Date: Fri, 14 Jun 2002 09:41:18 -0800
Message-ID: <F001.0047E4C8.20020614094118@fatcity.com>


Actually, for us the percentage is lower since the OLTP application we're using it for is heavily indexed ( with the exception of single SQL that updates many rows.) It's one of those claims that is usually followed by "your mileage may vary."  

Tony

-----Original Message-----
Sent: Thursday, June 13, 2002 9:23 PM
To: Multiple recipients of list ORACLE-L logs (online redo logs)

It shouldn't need to be a "theoretical" or "statistical" claim at all. A prospective customer should be able to ship a few archived redo log files (the more the better!) to Quest and have them run it through that part of SharePlex that will read the redo and produce SQL. I'm surprised they haven't suggested it already... :-)

I think Yechiel is referring to a statistical claim by Quest that only 30% of the redo stream is usable in re-assembling the SQL statement. The rest is like you suspect, index maintenance, rbs segment maintenance, etc. But you are right to point out (sooooo right) that a multi-row update by a single SQL on the source results in individual updates on the target. That's a little nugget that the marketing folks left out of their 30% claim.

Tony

-----Original Message-----
Sent: Wednesday, June 12, 2002 10:48 PM To: Multiple recipients of list ORACLE-L logs (online redo logs)

Just curious, why do you think replication will be less bandwidth? Are you replicating only certain schemas/accounts and not the entire database?

Is Quest asserting that shipping the SQL statements are more "compact" than shipping the redo? That could be possible, but I'm quite certain that it is near thing, unless the heavily-modified tables in the app have been indexed with a heavy hand. For example, unless SharePlex has some remarkable logic, it won't be "coalescing" a million-row update into the single SQL statement that spawned it, which ironically Oracle's advanced replication might be able to do! Instead, they'll need to reverse-engineer individual UPDATE statements for each row, just like Oracle's LogMiner. The only circumstances under which I can imagine individual row-level SQL statements being more compact that the redo resulting from them is when there are lots of large indices on the table...

---

On another note, the 9iR2 "logical standby" feature is a direct knockoff of SharePlex, in that the RDBMS ships the SQL instead of the redo logfile, so the characteristics should be very similar. Of course, 9iR2 is very new and *very* raw at the moment, while SharePlex has been around for something like 5-6 years already (i.e. eons!), so that should be a strong consideration. But, when I last worked with SharePlex (3.0, I think), it had lots of bad habits like demanding "DBA" role to be granted to it's account both for installation as well as run-time, setting SETUID on executables owned by "root" (17-18 of them! drove the UNIX sysadmins insane! with good reason); just a lot of lazy development practices that I hope have been fixed...

> Hello Tim and Rachel
>
> There is band width problem. The line is 256K (we are checking upgrade to
> 512k).
> The database, during peek time produce 10MB of logs every 2-3 minutes.
> On this line it will take 7-8 minutes to pass 10MB if the line was
dedicate
> and it is not dedicated.
>
> Upgrading the line to more then 512K need E1 at least and it is expansive.
>
> Since replication will need less band width we are checking it.
>
> To return to my original question:
> Quest Shareplex -
> Any success stories?
> Why use this and not replication?
> Ant performance tests between Shareplex and Oracle replication?
>
> Yechiel Adar
> Mehish
> ----- Original Message -----
> To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
> Sent: Monday, June 10, 2002 4:33 AM
> (online redo logs)
>
>
> > and if you need the remote site to support users, you could use the
> > logical standby feature of 9iR2, which generates SQL statements to be
> > applied and allows the database to be open and active.
> >
> > --- Tim Gorman <Tim_at_SageLogix.com> wrote:
> > > why wouldn't you consider simply using the standby database feature?
> > >
> > > do you need the remote site to support users also?
> > >
> > > ----- Original Message -----
> > > To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com>
> > > Sent: Sunday, June 09, 2002 11:43 AM
> > > (online redo logs)
> > >
> > >
> > > > Hello All
> > > >
> > > > I just had a meeting today about replication.
> > > > The situations is: One master db that is currently replicated
> > > > (master to master synchronous replication) to a second DB.
> > > > Both machines are NT and the is a direct cable connection
> > > > between the network cards on both machines.
> > > >
> > > > However, this solves the problem of machine failure but does not
> > > cover
> > > > the full disaster recovery as both machines are in the same room.
> > > > In case of fire both machines will be destroyed.
> > > >
> > > > We are thinking about adding asynchronous replication to replicate
> > > the
> > > > changes
> > > > across wan to a remote site. The problem is that this will load the
> > > > production system and the network link (wan is expensive), as the
> > > system
> > > > generates during peek time 10MB of archive logs every 2-3 minutes.
> > > >
> > > > I saw that some of you are using Quest Shareplex.
> > > > Can you share your reasons, success stories etc?
> > > > Benchmarks results will be very welcome.
> > > >
> > > > TIA
> > > >
> > > > Yechiel Adar
> > > > Mehish
> > > > ----- Original Message -----
> > > > To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
> > > > Sent: Thursday, June 06, 2002 4:32 PM
> > > > (online redo logs)
> > > >
> > > >
> > > > NB_ RESENDING in plain text - sorry, Outlook keeps seinding in html
> > > no
> > > > matter what default i set!
> > > > Hi lists,
> > > >
> > > > I am using Quest Shareplex product for Oracle to Oracle one way
> > > > replication. I have two systems (source and target) and two
> > > environments
> > > > (dev, demo). On system one, the environments are setup as schemas
> > > within
> > > > one oracle instance (therefore each schema will be a SOURCE in the
> > > > replication). My other system has each environment set up a
> > > separate
> > > Orace
> > > > Instances (therefore each instance will become a TARGET in the
> > > replication).
> > > >
> > > > I am trying to configure 2 separate replication streams (ie so
> > > that
> > > each
> > > > replication process is SEPARATE from the other - one for DEV and
> > > one for
> > > > DEMO). I will accomplish this by setting up Shareplex to use
> > > mulitple
> > > > processes.
> > > >
> > > > HOWEVER, Quest technical support has told me that this will
> > > cause
> > > > contention. However, I dont see why is would from an os/oracle
> > > point of
> > > > view. Basically Shareplex has a process which reads the online
> > > redo
> > > > logs......... tech support is suggesting that is there a two
> > > processes
> > > > trying to access the same block in the logs that contention can
> > > occur.
> > > This
> > > > does not make sense to me. Below is the blurb from techincal
> > > support when
> > > I
> > > > questioned their initial repsonse:
> > > >
> > > >
> > >
> >
>



> > > > *************************************************
> > > > The reason you might run into a contention is because multiple
> > > captue
> > > > processes may be reading the same data block in the redo log.
> > > Since there
> > > > is only one process that can access a single block, the other
> > > process may
> > > > have to wait.
> > > > Contention is a possibilty, and you will need to run some bench
> > > marks to
> > > > find out how much, if any, contention you will have.
> > > >
> > >
> >
>


> > > > *************************************************
> > > >
> > > > I would find it HARD to believe that only ONE process can read a
> > > block at
> > > a
> > > > time. If this were true, then OLTP system would FAIL miserably!
> > > >
> > > > Anyone have any ideas/comments regarding the OS and Oracle
> > > interaction
> > > ....
> > > > I mean are not the logs at this pointa UNIX file? and can't
> > > multiple
> > > > processes read a single unix file without bringing the whole system
> > > to its
> > > > knees?
> > > > Also, I am NOT knocking the techincal support, but I believe that
> > > the
> > > > opinion was formulated on an incorrect assumption on the operating
> > > system
> > > > and Oracle.
> > > > Thoughts/comments?
> > > >
> > > > Thanks in advance.
> > > >
> > > > Hannah
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Please see the official ORACLE-L FAQ: http://www.orafaq.com
> > > > --
> > > > Author:
> > > > INET: johanna.doran_at_sungard.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: Yechiel Adar
> > > > INET: adar76_at_inter.net.il
> > > >
> > > > 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: Tim Gorman
> > > INET: Tim_at_SageLogix.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).
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! - Official partner of 2002 FIFA World Cup
> > http://fifaworldcup.yahoo.com
> > --
> > Please see the official ORACLE-L FAQ: http://www.orafaq.com
> > --
> > Author: Rachel Carmichael
> > INET: wisernet100_at_yahoo.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: Yechiel Adar
> INET: adar76_at_inter.net.il
>
> 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: Tim Gorman 
  INET: Tim_at_SageLogix.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: Aponte, Tony
  INET: AponteT_at_hsn.net

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 Fri Jun 14 2002 - 12:41:18 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US