DBA Oracle

miércoles, 29 de abril de 2026

MAA (Maximum Availability Architecture) de Oracle

MAA es el conjunto de mejores practicas de Oracle para lograr la maxima disponibilidad de una base de datos. No es un producto que se compra sino una arquitectura que se implementa combinando tecnologias de Oracle segun el nivel de disponibilidad que necesitamos. Es independiente de donde la base de datos resida puede ser Onpremise, en Oracle Cloud, Hibrida o Multicloud.

Oracle define 5 tiers o niveles de MAA. Cada tier agrega mas tecnologias sobre el anterior y nos da mayor proteccion contra distintos tipos de fallas. La idea es que cada capa envuelve a la anterior — no se reemplaza, se acumula.

Los conceptos clave de MAA son:

RTO (Recovery Time Objective) - Tiempo maximo que puede estar caida la base de datos.

RPO (Recovery Point Objective) - Maximo de datos que podemos perder medido en tiempo.

Bronze

Es el nivel basico. Incluye las mejores practicas de una base de datos single instance con Clusterware Restart, Arquitectura Multitenant, Tecnologias Flashback, backup con RMAN, archivelog activado y parametros de configuracion recomendados por Oracle. Con este tier podemos recuperarnos de una falla pero la ventana de recuperacion puede ser de horas.

RTO: minutos a horas
RPO: horas o dias

Opcional backups con ZDLRA puede llevar el RPO casi cero

Silver

Opción 1: Agrega RAC (Real Application Clusters) y Application Continuity. Tenemos multiples instancias accediendo a la misma base de datos. Si un nodo cae, las instancias del otro nodo siguen atendiendo las conexiones sin intervencion del DBA. Opcionalmente se puede implementar Global Distruibuted Database.

Opción 2: Puede ser una single instance con Data Guard. Tenemos una base de datos primaria en un sitio y la base de datos standby en un sitio secundario listo para cambiar de rol y pasar a ser primario si hay algun incidente en la base primaria.

RTO: segundos a minutos
RPO: minutos

Opcional backups con ZDLRA puede llevar el RPO casi cero

Opción 1:

Opción 2:

Gold

Agrega Data Guard al RAC. Tenemos una base de datos primaria y una o mas standbys (pueden ser fisicas o logicas). Si la primaria cae hacemos un failover o switchover a la standby. Tambien incluye Active Data Guard que permite tener la standby abierta en modo read only para reportes mientras sincroniza.

RTO: minutos
RPO: segundos

Platinum

Opción 1: La arquitectura GOLD más Application Continuity y Fast Start Failover (FSFO). El failover es automatico, sin intervencion del DBA. Las aplicaciones se reconectan automaticamente despues del failover sin que el usuario final note la interrupcion. Las transacciones en vuelo se vuelven a ejecutar automaticamente. En Exadata y con la ultima version de Base de Datos.

Opción 2: La arquitectura GOLD más exadata con replicación con GoldenGate Activa/Activa.

RTO: segundos
RPO: cero

Opción 1:

Opción 2:

Diamond

Es el nivel de extrema disponibilidad. Agrega Oracle GoldenGate para replicacion activa-activa entre dos sitios. Los dos sitios estan activos al mismo tiempo recibiendo transacciones. Si cae un site completo el otro sigue operando sin interrupcion. En exadata y con la ultima version de la Base de Datos.

RTO: cero
RPO: cero

La eleccion del tier depende de cada aplicacion y del impacto que tiene para el negocio que la base este caida. No todas las bases necesitan Diamond. Lo importante es identificar que nivel de disponibilidad necesitamos y implementar el tier correspondiente.

Referencias:

https://www.oracle.com/database/technologies/maximum-availability-architecture/

Oracle Update Advisor y MAA

Oracle Update Advisor (OUA) es una herramienta que nos dice si el software de nuestra base de datos esta al dia con los patches recomendados. Es importante porque si el software esta desactualizado, nuestra arquitectura MAA (Maximum Availability Architecture) esta en riesgo aunque tengamos Data Guard o RAC configurados.

OUA nos muestra un estado de salud con tres colores:

Verde - El software esta actualizado segun la politica configurada. Estamos protegidos contra los bugs criticos conocidos.

Amarillo - Vamos un RU o MRP atrasado. El Data Guard o RAC pueden seguir corriendo pero con riesgo de problemas de performance o disponibilidad.

Rojo - El software esta muy desactualizado. El SLA de MAA esta comprometido sin importar el tier que tengamos (Gold, Platinum o Diamond).

Lo podemos usar desde tres herramientas:

