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

LAMI DBA

Hello,

La 12c apporte a apporté son lot de nouveautés. Et parmi celles-ci, on en trouve une au niveau du broker. Et c'est de celle-ci dont je voulais parler initialement : Validate Database: Une commande bien pratique qui nous donne un état à un instant t, et dont il est judicieux de regarder le résultat avant un "switchover". Pour rappel, ci-dessous ma configuration.

DGMGRL>
DGMGRL> show configuration

Configuration - mapogos

  Protection Mode: MaxAvailability
  Members:
  rastadb   - Primary database
    rastastby - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS   (status updated 14 seconds ago)

DGMGRL>


Donc avant un switchover, je vais lancer la commande en question (validate database) d'abord sur ma base primaire.

DGMGRL>
DGMGRL> validate database rastadb

  Database Role:    Primary database

  Ready for Switchover:  Yes

  Managed by Clusterware:
    rastadb:  YES

DGMGRL>


Tout semble ok, passons maintenant à la standby.

DGMGRL> validate database rastastby

  Database Role:     Physical standby database
  Primary Database:  rastadb

  Ready for Switchover:  Yes
  Ready for Failover:    Yes (Primary Running)

  Flashback Database Status:
    rastadb  :  On
    rastastby:  Off

  Managed by Clusterware:
    rastadb  :  YES
    rastastby:  YES

  Current Log File Groups Configuration:
    Thread #  Online Redo Log Groups  Standby Redo Log Groups Status
              (rastadb)               (rastastby)
    1         3                       3                       Insufficient SRLs

  Future Log File Groups Configuration:
    Thread #  Online Redo Log Groups  Standby Redo Log Groups Status
              (rastastby)             (rastadb)
    1         3                       2                       Insufficient SRLs

 

Bien que que ma standby soit marquée "Ready for Switchover", je constate que la commande me retourne une erreur sur les Standby Redo Log... et plus étrange encore, il n'y en aurait pas assez. La documentation oracle indique, que les Standby Redo doivent avoir la même taille que les redo, et qu'il doit y env avoir au moins un de plus que les redos. Dans le cas présent, j'ai 3 groupes de redo (de taille 200 Mo), et j'avais fait du zèle en créant 2 Standby Redo de plus soit 5 au total.. 

 

Vérifons d'abord sur ma base primaire.

SQL> select instance_name from v$instance;

INSTANCE_NAME
----------------
rastadb

SQL>
SQL>
SQL> select thread#, group#, sequence#, status, bytes/1024/1024 as "size (MO)" from v$standby_log;

   THREAD#     GROUP#  SEQUENCE# STATUS      size (MO)
----------     ------  --------- ----------  ----------
         1        4        0     UNASSIGNED    200
         1        5        0     UNASSIGNED    200
         0        6        0     UNASSIGNED    200
         0        7        0     UNASSIGNED    200
         0        8        0     UNASSIGNED    200

SQL>


J'ai bien 5 groupes et de taille identique à mes redos. Vérifions maintenant sur la standby. 

SQL> select instance_name from v$instance;

INSTANCE_NAME
----------------
rastastby

SQL>
SQL> select thread#, group#, sequence#, status, bytes/1024/1024 as "size (MO)" from v$standby_log;

   THREAD#     GROUP#  SEQUENCE# STATUS      size (MO)
 ----------    ------  --------  -------    ----------
         1        4       0      UNASSIGNED     200
         1        5      151     ACTIVE         200
         1        6       0      UNASSIGNED     200
         0        7       0      UNASSIGNED     200
         0        8       0      UNASSIGNED     200


Idem, 5 groupes de taille identique. Cependant, il est évident que j'avais du consommé quelque chose au moment de leur création puisque sur ma primaire j'en ai trois avec un numéro de thread à 0 et deux sur la standby dans ca cas... Ce qui a au moins le mérite d'être cohérent avec le resultat de la commande "Validate Database ..."

