Acerca de admin

Tras más de 20 años trabajando con tecnologías Oracle, me decidí a recopilar en un Blog algunas de las cosillas útiles para el día a día.

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

Script de arranque con el systemctl

Hoy vamos a ver (con mucho retraso) como hacer un script de arranque para el systemctl para nuestra base de datos 12c

Vamos a poner el supuesto de que tenemos una base de datos 12c, en filesystem en una OL7. Al no haber instalado el grid control, nadie arrancará nuestra base de datos.
¿Como hacemos para que arranque en el inicio ?
Simplemente hay que crearlos servicios de arranque

Scripts de arranque

Al igual que en un linux clásico, necesitaremos un script de start y stop para nuestra base de datos, nosotros crearemos :

  • listener.sh para el listener
  • cdbtest.sh para nuestra instancia cdbtest.

Por compatibilidad con los sistemas antiguos, lo dejaremos en /etc/init.d (auqnue toda la información que he visto en internet lo deja ene l propio $HOME de oracle ) y le añadiremos una guarda que compruebe que solamente pueda arrancase con el usuario oracle (y evitar asi que alguien lo use como root)

/etc/init.d/listener.sh

#!/bin/bash
##  Configuramos el nombre del usuario que arranca la BBDD
export USUARIO=oracle
if [ $UID -ne  `id -u $USUARIO`  ];then
 echo "Programa invocado con  incorrecto, debe de invocarse como $USUARIO "
 exit 1 ;
fi
export ORAENV_ASK=no
export export ORACLE_HOME=/u01/app/oracle/product/12.1.0/dbhome_1
case $1 in 
start)
	$ORACLE_HOME/bin/lsnrctl start 
;;
stop)
        $ORACLE_HOME/bin/lsnrctl stop
;;
status)
        $ORACLE_HOME/bin/lsnrctl status
;;
*)
  echo "Usage $0 start|stop|status "
  ;;
esac

/etc/init.d/cdbtest.sh

#!/bin/bash
##  Configuramos el nombre del usuario que arranca la BBDD
export USUARIO=oracle
if [ $UID -ne  `id -u $USUARIO`  ];then
 echo "Programa invocado con  incorrecto, debe de invocarse como $USUARIO "
 exit 1 ;
fi
export ORACLE_SID=cdbtest
export ORAENV_ASK=NO
. oraenv
case $1 in 
start)
$ORACLE_HOME/bin/sqlplus "/as sysdba" << EOF
	startup;
	exit;
EOF
;;
stop)
$ORACLE_HOME/bin/sqlplus "/as sysdba" << EOF
	shutdown immediate;
	exit;
EOF
;;
*)
  echo "Usage $0 start|stop "
  ;;

Creamos los servicios de systemctl

Ahora que tenemos ya los scripts que arrancaran y pararan el listener y la base de datos, crearemos nuestros servicios de arranque.
Crearemos uno especifico para el listener y otro para nuestra instancia cdbtest.
Para identificar cuales son nuestros servicios , los llamaremos dbora-XXX . Esto no es una convención genérica ni una best practice , sino que es simplemente un patrón propio para facilitarme su futura identificación.

Servicio dbora-listener.service

Crearemos un fichero llamado /lib/systemd/system/dbora-listener.service

[Unit]
Description=The Oracle Listener
After=syslog.target network.target

[Service]
LimitMEMLOCK=infinity
LimitNOFILE=65535

RemainAfterExit=yes
User=oracle
Group=oinstall
ExecStart=/etc/init.d/listener.sh start 
ExecStop=/etc/init.d/listener.sh stop 
Type=idle
RemainAfterExit=yes
User=oracle
Group=oinstall
[Install]
WantedBy=multi-user.target

Servcio dbora-cdbtets.service

Ahora crearemos un servicio de arranque para nuestra instancia /lib/systemd/system/dbora-cdbtets.service

[Unit]
Description=Base de datos cdbtest
After=syslog.target network.target dbora-listener.service

[Service]
LimitMEMLOCK=infinity
LimitNOFILE=65535
RemainAfterExit=yes
User=oracle
Group=dba
ExecStart=/etc/init.d/cdbtest.sh start  >> /tmp/startup_cdbtestlog 2>&1 &
ExecStop=/etc/init.d/cdbtest.sh stop  >> /tmp/shutdown_cdbtestlog 2>&1 &
Type=idle
[Install]
WantedBy=multi-user.target

