While sending an email from SBWP, for example for testing if the SMTP is well configured, the below error is given:
When looking to see more details at display log book we can check the error:
As you might think this error is not generated because the user who is sending the email does not have the email address available in SU01. But this is not the case, even if this is not mentioned in the communication area of the user, the sender address will appear as USERNAME@DOMAIN.
The problem is that the domain is not defined. This can be added in SCOT -> Settings -> Default domain and add your company domain name.
After that you can retry resending the email with success from SBWP.
During SUM upgrade in the extraction phase PREP_INIT/INIT_CNTRANS_PRE the following error was encountered:
The following entries in table ‘TAORA’ do not represent existing DB containers: [TABART, DBSPACE]
DODS PSAPDATODS
The following entries in table ‘IAORA’ do not represent existing DB containers: [TABART, DBSPACE]
DODS PSAPDATODS
From the description of the error we can draw the conclusion that the TABART DODS is assingned to the tablespace PSAPDATODS, that does not exist.
I checked at database level and all tablespaces were present, including PSAPDATODS:
sqlplus / as sysdba
select TABLESPACE_NAME from USER_TABLESPACES;
TABLESPACE_NAME
------------------------------
PSAPDAT
PSAPDAT740
PSAPDATFACT
PSAPDATODS
PSAPDATUSR
PSAPTEMP
PSAPUNDO
SYSAUX
SYSTEM
Also in SAP all of them could be visible in table TSORA:
This sounds very strange, so let’s also verify the SUM logs to check exactly what it checks:
The tool runs 3 scripts (that can be found in /usr/sap/SID/SUM/abap/control/dbs/ORA): SELTAIA.ORA, TAIORA.SAP that list the correspondents between TABART and tablespaces and SELDBS.ORA that lists the name of available tablespaces. The output of the first 2 scripts seems ok but SELDBS.LOG, the log from SELDBS.ORA does not display all the tablespaces available in the database:
The reason why the output is different, is because SUM executes the sql statement under user schema owner, which lists a different output because in this case the database specific preparations mentioned in the SUM upgrade guide haven’t been checked.
The resource quotas of Oracle user SAP<SCHEMA-ID> or SAPSR3 have to be checked with the statement:
select * from dba_sys_privs where grantee = 'SAPSR3/SAP<SCHEMA-ID>';
As this does not exist, it has to be granted:
grant unlimited tablespace to sapsr3/SAP<SCHEMA-ID>;
After the grant was given the error was solved, SUM tool could see all the available tablespaces and jumped to the next step.
While deploying any components for a Java system, in case there was no valid maintenance certificate installed, the validation of the deployment queue was only ending with status warning and it was possible to continue with deployment without being mandatory to install the certificate, like this:
But with the latest SUM versions, I am not sure since when exactly, but I think it is somewhere since some patch of SUM SP21 this has changed and the installation of the maintenance certificate cannot be skipped anymore and this error will show up: “Validation of deployment queue completed with error: No valid Maintenance Certificate found on AS Java with SID XXX. For more information, refer to SAP Note 1236587 … ”
So in order to pass the error a valid maintenance certificate is mandatory to be installed for the Java application server. How to do that? First generate a new certificate on SAP Support Portal:
https://launchpad.support.sap.com/ => System Operations and Maintenance -> License Keys -> Select installation number -> Select the respective SID from the list -> Select the current HW key, License type Licence Entitlement and press button Renew certificate or if there is already one that has a validity date that is not expired, press download button:
Now that we have the license, we can also install it. This can be done from NWA -> Configuration -> Infrastructure -> Licenses -> Select the Maintenance certificate from the list -> Install from file button
And now we have an up to date maintenance certificate, retry the step from SUM, that should continue with success.
This post should be of interest for you if you want to deploy 3rd party drivers for the JDBC and JMS adapters within the com.sap.aii.adapter.lib.sda archive. I will not insist on the preparations that need to be done for this, but you can find the answer in this note: 1770304 – PI: Preparing the com.sap.aii.adapter.lib.sda for deployment. What I would like to discuss is the error that is showing up when the archive package will be deployed.
The deployment is done via SUM tool and the error appears during configuration phase:
[Error ]: The following problem has occurred during step execution: com.sap.sdt.util.diag.DiagException: Validation of deployment queue completed with error: com.sap.engine.services.dc.api.deploy.AllItemsAlreadyDeployedValidaionException: [ERROR CODE DPL.DCAPI.1031] AllItemsAlreadyDeployedValidationException. Reason: ASJ.dpl_dc.003456 All batch items are marked as AlreadyDeployed because of Version check. com.sap.engine.services.dc.api.deploy.AllItemsAlreadyDeployedValidaionException: [ERROR CODE DPL.DCAPI.1031] AllItemsAlreadyDeployedValidationException. Reason: ASJ.dpl_dc.003456 All batch items are marked as AlreadyDeployed because of Version check. com.sap.engine.services.dc.cm.deploy.AllItemsAlreadyDeployedValidationException: ASJ.dpl_dc.003456 All batch items are marked as AlreadyDeployed
because of Version check.
If you already got this error, SUM tool has to be stopped. Then, SUM has to be configured to run in force-mode, this can be done by adding the two parameters:
After the parameters were set, restart SUM and follow the same steps to deploy the drivers, this time the error should not appear anymore.
More information can be found in SAP note 1138877 – How to Deploy External Drivers JDBC/JMS Adapters, note that should be read actually before deploying such drivers. What you will not find in the note is the error that appears in case SUM is not started with this option.
During a support package stack upgrade, in Preprocessing phase of SUM, more explicit MAIN/SHDCRE/SUBMOD_SHDDBCLONE/DBCLONE the following error appeared:
If the upgrade fails during DBCLONE phase, there are not much details of the error that can be found in the logs of SUM.
During this stage, the job DBCLONE (that is actually divided in several DBCLONEX jobs running in parallel) is running, so if this job gets canceled it is important to check the job log, syslog and short dumps.
In my case the job was getting canceled with the short dump: DBSQL_SQL_ERROR CX_SY_OPEN_SQL_DB SQL error “SQL code: 39” occurred while accessing table “FDT_FNCT_0110S”. Database error text: “SQL message: ORA-00039: error during periodic action #ORA-04036: PGA memory used by the instance exceeds PGA_AGGREGATE_LIMIT”:
This error can occur under Oracle database 12c, where a new parameter related to PGA, in addition to the already existing PGA_AGGREGATE_TARGET has been introduced => PGA_AGGREGATE_LIMIT.
Until Oracle 12c, the sessions that used memory from the PGA for activities like sorting, group-by, hash-joins etc… could have grown without restrictions, even more than PGA_AGGREGATE_TARGET value, this was only set a a soft limit. It could have happened that this impacted the overall memory usage of the database. That is why PGA_AGGREGATE_LIMIT has to be seen as a hard limit, when it is reached, Oracle will kill the sessions that are using the most untunable memory.
In our case DBCLONE jobs were terminated when the value of PGA_AGGREGATE_LIMIT was reached. In order to solve this you can increase the value of the parameter PGA_AGGREGATE_LIMIT, that I would say it is the recommended method, but you have also the option to deactivate the hard limit, parameter PGA_AGGREGATE_LIMIT, by setting it to 0. In my case setting the parameter PGA_AGGREGATE_LIMIT to 4Gb from the default 2Gb (alter system set PGA_AGGREGATE_LIMIT=4096M scope=both;), was sufficient in order for the job to complete with success. The good part is that the parameter is dynamic, so no restart of the database is necessary to activate the parameter and you also have the option to test the correct value for you, more easily.
A common problem with SUM, is when the tool is attempted to be started and in browser the following error is being displayed:
“Not Found
Unable to locate the requested resource”
Even if after multiple attempts and maybe after a hostagent update, the same error is being displayed.
In this case there is a problem with one of host agent processes that remained hanged and if you check the processes at OS level you will notice 4 processes associated to the host agent:
The first process, that you can see with a different timestamp, it is the hanged one, kill this process and retry opening SUM tool, it should start successfully now.
Normally for hostagent, you should only see 3 process all the time, something similar to this:
Basically, the alerts are being generated because of some wrong setting in the auto-reaction method that is launched in the background, when job SAP_CCMS_MONI_BATCH_DP is running. But it is not necessary that the background job is canceled to get this error message.
The steps to find why this errors appear and solve them consist on these steps:
1. check RZ21 -> Method definitions -> display overview
2. Search for all methods with the keyword “mail”
3. For every of the existing methods that contains this word, check:
3.1. At the “Control” tab, ensure that the option “Periodically in dialog process” is set at the “Execute method” section.
3.2. At the “Parameters” tab, ensure that the SENDER option is correctly set in UPPER CASE letters, with a valid user that exists on client 000 and finally with an email address assigned.
This means that the steps above should be checked every time we delete a user from client 000, to make sure that there is no user assigned to any mail related auto-reaction method. The sudden appearance of this error could be cause by deleting such user.
Recently, searching the developer traces I found these messages, right at the beginning of the log:
RSecSSFs: Configuration value "rsec/ssfs_datapath" from profile explicitly overwritten by different value in environment variable RSEC_SSFS_DATAPATH [rsecssfs.c 4677]
RSecSSFs: Configuration value "rsec/ssfs_keypath" from profile explicitly overwritten by different value in environment variable RSEC_SSFS_KEYPATH [rsecssfs.c 4686]
RSecSSFs: Reverting overwriting of profile by different environment (disabled in dw) [rsecssfs.c 4696]
I checked the SSFS configuration, more precisely the instance parameters:
rsec/ssfs_keypath = $(DIR_GLOBAL)$(DIR_SEP)security$(DIR_SEP)rsecssfs$(DIR_SEP)key = /usr/sap/SID/SYS/global/security/rsecssfs/key
rsec/ssfs_datapath = $(DIR_GLOBAL)$(DIR_SEP)security$(DIR_SEP)rsecssfs$(DIR_SEP)data = /usr/sap/SID/SYS/global/security/rsecssfs/key
And also the environment variables on the central instance:
Even if the two paths /usr/sap/SID/SYS/global/security/rsecssfs and /sapmnt/SID/global/security/rsecssfs point in the same location, it looks like the systems sees them differently that is why in also the environment variables on the application servers need to be changes to the same name path name /usr/sap/SID/SYS/global/security/rsecssfs/key and /usr/sap/SID/SYS/global/security/rsecssfs/data.
