Implicitement le créateur d’un objet (TABLE, VUE , INDEX, etc.) est son propriétaire, et possède tous les droits sur le contenu et le contenant : consultation, mises à jour, insertion , suppression des liognes. Mais aussi modification et suppression de la structure.

En supposant qu’un user ait le droit de créer une table, implicitement il peut faire toutes les opérations suivantes :

SQL> CREATE TABLE test (n integer);
– on fait des modifs
SQL> INSERT INTO test VALUES(1);
SQL> UPDATE test SET n=2;
SQL> COMMIT;
SQL> DELETE FROM test; — on vide la table
–  on modifie la structure
SQL> ALTER TABLE test ADD (c char(1));
– et finalement on supprime structure et contenu eventuel
SQL> DROP TABLE test;

GRANT et REVOKE permettent respectivement de donner ou de supprimer les droits explicites d’accès en lecture ou mise à jour à un utilisateur particulier, pour un objet particulier.
C’est en général le propriétaire de l’objet qui peut donner des droits d’accès à un autrer utilisateur.
Sinon c’est le DBA (qui a tous les drorts)i

exemples:

SQL> GRANT SELECT ON TAB_CLIENTS TO MARTIN
SQL> GRANT UPDATE, INSERT ON TAB_CLIENTS TO DUPONT

Un utilisateur non propriétaire peut donner des droits sur un objet ne lui appartenant pas : le DBA bien sûr, mais aussi un utilisateur qui a recu des droits et le droit de transferer ce droit (GRANT OPTION)

exemple :

SQL> connect DBA1/DBA1
SQL> GRANT SELECT ON scott.emp TO martin;
SQL> GRANT SELECT, UPDATE, INSERT ON scott.emp TO dupont WITH GRANT OPTION;
SQL> CONNECT dupont/dupont
SQL> GRANT UPDATE ON scott.emp TO martin;

note : ‘GRANT OPTION’ est à utiliser avec parcimonie…

Le type de privilège dépend évidemment de l’objet sur lequel il s’applique. Ceci est résumé dans le tableau suivant :

TABLE	VUE	VUE MAT.	SEQUENCE	PROCEDURE
ALTER 			X				X
DELETE 			X	X	X
EXECUTE 								X
INDEX 			X
INSERT 			X	X	X
REFERENCES (1) 		X	X
SELECT 			X	X	X		X
UPDATE			X	X	X
ON COMMIT REFRESH	X
QUERY REWRITE		X

(1) possibilité de créer une clé étrangère sur la table

Une erreur très répandue consiste à référencer un objet (dont on n’est pas proprétaire), sur lequel on a des droits et qu’on oublie de préfixer…

SQL> SELECT COUNT(*)  from EMP
‘ Table or view doesn’t exists ‘ !!!
– alors que
SQL> SELECT * FROM SCOTT.EMP
–  donne un résultat !!!!

Le cas particulier des droits sur les programmes stockés (packages procédures et fonctions )

Pour exécuter une procédure il faut le droit …EXECUTE PROCEDURE.
Jusque la ca va.
Mais pour les objets sous-jacents à la procédure, Il y a 2 types de droits :
- en tant que créateur de la procédure ( DEFINER’s RIGHT)
- en tant qu’exécuteur de la procédure ( INVOKER’S RIGHT)

Dans les cas simples un utilisateur est propriétaire des tables et des procédures dans le même schéma et par défaut il execute la procédure en tant que créateur et a donc forcément les droits sur les objets du même schéma.

Pour les packages du dictionnaire par contre qui appartiennent à SYS il serait délicat de les exécuter en tant que …SYS, ils sont donc créés avec ‘INVOKER’s RIGHT’

exemple de procédure

SQL> -- c'est lemot réservé AUTHID qui définit les droits 'executeur'
SQL>create or replace procedure TEST
authid current_user is
begin
...

