Siebel Server Down Troubleshooting

9/22/2013 1 Comment

Siebel Server is not coming up in Linux/Unix and Windows.

Server Busy Error for Siebel Server. Steps for Troubleshooting. There could be several cases where Siebel servers are not coming up or Siebel services are not running properly. We are discussing in detail about those scenarios and the solutions.

1. The first step is to ensure that you validate the .srf file is not corrupt by placing the SRF on a dedicated environment. If the dedicated client is facing issues there could be possibly two reasons as cited below.
  • The SRF file in the server machine got corrupt. Replace your SRF with the backup.
  • The Oracle Database Server itself is down. Restart the same.
2. Any changes or modification which lead to the corruption of Siebel Gateway Name Server information file siebns.dat will also result in the Siebel Servers not coming up. In general, NameSrvr logs tell us the connectivity related information and common errors like license key not found. Since there are multiple copies of siebns.dat, you can try to revert to an old working siebns.dat file. The servers will come up.

3. Stop Siebel servers after you set Siebel environment variables using the script ./siebenv.sh and then use the command stop_server all 

Unix/Linux/Solaris: Execute ps -ef | grep [directory path] (eg. ps -ef | grep /app/siebel/siebsrvr).
ps -ef | grep sieb
Ensure that all processes for that enterprise are killed.
use kill -9 pid
4. Delete OSDF files that exists in directory %SIEBEL_ROOT%\sys with name like the ones below:
osdf.[SiebelEnterprise].[SiebelServer]
Where [SiebelEnterprise] = The Siebel Enterprise name
[SiebelServer] = The Siebel Server name.

You can also use the command as below to clean OSDF files
  • % cleansync -f $SIEBEL_ROOT/siebsrvr/sys/osdf.<enterprise_name>.<server_name> -d 
5. After OSDF files, please also ensure that you delete any shared memory files that exists in directory %SIEBEL_ROOT%\admin with name like:*.shm files This shared memory file is maintained by each Siebel Server under the "admin" directory of its root installation. Though this file is automatically deleted when the Siebel server is shut down, if it still exists when the Siebel server is down then there is the likely possibility that it has been corrupted and has to be removed. You can delete it manually or by the command using below. Please ensure that if you have more than one Siebel Server, you have to delete the files from each server.

  • % siebclean -f $SIEBEL_ROOT/siebsrvr/admin/<enterprise_name>.<server_name>.shm -q 
6. Another quick test is to check for the Siebel enterprise logs. If there are no enterprise logs are getting generated then there are connectivity issues with the Siebel database. One of the possible reason is the change of Database password for SADMIN user.

You just need to run odbcsql from siebsrvr/bin to check connectivity issues. The command is as cited below.
odbcsql /u SADMIN /p SADMIN /s DSN Name

7. Ensure that you do cleanup of unwanted logarchive and log files so that fresh logs can be monitored and space can be freed up accordingly. It is recommended to move the Log Archives to a different machine if they are required from the Business point of view

8. Please ensure that you delete FDR and core files as these files consume large amounts of memory in the machines leading to servers not getting started.

9. In a Unix environment you can try to restart server after executing Siebel environment variable script ./siebenv.sh and then use the command start_server all
However, if the server still does not restart, you need to check the enterprise logs for it for any possible errors. 
The enterprise log lies in the following location in the server machine.
%SIEBEL_ROOT%\enterprises\[SiebelEnterprise]\[SiebelServer]\log
The enterprise log has name with format:
[SiebelEnterprise].[SiebelServer].log

10. Check that there is no Siebel processes for the enterprise that are still running. For Windows: Check Task Manager for any Siebel process for the enterprise still in running state.

11.If the Siebel environment has LDAP authentication, any changes and modification in the LDAP tree structure can also affect the environment to go down. This usually happens when you make the changes and propagate it across. Please verify if this is the case.

12. Use the command netstat -an|grep 2321 and verify that the SRBroker/SCBroker port is listening. 
You may get error messages like "SBL-NET-01218: The connection was refused by server crm. No component is listening on port 2321."

13. Use the command netstat -an|grep 2320 and verify that the Gateway Service port is open and listening.

14. Increase the log level of the server components so that SCBroker and SRBroker can be monitored From the log you would get very vital information that can be used for debugging.

In many of the troubleshooting steps mentioned above, it requires generation of Enterprise Server logs for finding the possible cases of errors. Please monitor the logs so there there is no disk space issue. 

1 comment :

 

Aired | The content is copyrighted and may not be reproduced on other websites. | Copyright © 2009-2016 | All Rights Reserved 2016

Contact Us | About Us | Privacy Policy and Disclaimer