Creacion de una Physical Standby Database - Oracle 12C

Tenemos los siguientes servidores con Oracle Linux 7.2 (Maipo)

Hostname	IP	Rol
rastasrvr	192.168.56.95	Primaria
gengar	192.168.56.97	Standby

Hemos deshabilitado el firewall y el SELINUX para realizar la configuración debida, además de haber colocado las loopback necesarias y actualizado la información del "/etc/hosts".

En la siguiente imagen del lado izquierdo tenemos el servidor primario, y del lado derecho el servidor secundario para standby.

En los servidores, se ha instalado Oracle de la siguiente manera

Nombre base de datos	Hostname	Oracle	Rol
magneta	rastasrvr	Instalado y con BD	Primaria
dragon	gengar	Instalado solo con la opción “software only”	Standby

Cabe destacar los siguientes aspectos antes de continuar:

Nombre base de datos	DB_NAME	DB_Unique_Name
magneta	magneta	magneta
dragon	magneta	dragon

Lo anterior es debido a que:

DB_UNIQUE_NAME = Especifica un nombre unico y global para la base de datos.

DB_NAME = Debe ser el mismo en ambos servidores

En el servidor primario (rastasrvr) que posee la base de datos "magneta" los datafiles fueron colocados en la particion de disco "/dbf" junto a los online redo logs y el controlfile.

A su vez existe un datafile en la ruta "/dbf/nodefaults/". Esto debido a que fue un datafile/tablespace no instalado por Oracle en la instalacion de la base de datos.

El primer paso como tal es crear la carpeta "adump" en el servidor standby, ya que en el servidor primario la ruta ya existe...incluso en mi caso posee archivos de auditoría.

Se crea el folder del FRA:

Creamos un pfile de la base de datos primaria, para esto podemos utilizar 2 maneras:

#1:

#2:

En mi caso, utilizaré el pfile creado de la segunda forma. Posteriormente he creado una carpeta en la ruta "/u01/tostdby" donde he movido el anterior pfile creado.

Localizo en el servidor primario, el archivo de password y lo copio a la ruta "/u01/tostdby":

Posteriormente copio todo lo que existe en la ruta /u01/stdby al servidor secundario:

En el servidor secundario se recibe la copia:

El archivo orapwd en el servidor secundario, se coloca en la ruta debida, incluso se le crea uno pero con el nombre respectivo.

Creo un listener estatico en el servidor secundario y lo "levanto";

En cada servidor me verifico que existan las 2 entradas en el archivo tnsnames, tanto la de la base de datos primario como la secundaria, si las entradas no existen las creo.

Tnsnames standby:

Tnsnames produccion:

Realizo la conexion de SqlPlus en el servidor standby:

La coloco en "nomount" utilizando el pfile creado anteriormente.

Reviso nuevamente los "listeners" de standby y produccion:

Listener magneta:

Listener dragon:

Realizo la conexion RMAN utilizando el auxiliar correspondiente:

En produccion (magneta) buscamos cuales datafiles existen, la ruta y su file#.

Igualmente en magneta, verifico que los archives se generen correctamente:

Buscamos en produccion el parametro "DB_CREATE_FILE_DEST", esta ruta debe crearse en la standby, sino se encuentra de la misma manera el "duplicate" de RMAN será finalizado con errores:

Si la ruta no existe la creamos en el servidor standby (dragon). También he creado la carpeta "nodefaults" ya que recordemos que existe en magneta un datafile allí...posteriormente todos los datafiles los moveremos de ruta más adelante.

He creado esta carpeta para mover en el respaldo de RMAN todos los datafiles/tablespaces en ella.

Aplico el comando RMAN en el servidor standby.

