Cours DBA

B.4 - Contraintes d’intégrité

admin — Fri, 21 Oct 2011 16:03:01 +0000

Les contraintes sont des règles de gestion, qui doivent (normalement) être vérifiées lors des mises à jour (INSERT, UPDATE, DELETE).
Ces contrôles sont centralisés dans la base, au niveau de la structure de la table elle même et non pas déportées sur l’application cliente.
Une mise à jour qui ne satisfait pas une contrainte, déclenche une erreur d’exécution :’…CONSTRAINT VIOLATED…’
Dans certains cas les contraintes peuvent être momentanément invalidées (DISABLEd ou DEFERRED).

Il y a plusieurs types de contraintes :

- NULL : valeur indéfinie (??)
- NOT NULL : valeur obligatoire (non indéfinie)
- DEFAULT : une valeur par defaut si non renseignée
- UNIQUE : !
- PRIMARY KEY : clé primaire (identifiant de la table, obligatoire ET unique)
- FOREIGN KEY : clé étrangère ‘colonne qui référence la clé primaire d’une autre table)
- CHECK : doit vérifier une condition

On peut créer des contraintes directement avec l’instruction ‘CREATE TABLE’ ou en ajouter / modifier / supprimer, respectivement avec les instructions ‘ALTER TABLE ADD | MODIFY |DROP CONSTRAINT …’

exemples de contraintes

– exemple de table avec des colonnes …
– et des contrainte NOT NULL, UNIQUE, PRIMARY KEY et CHECK

SQL> DROP TABLE employe_dd;

SQL> CREATE TABLE employe_dd
( employee_id NUMBER(6) PRIMARY KEY
, last_name VARCHAR2(25) NOT NULL
, salary NUMBER(8,2)
, CONSTRAINT emp_salary_min_dd CHECK (salary > 0)
, email VARCHAR2(25) NOT NULL
, CONSTRAINT emp_email_dd UNIQUE (email)
, commission_pct NUMBER(2,2)
, department_id NUMBER(4)
) ;

– exemple de table avec clé primaire et étrangère NOMMEES rajoutées ? posteriori
– ici la contrainte NOT NULL est nommée…

SQL> DROP TABLE departement_dd;
SQL> CREATE TABLE departement_dd
( department_id NUMBER(4)
, department_name VARCHAR2(30) CONSTRAINT dept_name_dd_nn NOT NULL
, location_id NUMBER(4)
) ;
SQL> ALTER TABLE departement_dd
ADD ( CONSTRAINT dept_id_dd_pk PRIMARY KEY (department_id));
SQL> ALTER TABLE employe_dd
ADD ( CONSTRAINT emp_dept_dd_fk FOREIGN KEY (department_id)
REFERENCES departement_dd );

Note : la contrainte d’intégrité référentielle impose qu’un employé appartienne a un département EXISTANT.
Symétriquement, si l’on veut supprimer un département qui a des employes on viole la contrainte :
SQL> delete from departments where department_id=10;
–> erreur : ORA-02292: violation de contrainte (HR.EMP_DEPT_FK) d’intégrité - enregistrement fils existant

Il existe une clause ‘ON DELETE CASCADE’ qui permet de déclencher une suppression automatique des lignes ‘filles’ si une ligne ‘mère’ est supprimée : supprimer par exemple tous les emplyés associés ? un departement qui vient d’être supprimé…

SQL> ALTER TABLE employees
ADD ( CONSTRAINT emp_dept_fk FOREIGN KEY (department_id)
REFERENCES departments ON DELETE CASCADE )
SQL> select count(*) from employees
WHERE department_id=100;
–> 6
SQL> DELETE from departments WHERE department_id=100;
–> 1 row deleted
mais les lignes de ‘employees’ correspondantes ont également été supprimées :
SQL> select count(*) from employees
WHERE department_id=100;
–> 0

Infos dans le référentiel

SQL> select * from user_constraints

ou + précisément

SQL> select constraint_name, constraint_type, table_name,
search_condition,r_constraint_name, status
from user_constraints
where table_name like ‘%DD’

CONSTRAINT_NAME CONSTRAINT_TYPE TABLE_NAME SEARCH_CONDITION R_CONST_NAME STATUS
—————– ————— ———- —————- ———— ——
EMP_SALARY_MIN_DD C EMPLOYE_DD salary > 0 - ENABLED
SYS_C004030 C EMPLOYE_DD EMAIL IS NOT NULL - ENABLED
SYS_C004029 C EMPLOYE_DD LAST_NAME IS NOT NULL - ENABLED
DEPT_NAME_DD_NN C DEPARTEMENT_DD D_NAME IS NOT NULL - ENABLED
EMP_DEPT_DD_FK R EMPLOYE_DD - DEPT_ID_DD_PK ENABLED
SYS_C004032 P EMPLOYE_DD - - ENABLED
EMP_EMAIL_DD U EMPLOYE_DD - - ENABLED
DEPT_ID_DD_PK P DEPARTEMENT_DD - - ENABLED

invalidation de contraintes

Les clauses ‘DEFERRED’ et ‘DEFERRABLE’ permettent de différer l’application de la contrainte à la fin de la
transaction :

SQL> create table test(n number check ( n in (10, 20) ) deferrable initially deferred );
SQL> alter session set constraint = deferred;
SQL> insert into test values(100);
–> OK
SQL> insert into test values(200);
SQL> commit;
–> erreur sur la transaction
ORA-02091: transaction annulée
ORA-02290: violation de contraintes (HR.SYS_C004039) de vérification