FPP (Fleet Patching and Provisioning) para entornos RAC, Data Guard o flotas grandes
DBCA para bases single-instance
AutoUpgrade 26.2 o superior

Que version de Oracle necesito para usar Oracle Update Advisory?

Para usar Oracle Update Advisor integrado en DBCA and FPP, necesitamos Oracle AI Database Release Update de July 2025, para 19c (19.28+) o 23ai o 26ai (23.9+).

Out-of-Place Patching

Oracle recomienda hacer el patching out-of-place usando gold images. La diferencia con el patching tradicional es:

1 - Con el patching tradicional (in-place) tenemos que bajar todas las instancias del Oracle Home, aplicar el patch y volver a levantar. La ventana de mantenimiento es larga.

2 - Con out-of-place creamos un Oracle Home nuevo a partir de una gold image mientras la base sigue corriendo. Cuando esta listo hacemos el switch. La ventana de mantenimiento es mucho mas corta.

3 - Si algo sale mal, volver al Oracle Home anterior es casi inmediato.

Políticas por tier MAA: no todo tiene que estar en N (la última versión)

Una cosa que me pareció muy útil del enfoque de OUA es que no te obliga a estar siempre en la última versión. Podés configurar políticas según el criticidad de cada entorno:

Bronze / Silver Tier: Pueden trabajar con un lag de 1 RU (N-1). Priorizando estabilidad antes que tener las últimas features.

Gold / Platinum / Diamond Tier: Deberían apuntar a N (última versión disponible) o aplicar MRPs mensuales sobre el RU actual para cubrir bugs de alto impacto antes de que causen un incidente.

Ejemplo de configuración :

applyFrequency=MonthlyLTRU
updateLag=N-1

Esto te da un punto de actualización a la version anterior a la ultima, sin dejar de recibir los fixes que impactan la disponibilidad mes a mes.

Para verificar el estado de nuestro entorno

Desde DBCA o FPP podemos ver si nuestra arquitectura MAA esta corriendo con software en estado Rojo o Amarillo.

La documentacion esta en:

OUA via FPP: https://docs.oracle.com/en/database/oracle/oracle-database/26/fppad/about-oracle-update-advisor.html
OUA via DBCA: https://docs.oracle.com/en/database/oracle/oracle-database/26/dbptc/index.html#GUID-2F954CB6-CF7C-4A7A-AF97-8B57A905548C

lunes, 29 de mayo de 2023

Export Data Pump en Windows

Para ejecutar un Export Data Pump en Windows podemos usar PowerShell (que es una herramienta mas moderna y potente) o simplemente CMD (la línea de comandos de Windows clasica)

En este ejemplo la base de datos se llama ORCL. Voy a hacer un export full. Tengo previamente creado un directorio c:\oracle\scripts y un directorio para los dumps d:\oracle\dumps

1 - Verifico en la Base de datos que el Directorio DATAPUMP_DIR apunta al directorio requerido

Desde PowerShell o CMD

set ORACLE_SID=ORCL

sqlplus / as sysdba

select * from dba_directories where directory_name=’DATA_PUMP_DIR’;

Se puede modificar ese directorio default o crear un directorio nuevo. En este ejemplo lo modifico

create or replace directory DATA_PUMP_DIR as “d:\oracle\dumps'';

2 - Crear un par file con wordpad

logfile=expdp_orcl.log

dumpfile=expdp_orcl.dmp

directory=DATAPUMP_DIR

full=Y

Para guardar : directorio seleccionado c:\oracle\scripts

nombre orcl.par formato : Documento de Texto – Formato MS-DOS

3 - En Windows PowerShell o CMD

set ORACLE_SID=ORCL

expdp system/password parfile=c:\oracle\scripts\ orcl.par

Finalmente cuando termine el dump va a quedar en el directorio seleccionado en DATA_PUMP_DIR

sábado, 27 de mayo de 2023

Como Conectarse a una Base Autonoma con SQL Developer

Una vez que tenemos creada una Base de Datos Autonoma podemos conectarnos de diversas formas entre ellas con SQL Developer.

1 - En nuestra Base Autonoma en mi ejemplo ATPTEST1, seleccionar Conexion de Base de Datos

2 - Ir a Descargar Cartera

3 - Agregarle contraseña y presionar Descargar

4 - Cuando lo descargamos nos va a quedar un archivo zip con el nombre Wallet_<BD>

5 - Abrimos el SQL Developer y agregamos la conexion con Usuario Admin (que es el 1ero que tenemos, luego podemos crear otros usuarios). Seleccionamos Tipo de Conexion : Cartera de Cloud

Agregamos el Wallet que recien bajamos.