Les privilèges systèmes sont des privilèges qui à la différence des privilèges d’accès aux objets s’intéressent plutôt au contenant qu’au contenu. Ils concernent principalement des ordres de création, de modification de structures et de suppression d’objets.
Ce sont donc des privilèges d’assez haut niveau, que l’on réservera par exemple aux développeurs mais qui seront utilisés avec beaucoup de parcimonie en phase de production…

Attention notamment à l’option ‘ANY’

Quelques exemples :

ALTER SNAPSHOT	Modifier tous les snapshots dans tous les schémas.
DROP ANY SNAPSHOT	Supprimer tous les snapshots dans tous les schémas.
SYNONYM
CREATE SYNONYM	créer un synonym dans son schema.
CREATE SYNONYM	Créer tous les synonyms dans tous les schémas.
DROP ANY SYNONYM	Supprimer tous les synonyms dans tous les schémas.
SYSTEM
ALTER SYSTEM	faire des ALTER SYSTEM .
TABLE
CREATE TABLE	Créer des tables ou des indexs dans son propre schéma
CREATE ANY TABLE	Créer des tables dans tous les schémas.
ALTER ANY TABLE	Modifier toutes les table dans tous les schémas et compiler toutes les vues dans tous les schémas.
BACKUP ANY TABLE	Réaliser des exports incrémentaux.
DROP ANY TABLE	Supprimer ou vider toutes les table dans tous les schémas.
LOCK ANY TABLE	Verrouiller toutes les tables ou vues dans tous les schémas.
COMMENT ANY TABLE	Commenter toutes les tables, vues, ou colonnes dans son schema.
SELECT ANY TABLE	Interroger toutes les tables, vues, ou clichés dans tous les schémas.

Il n’existe pas de notion de groupe d’utilisateur sous Oracle, mais la notion de rôle, qui permet de nommer un groupe de privilèges. On peut affecter un rôle à un ou n utilisateurs, voire à un rôle.

Gestion des rôles

Les rôles se créent et se suppriment respectivement  avec l’instruction ‘CREATE ROLE’ et ‘DROP ROLE’.
Pour pouvoir faire ces opération il faut bien sûr des privilègess : le droit systeme ‘CREATE ROLE’.
Ensuite on les enrichit par des GRANT de privilège objets, systeme ou des GRANT de …ROLEs.
Un rôle peut ainsi en cascade inclure d’autres roles.

Une fois créé le rôle sera GRANTé à 1 ou n USERs ou ROLEs.

SQL>  CREATE ROLE consulte_client;
SQL> CREATE ROLE modif_client;
SQ> GRANT CREATE SESSION TO consulte_client; — un droit systeme minimal !
SQL> GRANT SELECT ON gestion.client to consulte_client; — et un droit de consultation D’UN objet
SQL> GRANT UPDATE ON gestion.client to modif_client; — droit de modif
SQL> GRANT consulte_client TO MARTIN; — on donne le role a un user
SQL> GRANT consulte_client TO modif_client; - on donne un role a un role, et on comprend bien que si on a le droit de modifier on a aussi sans besoin de pouvoir consulter
SQL> GRANT modif_client TO dupont;
– et je donne le droit de créer des roles (pas forcément une bonne ideée…) à l’administarteur de l’application
SQL> GRANT CREATE ROLE TO roberto;

rem importante : lorsqu’on crée un ROLE on ‘hérite’ implicitement de ce rôle avec l’option ADMIN ! Cela est utile pour pouvoir donner ce rôle à quelqu’un une fois qu’on l’acréé. Attention tout de m^me à l’inflation de rôle possible du DBA

Rôles par défaut

Lorsqu’un utilisateur se connecte, il ‘prend’ ses rôles par défaut.
Au cours de sa session, Il lui est possible d’en rajouter ou d’en enlevre, avec la commande SET ROLE.
Pour voir la liste des rôles actuellement actif, consulter la table SESSION_ROLES du dictionnaire.

SQL> CONNECT SYSTEM/xxx
SQL> SELECT * FROM session_roles;

