Logical Standby Dataguard experience. Robust? Reliable?

DBAs,
Need sharing from all of your experience using logical standby Dataguard in 10gR2 or 11gR1. Do you feel that this logical standby technology requires high operational overhead (e.g. lots of problems, bugs, not so robust, error prone, etc). Transaction load is rather high for my environment.
I only use physical standby so far.
Thanks in advance

Hi - first you need to know the purpose of requiring a logical standby.
If it's for active standby - you might consider active dataguard in 11g.
Also you have to go through the doc for the list of limitation/s (regarding db objects) on logical standby - there's quite a few of them.
A well maintained/monitored system will have no additional admin overhead (maybe not initially) than the orhers.
cheers.
Lovell.

Similar Messages

Switchover logical standby dataguard

hi
we are using oracle9i on enterprise linux 3 . our primary and logical database are not located remotely but are two different servers.
now i need to know the steps that i need to perform in order to switch my primary database to standby database and vice versa . i tried few things but was unsuccessful.
according to my concept what we need to do is
Make sure no data is arriving and the applied and newest_scn are equal.
change the database role of the respective database .
make changes in initialization parameter file to change the primary dest as standby and vice versa .
and then start logical standby apply .
Is thier something that i am missing i tried few things from net but was not able to understand the logic and was unsuccessful .
THANKS

OEM>Tools>Database Applications>Dataguard Manager.
Select primary>Disable
Select secondary>Enable

When using DataGuard, the logical standby DB is already "OPEN"?

When I was setting up the physical standby DB several years ago no DataGuard got involved), I had the impression that the standby DB is in MOUNT status.
But since when using DataGuard to set up the logical standby DB, the logical standby DB can be used as it is already OPENed.
Is it actually in OPEN status? If so, can the primary and logical standby have the same SID without any trouble?
Please help advise. Thanks a lot!

Hello Christy,
yes it is ok that both database are in status OPEN, that is also the main reason for using logical standby databases (you can do changes and queries on standby too).
I hope you don't use a logical standby database in a SAP environment, because of this is NOT supported. Check sapnote #105047 - Point "14. Data Guard". A logical standby database has limitations.
If you just want to use the physical standby database for queries you can open it in read only or you can use flashback technology for read/write. With Oracle 11g you have these features included in data guard itself (Active Data Guard / Snapshot StandBy) to perform such steps automatically.
Regards
Stefan

Dataguard logical standby issue on lacking

we have logical standby database and its has been lacking sql apply from 14 hrs from primary database. Is there anyway i can stop sql apply and recover the database through archive files and make sync with primary and then again start the sql apply on logical standby database.
Please adivce

Neon,
I won't respond any further. The Dataguard Concepts and Administration Manual does contain a section on Troubleshooting.
It is quite clear you are using technology on which you have insufficient knowledge.
However, you belong to the class of wannabe-DBAs here,who as soon as they run into trouble start posting doc questions labeled with
'I need the detail steps'
'Urgent'
or (new development) post
'Any help' every half hour, when a volunteer didn't respond to their question.
If you want a quick response, submit a SR at Metalink. At least those analists are getting paid to answer your doc questions.
Sybrand Bakker
Senior Oracle DBA

Oracle DataGuard Logical Standby

Hi , I'd like to know what are the premisses to make a standby logical replication.
I have two environments (production and standby) with different number of processors and storage.
I'd like to know if it's possible to create data guard solution with these two environments and what are the premisses that I need aware to install the solution.
Thanks in advance.

Hello;
Yes the storage ( as long as you have enough space ) and cpu don't matter.
You can use hardware that's quite a bit different and it will work fine.
You can also create a Logical Standby fro a physical standby.
These notes may help :
NOTE 413484.1 - Data Guard Support for Heterogeneous Primary and Physical Standbys in Same Data Guard Configuration
Mixed Oracle Version support with Data Guard Redo Transport Services [ID 785347.1]
Logical Standby's don't seem to be very popular and the support base suffers because of this. I would consider a physical standby with Active Data Guard if costs allow.
Active Data Guard makes an excellent "Reader" database plus I believe your switchover and failover options are much better than a Logical Standby.
Oracle DataGuard Logical Standby Setup :
http://orajourn.blogspot.com/2007/02/setting-up-logical-standby-database.html
http://garyzhu.net/notes/DataGuard.html
Best Regards
mseberg
Edited by: mseberg on Apr 25, 2012 10:07 AM

