Comandos basicos del RAC II añadir bases de datos

Hoy vamos a seguir con la serie de entradas de comandos basicos de administracion de RAC.
Hoy vamos a centrarnos en añadir bases de datos y mover los recursos del cluster

Añadir una base de datos

Para anadir una base de datos esta tendra que tener en el init.ora los parametros

  • CLUSTER_DATABASE=TRUE
  • CLUSTER_DATABASE_INSTANCES=2
  • TEST1.INSTANCE_NUMBER=1
  • TEST2.INSTANCE_NUMBER=2
  • TEST1.THREAD=1
  • TEST2.THREAD=2
  • TEST1.UNDO_TABLESPACE=’UNDOTBS1′
  • TEST2.UNDO_TABLESPACE=’UNDOTBS2′

    or supuesto,deberemos de contar con tantos grupos de UNDO y threads de REDO como nodos vayamos a tener.
    Una vez tenemos esto, la registraremos en el crs con los comandos

    srvctl add database  -db TEST-instance IBTEST1 -spfile +DATA/TEST/spfileTEST.ora -diskgroup "DATA,FRA,REDO1,REDO2"-oraclehome $ORACLE_HOME
    srvctl add instance -d TEST-i TEST1 -n rac1.pamplona.name
    srvctl start database -db TEST
    srvctl add instance -d TEST-i TEST2 -n rac2.pamplona.name
    srvctl start  instance -db IBTES -i IBTEST2 
    

    Mas entradas para dummies sobre RAC:
    Comandos basicos en Orace RAC
    Comandos basicos del RAC II
    Eliminar un nodo del rac

  • Consultas utiles con Rman

    Hoy vamos a ver una entrada especial para dummies.
    Vamos a utilizar esta entrada para ir recopliando algunas de las consultas utiles que podemos necesitar relaccionadas con rman .
    Me gustaria decir que estas consultas son mias, pero varias de ellas han sido recopiladas a lo largo del tiempo , bien ca trabajo propio, como de casos con Oracle como de algunas webs que me han ayudado, con lo que, si alguien encuentra alguna y recooce a su propietario,e stare encantado de enlazarlo en caso que lo requiera

    Informe de los ultimos backups de rman

    set pagesize 200
    set linesize 200
    col COMMAND_ID format a20;
    col status  format a20;
    col Gb format 99999999;
     col OBJECT_TYPE format a20;
    
    Select COMMAND_ID,
    status,
    round(output_bytes /1024/1024,2)Gb ,
    start_time,end_time ,
    OBJECT_TYPE,round((end_time-start_time )*24,1) Duracion
     from v$rman_status 
    where 
    OBJECT_TYPE in ('DB FULL','DB INCR') 
    and output_bytes  > 0 
    order by start_time desc ;
    

    Ver los jobs de RMAN que ha habido

    set lines 220
    set pages 1000
    col cf for 9,999
    col df for 9,999
    col elapsed_seconds heading "ELAPSED|SECONDS"
    col i0 for 9,999
    col i1 for 9,999
    col l for 9,999
    col output_mbytes for 9,999,999 heading "OUTPUT|MBYTES"
    col session_recid for 999999 heading "SESSION|RECID"
    col session_stamp for 99999999999 heading "SESSION|STAMP"
    col status for a10 trunc
    col time_taken_display for a10 heading "TIME|TAKEN"
    col output_instance for 9999 heading "OUT|INST"
    select
      j.session_recid, j.session_stamp,
      to_char(j.start_time, 'yyyy-mm-dd hh24:mi:ss') start_time,
      to_char(j.end_time, 'yyyy-mm-dd hh24:mi:ss') end_time,
      (j.output_bytes/1024/1024) output_mbytes, j.status, j.input_type,
      decode(to_char(j.start_time, 'd'), 1, 'Sunday', 2, 'Monday',
                                         3, 'Tuesday', 4, 'Wednesday',
                                         5, 'Thursday', 6, 'Friday',
                                         7, 'Saturday') dow,
      j.elapsed_seconds, j.time_taken_display,
      x.cf, x.df, x.i0, x.i1, x.l,
      ro.inst_id output_instance
    from V$RMAN_BACKUP_JOB_DETAILS j
      left outer join (select
                         d.session_recid, d.session_stamp,
                         sum(case when d.controlfile_included = 'YES' then d.pieces else 0 end) CF,
                         sum(case when d.controlfile_included = 'NO'
                                   and d.backup_type||d.incremental_level = 'D' then d.pieces else 0 end) DF,
                         sum(case when d.backup_type||d.incremental_level = 'D0' then d.pieces else 0 end) I0,
                         sum(case when d.backup_type||d.incremental_level = 'I1' then d.pieces else 0 end) I1,
                         sum(case when d.backup_type = 'L' then d.pieces else 0 end) L
                       from
                         V$BACKUP_SET_DETAILS d
                         join V$BACKUP_SET s on s.set_stamp = d.set_stamp and s.set_count = d.set_count
                       where s.input_file_scan_only = 'NO'
                       group by d.session_recid, d.session_stamp) x
        on x.session_recid = j.session_recid and x.session_stamp = j.session_stamp
      left outer join (select o.session_recid, o.session_stamp, min(inst_id) inst_id
                       from GV$RMAN_OUTPUT o
                       group by o.session_recid, o.session_stamp)
        ro on ro.session_recid = j.session_recid and ro.session_stamp = j.session_stamp
    where j.start_time > trunc(sysdate)-&NUMBER_OF_DAYS
    order by j.start_time;
    

    Operaciones acrivas de Rman

    set linesize 200;
    set pagesize 9000;
     column STATUS FORMAT A15;
     column APPLIED FORMAT A4;
    COLUMN NAME format a20;
    column DB_UNIQUE_NAME format a20;
    COLUMN sequence# CLEAR;
    column OPEN_MODE format a10;
    column name format a100;
    col OPNAME for a40;
    set linesize 220 pagesize 10000
    col OPNAME for a40
    select OPNAME,SOFAR/TOTALWORK*100 PCT, trunc(TIME_REMAINING/60) MIN_RESTANTES,
    trunc(ELAPSED_SECONDS/60) MIN_ATEAGORA
    from v$session_longops where TOTALWORK>0 and OPNAME like '%RMAN%';
    
    
     select OPNAME,SOFAR/TOTALWORK*100 PCT, trunc(TIME_REMAINING/60) MIN_RESTANTES,
      trunc(ELAPSED_SECONDS/60) MIN_ATEAGORA
      from v$session_longops where TOTALWORK>0 and OPNAME like '%RMAN: incremental datafile%';
    

    En fin, como dije en un principio, simplemente una recopilacion de consultas utiles

    Problemas con el fichero crsgenconfig_params al intentar extender un rac

    Hoy vamos a ver un caso curioso .

    En el proceso de añadir un nodo en el rac nos encontramos con el error

    2021/02/10 20:14:04 CLSRSC-594: Executing installation step 4 of 19: 'GenSiteGUIDs'.
    oracle.ops.mgmt.cluster.ClusterException: scp: /u01/app/19c/grid/crs/install/crsgenconfig_params: No such file or directory
    
    2021/02/10 20:14:06 CLSRSC-180: An error occurred while executing the command '/u01/app/19c/grid/bin/cluutil -copy -sourcefile /u01/app/19c/grid/crs/install/crsgenconfig_params -fromnodesfile /tmp/7pqMR5nHtf -destfile /u01/app/19c/grid/crs/install/crsgenconfig_params -nodelist rac1'
    2021/02/10 20:14:06 CLSRSC-571: failed to copy file '/u01/app/19c/grid/crs/install/crsgenconfig_params' from node 'rac2' to file '/u01/app/19c/grid/crs/install/crsgenconfig_params' on local node
    Died at /u01/app/19c/grid/crs/install/crsutils.pm line 15809.
    

    Afortunadamente el error es claro , nos falta el fichero /u01/app/19c/grid/crs/install/crsgenconfig_params del nodo del que estamos extendiendo el rac, lo que hace que falle el punto 4 de la ejecucion del root.sh
    Si buscamos por internet veremos varias entradas en las que nos indican que es un problema en la descompresion de los paquetes originales, lo que no nos ayuda.
    La ayda viene en la nota 12.2 GI Upgrade fails with : CLSRSC-635: Failed to get EXTENDED_CLUSTER_SITE_GUIDS (Doc ID 2259672.1)
    En la que nos indican que solo hemos de poner el EXTENDED_CLUSTER_SITE_GUIDS en ese fichero y reejecutar el root.sh

    La idea parece buena, pero … cual deberia de ser el contenido de ese fichero ?

    El contenido de ese fichero es el siguiente

    EXTENDED_CLUSTER_SITE_GUIDS=rac
    

    Donde, el valor del campo EXTENDED_CLUSTER_SITE_GUIDS es el mismo que aparece en el campo CLUSTER_NAME del fichero /opt/app/19c/grid/crs/install/crsconfig_params

    CLUSTER_TYPE=DB
    VNDR_CLUSTER=false
    OCR_LOCATIONS=
    CLUSTER_NAME=rac
    NODE_NAME_LIST=rac1,rac2
    PRIVATE_NAME_LIST=
    VOTING_DISKS=
    #VF_DISCOVERY_STRING=%s_vfdiscoverystring%
    

    Mas informacion en

    • 12.2 GI Upgrade fails with : CLSRSC-635: Failed to get EXTENDED_CLUSTER_SITE_GUIDS (Doc ID 2259672.1)

    restaurar una base de datos desde el backup de una Standby

    Hoy vamos a ver como anticipar un error en lo que puede ser una recuperacion larga

    Supongamos que hemos recuperado una base de datos desde una standby database.
    Si ese es el caso, cuando intentemos abrir la base de datos despues del recover tendremos un error

    ORA-01666: control file is for a standby database
    
    
    

    Como lo prevenimos

    Vamos a ver primero como prevenir este error, y es simplemente añadiendo la clausula primary a la cadena que vamos a usar para recuperar la base de datos desde ese standby backup
    rman target /
    restore primary controlfile from '/backup/SID_STBY/standby_controlfile_backup';
    exit;
    

    Y pensareis, esto esta muy bien, pero.... y si ya tengo el backup restaurado

    Como lo solucionamos ?

     ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;
    ALTER DATABASE ACTIVATE STANDBY DATABASE;
    select name,open_mode ,database_role from v$database;
    alter database open resetlogs

    El RAC se queda en estado [ROLLING PATCH]

    Hoy vamos a ver una entrada sobre ago que puede dar mucho miedo pero que tiene una solucion muy sencila
    Pongamos que tras aplicar una serie de parches comprobamos la version de nuesrto softare en el RAC y nos encontramos lo siguiente

    [oracle@rac1~]$ sudo  $ORACLE_HOME/bin/crsctl query  crs  activeversion -f
    Oracle Clusterware active version on the cluster is [19.0.0.0.0]. The cluster upgrade state is [ROLLING PATCH]. The cluster active patch level is [724960844].
    
    Oracle Clusterware patch level on node rac1is [2701864972].
    [oracle@rac1~]$ sudo  $ORACLE_HOME/bin/crsctl query  crs  softwarepatch rac2
    Oracle Clusterware patch level on node rac2 is [387459443].
    

    De alguna manera que no alcanzamos a entender ( o igual si), tenemos que tras finalizar un parcheado los parches de los dos nodos son iguales.

    Que hacemos ??

    Veamos a ver cuales son los parches que tenemos instalados.
    Lo primero que se nos viene a la cabeza es tirar del comando optch
    Y ecejutamos un
    $ORACLE_HOME/OPatch/opatch -lsinventory
    o bien
    $ORACLE_HOME/OPatch/opatch -lspatches
    Pero, para nuestra desesperacion resulta que Opatch nos dice que hay los mismos parches instalados.
    ¿que hacemos ahora?

    La solucon esta en patchgen

    Vamos a ver realmente que es lo que tenemos instalado en los nodos.
    Para ello usaremos en ambos nodos el comando
    $ORACLE_HOME/bin/kfod op=patches

    [oracle@rac1~]$  $ORACLE_HOME/bin/kfod op=patches
    ---------------
    List of Patches
    ===============
    30489227
    30489632
    30557433
    30655595
    
    [oracle@rac2~]$ $ORACLE_HOME/bin/kfod op=patches
    ---------------
    List of Patches
    ===============
    29517242
    29517247
    29585399
    30489227
    30489632
    30557433
    30655595
    

    Como podemos ver, en el rac2 nos aparecen 3 parches que no tenemos en rac1.
    El siguiente paso deberia de ser el buscar cuales son esos parches y decidir si los queremos aplicar donde no estan , o quitrlos de donde estan.
    Dado que quitar un parche suele ser mas complicado que ponerlo , vamos ha hacer esta segunda opcion y a eliminar esos 3 parches de rac2.

    Para ello,lo primero que tendremos que hacer es como usuario root

    . oaenv
     $ORACLE_HOME/crs/install/rootcrs.sh -prepatch
    

    Y tras esto, eliminaremos los parches con

    $ORACLE_HOME/bin/patchgen commit -rb 29517242 
    $ORACLE_HOME/bin/patchgen commit -rb 29517247
    $ORACLE_HOME/bin/patchgen commit -rb 29585399
    

    Una vez eliminados, comprobamos d enuevo con kfod que tenemos solamente los parches deseados, y sera en ese momento cuando cerremos la operacion con (de nuevo como root)

     $ORACLE_HOME/crs/install/rootcrs.sh -postpatch
    

    Tras esto solamente tenemos que comprobar que el estado del cluster es normal y que las versiones y parches son los correctos

    [oracle@rac1~]$) crsctl query crs softwarepatch -all
    Oracle Clusterware patch level on node rac1 is [2701864972].
    [oracle@rac1~]$ crsctl query crs activeversion  -f
    Oracle Clusterware active version on the cluster is [19.0.0.0.0]. The cluster upgrade state is [NORMAL]. The cluster active patch level is [2701864972].
    [oracle@rac1~]$ crsctl query crs releasepatch
    Oracle Clusterware release patch level is [2701864972] and the complete list of patches [30489227 30489632 30557433 30655595 ] have been applied on the local node. The release patch string is [19.6.0.0.0].
    [oracle@rac2~]$ crsctl query crs releasepatch
    Oracle Clusterware release patch level is [2701864972] and the complete list of patches [30489227 30489632 30557433 30655595 ] have been applied on the local node. The release patch string is [19.6.0.0.0].
    

    Mas informacion como siempre en la documentacion de oracle

    • Troubleshooting OPatchAuto
    • KFOD, KFED, AMDU (Doc ID 1485597.1)
    • Note 1180491.1 – KFED Tool For Windows OS
    • Note 1346190.1 – KFED.PL for diagnosing – ORA-15036 ORA-15042 ORA-15020 ORA-15033
    • Note 1505005.1 – Where to find kfed utility before Oracle Grid Infrastructure is installed