Administration du module Oracle

Ce document couvre l’administration du module Oracle.

0. Prérequis et configuration du module

Prérequis

• Extension PHP oci8 + Oracle Instant Client côté serveur web. Sans elle,

le module s’affiche mais aucune connexion n’est possible.

• Extension ZipArchive si vous utilisez des connexions Oracle Cloud

(import du wallet).

• Rôle oracle_admin pour administrer (le super-rôle app_admin convient).

Configuration du module

Le module Oracle n’a pas de page de configuration globale et aucun hook d’activation : il n’y a rien à paramétrer avant de l’activer, et aucun fichier securite/modules/oracle.json n’est créé. L’activation se contente de créer les rôles oracle_admin et oracle_user.

Toute la configuration est applicative et se fait dans les pages du module, dans cet ordre :

1. Groupes (§2) — organiser les bases ; le groupe Default existe d’office.
2. Bases (§1) — déclarer les connexions (standard ou Cloud/wallet).
3. Accès (§3) — attribuer les droits par groupe × sous-groupe.
4. Rôles Oracle internes (§4) — facultatif, pour mutualiser des droits.

Les sous-groupes sont figés par l’application : dev, homol, perf, pre-prod, prod, secours.

Données et sauvegarde

Les connexions vivent dans la base applicative (tables oracle_*), les mots de passe y sont chiffrés, et les wallets Cloud sont extraits sous securite/wallets/<id_base>/.

Sauvegardez securite/master.key en même temps que la base applicative : sans cette clé, les mots de passe enregistrés sont irrécupérables.

1. Enregistrement des bases

Accès : oracle_admin uniquement.

Types de connexion

graph TD
 A[Nouvelle base] --> B{Type ?}
 B -->|Standard| C["host:port/service_name"]
 B -->|Cloud / Wallet| D["TNS Alias + fichier wallet ZIP"]
 C --> E[Test de connexion]
 D --> F[Extraction wallet<br>dans securite/wallets/]
 F --> E
 E -->|OK| G[Enregistrement]

Connexion standard

Connexion Cloud (wallet)

Le wallet est extrait dans securite/wallets/<id_base>/. Le fichier sqlnet.ora est automatiquement modifié pour pointer vers le bon répertoire. Les bases cloud ont automatiquement les licences Diagnostic et Tuning Pack.

Champs communs

Test de connexion

Le bouton Tester effectue une connexion OCI8 réelle et affiche la version Oracle en cas de succès.

Initialisation de session

À chaque connexion, l’application configure automatiquement :

• Formats NLS (dates ISO-8601, tri binaire)
• Identifiant client (dbms_session.set_identifier)
• Module/Action (dbms_application_info.set_module) — visible dans

V$SESSION pour l’audit

2. Groupes de bases

Accès : oracle_admin uniquement.

Les bases sont organisées en groupes (ex. “Production”, “Dev/Test”, “Cloud”). Chaque groupe contient des bases réparties en sous-groupes (environnements).

Les groupes servent de base au contrôle d’accès (voir section suivante).

3. Contrôle d’accès Oracle

Accès : oracle_admin uniquement.

Modèle d’accès

L’accès aux bases est contrôle par une matrice principal x groupe x sous-groupe x droit :

graph TD
 A[Utilisateur] --> B{Acces ?}
 B -->|oracle_admin| C[Toutes les bases]
 B -->|app_admin| C
 B -->|Acces direct| D[Bases du groupe/sous-groupe octroye]
 B -->|Via role Oracle| E[Bases du groupe/sous-groupe du role]
 D --> F{Droit ?}
 E --> F
 F -->|consultation| G[Lecture seule]
 F -->|dba_dev| H[Lecture + kill session + correction SQL]
 F -->|dba| I[Toutes les actions DBA]

Principaux (principals)

Deux types de principals :

Droits

Hiérarchie : dba > dba_dev > consultation.

Le helper oracle_right_at_least($right, $minLevel) centralise les comparaisons de niveau.

Interface d’édition

1. Vue liste : tableau des principals avec le nombre de

groupes/sous-groupes accessibles

1. Vue édition (clic sur un principal) : matrice groupes x

sous-groupes avec sélecteur (—, consultation, dev, dba)

