Problem:
Your SAP system is on Linux. Oracle database runs in a dedicated host where no SAP instance is installed.
Scheduling DB Jobs from DB13 does not work in a distributed system. Instead of going for additional gateway on DB instance, the following procedure can be followed .
Solution:
- Set the variable 'SAPDBHOST' with the database host name. In case of RAC database use the virtual hostname of the first node (see SAP Note 1738351 in case of Solution Manager). For database installed in OS cluster, use the virtual hostname of the cluster;
- Set the profile variable 'gw/netstat_once' to 0. This is to identify dynamic changes of the logical hostnames;
- Set the profile variable 'gw/remsh' with the full path of the 'rsh' in case you want to use normal remote shell or full path of 'ssh' in case of secure remote shell;
- Perform a connection test from the SAP instance host to database host. You should use 'rsh' or 'ssh' depending on what was configured in step 3. This can be tested using the following command. It should not return errors neither asks for password. It is also important to reinforce that the same hostname set in step one should be used here: rsh <database host> -l <sid>adm sapxpg
- You can refer to KBA 2312909 to see how to setup the passwordless SSH connection.
- DB13 will automatically create an RFC destination called SAPXPG_DBDEST_<SAPDBHOST>. Make sure there are no gateway options set for that destination. What makes DB13 choose the gateway instead of remote connection is the setting of the gateway option in this destination. If no settings for that, remote shell will be used;
To Setup SSH:
- Log to your SAP application server OS(in which you will run DB13) with user <SID>ADM. Run command “ping <DB hostname>”. DB should be able to get reached.
- SSH service should be running on OS level, check ps –ef |grep sshd
- Now you can perform an SSH connection test with <SID>ADM user from the SAP application server to database server by command “ssh <database host> -l <SID>adm”. It will ask for the password of user <SID>ADM. (the <SID>adm user should exist in database host.)
- Run command “ssh-keygen –t rsa” on SAP application server where DB13 jobs to be scheduled from. This is to create RSA key. Normally this program generates one key and asks for a file to store the private key. The public key is stored in a file with the same name but ''.pub'' appended. The program also asks for a passphrase. This passphrase is other than the actual password of user <SID>adm. (It is a password for the private key to increase the security. If you set the passphrase, you will be asked for it when you use the private key.) Here for DB13 use, you do not need to set it.
It then created a folder named “.ssh” from <SID>ADM home, and generated a file “id_rsa” with the private key and file “id_rsa.pub” to save the public key under “.ssh” folder.
Run command “ssh-copy-id <SID>adm@<hostname>” to copy the public key into the database server's authorized_keys file.
Here is the example, vml2493 is my database host. Localhost is my SAP application host. A file named authorized_keys under directory /home/<SID>adm/.ssh in database host will be generated.
Now you can test the connection via command "ssh <database host> -l <SID>adm". You will be connected to database host directly without entering password. Then you can run some standard linux commands for test, like ";s" or "uname -a". It will return you command result from standalone database host successfully.
Here is an example:
Lastly make sure sapxpg is with permission -rwxr-xr-x for <SID>adm user and SAPSYS group. Connection test in KBA 1974030 "ssh <database host> -l <SID>adm sapxpg" should now work perfectly.
Note SSH is not an SAP delivery. The guide here is only an example. Make sure to review configuration of SSH with OS admin or OS vendor for security matter.
Warning:
The generated private ssh key is accessible from within SAP. If you are concern about the potential security hole, you can use the alternative way: install a standalone gateway in oracle database server.
To avoid "Host key verification failed" error, make sure the full qualified domain name (FQDN) of remote database host is maintained in the ssh configuration file (/home/<sid>adm/.ssh/known_hosts) of the application server. (KBA 2919219)
Note: If the SAP RFC SAPXPG_DBDEST_<dbhost> still fails, modify the connection as below.