Rôles prédéfinis

Il existe un certain nombre de rôles prédéfinis, fournis avec Oracle 10g. Voici une liste de ces rôles avec les privilèges système qu’ils offrent :

CONNECT :
Se connecter ! équivalent du privilège système ‘CREATE SESSION’Attention !!! en version 10gR1 et antérieures, ce rôle donnait beaucoup + de privilèges, à savoir :
ALTER SESSION, CREATE CLUSTER, CREATE DATABASE LINK, CREATE SEQUENCE,
CREATE SESSION, CREATE SYNONYM, CREATE TABLE, CREATE VIEW

RESOURCE :
créer des données avec des quotas sur tous les tablespaces ->
CREATE CLUSTER, CREATE INDEXTYPE, CREATE OPERATOR, CREATE PROCEDURE,
CREATE SEQUENCE, CREATE TABLE, CREATE TRIGGER, CREATE TYPE

DBA :
Tous les privilèges système avec ADMIN OPTION

EXP_FULL_DATABASE :
export complet ou incrémental ->
SELECT ANY TABLE, BACKUP ANY TABLE, EXECUTE ANY PROCEDURE, EXECUTE ANY TYPE, ADMINISTER RESOURCE MANAGER, and

INSERT, DELETE, and UPDATE on the tables SYS.INCVID, SYS.INCFIL, and SYS.INCEXP. Also the following roles:

EXECUTE_CATALOG_ROLE and SELECT_CATALOG_ROLE.

IMP_FULL_DATABASE :
import full + tous les privilèges système + role

DELETE_CATALOG_ROLE :
droit DELETE sur la table SYS.AUD$

EXECUTE_CATALOG_ROLE : privilège EXECUTE sur les objets du dictionnaire + HS_ADMIN_ROLE.

SELECT_CATALOG_ROLE : accès en consultation au dictionnaire + HS_ADMIN_ROLE.

RECOVERY_CATALOG_OWNER : privilèges pour le propriétaire du catalogue de restauration ->
CREATE SESSION, ALTER SESSION, CREATE SYNONYM, CREATE VIEW, CREATE DATABASE LINK,
CREATE TABLE, CREATE CLUSTER, CREATE SEQUENCE, CREATE TRIGGER, and CREATE PROCEDURE

HS_ADMIN_ROLE
protection des accès (SELECT et EXECUTE) au référentiel HS (Heterogeneous Services) data dictionary tables

(grants SELECT) and packages
AQ_ADMINISTRATOR_ROLE
privilèges d’administration de l’ Advance Queuing. Notamment : ENQUEUE ANY QUEUE, DEQUEUE ANY QUEUE, et MANAGE

ANY QUEUE + SELECT sur les tables AQ + EXECUTE sur les packages AQ.

Rôles applicatifs

Pour bien gérer la sécurité des application il est nécessaire de créer des rôles, adaptés aux besoins et bien sûr à minima.
Un utilisateur de l’applicatif  (MARTIN) se connectera à son compte, et via un rôle précis accèdera aux données dont il a besoin (RH) .
Ce que l’on voit malheureusement souvent c’est :

Tous les utilisateurs de l’applicatif (par exemple MARTIN, DUPONT, …) se connectent dans le même compte applicatif propriétaire des données (par exemple RH) et ont  donc par définition tous les droits sur les données RH.

Exemple de bonne pratique  : on peut créer un rôle qui donne uniquement des droits de consultation sur quelques tables d’un schéma :

– creation du role
SQL> create role consult_finance;
– affectation des privileges au role
SQL> grant select on budget to consult_finance;
SQL> grant select on fournisseur to consult_finance;
SQL> grant select on client to consult_finance;
– cession du role aux utilisateurs
SQL> grant consult_finance to user_finance_1;
SQL> grant consult_finance to user_finance_2;

