C’est bien la rentrée et voici donc le dernier article de la série sur les benchs et l’outil swingbench, le premier que vous avez déjà lu ici, décrivait l’outil, son installation, son paramétrage et son utilisation.
Le second accessible par ce lien, permettait une analyse de l’impact de la génération des flashbacks log sur les performances.
L’objectif de celui-ci est de réaliser le même type d’analyse mais  pour la fonctionnalité de “block change tracking” mise en œuvre dans une stratégie de sauvegarde incrémentale avec RMAN.
Ce sera l’occasion de rappeler les principes qui gouvernent ce mode puis de faire des tests comparatifs avec et sans l’activation de celui-ci, en évaluant l’impact sur les performances ainsi que sur le déroulement des sauvegardes incrémentales.

Block Change Tracking

Entrons maintenant dans le vif du sujet ! Le postulat de départ est d’utiliser RMAN pour réaliser vos sauvegardes, le principe de la sauvegarde incrémentale (disponible depuis les versions 9i) est celui ci : une fois que vous avez réalisé une première sauvegarde (que l’on référence comme étant une sauvegarde de « level » 0) de ne prendre en compte que les blocs modifiés par rapport à la sauvegarde précédente. Pour cela RMAN lit chacun des blocs de la base de données et détermine si le SCN de celui ci est supérieur ou non au SCN de la dernière sauvegarde. Cette opération de lecture peut être très longue si la base est volumineuse, ce qui limite l’intérêt de la sauvegarde incrémentale à la seule diminution de la taille du jeu de sauvegarde résultant. La durée totale de la sauvegarde restant globalement la même car il faut tout lire.
Pour pallier cet inconvénient, Oracle à mis en place depuis la version 10G la possibilité de “pister” les blocs modifiés dans un fichier spécifique : le block change tracking. Cette opération est réalisée par un nouveau process spécifique nommé CTW (pour Check Tracking Writer). Pour plus de détails concernant le format du fichier généré et l’algorithme d’écriture je vous recommande la lecture (en anglais cependant) du papier d’Alex Gorbachev  du groupe Pythian disponible ici, il a réalisé une analyse très fine du comportement  des différents process.
Voici comment mettre en œuvre ce mode et vérifier son état :

sql>alter database enable block change tracking ;

Et si l’on souhaite définir un autre fichier que celui imposé par défaut :

sql>alter database enable block change tracking using file '/u01/test_bct/bct.ora'';

Pour vérifier la mise en œuvre :

SQL> col status format a10
SQL> col filename format a30
SQL> select status,filename,bytes from v$block_change_tracking ;
STATUS     FILENAME                            BYTES
---------- ------------------------------ ----------
ENABLED    /u01/test_bct/bct.ora            1159987

Le fichier créé est d’une taille proche de 11Mo , il correspond à la taille de départ pour 8 versions de bitmaps pouvant couvrir approximativement 300Go de fichiers de données (suivant les calculs d’Alex Gorbachev au paragraphe « BCT File Sizing » du document pré cité)
Pour désactiver la fonctionnalité:

SQL> alter database disable block change tracking ;

SQL> select status,filename,bytes from v$block_change_tracking ;
STATUS     FILENAME                            BYTES
---------- ------------------------------ ----------
 DISABLED

Tir de référence

J’ai refais un tir d’étalonnage en déroulant de nouveau le scénario “Order Entry” de swingbench sur une base Enterprise Edition 11.1.0.7 sous OEL5.3. Cette base est en archivelog sans fonctionnalité de flashback ni le process CTW. Les conditions du test sont les mêmes que dans mon précédent article: 15 connexions utilisateurs, 5 transactions de même poids, durée de 15 minutes.
On retrouve logiquement un graphique général similaire à l’étalonnage précédent:

Ce qui donne pour le tableau des résultats (rappel de l’intitulé des colonnes :  « Maximum TPM »  nombre maximum de transaction par minute, « Moyenne TPS » Moyenne du nombre de transaction par seconde, « Tps Moyen (ms)   durée moyenne d’une transaction en ms,et pour les colonnes « Customer registration » , « Browse Products », « Order Products » , « Process orders » , « Browse Orders » durée moyenne de la transaction concernée en ms)

Tir du test

Une fois la fonctionnalité “bloc change tracking” activée j’ai rejoué le même test, dans les mêmes conditions et pendant une durée identique. Voici les courbes résultantes:

Et le tableau de synthèse de la comparaison entre les deux tirs

On constate que la mise en œuvre de la fonctionnalité n’a pratiquement pas d’impact, avec un temps moyen plus élevé de 2 ms, mais qui correspond à un allongement de durée pour deux transactions alors que les trois autres se déroulent plus rapidement. Le faible volume généré (le fichier est resté à une valeur de 11Mo) et le fait que le process CTWR soit complète ment en mode asynchrone explique cela.

Effets de bord

