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)

Runaway queries : Consultas que tardan mas de lo esperado

Hoy vamos a ver otra entrada para dummies.

¿Que es una Runaway query?

Una «Runaway query» es una consulta que tarda mas de lo esperado, pero …
¿Como podemos definir «lo esperado»?

La definición que toma oracle de ese «mas de lo esperado » es que su ejecución se demora mas allá de lo esperado por el planificador , pero , en terminos corrientes llamamos así a las consultas que «no terminan nunca».

Como véis, inaguramos el mes con una entrada muy sencilla, pero es un concepto importante a tener en cuenta

Acciones en sys.aud$

Hoy vamos a ver una entrada rápida y sencilla sobre una de las tablas que mas vamos a usar en la auditoría.

Cuando preguntamos a la tabla sys.aud$ por un evento ( por ejemplo ver los logins), lo hacemos en base a un código del campo action#.
pero , ¿cual es el listado de codigos y la descripcion?
La respuesta es muy sencilla, y se encuentra en la tabla audit_actions
Si queremos saber el listado de descripciones para nuestra tabla solo deberemos de hacer

SELECT action, name 
  FROM audit_actions
ORDER BY 1;

Otro ejemplo facil de uso, es, si queremos saber el código de accion para un borrado de usuario,lo podemos obtener con :

SELECT action 
          FROM audit_actions
        WHERE name='DROP USER';

Com veis, una tabla muy util y tremendamente sencilla de consultar