Unblocking the Oracle VM Manager (OVM) Command Line Interface (CLI)

If OVM CLI queries block as follows . . .

OS>

/usr/local/bin/sshpass -p <OvmPassword> ssh -p <OvmPort> admin@<OvmHost> "show server name=<NameOfTheVmToQueyFor>"

Permission denied, please try again.

Logon to the OVM host (<OvmHost> from above) as OS root user and restart the OVM CLI:

# service ovmcli stop

Stopping Oracle VM Manager CLI   [  OK  ]

# service ovmcli start

Starting Oracle VM Manager CLI   [  OK  ]

# service ovmcli status

Oracle VM Manager CLI is running...

Now you can retry the query from top:

OVM> show server name=<NameOfTheVmToQueyFor>

Command: show server name=<NameOfTheVmToQueyFor>

Status: Success

Time: 2018-01-26 12:17:23,011 CET

Data:

  Status = Running

  Role 1 = Utility

  Role 2 = Vm

  Ip Address = 159.*********

  Maintenance Mode = Off

  Inbound Migration Locked = No

  Agent Login = oracle

  Statistic Interval = 40

  NTP Server 1 = b****************

  NTP Server 2 = m******************

  BIOS Vendor = HP

  BIOS Version = P70

. . .

I hope it helps.

AWK Usage Example: Generating Archivelog Register Statements

Here examples of generating Oracle DB statements in order to register archived log files stored in ASM into the DB.

In order to keep the implementation simple, only one archived log directory (variable P) is processed by each call.

Meaning of the awk Variables below:

• A <- used in order print the character '
• p <- holds the archived log directory path specified by the environment variable P
• $8 <- Holds the strings of the 8th column. That means, contains the names of the archive log files

OS>

P="U02/<DbUniqueName>/ARCHIVELOG/2018_01_19/"

echo "ls -l $P" |

  asmcmd |

  awk -v A="'" -v p="$P" '/^ARCH/{ print "ALTER DATABASE REGISTER LOGFILE "A p $8 A";" }' |

  more

 

Output

. . .

ALTER DATABASE REGISTER LOGFILE 'U02/<DbUniqueName>/ARCHIVELOG/2018_01_19/thread_1_seq_12145.643.965816317';

ALTER DATABASE REGISTER LOGFILE 'U02/<DbUniqueName>/ARCHIVELOG/2018_01_19/thread_1_seq_12146.644.965816317';

ALTER DATABASE REGISTER LOGFILE 'U02/<DbUniqueName>/ARCHIVELOG/2018_01_19/thread_1_seq_12147.266.965815979';

 

Instead of the statement more as last command in the pipe, the output could by written into a file.

Another example of generating statements for archivelogs with sequence numbers >= than a given number (here 12090)  (SeqNo="12090"):

SeqNo="12094"

P="U02/<DbUniqueName>/ARCHIVELOG/2018_01_19/"

echo "ls -l $P" |

  asmcmd |

  head |

  awk -v A="'" -v p="$P" -v n="$SeqNo" '/^ARCH/{

    if(n!="") { 

      match($0, /.+_([0-9]+)\./, sn)

    }

    if(n=="" || sn[1]>=n) {

      print "ALTER DATABASE REGISTER LOGFILE "A p $8 A";" 

    }

  }' |

  more

Output

ALTER DATABASE REGISTER LOGFILE 'U02/<DbUniqueName>/ARCHIVELOG/2018_01_19/thread_1_seq_12094.415.965815957';

ALTER DATABASE REGISTER LOGFILE 'U02/<DbUniqueName>/ARCHIVELOG/2018_01_19/thread_1_seq_12095.432.965815957';

ALTER DATABASE REGISTER LOGFILE 'U02/<DbUniqueName>/ARCHIVELOG/2018_01_19/thread_1_seq_12096.428.965815957';

If an "empty" SeqNo is given, this parameter will be ignored

SeqNo=""

P="U02/<DbUniqueName>/ARCHIVELOG/2018_01_19/"

echo "ls -l $P" |

  asmcmd |

  head |

  awk -v A="'" -v p="$P" -v n="$SeqNo" '/^ARCH/{

    if(n!="") { 

      match($0, /.+_([0-9]+)\./, sn)

    }

    if(n=="" || sn[1]>=n) {

      print "ALTER DATABASE REGISTER LOGFILE "A p $8 A";" 

    }

  }' |

  more

Output: all archivelogs are now listed

ALTER DATABASE REGISTER LOGFILE 'U02/<DbUniqueName>/ARCHIVELOG/2018_01_19/thread_1_seq_1.444.965820029';

ALTER DATABASE REGISTER LOGFILE 'U02/<DbUniqueName>/ARCHIVELOG/2018_01_19/thread_1_seq_10.440.965828087';

ALTER DATABASE REGISTER LOGFILE 'U02/<DbUniqueName>/ARCHIVELOG/2018_01_19/thread_1_seq_12090.404.965815957';

ALTER DATABASE REGISTER LOGFILE 'U02/<DbUniqueName>/ARCHIVELOG/2018_01_19/thread_1_seq_12091.399.965815959';

ALTER DATABASE REGISTER LOGFILE 'U02/<DbUniqueName>/ARCHIVELOG/2018_01_19/thread_1_seq_12092.398.965815959';

