InterBase 5.0 - Engine Changes
SuperServer Architecture
Support of Classic Architecture
Changes for 64 bit pointers and record struct additions.
ODS Change
The ODS for InterBase version 5.0 has been updated to support cascading referential integrity. Databases in ODS 8.0 will be dynamically upgraded to ODS 8.1 when the database is first connected using InterBase version 5.0.
New databases created by v5.0 will be in ODS 9.0. ODS 9.0 supports index garbage collection and SQL ROLES.
In ODS 9.0 relation numbers 0 .. 127 are reserved for system relations. (Previously, in ODS 8.x, the first user relation number was 31).
On Windows NT, Win95, Windows 3.1 and Novell - ODS 8.x calculates checksums for each disk page. (Other platforms do NOT calculate checksums for ODS 8.x). In ODS 9.0 no checksums are calculated for any platform.
ODS Version vs InterBase Version
IB 4.0, 4.1 and 4.2 create ODS 8.0 IB 5.0 will upgrade an ODS 8.0 to ODS 8.1 which includes changes for cascading referential integrity. IB 5.0 creates ODS 9.0 which supports garbage collection for indices with valid back pointers. ODS 8.X databases are not transparently upgraded to ODS 9.0 - a database must be backed up and restored to use the new ODS 9.0 features. V5.0 supports both ODS 8.x and ODS 9.0. There is no bridge used.
SPX Client Support for Windows NT & 95
SPX client support for NT & 95 is not part of the NevaStone specification. SPX support will be implemented on a post 5.0 kit as and when a Netware 4.x implementation of Interbase becomes available. The Implementation will be as follows:
- The Client software will be implemented over WinSock 1.1
- The WinSock 1.1 SAP addressing feature does not work and so SAP addresses will be resolved by a home grown implementation of parsing raw SAP packets off the wire.
- InterBase on Netware 3.1 sequences packet fragments over and above the SPX sequencing. In other words, it appends a sequence as a header on each fragment and expects the client to parse of the appended header and reconstruct the packet. This method works fine as long as a Novell Client SDK is used on Windows. The Novell Client SDK makes the low level fragments visible. This is how the 16 bit InterBase clients for Windows 3.1 are implemented.
- The new version of InterBase (IB 4.2 on Netware 4.x) needs to continue to provide this mode of data exchange so as to provide backward compatibility to existing 16 bit Interbase clients. Additionally, the server needs to? Discard the use of additional sequencing? when talking to SPX clients for NT & 95. This is absolutely required as a WinSock client has no access to low level fragment headers at all.
Remote Protocol Performance
Numerous performance enhancements have been made to the InterBase remote protocol. The basic protocol is still version 8, but client and server-side performance has been increased:
- Bugs in the calculation of buffering while doing ESQL & DSQL cursor fetches have been fixed.
- The Client side now does look-ahead caching of data rows (meaning that the client will batch fetch data rows from the server before the client-side cache is exhausted).
As a result of the client-side data caching, there may be a minor increase in client memory utilization should multiple cursors be active in the application. Memory Allocation
Memory Allocation
SuperServer will now allocate memory in such a way that it can be released back to OS instead of the engine's internal heap manager. The initial pass is to target database buffers and sort buffers to use this mechanism; they are obvious candidates: A sort buffer is 128Kb and database buffer pools can be multiple megabytes or potentially gigabytes. The current implementation also includes memory allocations greater than 256KB. Thus all allocation requests greater than 256K in the engine will be allocated, and subsequently released back to the OS.
Lock Management
New parameters in isc_config
V4_SOLARIS_STALL_VALUE - Classic Solaris platforms only.
Solaris is known to be "unfair" to the processes (threads) waiting on mutexes - with a mutex that is in high contention (such as InterBase lock table mutex) it is possible for some processes to never manage to acquire the mutex. To fight this problem we implemented a " fairness" algorithm . In this algorithm a process (thread) entering the lock table tries to determine if other processes have been "starved" out of the lock table. If so, the thread voluntarily releases the lock table and goes to sleep. When the "starved" process (thread) finally acquires the lock table it does its work and on exit awakens all the processes that went to sleep due to its starvation. This parameter specifies how long a process (thread) should sleep to let the "starved" process run.
Default: 60 seconds. Minimum: 0. Maximum: 200. To disable the algorithm the parameter should be set to 0.
LOCK_HASH_SLOT
This parameter specifies a number of hash slots in the lock table. The higher the parameter the shorter the hash chains. Shorter hash chains result in faster lock operation and decrease the likelihood that a process will context switch while owning the lock table mutex. On the other hand more hash slots require more space in the lock table (101 hash slot cost 800 bytes, a setting of 501 would cost an additional 3200 bytes, but reduce lock hash chains by a factor of 5 approximately).
Default: 101. Minimum: 101. Maximum: 2048.
Changes to existing parameters
V4_LOCK_MEM_SIZE
The parameter specifies the size of the lock table. Default is 96K. In the Superserver on all platforms and Classic architecture without MMAP_SUPPORTED the lock table size is not changed (increased) automatically. User needs to increase the above parameter in isc_config file. Also, in the SuperServer without MMAP_SUPPORTED a memory segment for the lock table is allocated exactly of a size specified by the parameter even if a memory segment of another size with the same key already exists in a system. The same could be said about V4_EVENT_MEM_SIZE.
Grant/Revoke UNIX group privileges through SQL
Support UNIX group on GRANT/REVOKE statements unix_role. This is a new feature. In the past, UNIX group privileges could only be granted/revoked through IB proprietary language called GDML. With this new feature, now user could grant/revoke UNIX group privileges through SQL GRANT/REVOKE statements.