27.10.2013 Views

Firebird 2.1 Release Notes

Firebird 2.1 Release Notes

Firebird 2.1 Release Notes

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Global Improvements in <strong>Firebird</strong> <strong>2.1</strong><br />

Configuration and Tuning<br />

Increased Lock Manager Limits & Defaults<br />

D. Yemanov<br />

Feature requests CORE-958 and CORE-937<br />

• the maximum number of hash slots is raised from 2048 to 65,536. Because the actual setting should be<br />

a prime number, the exact supported maximum is 65,521 (the biggest prime number below 65,536). The<br />

minimum is 101.<br />

• the new default number of hash slots is 1009<br />

• the default lock table size has been increased to 1 Mb on all platforms<br />

Page sizes of 1K and 2K Deprecated<br />

D. Yemanov<br />

Feature request CORE-969<br />

Page sizes of 1K and 2K are deprecated as inefficient.<br />

Note<br />

The small page restriction applies to new databases only. Old ones can be attached to regardless of their page<br />

size.<br />

Enlarge Disk Allocation Chunks<br />

V. Khorsun<br />

Feature request CORE-1229<br />

Until v.<strong>2.1</strong>, <strong>Firebird</strong> had no special rules about allocating disk space for database file pages. Because of dependencies<br />

between pages that it maintains itself, to service its “careful write” strategy, it has just written to newly-allocated<br />

pages in indeterminate order.<br />

For databases using ODS 11.1 and higher, <strong>Firebird</strong> servers from v.<strong>2.1</strong> onward use a different algorithm for<br />

allocating disk space, to address two recognised problems associated with the existing approach:<br />

1. Corruptions resulting from out-of-space conditions on disk<br />

The indeterminate order of writes can give rise to a situation that, at a point where the page cache contains<br />

a large number of dirty pages and <strong>Firebird</strong> needs to request space for a new page in the process of writing<br />

them out, there is insufficient disk space to fulfil the request. Under such conditions it often happens that the<br />

administrator decides to shut down the database in order to make some more disk space available, causing<br />

the remaining dirty pages in the cache to be lost. This leads to serious corruptions.<br />

29

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!