ALTER DATABASE REGISTER LOGFILE 'U02/<DbUniqueName>/ARCHIVELOG/2018_01_19/thread_1_seq_12093.397.965815959';

ALTER DATABASE REGISTER LOGFILE 'U02/<DbUniqueName>/ARCHIVELOG/2018_01_19/thread_1_seq_12094.415.965815957';

ALTER DATABASE REGISTER LOGFILE 'U02/<DbUniqueName>/ARCHIVELOG/2018_01_19/thread_1_seq_12095.432.965815957';

ALTER DATABASE REGISTER LOGFILE 'U02/<DbUniqueName>/ARCHIVELOG/2018_01_19/thread_1_seq_12096.428.965815957';

Correcting Oracle DB Errors: ORA-01153, ORA-16136, ORA-16766, ORA-16826, ORA-38706, ORA-38788

After having re-build the standby DB, I've got the following error trying to enable the flashback:

SQL> 

alter database flashback on;

alter database flashback on

*

ERROR at line 1:

ORA-38706: Cannot turn on FLASHBACK DATABASE logging.

ORA-38788: More standby database recovery is needed

In order to solve the problem, I tried to start the recovery . . .

SQL> 

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

ORA-16136: Managed Standby Recovery not active

. . . the error from above, reminded my that I forgot to start the DataGuard Broker on the primary DB. So I did it:

SQL> alter system set dg_broker_start=true;

This was not enough.

On the Data Guard Manager console, I've remarked the following error for the standby DB

. . .

DGMGRL> show configuration verbose;

. . .

        Error: ORA-16766: Redo Apply is stopped

Since I remembered, that I once solved this error by making sure that the physical standby DB really starts on MOUNT mode, I've checked it an restarted the standby DB:

OS>

srvctl modify database -d <MyPhysicalStandbyDbUniqueName> -r PHYSICAL_STANDBY -s mount

srvctl stop database -d <MyPhysicalStandbyDbUniqueName>

srvctl start database -d <MyPhysicalStandbyDbUniqueName>

And checked its configuration

OS>

srvctl config database -d <MyPhysicalStandbyDbUniqueName>

But when re-trying to start the recovery I've got another error:

SQL>

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT

*

ERROR at line 1:

ORA-01153: an incompatible media recovery is active

This was caused by the running recovery process (MRP0) . . .

SQL> 

select PROCESS,CLIENT_PROCESS,THREAD#,SEQUENCE#,BLOCK# from v$managed_standby where process = 'MRP0' or client_process='LGWR';

PROCESS CLIENT_P THREAD# SEQUENCE# BLOCK#

--------- -------- ---------- ---------- ----------

RFS LGWR 1 1551 125

MRP0 N/A 1 1551 125

. . . that I've stopped:

SQL>

alter database recover managed standby database cancel;

Database altered.

Check:

SQL>

select PROCESS,CLIENT_PROCESS,THREAD#,SEQUENCE#,BLOCK# from v$managed_standby where process = 'MRP0' or client_process='LGWR';

PROCESS CLIENT_P THREAD# SEQUENCE# BLOCK#

--------- -------- ---------- ---------- ----------

RFS LGWR 1 1551 125

Not I've re-tryied to enable the flash back again => with success

SQL>

alter database flashback on;

Database altered.

But the Data Guard Manager console shows that the redo apply is still stopped

DGMGRL>

show configuration verbose;

. . .

      Error: ORA-16766: Redo Apply is stopped

So, I re-tried to start it again:

SQL>

alter database recover managed standby database disconnect from session;

Database altered.

But the DataGuard Manager console shows that 

DGMGRL>

show configuration verbose;

. . .

      Warning: ORA-16826: apply service state is inconsistent with the DelayMins property

Ops, I used the wrong option when re-trying to start the recovery (I did not start it on the "MANAGED REAL TIME APPLY" mode).

Verify this with this query on the PRIMARY SITE:

SQL>

SET LINES 200

column DEST_NAME format A20;

column RECOVERY_MODE format A30;

select DEST_ID, DEST_NAME, RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS;

Output example:

   DEST_ID DEST_NAME            RECOVERY_MODE

---------- -------------------- --------------------

         1 LOG_ARCHIVE_DEST_1   IDLE

         2 LOG_ARCHIVE_DEST_2   MANAGED

         3 LOG_ARCHIVE_DEST_3   IDLE

. . .

It is only MANAGER, not 

After stopping the recovery again and restarting it "with REAL TIME APPLY"

SQL>

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE cancel;

Database altered.

SQL>

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE disconnect;

Database altered.

The recovery is now on "REAL TIME APPLY" mode:

SQL>

SET LINES 200

column DEST_NAME format A20;

column RECOVERY_MODE format A30;

select DEST_ID, DEST_NAME, RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS;

   DEST_ID DEST_NAME            RECOVERY_MODE

---------- -------------------- ------------------------------

         1 LOG_ARCHIVE_DEST_1   IDLE

         2 LOG_ARCHIVE_DEST_2   MANAGED REAL TIME APPLY

         3 LOG_ARCHIVE_DEST_3   IDLE

         4 LOG_ARCHIVE_DEST_4   IDLE

. . .

And the DataGuard Manager console shows that all is OK:

DGMGRL> show configuration verbose;

Configuration Status:

SUCCESS