S23 Analyse des performances DB2 for i : outils et stratégies d'indexation

Transcription

1 Evénement "Modernisation IBM i" des 19 et 20 mai 2015 IBM Client Center Paris, Bois-Colombes S23 Analyse des performances DB2 for i : outils et stratégies d'indexation Mercredi 20 mai 13h30-15h00 Intervenant Eric Saglier (eric.saglier@six-axe.fr)

2 Plan de la présentation S23 1. Technologie d indexation de DB2 for i 2. Création d index 3. Les index et l optimisation des requêtes 4. Stratégie d indexation 5. Les outils 2

3 Technologie d indexation de DB2 for i Deux types d index sont supportés par DB2 for i Les index de type Radix Les index de type EVI (Encoded Vector Index) Chaque type présente des spécificités et des avantages Ces deux types de technologies se complètent parfaitement Ces deux types d index sont utilisés aussi bien pour la mise à jour des statistiques que pour l exécution des requêtes Les index sont utilisés de manière «Scanner» ou/et «Prober» 3

4 Lecture des index Lecture «Scanned» Lecture séquentielle de l index Balayage de tous les postes d'index à la recherche des postes correspondants à la sélection Lecture «Probed» Fourniture d une clé Parcours (rapide) dans l'arbre binaire Accès au RRN (Relative Record Number) 4

5 Scan/Probe Existence d un index sur les colonnes (ITEM_NO, COLOR, SIZE) WHERE COLOR = NOIR and ITEM_NO = 003 WHERE SIZE = MEDIUM WHERE ITEM_NO =001 AND SIZE = LARGE Accès Probe (Positionnement sur clé) Clé(s) principale(s) + n clés contiguës Accès Scan (Test d index) N importe quel ordre de clés ITEM_NO COLOR SIZE 001 BLEU LARGE 002 ROUGE SMALL 003 NOIR SMALL 004 VERT MEDIUM 5

6 Index de type Radix 1/2 Les index de type Radix utilisent une structure de type arbre binaire Les valeurs de clés sont compressées logiquement Les données communes sont stockées une seule fois Les données uniques sont stockées seules Existence d un algorithme propre de recherche au sein d un arbre binaire Maintenance L arbre est automatiquement mis à jour en fonction des opérations réalisées au travers du DML (Data Manipulation Language), afin de maintenir une structure de données efficace 6

7 Index de type Radix 2/2 Root Code State 001 ARKSANSAS Test Nœud MISS 002 MISSISSIPI 003 MISSOURI AR IOWA 004 ISSISSIPI 002 OURI IOWA 005 ARIZONA IZONA 005 KANSAS 001 Avantages Accès très rapide à une seule valeur de clé Accès rapide à un petit ensemble de clés (peu de cardinalité) Tri demandé Désavantages Lignes récupérées dans l ordre des valeurs de clés (pas de l ordre physique) équivalent à des I/O random Aucune manière de prédire quelles seront les pages suivantes pour des valeurs de clés importantes 7

8 Index de type EVI Index conçu afin de délivrer des accès rapides dans les environnements de type «report analytique» Technologie issue de travaux de recherche IBM Permet de produire dynamiquement des listes de RRN Accès très rapide aux statistiques afin de faciliter les décisions de l Optimiseur Ce n est pas une structure de type «arbre» Ne peut être créé que par l intermédiaire d une interface SQL, d IBM Navigator for i ou de System i Navigator CREATE ENCODED VECTOR INDEX Mabib.Ixnom ON Mabib.Tablenom (Key1, Key2, ) INCLUDE (SUM(Col2)) (Nouveauté 7.1) 8

9 Index de type EVI La table des symboles contient des informations pour chaque valeur distincte de clé Chaque clé se voit affecter un code unique Le code est sur 1,2 ou 4 octets (en fonction du nombre de valeurs distinctes) Nouveauté en 7.1 : possibilité de spécifier AVG, COUNT, COUNT_BIG, SUM, STDDEV, STDDEV_SAMP, VARIANCE, VARIANCE_SAMP En lieu et place d un tableau de bits pour chaque valeur, utilisation d un tableau de vecteurs 9

10 Utilisation d un EVI Si l optimiseur utilise un EVI A partir de la table des vecteurs et pour les valeurs répondant aux critères de sélection, le système bâtira une liste de RRN en positionnant un bit à *ON ou *OFF 10