SQL> alter session set constraint = immediate;
SQL> insert into test values (100);
–> erreur sur l’insertion :
ORA-02290: violation de contraintes (HR.SYS_C004039) de vérification

On peut également utiliser les clause ENABLE/DISABLE de ‘ALTER TABLE’
ENABLE VALIDATE : s’applique aux lignes existantes dans la table
ENABLE NOVALIDATE : aux ligne futures
DISABLE : inhibe la contrainte

SQL> CREATE TABLE test (n number , constraint nb_ok check ( n in (10, 20) ));
SQL> insert into test values (100);
– erreur : ORA-02290: violation de contraintes (HR.NB_OK) de vérification
SQL> ALTER TABLE test DISABLE CONSTRAINT nb_ok ;
SQL> insert into testing values(100);
–> 1 ligne insérée (la contrainte était inhibée)

ALTER TABLE test ENABLE NOVALIDATE CONSTRAINT nb_ok;
–> OK : Table Altered…

ALTER TABLE test ENABLE VALIDATE CONSTRAINT nb_ok;
–> erreur : ORA-02293: impossible de valider (HR.NB_OK)
- violation d’une contrainte de contrôle

la clause validate, force le controle de la contraine sur la lignes existantes et la valeur ‘100′ insérée précédemment est non conforme…

Voici un exemple complet de création de mini base avec contraintes, d’après les tables de démo HR officielles d’Oracle :

Rem
Rem $Header: hr_cre.sql 29-aug-2002.11:44:03 hyeh Exp $
Rem Copyright (c) 2001, 2002, Oracle Corporation. All rights reserved.
Rem

REM ****************************************************
REM Create the REGIONS table to hold region information for locations
REM HR.LOCATIONS table has a foreign key to this table.

Prompt ****** Creating REGIONS table ….

CREATE TABLE regions
( region_id NUMBER
CONSTRAINT region_id_nn NOT NULL
, region_name VARCHAR2(25)
);

CREATE UNIQUE INDEX reg_id_pk
ON regions (region_id);

ALTER TABLE regions
ADD ( CONSTRAINT reg_id_pk
PRIMARY KEY (region_id)
) ;

REM ********************************************************
REM Create the COUNTRIES table to hold country information for customers
REM and company locations.
REM OE.CUSTOMERS table and HR.LOCATIONS have a foreign key to this table.

Prompt ****** Creating COUNTRIES table ….

CREATE TABLE countries
( country_id CHAR(2)
CONSTRAINT country_id_nn NOT NULL
, country_name VARCHAR2(40)
, region_id NUMBER
, CONSTRAINT country_c_id_pk
PRIMARY KEY (country_id)
)
ORGANIZATION INDEX;

ALTER TABLE countries
ADD ( CONSTRAINT countr_reg_fk
FOREIGN KEY (region_id)
REFERENCES regions(region_id)
) ;

REM ********************************************************
REM Create the LOCATIONS table to hold address information for company departments.
REM HR.DEPARTMENTS has a foreign key to this table.

Prompt ****** Creating LOCATIONS table ….

CREATE TABLE locations
( location_id NUMBER(4)
, street_address VARCHAR2(40)
, postal_code VARCHAR2(12)
, city VARCHAR2(30)
CONSTRAINT loc_city_nn NOT NULL
, state_province VARCHAR2(25)
, country_id CHAR(2)
) ;

CREATE UNIQUE INDEX loc_id_pk
ON locations (location_id) ;

ALTER TABLE locations
ADD ( CONSTRAINT loc_id_pk
PRIMARY KEY (location_id)
, CONSTRAINT loc_c_id_fk
FOREIGN KEY (country_id)
REFERENCES countries(country_id)
) ;

Rem Useful for any subsequent addition of rows to locations table
Rem Starts with 3300

CREATE SEQUENCE locations_seq
START WITH 3300
INCREMENT BY 100
MAXVALUE 9900
NOCACHE
NOCYCLE;

REM **************************************************
REM Create the DEPARTMENTS table to hold company department information.
REM HR.EMPLOYEES and HR.JOB_HISTORY have a foreign key to this table.

Prompt ****** Creating DEPARTMENTS table ….

CREATE TABLE departments
( department_id NUMBER(4)
, department_name VARCHAR2(30)
CONSTRAINT dept_name_nn NOT NULL
, manager_id NUMBER(6)
, location_id NUMBER(4)
) ;

CREATE UNIQUE INDEX dept_id_pk
ON departments (department_id) ;

ALTER TABLE departments
ADD ( CONSTRAINT dept_id_pk
PRIMARY KEY (department_id)
, CONSTRAINT dept_loc_fk
FOREIGN KEY (location_id)
REFERENCES locations (location_id)
) ;

Rem Useful for any subsequent addition of rows to departments table
Rem Starts with 280

CREATE SEQUENCE departments_seq
START WITH 280
INCREMENT BY 10
MAXVALUE 9990
NOCACHE
NOCYCLE;

REM *********************************************
REM Create the JOBS table to hold the different names of job roles within the company.
REM HR.EMPLOYEES has a foreign key to this table.

Prompt ****** Creating JOBS table ….

CREATE TABLE jobs
( job_id VARCHAR2(10)
, job_title VARCHAR2(35)
CONSTRAINT job_title_nn NOT NULL
, min_salary NUMBER(6)
, max_salary NUMBER(6)
) ;

