CC30 Certificat de compétence Conception, développement

Transcription

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
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.
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 ?
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
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.
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.
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
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
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
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
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 :
from commande where cmd cl.idclient = cm.idclient and l.idcmd = cm.idcmd and a.idart =
l.idart
where cm.ref = 'CMD2';
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 :
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.
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
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
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 .
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
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;
/
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
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
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)
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
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
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...
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
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
•
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.
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.
28
29
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
31

CC30 Certificat de compétence Conception, développement

Transcription

Documents pareils

Fiche examen 2

Le système de bases de données du futur

Curriculum Vitae

Curriculum Vitae - Pascal MARTINEZ

Procedure de truncate des logs

PDF Formation Flash initiation - créer des animations Lille Nord 59

MARTINIQUE

Fiche programme - Nicéphore Cité

11gR2 ASM – Inside story – Partie 6 (Recréer le

Architecture client serveur l`état de l`art

Intersport crée ses formats d`import en un temps record