Note : un user ne peut pas hériter de plus de ‘MAX_ENABLED_ROLES’ paramètre d’initialisation de la base, dont la valeur par défaut est 30 en 10g. Cela parait peu probable pour un applicatif classique (voire déraisonnable).
Dans le cas d’une console d’administration centrale (console 10g GRID ou server manager console). Le user d’administration connecté hérite de tous les droits qu’il crée…ce qui est beaucoup plus fréquent ! et la limite MAX_ENABLED_ROLES peut être facilement atteinte et … empêcher une connexion à la console !

Informations sur les rôles dans le référentiel (dictionnaire) Oracle 10g

DBA_ROLES
Tous les roles !
DBA_ROLE_PRIVS, USER_ROLE_PRIVS
roles donnés aux users et/ou aux roles
ROLE_ROLE_PRIVS
roles donnés aux roles
ROLE_SYS_PRIVS
privilèges systèmes donnés aux roles (accessible au user)
ROLE_TAB_PRIVS
privilèges objets donnés aux roles (accessible au user)
SESSION_PRIVS
privilèges de la session courante
SESSION_ROLES
roles de la session courante

Les rôles et la console GRID 10g
La console donne par defaut le role CONNECT, cela ne pose pas de pb de sécurité sur une base 10g…mais si on s’en sert pour administrer une base 9i (avec l’agent qui va bien) le role CONNECT offre presque tous les privilèges de création/suppression de données dans le schéma.

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
) ;

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

————————————————–
– une vue de BLAKE sur une table de SCOTT
————————————————–
connect scott
(scott a les droits sur la table)
create view vscott as select * from emp

connect blake
select * from scott.vscott
*
ERROR at line 1:
ORA-00942: table or view does not exist

connect scott
grant select on emp to blake

…le droit sur la table sert pour accéder …a la table
connect blake
select * from scott.vscott
*
ERROR at line 1:
ORA-00942: table or view does not exist

…Le droit sur la vue suffit
connect scott
grant select on vscott to blake

connect blake
select * from scott.vscott
–> OK

———————————————————
—KING accede a une vue de BLAKE sur une table de SCOTT
———————————————————
connect SYSTEM
grant select on scott.emp to blake;
create view blake.vblake as select * from scott.emp
connect SYSTEM
SQL> grant select on blake.vblake to king;
Autorisation de privilèges (GRANT) acceptée.
connect KING
select * from blake.vblake
*
ERROR at line 1:
ORA-01031: insufficient privileges

Si on avait tenté de donner les droits en tant que BLAKE
cela aurait été plus clair :
connect blake
grant select on blake.vblake to king
*
ERROR at line 1:
ORA-01720: grant option does not exist for ‘SCOTT.EMP’

LA SOLUTION
connect SCOTT (ou SYSTEM)
grant select on scott.emp to blake WITH GRANT OPTION

Diagnostic Files

• The alert.log file
• Trace files
• Core dump files
• System log files

Diagnostic Files
Generally speaking most diagnostic efforts should begin with a look at the alert.log file.
Often, simple problems become difficult ones because this step has been omitted. Errors written
to the alert.log file might possibly point the user to look at specific trace files for more
detailed information.
On some operating systems, abnormally terminated processes will leave a core file. This core file
can sometimes provide valuable insight when viewed with the platform debugger. On Solaris
platforms for example, adb is the debugger used for this purpose.

Note that a core file is useless without the executable that generated the core file. If a usable
trace file (with a call stack) is available, core files will not supply additional useful information.
However, when a trace file is missing, a call stack can be generated from the core file using a
debugger at the operating system level.
Note: Depending on the problem, one or more of the files listed in the slide may not exist.
Oracle Database 10g: Administration Workshop II 6-4

The Alert Log

The Alert Log contains:
• All internal errors
• Administrative operations, such as CREATE, ALTER,
and DROP statements
• Shared server errors
• Materialized view refresh errors
• Initialization parameter values

