ibm db2 analytics accelerator for z/os (idaa)

© 2012 IBM Corporation

IBM DB2 Analytics Accelerator for z/OS (IDAA)

La BI del 201x ha trovato casa

Milano Roma 13-14 Marzo 2012

Enrico Caraffi

Architect IBM Software [email protected]


Agenda

Introduzione: Tracce di BI del 201x

Architettura DB2 + IDAA

Alcuni risultati del beta program

DB2 + IDAA internals

Proposta: Workload assesment


Scenari di Business Intelligence e dintorni

Alcune Tracce per agevolare la discussione

3


LEGACY

SOURCES

DATAMARTSDATA INTEGRATION

WAREHOUSE

OLAP

REPORTS

MASTER DATA

OPERATIONAL

ANALYTICAL

REFERENCE DATA

Applicazioni OPERATIONAL APPLICATIONS AND USERS

C’era una volta un sistema IT ...

ENTERPRISE CONTENT DATA

Acquire Data

WarehouseInformation

TransformInformation

Present Information

Traccia 1) Lo scisma dell’IT

4


Il costo dello scisma

�Dis-Economie nella gestione di ambienti multi piattaforma

–Disomogeneità nei processi di Sicurezza, Storage, Schedulazione

–Limitati Workload management, Monitoraggio, H. Availability

–Limiti alla possibilità di consolidare l’HW

�Problemi nello spostare i dati da una piattaforma all’altra

–Ritardi di propagazione

–Inefficienze nello storage

–Instabilità nelle performance di Rete

�Difficoltà nel chiudere il ciclo dati-informazioni-decisioni

–Complicazione nel creare ritorni dalla Bi per il Business di Front-Line

–Difficoltà nel Certificare i processi e i dati di BI

–Difficoltà nel credere ai dati da parte degli utenti


6



Il costo dello scisma

�Dis-Economie nella gestione di ambienti multi piattaforma

–Disomogeneità nei processi di Sicurezza, Storage, Schedulazione

–Limitati Workload management, Monitoraggio, H. Availability

–Limiti alla possibilità di consolidare l’HW

�Problemi nello spostare i dati da una piattaforma all’altra

–Ritardi di propagazione

–Inefficienze nello storage

–Instabilità nelle performance di Rete

�Difficoltà nel chiudere il ciclo dati-informazioni-decisioni

–Complicazione nel creare ritorni dalla Bi per il Business di Front-Line

–Difficoltà nel Certificare i processi e i dati di BI

–Difficoltà nel credere ai dati da parte degli utenti

Mancate opportunitàDisEconomieRischi

$

R

R

R

$

$

$

O

O

O

O

$

$

$

$

R $

R

7


Board Room

Executive

Manager

Analisti del Business

Personale a contatto con il cliente

(es., Filiale, Centro Servizi, Call Center)

Customers

<50

<500

<1,000

n *1.000

Milioni

1990

1995

2005

201X

Un servizio che porta valore a ciascun utente

Cross Selling

Numero dellerichieste

Occasionali

KPI dashboard

Risk Analysis

Decine

Centinaia

Migliaia

2000

Milioni

Utenti

Traccia 2: la Business Intelligence e i suoi utenti

8


Utenti della BI

Query

DB2 z/OS

Ottimizzatore

Query più

complesse ampie e

storicamente

profonde

Query più

numerose

focalizzate in

ambiti specifici

Gioco di squadra: ad ognuno il suo compito

Workload diversificato

DB2 zOS

Ottimizzato per accessi puntuali

ottimizzato per accessi concorrenti

IDAA

Ottimizzato per processi massivi

Ottimizzato per fare scansioni

Ottimizzato per Aggregazioni

9


Agenda






12


Deep DB2 Integration within zEnterprise

Data

Manager

Buffer

ManagerIRLM

Log

Manager

IBM

DB2

Analytics

Accelerator

Applications DBA Tools, z/OS Console, ...

. . .

Operational Interfaces

(e.g. DB2 Commands)

Application Interfaces

(standard SQL dialects)

z/OS onSystem z

Netezza

DB2 for z/OS

Superior availability

reliability, security,

Workload management

Superior

performance on

analytic queries

