Alter database recover to logical standby is hanging

Hi,
when I try to convert my physical standby to logical standby using
alter database recover to logical standby STANDBYL;
the command just hangs
I have seen the usual hit on this which is to create the Redo Dictionary on the Primary using
execute dbms_logstdby.build;
which I did but the alter database command still keeps hanging on my Standby
Any ideas,
thanks
Jim

Hello;
Does your Standby alert log have any lines like this:
RECOVER TO LOGICAL ...
If yes look for the message ( after this )
Starting datafile conversion
and post any errors or warnings you have.
Best Regards
mseberg

Similar Messages

ALTER DATABASE RECOVER MANAGE STANDBY DATABASE

During the creation of Logical Standby database (NOAA2), after issuing the statement:
"ALTER DATABASE RECOVER MANAGE STANDBY DATABASE"
the following error appears:
FAL[server, ARC1]: Complete FAL noexpedite archive (thread 1 sequence 46 destination NOAA2)
ARC1: Attempting destination LOG_ARCHIVE_DEST_2 network reconnect (3113)
ARC1: Destination LOG_ARCHIVE_DEST_2 network reconnect abandoned
PING[ARC1]: Error 3113 when pinging standby NOAA2.
Can someone please shed any light on the problem.
Thank you.

Perform these steps on Standby and see if it works
%lsnrctl stop
%lsnrctl start

ORA-279 signalled during: ALTER DATABASE RECOVER automatic standby databas

Hi,
oracle server:8.1.7.0.0
os:solaris 5.9
we created standby server by taking coldbackup of primary server and we are using rsync to syschronize the archive log files between production and standby servers but every over we recover the standby server by executing
sql>recover automatic standby database:
but in alert log file i am getting the following error :
but when i googled for ora-279 error some people says it is default behaviour and can it be ignored and why it is asking next logfile.
Media Recovery Log /oratranslog/arch_1_1701118.arc
Wed Mar 26 21:35:34 2008
Media Recovery Log /oratranslog/arch_1_1701119.arc
Wed Mar 26 21:35:54 2008
Media Recovery Log /oratranslog/arch_1_1701120.arc
ORA-279 signalled during: ALTER DATABASE RECOVER automatic standby database...
Wed Mar 26 21:36:24 2008
ALTER DATABASE RECOVER CANCEL
Wed Mar 26 21:36:24 2008
Media Recovery Cancelled
Completed: ALTER DATABASE RECOVER CANCEL
Thanks and Regards
Prakash
juniour oracle dba

damorgan,
He is running 8.1.7.0. "DataGuard" scripts were initially available for 9i and then
backported (and available as a seperate download) for 8i. Many 8i implementations
did not and do not use DataGuard.
Even if it is "Jurassic" {which it certainly is NOT}, they obviously do have a good
reason for setting up a standby -- they DO have data of value. So, maybe they have
not upgraded to 9i or 10g. There could be a dozen reasons
1. Server HW/OS doesn't support 9i/10g, not budgetting for Server upgrade
2. Application using Forms 2.x or 4.5 and not tested on 9i / 10g (4.5 not certified
on 9i)
3. Low end client PCs working perfectly with Character-mode forms, not powerful
enought to run Jinitiator and Forms 6i / 9i
Just because someone hasn't upgraded to 10g doesn't mean that they are at fault
when you do NOT know the reason why they have not upgraded.
Surely, they do know that 8i is desupported. Don't you think that their management
has undertaken due diligence / cost-benefit analysis in considering whether they
should upgrade to 10g ?
Maybe they have another project implementing 10g in parallel and will be able
to shutdown this environment soon. Maybe they don't need to do so.
Do understand that people are intelligent enough to make their own decisions
considering their particular circumstances and don't go shooting off with your
assumption that anyone not running 10g is a dinosaur.

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE

Hi,
on 10g R2, how to know if :
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
DISCONNECT;
is already applied ?
thank you.

user522961 wrote:
thanks to all.
Should I issue the following and others on standby or on primary ?
select process,status from v$managed_standby;
Regards.You need execute that from standby instance.In additionally you can see standby instances alert.log.And if this process is active then if you execute this command again then you will get an error like "Media recover is active".