6 - Probamos y luego Guardar y ya nos conectamos a la base de datos

Ya estamos conectados!

Error Oracle Cloud 403 IP Address Rejected

Si obtenemos el siguiente error Oracle Cloud 403 IP Address Rejected es porque estamos tratando de acceder al recurso desde una IP no autorizada, para solucionarlo tenemos que agregar en la Lista del Control de Acceso del Recurso que queríamos acceder. En mi ejemplo una Base de Datos Autónoma desde otra Notebook que no era desde la cual la cree.

1 - Ir a Red / Lista de Control de Acceso / Editar

2 - Van a aparecer las IPs que ya estan habilitadas. Allí presionar Agregar mi dirección IP. En mi caso habia una sola habilitada

3 - Automáticamente detecta nuestra dirección IP y la agrega separada por coma. Allí presionar Guardar

Mi base autónoma quedo unos segundos actualizando su estado y enseguida quedo lista para acceder!

Como Crear una Base de Datos Autónoma Para Procesamiento Transaccional

En este ejemplo vamos a crear una Base de Datos transaccional autónoma OLTP Always Free, o sea Gratuita para Siempre. Debemos contar primero con una cuenta en la Nube de Oracle. La cuenta puede ser del tipo gratuita creada en cloud.oracle.com/free o puede ser una cuenta con créditos ya que igualmente podemos crear esta base gratuita sin consumir créditos. Podemos tener un máximo de 2 bases de datos autónomas por cuenta.

Las bases de datos autónomas tienen asignado 1 OCPU, 20G de Almacenamiento y la Licencia esta incluida.

1 - Seleccionar Oracle Database - Procesamiento de transacciones autónomo

2 - Seleccionar el Compartimento, en mi ejemplo elijo TEST, para saber mas sobre Compartimentos AQUI

3 - Presionar Crear Base de Datos Autónoma. Se pueden crear máximo 2 bases de datos autónomas Always Free por cuenta.

4 - Aparece con un nombre de Base de Datos a mostrar y el nombre de base de datos, ambos se pueden cambiar. En mi ejemplo los cambio por ATPTEST1

5 - Dejar seleccionado Procesamiento de Transacciones e Infraestructura Compartida

6 - Seleccionar SIEMPRE GRATIS. Queda asignada con 1 OCPU (Oracle CPU) y 20G de espacio de Almacenamiento.

7- Crear las credenciales del usuario Admin que es el administrador de esta base de datos y luego Presionar Crear Base de Datos Autónoma.

8 - En unos pocos minutos queda en verde en estado DISPONIBLE. ATP es por el tipo de Base de Datos, que en ingles es la sigla de Autonomous Transaction Processing

Conclusión : En pocos pasos podemos tener creada una base de datos autónoma gratuita para siempre con 1 OCPU y 20G de Almacenamiento y con Licenciamiento incluido.

viernes, 26 de mayo de 2023

OCI - Crear Compartimentos

Los Compartimentos sirven para organizar y aislar los recursos en la nube (como si fueran carpetas de windows). La idea es asignar a un Compartimento todos los recursos de un mismo tipo.

Cuando creamos una cuenta en la Nube de Oracle existe solo el Compartimento raíz que es con el mismo nombre que la cuenta.

Lo recomendado es que antes de comenzar a crear los recursos pensemos en como los agruparemos, por ejemplo DESARROLLO y PRODUCCION y creemos primeros los Compartimentos y luego a los recursos ya los creamos en su Compartimento correspondiente.

En el caso de que los hayamos creado los recursos en el Compartimento raíz, y luego creamos los Compartimentos, no hay tanto problema, la mayoría de los recursos se pueden mover a su Compartimento correspondiente.

Los Compartimentos atraviesan las regiones, por lo tanto van a existir en todas las regiones que tenga acceso esa cuenta.

Crear un Compartimento

1 - Seleccionamos Identidad y Seguridad -> Compartimentos

2 - Seleccionamos Crear Compartimento

3 - Completamos Nombre, Descripción y de que Compartimento depende

4 - Vamos a presionar Crear Compartimento

5 - Esperamos unos segundos y ya aparece creado

Conclusión : Los Compartimentos son necesarios y recomendados pero no obligatorios. Crearlos lleva pocos pasos y quedan disponibles inmediatamente. Cuando estan disponibles aparece el circulo VERDE y estado ACTIVO como en la figura anterior.

jueves, 18 de mayo de 2023

ASM : Como Consultar Compatibilidad Diskgroups

A partir de Oracle 11g tenemos que los diskgroups tienen 3 atributos de compatibilidad
COMPATIBILITY.RDBMS
COMPATIBILITY.ASM
COMPATIBILITY.ADVM
la vista v$asm_attribute donde detalla los attributos de un diskgroup

