XX_XXXXXXX is not a valid responsibility for the current user. Please contact your System Administrator.

 XX_XXXXXXX is not a valid responsibility for the current user. Please contact your System Administrator.

Issue: When user logs into EBS, he gets the following Error : 

xx_XXXXX  is not a valid responsibility for the current user. Please contact your System Administrator.

Solution:

1. Check if the responsibility is end dated.  Extend the end-date if required and try to login again. 

2. Check the profile option Applications Start Page for the user ( User Level). If there is any value defined, remove it and save it. Try to login again and it worked in our case. 

Before:

After:

Add disk in virtual box vm

 Add disk in virtual box vm 

In this post, we will check how to add disks in Virtual Box VM. 

1. First add the disk from VM console as a new HDD as shown below:

We have recently added oel76_db1.vdi disk.

2. Once the disk is added, it will be visible in fdisk -l command output. 

3. create the partion using below command

fdisk /dev/sdb 

for new partion : type n, 

to list partition : type p

to write the partion : type w

4. Format the partition by below command:

Now format the disk with mkfs command.

# mkfs.ext4 /dev/sdb1

[root@oel76 etc]# mkfs.ext4 /dev/sdb1

mke2fs 1.42.9 (28-Dec-2013)

Filesystem label=

OS type: Linux

Block size=4096 (log=2)

Fragment size=4096 (log=2)

Stride=0 blocks, Stripe width=0 blocks

15032320 inodes, 60108800 blocks

3005440 blocks (5.00%) reserved for the super user

First data block=0

Maximum filesystem blocks=2208301056

1835 block groups

32768 blocks per group, 32768 fragments per group

8192 inodes per group

Superblock backups stored on blocks:

        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,

        4096000, 7962624, 11239424, 20480000, 23887872

Allocating group tables: done

Writing inode tables: done

Creating journal (32768 blocks): done

Writing superblocks and filesystem accounting information: done

[root@oel76 etc]#

5. mount the disk using below command:

mount /dev/sdb1 /u02

6. Add entry in /etc/fstab file to automatically mount the disk during startup

/dev/sdb1               /u02                    ext4    defaults        0 0

Exception in thread "main" java.lang.UnsatisfiedLinkError: /u01/soft/ebs/startCD/Disk1/rapidwiz/jre/Linux_x64/1.6.0/lib/i386/xawt/libmawt.so: libXtst.so.6: cannot open shared object file: No such file or directory

Error while launching rapidwiz during EBS 12.2 Installation

 Exception in thread "main" java.lang.UnsatisfiedLinkError: /u01/soft/ebs/startCD/Disk1/rapidwiz/jre/Linux_x64/1.6.0/lib/i386/xawt/libmawt.so: libXtst.so.6: cannot open shared object file: No such file or directory

[oracle@oel76 rapidwiz]$ Exception in thread "main" java.lang.UnsatisfiedLinkError: /u01/soft/ebs/startCD/Disk1/rapidwiz/jre/Linux_x64/1.6.0/lib/i386/xawt/libmawt.so: libXtst.so.6: cannot open shared object file: No such file or directory

        at java.lang.ClassLoader$NativeLibrary.load(Native Method)

        at java.lang.ClassLoader.loadLibrary0(Unknown Source)

        at java.lang.ClassLoader.loadLibrary(Unknown Source)

        at java.lang.Runtime.load0(Unknown Source)

        at java.lang.System.load(Unknown Source)

        at java.lang.ClassLoader$NativeLibrary.load(Native Method)

        at java.lang.ClassLoader.loadLibrary0(Unknown Source)

        at java.lang.ClassLoader.loadLibrary(Unknown Source)

        at java.lang.Runtime.loadLibrary0(Unknown Source)

        at java.lang.System.loadLibrary(Unknown Source)

        at sun.security.action.LoadLibraryAction.run(Unknown Source)

        at java.security.AccessController.doPrivileged(Native Method)

        at sun.awt.NativeLibLoader.loadLibraries(Unknown Source)

        at sun.awt.DebugHelper.<clinit>(Unknown Source)

        at java.awt.Component.<clinit>(Unknown Source)

Could not find the main class: oracle.apps.ad.rapidwiz.RIWizard.  Program will exit.

Soltuion:

Mount the Linux CD Rom and then replace the below packages from the CDROM

cd /run/media/root/OL-7.6 Server.x86_64/Packages

rpm -Uhv libXtst-* libXi-* --replacepkgs --force

This worked

Additionally, if it doen't work.. please try to replace the below packages also. 

cd /run/media/root/OL-7.6 Server.x86_64/Packages

rpm -Uhv libXext-1.1-3.el7* libXext-devel-1.1-3.el7* libX11-*.rpm libxcb-*.rpm libXau-*.rpm --replacepkgs

/lib/ld-linux.so.2: bad ELF interpreter: No such file or directory - while building stage during 12.2

 /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory

Cause

• The Linux box is on a 64-bit system, and does not have 32-bit library support installed.

• Resolution

  Make sure glibc.i686 and glibc.x86_64 is installed on the system.
  If glibc.i686 is not available on the Centos-6, try glibc.i386

  To list all the package with prefix "glibc"
  Run:
  yum list glibc.
  
  To install the package:
  Run
  sudo yum install glibc.i686
  or
  sudo yum install glibc.i386
  
  If you do not have sudo setup in the environment, type "su" to accquire superuser authority first.
  Then run:
  yum install glibc.i686

