Cependant, n'étant pas propriétaire de la base et n'ayant pas l'autorisation d'augmenter le-dit SYSAUX, j'ai du chercher à grappiller quelques Mo.
Utilisation de SYSAUX
Pour savoir ce qui utilise SYSAUX, il suffit de lancer cette requête :SELECT occupant_name "Coupable",
space_usage_kbytes/1048576 "Espace occupé (Go)",
schema_name "Schema"
FROM v$sysaux_occupants
ORDER BY 2 desc;AWR et droit d'utilisation
Pour ce client, AWR était d'autant plus inutile qu'il n'avait pas payé le tuning pack. Il n'avait donc pas le droit de générer et d'aller voir les rapports AWR. Il se trouve qu ele client ne savait même pas ce que c'était. j'ai donc eu l'autorisation de purger les snapshots.Purge des snapshots
Pour purger les snapshots, il faut savoir quel est le plus ancien et quel est le plus récent. Cette requête donne ces infos.SELECT snap_id, begin_interval_time, end_interval_time
FROM SYS.WRM$_SNAPSHOT
WHERE snap_id = ( SELECT MIN (snap_id) FROM SYS.WRM$_SNAPSHOT)
UNION
SELECT snap_id, begin_interval_time, end_interval_time
FROM SYS.WRM$_SNAPSHOT
WHERE snap_id = ( SELECT MAX (snap_id) FROM SYS.WRM$_SNAPSHOT); Il faut ensuite réutiliser ces valeurs dans le bloc PL/SQL suivant :
BEGIN
dbms_workload_repository.drop_snapshot_range(low_snap_id => 14241, high_snap_id=>14321);
END;Récupérer la place libérée
Il faut ensuite shrinker la table pour pouvoir réellement récupérer la place (il faut être connecté en sys as sysdba).alter table sys.WRH$_ACTIVE_SESSION_HISTORY shrink space cascade;Et après ?
La procédure ci-dessus n'est qu'une procédure d'urgence. Il faudra prévoir rapidement d'envisager au moins une des actions suivantes :- Faire tourner le script utlsyxsz pour évaluer le besoin réel d'espace de SYSAUX
- Ajouter un datafile à SYSAUX (ou augmenter les datafiles existants)
- Diminuer la fréquence et la rétention des snapshots d'AWR
