Usuario administrador de Weblogic en OEM12C

Posted on 26 mayo, 2015 por admin

Vamos con una entrada rápida de esas que nos evitarán quebraderos de cabeza.

¿Sabemos cual es el usuario de administración de nuestro weblogic?

Cuando vamos a parchear nuestro Cloud control nos encontramos con lo siguiente

oracle@emc 18295180]$ opatchauto apply -analyze -property_file bundle.xml
OPatch Automation Tool  
 Copyright (c) 2013, Oracle Corporation.  All rights reserved.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                          OPatchauto version : 11.1.0.10.0                                                                                                                                                                                                             OUI version        : 11.1.0.11.0                                                                                                                                                                                                             Running from       : /u01/app/oracle/middleware/oms
Log file location  : /u01/app/oracle/middleware/oms/cfgtoollogs/opatch/opatch2015-05-26_09-09-22AM_1.log
opatchauto log file: /u01/app/oracle/middleware/oms/cfgtoollogs/opatchauto/18295180/opatch_oms_2015-05-26_09-09-27AM_analyze.log
OPatch will do the following:
[Get weblogic Admin Server information]                        : Interview to get weblogic Admin Server of the GC Domain
[Generate configuration context of the GC Domain]              : Get the configuration context for the GC Domain
[Run patch(es) deployment prerequisite checks]                 : Check the status of admin server of the GC Domain
                                                               :  Check the status of OMS repository 
[Run patch(es) binary prerequisite checks]                     :Check if all the patches can be applied to or rolled back from their corresponding Oracle Home
[Generate execution steps to apply and deploy the patch(es)]   : Generate execution steps to modify bits and deploy artifacts of the patch