Histoire de retrouver un situation "normale", je vais supprimer les SRL sur la primaire et la standby dont le thread est à 0 (à quand le thread negatif ;) ) et les recréer. Etant fainéant, le groupe 8 ne sera pas recrée. Cependant avec 4 groupes de SRL, je reste dans les clous (la fameuse règle des nb. de redo +1.

Evidemment avant de faire cela, je vais stopper l'apply sur la base standby.

DGMGRL> 
DGMGRL>
DGMGRL> edit database rastastby set state='APPLY-OFF';
Succeeded.
DGMGRL>


Ceci étant fait.. on peut y aller...
Sur la primaire:

SQL>
SQL> alter database drop standby logfile group 7;

Database altered.

SQL> alter database drop standby logfile group 8;

Database altered.

SQL> alter database drop standby logfile group 6;

Database altered.


Et on les récrée en précisant le thread.

SQL> alter database add standby logfile thread 1 group 6 size 200m;

Database altered.


SQL> alter database add standby logfile thread 1 group 7 size 200m;

Database altered.


Même chose sur la standby au groupe prés.

SQL>
SQL> alter database drop standby logfile group 7;

Database altered.

SQL> alter database drop standby logfile group 8;

Database altered.

SQL> alter database add standby logfile thread 1 group 6 size 200m;

Database altered.


SQL> alter database add standby logfile thread 1 group 7 size 200m;

Database altered.


Après ces modifications, une petite vérifications s'impose.
Sur ma standby.

SQL>
SQL> select thread#, group#, sequence#, status, bytes/1024/1024 as "size (MO)" from v$standby_log;

   THREAD#     GROUP#  SEQUENCE# STATUS         size (MO)
 ----------  -------- ---------- ------        ----------
         1       4        0      UNASSIGNED        200
         1       5       151     ACTIVE            200
         1       6        0      UNASSIGNED        200
         1       7        0      UNASSIGNED        200

 

Puis sur la primaire.

 

SQL> select thread#, group#, sequence#, status, bytes/1024/1024 as "size (MO)" from v$standby_log;

   THREAD#     GROUP#  SEQUENCE# STATUS          size (MO)
  ---------  -------   --------  --------        ----------
         1       4          0    UNASSIGNED        200
         1       5          0    UNASSIGNED        200
         1       6          0    UNASSIGNED        200
         1       7          0    UNASSIGNED        200


On peut relancer un validate sur la standby

DGMGRL> validate database rastastby

  Database Role:     Physical standby database
  Primary Database:  rastadb

  Ready for Switchover:  No
  Ready for Failover:    Yes (Primary Running)

  Flashback Database Status:
    rastadb  :  On
    rastastby:  On

  Managed by Clusterware:
    rastadb  :  YES
    rastastby:  YES

  Standby Apply-Related Information:
    Apply State:      Not Running
    Apply Lag:        10 minutes (computed 0 seconds ago)
    Apply Delay:      0 minutes

DGMGRL>


volontairement, je n'avais pas réactivé l'apply .Ce qui permet de constater que si necessaire le "Validate Database" nous indiquera que tenter un switchover n'est pas une bonne idée. Réactivons donc l'apply.

 

DGMGRL>
DGMGRL> edit database rastastby set state='APPLY-ON';
Succeeded.

 

Et sauf malédiction, cette fois-ci, nous devons être bon !

 

DGMGRL>
DGMGRL> validate database rastastby

  Database Role:     Physical standby database
  Primary Database:  rastadb

  Ready for Switchover:  Yes
  Ready for Failover:    Yes (Primary Running)

  Flashback Database Status:
    rastadb  :  On
    rastastby:  On

  Managed by Clusterware:
    rastadb  :  YES
    rastastby:  YES

DGMGRL>

 

Yes !! ... Prêt pour un switchover ;)
A savoir également, que l'on peu ajouter la clause "verbose" à la commande si l'on désire un peu plus d'informations. Qui a dit que le broker n'était pas verbeux ;)

 

DGMGRL> validate database verbose rastastby



  Database Role:     Physical standby database
  Primary Database:  rastadb

  Ready for Switchover:  Yes
  Ready for Failover:    Yes (Primary Running)

  Flashback Database Status:
    rastadb  :  On
    rastastby:  On

  Capacity Information:
    Database   Instances        Threads
    rastadb    1                1
    rastastby  1                1

  Managed by Clusterware:
    rastadb  :  YES
    rastastby:  YES

  Temporary Tablespace File Information:
    rastadb TEMP Files:    1
    rastastby TEMP Files:  1

  Data file Online Move in Progress:
    rastadb:    No
    rastastby:  No

  Standby Apply-Related Information:
    Apply State:      Running
    Apply Lag:        0 seconds (computed 0 seconds ago)
    Apply Delay:      0 minutes

  Transport-Related Information:
    Transport On:      Yes
    Gap Status:        No Gap
    Transport Lag:     0 seconds (computed 0 seconds ago)
    Transport Status:  Success

  Log Files Cleared:
    rastadb Standby Redo Log Files:    Cleared
    rastastby Online Redo Log Files:   Cleared
    rastastby Standby Redo Log Files:  Available

  Current Log File Groups Configuration:
    Thread #  Online Redo Log Groups  Standby Redo Log Groups Status
              (rastadb)               (rastastby)
    1         3                       4                       Sufficient SRLs

  Future Log File Groups Configuration:
    Thread #  Online Redo Log Groups  Standby Redo Log Groups Status
              (rastastby)             (rastadb)
    1         3                       4                       Sufficient SRLs

  Current Configuration Log File Sizes:
    Thread #   Smallest Online Redo      Smallest Standby Redo
               Log File Size             Log File Size
               (rastadb)                 (rastastby)
    1          200 MBytes                200 MBytes

  Future Configuration Log File Sizes:
    Thread #   Smallest Online Redo      Smallest Standby Redo
               Log File Size             Log File Size
               (rastastby)               (rastadb)
    1          200 MBytes                200 MBytes

  Apply-Related Property Settings:
    Property                        rastadb Value            rastastby Value
    DelayMins                       0                        0
    ApplyParallel                   AUTO                     AUTO
    ApplyInstances                  0                        0

  Transport-Related Property Settings:
    Property                        rastadb Value            rastastby Value
    LogXptMode                      SYNC                     SYNC
    Dependency                      <empty>                  <empty>
    DelayMins                       0                        0
    Binding                         optional                 optional
    MaxFailure                      0                        0
    MaxConnections                  1                        1
    ReopenSecs                      300                      300
    NetTimeout                      30                       30
    RedoCompression                 DISABLE                  DISABLE
    LogShipping                     ON                       ON

  Automatic Diagnostic Repository Errors:
    Error                       rastadb  rastastby
    No logging operation        NO       NO
    Control file corruptions    NO       NO
    SRL Group Unavailable       NO       NO
    System data file missing    NO       NO
    System data file corrupted  NO       NO
    System data file offline    NO       NO
    User data file missing      NO       NO
    User data file corrupted    NO       NO
    User data file offline      NO       NO
    Block Corruptions found     NO       NO

DGMGRL>


Enjoy.


 

 

 

commentaires

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