11 Utilisation d un EVI AND EVI et utilisation d un AND Select * from samples.employee where WORKDEPT in ('B01', 'D11', 'C01') AND JOB = 'MANAGER' 11

12 Utilisation d un EVI OR EVI et utilisation d un OR Select * from SAMPLES.EMPLOYEE where WORKDEPT = 'B01' OR JOB = 'MANAGER' 12

13 Utilisation d un EVI et fonctions de colonnes EVI et les fonctions de colonnes (V7) CREATE ENCODED VECTOR INDEX SAMPLES.EVI_SUM ON SAMPLES.EMPLOYEE ( WORKDEPT ) INCLUDE ( COUNT ( * ), SUM ( SALARY ), SUM ( BONUS ) ) SELECT COUNT(*) FROM SAMPLES.EMPLOYEE WHERE WORKDEPT = C01 SELECT COUNT(distinct WORKDEPT) FROM SAMPLES.EMPLOYEE SELECT WORDEPT, SUM(BONUS), SUM(SALARY) FROM SAMPLES.EMPLOYEE Key Value Code Count Sum(Salary) Sum(bonus) A , ,00 B , , E , ,00 13

14 Index avec clés dérivées Ce type d index est apparu en V6R1 Permet de faire apparaitre des expressions dans les colonnes clés Utilisé dans le cas de recherche en fonction de la casse Données extraites à partir de chaine de caractères ( SUBSTR, YEAR, MONTH, ) Colonnes de groupage dérivées (GROUP BY YEAR(), ) Résultats de calculs ((PU + HT), (QUANTITE * PU),..) CREATE INDEX LASTNAMEUPPER ON SAMPLES.EMPLOYEE (UPPER(LASTNAME)) as ULASTNAME ASC) CREATE ENCODED VECTOR INDEX YEARQTR ON SAMPLES.EMPLOYEE (YEAR(BIRTHDATE) as BIRTHYEAR ASC, QUARTER(BIRTHDATE) as BIRTHQ) CREATE INDEX TOTALBONUS ON SAMPLES.EMPLOYEE ((SALARY + BONUS) * 13 as TOTALANNUEL) 14

15 Index avec sélection Ce type d index apparait en V6R1 et permet de remplacer les fichiers logiques A partir de la V7R1, ce type d index est utilisable par l optimiseur CREATE INDEX SAMPLES.WORKDEPT_SELECT ON SAMPLES.EMPLOYEE (WORKDEPT ASC) WHERE WORDEPT in ('D11', 'E11') 15

16 Création d index Via SQL CREATE INDEX Via Sytem i Navigator 16

17 Création d index 17

18 Création d index 18

19 Choisir le bon type d index Le choix du type d index est fonction de la cardinalité des occurrences pour la valeur des colonnes de zones clés Haute cardinalité : nombre élevé de valeurs distinctes Faible cardinalité : nombre faible de valeurs distinctes. En général Un index de type «Radix» est le meilleur choix si la cardinalité est élevée et que le nombre d occurrences à traiter est faible Un index de type «EVI» est le meilleur choix afin d accéder à un lot d occurrences avec de faibles cardinalités 19

20 DB2 for i et l usage des index DB2 for i s appuie sur les index afin de fournir les méthodes et les statistiques permettant de fournir au plus vite les résultats Au cours du processus d optimisation, DB2 for i examine tous les index pertinents afin de réaliser la requête Soit la requête suivante SELECT COL1 where COL2 = XXX order by COL3 Un index comportant COL1 est sans intérêt pout l optimiseur (pas de statistiques ou de méthode d exécution) Un index comportant COL2 ou COL3 en clé principale pourra être envisagé afin d activer un usage de type «Probe» 20

21 Les différentes méthodes d accès aux données La méthode d'accès la plus rapide pour une table variera en fonction de la sélectivité et du nombre d occurrences par valeur distincte Sur la base des 101 département, la répartition dans la table des clients ne sera pas de 1/101 par département C est le rôle des statistiques que de fournir ces informations 21

22 Rôles des statistiques Plus la sélectivité est importante, plus la présence d un index est primordiale L'objectif de l'optimiseur est de choisir une mise en œuvre éliminant les lignes qui ne sont pas intéressantes ou pas nécessaires. Pour ce faire : L optimiseur DB2 utilise les informations statistiques des index afin de «comprendre les données» stockées dans les tables sousjacentes Cette compréhension des données permet à l'optimiseur trouver la méthode d'accès aux données la plus efficace Les index Radix et les EVI contiennent des informations sur le nombre de valeurs distinctes dans une colonne, ainsi que la distribution des dites valeurs 22 Réglage via la valeur système QDBFSTCCOL (*ALL, *SYSTEM, *USER, *NONE)

