It can be difficult to determine how many "loads" could be run at a time to not impact other production work. For example a single large mload could have more impact than several small fastloads due to duration and table locks that it can hold as well as cpu resources it can consume if it is a delete/update. You can also setup TASM rules to limit how many utility slots are consumed by a given user or workload. So if you wanted to control how many could be used in order to protect the system you can do that. For example we allow ETL to be able to run 15 fastloads but never more than 10 mloads any job past that limit goes into the queue to wait. We limit adhoc users of fastloads to one utility slot so they can't overconsume and impact production.
You can look at dbql tables and determine how many loads are running concurrently (its a little messy but doable) since for fastload/mload/fastexport you have to look at the LSN to see which sessions belong to the same job.
Out of the box Teradata supports 5 concurrent load slots (dbscontrol setting) which can be changed to 15, and if you change some other settings in dbscontrol then you can support more load slots based on the information that Joe mentions above. Also, if you don't use the MaxLOadTasks and MaxLoadAWT to go past the 15 load slot limit (or the TASM Utility Throttle) then fastexport will also count towards that 15 utility slot limit (I believe that is still correct).
It can be difficult to determine how many "loads" could be run at a time to not impact other production work. For example a single large mload could have more impact than several small fastloads due to duration and table locks that it can hold as well as cpu resources it can consume if it is a delete/update. You can also setup TASM rules to limit how many utility slots are consumed by a given user or workload. So if you wanted to control how many could be used in order to protect the system you can do that. For example we allow ETL to be able to run 15 fastloads but never more than 10 mloads any job past that limit goes into the queue to wait. We limit adhoc users of fastloads to one utility slot so they can't overconsume and impact production.
You can look at dbql tables and determine how many loads are running concurrently (its a little messy but doable) since for fastload/mload/fastexport you have to look at the LSN to see which sessions belong to the same job.
Out of the box Teradata supports 5 concurrent load slots (dbscontrol setting) which can be changed to 15, and if you change some other settings in dbscontrol then you can support more load slots based on the information that Joe mentions above. Also, if you don't use the MaxLOadTasks and MaxLoadAWT to go past the 15 load slot limit (or the TASM Utility Throttle) then fastexport will also count towards that 15 utility slot limit (I believe that is still correct).