Dataguard Problem(logical standby database)

Hi,
I have successfully created logical standby database, and everything is working fine, all of the SQL is applying and archiving is also shipping.
Until I create a new tablespace for e.g. pay in the primary database, and suddenly SQL applying is stopped, but the archive is shipping.
I am using Windows XP SP2 and Oracle 10gRel2.
The contents of AlertLog file are as
Wed Jul 23 22:52:19 2008
Thread 1 cannot allocate new log, sequence 133
Checkpoint not complete
Current log# 3 seq# 132 mem# 0: C:\ORACLE\PRODUCT\10.2.0\ORADATA\IMRAN\REDO03.LOG
Wed Jul 23 22:52:23 2008
Destination LOG_ARCHIVE_DEST_2 is SYNCHRONIZED
Wed Jul 23 22:52:23 2008
Destination LOG_ARCHIVE_DEST_2 no longer supports SYNCHRONIZATION
Wed Jul 23 22:52:23 2008
Thread 1 advanced to log sequence 133 (LGWR switch)
Current log# 1 seq# 133 mem# 0: C:\ORACLE\PRODUCT\10.2.0\ORADATA\IMRAN\REDO01.LOG
Thread 1 cannot allocate new log, sequence 134
Checkpoint not complete
Current log# 1 seq# 133 mem# 0: C:\ORACLE\PRODUCT\10.2.0\ORADATA\IMRAN\REDO01.LOG
Wed Jul 23 22:52:29 2008
Destination LOG_ARCHIVE_DEST_2 is SYNCHRONIZED
Wed Jul 23 22:52:29 2008
Destination LOG_ARCHIVE_DEST_2 no longer supports SYNCHRONIZATION
Wed Jul 23 22:52:29 2008
Thread 1 advanced to log sequence 134 (LGWR switch)
Current log# 2 seq# 134 mem# 0: C:\ORACLE\PRODUCT\10.2.0\ORADATA\IMRAN\REDO02.LOG
Wed Jul 23 22:55:49 2008
Thread 1 cannot allocate new log, sequence 135
Checkpoint not complete
Current log# 2 seq# 134 mem# 0: C:\ORACLE\PRODUCT\10.2.0\ORADATA\IMRAN\REDO02.LOG
Wed Jul 23 22:55:54 2008
Destination LOG_ARCHIVE_DEST_2 is SYNCHRONIZED
Wed Jul 23 22:55:54 2008
Destination LOG_ARCHIVE_DEST_2 no longer supports SYNCHRONIZATION
Wed Jul 23 22:55:54 2008
Thread 1 advanced to log sequence 135 (LGWR switch)
Current log# 3 seq# 135 mem# 0: C:\ORACLE\PRODUCT\10.2.0\ORADATA\IMRAN\REDO03.LOG
When i use this command, the SQL Apply starts again but the tablespace is not created on Logical standby database.
kindly give me a solution.
Thanks in advanced.

In Standy database also you need to add TB details for it to recognise Primary DB new TB .
try adding it and retry your operation .

Dataguard - logical standby - need help - not updating data at commit