23 Détail des statistiques Le détail des statistiques est accessible via System i Navigator 23

24 Méthode d accès aux données En fonction de la sélectivité, DB2 pourra mettre en œuvre : Un index «Probe» Un index «Scan» Un Table «Scan» 24

25 Analyse d une requête SQL inefficace Il faut rechercher et éliminer : Les analyses complètes de table (Full table «Scan») Les analyses complètes d index (Full index «Scan») Les constructions d index temporaires L usage en V6R1 du moteur CQE 25

26 Requête SQL La vie d une requête SQL 26

27 Optimisation DB2 et outils d analyse Outil d analyse SQE Plan Cache Requête SQL Optimisation SQE Plan Cache Snapshot Visual Explain CQE/SQE Performance Moniteur 27

28 Optimisation DB2 Lors de l exécution d une requête, l optimiseur réalise les opérations suivantes : Rassemblement des informations sur les métadonnées et les statistiques afin d établir le coût d exécution Statistiques de sélectivité Détermination des index disponibles pour chiffrer les coûts Tri des index en fonction de leur pertinence Détermination des attributs d exécution pouvant affecter le coût Génération d un coût par défaut Permet d établir un plan d'accès associé avec le plan par défaut Et ce pour chaque index 28 Recueil des renseignements nécessaires spécifiques à l'index Construction d un plan d'accès basé sur cet index Chiffrage du coût de l'utilisation de cet index avec le plan d'accès Comparaison du coût obtenu avec le coût le plus bas trouvé précédemment Répétition de cette opération afin de trouver le coût le plus bas

29 Outil de conseil à la construction des index L optimiseur va enregistrer les index conseillés dans un fichier. Fichier SYSIXADV de QSYS2 Ces conseils sont établis aussi bien pour le moteur CQE que pour le moteur SQE CQE Conseils basiques (Table scan et sélection uniquement) Index «Radix» uniquement Index temporaires Visual Explain est susceptible de proposer de meilleurs index SQE Conseils évolués Index de type «Radix» et «EVI» Basés sur la requête complète Plusieurs index proposés pour la même requête Quelques limitations 29

30 Outil de conseil à la construction des index Fournit des informations sur Sélections locales Jonctions Group by Order by Propose des index sur Sélection en égalité, suivi par inégalité («Probe») Conseil limité avec des OR sur des colonnes différentes Pas d index dérivé Pas d EVI avec des fonctions d agrégations Les conseils sont nombreux mais pas obligatoires 30

31 Visualisation Index Advisor 31

32 Visualisation index Advisor Clic Bouton droit permet d appeler la boite de dialogue permettant la création d index, avec le type d index et les colonnes clés renseignées 32

33 Usage des index Les informations d utilisation des index présents sont accessibles : Via System i Navigator Via IBM Navigator for i Au sein du catalogue DB2 33

34 Visualisation d informations index 34

35 Visualisation d informations index Permet d accéder aux informations suivantes : 35

36 Information sur les index Permet en particulier d analyser l utilisation de celui-ci 36

37 Le catalogue Les vues suivantes contiennent les informations visualisées au travers de System i Navigator Vue Description SYSINDEXSTAT Une ligne par index, fournit des informations identiques à System i Navigator SYSPATITIONINDEXES Une ligne par index. A utiliser afin d obtenir des informations complémentaires sur les index SYSTABLEINDEXSTAT Une ligne par index. A utiliser afin d obtenir des informations complémentaires sur les index et les membres sous jacents 37

38 L indexation autonome L optimiseur peut demander à DB2 de créer un ou plusieurs index temporaires, complets ou dérivés Les index temporaires (SQE) sont maintenus mais détruits à l IPL CQE Les index temporaires ne sont ni partageables, ni réutilisables Gains potentiels à les créer. SQE Les index temporaires sont réutilisables et partageables Leur création est dépendante : Du nombre d exécutions de la requête Des conseils propres à l optimiseur Les index temporaires ont une maintenance de chemins d accès «Delay» quand les curseurs associés sont fermés 38

