BASES DE DONNEES AVANCEES

Programme BASES DE DONNEES AVANCEES 7. Optimisation et performances de BD Jerzy Korczak email : jjk@dpt-info.u-strasbg.fr 1. Introduction 2. Modèles de données 3. Entrepôts de données 4. Programmation transactionnelle - SGBD ORACLE 5. Programmation JAVA avancée 6. Structures physiques de bases de données 7. Optimisation et benchmarks de performances - Taches de DBA - Amélioration de performances - Optimisation de requêtes - TPC -Benchmarks 8. Administration de bases de données J.Korczak 1 J.Korczak 2 Introduction Taches de DBA installation d'un SGBD, planification, évaluation de matériels, création et ouverture d'une BD, lancement des procédures de démarrage et de fermeture, sauvegarde (backup) et reprise, insertion d'utilisateurs, optimisation (tuning) Particularités des types d applications OLTP, Data Warehouse, Client-serveur Optimisation et des outils Optimisation des requêtes SQL, optimisation du schéma relationnel, optimisation du serveur Benchmarks - TPC Introduction Que veut on optimiser? - Le temps global d évaluation - Le temps pour obtenir la première réponse - Le débit réseau - Deux axes principaux : - Implantations des opérateurs de l algèbre relationnelle (σ, ) les plus performantes - Choisir un plan d évaluation le plus performant possible La performance d un SGBD - les transferts disque- mémoire - m. cache : très rapide (10 nanosec), très chère, < 1 M - m. principale : rapide (10 à 100 nonosec), chère, < 1G - disque dur : lent ( 10 millisec), bon marché, centaine de G J.Korczak 3 J.Korczak 4 Outils de diagnostic de performances Dictionnaire de données en ligne (ANALYZE objet, optimisation) Vues dynamiques des performances («V$») niveaux : instance (V$SYSSTAT), session(v$session_wait), statistiques SQL Trace Facility (utilisation de ressources par de requêtes SQL) EXPLAIN PLAN Oracle Entreprise Manager Performance Manager (mesures principales de performances) Oracle TopSessions (sessions d utilisateurs les plus actives I/O) Oracle Trace (CPU, mémoire, pagination) Oracle Tablespace Manager (image de Tablespaces, défragmentation) Oracle Expert (méthodes d accès, paramétrage, mémoire) Exemple des vues dynamiques de performances Liste des utilisateurs SELECT USERNAME, PROFILE, ACCOUNT STATUS FROM DBA_USERS; Liste de Tablespace Quotas : SELECT * FROM DBA_TS_QUOTAS ; Liste d utilisation de mémoire pour chaque session d utilisateur : SELECT USERNAME, VALUE b Current UGA memory FROM V$SESSION s, V$SESSTAT st, V$STATNAME name WHERE s.sid = st.sid AND st.statistic# = name.statistic# AND name.name = session uga memory ; J.Korczak 5 J.Korczak 6 1

Outils de DBA : Monitoring Les fichiers de la BD : bede DBA : monitoring Rollback J.Korczak 7 J.Korczak 8 DBA : monitoring Triggers What's New in Oracle Performance? Automatic Performance Diagnostic and Tuning Features including Automatic Statistics Collection, Automatic Database Diagnostic Monitoring, and Automatic SQL Tuning. Application End to End Tracing identifies the source of an excessive workload, such as a high load SQL statement, by client identifier, service, module, or action. trcsess Utility consolidates trace information from selected trace files based on specified criteria. Automatic Optimizer Statistics Collection Automatic Shared Memory Management simplifies the configuration of System Global Area (SGA) memory-related parameters through selftuning algorithms. Rule-based Optimization (RBO) Obsolescence (unsupported feature) Dynamic Sampling CPU Costing (CPU+I/O) New and updated dynamic performance views are available. Existing V$EVENT_NAME, V$SESSION, and V$SESSION_WAIT views were modified. New V$ACTIVE_SESSION_HISTORY, V$SESS_TIME_MODEL, V$SYS_TIME_MODEL, V$SYSTEM_WAIT_CLASS, V$SESSION_WAIT_CLASS, V$EVENT_HISTOGRAM, V$FILE_HISTOGRAM, and V$TEMP_HISTOGRAM were added. J.Korczak 9 J.Korczak 10 Oracle Enterprise Manager 10g Amélioration des performances Objectifs : hamélioration des performances pour des requêtes spécifiques hamélioration des performances pour des applications particulières hamélioration des performances globales du système J.Korczak 11 J.Korczak 12 2