Diff btw "recover datafile file#" & "alter database recover datafile file#"

What is the difference between
"recover datafile file#"
"alter database recover datafile file#"
Thanks
Naveen

I don't mean to be rude, but the statement that "There is no difference in both the commands" is facile in the extreme. Sounds like more off-the-cuff instant advice than the considered thoughts of someone who's actually bothered to try both commands out.
The "alter database recover..." command is a disaster waiting to happen and should never be used by anyone who actually wants to achieve a successful database recovery. It has the effect of suppressing most of the interactive dialogue you get when you submit the shorter "recover..." command, and indeed causes spurious errors to be displayed because the non-interactive recovery process gets it wrong.
For example, here's me recovering my database using the "alter database" syntax:
SQL> alter database open;
alter database open
ERROR at line 1:
ORA-01157: cannot identify/lock data file 4 - see DBWR trace file
ORA-01110: data file 4: 'C:\ORACLE\PRODUCT\10.2.0\ORADATA\WIN10\USERS01.DBF'
SQL> alter database recover datafile 4;
alter database recover datafile 4
ERROR at line 1:
ORA-00279: change 642359 generated at 07/04/2008 09:03:18 needed for thread 1
ORA-00289: suggestion :
C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\WIN10\ARCHIVELOG\2008_07_04\O1_MF_1_9_%U_.ARC
ORA-00280: change 642359 for thread 1 is in sequence #9Note the slightly alarming report of an 'error at line 1'. What's difficult to convey in mere text, however, is that at the end of that output, the thing just sits there, and you've no idea what on Earth is happening on the database. The text tells you it's making a suggestion, but there's no indication of how you accept the suggestion, of what's happening when you do accept it or where anything is up to.
I've interrupted one of those once (fortunately only in a training room) and lost the entire database as a result (because a half-complete, interrupted recovery is worse than no recovery at all).
Compare that with the plain "recover..." syntax example:
SQL> recover datafile 4;
ORA-00279: change 642359 generated at 07/04/2008 09:03:18 needed for thread 1
ORA-00289: suggestion :
C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\WIN10\ARCHIVELOG\2008_07_04\O1_MF_1_9_%U_.ARC
ORA-00280: change 642359 for thread 1 is in sequence #9
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
ORA-00279: change 642571 generated at 07/04/2008 09:06:26 needed for thread 1
ORA-00289: suggestion :
C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\WIN10\ARCHIVELOG\2008_07_04\O1_MF_1_10_%U_.ARC
ORA-00280: change 642571 for thread 1 is in sequence #10
ORA-00278: log file
'C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\WIN10\ARCHIVELOG\2008_07_04\O1_MF_1_9_46TPVL2G_.ARC' no longer needed for this recovery
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
ORA-00279: change 642576 generated at 07/04/2008 09:06:32 needed for thread 1
ORA-00289: suggestion :
C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\WIN10\ARCHIVELOG\2008_07_04\O1_MF_1_12_%U_.ARC
ORA-00280: change 642576 for thread 1 is in sequence #12
ORA-00278: log file
'C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\WIN10\ARCHIVELOG\2008_07_04\O1_MF_1_11_46TPVRMK_.ARC' no longer needed for this recovery
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
Log applied.
Media recovery complete.There are no weird error messages reported here. The suggestion is accompanied by a prompt that tells you how to accept it. Every time a new log is required, a new prompt is given. You can cleanly cancel at any time by typing 'cancel'. You are kept informed throughout and are in charge throughout.
Anyone that uses "alter database" syntax during a recovery is, therefore, either brave or foolhardy. In either case, there is a very profound difference between the two.
Your parting shot that 'alter database' is a SQL command and 'recover' can be an RMAN command misses the point by a wide mile, too. RMAN can issue pretty much any piece of SQL you like, so long as you wrap it in the SQL command:
RMAN> sql 'alter database recover datafile 4';
using target database control file instead of recovery catalog
sql statement: alter database recover datafile 4
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of sql command on default channel at 07/04/2008 09:23:16
ORA-00279: change generated at needed for thread
RMAN-11003: failure during parse/execution of SQL statement: alter database recover datafile 4
ORA-00279: change 642359 generated at 07/04/2008 09:03:18 needed for thread 1
ORA-00289: suggestion : C:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\WIN10\ARCHIVELOG\2008_07_04\O1_MF_1_9_%U_.ARC
ORA-00280: change 642359 for thread 1 is in sequence #9We don't get much further in RMAN with this dodgy form of the recovery command than we did in SQL*Plus, it's true -but that's just because it's a silly command to use in the first place, wherever you thought to use it. The distinction you seek to draw between 'SQL commands' and 'RMAN commands' is false in this case, in other words.

