Archivo de la categoría: 11g

Problemas con los requerimientos del cliente 11gr2 en windows

Posted on por

Volvemos tras las vacaciones navideñas con una pequeña entrada de esas tremendamente simples, pero que pueden ser evitarnos una gran pérdida de tiempo.

Una de las cosas mas engorrosas de las instalaciones de Oracle es la instalación del cliente, en primer lugar, porque pocas veces nos especifican que es exactamente los componentes del cliente que necesitan, y en segundo lugar, por que, hasta estas últimas versiones la instalación ( especialmente la desinstalación) del cliente de windows era muy engorrosa.

Pues bien, el otro día en la instalación de un cliente 11gr2 en windows me encontré con un error nuevo:

error_instalacion_XP

Mi windows XP detectaba un error en los requerimientos de la instalacion del cliente (no instantclient), cuando, todos los requerimientos eran correctos.

La solución es tan sencilla como el habilitar el uso compartido de C$. Parece ser que el instalador utiliza «\\< servidor >\C$\temp» , con lo que si no está habilitado el recurso, la instalación falla.

La información completa del caso está (como siempre) en metalink, en la nota «Installation of 11gR2 on Windows Fails Checking Requirements [ID 1133495.1]»

Crear un entorno de pruebas con KVM I

Posted on por

Hoy vamos a ver la primera de una serie de entradas que nos llevarán a poder crear un pequeño entorno de pruebas virtual en el cual poder hacer nuestras pruebas de alta disponibilidad de plataformas Oracle .

Lo que buscamos con este entorno  es el tener una plataforma en la que poder replicar entornos para hacer pruebas de funcionamiento/parcheados/ migraciones. Si lo que se busca es una plataforma en la que hacer pruebas de rendimiento habrá que aumentar mucho las características del hardware que vamos a indicar en estas entradas.

Vamos a usar  el entorno de virtualizacion KVM en nuestro caso bajo una distribucion de Linux Centos y como servidor virtual sobre el que correran nuestros Oracles usaremos un Oracle Linux (la 6.1 en este caso) que descargaremos en formato ISO y qye depositaremos en el filesystem bajo el nombre   /mnt/virtual1/sources/OracleLinux-R6-U1-Server-x86_64-dvd.iso

Nuestro hypervisor contará con  una estructura de 3 discos, estos discos estarán montados bajo:

  • /mnt/virtual1/sources: Donde guardaremos las imágenes .iso de nuestros discos de fuentes
  • /mt/virtual1/raw .  Donde se ubicaran los discos de datos que utilizaran nuestras bases de datos
  • /mnt/virtual1. Donde guardaremos las imagenes de las máquinas virtuales.

Asímismo tendremos 3 entornos de red :

  • host: red básica por defecto, nateada a la tarjeta de red del hypervisor y que hará de direccionamiento IP del host, estará en la red 192.168.100.0/24
  • vip: Red que usaremos para el entorno virtual (VIP de oracle)  192.168.101.0/24
  • priv: Red privada entre los hostos (prov de oracle)   192.168.102.0/24

La configuracion de nuestro hypervisor quedará de la siguiente manera (usando la herramienta virt-manager)

Pestaña Virtual networks

Donde las redes priv y vip son «isolated»

Pestaña almacenamiento

Pestaña Interfaces

Una vez tenemos nuestro hypervisor instalado, procederemos a instalar nuestro primer servidor virtual.  Lo que buscamos es un servidor llamado rac1 que cuente con 1 Gb de memoria y cuyo fichero físico se encuentr en /mnt/virtual1/rac1/rac1.img

Así pues ejecutaremos :

virt-install \
--name rac1 \
--ram 1024 \
--os-variant=rhel6 \
--cdrom /mnt/virtual1/OracleLinux-R6-U1-Server-x86_64-dvd.iso \
--disk /mnt/virtual1/servidores/rac1.img,bus=virtio \
--disk /mnt/virtual1/raw/raw_1.img,perms=sh,format=raw,bus=virtio \

Lo que nos creará la máquina virtual, ahora solamente tenemos que arrancarla y hacer la instalacion de Oracle Linux.

Dado que nuestro fin no es probarla distribucion de Linux sino arquitecturas de Grid, Dataguard o RAC que vayamos a montar sobre ellas ,no vamos a detallar mucho la instalacion del Oracle Linux, haremos una instalacion completa deteniendo mas tarde todos los servicios innecesarios.

Una vez esté instalada y levantada, entraremos en las propiedades del servidor y le añadiremos los 3 nuevos interfaces de red, cada uno en una de nuestras redes (host,vip y priv)