CREATE UNIQUE INDEX job_id_pk
ON jobs (job_id) ;

ALTER TABLE jobs
ADD ( CONSTRAINT job_id_pk
PRIMARY KEY(job_id)
) ;

REM ***********************************************
REM Create the EMPLOYEES table to hold the employee personnel
REM information for the company.
REM HR.EMPLOYEES has a self referencing foreign key to this table.

Prompt ****** Creating EMPLOYEES table ….

CREATE TABLE employees
( employee_id NUMBER(6)
, first_name VARCHAR2(20)
, last_name VARCHAR2(25)
CONSTRAINT emp_last_name_nn NOT NULL
, email VARCHAR2(25)
CONSTRAINT emp_email_nn NOT NULL
, phone_number VARCHAR2(20)
, hire_date DATE
CONSTRAINT emp_hire_date_nn NOT NULL
, job_id VARCHAR2(10)
CONSTRAINT emp_job_nn NOT NULL
, salary NUMBER(8,2)
, commission_pct NUMBER(2,2)
, manager_id NUMBER(6)
, department_id NUMBER(4)
, CONSTRAINT emp_salary_min
CHECK (salary > 0)
, CONSTRAINT emp_email_uk
UNIQUE (email)
) ;

CREATE UNIQUE INDEX emp_emp_id_pk
ON employees (employee_id) ;

ALTER TABLE employees
ADD ( CONSTRAINT emp_emp_id_pk
PRIMARY KEY (employee_id)
, CONSTRAINT emp_dept_fk
FOREIGN KEY (department_id)
REFERENCES departments
, CONSTRAINT emp_job_fk
FOREIGN KEY (job_id)
REFERENCES jobs (job_id)
, CONSTRAINT emp_manager_fk
FOREIGN KEY (manager_id)
REFERENCES employees
) ;

ALTER TABLE departments
ADD ( CONSTRAINT dept_mgr_fk
FOREIGN KEY (manager_id)
REFERENCES employees (employee_id)
) ;

Rem Useful for any subsequent addition of rows to employees table
Rem Starts with 207

CREATE SEQUENCE employees_seq
START WITH 207
INCREMENT BY 1
NOCACHE
NOCYCLE;

REM ***********************************************
REM Create the JOB_HISTORY table to hold the history of jobs that
REM employees have held in the past.
REM HR.JOBS, HR_DEPARTMENTS, and HR.EMPLOYEES have a foreign key to this table.

Prompt ****** Creating JOB_HISTORY table ….

CREATE TABLE job_history
( employee_id NUMBER(6)
CONSTRAINT jhist_employee_nn NOT NULL
, start_date DATE
CONSTRAINT jhist_start_date_nn NOT NULL
, end_date DATE
CONSTRAINT jhist_end_date_nn NOT NULL
, job_id VARCHAR2(10)
CONSTRAINT jhist_job_nn NOT NULL
, department_id NUMBER(4)
, CONSTRAINT jhist_date_interval
CHECK (end_date > start_date)
) ;

CREATE UNIQUE INDEX jhist_emp_id_st_date_pk
ON job_history (employee_id, start_date) ;

ALTER TABLE job_history
ADD ( CONSTRAINT jhist_emp_id_st_date_pk
PRIMARY KEY (employee_id, start_date)
, CONSTRAINT jhist_job_fk
FOREIGN KEY (job_id)
REFERENCES jobs
, CONSTRAINT jhist_emp_fk
FOREIGN KEY (employee_id)
REFERENCES employees
, CONSTRAINT jhist_dept_fk
FOREIGN KEY (department_id)
REFERENCES departments
) ;

2.4 - DBA s et privilèges

admin — Thu, 11 Aug 2011 13:43:10 +0000

DBA et privilèges système

La fonction de DBA, nécessite des privilèges au niveau Système d’exploitation :
- pour l’installation,
- la maintenance,
- la gestion et l’exécution de batchs, de scripts (SQL ou shell),
- les sauvegardes / restauration

Sur Unix / Linux :
Il existe un user Unix nommé ‘oracle’ et un groupe associé nommé ‘dba’.
Tous les fichiers Oracle, appartiennent à l’utilisateur Oracle.

On peut (doit ?) crééer autant d’utilisateur Unix que de DBAs dans l’entreprise ; dba1, dba2, appartenant au groupe ‘dba’.Ceci permet d’éviter les recouvrements et d’avoir une meilleure tracabilité.
On évitera de travailler connecté en tant qu’utilisateur ‘oracle’ pour éviter toute erreur de manipulation des fichiers Oracle.

Note : les programmes et processus, qui constituent le coeur d’Oracle, s’executent en tant qu’oracle, et ont conséquemment les droits nécessaires pour écrire dans les fichiers de données, journaux, archives, etc.

Le DBA et le super utilisateur ‘root’ :
lors de l’installation, il est nécessaire d’écrire dans certains répertoires protégés du système (/etc par exemple) ou d’exécuter certaines taches privilégiées.
Cependant l’installation se fait bien en tant qu’Oracle, et l’installeur demande simplement le privilège root pendant la période nécessaire à ces opérations.
Il execute 2 scripts autonomes root.sh et rootpre.sh, en tant que root.
Il retourne ensuite en mode ‘normal’.
En production les no de ports TCP/IP utilisés par Oracle 10g sont tous > 1024, et ne nécessitent donc pas de privilèges particuliers.

Sur Windows :
Le principe est plus simple. L’install se fait en général en tant qu’administrateur système.

DBAs et privilèges d’exploitation / production

