Voici le second article de la série de trois sur les benchs et l’outil swingbench,  le premier que vous pouvez retrouver ici, décrivait l’outil, son installation, son paramétrage et son utilisation.
Celui-ci va vous montrer les résultats produits dans le cadre de la mesure de l’impact de la fonctionnalité flashback sur les performances.
Le dernier, qui sera plus tardif au vue de mon agenda, concernera la fonctionnalité de “block change tracking” lors de l’utilisation d’une stratégie de sauvegarde incrémentale avec RMAN.
Je rappelle d’abord ici les principes de la fonctionnalité “flashback database”, avant de faire différents tests : l’un sans l’activation de la fonctionnalité, qui nous servira de référence, l’autre (voire les autres) avec sa mise en œuvre.  Ceci  afin de mesurer  l’impact sur les performances ainsi que les contraintes de volumétrie que cela induit, ce qui vous permettra j’espère d’avoir quelques éléments pour décider de l’activer ou non  sur votre propre base de données.

Rewind Database

Cette fonctionnalité présente depuis les premières versions 10G permet de remettre les données de la base dans un état antérieur, soit en précisant une date, soit en précisant un numéro de transaction (SCN) , soit jusqu’à un point de reprise précédemment déclaré.
Une fois cette fonction activée, l’image avant des blocs modifiés dans le cache des données est copiée dans une zone mémoire dédiée, puis écrite périodiquement et séquentiellement par un nouveau processus d’arrière plan nommé RVWR dans un fichier spécifique (flashback log) localisé dans la zone FRA (Flash Recovery Area) .  La gestion des  fichiers « flashback  log » est entièrement faite par le moteur, mais il reste pour nous les DBA à gérer l’espace pris par ces fichiers, qui va dépendre directement de la durée de  rétention souhaitée pour les informations.
Voici quelques exemples de commandes sous SQL*PLUS ou sous RMAN qui permettent l’opération de “rewind“ des données:

SQL>FLASHBACK DATABASE TO TIMESTAMP(SYSDATE-1/24);
SQL>FLASHBACK DATABASE TO SCN 53943;
SQL>FLASHBACK DATABASE TO RESTORE POINT b4_load;
RMAN>FLASHBACK DATABASE TO TIME=TO_DATE('2004-05-27 16:00:00','YYYY-MM-DD HH24:MI:SS');
RMAN>FLASHBACK DATABASE TO SCN=23565;

Une fois l’opération terminée, il faut bien entendu ouvrir la base via une commande  de type “OPEN RESETLOGS” .
La déclaration de la rétention se fait au travers du paramètre DB_FLASH_RETENTION_TARGET en précisant une valeur en minute,  le défaut étant de 2880 minutes (2 jours).
L’activation ce fait en mode « mount », donc base arrêtée au préalable, par la commande:

SQL> alter database flashback on;

On ouvre ensuite normalement la base:

SQL> alter database open

On peut vérifier le résultat de l’activation au travers de la colonne FLASHBACK_ON de la vue v$database

SQL> select flashback_on from v$database ;
FLASHBACK_ON
------------------
YES

L’usage combiné de points de restauration intelligemment placés et des informations de flashback permet de remettre très rapidement la base dans un état fonctionnel après par exemple le passage d’un batch indélicat. Il semble très intéressant  de l’intégrer dans les procédures d’exploitation, à condition que l’impact ne soit pas trop pénalisant pour les performances, c’est ce que nous allons voir  maintenant.

Etalonnage et référence

La première étape de mon test consiste à dérouler le scénario “order entry” de swingbench sur une base Enterprise Edition 11.1.0.7 sous OEL 5.3. Cette base est en archivelog mais n’utilise ni la fonctionnalité de flashback ni celle du “change block tracking”. Le test utilise 15 connexions utilisateurs, il déclenche les 5 transactions comprises dans le scenario avec la même répartition pour chacune.  La durée totale du tir  est de 15 minutes, avec une prise des statistiques internes sur une période de 10 minutes , 3 minutes après le démarrage.
Bien évidemment, 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.
Pendant le test 334 Mo de fichiers d’archive log ont été générés.
Le graphique montre les résultats dans la configuration archivelog uniquement:

