Archivo

Archive for the ‘Database’ Category

Reinicio automático de Oracle Database (Oracle Restart)

Oracle Clusterware es una capa de software que permite añadir alta disponibilidad, inicialmente pensada para Base de Datos (Oracle Real Application Clusters -RAC-). 

Esta capa de software la podemos implementar de distintas maneras y para distintos propósitos que no tienen que se necesariamente Base de Datos. Entre las posibles configuración tenemos:

  • Oracle RAC
  • Oracle RAC One Node
  • Oracle Standalone
  • Oracle Restart

En este post nos ocuparemos de Oracle Restart. Esta opción de configuración se limita a la instalación y configuración del software de Clusterware sin configurar ASM, solo los servicios de HA para proveer un arranque automático tanto a las DDBB como Listeners que tengamos configurados en el servidor.

En este ejemplo partiremos de un entorno de Base de Datos Oracle 11g R2 en el que ya tenemos instalado y configurado 2 Bases de Datos y, asumiendo que realizamos Backups y las Bases de Datos esta en modo archivado, sólo nos queda integrar Oracle Restart para poder cumplir un nivel Bronce.

Lo primero que haremos será instalar esta capa en el servidor descrito previamente.

Para ello descargaremos los Binarios correspondientes desde OTN . A continuación movemos este software al servidor y descomprimimos el zip.

Lanzamos el runInstaller:

2015-11-23 21_04_07-Oracle Grid Infrastructure - Setting up Grid Infrastructure - Step 1 of 10

Leer más…

Oracle Database Standard Edition 2 (SE2) – Licenciamiento y conversión desde SE/SE1

Oracle_DB_12c_SE2Desde el pasado mes de septiembre es posible descargar el parche 12.1.0.2 de Oracle Database Standard Edition. Este parche no sólo soluciona bugs detectados, sino que aporta gran cantidad de nuevas funcionalidades y hasta la fecha sólo estaba disponible para la versión Enterprise Edition.

Juntamente con la publicación del parche se notificó una modificación relevante del sistema de licenciamiento: desde el 01/12/2015 las versiones Standard Edition y Standard Edition One ya no pueden adquirirse y en su lugar ha aparecido en la tarifa de precios la nueva versión Oracle Database Standard Edition 2. Las versiones Enterprise Edition (EE) y Personal Edition (PE) no han sufrido variación alguna. Por tanto, ahora disponemos de las siguientes versiones de Oracle Database:

  • Enterprise Edition
  • Standard Edition 2
  • Personal Edition

Las licencias de Oracle Database Standard Edition 2 tienen el mismo coste que tenían las licencias de Oracle Database Standard Edition.

Vamos a revisar las normas de licenciamiento de Oracle Database Oracle Database Standard Edition 2 (SE2) y cómo afecta este nuevo licenciamiento a los clientes con licencias compradas de las versiones Standard Edition (SE) o Standard Edition One (SE1).
Leer más…

Aprovisionamiento de Bases de Datos “Pluggables” o PDB’s

octubre 2, 2015 Deja un comentario

Ahora con la versión 12c, y gracias a la opción “Multitenant“, disponemos de cuatro formas de aprovisionar/crear bases de datos plugables o PDB:

  1. Crear PDB a partir de la plantilla que dispone el “Container” o CDB: PDB raíz o seed (PDB$SEED)
  2. Clonar PDB a partir de otra PDB del mismo CDB
  3. Desconectar PDB de un CDB y re-conectarlo (unplug/plug)  a otro, como parte de migración a versiones superiores de la 12
  4. Conectar una Base de datos “NON-CDB” (lo que sería el formato pre-12) a un CDB como parte de un proceso de migración, convirtiéndola de esta forma en PDB.

Este sería el listado de acciones de mayor a menor agilidad de aprovisionado de PDB’s en la nueva versión y todas ellas las trataremos en este post. La cuarta partiremos de una BD versión pre-12 ya migrada  a la versión que nos atañe. Estos procesos se pueden realizar con SQL*Plus, SQL Developer, OEM12c y DBCA. Nosotros los abordaremos desde SQL*Plus.

 

METODO 1: Clonar de Plantilla

Antes de comenzar vamos a comprobar el estado de la PDB raíz (PDB$SEED) y explicar un par de cosas.

SQL>  select NAME, con_id, open_mode from v$PDBs;

