An OS dump is different from a Teradata crashdump in not only content but also size. Typically, a Teradata crashdump is smaller than the sum of the memory for all the nodes in the database configuration.
The size of raw PDE dumps still in “dump” format (before the crashdumps are saved in table format) depends on various factors such as the type of error, number of vprocs, amount of memory, number of processes running when Teradata crashed and so on. So the size of raw PDE dumps can vary greatly from 10 MB to 4 GB or even larger. For example, on a Linux node that is 4 GB with 10 vprocs, the size of the Teradata crashdump could range from 1.5 to 2 GB.
Because a full crashdump saved to the DBC.Crashdumps database is the collection of the raw PDE dumps from all the nodes, a full crashdump is approximately twice the size of the raw dump multiplied by the number of nodes for your system. The DBC.Crashdumps database, which is allocated from the permanent space of DBC, should be large enough to hold 4 to 5 crashdumps.
Note: Dump creation fails if the number of dumps saved on a node exceeds the limit in the control GDO. After each dump, Teradata checks the number of dumps saved on the node and writes a warning to the system messages log if there is space for only one more dump or if the saved dump limit has been reached.
To prevent space issues, actively manage dumps by saving raw PDE dumps from the dump directory to DBC.Crashdumps, unloading crashdumps from the DBC.Crashdumps database to tape, and deleting unwanted crashdumps from both the dump directory or DBC.Crashdumps database.