Al finalizar esto iremos al directorio /etc/sysconfig/network-scripts y modificarremos los ficheros ifcfg-ethX de manera que queden:

 

 

 

Añadiremos en el /etc/hosts las lineas

#   Para el kvm
# Ip de host
192.168.100.1  hypervisor.pamplona.name
192.168.100.2  server1.pamplona.name
192.168.100.3  server2.pamplona.name
192.168.100.4  server3.pamplona.name
192.168.100.5  server4.pamplona.name
192.168.100.99 rac1.pamplona.name
# Virtual IP 
192.168.101.1  hypervisor-vip.pamplona.name
192.168.101.2  server1-vip.pamplona.name
192.168.101.3  server2-vip.pamplona.name
192.168.101.4  server3.pamplona.name
192.168.101.5  server4.pamplona.name
192.168.101.99 rac1.pamplona.name
# Private IP
192.168.102.1  hypervisor-priv.pamplona.name
192.168.102.2  server1-priv.pamplona.name
192.168.102.3  server2-priv.pamplona.name
192.168.102.4  server3.pamplona.name
192.168.102.5  server4.pamplona.name
192.168.102.99 rac1.pamplona.name

Con esto tenemos un servidor llamado rac1 , con las ips que se ven en el  /etc/hosts

Ahora podremos utilizar este servidor para clonarlo tantas veces como queramos y tendremos una máquina base para poder hacer nuestras pruebas con Oracle.

En nuestro caso vamos a empezar clonandolo 2 veces para crear los servidores server1 y server2

Una vez clonadas las máquinas, habrá que cambiarles las MAC,IP y elnombre del servidor, esto se cambia mediante:

  • /etc/systconfig-network-scripts/ifcfg-eth0:  cambiar la MAC y la IP
  • /etc/systconfig-network-scripts/ifcfg-eth1:  cambiar la MAC y la IP
  • /etc/systconfig-network-scripts/ifcfg-eth2:  cambiar la MAC y la IP
  • /etc/sysconfig/network  donde cambiaremos el nombre del host

Con esto tenemos la infraestructura básica para nuestras pruebas, en los siguientes post iremos instalando diversas arquitecturas para hacer pruebas sobre ellas.

Añadir un recurso a grid control /clusterware

Posted on por

Una de las ventajas que nos ofrece Oracle clusterware o Oracle Grid control es el gestionar una serie de elementos/procesos/aplicaciones arrancándolas o parándolas de manera centralizada.

Si instalamos nuestras bases con  la infraestructura de grid control, podemos aprovecharnos de la misma para gestionar en el arranque otros elementos como servidores de aplicaciones o la consola de administracion.Esto puede sernos muy util por ejemplo en caso de reinicio del servidor ya que grid control se puede encargar de levantar estos procesos.

En esta entrada vamos a ver como añadir la consola de administracion a el grid control, pero puede ser igualmente valido para cualquier procesos/servidor como podría ser un tomcat, apache o cualquier cosa por el estilo.

Como pasos prvios necesitaremos:

  • Script de arranque/parada/check de nuestra aplicacion, en nuestro caso estará en /opt/oracle/app/admin/PRUEBAS/consola/dbconsole
  • SID del grid  en nuestro caso +ASM
  • SID de la instancia en nuestro caso PRUEBAS
  • Nombre del servidor: En nuestro caso  pruebas.org

Vamos primero a ver el script que arranca/para /chequea la consola

#! /bin/sh
# Author:    Clemente Pamplona
# Date:      15-10-2012
# Usage:     dbconsole [start|stop|status|check]
# Purpose:   Arranca ,para y quequea la dbconsole 
# Copyright: GNU GPL

export ORACLE_SID=PRUEBAS
export ORAENV_ASK=NO
export ORACLE_BASE=/opt/oracle
export ORACLE_HOSTNAME=pruebas.org
. oraenv 
case $1 in
    START|start)
        emctl start dbconsole
         ;;
    STOP|stop)
        emctl stop dbconsole
        ;;
    STATUS|status)
        emctl status dbconsole
        ;;
    CHECK|check)
      rm /var/tmp/consola_status.txt
      emctl status dbconsole 
      if [ $? != 0 ]
        then exit 1;
        fi
        ;;

    *) echo "Usage: dbconsole [start|stop|status|check]"
       exit
     ;;
   esac

Este script podemos probarlo como usuario oracle en el servidor.

Una vez tenemos nuestro script creado que es capaz de arrancar y parar la consola, cargaremos el entorno del grid.

