Uso de RMAN con PDBs

Con la llegada de los plugable databases se nos abre un mar de dudas, especialmente en un campo tan delicado como el backup.
Hoy vamos a ver en una entrada muy por encima las opciones de backup que tenemos con la nueva funcionalidad de la 12c

Llevar a cabo backups en CDB/PDB

Igual que las bases de datos no cdv se pueden lanzar desde RMAN y/o Enterprise manager Cloud Control El backup del CDB es igual al de un “no-cdb”, de esta backup de rman podríamos recuperar tanto el CDB completo como alguno de los PDBs del backup

  • Backup completo del CDB: Conectando al cdb y BACKUP DATABASE
  • Backup del PDB root: BACKUP DATABASE ROOT
  • Backup de un PDB:
    • conectando al CDB y BACKUP PLUGGABLE DATABASE test1
    • conectando al CDB y BACKUP PLUGGABLE DATABASE test1,test2,test3
    • Conectando al PDB y ejecutando BACKUP DATABASE

Recuperación de CDB and PDB

A la hora de llevar a cabo una recuperación de la base de datos se puede hacer también el CBD completo, solamente el root o un PDB independiente.
Si en la cadena de conexión del RMAN te conectas al CBD recuperarás todo, si te conectas a un PDB específico será este PDB lo que recuperarás
NOTA:Aunque técnicamente es posible restaurar solamente el root, Oracle recomienda no hacerlo , y si has de restaurar el root restaurar también los PDBs de la base de datos.
Puedes restaurar también un PDB con

RESTORE PLUGGABLE DATABASE 

Mientras estas restaurando un PDB el resto de ellos puede dar servicio normalmente
Los comandos a la hora de restaurar datafiles específicos son como los de no-cbd, pero incluyendo el PLUGGABLE database (al tratarse de un PDB).

deshabitando IP6 en Oracle Linux

Hoy vamos a ver una entrada rápida para dummies. Como deshabilitar el IPV6

El IPv6 es algo que seguramente no estemos usando y puede llegar a molestarnos tener activado, no es algo que deba de darnos errores, pero si que introduce ruido en el sistema, que es algo que no deseamos, así pues, vamos a ver de manera sencilla como quitarlo.

cambios en /etc/sysctl.conf

En el fichero de control del sistema añadiremos las siguientes entradas

# Deshabilitamos  IPv6
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

Deshabilitamos de las interfaces

El siguiente paso es deshabilitarlo de las interfaces, para ello iremos al directorio /etc/sysconfig/network-scripts/ y para cada uno de los ficheros ifcfg- configuraremos la línea:

IPV6INIT=no

Deshabilitamos en el grub

En la parte de GRUB_CMDLINE_LINUX añadiremos también el comando para que no lo lance al inicio, así pues, añadiremos al fichero /etc/default/grub lo siguiente

ipv6.disable=1

y regeneramos el grub con

grub2-mkconfig -o /boot/grub2/grub.cfg

Tras esto reiniciamos el sistema, y ya estaremos libres de IPV6

Actualizacion
Parece ser que podemos encontrar problemas con el ssh y las X en Oracle Linux 7 .
Para solucionarlo, tendremos que ir al fichero /etc/ssh/sshd_config y modificar

#AddressFamily any
AddressFamily inet

Parámetros de inicio en los PDB

Hoy vamos a ver una entrada muy breve sobre los parámetros de inicio en la nueva versión 12c

Los PDBS no tienen un fichero de inicialización propio, comparten el spfile único del CDB pero algunos de los parámetros de este spfile son modificables a nivel de PDB
La manera de ver cuales son es mediante la consulta

select name from v$system_parameter where ispdb_modifiable=‘TRUE';

Cada uno de estos (185) son heredados del CDB, y pueden ser modificados mediante .
Si el scoops es SPFILE o BOTH viajarán con la PDB cuando se haga una operación de plug/unplug

Arranque y paradas de los PDB

Hoy vamos a ver una entrada de iniciación a las bases de datos 12c

Veremos las diferencias y similitudes entre no-cdb y doc

Si no forma parte de un RAC, la mecánica de un DBC es la misma que tenemos en una base de datos normal.
La vista en la que se ve el estado de los PDB es la v$PDBS

SQL> select con_id,DBID,NAME,OPEN_MODE from v$pdbs;
   CON_ID       DBID NAME                           OPEN_MODE 
---------- ---------- ------------------------------ ----------
         2 3975244989 PDB$SEED                       READ ONLY 
         3 2001395940 TEST1                          READ WRITE
         4  810296607 TEST2                          MOUNTED  

Estados del CBD

NOMOUNT: Cuando la CBD está en estado nomount los PDB no tienen status, si preguntamos por ellos no tendremos información

SQL> select con_id,DBID,NAME,OPEN_MODE from v$pdbs;
no rows selected

MOUNT:Cuando la CBD está en estado mount los controlfiles de el CDB y PDB ya cuentan con información por lo que los dos están en estado Mount .

  CON_ID	 DBID NAME			     OPEN_MODE

---------- ---------- ------------------------------ ----------
	 2 3975244989 PDB$SEED		             MOUNTED
	 3 2001395940 TEST1			     MOUNTED
	 4  810296607 TEST2			     MOUNTED

