Gestion d’une instance et création d’une BD Oracle

Administration des bases de données

Chapitre 2

Initialisation de l’OS et authentification du password file

Création d’un PFILE et d’un SPFILE

Démarrage d’une instance et ouverture de la BD

Fermeture de la BD et arrêt de l’instance

Création de BD

Construction des vues du dictionnaire de données

Utilisation du dictionnaire de données

Objectifs

Une BD oracle n’est disponible à l’user que lorsque le DBA a démarré une instance et ouvert la BD

Les étapes de démarrage sont :Démarrage d’une instance

Mount database

Open database

À chaque démarrage d’une instance, Oracle utilise un parameter file, contenant les paramètres d’initialisation, pour allouer le SGA et démarrer les background processes

Si une instance est démarrée ou une BD est ouverte, alors pour la fermeture de ces derniers, il faut suivre les étapes suivantes :

Close database

unMount database

Généralités

Les 2 users administrateurs SYS et SYSTEMSont créés automatiquement lors de la création de la BDPossèdent le rôle DBA (tous les privilèges systèmes)

SYSPassword : change_on_installOwner of database dictionnary

SYSTEMPassword : managerPropriétaires de tables supplémentaires utilisées par Oracle Tools

Utilisateurs administrateurs de BD

Pour que une BD soit ouverte, le DBA doit s’authentifier en utilisant :

une méthode d’authentification par OS

Ou une méthode d’authentification par fichier mot de passe

Méthodes d’authentification

La méthode d’authentification d’un user par un OS diffère selon le système : UNIX ou NT

Les étapes générales sont :Définition de l’user à être authentifié par l’OS

Initialisation du paramètre REMOTE_LOGIN_PASSWORDFILE à NONE

Utilisez les commandes suivantes pour vous connecter à une BD : CONNECT /AS {SYSDBA|SYSOPER} SYSDBA et SYSOPER sont des privilèges spéciaux de DBA

Authentification par OS

Oracle fournit un utilitaire de gestion des password qui permet la connexion au noyau Oracle

Les étapes générales sont :

Créer le password file en utilisant l’utilitaire de gestion des mots de passe ORAPWD pour UNIX ou ORAPWD90 pour NT:

Orapwd file=<fname> password=<password> entries=<entries>

Fname : nom du password filepassword : le mot de passe de SYSentries : est le nombre maximum d’administrateurs distincts de BD

Authentification par password file1/2

Les étapes générales sont:

Initialisation du paramètre REMOTE_LOGIN_PASSWORDFILE à EXCLUSIVE ou SHARED

EXCLUSIVE: indique qu’une seule instance peut utiliser le password file et qu’il contient d’autres noms autre que SYS et SYSTEM

SHARED : indique que plusieurs instances peuvent utiliser le password file (les seuls users reconnus par le password file sont SYS et INTERNAL)

Utilisez la commande suivante pour vous connecter à une BD : CONNECT admin

Authentification par password file 2/2

Se trouve sous le répertoire $ORACLE_HOME/dbs

Fichier texte qui peut être manipulé par n’importe quel éditeur

Le parameter file est lu au moment du démarrage de l’instance. Dans le cas où on modifie des paramètres non dynamiques du fichier, il faut fermer et redémarrer l’instance pour prendre en considération les nouvelles valeurs

Quelques paramètres sont dynamiques ( peuvent être pris en charge sans fermer l’instance)

Les paramètres dans init<SID>.ora ont un effet non négligeable sur les performances de la BD

Creation d’un parameter file (PFile)

Se trouve sous le répertoire $ORACLE_HOME/dbs

Le SPFILE est un fichier binaire qui ne peut pas être édité par n’importe quel éditeur standard

Crée à partir d’un PFILE standard et donc nécessite l’existence du fichier PFILE

SQL> CREATE SPFILE FROM PFILE;

Au prochain démarrage de l’instance, seulement le SPFILE sera utilisé pour l’initialisation de la BD