Certains ‘administrateurs’ : les opérateurs et techniciens d’exploitation, ou ‘exploitants’ pour faire court, n’ont pas forcément besoin d’un niveau de privilège DBA.

Les opérations concernés sont par exemple :

les démarrage / arrêts,
les sauvegardes / restaurations,
la planification et l’exécution de batch

Oracle fournit 2 niveaux de privilèges, qui peuvent être assimilés à des niveaux de connexion, qui satisfont ces besoins : les privilèges d’exploitation ‘SYSDBA’ et ‘SYSOPER’.
Comme tout accès privilégié il s’acquiert via un processus d’identification / authentification.

Authentification locale au niveau du système d’exploitation

C’est une forme d’authentification externe, en ce sens que ce n’est pas Oracle qui contrôle la connexion grace à son référentiel interne. On se connecte directement (via telnet ou ssh par exemple) au système qui héberge le serveur de données, puis à la base locale, sans plus faire intervenir le réseau.
Ce type de connexion originale ne nécessite pas d’identifiant ni de mot de passe Oracle, mais d’être un utilisateur privilégié au niveau O.S.

note : un utilisateur quelconque, non privilégié de la base, peut aussi être défini avec une authentificatin externe, et se connecter localement avec une commande du type : sqlplus /

On peut dire que dans ce cas la sécrité est déportée au niveau O.S. et qu’Oracle accorde sa ‘confiance’ aux mécanismes d’identification / authentification de ce dernier.

exemples de connexion avec le client SQL standard :

# connexion 'normale'
$> sqlplus scott/tiger
# connexion avec authentification externe
$> sqlplus / as sysdba
$> sqlplus / as sysoper

Pour obtenir un ‘privilège’ d’exploitation il suffit d’appartenir au groupe utilisateur correspondant au niveau système :

privilège  gpe unix    groupe windows
---------  --------    --------------
SYSDBA     dba         ORA_DBA
SYSOPER    oper        ORA_OPER

Ces groupes sont créés lors de l’installation, et un administrateur système en ‘hérite’ automatiquement

note : Le ‘CONNECT INTERNAL’ des versions précédentes est définitivement obsolète et a été remplacé par le ‘CONNECT SYS AS SYSDBA. Parallèlement il n’est plus possible de se connecter SYS ‘tout court’ sans préciser ‘AS SYSDBA’.

Authentification distante au niveau du système d’exploitation

Elle présente les mêmes caratéristiques que précédemment sauf que la base est située sur une machine distante de la connexion système courante.

La syntaxe de connexion devient donc :

$>  sqlplus /@nom_base_distante AS SYSDBA (ou SYSOPER)

Un paramètre d’initialisation de la base : REMOTE_OS_AUTJENTICATION=TRUE autorise cette fonctionnalité.

Note importante : il est vivement conseillé pour des raisons de sécurité d’invalider cette possibilité.

Authentification via fichier de mots de passe
Dans ce cas de figure, les privilèges seront controlés à partir d’un fichier de mot de passe cryptés local.
exemple de création du fichier :
$ ORAPWD FILE=monfic PASSWORD=monpasse ENTRIES=100
avec
PASSWORD : le mot de passe de SYS
ENTRIES : le nb mas d’utilisateurs référencables dans le fichier.

on peut ensuite créer un utilisateur TOTO avec mot de passe TUTU et que le DBA lui donne le privilège oracle (et non pas système cette fois) nécessaire : SYSDBA ou SYSOPER :

$> sqlplus / AS SYSDBA
SQL> CREATE USER TOTO IDENTIFIED BY TUTU;
SQL> GRANT CREATE SESSION TO TOTO; -- qu'il ait le droit de se connecter quand même...
$ GRANT SYSDBA TO TOTO ; --et lui donner le privilège d'exploitation qui va bien

note : le paramètre d’initialisation REMOTE_LOGIN_PASSWORDFILE doit être à EXCLUSIVE (c’est le défaut) pour pouvoir utiliser et modifier le password file

DBAs et privilèges Oracle

Un utilisateur Oracle (déclaré au sein de la base, à distinguer de l’utilisateur au niveau OS) peut être DBA.
Il a tous les ‘privilèges système’ AU SEIN DE LA BASE, et le droit de les transmettre (ADMIN OPTION)
Grace à quoi, il peut essentiellement :

consulter et mettre à jour (SELECT, UPDATE, INSERT, DELETE) toutes les données utilisateur de la base
créer, modifier des structures de données utilisateur (CREATE, ALTER, DROP) n’importe ou (ANY TABLESPACE)
gérer des utilisateurs et des droits (CREATE/DROP USER, GRANT, REVOKE)
consulter la totalité du dictionnaire
exécuter des ordres d’administration purs (CREATE DATABASE, DATAFILE, TABLESPACE)

Il y a 2 utilisateurs privilégiés prédéfinis, SYS et SYSTEM (dont les mots de passe sont définis à la création de la base ou par ‘ORAPWD’)
Ils sont tous les 2 DBA, mais SYS est plus privilégié en ce sens qu’il est propriétaire des tables et des vues du dictionnaire.

Il existe un ensemble de privilèges (ROLE) prédéfinis nommés ‘DBA’ qui donne les privilèges nécessaires à un DBA.
Après avoir créé un utilisateur ‘normal’ il suffit de lui donner ce rôle pour en faire un DBA :

SQL> GRANT DBA TO dupont;