13

© 2012 IBM Corporation14

Query Execution Flow

DB2 for z/OS

Optimizer

IDA

A D

RD

A R

equesto

r

IBM DB2 Analytics Accelerator

Application

Application

Interface

Queries executed with DB2 Analytics Accelerator

Queries executed without DB2 Analytics Accelerator

Heartbeat (DB2 Analytics Accelerator availability and performance indicators)

Query execution run-time for

queries that cannot be or should

not be off-loaded to IDAA

SPU

CPU FPGA

Memory

SPU

CPU FPGA

Memory

SPU

CPU FPGA

Memory

SPU

CPU FPGA

Memory

SM

P H

ost

Heartbeat

Faster Answers, Faster Reports


Front End “SMP” Server

“Snippet Blades”TM

(S-Blades, SPUs)

Comparto Dischi

IDAA ServerSQL Compiler, Query Plan, OptimizeAdministration2 front/end hosts, IBM 3650M3clustered active-passive2 Nehalem-EP Quad-core 2.4GHz per host

Storage incorporato:8 Comparti con 12 Dischi ciascunoda 3.5” 1TB, 7200RPM, SAS (3Gb/s)steaming a max 116MB/s su datifortemente compressiEsempio:TF12: con 8 comparti→ 96 HDDs1/3 dedicati ai dati = 32 TB spazio fisico1/3 in Mirroring1/3 per WorkspaceIpotizzando una compressione media di 4:1

Ospita→→→→ 128 TB di dati

DB2 Analytics Accelerator Supportato dalla tecnologia HW e SW Netezza TwinfinTM

15

Processori e Logica di trattamento dati ottimizzatiper il Data Base streaming , le aggregazioni,le Join massivamente parallele.In un Case massimo 6+6 BladesCon 1+1 Blade di riserva


Asymmetric Massively Parallel Processing™

Massively Parallel Intelligent Storage

1

2

3

960

�

�

�

10 GigabitEthernetSMP Host

DBOSFront End

High-PerformanceDatabase Engine

Streaming joins, aggregations, sorts, etc.

Logical Processing Unit

Processor &

streaming DB logic


Processor &

streaming DB logic


Processor &

streaming DB logic


Processor &

streaming DB logic

Netezza TwinFin Appliance

High-speed Loader/Unloader

Execution Engine

SQL Compiler

Query Plan

Optimize

Admin

SQL


Execution Engine



1

2

3

960

�

�

�


DBOSFront End




Processor &

streaming DB logic


Processor &

streaming DB logic


Processor &

streaming DB logic


Processor &

streaming DB logic



SQL Compiler

Query Plan

Optimize

Admin

Snippets

1 2 31 2 3

1 2 3

1 2 3

1 2 3

1 2 3

17

SQL

Percorso logico della query


Ti Piace vincere facile ? Il Field Programmable Gate Array (FPGA)

COSA SONO GLI FPGA

� Circuiti basati su velocissime portelogiche “sea of gates” riconfigurabili

� Elaborazione in Streaming moltoefficiente

� La riconfigurazione avvienespecificamente per ciascuna query.

� Anticipa fino al 90% del lavorosolitamente svolto dalla CPU per procurarsi I dati che servono in forma utilizzabile

� Una soluzione che è stata utilizzata giàda 2003 da Netezza.

Le performance ottenute con gli FPGA

abilitano:

migliori livelli di servizio

• sulle query ad alta I-O & cpu

• e con tempi molto prevedibili

richiedono minore lavoro e risorse

• niente Indici da definire e manutenere

• meno memoria cache necessaria

• non serve precalcolare le MQT o I Cubi


116 MB/Sec Compressi

* fattore di compressione 4

464 MB di Row Data/Secondo

The Netezza Secret Sauce

FPGA Core CPU Core

Uncompress ProjectRestrict,Visibility

Complex ∑Joins, Aggs, etc.

select DISTRICT,PRODUCTGRP,sum(REVENUE)

from SALES_DATAwhere MONTH = '20091201'and MARKET = 509123

and SPECIALTY = ‘DAIRY'

Slice of tableSALES_DATA

(compressed)

Slice of tableSALES_DATA