Paramètres du fichier modifiés par la commande ALTER SYSTEM

SQL> ALTER SYSTEM SET log_archive_dest = ‘/oracle/archive/DB01’;

Creation d’un parameter file (SPFile)

Exemple de parameter file

Démarrage d’une instanceLecture du parameter file init<SID>.oraAllocation de la SGADémarrage des background processesOuverture des fichiers trace et ALERT(journaux chronologiques des messages d’erreur)

Monter la BDAssocier une BD à une instance déjà démarréeLocaliser et ouvrir les control files spécifiés dans les parameter filesLire les control files pour obtenir les noms et les états des data files et redo log files

Ouvrir la BD : Open data and redo log filesSi un des fichiers n’est pas présent, Oracle renvoie une erreur

Etapes de démarrage

Fermer la BD Quand la base se ferme, Oracle écrit les changements du database buffer cache et les entrées du buffer redo log dans les datas files and redo log filesOracle ferme tous les datas and redo log filesLes control files restent ouverts

DéMonter la BD d’une instanceFermeture des control files

Arrêt de l’instanceLibération de la SGAArrêt des background processesFermeture des fichiers trace et ALERT (journaux chronologiques des messages d’erreur)

Etapes d’arrêt

La commande STARTUP démarre l’instance et ouvre la BD

STARTUP [FORCE] [PFILE=parafile] [EXCLUSIVE | PARALLEL | SHARED] [OPEN | MOUNT | NOMOUNT]

FORCE : annule l’instance courante avant d’effectuer le démarrage

PFILE=parafile : utilisation du parameter file pour la configuration de l’instance

OPEN : permet aux users d’accéder à la BD

EXCLUSIVE : autorise l’instance courante à accéder à la base

PARALLEL : autorise plusieurs instances à accéder à la base

SHARED PARALLEL

MOUNT : monte la BD mais ne permet pas l’accès à la base

NOMOUNT : crée la SGA et démarre les background processes mais ne permet pas l’accès à la base

STARTUP PFILE=/DISK/initU15.ora

Commande de démarrage

La commande SHUTDOWN arrête une instance

SHUTDOWN [NORMAL | TRANSACTIONNEL | IMMEDIATE | ABORT]

Arrêt normal est l’arrêt par défaut

De nouvelles connexions ne sont pas permises

SO attend la déconnexion de tous les users avant de terminer l’arrêt (temps d’attente peut être important sans délai prévisible de fermeture)

Oracle ferme et démonte la base avant d’arrêter l’instance

Pas de restauration de l’instance lors du démarrage suivant (car toutes les informations modifiées encore présente dans la SGA sont écrites dans les dats and redo log files)

Commande d’arrêt

Arrêt transactionnel

De nouvelles connexions ne sont pas permises

Le client ne sera plus connecté dès la fin de la transaction en cours

Pas de restauration de l’instance lors du démarrage suivant

Arrêt immediat

De nouvelles connexions ne sont pas permises

SO n’attend pas la déconnexion des users avant de terminer l’arrêt

Les ordres SQL en cours ne seront pas traités

Oracle ferme et démonte la base avant d’arrêter l’instance

Pas de restauration de l’instance lors du démarrage suivant

Commande d’arrêt

Arrêt abort

De nouvelles connexions ne sont pas permises

SO n’attend pas la déconnexion des users avant de terminer l’arrêt

Les ordres SQL en cours ne seront pas traités

Les transactions non commitées ne seront pas effacées (rollback)

L’instance sera fermé sans la fermeture des fichiers

Restauration de l’instance lors du démarrage suivant

Commande d’arrêt

L’étape 1 jusqu’à l’étape 5 décrit un transfert d’argent d’une banque à une autre

1 Interrogation du compte afin de récupérer le solde

2 Exécution de la commande INSERT pour transférer les fonds au nouveau compte

3 Exécution de la commande DELETE afin de supprimer les fonds du solde courant

4 Exécution d’un COMMIT pour finir correctement la transaction

