Solaris pour la base de donnés Oracle - Alain Chéreau Oracle Solution Center
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
Solaris pour la base de donnés Oracle Alain Chéreau Oracle Solution Center
Agenda • Compilateurs • Mémoire pour la SGA • Parallélisme • RAC • Flash Cache
Compilateurs • La compilation d'un code et le choix des options de compilations sont importants sur l'efficacité du programme généré. • L'influence du compilateur est également importante. Le compilateur C est également optimisé pour améliorer l'efficacité du code généré pour la base de données Oracle. • La distribution Oracle est unique pour Solaris Sparc et pour Solaris x64 et n'utilise pas les optimisations dépendante du type de CPU.
Allocations mémoire pour la SGA
• ISM : Intimate Shared Memory
– Partage de la table d'indirection entre adresse mémoire du
processus et mémoire physique du server (Shared MMU)
– Segment de mémoire bloqué en mémoire physique
• Simplifie la gestion (pagination, libération)
• Toujours disponible immédiatement
– Gestion de pages de différentes taille et construit la SGA
avec les plus grandes pages mémoires disponibles
• Paramètres systèmes pour les IPC
– Simplification avec Solaris 10 et projets pour éviter les reboots
– Valeurs par défaut souvent suffisanteAllocations mémoire pour la SGA
Virtual Memory
can be swapped
LargeLarge mémoire centrale et caches
• Le 64 bits permet aux processus d'adresser une SGA
de plus de 4GB
• Les volumes des bases de données croissent
énormément
• Les serveurs ont des tailles mémoires de plus en plus
importantes (4TB - M9000)
– De très grande SGA sont possibles
– Flux de données mémoire – CPU dimensionnés
• Mémoire est utilisée en cache filesystem
– Evite des lectures disques (lecture anticipée, cache)
– Information cachée différente
– Stratégies de gestion de cache différentesAgenda • Compilateurs • Mémoire pour la SGA • Parallélisme • RAC • Flash Cache
Parallélisme • CPU multi-cœurs multi threads • Nombre d'unité de calcul dans un serveur explose – Un CPU de serveur en 2011 : 8 à 128 threads – Serveurs de 8 à 512 threads (M9000 – T3-4) • Solaris conçu pour les serveurs multi CPU • Solaris exploite la puissance des threads – Parallélisme applicatif nécessaire pour exploiter cette puissance – Un thread de processus s'exécute sur un thread de CPU • Concevoir parallèle
Parallélisme
• Applications utilisent le parallélisme du serveur
– Multi-processus indépendants ↔ Multi sessions
– Processus Multi-threadés : Java
– Mixte des approches : Apache
– Multi-processus et synchronisation : Oracle parallel query
• Serveurs désormais Non Uniform Memory Access : NUMA
– Croissances des serveurs et des flux imposent des switchs
• Solaris optimise la localisation d'exécution du thread de
processus sur les threads de CPU
– Optimisation par rapport à la dernière exécution (registres)
– Optimisation par rapport à la localisation de la mémoire utilisée
– Optimisation carte IO, interrupt, processServeur parallèle équilibré
• Parallèle CPU – Mémoire – IO
– Flux mémoire, IO dirigés par le nombre de CPU
– IO réparties en
multi-bus
– Réseaux 10Gb
EthernetServeur parallèle équilibré • Parallélisme CPU – Thread process – Thread de CPU
Parallélisme et éléments séquentiels
• Les I/O sont utilisent des canaux séquentiels
– Un port fibre optique émet séquentiellement
– Ethernet est séquentiel par canal
• Les éléments séquentiels impliquent la synchronisation
des threads sur des portions de codes
• Evolutions de Solaris
– Multiplication, nommage et multiples types de verrous (locks)
– Mutex (attente passive), Read-write locks, Memory page locks
– Ajustement des portions critiques
– Sémaphores utilisent les mutex
– Interface des mutex ouvertes aux applications
utilisée par les latchs dans la base de données OracleParallélisme dans la base Oracle
• Parallel server
– Requête lourde, fréquent en décisionnel
– De multiple processus pour réaliser une tâche complexe
• Query slaves = 2 x nombre de threads de CPU du serveur
• 10gR2 : Parallélisme défini au niveau des tables
• 11gR2 : Le mode Automatique fonctionne mieux
– Taille de message par défaut est trop petite, utiliser 16k :
• parallel_execution_message_size = 16384
– Calcul des statistiques des tables et index
• 10gR2 SQL> DBMS_STATS.GATHER_SCHEMA_STATS
(OWNNAME=>'scott',ESTIMATE_PERCENT=>$2,DEGREE=>32);
• 11gR2 : parallélisme par défaut est correct.
– Création, Rebuild d'index
• Create index abc_idx on abc(c1) parallel 8;Parallélisme dans la base Oracle
• Datapump (expdp et impdp)
• expdp system/manager directory=my_dir full=n schemas=gcbc
dumpfile=exp%u.dmp logfile=expdp.log parallel=10
• RMAN utiliser en mode multiple canaux
• DB writers, par défaut démarre un db writer par ensemble
de mémoire et processeurs (Numa)
– Sur certains bases très actives, il arrive que l'on doivent
augmenter le nombre de DB writers.
• Activer le Numa par le paramètre (spfile init.ora)
– Supporté bien que ce soit un paramètre caché
– Depuis la 11.2.0.1: _enable_NUMA_support=TRUE
– Avant: _enable_NUMA_optimization=TRUE
– La SGA est alors découpée en fragment ISM cohérent avec le
nombre d'éléments NumaParallélisme : Multi Base – Serveur partagé
• Conçu pour des machines ayant des partitions Numa de
même taille
– Construire les domaines de serveurs M avec que des élémentss
de même taille, sinon désactiver les optimisations Numa
• Tout est conçu pour une seule base très importante sur
un gros serveur.
– Lors de consolidation de nombreuses bases sur un seul serveur,
penser à limiter le parallélisme de chaque base, ou à utiliser
des pools
– cpu_count est initialisé au nombre de threads du serveur, du pool
d'exécution, le baisser en cas de consolidation
– pour les serveurs T, on utilise souvent cpu_count = 2 x nb coresAgenda • Compilateurs • Mémoire pour la SGA • Parallélisme • RAC • Flash Cache
RAC – Parallélisme multi-serveurs
• RAC est un parallélisme multi-serveurs
– Synchronisation entre les instances
– DLM (premières versions de RAC) implémentées par un travail
conjoint des ingénieries Sun et Oracle
– Remote shared memory : conçu initialement sur Sun Fire Link
• Complémentarité SunCluster – RAC
– Intégration SunCluster – RAC, primitives système permettant la
communication des instances à travers SunCluster et une
forte intégration entre CRS et SunCluster
– Adaptation du filesystem QFS dans SunCluster pour RAC
– Agent SunCluster pour RAC
– Interconnect des noeuds du cluster en équilibrage de charge sur
tous les liens (clprivnet) et ouvert aux applications dont RACRAC – Parallélisme multi-serveurs
• RAC utilise très fortement l'inter-connect du cluster
– Amélioration de l'inter-connect avec gestion de priorité pour les
messages de contrôle interne des clusters (SunCluster comme
Oracle CRS)
– Amélioration UDP
• Jumbo frames sur l'inter-connect
– augmenter le débit et transporter un block Oracle sans découpe au
niveau Ethernet
– Très utile sur les liens 10 Gb Ethernet
– Penser à augmenter le nombre de processus LMS
• Intégration de l'Infini Band d'origine HPC
– IPoIB prise en compte du protocole IP sur les interfaces infini band
– Utilisé dans les machines ExadataRAC – Gestion des Disques
• Disques partagés par toutes les instances
– Cache filesystem impossible, Force directio Obligatoire, le
filesystem utilisable en attachement direct est QFS.
– Raw devices : Ne sera plus supporté
– ASM est la solution préconisée en RAC
• Filesystem partagé par réseau – 'petites' instances
– NFS forte améliorations de performances,
dNFS et modifications des options de montages pour
améliorer les flux de la base de données
– Options de montage minimales imposées par Oracle
– NFS sur ZFS dans les storage appliance (S7000)Agenda • Compilateurs • Mémoire pour la SGA • Parallélisme • RAC • Flash Cache
Carte Mémoire Flash F20
• Capacité 96 GB en 4 domaines
• Optimisé en écriture pour usage en
cache, Base de données ou ZFS
• 100 000 IOPS – 4K, lecture aléatoire
• 87 000 IOPS - 4K, écriture aléatoire
• 1,1 GB/s de débit max
• Service time ~ 0,5 ms
• Performance sensibles à
l'alignement de IO.
• Disque classique :
– 300 IOPS aléatoire
– Service time ~ 7 msUsage de mémoire Flash
Demand Supply
• Stockage
– Volume stable très sollicité
• Temporaire de batch – ETL IOPS
• Cache ZFS S7000
– Dynamique
– Granularité au filesystem (Secondary cache)
MB/Sec
• Oracle Database Smart Flash Cache C
A
(11gR2) C
H
– Dynamique E
milliseconds
– Granularité au segment (Table, Index)Mémoire Flash très efficace
sur application en attente IO
• Chauffe du cache
• Durées divisés par 5; sur ce casSolaris – Base Oracle : Le bon couple
• Solaris est déjà optimisé pour la base de données Oracle
• Les ingénieries Oracle base de données, Solaris et
matérielle continuent à travailler ensemble.
Objectifs :
– Faire bénéficier des innovations, « out-of-the-
box »
– Vous permettre de tirer le maximum de vos
bases de données Oracle sur Oracle
• Une innovation continue... regardez les annonces
d’Oracle Open World
– Quelques mots clés : T4, Solaris 11 & SGBD OracleVous pouvez aussi lire