SQL> col name format a20
SQL> col value format a10
SQL> select group_number, name, value from v$asm_attribute where name like 'comp%' order by 1;

GROUP_NUMBER NAME VALUE
------------ -------------------- ----------
1 compatible.asm 12.1.0.2.0
1 compatible.rdbms 12.1.0.2.0
2 compatible.asm 12.1.0.2.0
2 compatible.rdbms 12.1.0.2.0
3 compatible.asm 12.1.0.2.0
3 compatible.rdbms 12.1.0.2.0

El COMPATIBLE.ASM y COMPATIBLE.RDBMS determinan la version minima de ASM y Base de datos que se pueden usar en ese Diskgroup. El parametro COMPATIBLE.ADVM debe ser mayor a 11.2 para que se pueda utilizar esta funcionalidad.
Se puede subir el valor de la compatibilidad con ALTER DISKGOUP teniendo en cuenta que subir el valor de la compatibilidad es una tarea irreversible.

Tuning Redo Logs

Para mejorar la performance en las escrituras a disco, es necesario que el tamaño de los redologs sea suficiente como para que se hagan como máximo 3 switch de redologs por hora.
Esto es independiente de la version de base de datos que estemos usando, el uso de los redologs en Oracle es igual en todas las versiones inclusive si es una CDB o no.
En este ejemplo detectamos en el alert.log que se estan ejecutando switch de redolog cada 2 minutos. Esto genera mucho overhead.

Mon Feb 06 16:21:23 2017

Thread 1 cannot allocate new log, sequence 104612

Checkpoint not complete

Current log# 1 seq# 104611 mem# 0:/u01/oradata/TEST/redo01.log

Thread 1 advanced to log sequence 104612 (LGWR switch)

Current log# 2 seq# 104612 mem# 0: /u01/oradata/TEST/redo02.log

Mon Feb 06 16:21:23 2017

Archived Log entry 69088 added for thread 1 sequence 104611 ID 0x72f28ed0 dest 1:

Mon Feb 06 16:23:21 2017

Thread 1 advanced to log sequence 104613 (LGWR switch)

Current log# 3 seq# 104613 mem# 0: /u01/oradata/TEST/redo03.log

Mon Feb 06 16:23:21 2017

Archived Log entry 69089 added for thread 1 sequence 104612 ID 0x72f28ed0 dest 1:

Mon Feb 06 16:23:32 2017

Thread 1 cannot allocate new log, sequence 104614

Checkpoint not complete

Current log# 3 seq# 104613 mem# 0: /u01/oradata/TEST/redo03.log

Thread 1 advanced to log sequence 104614 (LGWR switch)

Current log# 1 seq# 104614 mem# 0: /u01/oradata/TEST/redo01.log

Mon Feb 06 16:23:33 2017

Archived Log entry 69090 added for thread 1 sequence 104613 ID 0x72f28ed0 dest 1:

Mon Feb 06 16:25:22 2017

Thread 1 cannot allocate new log, sequence 104615

Checkpoint not complete

Current log# 1 seq# 104614 mem# 0: /u01/oradata/TEST/redo01.log

Thread 1 advanced to log sequence 104615 (LGWR switch)

Current log# 2 seq# 104615 mem# 0: /u01/oradata/TEST/redo02.log

Mon Feb 06 16:25:24 2017

Archived Log entry 69091 added for thread 1 sequence 104614 ID 0x72f28ed0 dest 1:

Mon Feb 06 16:27:22 2017

Thread 1 cannot allocate new log, sequence 104616

Checkpoint not complete

Current log# 2 seq# 104615 mem# 0: /u01/oradata/TEST/redo02.log

Thread 1 advanced to log sequence 104616 (LGWR switch)

Current log# 3 seq# 104616 mem# 0: /u01/oradata/TEST/redo03.log

Recomiendo revisar el log en varios horarios para ver si es algo que se mantiene o si es muy eventual, para poder calcular el tamaño de acuerdo a un promedio de actividad.

Revisamos el tamaño de los RedoLogs

$ ls -lh re*

-rw-r-----. 1 oracle oinstall 51M Feb 6 16:29 redo01.log

-rw-r-----. 1 oracle oinstall 51M Feb 6 16:31 redo02.log

-rw-r-----. 1 oracle oinstall 51M Feb 6 16:31 redo03.log