Etapes des méthodes d améliorations Etapes... 1. Affinement des commandes SQL 2. Affinement de l allocation de mémoire 3. Affinement des opérations E/S 4. Réduction de disk contention 1. Affinement des commandes SQL hconception des structures de données, index Quelles sont les opérations, commandes, données? hoptimiseur d Oracle hgestion du verrouillage au niveau des lignes hpl/sql (requêtes multiples) hgénérateur de séquences htraitement matriciel (array) J.Korczak 13 J.Korczak 14 Optimisation de requêtes L'optimiseur assigne un coût à toute opération relationnelle de la requête typiquement: nombre de pages examinées surtout on examine les jointures Le coût prévisible de chaque méthode possible en général les indexes diminue les coûts l'arbre algébrique d'exécution de la requête devient annoté Chaque arbre annoté devient un plan d'exécution Optimisation de requêtes (suite) Exemple : - SELECT Indexation si la recherche concerne < 25% de n-uplets ORACLE fait le choix d une condition WHERE Règles de sélection 1) colonnes indexées 2) index unique 3) ROWID (= constant) 4) intervalle limité 5) filtrage des n-uplets 'x%' J.Korczak 15 J.Korczak 16 Optimisation de requêtes But : la réalisation la plus efficace des commandes DML Exemple : SELECT enom, poste, salaire, dnom FROM personnel, dept WHERE personnel.nodept = dept.nodept AND NOT EXISTS (SELECT * FROM gradsalaire WHERE personnel.salaire BETWEEN minsal AND maxsal) Optimisation de requêtes Principes : 1) effectuer le plus tôt possible les opérations de sélection et de projection afin de limiter le volume de données ; 2) avant d'effectuer une opération de produit, rechercher la meilleure stratégie pour la faire (tri, index) ; 3) avant d'effectuer une opération de sélection, rechercher si la présence d'index facilite de cette opération ; 4) regrouper les successions d'opérations de sélection et de projection en seule opération ; 5) regrouper les succession d'opération de produit et de projection en seule opération. J.Korczak 17 J.Korczak 18 3

Optimisation de requêtes (suite) Les techniques d'optimisation pour les langages algébriques Principe :... descendre les opérations de sélection et de projection le plus près possible des feuilles de l'arbre syntaxique. Les méthodes m d'optimisation Méthode statique. L'optimiseur choisit le plan d'exécution en fonction des chemins d'accès disponibles pour chaque table utilisée dans la commande SQL en utilisant l'opération ayant le poids le moins élevé. Méthode statistique Disponible à partir de la version 7 d'oracle, elle se base sur des statistiques relatives aux tables pour déterminer le meilleur chemin d'accès. Ces statistiques concernent le volume des tables (nombre de lignes), le nombre de blocs alloués à la table, le nombre de valeurs distinctes de chaque colonne, la distribution de la clé, le nombre de valeurs différentes d'un index... Le but de cette méthode est le meilleur débit, ou le meilleur temps pour traiter les lignes concernées par la commande. J.Korczak 19 J.Korczak 20 Optimisation : plan d'exécution Approche d Oracle : RBO - fondée sur l ordre des chemins d'accès (règles heuristiques, ang. rule-based) ; CBO - fondée sur le coût d'exécution (statistiques, dictionnaire de données, et caractéristiques de stockage, ang. cost-based). Rule-based approach : ranking scheme Rank Path 1 ROWID = constant 2 unique indexed column = constant 3 entire unique concatenated index = constant 4 entire cluster key = corresponding cluster key 5 entire cluster key = constant 6 entire nonunique concatenated index = constant 7 nonunique index = constant 8 entire concat. index = lower band 9 most leading concatenated index specified 10 unique index column BETWEEN... or LIKE 'C%' 11 nonunique index column BETWEEN...or LIKE 'C%' 12 unique indexed column (unbounded) 13 nonunique indexed column (unbounded) 14 sort/merge (joins only) 15 MAX or MIN of single indexed column 16 ORDER BY entire index 17 full table scans 18 unindexed column = constant J.Korczak 21 J.Korczak 22 Optimisation : coût d'exécution 1. Optimiseur génère un ensemble de plans d exécution. 2. Optimiseur estime le coût d exécution pour chaque plan (basé sur la distribution de données et statistiques de stockages) USER_TABLES, USER_TAB_COLUMNS, USER_INDEXES, USER_CLUSTERS temps d exécution = fonction (E/S, UC, mémoire) 3. Optimiseur sélectionne le plan avec le temps minimal. Oracle Database 10g CBO Uses a New Cost Model The CBO estimates execution time for a query by estimating the number of I/O operations, the type of I/O operations, and the number of CPU cycles the database will perform while executing the query. These estimates depend on the existence of system statistics, which the CBO uses to convert the number of CPU cycles and the number of I/Os into execution time. Oracle Database 10g gathers two types of system statistics - statistics captured without a workload (noworkload) and statistics captured with a workload. Noworkload statistics capture I/O system performance average I/O seek time and transfer speed and CPU speed. When gathering noworkload statistics, the CBO issues sample reads of different sizes from the database's datafiles; it times every read and then uses statistical methods to compute average seek time and transfer speed. This takes from a few seconds to a few minutes. The CBO computes CPU speed in millions of cycles per second. - Workload statistics make the CBO aware of the workload. The system statistics captured during workload conditions identify whether the system is I/O- or CPU-bound; the CBO uses the data to adjust the cost of the plans accordingly. To gather workload statistics, execute : dbms_stats.gather_system_stats(gathering_mode=>'start')... dbms_stats.gather_system_stats(gathering_mode=>'stop') J.Korczak 23 J.Korczak 24 4

