BASES DE DONNEES AVANCEES
Transcription
BASES DE DONNEES AVANCEES
Programme 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 BASES DE DONNEES AVANCEES 7. Optimisation et benchmarks de performances 7. Optimisation et performances de BD - Taches de DBA - Amélioration de performances - Optimisation de requêtes - TPC -Benchmarks 8. Administration de bases de données Jerzy Korczak email : [email protected] J.Korczak 1 J.Korczak 2 Introduction Introduction Que veut on optimiser ? 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) Le temps global d’évaluation Le temps pour obtenir la première réponse Le débit réseau … Deux axes principaux : Particularités des types d’applications - OLTP, Data Warehouse, Client-serveur - Implantations des opérateurs de l’algèbre relationnelle (σ, performantes Choisir un plan d’évaluation le plus performant possible ⋈) les plus Optimisation et des outils Optimisation des requêtes SQL, optimisation du schéma relationnel, optimisation du serveur La performance d’un SGBD - les transferts disque- mémoire - Benchmarks - TPC J.Korczak 3 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 Exemple des vues dynamiques de performances Outils de diagnostic de performances • Dictionnaire de données en ligne (ANALYZE objet, optimisation) Liste des utilisateurs • Vues dynamiques des performances (« V$ ») SELECT USERNAME, PROFILE, ACCOUNT STATUS FROM DBA_USERS; – 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 – – – – – J.Korczak 4 Liste de Tablespace Quotas : SELECT * FROM DBA_TS_QUOTAS ; Liste d’utilisation de mémoire pour chaque session d’utilisateur : 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) 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’ ; 5 J.Korczak 6 1 Outils de DBA : Monitoring DBA : monitoring Les fichiers de la BD : bede J.Korczak Rollback 7 DBA : monitoring J.Korczak 8 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, Triggers 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 Oracle Enterprise Manager 10g J.Korczak 10 Amélioration des performances Objectifs : h amélioration des performances pour des requêtes spécifiques h amélioration des performances pour des applications particulières h amélioration des performances globales du système J.Korczak 11 J.Korczak 12 2 Etapes ... Etapes des méthodes d’améliorations 1. Affinement des commandes SQL 1. Affinement des commandes SQL 2. Affinement de l’allocation de mémoire h conception des structures de données, index Quelles sont les opérations, commandes, données ? 3. Affinement des opérations E/S h optimiseur d’Oracle 4. Réduction de disk contention h gestion du verrouillage au niveau des lignes h PL/SQL (requêtes multiples) h générateur de séquences h traitement matriciel (array) J.Korczak 13 Optimisation de requêtes J.Korczak Optimisation de requêtes (suite) Exemple : • 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 - SELECT • • 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 J.Korczak 15 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 16 Optimisation de requêtes Optimisation de requêtes Principes : But : la réalisation la plus efficace des commandes DML 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. 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) J.Korczak 14 17 J.Korczak 18 3 Les mé méthodes d'optimisation Optimisation de requêtes (suite) 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é. 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. J.Korczak 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. 19 Optimisation : plan d'exécution J.Korczak Rule-based approach : ranking scheme Rank 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 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). J.Korczak 21 Path ROWID = constant unique indexed column = constant entire unique concatenated index = constant entire cluster key = corresponding cluster key entire cluster key = constant entire nonunique concatenated index = constant nonunique index = constant entire concat. index = lower band most leading concatenated index specified unique index column BETWEEN ... or LIKE 'C%' nonunique index column BETWEEN...or LIKE 'C%' unique indexed column (unbounded) nonunique indexed column (unbounded) sort/merge (joins only) MAX or MIN of single indexed column ORDER BY entire index full table scans unindexed column = constant J.Korczak 22 Oracle Database 10g CBO Uses a New Cost Model 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. • J.Korczak 20 23 J.Korczak 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') 24 4 Understanding the Query Optimizer Query Optimizer Components 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. View merging Predicate pushing Subquery Unnesting Query Rewrite 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. J.Korczak Selectivity Cardinality Cost Access path Join methods Join orders 25 Définition d’un plan d’exécution 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. 27 Création de la table PLAN_TABLE 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 28 Commande EXPLAIN PLAN 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); J.Korczak 26 Commande EXPLAIN PLAN 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. J.Korczak J.Korczak ID 0 1 2 3 4 5 6 29 J.Korczak OPERATION SELECT STATEMENT FILTER NESTED LOOPS TABLE ACCESS TABLE ACCESS INDEX TABLE ACCESS OPTIONS OBJECT_NAME FULL BY ROWID UNIQUE SCAN FULL EMP DEPT PK_DEPTNO SALGRADE 30 5 OPERATIONS et OPTIONS du plan d’exécution 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 OPTIONS • NESTED LOOPS J.Korczak 31 • • • • • • • • • • NESTED LOOPS OUTER PROJECTION REMOTE SEQUENCE SORT UNIQUE SORT GROUP BY SORT JOIN SORT ORDER BY TABLE ACCESS FULL TABLE ACCESS CLUSTER • • • • TABLE ACCESS HASH TABLE ACCESS BY ROW ID UNION VIEW J.Korczak 32 Utilisation de EXPLAIN PLAN 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; 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 sel2 sel2 sel2 Il ne reste plus en suite qu'à interroger la table PLAN_TABLE (SELECT * FROM PLAN_TABLE, par exemple) J.Korczak SIGNIFICATION 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. Une boucle imbriquée pour effectuer une jointure externe. Opération interne Recherche de données d’une base distante. Opération nécessitant l’accès à des valeurs du séquenceur Tri d’un ensemble de lignes pour éliminer les doublons. Opération qui fait le tri à l’intérieur de groupes Tri avant la jointure (MERGE-JOIN). Tri pour un ORDER BY. Obtention de toutes lignes d’une table. Obtention des lignes selon la valeur de la clé d’un cluster indexé. Obtention des lignes selon la valeur de la clé d’un hash cluster Obtention des lignes on se basant sur les valeurs ROWID. Union de deux ensembles avec élimination des doublons. Opération qui utilise une vue et retourne le résultat à une autre opération. 33 OPTIONS ID PARENT_ID POSITION SELECT GROUP BY 0 STATEMENT 1 SORT FULL 2 TABLE ACCESS 0 1 1 1 J.Korczak 34 Exemples : EXPLAIN PLAN 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 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 J.Korczak 35 J.Korczak 36 6 Exemples : EXPLAIN PLAN Exemple EXPLAIN PLAN Jointure avec 1 index et sélection avec 1 index sur 2 tables différentes 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; 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 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 | | | ----------------------------------------------------------------------------------------------------------------------- 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 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") 37 Etapes ... J.Korczak 38 Instance d’une BD 2. Affinement de l’allocation de mémoire Instance System Global Area SQLDBA> SHOW SGA Buffers REDO LOG Buffers de BD PGA h zones de contexte h cache du dictionnaire de données h cache des buffers SQLDBA> MONITOR STATISTICS USER USER DBWR Seg. de données Seg. ROLLBACK PMON SMON LGWR ARCH REDO LOG actif BASE DE DONNEES J.Korczak 39 40 Gestion de la mémoire Types de zones de mé mémoire : SGA et PGA 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. 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 ; 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 Zone globale de programme (PGA) est emplacement en 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. mémoire dédié à un processus serveur (variables de session et tableaux internes). J.Korczak J.Korczak 41 J.Korczak 42 7 Fichier de paramètres init.ora Etapes ... db_file = 20 db_file_multiblock_read_count = 8 # db_file_multiblock_read_count = 16 # db_file_multiblock_read_count = 32 db_block_buffers = 200 # db_block_buffers = 500 # db_block_buffers = 3200 shared_pool_size = 3500000 # shared_pool_size = 6000000 # shared_pool_size = 9000000 log_checkpoint_interval = 10000 processes = 50 # processes = 100 # processes = 200 ... 3. Affinement des opérations E/S h distribution E/S pour éviter le disc contention h stockage des données et méthodes d’accès SQLDBA> MONITOR FILE h création des extents suffisamment larges, problème de «striping» 4. Réduction de contention h segments ROLLBACK h buffer REDO LOG J.Korczak 43 DB Benchmarks #small #medium #large #small #medium #large #small #medium #large #small #medium #large J.Korczak 44 TPC-A TPC-A : Organisations : TPC, SPEC, AIM, SAP, BAPCo, ... environnement OLTP faisant ressortir les opérations MAJ intensives - 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 TPC benchmarks (http://www.tpc.org) SPEC benchmarks (http://www.spec.org) SAP S&D Benchmarks (http://www.sap.com) La mesure : débit in transactions par seconde (tps) J.Korczak 45 J.Korczak TPC-C Overview TPC-B 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 • • • • • J.Korczak 46 47 J.Korczak 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. 48 8 TPC-C Database Schema TPC-C 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). J.Korczak Warehouse W Stock Item W*100K 100K 100K (fixed) W Legend 10 Table Name District oneone-toto-many relationship <cardinality> W*10 secondary index 3K Customer Order W*30K 49 TPC-C’s Five Transactions W*30K+ 1+ 1+ 1010-15 History OrderOrder-Line W*30K+ W*300K+ NewNew-Order W*5K 0-1 J.Korczak 50 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. 1 Select txn from menu: 1. NewNew-Order 2. Payment 3. OrderOrder-Status 4. Delivery 5. StockStock-Level 45% 43% 4% 4% 4% 2 Cycle Time Decomposition (typical values, in seconds, for weighted average txn) txn) Measure menu Response Time Menu = 0.3 Keying time Keying = 9.6 Input screen 3 Measure txn Response Time Output screen Think time Txn RT = 2.1 Think = 11.4 Average cycle time = 23.4 Go back to 1 J.Korczak 51 J.Korczak ACID Tests 52 Transparency (cont.) • TPC-C requires transactions be ACID. • Tests included to demonstrate ACID properties met. • Atomicity • 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. – Verify that all changes within a transaction commit or abort. • Consistency • Isolation • In a cluster, – ANSI Repeatable reads for all but Stock-Level transactions. – Committed reads for Stock-Level. • – cross warehouse traffic cross node traffic – 2 phase commit, distributed lock management, or both. For example, with distributed txns: • Durability Number of nodes 1 2 3 n→∞ – Must demonstrate recovery from • Loss of power • Loss of memory • Loss of media (e.g., disk crash) J.Korczak 53 J.Korczak % Network Txns 0 5.5 7.3 10.9 54 9 Typical TPC-C Configuration (Conceptual) TPC-C Rules of Thumb 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: – – – – – Emulated User Load Hardware • • • • • 55 Term. LAN Database Functions Database Server C/S LAN Client ... RTE, RTE, e.g.: Empower preVue LoadRunner TPCTPC-C application + Txn Monitor and/or database RPC library e.g., Tuxedo, ODBC TPCTPC-C application (stored procedures) + Database engine + Txn Monitor e.g., SQL Server, Tuxedo J.Korczak 56 TPC-C Summary TPC-C • Balanced, representative OLTP mix - Prix/performance : coût total du système – – – – Top TPC-C performance : how many complete business operations per minute ? 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 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 J.Korczak Presentation Services Response Time measured here How many terminals? How many warehouses? How much memory? How much disk capacity? How many spindles? J.Korczak Driver System Software • 57 J.Korczak 58 TPC-D Schema TPC-D Overview • Complex Decision Support workload • The result of 5 years of development by the TPC • Benchmark models ad hoc queries Customer Nation Region SF*150K 25 5 Order Supplier Part SF*1500K SF*10K SF*200K – 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 Time 2557 LineItem SF*6000K 59 J.Korczak PartSupp SF*800K Legend: • Arrows point in the direction of oneone-toto-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. 60 10 TPC-D Database Scaling and Load TPC-D Query Set • Database size is determined from fixed Scale Factors (SF): • 17 queries written in SQL92 to implement business questions. • Queries are pseudo ad hoc: – 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. 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 • Database Load time must be reported – Includes time to create indexes and update statistics. – Not included in primary metrics. J.Korczak 61 TPC-D Update Streams J.Korczak 62 TPC-D Metrics • Power Metric (QppD) – Geometric queries per hour times SF • 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) 3600 • SF QppD @ Size = i =17 19 j =2 ∏ 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 – Insert new rows into ORDER and LINEITEM tables equal to 0.1% of table size • Update Function 2 (UF2) QthD@ Size = S • 17 ( ) • SF TS 3600 where: S ≡ number of query streams TS ≡ elapsed time of test (in seconds) – Delete rows from ORDER and LINEITEM tables equal to 0.1% of table size • Throughput (QthD) – Linear queries per hour times SF J.Korczak 63 TPCTPC-D* et TPCTPC-H J.Korczak 64 TPCTPC-W : Overview • Evaluation de «Decision Support Systems» (1998) • 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. • Requêtes complexes ad hoc • VLDB et opérations de : - jointure multi-tables - tri - regroupement et agrégation - recherche séquentielle d’information • Mesures : performances et prix/performances Composite Query-per-hour perf. $/QphH@size J.Korczak 65 J.Korczak 66 11 TPC-W : Characteristics TPC-W : Primary Performance Metric • 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. J.Korczak • 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). 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