ALTER DATABASE RECOVER AUTOMATIC

Hi,
in 10 gR2 when applying :
ALTER DATABASE
RECOVER AUTOMATIC UNTIL TIME '2001-10-27:14:00:00';what should be the state of Database ? Nomount ? Mount ? Open ?
Thank you.

"RECOVER DATABASE" (or "ALTER DATABASE RECOVER") is in MOUNT state
"RECOVER TABLESPACE" or "RECOVER DATAFILE" can be in OPEN state (except when Tablespace/Datafile is SYSTEM , in which case the database must be MOUNT)

Streams Replication:Source database Physical or Logical Standby DB

Can the source database in streams replication be a physical or logical standby database ? If so, is the process of configuring streams the same as a regular database ? Are there any best practices or different configuration if the source is Logical or Physical standby DB ?
Thanks in advance.

Never done it, but I don't see any reason why it should not work.
Streams, at capture site, is only a data dictionary game and in a logical standby your data dictionary is open read write.
Streams, at capture site, never touch the source tables, in fact they may even not exists from Streams point of view,
as it deals only with the redo that are generated.
So Streams horizon is limited to the data dictionary, the log buffer, the archives and, in SYSAUX tablespace, all the LOGMNR_% tables. All these structures are read write in the logical standby. However, for the capture/propagation you may have to set to true the 'include_tagged_lcr' parameters.

Alter database ... keep identity hangs

Does anyone know what could cause the "alter database recover to logical standby keep identity" statement to hang waiting on "MRP wait on archivelog arrival"? I have executed this exact statement in the past on another physical standby and it went through fine.
I ran "exec dbms_logstdby.build" on the primary db (Linux 11.1.0.7), did a couple of log switches and then canceled the recovery process on the physical standby and executed the alter database...keep identity statement but the alter statement hung indefinitely on the standby db. It was always waiting to receive the current log file from the primary db.
Thanks.

