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

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Oracle : du bon usage de la flashback recovery area (FRA) - Apprendre à gérer et vérifier l'utilisation de ce volume,
Par Fabien Celaia

Le , par Fabien Celaia

0PARTAGES

KESAKO ?
Depuis la version 10, Oracle nous nourrit de nouvelles fonctionnalités fort intéressantes au niveau des sauvegardes / options de récupérations...
La Flashback Recovery Area (FRA pour les intimes) est souvent utilisée. Il s'agit d'un volume que l'on doit spécifier... mais comment justement gérer et vérifier l'utilisation de ce volume ?

Note : je travaille sur un environnement RAC, donc je fais parfois appel aux vues GV$... si tel n'est pas votre cas, corrigez en remplaçant le GV$ par V$ et, dans les ordres ALTER SYSTEM, supprimez les clauses sid='*'.

Activation

On détermine un volume distinct et on lui attribue une taille maximale. Optionnellement, on active ensuite le flashback DB : depuis la version 11, cette activation peut se faire base ouverte.
Code SQL : Sélectionner tout
1
2
3
ALTER SYSTEM SET db_recovery_file_dest='+ORA_DVP_FRA' scope=both sid='*' ; 
ALTER SYSTEM SET db_recovery_file_dest_size=10G scope=both sid='*' ; 
ALTER DATABASE FLASHBACK ON ;
... et si l'on souhaite utiliser ce volume comme stockage pour nos sauvegardes et nos archivelogs :

Une petite requête pour déterminer notre besoin de taille pour les archivelogs, par jour
Code SQL : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
SELECT trunc(first_time) JOURS, sum((blocks+1)*block_size)/1024/1024/1024 TAILLE_GO, count(*) NBR_FICHIERS  
FROM gv$archived_log   
GROUP BY  trunc(first_time)  
ORDER BY trunc(first_time) DESC ; 
  
JOURS                 TAILLE_GO NBR_FICHIERS 
------------------- ----------- ------------ 
09.10.2017 00:00:00        8.97          110 
15.10.2017 00:00:00      160.27         1506 
16.10.2017 00:00:00        8.50          104 
17.10.2017 00:00:00       33.72          322 
18.10.2017 00:00:00        6.95           98 
07.10.2017 00:00:00       16.88          172 
08.10.2017 00:00:00        5.25           62 
13.10.2017 00:00:00        8.87          102 
05.10.2017 00:00:00        9.41          106 
06.10.2017 00:00:00        9.37          116 
19.10.2017 00:00:00       16.44          162 
10.10.2017 00:00:00        8.24          106 
11.10.2017 00:00:00       19.95          198 
12.10.2017 00:00:00       22.02          200 
20.10.2017 00:00:00        2.76           36 
14.10.2017 00:00:00       18.53          184

En d'autres termes, rien que pour la partie des archivelogs, il me faut compter sur 250 Go d'espace pour tenir trois jours... ou alors je dois m'assurer que le besoin du 15.10.2017 était exceptionnel...

Lorsqu'elle est activée, la FRA va se purger quand elle peut, ceci souvent en adéquation avec votre politique de backup (rman retention policy). Si vous déterminez que vos backups prennent place en FRA, que vous les maintenez trois jours, il vaut que le volume soit suffisant. Si tel n'est pas le cas, vous allez geler votre base de données avec le désormais célèbre message ORA-19809: limit exceeded for recovery files

Désactivation

Lorsque la FRA est totalement pleine, la base gèle, et il est souvent stressant de libérer les espaces nécessaires lorsque la production n'est plus en état. C'est pour cette raison que je taille toujours ma FRA 10 Go en dessous de la taille du volume sous-jacent, ceci afin de me laisser du champ au cas où, malgré toutes mes précautions, je me retrouverais en situation de crise : il est toujours plus rapide de lui redonner ces 10 Go que de devoir attendre de nouveaux espaces de stockage...

La désactivation de la FRA se fait en lui désattribuant son volume.

Code SQL : Sélectionner tout
1
2
ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = '' scope=both sid='*'; 
ALTER DATABASE FLASHBACK OFF;

Monitoring
Lorsque le volume est spécifié et la base utilisée, deux tables vont nous être utiles : je vous transmets ici deux requêtes un peu plus parlantes :

Pour déterminer le volume utilisé réellement par rapport au volume défini par db_recovery_file_dest_size

Code SQL : Sélectionner tout
1
2
3
4
5
6
 SELECT space_limit/1024/1024/1024 LIMITE_GO, SPACE_USED/1024/1024/1024 UTILISE  
FROM V$RECOVERY_FILE_DEST; 
  
     LIMITE_GO    UTILISE 
------------- ---------- 
          180 97.9775391
Logiquement, la limite est la valeur spécifiée dans votre db_recovery_file_dest_size.

Et, plus spécifiquement, le pourcentage utilisé pour chacune des options possibles

Code SQL : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
SELECT * FROM V$RECOVERY_AREA_USAGE; 
  
FILE_TYPE            PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES 
-------------------- ------------------ ------------------------- --------------- 
CONTROL FILE                          0                         0               0 
REDO LOG                              0                         0               0 
ARCHIVED LOG                       6.56                       6.4             131 
BACKUP PIECE                          0                         0               0 
IMAGE COPY                            0                         0               0 
FLASHBACK LOG                     47.87                     26.28             439 
FOREIGN ARCHIVED LOG                  0                         0               0

La même chose, mais en taille :
Code SQL : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
SELECT u.FILE_TYPE, u.NUMBER_OF_FILES FICHIERS, d.space_limit/1024/1024/1024/100*PERCENT_SPACE_USED UTILISE   
FROM V$RECOVERY_AREA_USAGE U, V$RECOVERY_FILE_DEST D; 
  
FILE_TYPE              FICHIERS    UTILISE 
-------------------- ---------- ---------- 
CONTROL FILE                  0          0 
REDO LOG                      0          0 
ARCHIVED LOG                129     11.646 
BACKUP PIECE                  0          0 
IMAGE COPY                    0          0 
FLASHBACK LOG               439     86.166 
FOREIGN ARCHIVED LOG          0          0
Comme vous le voyez, il reste du travail ...
  • J'utilise moins de 50 % de la taille que je me suis fait allouer...
  • Mes backups sont faits sur bandes, donc n'apparaissent pas dans la FRA (ce qui me permet de maintenir une FRA pas trop énorme)
  • Mes redo logs et mes control files sont stockés hors FRA
  • Je n'utilise pas de réplication, donc pas d'archivelogs étrangers
  • J'utilise le flashback database


Dans cette situation bien précise, il va donc falloir que je prenne économiquement une décision :
  • soit je continue à travailler de la sorte, et je rends 40 % de la place allouée, en réduisant alors mon volume FRA dans ASM ;
  • soit j'utilise plus optimalement ma FRA en y déposant, entre autres, des copies de mes fichiers de contrôle, un membre de chacun de mes redo...

Une erreur dans cette actualité ? Signalez-nous-la !