TDC EXADATA X4

Chapitre 1

Configuration initiale de la machine

Exadata
 Configuration initiale Exadata

• Dans ce chapitre seront abordés les points

suivants :
- Utilisation de l’outil OneCommand
- Prise en compte des choix structurants dans la
configuration Exadata (stockage, réseau etc …)
- Fichier résultant pour l’installation par Oracle ACS
 Configuration initiale Exadata

• OneCommand est une petite application Java qui

permet de renseigner les différents choix pour
l’installation de la machine Exadata
• Cet outil se télécharge sur MOS (« My Oracle
Support ») :
 Configuration initiale Exadata

• L’outil se présente comme tel (il faut exécuter le

« config.cmd » sous Windows une fois le patch
décompressé) :
 Configuration initiale Exadata

• On renseigne les différents champs (nom de la

machine Exadata, préfixe, suffixe etc …)
 Configuration initiale Exadata

• On sélectionne le type de configuration Exadata

retenue (HP pour Haute Performance donc
disques rapides, HC pour Haute Capacité donc
disques plus lents)
 Configuration initiale Exadata
• Les choix structurants qui sont à renseigner dans l’outil
concernent les éléments suivants :
- O.S : Solaris ou Linux, cela concerne uniquement les
compute nodes car les storage nodes sont toujours sous
Linux.
- Sauvegardes : interne ou externe, en fonction le Disk
Group ASM RECO sera dimensionné en conséquence.
- Niveau de protection : il s’agit de la redondance ASM
(RAID stockage) qui va assurer la continuité de service en
cas de perte de disque et/ou de cellule de stockage, le
choix se fait entre « normal redundancy » (simple-mirorring)
ou « high redundancy » (double-mirorring)
- Plan d’adressage réseau (public, ILOM, KVM, PDU etc
…) serveur(s) DNS et NTP
- Nom SCAN (« Single Client Access Name ») pour la
configuration RAC
 Configuration initiale Exadata
• Il est ensuite nécessaire de lancer l’utilitaire « checkip »
sur le réseau afin de s’assurer que le plan d’adressage
indiqué est correct (résolution DNS, réseau d’admin etc
…)
• C’est à partir du fichier résultant de OneCommand (format
XML) que tous les choix d’installation seront opérés par
Oracle ACS
• La première étape lors de l’installation consiste à
« descendre » l’image de l’O.S sélectionné sur les
compute nodes :
 Chapitre 2

Caractéristiques Principales liées à

EXADATA
Intelligent Storage Grid (Smart Scan)

Réduction des données envoyées au

« DataBase Server » par un facteur 10+
 I/Os Database classiques et
déroulement d’un ordre SQL
• « Full Scan » traditionnel
 Principe « EXADATA Smart
Scan »
• « Full Scan » Intelligent
CELL_OFFLOAD_PROCESSING (CELL_OFFLOAD_PLAN_DISPLAY)
TABLE ACCESS STORAGE FULL
 Intelligent Storage Grid :
Capacité
• Délégation de traitement BDD vers les Cellules

• Filtrage sur les requêtes (« smart scan »)

SELECT nom FROM clients WHERE LENGTH(nom) > 8;
Au niveau colonne : seule « nom » est retournée .

Au niveau prédicat : seuls les noms de longueur > à 8 sont

retournés.

• Délégation des traitements type :

jointures « étoile », fonctions (e.g., « Data Mining », SQL …)
etc.,
décryptage, décompression des données,
création / extensions des fichiers de la base,
optimisation sauvegardes (incr) / restaurations.
Technique de l’ « Exadata Hybrid
Columnar Compression (HCC) » des
données
 Croissance des volumes :
un défi

• Les volumes de données vont en grandissant de

façon exponentielle
– Sans diminuer les performance
– Sans augmenter les coûts

• Nécessite une compression puissante et efficace

EXADATA Hybrid Columnar
Compression
 EXADATA HCC : Son principe
• Organisation des données selon une structure logique (CU)
comprend un ensemble d’enregistrements complets
la compression s’effectue par colonne et non enregistrement
(densité de valeurs similaires forte soit taux de compression élevé)
travail d’équipe avec le « Smart Scan » (délégation du traitement)
différents modes (archivage / space, DWH / speed.
DBMS_COMPRESSION)

• Impact des opérations DML

réorganisation CU mais moindre car compression maintenue
en mode dégradé pour les mises à jour (UPDATE) et les insertions
conventionnelles
Bonne pratique :
optimum pour les chargements en « direct-path » et les mises à jour
réduites.
EXADATA HCC : Sa valeur
ajoutée
Cache intelligent “Exadata Smart Flash
Cache”

sur les cellules de stockage

 Cartes Sun Flash Accelerator
F80

* Utilisation de cartes Flash plutôt que de disques SSD

• élimine les contentions dues au contrôleur disque

* 800 Go de capacité de stockage par carte

• 4 cartes dans chaque cellule EXADATA
• 4 modules de 200 Go par carte
• Optimisée pour le cache de Bases
 Utilisation des cartes Flash

• Une carte FLASH est associée à un disque

cellule (Cell Disk)

• Un disque cellule est utilisé en tant que «Flash

Cache » ou en tant que « Grid Disk »
 Organisation des cartes Flash
• Les cartes Flash physiques sont vues comme des Cell Disks
• Les Cell Disks sont soit
• Ajoutés au Flash Cache
• Partitionnés en tant que Grid Disks pour être vus par ASM
comme du stockage « normal »
 Utilisation des cartes Flash

• Le DBA peut forcer un objet à rester en mémoire

Flash
– ALTER TABLE calldetail STORAGE
(CELL_FLASH_CACHE KEEP)

• Peut être positionné aux niveaux suivants

– Table, Partition, à la création, etc.

• Les Table scans sur les objects marqués avec

l’attribut cell_flash_cache utiliseront également le
Flash Cache
 Cache Intelligent
• Les entrées / sorties sont typées (TAG via iDB)
• Suivant leur type / tag en cache ou pas
• Cache persistent au redémarrage des cellules de stockage
(11.2.3.2.1+)
• NON intrusif dans l’opération d’ entrée / sortie

OUI :
blocs de données / index ( en fonction de leur fréquence de
sollicitation)
r/w fichier de contrôle et en-tête fichiers bdd
un certain contrôle sur son activation (CELL_FLASH_CACHE)

NON :
copies miroir ASM, sauvegardes / restauration, DP, formatage
fichiers bdd
 Write Back Flash Cache

• Placer aussi les écritures en cache – en prévision

de leur futur lecture
• NON intrusif
• Ecritures intensives + « free buffer waits » ;
rapport AWR
• Conditions d’activation (MOS ID 1500257.1)
flashCacheMode (WriteBack / WriteThrough)
Technique « Storage Index » et
partitions
 EXADATA Storage Index : Son
Principe
Pour chaque colonne des blocs accédés fréquemment :
stockage en mémoire des valeurs MINimales,
MAXimales et, NULLES
 EXADATA Storage Index : Son
Gain
• Exemple de gain sur un cas réel
– Pas de Storage Index (les autres bénéfices
d’Exadata sont toujours là)
• Total seconds spent doing IO : 32
• Total GB saved with storage index: 0
– Exadata Storage Index
• Total seconds spent doing IO : 18
• Total GB saved with storage index: 148
– 44% des IO éliminés avec Exadata storage
index
 EXADATA Storage Index : Autre
• Non persistent :
(re-)création interne (en fonction de la fréquence d’accès
bloc)
• Transparent à l’utilisateur / application
• Utilisé avec « Smart Scan »
• Optimum pour prédicats : =, >, <
ET
• Données « rangées » / ordonnées de telle façon que les
valeurs identiques soient regroupées

• Profitent aux requêtes sur des colonnes de tables

partitionnées n’appartenant pas à la clé de partitionnement
DataBase File System (DBFS)
 Généralités