Voici aussi un extrait du fichier xml contenant le résumé des résultats, pour que vous vous rendiez compte de sa forme et de son contenu:

<Results xmlns="http://www.dominicgiles.com/swingbench">
<Overview>
<BenchmarkName>"Order Entry (PLSQL)"</BenchmarkName>
<Comment>""</Comment>
<TimeOfRun>6 avr. 2010 12:11:56</TimeOfRun>
<TotalRunTime>0:10:00</TotalRunTime>
<TotalLogonTime>0:00:31</TotalLogonTime>
<TotalCompletedTransactions>68951</TotalCompletedTransactions>
<TotalFailedTransactions>0</TotalFailedTransactions>
<AverageTransactionsPerSecond>114.92</AverageTransactionsPerSecond>
<MaximumTransactionRate>7139</MaximumTransactionRate>
</Overview>
<Configuration>
<NumberOfUsers>15</NumberOfUsers>
<MinimumThinkTime>10</MinimumThinkTime>
<MaximumThinkTime>20</MaximumThinkTime>
<ConnectString>//192.nnnn.nnnn.nnnn:1523/EASY11</ConnectString>
<TimingsIn>miliseconds</TimingsIn>
</Configuration>
<DMLResults>
<SelectStatements>234619</SelectStatements>
<InsertStatements>131165</InsertStatements>
<UpdateStatements>76634</UpdateStatements>
<DeleteStatements>0</DeleteStatements>
<CommitStatements>96700</CommitStatements>
<RollbackStatements>10</RollbackStatements>
</DMLResults>
<TransactionResults>
<Result id="Customer Registration">
<AverageResponse>64</AverageResponse>
<MinimumResponse>2</MinimumResponse>
<MaximumResponse>862</MaximumResponse>
<TransactionCount>13666</TransactionCount>
<FailedTransactionCount>0</FailedTransactionCount>
</Result>
<Result id="Browse Products">
<AverageResponse>26</AverageResponse>
<MinimumResponse>1</MinimumResponse>
<MaximumResponse>1088</MaximumResponse>
<TransactionCount>13707</TransactionCount>
<FailedTransactionCount>0</FailedTransactionCount>
</Result>
<Result id="Order Products">
<AverageResponse>87</AverageResponse>
<MinimumResponse>1</MinimumResponse>
<MaximumResponse>1573</MaximumResponse>
<TransactionCount>13826</TransactionCount>
<FailedTransactionCount>0</FailedTransactionCount>
</Result>
<Result id="Process Orders">
<AverageResponse>33</AverageResponse>
<MinimumResponse>1</MinimumResponse>
<MaximumResponse>850</MaximumResponse>
<TransactionCount>13335</TransactionCount>
<FailedTransactionCount>0</FailedTransactionCount>
</Result>
<Result id="Browse Orders">
<AverageResponse>36</AverageResponse>
<MinimumResponse>1</MinimumResponse>
<MaximumResponse>646</MaximumResponse>
<TransactionCount>13976</TransactionCount>
<FailedTransactionCount>0</FailedTransactionCount>
</Result>
</TransactionResults>

On trouve à la suite les résultats de 139 statistiques internes de la base de données pendant la période de test (delta entre les valeurs de début et de fin), sous la forme

<DatabaseStatistics>
<DatabaseStatistic name="commit immediate requested" value="74"/>
<DatabaseStatistic name="physical read total IO requests" value="155797"/>
<DatabaseStatistic name="CPU used by this session" value="14182"/>
…
</DatabaseStatistics>
</Results>

Voici un tableau présentant les résultats avec les 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.

Utilisation du flashback

