Database Insider - Julio Ayapan

En el siguiente articulo, breve pero conciso, veremos como podemos evitar el error  "Locale not recognized" que según investigue es muy común en la aplicación Oracle SQLDeveloper. Aunque es un error muy común, no lograba encontrar una solución precisa que solventara el problema. Vamos al grano con ello: el error es el siguiente, al intentar conectarme a una base de datos Oracle. No había error en ningún dato proporcionado, el usuario existe, el servicio esta activo, el listener esta funcionando normalmente. En pocas palabras, la base de datos no era el problema. Navegando como ya lo mencione en varios blogs de tecnología e incluso en los foros de OTN encontré una posible solución. Debía establecer las siguientes variables de entorno: AddVMOption -Duser.Xlanguage=en AddVMOption -Duser.region=US AddVMOption -Duser.language=en AddVMOption -Duser.country=US Sin embargo, cabe mencionar que esta solución estaba propuesta para un equipo con sistema operati

La Universidad Mariano Gálvez de Guatemala sede de Villa Nueva en colaboración con la facultad de Ingenieria (especial mención al Ingeniero Hector Santos) me invito a participar el pasado 05 de marzo a una serie de conferencias para los estudiantes del curso Base de Datos II. El objetivo de las charlas fue mostrar a los estudiantes las soluciones de alta disponibilidad y tolerancia a fallos que ofrece Oracle (Maximum Availability Architecture - MAA) . Como parte del Grupo de Usuarios Oracle de Guatemala nuestro objetivo es dar a conocer a la comunidad las características y beneficios de las tecnologías Oracle y en este caso los temas a tratar fueron Oracle Data Guard y Oracle Clusterware.  Espero que las charlas hayan sido de mucha utilidad para los estudiantes que tienen programado un proyecto donde deben demostrar su conocimiento sobre el tema y aplicarlo en una infraestructura real.  Siempre es un gusto colaborar en este tipo de eventos y espero pueda

El principal objetivo de este articulo es mostrar de una manera practica como se comportan los usuarios denominados COMMON dentro de una arquitectura Multitenant, nueva característica en Oracle 12c. Existen dos tipos de usuarios en una arquitectura Multitenant: LOCAL y COMMON. Los usuarios comunes (COMMON) son usuarios que deben ser creados en el contenedor o root. A partir de aquí los usuarios son replicados hacia todas las base de datos PLUGGABLE que pertenezcan al contenedor. Los esquemas pertenecientes a estos usuarios son independientes unos de otros dentro de cada pluggable database (PDB). Es decir pueden poseer privilegios y objetos diferentes en cada esquema en cada PDB. Los casos que vamos a analizar son los siguientes: Qué pasa cuando creamos una nueva PDB? Qué pasa cuando creamos un COMMON user y las PDB están apagadas (mount)? Qué pasa cuando creamos un COMMON user y las PDB están en modo READ ONLY? Qué pasa cuando hacemos un 'UNPLUG' y 'PLUG'

La arquitectura 'Multitenant', nueva en Oracle Database 12c permite crear y mantener multiples bases de datos denominadas 'PLUGGABLE' en un contenedor o 'CONTAINER'. Esta característica involucra muchas ventajas, una de las cuales es que reduce costos de administración. Esta ventaja precisamente que motiva a explicar como funciona la modificación de parámetros de instancia en  una arquitectura de este tipo.  Debemos considerar los siguientes puntos importantes antes de comenzar con la explicación: En una arquitectura Multitenant existe una sola instancia por lo tanto existe un solo archivo de parámetros (PFILE o SPFILE). Existen ciertos parámetros que pueden ser modificados a nivel de Pluggable Database, veremos cuales son mas adelante. Para que el concepto sea entendido he trabajado con el siguiente escenario: una arquitectura Multitenant con dos bases de datos Pluggable: PDB1 y PDB2. Parámetros modificables a nivel de PDB Existen al red

El 10 de septiembre de 2016, se llevo a cabo en el Gran Salón Torreon del Irtra, en Retalhuleu Guatemala, la convención anual de tecnología informática organizada por la Universidad Mariano Gálvez. Actividad que tiene por objetivo compartir conocimientos, experiencias y nuevas tendencias en tecnología con los estudiantes y profesionales en ingeniería de sistemas informáticos. Cada año, el congreso se especializa en un area diferente que va desde emprendimiento, tecnologías de desarrollo, entre otras. Este año se enfocaron en nuevas tendencias en plataformas de bases de datos por lo que tuve el enorme placer de poder colaborar con una charla denominada "Conceptos básicos de bases de datos Oracle 11GR2". Siempre es un gusto incentivar a los profesionales en sistemas a involucrarse en el mundo de tecnologías Oracle y motivarlos a involucrarse en el grupo de usuarios Oracle de Guatemala, esta,  como siempre, fue una de las premisas en la charla. Espero con ansias volver

En más de alguna ocasión me he topado con la necesidad de renombrar un Diskgroup de ASM, si el Diskgroup está vacío (no se ha almacenado ningún archivo de base de datos) la opción más sencilla -opinión personal-   es eliminarlo y volver a crearlo con el nombre correcto. Pero, ¿que sucede si ya tenemos archivos de base de datos en este Diskgroup? La solución a este problema surgió con la versión 11gR2 de ASM y se mejoró en la versión 12c. Para renombrar un Diskgroup utilizaremos la herramienta renamedg y la complementáremos con la sentencia ALTER DISKGROUP .. RENAME DISKS. A continuación, un sencillo ejemplo para renombrar un ASM Diskgroup y ASM Disks que lo conforman. Escenario: Nuestra base de datos de producción está utilizando como almacenamiento el disco +DATOS1, por control de la aplicación se requiere que el nombre sea +DATA1. Los datafiles residentes en el Diskgroup son: FILE_NAME -------------------------------------------- +DA