Ogan, thanks for your response.
All the archived logs appeared to have been applied so I'm not sure what "necessary archivelogs" are left to copy and apply. I could not find any archive gap. Any idea what may be the issue from the output (RAC primary -> physical standby) you requested? thanks.
From v$archived_log
THREAD# NAME SEQUENCE# ARC APPLIED
1 /flashrecovery/DBSB1/archivelog/2010_07_11/1_9133_832673014.arc 9133 YES YES
1 /u01/logs/dbsb1/1_9133_832673014.arc 9133 YES YES
1 /flashrecovery/DBSB1/archivelog/2010_07_11/1_9134_832673014.arc 9134 YES YES
1 /u01/logs/dbsb1/1_9134_832673014.arc 9134 YES YES
1 /flashrecovery/DBSB1/archivelog/2010_07_11/1_9135_832673014.arc 9135 YES YES
1 /u01/logs/dbsb1/1_9135_832673014.arc 9135 YES YES
1 /flashrecovery/DBSB1/archivelog/2010_07_11/1_9136_832673014.arc 9136 YES YES
1 /u01/logs/dbsb1/1_9136_832673014.arc 9136 YES YES
1 /flashrecovery/DBSB1/archivelog/2010_07_11/1_9137_832673014.arc 9137 YES NO
1 /u01/logs/dbsb1/1_9137_832673014.arc 9137 YES YES
1 /flashrecovery/DBSB1/archivelog/2010_07_11/1_9138_832673014.arc 9138 YES NO
1 /u01/logs/dbsb1/1_9138_832673014.arc 9138 YES YES
1 /flashrecovery/DBSB1/archivelog/2010_07_11/1_9139_832673014.arc 9139 YES NO
1 /u01/logs/dbsb1/1_9139_832673014.arc 9139 YES YES
1 /flashrecovery/DBSB1/archivelog/2010_07_12/1_9140_832673014.arc 9140 YES NO
1 /u01/logs/dbsb1/1_9140_832673014.arc 9140 YES YES
2 /flashrecovery/DBSB1/archivelog/2010_07_11/2_8192_832673014.arc 8192 YES YES
2 /u01/logs/dbsb1/2_8192_832673014.arc 8192 YES YES
2 /flashrecovery/DBSB1/archivelog/2010_07_11/2_8193_832673014.arc 8193 YES YES
2 /u01/logs/dbsb1/2_8193_832673014.arc 8193 YES YES
2 /flashrecovery/DBSB1/archivelog/2010_07_11/2_8194_832673014.arc 8194 YES YES
2 /u01/logs/dbsb1/2_8194_832673014.arc 8194 YES YES
2 /flashrecovery/DBSB1/archivelog/2010_07_11/2_8195_832673014.arc 8195 YES YES
2 /u01/logs/dbsb1/2_8195_832673014.arc 8195 YES YES
2 /flashrecovery/DBSB1/archivelog/2010_07_11/2_8196_832673014.arc 8196 YES NO
2 /u01/logs/dbsb1/2_8196_832673014.arc 8196 YES YES
2 /flashrecovery/DBSB1/archivelog/2010_07_12/2_8197_832673014.arc 8197 YES NO
2 /u01/logs/dbsb1/2_8197_832673014.arc 8197 YES YES
2 /flashrecovery/DBSB1/archivelog/2010_07_12/2_8198_832673014.arc 8198 YES NO
2 /u01/logs/dbsb1/2_8198_832673014.arc 8198 YES YES
SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 9140
Next log sequence to archive 0
Current log sequence 9141

Error while Creating a Logical Standby Database

Dears
I setup physical standby db. Now trying to convert it to logical standby db by following this link:
http://download-east.oracle.com/docs/cd/B19306_01/server.102/b14239/create_ls.htm#i92346
When i issue this statement:
ALTER DATABASE RECOVER TO LOGICAL STANDBY orcl2;
I am getting following error:
ORA-00905: missing keyword.
I do not find anything in ALERT.LOG file. The syntax seems to be correct as i carefully copied from the document itself.
Please reply.

Any ideas?

Creating logical standby database

Hi all,
10.2.0.1
Following this link
http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/create_ls.htm
Where do i need to issue these statements:
SQL> EXECUTE DBMS_LOGSTDBY.BUILD;
SQL> ALTER DATABASE RECOVER TO LOGICAL STANDBY db_name;
on physical standby or primary database.
I issued the first stament on primary and second on physical standby .
IN the alert log of standby,i have the following entries.
Wed Jan 20 15:34:28 2010
Converting standby mount to primary mount.
Wed Jan 20 15:34:28 2010
ACTIVATE STANDBY: Complete - Database mounted as primary (treasury)
*** DBNEWID utility started ***
DBID will be changed from 306589979 to new DBID of 330710340 for database
.........................I am trying to create a logical standby database after creating a physical standby database.
It seems standby changed to primary which was not desired.
Thanks

Not tried myself, but you might want to have a look at this URL.
It appears to suggest that you need to change names of datafiles as well as value db_name explcitly on standby.

Problem building logical standby database

Hi all,
i am trying to build a logical standby database on platform Sun OS 10/Oracle 10gR2. I am following the Oracle document http://download.oracle.com/docs/cd/B19306_01/server.102/b14239/create_ls.htm#BEIGHEIA
I have created a physical standby database and converting it to a logical standby database. I ensured that my physical Standby is in Sync with primary.
Procedure DBMS_LOGSTDBY.BUILD executes successfully on primary.
The problem is that the command *'alter database recover to logical standby test;'* DOESN'T END. No error in archive log. I have identified the archived redo log that contains the LogMiner dictionary and the starting SCN and applied that archive log on standby. Still the the above command doesn't end.
Any Help is appreciated.