(compressed)

where MONTH = '20091201'and MARKET = 509123


where MONTH = '20091201'and MARKET = 509123


sum(REVENUE)sum(REVENUE)



19




1

2

3

96

�

�

�


DBOSFront End




Processor &

streaming DB logic


Processor &

streaming DB logic


Processor &

streaming DB logic


Processor &

streaming DB logic



SQL Compiler

Query Plan

Optimize

Admin

1 2 3

1 2 3

1 2 3

1 2 3

Consolidate

Execution Engine

TWF12 Gross Data Scan Speed

464 MB * 8 Core * 12 Blades = 44 GB /Sec

��1 TB in 23 sec.20

Percorso dei dati di risposta alla query


Agenda






21


Esperienza Beta Test

Ambiente*

HW• Modello IBM Z196 (definita una partizione con 2 processori)• IDAA 12 Blades

SW

• zOS versione 1.12 • DB2 versione 9

Ambiente*

HW• Modello IBM Z196 (definita una partizione con 2 processori)• IDAA 12 Blades

SW

• zOS versione 1.12 • DB2 versione 9

* DB2+IDAA pone come prerequisiti:• Hardware IBM z196 o z114 (ultima generazione)

• Sistema operativo zOS dalla V1.12 (anche 1.11 ma con opportune PTF)

• DB2 V9 o V10


Esperienza Beta Test

Case test 1

13 mesi di Dati = > 353 GB row data

92,8 GB su IDAA

Tasso di compressione 3,8

Tabelle dei Fatti:

Tpcl : 3.600 Milioni di righe

Tabelle delle Dimensioni:

Altre 12 Tabelle max 114 Mil Rec

Case test 1

13 mesi di Dati = > 353 GB row data

92,8 GB su IDAA


Tabelle dei Fatti:

Tpcl : 3.600 Milioni di righe



Case test 2

6 mesi di Dati = >2.867 GB row data

265 GB su IDAA


Tabelle dei Fatti:

T20 : 2.491 Milioni di righe




Case test 2

6 mesi di Dati = >2.867 GB row data

265 GB su IDAA


Tabelle dei Fatti:






Analisi su casi di test reali 1/4

Query sui dati di 4 mesi circa 1,4 miliardi di record sulla fact table

+ Tempo di calcolo puro circa 19 secondi

+ circa 16 secondi di Tempo di rete

24


Analisi su casi di test reali 2/4

Query sui dati di 1 mese circa 350 milioni di record sulla fact table

- Ricerca molto selettiva dati di un solo cliente


Analisi su casi di test reali 2/4 con DB2 Indicizzato

Dopo avere definito gli indici del DB2 sullo star schema

- L’ottimizzatore sa che per una Ricerca molto selettiva

- è più veloce con il DB2


Analisi su casi di test reali 2/4 con DB2 Indicizzato


Performance Outcomes alla fine dei test

15

46

66

26

31

41

28

DB2 + IDAA

(Sec)

5,89

4,59

0,82

1,70

8,52

13,08

0,39

NOTA DELL’AUTORE

La comparazione diretta con le tecnologie concorrenti di mercato NON rappresente un

benchmark in quanto i dati utilizzati per i test sono IDENTICI ma la parte di benchmark a sinistra risale

a fine 2009.

Tra le 3 tecnologie concorrenti NESSUNA riesce a prevalere per più del 50% delle volte


Performance Outcomes alla fine dei test

15

46

66

26

31

41

28

DB2 + IDAA

(Sec)

5,89

4,59

0,82

1,70

8,52

13,08

0,39

NOTA DELL’AUTORE

La comparazione diretta con le tecnologie concorrenti di mercato NON rappresente un

benchmark in quanto i dati utilizzati per i test sono IDENTICI ma la parte di benchmark a sinistra risale

a fine 2009.

Le tecnologie concorrenti arrivano a occupare 3 ordini di grandezza nella scala logaritmina dei tempi di risposta

DB2 e IDAA contengono la variabilità del response time in 1 ordine di grandezza abbatendo in 2 casi su 7 la bariera del secondo


Agenda






30


IBM DB2 Analytics Accelerator Product Components

10Gb

OSA-Express3

