Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Re: STANDBY DB - 2 questions

Re: Re: STANDBY DB - 2 questions

From: Cyril Thankappan <>
Date: 18 Dec 2000 08:30:57 -0000
Message-Id: <>


 can u pls tell me more about
 the Shareplex software?


   PS: What has been this listers general experience

        with recovery manager?

       cos in the manual Oracle 'suggests' taking
       logical backup of recovery catalog
       which has 'greatly undermined' our
       management's 'confidence' in Recovery Manager
       and they 'DON'T WANT US TO do trial and error'
       in live/production systems.

 Can someone please tell what technical,'people' problems  were faced for implementing recovery manager  and how were they solved??

------------- Original Message -------------- "Roby Sherman" <> wrote: To:Multiple recipients of list ORACLE-L <> From:"Roby Sherman" <> Date:Sat, 16 Dec 2000 12:40:57 -0800
Subject:Re: STANDBY DB - 2 questions

<html><head></head><body>Jyoti wrote:<br>
<blockquote type="cite" cite=""><pre wrap="">Did you guys know that Oracle 9i claims to have an enhanced standby<br>database (logical stadby db) which can be opened in read/wirte mode?<br>That will be interesting.<br>Jyoti</pre>
It appears that the logical standby works in a similar manner to Shareplex by Quest software. Hopefully the performance will be better than in Quest's product...<br>

Please see the official ORACLE-L FAQ:
Author: Roby Sherman

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

Chat with your friends as soon as they come online. Get Rediff Bol at

Participate in crazy auctions at


 Date: Mon, 18 Dec 2000 16:47:30 +0800
 Subject: Oracle & DB2 co-exist

Any one have experience on 2 vendor database up concurrently on a Unix Box ?


 From: "Manivannan.M" <>
 Date: Mon, 18 Dec 2000 14:53:02 +0530 (IST)
 Subject: Listener Problem.


we have a typical problem here.
we have two versions of oracle 7.3.4 and 8i running in sun solaris.
The problem is with the listener. 8i uses default listener for 8i
and 7.3.4 uses another user defined listener(Listener_ora7). We have a
pro *c
program that connects to 7.3.4 database. it is always accessing
8i listener. How to make that pro*c program to consider 7.3.4 listener.

We could not put 7.3.4 database in 8i listener because of permission
and loging problems.

Manivannan Muthukrishnan.

    ADDRESS:                             E-MAIL:
    68/4, Site no:3,           
    80 Feet road,                        
    (opp) Deccan Studio,
    Indiranagar,                         PHONE:
    Bangalore - 560038.                  5284681  Ext: 464



 From: Ura! <>
 Date: Mon, 18 Dec 2000 12:17:24 +0300
 Subject: sysdba from different computers.

Hi dear ALL
I can login as sysdba on Oracle8i from one computers and can't login
as sysdba from another comp. Why?
and locate in %ORACLE_HOME%\DATABASE\
I have NT4 for Oracle server.



 From: "Indra Harimurti" <>
 Date: Mon, 18 Dec 2000 16:17:23 +0700
 Subject: question

This is a multi-part message in MIME format.

Content-Type: text/plain;
Content-Transfer-Encoding: quoted-printable

Dear Lists,

we're running Oracle 7.3.4 with Digital Unix 4.0d
some of our users are worry about the y2k things
when shifting to 2001, anyone have any information
about this matter. Please advise. Thank you.


Content-Type: text/html;
Content-Transfer-Encoding: quoted-printable


