...
In the running phase, the memory DB resides in the memory for all data stored on the disk. The space for loading data in the memory is managed in units of pages, and the size of one page is fixed at 32K. Each page is divided into n slots according to the record size of the table to which the page belongs, and data is stored in each slot. When data is changed/saved/deleted in the process of a transaction, the page where the data is stored is registered in the list of dirty pages managed internally. The process of storing the pages managed in this dirty page list in a physical file is called a checkpoint.
Since memory is volatile, data cannot have persistency in a situation such as power outages unless a process such as a checkpoint is performed. For more detailed information on the checkpoint, please refer to the checkpoint documentation. A thing to consider in this document is that the memory DB is also saved as a data file on the disk with a periodic checkpoint.
If the data files in the memory DB and the space in which the redo logs are stored were set to be in the same physical disk space, it is recommended to configure each disk separate separately because of the transactions that occur during the checkpoint causes disk bottleneck in the checkpoint stage.
...
If recovery is required, use a method of restoring the original data store din stored in the undo tablespace by copying it back to its original location. In this process, the undo tablespace is replicated whenever a disk DB change transaction occurs. Therefore, it is recommended to configure it as a disk DB and a separate disk space in order to avoid a physical bottleneck.
...