SQL> alter database recover to logical standby m2test;
This command doesn't return an sql> prompt. Alert log says it is waiting for log sequence 25. The command is running is for more than 5 hours, but still not competed.
Alertlog:
Thu Feb 5 22:14:25 2009
alter database recover to logical standby m2test
Thu Feb 5 22:14:25 2009
Media Recovery Start: Managed Standby Recovery (mtest)
Thu Feb 5 22:14:25 2009
Managed Standby Recovery not using Real Time Apply
parallel recovery started with 2 processes
Media Recovery Waiting for thread 1 sequence 25
Document says :-
If a dictionary build is not successfully performed on the primary database, this command will never complete.
But the dictionary build on primary is successful.
SQL> execute dbms_logstdby.build;
PL/SQL procedure successfully completed.
I used the following queries and to find which archive log contains dictionary build and made sure that the log archive sequence 22 is applied on standby.
SQL> SELECT NAME FROM V$ARCHIVED_LOG
WHERE (SEQUENCE#=(SELECT MAX(SEQUENCE#)
FROM V$ARCHIVED_LOG
WHERE DICTIONARY_BEGIN = 'YES' AND STANDBY_DEST='NO')); 2 3 4
NAME
/oradata/mtest/archive/mtest_1_22_677975686.arc
SQL> SELECT MAX(FIRST_CHANGE#) FROM V$ARCHIVED_LOG
WHERE DICTIONARY_BEGIN='YES'; 2
MAX(FIRST_CHANGE#)
177407
SQL>
Edited by: user592715 on Feb 6, 2009 3:22 PM

Convert to a Logical Standby Database

hii,
presently i m trying to convert physical standby into logical but i can't understand that this command is execute on standby db or primary db.
ALTER DATABASE RECOVER TO LOGICAL STANDBY <db_name>;

Vaibhav Dixit wrote:
hii all,
Thanks for reply
one more confusion
i have taken 2 parameter in standby initparameter file
db_name = prim
db_unique_name=stan
and execute command
ALTER DATABASE RECOVER TO LOGICAL STANDBY <db_name>;
in this
<db_name> is prim or stan
Vaibhav Dixitfor all check simply the database_role.
select db_unique_name,database_role from v$database;if it is standby then it is standby.

DB_NAME used by the Logical Standby db

Hi all,
It's Oracle 11g R2
I have a general question about converting a Physical standby database to a Logical Standby database.
An important step of the conversion procedure is to issue the following command:
ALTER DATABASE RECOVER TO LOGICAL STANDBY <NEWDBNAME>;
My question is: this statement changes the database name of the Standby database.
How come I still can connect to the new database without having to change the SERVIC_NAME in the tnsnames.ora file?
Here's the connection names used in the file:
db2 =
(DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = oradb2.mydomain.com)(PORT = 1521))
    (CONNECT_DATA =
      (SERVICE_NAME = oradb)
)Here's the new db_name:
SQL> SELECT VALUE FROM V$PARAMETER
WHERE NAME LIKE lower('DB_NAME%')
VALUE
ORADBLS
SQL> conn hr@db2
Enter password:
Connected.

If I understand you correctly, you are asking why changing the database name does not necessitate changing the service name? There is no direct relationship between them, you can define any number of service names to register with the listener. By default, there will be a service that does have the same name as the database (possibly with a domain appended) but you do not have to use that one. Query V$ACTIVE_SERVICES and DBA_SERVICES to see what services are available.
Edited by: JohnWatson on Oct 11, 2012 1:50 PM
Sorry - " a service that does have the same name as the database" should read " a service that does have the same unique name as the database"

Create logical standby from existing physical standby on 9i

I have physical standby database 9i running.
I want to try to convert the physical standby to logical standby. i follow the step by step in metalink document no. 748595.1
But I cannot do the 6th step:
6. Issue command to switch physical standby to logical standby after changing db_name in pfile to logical standby name. Shutdown the standby database if mounted and mount the database again. In this configuration, logical standby database name is LGSTDBY.
sql>alter database recover to logical standby LGSTDBY;
alter database recover to logical standby LGSTDBY;
Error at line 1:
ORA-00905: missing keyword
I have tried to create pfile from spfile on stanby and change the db_name to lgstdby.
I started nomount using pfile. I still cannot run the command.
I tried to mount the standby database but error occured:
ORA-01103: database name 'PRIMARY' in controlfile is not 'LGSTDBY'
The document in metalink is for 10.2.0.4
Is it possible to do it at 9i??
Thx for the help...

FEDORA 6 & ORACLE 10.2.0
alert_stb.log:
alter database start logical standby apply
Wed Jun 17 22:46:58 2009
ALTER DATABASE START LOGICAL STANDBY APPLY (stb)
Wed Jun 17 22:46:58 2009
No optional part
Attempt to start background Logical Standby process
LSP0 started with pid=22, OS id=4156
Wed Jun 17 22:46:59 2009
Completed: alter database start logical standby apply
Wed Jun 17 22:47:01 2009
LOGSTDBY status: ORA-16111: log mining and apply setting up
Wed Jun 17 22:47:01 2009
LOGMINER: Parameters summary for session# = 1
LOGMINER: Number of processes = 3, Transaction Chunk Size = 201
LOGMINER: Memory Size = 30M, Checkpoint interval = 150M
LOGMINER: session# = 1, reader process P000 started with pid=23 OS id=4158
LOGMINER: session# = 1, builder process P001 started with pid=24 OS id=4160
LOGMINER: session# = 1, preparer process P002 started with pid=25 OS id=4162
Wed Jun 17 22:47:02 2009
LOGMINER: Begin mining logfile: /u01/app/oracle/flash_recovery_area/STB/archivelog_3/1_3_689731882.arc
Wed Jun 17 22:47:02 2009
LOGMINER: Turning ON Log Auto Delete
Wed Jun 17 22:47:02 2009
LOGMINER: End mining logfile: /u01/app/oracle/flash_recovery_area/STB/archivelog_3/1_3_689731882.arc
LOGSTDBY Analyzer process P003 started with pid=26 OS id=4164
LOGSTDBY Apply process P008 started with pid=31 OS id=4174
LOGSTDBY Apply process P007 started with pid=30 OS id=4172
LOGSTDBY Apply process P004 started with pid=27 OS id=4166
LOGSTDBY Apply process P006 started with pid=29 OS id=4170
LOGSTDBY Apply process P005 started with pid=28 OS id=4168

Logical Standby recover with RMAN

Hi All,
I have a test environment with Primary DB Server, Physical Standby and Logical Standby.
The Logical Standby DB (cur_log_stdb) is backed up every evening by RMAN and I have a question:
If I recover my Logical Standby DB from backup and switch replication to new Logical Standby DB (new_log_stdb) it will work or not?
My steps e.g.:
1. Make a new server for my new_log_stdb and repair structure of catalogs;
2. Repair listener.ora and tnsnames.ora files from cur_log_stdb to new_log_stdb;
3. Restore DB with RMAN from backup to new_log_stdb;
4. On cur_log_stdb execute "alter database stop logical standby apply";
5. Change a DNS name from cur_log_stdb to new_log_stdb;
6. On new_log_stdb execute "alter database start logical standby apply immediate";
I'm not sure that archivelogs will apply to the new_log_stdb for period since rman backup was created.
But if this plan won't work how can I restore Logical Standby DB from RMAN backup and resume replication from Primary?
Configuration:
Oracle Linux 6.4
Oracle Database 11.2.0.3
Primary and Physical with Data Guard

Hello;
The only way to know for sure is to test it. You are asking somebody you don't know to confirm a recovery test for you. You have to perform the test yourself to be certain.
If your plan does not work you can always rebuild the Standby.
Best Regards
mseberg

Alter database recover to logical standby is hanging

Similar Messages

Maybe you are looking for