● ログ・データ を ログ・エリア から リカバリー・ファイル に移送することを スピル という。

　更新 トランザクション が リカバリー・ファイル に退避されるまで記録されている一時的な ストーレッジ （a transient storage area） がログ・エリア （ログ・ファイル） である。逆に言えば、ログ・エリア のなかに記録された更新 トランザクション は、リカバリー・ファイル に退避できる （ログ・エリア から リカバリー・ファイル に データ を移送することを 「スピル （spill）」 という）。ログ・エリア の容量は、2つの スピル の間に起こる更新 トランザクション を納める大きさでなければならない。

　リカバリー・ファイル は、通常、外部記憶媒体を使い、ログ・エリア のなかに記録された レコード が スピル されて、昇順（更新日の古い順）に納められる。

　
● チェックポイント は、ログ （logging） とリカバリー （recovery） の調整をする。

　ログ・エリア のなかに更新 トランザクション があれば、いわゆる 「データ の自動修復 （ロールバック あるいは トランザクション・バックアウト）」 ができる。

[ 注意 ]
　ロールバック と トランザクション・バックアウト はちがう。相違については、後日、述べる。

　したがって、更新 トランザクション に対して、以下の 2点を考慮しなければならない。

　　（1） [ 当座の データ を自動的に修復するために ] どの データ を ログ・エリア に残しておかなければならないのか。
　　（2） [ 将来の障害修復に備えて ] どの データ を リカバリー・ファイル に スピル するのか。

　更新 トランザクション を外部記憶媒体の リカバリー・ファイル に スピル すれば、データ の自動修復はできない （リカバリー・ファイル と、過去の データ を退避した バックアップ・ファイル の 2つを使って、リカバリー することになる）。更新 トランザクション を スピル するかどうかの判断が チェックポイント （checkpoints） である。
　つまり、チェックポイント を書き込まれた （付与された） 更新 トランザクション は スピル の対象となる （eligible for spilling to the Recovery File）。

　更新 トランザクション は、チェックポイント を付与されても、スピル されなければ、当然、ログ・エリア に残ったままである。逆に言えば、スピル を実行すれば、「最新の」 チェックポイント （last checkpoint） が付与された更新 トランザクション よりも以前に ログ・ファイル に書き込まれた トランザクション が リカバリー・ファイル に移されることになる。たとえば、ログ・エリア のなかに、更新 トランザクション が、記録された順に、4つ （a, b, c, d） あって、トランザクション c に対して チェックポイント が付与されたなら、スピル を実行すれば、a と b と c が リカバリー・ファイル に移送され、d は ログ・エリア に残る。

　
● チェックポイント の間隔が長ければ、トランザクション・バックアウト の パフォーマンス は悪くなる。

　基幹系 システム では、オンライン・リアルタイム の トランザクション に対して、1件ずつ （トランザクション ごとに） チェックポイント を付与することが普通であるが、時間枠を設けて、チェックポイント を付与することもある （たとえば、300秒ごとに、チェックポイント を付与するとか）。バッチ・システム では、チェックポイント は、ユーザ が設けた間隔で付与される （たとえば、100 件ごととか 1,000 件ごととか）。

　データ の自動修復 （ロールバック あるいは トランザクション・バックアウト） では、「最新の （last）」 チェックポイント まで遡及して、修復の対象となる データ を検証する。したがって、チェックポイント の間隔が長ければ長いほど、ロールバック あるいは トランザクション・バックアウト が起これば、データベース の パフォーマンス が悪くなる。チェックポイント の間隔は、データベース の チューニング 対象となる。
　データベース の 「モニタリング と チューニング （monitor and tune-up）」 は、後日、述べる。