Transactions in the RLV store are fully durable. Committed transactions are guaranteed to be recovered in the event of a system crash.
Data in the RLV store is not persisted to disk, but remains in-memory until it is merged into the IQ main store.
The performance of the I/O system supporting the RLV dbspace is a major factor in the ingestion and commit performance of the RLV store. Sustained write throughput is important for high volume data ingestion.Write latency is important for commit performance. Random write performance is important when simultaneously ingesting data into multiple RLV enabled tables.
A commit request from an application is not acknowledged until the entire transaction, including the commit state, has been persisted to stable storage.
Each RLV enabled table has its own logical persistence log. The space for these logs comes exclusively from the RLV dbspace. Log space is consumed during transactions and is freed by merge. At the end of a merge, the log for a table is truncated back to the oldest open transaction at the beginning of the merge. A long-running open transaction that spans multiple merges has the potential to prevent log space from being truncated. You can monitor the amount of RLV log space used for a table with the sp_iqtablesize stored procedure.
Because it is not possible for uncommitted data to be in the database at the start of recovery, recovery is a logical, transaction-oriented process rather than a physical, page-oriented process. RLV recovery is concerned with inserting committed data instead of physically modifying pages.