NAME                               CON_ID OPEN_MODE
—————————— ———- ———-
PDB$SEED                                2 READ ONLY

SQL>  select tablespace_name, plugged_in, status, CON_ID from cdb_tablespaces;

TABLESPACE PLUGGED_IN STATUS        CON_ID
———- ———- ——— ———-
SYSTEM     NO         ONLINE             2
SYSAUX     NO         ONLINE             2
TEMP       NO         ONLINE             2
SYSTEM     NO         ONLINE             1
SYSAUX     NO         ONLINE             1
UNDOTBS1   NO         ONLINE             1
TEMP       NO         ONLINE             1
USERS      NO         ONLINE             1

La PDB$SEED siempre está en formato “READ ONLY” debido a que existe únicamente como plantilla para generar otras PDBs, no es accesible.

En la consulta de los tablespaces aparecen asociados únicamente los tablespaces SYSTEM, SYSAUX y TEMP ya que “UNDO” es un elemento común, junto con los controlfile, y los redolog, a las PDB y existe exclusivamente a nivel de CDB.

Leer más…

Crear BBDD Oracle de desarrollo de manera ágil y con mínimo consumo de recursos

septiembre 15, 2015 1 comentario

El titulo de este post parece una panacea: imaginaros poder disponer de entornos de desarrollo “bajo demanda”, creándolos muy rápidamente y sin preocuparnos del espacio que ocupan (independientemente del tamaño de la BBDD origen)…

Existe la posibilidad de poder hacer algo parecido a esto si disponemos de un sistema de storage que nos permita replicar producción y realizar “snapshots” de esa replica o bien podemos aprovechar la funcionalidad de snapshot clone que nos proporciona Oracle Database desde la versión 11.2.

Las BBDD de tipo snapshot clone de Oracle prácticamente no ocupan espacio, ya que la BBDD clonada usa un backup de la BBDD origen para acceder a los datos (realmente no dispone de copia de los datos) y es cuando modificamos algún bloque que se realiza una copia con los nuevos datos modificados en los ficheros de la BBDD clonada (por lo que a medida que modifiquemos la BBDD clonada el espacio que ocupa irá creciendo).

BBDD clonadas usando Backup como origen de datos

El hecho de que los datos “base” de nuestro clon sean los de un backup nos permite desacoplar totalmente el entorno clonado del productivo (no interfiere uno con otro, pueden estar en servidores, cabinas e incluso CPD’s separados), y podemos crear tantos clones como queramos basados en el mismo backup (que habremos trasladado de producción al entorno de desarrollo o test). La copia debe ser de tipo “datafilecopy” y la podemos realizar en caliente mediante RMAN, en caliente manualmente con “begin/end backup” o en frío, y puede proceder de la BBDD origen o de una physical standby de ésta.

Notar que estos clones no están pensados para pruebas de rendimiento ya que el hecho de ir a buscar los bloques originales en el backup y los modificados en sus ficheros penaliza ese aspecto y por lo general los sistemas de storage de los entornos de desarrollo o test tampoco acostumbran a prestarse a este tipo de pruebas.

NOVEDAD: Indicar que a partir de la versión 12.1.0.2 se han relajado mucho los requisitos necesarios para poder usar esta funcionalidad, en esta versión podemos realizar clones sobre sistemas de ficheros locales. En versiones anteriores era necesario disponer de un sistema de ficheros NFS montado mediante el driver especifico de Oracle “dNFS” en el que crear la BBDD clon (notar que el backup no sufre esta restricción).

A continuación realizaremos una pequeña demostración de esta funcionalidad. En primer lugar lanzamos un backup de nuestra BBDD “origen”, realizamos un backup online con RMAN:

Leer más…

Upgrade Oracle Database a 12c mediante scripts y RMAN

2225367En esta entrada mostraremos un ejemplo de migración de 11g a 12c mediante scripts manuales y RMAN, al mismo tiempo que pasamos de una BBDD con almacenamiento ASM a otra sobre sistema de ficheros.

La idea general del proceso es realizar un backup con RMAN en la BBDD 11gR2 origen y restaurarlo en una maquina nueva con los binarios de 12cR1 para, acto seguido, aplicar los scripts de upgrade. La BBDD destino usará sistema de ficheros para almacenar los datos mientras que la de origen usaba ASM; notar que este ejemplo valdría también para el caso contrario.