39 Plan Cache Le moteur SQE stocke le plan d exécution de toutes les requêtes au sein d un cache unique Chaque plan contient des métadonnées ainsi que des informations d exécution Le Plan cache est considéré comme un objet temporaire Le Plan Cache est localisé dans le pool mémoire *BASE Le Plan Cache permet de repartir d un plan d accès déjà établi et ce pour une requête donnée 39

40 Plan Cache Informations générales sur le plan cache Toujours actif Mise en œuvre automatique Sa taille peut être fixée Si la taille est atteinte => bouclage N est utilisé que par le moteur SQE Interface graphique via System i Navigator Accès Filtres Analyse par heure, Job, instructions Explicitation via Visual Explain Données volatiles Les informations du plan cache sont vivantes Le plan cache est remis à blanc à chaque l IPL 40

41 Plan Cache Propriétés Les propriétés du Plan Cache sont visualisables via System i Navigator 41

42 Plan Cache Propriétés Les instructions du Plan Cache sont visualisables via System i Navigator Click bouton droit sur une instruction pour lancer Visual Explain 42

43 Visual Explain Visual Explain permet d afficher une représentation graphique du plan de la requête. Il permet de : Visualiser les objets ainsi que les structures de données Visualiser les méthodes et stratégies mises en œuvre Présenter les informations associées à l environnement d exécution Fournir des conseils sur les index à construire Fournir des conseil sur les statistiques à collecter Cet outil est accessible au travers de l interface System i Navigator Il permet d analyser Le Plan Cache SQE Les Snapshots du Plan Cache Les moniteurs de performances base de données Le détail d un job 43

44 Visual Explain 44

45 Visual Explain Suivi temps réel d une exécution 1/2 45

46 Visual Explain Suivi temps réel d une exécution 2/2 46

47 SQL Détail d un job Clic bouton pour lancer Visual Explain 47

48 Méthodologie d indexation Suivant les paramètres de la requête, l optimiseur mettra en en œuvre les aspects suivants Si présence de Sélection Table «Scan» Table «Probe» Index «Scan» Index «Probe» Si présence de Jonction Nested loop join with index (Jointure en boucle avec index) Nested loop join with hashing (Jointure en boucle avec hachage) Nested loop join with sort list (Jointure en boucle avec liste de tri) Si présence de Group by Grouping avec Index (Agrégation) Grouping avec hachage Si présence de Order by Index Tri 48

49 Stratégie d indexation Deux approches pour créer les index : Une approche proactive Une approche réactive L approche proactive consiste à bâtir les index sur la base du modèle de données (MCD) Mise en œuvre contraintes de clés Primaires, Uniques et Etrangères. Communément, les colonnes utilisées dans les sélections ainsi que les colonnes dépendantes, en relation, en corrélation. Communément, les colonnes utilisées dans les jonctions. Communément, les colonnes utilisées dans le groupage 49

50 Stratégie d indexation Méthode réactive. L'objectif d'une stratégie d'indexation est de donner à l'optimiseur de requêtes les deux éléments suivants : Informations sur les données contenues dans les table telles que : Le nombre de valeurs distinctes, La répartition des valeurs de données, Le nombre moyen de valeurs en double. Choix concernant les méthodes à utiliser pour traiter la requête. Le choix dépend du résultat souhaité (Batch, Interactif, Optimize for all rows, ) 50

51 Stratégie d indexation basique Index de type «RADIX» Sélection de colonnes minimum Jonction de colonnes Sélection de colonnes + colonnes de jonction Sélection de colonnes + colonnes de groupage Sélection de colonnes + colonnes de tri Index de type «EVI» Sélection local avec AND / OR Jonction de colonnes Fonctions (Distinct, Count, SUM,..) Privilégier la sélectivité, mettre les colonnes en égalité en premier 51

52 Stratégie d indexation Soit la requête suivante : Select b.col1, b.col2, a.col1 From table1 a inner join table2 b on (a.join_col = b.join_col) (Jonction) Where b.col3 = quelques valeurs (Sélection) and b.col2 = 9999 Group by c.col1, b.col2, a.col1 Order by b.col1 Avec une requête de ce type les règles sont : 2 index Radix sur les colonnes de jonction (a.join_col et b.join_col) Sélection 2 index Radix sur les colonnes de sélection (b.col3 et b.col2) dès lors quelles sont utilisées dans d autres requêtes comme critères de sélection. Ou bâtir deux index EVI sur les colonnes b.col3 et b.col2 dès lors que les colonnes de sélection ne sont pas uniques et que le nombre d occurrences pour chacune est relativement faible. 52

