erreur ORA-20001

Musée des erreurs pas de Commentaire »

L’utilisation de packages APEX hors de l’application APEX, c’est à dire en executant la procédure ‘à la main’, provoque une erreur.

ERROR
ORA-20001: This procedure must be invoked from within an application session.
ORA-06512: at « FLOWS_030000.WWV_FLOW_MAIL », line 109
ORA-06512: at « FLOWS_030000.WWV_FLOW_MAIL », line 139

La solution est de se donner les autorisation nécessaires en récupérant le Workspace Id, de l’application concernée dans Apex, via l’interface de gestion. Ensuite on positionne cet ID, avec wwv_flow_api.set_security_group_id et l’on peut executer la procédure désirée.

exemple :

begin
wwv_flow_api.set_security_group_id(1860821609902858);
– et execution d’un envoi de mail
apex_mail.send(p_to => ‘didier.deleglise@dd.fr’,
p_from => ‘test@test.com’,
p_body => ‘test’,
p_subj => ‘test ‘);
end;

Tablespaces et fichiers

Administration Oracle, Divers 2 Commentaires »

De l’utilité des tablespaces

Un tablespace ou espace disque logique, est une partition logique de la base contenant un ou plusieurs fichiers.
Un fichier appartient à 1 et 1 seul tablespace.
Par défaut un tablespace à la création est ON LINE et donc accessible, il peut être mis OFFLINE (et les fichiers qu’il contient par conséquent) pour en interdire l’accès ou pour certaines opérations de maintenance

Il existe toujours deux tablespace baptisés SYSTEM et SYSAUX .
- SYSTEM : contient le dictionnaire de données et segment d’annulation SYSTEM
- SYSAUX : contient les informations nécessaires aux composants et outils supplémentaires
et traditionnellement on créera également
- ‘TEMP’ : pour les données ‘swappées’ sur disque lors d’opération de tri ou de fusion trop volumineuses en mémoire
- ‘UNDO’ : pour les segment d’annulation, qui stockent les images avant, lors des ROLLBACKS

Outre ces tablespaces ‘système’ qui servent en quelque sorte à la cuisine interne d’Oracle, il faudra bien tout de même stocker quelques données (et indexs)
Ici plusieurs stratégies sont possibles :
- séparation des indexs et des datas,
- séparation des différents domaines fonctionnels

note : Il serait possible également de stocker les datas, les index dans ces SYSTEM ou SYSAUX.
Ceci est vivement déconseillé, car on aurait ainsi une base minimale peu structurée.

Les tablespaces sont donc utiles pour répartir les données, les index, mais aussi les segments d’annulations et les espaces temporaires sur plusieurs espaces logiques et disques.
Ils permettent :
- performance (répartitions des accès disques),
- souplesse (séparation fonctionnelle ou métier, meilleure granularité des sauvegardes),
- sécurité (séparation des infos systèmes des données utilisateurs)

SQL de base pour la gestion des TBS

SQL> CREATE TABLESPACE …
SQL> DROP TABLESPACE…
SQL> ALTER TABLESPACE…

exemples

SQL> CREATE TABLESPACE COMPTA DATAFILE
‘E:orantdatabaseTESTcompta1TEST.ora’ SIZE 100M;
SQL> ALTER TABLESPACE COMPTA OFFLINE;
SQL> ALTER TABLESPACE COMPTA ADD DATAFILE
‘E:orantdatabaseTESTcompta2TEST.ora’ SIZE 100M;
SQL> DROP TABLESPACE COMPTA INCLUDING CONTENTS AND DATAFILE;
SQL> ALTER TABLESPACE CHARGEMENT_BATCH NOLOGGING;
SQL> ALTER TABLESPACE INFOCENTRE READ ONLY;

Description des tablespaces et fichiers de la base courante dans les vues
DBA_TABLESPACES , DBA_DATA_FILES, DBA_FREE_SPACE du dictionnaire.

SQL> SELECT TABLESPACE_NAME « Nom TBS », CONTENTS « Type de contenu », STATUS « EN ligne? », LOGGING « Journalise? », BIGFILE FROM DBA_TABLESPACES;

Nom TBS Type de
contenu EN ligne? Journalise?
——– —— — ———–
SYSTEM PERMANENT ONLINE LOGGING NO
UNDOTBS1 UNDO ONLINE LOGGING NO
SYSAUX PERMANENT ONLINE LOGGING NO
TEMP TEMPORARY ONLINE NOLOGGING NO
USERS PERMANENT ONLINE LOGGING NO
EXAMPLE PERMANENT ONLINE LOGGING NO
6 rows selected.

Tablespaces et fichiers

