Overblog
Editer l'article Suivre ce blog Administration + Créer mon blog

LAMI DBA

 

Hello,


Le mois de juin débute comme il a terminé, c'est à dire sur le sujet "Dataguard".
Dans l'article précédent "http://www.lami-dba.com/2018/05/dataguard-configuration.html" nous avions abordé la configuration que j'avais qualifié "à l'ancienne".


Dans cet article, j'avais volontairement omis de parler du paramètre STANDBY_FILE_MANAGEMENT et pour cause... cela me donne l'occasion de le faire aujourd'hui en ce début de mois juin pluvieux.
Ce paramètre va influer sur la création de fichiers (datafile) sur la / les standby et peut prendre deux valeurs

  • MANUAL (valeur par défaut)
  • AUTO

Dans ma configuration, j'avais donc laissé la valeur par défaut (MANUAL). Que se passe t-il si j'ajoute un datafile sur ma base primaire.... let's go !

 

SQL>
SQL> alter tablespace USERS add datafile '/u04/oradata/rastadb/myfile04.dbf' size 20m;

Tablespace altered.

SQL>


SQL> alter system switch logfile;

System altered.

SQL> /


Remarque : Dans le mesure ou pour le moment je n'ai toujours pas crée & parlé des standby redo, une fois mon "alter tablespace effectué", je force un switch logfile pour propager la commande sur la base standby.
Et la patatra... le process mrp tombe (je le sais, car dans un environnement dg, ca peut être utile de monitorer ce process)
Un coup d'oeil dans l'alert log confirme tout cela.

 

File #13 added to control file as 'UNNAMED00013' because
the parameter STANDBY_FILE_MANAGEMENT is set to MANUAL
The file should be manually created to continue.
Errors with log /u01/app/oracle/product/12.2.0/db_1/dbs/use_db_recovery_file_dest,1_340_964979058.dbf
MRP0: Background Media Recovery terminated with error 1274
2018-06-05T09:18:44.363466+02:00
Errors in file /u01/app/oracle/diag/rdbms/rastastby/rastadb/trace/rastadb_pr00_10506.trc:
ORA-01274: cannot add data file that was originally created as '/u04/oradata/rastadb/myfile04.dbf'
Recovery interrupted!
Recovery stopped due to failure in applying recovery marker (opcode 17.30).
Datafiles are recovered to a consistent state at change 8372541 but controlfile could be ahead of datafiles.
2018-06-05T09:18:44.418348+02:00
Errors in file /u01/app/oracle/diag/rdbms/rastastby/rastadb/trace/rastadb_pr00_10506.trc:
ORA-01274: cannot add data file that was originally created as '/u04/oradata/rastadb/myfile04.dbf'
2018-06-05T09:18:44.444057+02:00
Errors in file /u01/app/oracle/diag/rdbms/rastastby/rastadb/trace/rastadb_m000_12495.trc:
ORA-01110: data file 13: '/u01/app/oracle/product/12.2.0/db_1/dbs/UNNAMED00013'
ORA-01565: error in identifying file '/u01/app/oracle/product/12.2.0/db_1/dbs/UNNAMED00013'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 7

Pour celui qui veut bien s'en donner la peine, nous avons ici toutes les informations.
  1. Le nouveau datafile n'a pas pu être ajouté
  2. Car Standby_file_Management est à MANUAL
  3. MRP0 est parti en sucette & donc le "recover" est stoppé sur la standby
  4. Le nom du fichier créer sur la base primaire
  5. Le pseduo nom /u01/.../UNNAMED00013'... crée sur la standby, mais qui au final n'existe pas.

D'ailleurs coté standby, nous pouvons en avoir la confirmation.

 

SQL> select file#,error from  v$recover_file where error like '%FILE%';

     FILE# ERROR
---------- -----------------------------------------------------------------
        13 FILE MISSING

SQL>

 

Exactement ce qui a été décrit dans l'alert.log... le datafile no 13 est manquant..
Il me faut donc ajouter le datafile à la mano sur la standby, rien de bien compliqué;. suffit juste d'avoir la syntaxe.

 

SQL>
SQL> alter database create datafile '/u01/app/oracle/product/12.2.0/db_1/dbs/UNNAMED00013' as '/u04/oradata/rastadb/myfile04.dbf';

Database altered.

SQL>

 

Et voila ! ne reste plus qu'à relancer le recover sur la standby... On n'a pas oublié que l'erreur a entraîné la chute de mrp0

 

SQL>
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

Database altered.