note : Il existe un autre rôle prédéfini, parmi quelques dizaines, qui est également intéressant c’est le role ‘SELECT_CATALOG_ROLE’. Il est souvent utilisé par des progiciels ou applicatifs utilisant Oracle pour récupérer des méta-données.

Pour plus d’infos sur les droits, rôles et privilèges voir les chapitres correspondants.

2.1 - Qu’est ce qu’un DBA ?

admin — Fri, 05 Aug 2011 14:49:40 +0000

D.B.A. = Data Base Administrator = Administrateur de bases de données.
Il est responsable du bon fonctionnement de toutes les bases de données de l‘entreprise (bases de développement, test, qualification, préproduction, infocentre et production).

Les taches du DBA

Installer le logiciel, faire les mises à jour (patchs, changement de version du noyau mais aussi des autres produits)

Créer les bases de données physiques et gérer l’espace physique,
Gérer les utilisateurs et leurs droits d’accès,
Valider les schémas de données (cohérence, non redondance, optimisation),
crééer les objets du schéma : table, index, viues, …
Assurer la sécurité de la base (sauvegarde, restauration, confidentialité d’accès),
surveiller le système, gérer les ressources et optimiser les performances,
Faire les transferts de données de et vers d’autres systèmes,
contacter le support technique…ou Google

Son travail peut être assimilé à celui d’un responsable système, Oracle pouvant être perçu comme un ’sous’ système d’exploitation.

Les utilisateurs d’une base Oracle :

le dba lui même
le déve loppeur d’application
l’administrateur d’application
l’utilisateur final (normal ou infocentre / web)

Les interlocuteurs du DBA :

les développeurs
les administrateurs système (unix/linux, windows, etc.)
le support tecnique Oracle
le support technique interne
l’admlinistrateur sécurité (s’il existe)
et plus rarement …les utilisateurs

Les ‘privilèges’ DBA

Un DBA pour pouvoir travailler doit posséder un certain niveau de privilèges

au niveau OS
au niveau de la base de données

Sous Unix / Linux
le DBA doit avoir un compte Unix particulier, généralement baptisé Oracle, qui appartient à un groupe prédéfini Unix baptisé DBA. Les fichiers composant le logiciel et les process d’Oracle, appartiendront à cet utilisateur. Pour certaine étapes de l’installation (notamment création du user, et mise à jour des fichiers de démarrage, et des paramètres système) le DBA devra les privilèges ‘root’.
Sous Windows
le DBA devra appartenir au groupe administrateur, notamment pour démarrer les services Oracle sur le serveur.
‘Sous’ Oracle
le DBA devra avoir reçu l’ensemble de droit (prédéfini) Oracle baptisé rôle ‘DBA’. Ceci lui permettra notamment d’avoir une vision complète du référentiel de la base de données et d’accéder sans restrictions à toutes les données utilisateurs.
remarque : les utilisateurs standards SYS et SYSTEM de la base de données ont les droits DBA.

1.3 - Oracle en 10 minutes…et en video!

admin — Fri, 05 Aug 2011 13:30:40 +0000

Pour les Internautes pressés d’arriver à un résultat nous allons relever ici un défi, (grace aux compétences et aux qualités pédagogiques de Stephane Faroult, consultant International sur les technologies Oracle) :

Présenter l’architecture d’Oracle à des débutants, en vidéo , en Français et en moins de 10 minutes !

exo72 - installer et tester un ‘ instant client ‘ 11gR2

admin — Tue, 07 Jun 2011 20:06:39 +0000

0) télécharger l’instant client 11gR2 lite + sqlplus
(rendez vous sur otn.oracle.com rubrique ‘téléchargement’, version 11gR2
1) creer un répertoire d’accueil genre c:oracle_iclient_11gr2
2) dézipper tous les fichier dans CE répertoire
3) positionner (étendre) le PATH dans vos variable d’environnement SYSTEME pour pointer sur LE répertoire qui contient SQL*Plus
4) tester une connexion EZconnect avec SQL*Plus vers un serveur distant

par exemple : nom_logique_du_serveur ou @IP : 10.28.18.33
port 1521
service : XE
user/passwd : HR/HR

(Vérifier que le pare-feu du serveur ne bloque pas les entrées sur le port 1521)

5) 5) faire en sorte de résoudre un nom logique de connexion (Alias Oracle*Net) pour se connecter simplement avec
sqlplus hr/hr@HR

créer un TNSNAMES.ORA sur le client avec les bonnes informations
(utiliser un fichier SAMPLE)
faire en sorte que Oracle retrouve ce fichier avec la variable d’environnement
TNS_ADMIN

exoB3 - Mini audit de sécurité d’une base Oracle

admin — Mon, 06 Jun 2011 21:17:51 +0000

-1) lister les comptes / schémas préinstallés sur Oracle (date de création ?). Vérifier leur statut : ouvert ou verrouillé
- 2) lister les users ayant le rôle DBA
- 3) lister les users ayant un privilège système de type ‘ANY’
- 4) lister les users ayant le privilège execute sur les objets stockés de SYS
- 5) vérifier les paramètres sensibles de sécurité de la base : notamment REMOTE_OS_AUTHENT, UTL_FILE, AUDIT_TRAIL
- 6) Vérifier les permissions des fichiers du noyau Oracle et de la DB
- 7) vérifier les utilisateurs unix ou WIndows appartenant au groupe DBA

B.5 - Audit Oracle

admin — Mon, 06 Jun 2011 10:46:54 +0000

Oracle - dba - Audit des opérations sur la base