Un tablespace contient AU MOINS un fichier. Celui-ci est créé lors de la création du tablespace, de manière automatique par
Oracle, en fonction des paramètres donnés par la commande CREATE ou ALTER tablespace (emplacement du fichier, nom, taille, et mode d’extension).

note : Lors de la suppression du tablespace (DROP TABLESPACE…) les fichiers correspondant ne sont PAS SUPPRIMES par Oracle par défaut. Utilisez la clause ‘AND DATAFILE’…

exemples

SQL>
Nom_Tbs   Nom_Fic.                                       MO  AUTOEXTENSILE
USERS     C:ORACLEPRODUCT10.1.0ORADATAORCLUSERS01.DBF    5   YES
SYSAUX    C:ORACLEPRODUCT10.1.0ORADATAORCLSYSAUX01.DBF   230 YES
UNDOTBS1  C:ORACLEPRODUCT10.1.0ORADATAORCLUNDOTBS01.DBF  30  YES
SYSTEM    C:ORACLEPRODUCT10.1.0ORADATAORCLSYSTEM01.DBF   440 YES
EXAMPLE   C:ORACLEPRODUCT10.1.0ORADATAORCLEXAMPLE01.DBF  150 NO
EXAMPLE   C:ORACLEPRODUCT10.1.0ORADATAORCLEXAMPLE012.DBF 10  NO

Extension et gestion d’espace des tablespaces et des fichiers

La taille d’un tablespace est la taille de son (ses) fichier(s) d’origine.
Pour augmenter la taille d’un tablespace, il y a 2 solutions :
* Ajouter un fichier au tablespace, qui sera chainé au premier (ALTER TABLESPACE toto ADD DATAFILE…)
* mettre le fichier du tablespace en AUTO extension (ALTER DATABASE DATAFILE toto.dbf AUTOEXTEND ON)
Une table (et tout segment en général) , peut « s’étaler » sur plusieurs fichiers. Ainsi le fait qu’une table sature un tablespace n’est pas bloquant il suffit d’augmenter la taille du tablespace.

autoextension des fichiers

ATTENTION : la clause AUTOEXTEND spécifie la taille d’extension du fichier d’un tablespace. La clause STORAGE INITIAL, NEXT, MINEXTENTS … spécifie la taille d’extension d’UN SEGMENT du tablespace par exemple une table. Ces 2 paramètres sont totalement indépendants. La preuve en est qu’une table (un segment de données) est forcément en allocation dynamique alors qu’un fichier peut avoir une taille fixe (AUTOEXTEND OFF)

note : Le changement de mode AUTOEXTEND se fait avec la commande ‘ALTER DATABASE’ pour les ‘SMALLFILE’ et ‘ALTER TABLESPACE’ pour les ‘BIGFILE’

exemples

SQL> – passage en AUTO extension d’un fichier de tablespace existant
SQL> ALTER DATABASE DATAFILE ‘E:orantdatabaseTESTUsr1TEST.ora’ AUTOEXTEND ON;
SQL> ALTER DATABASE DATAFILE ‘C:ORACLEPRODUCT10.1.0ORADATAORCLEXAMPLE01.DBF’
AUTOEXTEND OFF
SQL> – ajout d’un ficheir auto extensible jusqu’a 100 MO
SQL> ALTER TABLESPACE toto ADD DATAFILE ‘E:orantdatabaseTESTTEST.ora’ SIZE 10M AUTOEXTEND ON NEXT 5M MAXSIZE 100M;

extension des segments

* clause LOCAL : Tablespaces gérés localement (Locally managed tablespaces)
Anciennement les tablespaces étaient gérés au niveau du dictionnaire de données, la gestion de l’espace physique (allocation / libération de blocs) se fait désormais dans l’entête du fichier(s) du tablespace. Une table binaire d’allocation (bitmap) y
est maintenue. C’est le fonctionnement par défaut (sauf pour le tablespace SYSTEM)
Avantages :
* pas de contention en mise à jour au niveau du dictionnaire
* et conséquemment pas d’utilisation de Rollback segment pour ces transactions
* pas de soucis de gestion de l’espace (calcul d’un storage adéquat)
* « coalesce » automatique (fusion des espaces libres contigus pour optimiser l’espace libre)
Evidemment la clause « DEFAULT STORAGE » est invalide pour les tablespaces gérés localement.

* Clause AUTOALLOCATE
C’est Oracle qui gère !

* Clause UNIFORM
Les extents ont tous la meme taille, par défaut 1MO, sinon elle est précisée par le paramètre ‘SIZE’

* clause STORAGE
Les règles et les statistiques d’allocations sont gérées au niveau du dictionnaire.
Pour plus d’informations voir le chapitre sur les ‘segments et extents’
changement des paramètres d’un tablespace existant
ALTER TABLESPACE SYSTEM
DEFAULT STORAGE ( INITIAL 100K NEXT 100K MINEXTENTS 1 MAXEXTENTS 300 PCTINCREASE 1);