Each server and background process can write to an associated trace file. When an internal error
is detected by a process, it dumps information about the error to its trace file. The alert file, or
alert log, is a special trace file. The alert file of a database is a chronological log of messages and
errors, which includes the following:
• All internal errors (ORA-600), block corruption errors (ORA-1578), and deadlock errors
(ORA-60) that occur
• Administrative operations, such as CREATE, ALTER, and DROP statements and STARTUP,
SHUTDOWN, and ARCHIVELOG statements
• Several messages and errors relating to the functions of shared server and dispatcher
processes
• Errors occurring during the automatic refresh of a materialized view
• The values of all initialization parameters at the time the database and instance start
The Oracle Database uses the alert file to keep a log of these special operations as an alternative
to displaying such information on an operator’s console. If an operation is successful, a
“completed” message is written in the alert file, along with a timestamp.

What Is in the alert.log File
Every instance generates a file called alert.log,
which logs the following information:
• Diagnostic data from background and foreground
processes
• Summary information regarding errors and
pointers to trace files for detailed information
• Information since database creation (unless
purged) that might be useful in backtracking a
problem
The alert.log File
The alert.log file is written in the BACKGROUND_DUMP_DEST directory and follows the
naming convention alert_ORACLE_SID.log. Here are excerpts from an example
alert.log:
Wed Jan 21 05:48:20 2004
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Shared memory segment for instance monitoring created
Picked latch-free SCN scheme 2
…
Starting up ORACLE RDBMS Version: 10.1.0.2.0.
System parameters with non-default values:
processes = 150
shared_pool_size = 83886080
…
WARNING: Files may exists in db_recovery_file_dest that are not known to the
database. Use the RMAN command CATALOG RECOVERY AREA to re-catalog any such
files. One of the following events caused this:
1. A backup controlfile was restored.
2. A standby controlfile was restored.
3. The controlfile was re-created.
4. db_recovery_file_dest had previously been enabled and then disabled.

Viewing Recent Alert Log Entries

Recent alert log entries can be easily viewed using Enterprise Manager instead of resorting to
operating system utilities like vi or more. From the database home page, select the Alert Log
Content link from the Related Links area at the bottom of the page. The default action of this
page is to display or “tail” the most recent 100,000 bytes of the alert.log file. Note that the
data displayed will contain all the data mentioned previously such as administrative actions,
startup and shutdown information, etc., not just raised alerts. If you wish to view alerts only, go
to the bottom of the database home page for a list of current alerts and events triggered by
exceeding pre-configured thresholds.
You can also view entries in the Alert Log that contain ORA- errors by clicking the Alert Log
link in the Diagnostic Summary region of the Database Control Console Home page.

Alert Models Architecture
Oracle Database 10g provides alerts about problems to the administrator via the Enterprise
Manager Database Console. An alert condition discovery is based on some internally determined
or customer-defined threshold, or when certain events occur. The Oracle Database automatically
collects a significant number of metrics which used to be computed by Enterprise Manager (EM).
Early notification of potential problems allows you to respond quickly, and often resolve issues
before users even notice them.
The metrics computation and threshold validations are performed by the MMON process or by the
EM Agent, which checks for the monitored condition using a polling-based mechanism.
Server-generated alerts are queued into the predefined persistent queue ALERT_QUE owned by
SYS. EM Database Control Console is the main consumer of the ALERT_QUE. Depending on
the Database Control Console setup, you are notified via e-mail or pager. Server-generated alerts
are always displayed on the Database Control home page.
The ALERT_QUE is a multi-consumer queue. So, as a third-party client, you can subscribe to
that queue using the CREATE_AQ_AGENT and ADD_SUBSCRIBER procedures of the
DBMS_AQADM package. An alert is not purged until all subscribers have dequeued it. If you
dequeued it, you do not see it anymore but other subscribers do.
Note: If an alert cannot be written to the alert queue, a message about the alert is written to the
Oracle Database alert log file.