Hi
Need help ?
We have logical standby setup where data is not updated at standby when committed at Primary. It only updates when alter system swith logfile.
On Primary:
log_archive_dest_2='service=xxStandby LGWR ASYNC valid_for=(online_logfiles,primary_role) db_unique_name=xxStandby'
On Standby:
we have already created standby redo logs ( 1+ # redo logs)
we used ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE NODELAY;
The data only ships when we do the ALTER SYSTEM SWITCH LOGFILE whereas it should so when data is commited on the primary.
Is there anything we are missing or need attention.
Please help
Thanks you so much

Yes, I have standby redo logs = ( 1 + # redo logs on the primary) and are of same size.
I also changed the log_archive_dest_2 setting for valid_for to ALL_LOGFILES, but the performance is still very slow... we are now overr 9 hrs behind the primary.
log_archive_dest_2='service=xxStandby LGWR ASYNC valid_for=(ALL_LOGFILES,primary_role) db_unique_name=xxStandby'
The Logical standby performance reallly not good at all. trying to increase sga/pga more ... hoping this will speed up some
Paul

Dataguard Logical Standby

Question: We're just thinking here.
If I have a primary database (A), which has a logical standby database (B), is it possible to have a logical standby database (C) for database (B)?
We have users that are updating tables in the logical standby database (B) but these are different tables than what are being updated from primary database (A).
Thank you

Yes.
http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/cascade_appx.htm#i636960

Large import on dataguard (logical standby) 11.2

The action I'll like to perform is to do a large import on the production enviroment without that this import will be applied on the logical-standby environment (because its to large for the standby envoriment to keep it up) and after that I will do this same import on the logical standby.
What the most common way to do this large import on logical standby enviroment after this is performed on the produnction ?
something like ;
alter session disable guard;
do the import
alter session enable guard;
alter database start logical standby apply skip failed transaction;
thanks in adv

if the table you are importing will have changes made to it AFTER the import and you want those changes replicated to the logical standby then you have to actually re-sync the table FROM primary.
Step 1. Skip the table DML on logical
EXECUTE DBMS_LOGSTDBY.SKIP(stmt => 'DML', schema_name => 'schema', object_name =>'table_name');
Step 2. Import the table into primary
Step 3. Stop Logical Standby apply
alter database recover managed standby database cancel;
Step 4. Get the restart_scn on Logical Standby to use for the flashback scn with exp_dp
SELECT RESTART_SCN FROM V$LOGSTDBY_PROGRESS;
Step 5. On Primary export the table using the restart_scn from logical
expdp DIRECTORY=DP_DIR DUMPFILE=sync_table.dmp LOGFILE=sync_table.log tables=schema.table_name flashback_scn=6146375299983
Step 6. On Logical import the table
impdp DIRECTORY=DP_DIR dumpfile=sync_table.dmp TABLE_EXISTS_ACTION=REPLACE
Step 7. Unskip the table and start the apply on logical standby
EXECUTE DBMS_LOGSTDBY.UNSKIP(stmt => 'DML', schema_name => 'schema', object_name =>'table_name');
alter database start logical standby apply immediate;
Now the tables should both be synced up and any new changes made to the table on primary will replicate correctly to logical.
Note that oracle must maintain a read consistent copy of the table as of the SCN you specified, depending on how long it takes to export you may run into rollback segment issues. I'd plan on doing this during the least busy time on your db and increase undo to avoid ORA-01555

Oracle 9i database software upgrade issue with standby (Dataguard) database

All,
I have encountered a problem in upgrading the Oracle software on 2 of our databases in-house. The databases in question here are using Dataguard, so one is set to primary and one is set to standby. The version that they are/were starting at is 9.2.0.7.
I was able to install and complete the 9.2.0.8 and 9.2.0.8 OCT CPU patches on the primary database, however when I moved to working on the standby database, I am got an error when attempting to follow step 6 of the post installation tasks:
Enter the following SQL*Plus commands:
SQL> STARTUP MIGRATE
SQL> SPOOL patch.log
SQL> @ORACLE_BASE\ORACLE_HOME\rdbms\admin\catpatch.sql
SQL> SPOOL OFF
(Please note that this is my first experience with working with Dataguard, so my methods in updating might have been a bit off-base.)
If I attempt to startup the standby database in MIGRADE mode, I get the following error (which is expected):
ORA-01666: controlfile is for a standby database
If I try to run the catpatch.sql script, even after mounting the database in standby mode, I receive the additional error:
ORA-01219: database not open: queries allowed on fixed tables/views only
My question here is, how do I get the standby database to allow me to finish the software upgrade process, so that both versions of Oracle match on the primary and standby databases? :)
(I did try some research on Metalink, but only found an article detailing how to upgrade your dataguard database from 9i to 10g, which did not look especially helpful in this case...)
Thank you!
-Sabrina

Depending on the kind of Dataguard you currently have, physical or logical, there are two useful metalinks notes:
Upgrading to 10g with a Physical Standby in Place
Doc ID: Note:278521.1
Upgrading to 10g with a Logical Standby in Place
Doc ID: Note:278108.1
~ Madrid
http://hrivera99.blogspot.com/

Fast Start Failover has broken my Logical Standby and Flashback has not helped

I have a primary ( PRIMARYP ), a physical standby ( STANDBYP ) and a logical standby ( STANDBYL ).
I configured Fast Start Failover ( with STANDBYP as the target ) and started an Observer. I did a shutdown abort on my primary and the Fast Start Failover did make STANDBYP the primary. I was able to reinstate PRIMARYP as a physical standby.
However when I checked my broker config it gave for STANDBYL
ORA-16795: the standby database needs to be recreated
Strange I though, since I would have expected STANDBYL to survive ok given that the new primary, STANDBYP was a physical standby of PRIMARYP.
Not to worry I thought, I simply will flashback STANDBYL to the beginning of the day and SQL APPLY will reapply all the redo.
This is where the problem begins
I mount STANDBYL
RMAN> connect target /
connected to target database: STANDBYL (DBID=440422466, not open)
RMAN> flashback database to time "TO_DATE('05/12/13 09:30:00','DD-MM-YY HH24:MI:SS')";
Starting flashback at 05-DEC-13
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=11 device type=DISK
starting media recovery
archived log for thread 1 with sequence 24 is already on disk as file /home/app/oracle/fast_recovery_area/STANDBYL/archivelog/2013_12_04/o1_mf_1_24_99yqwog0_.arc
archived log for thread 1 with sequence 25 is already on disk as file /home/app/oracle/fast_recovery_area/STANDBYL/archivelog/2013_12_05/o1_mf_1_25_9b0mlyvr_.arc
media recovery complete, elapsed time: 00:00:04
Finished flashback at 05-DEC-13
RMAN> quit
Recovery Manager complete.
oraclel[STANDBYL]>dgmgrl
DGMGRL for Linux: Version 11.2.0.3.0 - Production
Copyright (c) 2000, 2009, Oracle. All rights reserved.
Welcome to DGMGRL, type "help" for information.
DGMGRL> connect sys/manager
Connected.
DGMGRL> shutdown;
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
DGMGRL>
DGMGRL>
DGMGRL> startup;
ORACLE instance started.
Database mounted.
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open
ORA-01589 - that a nasty surprise ! I didn't think I would need to do anything with the log sequences after a flashback
Any ideas of what is going on ?
thanks,
Jim

Hello;
This pdf might meet your needs :
http://blogs.oracle.com/AlejandroVargas/resource/DATAGUARD-FSFO-IMPLEMENTATION.pdf
Additional info :
http://oracle-tech.blogspot.com/2008/08/fast-start-failover-it-is-reliable.html
http://jakub.wartak.pl/blog/?p=80
http://www.databasejournal.com/features/oracle/article.php/3849106/Fast-Start-Failover-in-Oracle-11g-Data-Guard.htm
Best Regards
mseberg

CPU patch procedure with physical and logical standby database in place

Hello All,
I've also placed this in the Upgrades forum, but perhaps this is the best place to have put it.
I'm trying to compile a decent set of steps for applying the CPUOCT2008 patch to our production RAC cluster which has both a logical and physical standby in place. I've read a tonne of documentation, including the CPU readme, DOCID 437276.1 and 278641.1. I''ve also read through the Upgrading Databases in a Data Guard Configuration chapter of Dataguard Concepts and Administration. The last doc mentioned is really for upgrading a full version of Oracle rather than applying a CPU (at least I think that's the case). DocID 437276.1 is rather sparse on details.
I guess what I'm trying to understand is the proper method for applying the patch with the logical standby in place. The physical standby looks pretty straightforward. After running opatch on it as well, it will basically have all of the changes applied to the primary shipped over and applied as per the normal primary/standby relationship. Will the same be true for the logical (having applied the patch, and then re-enabling SQL apply)? Should I aim to have it work that way? By that I mean start it up and re-enable sql apply and then upgrade the primary. Or, am I to apply the catcpu.sql script to it as well before re-enabling the sql apply? Am I wrong in regards to the physical standby as well i.e. should the catcpu also be applied directly to it?
Thanks very much in advance.
Cheers,
Chris
Edited by: chris.baron on Dec 12, 2008 11:38 AM

Given the fact that your system is far from main-stream I'd recommend opening an SR with Oracle Support Services (metalink) and asking them.
If you would like to publish a White Paper on your experience after you have successfully completed the project let me know off-line.

Apply CPUOCT2008 with both a physical and logical standby in place

Hello All,
I'm trying to compile a decent set of steps for applying the CPUOCT2008 patch to our production RAC cluster which has both a logical and physical standby in place. I've read a tonne of documentation, including the CPU readme, DOCID 437276.1 and 278641.1. I''ve also read through the Upgrading Databases in a Data Guard Configuration chapter of Dataguard Concepts and Administration. The last doc mentioned is really for upgrading a full version of Oracle rather than applying a CPU (at least I think that's the case). DocID 437276.1 is rather sparse on details.
I guess what I'm trying to understand is the proper method for applying the patch with the logical standby in place. The physical standby looks pretty straightforward. After running opatch on it as well, it will basically have all of the changes applied to the primary shipped over and applied as per the normal primary/standby relationship. Will the same be true for the logical (having applied the patch, and then re-enabling SQL apply)? Should I aim to have it work that way? By that I mean start it up and re-enable sql apply and then upgrade the primary. Or, am I to apply the catcpu.sql script to it as well before re-enabling the sql apply? Am I wrong in regards to the physical standby as well i.e. should the catcpu also be applied directly to it?
Thanks very much in advance.
Cheers,
Chris

Given the fact that your system is far from main-stream I'd recommend opening an SR with Oracle Support Services (metalink) and asking them.
If you would like to publish a White Paper on your experience after you have successfully completed the project let me know off-line.

Physical Standby database Vs. Logical Standby database

I have few questions regarding capability of Logical Standby Database against Physical Standby database.
1. How efficient is Logical Standby database in terms of Physical Standby Database?? How both differ from each other and can I use Logical Standby Database for disaster Recovery?? Can It be use for recovering the failed Primary Instance?? If yes how efficient and reliable it is??
2. What are the known bugs and roadblocks for logical standby database on Oracle 10.2.0.1 on Soalris X86-64?
3.As logical standby database not going to replicate each and every schema of Primary database?? how is the change management effects to the logical standby from primary?? I mean there are some parameters and job that we create on primary how can it be transferred over to the logical standby??

1. How efficient is Logical Standby database in terms
of Physical Standby Database?? How both differ from
each other and can I use Logical Standby Database for
disaster Recovery?? Can It be use for recovering the
failed Primary Instance?? If yes how efficient and
reliable it is??I'm not sure what sort of "efficiency" you're talking about here...
Physical standby is just the old, tried and true application of archived logs to recover a database. Very solid, very old school.
Logical standby, on the other hand, is parsing the redo log, extracting logical change records, and applying them to the standby database. This obviously takes a bit more processing effort, it's newer technology, it doesn't have quite the level of support that physical standby does (i.e. certain data types are excluded), etc. You certainly can use it for failover, but it isn't quite as robust as a physical standby. Of course, this is getting better and better all the time and is definitely a focus of Oracle's development efforts.
On the other hand, logical standby systems can do things other than act as a warm standby. They can be open serving reports, for example. You can create additional structures (i.e. new materialized views) to support reporting. A physical standby is pretty much always going to be in managed recovery mode, so it cannot be queried.
2. What are the known bugs and roadblocks for logical
standby database on Oracle 10.2.0.1 on Soalris
X86-64?a) You'll want to do a Metalink search
b) If you're talking about a high-availability solution, why are you looking at a base release of the database? Why wouldn't you apply the latest patchset?
3.As logical standby database not going to replicate
each and every schema of Primary database?? how is
the change management effects to the logical standby
from primary?? I mean there are some parameters and
job that we create on primary how can it be
transferred over to the logical standby??I'm not sure I understand... Changes made to the primary generate redo. Oracle parses that redo, generates a LCR, and sends that to the standby database where that change record gets applied.
Justin

Creating standby or logical standby database manually?

Hi,
I have to create 4 logical standby databases on a Linux Red Hat 64-bits server.
The primary databases reside on another Linux Red Hat 64-bits server.
The oracle database version is 10.2.0.3.
The question is as follows:
Should I create the logical standby databases manually or should I do it with the Oracle EM Grid Control?
I have read that the creation of standby databases with the Grid Control is very straightforward, but I really want to read of some of your experiences.
I have read that there are some problems in Grid Control with the test of Failover and Switchover.
Please advice.

Hi,
It all depends.
I assume you don't backup your database to tape using RMAN.
Do you backup your database to disk using RMAN?
You would need to set up NFS links from your standby server to the primary server.
For this purpose, in 9i, I made sure my disk backup ended up in <directory>/backup/<nodename>, so I could easily set up a NFS link.
If you do it manually, you need to have made a full database RMAN backup first.
Probably Grid Control is taking care of this for you.
I have done it once using database control in 10g. It is really simple, and you just have to click a few buttons and sit back.
Doing it manually is slightly more work: you need to make sure parameters are correct and you need to write a (generic) script of less than 10 lines.
You probably do have more control over it, though RMAN's duplicate database command is robust and can be restarted easily.
I can't answer your last remark.
Hth
Sybrand Bakker
Senior Oracle DBA

Logical Standby Dataguard experience. Robust? Reliable?

Similar Messages

Maybe you are looking for