3_Stockage - StructureDB Oracle8

– Structures de stockage
– Organisation du dictionnaire
• Oracle
– Type d’index
– Modèle de stockage
• Organisation des index
– Format des attributs, tuples, pages, fichiers, index
– Modèle de stockage
• Organisation des données
– Cache CPU, RAM, disques, bandes, …Flash ?
• Introduction à la hiérarchie mémoire
Modèle de stockage: plan du cours
Support construit à partir de ceux de Nicolas Anciaux, L. Bouganim, P. Pucheral,
P. Bonnet, D. Shasha, Mohammed J. Zaki
Modèles de stockage
et d’indexation
3
1
0.001
0.01
1
10
Disques
RAM
Cache processeur
Bandes / Disques optiques
Ratio Prix (approx)
Système opérationnel
Gestion de
Verrous
Gestion des
Journaux
qq sec
1010
10ms
107
10
1
Accès (ns)
Hiérarchie mémoire
Gestion de
Mémoire
Méthodes d’accès aux données
Opérations relationnelles
Moteur d’exécution
Optimiseur
Analyseur sémantique
Interface
10 Mo/s
(x10-3)
100 Mo/s
(x10-2)
1 Go/s
(x10-1)
10 Go/s
Débit (Mo/s)
Architecture en couche d’un SGBD
4
2
•
Interface (IDE, SCSI)
Contrôleur
bras
tête de
lecture
arbre
•
•
•
2048 bytes
Page 64
…
Page 3
Page 2
Page 1
…
8192 blocs
…
– Notamment, coût extrême des écritures aléatoires
FTL (Flash Translation Layer) actuelles peu adaptées à des
comportements BD
• 104 to 105 erase cycles => wear leveling
– Erase: block granularity (2ms)
• Écritures séquentielles dans un bloc
• Contrainte Erase-before-rewrite
– Read: Random (25µs), sequentiel (50ns/byte)
– Write: page (300 µs)
Capacité des disques SSD jusqu’à 256GB aujourd’hui
Performances STM NAND 08Gb
Bloc
(64 pages)
• Ex: STM NAND 08Gb
Plateaux
Secteur
Pistes
Sequential
writes
© Mohammed J. Zaki, Luc Bouganim, Philippe Pucheral
Bras
Mouvement du bras
Tête de lecture
Arbre
NAND Flash : le futur ?
© Dennis Shasha, Philippe Bonnet
levier
plateau
piste
– Capacité + 60% par an
– Latence + 15% par an Å contraintes
mécaniques …
– Débit + 40% par an
Progression moyenne des disques
Disques Magnétiques
7
5
attributs
∈ tuples
∈
pages
∈
fichiers
attributs, de taille fixe ou variable...
…stockés eux-mêmes sous forme de tuples...
…stockés dans des pages (blocs disques)...
…stockés dans des fichiers
• Rappel : le SGBD gère un cache de pages en RAM à
la façon d’une mémoire virtuelle
–
–
–
–
• Les données sont stockées sous forme de
Modèles de stockage des données
• Regroupement physique des blocs de données
– Quand ils contiennent des données souvent utilisées ensemble
• Placement de ces blocs sur
– La même piste physique => I/O unique
– Le même cylindre physique => I/O séquentielles
• Compromis entre bon placement et trop de perte de place
– Allocation d’un ensemble de blocs par «granule»
– Calibrer la taille du granule pour chaque objet BD
– Clustering
• Le SGBD peut anticiper les patterns d’accès aux données
• Ainsi, il peut pré-charger (prefetch) des données en RAM
• NB: le prefetching doit être géré au niveau du SGBD (vs. OS)
– Prefetching
Optimisations logicielles
8
6
T2
T1
Adresse = B+T1+T2
T3
Att3
T4
Att4
N
Page compacte
(pas de trou)
...
Nombre
de tuples
Trou
M ... 3 2 1
Bitmap (0=trous)
Page éparse
1 . . . 0 1 1M
...
9
– la Clé d’un tuple est un «pointeur logique», le Rid est un «pointeur physique»
11
Nombre
d’emplacements
Emplacement M
Emplacement N
Emplacement 1
Emplacement 2
Identifiant d’un tuple (Record id) : Rid = < id page, emplacement #>
Remarque
Emplacement N
Emplacement 1
Emplacement 2
•
•
attribut ⇒ la lecture totale du tuple
Pages : tuples de taille fixe
• Accéder au
ième
– Sont partagées par tous les tuples d’un fichier
– Sont stockées dans le catalogue système
• Les informations concernant les types/tailles d’attributs
Adresse de base (B)
Att2
Att1
Stockage des tuples (attributs de taille fixe)
$
$
Att2
Att3
Att3
$
Tableau d’offsets des attributs
Att1
Att2
$
Att4
Att4
...
16
2
Rid = (i,1)
24
1
Pointeurs d’emplacements
20
N
Rid = (i,2)
12
Pointeur
vers l’espace
libre
Nombre
d’emplacements
N
Page i
• Déplacement des tuples dans la page sans changer le Rid…
Rid = (i,N)
Pages: tuples de taille variable
10
– Un accès direct au ième attribut
– Un petit coût de stockage supplémentaire (taille de «offset» > taille «$»)
• La deuxième alternative offre
Att1
• Deux alternatives de stockage (le nombre d’attributs est fixe):
Stockage des tuples (att. de taille variable)
ID3
3
ID2
2
Dominique
F
– Plusieurs index secondaires possibles par table
• Seuls les Rid des tuples sont «dans» l’index
– Tuples organisés indépendamment de l’index
• Index secondaire ou non plaçant
(secondary or unclustered)
• Souvent construit par le SGBD sur la clé primaire
– 1 seul index primaire par table…
• Les tuples sont stockés «dans» l’index
Tuples
triés sur K
…K2…
Page 1
…K1…
Page 2
Clé K
Psychology
Page 2
Page i
…Kn…
Tuples non triés sur L
…K2…
Page 1
…K1…
Clé L
Page i
…Kn…
15
13
Psychology
Dermatology
ID3
Dominique
Dermatology
ID3
Antonio F M Pediatrics
ID1 Pediatrics ID2
ID1 F ID2 M ID3 F
– Tuples du fichier organisés par rapport à l’index
• Index primaire ou plaçant
(primary or clustered)
3
Antonio
ID3
Catégories d’index (1)
– Optimisation du cache
1
Psychology
Dermatology
3 Dominique F Psychology
F
ID1 Maria ID2
ID1
Dermatology
ID1 ID2 1 2 Maria
Pages disques
• Le modèle de stockage PAX
(Partition Attributes Across)
– Optimisation des I/O
• Le modèle de stockage DSM
(Decomposition Storage Model)
M
Dominique
3
M
Pediatrics
2
F
Maria
Antonio
1
specialty
char(20)
gender
char(1)
first_name
char(30)
id
number(4)
1 Maria F Pediatrics 2 Antonio
• Le modèle de stockage NSM
(N-ary Storage Model)
• Soit la table Doctor suivante
Fichiers non ordonnés
↓
tuple
Page 1
tuple
• NB : Densité d’un index :
tuple
Page 1
tuple
Page 2
nb clés dans l'index
nb clés dans la table
Contient alors la plus grande clé de chaque bloc
+ l'adresse du bloc
– Ne contient pas toutes les clés
– N’adresse pas tous les tuples
(e.g., adresse une seule fois chaque page)
– Nécessite que le fichier soit trié sur les clés
• Index non dense (sparse)
– Contient toutes les clés
– Adresse tous les tuples
• Index dense (dense)
Catégories d’index (2)
Page 2
Page i
tuple
– Table (ou hiérarchie de tables) implémentant cet
accélérateur
• Index
tuple
Page i
16
14
– Créer une structure de données accélératrice associant des
adresses de tuples aux valeurs de clés
• Moyen
• A partir d’une clé (discriminante ou non, mono ou multi-attributs)
• Sur des fichiers ordonnés sur cette clé, ou non ordonnés, ou
ordonnés sur une autre clé
– Offrir un accès rapide à tous les tuples d’un fichier
satisfaisant un même critère
• Objectifs
Indexation
1) en mettant toutes les clés des articles dans un arbre B+ et en pointant sur
ces articles par des adresses relatives ==> INDEX NON PLACANT
2) en rangeant les articles au plus bas niveau de l'arbre B+ ==> INDEX
PLACANT
Arbre-B (B-tree)
Un arbre-B d'ordre m est un arbre tel que:
(i) chaque noeud contient k clés triées, avec m <= k <= 2m,
sauf la racine pour laquelle k vérifie 1<= k <= 2m.
(ii) tout noeud non feuille possède (k+1) fils. Le ième fils contient des
clés comprises entre la (i-1)ème et la ième clé du père.
(iii) l'arbre est équilibré.
Exemple : Arbre-B+
– Peut-on créer un index secondaire (c.à.d, non plaçant) sur
une clé primaire (c.à.d, discriminante) ?
– Peut-on créer un index primaire (c.à.d, plaçant) sur une clé
secondaire (c.à.d, non discriminante) ?
– Peut-on créer un index dense et plaçant ?
– Peut-on créer un index non dense non plaçant ?
• Mais au fait …
Catégories d’index (3)
19
17
18
• Dans la pratique, qu’est ce qui détermine m ?
• Et pourquoi est-ce important que l’arbre soit équilibré ?
20
• h est très important car il détermine le nombre d’E/S nécessaire
pour traverser l’arbre lors d’une sélection
– Soit h=3 pour N=2 millions et m=100
– Soit encore h=3 pour N=250 millions et m=500
h ≤ logm ((N+1)/2)
– pour stocker N clés :
• La hauteur d'un arbre-B est déterminé par son ordre et le
nombre de clés contenues.
Hauteur d'un Arbre-B
(jusqu’à obtenir un index non dense qui
tiennent dans une seule page…)
– On peut continuer…
• Par un second index non dense
(Æ 2ème niveau)
– On indexe l’index
Pourquoi l’index à indexer doit-il être trié ?
– L’index est trié
(mais trop gros Î peu performant…)
• Fonctionnement
– Permet de gérer de gros index
(i.e., très gros fichiers…)
– Principe : chaque index est indexé
• Index hiérarchisés ou multi-niveaux
Index arborescents
XXX
- on double la taille du
répertoire
- on considère un bit de plus
dans chaque signature
Le paquet 01 éclate en
deux paquets 001 et
101
Signature
XXXX
H (KEY)
000
001
010
011
100
101
110
111
00
01
10
11
Répertoire
Répertoire
Paquets
Paquets
Hachage extensible
– Calculer l’adresse du tuple à l'aide d'une fonction de
hachage appliquée à la clé de recherche
– La sélection se fait directement en recalculant cette même
fonction
• Moyen
– Offrir un accès rapide à tous les tuples d’un fichier
satisfaisant un même critère (idem orga. arborescentes)
– Eviter le coût lié à la traversée d’une arborescence
• Objectif
Organisations par Hachage
23
21
1
2
…………
i
Fonction de
hachage
………
n
} Paquets
– Peut-on traiter par exemple (A2 = y) seul ?
– Hachage multi-attributs A1, A2, …An
– Certains attributs peuvent être privilégiés
en leur allouant plus de bits, en positionnant
ces bits en début de chaîne
• Organisations hachées
– Peut-on traiter par exemple (A2 θ y) seul ?
22
h1(A1), h2(A2), … hn(An)
001101001100100100100100011110010100
001101001100100100100100011110010100
24
h1(A1), h2(A2), … hn(An)
– Permet de traiter les critères du type ‘(A1 θ x) AND (A2 θ y) …’
– Tri multi-critères A1, A2, …An
• Ex: Table Médecins fréquemment interrogée sur l’attribut
Spécialité mais également sur l’attribut Adresse
• Organisations arborescentes
Et la gestion multi-attributs ?
• Solution idéale: réorganisation progressive
– Donc des débordements de paquets
– Un fichier ayant débordé ne garantit plus de bons temps d'accès (1 + p),
avec p potentiellement grand
– Il ne garantit pas non plus l’uniformité (prédictibilité) des temps d’accès
• Les fonctions de hachage génèrent des collisions
0
Clé
Hachage statique
↓
– Les prédicats sont tous appliqués
par AND/OR de bitmaps
2
3
8
1
4
7
2
2
2
3
3
3
Jour
Lundi
mardi
mercredi
1
2
3
D1
D1
3
2
2
3
1
1
2
3
4
5
2
2
1
1
2
D2
FACT
id
10010
mercredi
↓
6
1
00001
5
1
01100
Lundi
visitid
IJ
docid
mardi
id
• σ : des sélections sur les dimensions
• ∞ : entre les dimensions et la table de faits
– Utilisé pour les requêtes en étoile
clés = valeur d’attributs d’une dimension
bits = référencent les tuples de Fact
– Pour les schémas en étoile (star schema)
– Stocké sous forme de bitmap
• Star Join index
• Exemple IJDoc,Visit
– Matérialisation d’une association (jointure)
• Join Index
vers Doctor
Index de jointure
• Index sur la clé suivante : P.salaire, P.nom
– Index couvrant
SELECT P.nom
FROM Personne P
WHERE P.salaire > Y;
– Pattern de requête
• Exemple
• Attributs intervenant dans les sélections
• Attributs intervenant dans les projections
– Tous les attributs nécessaires à la requête…
• Attributs à mettre dans l’index couvrant
XL
2
Zouk
Bif
Frank
D3
XXL
1
Berthe
XL
id
Art
Taille
D2
01100
10011
Desc
XXL
vers Visit
– Accès à l’index (sans accès à la relation) permet de
répondre
– Accélération drastique d’un pattern de requêtes particulier
• Construction d’index couvrant une requête
Utilisation d’index multicritères – cas part.
27
…
…
…
25
Art
Berthe
Nurse
Zouk
Art
……
……
Zouk
……
……
……
……
……
Berthe
Art
Zouk
Nurse
……
……
……
……
……
Art
……
Berthe
……
010010010
……
……
000000001
Zouk
……
……
001001000
100100100
Support partiellement emprunté à Pascale Borla Salamet – Oracle France
Oracle
– Peut être vu comme une façon de compresser les listes inversées (listes
de Rid)
1) clé varie sur un domaine de faible cardinalité
2) requêtes multi-critères sans sélectivité dominante
– Utilisé si
• 1 entrée par tuple
1/0 = contient oui/non la valeur ↓
– Index Bitmap = index secondaire dense non trié
– A chaque clé, on associe un bitmap
Index Bitmap
28
26
Granule d’I/O
Idéalement multiple d’un Bloc OS
Granule d’allocation =
Ensemble de blocs contigus
Lieu de stockage d’une
structure :
Table, index, partition de table …
Récipient logique pour
regrouper des objets applicatifs
liés et administrés ensemble
Base de données
Block
Extent
Segment
Tablespace
Database
Logique
Bloc OS
Datafiles
Physique
Organisation des données sur disque
30
32
29
31
Répertoire de tuples (row directory)
Répertoire de table (table directory)
Espace libre (PCTFREE, PCTUSED)
33
Si PCTUSED<40, alors des insertions peuvent à
nouveau être effectuées
SUPPRESSION
Mise à jour
INSERTION (Max 80% du bloc)
PCTFREE=20, PCTUSED=40
35
Utilisation de PCTFREE et PCTUSED
Entête
Tuples (row data)
• Un data block est l’unité de gestion de l’espace disque
• Il est la plus petite unité d’E/S
• Géré indépendamment de son contenu (table, index …)
Data blocs
•
•
•
-> recommandé
– Par le DBA (paramètre du CREATE TABLE)
– Par l’ASS = Automatic Segment Space Management (>Oracle 8i)
Réglage
Si Oracle remet les bloc dans la liste des blocs libre alors que ces blocs disposent de
peu d’espace libre, le coût des insertions nombreuses (de plusieurs tuples) sera très
élevé (jusqu’à 1 IO par tuple inséré)
Pourquoi si fort ? La taille
moyenne d’un tuple suffirait…
– Pourcentage d’occupation minimum d’un bloc en dessous duquel des données
peuvent à nouveau être insérées
– Quand PCTUSED est atteint : le bloc est remis dans la freelist
– 40%, par défaut
Paramètre PCTUSED
36
34
– Pourcentage d’un bloc réservé aux mises à jour futures
– Quand PCTFREE est atteint : le bloc est retiré de la freelist (liste des blocs dans
lesquels il est possible d’insérer de nouvelles données)
Paramètre PCTFREE
PCTFREE et PCTUSED
1
1
1
1
• Table index-organized = index plaçant
• les tuples entiers sont stockés dans les feuilles plutôt que leur Rowid
39
37
• 3 méthodes de partitionnement
40
Exemple
CREATE TABLE sales_hash
(salesman_id NUMBER(5),
salesman_name VARCHAR2(30),
sales_amount NUMBER(10),
week_no NUMBER(2))
PARTITION BY HASH(salesman_id)
PARTITIONS 4
STORE IN (ts1, ts2, ts3, ts4);
Partitionnement des tables (1)
38
• Possibilité de combiner les modes (partitionnement
composite)
Partitionnement des tables (2)
43
41
Index partitionné global
• Un index bitmap partitionné ne peut qu’être local
• Index global non partitionné sur une table partitionnée
Index partitionné local
Partitionnement des index
44
42
Support emprunté à L. Bouganim
Le dictionnaire de données Oracle
47
45
•
•
Evolution du dictionnaire
•
– Vues user de ces tables= présentation lisible dépendant du rôle du user …
• Conservées dans le tablespace SYSTEM
• Compréhensibles par Oracle uniquement
– Tables de base = tables fondamentales contenant les informations sur la BD
Structure
– Utilisateurs (privilèges, rôles)
– Noms et caractéristiques des objets
(tables, vues, index, clusters, triggers, packages, ...)
– Contraintes d'intégrité
– Ressources physiques allouées à la base
– Valeurs par défaut pour des colonnes
– Les autres informations générales sur la base des données
Contient des informations sur la structure de la BD
– Généré au moment de la création de la DB
– Mis à jour automatiquement
Dictionnaire Oracle = tables systèmes en lecture seule
•
Contenu du Dictionnaire Oracle
48
46
•
– Les vues ALL_ contiennent en plus un attribut ‘Owner’
Vues ALL : description des objets logiques visibles par un utilisateur
– …
• Information sur l’utilisateur
– USER_USERS
• Informations sur les vues créées par l’utilisateur
– USER_VIEWS
• Contraintes créées par l’utilisateur
– USER_CONSTRAINTS
• Index créés par l’utilisateur
– USER_INDEXES
• Tables créées par l’utilisateur
– USER_TABLES
Exemples de vues USER_
•
– Objets logiques = tables, index, vues, triggers, procédures…
Vues USER : description des objets logiques créés par un utilisateur
•
Les vues USER et ALL
• Modification du dictionnaire
– Lors des requêtes SQL DDL (Data Definition Language)
• Consultation d’informations sur les utilisateurs et leurs privilèges
• Consultation d’informations sur les objets de la BD
– A la connexion et pendant l’exécution des requêtes
• Utilisé par Oracle
– Consultation d’informations sur la structure de la BD
– Seulement des droits en lecture (SELECT) sur des vues du
dictionnaire
• Utilisé par le DBA et les utilisateurs
Utilisation du dictionnaire
51
49
objets visibles
par le DBA
Les vues DBA (1)
objets visibles
par un utilisateur
objets relatif à
l’audit de performance
6 row(s) selected.
TABLESPACE_NAME
-----------------------------CWMLITE
DRSYS
EXAMPLE
SYSTEM
TOOLS
UNDOTBS
OCCUPE (K)
---------6080
7872
155904
245712
5888
51480
SQL> SELECT tablespace_name, sum(bytes)/1024 "OCCUPE (K)"
> FROM dba_segments
> GROUP BY tablespace_name;
• Ex. La vue DBA_SEGMENTS
– Ayant le rôle DBA
– Ou ayant le privilège système SELECT ANY DICTIONARY
• Décrivent tous les objets de la base
• Accessibles uniquement aux utilisateurs
objets créés
par un utilisateur
Différentes vues
52
50
1 row(s) selected.
TABLE_NAME NUM_ROWS BLOCKS EMPTY_BLOCKS AVG_SPACE
---------- -------- ------ ------------ --------LIVRE
6764
180
19
861
SQL> SELECT table_name, num_rows, blocks,
<
empty_blocks, avg_space
> FROM dba_tables
> WHERE table_name=’Livre’;
53
SQL> SELECT *
GROUP# STATUS
------ -----1
STALE
2
STALE
3
STALE
4
FROM v$logfile;
MEMBER
-----------------------------E:\ORANT\DATABASE\LOG4ORCL.ORA
E:\ORANT\DATABASE\LOG3ORCL.ORA
E:\ORANT\DATABASE\LOG2ORCL.ORA
E:\ORANT\DATABASE\LOG1ORCL.ORA
• V$LOGFILE : détail des fichiers redo-log
SQL> SELECT * FROM V$SGA;
NAME
VALUE
-------------------- --------Fixed Size
49152
Variable Size
12906496
Database Buffers
2048000
Redo Buffers
73728
– Informations sur la «System Global Area» (SGA)
• Ex. V$SGA (voir premier cours...)
Les vues dynamiques V$ (2)
55
USER
INACTIVE
– DBA_FREE_SPACE :
– DBA_SEGMENTS :
– DBA_EXTENTS :
• Structure logique
Description des Extents composant les
Segments de la base de données
Extensions libres dans tous les Tablespaces
Allocation d’espace disque de tous les
Segments de la base de données
V$DATABASE: Statut de la base de données
V$INSTANCE: Détails sur l’instance
V$PARAMETER: Paramètres d’initialisation de l’instance
V$PROCESS: Processus lancés par l’instance et les utilisateurs
V$SGASTAT:
Détail de l’occupation mémoire de votre SGA
• Instance Oracle
–
–
–
–
–
HEURTEL
Quelques vues intéressantes (1)
6
SERIAL# USERNAME
TYPE
STATUS
-------- ------------ ---------- ------1
BACKGROUND ACTIVE
SID
----1
…
8
ADM
--YES
YES
YES
GRANTEE
------DBA
DBA
DBA
...
PRIVILEGE
-------------------ALTER ANY CLUSTER
ALTER ANY INDEX
ALTER ANY LIBRARY
SQL> SELECT sid, serial#, username, type, status
> FROM v$session;
• Ex. V$Session
– Audit et amélioration des performances de la BD
• Usage de ces données
– Evoluent du démarrage de l’instance jusqu’à son arrêt
– Décrivent l’activité de la DB et de l’instance
– Externalisent l’état de variables internes à Oracle
• Vues dont les informations sont «dynamiques»
Les vues dynamiques V$ (1)
SQL> SELECT * FROM dba_sys_privs
> WHERE grantee='DBA';
– Privilèges systèmes octroyés aux utilisateurs et aux rôles
• Ex. La vue DBA_SYS_PRIVS
• Ex. La vue DBA_TABLES
Les vues DBA (2)
56
54
•
•
– Flash disk 3,5’’ : http://www.bitmicro.com/public_docs/products_edide_
datasheet.3.5.pdf
– Flash disk 2.5’’ : http://www.bitmicro.com/public_docs/products_edide_
datasheet.2.5.pdf
– Etude de 2005 : http://www.storagesearch.com/semico-art1.html
– Latence et débit : http://www.bitmicro.com/products_edisk_35_scsiw.php
Sites industriels – Stockage persistent basé sur la technologie FLASH
– Article de recherche : Modeling and Performance of MEMS-Based Storage
Devices (Sigmetrics 2000)
– Lien : http://www.pdl.cmu.edu/PDL-FTP/Storage/sigmetrics2000.pdf
J. L. Griffin et al. – Stockage persistent basé sur la technologie MEMS
– Présentations (voir en particulier les lectures 7 et 8)
– Lien : http://www.cs.rpi.edu/~zaki/cs4380/
Mohammed J. Zaki – Modèle de stockage et d’indexation des données
Bibliographie (2)
– DBA_TABLES : Description des tables relationnelles de la BD
– DBA_INDEXES: Description de tous les index de la BD
– DBA_CLUSTERS: Description de tous les clusters de la BD
• Objets du schéma
•
Liste des fichiers de contrôle de votre BD
Détail des fichiers de données de la BD
Tablespaces de la base de données
– DBA_ROLE_PRIVS :
Rôles reçus et donnés de la BD
– DBA_USERS : Informations concernant les utilisateurs
déclarés de la base de données
– V$SESSION :
Détail de toutes les sessions actives de l’instance
• Utilisateurs et droits
– V$CONTROLFILE :
– V$DATAFILE:
– V$TABLESPACE :
• Structure physique
Quelques vues intéressantes (2)
59
57
•
•
•
•
•
http://www.pcguide.com/ref/hdd/
Lien : http://research.microsoft.com/~Gray/talks/FiveMinuteRule.ppt
•
Lien : http://projets.etudes.ecp.fr/2003-2004/intranetIT/nvSite/Bibi/Folder.2003-06-27.5856/Folder.2003-0330.0033/Innovation%20-%20Centrale.pdf/download
Présentation de Bernard Ourghanlian (Microsoft France)
•
Présentation : « the five minutes rule »
•
http://asi.insa-rouen.fr/enseignement/siteUV/bd/Cours/Supports/BD1/5-Stockage
INSA Rouen – Stockage
Livre : Database Tuning
Lien : http://www.distlab.dk/dbtune/slides/StorageTuning.ppt
–
–
•
•
•
Sun/sunfire.x4100.3.0_tpch.sybaseIQ.100gb.es.pdf
IBM/IBM_595_64_20041118_ESv2.pdf
Sun/sunfire.x4100.3.0_tpch.sybaseIQ.100gb.es.pdf
Sur : http://www.tpc.org/results/individual_results/
Compléments du lien :
Site industriels – Prix du matériel (nouvelles technologies de stockage)
–
–
Dennis Shasha, Philippe Bonnet – Storage Tuning
–
Cours BD
–
–
Jim gray – Evolution du matériel pour le stockage persistent des données
–
Site de vulgarisation – Disques durs
Bibliographie (1)
58