TimesTen磁盘空间管理

Posted 2021-05-19 dingdingfish

TimesTen数据库的的磁盘空间占用主要由两部分组成：

1. checkpoing文件
2. 数据库log 文件

checkpoint文件因为有两个，因此至少需要2 * Permsize空间，建议预留3-4倍Permsize空间。

数据库log文件类似于Oracle的redo log，在checkpoint(默认600秒)时会自动清理，也可以用ttckpt命令手工清理。是否能被清理取决于是否有缓存组，日志，XLA等。

写这篇文章的初衷，是由于客户运维关心日志文件清理，这样看来只需要留够足够的空间就好了。

比较经典的解答看这里，我粘贴了原文，概念讲得很好：

Although TimesTen is an in-memory database it does provide full persistence and recoverability using local disk storage (it also supports replication for high availability but that is a different topic). The persistence mechanism uses a combination of checkpoint files (dbname.ds[01]), and transaction log files (dbname.logNNN) to provide persistence, recoverability etc.
The checkpoint files contain an ‘image’ of the in-mmory database and these on disk images are referred periodically by automatic checkpoint operations. When a checkpoint occurs it always updates the oldest checkpoint image (which flip flops from one checkpoint to the next); the checkpoint flushes all changed data from the in-memory database to the checkpoint disk image performing an in-place update on the disk file. After the checkpoint has completed the file on disk is an up to date image of the in-memory database. Since checkpoints do not block queries or DML, the checkpoint images on disk are in fact ‘fuzzy’ (not transactionally consistent).
In addition to checkpointing, any change to persistent data that occurs in the database (for example as a result of DML operations) generates log records that describe the changes. These log records can be used for undo (rollback) and for redo (recovery). They are also used by various TimesTen features such as replication, AWT caching and XLA. These log records are staged in an in memory buffer (the log buffer) before being written to the current log file on disk. Each log file has a fixed maximum size (the LogFileSize parameter) and when it reaches that size it is closed an a new log file is created. The log files have a sequence number as part of their name (dbname.logNNN).
So over time the size and number of log files continually increases, which would be a problem if there was no mechanism to clean them up. Luckily there is - checkpointing. When a log file is no longer required - the changes represented by the records in the file have been checkpoints into both checkpoint files and are no longer required by replication, cache, XLA etc. - then the file will be deleted when the next checkpoint operation occurs.
During normal operation, checkpoint operations occur automatically based on the parameters CkptFrequency (in seconds, default is 600) and CkptLogVolume (in MB, default 0).
So, in a system in steady state with a workload running that contains some amount of write operations log files are continuously generated but also continuously purged based on checkpointing.
When configuring your system you need to consider:

1. What checkpoint parameters should I use? the defaults are rarely ‘correct’ for any given scenario.
2. How much disk space do I need for the checkpoint files? The answer is PermSize +64 [MB] * 2.
3. How much disk space do I need for log files. This depends (a) on the workload and (b) on the checkpoint parameters.

It is important to ensure the system has sufficient disk space for the checkpoint files and (especially) the transaction log files since running out of disk space is highly inadvisable.
Note that you can force a manual checkpoint at any time by connecting to the database using ttIsql as an ADMIN user (or the instance administrator) and issuing the command:

call ttCkpt;

I hope that clarifies.

Best regards,

Chris

以及：

You must never remove database files manually (this applies not just
to TimesTen but to any database). The log files are the transaction
logs (undo/redo) and are essential for correct database operation and
recoverability. If you remove them you essentially corrupt/destroy
your database.

Log files are cleaned up automatically when they are no longer needed,
by checkpoint operations; after two checkpoints most log files will be
removed. Any remaining are still required for database recovery,
replication, cache propagation etc.

Given that after just a little activity your server is down to 3% free
disk space I would recommend you increase the available disk space
significantly or use a server with more free space. Sufficient space
is a necessity and it sounds like your server does not have sufficient
for the size of database and workload that you are experimenting with.

Chris