[oracle@pruebas.org consola]$ . oraenv
ORACLE_SID = [oracle] ? +ASM

Lo primero que vamos ha hacer es comprobar que elementos tiene corriendo nuestro grid

[oracle@pruebas.org consola]$ crs_stat -t
Name              Type                Target    State     Host
-----------------------------------------------------------------
ora.DATA.dg       ora.diskgroup.type ONLINE    ONLINE    pruebas.org
ora.LISTENER.lsnr ora.listener.type  ONLINE    ONLINE    pruebas.org
ora.asm           ora.asm.type       ONLINE    ONLINE    pruebas.org
ora.cssd          ora.cssd.type      ONLINE    ONLINE    pruebas.org
ora.pruebas.db    ora.database.type  ONLINE    ONLINE    pruebas.org
ora.diskmon       ora.diskmon.type   OFFLINE   OFFLINE
ora.evmd          ora.evm.type       ONLINE    ONLINE    pruebas.org
ora.ons           ora.ons.type       OFFLINE   OFFLINE

Vemos como tenemos claramente identificados el ASM, el Listener y la instancia . Así pues vamos  a añadrir un recurso local  tal y como dice la documentacion del crsctl

crsctl add resource dbconsola_pruebas -type local_resource \
-attr "ACTION_SCRIPT=/opt/oracle/app/admin/PRUEBAS/consola/dbconsole,\
 CHECK_INTERVAL='300',\
 RESTART_ATTEMPTS='2',\
 START_DEPENDENCIES=hard(ora.pruebas.db)"

Con esto le indicamos que cree:

  • recurso llamado pruebas
  • del tipo local_resource
  • usará nuestro script para actuar sobre él
  • chequeará su funcionamiento cada 5 minutos (300 segundos)
  • Intentará rearrancarlo 2 veces
  • Para arrancarlo deberá de estar la base de datos pruebas activa

Ahora podremos arrancarlo /pararlo /monitorizarlo desde las herramientas del grid.

$ORACLE_HOME/bin/crsctl start resource dbconsola_pruebas

$ORACLE_HOME/bin/crsctl stop resource dbconsola_pruebas

$ORACLE_HOME/bin/crsctl status resource dbconsola_pruebas

O bien con la salida total del sistema

[oracle@pruebas.org consola]$ crs_stat -t
Name              Type                Target    State     Host
-----------------------------------------------------------------
dbco..._pruebas  local_resource      ONLINE    ONLINE    pruebas.org
ora.DATA.dg       ora.diskgroup.type ONLINE    ONLINE    pruebas.org
ora.LISTENER.lsnr ora.listener.type  ONLINE    ONLINE    pruebas.org
ora.asm           ora.asm.type       ONLINE    ONLINE    pruebas.org
ora.cssd          ora.cssd.type      ONLINE    ONLINE    pruebas.org
ora.pruebas.db    ora.database.type  ONLINE    ONLINE    pruebas.org
ora.diskmon       ora.diskmon.type   OFFLINE   OFFLINE
ora.evmd          ora.evm.type       ONLINE    ONLINE    pruebas.org
ora.ons           ora.ons.type       OFFLINE   OFFLINE

 

P.D uede parecer algo evidente, pero, nuestro recurso nunca podrá llamarse ora.

Creando grupos de consumidores. A la caza del bloqueo II

Posted on por

Hasta el momento, en la entrada   A la caza del bloqueo I   teníamos  un  plan de recursos llamado NO_LOCKS que mataba aquellos procesos que estaban mas de 5 segundos bloqueando otra consulta. Este plan de consumidores no era muy util , ya que podía provocar estragos matando indiscriminadamente cualquier bloqueo de mas de 5 segundos, con lo que hoy daremos un paso mas para hacer de ese plan de recursos algo mas útil.

En esta entrada vamos a crear un grupo de consumidores, este grupo de consumidores nos permitirá afinar el perfil de los usuarios sobre los que queremos aplicar nuestro pal de recursos.

El grupo de consumidores lo vamos a llamar USER_NO_LOCK_ALLOW y lo crearemos de la siguiente manera:

BEGIN
 dbms_resource_manager.clear_pending_area();
 dbms_resource_manager.create_pending_area();
 dbms_resource_manager.create_consumer_group(
consumer_group =>'USER_NO_LOCK_ALLOW','Grupo de consumidores alos que no permitiremos bloqueos '
);
 dbms_resource_manager.submit_pending_area();
END;

 

