Oracle Locator: el “subconjunto” gratuito de Oracle Spatial

octubre 1, 2014 Deja un comentario

Como muchos sabréis, Spatial and Graph es una opción de Oracle Database Enterprise Edition que requiere un licenciamiento extra (información aquí). Oracle Locator es un subconjunto de funciones de Oracle Spatial and Graph, SDO_GEOMque no requiere un cargo adicional. Está disponible en todas las versiones de Oracle Database: Standard Edition One, Standard Edition, Enterprise Edition y XE (Express Edition).

Locator provides core features and services available in Oracle Spatial. It provides significant capabilities typically required to support Internet and wireless service-based applications and partner-based GIS solutions. Locator is not designed to be a solution for geographic information system (GIS) applications requiring complex spatial data management. If you need capabilities such as linear referencing, advanced spatial functions, or Spatial Web services, use Oracle Spatial instead of Locator.

Like Spatial, Locator is not designed to be an end-user application, but is a set of spatial capabilities for application developers.

El inconveniente que hay a la hora de usar Locator, sobre todo cuando se está en medio de una auditoría, es que, a pesar que sólo se tenga instalado y se esté usando Locator, parece que se esté usando Spatial.

*** SPATIAL

======================================================================

ORACLE SPATIAL INSTALLED: TRUE

CHECKING TO SEE IF SPATIAL FUNCTIONS ARE BEING USED…

SDO_GEOM_METADATA_TABLE

———————–

325

1 row selected.

El extracto anterior hace referencia al resultado de consultar la vista dba_feature_usage_statistics. Esta tabla sólo existe en versiones 10gR1 en adelante, por lo que si se quiere comprobar el uso de Locator o Spatial en versiones anteriores, sólo queda la opción de fiarse de la palabra del cliente.

Para verificar si Oracle Locator está instalado, es necesario comprobar que Intermedia (10g y 11gR1) o Multimedia (11gR2 y 12gR1) esté instalado y el usuario MDSYS exista en la base de datos.

Si se quiere garantizar el uso exclusivo de Locator y se tiene instalado Spatial (que por defecto se instala aunque no se seleccione), es recomendable desinstalar Spatial y reinstalar Locator. A continuación indicamos el procedimiento a seguir (en versiones anteriores de la 10gR1 no es posible hacerlo):

10gR1

No es posible pasar de Oracle Spatial a Oracle Locator sin desinstalar completamente Oracle Spatial. La única forma válida sería desinstalar Spatial e instalar Locator (Nota: 179472.1)

10gR2 y 11gR1

Desinstalación de Oracle Spatial manteniendo Oracle Locator. Script sdo_deinst.sql que se aporta en la nota MOS 1070647.1. Los datos se mantienen intactos, las tablas con columnas SDO_GEOMETRY no se verán afectadas.

11gR2 y 12gR1

De la misma forma que en la 10gR2 y 11gR1, desinstalar Oracle Spatial manteniendo Oracle Locator. El script en este caso es  $ORACLE_HOME/md/admin/mddins.sql

NOTA: Después de realizar el procedimiento de desinstalación de Spatial dejando Locator, es recomendable recompilar la base de datos con el script “utlrp.sql”, ya que podrían quedar descompilados algunos objetos.

Eliminar usuarios/contraseñas de base de datos del código de las aplicaciones

septiembre 30, 2014 Deja un comentario

Es habitual que tanto algunas aplicaciones como shell scripts tengan los datos de conexión a base de datos (incluyendo el usuario y la contraseña) almacenados en ficheros de texto. Esto implica, principalmente, un problema de seguridad, ya que cualquiera que tenga acceso a estos ficheros tendrá acceso a los datos de conexión a la base de datos, pero además, supone un serio problema a la hora de modificar las contraseñas de los usuarios, porque esto provoca que haya que modificar el código de las aplicaciones y los shell scripts.

Para solucionar esto, Oracle posee la opción Secure External Password Store (SEPS) que, mediante la creación de un wallet que almacena las credenciales, permite que las aplicaciones y los shell scripts se conecten a la base de datos utilizando ‘/@<cadena_de_conexión>’. SEPS está disponible a partir de la versión 10gR2 y no necesita licenciamiento adicional, es posible utilizarlo con cualquier edición de la base de datos, ya sea Standard o Enterprise.

La configuración de SEPS se deberá efectuar en todos los clientes que se vayan a conectar a la base de datos y quieran hacer uso de esta opción. En la imagen siguiente está configurado en un servidor de aplicaciones y en una máquina con un cliente Oracle.

Uso de SEPS

Vamos a explicar con un paso a paso como realizar la configuración de Secure External Password Store para conectarse a nuestra base de datos. Esto nos permitirá tener acceso sin explicitar las credenciales. Todos los pasos que se muestran se han efectuado con una versión 11gR2 en un Oracle Linux 5. En este caso, el cliente y la base de datos son la misma máquina, pero se procedería de manera similar si el cliente estuviera en otra máquina.

