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