How to Resolve OEM Agent ‘Availability Evaluation Error’

 

Issue : While registering a database as a target in OEM 13c the agent was failing during start with following error  ‘Availability Evaluation Error’


Solution:-

To resolve the issue make I followed the following steps in following order .

Run this from db target server which you are trying to add as a target in OEM

cd $AGENT_HOME/agent_inst/bin

$ ping omshost

$ nslookup omshost

$ emctl pingOMS

$ emctl config agent addinternaltargets

$ emctl secure agent

$ emctl config agent listtargets

$ emctl clearstate agent

$ emctl upload agent

$ emctl reload agent

$ emctl start agent

 

The agent should show UP now, otherwise continue with the following steps:

 

$ emctl stop agent

$ emctl secure agent

$ emctl clearstate agent

$ emctl secure agent

$ emctl start agent

$ emctl upload agent

$ emctl reload agent

$ emctl pingOMS

$ emctl status agent

 

 

 

 

How to fix No ADR base is set message

 

No ADR homes are set

 

Recently for one my customer, I upgraded database from 12c to 19c. So after upgrade when I tried to use adrci utility It showed me “No ADR base is set” message

 

[oracle@oda02 ~]$ adrci

 

ADRCI: Release 19.0.0.0.0 - Production on Sun Nov 20 12:12:58 2022

 

Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.

 

No ADR base is set

adrci> show homes

No ADR homes are set

 

Solution:-

The reason behind above message is adrci utility is unable to find any information about ADR base .

 

Create following directory in new oracle home

[oracle@oda02 ~]$ echo $ORACLE_HOME

/u01/app/odaorahome/oracle/product/19.0.0.0/dbhome_1

 

[oracle@oda02 dbhome_1]$ mkdir -p $ORACLE_HOME/log/diag

 

 

Now copy the following file from old ORACLE_HOME i.e. 12c home in our case

[oracle@oda02$ cd /u01/app/odaorahome/oracle/product/12.1.0.2/dbhome_1/log/diag/

 [oracle@oda02$ cp adrci_dir.mif $ORACLE_HOME/log/diag/

 

Now lets check ADR home using adrci utility

[oracle@oda02 diag]$ adrci

 

ADRCI: Release 19.0.0.0.0 - Production on Sun Nov 20 12:23:30 2022

 

Copyright (c) 1982, 2019, Oracle and/or its affiliates.  All rights reserved.

 

ADR base = "/u01/app/odaorabase0"

adrci> show homes

ADR Homes:

diag/rdbms/orcl/orcl

 

 

Now we are able to see the homes in ADR base.

Steps to move AUD$ table to a different tablespace in 19c

 

By default oracle stores audit data in system tablespace. Most of the customers tend to keep it in default tablespace but as a best practice its best to move the AUD$ table in a non system tablespaces.

 

Step 1:-To find out existing tablespace of AUD$ table:-

SQL> select owner,segment_name,segment_type,tablespace_name,bytes/1024/1024 as Size from dba_segments where segment_name='AUD$';

 

OWNER           SEGMENT_NAME         SEGMENT_TYPE       TABLESPACE_NAME       Size

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

SYS             AUD$                 TABLE              SYSTEM               10.0625

 

Step 2:- Create a tablespace to move AUD$ table data

SQL> create tablespace TBS_AUDIT datafile 'D:\ORACLE\ORADATA\ORCL\TS_AUDIT01.DBF' size 15G autoextend on next 1G maxsize unlimited;

 

Step 3:- Use DBMS_AUDIT_MGMT procedure to move the data into newly created tablespace

SQL> BEGIN

DBMS_AUDIT_MGMT.SET_AUDIT_TRAIL_LOCATION(audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,

audit_trail_location_value => 'TBS_AUDIT');

END;

/

 

PL/SQL procedure successfully completed.

 

Step 4: Check the AUD$ tablespace

SQL> select owner,segment_name,segment_type,tablespace_name,bytes/1024/1024 from dba_segments where segment_name='AUD$';

 

OWNER           SEGMENT_NAME         SEGMENT_TYPE       TABLESPACE_NAME       Size

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

SYS             AUD$                 TABLE              TBS_AUDIT              10.0625

 

 

 

How to change compatible parameter in Standby & Primary database

Env Details:-

Primary DB Version: 19.15

Env : RAC 2 node Exadata

GI: 19.15.0.0

OS: OEL 7


Standby DB Version : 19.15

Env : Standalone DB on ODA

GI: 19.15.0.0

OS: OEL 7


Scenario: - For one of my customers, there was a requirement to change compatible parameter in both primary and standby database. The customer went through a database upgrade (12c to 19c) activity and had GRP (Guaranteed Restore Point) in the database. The GRP was kept for a week post DB upgrade to make sure there is in case of any requirement Database can fall back to its old version. Now after a week, once GRP was dropped, we had to set compatible parameter to 19.0.0 in both primary and standby database. Following are the steps that I performed to achieve this.

Steps:-

First make sure there is no log gap between primary & Standby Database

SQL> SELECT ARCH.THREAD# "Thread", ARCH.SEQUENCE# "Last Sequence Received",

  2  APPL.SEQUENCE# "Last Sequence Applied", (ARCH.SEQUENCE# - APPL.SEQUENCE#) "Difference"

  3  FROM

  4  (SELECT THREAD# ,SEQUENCE# FROM V$ARCHIVED_LOG WHERE (THREAD#,FIRST_TIME ) IN

  5  (SELECT THREAD#,MAX(FIRST_TIME) FROM V$ARCHIVED_LOG GROUP BY THREAD#)) ARCH,

  6  (SELECT THREAD# ,SEQUENCE# FROM V$LOG_HISTORY WHERE (THREAD#,FIRST_TIME ) IN

  7  (SELECT THREAD#,MAX(FIRST_TIME) FROM V$LOG_HISTORY GROUP BY THREAD#)) APPL

  8  WHERE

  9  ARCH.THREAD# = APPL.THREAD#

 10  ORDER BY 1;

 

 

    Thread Last Sequence Received Last Sequence Applied Difference

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

         1                  97989                 97989          0

         2                  90142                 90142          0

 

Current compatible set in database

SQL> show parameter compatible

 

NAME                                 TYPE        VALUE

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

compatible                           string      12.1.0.2.0

 Now change the compatible parameter in standby database then do it on primary database.

On Standby DB:-

STANDBYDB_SQL> alter system set compatible='19.0.0' scope=spfile ;

After changing we need to bounce the database to get it in effect, so cancel the MRP apply.

STANDBYDB_SQL> alter database recover managed standby database cancel;

Now stop and start the standby database.

[oracle@standbydb]$ srvctl stop database -d $ORACLE_UNQNAME

[oracle@standbydb]$ srvctl start database -d $ORACLE_UNQNAME -o mount

Now start the MRP process to apply the redologs in standby db.

STANDBYDB_SQL> alter database recover managed standby database disconnect from session;

 

On Primary DB:-

Login to, primary database and change the compatible parameter.

PRIMARYDB_SQL> alter system set compatible='19.0.0' scope=spfile sid='*'; 

[oracle@primarydb]$ srvctl stop database -d $ORACLE_UNQNAME

[oracle@primarydb]$ srvctl start database -d $ORACLE_UNQNAME