par , 31/08/2020 à 12h17 (1238 Affichages)
Introduction
Depuis la version 10 d'Oracle, une corbeille bien pratique permet aux développeurs maladroits de récupérer une table qu'ils auraient malencontreusement supprimée. Je vous renvoie à mon article sur le sujet.
Le problème, c'est que la suppression devient alors logique (et pas physique) : l'objet (et ses blocs alloués) ne disparaît pas, mais est juste renommé (les fameux objets BIN$%==$0).
La base de donnée prend donc de l'embonpoint... une couche de gras qu'il convient de maîtriser dans un environnement de production.
Bien sûr, il y a toujours l'option d'inactiver la corbeille (qui nécessite un reboot)... mais c'est une fonctionnalité quand même bien pratique qui évide de fastidieuses restaurations.
alter system set recyclebin=off scope=spfile sid='*' ;
Taille des objets d'une base
Pas trop compliqué : il suffit de requêter sur les segments
1 2 3 4 5 6 7 8 9 10 11
| select segment_type,
case segment_type when 'LOBSEGMENT' then s.owner||'.'||l.table_name ||'('||l.column_name||')'
when 'INDEX' then i.index_name ||' de '||i.owner||'.'||i.table_name
ELSE s.segment_name
END OBJ,
s.bytes/1024/1024/1024 Gb
from dba_segments s
left join dba_lobs l on s.owner=l.owner and s.segment_name=l.segment_name
left join dba_indexes i on s.owner=i.owner and s.segment_name=i.index_name
where s.tablespace_name like '%CARI%'
order by s.bytes desc |
Sentez-vous libre, au besoin, d'ajouter un filtre sur le segment_type... mais il est toujours intéressant de ne pas se limiter au tables. Souvent, ce sont les objets sous-jacents (index, LOB) qui mangent plus de place que ce que l'on s'imagine.
Taille de la recylebin
Assez simple aussi, il suffit d'aller voir dans la vue DBA_RECYCEBIN (select ou SHOW). La colonne SPACE y est spécifiée en bloc.
Nettoyage de la recyclebin
Là aussi, rien de plus simple, en tant que SYS
Au niveau global, on peut le faire, en tant que SYS, via
On peut aussi se retreindre à des objets particuliers via
1 2 3 4
| PURGE recyclebin;
PURGE TABLESPACE monTablespace;
PURGE TABLESPACE monTablespace USER MonSchema;
PURGE UneTable; |
L'effet se fait directement sentir sur les tablespaces, mais il reste un souci : impossible souvent de réduire la taille des datafiles puisque le nettoyage des blocs est souvent sous la barre du high watermark.
ORA-03297: le fichier contient des données utilisées au-delà de la valeur RESIZE requise
Réduction d'un tablespace
Il convient de détecter quels sont les objets qui monopolisent le "haut" de l'adressage du tablespace et de les réorganiser afin qu'ils se stockent sur la partie basse. Là, ca devient un peu plus "touchy" car la place physique dans le tablespace doit être trouvée dans DBA_EXTENTS, et cela ne se fait plus au niveau du tablespace, mais bien au niveau (physique) de chaque datafile.
1 2 3 4 5 6
| select e.owner,e.SEGMENT_NAME, max(e.block_id), d.file_name
from dba_extents e
inner join dba_data_files d on e.FILE_ID = d.file_id
where e.tablespace_name like '%MonTablespace%'
group by e.owner,e.SEGMENT_NAME, d.file_name
order by max(e.block_id) desc |
Le travail d'administration du DBA reste alors à faire:
- reconstruction des tables
- reconstruction des LOB
- reconstruction des indexes
Une nouvelle fois, je vous renvoie à un article sur la réorganisation
Ensuite la réduction des datafiles devrait pouvoir se faire.
Selon la masse de travail à investir, il convient peut-être de passer par un expdp/impdp (avec l'interruption de service que cela provoquera)... Le datapump a le mérite de travailler au niveau logique... donc il réorganisera automatiquement tous les objets traités, s'il est bien entendu en mode TABLE_EXISTS_ACTION=REPLACE.
Les pièges de la recyclbin
Le problème avec ce type de procédé, c'est lorsqu'il est associé à une vision minimaliste de l'administration des DBA. Si ces derniers ont déterminés vos tablespaces en mode autoextent, unlimited, la recyclebin ne se sentira pas bloquée tant que la place ne lui manquera pas.... et vos tablespaces vont prendre de l'embonpoint. Etrange : ma base fait 1To, mais si je fais la somme de mes extents, elle n'est que de 200Go ? un petit coup de purge_dba_recyclebin, et revoilà 80% d'espace libéré... Donc, il nous reste 3 alternatives :
- travailler avec le recyclebin dans des tablespaces avec limite de taille
- se passer de la recyclebin
- purger régulièrement la recyclebin
Including datafiles
Que ce soit lors de la suppression d'un tablespace ou lors de la suppression d'une base de données enfichable, on peut spécifier le "including datafiles" : ce n'est pas anodin, on demande donc à Oracle de supprimer non seulement l'objet logique, mais aussi les fichiers physiques sous-jacents.
Dans le cas où on ne le fait pas, le fichier va rester sur le disque, mais est alors dissocier d'un objet en base. Difficile ensuite de ne pas oublier d'aller le nettoyer manuellement, surtout dans le cas des bases enfichables, et lorsqu'elles sont en plus stockées dans un ASM. Mais si on ne le fait pas, en voici des Go gaspillés.
Je connais un cas où la suppression doit se faire sans le including datafiles, c'est lorsque le tablespace ou la base sont corrompus. Le drop simple permet de les supprimer du métamodèle, le drop manuel au niveau ASM de récupérer l'espace.
Il y a une vue assez pratique qui, pour une base de données spécifique, vous donne la liste des datafiles. Il suffit alors de comparer cette liste à la liste de vis fichiers dans ASM pour savoir lesquels sont orphelins, et susceptibles d'être détruire "à la main".
1 2 3 4 5 6 7
| set pagesize 900 linesize 200
col USER_BYTES/1024/1024 format 999,99,999.99
col tablespace_name format a20
col file_name format a100
select tablespace_name, file_name, user_bytes/1024/1024 SIZE_MO
from cdb_data_files
order by file_name; |
Et celle-ci pour vous sortir les fameux UUID des bases enfichables utilisées actuellement (ici un cluster à 2 noeuds)
1 2 3 4 5 6 7 8
| set linesize 300
set pagesize 9999
col total_size format 9999999999999
col name format a30
select p1.name, p1.open_mode INST1, p2.open_mode INST2, p1.total_size, p1.guid
from gv$pdbs p1 inner join gv$pdbs p2 on p1.guid=p2.guid
where p1.inst_id=1 and p2.inst_id=2
order by p1.name; |
Ne supprimez, dans ASM, JAMAIS un datafile contenu dans un UUID utilisé poar votre instance, ou uniquement avec attention, lorsque vous avez exécuté un drop tablespace sans including contents and datafiles.
Mis à jour 08/05/2021 à 20h20 par Fabien Celaia
Tags:
corbeille,
datafile,
extent,
oracle,
recyclebin,
reorg,
réorganisation,
segment,
tablespace,
taille,
volume
- Catégories
-
SGBD
,
Oracle