Systemwide Performance Checklist


If DBA Manufacturing is generally slow throughout the system rather than within one particular screen or process, begin by determining how widespread the problem is and whether the surrounding server or network environment may be contributing.


Compare local and affected users

One of the quickest ways to isolate a performance problem is to determine whether all users are affected.

  • If all users are slow, investigate the server, database storage, antivirus activity, backup activity, and local network.
  • If only one or a few users are slow, investigate those workstations and their network connections.
  • If only remote users are slow, investigate VPN, internet, wireless, or Remote Desktop configuration.
  • If only one DBA screen or process is slow while the remainder of the system performs normally, the issue may be specific to that process rather than a systemwide performance problem.


Start with the environment

Before investigating individual DBA screens or reports, first verify that the server, storage, network, antivirus software, and backup routines are operating normally.


Systemwide performance problems are often caused by conditions outside of DBA itself. Correcting an environmental bottleneck can improve performance throughout DBA Manufacturing.


Use the following checklist to review the most common areas.


1. Check available disk space

Make sure the drive containing DBA Manufacturing and the Firebird database has adequate free disk space.

Low disk space can affect Windows, Firebird, database backups, temporary files, and overall server performance.

As a general guideline, maintain at least 15–20% free disk space and allow additional space for:

  • Database growth

  • DBA Backup Manager backups

  • Database backup copies created during product updates

  • Backup and restore operations

  • Windows temporary files and maintenance

If the drive is becoming full, review old backup files according to your organization's backup retention policy.


2. Use solid-state storage

SSD storage is recommended for the drive containing the DBA database.


Firebird performs frequent disk reads and writes. A solid-state drive can provide significantly faster access than a traditional mechanical hard drive, particularly on database-intensive operations.


If the server is still using a mechanical hard drive, upgrading the database storage to SSD should be considered.


3. Review antivirus scanning

Real-time antivirus scanning can affect database performance when it continuously inspects files being accessed by Firebird.

Have your IT provider review the antivirus configuration and determine whether appropriate exclusions should be established for:

  • The live DBA database location

  • The DBA Manufacturing program folder

  • DBA database backup locations

  • Other Firebird files that are continuously accessed

Antivirus protection should not be permanently disabled. Any exclusions should be configured according to your organization's security requirements.


Also check whether scheduled antivirus scans correspond with periods of poor DBA performance.


4. Review server backup activity

Third-party server backup utilities can consume significant disk, processor, memory, and network resources while backups are running.


Avoid continuously backing up or scanning the live Firebird database file with a general-purpose backup utility.


Use the DBA Backup Manager to create database backups and then include those resulting backup files in your normal server or off-site backup routine.


Whenever possible, schedule resource-intensive server backups outside normal working hours.


5. Check the local network

DBA client workstations require a stable connection to the server.


Check for:

  • Network packet loss

  • Faulty network cables

  • Failing switches or network equipment

  • Network interface problems

  • Excessive network congestion

  • Security or firewall software inspecting internal database traffic

A network connection can appear functional for normal internet use while still being unstable enough to affect database performance.


6. Avoid wireless client connections

DBA client workstations should use a wired local area network connection.


Wireless connections can experience temporary interference, latency, or connection interruptions that are particularly disruptive to database applications.


If a workstation must connect wirelessly, use it as a Remote Desktop workstation rather than running the DBA client directly across the wireless connection.


7. Do not run DBA clients directly across a VPN

A direct DBA client connection across a VPN can result in poor performance because database communication must travel across the internet for each request.


Internet bandwidth alone does not determine database performance. Latency, packet loss, and connection stability are equally important.


For remote users, use Remote Desktop so that DBA runs on a computer or server located on the same local network as the Firebird database server.


8. Check server resource usage

Review Windows Task Manager or other server monitoring tools while DBA is experiencing poor performance.

Look for unusually high:

  • Disk activity

  • CPU usage

  • Memory usage

  • Network activity

Determine whether another program or server service is consuming resources at the same time.


Common examples include antivirus scans, backup software, Windows maintenance routines, and other applications running on the DBA server.


9. Make sure the server is appropriately sized

The DBA server should have sufficient processor, memory, and storage performance for the number of users and size of the database.


A server that performed well when DBA was initially installed may no longer provide the same performance after years of database growth or an increase in the number of users.


Older servers should be reviewed periodically to determine whether hardware upgrades are appropriate.


10. Perform regular database maintenance

Use the DBA Backup Manager to maintain reliable database backups and perform backup and restore operations when recommended.


A Firebird backup and restore recreates the database and can improve database efficiency while also verifying that a usable backup can be created.


Database maintenance becomes increasingly important as the database grows over time.


11. Review the Windows power plan


Windows Server commonly uses the Balanced power plan, which adjusts processor performance according to workload demand.


For a database server, your IT provider may want to evaluate the High Performance power plan, particularly if DBA performance is sensitive to processor response time.


High Performance mode keeps the processor operating more aggressively and can reduce delays associated with processor power-state changes. The actual performance improvement varies by server hardware and workload.

The Windows power plan can normally be changed without restarting the server.


Also be aware that some servers manage processor power through BIOS or manufacturer-specific settings. In those cases, changing the Windows power plan may have little or no effect.


12. Avoid combining the database server with a Domain Controller when possible

A server performing multiple infrastructure roles can have fewer resources available for DBA Manufacturing.


This is particularly relevant when the DBA database server is also functioning as an Active Directory Domain Controller. Active Directory has its own database and disk activity, and Microsoft uses conservative write behavior to protect the durability of Active Directory data. This additional workload can compete with Firebird for processor, memory, and storage resources.


Whenever practical, the DBA database server should not also be used for heavily utilized infrastructure services such as Active Directory.


If DBA is running on a Domain Controller and systemwide performance is poor, review server resource usage and disk performance with your IT provider.


13. Check virtual server resource limits

If the DBA server is a virtual machine, verify that sufficient processor, memory, disk, and network resources have been assigned to it.


Virtualization platforms can impose limits or quality-of-service settings that restrict the resources available to a virtual machine. For example, Hyper-V supports CPU caps and storage I/O limits that can restrict how much processor time or disk I/O a virtual server is allowed to consume.


Have your IT provider check for:

  • CPU limits or caps

  • Insufficient virtual processors

  • Insufficient assigned memory

  • Storage IOPS limits

  • Slow or heavily shared storage

  • Network bandwidth restrictions

  • Heavy resource contention with other virtual machines


Database servers are particularly dependent on consistent disk performance. The underlying virtualization host and storage system should provide sufficient I/O capacity for the DBA workload.


Do not assume that a virtual server has access to all of the physical server's resources simply because those resources exist on the host.