Leer más…

Oracle Day 2014 (Madrid, 6 Noviembre)

septiembre 23, 2014 Deja un comentario

avanttic Oracle Day MAD-20141106

El próximo día 6 de Noviembre 2014, avanttic participará como Patrocinador Silver en el Oracle Day que tendrá lugar en Madrid, en el Teatro Goya.

Aquí tienes un link a la agenda. Podrás escuchar la charla “Digital Disruption, la transformación de las grandes empresas” que impartirá Andrew Sutherland, Senior Vice President (Oracle EMEA), descubrirás las novedades presentadas en Oracle Open World 2014 y, después del café, podrás seguir las sesiones especializadas del track al que te hayas apuntado al inscribirte:

  • Big Data & Business Analytics
  • Cloud
  • Movilidad

Inscríbete aquí en el Oracle Day 2014 y aprovecha para visitarnos en nuestro standÉste va a ser el gran evento del año de Oracle en Madrid, ¡no te lo pierdas!

Son temas apasionantes y de actualidad. Para todos ellos desde avanttic ofrecemos a nuestros clientes asesoramiento y soluciones basadas en tecnología Oracle. Contacta con nosotros en este e-mail Mónica Esteve o llamando al teléfono 618 907 428.

Categorías:Eventos Etiquetas: , , ,

Bug de Reports: REP-52262

septiembre 16, 2014 Deja un comentario

En los últimos proyectos de migración de Forms me he encontrado que al recuperar la ejecución de un report para mostrar el resultado me aparecía el siguiente error:

REP-52262: Diagnostic output is disabled when using reports server 11g on new installation    

Por ejemplo se puede reproducir el error con la siguiente URL:

http://yourhostname:port/reports/rwservlet/showjobs?server=Reports_Server_Name

El error es debido a un bug de Oracle en la instalación del Servidor de Reports, a partir de la versión 11.1.1.1.0 incluida e independientemente de la plataforma de instalación. Nosotros por ejemplo lo hemos vivido en instalaciones tanto Windows, como RedHat como IBM AIX.

Para solucionarlo simplemente es necesario seguir los siguientes pasos:

  1. Realizar una copia de seguridad del fichero rwservlet.properties localizado en: %DOMAIN_HOME%\config\fmwconfig\servers\WLS_REPORTS\applications\reports_11.1.2\configuration
  2. Editar el fichero rwservlet.properties
  3. Localizar la línea: <!–webcommandaccess>L1</webcommandaccess–>
  4. Descomentarla de la siguiente forma: <webcommandaccess>L1</webcommandaccess–>
  5. Modificar el valor L1 por L2: <webcommandaccess>L2</webcommandaccess–>
  6. Guardar el fichero
  7. Reiniciar el Reports Server (WLS_REPORTS)

Las modificaciones arriba descritas pueden realizarse también desde la consola de administración Enterprise Manager 11g Fusion Middleware Control. En este caso los pasos a seguir son los siguientes:

  1. Seleccionamos el link reports(11.1.2)(WLS_REPORTS)
  2. REP52262_11Desde el menú Reports de la parte central superior seleccionamos “Configuración avanzada”
  3. REP52262_22En la parte de seguridad seleccionamos L2

REP52262_33

Para más información podéis revisar el SR de My Oracle Support (Metalink) que habla de este bug:

https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=2265872327770643&id=1242614.1&_afrWindowMode=0&_adf.ctrl-state=114vp4k9m6_4

Oracle Database 12c – Multitenant: Creación de una Pluggable DataBase

septiembre 3, 2014 Deja un comentario

La creación de una base de datos “plugable” es el siguiente paso natural posterior a la creación de una base de datos “Container”, que ya explicábamos en este otro post. A continuación se explican los pasos para su creación.

¿Cómo se crean las bases de datos “plugables”?

Para poder crear este tipo de base de datos, al ejecutar el dbca sería necesario elegir la opción “Manage Plugglabe Database” que aparece en el menú inicial.

crea_pdb12c

 

Posteriormente “Create Pluggable Database”.

pdb12

 

Y seguiría con la elección del contenedor o “CDB” donde se quiere crear.

CDB

 

Los pasos posteriores son prácticamente idénticos a versiones anteriores.

¿Y ahora qué?

Leer más…

Upgrade desde ODI 11g a ODI 12c

Hace unos meses Oracle presentó la nueva versión de Oracle Data Integrator. En este post vamos a detallar los pasos necesarios para migrar los objetos de ODI desde la versión 11g a la versión 12c.

En la instalación de ODI 11g que queremos migrar tenemos creadas tres interfaces que cargan datos de ficheros de texto y tablas Oracle a tablas Oracle. Las interfaces son sencillas, pero tienen joins, filtros y expresiones que necesitamos que se traspasen correctamente si no queremos perder la funcionalidad implementada.

ODI 11g Interface

