Temporary files are the files that Progress creates during a session and deletes at the end of a session.
Files used and naming convention:
The naming convention used for the temp-files is <prefix>+<random sequence>, where the complete filename is unique to the machine that generated it.
- The prefix is a 3-letter prefix indicating the type and purpose of the temp-file.
- The random sequence is obtained by using operating system APIs (mktemp, mkstemp or equivalent), so the behavior can vary depending on the exact OS and OS version. Often the sequence is unique per running process, in some cases (for example: AIX) it's unique per file.
Any combination of the following files might be seen in the Progress working directory per client connection (or where -T is specified):
- Temp table file (dbi*) - Progress uses this file to store temporary tables when temp table space requirements grow beyond the number of blocks specified by -Bt parameter. If the application uses a lot of temporary tables, this file can grow quite large.
- Local before-image file (lbi*) - Progress uses this file to back out of subtransactions and variable value changes. If the local before-image file becomes too large, the procedures probably use a lot of subtransactions.
- Session sort file (srt*) - Progress uses this file to maintain client-side sorting and result lists for queries. In releases earlier than OpenEdge 10.1C, it is also used to swap r-code segments in and out of the execution buffer (= the memory allocated via -mmax).
- R-code swap file (rcd*) - In OpenEdge 10.1C and later, this is used to swap r-code segments in and out of the execution buffer instead of the srt* file. If these files are big and growing, you have a lot of rcode swapping and many procedures open.
- Edit buffer contents (pge*)
- trp* - Stores Data Dictionary changes until they are saved
- rpf* - Stores raw data used by the Profiler
Temp-file locations
By default, Progress stores temporary files in the user’s working directory, whether the working directory is local or remote.
On UNIX, unless the Save Temp Files (-t) startup parameter, the temporary files will not be seen in the directory because they are created unlinked. If the system crashes and the UNIX file system recovery program fsck finds the files. This program might then prompt the system administrator to delete the files. If this occurs, delete them. The temp-files are always deleted if a client shuts down normally. Using the -t will preserve the temp-files if the client terminated abnormally.
On Windows, these temporary files are always visible during a Progress session unless a Transparent Database Encryption (TDE) license is used. The temp-files are always deleted if a client shuts down normally.
Common issues and recommendations:
- Put temporary files on a local drive local to the machine running the client, do not place them on a network drive.
This avoids two issues:
- Since network storage is normally slower than local disks, storing the temp files in a network location can cause a significant performance loss.
- Depending on OS used the file names generated are only guaranteed to be unique for the machine creating them, not for the overall environment. If clients from multiple machines use the same network directory, there is a risk they try to use the same temp-file names which will result in conflicts.
To ensure that Progress stores temporary files in a local directory, either start each Progress client in a local directory or with the Temporary Directory (-T) startup parameter set to a local directory.
- If one of the temp files exceed the size limit, the client will crash.
Temporary files are written to one folder location. It is not possible to specify a second temporary file location when the current file location runs out of space or cannot be written to for some reason.
Up to and including the OpenEdge 10.1B release, the client imposes a hard limit of 2GB applies to all client-temporary files. Since OpenEdge 10.1C, this limit was dropped. However, hard limits from the OS or the filesystem used, as well as user limits set on the OS level will apply in all environments.
The amount of temporary file I/O activity varies among applications, but if a temp-file reaches a file limit is reached the client will crash with a message indicating that that file can not grow. But these messages can be somewhat misleading. For example, running a particular procedure on a Unix results in Progress abnormally terminating in a way that indicates the hard disk is full. However, when you check the disk immediately afterward, adequate space is available. In this case: a temp-file hit a limit, the client crashed, and the OS cleaned up the unlinked temp-file and freed up the disk space.
To confirm this scenario, use the -t parameter to expose the temp-files, and verify how large they grow.
When temp-files grow too large, this is often indicative of inefficient use of resources, or resource leaks which need further investigation at the application code levels.
- SQL clients do not behave the same as ABL clients
For SQL clients the situation is somewhat different. SQL-92 temp tables are analogous to those created for 4GL clients, but they have a uniform name format of Mxxxx; they are similarly created during a transaction and released when the transaction ends. These temp files are (currently) designed to efficiently handle very large amounts of data. Pre 9.1D05, there is a 500 MB size limit on these tables. Pre OpenEdge 10.1x, they cannot be relocated by use of the -T parameter, but will always appear in the Progress working directory ($WRKDIR, %WRKDIR%).
The -T parameter need to be defined explicitly on the database (secondary) broker used for the SQL connections, the -T value defined for a non SQL primary broker will not be used on a secondary broker dedicated for SQL connections.
SQL tempfiles after 10.1x behave more like ABL temp files. Please refer to the Article links below for further information.
