Activate Trace in SM50 for failed logon attempt to /irj/portal issues.

If the authentication was rejected at the ABAP level
, please capture SM50 trace of a failed logon attempt to /irj/portal.
Please reproduce the issue in the following way
(1) Set the security trace level in the ticket accpting system
======================================================
1. Call transaction SM50 (process list):
2. Process -> Trace -> Reset -> Workprocess Files
3. Key combination: F5 (select all), CTRL-Shift-F7 => Dialog box;
4. Set trace level=3 and ONLY(!) check the "Security" component;
If necessary, you must repeat these steps for each server (see
transaction SM51), unless you can use a specific server for
reproducing the error (for example, by excluding the load
distribution).
Please provide us exact time of failed logon attempt and the user you
used.

Redirecting HTTP requests to HTTPS

  
 All HTTP requests will be redirected to HTTPS by using below SAP Parameter
=========================================================

Maintain the below SAP parameter in Default profile.


icm/HTTP/redirect_0 = PREFIX=/, FROM=*, FROMPROT=http, PROT=https 

How to Activating emergency user (Super Administrator User (sap*)) in JAVA Stack

Go to Config Tool -> click on the button “Switch to configuration edit mode”
Expand the tree :-
“Cluster_data -> Server -> cfg -> Services -> Propertysheet com.sap.security.core.ume.service”

When the “Super Administrator” parameter is activated to true and the password being reset, all other users will locked.
Set the parameters
ume.superadmin.activated = true
ume.superadmin.password = a new password

Restart the Java Cluster...

Logon as sap* and new password, correct the problem. then revert the change made to the parameter ume.superadmin.activated to false and Restart the Java Cluster.

How to bring a Standby DB in Sync with Promary DB , if the Stand By DB was in Out of Sync

If found Standby DB(DR Server) is not in sync with Primary Database ,Follow the below steps to make it in sync with Primary DB.

1.Check the Status of log sequence with below query

SQL>select sequence#, status, process from v$managed_standby;

SEQUENCE#     STATUS       PROCESS
----------             ------------          ---------
    137675        CLOSING               ARCH
    137673        CLOSING               ARCH
    137674        CLOSING               ARCH
         0        CONNECTED             ARCH
         0                  IDLE                  RFS
    137676             IDLE                  RFS
         0                  IDLE                  RFS
    137576 WAIT_FOR_LOG        MRP0
         0                  IDLE                   RFS
2.Check the archive gap.(v$archive_gap only shows the log sequences of the next gap that needs to be resolved)

        SQL>SELECT * FROM V$ARCHIVE_GAP;

To find out how far behind your standby is (in days), try this query on the standby:

3.SQL> select name,sequence#,archived,applied from v$archived_log order by sequence#;

  
If the Gap is more like in the above example Standby DB showing 100 Archive gap with Primary DB and status is  showing "WAIT_FOR_LOG"
   

4)Check first if the archive log file which is showing "WAIT_FOR_LOG" is available in /Oracle/SID/Oraarach or not.

5)if not available try to copy mannually from primary or restore from tape
        brrestore -a 136541 -c -d util_file -r /oracle/SID/112_64/dbs/initSID.utl

 6)Once the archive log available in "oraarch" directory register the log file in Standby DB using below command:

 SQL>ALTER DATABASE REGISTER LOGFILE '/oracle/SID/oraarch/SIDarch1_136541_701090413.dbf';

  7)Then check the status again

        SQL>select sequence#, status, process from v$managed_standby;

SEQUENCE#     STATUS       PROCESS
----------             ------------          ---------
    137675        CLOSING               ARCH
    137673        CLOSING               ARCH
    137674        CLOSING               ARCH
         0        CONNECTED             ARCH
         0                  IDLE                  RFS
    137676             IDLE                  RFS
         0                  IDLE                  RFS
    137576  APPLYING LOG       MRP0
         0                  IDLE                   RFS

If the status changed to "APPLING LOG " Then the issue resolved .Now rest of the logs will applied automatically if not applying automatically then follow the above steps.

 8)Check the applied logs status

        SQL>select name,sequence#,archived,applied from v$archived_log order by sequence#;

It should show the status as applied.

 SEQUENCE# ARC APPLIED
----------            ---     ---------
/oracle/SID/oraarch/SIDarch1_137575_701090413.dbf
    137575 YES YES

ORA-01274: cannot add datafile '/oracle/SID/sapdata2/dat_19/dat.data19' - file could not be created Recovery interrupted!

If the Parameter STANDBY_FILE_MANAGEMENT is set to MANUAL , we will get below error in Standby Databae (DR) while adding a datafile in Primary Database. And this will bring the DR out of sync. " ORA-01274: cannot add datafile '/oracle/SID/sapdata2/dat_19/dat.data19' - file could not be created Recovery interrupted!" Solution : On standby(DR) database: SQL> select name from v$datafile where name like '%UNNAMED00039%'; NAME -------------------------------------------------------------------------------- /oracle/SID/112_64/dbs/UNNAMED00039 On production database: SQL> select name from v$datafile where file# = 39; NAME -------------------------------------------------------------------------------- /oracle/SID/sapdata2/dat_19/dat.data19 And finally on standby database alter the database using below command: SQL> alter database create datafile '/oracle/SID/112_64/dbs/UNNAMED00039' as '/oracle/SID/sapdata2/dat_19/dat.data19'; Recomendation :: Permanently set  STANDBY_FILE_MANAGEMENT to AUTO in Standby Database.

Oracle Data Guard (ODG) Management During Outage in SAP Production Server & DR Server

 Oracle Data Guard (ODG) Management During Outage in SAP Production Server & DR Server

----------------------------------------------------------------------------     
                Before Outage :
----------------------------------------------------------------------------

In Production
=============
1) SQL>alter system set log_archive_dest_state_2 = 'defer';

In DR
=====
2) SQL> alter database recover managed standby database cancel;
   SQL> shutdown immediate;

---------------------------------------------------------------------------
            After Outage :
---------------------------------------------------------------------------

In Production
=============

1) SQL> alter system set log_archive_dest_state_2 = 'enable';

In DR
====
2) SQL> startup nomount;
   SQL> alter database mount standby database;
   SQL> alter database recover managed standby database disconnect from session;

In Production
=============

3) SQL> select status, error from v$archive_dest where dest_id=2;

The value should be "Valid". It will take some time to show the value as "Valid".
------------------------------------------------------------------------------
            DR Sync Checking
-----------------------------------------------------------------------------
In DR
====
To check the DR Sync :

SQL> set linesize 80;
SQL> column name format a60;
SQL> select name,sequence#,archived,applied from v$archived_log order by sequence#;

SQL> select process,status from v$managed_standby;

SQL> select message from v$dataguard_status;

[INS-30060] Check for group existence failed in Oracle 11g(Solaris)

[INS-30060] Check for group existence failed.

Solution:

 Note 1431796 - Oracle 11.2.0: Troubleshooting the Software Installation

OS> ls -la /var/tmp/CVU* (Solaris)

Solaris:
OS> chown -R <user>:<group> /var/tmp/CVU_11.2.0.*
or
OS> rm -rf /var/tmp/CVU_11.2.0.*