ORA-12777: A non-continuable error encountered.

 ORA-12777: A non-continuable error encountered.  Check the error stack for additional information [ksm_check_ob_paths:1], [ORACLE_BASE], [], [].

After moving the 19c Database Oracle Home to new location, i relinked the binaries and then tried to start up the database.  Got the below error:

ORA-12777: A non-continuable error encountered.  Check the error stack for additional information [ksm_check_ob_paths:1], [ORACLE_BASE], [], [].

Solution:

Correct the path of Oracle Home in the orabasetab file under $ORACLE_HOME/Install location

e.g 

oraprod@erpdbpreprod1:/u01/app/oracle/product/19.0.0/dbhome_3/install$ cat orabasetab

#orabasetab file is used to track Oracle Home associated with Oracle Base

/u01/app/oracle/product/19.0.0/dbhome_3:/u01/app/oracle/product/19.0.0:SPROD_DB__u01_app_oracle_product_19_0_0_dbhome_3:N:

Note: dbhome_1 was corrected to dbhome_3 

19c RMAN-04006: error from auxiliary database: ORA-12514: TNS:listener does not currently know of service requested in connect descriptor

 19c RMAN-04006: error from auxiliary database: ORA-12514: TNS:listener does not currently know of service requested in connect descriptor

Before doing an RMAN DUPLICATE DATABASE from an Active Database, we need to set up listener on the target environment with static registration.  Else when the RMAN shuts down the auxiliary database for creating spfile or making changes in it, it will not be able to connect the auxiliary and start the database (nomount) and throw the error :

RMAN-04006: error from auxiliary database: ORA-12514: TNS:listener does not currently know of service requested in connect descriptor

To Solve this issue ensure that listener is configured with static registration using the below syntax :

========= LISTENER.ORA==================

EBSUPG=

  (DESCRIPTION_LIST =

    (DESCRIPTION =

      (ADDRESS = (PROTOCOL = TCP)(HOST =<hostname>)(PORT = 1536))

      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1536))

    )

  )

SID_LIST_EBSUPG=

  (SID_LIST =

    (SID_DESC =

      (GLOBAL_DBNAME = EBSUPG)

      (ORACLE_HOME = /u01/app/oracle/product/19.0.0/dbhome_1)

      (SID_NAME = EBSUPG)

    )

  )

ADR_BASE_LISTENER_EBSUPG = /u01/app/oracle

=================================================================

When we check the listener status, it should show as UNKNOWN instead of BLOCKED 

-bash-4.4$ lsnrctl status EBSUPG

LSNRCTL for Solaris: Version 19.0.0.0.0 - Production on 30-SEP-2022 13:57:46

Copyright (c) 1991, 2021, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=10.92.27.104)(PORT=1536)))

STATUS of the LISTENER

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

Alias                     EBSUPG

Version                   TNSLSNR for Solaris: Version 19.0.0.0.0 - Production

Start Date                30-SEP-2022 13:35:31

Uptime                    0 days 0 hr. 22 min. 14 sec

Trace Level               off

Security                  ON: Local OS Authentication

SNMP                      OFF

Listener Parameter File   /u01/app/oracle/product/19.0.0/dbhome_1/network/admin/listener.ora

Listener Log File         /u01/app/oracle/diag/tnslsnr/STDBY4BKP/ebsupg/alert/log.xml

Listening Endpoints Summary...

  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=hostname)(PORT=1536)))

  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1536)))

Services Summary...

Service "EBSUPG" has 1 instance(s).

  Instance "EBSUPG", status UNKNOWN, has 1 handler(s) for this service...

The command completed successfully

This solved my issue and it started with the ACTIVE DUPLICATE.

ORA-01111: name for data file 975 is unknown - rename to correct file MRP0: Background Media Recovery terminated with error 1111

 ORA-01111: name for data file 975 is unknown - rename to correct file  MRP0: Background Media Recovery terminated with error 1111

Issue: 

Standby database throws below errors and stops the MRP. 

MRP0: Background Media Recovery terminated with error 1111

Errors in file /u01/app/oraprod/diag/diag/rdbms/sprod/SPROD1/trace/SPROD1_pr00_23061.trc:

ORA-01111: name for data file 975 is unknown - rename to correct file

ORA-01110: data file 975: '/u01/app/oraprod/11.2.0.4/dbs/UNNAMED00975'

ORA-01157: cannot identify/lock data file 975 - see DBWR trace file

ORA-01111: name for data file 975 is unknown - rename to correct file

ORA-01110: data file 975: '/u01/app/oraprod/11.2.0.4/dbs/UNNAMED00975'

Recovery Slave PR00 previously exited with exception 1111

Solution:

- Please cancel the managed recovery by

SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

- Set standby_file_management=manual

SQL>ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=MANUAL;

If the physical standby database is RAC, then please make the change to all standby instances.

SQL>ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=MANUAL SID='*';

alter database create datafile '/u01/app/oraprod/11.2.0.4/dbs/UNNAMED00975' as '+DATA_DG' size 30g;

- Set standby_file_management=auto 

SQL>ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;

If the physical standby database is RAC, then please make the change to all standby instances.   

SQL>ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO SID='*';

- Start managed recovery by  

SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;