IDV Database : How does it work?
The Indexes are structures to speed up search operations; they are maintained by the database engine. Views are virtual tables created from other tables, and their content is maintained by the database engine. It also handles the catalog, transaction control, checks the consistency of information and ensures that users access only to authorized information:
The operations performed by the engine are often recorded in a log file, which allow to cancel them in case of incident - failure or cancellation of a transaction.
Indeed, it relies on a "periodic" memory allocation.
For instance:
The base file is 500KB, IDS needs to add data, engine detects it and requests for 200KB additional memory allocation. At that time, the database file grows up from 500KB to 700KB.
As long as 200KB are sufficient to accommodate the data, the engine does not allocate additional space.
After compression (database space optimization), if the total amount of data processed is not less than the allocated size (200KB in our example) then the file size does not change and remains at 700KB.
i.e.: 150KB compressed data => remains 50KB/200KB. Minimum size necessary for database is 550Ko. We keep an allocation of 200KB and the database file remains to 700KB.
This operation does not interfere in any case access neither to the access to the data (visible on IDS Explorer) nor their update.
- Database engine and Memory Allocation Principe
The Indexes are structures to speed up search operations; they are maintained by the database engine. Views are virtual tables created from other tables, and their content is maintained by the database engine. It also handles the catalog, transaction control, checks the consistency of information and ensures that users access only to authorized information:
- Transaction Control: during a transaction, several changes to the database correspond to a single operation. The engine ensures consistency of the content of the database, including the failure or breakdown. The engine checks that concurrent modifications to the same information does not lead to inconsistent results.
- Security: the engine verifies that no users are accessing to unauthorized information, and that no user makes changes inconsistent with the consistency rules.
- File access: the engine manipulates the space for storage. The information is grouped by type, and each file stores a collection of similar information. The program which access to the file, structures the various files in accordance with the organizational scheme of the database.
The operations performed by the engine are often recorded in a log file, which allow to cancel them in case of incident - failure or cancellation of a transaction.
- Case of IDV database
Indeed, it relies on a "periodic" memory allocation.
For instance:
The base file is 500KB, IDS needs to add data, engine detects it and requests for 200KB additional memory allocation. At that time, the database file grows up from 500KB to 700KB.
As long as 200KB are sufficient to accommodate the data, the engine does not allocate additional space.
After compression (database space optimization), if the total amount of data processed is not less than the allocated size (200KB in our example) then the file size does not change and remains at 700KB.
i.e.: 150KB compressed data => remains 50KB/200KB. Minimum size necessary for database is 550Ko. We keep an allocation of 200KB and the database file remains to 700KB.
This operation does not interfere in any case access neither to the access to the data (visible on IDS Explorer) nor their update.