10 GbE

Primary

Backup

CLIENT

Data Studio Foundation

IDAA Plug-in

zEnterprise

Data Warehouse applicationDB2 for z/OS enabled for IBM

DB2 Analytics Accelerator

IBM DB2 Analytics Acelerator

BladeCenter

NetezzaTechnology

Users/

Applications

Private Service Network


Gestione dei dati nell’acceleratore IDAA

Alcuni principi:

1. Per potere essere consistenti ed efficienti DB2 e IDAA devono contenere sempre gli stessi dati

• Questo perchè l’organizzazione interna dei dati su DB2 e IDAA è profondamante antitetica

• E perchè ogni motore deve potere essere indipendente dall’altro in tutto

2. Il ruolo di Owner del dato, della sicurezza, Backup, Change ecc.. Rimane il DB2zOS,

3. l’IDAA è sempre mediato dal DB2 quindi NON può ricevere direttamente dati da nessun altro

Come Funziona:1. Tutte le funzioni di gestione dei dati e dei metadati su IDAA sono implementate con una serie

di stored procedure standard DB22. Le Stored procedure sono lanciabili in diversi modi, a seconda della necessità:

• Sono associate ai tasti disponibili sulla GUI IDAA Studio• Possono essere richiamate da JCL zOS• Possono essere integrate in altri strumenti come ETL e Scripting


Caricare e allineare I dati nell’acceleratore IDAA

Ciclo di vita dei dati su IDAA

1.Le tabelle si aggiungono all’acceleratore con la SP “ACCEL_ADD_TABLES” che riceve la lista

delle tabelle da portare sull’accelelratore

2.I dati si caricano con la SP “ACCEL_LOAD_TABLES” che riceve la lista delle tabelle o delle

partizioni che devono essere rinfrescate

3. Al momento è possibile rinfrescare su IDAA• Intere tabelle

• Singole partizione (solo Partizionamento per Range)

• Sono supportate la ADD e la ROTATE delle partizioni ma non la ALTER PARTITION RANGE

Processo di allineamento IDAA

1.Il processo di caricamento dati su IDAA è gestito come stored procedure e si basa sulla Unload DB2 2.Il lavoro viene parallelizzato su più tabelle e su più partizioni con un limite parametrico3.I dati si riversano dal DB2 a un buffer “USS pipe” che viene subito letto dall’IDAA.4.Tutti i nodi di lavoro di IDAA partecipano al caricamento dei dati con l’efficienza data dagli FPGA5.Il caricamento non sospende il servizio dell’acceleratore sulle query

SMP

server

Blade N – 8 core + 8 FPGA

Blade 1 – 8 core + 8 FPGA

Blade 2 – 8 core + 8 FPGA

.........

IDAA

T1 p1

USS pipeunloadT1 p2

USS pipeunload

T1 p3

USS pipeunload

zOS

10Gb


Componenti DB2 influenzate

� Nuovi Parametri di sistema e Special registers

� Nuove tabelle/colonne nel catalogo

� Criteri di Ottimizzazione e di routing

� Explain delle query con opzioni IDAA

� Nuovi Comandi DB2

� Nuove Stored Procedures specifiche di gestione IDAA


System parameters

� ACCEL

� Possible values: NO, AUTO, COMMAND

� QUERY_ACCELERATION

� Sets the initial value for the CURRENT QUERY ACCELERATION special register

� Possible values: NONE (default), ENABLE and ENABLE WITH FAILBACK

Special register CURRENT QUERY ACCELERATION

� Can be set implicitly by inheriting the value of the system parameter, or

� Explicitly by SET CURRENT QUERY ACCELERATION

Value Description

NONE No query is routed to the accelerator

ENABLEA query is routed to the accelerator if it satisfies the acceleration criteria.If there is an accelerator failure while running the query, or the accelerator returns an error, DB2 will return

a negative SQL code to the application.

ENABLE WITH FAILBACK

A query is routed to the accelerator if it satisfies the acceleration criteria.Under certain conditions the query will run on DB2 after it fails in the accelerator. In particular, any negative

SQLCODE will cause a failback to DB2 during PREPARE or first OPEN. No failback is possible after a successful OPEN of a query.