Server-Generated Alert Types
MMON
85%Warning
97% Critical Cleared
Cleared
Alert
Snapshot
Too Old
Resumable
Session
Suspended
Recovery Area
Low On
Free Space
Metric-based
Event-based
Threshold
(stateful)
alerts
Nonthreshold
(stateless)
alerts
DBA_OUTSTANDING_ALERTS DBA_ALERT_HISTORY
Server-Generated Alert Types
There are two kinds of server-generated alerts: threshold and nonthreshold. Most servergenerated
alerts are configured by setting a warning and critical threshold values on database
metrics. You can define thresholds for more than 120 metrics. For example:
• Physical Reads Per Sec
• User Commits Per Sec
• SQL Service Response Time
Except for the Tablespace Space Usage metric, which is database related, the other metrics are
instance related. Threshold alerts are also referred to as stateful alerts. These alerts are
automatically cleared when an alert condition clears. When the severity level of an outstanding
alert is updated, a new alert message is sent out. When the problem condition is cleared, the
outstanding alert is moved to the alert history. Alert history is purged according to workload
repository snapshot purging policy.
Other server-generated alerts correspond to specific database events such as Snapshot Too Old
errors and Recovery Area Low On Free Space. These are non-threshold-based alerts, also
referred to as stateless alerts. Stateless alerts go directly to the history table. Clearing a stateless
alert makes sense only in the Database Control environment, because Database Control stores
stateless alerts in its own repository.

Viewing Alerts with Enterprise Manager

Alert General View
Viewing Alerts with Enterprise Manager
Alerts raised by the database and those that are raised by exceeding user-defined threshold
values can be viewed at a glance from the Enterprise Manager database home page under the
Alerts and Related Alerts headings.
Any ORA-nnnnn errors that are raised can be seen by clicking the Alert Log link located under
the Diagnostic Summary section.

Alert Details
Viewing Alerts with Enterprise Manager (continued)
Alerts raised and displayed on the Enterprise Manager database home page under the Alerts and
Related Alerts headings can be drilled down to view details about alerts of interest to you. By
clicking on the Filesystem / has only 18%available space link, in the Message column of the
Related Alerts table, the detail page shown above is displayed.
In addition to providing threshold statistics, a timeline is provided to track graphically the
activity for a 24 hour period surrounding the alert. The graph also uses colored sections to
indicate the warning threshold and the critical threshold values. In the graphic shown above, the
disk space utilization is operating within the warning threshold limits, but has not yet reached
critical levels.

Alerts Notification

Des notifications peuvent être programmées pour vous informer de certains événements en fonctions de règles définies.
Les alertes peuvent se faire par mail, interruption SNMP ou déclencher un script.
On peut y accéder via la console EM : page d’accueil /lien préférences / Notification / règles

Alert Log Monitoring Configuration
Enterprise Manager provides an alert filter configuration page that can be found by clicking on
the Alert Log Errors link located under the Diagnostic Summary section of the database home
page and then choosing the Generic Alert LogMonitoring Configuration link. The DBA can
filter out any errors not to be considered generic alerts by using standard Unix regular
expressions. In the slide example, the expression
“.*ORA-0*(54|1142|1146)D.*” prevents ORA-00054 (resource busy…), ORA-
01142 (cannot end online backup - none of the files are in backup) , and ORA-01146 (cannot
start online backup - file is already in backup) errors from being displayed under Alerts and
Related Alerts section on the Database Control home page.
In addition, this page allows you to edit the “critical” and “warning” thresholds for the alert log
errors that are displayed on the database home page thereby controlling when these generic alerts
are raised. Other alert log error thresholds can be modified by selecting the Alert Log Errors
link and then clicking on the EditMetrics Thresholds link.

