| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Re: Logical StandBy question
Hi Juan,
It is not the patch level that makes it unusable for standby. It's the
complexity, limitations and elaborous management tasks that cause the
problem. One single unsupported DML command can stop/suspend the SQL-Apply
process at the standby, and you have to circumvent the problem manually
before you can resume.
That's something you definitely don't want in a standby environment. At the
other end, when everything has been tested, tested, and tested, your users
have no SQL*Plus/Toad/ODBC/whatever SQL-tool access to the primary
database, you have reliable DBA's ;-), it can run pretty well, and it can
be used for reporting purposes.
Note that redolog forwarding doesn't mean SQL Apply. Let me clarify this. When running in Guaranteed protection mode, all (online) redolog information gets forwarded to the standby. This is done synchronously, so it is guaranteed that every transaction arrives at the standby when it's written in the redolog on the primary. The same applies to the other protegction modes, but some data divergence may be the result. But. After a logswitch and not earlier, logmining will start, and the SQL Apply process will start processing the transactions. This is called serialisation, and doesn't really scale!
PSB remains in recovery mode, that uses less resources, and kan keep up pretty well on the sites I've installed it so far (right, Yong? ;-) ).
What do you want to achieve with LSB? Off-line reporting facilities on
actual data? How actual do you need them? When a daily refresh is enough
consider this plan:
Create a PSB, and keep it in Read-only mode. All redolog gets forwarded
whatsoever, even in Read Only mode. Once, twice a day you switch the PSB to
Recovery mode, wait until the waiting redologs have been applied, and
switch back to Read Only mode. Has some limitations, not usable for all
demands for offline reporting, but on the other hand, you know what your
report is based on. Many DWH applications don't even want to have their
data updated real-time, simply because succeeding reports will be
uncomparable because variations in the daily workflow can affect the results.
Another plan might be creating both an LSB and a PSB (can be done on a single machine when the size of your database allows you), and use the LSB for reporting, and the PSB for failover. I would strongly recommend not to use LSB for failover purposes. The techniques simply aren't mature enough. I hope 10g is better, can't wait to get a copy to investigate DG in 10g. I've developed some scripts, 900+ lines for (hot) instantiation, and twice as much for database control. Together with some (still undocumented) naming conventions, they make life pretty easy for the command-line oriented DBA. However, they're not finished yet (what script is?), and not completely bug-free. And, they're Korn-shll scripts, so not usable on Windoze.
Regards, Carel-Jan
At 00:34 13-11-03 -0800, you wrote:
>
>I am just planning a LOGICAL data guard installation in an important client.
>They need it for reporting and backup (primary is 24x7x365 and we have hot
>backup.)
>
>I didnīt kwon that LSB are so bad.
>
>So do you think It is so bad that you donīt put it into production ???
>
>Do you try 9.2.0.4 ??
>
>
>I need to take a decision....
>
>I thank your previous answers.
>(I read doc, of course, but It is not explicity say that)
>-----Mensaje original-----
>De: ml-errors_at_fatcity.com [mailto:ml-errors_at_fatcity.com]En nombre de
>Carel-Jan Engel
>Enviado el: miércoles, 12 de noviembre de 2003 19:59
>Para: Multiple recipients of list ORACLE-L
>Asunto: RE: Re: Logical StandBy question
>
>Walt, drop me your email-address, and I send you the handouts of a special
>I presented about DG for Oracle University in Stockholm.
>
>I'm going out now for a few hours (it's 19.30 over here), but I'll respond
>later this evening.
>
>regards, Carel-Jan
>At 09:19 12-11-03 -0800, you wrote:
>>Stephane,
>>
>>What sort of problems can one expect from logical standby?
>>
>>I'm toying with the idea of using it as a replication database -- no
>>additional schema objects will be created, but users will have read-only
>>access to it. It's one of the options I'm looking at.
>>
>>Seems to me like there was a thread on this a few months ago, but I'm
>>not sure...
>>
>>--Walt
>>
>>On Wed, 2003-11-12 at 09:49, Stephane Faroult wrote:
>> > Jose Luis,
>> >
>> > What you say refers to the physical standby database (which works
>> well),
>> > not to the logical standby database (which on the paper looks great,
>> allows you to open the database, create additional tablespaces, create
>> additional indexes on replicated objects etc) but which in practice
>> still has a lot of teething troubles. Wouldn't use it in production on
>> Oracle 9.2.
>> >
>> > HTH,
>> >
>> > SF
>> >
>> > >----- ------- Original Message ------- -----
>> > >From: Jose Luis Delgado
>> > ><joseluis_delgado_at_yahoo.com>
>> > >To: Multiple recipients of list ORACLE-L
>> > ><ORACLE-L_at_fatcity.com>
>> > >Sent: Wed, 12 Nov 2003 08:09:27
>> > >
>> > >Hmmmmmm...
>> > >
>> > >I'd like to know where in the manuals... :-)
>> > >
>> > >I do not think so since the standby database stay
>> > >in
>> > >permanent recovery mode.
>> > >
>> > >JL
>> > >
>> > >--- Rachel Carmichael <wisernet100_at_yahoo.com>
>> > >wrote:
>> > >> yes. Well documented in the manuals
>> > >>
>> > >>
>> > >> --- Juan Miranda <j.miranda_at_sermatica.es> wrote:
>> > >> >
>> > >> >
>> > >> > Hi
>> > >> >
>> > >> > It is posible to create other schemas on a
>> > >logical
>> > >> stand by database
>> > >> > ?
>> > >> >
>> > >> > I mean, schemas that don?t exist in the primary
>> > >
>> > >> database.
>> > >> > --
>> > >> > Please see the official ORACLE-L FAQ:
>> > >> http://www.orafaq.net
>> > >> > --
>> > >> > Author: Juan Miranda
>> > >> > INET: j.miranda_at_sermatica.es
>> > --
>> > Please see the official ORACLE-L FAQ: http://www.orafaq.net
>>--
>>Please see the official ORACLE-L FAQ: http://www.orafaq.net
>>--
>>Author: Walt Weaver
>> INET: wweaver_at_rightnow.com
>>
>>Fat City Network Services -- 858-538-5051 http://www.fatcity.com
>>San Diego, California -- Mailing list and web hosting services
>>---------------------------------------------------------------------
>>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).
>
>DBA!ert, Independent Oracle Consultancy
>Kastanjelaan 61C
>2743 BX Waddinxveen
>The Netherlands
>tel. +31 (0) 182 640 428
>fax +31 (0) 182 640 429
>mobile +31 (0) 653 911 950
>e-mail info.dbalert_at_xs4all.nl
>
>
DBA!ert, Independent Oracle Consultancy
Kastanjelaan 61C
2743 BX Waddinxveen
The Netherlands
tel. +31 (0) 182 640 428 fax +31 (0) 182 640 429 mobile +31 (0) 653 911 950
-- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Carel-Jan Engel INET: cjpengel.dbalert_at_xs4all.nl Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- 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 Nov 13 2003 - 03:49:24 CST
 |
 |