Los pasos a realizar son:

  • Lanzar el backup RMAN en origen con los binarios de 11g
  • Traspaso del backup a destino (mediante SCP, ftp o similares)
  • Realizar la restauración con los binarios de 12c
  • Ejecutar los scripts de upgrade

En el fondo realizamos un upgrade mediante scripts, por lo que aplican las mismas restricciones y es necesario realizar los mismos pasos previos indicados en la documentación de migración mediante scritps.

Empecemos con el backup en origen con una sentencia similar a esta:

RUN {

ALLOCATE CHANNEL d1 TYPE DISK;

BACKUP TAG 'COPIA_MIGRACION' AS COMPRESSED BACKUPSET DATABASE format '/home/oracle/backup/temporal/%U' ;

backup TAG 'COPIA_MIGRACION' archivelog all format '/home/oracle/backup/temporal/%U';

RELEASE CHANNEL d1;

}

Una vez realizado el backup lo podemos copiar a la maquina destino con las herramientas de que dispongamos.

La máquina destino tiene que ser de la misma plataforma que la origen (si bien podría ser una versión de sistema operativo diferente) porque, como ya hemos comentado, este procedimiento equivale a un upgrade manual mediante scripts.

Leer más…

¿Qué versión elegir de Oracle Database, Enterprise o Standard?

Últimamente hemos recibido varias preguntas de diferentes clientes respecto a las diferencias entre las versiones Enterprise y Standard de Oracle Database, básicamente para saber cuál de estas ediciones encaja mejor con sus necesidades.

Standard-Enterprise

Usando un símil con los taladros, la Enterprise Edition sería un taladro potente, que podemos usar en cualquier superficie (ladrillo, hormigón, madera, metal) que atornilla/desatornilla y al que podemos conectar multitud de complementos que nos permitirán trabajar más rápidamente, con más precisión o realizando tareas que quizá podrían haber obligado a comprar otras herramientas (como lijar o cortar). Este sería el taladro imprescindible en la caja de herramientas de un buen carpintero, cerrajero, paleta, etc.

Por otra parte, si en casa colgamos algún cuadro de vez en cuando, necesitamos un taladro que permita taladrar muros y madera fácilmente, que sea práctico y fiable. Esta sería la versión Standard Edition del taladro, que no debería faltar en la caja de herramientas de ningún manitas.

Entrando un poco más en detalle, antes de nada aclarar que en este post no tengo intención hacer lista detallada de todas las diferencias entre ambas versiones, únicamente comentaré las más relevantes o que he detectado como más útiles en el día a día con nuestros clientes. Indicar también que no entraré en diferenciar las versiones XE (gratuita), Standard Edition y Standard Edition One pues ya las explicamos en este post.

A modo de recordatorio: algunas de las opciones o packs de Oracle Database Enterprise Edition, que comentaré a continuación, requieren ser licenciadas por separado de la BBDD.

El punto de partida obligado, para conocer en detalle las diferencias entre todas las versiones de Oracle Database, es esta página web de Oracle.

Desde mi punto de vista destacaría en Oracle Database Enterprise Edition:

  • La primera funcionalidad que destaca en una Enterprise Edition (EE en adelante) sobre una Standard Edition (SE en adelante) es, en mi opinión, la posibilidad de utilizar los packs de Diagnostics y de Tuning. Nos ofrecen la mayor y más detallada cantidad de información sobre el funcionamiento de la BBDD que os podáis imaginar (existen otros productos que hacen cosas parecidas, pero ninguno que los llegue a igualar), así como la posibilidad de ajustar de manera automática el rendimiento de nuestras sentencias SQL. En la SE no existe la opción de usar estas funcionalidades, lo que implica tener que controlar el estado y ajustar el rendimiento del gestor de manera tradicional (trazas de selects, vistas dinámicas V$ o herramientas como statspack -que se basa en las dos anteriores-).
  • Otra funcionalidad presente sólo en EE, y que creo que es importante y se tiene poco en cuenta, es el paralelismo. En EE una única sentencia SQL puede paralelizarse y usar varias CPU’s/cores de manera simultánea, mejorando notablemente el tiempo de respuesta en algunos casos. En SE no es posible paralelizar y una sentencia SQL no puede usar al mismo tiempo más de 1 CPU/core.

Leer más…

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.