Pasar variables de entorno windows a un código PL/SQL

Nos hemos mudado a bloger!
El contenido actualizado de esta entrada lo tienes en:

    http://dba.pamplona.name/2013/12/pasar-variables-de-entorno-windows-un.html

    Hoy vamos a ver algo muy muy sencillo pero que puede generar un quebradero de cabeza cuando,acostumbrado a entornos Unix se trabaja con windows.

    Veamos como pasar parámetros por variables de entorno en unix

    consulta.sh

    #!/bin/bash
    export RUTA=/opt/oracle/logs
    export ORACLE_SID=miinstancia
    sqlplus -s user/pass @consulta.sql

    consulta.sql

    spool ${RUTA}/${INSTANCIA}.log
    select sysdate from dual;
    spool off 
    exit;

    ¿Como podemos conseguir lo mismo en un entorno windows?

    consulta.bat

    SET RUTA=d:\oracle\logs
    SET ORACLE_SID=miinstancia
    sqlplus -s user/pass @consulta.sql

    consulta.sql

    spool %RUTA%/%INSTANCIA%.log
    select sysdate from dual;
    spool off 
    exit;

    Como podemos ver, la diferencia es bastante pequeña y el funcionamiento final es el mismo, es un simple problema usar las variables de entorno propias de cada sistema operativo.

Consultas sobre tablas particionadas

Nos hemos mudado a bloger!
El contenido actualizado de esta entrada lo tienes en:

    http://dba.pamplona.name/2013/12/consultas-sobre-tablas-particionadas.html

    Hola de nuevo.
    Tras un largo parón, vamos a volver con otra nueva entrada de SQL para dummies
    Vamos a ver algunas consultas interesantes para cuando se trabaja con tablas particionadas.

    Mover una particion de un tablespace a otro

    ALTER TABLE  MITABLA  MOVE PARTITION   PART_GRANDE 
         TABLESPACE TS_NUEVO NOLOGGING;
    
    

    Tamaño de las particiones

     select  b.TABLE_OWNER,
             b.TABLE_NAME,b.PARTITION_NAME,
             sum(a.bytes)/1024/1024 Mb 
      from
              dba_segments a,
             dba_tab_subpartitions b
      where 
           a.segment_name=b.table_name 
           and a.PARTITION_NAME=b.SUBPARTITION_NAME
      group by b.TABLE_OWNER,b.TABLE_NAME,b.PARTITION_NAME
      order by TABLE_NAME
    
    

    Tamaño de las particiones de una determinada tabla

    select 
       owner,
       segment_name,
       segment_type,
       partition_name,
       bytes/1024/1024 Mb
    from
        dba_segments 
    where segment_name='TABLA'
    

Añadir agentes en OEM12c

Una vez tenemos instalado el OEM12c el siguiente paso lógico es el de añadir nuestros sistemas para su gestión.

El primer paso que tenemos que dar, es el de añadir nuestros hosts, bien sea por autodescubrimiento o bien de manera manual. El problema con el que nos encontramos es que, el OEM12c no tiene instalados los agentes para los distintos hosts de las arquitecturas, por lo que tenemos que hacerlo nosotros manualmente
ScreenHunter_114 Jul. 26 09.57

La actualización en modo on-line no funciona, con lo que, debemos de ir a la actualización «off-line»
En la actualización off-line, el sistema nos aconseja el bajarnos el catálogo de agentes que podemos utilizar y «cargarlos» al OEM . El problema es que, tampoco funciona , devolviendonos el siguiente error:

«The uploaded catalog file does not contain the following files: «components.xml, aru_targets.xml, patch_recommendations.xml, certifications.xml, aru_releases.xml, aru_component_releases.xml, aru_languages.xml, aru_product_groups.xml, aru_platforms.xml, aru_product_releases.xml, aru_products.xml»»

¿Que podemos hacer?
La solución será el instalar el catálogo de agentes desde linea de comandos. Los pasos detallados de lo que debemos de hacer es:

1- Vamos a la pestaña «Configurar-> extensibilidad-> Actualizacion automatica , alli tendremos que cambiar el modo «online» por «oflline»

Una vez hecho eso, OEM12c nos indicará en un desplegable donde podemos descargar el último catálogo de agentes,en mi caso fué https://updates.oracle.com/Orion/Download/download_patch/p9348486_112000_Generic.zip

Lo que tendremos que hacer es abrir una consola de sistema operativo para descargar los agentes y añadirlos al catalogo de OEM, para esto haremos
ya en modo consola y desde nuestro usuario de OEM12c hacemos:

cd /u01/app/oracle/libreria_instalacion/
wget https://updates.oracle.com/Orion/Download/download_patch/p9348486_112000_Generic.zip
cd  $OEM_HOME
$OEM_HOME/bin/emcli login -username=SYSMAN
** Introducimaos contraseña de OEM 
./emcli import_update_catalog -file=/u01/app/oracle/libreria_instalacion/p9348486_112000_Generic.zip  -omslocal

COmo podéis ver, hay un directorio «libreria_instalacion» del que no hemos hablado antes, este directorio lo hemos creado previamente en el servidor y lo hemos dado de alta en las opciones
Configurar->Provisionamiento y aplicacion de parches -> Biblioteca de software