Les changements sont transactionnels : suppression des anciens droits + insertion des nouveaux.

Cas spécial : group_id = NULL signifie “tous les groupes (présents et futurs)”. subgroup = NULL signifie “tous les sous-groupes”.

4. Rôles Oracle internes

Accès : oracle_admin uniquement.

Note : ces rôles sont internes au module Oracle et distincts des rôles applicatifs (oracle_admin, oracle_user). Ils sont un mécanisme supplémentaire pour regrouper des permissions d’accès.

Structure

Opérations

La résolution des droits est récursive (un rôle peut inclure d’autres rôles, avec protection contre les cycles).

5. Import/Export de bases

Accès : oracle_admin uniquement.

Export

Généré un fichier JSON contenant toutes les bases enregistrées avec :

• Paramètres de connexion
• Mots de passe (chiffrés)
• Groupe et sous-groupe
• Description

Import

Upload d’un fichier JSON : les bases sont fusionnées dans le registre existant. Les mots de passe sont re-chiffrés si nécessaire. Les wallets associés sont re-extraits.

6. Licences Oracle

Le module détecte automatiquement les licences Diagnostic Pack et Tuning Pack de chaque base.

Détection

Impact sur les fonctionnalités

Quand une licence manque, les rapports concernés affichent un bandeau d’avertissement avec la valeur du paramètre CONTROL_MANAGEMENT_PACK_ACCESS.

7. Administration sw$bash_snapper

Contexte

sw$bash_snapper est un package PL/SQL qui échantillonne l’activité des sessions Oracle à la manière d’AWR, sans nécessiter de licence Diagnostic Pack. C’est une alternative gratuite pour les bases sans cette licence.

Prérequis

• Droit DBA sur la base cible
• Compte Oracle avec les privilèges CREATE TABLE, CREATE Procédure,

MANAGE SCHEDULER

Cycle de vie

stateDiagram-v2
 [*] --> Non_installe
 Non_installe --> Installe : Installer
 Installe --> En_cours : Demarrer
 En_cours --> Installe : Arreter
 Installe --> Non_installe : Desinstaller
 En_cours --> En_cours : Purger

Objets créés

Interface d’administration

Depuis le rapport Diagnostics > sw$bash_snapper :

Informations affichées :

• Statut du collecteur (en cours / arrêté)
• Version du package
• Nombre d’échantillons actifs et historiques
• Nombre de snapshots
• Plage de dates des données disponibles

Actions :

Paramètres éditables :

Journal : les 20 dernières entrées du log du collecteur (SW$BASH_LOG) sont affichées en bas de page avec sévérité et message.

Basculement automatique

Quand sw$bash_snapper est installé et que la base n’a pas de licence Diagnostic Pack, les rapports historiques (ASH, heatmaps) basculent automatiquement sur les tables SW$BASH_* au lieu de DBA_HIST_*. Ce basculement est transparent pour l’utilisateur.

8. Opérations DBA

Les opérations suivantes nécessitent le droit DBA sur la base sélectionnée, sauf mention contraire (certaines sont accessibles des dba_dev).

Kill Session (dba_dev+)

Disponible depuis le rapport Temps réel > Sessions actives et Temps réel > Verrous.

• Exécute ALTER SYSTEM KILL SESSION 'sid,serial#,@inst_id'
• Confirmation demandée avant exécution
• Protégé par CSRF

Collecte de statistiques (dba)

Disponible depuis le tableau de bord Calcul des stats :

• Bouton “Collecter” en face de chaque table à statistiques périmées
• Exécute DBMS_STATS.GATHER_TABLE_STATS via DBMS_SCHEDULER

(exécution asynchrone)

Planification de stats système/dictionnaire

Le bouton Planifier ouvre une modale permettant de lancer un calcul asynchrone via DBMS_SCHEDULER.CREATE_JOB (auto_drop=TRUE) :

Options :

• Mode (stats système uniquement) : NOWORKLOAD, INTERVAL, EXADATA
• Flush buffer cache : exécute ALTER SYSTEM FLUSH BUFFER_CACHE

avant la collecte

Correction SQL (dba_dev+)

Disponible depuis la page Détail SQL :

Suppression de SQL Profiles (page Tuning SQL)