En este caso tienen 51M y no alcanzan a almacenar ni un minuto, en forma teorica tendrian que poder almacenar 20 minutos, o sea 3 switch de redolog por hora. Sin embargo el comportamiento no es igual en todas las horas, y decido realizar el incremento en forma gradual, por lo tanto voy a subir el tamaño a 300M para luego seguir monitoreando y ajustando según se necesite.

SQL> select group#, bytes/1024/1024 "size Mb" from v$log;

GROUP# size Mb

---------- ----------

1 50

2 50

3 50

SQL> select group#,member from v$logfile;

GROUP#

----------

MEMBER

--------------------------------------------------------------------------------

/u01/oradata/TEST/redo01.log

/u01/oradata/TEST/redo02.log

/u01/oradata/TEST/redo03.log

El procedimiento para agrandarlos, es agregar otros 3 grupos con el tamaño deseado y eliminar estos 3 grupos actuales. En este caso aprovecho a realizarlo en otro file system que hay mas espacio.

SQL> alter database add logfile group 4 '/u01/redologs/TEST/redo04.log' size 300M;

Database altered.

SQL> alter database add logfile group 5 '/u01/redologs/TEST/redo05.log' size 300M;

Database altered.

SQL> alter database add logfile group 6 '/u01/redologs/TEST/redo06.log' size 300M;

SQL> select group#,status from v$log;

GROUP# STATUS
---------- ----------------
1 INACTIVE
2 INACTIVE
3 ACTIVE
4 ACTIVE
5 CURRENT
6 UNUSED

SQL> alter database drop logfile group 1;

Database altered.

SQL> alter database drop logfile group 3;

alter database drop logfile group 3

ERROR at line 1:

ORA-01624: log 3 needed for crash recovery of instance TEST (thread 1)

ORA-00312: online log 3 thread 1: '/u01/oradata/TEST/redo03.log'

Este error es porque todavia esta ACTIVE

SQL> alter database add logfile group 7 '/u01/redologs/TEST/redo07.log' size 300M;

Database altered.

SQL> alter database add logfile group 8 '/u01/redologs/TEST/redo08.log' size 300M;

Database altered.

SQL> alter database add logfile group 9 '/u01/redologs/TEST/redo09.log' size 300M;

Database altered.

SQL> select status, group# from v$log;

STATUS GROUP#

---------------- ----------

INACTIVE 3

CURRENT 4

ACTIVE 5

ACTIVE 6

UNUSED 7

UNUSED 8

UNUSED 9

SQL> alter database drop logfile group 3;

Database altered.

Conclusion : Cuando el tamaño de los Redo Logs no sea suficiente para almacenar 20 minutos hay que agrandarlos y la forma es agregando mas grupos de RedoLogs del tamaño requerido. Luego se deben borrar los anteriores aunque posiblemente no puedan borrarse en el instante pero si unos minutos más tarde.

Como Crear Base de Datos 19c desde SQL

En este ejemplo ya tenemos en un servidor Linux instalado el Software Oracle Database 19c y vamos a crear una Base de Datos de tipo Container Database CDBDEV logueados con el usuario oracle (el mismo con el cual instalamos el Software). Tanto el nombre de la base de datos como los directorios usados en este ejemplo se pueden personalizar.

1 - Configurar las variables de ambiente, reemplazando en mi ejemplo con los Directorios correspondientes a la instalacion

$ export ORACLE_BASE=/u01/app/oracle

$ export ORACLE_HOME=/u01/app/oracle/product/19.3.0/db_home1

$ export ORACLE_SID=CDBDEV

2 - Levantar el listener

$ lsnrctl start

(Para levantar el listener default con nombre LISTENER en el Port default 1521 no hace falta configurar nada)

3 - Copiar init.ora en initCDBDEV.ora

$ cp init.ora initCDBDEV.ora

4 - Editar el initCDBDEV.ora

agregar

db_create_file_dest='/u01/app/oracle/oradata'

enable_pluggable_database=true

cambiar

db_name='CDBDEV'

db_recovery_file_dest='/app/oracle/fast_recovery_area'

verificar que el parametro compatible sea mayor a 12.0.0, idealmente

compatible='19.0.0.0'

4 - Crear los directorios

correspondientes a la auditoria que coincida con el parametro audit_file_dest del initCDBDEV.ora

$ mkdir -p /u01/app/oracle/admin/CDBDEV/adump

$ mkdir -p /u01/app/oracle/oradata

$ mkdir -p /app/oracle/fast_recovery_area

5 - Levantar la instancia en estado NOMOUNT

$> sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Mon Apr 3 06:31:08 2023

Version 19.16.0.0.0

Connected to an idle instance.

SQL> startup nomount

ORACLE instance started.

Total System Global Area 1073738192 bytes