run
{
allocate channel c1 type disk;
allocate channel c2 type disk;
allocate channel c3 type disk;
allocate channel c4 type disk;
allocate channel prim type disk;
allocate auxiliary channel aux type disk;
duplicate target database for standby from active database spfile
parameter_value_convert 'magneta','dragon'
set db_file_name_convert='magneta','dragon', '/dbf/defaults/MAGNETA/datafile', '/dbf/defaults/dragondbf', '/dbf/nodefaults', '/dbf/defaults/dragondbf'
set log_file_name_convert='magneta','dragon'
set log_archive_max_processes='10'
set db_unique_name='dragon'
set standby_file_management='AUTO'
set control_files='/dbf/dragonctl/control01.ctl'
set log_archive_config='dg_config=(magneta,dragon)'
set log_archive_dest_1='location=USE_DB_RECOVERY_FILE_DEST valid_for=(all_logfiles,all_roles) db_unique_name=dragon'
set log_Archive_dest_2='service=magneta async noaffirm reopen=15 valid_for=(all_logfiles,primary_role) db_unique_name=magneta'
set log_archive_config='dg_config=(magneta,dragon)';
SET NEWNAME FOR DATAFILE 1 TO 'system01.dbf';
SET NEWNAME FOR DATAFILE 3 TO 'sysaux.dbf';
SET NEWNAME FOR DATAFILE 4 TO 'undotbs1.dbf';
SET NEWNAME FOR DATAFILE 5 TO 'tde_ediez.dbf';
SET NEWNAME FOR DATAFILE 6 TO 'users.dbf';
sql channel aux "alter database add standby logfile ''/dbf/dragonredo/stdbyredo1.log'' size 50M";
sql channel aux "alter database add standby logfile ''/dbf/dragonredo/stdbyredo2.log'' size 50M";
sql channel aux "alter database add standby logfile ''/dbf/dragonredo/stdbyredo3.log'' size 50M";
sql channel aux "alter database add standby logfile ''/dbf/dragonredo/stdbyredo4.log'' size 50M";
sql channel prim "alter system archive log current";
sql channel aux "alter database recover managed standby database disconnect";
}

Cuando el RMAN finaliza muestra en sus ultimas lineas lo siguiente:

Los siguientes "Alter" se aplican en la base de datos primaria, para habilitar la aplicacion de archives de produccion (magneta) a standby (dragon)

Generamos archives en servidor magneta:

Verificamos que se apliquen los archives en servidor dragon:

Según la documentacion oficial de Oracle:

No es posible crear una standby física a nivel de las PDB, solamente a nivel de CDB. La CDB deberá ser clonada/creada como standby física.

You cannot create a physical standby at PDB(plugable Database) level. It should be at CDB(Container Database) level i.e entire primary CDB should be cloned/created as physical Standby.

Transparent Data Encryption 12C Oracle

Creación del wallet específico para el “Transparent Data Encryption”

Primeramente en el “$ORACLE_BASE/admin/SID/” se requiere crear la carpeta del wallet debido

Posteriormente a la creación de la carpeta debe agregarse y especificar el nuevo Wallet en el archivo “sqlnet.ora”

Para efectos de prueba se crea un tablespace con datafile específico:

Se crea el usuario con el que se trabajaran las tablas; al mismo brindamos los siguientes permisos:

• ·        QUOTA
• ·        Tablespace default
• ·        Grant de conexión
• ·        Grant de creación de tablas

Realizado lo anterior, procedemos a crear la tabla sin encriptación de datos

Manipulacion del wallet

El “wallet” como tal requiere tener autenticación, esto se realiza de la siguiente forma: 

Al ejecutar el “alter” anterior, entonces observamos que en la ruta del wallet se ha creado un archivo.

Creamos la tabla con la encriptación habilitada:

Para observar el estatus del “wallet” se ejecuta:

Verificación de data no encriptada físicamente

Como un aspecto importante es posible verificar la data en un tablespace/datafile si el mismo como tal no fue creado en modo de encriptación.Esto lo veremos en otra entrada del blog proximamente...

Si realizamos las consultas de la tabla con el “wallet” cerrado:

Close Wallet:

Nótese como la tabla con encriptación activada no puede ser consultada.

Mientras que si realizamos las consultas de la tabla con el wallet abierto:

Open Wallet:

La información puede ser consultada de manera correcta.

Esto para SQL Server seria como utilizar certificados simetricos y demas herramientas relacionadas.