Ces tests ont été effectués sur notre LAN avec notre infrastructure, les résultats sont à prendre avec précaution et ne seront pas forcément identiques chez vous, même si la tendance devrait être respectée.
Regarder par exemple cette courbe qui traduit l’influence du chargement d’un logiciel sur le même LAN par un collègue pendant un tir.

On voit très bien l’écroulement du nombre de transaction par seconde et par minute et l’augmentation de la durée moyenne d’une transaction. Attention quand vous déroulerez vos propres tests à bien vous isolez du reste de votre activité.

Impact sur la sauvegarde

Sur  la configuration en place une sauvegarde de niveau 0 (sauvegarde complète) prend un temps elapse de 3 min 40s etgénère pour ma base test EASY11 un backupset de près de 500Mo, voici les traces de l’opération :

RMAN> backup incremental level 0 format '/u01/backup/back_bct_l0_%U' database ;
Starting backup at 16-AUG-10
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=121 device
channel ORA_DISK_1: starting compressed incremental level 0 datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00001 name=/u02/prod/oradata/EASY11/system01.dbf
input datafile file number=00002 name=/u02/prod/oradata/EASY11/sysaux01.dbf
input datafile file number=00006 name=/u02/prod/oradata/EASY11/soeindex.dbf
input datafile file number=00003 name=/u02/prod/oradata/EASY11/undotbs01.dbf
input datafile file number=00005 name=/u02/prod/oradata/EASY11/soedata.dbf
input datafile file number=00004 name=/u02/prod/oradata/EASY11/users01.dbf
channel ORA_DISK_1: starting piece 1 at 16-AUG-10

Backupset en sortie :

-rw-r----- 1 oracle oinstall 504799232 Aug 16 10:31 back_bct_l0_19llfooh_1_1

Sauvegarde incrémentale de niveau 1 (cumulatif par défaut) après tir de test sans la fonctionnalité BCT active, la durée est de 2m 46s pour un backupset de 100Mo :

RMAN>  backup incremental level 1 format '/u01/backup/back_bct_l1_%U' database ;
Starting backup at 16/08/2010 11:24:42
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=124 device
channel ORA_DISK_1: starting compressed incremental level 1 datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00001 name=/u02/prod/oradata/EASY11/system01.dbf
input datafile file number=00002 name=/u02/prod/oradata/EASY11/sysaux01.dbf
input datafile file number=00006 name=/u02/prod/oradata/EASY11/soeindex.dbf
input datafile file number=00003 name=/u02/prod/oradata/EASY11/undotbs01.dbf
input datafile file number=00005 name=/u02/prod/oradata/EASY11/soedata.dbf
input datafile file number=00004 name=/u02/prod/oradata/EASY11/users01.dbf
channel ORA_DISK_1: starting piece 1 at 16/08/2010 11:24:43
channel ORA_DISK_1: finished piece 1 at 16/08/2010 11:27:29
piece handle=/u01/backup/back_bct_l1_1dllfs3r_1_1 tag=TAG20100816T112443 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:02:46
Finished backup at 16/08/2010 11:27:29

Sauvegarde incrémentale de niveau 1 (cumulatif par défaut) après tir de test avec la fonctionnalité BCT active, la durée est de 1mn 15s pour une volumétrie identique d’une centaine de Mo:

RMAN>  backup incremental level 1 format '/u01/backup/back_bct_l1_%U' database ;
Starting backup at 16/08/2010 11:00:26
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=125 device
channel ORA_DISK_1: starting compressed incremental level 1 datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00001 name=/u02/prod/oradata/EASY11/system01.dbf
input datafile file number=00002 name=/u02/prod/oradata/EASY11/sysaux01.dbf
input datafile file number=00006 name=/u02/prod/oradata/EASY11/soeindex.dbf
input datafile file number=00003 name=/u02/prod/oradata/EASY11/undotbs01.dbf
input datafile file number=00005 name=/u02/prod/oradata/EASY11/soedata.dbf
input datafile file number=00004 name=/u02/prod/oradata/EASY11/users01.dbf
channel ORA_DISK_1: starting piece 1 at 16/08/2010 11:00:27
channel ORA_DISK_1: finished piece 1 at 16/08/2010 11:01:42
piece handle=/u01/backup/back_bct_l1_1bllfqmb_1_1 tag=TAG20100816T110026 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:01:15
Finished backup at 16/08/2010 11:01:42

Soit une différence d’un facteur de plus de 2 sur la durée de la sauvegarde.

Conclusion

Contrairement à la fonctionnalité de « flashback log », la mise en place du bloc change tracking n’a pas d’incidence sur les performances de la base de données. La diminution d’un facteur de plus de 2 de la durée de la sauvegarde lui donne tout son intérêt pour une stratégie utilisant les incréments.
Je vous encourage donc à ne pas hésiter à utiliser cette fonctionnalité pour diminuer vos fenêtres d’exploitation.  Attention cependant  à ne pas tomber dans le cas signalé par Alex sur une successsion d’incrément de plus de 8 jours (valeur  par défaut du paramètre _bct_bitmap_per_file). Comme d’habitude faites moi un retour de vos expériences !