Formation Oracle "DBA 1" préparation de Certif (Z0-052)

dans cette vidéo consacrée à la présentation de la formation Oracle Database 11g.

L’objectif de cette vidéo de présentation sera donc de présenter d’une manière claire et assez simple, le contenu de la formation… 

Oracle – La gestion de la mémoire :

Oracle fait un usage poussé de la mémoire physique (RAM, Random Access Memory)
du serveur afin de fournir les meilleures performances possibles.

Ainsi Oracle utilise la mémoire physique du serveur pour :

• accélérer l’accès aux données de la base régulièrement accédées.

• mettre les processus en mémoire.

• optimiser la communication entre les processus et la base de données.

Ainsi la taille de la mémoire vive du serveur est primordiale pour la performance de la base de données. En effet, lorsqu’il n’y a plus de mémoire physique disponible, le système d’exploitation
met à disposition de l’application une mémoire dite « virtuelle » composée de fichiers d’échange
(fichiers swap) sur le disque du serveur. Or l’accès au disque dur est extrêmement plus long
que l’accès à la mémoire physique, ce qui provoque des ralentissements notables
dans le fonctionnement de la base de données Oracle.

La SGA (System Global Area) : C’est cette zone qui assure le partage des données
entrent les différents utilisateurs.

Toute donnée lue ou modifiée transite par la SGA.

La mémoire SGA stocke des données telles que des blocs de données en cache
et des zones SQL partagées.

La PGA (Program Global Area) : Cette zone de la mémoire contient des données et des informations
de contrôle pour un processus serveur ou un processus en arrière-plan.

Il s’agit d’une mémoire non partagée qui est créée par Oracle Database au démarrage d’un processus serveur ou processus en arrière-plan.

Son accès est exclusivement réservé au processus serveur.

Chaque processus serveur et processus en arrière-plan dispose de sa propre mémoire PGA.

Cache de tampons (buffer cache) de la base de données : Il met en mémoire cache les blocs de données extraits de la base.

Tampon de journalisation (redo log buffer) : Il met en mémoire cache les informations
de journalisation (utilisées pour la récupération de l’instance) jusqu’à ce qu’elles puissent être écrites dans les fichiers de journalisation physiques stockés sur le disque.

Zone de mémoire partagée : Elle met en mémoire cache diverses structures pouvant
être partagées par les utilisateurs.

Zone de mémoire Java : Elle est utilisée pour l’ensemble du code Java et des données propres
à la session dans la JVM (Java Virtual Machine).

Zone de mémoire LARGE POOL : Il s’agit d’une zone facultative fournissant d’importantes allocations de mémoire pour certains processus très consommateurs, tels que les opérations de sauvegarde
et de récupération Oracle et les processus serveur d’entrée-sortie.

Zone de mémoire Streams : Elle est utilisée par Oracle Streams pour stocker les informations nécessaires aux opérations de capture et d’application.

Proccess BackGround ORACLE

Processus utilisateur : démarrés lorsqu’un utilisateur de base de données demande une connexion au serveur Oracle.

Processus serveur : se connecte à l’instance Oracle et il’est démarre lorsqu’un utilisateur établit une session.

Processus en arrière-plan : démarrés en même temps qu’une instance Oracle.

Mémoires tampon (buffers) :

Tampon faisant l’objet d’opérations pin (Pinned) : Plusieurs sessions ne peuvent pas écrire simultanément dans le même bloc. Chaque session attend de pouvoir accéder au bloc.

Propre (Clean) : La mémoire tampon fait à présent l’objet d’opérations unpin et est candidate à une suppression immédiate si le contenu en cours (bloc de données) n’est pas à nouveau référencé. Soit le contenu est synchronisé avec le contenu de bloc stocké sur le disque, soit la mémoire tampon contient le cliché (snapshot) de lecture cohérente d’un bloc.

Disponible/inutilisé (Free/unused) : La mémoire tampon est vide car l’instance vient juste de démarrer. Cet état est très semblable à l’état « Propre » (Clean), sauf qu’ici la mémoire tampon n’a pas été utilisée.

Dirty : La mémoire tampon ne fait plus l’objet d’opérations pin, mais le contenu (bloc de données) a été modifié et doit être transféré sur le disque via le processus DBWn avant de pouvoir être retiré de la mémoire.

les processus d’ arrière-plan :

Processus SMON (System Monitor) : effectue la récupération après panne lorsque l’instance est démarrée suite à une défaillance.