Una vez tenemos nuestro grupo de consumidores creado, es el momento de decidir que usuarios queremos tener dentro de el y cuales no. Oracle 11g nos da muchas opciones para seleccionar este grupo de usuarios, algunas de ellas son:

Por esquema

Si quisieramos añadir a los usuarios del esquema «esquema1» a este grupo de consumidores usariamos el parámetro dbms_resource_manager.oracle_user  del paquete dbms_resource_manager

BEGIN
dbms_resource_manager.clear_pending_area();
dbms_resource_manager.create_pending_area();
dbms_resource_manager.set_consumer_group_mapping(
dbms_resource_manager.oracle_user,'esquema1','USER_NO_LOCK_ALLOW'
);
dbms_resource_manager.submit_pending_area();
 END;

Por maquina cliente

Supongamos que queramos aplicar incluir en nuestro grupo de consumidores solamente las sesiones que se ejecutan desde el servidor cliente «WORKGROUP\client1», para ello  usaríamos dbms_resource_manager.client_machine 

BEGIN
dbms_resource_manager.clear_pending_area();
dbms_resource_manager.create_pending_area();
dbms_resource_manager.set_consumer_group_mapping(
dbms_resource_manager.client_machine,'WORKGROUP\MAQUINA1','USER_NO_LOCK_ALLOW'
);
dbms_resource_manager.submit_pending_area();
END;

Por programa

Para separar por programa usaremos la llamada dbms_resource_manager.client_program

BEGIN
dbms_resource_manager.clear_pending_area();
dbms_resource_manager.create_pending_area();
dbms_resource_manager.set_consumer_group_mapping(
dbms_resource_manager.client_program,'PROGRAMA1','USER_NO_LOCK_ALLOW'
);
dbms_resource_manager.submit_pending_area();
END;

Como podeis ver, las posibilidades son muy grandes, en esta entrada nos hemos centrado en capturar sesiones por parámetros de login, pero la funcion dbms_resource_manager.set_consumer_group_mapping permite también seleccionar usuarios por atributos de runtime-.

La lista de las opciones la podeis encontrar en la documentación del paquete
dbms_resource_manager.set_consumer_group_mapping, pero a groso modo se puede resumir en:
Login Attributes

  • oracle_user
  • service_name
  • client_os_user
  • client_program
  • client_machine

 Runtime Attributes

  • module_name
  • module_name_action
  • service_module
  • service_module_action

Ahora solamente nos quedará el incluir este grupo de consumidores en nuestro plan de recursos, indicándole que son los consumidores de este grupo a los que no se les debe permitir el bloquear al resto de los usuarios . Pero esto será en otra entrada.

Tablas que desaparecen en el export

Posted on por

Hola

Vamos hoy con un pequeño expediente X. tenemos una base de datos 11g de la que queremos mover los datos a una base de datos de test. Lo primero que se nos ocurre es hacer un export de la misma con el comando exp  y llevarla a el entorno de test.

Sinembargo, al llegar a allí nos damos cuenta de que faltan objetos.

¿como es posible que nuestro export de toda la vida no haya sacado todas las tablas del esquema?

La respuesta es sencilla : por haber usado nuestro export de toda la vida

Aunque muchas veces sea mas comodo el uso del exp que de el expdp  ( especialmente por no tener que crear un directorio en la instancia),  el uso del exdp debería de ser obligatorio en nuestro día a dia,  ya que nos salvará de quebraderos de cabeza como este.

Pero,  seguramente  os estaréis preguntando a que es debido este problema.

 

Oracle 11g viene con la nueva funcionalidad deferred_segment-creation=TRUE activada por defecto.  Esto provoca que, al crear los objetos del esquema de la aplicacion en la base de datos no cree todos los segmentos de los mismos, sino que solamente creee los segmentos que contienen datos.

Nuestro «export de toda la vida» no es capaz de detectar esto,  exportandonos «solamente» los segmentos exsistentes en la base de datos,  sin embargo,  el nuevo expdp es mas listo,  y es capaz de exportar todos los objetos,  independientemente de que contengan datos  o no.

¿Como saber si tengo este tipo de tablas?

Podemos ver que objetos no están creados con la columna SEGMENT_CREATED  de las vistas del USER_TABLES, USER_INDEXES o USER_LOBS.

pregunta a ver que tablas  no tienen segmentos, si estásen una 11g seguramente te lleves una sorpresa.

select * from user_TABLES where  SEGMENT_CREATED='N'

Y en lo que se refiere a esta nueva funcionalidad de la 11g, cuidadito con ella,  por que,   seguramente nos traera algún que otro susto mas.