1 – record_marked_field
This field gives the number of records marked. A record is marked
when it is modified or it is erased, but not when it is stored.
2 – record_fetched_field
This field gives the number of records, including snapshot
records, fetched.
3 – _fragmented_field
This subfield indicates the number of record fragments that
Oracle Rdb had to fetch. A record is fragmented if it is too
large to fit on one page. A fragmented record requires more
CPU time and more virtual memory, and often requires additional
I/O operations because each record fragment must be fetched. If
this value is high compared to the number of records fetched,
Oracle Corporation recommends that you use the RMU Analyze Areas
command to further analyze the problem to see how many records
are actually fragmented.
4 – ___record_stored_field
This field gives the number of records stored in the database.
5 – __fragmented_field
This subfield indicates the number of rows stored as fragmented
records in the database. This number indicates that a page
size is smaller than a record's uncompressed size (including
overhead). You should use the RMU Analyze Areas command to
further analyze the problem and then increase the page size for
the storage area that has the problem.
6 – pages_checked_field
This field indicates the number of pages checked in order to
store a record. Ideally, very few candidate pages need to
be checked when storing a record. However in certain cases,
depending on record size, access method, locked space on a page,
and SPAM thresholds, storing a record requires a number of page
fetches.
7 – saved IO field
This field gives the number of pages checked that did not result
in an I/O because the page was already in the buffer. It is
essentially a "for free" pages checked.
8 – ____discarded_field_
This field identifies the number of pages checked but discarded
because the actual free space on that page did not meet the
physical requirements needed to store a new record.
9 – _record_erased_field
This field gives the number of records erased from the database.
10 – ___fragmented_field
This subfield indicates the number of fragmented records erased
from the database.
11 – node_fetches_field
This field gives the number of times Oracle Rdb fetched an
index node during index retrievals. This number includes the
number of leaf nodes and duplicate nodes fetched. Therefore, the
calculation for the number of upper-level index nodes accessed
is: this "node fetches" field minus the sum of the leaf and
duplicate node fetches. The result can indicate the depth of
the database indexes.
12 – _leaf_fetches_field
This field gives the number of times Oracle Rdb fetched bottom
level (leaf) nodes during index retrievals. This number, along
with the "index scans" field, can indicate the length of scans in
terms of index nodes accessed. There is one leaf node fetch for
each "index lookup" retrieval.
13 – _dup__fetches_field
This field gives the number of times Oracle Rdb fetched a
duplicate node (as opposed to a leaf node) during index
retrievals. This number can indicate the lengths of duplicate
node chains in the database indexes. When a duplicate node is
retrieved, the operation always includes one leaf fetch.
14 – index_lookups_field
This field gives the number of direct single-key retrievals
performed on the database indexes. This statistic shows up only
on unique key retrievals and not on duplicate key retrievals.
15 – index_scans_field
This field gives the number of scans, or range retrievals,
performed on the database indexes. In an index scan, Oracle Rdb
searches an index from top to bottom to find the starting point
(low value) of the retrieval. Oracle Rdb then searches the bottom
level nodes of the index, including duplicate nodes, until the
scan's end condition is met.
16 – _primary_entries_field
This field gives the number of unique keys found during the index
scan.
17 – _dup__entries_field
This field gives the number of duplicate keys found during the
index scans. If an index has two entries with the same key value,
the first one is a primary entry and the second is a duplicate
entry.
18 – node_insertions_field
This field gives the number of index entries inserted into all
index nodes. This number includes root, leaf, and duplicate
entries within user- and system-defined indexes.
This number is greater than the number of records being stored
in the database because it usually takes one to two insertions
into an index for each record for each index. The calculation of
node insertions minus the sum of the root, leaf, and duplicate
insertions yields the number of entries inserted into mid-level
nodes. This number and the "root insertions" field indicate
sorted balancing activity.
19 – _root_insertions_field
This field gives the number of entries inserted into the root
(top-level) index nodes. The number of insertions should be small
except for when you load the database. Also, if an index consists
of only one node, insertions into this node are not included in
this field, but are included in the "leaf insertions" field.
20 – _leaf_insertions_field
This field gives the number of unique keys inserted into the
database's indexes. This field indicates the number of entries
inserted into the leaf (bottom-level) index nodes.
21 – _dup__insertions_field
This field gives the number of duplicate index keys inserted
into the database's indexes. There should be a one-to-one
correspondence to the number of duplicate records being stored
in the tables.
22 – node_creations_field
This field gives the total number of index nodes created during
insertion of index entries into the index trees. This includes
root, leaf, and duplicate nodes created within user- and system-
defined indexes. Nodes are created three ways:
o When an index is first defined
o When a node cannot accommodate an insertion, causing it to
overflow into a new node (node splitting)
o When the first duplicate for a particular key is inserted into
an index, causing a duplicate node to be created
The total number of nodes created and the associated fields
should be relatively small, except for an initial load of the
database with indexes already defined, or for creation of indexes
on already-stored data.
23 – _root_splits_field
This field gives the number of times the root nodes have split
because they overflowed after an insertion. A root node split
causes the index to grow by one level-a parent node must be
created to point to the two "halves" of the overflowed root node.
Therefore, two nodes are created-the parent node and the node for
the second half of the root node. Increasing the number of tree
levels means Oracle Rdb must search more index nodes to access a
data row; this can result in additional I/O operations.
24 – _leaf_creations_field
This field gives the number of times a leaf (bottom level) node
was created because an existing leaf node had become full and
needed to accommodate another unique index key entry.
25 – _dup__creations_field
This field gives the number of times a duplicate node was created
to accommodate more duplicated entries within the duplicate index
node or on the first store of a duplicate key entry.
26 – index_creations_field
This field gives the number of times an index was created on
a particular table. This count is the number of CREATE INDEX
statements. Also, if an index is partitioned over three areas,
for example, there will be a count of three index creations.
27 – node_removals_field
This field gives the total number of index entries within the
root, leaf, and duplicate nodes that have been removed. This
removal can be triggered by erasing rows, deleting tables, or
deleting indexes. The calculation of node removals minus the sum
of the root, leaf, and duplicate node removals yields the number
of entries removed from mid-level nodes. A node is not deleted
until all its entries are removed.
28 – _root_removals_field
This field gives the number of index entries removed from a root
node due to deletion of entries within lower-level nodes. If an
index consists of only one node, removals from this node are not
included in this field, but are included in the "leaf removals"
field.
29 – _leaf_removals_field
This field gives the number of unique index keys removed from the
leaf nodes during an SQL DELETE operation.
30 – _dup__removals_field
This field gives the number of duplicate index keys removed from
duplicate nodes due to the deletion of duplicate records. This
should be a one-to-one correspondence to the number of erased
duplicate records within the database.
31 – node_deletions_field
This field gives the total number of index nodes deleted due
to an SQL DROP INDEX statement or when the nodes become empty
(except for the root node, which remains even when it is empty).
When an index is deleted, this number should be equal to the
total number of index nodes within the index. This field minus
the sum of leaf and duplicate node deletions yields the number of
mid-level node deletions.
32 – _leaf_deletions_field
This field gives the number of leaf (bottom level) nodes deleted
from the database's indexes. A leaf node is deleted only when it
becomes empty.
33 – _dup__deletions_field
This field gives the number of duplicate node deletions within
the indexes.
34 – index_destructions_field
This field gives the number of indexes deleted with an SQL
DROP INDEX statement. This count will be 1 if the index is not
partitioned. If an index that is partitioned over three areas is
deleted, for example, then the count will be 3. This count also
gives the number of root node deletions.
35 – __pages_checked_field
This field indicates the number of pages checked in order to
store a B-tree index node. Ideally, very few candidate pages
need to be checked when storing a B-tree index node. However,
in certain cases, depending on the size of the segment, locked
space on a page, and SPAM thresholds, storing a B-tree index node
requires a number of page fetches.
36 – saved IO field
This field gives the number of pages checked that did not result
in an I/O because the page was already in the buffer. It is
essentially a "for free" pages checked.
37 – ______discarded_field_
This field identifies the number of pages checked but discarded
because the actual free space on that page did not meet the
physical requirements needed to store a new B-tree index node.
38 – bucket_marked_field
This field gives the number of buckets marked. A bucket is marked
when it is modified or it is erased, but not when it is stored.
39 – bucket_fetched_field
This field gives the number of buckets fetched.
40 – ____fragmented_field_
This subfield indicates the number of bucket fragments that
Oracle Rdb had to fetch. A bucket is fragmented if it is too
large to fit on one page. A fragmented bucket requires more
CPU time and more virtual memory, and often requires additional
I/O operations because each bucket fragment must be fetched. If
this value is high compared to the number of buckets fetched,
Oracle Corporation recommends that you use the RMU Analyze Areas
command to further analyze the problem to see how many buckets
are actually fragmented.
41 – _bucket_stored_field
This field gives the number of buckets stored in the database.
42 – _____fragmented_field_
This subfield indicates the number of buckets stored as
fragmented buckets in the database. This number indicates that a
page size is smaller than a bucket's uncompressed size (including
overhead). You should use the RMU Analyze Areas command to
further analyze the problem and then increase the page size for
the storage area that has the problem.
43 – ___pages_checked_field
This field indicates the number of pages checked in order to
store a hashed index. Ideally, very few candidate pages need
to be checked when storing a hashed index. However, in certain
cases, depending on the size of the segment, locked space on a
page, and SPAM thresholds, storing a hashed index requires a
number of page fetches.
44 – saved IO field
This field gives the number of pages checked that did not result
in an I/O because the page was already in the buffer. It is
essentially a "for free" pages checked.
45 – _______discarded_field_
This field identifies the number of pages checked but discarded
because the actual free space on that page did not meet the
physical requirements needed to store a new hashed index.
46 – hash_insertions_field
This field gives the number of hash key insertions in the
database's hashed indexes. It includes unique key insertions
as well as duplicate key insertions.
47 – _____duplicates_field_
This field gives the number of duplicate key updates in the
database's hashed indexes.
48 – hash_deletions_field
This field gives the number of hash key deletions from the
database's hashed indexes. It includes unique key deletions as
well as duplicate key deletions.
49 – ____duplicates_field_
This field gives the number of duplicate key deletions in the
database's hashed indexes.
50 – hash_scans_field
This field gives the number of hashed index scans, including both
retrieval and update scans, that were opened on the database's
hashed indexes. A scan is defined as the sequential processing
of the records that meet the search criteria of a query. Hashed
scans then refer to the case where duplicate records are returned
that meet the search criteria of a query from a scan of the
hashed index.
51 – hash_index_fetches_field
This field gives the number of hashed index nodes that were
fetched on a successful search of the database's hashed indexes.
This includes fetches of duplicate nodes as well as bucket
fragment nodes.
52 – __bucket_fragments_field
This field gives the number of bucket fragments that were fetched
on a successful search of the database's hashed indexes.
53 – ___duplicate_nodes_field
This field gives the number of duplicate nodes that were fetched
on a successful search of the database's hashed indexes.
54 – blob_marked_field
This field gives the number of blob segments marked. A blob
segment is marked when it is erased or reused, but not when it
is stored.
55 – _blob_fetched_field
This field gives the number of blob segments fetched. This number
includes pointer segments in addition to actual user data.
56 – ______fragmented_field_
This subfield indicates the number of blob segment fragments that
Oracle Rdb had to fetch. A blob segment is fragmented if it is
too large to fit on one page. A fragmented blob segment requires
more CPU time and more virtual memory, and often requires
additional I/O operations because each blob segment fragment
must be fetched.
This number refers only to actual user data as pointer segments
are unlikely to fragment.
57 – _blob_stored_field
This field gives the number of blob segments stored in the
database. This number includes pointer segments in addition to
actual user data.
58 – _______fragmented_field_
This subfield indicates the number of rows stored as fragmented
blob segments in the database. This number indicates that a page
size is smaller than a blob segment.
This number refers only to actual user data as pointer segments
are unlikely to fragment.
59 – _pages_checked_field
This field indicates the number of pages checked in order to
store a blob segment. Ideally, very few candidate pages need to
be checked when storing a blob segment. However in certain cases,
depending on the size of the segment, locked space on a page, and
SPAM thresholds, storing a blob segment requires a number of page
fetches.
60 – saved IO field
This field gives the number of pages checked that did not result
in an I/O because the page was already in the buffer. It is
essentially a "for free" pages checked.
61 – _____discarded_field_
This field identifies the number of pages checked but discarded
because the actual free space on that page did not meet the
physical requirements needed to store a new blob segment.
62 – blob_erased_field
This field gives the number of blob segments erased from the
database. Note that the erase of blob segments is deferred until
COMMIT time.
63 – ________fragmented_field_
This subfield indicates the number of fragmented blob segments
erased from the database.
This number refers only to actual user data as pointer segments
are unlikely to fragment.