5 Déconnexion du SO

Les différents types d’arrêt-Exemple

Normal shutdown : SO attend la déconnexion de tous les users avant de terminer le shutdown

Immediate shutdown : SO termine l’ordre SQL en cours (step 2) et annule la transaction en cours

Transactional shutdown : SO attend la fin de la transaction (step 4)

Abort shutdown : SO termine la commande SQL en cours, cependant la transaction en cours ne sera pas annulée

Les différents types d’arrêt-Exemple

Création d’une BD

Création de la BD en utilisant Oracle Database Configuration Assistant (DBCA)

Création manuelle de la BD

Méthodes de création

Step 1: Choisir un nom unique pour l’instance et la BD

Step 2: Préparer le fichier des paramètres

Step 3: Création d’un password file

Step 4: Démarrer l’instance

Step 5: Création de la BD

Step 6: Exécuter les scripts pour générer le dictionnaire de données et exécuter les étapes post-création

Les étapes de création d’une BD

Step 2: Préparer le fichier des paramètresCréation d’un nouveau parameter file : $cp init.ora $ORACLE_HOME/dbs/initU16.ora

Modification du fichier initU16.ora en éditant les paramètres (DB_NAME, CONTROL_FILES…)

Création du fichier SPFILE à partir du PFILE en se connectant en tant que SYSDBA

SQL>CREATE SPFILE FROM PFILE;

Par défaut, les 2 fichiers existent dans la même location. Lorsque on démarre l’instance, OS cherche si il existe un fichier nommé sfileSID.ora (SPFILE). S’il n’existe pas alors le fichier initSID.ora (PFILE) sera utilisé

Les étapes de création d’une BD- Step 2

Step3: Création d’un password file Utiliser l’utilitaire ORAPWD pour créer le password file

Syntaxe: orapwd file=<fname>password=<password> entries=<users>

Avecfile - name of password filepassword - password for SYS entries - maximum number of distinct DBAs

Step 4: Démarrer l’instanceSe connecter en tant que SYSDBA

Démarrer l’instance à l’étape NOMOUNT : STARTUP NOMOUNT PFILE=/DISK/initU16.ora

Les étapes de création d’une BD- Step 3,4

Step 5: Création de la BDCREATE DATABASE [database_name]

[MAXLOGFILES integer]

[MAXDATAFILES integer]

[DATAFILE filespec]

[LOGFILE [GROUP integer] filespec]…;

DATAFILE filespec : spécifie les data files à utiliser

LOGFILE [GROUP integer] filespec] : spécifie les noms des fichiers journaux à utiliser et le groupe auquel ils appartiennent

Les étapes de création d’une BD- Step 5

CREATE DATABASE "PROD01"

CONTROLFILE REUSE

LOGFILE

GROUP 1 (‘/oradata02/PROD01/redo0101.log’, ‘/oradata03/PROD01/redo0102.log) SIZE 5M REUSE,

GROUP 2 (‘/oradata02/PROD01/redo0201.log’, ‘/oradata03/PROD01/redo0202.log) SIZE 5M REUSE

MAXLOGFILES 4

MAXLOGMEMBERS 2

MAXLOGHISTORY 0

MAXDATAFILES 254

MAXINSTANCES 1

NOARCHIVELOG

CHARACTER SET "WE8MSWIN1252“

DATAFILE ‘/oradata01/PROD01/system01.dbf’ SIZE 80M AUTOEXTEND ON NEXT 5M MAXSIZE UNLIMITED

UNDO TABLESPACE UNDOTBS

DATAFILE ‘/oradata04/PROD01/undo01.dbf’ SIZE 35M

DEFAULT TEMPORARY TABLESPACE TEMPTEMPFILE ‘/oradata05/PROD01/temp01.dbf’ SIZE 20M;

Création d’une BD- Exemple

La base contient:Des datas files constituant le tablespace SYSTEMControl and redo log fileLes users SYS/change_on_install and

