Hi ,
We are trying to get a LINUX Cluster and RAC setup to work correctly and it
looks promissing sofar (<sarcasm>no thanks to the excellent documentation
Oracle provides on the subject </sarcasm>)
many guesses & visits to technet and metalink forums later we have two
instances up and running and the whole thing seems to be working properly.
The only thing I can't seem to get to work is that from my client I connect
fine to one node (using service_name) and get no listener for the other
node while the listener is up and running. Trying the same from the server
works fine. It connect to both instances w/o problem usin the service_name
(not sid or alias)
Does anybody have good documentation on sqlnet, tnsnames and listener.ora
files in RAC environment (O91R2)?
Also is it correct that 9iR2 does not have the oranm binary
TIA
Jack
Scott
<oraracdba_at_yahoo. To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
com> cc: (bcc: Jack van Zanen/nlzanen1/External/MEY/NL)
Sent by: Subject: RE: OPS and redos
root_at_fatcity.com
03-07-2002 20:18
Please respond to
ORACLE-L
John, I actually have never sat down tested to see
when Oracle actually does the redo kick. I do have a
OPS and RAC test environment so I may have to see how
big the GAP gets before Oracle starts doing log
archive switches on the idle node.
The only reason I have heard why Oracle does this kick
is to keep on-line redo logs archiving off of idle
instances, while other active instances generate redo
and archive on-line logs. The intent is to keep
archive streams from all participating instances close
to each other in time, so that a set of archived logs
for all redo streams/instances can easily be
identified and managed for backup or recovery. Also
used in executing the ALTER SYSTEM ARCHIVE LOG CURRENT
command, which is used to cause all instances to
archive their current logs.
I know Anjo has some detail on this feature. So he may
be able to provide more information.
Scott
- John.Hallas_at_vodafone.co.uk wrote:
> Thank you Scott for supplying a well-written
summary
> of SCN usage within OPS
> nodes.
>
> I was interested in "If the gap in the log
sequence
> gets to big Oracle will
> force the idle node to do log switches "
>
> I was not aware of that and whilst I believe you,
I
> cannot see what the
> reason behind it is. Have you any thoughts on why
it
> is set like that
> I suppose it is quite easy to test if you happen
to
> have a OPS development
> setup handy (which I do not at the moment)
>
> John
>
> -----Original Message-----
> Sent: 02 July 2002 19:44
> To: Multiple recipients of list ORACLE-L
>
>
> Fawzia, What are you querying to get the SCN
> information. I would also be curious where you
read
> about the recovery issues in OPS environment?
Oracle
> maintains what is called a snapshot SCN and
global
> SCN. The snapshot SCN is usually maintained in
the
> SGA
> and the global SCN is maintained by the DLM. All
> transactions committed in an OPS environment use
the
> global SCN and that SCN is always incrementing
even
> in
> if both instances are idle. In an OPS environment
it
> is possible for multiple transactions on
different
> nodes to commit with the same SCN but each
> transaction
> will commit with an SCN that is greater whether
> these
> transactions are on the same node or different
> nodes.
> The bottom line is that Oracle basically treats
> SCN's
> with committed transactions the same whether it
is a
> single instance or OPS.
>
> The snapshot SCN is used for queries and the
> snapshot
> SCN could be older than current or global SCN.
This
> SCN only effects queries not DML. The only issue
> here
> is using this snapshot SCN could give read
> consistency
> on transactions that where committed on the on
the
> other node.
>
> an example
>
> Time 10:00:00 - Node2 issues DML and commits
updates
> deptno from 10 to 11 committed with current SCN
> 1000,
> current SCN is now incremented to 1001
>
> Time 10:00:01 - Node1 issues a select on deptno
and
> sees 10 (should see 11 because the transaction
was
> commmited) because the snapshot SCN is 998 and
the
> transaction was committed with newer SCN we must
> perform a read consistent read.
>
> PMON is the process that synchs current or global
> SCN
> with the snapshot SCN and PMON usually does this
> every
> 3 seconds
>
> so if you issue the query
> Time 10:00:05 (5 seconds after the commit) -
Node1
> issues the select on deptno and now sees 11. This
is
> because PMON sync-ed up the snapshot SCN with the
> current or global SCN and now my SCN for my query
is
> newer than the SCN the transaction you committed
> with
> so there is no need to perform a CR you can just
use
> the current version.
>
> The above issue is really only a problem is a
system
> if you have a lot of DML on 1 node and a lot of
> selects on the other node. It this is an issue
you
> can
> set MAX_COMMIT_PROPAGATION_DELAY=0 and this will
> force
> the queries to always use the current or global
SCN
> and now you should see the committed data as soon
as
> it is committed because both the DML and queries
are
> use the current or global SCN.
>
> I find odd that you have SCN of 500 and 2000. The
> way
> Oracle maintains SCN's in an OPS environment
> shouldn't
> allow for this large of a gap in SCN's. This
looks
> more like log sequence numbers not SCN's. If
these
> are
> indeed log sequence then this gap is not an
issue.
> Recovery is based more on SCN's not log sequence
> numbers.
>
> If the gap in the log sequence gets to big Oracle
> will
> force the idle node to do log switches and if you
> are
> archiving you will see archive logs 1 OS block in
> size. When Oracle does this you should a KK
> "Redo
> log Kick" lock being allocated.
>
> Hope this helps,
>
> Scott
>
> --- "Malik, Fawzia"
> &lt;Fawzia.Malik_at_bskyb.com&gt; wrote:
> &gt;
> &gt;
> &gt; Hi gurus,
> &gt;
> &gt; I have a query..Basically we have an OPS
set up
> here
> &gt; (8.0.6) and I have
> &gt; noticed that the scn on node A is 500
and the
> scn
> on
> &gt; node B is 2000. I am
> &gt; concerned about this w.r.t recovery-
surely
> this
> &gt; would be an issue ??I
> &gt; logged a call with oracle and they said
it
> wasnt
> an
> &gt; issue, but then I read
> &gt; in a document that it WAS an issue and
could
> &gt; potentially lose everything
> &gt; between 500 abd 2000..and that the
workaround
> would
> &gt; be to add more logs to A
> &gt; or to modify the check point
interval....
> &gt;
> &gt; Please can you advise??
> &gt;
> &gt; Rgds
> &gt;
> &gt; Fawzia
> &gt;
> &gt;
> &gt;
>
> &gt; Information in this email is
confidential and
> may
> be
> &gt; privileged.
> &gt; It is intended for the addressee only.
If you
> have
> &gt; received it in error,
> &gt; please notify the sender immediately and
delete
> it
> &gt; from your system.
> &gt; You should not otherwise copy it,
retransmit it
> or
> &gt; use or disclose its
> &gt; contents to anyone.
> &gt; Thank you for your co-operation.
> &gt;
>
> &gt;
> &gt; --
> &gt; Please see the official ORACLE-L FAQ:
> &gt; http://www.orafaq.com
> &gt; --
> &gt; Author: Malik, Fawzia
> &gt; INET: Fawzia.Malik_at_bskyb.com
> &gt;
> &gt; Fat City Network Services -- (858)
538-5051
> FAX:
> &gt; (858) 538-5051
> &gt; San Diego, California -- Public
Internet
> &gt; access / Mailing Lists
> &gt;
>
> &gt; To REMOVE yourself from this mailing
list, send
> an
> &gt; E-Mail message
> &gt; to: ListGuru_at_fatcity.com (note EXACT
spelling
> of
> &gt; 'ListGuru') and in
> &gt; the message BODY, include a line
containing:
> UNSUB
> &gt; ORACLE-L
> &gt; (or the name of mailing list you want to
be
> removed
> &gt; from). You may
> &gt; also send the HELP command for other
> information
>
=== message truncated ===
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Scott
INET: oraracdba_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).
===================================================================
De informatie verzonden in dit e-mailbericht is vertrouwelijk en is
uitsluitend bestemd voor de geadresseerde. Openbaarmaking,
vermenigvuldiging, verspreiding en/of verstrekking van deze informatie aan
derden is, behoudens voorafgaande schriftelijke toestemming van Ernst &
Young, niet toegestaan. Ernst & Young staat niet in voor de juiste en
volledige overbrenging van de inhoud van een verzonden e-mailbericht, noch
voor tijdige ontvangst daarvan. Ernst & Young kan niet garanderen dat een
verzonden e-mailbericht vrij is van virussen, noch dat e-mailberichten
worden overgebracht zonder inbreuk of tussenkomst van onbevoegde derden.
Indien bovenstaand e-mailbericht niet aan u is gericht, verzoeken wij u
vriendelijk doch dringend het e-mailbericht te retourneren aan de verzender
en het origineel en eventuele kopieën te verwijderen en te vernietigen.
Ernst & Young hanteert bij de uitoefening van haar werkzaamheden algemene
voorwaarden, waarin een beperking van aansprakelijkheid is opgenomen. De
algemene voorwaarden worden u op verzoek kosteloos toegezonden.
=====================================================================
The information contained in this communication is confidential and is
intended solely for the use of the individual or entity to whom it is
addressed. You should not copy, disclose or distribute this communication
without the authority of Ernst & Young. Ernst & Young is neither liable for
the proper and complete transmission of the information contained in this
communication nor for any delay in its receipt. Ernst & Young does not
guarantee that the integrity of this communication has been maintained nor
that the communication is free of viruses, interceptions or interference.
If you are not the intended recipient of this communication please return
the communication to the sender and delete and destroy all copies.
In carrying out its engagements, Ernst & Young applies general terms and
conditions, which contain a clause that limits its liability. A copy of
these terms and conditions is available on request free of charge.
===================================================================
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Jack van Zanen
INET: nlzanen1_at_EY.NL
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 Thu Jul 04 2002 - 02:53:22 CDT