ScreenHunter_115 Jul. 29 12.52

Con esto ya tenemos nuestros agentes en el catálogo, ahora ya podemos descargarlos e instalarlos.
Esta parte ya funciona bien desde la actualizacion «online», con lo que volveremos a
ScreenHunter_115 Jul. 26 10.05

Y seleccionaremos «online».
Una vez activado la instalacion online, se conectará a el repositorio de oracle y tendremos disponibles todos los agentes, lo siguiente será seleccionarlos para la descarga y posteriormente para la instalacion
ScreenHunter_113 Jul. 26 09.40
ScreenHunter_116 Jul. 26 10.50

Consultas para tablespaces temporales

Hoy vamos a volver con las entradas para dummies. Vamos algunas consultas prácticas sobre tablespaces temporales.

Lo primero vamos a ir a las consultas mas básicas, ver los tablespaces temporales, los tempfiles, crear un o o modificar su tamaño

-- Ficheros temporales
select * from dba_temp_files;


-- Creación de Tablespaces temporales gestionados localmente.
create temporary tablespace tempaux 
tempfile '/oradata/orcl/temp_aux01.dbf' SIZE 300M REUSE
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 4M;

--Añadimos un fichero a un tablespace
alter tablespace TEMPAUX 
     add  tempfile  '/oradata/orcl/temp:aux02.dbf' size 200M ;

--Cambio de tamaño
alter database tempfile
 '/oradata/orcl/temp_aux02.dbf' resize 5000M;

Y luego veamos algunas consultas algo mas complejas que nos pueden servir para comprobar el uso de los temporales

--Uso de tablespaces temporal
select t2."TempTotal" "TempTotal (Mb)",
       t1."TempUsed" "TempUsed (Mb)",
       t2."TempTotal" - t1."TempUsed" "TempFree (Mb)"
  from (select nvl(round(sum(tu.blocks * tf.block_size) / 1024 / 1024, 2), 0) "TempUsed"
          from v$tempseg_usage tu, dba_tablespaces tf
         where tu.TABLESPACE = tf.tablespace_name) t1,
       (select round(sum(bytes) / 1024 / 1024, 2) "TempTotal"
          from dba_temp_files) t2;  

--Uso de temporal por sesion 
SELECT S.sid || ',' || S.serial# sid_serial, S.username, S.osuser, P.spid, S.module,
P.program, SUM (T.blocks) * TBS.block_size / 1024 / 1024 mb_used, T.tablespace,
COUNT(*) statements
FROM v$sort_usage T, v$session S, dba_tablespaces TBS, v$process P
WHERE T.session_addr = S.saddr
AND S.paddr = P.addr 
AND T.tablespace = TBS.tablespace_name
GROUP BY S.sid, S.serial#, S.username, S.osuser, P.spid, S.module,
P.program, TBS.block_size, T.tablespace
ORDER BY sid_serial;

Truncate table sin permisos TRUNCATE ANY TABLE

Hoy vamos a ver rápidamente un tema muy sencillo que puede traernos algun que otro dolor de cabeza. Intentar truncar una tabla de otro esquema.

Supongamos que tenemos una aplicación que utiliza dos esquemas:

ADMINISTRADOR-> Propietario de los datos y de todos los objetos del esquema
APLICACION-> Usuario de explotación de los datos que no tiene objetos propios y que accede a los datos de ADMINISTRADOR mediante grants

Este modelo de aplicación es muy común ya que nos garantiza que , el esquema APLICACION nunca va a modificar la estructura del modelo de datos, su funcionamiento se base en dar los grants
DELETE, INSERT, SELECT, UPDATE para todas las tablas del esquema ADMINISTRADOR, lo que permite a el usuario APLICACION borrar todos los datos de una tabla de ADMINISTRADOR, pero no es posible que lleve a cabo una acción de truncado, ya que , para Oracle el truncado es una acción distinta a el borrado (no lo hace sobre los datos sino sobre la propia tabla).

El problema con el que nos encontramos es que, oracle no contempla el otorgar un permiso «TRUNCATE TABLE» a un usuario sobre los objetos de otro usuario, el único permiso que contempla es el de «TRUNCATE ANY TABLE»; lo que es una brecha de seguridad ya que permitiría al usuario APLICACION el truncar cualquier tabla de cualquier otro esquema de la base datos.

¿Como se soluciona el problema?

La solución es muy sencilla, y pasa por hacer una funcion en el esquema ADMINISTRADOR que trunque la tabla que le pasamos por parámetro.
EL procedure sería tal que


create or replace procedure truncartabla(tabla_a_truncar varchar2) 
is
 begin
    execute immediate 'truncate table ' || tabla_a_truncar ;
 end;


Despues de eso , deberemos de dar permisos de ejecución sobre este procedimiento al usuario APLICACION (seguimos como usuario ADMINISTRADOR)


 grant execute on truncartabla to APLICACION

Ahora ya podremos truncar tablas desde el usuario expfin, el único cambio que habrá que hacer es, en el código SQL donde pone


TRUNCATE TABLE ADMINISTRADOR.TABLA1

por


execute ADMINISTRADOR.truncartabla('TABLA1');