Audit, vous avez dit audit ?

L’audit Oracle est une des possibilités de surveillance de l’activité de la base de données :

pour contrôler les accès à la base, à des fins de sécurité,
pour vérifier que tel ou tel objet est accédé en lecture ou en écriture (sécurité ou analyse de performance),
pour vérifier les tentatives d’accès infructueuses à des objets,
pour contrôler l’audit éventuellement pirate !

Les résultats sont stockés dans une table du dictionnaire : SYS.AUD$
et préférablement accédés à travers des vues prédéfinies. Ceci permet de faire des requêtes SQL sur le résultat et éventuellement de produire des rapports sophistiqués.

type de résultat fourni :

no session ,
nom du User ,
no/nom du Terminal ,
nom de l’objet accédé ,
type d’ordre SQL ou de commande ,
Date d’occurence.

la table SYS.AUD$ et les vues DBA_% ne sont bien sur accessibles qu’au DBA…

la table SYS.AUD$ doit être surveillée et purgée par un DELETE (ou mieux un TRUNCATE) explicite de Mr SYS si nécessaire

Les vues d’audit dans le dictionnaire de données

Les vues d’audit sont normalement créées par CATALOG.SQL, et + précisément par le script CATAUDIT.SQL, lors de la création de la base.

Vue d’audit	Description du contenu
STMT_AUDIT_OPTION_MAP	code des types d’option
AUDIT_ACTIONS	codes des actions
ALL_DEF_AUDIT_OPTS	otion d’audit OBJET part défaut
DBA_STMT_AUDIT_OPTS	options d’audit courantes
DBA_PRIV_AUDIT_OPTS	options d’audit SYSTEME courantes
DBA_OBJ_AUDIT_OPTS, USER_OBJ_AUDIT_OPTS	options d’audit sur tous les objets et sur ceux du USER
DBA_AUDIT_TRAIL, USER_AUDIT_TRAIL	toutes les entrées d’audit et celles concernant uniquement le USER
DBA_AUDIT_OBJECT, USER_AUDIT_OBJECT	toutes les entrées d’audit OBJET et celles concernant uniquement le USER
DBA_AUDIT_SESSION, USER_AUDIT_SESSION	les entrées d’audit concernant toutes les (dé)connexions et celles concernant uniquement le USER
DBA_AUDIT_STATEMENT, USER_AUDIT_STATEMENT	les entrées d’audit concernant GRANT, REVOKE, AUDIT, NOAUDIT, et ALTER SYSTEM de tous ou du user connecté
DBA_AUDIT_EXISTS	les entrées d’audit concernant AUDIT EXISTS et AUDIT NOT EXISTS.

Autorisation de Mise en route de l’audit

il faut positionner le paramètre de démarrage AUDIT_TRAIL dans le fichier INIT.ORA de la base.

3 valeurs possibles :

NONE : invalide l’audit (valeur par défault)
DB : valide l’audit et stocke les résultats dans la table d’audit
OS : valide l’audit et stocke les résultats dans un fichier externe (un autre paramètre : AUDIT_FILE_DEST précise le répertoire de destination…)

SQL> — on modifie le paramètre AUDIT_TRAIL qui n’est pas dynamique
SQL> ALTER SYSTEM SET AUDIT_TRAIL=’DB’ SCOPE=SPFILE;
SQL> SHUTDOWN ABORT;
SQL> STARTUP

attention cette opération nécessite l’arrêt / démarrage de la base et NE DEMARRE PAS L’AUDIT !!

Déclenchement effectif de l’audit (ciblé) par le DBA ou un user autorisé

Il existe 4 niveaux d’audit :

connexion / déconnexion : surveille les connexions
ordre SQL : audit par type d’ordre SQL utilisé
privilège : audit d’un privilège SYSTEM (SELECT ANY, DROP ANY, CREATE ANY, * ANY…)
objet : un ordre SQL particulier sur un objet particulier (audit SELECT sur SCOTT.EMP)

A chaque niveau d’audit, on peut de + surveiller aussi bien LES SUCCES que LES ECHECS, et avoir une entrée d’audit par commande utilisateur ou globalement pour la session.

Le déclenchement de l’audit effectif se fait par la commande AUDIT et une ou des option(s), qui précise(nt) :

le type d’action à auditer,
si l’on veut les tentatives réussies ou échouées,
pour une session globale ou pour chaque ordre SQL

Exemples :

SQL> CONNECT WHENEVER NOT SUCCESSFULL
– surveille toutes les tentatives de connexions infructueuses

SQL> AUDIT CREATE ANY PROCEDURE
BY ACCESS
WHENEVER SUCCESSFULL
– audit système : surveille les création de procédures réussies nsur toutes la base, une entrée par commande passée.

SQL> AUDIT SELECT TABLE, DELETE TABLE
BY SESSION
WHENEVER NOT SUCCESSFUL
– surveille les select et insert infructueux sur n’importe quelle table, une entrée seulement par session

SQL> AUDIT INSERT ON scott.dept
– audit objet : surveille les insertion (réussies ou échouées) sur la table DEPT de SCOTT

Vérification des options d’audit en cours

Il suffit d’aller consulter les vues adéquates du dictionnaire de données (%AUDIT_OPTS) : ALL_DEF_AUDIT_OPTS , DBA_STMT_AUDIT_OPTS , DBA_PRIV_AUDIT_OPTS , DBA_OBJ_AUDIT_OPTS, USER_OBJ_AUDIT_OPTS

