z/VSE: 45 Years of Progress - z/VM - IBM

tical. Most available blades are referred
to as worker nodes, while a smaller
number are brought up as coordinator
nodes. The worker nodes actually store
the data while the coordinator nodes act
as an interface to DB2 for z/OS. During
the unload process, the data flows to the
coordinator nodes and is distributed to
available worker nodes.
While being loaded in the IBM
Smart Analytics Optimizer, the data is
compressed and distributed among
available blades, allowing for massive
parallel processing of those queries
accessing the data. While the data is
stored in main memory, it’s also stored
on a separate storage unit for failover
purposes. Once the offloading process
completes, the mart is ready to be queried
(see Figure 2).
According to an International DB2
Users Group (IDUG) study, most data
warehouses are refreshed once a day or
less. Regarding this information, for
most OLAP applications, querying data
stored on an IBM Smart Analytics
Optimizer can deliver breakthroughs in
terms of performance and reduce the
time needed to complete today’s business
processes.
Here’s the interesting question: Are
there any business questions or business
cases relying on SQL statements that
just didn’t complete in an appropriate
time and you never moved these applications
to production? It might be time
to reconsider these applications.
What happens if a query accesses the
data that’s also available in a mart?
Because of the IBM Smart Analytics
Optimizer’s deep integration into DB2
for z/OS, the optimizer makes a costbased
decision if a query will be routed
to the IBM Smart Analytics Optimizer
for execution or whether it will be processed
in the traditional way by accessing
the data pages, either if they’re
located in the buffer pool or must be
retrieved from DASD.
Queries being routed to the IBM
Smart Analytics Optimizer are expected
to benefit from a significant acceleration.
Results from an early beta customer
experience, presented at the Information
On Demand Conference 2009 in Las
Vegas, have shown a query acceleration
by a factor of more than 370 for a given
query. But mileage will vary, depending
on individual data and queries to access
the data. Internally, the IBM Smart
Analytics Optimizer can be looked at as
kind of an MQT. But the biggest differentiator
is that MQTs are designed to
satisfy a limited set of queries. These
queries need to match the MQT definition
in regard to possible restriction,
projection, grouping, and aggregation
operators while the IBM Smart Analytics
Optimizer matches a much larger scope
of queries because they don’t assume any
of these operations.
What happens if most users can
work with a snapshot, but some users
definitely need to query original data
since important updates must be honored?
If a defined mart hasn’t been
refreshed to contain the most recent
data, queries can be routed to DB2 for
z/OS traditional data access methods by
setting CURRENT REFRESH AGE special
register to 0. On the other hand, a
value of ANY allows for IBM Smart
Analytics Optimizer processing, giving
you maximum flexibility.
Figure 2: Smart Analytics Optimizer Mart Load
Figure 3: Query Execution Process Flow
A query can consist of one or more
query blocks. Typical queries eligible for
IBM Smart Analytics Optimizer processing
access data in a large (fact) table,
including inner joins or left outer joins
with smaller (dimension) tables. If only
one or more query blocks of a given
query use the structure previously
described, queries can also partially
benefit from the IBM Smart Analytics
Optimizer since DB2 for z/OS routes
one query block at a time to the IBM
Smart Analytics Optimizer for execution.
To predict the possible amount of
queries that can be routed to the IBM
Smart Analytics Optimizer for execution
in a DB2 for z/OS environment
using dynamic SQL, IBM offers an
assessment of DB2 for z/OS OLAP
workloads (see Figure 3).
2 4 • z / J o u r n a l • O c t o b e r / N o v e m b e r 2 0 1 0