Please enter the WebLogic Admin Server URL for primary OMS(t3s://emc.pamplona.name :7103):>
Please enter the WebLogic Admin Server username for primary OMS:> 
Please enter the WebLogic Admin Server password for primary OMS:>

¿Cual es ese usuario que nos piden?
Si vamos a la URL que nos indica el fichero setupinfo.txt que nos dejó la instalacion en $ORACLE_HOME/install vemos que:

 Admin Server URL: https://emc.pamplona.name:7103/console

Y acediendo a esa URL nos encontramos con

Pero si revisamos los pasos de la instalacion del OEM12c veremos como en ninguna de las ventanas indicamos cual era el usuario de administrador del servidor de aplicaciones que va a correr el OEM12c. Solo indicamos el password.

La respuesta es sencilla :

usuario : weblogic
Contraseña: La de la instalación

Instalacion de RAC II , instalacion de grid infraestructure

Posted on 26 diciembre, 2013 por admin

Repasando las entradas anteriores he podido comprobar como , tas la entrada de RAC I Preparativos no teníamos las siguientes entradas de instalación del RAC, así pues, vamos a hacer de nuevo la instalación para dejarla documentada.

Partimos de la base de la configuración de entorno y máquinas del post RAC I Preparativos
Como recordatorio rápido tenemos que los directorios a utilizar serán:

GI_HOME=/oracle/11.2.0/grid
ORACLE_BASE=/oracle/app/grid
grid

Y la configuración de red de los servidores será

# Direcciones para nuestros equipos
# HOST y publica  eth0
10.0.2.2  exodar.pamplona.name   exodar
10.0.2.3  rac1.pamplona.name     rac1
10.0.2.4  rac2.pamplona.name     rac2
10.0.2.5  rac3.pamplona.name     rac3
10.0.2.6  rac4.pamplona.name     rac4
10.0.2.24 plantilla.pamplona.name        plantilla


#Virtual  Eth1  direcciones de la red sobre la que se da el servicio 
192.168.1.1  exodar-vip.pamplona.name   exodar-vip
192.168.1.2  rac1-vip.pamplona.name     rac1-vip
192.168.1.3  rac2-vip.pamplona.name     rac2-vip
192.168.1.4  rac3-vip.pamplona.name     rac3-vip
192.168.1.5  rac4-vip.pamplona.name     rac4-vip
192.168.1.24 plantilla-vip.pamplona.name        plantilla-vip

#ScaN  comentadas ya que estan dada de alta en round robin dns
# estas son las verdaderas direcciones de servicio 
#192.168.1.20  ractest.pamplona.name  ractest
#192.168.1.21  ractest.pamplona.name  ractest
#192.168.1.22  ractest.pamplona.name  ractest

#Private ETH2 red privada de los nodos
192.168.2.1  exodar-priv.pamplona.name  exodar-priv
192.168.2.2  rac1-priv.pamplona.name    rac1-priv
192.168.2.3  rac2-priv.pamplona.name    rac2-priv
192.168.2.4  rac3-priv.pamplona.name    rac3-priv
192.168.2.5  rac4-priv.pamplona.name    rac4-priv
192.168.2.24 plantilla-priv.pamplona.name   plantilla-priv

Así pues, lanzamos la instalación del grid control:
En nuestro caso omitiremos la información de soporte, en el caso de una instalación real de RAC es muy recomendable el incluirla ya que facilitará mucho el uso del área de soporte así como la descarga de los últimos parches para llevar a cabo la instalación de la ultima versión disponible.

En la siguiente pantalla indicaremos que queremos instalar la versión del grid infraestructure que aplica a un cluster

Nosotros elegiremos la instalación avanzada para poder afinar mas las opciones de instalación.

En este punto comenzamos con la instalación específica del rac.
Aquí tendremos que introducir las direcciones de servicio y privadas del RAC.
Hemos de tener en cuenta que, nosotros ya teníamos comprobado y solucionado el tema de la conexión ssh entre los nodos, en caso de no estar claro ese tema, podremos comprobarlo desde la opción conectividad ssh

Si la configuración de las tarjetas con los nombres es correcta, pasamos a la pantalla en la que indicamos cual van a ser las direcciones de red.
Como las traducciones las carga el diablo,vamos a detallar unpoco que es cada cosa:

privada:van a ser las interfaces de interconexión del rac, esta debe de ser una conexión dedicada para la sincronización de las caches.
públicaEs las interfaces vip que serán sobre las que posteriormente Oracle levantará las interfaces de scan

La version 11.2 del Grid nos permite tener el OCR y el Quorum en un disco en ASM, nosotros vamos a elegir este tipo de instalacion

Estamos en el momento en el que ASM nos muestra los discos disponibles, en nuestro caso lo hacemos mediante asmlib ( ver RAC I Preparativos ) , en la imagen tenemos que vamos a crear el grupo de discos OCRQUORUM y vamos a usar 1 disco de los que tenemos con la redundancia EXTERNAL.
En un entorno de producción real, será más aconsejable el uso de varios discos de 1 Gb con redundancia SUPERIOR.
Que el nombre del grupo de datos sea distinto a DATA (por defecto), llamándose OCRQUORUM no es un standard o buena práctica de Oracle, sino una modificación mía para que sirva para distinguirlo fácilmente del nombre del diskgroup que usaré en las bases de datos

El IPMI podríamos decir que es lo que tradicionalmente se ha llamado fencing , para tener mas infiormación del mismo podemos mirar en la documentación de Oracle Configuring IPMI for Failure Isolation, en nuestro caso, no lo vamos a activar.

Indicamos los directorios que teníamos planificados

Finalmente, vemos las opciones y el resumen

Y la tipica ventana de ejecución de los comandos como root.
Aquí hemos de ser pacientes y ejecutar los scripts en orden, primero siempre en el nodo en el que estamos llevando a cabo la instalacón, y, solamente cuando hallan acabado de manera correcta ejecutarlos en el otro nodo

Tras esto, continuamos con la instalación dando a «siguiente» hasta que finalice.

La instalación del Grid Infraestructure no es (desde mi punto de vista) algo muy limpio, y , tiene bastantes papeletas de fallar en algún punto, por lo que, es muy recomendable el tener a mano las notas específicas de soporte Oracle que nos ayudarán a solucionar estos problemas.
Estas notas son:

Alta de un host Windows 32/64 en OEm12c

Posted on 30 julio, 2013 por admin

En la entrada anterior vimos como descargar los catálogos de agentes en el nuevo OEM12c, nuestro siguiente paso será el dar de alta un host para después poder dar de alta los elementos que lo contengan.
Algo que pude sorprender respecto de las anteriores versiones del oem es que, en esta version 12.1.0.3.0 del Enterprise Manager, los agentes no son programas cliente que te descargas e instalas en el servidor, son programas que se despliegan desde el OEM12c por ssh

En vista de esto,lo primero que se nos viene a la cabeza es ¿que hacemos con los windows?

Lo primero que tendremos que hacer es instalar un servidor de ssh para windows, en el mercado hay varios de ellos, sin embargo,y a pesar de que es de los que personalmente menos me gustan, yo solamente recomiendo la instalación de uno de ellos, el cygwin .
¿Por que de esta recomendación?
Por que es el que aconseja Oracle en su manual de instalación, y, ya que vamos a instalar un elemento extraño en un entorno windows, al menos, usemos el que está documentado y sobre el que vamos a tener soporte.

El proceso de descarga e instalacion de cygwin está perfectamente documentado en los pasos previos a la instalacion del oem12c para windows Install cygwin. Seguiremos ese enlace y crearemos un usuario con permisos de administración ( por ejemplo usuario oem)

Una vez lo tenemos instalado, lo primero que debemos de hacer es probarlo, para ello abriremos una conexión ssh con el servidor windows, comprobando que podemos logarnos en el sistema con ese usuario oem que hemos creado previamente. Hasta que este paso no este claro y en funcionamiento no podemos seguir con el despliegue del agente.

Lo primero que haremos es buscar el alta manual

Tras eso llegamos a la ventana del directorio de instalación, a pesar de que la instalación se va a llevar a cabo mediante ssh y que el cygwin es capaz de ver las rutas de disco con path unix, la definición de directorios en esta pestaña debe de ser en modo windows, es decir c:\ d:\

Una vez hemos decidido el lugar, tendremos que dar los datos de la conexión ssh, para esta conexión aconsejo el crear un usuario windows (por ejemplo OEM ) dentro del grupo DBA y hacer la equivalencia en el cygwin con ese usuario

Tras esta pantalla llegamos a una ventana de trámite de confirmación de datos de despliegue de agente en la que le daremos a desplegar agente. Una vez le decimos que despliegue el agente, oem12c llevará a cabo una serie de comprobaciones en el host destino, estas comprobaciones son bastante completas

Una vez tengas el OK en todas las comprobaciones, la instalación es inmediata.

Como veis, la instalación de un agente de windows es prácticamente siguiente-> siguiente, la mayor dificultad es el asumir que esta se lleva a cabo mediante ssh y no mediante protocolos de Microsoft.

Problemas con glibc-devel instalando OEM 12c (crt1.o)

Posted on 21 abril, 2013 por admin

Hoy vamos a ver la solución a un problema en la instalación de OEM 12c bajo Oracle linux 6.4

Si miramos la documentación de la instalación en el apartado de paquetes tenemos que necesitamos los paquetes:

glibc-devel-2.5-49-i686 (This is a 32-bit package)
glibc-devel-2.5-49-x86_64 (This is a 64-bit package)

Sin embargo, si miramos lo que tenemos en la distribución,

[root@emc ~]# rpm -qa --queryformat "%{NAME}-%{VERSION}-%{RELEASE}(%{ARCH})\n" | grep glibc-dev
glibc-devel-2.12-1.107.el6(x86_64)

Y a la hora de instalar otro glibc-devel nos dice que ya está instalado

[root@emc ~]# yum install glibc-devel-2.12-1.80.el6
Loaded plugins: security
Setting up Install Process
Package matching glibc-devel-2.12-1.80.el6.x86_64 already installed. Checking for update.
Nothing to do

Si intentamos instalar , llega aun punto en que nos da un error de linkado, y es que no encuentra la librería crt1.o


INFO: Salida final del proceso iniciado.
INFO: ----------------------------------
INFO: Excepción devuelta de la acción: make
Nombre de la Excepción: MakefileException
Cadena de la Excepción: Error al llamar al destino 'install' del archivo make '/oem/oem12c/oms/sqlplus/lib/ins_sqlplus.mk'. 
Consulte '/oraInventory/logs/installActions-XX.log' para obtener más información.
Gravedad de la Excepción: 1
INFO: POPUP WARNING:Error al llamar al destino 'install' del archivo make '/oem/oem12c/oms/sqlplus/lib/ins_sqlplus.mk'. Consulte '/oraInventory/logs/installActions-XX.log' para obtener más información.

Haga clic en  "Reintentar" para volver a intentarlo.
Haga clic en "Ignorar" para ignorar este error y continuar.
Haga clic en "Cancelar" para parar esta instalación.

Este error estaba en el proceso de linkado delsqlplus, con el error

/usr/bin/ld: crt1.o: No suxh file or directory

La solución es tremendamente sencilla, y pasa un poco por la comprension del Oracle Linux, y es que,debemos instalar una librería del formato i396 (i696 para Oracle Linux), el problema , es que, cuando ejecutamos el yum este no instala las librerias de i686 debido a que nuestro sistema es x64.

Así pues, hay que forzarle a que instale el paquete de i386 (i686) con el comando


yum install glibc-devel.i686

Con este comando, tendremos los dos paquetes instalados

[root@emc ~]# rpm -qa --queryformat "%{NAME}-%{VERSION}-%{RELEASE}(%{ARCH})\n" 
 | grep glibc-dev

glibc-devel-2.12-1.107.el6(x86_64)
glibc-devel-2.12-1.107.el6(i686)

Y la instalación continuará sin problemas

Crear un entorno de pruebas con KVM I

Posted on 30 octubre, 2012 por admin

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.

Dba stuff

Un cajon desastre para el día a día

Archivo de la categoría: cloud

Usuario administrador de Weblogic en OEM12C

¿Sabemos cual es el usuario de administración de nuestro weblogic?

Instalacion de RAC II , instalacion de grid infraestructure

Alta de un host Windows 32/64 en OEm12c

Crear un entorno de pruebas con KVM I