Una query viene indirizzata all’IDAA se:

� Arriva come SQL Dinamico

� Tutte le tabelle referenziate dalla Query devono essere copiate nell’acceleratore

� L’SQL non deve contenere le istruzioni unsupported (vedi pagina seguente)

� La query NON contiene istruzioni di scrittura (es INSERT INTO W. SELECTW)

� Il cursore associato non è definito “scrollable” o “rowset”

� Tutta la query è gestita come una unità atomica e quindi non scindibile:

� la query girerà per intero sul DB2 o sull’accelleratore

� I singoli query blocks non sono considerati accellerabili

� Non viene supportato il protocollo privato (già deprecato da DB2 V9)

�E soprattutto:

l’esecuzione della query sull’IDAA deve essere ritenuta

conveniente rispetto alla esecuzione sul DB2

Questa decisione viene assunta nell’ottimizzatore


limitazioni: SQL non accellerabile

� Non sono ammessi alcuni „data types“ come LOBs, ROWID, XML.

– Le colonne di questi tipi non verranno portate in IDAA

– Le query che le utilizzano non sono accellerate, le atre si

� Non tutte le funzioni del DB2 sono supportate, sono escluse

� Le funzioni trigonometriche come SIN, COS, TAN.

� Le funzioni user defined

� Le funzioni avanzate sulle stringhe come LOCATE, LEFT, OVERLAY.

� Alcune funzionalità tipicamente „OLAP“ tipo RANK, ROLLUP, CUBE


Dentro l’Ottimizzatore 1/2

Per scegliere a quale percorso instradare la Query l’ottimizzatore deve basarsi:

� sulla query,

� sulla base dati inferita,

Con I dati contenuti nelle tabelle statistiche del catalogo DB2 si posssono avere o stimare:

� dimensione delle tabelle in input

� quantità di dati da elaborare

� dimensione attesa del risultato

La regola decisionale è di tipo “euristico”, ossia è una regola che a fronte di un problema

molto complesso deve necessariamente essere veloce da calcolare

(1) http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=/com.ibm.db2z10.doc.perf/src/tpc/db2z_profiles.htm


Dentro l’Ottimizzatore 2/2

La regola euristica prevede che una serie di casi rimangano di pertinenzadel DB2 “core engine” piuttosto che nell’IDAA,

Ad esempio rimangono al DB2 le query:

� Stimate come molto selettive (tipo OLTP) ad esempio

� Accessi per campi chiave molto selettivi

� Accesso a campioni di dati

� Query completamente prive di funzioni di aggregazione o selezione WHERE, GROUP BY, ORDER BY

� Nei casi in cui tutte le tabelle referenziate dalla query siano definite di taglia“small”

� Il concetto di “small” viene riferito a un numero minimo di pagine in cui rientra la

tabella, normalmente impostato a 50

� Si tratta di un parametro modificabile, il valore -1 fa saltare questo controllo

� Nei casi in cui si stimi che la query produca un risultato potenzialmente“large” allora la query viene lasciata al db2

� Anche il concetto di “Large” è affidato a un parametro legato al numero di righe

� Si tratta di un parametro modificabile, il valore -1 fa saltare questo controllo


Agenda






40


Quick Workload Test

1

CustomerDatabase

CustomerDatabase

Documentationand REXX procedure

Documentationand REXX procedure

Data package(mainly unload

data sets)

Data package(mainly unload

data sets)IBM lab

Database

IBM labDatabase

Pre-process andload

Pre-process andload

2 3

Quick Workload Test Tool

Quick Workload Test Tool

Report

Assessment

� Customer

� Collecting information from dynamic statement cache, supported by step-by-step instruction and REXX script (small effort for customer)

� Uploading compressed file (up to some MB) to IBM FTP server

� IBM / Center of Excellence

� Importing data into local database

� Quick analysis based on known DB2 Analytics Accelerator capabilities

Report for a first assessment:

� Acceleration potential for

� Queries

� Estimated time

� CP cost

Report for a first assessment:

� Acceleration potential for

� Queries

� Estimated time

� CP cost

41


approfondimenti

Workload Analysis

- Step 1: Activate Dynamic Statement Cache

