mayo | 2018 | Dba stuff

Hoy vamos a ver un a entrada rápida de como eliminamos un DR de una configuración de dataguard.

Tenemos un entorno donde tenemos 2 Physycal standby y queremos eliminar la primera de ellas TEST_STBY1

Comprobemos la configuración de nuestro entorno, nos conectamos a la primaria y ejecutamos:

-bash-4.2$ . oraenv
ORACLE_SID = [oracle] ? TEST
The Oracle base has been set to /opt/app/oracle
-bash-4.2$ export ORACLE_SID=TEST
-bash-4.2$ dgmgrl /

DGMGRL> show configuration verbose;
Configuration - DR_TWO_STANDBY
  Protection Mode: MaxPerformance
  Databases:
    TEST      - Primary database
    TEST_STBY1    - Physical standby database
    TEST_STBY2 - Physical standby database
  Properties:
    FastStartFailoverThreshold      = '30'
    OperationTimeout                = '30'
    FastStartFailoverLagLimit       = '30'
    CommunicationTimeout            = '180'
    FastStartFailoverAutoReinstate  = 'TRUE'
    FastStartFailoverPmyShutdown    = 'TRUE'
    BystandersFollowRoleChange      = 'ALL'
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS

DGMGRL> show database  'TEST_STBY1';
Database - TEST_STBY1
  Role:            PHYSICAL STANDBY
  Intended State:  APPLY-ON
  Transport Lag:   14 hours 4 minutes 14 seconds
  Apply Lag:       14 hours 4 minutes 14 seconds
  Real Time Query: OFF
  Instance(s):
    TEST
Database Status:
SUCCESS

Tenemos claro que es la que queremos eliminar , de echo, podemos ver como lleva 14 horas. de retraso .
Para eliminarla ejecutaremos el comando Remove Database , si vemos el ejemplo, poderes ver como siempre ponemos el nombre de la base de datos entre comillas simples, en caso de no hacerlo, el dataguard lo tomará como minúsculas


DGMGRL> disable database 'TEST_STBY1';
Disabled.

DGMGRL> remove database 'TEST_STBY1';
Removed database "TEST_STBY1" from the configuration

DGMGRL> show configuration verbose;

Configuration - MyTEST_STBY1
  Protection Mode: MaxPerformance
  Databases:
    TEST      - Primary database
    TEST_STBY2 - Physical standby database
  Properties:
    FastStartFailoverThreshold      = '30'
    OperationTimeout                = '30'
    FastStartFailoverLagLimit       = '30'
    CommunicationTimeout            = '180'
    FastStartFailoverAutoReinstate  = 'TRUE'
    FastStartFailoverPmyShutdown    = 'TRUE'
    BystandersFollowRoleChange      = 'ALL'
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS

DGMGRL> quit

Ya lo hemos eliminado, pero , deberemos de comprobar en nuestra base de datos primaria que no hemos dejado restos, para ello, buscaremos que los servicios y los destinos de archivado estén limpios de nuestra configuración anterior.

-bash-4.2$ sqlplus "/as sysdba"

SQL> set linesize 800;
SQL> show parameter log_archive_dest_

NAME                                 TYPE        VALUE

log_archive_dest_1                   string      location=USE_DB_RECOVERY_FILE_
                                                 DEST, valid_for=(ALL_LOGFILES,
                                                  ALL_ROLES)
log_archive_dest_2                   string      service="TEST_STBY1", LGWR ASYNC NOAFFIRM
                                             
log_archive_dest_3                   string      service="TEST_STBY2", LGWR ASYNC NOAFFIRM 
												
SQL>   show parameter log_archive_config;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_config                   string      dg_config=(TEST,TEST_STBY1,TEST_STBY2)

Podemos ver como el broker no ha limpiado la configuración, por lo que lo haremos nosotros a mano

SQL> alter system set log_archive_dest_2='' scope=both;
SQL> alter system set log_archive_config='dg_config=(TEST,TEST_STBY2)' scope=both;