exemple

SQL> SELECT * FROM sys.dba_obj_audit_opts
WHERE owner = ‘SCOTT’ AND object_name LIKE ‘EMP%’;

OWNER OBJECT_NAME OBJECT_TY ALT AUD COM DEL GRA IND INS LOC
—– ———– ——— — — — — — — — —
SCOTT DEPT TABLE -/S -/- -/- A/- -/- S/S -/- -/- …
SCOTT D VIEW -/- -/- -/- -/A -/- -/- -/- -/- …

‘-’ : pas d’audit
‘S’ : par session
‘A’ : un par accès
à gauche du ‘/’ : Successful
à droite du ‘/’ : Not successful

La première ligne nous donne :
audit de la table DEPT de SCOTT : Alter not successfull, par session + delete successful par accès + creation d’index reussie ou échouée, par session !

Selection des résultats dans les vues d’audit

Faire un SELECT sur %_AUDIT_OBJECT ou %_AUDIT_SESSION ou %_AUDIT_STATEMENT

Exemple :

SQL> select OS_USERNAME, USERNAME, TERMINAL, TIMESTAMP
FROM dba_audit_session;

OS_USERNAME USERNAME TERMINAL TIMESTAMP
—————————————
TOTO TOTO pts/2 20-AUG-01
oracle SCOTT pts/3 20-AUG-01

SQL> select OS_USERNAME, USERNAME,TERMINAL,
TIMESTAMP, OWNER, OBJ_NAME,
from dba_audit_object; OS_USERNAME

USERNAME TERMINAL TIMESTAMP OWNER OBJ_NAME
————————————————-
SCOTT pts/3 20-AUG-01 SCOTT EMP

gestion des statistiques

admin — Mon, 30 May 2011 21:47:54 +0000

Vérification des statistiques collectées pour HR :

SQL> select table_name, last_analyzed
  2  from user_tables;
TABLE_NAME		       LAST_ANAL
------------------------------ ---------
REGIONS 		       13-MAY-11
LOCATIONS		       13-MAY-11
JOBS			       13-MAY-11
EMPLOYEES		       13-MAY-11
JOB_HISTORY		       13-MAY-11
COUNTRIES		       13-MAY-11
DEPARTMENTS		       13-MAY-11

Nous sommes le 30 le Job a l’air un peu ancien…

Vérification de la collecte automatique des statistiques à la console :

SERVEUR > Oracle Scheduler > Tache de maintenance automatisée.

Vérification de la date de création de la base :

SQL> select name, created
  2  from v$database;
NAME	  CREATED
--------- ---------
DD	  13-MAY-11

CQFD

plan d’exécution d’un ordre SQL et explain plan

admin — Mon, 30 May 2011 14:24:00 +0000

Il est possible de voir globalement le temps écoulé lors de l’exécution d’une requête SQL grace à l’option SQL*Plus ‘ SET TIMING ON’

Il est possible de visualiser ‘manuellement’ le plan d’exécution d’une requête SQL particulière grace à la commande ‘explain plan’.

Cette commande utilise une table système d’oracle, nommée PLAN_TABLE qui stocke les ligne correspondant au plan d’exécution choisi par l’optimiseur.
il existe un package PLSQL fourni par Oracle ( DBMS_XPLAN ) qui permet de visualiser le résultat formatté du plan d’exécution.
Voir l’exemple ci-après :

Se connecter à SH et lister les quantités et montant total des ventes par produitson

SQL> connect SH/SH
SQL> set timing on

SQL> select prod_name, sum(quantity_sold), sum(amount_sold)
from products p, sales s
 where p.prod_id= s.prod_id
 group by p.prod_name

71 rows selected.
Elapsed: 00:00:01.12

SQL> explain plan for
select prod_name, sum(quantity_sold), sum(amount_sold)
from products p, sales s
 where p.prod_id= s.prod_id
 group by p.prod_name

SQL> -- on configure un peu l'affichage
SQL> set pagesize 30
SQL> set linesize 150
SQL> select * from table(dbms_xplan.display)

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 504757596

----------------------------------------------------------------------------------------------------
| Id  | Operation        | Name       | Rows  | Bytes | Cost (%CPU)| Time       | Pstart| Pstop |
----------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT    |       |    71 |  4260 |   558  (14)| 00:00:07 |       |       |
|   1 |  HASH GROUP BY        |       |    71 |  4260 |   558  (14)| 00:00:07 |       |       |
|*  2 |   HASH JOIN        |       |    72 |  4320 |   557  (14)| 00:00:07 |       |       |
|   3 |    VIEW         | VW_GBC_5 |    72 |  2160 |   553  (14)| 00:00:07 |       |       |
|   4 |     HASH GROUP BY    |       |    72 |  1152 |   553  (14)| 00:00:07 |       |       |
|   5 |      PARTITION RANGE ALL|       |   918K|    14M|   498   (4)| 00:00:06 |     1 |    28 |
|   6 |       TABLE ACCESS FULL | SALES    |   918K|    14M|   498   (4)| 00:00:06 |     1 |    28 |
|   7 |    TABLE ACCESS FULL    | PRODUCTS |    72 |  2160 |     3   (0)| 00:00:01 |       |       |
----------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
   2 - access("P"."PROD_ID"="ITEM_1")

Optimisation grace aux vues matérialisées

admin — Fri, 27 May 2011 19:06:53 +0000

1) creer si necessaire le schema SH avec les scripts fournis

sous SQL+ lancer la requete suivante