53 Index de type Radix Dans un index l ordre des colonnes est important Classer les colonnes d égalité en premier (permet d activer la sélectivité) Si tous les prédicats utilisés sont en égalité Colonnes de sélection + colonnes de jonction Colonnes de sélection + colonnes de groupage Colonnes de sélection + colonnes de tri Mettre la colonne à sélectivité la plus élevée en premier Select col1, col2, col3 from table where col4 = 2014 and col5 = 3 and col6 = T order by col1, col2 L index à créer comportera les colonnes de sélection (col4, col5, col6) suivies des colonnes de tri col1 et col2 L ordre des colonnes de sélection devra être choisi en fonction de la sélectivité 53

54 Index parfait de type Radix/Index Only Access IOA Index Parfait : inclure dans l index les colonnes souhaitées Select nom, srv from employes order by nom Index sur nom Création d un index IOA «Only Access» CREATE INDEX ESALIB.INDEX_PARFAIT ON ESALIB.EMPLOYES (SRV ASC, NOM ASC ) Récupération de l ensemble des informations au sein de l index => plus besoin de test de table 54

55 Illustration : SELECT partkey, shipmode FROM item_fact WHERE orderkey=1 ORDER BY partkey Index sur orderkey 55

56 Illustration mise en œuvre index parfait SELECT partkey, shipmode FROM item_fact WHERE orderkey=1 ORDER BY partkey CREATE INDEX DB2IPFR/INDEX_PARFAIT DB2IPFR/ITEM_FACT ( ORDERKEY ASC, PARTKEY ASC ) Durée estimée Sans index Index de base Index parfait 56 : ms : 25 ms : 19 ms

57 Illustration mise en œuvre index parfait Only Access SELECT partkey, shipmode FROM item_fact WHERE orderkey=1 ORDER BY partkey CREATE INDEX DB2IPFR.INDEX_IOA ON DB2IPFR.ITEM_FACT (ORDERKEY ASC, PARTKEY ASC, SHIPMODE ASC) Durée estimée 57 Sans index Index de base Index parfait Index parfait Only access : ms : 25 ms : 19 ms : 1 ms

58 Exemples Requête 1 SELECT * FROM TABLE1 A WHERE A.COLOR IN ( BLUE, GREEN, RED ) CREATE INDEX TABLE1_INDEX1 ON TABLE1 (COLOR) Ou CREATE ENCODED VECTOR INDEX TABLE1_EVI1 ON TABLE1 (COLOR) Anticipe un index probe ou table probe avec bitmap dynamic Requête 2 SELECT * FROM TABLE1 A WHERE A.COLOR IN ( BLUE, GREEN, RED ) AND A.SIZE IN ( LARGE, X-LARGE ) CREATE INDEX TABLE1_INDEX1 ON TABLE1 (COLOR, SIZE) Ou CREATE ENCODED VECTOR INDEX TABLE1_EVI1 ON TABLE1 (COLOR) CREATE ENCODED VECTOR INDEX TABLE1_EVI2 ON TABLE1 (SIZE) Anticipe un index probe ou table probe avec bitmap dynamic 58

59 Exemples Requête 3 SELECT * FROM TABLE1 A WHERE A.COLOR IN ( BLUE, GREEN, RED ) AND A.SIZE IN ( LARGE, X-LARGE ) AND A.STYLE = ADULT MENS T-SHIRT CREATE INDEX TABLE1_INDEX1 ON TABLE1 (COLOR, SIZE, STYLE) Ou CREATE ENCODED VECTOR INDEX TABLE1_EVI1 ON TABLE1 (COLOR) CREATE ENCODED VECTOR INDEX TABLE1_EVI2 ON TABLE1 (SIZE) CREATE ENCODED VECTOR INDEX TABLE1_EVI3 ON TABLE1 (STYLE) Anticipe un index probe ou table probe avec bitmap dynamic 59

60 Exemples Requête 4 SELECT * FROM TABLE1 A WHERE A.COLOR IN ( BLUE, GREEN, RED ) AND A.SIZE IN ( LARGE, X-LARGE ) AND A.STYLE = ADULT MENS TSHIRT AND A.INVENTORY > 100 CREATE INDEX TABLE1_INDEX1 ON TABLE1 (COLOR, SIZE, STYLE, INVENTORY) Ou CREATE ENCODED VECTOR INDEX TABLE1_EVI1 ON TABLE1 (COLOR) CREATE ENCODED VECTOR INDEX TABLE1_EVI2 ON TABLE1 (SIZE) CREATE ENCODED VECTOR INDEX TABLE1_EVI3 ON TABLE1 (STYLE) CREATE ENCODED VECTOR INDEX TABLE1_EVI4 ON TABLE1 (INVENTORY) Anticipe un index probe ou table probe avec bitmap dynamic 60