Editing Thresholds
Other alert thresholds can be modified by clicking on the Alert Log Errors link located under
the Diagnostic Summary section of the database home page and then choosing the EditMetrics
Thresholds link. Here, you can select any metric tracked by the database and set the warning
threshold and critical threshold values for that metric. Additionally, you may specify a command
or script to be executed when the alert is raised in the Response Action column.
For certain metrics it is possible to specify multiple thresholds. For example, the Tablespace
Space Usage metric can be set for individual tablespaces.
Oracle Database 10g: Administration Workshop II 6-14
6-14 Copyright © 2004, Oracle. All rights reserved.
Viewing Initialization Parameters
Viewing Initialization Parameters
The alert log shows initialization parameters of the database when started as mentioned earlier.
You can view initialization parameters using Enterprise Manager by following these steps:
1. Navigate to the database home page.
2. In the Instance section on the Administration page, click All Initialization Parameters.
Enterprise Manager displays the Initialization Parameters page comprised of a table listing
the current value of each initialization parameter as seen by the database instance.
3. You make your changes to the parameters as necessary and then click Save to File.

Trace Files

• Every server process, on encountering an
exception, writes diagnostic data to a trace file
• The trace file header contains the following
information:
– OS and version
– Oracle version and options installed
– Instance name
– Process ID
Trace Files
Here is a sample trace file containing a logged error:
Dump file /u01/app/oracle/admin/orcl/udump/orcl_ora_23042.trc
Oracle Database 10g Enterprise Edition Release 10.1.0.2.0
With the Partitioning, OLAP and Data Mining options
ORACLE_HOME = /u01/app/oracle/product/10.1.0
System name: Linux
Node name: EDCDR12P1
Release: 2.4.9-e.25
Machine: i686
Instance name: orcl
Redo thread mounted by this instance: 1
Oracle process number: 35
Unix process pid: 23042, image: oracle@EDCDR12P1 (TNS V1-V3)
*** ACTION NAME:(0000023 STARTED16) 2004-01-16 13:35:42.282
*** MODULE NAME:(backup full datafile: ORA_DISK_1) 2004-01-16
13:35:42.282
*** SERVICE NAME:(SYS$USERS) 2004-01-16 13:35:42.282
*** SESSION ID:(131.47) 2004-01-16 13:35:42.282
clsssinit: Unable to access OCR device in OCR init.PROC-26: Error
while accessing the physical storage
kgxgncin: CLSS init failed with status 21

Specifying the Location of Trace Files
Initialization parameters controlling the location and
size of trace files include:
• BACKGROUND_DUMP_DEST
• USER_DUMP_DEST
• MAX_DUMP_FILE_SIZE
Specifying the Location of Trace Files
All trace files for background processes and the alert log are written to the destination directory
specified by the initialization parameter BACKGROUND_DUMP_DEST. In most cases, these
parameters are set when the database is created initially, although the locations can be changed
later if desired. All trace files for server processes are written to the destination directory
specified by the initialization parameter USER_DUMP_DEST. The names of trace files are
operating system specific, but each file usually includes the name of the process writing the file
(such as LGWR and RECO).
Initialization parameters controlling the location and size of trace files are:
• BACKGROUND_DUMP_DEST
• USER_DUMP_DEST
• MAX_DUMP_FILE_SIZE

Controlling Trace File Size
You can control the maximum size of all trace files (excluding the alert file) using the
initialization parameter MAX_DUMP_FILE_SIZE. This limit is set as a number of operating
system blocks. To control the size of an alert file, you must manually delete the file when you no
longer need it; otherwise Oracle continues to append to the file. You can safely delete the alert
file while the instance is running, although you might want to make an archived copy of it first.
To change the value of MAX_DUMP_FILE_SIZE and make it permanent, execute the following
SQL statement:
SQL> ALTER SYSTEM SET max_dump_file_size = “10m” scope = both
To adjust the size of trace files using Enterprise Manager, select the Administration folder tab.
Under Instance, click on the All Initialization Parameters link. The parameter list is rather
large, so type MAX_DUMP_FILE_SIZE in the filter window and click on the Go button. The
default value for the parameter is unlimited. Type in the value that you deem sufficient in the
Value field and click on the Apply button. This will change the parameter in memory only. To
make the change persistent, click on the SPFile tab and set the value there also.