SQL> SELECT p.prod_subcategory, t.calendar_month_desc, c.cust_city,
       SUM(s.amount_sold) AS sum_amount_sold,
       COUNT(s.amount_sold) AS count_amount_sold
FROM   sales s, products p, times t, customers c
WHERE  s.time_id=t.time_id
AND    s.prod_id=p.prod_id
AND    s.cust_id=c.cust_id
and t.calendar_year=1999
and country_id='US'
GROUP BY p.prod_subcategory, t.calendar_month_desc, c.cust_city;

2) Que fait elle ?
Verifier son temps d'execution : 

SQL> SET TIMING ON
...
...
...
22016 rows selected.
Elapsed: 00:00:05.62

3) afficher le PLAN d'execution

SQL> set linesize 160
SQL> select * from table(DBMS_XPLAN.DISPLAY);

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 790960488

------------------------------------------------------------------------------------------------------------------
| Id  | Operation                    | Name      | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     | Pstart| Pstop |
------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |           |   360K|    28M|       |  9096   (2)| 00:01:50 |       |       |
|   1 |  HASH GROUP BY               |           |   360K|    28M|    31M|  9096   (2)| 00:01:50 |       |       |
|*  2 |   HASH JOIN                  |           |   360K|    28M|       |  2119   (3)| 00:00:26 |       |       |
|   3 |    TABLE ACCESS FULL         | PRODUCTS  | 10000 |   224K|       |    61   (0)| 00:00:01 |       |       |
|*  4 |    HASH JOIN                 |           |   360K|    20M|  1016K|  2054   (3)| 00:00:25 |       |       |
|*  5 |     TABLE ACCESS FULL        | CUSTOMERS | 34445 |   605K|       |   183   (5)| 00:00:03 |       |       |
|*  6 |     HASH JOIN                |           |   360K|    14M|       |   893   (5)| 00:00:11 |       |       |
|*  7 |      TABLE ACCESS FULL       | TIMES     |   365 |  7300 |       |     9   (0)| 00:00:01 |       |       |
|   8 |      PARTITION RANGE SUBQUERY|           |  1016K|    21M|       |   874   (4)| 00:00:11 |KEY(SQ)|KEY(SQ)|
|   9 |       TABLE ACCESS FULL      | SALES     |  1016K|    21M|       |   874   (4)| 00:00:11 |KEY(SQ)|KEY(SQ)|
------------------------------------------------------------------------------------------------------------------

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("S"."PROD_ID"="P"."PROD_ID")
   4 - access("S"."CUST_ID"="C"."CUST_ID")
   5 - filter("COUNTRY_ID"='US')
   6 - access("S"."TIME_ID"="T"."TIME_ID")
   7 - filter("T"."CALENDAR_YEAR"=1999)

4) creer une VM correspondante

SQL> CREATE MATERIALIZED VIEW MV_VENTES1
AS SELECT p.prod_subcategory, t.calendar_month_desc, c.cust_city,
       SUM(s.amount_sold) AS sum_amount_sold,
       COUNT(s.amount_sold) AS count_amount_sold
FROM   sales s, products p, times t, customers c
WHERE  s.time_id=t.time_id
AND    s.prod_id=p.prod_id
AND    s.cust_id=c.cust_id
and t.calendar_year=1999
and country_id='US'
GROUP BY p.prod_subcategory, t.calendar_month_desc, c.cust_city;

5) Verifier le temps d'execution sur la VM

SQL> explain plan for
  2  select * from mv_ventes1;
Explained.

SQL>
SQL> select * from table(DBMS_XPLAN.DISPLAY);

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 1210413503

-----------------------------------------------------------------------------------
| Id  | Operation            | Name       | Rows  | Bytes | Cost (%CPU)| Time     |
-----------------------------------------------------------------------------------
|   0 | SELECT STATEMENT     |            | 18830 |  1397K|    30   (4)| 00:00:01 |
|   1 |  MAT_VIEW ACCESS FULL| MV_VENTES1 | 18830 |  1397K|    30   (4)| 00:00:01 |
-----------------------------------------------------------------------------------

6) verifier si le QUERY REWRITE est actif sur la base

SQL>  show parameter query

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
query_rewrite_enabled                string      TRUE
query_rewrite_integrity              string      enforced

7) créer une nouvelle VM comme la precedente mais avec l'option QUERY REWRITE

  re tester le SELECT de depart...

SQL> explain plan for
  2  SELECT p.prod_subcategory, t.calendar_month_desc, c.cust_city,
  3         SUM(s.amount_sold) AS sum_amount_sold,
  4         COUNT(s.amount_sold) AS count_amount_sold
  5  FROM   sales s, products p, times t, customers c
  6  WHERE  s.time_id=t.time_id
  7  AND    s.prod_id=p.prod_id
  8  AND    s.cust_id=c.cust_id
  9  and t.calendar_year=1999
 10  and country_id='US'
 11  GROUP BY p.prod_subcategory, t.calendar_month_desc, c.cust_city;

Explained.

SQL> select * from table(DBMS_XPLAN.DISPLAY);

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Plan hash value: 3325364141

-------------------------------------------------------------------------------------------
| Id  | Operation                    | Name       | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |            | 25025 |  1857K|    30   (4)| 00:00:01 |
|   1 |  MAT_VIEW REWRITE ACCESS FULL| VM_VENTES2 | 25025 |  1857K|    30   (4)| 00:00:01 |
-------------------------------------------------------------------------------------------