|
The unit of storage within a database is known as a page, and all database input and output operations are always carried out a page at a time. UltraLite allocates a page to hold either:
Table rows (user or system tables)
Index information
MobiLink server synchronization information
If you are encrypting your database, UltraLite encrypts the data at the page level.
UltraLite databases are stored in pages, and all I/O operations are carried out a page at a time. For most applications, the UltraLite default page size of 4 KB is appropriate.
However, you can choose another size if your database deployment requires it. Just remember that the page size you choose can affect the performance or size of the database. The typical rule of thumb is that larger databases usually benefit from a larger page size, because smaller pages hold less information and may force less efficient use of space—particularly if you insert rows that are slightly more than half a page in size:
Number of rows Because a row (excluding BLOBs) must fit on a page, the page size determines how large the largest packed row can be, and how many you can store on each page. See Row packing and table definitions .
In general, smaller page sizes are likely to benefit operations that retrieve a relatively small number of rows from random locations. By contrast, larger pages tend to benefit queries that perform sequential table scans. In this situation, reading one page into memory to obtain the values of one row may have the side effect of loading the contents of the next few rows into memory.
Cache size Large page sizes require larger cache sizes, because fewer large pages can fit into the same space. Should you choose a larger page size, such as 8 KB, you may want to increase the size of the cache when you connect to the database.
For example, 1 MB of memory can hold 1000 pages that are each 1 KB in size, but only 250 pages that are 4 KB in size. How many pages is enough depends entirely on your database and the nature of the queries your application performs. You can conduct performance tests with various cache sizes. If your cache cannot hold enough pages, performance suffers as UltraLite begins swapping frequently-used pages to disk. See UltraLite CACHE_SIZE connection parameter.
Index entries Page size also affects indexes. The larger the database page, the more index entries it can hold. See Working with UltraLite indexes.
However, there are instances when a smaller page size is in order. For example, small page sizes allow UltraLite to run with fewer resources because it can store more pages in a cache of the same size. Small pages are particularly useful if your database must run on small devices with limited memory. They can also help in situations when you use your database primarily to retrieve small pieces of information from random locations.
You can check the validity of the pages stored to disk, flash, or memory by setting the checksum_level database property. Depending on the level you choose, UltraLite calculates then records a checksum for each database page, before it writes the page to storage. See UltraLite checksum_level property.
If the calculated checksum does not match the stored checksum for a page read from storage, the page has been modified or became corrupted during the storage/retrieval of the page. If a checksum verification fails, UltraLite stops the database and reports fatal error. This error cannot be corrected; you must re-create your UltraLite database and report the database failure to iAnywhere.