Fixed Size 9142736 bytes

Variable Size 633339904 bytes

Database Buffers 423624704 bytes

Redo Buffers 7630848 bytes

6 - Crear la Base de Datos

SQL> CREATE DATABASE CDBDEV

USER SYS IDENTIFIED BY oracle

USER SYSTEM IDENTIFIED BY oracle

EXTENT MANAGEMENT LOCAL

DEFAULT TEMPORARY TABLESPACE temp

DEFAULT TABLESPACE users

UNDO TABLESPACE undotbs1

ENABLE PLUGGABLE DATABASE;

Database created.

7 - Ejecutar el script catalog, demora como media hora

SQL> @?/rdbms/admin/catalog.sql

…………………………

PL/SQL procedure successfully completed.

TIMESTAMP

--------------------------------------------------------------------------------

COMP_TIMESTAMP CATALOG 2023-04-03 06:42:22

Session altered.

SQL>

SQL> Rem *********************************************************************

SQL> Rem END catproc.sql

SQL> Rem *********************************************************************

SQL>

8 - Ejecutar el script catproc

SQL> @?/rdbms/admin/catproc.sql

9 - Agregar la Base en el oratab

Editar /etc/oratab

CDBDEV:/u01/app/oracle/product/19.3.0/dbhome_1:Y

Conclusión : Si no contamos con ambiente gráfico como para usar el DBCA pordemos crear la base de datos con estos simples pasos por linea de comandos.

viernes, 12 de mayo de 2023

Exadata : Como cambiar el Modo del Flash Cache

Elemplo con una configuracion de 3 Storage Servers.

1 - Verificamos el modo actual

[celladmin@qr01celadm01 ~]$ dcli -c qr01celadm01,qr01celadm02,qr01celadm03 cellcli -e list cell attributes flashCacheMode

qr01celadm01: WriteBack

qr01celadm02: WriteBack

qr01celadm03: WriteBack

2 - Bajamos los servicios

[celladmin@qr01celadm01 ~]$ dcli -c qr01celadm01,qr01celadm02,qr01celadm03 cellcli -e alter cell shutdown services cellsrv

qr01celadm01:

qr01celadm01: Stopping CELLSRV services...

qr01celadm01: The SHUTDOWN of CELLSRV services was successful.

qr01celadm02:

qr01celadm02: Stopping CELLSRV services...

qr01celadm02: The SHUTDOWN of CELLSRV services was successful.

qr01celadm03:

qr01celadm03: Stopping CELLSRV services...

qr01celadm03: The SHUTDOWN of CELLSRV services was successful.

3 - Vaciamos los datos del FlashCache

[celladmin@qr01celadm01 ~]$ dcli -c qr01celadm01,qr01celadm02,qr01celadm03 cellcli -e alter flashcache all flush

qr01celadm01: Flash cache qr01celadm01_FLASHCACHE altered successfully

qr01celadm02: Flash cache qr01celadm02_FLASHCACHE altered successfully

qr01celadm03: Flash cache qr01celadm03_FLASHCACHE altered successfully

4 - Eliminamos el FlashCache

[celladmin@qr01celadm01 ~]$ dcli -c qr01celadm01,qr01celadm02,qr01celadm03 cellcli -e drop flashcache

qr01celadm01: Flash cache qr01celadm01_FLASHCACHE successfully dropped

qr01celadm02: Flash cache qr01celadm02_FLASHCACHE successfully dropped

qr01celadm03: Flash cache qr01celadm03_FLASHCACHE successfully dropped

5 - Bajamos los servicios

[celladmin@qr01celadm01 ~]$ dcli -c qr01celadm01,qr01celadm02,qr01celadm03 cellcli -e alter cell shutdown services cellsrv

qr01celadm01:

qr01celadm01: Stopping CELLSRV services...

qr01celadm01: The SHUTDOWN of CELLSRV services was successful.

qr01celadm02:

qr01celadm02: Stopping CELLSRV services...

qr01celadm02: The SHUTDOWN of CELLSRV services was successful.

qr01celadm03:

qr01celadm03: Stopping CELLSRV services...

qr01celadm03: The SHUTDOWN of CELLSRV services was successful.

6 - Cambiamos el Modo del FlashCache a Write Trough

[celladmin@qr01celadm01 ~]$ dcli -c qr01celadm01,qr01celadm02,qr01celadm03 cellcli -e alter cell flashCacheMode = WriteThrough

qr01celadm01: Cell qr01celadm01 successfully altered

qr01celadm02: Cell qr01celadm02 successfully altered

qr01celadm03: Cell qr01celadm03 successfully altered

