Database Reference
In-Depth Information
always be exceptions to database behavior. use the ideas presented here as guidelines
and not absolutes. This chapter is aimed squarely at the BSo developer or administra-
tor who knows the basics, but does not have a solid understanding of the underlying
technology; this is not a chapter for the novice BSo developer or administrator. BSo
is almost 20 years old and there are already numerous topics, whitepapers, and online
resources that are terrific when it comes to the basics. The chapter will appeal to:
• Those who want to understand the elements that impact database performance.
• Anyone who is confused with the plethora of BSo cache settings.
• Those who want to take advantage of the log messages while tuning calculations
scripts.
• Anyone needing to efficiently create data blocks in a calculation script.
• Administrators or developers seeking the “choke point” of a calculation script.
This chapter is full of ideas and examples that will encourage you to create efficient and
robust Essbase databases and inspire you to improve your existing calculation scripts.
4.2 prereQuisites
It is absolutely critical that the reader have at least moderate administration experi-
ence with Essbase and, in particular, with BSo. In addition, it will be helpful to be very
familiar with Essbase Administration Services (EAS) and how to view application logs
and database statistics.
4.3 why Bso, inDeeD
With apologies to mark twain, reports of the death of Essbase block storage are greatly
exaggerated. We have heard all of the reasoning for the demise of block storage: BSo
has limitations on the number of practical dimensions, sparse/dense configuration is
confusing, dense block has size limitations, and, finally, the calculations are too slow.
oh, and let us not forget data explosion. okay, I understand the issues, but tell me this:
name another tool that offers in-place write back along with scores of functions for
manipulating data. These are the features that separate Essbase block storage from every
other tool and reasons why BSo will be around for some time.
What about the performance-related concerns, you ask? Admittedly, there can be
issues. one only needs to look on the oracle technology network (otn) message boards
to view performance difficulties that others have experienced. Like any technology, there
is a time and place when BSo is the correct choice. no good discussion of BSo can begin
without identifying where BSo is not a good fit. Before the advent of aggregate storage
options (ASo), block storage Essbase was used for every type of application imagin-
able. today, BSo is best used for read/write applications and databases that use complex
allocations and calculations. I am not saying that BSo cannot be used for large report-
ing applications, it certainly can. I am asserting that because of scaling constraints that
is not its best application. regardless of use, I am going to show you how to use the
power of Essbase block storage to build databases that perform to the best of their ability.
Certainly you have all heard that Essbase design is more art than science. truer words
have never been spoken. What works with one database might not work as well with
another. I will help you understand the variables that affect performance. After that, it is
your responsibility to try various options and then test, test, and test some more.
