Quelqu’un qui se reconnaitra m’a posé une question très instructive à propos de la clause RMAN 11g « FOR DB_UNIQUE_NAME ». Il s’agissait de savoir si, du fait de cette nouvelle syntaxe, on pouvait, sans se connecter aux standbys supprimer les archivelogs sur tous les serveurs d’une configuration Data Guard.
La question est intéressante, surtout si on fait évoluer très souvent ses environnements standby comme c’est parfois le cas pour des migrations ou des tests. Pour ne pas faire durer le suspense, la réponse un NON assez catégorique (à moins de construire une petite usine évidemment mais ce n’a jamais été mon état d’esprit). Et pourtant, on peut effectivement supprimer les archivelogs des standbys avec la commande "delete archivelog [...] for db_unique_name [...]" dans certains cas. Il reste que les limites et les effets de bords sont trop importants. Cet article explique et illustre à travers quelques tests pourquoi.
Notes:
Evidemment, les choses évolueront à n’en pas douter. Le contexte décrit ci-dessous est celui une base de données 11.2.0.2 (ou 11g en général). On considère qu’on utilise un catalogue RMAN et on ne parle pas de la syntaxedelete obsoletequi ne supporte pas la-dite clause. Pour l’instant, il est toujours possible de lancer tous les scripts sur la standby en utilisant un alias réseau dans la connexion à la cible avec la commandeconnect target
Les raisons pour lesquelles je dis qu’il ne faut pas utiliser la commande delete archivelog for db_unique_name sont les suivantes :
- Il faut pouvoir accéder aux fichiers de sauvegarde et d’archivelogs depuis les instances de la base de données primaire
- La commande ne vérifie pas les règles d’intégrité; elle efface les fichiers même si ceux-ci n’ont pas été appliqués sur la standby
- Le controlfile de la base standby n’est pas mis à jour
- Le catalogue RMAN n’est pas mis à jour lors de la génération d’un nouvel archivelog mais lors d’une synchronisation avec une commande RMAN connectée au controlfile de la standby
Pouvoir accéder aux fichiers depuis le site primaire
D’abord pour que la commande fonctionne, il faut pouvoir allouer un canal RMAN qui accède aux fichiers que vous voulez supprimer depuis la base cible (target). C’est une contrainte qui me parait assez forte dans un contexte de plan de reprise d’activité avec des sites multiples d’autant que le service de log transport permet en particulier de ne pas avoir de partage disque. Alors bien sur, c’est faisable avec un NAS. Bien sur, il est conseillé Media Manager répliqué ou distribué pour pouvoir accéder aux sauvegardes bande (ou VTL). Cela dit dans l’ensemble si on utilise Data Guard ce n’est pas pour s’obliger les archivelogs sur disque entre les sites… Pour vous en persuader, voici un test effectué sur un standby sans partage disque ; ma primaire est BLACK et la standby WHITE :
$ rman target / catalog rman/rman@red:1521/BLACK
Recovery Manager: Release 11.2.0.2.0 - Production on Thu Jan 6 11:57:27 2011
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
connected to target database: BLACK (DBID=418538745)
connected to recovery catalog database
RMAN> list archivelog all for db_unique_name white;
List of Archived Log Copies for database with db_unique_name WHITE
=====================================================================
Key Thrd Seq S Low Time
------- ---- ------- - ---------
421 1 26 A 06-JAN-11
Name: /u01/app/oracle/oradata/WHITE/archivelog/1_26_738076603.dbf
RMAN> delete archivelog sequence 26 for db_unique_name white;
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=151 device type=DISK
List of Archived Log Copies for database with db_unique_name WHITE
=====================================================================
Key Thrd Seq S Low Time
------- ---- ------- - ---------
421 1 26 A 06-JAN-11
Name: /u01/app/oracle/oradata/WHITE/archivelog/1_26_738076603.dbf
Do you really want to delete the above objects (enter YES or NO)? YES
RMAN-06207: WARNING: 1 objects could not be deleted for DISK channel(s) due
RMAN-06208: to mismatched status. Use CROSSCHECK command to fix status
RMAN-06210: List of Mismatched objects
RMAN-06211: ==========================
RMAN-06212: Object Type Filename/Handle
RMAN-06213: --------------- ---------------------------------------------------
RMAN-06214: Archivelog /u01/app/oracle/oradata/WHITE/archivelog/1_26_738076603.dbf
Pas de vérification des règles d’intégrités sur la standby
Imaginons maintenant que la base primaire a un accès (via NFS par exemple aux fichiers de la standby; quand on lances la commande « delete archivelog all » sur la standby, la commande vérifie que les fichiers sont appliqués pour les supprimer. J’ai arrêté l’apply et vous le constatez ici :
$ rman target / catalog rman/rman@red:1521/BLACK
Recovery Manager: Release 11.2.0.2.0 - Production on Thu Jan 6 12:03:49 2011
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
connected to target database: BLACK (DBID=418538745, not open)
connected to recovery catalog database
RMAN> delete archivelog all;
released channel: ORA_DISK_1
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=18 device type=DISK
RMAN-08120: WARNING: archived log not deleted, not yet applied by standby
archived log file name=/u01/app/oracle/oradata/WHITE/archivelog/1_27_738076603.dbf thread=1 sequence=27
RMAN-08120: WARNING: archived log not deleted, not yet applied by standby
archived log file name=/u01/app/oracle/oradata/WHITE/archivelog/1_28_738076603.dbf thread=1 sequence=28
Si on effectue la même opération sur la base primaire, ceci malgré la politique de rétention des archivelogs, le résultat est intéressant :
$ rman target / catalog rman/rman@red:1521/BLACK
Recovery Manager: Release 11.2.0.2.0 - Production on Thu Jan 6 12:06:35 2011
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
connected to target database: BLACK (DBID=418538745)
connected to recovery catalog database
RMAN> show ARCHIVELOG DELETION POLICY;
RMAN configuration parameters for database with db_unique_name BLACK are:
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;
RMAN> delete archivelog all for db_unique_name WHITE;
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=147 device type=DISK
List of Archived Log Copies for database with db_unique_name WHITE
=====================================================================
Key Thrd Seq S Low Time
------- ---- ------- - ---------
471 1 27 A 06-JAN-11
Name: /u01/app/oracle/oradata/WHITE/archivelog/1_27_738076603.dbf
472 1 28 A 06-JAN-11
Name: /u01/app/oracle/oradata/WHITE/archivelog/1_28_738076603.dbf
Do you really want to delete the above objects (enter YES or NO)? YES
deleted archived log
archived log file name=/u01/app/oracle/oradata/WHITE/archivelog/1_27_738076603.dbf RECID=18 STAMP=739713312
deleted archived log
archived log file name=/u01/app/oracle/oradata/WHITE/archivelog/1_28_738076603.dbf RECID=19 STAMP=739713319
Deleted 2 objects
Evidemment, vous me direz si on redémarre l’apply sur la standby, les archivelog sont resynchronisés, mais bon…
Le controlfile de la standby n’est pas mis à jours
Ca parait logique mais comme dit un de mes bons amis, c’est mie
ux en le disant ; le controlfile de la standby n’est en outre pas mis à jour; on a bien effacé les 2 fichiers mais la standby n’est pas au courant (connectez-vous sans catalogue) :
$ rman target / nocatalog
Recovery Manager: Release 11.2.0.2.0 - Production on Thu Jan 6 12:10:40 2011
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
connected to target database: BLACK (DBID=418538745, not open)
RMAN> delete archivelog all;
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=17 device type=DISK
RMAN-08120: WARNING: archived log not deleted, not yet applied by standby
archived log file name=/u01/app/oracle/oradata/WHITE/archivelog/1_27_738076603.dbf thread=1 sequence=27
RMAN-08120: WARNING: archived log not deleted, not yet applied by standby
archived log file name=/u01/app/oracle/oradata/WHITE/archivelog/1_28_738076603.dbf thread=1 sequence=28
Par contre si on utilise le catalogue, les fichiers ont bien disparus :
oracle@red:/u01/app/oracle/oradata/WHITE/archivelog$ rman target / catalog rman/rman@red:1521/BLACK
Recovery Manager: Release 11.2.0.2.0 - Production on Thu Jan 6 12:14:11 2011
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
connected to target database: BLACK (DBID=418538745, not open)
connected to recovery catalog database
RMAN> list archivelog all;
specification does not match any archived log in the repository
Imaginons que la standby soit en lecture seule lorsqu’on perd le site primaire et que le catalogue soit sur ce site…
Le catalogue n’est pas notifié de nouveaux archivelogs sur la standby automatiquement
Mais LA raison qui vous empêchera à coup sur d’utiliser cette pratique (sans construire une usine à gaz), c’est que le catalogue n’est mis à jour que lorsqu’il est synchronisé avec RMAN; comme vous allez le voir ci-dessous; je redémarre l’apply :
Le catalog n’est pas mis à jour avec les archivelog s’il n’y a pas de connexions RMAN
Pire, si tu le te connectes pas à la standby, le catalogue n’est pas synchronisé et les archivelogs de la standby ne sont pas mis à jour (au moins dans le cas ou les archivelogs sont archivées par ARCH depuis des standby redo log :
rman target / catalog rman/rman@red:1521/BLACK
Recovery Manager: Release 11.2.0.2.0 - Production on Thu Jan 6 12:20:11 2011
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
connected to target database: BLACK (DBID=418538745)
connected to recovery catalog database
RMAN> list archivelog all for db_unique_name white;
specification does not match any archived log in the repository
RMAN> sql 'alter system archive log current';
sql statement: alter system archive log current
# Attendez autant que vous voulez
# ET laissez 2 lignes vides après votre commentaire
RMAN> list archivelog all for db_unique_name white;
specification does not match any archived log in the repository
Et pourtant, si vous vérifiez sur la base standby en vous connectant au catalogue, ils sont là ; c’est parce que le catalog est synchronisé lors de la connexion à la cible et au catalogue :
$ rman target / catalog rman/rman@red:1521/BLACK
Recovery Manager: Release 11.2.0.2.0 - Production on Thu Jan 6 12:23:04 2011
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
connected to target database: BLACK (DBID=418538745, not open)
connected to recovery catalog database
RMAN> list archivelog all;
List of Archived Log Copies for database with db_unique_name WHITE
=====================================================================
Key Thrd Seq S Low Time
------- ---- ------- - ---------
521 1 29 A 06-JAN-11
Name: /u01/app/oracle/oradata/WHITE/archivelog/1_29_738076603.dbf
522 1 30 A 06-JAN-11
Name: /u01/app/oracle/oradata/WHITE/archivelog/1_30_738076603.dbf
Vous pourrez vous en rendre compte en vous reconnectant à la base de données primaire et au catalogue; les fichiers apparaissent uniquement à ce moment là…
Conclusion
On comprend mieux pourquoi la commande « crosscheck for db_unique_name » n’est pas implémentée. On pourrait imaginer assez simplement des scénarios d’utilisations où on dé-cataloguerait les archivelogs par inadvertance. Je l’ai déjà vu avec un cluster alors avec 2 sites ! La commande est intéressante dans certains cas où on constitue des bases de tests avec le même DBID (ou peut-être dans le cas de la nouvelle CLONEDB disponible avec la version 11.2.0.2). Je ne doute pas qu’il y a des cas où elle s’avèrera utile ; enfin tout ça montre qu’il fait garder un peu de discernement.