7 - Levantamos los servicios

[celladmin@qr01celadm01 ~]$ dcli -c qr01celadm01,qr01celadm02,qr01celadm03 cellcli -e alter cell startup services cellsrv

qr01celadm01:

qr01celadm01: Starting CELLSRV services...

qr01celadm01: The STARTUP of CELLSRV services was successful.

qr01celadm02:

qr01celadm02: Starting CELLSRV services...

qr01celadm02: The STARTUP of CELLSRV services was successful.

qr01celadm03:

qr01celadm03: Starting CELLSRV services...

qr01celadm03: The STARTUP of CELLSRV services was successful.

8 - Creamos el FlashCache

[celladmin@qr01celadm01 ~]$ dcli -c qr01celadm01,qr01celadm02,qr01celadm03 cellcli -e create flashcache all

qr01celadm01: Flash cache qr01celadm01_FLASHCACHE successfully created

qr01celadm02: Flash cache qr01celadm02_FLASHCACHE successfully created

qr01celadm03: Flash cache qr01celadm03_FLASHCACHE successfully created

9 - Verificamos

[celladmin@qr01celadm01 ~]$ dcli -c qr01celadm01,qr01celadm02,qr01celadm03 cellcli -e list cell attributes flashCacheMode

qr01celadm01: WriteThrough

qr01celadm02: WriteThrough

qr01celadm03: WriteThrough

Como crear un Scheduler JOB

Para crear un Job se usa DBMS_SCHEDULER.CREATE_JOB. Se debe tener el privilegio CREATE JOB

En estos dos ejemplos los jobs ejecutan un bloque de PLSQL

En el usuario dueño del esquema, se crea el Job, los parametros minimos son :

1- job_name : Nombre del JOB (no puede ser el mismo nombre de otro objeto, por ejemplo del procedure que va a ejecutar porque comparte el mismo NAMESPACE)

2 - job_type : Tipo de Job, en este ejemplo es un bloque de PLSQL, en job_action especificar el nombre del job

3 - start_date : La fecha de comienzo, en este ejemplo tomamos la fecha del dia.

4 - repeat_interval : Este job se va a ejecutar todos los dias a las 23:30

5 - enabled : En este ejemplo creamos el job y ya lo dejamos habilitado.

BEGIN

DBMS_SCHEDULER.CREATE_JOB (

job_name => 'JOB_M4_PROC_EJEMPLO',

job_type => 'PLSQL_BLOCK',

job_action => 'M4_PROC_EJEMPLO',

start_date => TRUNC(SYSDATE),

repeat_interval => 'FREQ=DAILY; byhour=23; byminute=30; bysecond=0;',

enabled => TRUE);

END;

Otro ejemplo ejecutando un Procedure que recibe un parámetro de tipo fecha, el parámetro a recibir debe ser el sysdate (fecha del sistema).

El Job se debe ejecutar a las 5:00 am todos los dias.

BEGIN

DBMS_SCHEDULER.CREATE_JOB (

job_name => 'JOB_ M4_EJEMPLO2 ',

job_type => 'PLSQL_BLOCK',

job_action => ' M4_PROC_EJEMPLO2(SYSDATE)',

start_date => TRUNC(SYSDATE),

repeat_interval => 'FREQ=DAILY; byhour=05; byminute=0; bysecond=0;',

enabled => TRUE);

END;

Como Activar el Modo Archive Log

Para activar el archive log hay que reinciar la base y cambiar de modo de NO ARCHIVE a ARCHIVE LOG

1 - Bajamos la Base de Datos

$> sqlplus / as sysdba

SQL*Plus: Release 12.1.0.2.0 Production on Dom Feb 19 21:36:14 2023

Conectado a:

Oracle Database 12c Standard Edition Release 12.1.0.2.0 - 64bit Production

SQL> shutdown immediate

Base de datos cerrada.

Base de datos desmontada.

Instancia ORACLE cerrada.

2 - Levantamos la base es estado MOUNT

SQL> startup mount

Instancia ORACLE iniciada.

Total System Global Area 4,0668E+10 bytes

Fixed Size 5294184 bytes

Variable Size 5771364248 bytes

Database Buffers 3,4762E+10 bytes

Redo Buffers 128921600 bytes

Base de datos montada.

3 - Ejecutamos el cambio a ARCHIVE LOG

SQL> Alter database archivelog;

Base de datos modificada.

4 - Abrimos la base de datos

SQL> alter database open;

Base de datos modificada.

5 - Verificamos

SQL> archivelog list

Modo log de la base de datos Modo de Archivado

Archivado autom▒tico Activado