• ACFS n’est pas supporté sur EXADATA

• Pour le remplacer, DBFS
• Système de Fichiers en Base de Données
• Principale utilisation : Chargement de masse
(fichiers plats)
copie des fichiers sur DBFS puis (transformation + )
chargement dans les tables

• Création dans une base dédiée (BIGFILE

tablespace)
Présentation de l’I/O Resource
Management
 I/0 Resource Management

• IORM peut être envisagé et aider dans les contextes suivants :

* Nombreux groupes de consommateurs en base (requêtes ad-

hoc, restitution via des rapports etc …)
* Nombreuses bases de données multi-environnement
(production, développement etc …)
* Actions d’administration concurrentes : sauvegardes, ETL,
calcul de statistiques etc …
* Si les wait events en base concernent principalement les I/Os
(goulot d’étranglement)
* Chargement de données dans une base Data Warehouse
* Modes intra-database (DBRM), inter-database, catégorie et,
combinaison

• IORM apporte une gestion des priorités sur les I/Os afin d’assurer
une performance prédictible.
• L’objectif étant d’assurer des performances optimales en fonction
des besoins.
Configuration de l’Exadata Storage
Server (cellule)
 Un des composants clé de la
machine
• Cellules de stockage (3, 7, 14)
Intelligent Storage Grid
Rôle dans l’architecture
 Configuration matérielle (X4-2)

• Disques physiques : 1,2TB SAS (HP) ou 4TB

SAS (HC)

• Processeurs : 2 x 6-core

• RAM : 96GB (4 x 8GB + 4 x 16GB)

• Mémoire Flash : 4 x 200GB par carte (PCI 3)

4 cartes par cellule
 Organisation des disques
physiques
* Les disques physiques sont appelés Cell Disks une fois pris
en compte par le serveur Exadata
* Les Cell Disks sont partitionnés en un ou plusieurs Grid Disks
* Un Grid Disk est alloué à ASM en tant que ASM Disk
* Les DiskGroups ASM sont crés à partir des ASM Disks (GridDisks)
* Mise en oeuvre transparente pour ASM
 Les GRID DISKS

* Les Cell Disks sont partitionnés logiquement en un ou plusieurs

Grid Disks
• Un Grid Disk est alloué à ASM en tant que ASM Disk
• Il y a au minimum un Grid Disk par Cell Disk
• Il est possible de définir des régions « chaudes » et
« froides »
dans un Cell Disk ou de séparer des bases partageant des
 Disk Group ASM et miroir ASM

• Deux Disk Groups ASM définis

• un pour la partie « chaude », active de la base et un second pour la
partie
« froide » ou inactive
• Le striping ASM distribue uniformément les I/O dans tout le Disk
Group
 Miroir ASM et « Failure
Groups »

• Le mirroring ASM protège contre les pannes disques

• Les Failures Groups d’ASM protègent des pannes de cellu
Création de Grid Disks en flash
 Procédure
• Au prompt « CellCLI » (DCLI)

DROP FLASHCACHE
CREATE FLASHCACHE ALL SIZE=160G
CREATE GRIDDISK ALL FLASHDISK PREFIX=flash
(PREFIX = Bonne pratique)

LIST GRIDDISK
Les Smart Flash Log
 Généralités

• Ecriture des informations de REDO à la fois sur disque et en flash

• Pallier à une éventuelle contention d’écriture sur les REDO LOGS

disque

• Opération d’écriture simultanée sur les deux media (« multiplexage »)

• Validation dès le premier succès

• Configuré par défaut (512MB par cellule)

• Peut être redimensionné (cas rare)

 Redimensionnement

• Au prompt « CellCLI » (DCLI)

DROP FLASHCACHE

CREATE FLASHLOG ALL

(défaut)
ou
CREATE FLASHLOG ALL SIZE=

CREATE FLASHCACHE ALL

Configuration d’ASM et des instances
Oracle pour se connecter aux Exadata
Storage Servers
 Configuration de connexion ASM /
SID aux Cellules

