RDBPROD: RMU/VERIFY Reports PGSPAMENT or PGSPMCLST Warnings
Last updated on APRIL 03, 2018
Applies to:Oracle Rdb Server on OpenVMS - Version 6.1 and later
HP OpenVMS Itanium
HP OpenVMS VAX
HP OpenVMS Alpha
RMU/VERIFY may sometimes report %RMU-W-PGSPAMENT or %RMU-W-PGSPMCLST warnings when verifying storage areas. These warnings indicate that the Space Area Management (SPAM) page fullness threshold for a particular data page does not match the actual space usage on the data page. For a further discussion of SPAM pages, consult the Oracle Rdb Guide to Database Maintenance.
In general, these inconsistencies will not cause any adverse affect on the operation of the database. There is potential for space on the data page to not be totally utilized, or for a small amount of extra I/O to be expended when searching for space in which to store new rows. But, unless there are many of these warnings, the impact should be negligible.
It is possible for these inconsistencies to be introduced by errors in the Oracle Rdb product. When those cases are discovered, Oracle Rdb is corrected to prevent the introduction of the inconsistencies. It is also possible for these inconsistencies to be introduced during the normal operation of the product. The following scenario can leave the SPAM pages inconsistent:
- A process inserts a row on a page, and updates the threshold entry on the corresponding SPAM page to reflect the new space utilization of the data page. The data page and SPAM pages are not flushed to disk.
- Another process notifies the first process that it would like to access the SPAM page being held by the process. The first process flushes the SPAM page changes to disk and releases the page. Note that it has not flushed the data page.
- The first process then terminates abnormally (for example, from the DCL Stop/Identification command). Since that process never flushed the data page to disk, it never wrote the changes to the Recovery Unit Journal (RUJ) file. Because there were no changes in the RUJ file for that data page, the Database Recovery (DBR) process did not need to rollback any changes to the page. The SPAM page retains the threshold update change made above even though the data page was never flushed to disk.
Sign In with your My Oracle Support account
Don't have a My Oracle Support account? Click to get started
My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms