Ce cours est destiné à toute personne voulant utiliser efficacement, administrer et mieux comprendre le système Oracle 4





télécharger 320.65 Kb.
titreCe cours est destiné à toute personne voulant utiliser efficacement, administrer et mieux comprendre le système Oracle 4
page20/20
date de publication14.10.2019
taille320.65 Kb.
typeCours
1   ...   12   13   14   15   16   17   18   19   20

WW.Gestion de la mémoire


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 (et le plus efficace) est d'ajouter de la mémoire à la machine afin d'augmenter le plus possible la taille du SGA. Attention, nous l'avons déjà dit : il n'y a pas qu'Oracle qui fonctionne sur la machine. Il faut donc surveiller, au niveau de l'OS que le système ne pagine pas trop.

1.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, BD_BLOCK_BUFFERS, LOG_BUFFER et SHARED_POOL_SIZE.
DB_BLOCK_BUFFER :

nombre de tampons pour les données (200 pour une petites base).
LOG_BUFFER :

taille en octet du buffer pour les Redo log files.
SHARED_POOL_SIZE :

pour stocker les données du dictionnaire. la taille s'exprime en octets. Dans le cas d'un Serveur configuré en parallèle, cette zone est partagée.
La taille totale du SGA dépend de ces valeurs. Plus exactement la taille vaut : SIZE = BD_BLOCK_SIZE*DB_BLOCK_BUFFER + LOG_BUFFER + SHARED_POOL_SIZE.

2.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.

XX.Optimisations de requêtes

1.L'optimiseur intégré


Le serveur Oracle propose un optimiseur de requêtes intégré. Celui-ci propose deux méthodes d'optimisation. La première RULE-BASED-METHOD se charge de trouver un chemin d'accès à la donnée en appliquant un ensemble de règles. Finalement il choisit la possibilité (la règle) qui a le plus haut niveau de priorité. Cette méthode est parfois inadaptée. En titre indicatif, lors d'un SELECT, la règle utilisée de plus bas niveau est de faire un parcours complet de la table. Une règle de niveau un peu plus élevée est de s'arrêter à la première donnée trouvée, si la clé (du WHERE) est PRIMARY KEY ou UNIQUE.


L'autre méthode consiste en l'étude de statistiques sur la table en question. Ces statistiques ne sont pas automatiques et doivent être demandées expressément par le DBA. Le problème, avec cette méthode, est que si la table change avec le temps, les statistiques deviennent erronées.


ANALYSE TABLE table COMPUTE STATISTICS;

ANALYSE TABLE table ESTIMATE STATISTICS;

ALTER SESSION SET OPTIMIZER_GOAL = ALL_ROWS;

ALTER SESSION SET OPTIMIZER_GOAL = FIRST_ROWS;


Il vous est possible de choisir la méthode que vous préférez appliquer. Pour cela, fixer le paramètre d'initialisation OPTIMIZER_MODE soit à RULE soit à CHOOSE.

2.Utilisation d'index et de clusters


Supposons que vous êtes en train de concevoir une base de données. Vous estimez qu'une table sera très utilisée en sélectionnant les lignes selon une colonne bien précise. Il peut alors être judicieux de créer un index sur colonne. En effet, grâce à cet index, Oracle pourra accéder directement les lignes en question tout comme vous accédez les pages d'un livre par l'index.
Pour créer un tel index, sur une colonne d'une table, utilisez la commande suivante.


CREATE INDEX

ON tableName (colName)

TABLESPACE ts;

Pour être le plus optimal possible, il peut être intéressant de séparer les fichiers d'index des fichiers de données sur deux disques différents. Ainsi le Système pourra accéder l'index et les données plus rapidement.
Une autre possibilité d'optimisation consiste à utiliser des HASH CLUSTERS. En créant un cluster, vous définissez une fonction de répartition qui à chaque valeur d'une colonne associe le block dans lequel la donnée doit être stockée. Un tel mécanisme est bien plus performant qu'un index. L'index doit d'abord rechercher la clé dans l'index (accès à un datafile), puis charger le block en question (un autre accès). Avec une table clusterisée, on calcul en mémoire la localisation d'un bloc, puis on va directement le charger.
L'exemple suivant, montre comment créer un cluster et comment l'utiliser.


CREATE CLUSTER clusterName (key DATE)

SIZE 24k

HASHKEYS 10;
CREATE TABLE tableName

(...

key DATE)

CLUSTER clusterName (key);

YY.Conclusion


Nous voyons maintenant mieux comment les choses s'organisent afin d'optimiser le système. Un dernier point permet d'améliorer les performances : utiliser le serveur en mode multi-thread. Cela fera l'objet du dernier chapitre de ce cours. Pour l'heure attachons nous à mieux comprendre ce que l'on doit faire en cas de panne.

  1. Gestion des situations anormales

Dans ce chapitre nous allons nous intéresser aux différents moyens disponibles pour palier d'éventuelles pannes. En effet, une BD peut être soumisse à différentes sortes de pannes (par exemples un crash de disque). Afin de préserver, au mieux, la consistance de la base, divers mécanismes ont été adjoints à Oracle.

ZZ.Les différents types de pannes

1.Panne d'un processus utilisateur


Ce genre de panne intervient quand un utilisateur tue le processus sans avoir terminé une transaction ou lorsque la connexion est rompue. Dans ce cas, vous n'avez rien à faire, le processus PMON se charge de repérer ces processus et d'effectuer un rollback (en utilisant le segment rollback) sur les données utilisées. Le système se retrouve tout seul dans un état consistant.

2.Panne d'une instance


Ce type de panne est plus problématique. Il affecte un certain nombre d'utilisateurs et de transactions. Cette panne peut avoir plusieurs raisons : l'ordinateur ou l'OS se crashe, le DBA arrête une instance avec l'option abord, ...
Le gros problème avec ce genre de panne, est que l'on a perdu le contenu du SGA non encore écrit sur le disque. Dès lors, la seule façon de se retrouver dans un état consistant est d'utiliser les fichiers de Redo log dans une phase appelée recovery.

3.Panne d'un support


Cette panne est assez grave dans le sens ou l'on perd des données. La seule façon de se retrouver dans un état stable est de faire un backup.

AAA.Les backups


Un backup est en fait une sauvegarde de la base à un moment donné. Deux genres de backup sont possibles : le online backup et le offline backup. Dans les deux cas, le backup consiste en la copie des fichiers de données, de contrôle et de redo log, ainsi que le fichier initialisation bien entendu.

1.Offline backup


C'est la façon la plus simple de faire. Il suffit de procéder ainsi :

  • connaître l'ensemble des fichiers de données : SELECT file_name_ FROM sys.dba_data_files;,




  • connaître l'ensemble des fichiers de redo log : SELECT member FROM sys.v$logfile;




  • connaître l'ensemble des fichiers de contrôle : SHOW PARAMETER control_files;,




  • repérer le fichier d'initialisation,




  • arrêter toutes instances et fermez la base de données,




  • copier ces fichiers par le biai de l'OS,




  • la procédure de sauvegarde est terminée.

2.Online backup


Cette procédure est un peu plus complexe. Il faut procéder ainsi :

  • Pour chaque tablespace : (select * from dba_tablespaces;)

    • ALTER TABLESPACE tables BEGIN BACKUP;

    • On récupère chaque fichier de ce tablespace : SELECT file_name FROM sys.dba_data_files WHERE tablespace_name='tables';

    • Copier ces fichiers

    • ALTER TABLESPACE tables END BACKUP;

  • ALTER DATABASE BACKUP CONTROLFILE TO 'dest';

  • Copier le fichier d'initialisation.

Dans cette état, la base de données sauvegardées est inconsistante. Il faut effectuer un recovery (une reprise) de la base, à partir des fichiers de redo log.

BBB.Les recovery


Cette procédure se réalise automatiquement lors d'un démarrage d'instance, afin de rapidement retrouver un système consistant. Cette procédure utilise les fichiers de redo log.
Pour s'y retrouver le système utilise les SCN qui sont affectés à chaque transaction. Ainsi, si les données n'ont pas le bon SCN, on applique les transactions (stockées dans les redo log files avec leur SCN) jusqu'à se retrouver dans l'état final.
Rappelez vous bien que les redo log buffers sont stockés sur les redo log files après chaque COMMIT.

  1. Instances distribuées et instances parallèles

Dans ce chapitre, nous allons voir comment répartir une base de données, puis comment configurer le serveur en mode parallèle.

CCC.Bases de données reparties


Il est parfois nécessaire de répartir les données sur plusieurs machines, chacune d'entre elles ayant sont propre serveur. Dans ce cas, il peut être utile de pouvoir utiliser les données d'une base à partir d'une autre. Pour ce faire quelques tâches d'ordre administratives sont requises. Notez que dans ce cas, l'utilisation du programme SQL*NET est obligatoire.

1.Mécanismes d'accessions


Global DataBase Name :

le nom global d'une BD est constitué du nom de la base et du nom de domaine de la machine (le deux séparés par un point).
Database link :

ce lien permet de créer une connexion entre deux bases. Il pourra ensuite être utilisé. Cependant, le nom global peut être fastidieux à écrire.


CREATE PUBLIC DATABASE LINK

base.machine.societe.fr;
SELECT * FROM user.table.base.machine.societe.fr;
SELECT db_link FROM all_db_links;


Synonyms :

pour simplifier les choses, vous pouvez définir des synonymes sur des liens.


CREATE PUBLIC DATABASE LINK

base.machine.societe.fr;

CREATE SYNONYM base

FOR base.machine.societe.fr;

SELECT * FROM user.table@base;

2.Réplication de données


