MM IDocs got stuck

It was related to MM team the IDocs got stuck and even by manually processing the IDocs in background with program RBDAPP01, it was getting hung ( the job was running for infinite time.

We were checking the Idocs in transaction WE02 and putting 64 (Idocs ready to be processed) in "Current Status" and Message Type in "Logical Message", but the numbers were not reducing.

Upon Analysis, we came to know that there was a long running process on application server avggsqeh by user 10501828 which was indirectly holding a table lock on NRIV table.

How we got the clue ?

In t-code DB01 there were entries like HOLD and __WAIT, the application server which was holding the lock was avggsqeh but it was not relevant to our activity,"Linked Locks" button but it was showing up time and again when we clicked on anyhow we logged on to the application server and saw that there was a long running process there and we killed that after that everthing went on fine.

UID error while adding dialogue instance

Hi,

Last night we had an issue with this server where we were adding application servers as dialogue instances and it was throwing us the errors, viz changue uid of the user zb5adm as it doesn't match with zb1adm.

As on single host there were many installations we were trying to figure out the relationship between zb5adm and zb1adm..at last we figured out that someone has compied profiles from zb1 to zb5 in /sapmnt/ZB5/profile directory and system was confused to read multiple profiles in one profile directory.

At the OS level the SAP application can only see uid and not the usernames, so issue was resolved by removing the redundant ZB1 profiles from /sapmnt/ZB5/profile directory.

SAPJSF user locked for UME connection

The scenarion is that the user SAPJSF got locked in ABAP stack of PI ZX2, the reason being UME Tech Team changed password of that user, now in configtool the ume.master.password is configured with SAPJSF user earlier old password so it got locked.

Secondly ZX2 system has eight application servers, even after changing the password in Global configuration of configtool the SAPJSF user is getting locked in backend ABAP stack, guess what, all the RFC of local server nodes are configured with SAPJSF user old password.

Resolution

First we configured the configtool of Global configuration in CI with RFC_USER so that we can run the visual admin because visual admin will not respond because of locked SAPJSF user, secondly we logged on to each application server node "RFC Provider " service to change the password of SAPJSF user as the RFC are configured for each local node and cannot be configured globally.

Easy way to list out software components of System

Goto SE16
put in CVERS table name and list out its components, it will give you the software component versions at one go in table form, much more visible than going to system and then status.

PA20 and PA30 tcode execution is very slow

There was an issue in our Project some users were facing extraordinarily long response times while using transactions PA20 and PA30, the resolution was as follows:

Do you happen to have structural authorization implemented ? If yes, this can cause performance issue when doing authrorization checking. To resolve this (only if you have struct auth implemented) , the user id would need to be added in T77UU, and SAP utility to re-generate index for structural auth (RHBAUS00) to be run after .

Source : https://forums.sdn.sap.com/thread.jspa?threadID=1458192

Oracle Schema User Locked in trans.log ORA-28000

951167- ORA-28000: the account is locked

Problem
You cannot log on to the Oracle database and the program returns the message:

ORA-28000: the account is locked



Reason and Prerequisites

ORA-28000 is usually triggered because someone has previously attempted to log on several times using an incorrect password, which causes the logon to fail and returns ORA-01017. The number of allowed logon attempts is defined by the resource FAILED_LOGIN_ATTEMPTS in the profile. You can determine the current value of this parameter using the following query:

SELECT LIMIT FROM DBA_PROFILES
WHERE
PROFILE = 'DEFAULT' AND
RESOURCE_NAME = 'FAILED_LOGIN_ATTEMPTS';

Until Oracle 10.1, this parameter had the default value UNLIMITED, so that no ORA-28000 messages would normally occur. As of Oracle 10.2, this standard value has been set to 10.

A further option in the case of a locked user is an explicit lock as follows:

ALTER USER ACCOUNT LOCK;


Solution

To prevent ORA-28000 errors, and avoid similar problems in future, be aware of the following:

If you use Oracle 9i or earlier, do not manually restrict the authorizations of the default profile (also refer to Note 700548 (16)).
If FAILED_LOGIN_ATTEMPTS is not set to UNLIMITED, you can adjust it as follows:

ALTER PROFILE DEFAULT LIMIT FAILED_LOGIN_ATTEMPTS UNLIMITED;
This is also possible for Oracle 10. 1 and earlier and Oracle 10.2 and later.

If a user is already locked, you can unlock it as follows:

ALTER USER ACCOUNT UNLOCK;
If the ORA-28000 error occurred due to a large number of failed logon attempts, you must check why these logon attempts were unsuccessful and returned the ORA-01017 error. The cause is often an incorrect configuration of the OPS$ mechanism. In this case, refer to Note 400241.

Why is it necessary to delete the tables ALCONSEG, ALSYSTEMS, DBSNP, MONI, OSMON, PAHI, SDBAD, SDBAP, SDBAR, TPFET, and TPHFT in an SAP System Refresh

Those tables contain information specific to the source system. On the target system this piece of information will be misleading or wrong.


Tables SDBAD, SDBAP, SDBAR are about backup history. Backups of the source system won't tell you anything about backups of the target system.

TPFET and TPHFT are about SAP instance profiles. You can't keep profiles of the source system; you will have to create new ones for the target system anyway.


Below tables:

SDBAP = SAP DBA Plan Table
SDBAR = SDBA Resource Table
SDBAH = Header table for DBA protocols
SDBAD = Detail table for DBA protocols

belong to sapdba. They contain the log information of the logs that
sapdba and BrBackup and BrArchive write. The sapdba -cleanup function
will enable you to delete the entries from the db-tables, as well as the
respective files in the operating system.

The tables
MONI = Monitor table
PAHI = History of OS system, DB and SAP parameters
ALAMO = Collector of alert events
OSMON = Operating system monitor data
DBSNP = Table for DB snapshots

contain statistical data tha can be displayed in transaction st04. They
can partially be deleted from within the R/3-System following
st04->Monitor->Performance->Database

Tables:
ALSYSTEMS:CCMS Central System Management: Remote Managed Systems

As they contain information related to that source system and will be misleading if copied to target system.

They can partially be deleted from within the R/3-System following
st04->Monitor->Performance->Database

If not work, you can truncate these tables with sqlplus.

sqlplus sapr3/sap
truncate table ;

There is another option to delete all the data with SE14, using database
utility.

Source : https://forums.sdn.sap.com/thread.jspa?threadID=1204044