Understanding the Query Optimizer The query optimizer determines which execution plan is most efficient by considering available access paths and by factoring in information based on statistics for the schema objects (tables or indexes) accessed by the SQL statement. The query optimizer also considers hints, which are optimization suggestions placed in a comment in the statement. The query optimizer performs the following steps: 1. The optimizer generates a set of potential plans for the SQL statement based on available access paths and hints. 2. The optimizer estimates the cost of each plan based on statistics in the data dictionary for the data distribution and storage characteristics of the tables, indexes, and partitions accessed by the statement. 3. The cost is an estimated value proportional to the expected resource use needed to execute the statement with a particular plan. The optimizer calculates the cost of access paths and join orders based on the estimated computer resources, which includes I/O, CPU, and memory. 4. The optimizer compares the costs of the plans and chooses the one with the lowest cost. Query Optimizer Components View merging Predicate pushing Subquery Unnesting Query Rewrite Access path Join methods Join orders Selectivity Cardinality Cost J.Korczak 25 J.Korczak 26 Définition d un plan d exécution Lorsqu'une commande SQL (SELECT, UPDATE, INSERT ou DELETE) est soumise à Oracle, l optimiseur doit trouver le meilleur chemin appelé plan d'exécution, pour accéder aux données référencées dans la commande avec à la fois un minimum d opération d E/S et minimum de temps de traitement. Les différentes étapes avant d'utiliser la commande EXPLAIN PLAN sont : 1) de créer une table destinée à contenir toutes les informations relatives à un plan d'exécution 2) d'exécuter une requête en demandant le stockage des explications relatives à cette requête dans la table précédemment crée 3) d'interroger la table précédemment remplie pour connaître le plan d'exécution. Commande EXPLAIN PLAN EXPLAIN donne le plan d'exécution d'une requête. La description comprend : 1. Le chemin d'accès utilisé 2. Les opérations physiques (tri, fusion, intersection, 3. L'ordre des opérations, représentable par un arbre Cette commande permet de comprend les actions de Oracle lors d'une requête SELECT afin d'améliorer la rapidité d'exécution. Les résultats de la commande EXPLAIN PLAN sont mis dans la table PLAN_TABLE J.Korczak 27 J.Korczak 28 Création de la table PLAN_TABLE Exécuter l'ordre suivant : CREATE TABLE PLAN_TABLE ( STATEMENT_ID VARCHAR2 (30), TIMESTAMP DATE, REMARKS VARCHAR2 (80), OPERATION VARCHAR2 (30), OPTIONS VARCHAR2 (30), OBJECT_NODE VARCHAR2 (30), OBJECT_OWNER VARCHAR2 (30), OBJECT_NAME VARCHAR2 (30), OBJECT_INSTANCE NUMBER (38), OBJECT_TYPE VARCHAR2 (30), SEARCH_COLUMNS NUMBER (38), ID NUMBER (38), PARENT_ID NUMBER (38), POSITION NUMBER (38), OTHER LONG); Commande EXPLAIN PLAN ID OPERATION OPTIONS OBJECT_NAME 0 SELECT STATEMENT 1 FILTER 2 NESTED LOOPS 3 TABLE ACCESS FULL EMP 4 TABLE ACCESS BY ROWID DEPT 5 INDEX UNIQUE SCAN PK_DEPTNO 6 TABLE ACCESS FULL SALGRADE J.Korczak 29 J.Korczak 30 5

OPERATIONS et OPTIONS du plan d exécution OPERATIONS OPTIONS SIGNIFICATION AGGREGATE GROUP BY Une recherche d une seule ligne qui est le résultat de l application d une fonction de group à un groupe de lignes sélectionnées. AND-EQUAL Une opération qui a en entrée des ensembles de rowids et retourne l intersection de ces ensembles en éliminant les doublants. Cette opération est utilisée par le chemin d accès par index. CONNECT BY Recherche de ligne dans un ordre hiérarchique COUTING Opération qui compte le nombre de lignes sélectionnées. FILTER Accepte un ensemble de ligne, appliqué un filter pour en éliminer quelque unes et retourne le reste. FIRST ROW Recherché de le première ligne seulement. FOR UPDATE Opération qui recherche et verrouille les lignes pour une MAJ INDEX UNIQUE SCAN Recherche d une seule valeur ROWID d un index. INDEX RANGE SCAN Recherche d une ou plusieurs valeurs ROWID d un index. L index est parcouru dans un ordre croissant. INDEX RANGE SCAN Recherche d un ou plusieurs ROWID d un index. DESCENDING L index est parcouru dans un ordre décroissant. INTERSECTION Opération qui accepte deux ensembles et retourne l intersection en éliminant les doublons. MARGE JOIN+ Accepte deux ensembles de lignes (chacun est trié selon un critère), combine chaque ligne du premier ensemble avec ses correspondants du deuxième et retourne le résultat. MARGE JOIN+ OUTER Pour effectuer une jointure externe MINUS Différence de deux ensembles de lignes. OPERATIONS et OPTIONS du plan d exécution OPERATIONS OPTIONS SIGNIFICATION NESTED LOOPS Opération qui accepte deux ensembles, l un externe et l autre interne. Oracle compare chaque ligne de l ensemble externe avec chaque ligne de l ensemble interne et retourne celle qui satisfont une condition. NESTED LOOPS OUTER Une boucle imbriquée pour effectuer une jointure externe. PROJECTION Opération interne REMOTE Recherche de données d une base distante. SEQUENCE Opération nécessitant l accès à des valeurs du séquenceur SORT UNIQUE Tri d un ensemble de lignes pour éliminer les doublons. SORT GROUP BY Opération qui fait le tri à l intérieur de groupes SORT JOIN Tri avant la jointure (MERGE-JOIN). SORT ORDER BY Tri pour un ORDER BY. TABLE ACCESS FULL Obtention de toutes lignes d une table. TABLE ACCESS CLUSTER Obtention des lignes selon la valeur de la clé d un cluster indexé. TABLE ACCESS HASH Obtention des lignes selon la valeur de la clé d un hash cluster TABLE ACCESS BY ROW ID Obtention des lignes on se basant sur les valeurs ROWID. UNION Union de deux ensembles avec élimination des doublons. VIEW Opération qui utilise une vue et retourne le résultat à une autre opération. J.Korczak 31 J.Korczak 32 Utilisation de EXPLAIN PLAN Le modèle suivant : EXPLAIN PLAN SET STATEMENT_ID='Identifiant_choisi ' FOR requête ; où ' Identifiant_choisi est un identifiant choisi par le programmeur pour identifier ce Plan d'exécution, et requête est la requête dont on veut le Plan d'exécution Exemple : EXPLAIN PLAN SET STATEMENT_ID='sel1' FOR SELECT NOM from ACTEURS order by NOM; EXPLAIN PLAN SET STATEMENT_ID='sel2' FOR SELECT NOM from ACTEURS group by NOM; Il ne reste plus en suite qu'à interroger la table PLAN_TABLE (SELECT * FROM PLAN_TABLE, par exemple) Utilisation de EXPLAIN PLAN Si on ne veut pas tous les champs, on peut lancer l ordre suivant : SELECT STATEMENT_ID, OPERATION, OPTIONS, ID, PARENT_ID, POSITION FROM PLAN_TABLE WHERE STATEMENT_ID='sel2'; On obtient : STATEMENT_ ID OPERATION OPTIONS ID PARENT_ID POSITION sel2 SELECT GROUP BY 0 0 1 STATEMENT sel2 1 1 1 SORT FULL sel2 2 TABLE ACCESS J.Korczak 33 J.Korczak 34 Exemples : EXPLAIN PLAN Sélection sans index SELECT * FROM cinema WHERE nom='le Rex'; Plan d'exécution : 0 SELECT STATEMENT 1 TABLE ACCESS FULL CINEMA L'opération 1 est très couteuse car elle balaie entièrement la table Exemples : EXPLAIN PLAN Sélection conjonctive avec deux index SELECT nom FROM salle WHERE ID-cinema=1098 AND capacité=150 Plan d'exécution : 0 SELECT STATEMENT 1 TABLE ACCESS BY ROWID SALLE 2 AND-EQUAL 3 INDEX RANGE SCAN IDX-SALLE-CINEMA-ID 4 INDEX RANGE SCAN IDX-CAPACITE Avec ID-cinema et Capacité : index non unique Sélection disjonctive avec des index SELECT nom FROM salle WHERE ID-cinema=1098 OR capactié>150 Plan d'exécution : 0 SELECT STATEMENT 1 CONCATENATION 2 TABLE ACCESS BY ROWID SALLE 3 INDEX RANGE SCAN IDX-CAPACITE 4 TABLE ACCESS BY ROWID SALLE 5 INDEX RANGE SCAN IDX-SALLE-CINEMA-ID Avec ID-cinema et Capacité : index non unique J.Korczak 35 J.Korczak 36 6

Exemples : EXPLAIN PLAN Jointure avec 1 index et sélection avec 1 index sur 2 tables différentes SELECT e.enom, d.dnom FROM emp e, dept d WHERE e.dno=d.dno AND e.sal=10000 Plan d'execution : 0 SELECT STATEMENT 1 NESTED LOOPS 2 TABLE ACCESS BY ROWID EMP 3 INDEX RANGE SCAN EMP_SAL 4 TABLE ACCESS BY ROWID DEPT 5 INDEX UNIQUE SCAN DEPT_DNO Avec d.dno : index unique et e.sal : index non unique La différence SELECT nom FROM cinema WHERE NOT EXISTS (SELECT * FROM scéance, salle WHERE SALLE.ID-salle=Séance.ID-salle AND heure-fin>'23h00') Plan d'execution : 0 SELECT STATEMENT 1 FILTER 2 NESTED LOOPS 3 TABLE ACCESS FULL SALLE 4 TABLE ACCESS BY ROWID CINEMA 5 INDEX UNIQUE SCAN IDX-CINEMA-ID 6 TABLE ACCESS BY ROWID SEANCE 7 INDEX RANGE SCAN IDX-SEANCE-SALLE-ID Jointure avec 2 index et sélection avec 1 index J.Korczak 37 Exemple EXPLAIN PLAN EXPLAIN PLAN FOR SELECT e.employee_id, j.job_title, e.salary, d.department_name FROM employees e, jobs j, departments d WHERE e.employee_id < 103 AND e.job_id = j.job_id AND e.department_id = d.department_id; EXPLAIN PLAN Output ------------------------------------------------------------------------------------------------------------------------ Id Operation Name Rows Bytes Cost (%CPU) ------------------------------------------------------------------------------------------------------------------------ 0 SELECT STATEMENT 3 189 10 (10) 1 NESTED LOOPS 3 189 10 (10) 2 NESTED LOOPS 3 141 7 (15) * 3 TABLE ACCESS FULL EMPLOYEES 3 60 4 (25) 4 TABLE ACCESS BY INDEX ROWID JOBS 19 513 2 (50) * 5 INDEX UNIQUE SCAN JOB_ID_PK 1 6 TABLE ACCESS BY INDEX ROWID DEPARTMENTS 27 432 2 (50) * 7 INDEX UNIQUE SCAN DEPT_ID_PK 1 ----------------------------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): 3 - filter("e"."employee_id"<103) 5 - access("e"."job_id"="j"."job_id") 7 - access("e"."department_id"="d"."department_id") J.Korczak 38 Etapes... Instance d une BD 2. Affinement de l allocation de mémoire SQLDBA> SHOW SGA hzones de contexte hcache du dictionnaire de données hcache des buffers SQLDBA> MONITOR STATISTICS USER Instance PGA Buffers de BD System Global Area Buffers REDO LOG USER DBWR PMON SMON LGWR ARCH Seg. de données Seg. ROLLBACK REDO LOG actif J.Korczak 39 BASE DE DONNEES J.Korczak 40 Types de zones de mémoire m moire : SGA et PGA Zone globale de système (SGA) : le centre de communication La zone SGA est un emplacement en mémoire exploité par une instance de BD Oracle pour y stocker des informations importantes. La SGA est partagée par tous les processus client et serveur. Cache de tampons de données : une zone de blocs de données. L algorithme LRU. Cache de dictionnaire : les lignes extraites du DD Tampon de journaux de reprise Zone SQL partagée : le cache de programmes SQL> SELECT * FROM V$SGA ; Zone globale de programme (PGA) est emplacement en mémoire dédié à un processus serveur (variables de session et tableaux internes). Gestion de la mémoire En terme d'optimisation, il est clair que le SGA y joue un très grand rôle. Le plus grand conseil que l'on puisse donner est d'ajouter de la mémoire à la machine afin d'augmenter le plus possible la taille du SGA. Parametrage du SGA Le SGA peut se paramétrer grâce au fichier d'initialisation qu'il charge lors de tout démarrage. Quatre paramètres sont importants : DB_BLOCK_SIZE DB_BLOCK_BUFFER : nombre de tampons pour les données LOG_BUFFER : taille en octet du buffer pour les Redo log files. SHARED_POOL_SIZE : pour stocker les données du dictionnaire. La taille totale du SGA : SIZE = DB_BLOCK_SIZE*DB_BLOCK_BUFFER + LOG_BUFFER + SHARED_POOL_SIZE Quelques statistiques Certaines vues sont là pour vous fournir quelques statistiques. On trouve notamment V$SYSSTAT, V$ROWCACHE, V$LIBRARYCACHE. A titre indicatif, un bon cache doit assurer 85% d'accès directement dans le cache pour le dictionnaire, 90% pour le cache library et 60% pour les données. J.Korczak 41 J.Korczak 42 7