Para poder migrar una instalación de ODI 11g a 12c es necesario que se cumplan unos requisitos:

  1. La versión de la base de datos donde se instalaron los Master y el Work Repository para ODI 11G tiene que estar soportada y certificada para Oracle Fusion Middleware 12c (comprobarlo en http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html).
  2. La base de datos de los esquemas del Master y del Work Repository 11g tiene que ser UTF-8.

Si así no fuera, hay que migrar previamente a una base de datos que tenga estas características.

Antes de empezar, es aconsejable realizar un backup tanto del Master como del Work Repository 11g porque después de que se haya realizado el upgrade ya no será posible utilizar los esquemas en una instalación de ODI 11g. Para clonar los esquemas involucrados, se han seguido los siguientes pasos:

  1. Export de los esquemas del Master (ODIM) y del Work (ODIW) Repository

    exp userid=ODIM/ODIM file=ODIM11.dmp

    exp userid=ODIW/ODIW file=ODIW11.dmp

  2. Creación de nuevos usuarios

    create user ODIM11 identified by …;
    create user ODIW11 identified by …;
    grant connect, resource to ODIM11, ODIW11;

  3. Import de los esquemas copiados

    imp userid=’system/xxx’ touser=ODIM11 fromuser=ODIM file=ODIM11.dmp

    imp userid=’system/xxx’ touser=ODIW11 fromuser=ODIW file=ODIW11.dmp

  4. Reconfigurar la conexión de ODI 11 a los nuevos esquemas ODIM11 y ODIW11 para comprobar que se hayan clonado correctamente.

Para ejecutar el upgrade, hay que ejecutar el fichero ua.bat (Upgrade Assistant) que se encuentra en la carpeta

    <Oracle_Middleware_Home>\oracle_common\upgrade\bin\ua.bat

de la instalación de ODI 12c. Para poder ejecutar el Upgrade Assistant es imprescindible instalar las parches que vienen con el installer de ODI 12c.

Leer más…

Categorías:BI Etiquetas: , , , , ,

ADF tips: Auditemos nuestros datos

En este tip comentaremos las opciones que nos brinda Oracle ADF para poder auditar la creación y modificación de datos. Contar con un sistema de auditoría de datos, en esta época en la que la seguridad y el saber quién y cuándo ha hecho qué, se  ha vuelto prácticamente imprescindible.

Para ello en ADF existen las “History Columns”, que se encargarán de almacenar debidamente la información para poder auditar nuestros datos. Cuando habilitamos este tipo de columnas será el framework el encargado de informarlas debidamente. El momento de asignación es durante la fase de “prepareForDML”.

Por defecto existen cinco tipos de columnas:

adf_tips_history_00

  • created on: Debe seleccionarse en un campo de tipo “Date” o “Timestamp”, una vez seleccionada la columna queda marcada como no actualizable nunca. El sistema almacenará la fecha y hora en la que el dato fue creado  (el valor es obtenido de la base de datos).
  • created by: Debe seleccionarse en un campo de tipo “String”, una vez seleccionada la columna queda marcada como no actualizable nunca. El sistema almacenará el nombre de usuario que creó la fila, para ello recupera al atributo “Principal” del contexto de seguridad (en caso de que no haya usuario se utilizará “anonymous”).
  • modified on: Debe seleccionarse en un campo de tipo “Date” o “Timestamp”. El sistema almacenará la fecha y hora en la que el dato fue modificado por última vez.
  • modified by: Debe seleccionarse en un campo de tipo “String”.  El sistema almacenará el nombre de usuario que modificó por última vez el dato.
  • version number: Debe seleccionarse en un campo de tipo “Long” o “Number”. Este campo indica el número de veces que este registro ha cambiado. En el momento de crearse el valor será 1, y con cada modificación irá aumentando.

Este tipo de columnas no pueden seleccionarse cuando el atributo en cuestión es parte de la clave primaria. Y además debemos no marcar las opciones de “Refresh After Update / Insert”, dado que si las marcaremos no servirá más que para ocasionar una pérdida de rendimiento o incluso almacenar datos incorrectos.

Estas opciones son las que nos brinda Oracle ADF por defecto, pero adicionalmente podemos definir columnas de auditoría personalizadas. Para ello tendremos que seguir los siguientes pasos:

  • Definir el tipo desde las opciones de JDeveloper:

adf_tips_history_01

  • Implementar el código asociado a nuestro tipo personalizado definiendo una constante que identifique nuestro tipo y sobreescribiendo el método getHistoryContextForAttribute:
private static final byte MY_AUDIT_COLUMN_HISTORY_TYPE = 11;

@Override
protected Object getHistoryContextForAttribute(AttributeDefImpl attr) {
    if (attr != null && attr.getHistoryKind() == MY_AUDIT_COLUMN_HISTORY_TYPE) {
        //Código de mi columna de auditoría personalizada.
    }else {
        return super.getHistoryContextForAttribute(attr);
    }
}
Categorías:ADF Etiquetas: , ,
Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 134 seguidores