CC30 Certificat de compétence Conception, développement
Transcription
CC30 Certificat de compétence Conception, développement
CC30 Certificat de compétence Conception, développement et animation de sites Web UE RSX053 Introduction aux bases de données Séance 11 UERSX053 – Introduction aux bases de données– Séance 10 - 23/04/2009 1 Table des matières 1. L’administration, Deuxième partie. ................................................................................... 3 1.1. Le dictionnaire de données......................................................................................... 3 1.1.1. Présentation ........................................................................................................ 3 1.1.2. Les différentes vues............................................................................................ 3 1.1.3. Exemples ............................................................................................................ 4 1.2. Commande Show ....................................................................................................... 6 1.3. Les curseurs................................................................................................................ 6 1.3.1. Le traitement SQL.............................................................................................. 7 1.4. Traces ......................................................................................................................... 9 1.4.1. Tracer une cession .............................................................................................. 9 1.5. Killer des sessions .................................................................................................... 17 1.6. Les jobs .................................................................................................................... 18 1.7. Import/Export ........................................................................................................... 19 1.7.1. Utilité................................................................................................................ 20 1.7.2. Caractéristiques principales.............................................................................. 20 1.7.3. export : généralités ........................................................................................... 20 1.7.4. export : Description des paramètres ................................................................. 20 1.7.5. import : généralités........................................................................................... 21 1.7.6. import : paramêtres........................................................................................... 21 1.8. exemples d'export et d'import................................................................................... 22 2. Sécurité :........................................................................................................................... 23 2.1. Les piliers de la sécurité des systèmes en général et des SGBDs en particulier ...... 24 2.2. Les mécanismes mis en oeuvre pour la sécurité ...................................................... 25 2.3. Les principales menaces........................................................................................... 27 2.4. Les principales failles de sécurité...ou de comportement......................................... 28 3. SOURCES........................................................................................................................ 31 UERSX053 – Introduction aux bases de données– Séance 10 - 23/04/2009 2 1. L’administration, Deuxième partie. 1.1. Le dictionnaire de données. 1.1.1. Présentation Le dictionnaire de données Oracle représente le coeur de la base de données. Il s'agit d'un ensemble de tables systèmes contenant les informations relatives à la structure de la base de données : • • • • Utilisateurs de la base (ainsi que leurs privilèges et leur rôle) Noms et caractéristiques des objets contenus dans la base (tables, vues, index, clusters, triggers, packages, ...) Contraintes d'intégrité Ressources physiques allouées à la base Le dictionnaire est créé au moment de la création de la base et est mis à jour. Il appartient à l'utilisateur SYS, mais l'utilisateur SYSTEM, c'est-à-dire l'administrateur de la base, possède des droits de lecture sur des vues du dictionnaire. Enfin le dictionnaire de données est conservé dans le tablespace SYSTEM. Les vues les plus couramment utilisées sont des vues statiques. Elles décrivent les : tablespaces, fichiers physiques, tables, contraintes, clusters, vues, index, synonymes, procédures, fonctions, packages, triggers, utilisateurs, droits d'accès, rôles, profils, audits, etc... Il existe également des vues dynamiques, concernant essentiellemnt les ressources système en cours d'utilisation, les ressources Oracle en cours d'utilisation, les sessions connectées, les verrous, etc. C'est ce qu'on appelle les vues et tables virtuelles. 1.1.2. Les différentes vues. Le dictionnaire est composé de vues. De nombreuses vues permettent à des utilisateurs d'accéder à certaines parties du dictionnaire de données. Les vues fournissent à l'administrateur de la base le meilleur moyen pour obtenir les caractéristiques techniques de celle-ci. UERSX053 – Introduction aux bases de données– Séance 10 - 23/04/2009 3 Les vues du dictionnaire de données sont classées par famille et nommées en fonction de l'appartenance à une de ces familles. Voici la liste de ces familles de vues : • • • • Les vues USER (dont le nom commence par USER_) donnent des informations sur tous les objets logiques dont l'utilisateur connecté est propriétaire (tables, index, vues, procédures, ...) Les vues ALL (dont le nom commence par ALL_) fournissent des informations sur les objets pour lesquels l'utilisateur a un droit d'accès, c'est-à-dire les objets de la base créés par l'utilisateur ainsi que tous les objets accessibles par cet utilisateur. Les vues DBA (dont le nom commence par DBA_). Ces vues sont réservées à l'administrateur de la base (DBA, DataBase Administrator) afin de lui fournir des informations sensibles sur tous les objets de la base de données. Les vues V$ (dont le nom commence par V$_) sont des vues dynamiques permettant d'avoir des informations sur l'état courant de l'instance de la base de données de son démarrage à son arrêt. Elles permettent par exemple de connaître les fichiers physiques actuellement utilisés par la base (logs, rollback segments, ...). 1.1.3. Exemples 1.1.3.1. Exemple 1 La requête permttant de trouver quelle table utilise "id_client" : select column_name, table_name from all_tab_columns where column_name = 'ID_CLIENT'; 1.1.3.2. D’autres exemples : select select select select select select * * * * * * from from from from from from user_tables; dba_tables; all_tables; user_indexes where table_name = ‘MaTable’; all_indexes where table_name = 'MaTable'; all_ind_columns where index_name = 'PK_MaColonne'; 1.1.3.3. Exemple 3 J’ai récemment utilise par exemple dans un script un dictionnaire de données pour extraire les colonnes d’une table donnée. En effet, la structure de ma base évolue régulièrement, et mon script doit continuer à prendre en compte les colonnes ajoutées ou supprimées dans la table qui l’occupent. Comment ai-je fait ? UERSX053 – Introduction aux bases de données– Séance 10 - 23/04/2009 4 select * from all_tab_columns where table_name= MaTable and owner=upper(t_owner) order by COLUMN_ID Je sélectionne ainsi l’ensemble des colonnes de la table Matable pour le schema t_owner, mon script continue à fonctionner même si MaTable change de structure. 1.1.3.4. Exemple de vues sur les utilisateurs Nous avons vu plus haut ce qu’était un utilisateur. A présent, il est possible de consulter les informations sur un utilisateur : SELECT * FROM all_users; -- pour connaitre le nom des utilisateurs sur la base de données courante, celle sur laquelle la requête est exécutée. Cela permet aussi d’avoir la date de création SELECT * FROM sys.dba_sys_privs; --Pour connaitre les privileges. Mais un outil comme toad offer cette visualisation aussi par exemple. SELECT table_name, privilege, grantable FROM sys.dba_tab_privs WHERE grantee=’votreLogin’; SELECT grantee, table_name, column_name, privilege FROM sys.dba_col_privs; SELECT * from session_privs; SELECT * FROM session_roles; SELECT * FROM sys.dba_roles; SELECT * FROM role_sys_privs WHERE role=’LICENCE07’; 1.1.3.5. Exemple 5 Comment retrouver la liste des tables d'une base ? SQL> SELECT 2 OWNER, 3 TABLE_NAME, 4 TABLESPACE_NAME, 5 NUM_ROWS, 6 BLOCKS, 7 EMPTY_BLOCKS, 8 LAST_ANALYZED 9 FROM DBA_TABLES 10 WHERE OWNER = 'FD' ; OWNER TABLE_NAME TABLESPACE_NAME NUM_ROWS EMPTY_BLOCKS LAST_ANA ---------- -------------------- --------------- ---------- ---------- ------------ -------FD CONTACT USERS 2 5 0 03/12/02 FD DEPT USERS FD EMP USERS FD EMPLOYE USERS FD FACTURE USERS BLOCKS UERSX053 – Introduction aux bases de données– Séance 10 - 23/04/2009 5 1.2. Commande Show Voici une commande utilisée en ligne de commande pour Oracle et qui vous donnera la réponse à des questions courantes lors d’une consultation sous sql*plus, l’outil d’interrogation sql d’ORACLE : Show User Indique l’utilisateur connecté. Show errors Affiche les erreurs de la dernière fonction/procedure/package/type compilé et exécuté. Il en existe plein d’autres comme le format d’affichage de la langue ou des dates, le chemin par défaut des exécutables ORACLE et d’autres interrogations tout autant existentielles. Mais le but est de vous donner le meilleur comme toujours ! 1.3. Les curseurs Toute instruction SQL est traitée par ORACLE en tant que curseur. Définition : Un curseur est un objet qui permet à ORACLE de résoudre quelques problèmes d’interprétation, d’exécution, de partage et de performance. Le curseur consiste en un ensemble de zones mémoire dont la SGA, plus précisément le shared pool. Quand une session doit exécuter un curseur qui est déjà partagé dans le shared pool, il s’agit d’un mécanisme de cache en quelque sorte, de chargement. Le phénomène de chargement est gourmand en ressources (c’est pour éviter la consommation de ces ressources employés que le cache est utilisé). Idéalement, pour une instruction SQL, un seul chargement (initial est nécessaire) même dans le cas des millions d’exécutions. UERSX053 – Introduction aux bases de données– Séance 10 - 23/04/2009 6 1.3.1. Le traitement SQL 1.3.1.1. Les trois phases de traitement SQL Nous allons étudier la façon dont est exécuté un ordre SQL transmis par le process utilisateur. Il y a trois phases : • Parsing (analyse en français) • Execute • Fetch. (extraction en français) Globalement : • PARSE Cette étape convertit l’instruction SQL en plan d’exécution. Elle vérifie également que l’utilisateur bénéficie bel et bien des autorisations appropriées et que les tables, colonnes et autres objets de référence existent. Il a également une vérification syntaxique EXECUTE Cette étape correspond à l’exécution effective de l’instruction par le serveur Oracle. - Insert , update et Delete cette étape modifie les données ( et effectue les tris nécessaire ). - Select : cette étape identifie les lignes concernées FETCH Cette étape extrait les lignes par une requête et effectue le tri nécessaire. Cette partie ne concerne donc que les instructions SELECT. • • 1.3.1.1.1. Parsing et optimisation Durant cette phase, ORACLE transforme la chaîne de caractères que vous croyez être ‘un ordre SQL’ en une requête intelligible par son noyau. Quelques étapes sont franchies lors du parsing : • • Vérification de la syntaxe de l'ordre SQL. Recherche dans le dictionnaire de données des informations : L’existence et les structures des objets référencés. Les droits de l'utilisateur sur les objets référencés. Les différents chemins d'accès (indirectement). • Traduction des noms employés (synonymes qui représente un objet, une table sous un autre nom, permettant ainsi de lui donner des droits et une visibilité propre grâce à la gestion de privilèges). • Mise dans le library cache de la requête SQL. UERSX053 – Introduction aux bases de données– Séance 10 - 23/04/2009 7 Cette étape est extrêmement gourmande en ressources. Il est important de noter qu’à ce stade, le curseur (l’ordre SQL) est réellement stocké dans la shared pool, mais il n’est pas partagé, il est partageable. Il deviendra partagé lors de l’utilisation du curseur par une autre session lorsqu’un ordre identique devra s’exécuter. A l'aide des informations ainsi collectées, ORACLE élabore un plan d'exécution. Ce plan d'exécution est ensuite stocké dans la SHARED POOL. Il sera partagé par tous les utilisateurs qui effectueront le MÊME ordre SQL. Le mécanisme de partage tire profit d’un algorithme de hachage qui est appliqué à l’intégralité du texte de l'ordre SQL : • La valeur calculée est comparée aux valeurs des autres ordres SQL déjà présents dans la SHARED POOL. • Si les valeurs de hachage sont identiques, les textes des curseurs qui partagent la même chaîne de valeurs sont comparés avec le texte actuel. • Si aucun texte n’est identique, il constituera un père pour tous les futurs ordres SQL identiques. Un enregistrement enfant est également constitué. • Si le texte est identique, il constituera une occurrence supplémentaire dans la liste des ‘enfants’ qui ont un père commun. Dans ce cas, des vérifications supplémentaires sont effectuées concernant les variables, l’authentification de l’utilisateur, la résolution des synonymes, etc. En conclusion, pour partager un curseur, les ordres qui interrogent les mêmes données doivent être IDENTIQUES ! C’est pour ceci qu’idéalement les ordres souvent passés devraient passer par des procédures stockées : une procédure stockée présentera toujours le même texte au noyau, donc elle aura toujours le même résultat à la fin de la fonction de hachage. D’un autre point de vue, les procédures stockées offrent l’avantage d’être enregistrées avec le plan d’exécution, ceci réduit énormément l’étape de parsing. Globalement, le parsing est une étape gourmande en ressources et actions. En conséquence, une des actions importantes de l’optimisation de la base de données est l’optimisation des ordres SQL. Un des buts souhaités est de minimiser le parse et load des requêtes. Hit ratio du parse Des informations concernant les diverses étapes de l’analyse sont disponibles dans quelques vues du dictionnaire de données: V$LIBRARYCACHE, V$SQLAREA, V$SQL. Comme spécifié dans les paragraphes précédents, le rapport hard parses/soft parses devrait avoisiner 0. La requête suivante calcule le parse hit ratio, indicateur convenable des performances du library cache, reflet de la ‘bonne écriture des ordres SQL’ : Select 100*gethits/gets from V$LIBRARYCACHE where namespace = ‘SQL AREA’; Le résultat de cette requête devrait avoisiner 100 pour-cent (résultat impossible, au moins un hard parse est à faire pour chaque curseur). Quelques paramètres de la vue V$SQLAREA sont essentiels pour déterminer les divers problèmes d’analyse : LOADS Nombre d’interprétations de l’ordre SQL. Un minimum de loads (valeur à un) est souhaitable. VERSION_COUNT UERSX053 – Introduction aux bases de données– Séance 10 - 23/04/2009 8 Un même ordre SQL (en-tête du curseur) peut avoir plusieurs enfants (corps du curseur), en fonction de la résolution différente des synonymes, variables bind, etc. Durant la phase d'exécution de l'ordre SQL, le process SERVER : • Applique le plan d'exécution aux données lues (qui se trouvent donc dans les buffers de données, en SGA). • Effectue des lectures physiques depuis les fichiers de données ou des lectures/écritures en mémoire. 1.3.1.1.2. Fetch Pendant la phase de 'Fetch', les enregistrements sont transférés depuis les buffers de données vers le process utilisateur. Je vous passe le tuning de la mémoire Shared Pool à ce niveau…. 1.4. Traces 1.4.1. Tracer une cession Il est possible de tracer une session sous Oracle. Une session est l’ensemble des activités d’un utilisateur connecté à un schéma ORACLE. Cette trace permet de voir les requêtes exécutées ainsi que les temps d'exécution de chacune des étapes qui composent d’exécution d’une requête (parse, execute et fetch vus plus haut). Pour lancer une trace vous pouvez utiliser la commande SQL*Plus : oradebug. D'abord, recherchons le spid de la session en question, c'est-à-dire son identifiant : SELECT spid FROM v$process a, v$session b WHERE a.addr = b.paddr AND sid = &sid; Celui est consultable via une interface graphique telle que fournie par TOAD par exemple. Mais sachez que de façon jacente une requête SQL est à l’origine de cette information. Le spid permet alors de positionner oradebug et lancer la trace proprement dite. Connectezvous sous l'utilisateur SYS et lancez (en mentionnant votre spid) : SQL> oradebug setospid 2961508 UERSX053 – Introduction aux bases de données– Séance 10 - 23/04/2009 9 Oracle pid: 48, Unix process pid: 2961508, image: oracle@canebiere (TNS V1-V3) SQL> oradebug event 10046 trace name context forever, level 8 Statement processed. SQL> La trace de niveau 8 (le niveau permet de tracer plus ou moins de détail) est en cours. Un fichier trace doit être créé dans le répertoire indiqué par le paramétre user_dump_dest. SQL> show parameter user_dump NAME TYPE VALUE ------------------------------------ ----------- -----------------------------user_dump_dest string /oracle/admin/orafrance/udump Pour arrêter la trace vous devez lancer la commande suivante : SQL> oradebug event 10046 trace name context off Statement processed. 1.4.1.1. Analyse de la trace L'opération précédente a généré un fichier de cette forme : Imbuvable, illisible. Heureusement, Oracle fournit un outil pour formater ce fichier pour faciliter la lecture, cette outil s'appelle tkprof. 1.4.1.2. TKPROF Ici nous aborderons l’aspect mise en œuvre du produit, ou comment formater le fichier trace que l’on a obtenu en sortie. TKPROF est un binaire. Il ne peut donc être appelé sous SQL*PLUS. Pour l’exécuter il suffit de lancer une fenêtre de commande et d’appeler le binaire. Ce dernier se trouve dans le répertoire suivant: Unix $ORACLE_HOME/bin $ cd $ORACLE_HOME/bin $ ll tkprof -rwxr-x--x 1 oracle dba 8204288 Jun 18 2004 tkprof Window C:\ > cd %ORACLE_HOME%/bin UERSX053 – Introduction aux bases de données– Séance 10 - 23/04/2009 10 C:\oracle\ora92\bin>dir tkprof* Répertoire de C:\oracle\ora92\bin 28/04/2002 11:07 16 656 tkprof.exe Si ce répertoire est défini dans le PATH (voir les variables d’environnement), il suffit juste de taper TKPROF sans le chemin pour pouvoir s’en servir. Syntaxe : TKPROF nom_du_fichier_en_entrée nom_du_fichier_en_sortie options Pour obtenir l'aide sur la commande, il suffit de taper TKPROF sans argument. Je ne présente pas ici les options de tkprof, mais je m’arrête sur l’option SORT SORT donne l’ordre dans lequel sont triées les instructions Elles peuvent être découpées en quatre parties: - La phase d’analyse : (PARSE) prscnt prscpu prsela prsdsk Nombre d’appels d’analyse (PARSE) Temps CPU consommé pour l’analyse Temps écoulé pour l'analyse Nombre de lectures sur le disque Nombre de mémoire tampon pour une lecture prsqry cohérente au cours de l’analyse prscu Nombre de buffers durant la phase de parse Nombre d’échecs dans le cache « library » au cours prsmis de l’analyse - La phase d’exécution : (EXEC) execnt execpu exeela exedsk Nombre d’exécutions appelées Temps CPU consommé pour l’exécution Temps écoulé durant l’exécution Nombre de lectures sur le disque durant l’exécution Nombre de mémoire tampon pour une lecture exeqry cohérente au cours de l’exécution execu Nombre de buffers durant la phase d’exécution exerow Nombre de lignes traitées durant l’exécution Nombre d’échecs dans le cache « library » au cours exemis de l’exécution - La phase d’extraction : (FETCH) fchcnt fchcpu Nombre d’appels d’extraction (FECTH) Temps CPU consommé pour l’extraction UERSX053 – Introduction aux bases de données– Séance 10 - 23/04/2009 11 fchela fchrow Temps écoulés pour l’extraction Nombre de lectures sur le disque au cours du FETCH Nombre de mémoires tampon pour une lecture cohérente au cours de l’extraction Nombres de mémoires tampon pour la lecture en cours lors de l’extraction Nombre de lignes traitées durant l’extraction. userid ID de l’utilisateur qui a analysé le curseur fchdsk fchqry fchcu - Autre 1.4.1.2.1. Interpréter le résultat du TKPROF Avant de commencer une notion de bind variable sera utile à la compréhension du propos. 1.4.1.2.2. Les bind variables pour les requêtes courantes Une application destinée à un grand nombre d'utilisateurs est généralement composée de requêtes identiques à un critère prêt. Soit la requête de l'application permettant de générer la facture pour une commande donnée (CMD1) : select cm.ref, cl.nom, cl.adresse, a.description, a.prix, l.quantite, sum(l.prix*l.quantite) from commande cmd where cl.idclient = cm.idclient and l.idcmd = cm.idcmd and a.idart = l.idart where cm.ref = 'CMD1'; Dans ce cas, Oracle analysera le requête et construira le meilleur plan d'exécution. Cependant, si un autre utilisateur demande ensuite la même chose mais pour la commande CMD2, Oracle réévaluera la requête suivante : select cm.ref, cl.nom, cl.adresse, a.description, a.prix, l.quantite, sum(l.prix*l.quantite) from commande where cmd cl.idclient = cm.idclient and l.idcmd = cm.idcmd and a.idart = l.idart where cm.ref = 'CMD2'; UERSX053 – Introduction aux bases de données– Séance 10 - 23/04/2009 12 Or, comme cette demande est très courante, il est utile qu'Oracle ne recherche pas systématiquement le plan à utiliser. C'est pour cela que sont utiliser les bind variables : select cm.ref, cl.nom, cl.adresse, a.description, a.prix, l.quantite, sum(l.prix*l.quantite) from commande cmd where cmd cl.idclient = cm.idclient and l.idcmd = cm.idcmd and a.idart = l.idart where cm.ref = :ref_cmd; Il faudra ensuite indiquer la valeur de cette variable. Dans TOAD, il suffit d'écrire la requête comme citée précedemment, le logiciel propose ensuite d'assigner une valeur à la bind variable. Dans SQL*Plus, il faut au préalable déclarer la variable : SQL> variable ref_cmd char Puis l'affecter dans un bloc PL (en la préfixant par les :) : SQL> begin 2 :ref_cmd := 'CMD1'; 3 END; ou bien : SQL> execute :ref_cmd := 'CMD1' PL_SQL procedure successfully executed 1.4.1.2.3. Interpréter le TKPROF Concernant la phase de PARSE , il en existe deux types :« Hard et Soft parse » comme nous l’avons vu plus haut. Rappel : Les deux types de PARSE • • Le hard parse est une phase complète de parse (analyse ….). Le soft parse réapplique un hard parse encore présent en mémoire (library cache). . Lorsque l’option AGGREGATE est positionnée à YES, un nombre élevé de PARSE indique une phase d’analyse à chaque instruction. UERSX053 – Introduction aux bases de données– Séance 10 - 23/04/2009 13 Cela peut être symptomatique de requête sans BIND variable, ou alors un nombre comportant d’invalidations (calcul de statistiques, création suppression d’index ..). Les statistiques de suivi: Count CPU Elapsed Disk Query Current Rows Nombre d’analyses, exécutions et récupération effectuées. (Bien vérifier la présence d’une valeur supérieur à 0 avant d’interpréter les autres colonnes). A moins d’avoir spécifié AGGREGATE=no , TKPROF regroupe les instructions SQL identiques . Temps CPU total, exprimé en secondes, consacré aux étapes d’analyse, d'exécution et de récupération. Temps total, en secondes, consacré à tous les appels d’analyse, d’exécution ou de récupération (Ici les waits sont ajoutés et donc ce temps comprend aussi bien les opérations Oracle que les opérations CPU ). Il faut vérifier qu’il n’y a pas de différence notable entre CPU et Elapsed Nombre total de blocs de données lus physiquement dans les fichiers de données pour les étapes d’analyse, d'exécution ou de récupération. Nombre total de buffers extraits en mode cohérent pour toute les étapes. Nombre total de buffers extraits en mode courant pour toute les étapes. Nombre total de lignes traitées (mais cela ne concerne pas les sous-requêtes) - Select : ce nombre se trouve dans la colonne Fetch - Insert , Update et Delete : ce nombre se trouve dans la colonne Execute 1.4.1.2.4. Exemple de résultat Bien que très technique, ce fichier contient des informations très improtantes. (1) select numero, numcde,reference from commandes,clients where numero='CLI12' and datecde > sysdate-200 and numero=numeroclient (2) call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------Parse 1 0.00 0.00 0 0 0 0 UERSX053 – Introduction aux bases de données– Séance 10 - 23/04/2009 14 Execute Fetch 1 1 0.00 0.00 0.00 0.00 0 0 0 0 0 126 0 17 ------- ------ -------- ---------- ---------- ---------- ---------- ---------total 3 0.00 0.00 0 126 0 17 Misses in library cache during parse: 1 Optimizer mode: CHOOSE Parsing user id: 83 (COURS) (3) Rows Execution Plan ------- --------------------------------------------------0 SELECT STATEMENT MODE: CHOOSE 0 NESTED LOOPS 0 INDEX MODE: ANALYZED (UNIQUE SCAN) OF 'CLIENTSNUMERO' (UNIQUE) 0 TABLE ACCESS MODE: ANALYZED (BY INDEX ROWID) OF 'COMMANDES' 0 INDEX MODE: ANALYZED (RANGE SCAN) OF 'COMMANDESNUMEROCLIENT' (NON-UNIQUE) (1) : l'ordre sql executé (2) : les statistiques (3) : l'explain Call=La phase du traitement de l’instruction SQL Count= Le nombre d’appels et d’exécutions d’une phase CPU= Le temps CPU (en secondes ) consommé pour l’exécution d’une phase Elapsed= Le temps CPU (en secondes ) écoulé, . Disk= Le nombre de blocs Oracle lus sur le disque pour une phase donnée Query= Le nombre de blocs Oracle lus en mémoire en mode cohérent (pour les select) Current= Le nombre de blocs Oracle lus en mémoire en mode courant ( pour les updates) Rows= Le nombre de lignes traitées dans chaque phase 1.4.1.2.5. Interprétation de l’exemple UERSX053 – Introduction aux bases de données– Séance 10 - 23/04/2009 15 Une analyse type est décrite ci-dessous. A ce stade, le lecteur n’ets pas à même de tout comprendre. Cependant, vous percevrez que le travail d’adminuistrateur ORACLE exige des connaissances et une expérience qui dépasse le contenu de ce cours. Une bonne prise de conscience en somme. Dans l’exemple ci dessus , on constate : Colonne « Disk » : La colonne « Disk » est a zéro . Cela signifie simplement que les données nécessaires à l’ordre sql etaient déjà en memoire ( appelées par le même select lancé auparavant ou par un autre select sur les mêmes données ) , ORACLE conservant en mémoire ( dans la limite de db_cache_size , ou db_block_buffers* blok_size ) les données lues sur disque .Si ce select avait été lancé quelques heures plus tôt , on aurait vu les chiffres de la colonne « Query » dans la colonne « Disk » . Colonne « Query » : 126 block lus : Autrement dit , notre select ne provoque que très peu de lectures . Colonne « Rows » :17 lignes ramenées. Il est important de comparer le nombre de blocs lus au nombre de lignes traitées . Si un select traite 10M de block ( « Query ») pour ramener 1M de lignes (« Rows ») , pas d’affolement. Le select est tres coûteux , mais vu le nombre de lignes qu’il traite , c’est normal . Par contre , si un select traite 10M de block pour ne ramener qu’une lign, c’est peu être une piste de tuning SQL. Le temps CPU . Il faut plutot surveiller le temps CPU que le temps elapse .En effet , le temps elapse peut etre important à cause de facteurs exterieurs au select ( comme un lock , par exemple ) ou de problemes de tuning de base . Le nombre de blocks lus =Query+Current . Le nombre de blocks lus est toujours un signe que le sql est coûteux . Le temps CPU peut etre faible ( si le serveur est une super machine) , le nombre de block ne mentira pas . Rows . C’est un indicateur important : si le select lit 1 million de block pour ramener un million de lignes , cela peut etre normal , par contre s i le select lit un million de block pour ramener une ligne ,alors.on retourne au SQL. Count . UERSX053 – Introduction aux bases de données– Séance 10 - 23/04/2009 16 Tous les chiffres ci dessus doivent etre divisés par le nombre de fois ou la requete a été exécutée . Traiter un million de blocks en 1 appel ne signifie pas la même chose que traiter un million de blocks en 100000 appels 1.4.1.2.6. Les erreurs à ne pas commettre Une des principales fautes faite lors de l’analyse d’un tkprof est de ne tenir compte que des explains , pas des nombreux chiffres donnés par tkprof : Nombre de blocs : « le select met 500 secondes à répondre , pourtant il n’y a pas d’access full » : Un access full ne signifie pas forcement un mauvais select : si la table a moins de 100 lignes , il ne faut pas utiliser d’index . A l’inverse , un passage par un index doit être examiné de près et modifié si le nombre de blocs traités (« query ») est énorme par rapport aux données ramenées . En créant l’index approprié ( ou mieux , en modifiant le select ) et en relancant le programme , vous devez voir ce nombre diminuer de façon significative . Nombre de lignes ramenées : C'est le ratio nombre de blocks lus sur le nombre de lignes ramenées qui va donner une indication sur la possibilite de tuner l'ordre sql .Plus le ratio est important , plus il faut surveiller l’ordre sql Nombre d'exécutions : Penser à toujours diviser le nombre de blocks lus par le nombre d'exécutions du select 1.5. Killer des sessions Définition : Une session regroupe l’ensemble des activités liée à une connection à un schéma ORACLE par un utilisateur. Une session est identifiée par un numéro. Il ets parfois utile de « killer » une session. Pourquoi faire ? Parfois, voire souvent, vous pouvez travailler dans un contexte collaboratif sur une application qui exploite un même schéma. Quand un utilisateur exécute un update sur une UERSX053 – Introduction aux bases de données– Séance 10 - 23/04/2009 17 table, la table est dite lockée, un néologisme pratique qui exprime l’idée qu’un autre utilisateur ne peut pas procéder à un autre update sur la même table tant que le premier utilisateur n’a pas fait de commit. Vous imaginez qu’il peut alors exister souvent des cas de figure de blocage. Le deuxième utilisateur voit sa requête sql ne jamais se terminer. L’administrateur rentre en jeu. Il peut diagnostiquer le problème est visualisant les blocages et il peut « killer » une session afin de libérer les transactions en cours. Voir le chapitre 1.4.1. Pour visualiser les blocages, je pourrais également vous livrer l’élégante formule SQL qu’une personne normalement constituée ne retiendra jamais par cœur. Sachez simplement qu’un outil comme TOAD permet de visualiser facilement ces blocages avec les identifiants de sessions associés. Pour killer une session en sql, la commande est orakill à laquelle on associé le spid obtenu par la requête suivante. : SELECT instance_name FROM gv$instance; col program format a30 SELECT spid, osuser, s.program, schemaname FROM gv$process p, gv$session s WHERE p.addr = s.paddr; c:\oracle\product\ora102\bin> orakill orabase spid 1.6. Les jobs Les jobs peuvent s’apparenter à des programmes qui s’éxécutent automatiquement sur une base ORACLE. Ils peuvent s’exécuter pour un utilisateur donné, à une fréquence donnée. A quoi cela sert ? Les jobs sont souvent utilisés pour exécuter des procédures stockées qui doivent effectuer des tâches de maintenance sur une base toutes les nuits par exemple. Un exemple très utilisé est le calcul de statistique d’un schéma/table/index/ect qui permet à Oracle de mettre à jour ses outils internes d’optimisation de performance. Syntaxe : declare jn number; begin dbms_job.submit(jn, 'dbms_stats.gather_schema_stats(ownname => ‘’MONSCHEMA’’,cascade => TRUE);',sysdate+2/24,'TRUNC(SYSDATE) + 24/24'); commit; end; / UERSX053 – Introduction aux bases de données– Séance 10 - 23/04/2009 18 • • • • Le package natif à ORACLE (propriétaire sys) est dbms_job. Il contient une méthode qui permet de créer un job. Dans le package dbms_stats, la méthode gather_schema_stats permet de lancer un calcul de statistique. Ici le schéma cible est ’MONSCHEMA’ Le reste des arguments concerne la fréquence. Exemple 2 : declare jn number; begin dbms_job.submit(jn, MaProcedure_Stockee;',sysdate,'trunc(sysdate,''mi'')+2/(24/60)'); commit; end; / 1.7. Import/Export Définition : EXPORT et IMPORT sont des utilitaires de transfert de données spécifiques à Oracle et utilisés de manière symétrique : export extrait les données d'Oracle vers un fichier externe et import réinjecte le contenu d'un fichier d'export Oracle vers la base de données. La sauvegarde et la restauration sont des sujets qui occupent encore de nombreuses pages de des guides d’utilisation ORACLE. Je garderais que le mécanisme d’export et d’import. Ils sont pratiques, accessibles, intuitifs, en somme un moyen efficace et privilégié pour fournir une méthode de sauvegarde manuelle, et qui peut aussi être automatisée. Export et Import fonctionnent en client/serveur, on peut les effectuer localement à la machine ou sur une machine cliente. On les lance donc sur une console dos (un cmd concrêtement depuis « Demarrer/executer… ») La commande doit être exécutée sur le serveur qui héberge les bases. Le résultat est un fichier qu’on appelle dump. En général on lui donne comme extension .dmp UERSX053 – Introduction aux bases de données– Séance 10 - 23/04/2009 19 1.7.1. Utilité D'une manière générale export et import sont des utilitaires de transfert LOGIQUE de données. Moyennant cela ils peuvent être utilisés pour : • • • • • l'archivage logique de la base le changement de version d'Oracle (upgrade) les sauvegardes logiques le déplacement de données (d'une base vers une autre, d'un schéma vers un autre) la réorganisation physique de la base 1.7.2. Caractéristiques principales • • • • • stocke les données dans un fichier d'un format spécial lisible par Oracle stocke la définition des objets format logique des données (possibilité de fusion des extents) possibilité d'export 'cumulatif' ou 'incrémental' plusieurs niveaux de finesse (full,user,table) 1.7.3. export : généralités Il existe 3 modes d'export correspondant à des niveaux de finesse (granularité) plus ou moins importants. Du plus petit au plus grand on a respectivement les modes : • • • Table User full exemple de commande : exp scott/tiger grants=Y tables=(EMP,DEPT) • • • exp est la commande (dispo sous le répertoire bin du répertoire d’installation d’ORACLE) grants indique si l’on exporte les privilèges tables permet de choisir les tables à exporter. 1.7.4. export : Description des paramètres (valeurs par défaut entre parenthèses) : help aide :affiche les otions possibles (N) parfile nom du fichier de paramêtres USERID user et password de connexion FULL export du fichier entier (N) BUFFER taille du data buffer UERSX053 – Introduction aux bases de données– Séance 10 - 23/04/2009 20 OWNER liste des utilisateurs a exporter (en mode User) FILE fichier de sortie ou d'export (EXPDAT.DMP) TABLES liste des tables COMPRESS import dans 1 seul extent : compression (Y) RECORDLENGTH longueur d'enregistrement GRANTS export des grants ? (Y) INCTYPE export differentiel de type (incrémental, cumulative ou complete) DIRECT accès otimisé aux données (pas de SQL) FEEDBACK n indique la progression de l'export table par table. 1 caractère affiché pour n lignes exportées INDEXES export des index (Y) RECORD marquage des export incrementaux (différentiels) dans le dictionnaire (Y) ROWS export des données aussi ? (Y) PARFILE fichier de paramètres (si pas mode commande) CONSTRAINTS export des constraintes (Y) CONSISTENT image avant consistante de l'export (mises a jour autorisées) LOG log file of screen output STATISTICS type de statistiques à générer à l'import estimate|compute|none (ESTIMATE) 1.7.5. import : généralités Environnement identique à export ordre dans lequel les objets sont 'importés : • • • • structures de tables données index contraintes d'intégrité et triggers Pour faire un import FULL, il faut être DBA ou posséder le role IMP_FULL_DATABASE 1.7.6. import : paramêtres HELP décrit les paramètres de l'import USERID username/password de connexion FULL import complet (N) UERSX053 – Introduction aux bases de données– Séance 10 - 23/04/2009 21 BUFFER taille du data buffer FROMUSER liste des propriétaires exportés FILE fichier d'entrée (EXPDAT.DMP) TOUSER liste des propriétaires cibles de l'import SHOW liste les objets à importer, sans importer ! (N) TABLES liste des tables IGNORE ignore les erreurs due aux objets déjà existants (N) RECORDLENGTH longueur des enregistrements en entree/sortie GRANTS import des droits (Y) INCTYPE import de type différentiel INDEXES import les indexs aussi ? (Y) COMMIT commit par paquet (N) ROWS importe aussi le contenu des tables (Y) PARFILE fichier de parametres LOG trace des sorties écran DESTROY écrase le fichier du tablespace (N) INDEXFILE écrit table/index dans le fichier spécifié CHARSET character set du fichier d'export (NLS_LANG) FEEDBACK n indique la progression de l'import table par table. 1 caractère affiché pour n lignes importées 1.8. exemples d'export et d'import export mon_user/mon_password PARFILE=mon_fichier_de_parametres export des tables EMP et DEPT de SCOTT : exp scott/tiger file=/tmp/expscott.dmp tables=emp,dept on obtient a l'écran : Export: Release 8.0.5.0.0 - Production on Fri Sep 10 13:54:8 1999 (c) Copyright 1998 Oracle Corporation. All rights reserved. Connected to: Oracle8 Enterprise Edition Release 8.0.5.0.0 Production PL/SQL Release 8.0.5.0.0 Production Export done in US7ASCII character set and US7ASCII NCHAR character set About to export specified tables via Conventional Path .. . . . exporting table EMP 14 rows exported . . exporting table DEPT 4 rows exported Export terminated successfully without warnings. réimport des 2 tables : imp scott/tiger file=/tmp/expscott.dmp commit=y ignore=y UERSX053 – Introduction aux bases de données– Séance 10 - 23/04/2009 22 remarque : le paramètre COMMIT=Y est très important surtout pour des tables volumineuses. S'il n'est pas spécifié il y aura juste un commit final, mais l'image avant (les rollback segments) risquent fort d'être saturés avant le terme de l'import... Le paramètre ignore est nécessaire, si les tables EMP et DEPT existent déjà dans le compte cible. On obtient a l'écran : Import: Release 8.0.5.0.0 - Production on Fri Sep 10 14:0:2 1999 (c) Copyright 1998 Oracle Corporation. All rights reserved. Connected to: Oracle8 Enterprise Edition Release 8.0.5.0.0 Production PL/SQL Release 8.0.5.0.0 Production Export file created by EXPORT:V08.00.05 via conventional path . importing SCOTT's objects into SCOTT . . importing table "EMP" 14 rows imported . . importing table "DEPT" 4 rows imported Import terminated successfully without warnings. 2. Sécurité : On trouvera ci-après un résumé succinct des principales étapes de l'évolution des architectures matérielles et logicielles qui se sont profondément modifiées lors des deux dernières décennies. Type client Type serveur terminal Mainframe Type logiciels connexion / clients architecture logiciels serveur directe OS + Applicatif + fichiers de données - PC Départemental réseau terminal émulateur OS + Applicatif + SGBD PC lourd Départemental applicatif nav + OS + Applicatif + SGBD applet PC léger Départemental n-tier / Central client / serveur Srv d'application : OS (+web) + appli navigateur Srv de données : OS + SGBD La plupart de ces architectures peuvent sembler désuettes, voire anachroniques, mais il suffit de se pencher sur l'écran d'un ordinateur dans une grande surface ou un aéroport pour UERSX053 – Introduction aux bases de données– Séance 10 - 23/04/2009 23 constater que l'émulation de terminal (même enjolivée) est toujours très utilisée en 2004. Quoi qu'aie pu en penser SUN il y a quelques années :" the Network is NOT YET the computer" On constate cependant à l'évidence une tendance à la complexité : • • • • multiplication des matériels (plusieurs clients fixes ou mobiles, plusieurs serveurs, réseau hétérogènes) multiplication des couches logicielles (OS client, application client, client reseau, OS serveur, serveur reseau, serveur applicatif, SGBD) multiplication (voire ubiquité) des réseaux ( intranet, internet et surtout en ce qui concerne la sécurité des données EXTRAnet) généralisation du partage de données : entre particuliers, mais aussi employés, entreprises, clients, fournisseurs, partenaires qui fait de la sécurité des données un enjeu majeur. Pour info, ci après les statistiques du CERT sur les enregistrements d'incidents des dernières années : Année Incidents rapportés 1990 1991 1992 Année Incidents rapportés 1997 1998 1999 2000 2001 2002 2134 3734 9859 21756 52658 82094 +150000 252 406 773 1993 1994 1995 1996 1334 2340 2412 2573 2003 2.1. Les piliers de la sécurité des systèmes en général et des SGBDs en particulier On envisage souvent la sécurité sous un angle fermé, essentiellement celui de la confidentialité. Mais bien d'autres concepts sous tendent la sécurité. Ils sont pratiquement tous applicables aux OS et aux SGBDs, tant il est vrai que ces deux domaines sont extrêmement recouvrants. • • confidentialité Tout n’est pas accessible à tout le monde! Se connecter à l'OS ou à la base de données, donne un certain nombre de droits et de ressources en fonction d’un profil défini et maintenu par un administrateur. La granularité d’accès peut aller jusqu’à la vision unique d’un champ d’un enregistrement d’une table particulière. disponibilité Faculté de délivrer correctement un service en terme de délai et de qualité à l'utilisateur. Se mesure en pourcentage du temps de fonctionnement total.Une disponibilité de 100% est possible (temps de reprise nul) il suffit de s’en donner les moyens logiciels et matériels... UERSX053 – Introduction aux bases de données– Séance 10 - 23/04/2009 24 • • • • fiabilité Des mécanismes de sauvegarde variés (physique, logique, off-line, on-line, totale, partielle, incrémentale), ainsi que des mécanismes de journalisation, et de reprise permettent de restaurer une information sans pratiquement aucune perte, dans tous les cas de problème matériel ou logiciel. intégrité Que les données soient réparties ou non –dans ce dernier cas les mécanismes mis en jeux seront plus complexes– elles doivent être cohérentes. Cela sous entend, d’une part que les accès concurrents d’utilisateurs, notamment lors de mises à jour, ne doivent pas compromettre la cohérence des données et d’autre part que ces dernières satisfassent aux contraintes d’intégrité du modèle, et / ou aux règles de gestion de l’entreprise. tracabilité en cas de problème important ou d’attaque du système,on peut recourir à l’analyse de traces ou de logs. Le niveau de détail de ces traces est paramétrable, et concerne soit les aspects système, soit réseau, soit l’accès aux données élémentaires elles-mêmes. maintenabilité aptitude à la réparation, évolution, maintenance du système. Mesuré en temps de reprise après panne (Mean Time To Recover) 2.2. Les mécanismes mis en oeuvre pour la sécurité Les sgbds (dignes de ce nom) se doivent de fournir un certain n ombre de mécanismes internes ou de fonctionnalités assurant un niveau satisfaisant de sécurité. • L'authentification, est le processus qui permet de vérifier qu'un utilisateur réclamant un accès est bien celui qu'il prétend être, ou plus simplement le processus qui contrôle l'identité de l'utilisateur. Cette action (login) se fait en général via la fourniture du couple nom d'utilisateur / mot de passe. Dans certains cas l'authentification peut être implicite et héritée d'une authentification précédente, ou reconnue automatiquement (@IP du user sur le réseau par exemple), bien que simplifiant les accès ce choix peut évidemment s'avérer dangereux. Voir chapitre sur les utilisateurs. La multiplication des couches logicielles évoquées ci dessus, et l'inflation d'applications sur les postes utilisateur fait que ce dernier est fréquemment amené à s'authentifier des dizaines de fois par jour. La signature unique (Single Sign On ou SSO) est un objectif très louable mais rarement atteint ! • Les droits et privilèges : une fois correctement identifié l'utilisateur doit pouvoir accéder aux informations et ressources auxquelles il a droit (et uniquement à celle là! ) Ce problème est résolu le + simplement avec la gestion de droits élémentaires accordé à un individu, ou plus efficacement avec des rôles et / ou profils affectés à des groupes d'invidus...ou à des rôles ou profils. • Les LOGs ou traces : permet d'enregistrer tout ou partie des informations concernant les accès (réussis ou échoués). Cette trace pourra être plus ou moins verbeuse et son volume étroitement surveillée. De ce fait on l'utilisera de manière ciblée sur des périodes de temps spécifiques • tolérance aux pannes : permet par du matériel ou du logiciel redondant (CPUs, disques, IOs) de supporter de manière partiellemnt ou complètement transparentes UERSX053 – Introduction aux bases de données– Séance 10 - 23/04/2009 25 • • différents types de pannes, tant au niveau du client, que du réseau, que du serveur. Une tolérancec totale a bien sur un cout certain. sauvegarde et restauration sauvegarder les données sur des supports externes (disques, bandes, etc.) et pouvoir les restituer, les plus à jour possible. le but est de ne pas perdre de données suite à un pb matériel (panne disque) , logiciel (bug) ou une fausse manipulation d'un utilisateur. mécanismes transactionnels l'atomicité des transactions, par définition assure la cohérence des données, même dans des environnements distribués. L'image avant modification, stockée de manière redondante dans ou hors de la BD, permet de faire d'éventuels retours arrière pour retrouver le dernier état cohérent, ou de s'assurer qu'il n'y aps pas eu d'opérations partielles ou incomplète (transaction bancaires par exemple) Aspect sécurité mécanisme mis en oeuvre exemple d'implémentation au niveau SGBD • • • authentification indépendance logique / physique • • • • • référentiel user / password : DBA_USERS tables de user applicatifs identification externe : CREATE USER ...IDENTIFIED EXTERNALLY tables / tbs / fichiers vues (1) virtual private database exemple d'implémentation au niveau OS • • • SSO LDAP identification externe architecture client serveur • user OS DBA ou root confidentialité • • traçabilité droits et privilèges • logs et traces • tolérance de panne • sauvegarde et fiabilité, disponibilité, maintenabilité • droits d'accès aux données GRANT SELECT ON toto droits du LDD ou Systeme GRANT CREATE TABLE TO... GRANT CREATE SESSION TO... roles • • tables d'audit log Oracle Net • • • logs apache logs OS logs réseau • • stand by DB cluster logiciels : architecture R.A.C • • • H.A.C.M.P techno RAID machine redondantes • physique : sauvegarde + journalisation + • copie physique totale • UERSX053 – Introduction aux bases de données– Séance 10 - 23/04/2009 26 restauration • • • intégrité • transaction atomique contraintes d'intégrité • • • restauration logique : export / import génération de SQL Two Phase Commit (2PC) contraintes 'reference' read consistancy (1) la vue est pratiquement le seul contrôle d'accès offrant un niveau de granularité ligne ou colonne ! et qui plus est de manière contextuelle, en les paramétrant (tranches horaires, @ IP, etc.) 2.3. Les principales menaces Au delà des attaques accidentelles ou les défaillances du système, les attaques 'malveillantes' nous intéresseront plus particulièrement. Les menaces les plus connues du grand public, visent à paralyser, ou détruire tout ou partie du système d'information. Elles ne ciblent pas vraiment les SGBDs mais nous les citerons néanmoins parce qu'incontournables. Jetons un oeil aux définitions données par le grand glossaire de la sécurité de ECHU.ORG : • • • Virus : Au sens large du terme, on qualifie généralement de virus tout programme capable de se reproduire (techniquement, se recopier) lui-même et d'endommager des données informatiques. On les classe en plusieurs catégories, principalement: parasite, compagnon, amorce, multiformes, résident mémoire ou non, furtifs, polymorphes, réseau et flibustier. Pour plus de détails reportez-vous aux définitions correspondantes. Ver (ou Worm) : programme qui peut s'auto-reproduire et se déplacer à travers un réseau en utilisant les mécanismes réseau, sans avoir réellement besoin d'un support physique ou logique (disque dur, programme hôte, fichier ...) pour se propager; un ver est donc un virus réseau. Cheval de Troie : (en anglais trojan horse) un programme informatique effectuant des opérations malicieuses à l'insu de l'utilisateur : vol des mots de passe, copie de données sensibles, exécution d'action nuisible ... Un peu moins connus mais plus probables dans le domaine des SGBDs : • Back doors : ("Portes dérobées") : Programmes usurpateurs qui détournent des fonctionnalités systèmes dans le but d'ouvrir des accès utiles aux pirates pour contrôler à distance les machines ciblées (modification des programmes de login avec user/passwd en dur, ouverture de ports particuliers, etc.) . Ces programmes sont la plupart du temps installés par le biais d'un "cheval de Troie". Parmi les plus (tristement) célèbres, on peut citer BackOrifice (BO) ou encore NetBus. Les accès illicites via ces backdoors pouvant être facilement détectés par des commandes système standards (liste des process connectés, des ports ouverts) ils sont parfois utilisés conjointement avec des rootkits, ensemble de commandes standards modifiées pour masquer les intrusions. UERSX053 – Introduction aux bases de données– Séance 10 - 23/04/2009 27 • • altération du SQL o C’est l’aspect le plus intéressant mais il nécessite des connaissances sur le monde la programmation en général. Bien que tentant d’en écrire ici les rouages, je m’abstiens à cause d’un public éventuellement non averti. o Il aurait été essentiellement question de récupération d’information à travers des requêtes sql qui filtrent jusqu’à l’utilisateur de x façon. Buffer Overflow 2.4. • • • • Les principales failles de sécurité...ou de comportement Installation par défaut : - les valeurs de paramètres sont connues (port 80 / 1525, mot de passe SYS et SYSTEM, - des services superflus sont accessibles (srv ftp, srv samba, snmp, serveur d'admin, etc - les communications ne sont pas chiffrées (ftp, telnet, pop) mauvaise politique de gestion des droits (top, au lieu de bottom-up) : - installation confortable : tous les logiciels sont installés sous root, tous les utilisateurs de l'applicatif sont DBAs - allow all implicite...deny N / deny all.. allow n - utilisation abusive de l'héritage ;-) maitrisez la gestions des droits de vos OS / logiciels serveurs / bases de données bugs (qui peuvent provoquer un simple déni de service voire l'arrêt du système ) ;-) faites de la veilles, patchez régulièrement mauvais codage (parametres en clair dans les URLs, connexion non chiffrées, etc.) ;-) documentez vous (best practices, faites tester vos programmes) comme chacun sait (depuis certaines émissions de télé) c'est le maillon le plus faible de la chaîne qui cassera imanquablement. On peut mettre en place le plus beau (et le + cher) des firewalls, il sera bien inutile si un adminitrateur est resté 'loggué' root sur son poste (Statistiquement la majorité des attaques provient de l'intérieur des entreprises !) Cependant, on n'oubliera pas de rester pragmatique : tous les PMEs ne sont pas le pentagone et n'intéressent pas tous les hackers de la planète. Les besoins et les objectifs doivent être clairement définis au départ et l'adéquation de la solution vérifiée. Un certains nombres d'utilitaires libres sont disponibles sur internet pour vérifier la fiabilité de votre système d'information. Voir parmi la liste des liens utiles. Il faudra de + trouver un équilibre entre niveau de sécurité satisfaisant et confort (voire simple possibilité) de travail des autres acteurs. trigger pour simuler relation clef etrangere entre tables de de bases distantes. UERSX053 – Introduction aux bases de données– Séance 10 - 23/04/2009 28 UERSX053 – Introduction aux bases de données– Séance 10 - 23/04/2009 29 UERSX053 – Introduction aux bases de données– Séance 10 - 23/04/2009 30 3. SOURCES http://www.sam-mag.com http://fr.wikipedia.org/wiki/Structured_Query_Language ORACLE 9i SQLLANGUAGE REFERENCE Commentcamarche.net http://sqlpro.developpez.com/cours/optimiser/ http://www.toutenligne.com/index.php?contenu=sql_explain&menu=sql http://jpg.developpez.com/oracle/tuning/ http://download.oracle.com/docs/cd/B19306_01/server.102/b14231/views.htm#i1106548 http://encyclopedie.aidenet.com/oracle/oracseq.htm http://oracle.developpez.com/guide/administration/adminuser/ http://didier.deleglise.free.fr/dba/structure/struct_main.htm http://otn.oracle.com/docs/products/oracle9i/doc_library/release2/nav/docindex.htm http://www.commentcamarche.net/contents/odbc/odbcintro.php3 http://www.commentcamarche.net/contents/oracle/oracdico.php3 http://www.tafora.fr/wp/optisql.doc.html http://tuningsql.metouyou.fr/tuning-sql/tkprof.html?Itemid=30 http://didier.deleglise.free.fr/dba/exp_imp/exp_imp_main.htm http://didier.deleglise.free.fr/dba/droits/droits_fs.htm UERSX053 – Introduction aux bases de données– Séance 10 - 23/04/2009 31