Etapes... 3. Affinement des opérations E/S hdistribution E/S pour éviter le disc contention hstockage des données et méthodes d accès SQLDBA> MONITOR FILE hcréation des extents suffisamment larges, problème de «striping» 4. Réduction de contention hsegments ROLLBACK hbuffer REDO LOG Fichier de paramètres init.ora db_file = 20 db_file_multiblock_read_count = 8 #small # db_file_multiblock_read_count = 16 #medium # db_file_multiblock_read_count = 32 #large db_block_buffers = 200 #small # db_block_buffers = 500 #medium # db_block_buffers = 3200 #large shared_pool_size = 3500000 #small # shared_pool_size = 6000000 #medium # shared_pool_size = 9000000 #large log_checkpoint_interval = 10000 processes = 50 #small # processes = 100 #medium # processes = 200 #large... J.Korczak 43 J.Korczak 44 DB Benchmarks TPC-A Organisations : TPC-A : environnement OLTP faisant ressortir les opérations MAJ intensives TPC, SPEC, AIM, SAP, BAPCo,... TPC benchmarks (http://www.tpc.org) SPEC benchmarks (http://www.spec.org) SAP S&D Benchmarks (http://www.sap.com) - multiples sessions en ligne - quantité d opérations E/S disque importante - complexité moyenne en place et en temps d exécution - intégrité des transactions La mesure : débit in transactions par seconde (tps) J.Korczak 45 J.Korczak 46 TPC-B TPC-C Overview TPC-B : un test de stress pour le noyau du SGBD * - Combien transactions peuvent être simultanément gérées par un SGBD? - pas d utilisateurs (pas de temps de réponse d un utilisateur), pas de lignes de communication, - un test de stress : CPU, mémoire, disque I/O, DB manager, système d exploitation * obsolète Moderately complex OLTP The result of 2+ years of development by the TPC Application models a wholesale supplier managing orders. Order-entry provides a conceptual model for the benchmark; underlying components are typical of any OLTP system. Workload consists of five transaction types. Users and database scale linearly with throughput. Spec defines full-screen end-user interface. Metrics are new-order txn rate (tpmc) and price/performance ($/tpmc) Specification was approved July 23, 1992. J.Korczak 47 J.Korczak 48 8

