Database operations
T24 Database Storage Growth
Separate physical file size, allocated space, used space, and reusable space before deciding that a T24 database has a capacity problem. Database terminology and recovery behaviour differ by platform.
Browse more Production support articles →
Start with the database platform
T24 can run on different relational database platforms. Data files, transaction or redo logs, undo handling, checkpoints, backups, and recovery modes are not described identically across Microsoft SQL Server, Oracle Database, PostgreSQL, and other supported deployments. Confirm the platform and version before applying a command or interpreting a metric.
The SQL Server sections below are explicitly SQL Server-specific. Do not translate FULL, BULK_LOGGED, SIMPLE, VLF, or log-backup behaviour directly to another database.
Four measurements that must not be confused
- Physical size: space currently allocated to the database file on disk.
- Used space: allocated pages or log records that are currently required.
- Reusable space: allocated space that the database can reuse internally.
- Filesystem free space: capacity still available outside the database files.
A large file is not automatically full, and freeing internal space does not automatically return capacity to the operating system. Capacity planning should track all four measures and their trend.
Data-file growth
T24 data storage grows through transaction history, balances, audit data, interfaces, local applications, indexes, temporary work, and retention. Investigate which objects and partitions are growing, whether growth is expected, and whether maintenance or retention controls are working before resizing files.
- Largest and fastest-growing tables and indexes
- Daily and COB-window growth rate
- Free space inside each data file and on the filesystem
- Autogrowth increment, maximum size, and event history
- Archive, purge, and statutory retention requirements
Microsoft SQL Server transaction-log model
In SQL Server, the transaction log file is divided internally into virtual log files (VLFs). The physical log file does not normally grow and shrink with each transaction. SQL Server writes log records into the allocated file and can reuse inactive log space after the conditions for log truncation are met.
Log truncation marks inactive log space as reusable; it does not reduce the physical file size. A shrink operation is the separate action that may return unused physical space to the operating system, and it should be exceptional rather than routine.
SQL Server recovery models and log reuse
FULL and BULK_LOGGED
Regular successful transaction-log backups are normally required to advance the log backup chain and make inactive log space reusable. A full database backup does not replace transaction-log backups and does not itself shrink the log file.
SIMPLE
SQL Server can truncate inactive log records after checkpoints when no other reuse blocker remains, but the physical log file still stays at its allocated size unless it is explicitly shrunk.
Recovery-model changes affect point-in-time recovery and the log backup chain. Do not switch models merely to reduce a file without an approved recovery and backup plan.
Why a SQL Server log cannot reuse space
Diagnose the reported log-reuse wait rather than guessing. Common categories include missing log backups under FULL or BULK_LOGGED recovery, an active transaction, availability or replication dependencies, backup or restore activity, and other platform-reported waits. Capture the oldest active transaction and backup history before intervention.
When shrink is justified
Shrink can be reasonable after a one-off event caused an exceptional increase and the normal working requirement is demonstrably lower. Set a target that preserves headroom for the largest expected transaction and COB window. Repeated shrinking followed by autogrowth creates avoidable I/O, fragmentation of the VLF layout, and capacity risk.
Platform-neutral monitoring sequence
- Confirm database platform, version, recovery configuration, and storage layout.
- Measure physical size, used space, reusable space, and filesystem headroom.
- Compare growth during normal hours, COB, backup, and maintenance windows.
- Identify the objects, operations, or reuse blockers driving the trend.
- Review autogrowth, alert thresholds, backup success, and recovery objectives.
- Model the next peak window before resizing or reclaiming space.
COB and recovery impact
Storage exhaustion can stop posting, logging, temporary work, or database growth during COB. A green application status does not override database evidence. Preserve the first database error, file and filesystem trends, active workload, backup status, and the COB stage before escalating.
For wider closeout checks, read why batch success can be misleading.
Related reading
What Is COB in T24? Close of Business Explained
A plain-English introduction to Close of Business (COB) in Temenos T24 — what it does, why it matters, what the batch actually processes, and what to do when it does not complete.
COB and supportWhy Batch Success Can Be Misleading in T24
A practical T24 operations guide to proving that a completed batch produced the expected business outcome, not only a successful return status.
Production supportFive Things to Check Before Escalating a T24 Incident
The difference between a junior analyst and an experienced one is often ten minutes and a short checklist. Five questions to answer before you pick up the phone.