Dans un modèle répartit, il se peut que des données soient momentanément inaccessibles. Afin de ne pas gêner les éventuels utilisateurs, il vous est possible de répliquer les données d'une base en créant un SNPASHOT.
Les snapshot ne sont pas mis à jour régulièrement, mais à des intervalles précis nommés asynchronous replication. Ces instants sont précisés par le paramètre NEXT de la commande CREATE SNAP SHOT (dans l'exemple, tout les jours).


CREATE SNAPSHOT snapshotName

REFRESH COMPLETE

START WITH sysdate

NEXT sysdate+1

AS SELECT * FROM user.table@base;

Un snapshot est par défaut READ-ONLY. Si vous voulez que ce dernier soit modifiable, il vous faut créer un "updatable snapshot". La création est quasiment la même à un détail près

CREATE SNAPSHOT snapshotName FOR UPDATE

REFRESH COMPLETE

START WITH sysdate

NEXT sysdate+1

AS SELECT * FROM user.table@base;

DDD.Instances parallèles


Nous allons maintenant voir qu'il est possible de configurer le serveur en un mode dit parallèle, dans le sens ou plusieurs instances vont pouvoir travailler conjointement sur une même base. Quant on parle de plusieurs instances, on parle donc de plusieurs SGA, et de plusieurs processus de natures diverses, qui cohabitent sur la même machine.
Cependant quelques tampons sont partagés (pour le data dictionary par exemple). Il faut bien entendu avoir une machine multiprocesseur pour en tirer avantage.
Il y a plusieurs avantage à configurer le serveurs en parallèle, et notamment le fait que si une instance a un problème, le serveur peut continuer à accepter des requêtes. Cela peut être important si la base doit pouvoir être accédée 24H/24.

1.Initialisation du serveur


Deux paramètres servent dans la configuration du serveur en mode parallèle :

PARALLEL_DEFAULT_MAX_SCANS et PARALLEL_DEFAULT_SCAN_SIZE.
PARALLEL_DEFAULT_MAX_SCANS :

définit le nombre de requêtes serveur utilisées pour résoudre une requête.
PARALLEL_DEFAULT_SCAN_SIZE :

définit le nombre de blocks que chaque requêtes serveur peut scanner pour solutionner une requête.
Exemple : si une table comporte 500 blocks et que ce paramètre vaut 100, il faudra 5 requêtes serveurs.

2.Contrôle au niveau des requêtes


Il vous est possible de spécifier les chose aux niveaux des requêtes. Pour mieux comprendre les choses, regardez un peu les exemples suivants.

CREATE TABLE tableName

(...)

PARALLEL 4;
ALTER TABLE tableName

PARALLEL 5;



Page sur
1   ...   12   13   14   15   16   17   18   19   20

similaire:

Ce cours est destiné à toute personne voulant utiliser efficacement, administrer et mieux comprendre le système Oracle 4 iconBibliographie sélective Table des matières introduction generale...
«Santé publique» et est destiné aux étudiants en deuxième année de graduat en Sciences Infirmières pour toute les orientations

Ce cours est destiné à toute personne voulant utiliser efficacement, administrer et mieux comprendre le système Oracle 4 iconLa Loi du 27 décembre 1973 tendant à assurer, en cas de faillite,...
«tout commerçant, toute personne inscrite au répertoire des métiers, tout agriculteur, toute autre personne physique exerçant une...

Ce cours est destiné à toute personne voulant utiliser efficacement, administrer et mieux comprendre le système Oracle 4 iconCours très important pour bien comprendre la pathologie expliquée...
«Il y aura probablement une question sur mon cours pour le contrôle de la rentrée, je ne peux pas vous l’assurer, mais habituellement...

Ce cours est destiné à toute personne voulant utiliser efficacement, administrer et mieux comprendre le système Oracle 4 iconLe dispositif d’annonce
«Toute personne a le droit d’être informée sur son état de santé […] Cette information incombe à tout professionnel de santé […]...

Ce cours est destiné à toute personne voulant utiliser efficacement, administrer et mieux comprendre le système Oracle 4 iconCours : Oracle ™

Ce cours est destiné à toute personne voulant utiliser efficacement, administrer et mieux comprendre le système Oracle 4 icon2. 1 Qu’est ce qu’un déchet radioactif ?
«qu’est un déchet au sens de la présente loi tout résidu d’un processus de production, de transformation ou d’utilisation, toute...

Ce cours est destiné à toute personne voulant utiliser efficacement, administrer et mieux comprendre le système Oracle 4 iconPourquoi evaluer ?
«… Toute personne a le droit de recevoir des soins visant à soulager sa douleur. Celle-ci doit être en toute circonstance prévenue,...

Ce cours est destiné à toute personne voulant utiliser efficacement, administrer et mieux comprendre le système Oracle 4 iconMieux comprendre l’insomnie des personnes âgées

Ce cours est destiné à toute personne voulant utiliser efficacement, administrer et mieux comprendre le système Oracle 4 iconTribunal administratif de marseille
L’accès du terrain est donc interdit à toute personne utilisant un de ces abris, soit

Ce cours est destiné à toute personne voulant utiliser efficacement, administrer et mieux comprendre le système Oracle 4 iconMieux comprendre les conflits sociaux en sept points





Tous droits réservés. Copyright © 2016
contacts
m.20-bal.com