La page Config > Tuning SQL affiche la liste des SQL Profiles existants. Les DBA peuvent supprimer un profil directement depuis cette page via le bouton Supprimer en colonne Actions.

Tablespaces & Redo Logs (dba)

Disponible depuis le rapport Config > Tablespaces & Redo Logs :

Redimensionnement de datafiles

Le nom de chaque tablespace data (souligné, cliquable des le premier affichage du graphique) ouvre une modale qui chargé la liste des datafiles via AJAX, puis permet de modifier la taille de chacun.

• Exécute ALTER DATABASE DATAFILE '<path>' RESIZE <N>M
• Validation : le chemin du fichier est vérifie contre DBA_DATA_FILES

avant exécution (protection injection)

Gestion des redo log groups

Redimensionnement de tous les redo logs

Bouton Redimensionner tous les redo logs : recrée chaque groupe avec la nouvelle taille. L’opération procède par :

1. Log switch (ALTER SYSTEM SWITCH LOGFILE) + checkpoint
2. Drop de chaque groupe INACTIVE
3. Recréation avec la nouvelle taille
4. Groupes ACTIVE/CURRENT traités en dernier après nouveau switch

Le résultat affiche le nombre de groupes recréés, ignorés et en erreur.

Gestion DBMS_SCHEDULER (dba)

Disponible depuis le tableau de bord Scheduler :

La suppression demande une confirmation. Toutes les actions sont protégées par CSRF et droit DBA.

Gestion sw$bash_snapper (dba)

Installation, démarrage, arrêt, purge et désinstallation du collecteur (voir section 7).

Statistiques & Auto Tuning (dba)

Depuis les pages Configuration → Calcul des statistiques et Configuration → Tuning SQL :

Toutes ces actions sont protégées par CSRF et exigent le droit DBA.

TDE — passage en auto-login (dba / app_admin)

Depuis le tableau de bord TDE / Wallets, un bouton « Passer en auto-login » est propose aux utilisateurs ayant le droit DBA sur la base ou le rôle app_admin (administrateur du site), et uniquement si le wallet n’est pas déjà en auto-login.

Une fenêtre modale demande le mot de passe du keystore et, en option, un auto-login local (LOCAL_AUTO_LOGIN, lié à l’hôte — deconseille en RAC car le wallet ne peut être copie vers un autre nœud).

L’action exécute :

ADMINISTER KEY MANAGEMENT CREATE [LOCAL] AUTO_LOGIN KEYSTORE
 FROM KEYSTORE '<emplacement>' IDENTIFIED BY "<mot_de_passe>";

• L’emplacement du keystore est lu côté serveur (V$ENCRYPTION_WALLET),

jamais fourni par le client.

• Le mot de passe est inline dans le DDL : les guillemets doubles et

sauts de ligne sont refusés (validation côté serveur). Il n’est pas journalisé par l’application.

• La connexion Oracle doit disposer du privilège SYSDBA / SYSKM (ou

ADMINISTER KEY MANAGEMENT) ; sinon l’erreur ORA- est renvoyée.

• Effet diffère : le keystore auto-login (cwallet.sso) est créé mais ne

devient actif qu’au prochain redémarrage de l’instance (ou après fermeture / réouverture du keystore).

Annexe : Schéma du module Oracle

erDiagram
 oracle_databases ||--o{ oracle_access : "controle par"
 oracle_groups ||--o{ oracle_databases : "contient"
 oracle_roles ||--o{ oracle_role_perms : "a pour permissions"
 oracle_roles ||--o{ oracle_role_grants : "attribue via"
 oracle_databases {
 int id PK
 text name
 int group_id FK
 text subgroup
 text connection_type
 text host
 int port
 text service_name
 text tns_alias
 text username
 text password
 int sysdba
 text description
 }
 oracle_groups {
 int id PK
 text name UK
 }
 oracle_access {
 int id PK
 int user_id FK
 text ad_group
 int group_id FK
 text subgroup
 text right
 }
 oracle_roles {
 int id PK
 text name
 text description
 }
 oracle_role_perms {
 int id PK
 int role_id FK
 int group_id FK
 text subgroup
 text right
 }
 oracle_role_grants {
 int id PK
 int role_id FK
 int user_id FK
 text ad_group
 }