La mise en place est la suivante :

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
Total System Global Area  322228224 bytes
Fixed Size                  1313148 bytes
Variable Size             197133956 bytes
Database Buffers          117440512 bytes
Redo Buffers                6340608 bytes
Database mounted.
SQL> select flashback_on from v$database ;
FLASHBACK_ON
------------------
NO
SQL> alter database flashback on;
Database altered.
SQL> select flashback_on from v$database ;
FLASHBACK_ON
------------------
YES

Une fois le mode flashback enclenché, l’exécution du même scénario “order entry”, dans les mêmes conditions,  génère:

• autant de fichiers d’archives log (334Mo)
• quasiment deux fois plus de fichiers flashback logs (549 Mo )
• 66 fichiers flashback logs, 64 fichier de 8Mo puis 1 de 16Mo et un de 32Mo; le moteur adapte la taille en fonction du taux de génération

Le graphique des résultats est maintenant  le suivant :

Voici le tableau récapitulatif :

Il y a donc une dérive moyenne de 4% sur la durée des transaction,  plus ou moins accentuée selon la typologie de l’action, avec jusqu’à près de 8% pour l’enregistrement du client (Customer registration).
Pour assurer une bonne répétabilité, j’ai refait les tirs plusieurs fois pour arriver à un impact moyen  compris chaque fois entre 4 et 6 %.
Bien sur celui-ci va dépendre principalement de votre configuration disque, le même type d’essai en utilisant un laptop avec les fichiers de la base sur un disque externe USB2 donne un impact de plus de 20% sur les performances.

Conclusion

Si vous n’êtes pas déjà saturé au niveau des entrées/sorties  vers la zone FRA (Flash Recovery Area) , que vous disposez de suffisamment de place disque (prévoir deux fois l’espace nécessaire pour les archivelogs pendant la durée de rétention) et que vous admettez une diminution potentielle des performances de 4 à 6%,  la fonctionnalité de flashback database est pour vous.
Elle vous permettra de vous assurez de pouvoir faire revenir rapidement votre base de données à n’importer quel moment dans le temps, ce jusqu’à la période de rétention prévue. Vous affranchissant de toutes les erreurs utilisateurs qui peuvent être commises et pour lesquelles vous auriez du réaliser une restauration. De plus, combinée à une base de secours (en utilisant la fonctionnalité Dataguard) , elle vous apportera beaucoup de souplesse dans la réinitialisation –réinstantiation – des bases après les opérations de bascule.
Voici pour finir un exemple de séquence de retour arrière qui démontre la simplicité des opérations, le point de restauration nommé “swing” avait été créé avant le passage des tests :
Arrêt de la base, démarrage en mode mount, retour arrière et réouverture :

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
Total System Global Area 322228224 bytes
Fixed Size 1313148 bytes
Variable Size 197133956 bytes
Database Buffers 117440512 bytes
Redo Buffers 6340608 bytes
Database mounted.
SQL> flashback database to restore point swing ;
SQL> alter database open resetlogs ;
Database altered.
Flashback complete.

Avec la trace générée dans le fichier d’alert:

2010-04-06 11:45:24.291000 -04:00
flashback database to restore point swing
Flashback Restore Start
2010-04-06 11:47:36.366000 -04:00
Flashback Restore Complete
Flashback Media Recovery Start
Fast Parallel Media Recovery enabled
Flashback Media Recovery Log
/u02/prod/oradata/EASY11/FRA/EASY11/archivelog/2010_04_06/o1_mf_1_206_5vpntq58_.arc
Incomplete Recovery applied until change 4801357 time 04/06/2010 11:26:20
Flashback Media Recovery Complete
2010-04-06 11:47:37.427000 -04:00
Completed: flashback database to restore point swing

Voilà c’est tout pour aujourd’hui, si vous avez fait vous même vos propres mesures et/ou si vous avez des trucs/astuces/plaintes  sur l’utilisation de la fonctionnalité  n’hésitez pas à commenter et à partager.