SQL>


Et puis... tout d'un coup... Petite question saugrenue... Et si j'avais été en ASM ou OMF
Soyons fous...
sur ma base primaire.

 

SQL>
SQL> alter tablespace USERS add datafile '+DATA' size 50m;

Tablespace altered.

SQL>


SQL>
SQL> alter system switch logfile;

System altered.

SQL>


Evidemment, fallait pas s'attendre à ce que ca fonctionne mieux...
Même cause, même conséquence...

 

Media Recovery Log /u01/app/oracle/product/12.2.0/db_1/dbs/use_db_recovery_file_dest,1_350_964979058.dbf
File #14 added to control file as 'UNNAMED00014' because
the parameter STANDBY_FILE_MANAGEMENT is set to MANUAL
The file should be manually created to continue.
Errors with log /u01/app/oracle/product/12.2.0/db_1/dbs/use_db_recovery_file_dest,1_350_964979058.dbf
MRP0: Background Media Recovery terminated with error 1274
2018-06-05T09:37:36.895569+02:00
Errors in file /u01/app/oracle/diag/rdbms/rastastby/rastadb/trace/rastadb_pr00_19335.trc:
ORA-01274: cannot add data file that was originally created as '+DATA/RASTADB/DATAFILE/users.332.977996231'
Recovery interrupted!
2018-06-05T09:37:36.920543+02:00
Primary database is in MAXIMUM PERFORMANCE mode
2018-06-05T09:37:36.958446+02:00
Errors in file /u01/app/oracle/diag/rdbms/rastastby/rastadb/trace/rastadb_m000_20107.trc:
ORA-01110: data file 1: '+DATA/RASTASTBY/DATAFILE/system.301.976829217'
2018-06-05T09:37:36.961513+02:00
Recovery stopped due to failure in applying recovery marker (opcode 17.30).
Datafiles are recovered to a consistent state at change 8375485 but controlfile could be ahead of datafiles.
2018-06-05T09:37:36.963087+02:00


Et donc même solution...

 

SQL>
SQL> alter database create datafile '/u01/app/oracle/product/12.2.0/db_1/dbs/UNNAMED00014' as '+DATA/RASTADB/DATAFILE/users.332.977996231';
alter database create datafile '/u01/app/oracle/product/12.2.0/db_1/dbs/UNNAMED00014' as '+DATA/RASTADB/DATAFILE/users.332.977996231'
*
ERROR at line 1:
ORA-01276: Cannot add file +DATA/RASTADB/DATAFILE/users.332.977996231.  File
has an Oracle Managed Files file name.


Et bien non ! On le sait ASM gère lui même les noms des fichiers... donc pourquoi sur ma standby je voudrai le nommer.... Rien de bien méchant... la syntaxe est juste un peu différente.

 

SQL>
SQL> alter database create datafile '/u01/app/oracle/product/12.2.0/db_1/dbs/UNNAMED00014' as new;

Database altered.

SQL>

 

Une nouvelle fois, ne reste plus qu'à redémarrer mrp et vérifier que tout fonctionne ;)

En conclusion, j'ai envie de dire que si il n'y a pas de contre indications du médecin en chef, autant s'éviter ce genre de soucis en initialisant STANDBY_FILE_MANAGEMENT à la valeur AUTO.... 

Remarque : Pour ne plus avoir de soucis, c'est sur la / les standby qu'il faut effectuer  la modification. Mais dans les faits, autant le faire également sur la base primaire... Qui sait un jour son rôle changera, et elle deviendra Standby...

Enjoy !

 

 

commentaires

KUASSIA M. BRICE H. 27/09/2018 13:14

Merci beaucoup pour vos tutos.
Ces doses d'humour qui les accompagnent stimulent...
Merci.

Articles autour des SGBD Oracle, SQL Server & PostgreSQL

A propos de LAMI-DBA

Le Blog LAMI-DBA est la fusion de deux blogs existants, celui de LAurent (laodba) et celui de MIckael (dbafaq), deux DBA passionnés des sgbd, et particulièrement d'Oracle.

 

Laurent, 47 ans, Expert Oracle & MS SQL Server, Team Leader, dit "Le Taz", Certifié Expert RAC 11G, Exadata Implementation Specialist, OCA 11G, 

Profil Linkdin

 

 

 

Mickael, 37 ans, Expert Oracle, dit "Batman", Certifié Expert RAC 11G, OCP 11G, OCP 10G,

Profil Linkdin      

 

Hébergé par Overblog