61 Exemples Requête 5 SELECT * FROM TABLE1 A, TABLE2 B WHERE A.KEY = B.KEY AND A.COLOR IN ( BLUE, GREEN, RED ) AND A.SIZE IN ( LARGE, XLARGE ) AND A.STYLE = ADULT MENS T-SHIRT AND A.INVENTORY > 100 CREATE INDEX TABLE1_INDEX1 ON TABLE1 (COLOR, SIZE, STYLE, KEY, INVENTORY) CREATE INDEX TABLE2_INDEX1 ON TABLE2 (KEY) Et/Ou CREATE ENCODED VECTOR INDEX TABLE1_EVI1 ON TABLE1 (COLOR) CREATE ENCODED VECTOR INDEX TABLE1_EVI2 ON TABLE1 (SIZE) CREATE ENCODED VECTOR INDEX TABLE1_EVI3 ON TABLE1 (STYLE) CREATE ENCODED VECTOR INDEX TABLE1_EVI4 ON TABLE1 (INVENTORY) Anticipe un index probe ou table probe avec bitmap dynamic et jointure de boucle imbriquée avec index 61

62 Exemples Requête 6 SELECT A.STORE, A.STYLE, A.SIZE, A.COLOR SUM(A.QUANTITY_SOLD) FROM TABLE1 A, TABLE2 B WHERE A.KEY = B.KEY AND A.COLOR IN ( BLUE, GREEN, RED ) AND A.SIZE IN ( LARGE, X-LARGE ) AND A.STYLE = ADULT MENS T-SHIRT GROUP BY A.STORE, A.STYLE, A.SIZE, A.COLOR CREATE INDEX TABLE1_INDEX1 ON TABLE1 (COLOR, SIZE, STYLE, KEY) CREATE INDEX TABLE1_INDEX2 ON TABLE1 (STORE, STYLE, SIZE, COLOR) CREATE INDEX TABLE2_INDEX1 ON TABLE2 (KEY) Et/ou CREATE ENCODED VECTOR INDEX TABLE1_EVI1 ON TABLE1 (COLOR) CREATE ENCODED VECTOR INDEX TABLE1_EVI2 ON TABLE1 (SIZE) CREATE ENCODED VECTOR INDEX TABLE1_EVI3 ON TABLE1 (STYLE) Anticipe un index probe ou table probe avec bitmap dynamic et jointure de boucle imbriquée avec index 62

63 Exemples Requête 7 SELECT A.COL3, A.COL4, B.COL2, C.COL6, C.COL7 FROM TABLE1 A, TABLE2 B, TABLE3 C WHERE A.KEY_COL1 = B.KEY_COL1 AND A.KEY_COL2 = C.KEY_COL2 AND A.COLOR IN ( BLUE, GREEN, RED ) CREATE INDEX TABLE1_INDEX1 ON TABLE1 (COLOR, KEY_COL1) CREATE INDEX TABLE1_INDEX2 ON TABLE1 (COLOR, KEY_COL2) CREATE INDEX TABLE2_INDEX1 ON TABLE2 (KEY_COL1) CREATE INDEX TABLE3_INDEX1 ON TABLE3 (KEY_COL2) Anticipe un index probe, jointure de boucle imbriquée avec index 63

64 Exemples Requête 8 SELECT A.COLOR, A.SIZE, SUM(A.SALES), SUM(A.QUANTITY) FROM TABLE1 A WHERE A.COLOR IN ( BLUE, GREEN, RED ) GROUP BY A.COLOR, A.SIZE CREATE INDEX TABLE1_INDEX1 ON TABLE1 (COLOR, SIZE) Anticipe un index probe, Grouping avec index Requête 9 SELECT A.COLOR, A.SIZE, SUM(A.SALES), SUM(A.QUANTITY) FROM TABLE1 A WHERE A.COLOR IN ( BLUE, GREEN, RED ) GROUP BY A.COLOR, A.SIZE ORDER BY A.COLOR, A.SIZE CREATE INDEX TABLE1_INDEX1 ON TABLE1 (COLOR, SIZE) Anticipe un index probe, Grouping avec index et Ordering avec index 64