<META content=3Dtext/html;charset=3Diso-8859-1 =
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>Dear Lists,</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>we're running Oracle 7.3.4 with =
Digital Unix=20 4.0d</FONT></DIV>
<DIV><FONT size=3D2>some of our users are worry about the y2k =
<DIV><FONT size=3D2>when shifting to 2001, anyone have any=20
<DIV><FONT size=3D2>about this matter. Please advise. Thank =
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>Indra</FONT></DIV></BODY></HTML>
------=_NextPart_000_0007_01C0690E.01618200-- ------------------------------ From: "K Gopalakrishnan" <> Date: Mon, 18 Dec 2000 15:08:55 +0530 Subject: Re: Re: STANDBY DB - 2 questions Cyril ! Looked Shareplex for a client and it is very expensive (10000s of $$ per instance).. where you can get the same high availability thru some means (logminer.. standby database).. And there are news coming from Oracle . the similar kind of functionality (logical standby database) will be available with Oracle 9i.. So the choice is yours.and for a compatision Look Oracle9i at and Shareplex at __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. ------------------------------ From: "O'Neill, Sean" <> Date: Mon, 18 Dec 2000 10:29:13 +0100 Subject: Evaluation checklist - monitoring s/w Hi Folks, Early next year I'm planning to evaluate and select Oracle DB monitoring s/w. We are currently NT bound, but there might be a possibility of Unix introduced too. Anyhow, to help select the monitoring software I am planning to put together an evaluation checklist to try and objectively compare the various offerings out there. I'd appreciate it if you would let me know what features you think a monitoring package should have, e.g. in categories, "must have", "useful to have", "nice to have" (if you can afford it???). It would be also useful to hear feedback from you folk who already have such software on other factors such as, support level, costs (licences, annual maintenance), or even such aspirations as "looking back what I should have gone for was", or "but nowadays the xxxx package does this and more". In return for your time and feedback I'll publish the evaluation sheet to members of the list for everyone to use if they choose to do so. Oh! and of course if there is already an evaluation sheet in existence that folk know of, I'll cut to the chase there ;) Sean :) Rookie Data Base Administrator [0%] OCP Oracle8 DBA [0%] OCP Oracle8i DBA [0%] OCP Oracle9i DBA -------------------------------- ------------ Organon (Ireland) Ltd. E-mail: [subscribed: Digest Mode] Visit: The only man who never makes a mistake is the man who never does anything. - Theodore Roosevelt ------------------------------ From: =?iso-8859-1?q?paquette=20stephane?= <> Date: Mon, 18 Dec 2000 01:38:20 -0800 (PST) Subject: RE: Redo Copy Latch - Correction Hi all On a datawarehouse system where data changes by big loads in a small time interval, the log buffer is filled very fast, is there any specific advices on setting the size of the log_buffer (Oracle 8.1.6)? I know the best performance would be obtained by loading without logging but it's too late for this phase. --- Steve Adams <> a écrit : > Hi All, > > Time to eat some humble pie. I have received an > email from someone on the list > who works for Oracle and has access to the source > code telling me that the > "rumour" about the 1M background write threshold is > in fact true, and has been > since 8.0. Upon reflection, it makes sense that I > was able to see background > writes well in excess of 1M, because I was using > lots of processes to generate > the redo and may have unintentionally starved LGWR > of CPU time. I'll repeat the > test more carefully when I have some time. > > @ Regards, > @ Steve Adams > @ > @ > > > -----Original Message----- > Sent: Tuesday, 12 December 2000 12:22 > To: Multiple recipients of list ORACLE-L > > > Hi All, > > I've just noticed this thread, and it seems that > some further clarification is > needed. > > It is not true that if the log buffer is less than > 1M then LGWR will not be > posted to do background writes when the buffer > becomes more than 1/3rd full (or > exceeds _log_io_size). This is a ludicrous > suggestion. Just think of all the > 'log buffer space' waits that would ensue. Anyway, > the statistics demonstrate > plainly that the background write threshold is still > respected, regardless of > the size of the log buffer. > > Incidentally, there is another rumour about that a > 1M maximum has been > introduced at Oracle8 for the background write > threshold to prevent long 'log > file sync' waits if the DBA configures a log buffer > larger than 3M. I think this > comes from Oracle's "Oracle8 Performance Tuning > Workshop". Although the idea has > some merit, and Oracle may be planning to implement > it in a future release, it > is not there as of > > As to LGWR's use of the redo latches, it is fairly > obvious that LGWR would need > the 'redo allocation' latch because it reads and > writes the same variables that > foregrounds do when allocating space in the buffer. > Although there are others, > the main variables concerned are kcrfsfbb (the base > disk block number), kcrfsfi > (the index of current block being filled) and > kcrfshsb (the highest block that > needs to be synced). As you say, LGWR no longer > waits for the copy latches at > 8i. Have a look at the Ixora tip on "Redo Latch > Tuning" at > > for more information. > > @ Regards, > @ Steve Adams > @ > @ > > > -----Original Message----- > Sent: Tuesday, 12 December 2000 2:26 > To: Multiple recipients of list ORACLE-L > > > Hi Gaja, > > Thanks for your clarification. I didn't know that > LGWR functionality had > changed in Oracle 8. Please confirm me this (for > Oracle 8 realease or above): > > If log_buffer < 1MB then Oracle8 LGWR behaves like > Oracle7 does. I mean LGWR > writes when 1/3 of log buffer fills (background > write), and in order to do this, > it takes redo copies and redo allocation latch to > mark entries in the redo log > buffer, etc ... . And, of course, it also writes > when a commit takes place (sync > write), and when that happens it also takes these > latches. > > But, if log_buffer >= 1MB then LGWR behaves as you > described in your post. LGWR > only flushes entries to disk if log buffer is "full" > or when a commit takes > place. And when "any" one of these events happens, > LGWR takes the redo copy > latches and the RAL, it marks what it has to flush > to disk, realeases these > latches, then it writes the entries to disk (or the > whole log buffer), it takes > RAL again, updates "base disk block" variable and > realeses RAL. am I correct? > > Please correct me if I'm wrong. > Thanks > > > ----- Original Message ----- > To: Multiple recipients of list ORACLE-L > <> > Sent: Friday, December 08, 2000 2:20 PM > > > Hi Anil, Diego & the list, > > I think I may have a clarification to your > disagreement and it is related to a > functionality change in how LGWR writes the redo > entries from the log_buffer to > disk. It stems from one of the "events" that cause > LGWR to write - the 1/3rd > full event. > > Prior to Oracle8, if log_buffer were 'x bytes' in > size, when there were 'x/3 > bytes worth of redo entries' in the log_buffer, LGWR > wrote the x/3 bytes to > disk, allowing other server processes to continue > writing to the remaining 2x/3 > bytes. That was the whole point behind it being a > 'circular buffer'. This > occurred without any redo copy latches being taken > away or frozen. > > In Oracle8 that functionality got modified a little. > The 1/3 full event really > does not 'kick in' unless log_buffer was sized at > 1Mb. So if log_buffer is less > than 1Mb. in size, LGWR will wait for log_buffer to > be full and then initiate > the write. When that happens, it is only normal for > the redo copy latches to be > momentarily frozen or taken away (as the case may > be), to prevent any writes to > log_buffer (because it is already full). > > The point I was trying to make in my original > posting that LGWR itself should > not take away any of the redo copy latches for the > normal process of writing > redo entries to disk. The subtle difference I am
Received on Mon Dec 18 2000 - 02:30:57 CST

Original text of this message