SYSTEM/managerLe rollback segment SYSTEMDes tables internes (sans vues de dictionnaire de

données)

Après la création de la BD

La commande ALTER permet de changer l’état d’une BD

Pour changer l’état de la BD de NOMOUNT à MOUNT ou de MOUNT à OPEN, il suffit d’écrire cette commande :

ALTER DATABASE { MOUNT | OPEN }

Pour que les données ne soient pas modifier, nous pouvons ouvrir la base en mode read-only

ALTER DATABASE OPEN

[READ WRITE| READ ONLY]

Commande de changement de l’état de la BD

Dictionnaire données

Le dictionnaire de données est une méta-base qui décrit dynamiquement la BD. Il fournit des informations sur:

La structure logique et physique de la BD

Les noms, définitions et allocation d’espace des objets des schémas

Les users et les privilèges de la base

L’audit

Le dictionnaire de données

Le dictionnaire de données, situé dans le tablespace SYSTEM et appartenant à l’user SYS, consiste en 2 parties :

Les tables de base contiennent des informations comme les users de la BD et leurs permissions, le pourcentage de l’utilisation de la taille de la BD

Tables internes du SORarement utiliséesCréées à l’aide du script sql.bsqExemple : AUD$

Les vues du dictionnaire de donnéesCréées à l’aide du script catalog.sql

Table de base et vues du dictionnaire de données

Les VDD sont classées selon ces catégories:

DBA_ Ces vues contiennent des informations sur tous les objets

de la BD et sur leurs propriétairesAccessible au DBA et à tout utilisateur qui a le privilège

SELECT_CATALOG_ROLE

ALL_ Ces vues contiennent des informations sur les objets

auxquels un user a accèsElles sont accessibles à n’importe quel userToutes les vues ont une colonne OWNER

Les Vues du Dictionnaire de Données (VDD)

Les VDD sont classées selon ces catégories:

USER_ Ces vues contiennent des informations sur les objets

appartenant à userElles sont accessibles à tous les users et n’ont pas de

colonne OWNER

V$ synonyme V_ $ (V pour virtual)Ces vues sont connus sous le nom « dynamic performance

views » vu qu’elles sont continuellement en modification lors de l’ouverture et de l’utilisation de la BD

Les Vues du Dictionnaire de Données (VDD)

Les Vues du Dictionnaire de Données (VDD)

Description de la structure des vues

La description se fait grâce à la commande DESC du langage SQL

Interrogation des vues

L’interrogation des vues se fait grâce à l’ordre SELECT du langage SQL

Description et accès aux VDDs

Question 1 : How many control files are required to create a database?1, 2, 3, aucun

Answer: you do not need any control files to create a database; the control files are created when you create the database, based on the filenames specified in the CONTROL_FILES parameter of the parameter file

Question 2 : Which environment variable or registry entry variable represents the instance name?

ORA_SID, INSTANCE_NAME, ORACLE_INSTANCE, ORACLE_SID Answer: The ORACLE_SID environment variable represents the instance name. When you connect to

the database without specifying a connect string, Oracle connects you to this instance

Question 3 : Which command must you issue before you can execute the CREATE DATABASE command?

STARTUP INSTANCE, STARTUP NOMOUNT, STARTUP MOUNT, None of the above

Answer :You must start up the instance to create the database. Connect to the database by using the SYSDBA privilege, and start up the instance by using the command STARTUP NOMOUNT

Review Questions

Question 4 : What is the prefix for dynamic performance views?DBA_ X$ V$ X#Answer : the dynamic performance views have a prefix of V$. The actual views have the prefix of

V_$, and the synonyms have a V$ prefix. The views are called dynamic performance views because they are continuously updated while the database is open and in use, and their contents relate primarily to performance

Question 5 : Who owns the data dictionary?SYS SYSTEM DBA ORACLEAnswer : The SYS user owns the data dictionary. The SYS and SYSTEM users are created when

the database is created

Review Questions

Questions?

Commentaires?

Merci!