TPC-C TPC-C Database Schema TPC-C : OLTP benchmark plus complexe que TPC-A (multiples types de transactions, BD plus complexe), la gestion des commandes (saisie de commandes, livraison, enregistrement des payements, vérification de l état des commandes, et le contrôle du stock), 100,000 produits, environ 10 produits par commande, chaque entrepôt doit servir 10 zones de vente (une zone correspond à environ 3,000 clients), 10% de commandes doit être fournies par un autre entrepôt, 5 transactions concurrentes de types différents, saisie de données en ligne, la mesure de performance : transactions par minute (nouvelles commandes). Warehouse W 10 District W*10 3K Customer W*30K 1+ History W*30K+ 100K 1+ Stock W*100K Order W*30K+ 10-15 15 Order-Line W*300K+ W Legend Table Name <cardinality> Item 100K (fixed) secondary index 0-1 one-to to-many relationship New-Order W*5K J.Korczak 49 J.Korczak 50 TPC-C s Five Transactions TPC-C Workflow OLTP transactions: New-order: enter a new order from a customer Payment: update customer balance to reflect a payment Delivery: deliver orders (done as a batch transaction) Order-status: retrieve status of customer s most recent order Stock-level: monitor warehouse inventory Transactions operate against a database of nine tables. Transactions do update, insert, delete, and abort; primary and secondary key access. Response time requirement: 90% of each type of trans. must have a response time < 5 s, except (queued mini-batch) stock-level which is < 20 s. J.Korczak 51 1 Select txn from menu: 1. New-Order 45% 2. Payment 43% 3. Order-Status 4% 4. Delivery 4% 5. Stock-Level 4% 2 Input screen 3 Output screen Go back to 1 Measure menu Response Time Keying time Measure txn Response Time Think time Cycle Time Decomposition (typical values, in seconds, for weighted average txn) Menu = 0.3 Keying = 9.6 Txn RT = 2.1 Think = 11.4 Average cycle time = 23.4 J.Korczak 52 ACID Tests Transparency (cont.) TPC-C requires transactions be ACID. Tests included to demonstrate ACID properties met. Atomicity Verify that all changes within a transaction commit or abort. Consistency Isolation ANSI Repeatable reads for all but Stock-Level transactions. Committed reads for Stock-Level. Durability Must demonstrate recovery from Loss of power Loss of memory Loss of media (e.g., disk crash) How does transparency affect TPC-C? Payment txn: 15% of Customer table records are non-local to the home warehouse. New-order txn: 1% of Stock table records are non-local to the home warehouse. In a cluster, cross warehouse traffic cross node traffic 2 phase commit, distributed lock management, or both. For example, with distributed txns: Number of nodes % Network Txns 1 0 2 5.5 3 7.3 n 10.9 J.Korczak 53 J.Korczak 54 9