Controlling Trace File Writes
• Trace files are usually generated by a server
process upon encountering an error.
• Some background processes like ARCn, have
parameters that control the amount and type of
trace information generated.
• In some instances, trace files can be generated for
server processes at user request.
SQL> ALTER SESSION SET SQL_TRACE TRUE;
Controlling Trace File Writes
Background processes always write to a trace file when appropriate. In the case of the ARCn
background process, it is possible, through an initialization parameter, to control the amount and
type of trace information that is produced. Other background processes do not have this
flexibility. Trace files are written on behalf of server processes whenever internal errors occur.
For example, setting the initialization parameter SQL_TRACE = TRUE causes the SQL trace
facility to generate performance statistics for the processing of all SQL statements for an
instance and write them to the USER_DUMP_DEST directory.
Trace files can be generated for server processes at user request. Regardless of the current value
of the SQL_TRACE initialization parameter, each session can enable or disable trace logging on
behalf of the associated server process by using the SQL statement ALTER SESSION SET
SQL_TRACE. This example enables the SQL trace facility for the current session:
SQL> ALTER SESSION SET SQL_TRACE TRUE;

Using Enterprise Manager to Enable and View SQL Tracing

SQL> SELECT * FROM dba_enabled_traces;
Using Enterprise Manager to View Enabled Traces
You can enable, disable and view SQL tracing on the Top Modules, Top Actions, and Top Client
pages. You navigate to these pages from the Database Control home page and click the
Performance tab. You then select Top Consumers from the Additional Monitoring link, and
choose Top Services, TopModules, Top Actions, Top Clients, and Top Sessions.
You can query DBA_ENABLED_TRACES view to determine the traces enabled. The
DBA_ENABLED_TRACES view contains the following columns:
• trace_type: Type of trace: CLIENT_ID, SESSION, SERVICE, SERVICE_MODULE,
SERVICE_MODULE_ACTION
• primary_id: Primary qualifier, such as specific client identifier or service name
• qualifier_id1: Secondary qualifier, such as specific module name
• qualifier_id2: Additional qualifier, such as specific action name
• waits: TRUE if waits are traced
• binds: TRUE if binds are traced
• instance_name: Instance name for tracing restricted to named instances

System Log Files

• System log files capture error messages and
exceptions encountered at the OS level
• These would be useful if a hardware or OS
problem is suspected
System Log Files
Operating system log file locations vary depending on the specific platform. On Solaris, for
example, look at the /var/adm/messages file for system error messages. Check with the
product line or the operating system vendor for the location and name of the operating system
message file. Some typical examples of errors at the OS level are paging failures, I/O errors,
network errors, and swapping errors.
Example of a /var/adm/messages file
Sep 14 10:52:33 stc-sun02 unix: NOTICE: quota_ufs: Warning: over disk limit
(pid 1 5606, uid 19113, inum 37358, fs /home)
Sep 14 10:55:42 stc-sun02 inetd[1294]: printer/tcp: bind: Address already in
use
Sep 14 11:16:08 stc-sun02 inetd[1294]: printer/tcp: bind: Address already in
use
Sep 14 11:16:46 stc-sun02 unix: NOTICE: quota_ufs: Warning: over disk limit
(pid 1 8298, uid 34915, inum 1272507, fs /home)
Sep 14 11:46:48 stc-sun02 inetd[1294]: printer/tcp: bind: Address already in
use
Sep 14 11:53:03 stc-sun02 unix: NOTICE: quota_ufs: over disk and time limit
(pid 2 4428, uid 13952, inum 1542289, fs /home)
Sep 14 11:56:58 stc-sun02 inetd[1294]: printer/tcp: bind: Address already in
use
Sep 14 12:10:25 stc-sun02 unix: NOTICE: quota_ufs: over disk and time limit
(pid 2 4401, uid 13952, inum 1542526, fs /home)