Destino del archivo USE_DB_RECOVERY_FILE_DEST

Secuencia de log en l▒nea m▒s antigua 163

Siguiente secuencia de log para archivar 165

Secuencia de log actual 165

Conclusiòn : Cambiar a Modo Archive Log una base de datos implica bajar la base por lo tanto una baja del servicio, conviene dejarlo configurado antes de que la base este productiva.

miércoles, 29 de marzo de 2023

Data Guard : Como ejecutar un Failover cuando no se puede resolver el GAP en la Standby

El Failover es un cambio de rol, en el cual una base de datos Standby pasa a ser Primaria cuando la Primaria falla o queda inalcanzable.

A continuación explicaré el procedimiento Manual que se ejecuta mediante comandos SQL.

En este escenario tenemos instalado Oracle Database 19c con un Data Guard configurado con una base de datos Primaria y una Standby, ambas son single instance No-CDB.

La Standby habia reportado un GAP pero no se encontraban disponibles los archive logs que faltaban y a continuación falló la base de datos Primaria por lo que tuvimos que hacer un Failover sin resolver el GAP.

Procedimiento

1 - Verificar Rol de la Base de Datos Standby

server1:orcl:/u05/backup> sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Tue Mar 28 13:21:59 2023

Version 19.16.0.0.0

Connected to:

Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production

Version 19.16.0.0.0

SQL> select database_role from v$database;

DATABASE_ROLE

----------------

PHYSICAL STANDBY

2 - Verificar que esta ejecutando el proceso MRP

server1:orcl:/u05/backup> ps -ef | grep mrp

oracle 4918 1 0 09:29 ? 00:00:01 ora_mrp0_orcl

oracle 12904 9434 0 13:22 pts/2 00:00:00 grep --color=auto mrp

3 - Cancelar MRP

server1:orcl:/u05/backup> sqlplus / as sysdba

SQL*Plus: Release 19.0.0.0.0 - Production on Tue Mar 28 13:25:05 2023

Version 19.16.0.0.0

Connected to:

Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production

Version 19.16.0.0.0

SQL> recover managed standby database cancel;

Media recovery complete.

4 - Cambiar la Base de Datos a Modo Primaria

SQL> alter database recover managed standby database finish;

Da error por el GAP :

alter database recover managed standby database finish

ERROR at line 1:

ORA-00283: recovery session canceled due to errors

ORA-16171: RECOVER...FINISH not allowed due to gap for thr 1, seq 22871-22970

5 - Volvemos a ejecutar el Cancel por si quedo el MRP corriendo

SQL> alter database recover managed standby database cancel;

alter database recover managed standby database cancel

ERROR at line 1:

ORA-16136: Managed Standby Recovery not active

6 - Activamos la Base, de esta forma monta la base de datos como Primaria.

SQL> alter database activate standby database;

Database altered.

7 - Verificamos

SQL> select name,open_mode,database_role from v$database;

NAME OPEN_MODE DATABASE_ROLE

--------- -------------------- ----------------

ORCL MOUNTED PRIMARY

8 - Reiniciamos con force

SQL> STARTUP MOUNT FORCE;

ORACLE instance started.

Total System Global Area 1.0637E+10 bytes

Fixed Size 13626296 bytes

Variable Size 4966055936 bytes

Database Buffers 5637144576 bytes

Redo Buffers 19927040 bytes

Database mounted.

9 - Nos aseguramos que este configurada en Maxima Performance

SQL> alter database set standby database to maximize performance;

Database altered.

10 - Abrimos la Base de Datos

SQL> alter database open;

Database altered.

Conclusión : Es posible realizar el Failover aun teniendo un GAP que no se puede resolver. En pocos pasos ejecutando comandos SQL podemos cambiar el rol de la Standby a Primaria.

lunes, 11 de octubre de 2021

Como Clonar una Maquina Virtual en OCI #JoelKallmanDay

Como Clonar una Maquina Virtual en OCI (Oracle Cloud Infrastructure) #JoelKallmanDay

Este es mi aporte en el dia de nuestra Comunidad Oracle, 11 de Octubre 2021, iniciativa de Tim Hall desde 2016, este año renombrado #JoelKallmanDay en Memoria de Joel Kallman.

Como Clonar una Maquina Virtual en OCI (Oracle Cloud Infrastructure)

Cuando tenemos que crear un clon de una Maquina Virtual de OCI que solo tiene asignado un disco de booteo, podemos clonar el disco de booteo y generar la Maquina Virtual con ese disco clonado. El clonado de un disco de booteo demora unos pocos segundos.

1 - Comenzamos buscando en el Menu - Storage - Block Storage - Block Volumes