Database Reference
In-Depth Information
construction, going back and forth with mDx references before finally determining that
it was written correctly. “hmmm,” you would pause again, “I must have done something
wrong with my query.” Back to Excel you would go to adjust the query only to have it
return #mISSIng again. off you would go to database properties to do some checking
on your aggregations only to find that you have 0 cells loaded and 0 cells aggregated on
this cube. “What the …,” you would literally scream, “I hate this tool. It just dumped the
data.” yep it did—all the time.
That is the place where ASo cube developers started—with a new technology that
carried with it a great deal of excitement, but within a tool that felt very fragile. If you
disturbed the cube in almost any way, the data had to be reloaded. Those early days in
ASo cube development found developers creating load files that needed no Load rules
so that reloads were quick and easy, because they were done over and over and over
again. It certainly is no wonder that many shunned this new storage kernel after only a
few attempts to use it.
Fast forward to present day ASo cube development. now, not only can you update
dimensionality without disturbing the data, you can incrementally update the data-
base without disturbing the main dataset by using Data Slices. Incremental data load
times are proportionate to the size of the data that is being loaded, not to the size of the
existing database and this is a very significant differentiation. Just because the database
is enormous does not mean adding data to it will take an excessive amount of time.
Present day, not only can you incrementally update the data, but you do not have to
rerun the aggregations because they update automatically as needed. The system does it
for you. how fantastic is that? I feel a bit like I am in a television infomercial right now
and want to yell “kABoom.” Seriously, that is how exciting this new development in
ASo cube processing is.
This section will walk through a sequential explanation of how Data Slices work,
and the steps involved in using them in a summary fashion. once that is completed,
the journey will continue by exploring a week of time and processing in a real-life pro-
duction set of cubes that are using these specific techniques (this is very fresh, as those
cubes went into production while this topic was being written). his will allow for com-
plete access to production code, production situations, and production pros and cons.
In addition, some assurance can be felt in the knowledge that these strategies and tech-
nologies are currently being used successfully and, hopefully, that knowledge will help
to alleviate any fears or angst over trying it out.
The usage of Data Slices is a very simple concept. In its most basic form, the steps to
use a Data Slice include:
• Data is loaded into the main part of the database and aggregated using normal
processes.
• A new load is defined and when the data is loaded from the buffer, the system is
told to situate it next to the existing database as a Data Slice, instead of merging
it directly into the existing database.
• When the Data Slice is loaded, the system automatically creates the required
views for that slice and the system completes this task prior to making the new
Data Slice visible to user queries.
• multiple slices can be added during the same process.
• Eventually, query performance will degrade as the slices pile up; a fact that will
be seen in the statistics provided in EAS on the cost of querying the slices.
