par , 20/10/2017 à 14h06 (7470 Affichages)
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.
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
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.
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
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
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 :
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...
Consulter le profil
Marquer ce blog comme lu