Quelques exemples de syntaxe

SQL> CREATE TABLESPACE COMPTA DATAFILE ‘E:orantdatabaseTESTcompta1TEST.ora’
SIZE 100M EXTENT MANAGEMENT LOCAL AUTOALLOCATE;
SQL> CREATE TABLESPACE COMPTA DATAFILE ‘E:orantdatabaseTESTcompta1TEST.ora’ SIZE 100M EXTENT MANAGEMENT LOCAL UNIFORM SIZE 500K;
SQL> CREATE TABLESPACE COMPTA DATAFILE ‘E:orantdatabaseTESTcompta1TEST.ora’ SIZE 100M EXTENT MANAGEMENT DICTIONARY;

Architecture (s) Oracle

Administration Oracle, Divers pas de Commentaire »

Architectures locales et réparties

On peut distinguer essentiellement 3 types d’architecture globale de systèmes d’information basés sur Oracle :

  • architecture locale
    Tout est sur le même serveur matériel, programme client et serveur de données Oracle

    archi locale

  • architecture client/serveur
    On a 2 poles : client + serveur
    On a un programme client (un exécutable) sur le poste client, dit alors ‘client lourd’ . Le PC communique avec le serveur de données sur un serveur distant, via le réseau, et la couche Oracle Net.

    archi 2 tier

  • architecture 3 tiers
    On a 3 poles : cleint / serveur d’application /serveur de donnéesPas de programme client. Un navigateur suffit sur le poste de travail (dit alors ‘client léger’). Il dialogue avec le seveur de données distant via http.

archi 3 tier

note : il existe également des architectures n- tiers plus anecdotiques, mais conceptuellement intéressantes

Instance ?
Rappel : Une instance est caractérisée par son identificateur : SID, généralement une variable ORACLE_SID positionnée dans l’environnement.

Une instance active en mémoire ce sont :
- des programmes de fond, services ou processus, qui assurent la maintenance du serveur de données et les entrées / sorties fichiers
- des process server (dédiés ou non à un utilisateur)
- une zone globale partagée : la SGA, qui contient essentiellement du cache de buffers
- des zones mémoires dédiées aux utilisateurs : les PGAs (Private Global Area)

instance gene

Schéma de l’architecture générale en mémoire

La SGA
La SGA est essentiellement un cache mémoire qui contient des infos partagées de la base.

Les process de fond
Ils permettent de paralléliser et désynchroniser les accès multi-utilisateur à la base.
Nous allons lister les principaux :

  • DBWn Database Writer
    Ecrit les données modifiées, du cache de données de la SGA vers les fichiers de données. On peut en avoir plusieurs (max 20) suivant la valeur du parametre DB_WRITER_PROCESSES
  • LGWR Log Writer
    Ecrit les mises à jour, du cache de LOG de la SGA vers les ou le fichiers REDOLOG, suivant qu’on utilise des LOGs multiplexés ou non.
  • CKPT Checkpoint
    Signale l’occurence d’un point de reprise (flush de tous les buffers de données), à DBWR
  • PMON Process Monitor
    Libère les ressources et nettoie le cache en cas d’échec d’un process utilisateur
  • SMON System Monitor
    Surveille les process de l’instance et assure les restaurations d’instance
  • RECO Recoverer
    Gère les transactions distribuées (commit à 2 phases)

et optionnellement :

  • ARCn Archiver
    sauvegarde le REDOLOG qui vient d’être terminé
  • Dnnn Dispatcher
    Distribue les accès utilisateurs, vers les serveurs partagés, en architecture multiplexée (Shared Server)
  • Snnn Shared Server
    Process utilisateurs partagé, en architecture multiplexée
  • CJQn Coordinateur de jobs batch
    Jnnn Process fils dédiés aux Jobs
  • QMNn – Queue monitor
    gestionnaire de file d’attente, pour l’option Oracle Advanced QUeuing
  • Pnnn Esclave d’execution Parallele
    Exécution des requêtes parallèles. Le nb max de process est donné par : PARALLEL_MAX_SERVERS
  • LCKn Lock monitor
    verrouillage des ressources utilisées par plusieurs instances
  • LMS Global cache service
    Gestion des ressources inter-instances en architecture cluster (RAC)

instance detail

note : sous Unix/Linux ces process correspondent à des process Unix, qui appartiennent à l’utilisateur Oracle et s’exécutent de manière ‘déconnectée’ (background).
On peut facilement en avoir la liste avec la commande suivante :
$> ps -ef |grep oracle

process unix

Sous Windows ils correspondent à des services :

services