Typical causes of server problems and how to avoid them

<< Database repair | Firebird administration using IBExpert | Working with shadows >>

tutorial available

Typical causes of server problems
Detect and avoid server problems

Typical causes of server problems

Network problems

If you encounter network problems try to ping the server. Check the firebird.log, as this can indicate where the source lies.

Approximately half the problems with failure to reach the server are due to a Firewall. If you're using the default port 3050 make sure this is listed in your Firewall settings. Although Firebird normally only requires one port, this is not the case if you use the Event Alerter. The Event Alerter is a mechanism with which you can trigger a message, when a certain event occurs, to be sent to a client. These Event Alerters are a powerful feature. As soon as you register any events with the Firebird server it will open a separate port. You can specify which port in the firebird.conf file. Otherwise it selects a random port.

Hardware problems

One of the issues on Firebird server hardware is running out of disk space, often due to temp files. Many DBAs don't set their temp directory in firebird.conf, and often forget to check the temp directory when they notice they're running out of space. When the hard drive begins to become full, Windows stores data pages anywhere it can find space. Which of course degrades performance when searching for and uploading the data on these pages. Please refer to Temporary files below for further information.

Hardware defects can happen at any time and can have disastrous effects, if you can't react quickly. The best defense against such a problem is to run a database shadow on another server or external hard drive. Please refer to Working with shadows for further information.

OS problems

When performance starts to degrade it's important not just to look at queries and programming, but also at the operating system itself.

Windows system restore: On Windows My Computer / System Properties the automatic System restore can be disabled. This also prevents Windows copying all manner of files into the Win/System32/dllcache directory (it not been unknown to discover files of 5GB and more in this directory!).
Automatic Windows update: the infamous automatic Windows update with its automatic rebooting is the cause of many Firebird server machines suddenly being shut down, because noone was sitting in front of the screen to stop it. This must be disabled! And it's not just Windows. There are many other services running that may deny you server access.

So prevent any updates running and rebooting your system automatically, even antivirus applications. Close everything up, leaving only those really vital ports free. Backups can be configured via ftp onto a backup server.

As far as possible, use a dedicated server for your Firebird applications.

Detect and avoid server problems

Check the Firebird logs from time to time. This provides an opportunity to notice things that users don't realize are going wrong. Check the Windows Event log as well. When the daily log starts to increase in size, look for the causes, e.g. that the server is often restarted. The cause of frequent Firebird server reboots is often due to UDFs. Writing robust UDFs is vital. Poorly written UDFs can lead to technical suicide, if you are not familiar with memory management. If 2 processes are using the same UDF simultaneously, it can well lead to server instability. Before you go ahead and write your own UDFs for everything, consider taking an existing one from a library such as FreeAdhocUDF, and complement it if necessary.

Recommendation:

Use only robust UDF libraries, such as RFunc.
Check every UDF you've written yourself not just once, but 10 times!

If you're using two different Firebird/InterBase^Ž flavors concurrently, check that the correct fbclient.dll/gds32.dll version is installed on the server and all clients. You'd be amazed how often DBAs are surprised by this or that previously undiscovered dll suddenly turning up, because somewhere there is an old InterBase^Ž version installed (and maybe even still running). When you start your Firebird 2 database, it tries to work with the old dll. Ensure that at least the correct client library is available in your application directory for the application's database version.

Remove any old redundant InterBase^Ž versions.

Use the IBExpert Communication Diagnostics to test connect to your server. Analyze any error messages returned. Alternatively attempt a connection at TCPIP level and ping the server. When the server can't be reached this way, it is obviously not a Firebird problem. Please refer to the IBExpert Services menu item, Communication Diagnostics for further information.