Processus PMON (Process Monitor) : procède au nettoyage des processus utilisateur en cas d’échec.

Processus Database Writer (DBWn) : écrit les blocs modifiés du cache de tampons (buffer cache) de la base de données vers les fichiers de données présents sur le disque.

Point de reprise (CKPT) : met à jour l’ensemble des fichiers de données et de contrôle de la base de données afin d’indiquer le point de reprise (checkpoint) le plus récent.

Processus LGWR (Log Writer) : écrit les entrées de journalisation sur le disque.

Processus d’archivage (ARCn) : copie les fichiers de journalisation
(fichier redo log) dans l’emplacement de stockage d’archivage
en cas de changement de fichier de journalisation.

Les infos sur les processus :

Les vues :

V$PROCESS, V$BGPROCESS

Si champ ADDR <> ‘00’ = processus lancé

Si champ BACKGROUND = 1 => processus démon

Comment fonctionne une base de données :

Une base de données est stockée sous la forme d'un fichier ou d'un ensemble de fichiers sur un disque ou un disque magnétique, un disque optique ou tout autre support de stockage. L'information contenue dans ces fichiers peut être divisée en enregistrements. Ces enregistrements sont constitués d'un ou de plusieurs champs. Un champ constitue une seule pièce d’information, et chaque champ contient généralement des informations se rapportant à un aspect ou attribut de l'entité décrite par la base de données.

Les enregistrements sont également organisés en tableaux qui contiennent des informations sur les relations entre les différents champs. À l'aide de mots-clés et de diverses commandes de tri, les utilisateurs peuvent rapidement rechercher, réorganiser, regrouper et sélectionner les champs dans de nombreux enregistrements pour récupérer ou créer des rapports sur des agrégats particuliers de données.

Descriptions des fichiers :