Configuramos los servicios

Ya tenemos los scripts de arranque y los scripts de los servicios. Ahora simplemente nos quedará el habilitarlos para su funcionamiento.
Para ello, primero haremos un reload para refrescar los servicios

# systemctl daemon-reload
Y luego los cargaremos y habilitaremos
systemctl start dbora-listener.service
systemctl enable dbora-listener.service
systemctl start dbora-cdbtest.service
systemctl enable dbora-cdbtest.service

Así pues, si queremos ver el estado del service, podremos ver como :

[root@alone ~]# systemctl status dbora-cdbtest.service
● dbora-cdbtest.service - Base de datos cdbtest
   Loaded: loaded (/usr/lib/systemd/system/dbora-cdbtest.service; enabled; vendor preset: disabled)
   Active: active (exited) since mar 2017-02-21 13:16:19 CET; 9min ago
  Process: 1039 ExecStart=/etc/init.d/cdbtest.sh start >> /tmp/startup_cdbtestlog 2>&1 & (code=exited, status=0/SUCCESS)
 Main PID: 1039 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/dbora-cdbtest.service
           ├─2303 ora_pmon_cdbtest
           ├─2305 ora_psp0_cdbtest
           ├─2307 ora_vktm_cdbtest
           ├─2311 ora_gen0_cdbtest
           ├─2315 ora_mman_cdbtest
           ├─2317 ora_diag_cdbtest
           ├─2319 ora_dbrm_cdbtest
           ├─2321 ora_vkrm_cdbtest
           ├─2323 ora_dia0_cdbtest
           ├─2325 ora_dbw0_cdbtest
           ├─2327 ora_lgwr_cdbtest
           ├─2329 ora_ckpt_cdbtest
           ├─2331 ora_smon_cdbtest
           ├─2333 ora_reco_cdbtest
           ├─2335 ora_lreg_cdbtest
           ├─2337 ora_pxmn_cdbtest
           ├─2339 ora_mmon_cdbtest
           ├─2341 ora_mmnl_cdbtest
           ├─2343 ora_d000_cdbtest
           ├─2345 ora_s000_cdbtest
           ├─2357 ora_tmon_cdbtest
           ├─2359 ora_tt00_cdbtest
           ├─2361 ora_smco_cdbtest
           ├─2363 ora_w000_cdbtest
           ├─2365 ora_w001_cdbtest
           ├─2369 ora_aqpc_cdbtest
           ├─2373 ora_p000_cdbtest
           ├─2375 ora_p001_cdbtest
           ├─2377 ora_p002_cdbtest
           ├─2379 ora_p003_cdbtest
           ├─2381 ora_qm02_cdbtest
           ├─2385 ora_q002_cdbtest
           ├─2387 ora_q003_cdbtest
           └─2452 ora_cjq0_cdbtest

feb 21 13:16:33 alone.pamplona.name cdbtest.sh[1039]: Copyright (c) 1982, 2014, Oracle.  All rights reserved.
feb 21 13:16:51 alone.pamplona.name cdbtest.sh[1039]: Connected to an idle instance.
feb 21 13:17:00 alone.pamplona.name cdbtest.sh[1039]: SQL> ORACLE instance started.
feb 21 13:17:00 alone.pamplona.name cdbtest.sh[1039]: Total System Global Area 6291456000 bytes
feb 21 13:17:00 alone.pamplona.name cdbtest.sh[1039]: Fixed Size                    2938352 bytes
feb 21 13:17:00 alone.pamplona.name cdbtest.sh[1039]: Variable Size                 3372222992 bytes
feb 21 13:17:00 alone.pamplona.name cdbtest.sh[1039]: Database Buffers         2902458368 bytes
feb 21 13:17:00 alone.pamplona.name cdbtest.sh[1039]: Redo Buffers                   13836288 bytes
feb 21 13:17:05 alone.pamplona.name cdbtest.sh[1039]: Database mounted.
feb 21 13:17:30 alone.pamplona.name cdbtest.sh[1039]: Database opened.