• Pour ASM, ASM_DISKSTRING=‘o/*/*’

• Pour l’INSTANCE, COMPATIBLE=‘11.2.0.0.0’

• Information de compatibilité dans MOS 888828.1

Présentation et mise en oeuvre de la
sécurité de l’Exadata Storage Server
 Généralités
• Contrôler qui (ASM, DB) accède quel(s) Grid
Disk(s) d’une même « Intelligent Storage Grid »

• Associer des « Grid Disks » à une base spécifique

DATABASE-scoped security

• Associer des « Grid Disks » à un cluster ASM

spécifique
ASM-scoped security

• Configurer DATABASE-scoped security implique

configurer ASM-scoped security
 Principe de mise en œuvre
(cellCli)
• Si DATABASE-scoped security alors d’abord ASM-
scoped security

• ASM-scoped security (instances DB et ASM

arrêtées)
* Sur une des cellules, génération d’une clé
(« CREATE KEY ») par cluster
* Assignation de ces clés aux instances ASM
ciblées (« ASSIGN KEY FOR» )
* Mise à disposition des Grid Disks aux instances
ASM ciblées (« ALTER GRIDDISK availableTo»)
 Principe de mise en œuvre
(cellCli)

* Déploiement d’un fichier de configuration

«cellkey.ora» comprenant la clé sur chacun des
noeuds participant au cluster concerné
(«/etc/oracle/cell/network-config/»)

* Redémarrage d’ASM et des instances DB

 Principe de mise en œuvre
(cellCli)
• DATABASE-scoped security (instances DB et
ASM arrêtées)
* Sur une des cellules, génération d’autres clés
(« CREATE KEY »), une par base
* Assignation de ces clés aux bases ciblées
(« ASSIGN KEY FOR» )
* Mise à disposition des Grid Disks aux bases
ciblées (« ALTER GRIDDISK
availableTo=‘<ASM>,<DB>’»)
 Principe de mise en œuvre
(cellCli)
* Déploiement d’un fichier de configuration par base
«cellkey.ora» (droits 640) comprenant la clé
associée sur chacun des noeuds hébergeant
ladite base
(«$ORACLE_HOME/admin/<db_unique_name>/p
file/»)

* Redémarrage d’ASM et des instances DB

 Chapitre 3

I/O Resource Management

 I/O Resource Management

• Dans ce chapitre seront abordés les points suivants :

* Architecture IORM
* Prise en main d’IORM
* Mise en œuvre du Resource Management intra-base et
inter-base
* Positionnement des limites d’utilisation des I/O par
base
* Resource Management inter-base
* Utilisation des métriques I.O des bases
* Resource management et les Exadata Storage Server
Flash Memory
 I/O Resource Management
• IORM apporte une gestion des priorités sur les I/Os afin d’assurer
une performance prédictible.
• L’objectif étant d’assurer des performances optimales en fonction des
besoins.
• Exemple dans un environnement mixte :
 I/O Resource Management

IORM est complémentaire à DBRM (« DataBase Resource

Manager ») dans un contexte Exadata
 I/O Resource Management
• IORM peut être envisagé et aider dans les
contextes suivants :
* Nombreux groupes de consommateurs en
base (requêtes ad-hoc, restitution via des
rapports etc …)
* Nombreuses bases de données multi-
environnement (production, développement
etc …)
* Actions d’administration concurrentes :
sauvegardes, ETL, calcul de statistiques etc
…
* Si les wait events en base concernent
principalement les I/Os (goulot
d’étranglement)
* Chargement de données dans une base Data
 I/O Resource Management
• IORM peut s’implémenter en mode intra-
database ou inter-database :
 I/O Resource Management
• Intra-database
* Ce mode permet de prioriser les ressources (CPU, I/O et
Parallel Server) au niveau session (schéma, service etc
…) dans une base de données.
* Les ressources sont allouées au niveau session
utilisateur par rapport à un plan de ressources
préalablement défini, ce plan définit comment les
ressources sont distribués entre les groupes de
consommateurs de ressources.
* Dans le cadre d’une consolidation de schémas il convient
donc de créer un groupe de consommateur pour chaque
application.
* La gestion des I/Os disques se fait donc en activant
IORM
 I/O Resource Management
• Intra-database
* Un plan de ressource qui gère la CPU est également
utilisé pour gérer les I/Os

* IORM gère les I/Os des cellules Exadata, il permet donc

de prioriser la bande passante en fonction de la
configuration du plan de ressources, c’est donc IORM qui
gère les files d’attentes I/Os sur les demandes de chaque
application en priorisant toujours les I/Os « critiques »
comme « Log File Sync » et les lectures/écritures dans
les fichiers de contrôle par exemple.
 I/O Resource Management
• Intra-database
Exemple :
 I/O Resource Management
• Inter-database
* IORM est aussi utilisé pour contrôler les I/Os
entre les bases de données, toujours au travers
d’un plan de ressources.
* IORM inter-database est configuré à partir des
cellules de stockage via la commande « CellCli »
(« Cell Control Command-Line Interface »)
* IORM permet de partager les ressources I/O
entre les bases de production (avec un objectif
de 100% d’utilisation I/O en termes de
répartition)
* IORM empêche les bases non critiques
(standby, développement, test etc …) d’impacter
les bases de production en termes de
consommation I/O
 I/O Resource Management
• Inter-database
Avec IORM inter-database on peut spécifier les limitations
suivantes :
* Allocation des ressources I/O : les bases de données avec un
score élevé dans le plan de ressource obtiendront plus
rapidement les besoins I/Os
Si aucun plan n’est activé alors toutes les demandes I/Os sont
réparties de manière égale entre les bases de données.
Les I/Os background (processus internes Oracle) sont
automatiquement toujours prioritaires.
* Bande passante disque : on peut limiter l’utilisation I/O
maximale pour chaque base de données, ce qui permet
d’assurer des performances constantes pour les applications
les plus critiques.
* IORM supporte la gestion du flash cache, on peut donc activer
ou désactiver l’utilisation du flash cache par plan de
ressources (« ALTER IORMPLAN flash cache on/off »). Il
 I/O Resource Management
• Inter-database
Exemple :
 I/O Resource Management

• Avant d’implémenter IORM il est fortement recommandé

d’être en version CellSrv Software 11.2.3.3 afin de corriger
tous les bugs référencés par Oracle

• Par défaut IORM est activé en mode « basic », c’est-à-dire

qu’il ne privilégie aucune base par rapport à l’autre, en cas
de forte activité I/O alors il favorisera les « petits » I/Os
(controlfile, redo logs etc …)
• Ensuite les autres modes permettent de spécifier si le type
d’activité est plutôt transactionnelle (OLTP donc favorise la
latence), dataware (favorise le débit) et enfin mixte (DWH
et OLTP)
 I/O Resource Management

• L’implémentation d’IORM (et DBRM) n’est pas anodin et il faut donc

dans un premier temps auditer l’utilisation des ressources disques et
FLASH. Pour cela Oracle met à disposition un script PERL qui permet
de récupérer en temps réel ou en historique l’ensemble des métriques
d’utilisation par base de données. Le résultat est très intéressant car
permet d’affiner les % d’allocations et les limites qui vont être spécifiés
dans le plan de ressources.

• IORM se configure soit en ligne de commande via CellCLI ou

graphiquement via OEM 12c (« Oracle Enterprise Manager »)

• 2 notes MOS très intéressantes sur l’implémentation de :

• IORM :
• DBRM + IORM :
 I/O Resource Management
Comment IORM opère t’il ?
* La limitation des ressources ne prend effet
que si le débit I/O atteint les 100%
d’utilisation
* Un groupe de ressources ou catégorie de
ressources peut disposer de toute la bande
passante tant que le débit ne commence pas
à saturer
* Si le débit I/O commence à atteindre les
100% d’utilisation alors les requêtes I/O sont
mises en files d’attente en fonction des plans
IORM définis
 I/O Resource Management
Comment le scheduler IORM opère t’il ?
* Les requêtes sont systématiquement mises
dans une file d’attente et traitées en fonction
des priorités afin de prévenir une saturation
des disques (comme on peut le voir dans
l’exemple ci-dessous)
 I/O Resource Management
Background I/Os
* Les redo et control file I/Os sont toujours
prioritaires
* Les écritures DBWR appliquent la priorité
spécifié dans le plan
 I/O Resource Management
Allocations IORM
Catégories, inter-database, intra-database
 I/O Resource Management
Activation IORM (intra-database + inter-database)
1. Définir des groupes de consommateur avec
DBRM (assigner les sessions au groupes de
consommateur, manuellement ou via des
règles de mapping)
2. Créer le plan intra-database avec DBRM
3. Créer les catégories avec DBRM
4. Créer le plan inter-database avec CellCLI
5. Activer le plan avec le paramètre
« RESOURCE_MANAGER_PLAN »
6. Activer IORMPLAN sur toutes les cellules
• DBPLAN et CATPLAN
On peut switcher de plan à n’importe quelle moment
(dynamique)
Les plans IORM restent persistants post reboot des
cellules
 I/O Resource Management
Activation IORM via OEM12c
1. A partir du menu « Exadata Storage Server Grid » il
faut sélectionner « Administration » puis « Manage
IO Resource »
 I/O Resource Management
Activation IORM via OEM12c
2. C’est ici que l’on configure les plans
Chapitre 4

Smart Scan
 Smart Scan

• Dans ce chapitre seront abordés les points

suivants :
* Architecture/Prérequis
* Reconnaître un Smart Scan dans les plans
d’exécution SQL
* Jointures Smart Scan avec Bloom Filters
* Cas particuliers touchant le Smart Scan
* Statistiques et Waits de l’Exadata Storage Server
* Utilisation du Smart Scan
 Smart Scan

• Des ressources limitées peuvent conduire à des

problèmes de performance

• Les ressources I/O sont la principale source de

goulot d’étranglement pour une base de données

• Le Smart Scan permet donc de réduire la quantité

de données ramenées par les disques vers les
serveur database
 Smart Scan

Description d’un scan traditionnel

• Un exemple classique : une entreprise TELCO
souhaite identifier les clients qui ont passé un
appel de plus de 200$, le résultat ne représente
que 2MB sur une table qui en fait 1TB :
 Smart Scan

Description d’un scan traditionnel

• Avec du stockage traditionnel (SAN, NAS etc …) toute
l’intelligence base de données réside sur les serveurs
database
• Il faut donc que la base identifie tous les extents qui
contiennent les données demandées
• Le partitionnement de table peut aider à réduite le nombre
d’extents à parcourir
 Smart Scan

Description d’un scan traditionnel

• Le serveur database effectue une requête au système de
stockage permettant de récupérer toutes les données
potentiellement pertinentes
• Le système de stockage renvoie toutes les données au
serveur database (blocs de données)
 Smart Scan

Description d’un scan traditionnel

• Le serveur database doit ensuite trier les données
pertinentes des données non pertinentes (en fonction du
prédicat indiqué dans la requête SQL)
• Le résultat final est envoyé au client
• Cette méthode impose une utilisation accrue des
ressources sur les serveurs database
(CPU, mémoire et I/Os)
 Smart Scan

Description d’un scan Exadata

• L’utilisation du smart scan est complètement transparent
pour les applications
• La même requête SQL est rejouée
 Smart Scan

Description d’un scan Exadata

• La grosse différence est que le serveur database envoi la
requête SQL aux serveur de stockage Exadata
• L’opération de mapping pour rechercher les extents n’a
donc pas lieu
 Smart Scan

Description d’un scan Exadata

• Le smart scan intervient sur les cellules de stockage en
scannant uniquement les blocs de données qui
correspondent aux colonnes/lignes de la requête
 Smart Scan

Description d’un scan Exadata

• Seules les données lignes/colonnes sont renvoyés au
serveur database (avec le smart scan les blocs ne sont
pas retournés au serveur database)
 Smart Scan

Description d’un scan Exadata

• Le serveur database n’a plus qu’à rassembler les données
avant d’envoyer le résultat
• Le smart scan permet d’éviter une saturation de la bande
passante I/O et de la CPU (peu de blocs à manipuler en
mémoire)
 Smart Scan

Plan d’exécution
• Lorsque le smart scan est utilisé l’access path correspondant
(« TABLE ACCESS STORAGE FULL ») est indiqué dans le
plan d’exécution de la requête SQL, exemple :
 Smart Scan

Principaux paramètres d’initialisation

• CELL_OFFLOAD_PROCESSING
– TRUE | FALSE
– Active ou désactive le smart scan et les autres
capacités de stockage smart
– Modifiable dynamiquement au niveau session ou
système (ALTER SESSION ou ALTER SYSTEM)
– Peut se spécifier au niveau d’une requête via le hint
« OPT_PARAM »
 Smart Scan

Principaux paramètres d’initialisation

• CELL_OFFLOAD_PLAN_DISPLAY
– NEVER | AUTO | ALWAYS
– Indique si l’instruction SQL « EXPLAIN PLAN » doit
montrer ou pas les prédicats interprétables par les
serveurs de stockage Exadata
– Modifiable dynamiquement au niveau session ou
système (ALTER SESSION ou ALTER SYSTEM)
 Smart Scan

Monitoring du smart scan

On peut contrôler l’efficacité du smart scan avec
des requêtes sur les vues du dictionnaire :
 Smart Scan
Monitoring du smart scan

* V$SQL statistics
• IO_CELL_OFFLOAD_ELIGIBLE_BYTES
• IO_CELL_OFFLOAD_RETURNED_BYTES
• OPTIMIZED_PHY_READ_BYTES

* Egalement disponible dans les vues

• V$SQLAREA
• V$SQLAREA_PLAN_HASH
• V$SQLSTATS
• V$SQLSTATS_PLAN_HASH
 Smart Scan

Règles de filtrage

• Prédicats supportés :
* >, <. =, !=, <=, =>, IS [NOT] NULL, LIKE, [NOT}
BETWEEN, [NOT]IN, EXISTS, IS OF type, NOT, AND,
OR
• La majorité des fonctions SQL sont supportées
• La liste complète des filtres supportés est
disponible avec la requête suivante :
 Smart Scan

Projection de colonne

• Le smart scan renvoi uniquement les colonnes

spécifiées dans la requête SQL
• Exemple ici avec « SELECT B, D FROM table »
 Smart Scan

Filtre de Bloom
• Un filtre de Bloom est une structure de données
qui permet de déterminer l'appartenance d’un
élément à un ensemble en faisant un compromis
entre la taille mémoire occupée et la précision de
la réponse.
• La nature probabiliste du filtre de Bloom se trouve
dans le fait que des faux positifs (i.e. l'élément X
n'appartient pas à notre Set mais est identifié
comme y appartenant par le filtre) soient possibles
avec une probabilité p, mais pas les faux négatifs.
 Smart Scan

Filtre de Bloom

• Depuis Oracle 10gR2 le filtre de Bloom est utilisé

pour optimiser les jointures parallèles

• Avec Exadata le filtre de Bloom est supporté sur

les serveurs de stockage réduisant ainsi la
quantité de données non nécessaires à renvoyer
au serveur database
 Smart Scan

Smart Incremental Backup

• RMAN utilise le BCT (« Block Change Tracking »)
– Maintient une liste de blocs où les données ont
changées
– Les sauvegardes incrémentales prennent en compte
uniquement ces blocs marqués
• Les serveurs de stockage Exadata améliorent la
granularité sur le suivi des blocs modifiés,
réduisant encore plus la taille des sauvegardes
Chapitre 5

DBFS
 Pourquoi DBFS

• Le chargement dans une base RAC doit

pouvoir se faire de n’importe quel nœud
• ACFS n’est pas compatible avec Exadata
• Les disques systèmes Exadata ne sont
pas adaptés
• NFS ne bénéficie pas de l’infiniband de
l’Exadata
Principe de fonctionnement
DBFS
 Comment configurer
DBFS(database)
• DBFS doit être configuré dans une base de données à
part.
• La base DBFS est crée via DBCA (voir note 1191144.1
pour les détails)
• Unbigfile
create tablespace bigfile
tablespace DBFS doit être
datafile crée : size 32g autoextend on
'+DBFS_DG'
next 8g maxsize 300g NOLOGGING EXTENT MANAGEMENT LOCAL
AUTOALLOCATE SEGMENT SPACE MANAGEMENT AUTO ;

• Un utilisateur doit être créé avec des roles spécifiques

create user dbfs identified by dbfs_passwd default tablespace dbfsts quota
unlimited on dbfs;
grant create session, create table, create view, create procedure, dbfs_role to
dbfs_user;
 Comment configurer DBFS (OS)

• Ajouter le groupe fuse au user servant à

monter le filesystem:
usermod –a –G fuse <user>

• Créer le fichier /etc/fuse.conf (permissions

644) contenant la ligne suivante:
user_allow_others

• Créer le point de montage et donner les

droits au user :
mkdir –p /dbfs
chown <user>:<group> /dbfs
 Comment configurer DBFS
(finalisation)
• Créer le stockage DBFS dans sqlplus:
@?/rdbms/admin/dbfs_create_advanced.sql DBFS mydbfs
nocompress nodeduplicate noencrypt nopartition

• Monter le filesystem DBFS :

$ORACLE_HOME/bin/dbfs_client dbfs@<dbfs_db> -o
allow_other,direct_io /dbfs < passwd.txt

• Pour permettre le montage automatique du

filesystem DBFS, il faut créer une ressource
dans le cluster qui le démarre
automatiquement, voir note 1054431.1 pour
plus de détail
 Chapitre 6

Migrer ses bases vers Exadata

 Objectifs du chapitre

• Lister les différentes méthodes pour

migrer les bases existantes vers Exadata
• Comprendre les avantages
inconvénients limitation de chaque
méthode
 Informations sur la plateforme
Exadata
• La plateforme Exadata est du Intel 64bits
• La version Oracle est 11.2.0.1 ou
supérieure (ASM, RDBMS…)
• Pour des raisons de performance, la taille
des unités d’allocation ASM devrait être de
4Mo (ce qui implique que la taille des
extents database devraient être un multiple
de 4Mo)
 Méthodes de migration logique

• Les méthodes de migration logiques ont

l’avantage de pouvoir fonctionner entre
différentes version d’Oracle et différentes
plateformes
• Elle permettent une réorganisation des extents
en taille multiple de 4M
• Inconvénients : elles ont certaines limitations
au niveau des types de données ou de temps
de bascule
 Standby Logique

• Avantages : permet une bascule rapide,

relativement simple à mettre en œuvre
• Inconvénients : limité au niveau des plateforme
sources possibles et au niveau du type de
données
 Replication Oracle

• Avantages : Très souple au niveau des différentes

plateformes, voire même de différents systèmes de base de
données, permet une bascule rapide.
• Inconvénients : Limitation au niveau du type de données,
relativement complexe à mettre en œuvre, peut impliquer
des couts supplémentaires de licences (Oracle Golden Gate,
DbVisit Replicate, HVR … )
 Datapump

• Avantages : N’a pas de limitation de

version, de type de données ou de
plateforme.
• Inconvénients : le temps de bascule est
dépendant du volume de données
 Méthodes de migration physique

• Méthodes permettant une bascule

relativement rapide et assez simples à
mettre en oeuvre.
• Limité au niveau des plateformes sources,
voire des versions sources supportées.
• Ne permet pas une réorganisation des
données (taille des extents)
 ASM Online Reorganisation

• Avantage : bascule à chaud (après migration d’instance),

simple à mettre en oeuvre
• Inconvénients : la version Oracle doit être identique à celle de
l’Exadata, la base doit être dans ASM, la configuration des
disques ASM ne peut être changée.
 RMAN : Switch to copy

• Avantages: Bascule rapide(quelques minutes), configuration

diskgroup ASM modifiable, simple à mettre en oeuvre
• Inconvénients : Version Oracle identique à celle d’Exadata
uniquement
 Physical Standby

• Avantages : bascule rapide (quelques minutes), assez

simple à mettre en œuvre, configuration diskgroup ASM
modifiable
• Inconvénients : Limité à certaines versions et
plateformes
 Transportable Database

• Avantages : bascule moyennement rapide

(quelques dizaines de minutes), assez
simple à mettre en œuvre, configuration
diskgroup ASM modifiable
• Inconvénients : Limité à certaines
plateformes
 Transportable Tablespace

• Avantages : très peu de limitations au niveau

OS et version d’Oracle, temps de bascule
moyen, configuration des diskgroups ASM
modifiable
• Inconvénients : temps de bascule dépendant
de la volumétrie des données
 Recommandations

• Toujours tester et valider le processus de

migration (et prévoir un retour arrière en
cas de soucis)
• Vérifier l’état des diskgroups ASM
(vérification d’équilibrage)
 Chapitre 7

Consolidation : Best Practices

 Consolidation : Best Practices

• Dans ce chapitre seront abordés les points

suivants :
* Les questions à se poser dans le cadre d’une
consolidation
* Configuration Exadata recommandée pour la
consolidation
* Evolution dans le temps
* Les options Oracle disponibles pour aider à
consolider
 Consolidation : Best Practices
En règle générale les critères de
consolidation sont les suivants :
• Différents SLAs : 24/7 vs 8/5
• Type d’application : OLTP, DW, hybride
• Dimensionnement à des fins de haute-
disponibilité
• Temps de réponse prédictibles
• Type d’environnement : production,
qualification, test etc …
 Consolidation : Best Practices
Options disponibles pour la Database
• Single RAC database
* Placer tous les schémas dans une seule base de
données
* Les + :
o Meilleur contrôle des ressources
o Faible « overhead »
o Supervision/administration simplifié car une seule
database
* Les - :
o Les paramètres d’initialisation sont communs
o Un problème sur une application (donc un
schéma) affecte les autres applications
o Tout migrer dans une seule et même base peut
s’avérer compliqué (interactions possibles)
 Consolidation : Best Practices
Options disponibles pour la Database
• Multiple RAC database
* Déplacer les bases de données avec un minimum de
changement
* Les + :
o Flexibilité sur les différents paramètres et
versions/patchs
o Migration de plate-forme simplifié
o La sécurité (étanchéité entre applications) en est
simplifié
* Les - :
o Contrôle des ressources plus difficile à gérer
o Supervision/administration plus lourde
* Il s’agit du choix le plus commun
 Consolidation : Best Practices
Options disponibles pour le stockage
• Un seul Disk Group ASM sur toutes les cellules
* Répartit les données entre toutes les cellules
* Les + :
o Débit maximum
o Contrôle des ressources centralisé
o Faible « overhead »
o Gestion simplifiée
* Les - :
o La perte de 2 cellules (en « normal redundancy »)
peut causer une indisponibilité
* Option recommandée
 Consolidation : Best Practices
Options disponibles pour le stockage
• Groupes de cellules séparés
* Dans ce cas le but est d’isoler au maximum les
environnements
* Les + :
o Peut supporter plus de pannes simultanées
o Peu de chance qu’une base de données impacte
les autres (performance, espace disque)
* Les - :
o Réduit la bande passante/débit disponible
o Gestion de l’overhead
* Le principal inconvénient est de dimensionner les
différents environnements (spécifiquement pour les
performances)
 Consolidation : Best Practices
Considérations pour la sauvegarde et le
Disaster Recovery
• Sauvegarde
* Ajuster la planification des backup (concurrence etc
…)
* Le matériel actuel peut être amené à évoluer (débit
en entrée/sortie, capacité disque etc …)
* Concilier les différents SLAs si tout merge dans une
seule base de données
• Disaster Recovery
* Un désastre pourrait avoir un impact sur **toutes les
applications hébergées, ce qui peut provoquer des
conflits dans les contrats SLA
* Est-ce que le site de secours est également un
Exadata ? (afin de porter les fonctionnalités
intrinsèques comme le HCC etc …)
 Consolidation : Best Practices
Le meilleur moyen de valider une consolidation
: tester!
• Le plus efficace dans ce contexte : RAT (« Real Application
Testing »)
* Permet de rejouer de l’activité production dans la cible
de migration
* Observer rapidement les écarts de performance entre
chaque tir
• Outils de montée en charge
* Le défi consiste à simuler de l’activité réelle (de manière
automatisée)
* En générale difficile à implémenter avec des coûts
relativement élevés (développement)
• Tests de charge utilisateurs
* Le défi consiste à simuler de l’activité réelle en mode
manuelle (exécution parallèles etc …)
* Retour utilisateur subjectif : plus « lent », plus « rapide »
 Consolidation : Best Practices
Fonctionnalités Oracle
• Les outils pour aider à la consolidation sont les
suivants:
* Database Resource Manager (DBRM)
* I/O Resource Manager (IORM)
* Instance caging
* RAC
* Services
* Database server pools
* RAC One Node
 Consolidation : Best Practices
Fonctionnalités Oracle
Database Resource Manager
• Permet de :
• Partager la CPU entre les différentes
applications
• Contrôler l’utilisation maximale de la CPU par
une application
• Gérer les degrés de parallélisme
• Plusieurs niveau de priorités
• Groupes de consommateurs basés sur les
services, schémas et autres attributs liés à la
session
• Disponible en Enterprise Edition
• Les changements de plans de ressources sont
dynamiques
 Consolidation : Best Practices
Fonctionnalités Oracle
Database Resource Manager
• I/O Resource Manager
• Gestion des ressources I/O inter-database (via
configuration des cellules)
• Gestion des ressources I/O intra-database (via
configuration DBRM)
• L’utilisation des catégories apporte un niveau de
granularité supplémentaire
• Instance Caging au niveau serveur database
• Permet de limiter la CPU utilisé par base de
données (paramètre d’initialisation)
 Consolidation : Best Practices
RAC et ses fonctionnalités
• Evolution et disponibilité
• Services Oracle qui peuvent être définis par :
• Le type d’application
• Groupe d’utilisateurs (DBRM)
• Type d’activité
• Combinaison des précédents
• Pools de serveurs database
• Service associé à un pool de serveurs
• Un serveur (singleton) ou tous
(uniforme)
• Les pools de serveurs ont un nombre
minimum/maximum de serveur
 Consolidation : Best Practices

• Un tableau récapitulatif des options

disponibles pour le provisionnement CPU :
 Consolidation : Best Practices
Considérations à prendre en compte pour le
dimensionnement
• Les besoins en ressources :
• Utiliser AWR pour déterminer les besoins
actuels
• Avoir en tête qu’une Database Machine aura
probablement :
• Des CPUs plus rapides
• Un stockage plus rapide (IOPS)
• Une plus large bande passante réseau (IB)
• Une quantité de données plus faible pour le
traitement CPUs des serveurs database
• Plus de mémoire disponible (« Database Flash
Cache »)
 Chapitre 8

Supervision de l’Exadata Database

Machine
 Supervision Exadata
Les points suivants seront abordés dans ce
chapitre :
• Les solutions logicielles
• Techniques et standards
• Protocoles SNMP, IPMI, ILOM, métriques,
seuils, alertes, ADR
• Aperçu de l’architecture d’OEM
• Configuration d’OEM
• Déploiement des agents et configuration des
cibles
• Supervision des Exadata Storage Servers
• Supervision du réseau Infiniband, du switch
Ethernet CISCO, des PDU, du KVM
• Outils complémentaires :
Exachk, Diagtools, ADRCI, Imageinfo,
Imagehistory, OSWatcher
 Supervision Exadata
Deux solutions permettent de superviser de bout en bout les
différents composants techniques qui composent les machines
EXADATA (serveurs, switchs, cellules de stockage etc …).

Les deux solutions qui couvrent la totalité des besoins en

termes de supervision/administration sont les suivantes :
* Oracle Enterprise Manager Cloud Control (qui succède à
Oracle Enterprise Manager Grid Control) : couvre le scope
serveur/software
* Oracle Enterprise Manager Ops Center : couvre le scope
hardware

Ces deux solutions peuvent être couplés afin de bénéficier

d’une vision globale à partir d’une seule interface.
 Supervision Exadata
Oracle Enterprise Manager

Il s’agit d’une solution de supervision fournie par Oracle

permettant de gérer de nombreuses « cibles » (serveurs, BDD,
cluster etc …)

OEM Cloud Control 12c intègre entre autre les concepts

suivants :
* Capacity Planning
* Exadata Management (via un plug-in spécifique)
* Configuration Management
* Provisioning/Patching, Application Management
* Database Management (administration, tuning etc …)
* Fusion Middleware Management
* Middleware Management and Application Quality
 Supervision Exadata
Oracle Enterprise Manager

La solution OEM Cloud Control s’articule autour de 4 composants logiciels :

• OMR
• OMS
• OMA
• Console

OMR (« Oracle Management Repository ») : il s’agit de la base de données

référentielle où sont stockés toutes les données/métadonnées du Cloud Control

OMS (« Oracle Management Service ») : il s’agit d’applications J2EE qui tournent

sur un serveur Oracle WebLogic

OMA (« Oracle Management Agent ») : il s’agit de l’agent déployé sur le serveur

supervisé, c’est donc lui qui remonte toutes les informations auprès de l’OMS

Console Cloud Control : il s’agit de l’interface Web permettant d’utiliser la solution

OEM Cloud Control
 Supervision Exadata
Oracle Enterprise Manager

Rappel de l’architecture OEM Cloud Control :

 Supervision Exadata
Oracle Enterprise Manager
Le plug-in Exadata permet une administration et supervision unifiée des composants
matériel et logiciel :
 Supervision Exadata
Oracle Enterprise Manager
La couche réseau IB (InfiniBand) est supervisé (débit, surveillance des ports etc …)
avec une gestion des incidents associée :
 Supervision Exadata
Oracle Enterprise Manager
La couche stockage (cellules) est supervisé (débit, latence etc …) avec une gestion
des incidents associée :
 Supervision Exadata
Oracle OPS Center
• OEM Ops Center permet de faire converger toutes les
solutions de gestion des composants hardware des Exadata, il
est un complément indispensable à OEM Cloud Control 12c
• L’objectif étant de gérer l’administration au sein d’une seule
console de management (stockage, réseau, serveurs, Oracle
Linux, switchs).
• Pour ce faire OEM Ops Center communique avec les
interfaces ILOM (« Integrated Lights Out Manager ») des
serveurs et autres équipements afin de les gérer/superviser.
• Au travers d’une interface intuitive on peut donc gérer tous les
composants hardware, OPS Center est également couplé à
OEM Cloud Control 12c afin de récupérer toutes les cibles
(bases, listener etc …) hébergées sur les serveurs.
 Supervision Exadata
Oracle OPS Center
A la différence d’OEM Cloud Control on ne parle pas de cible
(« target ») mais d’actif (« asset ») dans OPS Center
 Supervision Exadata
Oracle OPS Center
L’avantage consiste à consolider tous les accès ILOM au
travers d’une seule interface :
 Supervision Exadata
Oracle OPS Center
Tout comme dans OEM 12c de nombreux métriques
permettent de surveiller en temps réel ou en historique (jusqu’à
6 mois) les différents composants
 Supervision Exadata
Oracle OPS Center
Un aperçu du gestionnaire d’incidents :
 Supervision Exadata
Monitoring manuel des switchs SUN InfiniBand

• Il est également possible de superviser manuellement

les switchs si l’on ne souhaite pas utiliser le protocole
SNMP par exemple.
• Dans ce cas les 2 commandes à connaître sont les
suivantes :

• Il est conseillé de lancer un check toutes les minutes

 Supervision Exadata
Outils d’aide au diagnostic

Oracle fournit un certain nombre d’outils permettant

d’analyser ou collecter les informations dans le but
d’assurer une supervision/diagnostic sur l’état du système.

Il s’agit des outils suivants :

• Exachk
• DiagTools
• ADRCI
• Imageinfo et Imagehistory
• OSWatcher
 Supervision Exadata
Outils d’aide au diagnostic - Exachk
Cet outil permet de :
• Collecter les données d’une Database Machine
(hardware, software, firmware et bases de
données)
• Vérifier que l’environnement installé correspond
aux recommandations Oracle
Exachk est préinstallé sur les compute nodes (dans
« /home/oracle/Exachk ») et également disponible sur
MOS (note 1070954.1) pour obtenir la dernière
version.
Au lancement l’outil est non intrusif et n’altère en rien
les paramètres de configuration, sa consommation
 Supervision Exadata
Outils d’aide au diagnostic - Exachk
Exemple d’exécution :
 Supervision Exadata
Outils d’aide au diagnostic – Exachk
Les fichiers de sorties Exachk sont générés dans un répertoire
horodaté sous l’emplacement où Exachk a été installé.
Les principaux fichiers de sortie sont les suivants :
• exachk_summary.rep : contient le sommaire des
informations, avertissements et notifications d’échecs
• exachk.rep : contient les informations détaillées
correspondant au sommaire du rapport.
Les informations contenus dans ce rapport détaille les
problèmes rencontrés et propose des recommandations.
Il peut également renvoyer vers des notes MOS (« My Oracle
Support »)
Un zip contenant toutes les sorties est automatiquement
généré à la fin de l’exécution pour envoi au support par
exemple.
 Supervision Exadata
Outils d’aide au diagnostic – Diagtools
Diagtools.zip contient 2 scripts pour collecter les traces, logs et
les informations de configuration :
• DbmCheck.sh : collecte les informations de configuration sur
les serveurs de stockage Exadata (cell disks, grid disks,
flash cache etc …)
• diagget.sh : collecte les logs et fichiers trace du software
Oracle (clusterware, ASM, database) plus les informations
O.S de tous les serveurs

Ces scripts sont surtout utilisés pour générer un package

d’information à envoyer au support Oracle
Diagtools.zip est disponible sur MOS (note 735323.1) pour
obtenir la dernière version.
 Supervision Exadata
Outils d’aide au diagnostic – ADRCI

o ADRCI (« Automatic Diagnostic Repository » ) est un outil en

ligne de commande qui permet de structurer et gérer les
données de diagnostic.
o Tout comme les compute nodes les serveurs de stockage
Exadata utilisent également ADRCI, l’utilisation est donc
similaire au RDBMS.
o ADRCI embarque IPS (« Incident Packaging System »), il
permet l'identification et le packaging de toutes les données
de diagnostic pertinentes pour une erreur critique. L’intérêt
étant de pouvoir envoyer ce package au support Oracle.
o L’emplacement par défaut sur les storage nodes est situé
dans
« /opt/oracle/cell<cell_version>/log/diag/asm/cell/<hostname
 Supervision Exadata
Outils d’aide au diagnostic – ADRCI

Exemple d’utilisation sur une cellule de stockage :

 Supervision Exadata
Outils d’aide au diagnostic – ADRCI

Exemple de génération d’un package d’incident :

 Supervision Exadata
Outils d’aide au diagnostic – Imageinfo / Imagehistory

Le software est initialement installé sur les serveurs de

stockage et serveurs database en utilisant une image
spécifique Exadata.
Les bundles patch sont aussi considérés comme des images
software.

Deux commandes permettent de récupérer la version des

images serveur :
• imageinfo : affiche l’information concernant l’image courante
installée sur le serveur
• imagehistory : affiche l’historique concernant les images
installées sur le serveur
 Supervision Exadata
Outils d’aide au diagnostic – Imageinfo / Imagehistory

Il y a une différence sur la sortie des commandes entre les

serveurs de stockage (storage nodes) et serveurs database
(compute nodes), en effet sur les serveurs database il y a
moins d’informations remontées car il n’y a pas de concept
d’image active/inactive, et les serveurs database ne
contiennent pas de device USB (pour le boot) comme sur les
cellules de stockage.
 Supervision Exadata
Outils d’aide au diagnostic – Imageinfo / Imagehistory
Exemple de sortie :
 Supervision Exadata
Outils d’aide au diagnostic – OSWatcher

OSWatcher est une application Java qui collecte et archive

tous les métriques réseaux et O.S pour aider au diagnostic
suite à un problème de performance.
Il s’appuie donc sur des outils système tels que vmstat, netstat
et iostat.

OSWatcher se lance sur tous les serveurs (stockage et

database) avec les paramètres par défaut suivants :
• Snapshots des métriques enregistrés tous les 15 secondes
• Les archives sont stockés 168 heures (7 jours)
• Emplacement d’installation : « /opt/oracle.oswatcher/osw »
• Emplacement d’archive :
« /opt/oracle.oswatcher/osw/archive »
 Supervision Exadata
Outils d’aide au diagnostic – OSWatcher
Exemple de sortie sur les métriques mémoire :
 Supervision Exadata

Outils d’aide au diagnostic

Pour tous ces outils (et bien d’autres encore comme RDA etc
…) la master note correspondante sur MOS est la suivante :
 Chapitre 9

Best Practices pour l’optimisation de

bases sur Exadata
 Optimisation BDD sur Exadata
Les points suivants seront abordés dans ce
chapitre :
• Utilisation de Flash Memory, compression HCC,
index et unités d’allocation
• Recommandations sur l’implémentation de ces
options
 Optimisation BDD sur Exadata
Utilisation de la mémoire Flash
• Exadata Smart Flash Cache
• Améliore l’accès aux données les plus fréquemment
accédées
• Peut être géré automatiquement pour maximiser
l’efficacité (conseillé dans un premier temps)
• On peut également influencer l’utilisation du cache via
des hints
• Aussi bénéfique pour des applications type OLTP que
DWH
• Flash-based permanent storage
• Utiliser la mémoire Flash comme stockage permanent
• Différer les écritures sur disques en stockant directement
sur les cartes Flash (« Write Back Flash Cache »)
• Exadata Smart Flash Log
• Les enregistrements Redo Logs sont temporairement
stockés sur les cartes Flash
• Géré automatiquement par les cellules de stockage
 Optimisation BDD sur Exadata
Utilisation de la compression HCC
• Les bénéfices à implémenter HCC :
• Lectures/écritures de données compressées sur
disque
• Lectures/écritures de données compressées sur
les cartes Flash
• Envoi de données compressées via InfiniBand
• Ecritures de données compressées pour les
Redo Logs et backup
 Optimisation BDD sur Exadata
Utilisation des index
• Les requêtes qui nécessitaient des index sur le
système précédent peuvent avoir de meilleurs
performances sur la Database Machine avec le
Smart Scan
• On peut donc supprimer des index si le Smart Scan
délivre les performances attendues
• Intérêt de supprimer des index non nécessaires :
• Améliore les temps de réponse DML
• Economise du stockage
• On peut simuler l’effet de la suppression d’un index
via la commande SQL suivante :
 Optimisation BDD sur Exadata
Taille de l’unité d’allocation ASM
• Par défaut ASM utilise une taille d’unité d’allocation
(« AU size » ) de 1MB
• Avec les serveurs de stockage Exadata la valeur
recommandée est 4MB
• AU size peut être défini à la création du Disk Group
• AU size ne peut être modifié une fois le Disk Group crée
• AU size se définit via l’attribut du Disk Group
« AU_SIZE »
 Optimisation BDD sur Exadata
Taille minimum d’extent
• Pour les segments volumineux il est fortement
recommandé d’adopter un INITIAL EXTENT à 8MB
• Ceci afin d’éviter la prolifération de nombreux petits
extents dans la base
• Complète la recommandation de la taille « AU size » à
4MB dans les Disk Group ASM
 Chapitre 10

Opération de maintenance Exadata

 Maintenance Exadata

Dans ce chapitre seront abordés les points suivants :

• Arrêt/démarrage de la Database Machine

• Arrêt “propre” d’un seul Exadata Storage Server
• Remplacement d’un disque physique ou d’une carte
Flash
• Déplacement de tous les disques d’un Exadata
Storage Server à un autre
• Utilisation de la procedure “Exadata Cell Software
Rescue”
 Maintenance Exadata

* Les opérations de maintenance sur une Database

Machine sont similaires à toute autre plate-forme
Oracle RAC (« Real Application Cluster »)

* Les opérations sur le cluster GI (Grid Infrastructure :

clusterware + ASM) et RAC sont tout à fait
standard.

* La seule spécificité réside dans le fait qu’il faut

appréhender la couche stockage (serveurs de
stockage Exadata avec la couche intelligente qui en
découle)
 Maintenance Exadata
Arrêt/démarrage d’une Database Machine

La séquence d’arrêt « propre » est la suivante :

1. Serveurs Database (commande O.S) :

2. Serveurs de stockage Exadata (commande O.S) :

3. Arrêt du rack (arrière du châssis au niveau des PDUs), y

compris des switchs réseaux (administration et
InfiniBand)
 Maintenance Exadata
Arrêt/démarrage d’une Database Machine

La séquence de démarrage « propre » est la suivante

:

1. Démarrage du rack (arrière du châssis au niveau des

PDUs), y compris des switchs réseaux (administration et
InfiniBand)

2. Serveurs de stockage Exadata (bouton « Power On »

ou commande « reset /SYS » via ILOM)

3. Serveurs Database (bouton « Power On » ou

commande « reset /SYS » via ILOM)
 Maintenance Exadata
Arrêt/démarrage d’un serveur de stockage Exadata
La séquence d’arrêt « propre » est la suivante :
1. S’assurer que l’arrêt ne rendra pas un Disk Group ASM
« offline » :

2. Positionner tous les disques grid de la cellule inactifs :

3. Vérifier que tous les disques grid sont bien inactifs :

4. Arrêter le serveur de stockage.

 Maintenance Exadata
Arrêt/démarrage d’un serveur de stockage Exadata
La séquence de démarrage « propre » est la suivante :
1. Démarrer le serveur de stockage
* les services CELL démarrent automatiquement au boot

2. Positionner tous les disques grid actifs :

3. Vérifier que tous les disques grid sont bien actifs :

 Maintenance Exadata
Remplacement d’un disque physique endommagé
La séquence de remplacement est la suivante :
1. Déterminer le disque à changer :

2. Remplacer le disque :

3. Vérifier dans ASM que la réallocation du disque est bien

effective :
 Maintenance Exadata
Remplacement d’un disque physique endommagé

Délai de récupération :

* Si le temps de récupération (spécifié via le paramètre

d’initialisation ASM « DISK_REPAIR_TIME ») n’a pas expiré
alors le disque ASM peut être offline (mais non supprimé) et
le Disk Group encore prêt pour l’opération de « rebalancing »

* Dans ce cas l’information est notifié au prompt lors du

remplacement du disque.
 Maintenance Exadata
Remplacement d’une carte Flash endommagé
La séquence de remplacement est la suivante :
1. Déterminer la carte à changer :

2. Arrêter le serveur de stockage concerné

3. Remplacer la carte flash

4. Démarrer le serveur de stockage, si la carte flash est

configuré en disque grid alors vérifier dans ASM la
réallocation :
 Maintenance Exadata
Déplacement des disques d’une cellule à l’autre
L’intérêt d’une telle opération concerne la non disponibilité d’un
serveur de stockage (panne matérielle interne) ou
l’indisponibilité d’un châssis.

Dans ce cadre la procédure à suivre est la suivante :

1. Si possible rendre les disques grid inactifs (« ALTER
GRIDDISK ALL INACTIVE »)
2. Si possible sauvegarder les fichiers de configuration
(‘/etc/hosts’, ‘/etc/sysconfig/network’ etc …)
3. Arrêter le serveur de stockage puis déplacer les disques
(les 2 premiers disques qui hébergent le système
doivent impérativement se situés dans les 2 premiers
slots)
 Maintenance Exadata
Déplacement des disques d’une cellule à l’autre
Procédure – suite

4. Démarrer le serveur de stockage, l’O.S se reconfigure

automatiquement suite à la détection du nouveau matériel.

5. Redémarrer les services CELL via la commande suivante

:

6. Importer les disques CELL via la commande suivante :

 Maintenance Exadata
Utilisation de la procédure “Exadata Cell Software Rescue”

• Chaque serveur de stockage dispose d’un lecteur USB flash

CELLBOOT pour en faciliter la récupération :

* Nécessaire si les disques système subissent une

défaillance simultanée
* A utiliser avec une extrême précaution
 Maintenance Exadata
Utilisation de la procédure “Exadata Cell Software Rescue”

• Pour effectuer une récupération de cellule il faut :

1. Se connecter à la cellule via la console
2. Boot de la cellule et à l’écran lorsque le logo « Oracle
Exadata » apparait il faut appuyer sur n’importe quelle touche
du clavier
3. Dans la liste des options affichées il faut sélectionner la
dernière soit
« CELL_USB_BOOT_CELLBOOT_usb_in_rescue_mode »
puis entrée
4. Sélectionner l’option de récupération
5. A la fin de la récupération s’assurer que le serveur boot bien
sur les disques système (F8 puis sélectionner le contrôleur
RAID)
6. Reconfigurer la cellule : créer de nouveaux disques grid ou
 Chapitre 11

Application de patchs sur Exadata

 Application de patchs

Dans ce chapitre seront abordés les points suivants :

• Description du service Oracle Platinum

• Mise à jour de l’Exadata Storage Server Software
• Mise à jour du Database Server Software
• Utilisation d’OPlan
• Mise à jour d’autres composants logiciels
• Recommandations
 Application de patchs

Service Oracle Platinum

Pour respecter le contrat de support Oracle Platinum il est obligatoire
d’effectuer au minimum 2 mises à jour/an avec un délai d’application
maximum de 6 mois suite à la disponibilité du dernier bundle patch.
Le bundle patch appliqué par Oracle se nomme « Quarterly Full Stack Patch
For Oracle Exadata » et est donc disponible trimestriellement, il est conseillé
de l’appliquer dès sa sortie (soit 4 mises à jour/an).
Il est nécessaire de contacter le support Oracle pour déclencher cette
opération (via l’ouverture d’un SR)
Le support Oracle assure la mise à jour à distance de l’ensemble des
composants matériels et logiciels Exadata (firmware, binaires Oracle, Oracle
Linux etc …), ainsi qu’un certain nombre de bases de données.
Il y a une limitation sur le nombre d’ORACLE_HOME, Storage Software,
bases de données prises en charge.
Le document de référence est le suivant :
http://www.oracle.com/us/support/library/remote-quarterly-patching-scope-
1652890.pdf
 Application de patchs
Vue d’ensemble des composants mis à jour
 Application de patchs
* On compte 3 catégories logicielles qui doivent être mis à jour
:
• Software et firmware sur les serveurs de stockage
• Software et firmware sur les serveur database
• Software et firmware pour les autres composants comme
les switchs InfiniBand

* La compatibilité entre ces 3 catégories doit être assurée

* Les patchs sont autant que possible applicables à chaud

* La note MOS de référence est la suivante :

 Application de patchs
Serveur de stockage Exadata

• Un seul patch est nécessaire pour mettre à jour l’ensemble

des éléments suivants :
* Exadata software, O.S, ILOM et firmware
• Le patch inclus un README ainsi qu’une note support
• La consistance entre les cellules est assurée
• La majorité des patchs peuvent être appliqués à chaud mais
le temps de mise à jour est plus long dans ce cas (cellule par
cellule), si une fenêtre d’arrêt est possible alors il est
recommandé de patcher toutes les cellules d’un coup afin de
limiter le temps de mise à jour
• Aucun logiciel tiers, RPM ou autre ne doit être installé sur les
serveur de stockage
 Application de patchs
Serveur Database

• L’application de patch Database est identique à un

environnement non-Exadata
• OPatch est donc utilisé pour appliquer et gérer les
patchs
• Il est fortement recommandé d’ouvrir un SR (« Service
Request ») au support Oracle afin de vérifier la
compatibilité d’un patch dans un contexte Exadata
• En plus des patchs traditionnels Oracle fournit
périodiquement des Bundle Patchs pour Exadata, il est
recommandé d’appliquer ces Bundle Patchs dès leur
sortie
 Application de patchs
Serveur Database

• Les patchs O.S et firmware sont appliqués de manière

standard (mais toujours se référer à la note MOS
888828.1 afin de valider la compatibilité, surtout avec
OFED * InfiniBand)
• La plupart du temps les patchs pour les serveur de
stockage incluent également les mises à jour pour l’O.S
et firmware des serveur database, par exemple si une
mise à jour de la carte InfiniBand est opérée sur les
serveurs de stockage alors il faut donc obligatoirement
appliquer celle-ci sur les serveurs database
 Application de patchs
Utilitaire OPlan
• OPlan fournit une procédure d’installation pas à pas des
bundle patch avec instructions spécifiques en fonction de
l’environnement, il s’agit donc d’un complément à OPatch
afin d’optimiser la procédure de mise à jour.
• OPlan créée donc les instructions « Apply » et « Rollback »
pour Opatch
• Utilisation de OPlan :
* Valoriser la variable $ORACLE_HOME et lancer la
commande suivante :

* Consulter les instructions d’installation du patch dans ce

fichier :
 Application de patchs
Mise à jour des autres logiciels

Les autres composants Exadata nécessitant une mise à

jour software et firmware sont les suivants :
• Switchs InfiniBand SUN Datacenter
• Power Distribution Units (PDUs)
• Switch KVM
• Switch Ethernet Cisco

Pour la mise à jour de ces composants toujours se référer

à la note MOS 888828.1, surtout en ce qui concerne les
switchs InfiniBand qui sont évidemment très critique dans
ce contexte (communication inter-nœuds + accès au
stockage)
 Application de patchs
Procédure de mise à jour recommandée
1. Consulter la documentation du patch (fichier README)
2. Valider l’installation du patch sur un système de test :
• Lancer un exachk avant et après l’installation du patch
• Automatiser au maximum les étapes d’installation du
patch
• Tester la procédure de retour arrière
3. Valider la fonctionnalité du patch sur le système de test
• Vérifier qu’aucune régression fonctionnelle n’est
observée
• Valider les performances globales
4. Appliquer le patch en production :
• Lancer un exachk avant et après l’installation du patch
• S’assurer que toutes les cellules sont bien « saines »
avant d’appliquer le patch
 Application de patchs
Recommandations pour le système de test

• Il doit être une exacte réplique de l’Exadata de production

• Durant l’application du patch aucune activité annexe ne doit
être en cours
• Il contient une copie complète des données de la
production, avec des statistiques identiques
• Etre capable de reproduire une activité de production
(volume et transactions) sur ce système de test, on peut
utiliser RAT (« Real Application Testing ») par exemple
• Etre capable de comparer les métriques de performance
entre la production et le test patché, on peut utiliser AWR
(« Automatic Workload Repository ») par exemple