Database Insider - Julio Ayapan

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 -------------------------------------------- ...