Database Reference
In-Depth Information
from the bitmap are not adopted, no amount of aggregation or slice clean-up will help.
In fact, let us make this our fourth rule:
r4: Do not depend on aggregation or other “maintenance” to make up for bad design.
okay, on to the bitmap.
7.4 the Bitmap: its role anD FunCtion
I have discussed the bitmap generically and how it effectively creates an index that
allows queries to directly access any level-0 member or all of the level-0 descendants of
an upper-level member. Where BSo calculation “precooked” the data at all levels, ASo
effectively “precooks” by providing an index at all levels.
moving from a generic to a more specific analysis, the data found in EAS, on the
“Statistics” tab of the “Database Properties” dialog, is crucial to understanding perfor-
mance implications of your cube design. In Figure 7.5, the “bits used” for each dimen-
sion are shown. When combined, they make up the bitmap that is attached to each
input-level cell. The “max. key length (bits)” is the sum of these “bits used.” The “max.
key length (bytes)” is the bitmap overhead attached to each input-level cell. It is the
“max. key length (bits)” rounded up to the nearest 8 byte (64 bit) boundary.
7.4.1 Why Should Anyone Care about the Bitmap?
Why indeed? From a high level, the reasons include:
• Increasing the use of Stored hierarchies and attributes can greatly improve per-
formance, but there are costs to be paid in terms of the size of the bitmap.
• It can be worth paying the “cost” of increasing the bitmap and the input-level
data size to increase performance without aggregation.
• There are ways to design the hierarchies to minimize the length of the bitmap
and, therefore, the input-level database size.
• Dynamic members can be used to make a cube that has been optimized as sug-
gested above to appear to the user as originally designed (see Section 7.6.2.1).
In actuality, all of the above relate to the reducing size of the input-level database and
are derived from the prime importance of r1: We need to reduce the footprint of the
cube to enable it to it into memory.
7.4.2 How Is the Bitmap Constructed?
The bitmap is calculated independently for each standard dimension (with attribute
dimensions operating effectively as alternate hierarchies). The number of bits will depend
on the number of siblings at each level and the number of levels. The number of bits
required for each dimension is then summed and rounded up to the nearest multiple
of 64 bits. The DBAg (Database Administrators guide) documentation of this is shown
below. mastering the details of the construction described in the remainder of this sec-
tion is not strictly required to take advantage of the lessons to be gained from the result of
that construction. The reader should feel free to skip ahead and come back for detail later.
The following is reprinted with permission from oracle Corporation,
Oracle Essbase
Administrators Guide Release 11.1.2.1
(oracle Press, 1996, 2011) Chap. 62, p. 934 (DBAg):