Fichiers de contrôle : contiennent des données relatives à la base de données elle-même
(c'est-à-dire des informations propres à la structure de base de données physique).

Fichiers de données : contiennent les données d'application ou les données utilisateur de la base.

Fichiers de journalisation (fichier redo log) en ligne : permettent la récupération d'une instance
de la base de données.

Fichier de paramètres : utilisé pour définir la façon dont l'instance est configurée au démarrage.

Fichier de mots de passe : permet aux utilisateurs de se connecter à distance à la base de données
et d'effectuer des tâches d'administration.

Fichiers de sauvegarde : utilisés pour la récupération de la base de données.

                                                les fichiers du Base de données Oracle

Sa fonction :

Unité d’échange entre données disque et la mémoire Oracle

SHOW PARAMETER DB_BLOCK_SIZE

Les tailles de bloc : 2K, 4K, 8K, 16k, 32K

On peut avoir une taille de bloc standard et 4 tailles de bloc non standard

SHOW PARAMETER K_CACHE_SIZE

Principes des redo log oracle :

Chaque base de données Oracle possède un ensemble d’au moins deux fichiers redo log : cet ensemble est nommé le redo log de la base. La fonction principale du redo log est d’enregistrer toutes les modifications sur les données. Si un problème devait empêcher les données d’être écrites de façon permanente sur le disque, les modifications seraient obtenues depuis le redo log. Le redo log étant vital pour le maintient de la base de données, Oracle permet de multiplexer le redo log ce qui signifie que une ou plusieurs copies du redo log peuvent être maintenues sur des disques différents.

Toutes les transactions sont enregistrées dans des fichiers redo-log. Ce sont ces fichiers qui permettent une restauration en cas de panne de la base de données ou par exemple en cas d’arrêt brutal d’un serveur.

Ces fichiers sont très importants pour la sécurité de la base ainsi que pour sa performance. Les redo-log sont organisés en groupe et sont écrits de façon circulaire.

Nous avons 2 groupes au minimum composés au minimum d’un membre. Lorsque le premier groupe est plein, il y a un SWITCH (basculement) pour le passage au deuxième groupe. Oracle écrase les données du premier groupe, lorsqu’il a fini son tour circulaire.
C’est le processus LGWR (LOGWRITER) qui écrit dans les redo.

Leur contenu

• L’identification de la transaction (N° process user)

• La date et l’heure de la transaction (TIMESTAMP, SCN)

• L’adresse physique de la données modifiée (ROWID)

• Le type d’opération effectuée : UPDATE, INSERT, DELETE, COMMIT, ROLLBACK Les données AVANT modification

• Les données APRES modification

• L’état de la transaction (en cours, validée, invalidée) L’emplacement des archives

Information sur les fichiers journaux :

• V$LOGFILE

• V$LOG

• V$DATABASE

• V$INSTANCE

Commande :

ARCHIVE LOG LIST

Les opérations sur les fichiers journaux

Création d’un groupe :

ALTER DATABASE ADD LOGFILE GROUP 5 (’D:\ORACLE\ORADATA\…’ , ’E:\ORACLE\ORADATA\… ’) SIZE 10M;

Création d’un membre :

ALTER DATABASE ADD LOGFILE MEMBER ’D:\ORACLE\ORADATA\…’ TO GROUP 1;

Suppression d’un groupe :

ALTER DATABASE DROP LOGFILE GROUP 3;

Suppression d’un membre :

ALTER DATABASE DROP LOGFILE MEMBER D:\ORACLE\ORADATA\…’ TO GROUP 1 ;

Switch de fichier journal :

ALTER SYSTEM SWITCH LOGFILE;

Le statut d’un groupe :

UNUSED => un groupe qui vient d’être créé

CURRENT => le groupe courant (en cours d’utilisation)

ACTIVE => n’est plus le groupe courant mais les données n’ont pas été écrites dans les fichiers de données

INACTIVE => toutes les données sont écrites dans les fichiers de données

Principes d'archivage :

Le mode ARCHIVELOG est un mode dans lequel vous pouvez placer la base de données pour créer une sauvegarde de toutes les transactions qui se sont produites dans la base de données afin de pouvoir récupérer à tout moment.

Le mode NOARCHIVELOG est essentiellement l’absence de mode ARCHIVELOG et présente l’inconvénient de ne pas pouvoir récupérer à un moment donné. Le mode NOARCHIVELOG a l’avantage de ne pas avoir à écrire de transactions dans un journal d’archives et augmente ainsi légèrement les performances de la base de données.

MODE ARCHIVELOG :

Les avantages :

Vous pouvez effectuer des sauvegardes à chaud (sauvegardes lorsque la base de données est en ligne).

Les journaux d’archivage et la dernière sauvegarde complète (hors ligne ou en ligne) ou une sauvegarde plus ancienne peuvent récupérer complètement la base de données sans perdre de données car toutes les modifications apportées dans la base de données sont stockées dans le fichier journal.

Désavantages :

Il nécessite de l’espace disque supplémentaire pour stocker les fichiers journaux archivés. Cependant, l’agent offre la possibilité de purger les journaux après leur sauvegarde, vous donnant ainsi la possibilité de libérer de l’espace disque si vous en avez besoin.

MODE SANS ARCHIVELOG :

Les avantages :

Il ne nécessite aucun espace disque supplémentaire pour stocker les fichiers journaux archivés.

Désavantages :

Si vous devez récupérer une base de données, vous ne pouvez restaurer que la dernière sauvegarde complète hors ligne. Par conséquent, toutes les modifications apportées à la base de données après la dernière sauvegarde complète hors ligne sont perdues.

Le temps d’arrêt de la base de données est important car vous ne pouvez pas sauvegarder la base de données en ligne. Cette limitation devient une considération très sérieuse pour les grandes bases de données.

Remarque: le mode NOARCHIVELOG ne garantissant pas la récupération de la base de données Oracle en cas de sinistre, l’agent pour Oracle ne prend pas en charge ce mode. Si vous devez maintenir Oracle Server en mode NOARCHIVELOG, vous devez sauvegarder les fichiers de base de données Oracle complets sans l’agent à l’aide de CA ARC serve Backup pendant que la base de données est hors ligne pour assurer la reprise après sinistre.

Etapes de mise en place du mode ARCHIVELOG :

1- Spécifié un emplacement pour l’archive au niveau de l’OS

> mkdir /u104/archivlog/test’

2- Paramètre: log_archive_dest_[1-31]

SQL> alter system set log_archive_dest_1=’LOCATION=/u104/archivlog/test’;

3- Arrêt de l’instance et démarrage en mode MOUNT :

SQL> shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> startup mount

ORACLE instance started.

Database mounted.

4- Modification du mode d’archive:

SQL> alter database archivelog;

Database altered.

ALTER DATABASE ARCHIVELOG | NOARCHIVELOG;

5- Ouverture de la base de données.

SQL> alter database open;

Database altered.

6- Vérification

SQL> archive log list ;

Download Oracle 11g

Vous pouvez télécharger gratuitement l’ Oracle. Vous pouvez accéder à la page principale de l’ Oracle pour télécharger ce logiciel.

https://www.oracle.com/technetwork/database/enterprise-edition/downloads/112010-win64soft-094461.html

Vérifiez si votre système d’exploitation est de 32bit ou 64bit pour télécharger exactement

2- création et paramétrage d’un environnement du Prod

2- Duplication et paramétrage d’un autre environnement backup

Tags: installation oracle, simple déploiement oracle

Introduction sur l’outil Sql*Plus :

SQL*Plus est un outil en ligne de commande permettant de se connecter à une base de données Oracle afin d’y exécuter des ordres SQL ou des procédures PL/SQL. Dans ce tutoriel, je vous propose de découvrir ses principales fonctionnalités.

Même s’il est parfois plus confortable d’utiliser un outil graphique, tel que Toad ou SQL Developer, il faut aussi savoir se contenter de la ligne de commande. Tout d’abord, parce que nous n’avons pas toujours le choix ! Mais même au-delà, il peut s’avérer plus simple et plus rapide de lancer une invite SQL*Plus plutôt que l’artillerie lourde d’un client graphique.

Nous allons donc voir que SQL*Plus permet d’envoyer des commandes SQL et PL/SQL au SGBDR, mais aussi d’exécuter ses propres commandes internes. Nous parlerons notamment des scripts et des variables gérés par SQL*Plus. Nous apprendrons également à manier son buffer et paramétrer l’affichage des résultats afin de les rendre plus lisibles. Enfin, nous verrons comment exporter les résultats de nos requêtes dans des fichiers.

Attention, nous n’aborderons pas ici l’installation de SQL*Plus ou même d’une base Oracle, nous partirons du principe que cela a déjà été fait par votre DBA préféré et qu’il ne vous reste plus qu’à vous mettre au travail.

Les commandes SQL Plus :

LINESIZE (défini le nombre maximal de caractères autorisés dans chaque ligne)

PAGESIZE (défini le nombre maximal de lignes dans chaque page)

TERMOUT (désactive l’affichage des lignes à l’écran : SET TERMOUT OFF)

HEADING (désactive ou active l’affichage des entêtes de colonnes : SET HEADING { ON | OFF})

TRIMSPOOL (supprime ou non les blancs situés à la fin des lignes envoyées vers un fichier)

FEEDBACK (affiche ou non le nombre de lignes extraites)

ECHO (affiche ou non l’instruction lorsqu’elle est exécutée)

CONNECT,DISCONNECT

EXIT,QUIT

RUN,START EDIT

SAVE

Création de la base de données à l’aide de l’assistant graphique :

1. Vue d’ensemble

L’assistant Configuration de base de données permet de :

• Créer une nouvelle base de données, à partir de modèles pouvant comporter des fichiers de données prêts à l’emploi .

• modifier les options installées dans une base de données .

• Supprimer une base de données .

• Créer des modèles .

• Configurer ASM.

L’assistant crée des structures de stockage complémentaires (que nous verrons dans les chapitres Gestion des tablespaces et des fichiers de données et Gestion des informations d’annulation).

L’assistant peut être lancé à partir d’une fenêtre du système d’exploitation par la commande DBCA. Sur plate-forme Windows, l’assistant peut aussi être lancé par le menu Démarrer – Programmes – Oracle -nom_oracle_home – Outils de configuration et de migration – Assistant Configuration de base de données.

Un écran de bienvenue s’affiche ; cliquez sur le bouton Suivant pour afficher l’écran proposant les différentes opérations :

Etapes de création du base de données Oracle Manuellement :

1. Creation des directories :

MKDIR C:\BaseBackup\admin

MKDIR C:\BaseBackup\oradata

MKDIR C:\BaseBackup\admin\BACKUP

MKDIR C:\BaseBackup\oradata\BACKUP

MKDIR C:\BaseBackup\admin\BACKUP\bdump

MKDIR C:\BaseBackup\admin\BACKUP\adump

MKDIR C:\BaseBackup\admin\BACKUP\cdump

MKDIR C:\BaseBackup\admin\BACKUP\pfile

MKDIR C:\BaseBackup\admin\BACKUP\udump

2. Création d’instance :

Oradim -new -sid BACKUP

3. CREATION DE FICHIER DE PARAMETRAGE

##################################################################

# Copyright (c) 1991, 2001, 2002 by Oracle Corporation

##################################################################

###########################################

# Cache and I/O

###########################################

db_block_size=8192

db_file_multiblock_read_count=16

###########################################

# File Configuration

###########################################

control_files=(« C:\BaseBackup\oradata\BACKUP\control01.ctl »,

« C:\BaseBackup\oradata\BACKUP\control02.ctl »,

« C:\BaseBackup\oradata\BACKUP\control03.ctl »)

###########################################

# Cursors and Library Cache

###########################################

open_cursors=300

###########################################

# Diagnostics and Statistics

###########################################

background_dump_dest=C:\BaseBackup\admin\BACKUP\bdump

core_dump_dest=C:\BaseBackup\admin\BACKUP\cdump

user_dump_dest=C:\BaseBackup\admin\BACKUP\udump

###########################################

# Miscellaneous

###########################################

compatible=11.1.0

###########################################

# Job Queues

###########################################

job_queue_processes=10

###########################################

# Database Identification

###########################################

db_domain= » »

db_name=BACKUP

db_unique_name=BACKUP

###########################################

# SGA Memory

###########################################

sga_target=2048M

###########################################

# Processes and Sessions

###########################################

processes=150

###########################################

# System Managed Undo and Rollback Segments

###########################################

undo_management=AUTO

undo_tablespace=UNDOTBS1

###########################################

# Shared Server

###########################################

dispatchers= »(PROTOCOL=TCP) (SERVICE=ORADBXDB) »

###########################################

# Security and Auditing

###########################################

audit_file_dest=C:\BaseBackup\admin\BACKUP\adump

remote_login_passwordfile=EXCLUSIVE

###########################################

# Sort, Hash Joins, Bitmap Indexes

###########################################

pga_aggregate_target=20M

4. connexion à la base

SQL> Set ORACLE_SID = BACKUP

SQL> sqlplus /nolog

SQL> connect sys / as sysdba

5. Démarrer la base en mode « NO MOUNT »

SQL> startup nomount pfile=’C:\BaseBackup\admin\BACKUP\pfile\init.ora’

6. Création de la base de données

SQL> Create DATABASE BACKUP

USER SYS IDENTIFIED BY oracle

USER SYSTEM IDENTIFIED BY oracle

MAXDATAFILES 200

MAXINSTANCES 1

CHARACTER SET AL32UTF8

NATIONAL CHARACTER SET UTF8

LOGFILE

GROUP 1 (‘C:\BaseBackup\oradata\BACKUP\redo01.rdo’) SIZE 50M,

GROUP 2 (‘C:\BaseBackup\oradata\BACKUP\redo02.rdo’) SIZE 50M,

GROUP 3 (‘C:\BaseBackup\oradata\BACKUP\redo03.rdo’) SIZE 50M

MAXLOGFILES 20

MAXLOGMEMBERS 5

NOARCHIVELOG

EXTENT MANAGEMENT LOCAL

DATAFILE ‘C:\BaseBackup\oradata\BACKUP\system.dbf’ SIZE 500M

SYSAUX DATAFILE ‘C:\BaseBackup\oradata\BACKUP\sysaux.dbf’ SIZE 500M

DEFAULT TEMPORARY TABLESPACE TEMP

TEMPFILE ‘C:\BaseBackup\oradata\BACKUP\temp.dbf’ SIZE 250M

EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M

UNDO TABLESPACE UNDOTBS1

DATAFILE ‘C:\BaseBackup\oradata\BACKUP\UNDOTBS1.dbf’ SIZE 250M;

7. Création du dictionnaire

@?\rdbms\admin\catalog.sql

@?\rdbms\admin\catproc.sql

8. Création du fichier spfile

SQL> create spfile from pfile=’C:\BaseBackup\admin\BACKUP\pfile\init.ora

Création de la base de données à l’aide de l’outil Xming.

Ce programme est un portage sous Windows du système de fenêtrage X utilisé dans la plus part des distributions GNU/Linux (mais aussi Unix et BSD). Il permet ainsi de rediriger l’affichage vers Windows d’une application graphique tournant sur une machine Linux. Très pratique pour lancer un programme présent sur un serveur linux (ex héberger sur un raspberry sans clavier / souris) et l’exécuter sur votre PC Windows comem si c’était un programme local. Seul condition, le programme doit avoir une interface graphique basé sur le serveur X.org

Paramétrage de l’outil Xming :

Télécharger Xming sur sourceforce. (gratuit et open source)
– Lancer Xming, si vous avez un firewall, autorisez l’accès réseau pour ce programme. Laissez le tourner en arrière plan, il devrait y avoir le logo dans le systray pret de l’horloge Windows.
– télécharger puis lancer Putty

Dans putty:

– Entrer l’adresse IP de votre serveur Linux (dans la partie session) puis dans le champs « Saved session » indiqué le nom de votre serveur puis cliquez sur Save.

Dans l’arborescence: déployer les options SSH > Rubrique X11 > Cocher « Enable X11 forwarding »et compléter le champ comme indiqué sur la capture d’écran: localhost:0
Retourner sur le premier écran pour cliquez sur Save puis terminer en faisant Open

– Rentrer vos identifiants.

– Vous n’avez plus qu’à taper le nom du programme que vous voulez afficher

sur votre bureau Windows.

Tapez par exemple: chromium pour lancer le navigateur sur votre bureau.

Principes de Démarrage et Arrêt d’instance Oracle:

Pour rendre une base accessible à tous les utilisateurs, il faut démarrer une instance et ouvrir la base de données avec cette instance.

Il y a trois grandes phases dans le processus de démarrage :

• démarrage de l’instance.

• montage de la base de données.

• ouverture de la base de données.

De même, il y a trois grandes phases dans le processus d’arrêt :

• fermeture de la base de données.

• démontage de la base de données.

• arrêt de l’instance.

Une instance peut être démarrée avec trois niveaux successifs de disponibilité de la base de données, correspondant aux trois phases du démarrage :

• Instance démarrée (état NOMOUNT).

• Base montée (état MOUNT).

• Base ouverte (état OPEN).

Lors du démarrage de l’instance, le fichier de paramètres est lu, la SGA est allouée et les processus d’arrière-plan sont démarrés. À ce stade, seule l’instance est lancée. il n’y a pas de base de données associée.

Les vues dynamiques relatives à l’instance (V$INSTANCE, V$SGA, V$OPTION, V$PARAMETER, V$VERSION etc.) sont interrogeables mais pas les vues dynamiques relatives à la base de données (V$DATABASE par exemple). Cet état est principalement utilisé lors de la création d’une nouvelle base.

Cas de Démarrage (STARTUP mode) :

Dans SQL*Plus, la commande STARTUP permet de démarrer une instance et de lui associer une base avec le niveau de disponibilité souhaité.

Syntaxe simplifiée

STARTUP [NOMOUNT | MOUNT [nom_base] | OPEN [nom_base]] [RESTRICT] [PFILE=nom_fichier]

Avec

• niveau de disponibilité souhaité.

(NOMOUNT | MOUNT | OPEN )

NOMOUNT : L’instance est démarrée, mais aucune base n’est montée. La base va lire le fichier d’initialisation (SPFILE ou PFILE), allouer la SGA (System Global Area, mémoire allouée au système pour appeller les process), et démarrer les processus d’arrière-plan. Ce mode est souvent utilisé pour la maintenance des Control Files.

MOUNT : La base est montée, mais n’est pas ouverte. On a lu le control file, et on sait où sont les fichiers de données, et les redo log, mais ils ne sont pas encore accessibles, on n’agit pas dessus. Ce mode sert à des fins de maintenance. Il est ainsi possible de restaurer la base de données après une panne, d’activer ou désactiver le mode ARCHIVELOG, etc.

C’est aussi dans ce mode qu’il est possible de renommer les fichiers de données.

OPEN : Les fichiers de données et les redo logs sont ouverts, et n’importe quel utilisateur autorisé peut se connecter. Attention cependant, c’est à ce moment qu’Oracle vérifie si ces fichiers existent,
et renverra une erreur dans le cas contraire.

nom_base : nom de la base à monter ou à ouvrir.

RESTRICT : restreint l’accès à la base aux utilisateurs ayant le privilège RESTRICTED SESSION.

PFILE : nom du fichier de paramètres à utiliser.

Cas d’arrêt (SHUTDOWN mode) :

Dans SQL*Plus, la commande SHUTDOWN permet de fermer la base et d’arrêter l’instance.

Syntaxe

SHUTDOWN [NORMAL | IMMEDIATE | TRANSACTIONAL | ABORT]

Options :

NORMAL

Oracle attend que tous les utilisateurs soient déconnectés (pas de nouvelle connexion autorisée) puis ferme proprement la base de données.

IMMEDIATE

Oracle déconnecte tous les utilisateurs (en effectuant un ROLLBACK des éventuelles transactions en cours) puis ferme proprement la base de données.

TRANSACTIONAL

Oracle attend que toutes les transactions en cours se terminent avant de déconnecter les utilisateurs (pas de nouvelle transaction autorisée) puis ferme proprement la base de données.

ABORT

Oracle déconnecte tous les utilisateurs (sans effectuer de ROLLBACK des éventuelles transactions en cours) puis ferme « brutalement » la base de données, sans effectuer de point de synchronisation (checkpoint). Une récupération de l’instance sera nécessaire lors du prochain démarrage.

Le processus de l’arrêt est le suivant :

• La base de données est fermée.

• La base de données est démontée.

• L’instance est arrêtée (les processus d’arrière-plan sont arrêtés et la SGA est libérée).

Un arrêt est forcément complet . il n’est pas possible de s’arrêter dans un état intermédiaire …

Authentification :

Deux méthodes

Par système d’exploitation

Groupe dba

Par fichier de mot de passe

orapwd file=orapw password= entries= force=y

Note: le fichier de mot de passe est crée dans $ORACLE_HOME/dbs

Paramètre REMOTE_LOGIN_PASSWORDFILE = [EXCLUSIVE | SHARED | NONE]

du fichier d’initilisation

Les utilisateurs SYS et SYSTEM :

Je n’utiliserais ni SYS ni SYSTEM, sauf lorsque je suis dirigé vers une procédure d’installation spécifique. Vous devez créer vos propres comptes DBA et leur accorder le privilège sysdba ou sysoper pour démarrer / arrêter la base de données.

SYS est spécial. Mais sys n’est pas assez bon. Je recommande fortement de ne pas utiliser SYS pour faire des choses. SYS ne peut pas créer de déclencheurs, SYS ne peut pas avoir de transactions en lecture seule, etc. SYS ne doit pas être utilisé.

Le système n’est qu’un compte, rien de spécial à ce sujet. Nous l’utilisons pour stocker diverses

SYS possède le dictionnaire de données Oracle. Chaque objet de la base de données (tables, vues, packages, procédures, etc.) a tous un seul propriétaire. Pour le dictionnaire de base de données, et un tas de tables spéciales (vues de performances et similaires) sont toutes détenues par l’utilisateur SYS.

L’utilisateur SYSTEM est censé être l’utilisateur DBA maître, avec accès à tous ces objets. Cela reflète une philosophie de conception de sécurité Oracle ancienne. Vous créez l’application en utilisant un seul utilisateur, puis créez un second avec accès (sélectionner, mettre à jour, supprimer) mais pas supprimer les privilèges. Cela vous donne un accès «super-utilisateur» à votre schéma sans pouvoir le détruire accidentellement. Au fil des ans, quelque chose a été ajoutée au compte SYSTEM qui peut avoir dû être dans le compte SYS. Mais très peu de gens veulent donner accès à leur compte SYS s’ils n’y sont pas obligés.

SYS:

Créé automatiquement lors de l’installation de la base de données Oracle accordé automatiquement le rôle DBA a un mot de passe par défaut: CHANGE_ON_INSTALL (assurez-vous de le changer) possède les tables de base et les vues du dictionnaire de données de la base de données le schéma par défaut lorsque vous vous connectez

en tant que SYSDBA.

Les tables du schéma SYS sont manipulées uniquement par la base de données. Ils ne doivent jamais être modifiés par un utilisateur ou un administrateur de base de données, et personne ne doit créer de tables dans le schéma de l’utilisateur SYS. Les utilisateurs de base de données ne doivent pas se connecter à la base de données Oracle à l’aide du compte SYS.

SYSTÈME:

Créé automatiquement lors de l’installation de la base de données Oracle accordé automatiquement le rôle DBA

a un mot de passe par défaut: MANAGER (assurez-vous de le changer) utilisé pour créer des tables et des vues supplémentaires qui affichent des informations administratives utilisé pour créer des tables et des vues internes utilisées par diverses options et outils de base de données Oracle

N’utilisez jamais le schéma SYSTEM pour stocker des tables d’intérêt pour les utilisateurs non administratifs.

Fichiers de Traces :

Le fichier d’alerte (alert.log)

Son nom: alert_<ORACLE_SID>.log

Paramètre de configuration: diagnostic_dest = ORACLE_BASE

Son emplacement: $ORACLE_BASE/diag/rdbms/<dbname>/<ORACLE_SID>

diag est un répertoire commun

rdbms est le type du produit

<dbname> est le nom de la base de données

<ORACLE_SID> est le nom de l’instance

Visualisation du chemin:

show parameter background_dump;

Le fichier d’alerte (alert.log)

Son utilité

• Enregistre avec horodatage

• Arrêt/Démarrage

• Les opérations de récupération automatique ou manuelle

• Toutes les erreurs au niveau instance

• Création de tablespaces et opérations DDL (ALTER)

• Possibilité de tracer les processus serveur

ALTER SESSION SET sql_trace=TRUE;

ALTER SYSTEM SET sql_trace=TRUE;

Les fichiers de traces :

Chaque processus d’arrière-plan a son propre fichier de trace

Contient des informations beaucoup plus détaillées que l’alert.log Paramètres de configuration:

USER_DUMP_DEST (chemin des fichiers de trace)

MAX_DUMP_FILE_SIZE (taille des fichiers de trace)

Outil ADRCI

Permet d’identifier les problèmes Utilisation

$ adrci

adrci> help

Automatic Storage Management :

Caractéristiques

• Gestion automatique des fichiers (données et journaux).

• Répartit automatiquement les fichiers de bases de données entre tous les disques pour l’équilibrage de charge.

• Actualise automatiquement la répartition des données suite a l’ajout ou le retrait d’un disque.

• Nécessite l’installation et le démarrage d’une instance appelée « ASM Instance »

Instance ASM

Caractéristiques

• Ne monte pas de base de données.

• Gère les Meta-datas requises pour rendre les fichiers ASM disponibles à n’importe qu’elle instance de base de données.

• L’instance ASM et l’instance BDD ont accès au contenu des fichiers.

L’instance BDD communique avec l’instance ASM pour connaître la disposition des fichiers utilisés.

RBAL – Processus maître de rééquilibrage ASM

– Coordonne l’activité de rééquilibrage.

– Dans une instance ASM, il coordonne l’activité de rééquilibrage pour les groupes de disques et effectue une ouverture globale sur les disques ASM.

– Dans les instances de base de données, il gère les groupes de disques ASM.

ARBn – Processus de rééquilibrage ASM

– Rééquilibre les data extents de données au sein d’un groupe de disques ASM

Architecture reseau oracle :

Présentation du fichier de configuration d’Oracle Net Listener :

La configuration d’Oracle Net Listener, stockée dans le fichier listener.ora, comprend les éléments suivants:

• Descripteur

• Les adresses de protocole sur lesquelles l’auditeur accepte les demandes de connexion

• Services de bases de données

Paramètres de contrôle :

Par défaut, le fichier listener.ora se trouve dans le répertoire $ ORACLE_HOME / network/admin sur les systèmes d’exploitation UNIX et dans le répertoire %ORACLE_HOME% \ network\admin sous Windows. listener.ora peut également être stocké aux emplacements

suivants:

Le répertoire spécifié par la variable d’environnement TNS_ADMIN ou la valeur de registre

Sur les systèmes d’exploitation UNIX, le répertoire de configuration globale. Par exemple, sur le système d’exploitation Solaris, ce répertoire est /var/opt/oracle.

Il est souvent utile de configurer plusieurs écouteurs dans un seul fichier listener.ora. Cependant, Oracle recommande d’exécuter un seul écouteur pour chaque nœud dans la plupart des environnements clients.

L’exemple 1 : montre un fichier listener.ora pour un écouteur nommé LISTENER, qui est le nom par défaut de l’écouteur.

Exemple 2 : Exemple de fichier listener.ora

Présentation de fichier tnsnames.ora :

Ce fichier tnsnames.ora est un fichier de configuration qui contient des noms de service réseau mappés pour connecter des descripteurs pour la méthode de dénomination locale, ou des noms de service réseau mappés sur des adresses de protocole d’écoute.

Un nom de service réseau est un alias mappé à une adresse réseau de base de données contenue dans un descripteur de connexion. Un descripteur de connexion contient l’emplacement de l’écouteur via une adresse de protocole et le nom de service de la base de données à laquelle se connecter. Les clients et les serveurs de base de données (qui sont des clients d’autres serveurs de base de données) utilisent le nom de service net lors de l’établissement d’une connexion avec une application.

Par défaut, tnsnames.ora se trouve dans le répertoire $ ORACLE_HOME/network/admin sur les systèmes d’exploitation UNIX et dans le répertoire %ORACLE_HOME%\network\admin sur les systèmes d’exploitation Windows. tnsnames.ora peut également être stocké aux emplacements suivants:

Le répertoire spécifié par la variable d’environnement TNS_ADMIN ou la valeur de registre

Sur les systèmes d’exploitation UNIX, le répertoire de configuration globale. Par exemple, sur le système d’exploitation Solaris, ce répertoire est /var/opt/oracle.

Exemple 3 : Exemple de fichier tnsnames.ora