DUMPTMAX parameter: Difference between revisions
(Automatically generated page update) |
mNo edit summary |
||
| Line 9: | Line 9: | ||
<dd>System manager resettable | <dd>System manager resettable | ||
<dt>Related products | <dt>Related products | ||
<dd>[ | <dd>[http://m204wiki.rocketsoftware.com/images/1/12/FastbackNew.pdf Fast/Backup] | ||
<dt>Introduced | <dt>Introduced | ||
<dd>Before <var class="product">Sirius Mods</var> 6.7 | <dd>Before <var class="product">Sirius Mods</var> 6.7 | ||
</dl> | </dl> | ||
==Description== | ==Description== | ||
This parameter sets the maximum number of CCATEMP | This parameter sets the maximum number of CCATEMP | ||
| Line 20: | Line 21: | ||
and the thread needs to update a page that has not been dumped yet, | and the thread needs to update a page that has not been dumped yet, | ||
that page needs to be dumped before the page can be updated. | that page needs to be dumped before the page can be updated. | ||
Normally, | Normally, Fast/Backup will dump such a page almost immediately, and | ||
there will be no noticeable delay for the updating transaction. | there will be no noticeable delay for the updating transaction. | ||
However, if | However, if Fast/Backup is waiting for a tape volume switch, perhaps waiting | ||
for a tape mount, an updating transaction in this scenario would | for a tape mount, an updating transaction in this scenario would | ||
also have to wait for the tape mount. | also have to wait for the tape mount. | ||
| Line 30: | Line 31: | ||
are timed out. | are timed out. | ||
In such a situation, | In such a situation, Fast/Backup will try to copy the page to be updated to CCATEMP, | ||
allowing the updating thread to continue with its update. | allowing the updating thread to continue with its update. | ||
After the tape mount is satisfied, the page is copied from CCATEMP, and the | After the tape mount is satisfied, the page is copied from CCATEMP, and the | ||
| Line 38: | Line 39: | ||
CCATEMP being used, leaving insufficient CCATEMP for other applications. | CCATEMP being used, leaving insufficient CCATEMP for other applications. | ||
The DUMPTMAX parameter indicates the maximum number of CCATEMP pages that an | The <var>DUMPTMAX</var> parameter indicates the maximum number of CCATEMP pages that an | ||
individual DUMP will be allowed to use to cache pages that are | individual DUMP will be allowed to use to cache pages that are | ||
about to be updated. | about to be updated. | ||
If this number of pages is exceeded in the scenario described above, the | If this number of pages is exceeded in the scenario described above, the | ||
updating thread will have to wait for the tape mount, or the dump | updating thread will have to wait for the tape mount, or the dump | ||
will be terminated with an error, depending on the setting of the [[DUMPOPTS parameter]]. | will be terminated with an error, depending on the setting of the <var>[[DUMPOPTS parameter|DUMPOPTS]]</var> parameter. | ||
The default value for <var>DUMPTMAX</var> of 0 means that no limit is placed on | |||
the use of CCATEMP pages by Fast/Backup. | |||
See also <var>[[DUMPTMIN parameter|DUMPTMIN]]</var>. | |||
[[Category:System parameters]] | [[Category:System parameters]] | ||
[[Category:Parameters]] | [[Category:Parameters]] | ||
Latest revision as of 19:14, 12 August 2014
Maximum CCATEMP usage for DUMP
Summary
- Default value
- 0
- Parameter type
- System
- Where set
- System manager resettable
- Related products
- Fast/Backup
- Introduced
- Before Sirius Mods 6.7
Description
This parameter sets the maximum number of CCATEMP pages any individual DUMP can use.
If a thread is performing an update on a file that is being dumped, and the thread needs to update a page that has not been dumped yet, that page needs to be dumped before the page can be updated. Normally, Fast/Backup will dump such a page almost immediately, and there will be no noticeable delay for the updating transaction. However, if Fast/Backup is waiting for a tape volume switch, perhaps waiting for a tape mount, an updating transaction in this scenario would also have to wait for the tape mount. The result is not good for the updating request and potentially not good for other users in the Online, as resources held by the updating user are not released and, if sub-transaction checkpoints are being used, checkpoints are timed out.
In such a situation, Fast/Backup will try to copy the page to be updated to CCATEMP, allowing the updating thread to continue with its update. After the tape mount is satisfied, the page is copied from CCATEMP, and the CCATEMP used by the cached page is freed. Obviously, if there is a lot of updating for a file being dumped, and the dump ends up waiting on a tape mount, this could result in a lot of CCATEMP being used, leaving insufficient CCATEMP for other applications.
The DUMPTMAX parameter indicates the maximum number of CCATEMP pages that an individual DUMP will be allowed to use to cache pages that are about to be updated. If this number of pages is exceeded in the scenario described above, the updating thread will have to wait for the tape mount, or the dump will be terminated with an error, depending on the setting of the DUMPOPTS parameter.
The default value for DUMPTMAX of 0 means that no limit is placed on the use of CCATEMP pages by Fast/Backup.
See also DUMPTMIN.