- Step 2: Activate relevant IFCIDs 316, 317, 318

- Step 3: Create objects for collecting workload information

- Step 4: Collect workload information from Dynamic Statement Cache (EXPLAIN STMT CACHE) --> popola la tabella DSN_STATEMENT_CACHE_TABLE

- Step 5: Explain degli Stmt scaricati nella tabella DSN_STATEMENT_CACHE_TABLE

- Step 6: Unload workload, explain and catalog information su data set

- Step 7: Prepare tersed datasets for sending

- Step 8: Send Unload files to IBM Boeblingen DWHz CoE

42


Team Tecnico IDAA

Mario Biffi [email protected]

Enrico Caraffi [email protected]

Massimiliano Castellini [email protected]

Paola Zornig [email protected]

Team Commerciale Information Management su zOS

Angela Ascione (Centro-Sud) [email protected]

Elisabetta Curci (Nord) [email protected]

contatti - per i prossimi passi

Se sai già come DB2 e IDAA possono portare valore alla tua azienda..

Spiegacelo!

strada facendo abbiamo conosciuto altri clienti che hanno avuto idee interessanti

Se non ne sei sicuro?

Noi alcune idee le porta IBM, il valore sicuramente esite,

e vorremmo provare scoprirlo assieme.

Iniziando dalla Workload Analysis che si può fare anche sul DB2 in V8


IDAA Preserves DB2 Key Value Propositions

�DB2 continues to own data (both OLTP and DW)

� Access to data (authorization, privileges, W)

� Data consistency and integrity (backup, recovery, W)

� Enables extending System z QoS characteristics to BI/DW data as well

�Applications access data (both OLTP and DW) only through DB2

� DB2 controls whether to execute query in DB2 mainline or route to IDAA

� DB2 returns results directly to the calling application

� Enables mixed workloads and selection of optimal access path (within DB2 mainline or IDAA) depending on access pattern

�IDAA continues to be implemented as DB2 internal component

� DB2 provides key IDAA status and performance indicators as well as typical administration tasks by standard DB2 interfaces and means

� No direct access (log-on) to IDAA

� Enables operational cost reduction through skills, tools and processes consolidation


IDAA Administrative Stored Procedures

ACCEL_ADD_ACCELERATOR Pairing an accelerator to a DB2 subsystem

ACCEL_TEST_CONNECTION Check of the connectivity from DB2 procedures to the accelerator

ACCEL_REMOVE_ACCELERATOR Removing an accelerator from a DB2 subsystem and cleanup resources on accelerator

ACCEL_UPDATE_CREDENTIALS Renewing the credentials (authentication token) in the accelerator

ACCEL_ADD_TABLES Add a set of tables to the accelerator

ACCEL_ALTER_TABLES Alter table definitions for a set of tables on the accelerator (only distribution and organizing keys)

ACCEL_REMOVE_TABLES Remove a set of tables from the accelerator

ACCEL_GET_TABLES_INFO List set of tables on the accelerator together with detail information

ACCEL_LOAD_TABLES Load data from DB2 into a set of tables on the accelerator

ACCEL_SET_TABLES_ACCELERATION Enable or disable a set of tables for query off-loading

ACCEL_CONTROL_ACCELERATOR Controlling the accelerator tracing, collecting trace and detail of the accelerator (software level etc.)

ACCEL_UPDATE_SOFTWAREUpdate software on the accelerator (transfer versioned software packages or apply an already transferred

package, new: also list software both on z/OS and accelerator side)

ACCEL_GET_QUERY_DETAILS Retrieve statement text and query plan for a running or completed Netezza query

ACCEL_GET_QUERY_EXPLAIN Generate and retrieve Netezza explain output for a query explained by DB2

ACCEL_GET_QUERIES Retrieve active and/or history query information from accelerator


EXPLAIN

�DB2 EXPLAIN function is enhanced to provide basic information about accelerator usage

� Whether query qualifies for acceleration and, if not, why

� The access path details associated with the query execution by Netezza are provided

independently of DB2 EXPLAIN by the IDAA Studio.

�For each query (irrespective of the number of query blocks) a row is inserted in the following tables:

� in both PLAN_TABLE and DSN_QUERYINFO_TABLE, if the query is re-routed

� PLAN_TABLE's ACCESSTYPE column is set to a value of 'A'

� DSN_QUERYINFO_TABLE's QI_DATA column shows the converted query text

� in DSN_QUERYINFO_TABLE only, if the query is not re-routed

� REASON_CODE and QI_DATA columns provide details

�Note that the EXPLAIN tables can be populated with above described information even if there is no accelerator connected to DB2

� Specifying EXPLAINONLY on START ACCEL command does not establish any communications with an actual accelerator, but enables DB2 to consider its presence in the access path selection process


Column Name Column Contents

QUERYNOThe statement identification, the same value as in PLAN_TABLE.

Use it with EXPLAIN_TIME to correlate DSN_QUERYINFO_TABLE and PLAN_TABLE

QBLOCKNO

QINAME1 If REASON_CODE = 0, the name of the accelerator

QINAME2 If REASON_CODE = 0, the location of the accelerator

APPLNAME The name of the application plan for the row. Applies only to embedded EXPLAIN statements that are executed from a plan or to statements that are explained when binding a plan. A blank indicates that the column is not applicable.

PROGNAMEThe name of the program or package containing the statement being explained. Applies only to embedded EXPLAIN statements and to statements explained as the result of binding a plan or

package. A blank indicates that the column is not applicable.

VERSIONThe version identifier for the package. Applies only to an embedded EXPLAIN statement executed from a package or to a statement that is explained when binding a package. A blank indicates

that the column is not applicable.

COLLIDThe collection ID for the package. Applies only to an embedded EXPLAIN statement that is executed from a package or to a statement that is explained when binding a package. A blank indicates

that the column is not applicable.

GROUP_MEMBER The member name of the DB2 that executed EXPLAIN. The column is blank for non-data sharing.

SECTNOI The section number of the statement.

SEQNO

EXPLAIN_TIMEThe time at which the statement is processed.

This time is the same as the BIND_TIME column in PLAN_TABLE.

TYPE'A' identifies a query that is considered for acceleration.

REASON_CODE identifies if the query qualifies for acceleration or not.

REASON_CODEIf 0, the query qualifies for acceleration.Otherwise, the query cannot be accelerated. More details on the next chart.

QI_DATA If REASON_CODE = 0, the text of the converted SQL statement (sent to IDAA).Otherwise, the description of the reason for not qualifying for acceleration

SERVICE_INFO IBM internal use only

QB_INFO_ROWID IBM internal use only

DSN_QUERYINFO_TABLE


Value Description

0 Query qualifies for acceleration

1 No active accelerator was found when EXPLAIN was executed.

2 The special register CURRENT QUERY ACCELERATION is set to NONE.

3 The query is a DB2 short running query or re-routing to the accelerator is not considered advantageous.

4 The query is not read-only

5 The query is running under the private protocol.

6 The cursor is defined as scrollable or rowset cursor.

7 The query refers to multiple encoding schemes.

8 The query FROM clause specifies a data-change-table-reference.

9 The query contains a correlated table expression.

10 The query contains a common table expression reference.

11The query contains an unsupported expression.

QI_DATA contains the expression text.

12The query references table table-name that is either not defined in accelerator, or the table is defined, but is not enabled for query

re-routing.

13 The accelerator accelerator-name containing the tables of the query is not started.

14 The column column-name referenced in the query is altered in DB2 after the data is loaded in the accelerator.

900 through 999 IBM internal use


Connectivity Options

Multiple DB2 systems can connect to a single IDAA

A single DB2 system can connect to multiple IDAAs

DB2 IDAA

• residing in the same LPAR• residing in different LPARs

• residing in different CECs

• being independent (non-data sharing)

• belonging to the same data sharing group

• belonging to different data sharing groups

Multiple DB2 systems can connect to multiple IDAAs

DB2

DB2 DB2

IDAA

IDAA

DB2IDAA IDAA

Full flexibility for DB2 systems:

Better utilization of IDAA resourcesBetter utilization of IDAA resources

ScalabilityScalability

High availabilityHigh availability

ibm db2 analytics accelerator for z/os (idaa)

Documents