65 Exemples Requête 10 SELECT A.COLOR, A.SIZE, MIN(A.QUANTITY) FROM TABLE1 A WHERE A.COLOR IN ( BLUE, GREEN, RED ) GROUP BY A.COLOR, A.SIZE CREATE INDEX TABLE1_INDEX1 ON TABLE1 (COLOR, SIZE, QUANTITY) Anticipe un index probe, Grouping avec index et traitement du MIN 65

66 Exemples Requête 11 SELECT A.COLOR, A.SIZE, A.SALES FROM TABLE1 A WHERE A.SALES < (SELECT AVG(B.SALES) FROM TABLE1 B WHERE B.SIZE IN ( LARGE, X-LARGE )) AND A.COLOR IN ( BLUE, GREEN, RED ) AND A.SIZE IN ( LARGE, X-LARGE ) CREATE INDEX TABLE1_INDEX1 ON TABLE1 (SIZE, COLOR) Anticipe un index probe, Grouping avec index et, comme SIZE est la première colonne de la clé, l index peut être utilisé pour les jonctions INNER ou OUTER 66

67 Exemples Requête 12 SELECT A.COLOR, A.SIZE, SUM(A.SALES), SUM(A.QUANTITY) FROM TABLE1 A GROUP BY B.COLOR, B.SIZE CREATE INDEX TABLE1_INDEX1 ON TABLE1 (COLOR, SIZE) Anticipe Grouping avec index et index Parfait (toutes les colonnes référencées sont dans l index) 67

68 Exemples Requête 13 SELECT A.CUSTOMER, A.CUSTOMER_NUMBER, A.YEAR, A.MONTH, A.SALES FROM TABLE1 A WHERE A.SALES > (SELECT AVG(B.SALES) FROM TABLE1 B WHERE B.CUSTOMER = A.CUSTOMER AND B.YEAR = A.YEAR) AND YEAR = 2012 CREATE INDEX TABLE1_INDEX1 ON TABLE1 (YEAR, CUSTOMER, SALES) Anticipe index probe et index (SUBQUERY), l index est utilisé par les deux requêtes. 68

69 Exemples Requête 14 SELECT T.CHAR_DATE, C.COUNTRY, C.CUSTOMER_NAME, P.PART_NAME,.SUPPLIER_NAME, SUM(F.QUANTITY), SUM(F.REVENUE_WO_TAX) FROM STARLIB/SALES_FACTS F, STARLIB/PART_DIM P, STARLIB/TIME_DIM T, STARLIB/CUST_DIM C, STARLIB/SUPP_DIM S WHERE F.PARTKEY = P.PARTKEY AND F.TIMEKEY = T.TIMEKEY AND F.CUSTKEY = C.CUSTKEY AND F.SUPPKEY = S.SUPPKEY AND T.YEAR = 2000 AND T.MONTH = 06 AND T.DAY = 30 AND C.COUNTRY = FRANCE AND P.MFGR = 'Manufacturer#3' GROUP BY T.CHAR_DATE, C.COUNTRY C.CUSTOMER_NAME, P.PART_NAME, S.SUPPLIER_NAME ORDER BY T.CHAR_DATE, C.COUNTRY,C.CUSTOMER_NAME, P.PART_NAME CREATE INDEX SALES_FACTS_INDEX1 ON SALES_FACTS (PARTKEY) CREATE INDEX SALES_FACTS_INDEX2 ON SALES_FACTS (TIMEKEY) CREATE INDEX SALES_FACTS_INDEX3 ON SALES_FACTS (CUSTKEY) CREATE INDEX SALES_FACTS_INDEX4 ON SALES_FACTS (SUPPKEY) CREATE INDEX PART_DIM_INDEX1 ON PART_DIM (MFGR, PARTKEY, PART_NAME) CREATE INDEX TIME_DIM_INDEX1 ON TIME_DIM (YEAR, MONTH, DAY, TIMEKEY) CREATE INDEX CUST_DIM_INDEX1 ON CUST_DIM (COUNTRY, CUSTKEY) CREATE INDEX SUPP_DIM_INDEX1 ON SUPP_DIM (SUPPKEY, SUPPLIER_NAME) Anticipe Index Probe, Index lecture seules, jointure en boucle imbriquée 69