TPC-C Rules of Thumb Typical TPC-C Configuration (Conceptual) 1.2 tpmc per User/terminal (maximum) 10 terminals per warehouse (fixed) 65-70 MB/tpmC priced disk capacity (minimum) ~ 0.5 physical IOs/sec/tpmC (typical) 300-700 KB main memory/tpmc So use rules of thumb to size 10,000 tpmc system: How many terminals? How many warehouses? How much memory? How much disk capacity? How many spindles? Hardware Software Emulated User Load Driver System RTE,, e.g.: Empower prevue LoadRunner Term. LAN Response Time measured here Presentation Services Client TPC-C C application + Txn Monitor and/or database RPC library e.g., Tuxedo, ODBC C/S LAN Database Functions Database Server... TPC-C C application (stored procedures) + Database engine + Txn Monitor e.g., SQL Server, Tuxedo J.Korczak 55 J.Korczak 56 TPC-C TPC-C Summary - Prix/performance : coût total du système Top TPC-C performance : how many complete business operations per minute? IBM eserver, 3,210,540 tpmc, 5.07 $/tpmc, IBM DB2, IBM AIX 5L IBM, eserver, 1,601,784 tpmc, 5.05 $/pmpc, Oracle DB 10g, Microsoft HP, Integrity Superdome, 1,231,433 tpmc, 4.82 $/tmpc, MS SQL Ser, MS Balanced, representative OLTP mix Five transaction types Database intensive; substantial IO and cache load Scaleable workload Complex data: data attributes, size, skew Requires Transparency and ACID Full screen presentation services De facto standard for OLTP performance J.Korczak 57 J.Korczak 58 TPC-D Overview TPC-D Schema Complex Decision Support workload The result of 5 years of development by the TPC Benchmark models ad hoc queries extract database with concurrent updates multi-user environment Workload consists of 17 queries and 2 update streams SQL as written in spec Database load time must be reported Database is quantized into fixed sizes Metrics are Power (QppD), Throughput (QthD), and Price/Performance ($/QphD) Specification was approved April 5, 1995. J.Korczak 59 Customer SF*150K Order SF*1500K LineItem SF*6000K Time 2557 Nation 25 Supplier SF*10K PartSupp SF*800K Region 5 Part SF*200K Legend: Arrows point in the direction of one-to to-many relationships. The value below each table name is its cardinality. SF is the Scale Factor. The Time table is optional. So far, not used by anyone. J.Korczak 60 10

