SQL Server clients, servers, and networks

You can run iBase on a system configured in a number of ways.

The system uses a combination of these elements:
  • SQL Server database server for managing access to the databases
  • iBase clients, or,
  • An application server that is running iBase with thin clients, if you are using Terminal Services/Citrix

The following figures summarize the possible configuration options for iBase.

iBase Standard configuration option 1

iBase Standard configuration option 2

Hardware specifications and supported operating systems

Hardware specifications and the supported operating systems for a particular release of iBase are defined in its system requirements.

Client machines

The client should be sized to suit all the applications that it is intended to run alongside iBase. Mapping products in particular can place heavy demands on the host’s processor and memory resources. The type of iBase usage that is expected on the client machine should also be taken into account: manual data entry places much lower stress on the client than analytical use or large data imports.

Server machines

iBase data is stored in database files that are managed by SQL Server. When your administrator first installs Microsoft™ SQL Server, they are prompted for the location of the program files and the data files. The default is that both sets of files are placed on the boot drive of the server. It is important to ensure that the data files are stored on the dedicated data partition. Typically this is a dedicated set of disks in a RAID 5 configuration. SQL Server stores the database files created by iBase in the default location for the database files.

We suggest that your SQL Server administrator use a RAID 1 configuration for the system disks and transaction logs, and RAID 5 for the data. The major activity in an iBase Standard installation is reading data and RAID 5 offers a performance advantage in reading. RAID 5 requires a minimum of three disks. The more disks used, the better the performance.

If the read auditing of activity is turned on, it is advantageous to place files for the iBase Audit Log database, both main data file and transaction log file, on a disk array with good write performance such as RAID 1. For maximum performance this should be on a separate disk controller.

Network requirements

Analysts use large amounts of data that must be transferred from the server to the client across the network. For example when starting up, finding, charting, and so on. A measure of the suitability of the network is latency: that is how long a packet of data takes to get from the server to the client and vice versa. Most local area networks should have low latency. Poor network performance leads to poor iBase performance when you browse, query, chart, map, and export to Data Miner.
Note: Deployment of iBase clients over a wide area network (WAN) is not supported. The architecture of iBase Standard requires relatively large volumes of network traffic. However, because the data flows in relatively small packets, the effect of latency, which is usually higher on WANs is more pronounced. The effect is that not only would client performance be slow and inconsistent but iBase would also disrupt other services that run over the WAN. As an alternative, i2 offers support for iBase WAN deployment using terminal services emulation.