SQL> show parameter log_archive_config;
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_config                   string      dg_config=(TEST,TEST_STBY)
SQL> show parameter log_archive_dest_

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_1                   string      location=USE_DB_RECOVERY_FILE_
                                                 DEST, valid_for=(ALL_LOGFILES,
                                                  ALL_ROLES)
log_archive_dest_2                   string
log_archive_dest_3                   string      service="TEST_STBY2", LGWR ASYNC NOAFFIRM
SQL>

Con esto, podremos afirmar que nuestra configuración está limpia

Oracle 11g

Si estamos en la version 11g deberemos de hacerlo consultando la tabla del diccionario sys.registry$history

SET LINESIZE 180 PAGESIZE 90 COLUMN FECHA FORMAT A18 COLUMN action FORMAT A20 COLUMN version FORMAT A10 COLUMN comments FORMAT A30 COLUMN bundle_series FORMAT A10 SELECT TO_CHAR(action_time, 'YYYY-MM-DD HH24:MI') AS FECHA, action, namespace, version, comments, bundle_series FROM sys.registry$history ORDER by action_time;

Lo que nos devolvera algo similar a :

FECHA ACTION NAMESPACE VERSION COMMENTS BUNDLE_SER ------------------ -------------------- -------------------- ---------- ------------------------------ ---------- 07-JAN-2017 15:21 APPLY SERVER 11.2.0.3 PSU 11.2.0.3.15 PSU 01-DEC-2017 18:59 UPGRADE SERVER 11.2.0.4.0 Upgraded from 11.2.0.3.0 01-DEC-2017 19:00 APPLY SERVER 11.2.0.4 PSU 11.2.0.4.171017 PSU

Preguntando a DBA_REGISTRY_SQLPATCH

La consulta sera muy similar a la anterior, pero en ved de preguntar a el dicionario sys.registry$history, lo haremos a la tabla DBA_REGISTRY_SQLPATCH

SET LINESIZE 180 PAGESIZE 90 COLUMN FECHA FORMAT A20 COLUMN action FORMAT A10 COLUMN status FORMAT A20 COLUMN description FORMAT A90 COLUMN version FORMAT A10 COLUMN bundle_series FORMAT A10 SELECT TO_CHAR(action_time, 'YYYY-MM-DD HH24:MI:SS') AS action_time, action, status, description, version, patch_id, bundle_series FROM sys.dba_registry_sqlpatch ORDER by action_time;

Lo que nos devolvera algo similar a

ACTION_TIME ACTION STATUS DESCRIPTION VERSION PATCH_ID BUNDLE_SER -------------------- ---------- ---------- ---------------------------------------- ---------- ---------- ---------- 07-MAR-2018 21:37:51 APPLY SUCCESS Database Patch Set Update : 12.1.0.2.4 12.1.0.2 20831110 PSU (20831110)

Mediante el package dbms_qopatch

En la version 12c tenemos el nuevo datapatch en los parcheados, la informacion de los parches de la base de datos esta tambien accesible con el package dbms_qopatch.
Esto ya lo vimos en la entrada Obtener los parches instalados en la base de datos CDB que venia a decir :

set serverout on exec dbms_qopatch.get_sqlpatch_status;

Lo que nos devuelve

Patch Id : 25171037 Action : APPLY Action Time : 14-JUN-2017 23:09:33 Description : DATABASE PATCH SET UPDATE 12.1.0.2.170418 Logfile : /u01/app/oracle/cfgtoollogs/sqlpatch/25171037/21099266/25171037_apply_SID_2017Jun14_23_09_20.log Status : SUCCESS PL/SQL procedure successfully completed.

Sobre el uso de dbms_qopatch tenemos la URL hay una URL Como saber si un parche esta aplicado en la BBDD que tiene consultas muy utiles para obtener informacion de la base de datos (inventario,paches…)

Esta informacion ha sido obtenido en su totalidad de las URLS:

Dba stuff

Un cajon desastre para el día a día

Archivo por meses: mayo 2018

Eliminar un DR del Dataguard

Version del parcheado de la base de datos

Oracle 11g

Oracle 12c

Preguntando a DBA_REGISTRY_SQLPATCH

Mediante el package dbms_qopatch