TPC-D Database Scaling and Load Database size is determined from fixed Scale Factors (SF): 1, 10, 30, 100, 300, 1000, 3000 (note that 3 is missing, not a typo) These correspond to the nominal database size in GB. (I.e., SF 10 is approx. 10 GB, not including indexes and temp tables.) Indices and temporary tables can significantly increase the total disk capacity. (3-5x is typical) Database is generated by DBGEN DBGEN is a C program which is part of the TPC-D spec. Use of DBGEN is strongly recommended. TPC-D database contents must be exact. Database Load time must be reported Includes time to create indexes and update statistics. Not included in primary metrics. TPC-D Query Set 17 queries written in SQL92 to implement business questions. Queries are pseudo ad hoc: Substitution parameters are replaced with constants by QGEN QGEN replaces substitution parameters with random values No host variables No static SQL Queries cannot be modified -- SQL as written There are some minor exceptions. All variants must be approved in advance by the TPC J.Korczak 61 J.Korczak 62 TPC-D Update Streams Update 0.1% of data per query stream About as long as a medium sized TPC-D query Implementation of updates is left to sponsor, except: ACID properties must be maintained Update Function 1 (UF1) Insert new rows into ORDER and LINEITEM tables equal to 0.1% of table size Update Function 2 (UF2) Delete rows from ORDER and LINEITEM tables equal to 0.1% of table size TPC-D Metrics Power Metric (QppD) Geometric queries per hour times SF 3600 SF i= 17 j= 2 19 QI ( i, 0) UI ( j, 0) i= 1 j= 1 where QI(i,0) Timing Interval for Query i, stream 0 UI(j,0) Timing Interval for Update j, stream 0 SF Scale Factor QppD@ Size = Throughput (QthD) S Linear queries per hour times SF S QthD@ Size = 17 SF where: S number of query streams T ( S 3600) T elapsed time of test (in seconds) J.Korczak 63 J.Korczak 64 TPC-D* et TPC-H Evaluation de «Decision Support Systems» (1998) Requêtes complexes ad hoc VLDB et opérations de : - jointure multi-tables - tri - regroupement et agrégation - recherche séquentielle d information TPC-W : Overview TPC-W is a transactional web benchmark. The workload is performed in a controlled Internet Commerce environment that simulates the activities of a business oriented web server. The workload exercises a breadth of system components associated with such environments. The application portrayed by the benchmark is a Retail Store on the Internet with a customer browse and order scenario. Mesures : performances et prix/performances Composite Query-per-hour perf. $/QphH@size J.Korczak 65 J.Korczak 66 11

TPC-W : Characteristics Multiple on-line browser sessions. Dynamic page generation with database access and update. Consistent web objects. The simultaneous execution of multiple transaction types On-line transaction execution modes. Databases consisting of many tables with a wide variety of sizes, attributes, and relationships. Contention on data access and update. TPC-W : Primary Performance Metric The performance metric reported by TPC-W measures the number of web interactions processed per second. Multiple transactions are used to simulate the business activity of processing an order, and each transaction is subject to a response time constraint. The performance metric for this benchmark is expressed in Web Interactions per second (WIPS). J.Korczak 67 J.Korczak 68 TPC-W : Three profiles, operations and measures TPC-W simulates three different profiles by varying the ratio of browse to buy: Primarily shopping (WIPS), Browsing (WIPSb) and Web-based Ordering (WIPSo) Web Interaction VLDB et operations: - join multi-tables - sort - clustering and aggregation - sequential search Measures : performance and price/performance J.Korczak 69 12