ORA-20411: Monitoring credentials not set for target

While promoting auto-discovered targets in OEM 13.4, the following errors occur:

“ORA-20411: Monitoring credentials not set for target name RACTESTDB target type rac_database set nameDBCredsMonitoring”

After testing monitoring user DBSNMP credentials , all works fine.

WORKAROUND

Remove the auto discovered targets, and manually add them into OEM again by :

Setup -> Add Target -> Add Targets Manually -> Add Using Guided Process

ORA-01578 ORA-01110 ORA-26040: Data block was loaded using the NOLOGGING option

Alert log shows following ORA- errors:

ORA-01578:ORACLE data block corrupted (file # 13, block # 652351)
ORA-01110:data file 13:'/media/sf_software/oradata/OEMREP/EMPDBREPOS/mgmt.dbf'
ORA-26040:Data block was loaded using the NOLOGGING option

Find out the segment impacted, and confirm this is an empty table.

SQL>select OWNER, SEGMENT_NAME, SEGMENT_TYPE, TABLESPACE_NAME 
    from dba_extents 
   where file_id =13 and 652351 between block_id AND block_id+blocks-1;

OWNER    SEGMENT_NAME           SEGMENT_TYPE   TABLESPACE_NAME
-------- ---------------------  -------------- ----------------
SYSMAN   MOS_PA_EVAL_TARGETS_E  TABLE          MGMT_TABLESPACE
SQL> select count(*) from SYSMAN.MOS_PA_EVAL_TARGETS_E;

COUNT(*)
----------
0
SQL>select FILE#, BLOCK#, BLOCKS,scn_to_timestamp(NONLOGGED_START_CHANGE#), 
           scn_to_timestamp( NONLOGGED_END_CHANGE#), OBJECT# 
    from v$nonlogged_block;

FILE# BLOCK#   BLOCKS  SCN_TO_TIMESTAMP(NONLOGGED_START_CHANGE#)  SCN_TO_TIMESTAMP(NONLOGGED_END_CHANGE#)  OBJECT#
---------------------- -----------------------------------------  ---------------------------------------  -------
13   652351   1        12-MAY-20 11.58.27.000000000 AM           12-MAY-20 10.59.29.000000000 PM           91461

Truncate or move the table. 

SQL>truncate table SYSMAN.MOS_PA_EVAL_TARGETS_E;

or

SQL> alter table SYSMAN.MOS_PA_EVAL_TARGETS_E move tablespace MGMT_TABLESPACE;

luckily, the table is empty. it is easy to deal with. If table is not empty, then we can skip corrupted blocks to avoid DML ORA- errors.

Skip corrupt blocks 

SQL> select * from SYSMAN.STG_MOS_PA_EVAL_TARGETS_E;

select * from SYSMAN.STG_MOS_PA_EVAL_TARGETS_E
                      *
ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 13, block # 652351)
ORA-26040: Data block was loaded using the NOLOGGING option
BEGIN
  DBMS_REPAIR.skip_corrupt_blocks (
    schema_name => 'SYSMAN',
    object_name => 'MOS_PA_EVAL_TARGETS_E',
    object_type => DBMS_REPAIR.table_object,
    flags       => DBMS_REPAIR.skip_flag);
END;
/
 
SQL> select owner, table_name, SKIP_CORRUPT  from dba_tables 
      where table_name='MOS_PA_EVAL_TARGETS_E'

OWNER      TABLE_NAME                     SKIP_COR
---------- ------------------------------ --------
SYSMAN     MOS_PA_EVAL_TARGETS_E          ENABLED

Backup the table data, truncate the table , and then restore the table data

SQL> create table SYSMAN.STG_MOS_PA_EVAL_TARGETS_E as 
            select * from SYSMAN.MOS_PA_EVAL_TARGETS_E;

SQL> Truncate table SYSMAN.MOS_PA_EVAL_TARGETS_E;

SQL>Insert into SYSMAN.MOS_PA_EVAL_TARGETS_E 
                select * from SYSMAN.STG_MOS_PA_EVAL_TARGETS_E ;

The nologging corrupt block is returned to free space list

SQL> Select BYTES from dba_free_space 
     where file_id=13 and 652351 between block_id and block_id + blocks -1;

BYTES
----------
65536

SQL> select * from dba_extents 
     where file_id =13 and 652351 between block_id AND block_id+blocks-1;

no rows selected

After a little while, the nologging corrupt block will be reused

SQL> Select BYTES from dba_free_space
where file_id=13 and 652351 between block_id and block_id + blocks -1; 

no rows selected

SQL> select count(*) from dba_extents
where file_id =13 and 652351 between block_id AND block_id+blocks-1; 

COUNT(*)
----------
1

DUPLICATE FROM ACTIVE DATABASE Fails With RMAN-03009 ORA-17628 ORA-19505

While creating a new physical standby database by using RMAN duplicate command, the following errors occur:

RMAN> run {
allocate channel prim1 type disk;
allocate channel prim2 type disk;
allocate auxiliary channel standby1 type disk;
DUPLICATE TARGET DATABASE
FOR STANDBY
FROM ACTIVE DATABASE
...
..
.
RMAN-03009: failure of backup command on prim2 channel 
ORA-17628: Oracle error 19505 returned by remote Oracle server
ORA-19505: failed to identify file ""

SOLUTION

  1. Check and remove the old standby database data files.
  2. Make sure directories for standby database data files created and accessible.

ORA-01012 While Starting Up Oracle Database

ISSUES

When starting up an Oracle database, the “ORA-01012: not logged on” occurs:

$ sqlplus / as sysdba
Connected to an idle instance.

SQL> startup
ORA-01012: not logged on
Process ID: 0
Session ID: 0 Serial number: 0

Subscribe to get access

Read more of this content when you subscribe today.

ORA-01940: cannot drop a user that is currently connected

Try to drop a user in a RAC environment with below errors :

SQL> drop user testuser cascade;
drop user testuser cascade
*
ERROR at line 1:
ORA-01940: cannot drop a user that is currently connected

There is no sessions, and objects for this user.

SQL> select count(*) from gv$session where username='TESTUSER';

COUNT(*)
----------
0
SQL> select count(*) from dba_objects where owner='TESTUSER';

COUNT(*)
----------
0

It seems there is internal issues in database for this user.

we can either wait for a while , or bounce the database. After this, it is OK to drop the user.

SQL> drop user TESTUSER cascade;

User dropped.