IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Voir le flux RSS

Fabien Celaia

Volumes et recyclebin

Noter ce billet
par , 31/08/2020 à 11h17 (496 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.

Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
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

Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
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
Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
PURGE DBA_RECYCLEBIN ;

On peut aussi se retreindre à des objets particuliers via
Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
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.

Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
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:
  1. reconstruction des tables
  2. reconstruction des LOB
  3. 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".
Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
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)

Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
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.

Envoyer le billet « Volumes et recyclebin » dans le blog Viadeo Envoyer le billet « Volumes et recyclebin » dans le blog Twitter Envoyer le billet « Volumes et recyclebin » dans le blog Google Envoyer le billet « Volumes et recyclebin » dans le blog Facebook Envoyer le billet « Volumes et recyclebin » dans le blog Digg Envoyer le billet « Volumes et recyclebin » dans le blog Delicious Envoyer le billet « Volumes et recyclebin » dans le blog MySpace Envoyer le billet « Volumes et recyclebin » dans le blog Yahoo

Mis à jour 08/05/2021 à 19h20 par Fabien Celaia

Catégories
SGBD , Oracle

Commentaires