OPEN: Con la base de datos abierta la base de datos SEED estará en modo REEAD ONLY, el resto estará en alguno de los estados de los PDB

    CON_ID       DBID NAME                           OPEN_MODE 
    -------- ---------- ------------------------------ ----------
         2 3975244989 PDB$SEED                       READ ONLY 
         3 2001395940 TEST1                          READ WRITE
         4  810296607 TEST2                          MOUNTED  

Estados del PDB

Los PDB se administran de manera similar a la base de datos, algunos ejemplos de nuestro caso serían

ALTER PLUGGABLE DATABASE TEST2 OPEN ;  (La abre en modo read write)
ALTER PLUGGABLE DATABASE TEST2,TEST1 OPEN READ ONLY;
ALTER PLUGGABLE DATABASE ALL OPEN ;
ALTER PLUGGABLE DATABASE ALL EXCEPT test2 OPEN ;

Si el contenedor (CDB) es un PHYSYCAL STANDBY entonces el modo open por defecto la deja en modo read only.
Los modos en los que pueden estar los CDB son:

  • OPEN READ WRITE: como el nombre indica abierta lectura escritura (puedes generar redos)
  • OPEN READ ONLY: como el nombre indica abierta lectura escritura
  • OPEN MIGRATE: Este modo permite ejecutar un upgrade del PDB , si desde el root hacer un ALTER DATABASE OPEN UPGRADE el PDB se pone así
  • MOUNTED: Es como una base de datos normal en modo MOUNT , no permite hacer cambios de los objetos y solo es accesible a los administradores
    La parada es igual que el arranque, en este modo de parada tiene mas sentido el de la cláusula EXCEPT

    ALTER PLUGGABLE DATABASE TEST2 CLOSE ;  (La abre en modo read write)
    ALTER PLUGGABLE DATABASE TEST2,TEST1 CLOSE ABORT;
    ALTER PLUGGABLE DATABASE ALL CLOSE ;
    ALTER PLUGGABLE DATABASE ALL EXCEPT test2 CLOSE ;
    

NOTA: Cuando estas conectado a una pluggable Database el comando SHUTDOWN IMMEDIATE, es el equivalente a si ejecutaras ALTER PLUGGABLE DATABASE CLOSE;


Conexiones JDBC Thin a una base de datos Oracle

Hoy vamos a ver una entrada rápida y útil sobre la manera de configurar los clientes JDBC para acceder a los motores de la base de datos. Tradicionalmente los desarrolladores e integradores Java son muy dados a configurar los pooles de conexión hardcodeando los datos de la conexión en el fichero de propiedades de la misma de la manera IP:puerto:SID
Esta codificación podía ser muy buena en los anales de la historia de Java, pero con la versión del jdbc del cliente 10.2.0.1 se introdujeron una serie de mejoras que, desgraciadamente no suelen ser aplicadas por los desarrolladores/integradores.

Veamos pues la maneras que hay de configurar el jdbc

Oracle JDBC Thin usando SID

Desgraciadamente es la mas utilizada de todos, en esta se fija en cada fichero de pool de conexión tanto la Ip como el puerto como el SID de base de datos, lo que además de hacer muy costoso el cambio de alguno de los tres elementos, imposibilita todas las funciones asociadas a los servicios de Oracle.
jdbc:oracle:thin:@//host:puerto:ORACLE_SID
Ejemplo :

 jdbc:oracle:thin:@//192.168.73.6:1521:TEST

Oracle JDBC Thin usando Service Name:

Esta opción es similar a la anterior, solamente que se cambia el ORACLE_SID por el SERVICE_NAME, dista mucho de ser buena, pero al menos nos permite utilizar servicios.
jdbc:oracle:thin:@ //host:puerto:SERVICE_NAME
Ejemplo :

jdbc:oracle:thin:@//192.168.73.6:1521/TEST

Oracle JDBC Thin usando a TNSName:

Este es el método que deberíamos de recomendar, puesto que mantiene centralizado en el TNSNAMES.ora la gestión de la notación de las bases de datos Oracle
jdbc:oracle:thin:@TNSName
Ejemplo :

jdbc:oracle:thin:@TEST 

Esta funcionalidad fue añadida en la versión 10.2.0.1(lleva disponible desde mediados del 2004) por lo que en un sistema bien mantenido no deberíamos de tener ningún problema la compatibilidad el driver jdbc de Oracle que usemos (al contrario debería de ser un problema si usamos un driver mas antiguo de una 10.2.0.1)

A la hora de utilizar el TNSNAMES, nos encontramos con que el servidor de aplicaciones deberá de conocer la ubicación de este fichero. Para ello usamos la variable de entorno del sistema operativo que referencia a este fichero, la variable TNS_ADMIN .unido a la variable de entorno del sistema, el servidor de aplicaciones debe de contar con una propiedad específica para encontrarla , esta propiedad es oracle.net.tns_admin que se le puede pasar en en arranque del java como como java -Doracle.net.tns_admin=$TNS_ADMIN

Mas información como siempre en las notas de soporte

  • Can JDBC Thin Driver Connect Using Tns Entry in tnsnames.ora File (Doc ID 333686.1)
  • JDBC/thin does not Currently Support the IFILE Clause Inside a TNSNAMES.ORA File (Doc ID 1270872.1)