70 Stratégie d indexation Si l optimiseur via Visual Explain rapporte : Un Full Table Scan Créer un Index sur les colonnes de sélections Un full Index Scan Créer un Index permettant la mise en œuvre d un Probe Un index temporaire Créer un index sur les colonnes de Jonction Créer un index sur les colonnes de Groupage Créer un index sur les colonnes d Order By Une table de Hachage Créer un index sur les colonnes de Jonction Créer un index sur les colonnes de Groupage 70

71 Trop d index Attention le coût de maintenance des index croit linéairement avec le nombre d index 71

72 Indexer ou ne pas Indexer? Pour de meilleurs performances, créer les index appropriés Eliminer au maximum les lectures de tables et les index temporaires Eventuellement, supprimer les index avant de faire de grosses modification de données Supprimer les index lors de l insertion dans une table vide. Supprimer les index et les recréer si plus de 40 % des lignes sont impactées Envisager l acquisition de 5770SS1 option 26 (DB2 Symmetric Multi Processing) Temps (INSERT + CREATION d INDEX) < Temps (INSERT + MAINTENANCE d INDEX) 72

73 Performances Prendre en compte les nouveautés d indexation apparues en V6R1 Gérer les index, créer ceux qui vont améliorer les performances et supprimer les index inutilisés Moderniser vos bases de données afin de profiter des augmentations des tailles de page Réorganiser vos tables si présence d enregistrements supprimés en grande quantité Si utilisation de colonnes de type VARCHAR, positionner la taille allouée à la bonne valeur 73

74 Performances Eviter l usage du Force Ratio Utiliser les fonctions OLAP type Grouping SET (permet le groupage sur des colonnes différentes en une seule requête) Implémenter l intégrité référentielle Penser à utiliser les clauses FOR READ ONLY FOR UPDATE OF FETCH FIST N ROWS ONLY OPTIMIZE FOR n/all ROWS Utiliser l OVRDBF Eviter le LIKE avec le % en première position.. LIKE %TEST% Eviter Select *, nommer les colonnes. Proscrire l utilisation des logiques 74

75 Performances Savoir distinguer une instruction lourde optimisée, d une instruction non optimisée mais répétitive S1 : 5000 exécutions à 1 s = 5000 secondes S2 : 500,000 exécution à 10 ms = 5000 secondes Optimisation de S2 10 ms à 1 ms = 500 secondes Optimiser au maximum les requêtes répétitives ainsi que les requêtes lourdes Disposer d un pool privé pour les travaux serveurs BD (QZDASOINIT, QSQSRVR, ) Si suffisamment de RAM activer l expert Cache Si l ajustement de performance est en fonction : Caper ce pool en pourcentage et priorité. Régler les valeurs systèmes QQRYDEGREE QDBFSTCCOL Envisager l acquisition de SMP 75

76 Utiliser les MQT Les MQT permettent de créer des tables comportant les données extraites par la requête Possibilité d exécuter des requêtes au travers des MQT Les MQT sont mises à jour via l ordre SQL REFRESH TABLE CREATE TABLE SAMPLES.SALAIRE_BY_WOKDEPT AS (select workdept, sum(salary) as salaire from samples.employee group by workdept) DATA INITIALLY IMMEDIATE REFRESH DEFERRED MAINTAINED BY USER Refresh table SAMPLES.SALAIRE_BY_WOKDEPT 76

77 Moderniser vos logiques Modifier la taille des chemins d accès des logiques en les portant à 64 K Paramètre PAGESIZE de la commande CRTLF CRTLF ACCPTHSIZ(*MAX1TB) PAGESIZE(64) SELECT INDEX_NAME as Logique nl, case when SYSTEM_INDEX_NAME is not null then SYSTEM_INDEX_NAME else INDEX_NAME end as Logique nc, case when index_partition is not null then index_partition else INDEX_NAME end as Membre logique, index_schema as Schéma Logique, QUERY_STATISTICS_COUNT Nb util. optim., QUERY_USE_COUNT as Nb util. exec., LAST_STATISTICS_USE as Date dernière util. optim., LAST_QUERY_USE Date dernière util. exec., LOGICAL_PAGE_SIZE as Taille page logique, ACCPTH_TYPE as Taille CA FROM QSYS2.SYSPARTITIONINDEXES WHERE SYSTEM_TABLE_SCHEMA in ( NOMBIB') and INDEX_TYPE='LOGICAL order by index_name ; 77