Below is a description for all server statistics. <br><br>

<h3> Uptime</h3>
How long the server engine has been active.

<h3>Sessions</h3>
How many TnxServerSession objects exist inside the server engine, there is usually a 1:1 relationship of these with TnxSession objects inside connected clients.

<h3>Databases</h3>
Same for TnxServerDatabase / TnxDatabase

<h3>Transaction Contexts</h3>

Same for TnxServerTransContext / TnxTransContext. If no explicit transaction contexts are used each database has one internally.

<h3>Cursors</h3>
How many TnxServer*Cursor objects exist inside the server engine. TnxTable and TnxQuery are wrappers around cursors. Any active TnxTable or TnxQuery will use at least 1 cursor. If you make use of Locate there might be a 2nd cursor. The SQL engine will use cursors internally to execute statements. Result sets are in-memory tables for which cursors are also needed to access.

<h3>Statements</h3>
Count of TnxServerStatement objects. A statement object is a prepared (but not necessarily open) TnxQuery.

<h3>Folders</h3>
Count of TnxServerFolder objects. They represent physical folders. TnxServerDatabase objects connect to them. 

<h3>Tables</h3>
Count of TnxServer*Table objects. They represent physical tables in a specific folder. Cursors connect to them.

<h3>Block Cache Available</h3>
How much memory the server is allowed to use for the block cache to keep blocks in memory. The block cache is used for both dirty blocks (changed in a not yet committed transaction) as well as read-only blocks that are simple a copy of the block as it exists on disk right now (to reduce I/O cost for repeated access). 

<h3>Block Cache Used</h3>
How much of the block cache is currently filled with blocks.

<h3>Block Cache Miss</h3>
How often a requested block could not be found in the cache and had to be loaded from disk.

<h3>Block Cache Hit</h3>
How often a requested block could be found in the cache and disk I/O was prevented.

<h3>Block Cache Eviction</h3>
How often a block has been evicted from the cache. Blocks are evicted if the Block Cache was full at a time that the server needed additional space to store blocks. Either to store a dirty block (copy of a read-only block) as it is modified in the context of a transaction or because a block has been requested which is not yet present in memory and has to be read in from disk.

The block in the block cache that hasn't been accessed for the longest time is evicted first. Evicted read-only blocks are simply discarded (can be read in again from disk later if required). Evicted dirty blocks are written into temporary storage.

Even if the block cache is only 50% in use, the fact that evictions take place indicates that at some point in time the block cache was completely filled.

If there are any issues with server performance, making more memory available to the block cache could help if there are block evictions recorded. The AWE edition of NexusDB is able to use all physical memory that the OS can access, without being limited by the address space available for 32bit processes. In addition it supports something called "bulk block loading" which allows the server to fill the block cache much quicker after the server was started which can speed up certain operations by orders of magnitudes compared to reading each block individually when first needed.

<h3>Transactions Commited</h3>
Number of committed transactions. Both explicit and implicit ones. If you perform a Post through a TnxTable (or execute some DML statement through SQL) without having an explicit transaction active, the server will start and commit and implicit transaction inside the Post call. No modification to a table can ever take place in NexusDB without a transaction.

<h3>Transactions Commited Nested</h3>
Number of committed nested transaction. A nested transaction is started when StartTransaction is called while a transaction is already active. "Committing" such a nested transaction just assigns the dirty blocks in the block cache that belong to this transaction to the next outer transaction. No disk writes take place.

Under certain conditions (which obviously didn't apply to you given the count is 0) calling Post on a Table or executing certain SQL statements will internally start and commit a nested transaction even if an explicit outer transaction was already active. 


<h3>Transactions Rolledback</h3>
Number of rolled back transactions. This can have been for either explicit or implicit transactions.

<h3>Transactions Rolledback Nested</h3>
Same for nested transactions.

<h3>Transactions Deadlocked</h3>
Transaction deadlocks occur if 2 clients started a transaction, both clients acquired a shared lock on a table (required for read access in the context of the transaction) and then both clients try to upgrade that shared lock to an exclusive lock (required for write access to the table). In that case neither client can be upgraded to an exclusive lock as the shared lock from the other client is preventing this. The server detects such a case, force fully rolls back one of the 2 clients internally and returns a deadlock exception to that client. (The client still needs to explicitly call Rollback.) Any further operation from that client will just keep getting deadlock exceptions until the explicit rollback has taken place.

<h3>Transactions Corrupted</h3>
Transactions can be marked as corrupted, either explicitly by a call TransactionCorrupted from the client or internally if an error happens during an operation which normally uses its own implicit transaction to roll back in case of an error, but which was executed in the context of an explicit transaction (e.g. CopyRecords). The behaviour is the same as for deadlocked transactions: all further operations result in an error till an explicit rollback has been performed.

<h3>Blocks Read</h3>
How many blocks have been read in from disk.

<h3>Blocks Written</h3>
How many blocks have been written to disk.

<h3>Temporary Storage in use</h3>
How much temporary storage is currently in use (to hold dirty, evicted blocks).
