- Parameters affecting file system cache usage
RemoteAuxPortfor Classic and Superclassic
- Use host name for
The following changes or additions to
firebird.conf should be noted:
This parameter points to the name and location of the file that the Firebird engine is to read to determine the list of events required for the next system audit trace. By default, the value of this parameter is empty, indicating that no system audit tracing is configured.
Note: The template file
fbtrace.conf, found in Firebird's root directory, contains the full list of available events, with format, rules and syntax for composing an audit trace configuration file.
There are now two parameters for configuring how Firebird interacts with the file system cache.
New in Firebird 2.5,
FileSystemCacheSize controls the maximum amount of RAM used by a Windows file system cache on 64-bit Windows XP or a Microsoft Server 2003 host with Service Pack 1 or higher.
At the v.2.5 initial release, it has no effect on POSIX host systems.
The setting for this parameter is an integer expressing the percentage of the total physical RAM that is available to the OS. To be valid, settings must be within the range 10 (per cent) to 95 (per cent), or explicitly set to 0 to enforce the host caching settings. Numbers outside that range will assume the default, which is 30 (per cent).
As with any
firebird.conf setting, changes will not take effect until the server process is restarted.
Windows security privileges
The OS user needs the
SeIncreaseQuotaPrivilege in order to adjust the file system cache settings.
This right is built in for users with Administrator privileges and for service accounts and it is also granted to the Firebird service account explicitly by the Windows installer.
Under other conditions, e.g., embedded, or where the Firebird server is run as an application, or in a custom service installation, the user may not have that privilege. The process startup does not fail as a result of this misconfiguration: it will write a warning to the
firebird.log and startup will simply proceed with the host OS settings.
This parameter was introduced in v.2.1 as
MaxFileSystemCache. Because its name has been changed, its description is repeated here to alert upgraders.
FileSystemCacheThreshold sets a threshold determining whether Firebird will allow the page cache to be duplicated to the file system cache or not. If this parameter is set to any (integer) value greater than zero, its effect depends on the current default size of the page cache: if the default page cache (in pages) is less than the value of
MaxFileSystemCache (in pages) then file system caching is enabled, otherwise it is disabled.
Note: This applies both when the page cache buffer size is set implicitly by the
DefaultDBCachePages setting or explicitly as a database header attribute. It applies to all platforms.
- To disable file system caching always, set
- To enable file system caching always, set
FileSystemCacheThresholdan integer value that is sufficiently large to exceed the size of the database page cache. Remember that the effect of this value will be affected by subsequent changes to the page cache size.
- The default setting for
FileSystemCacheThresholdis 65536 pages, i.e. file system caching is enabled.
- Observe that, if the configured cache size affecting a particular database is greater than the
FileSystemCacheThresholdthen the setting for
FileSystemCacheSize(see above) will have no effect on that database.
MaxFileSystemCache, introduced in Firebird 2.1, is no longer a valid parameter.
On heavily loaded Windows systems, local connect (XNET) could fail due to the client timing out while waiting for the server to set the xnet_response_event. To help with this problem, the
ConnectionTimeout parameter has been enhanced to affect XNET connections, in addition to TCP/IP.
Note: The caveat documented for this parameter, although still applicable to network transports, does not apply to XNET's protocol.
On Windows server platforms, since v.2.1, authentication has been used for configuring the server authentication mode if you need it to be other than the default.
The mode settings for v.2.5 are the same, viz.
- trusted makes use of Windows trusted authentication. Under the right conditions, this may be the most secure way to authenticate on Windows.
- native sets the traditional Firebird server authentication mode, requiring users to log in using a user name and password defined in the security database.
- mixed allows both.
- Under v.2.5, although the modes are unchanged, configuring 'mixed' or 'trusted' mode no longer confers SYSDBA privileges on Windows domain administrators automatically by default. Please read the notes in the Administrative Features chapter regarding the new
RDB$ADMINrole in ODS 11.2 databases and automapping SYSDBA privileges to domain administrators.
- The default configuration has been changed from mixed to native. To enable trusted user authentication (whether mixed or trusted, it is now necessary to configure this parameter specifically.
Tracker reference CORE-2376
Stores the maximum total size of the temporary files to be created by a user trace session using the new Trace functions in the Services API. The default limit is 10 MB. Use this parameter to raise or lower the maximum total size of the temporary files storing the output.
Before Firebird 2.5, the
SET clause of the
UPDATE statement assigned columns in the user-defined order, with the
NEW column values being immediately accessible to the subsequent assignments. This did not conform to the SQL standard, which requires the starting value of the column to persist during execution of the statement.
Now, only the
OLD column values are accessible to any assignment in the
OldSetClauseSemantics enables you to revert to the legacy behavior via the
OldSetClauseSemantics, if required. Values are
1 for the legacy behaviour,
0 (the default) for the corrected behaviour.
- Changing this parameter affects all databases on your server.
- This parameter is provided as a temporary solution to resolve backward compatibility issues. It will be deprecated in future Firebird versions.
Tracker entry: CORE-2263
This long-awaited improvement now enables applications that connect to databases over the internet through a firewall or a secure tunnel to use events, regardless of the server model in use.
Tracker entry: CORE-2094
It is now possible to use the host name of the host where the Firebird server is running to configure
RemoteBindAddress, where previously, only an IP address was allowed.
RemoteBindAddress can be used to "pin" user connections to a specific NIC card on the host server. Take care that the host name specified is not associated concurrently with more than one IP address, anywhere! In particular, check the
etc/hosts file on all stations, including the host station itself.
Tracker entry: CORE-2263
Code from Red Soft was incorporated, to make this extreme option available to Windows and allow a database to be opened on a network share, in line with the long-time ability to allow access to a database on a NFS device on POSIX.
It is offered in the interests of maintaining feature consistency across platforms. There is no associated architectural change or any implication that its use in practice is considered safer now than in the past. However, it makes it possible to shadow databases to mapped locations and to connect to a database on an external file system for a specific, well-tested, safe purpose. An example given was a database kept under lock-and-key on a USB device that could be plugged in to a diskless workstation for performing an occasional, isolated security task.
Warning: READ THE NOTES IN FIREBIRD.CONF BEFORE YOU CONSIDER ACTIVATING THIS!