Instalación de Ruby-Oci8 con Oracle

Para instalar ruby-oci8 en un servidor Linux con Oracle 10.2.0.4 es necesario seguir los siguientes pasos:

1.- Debe estar instalado previamente en el servidor el paquete de ruby y las gemas que se necesiten.

Para comprobar la instalación de ruby:

# ruby -v
ruby 1.8.6 (2008-03-03 patchlevel 114) [x86_64-linux]

Para comprobar la instalacion de las gemas:

# gem -v
1.3.0

2.- Instalación del adaptador de Oracle:

gem install activerecord-oracle-adapter --source http://gems.rubyonrails.org

3.- Variables de entorno de Oracle
Antes de instalar el driver de ruby-oci8 es recomendable poner las siguientes variables de entorno:

export ORACLE_SID=ORCL
export PATH=$PATH:/home/oracle/product/10.2/db_1/bin
export ORACLE_HOME=/home/oracle/product/10.2/db_1
export TNS_ADMIN=/home/oracle/product/10.2/db_1/network/admin
export LD_LIBRARY_PATH=/home/oracle/product/10.2/db_1/lib
export NLS_LANG=american_america.AL32UTF8

4.- Instalación de ruby-oci8.

Bajar la última versión ruby-oci8-1.0.3.tar.gz desde: http://rubyforge.org
una vez descomprimido el fichero es necesario ejecutar:

# ruby setup.rb config

# make

# make install

5.- Configuración del fichero tnsnames.ora.

Añadir una entrada en el fichero tnsnames para el servicio ORCL.

ORCL =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.10)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = ORCL)
)
)

6.- Comprobar que ruby-oci8 funciona correctamente.

Para comprobar el funcionamiento de ruby-oci8 se puede ejecutar el siguiente comando:

ruby -roci8 -e "OCI8.new('scott', 'tiger', 'ORCL').exec('select * from locales') do |r| puts r.join(' | '); end"

Si todo ha ido bien mostrará los datos de la tabla indicada.

7.- Modificar el fichero database.yml para configurar la conexión de rails a la base de datos.

   production:
     adapter: oracle
     database: ORCL
     username: scott
     password: tiger
     host: 192.168.1.10
     encoding: utf8

   development:
     adapter: oracle
     database: ORCL
     username: scott
     password: tiger
     host: 192.168.1.10
     encoding: utf8

8.- Arrancar el WEBrick de rails para comprobar que conecta bien.

Para probar la conexión se arranca el WEBrick de rails:

#RAILS_ENV=production ruby /home/rails/script/server

Es posible que al arrancarlo nos de el siguiente error:

/usr/lib64/ruby/site_ruby/1.8/rubygems.rb:147:in `activate': can't activate activerecord (>= 1.15.5.7843, runtime), 

already activate activerecord-2.1.0 (Gem::Exception)

En este caso es necesario modificar el fichero gemspec del oracle-adapter.

En el ejemplo, el fichero es el siguiente:

/usr/lib64/ruby/gems/1.8/specifications/activerecord-oracle-adapter-1.0.0.9250.gemspec

Hay que comentar las últimas líneas del fichero, quedará así:

# -*- encoding: utf-8 -*-

Gem::Specification.new do |s|
s.name = %q{activerecord-oracle-adapter}
s.version = "1.0.0.9250"

s.required_rubygems_version = Gem::Requirement.new(">= 0") if s.respond_to? :required_rubygems_version=
s.authors = ["Michael Schoen"]
s.date = %q{2008-06-04}
s.email = %q{schoenm@earthlink.net}
s.files = ["lib/active_record/connection_adapters/oracle_adapter.rb"]
s.homepage = %q{http://ruby-oci8.rubyforge.org/}
s.require_paths = ["lib"]
s.rubyforge_project = %q{activerecord}
s.rubygems_version = %q{1.3.0}
s.summary = %q{Oracle adapter for Active Record}

# if s.respond_to? :specification_version then
# current_version = Gem::Specification::CURRENT_SPECIFICATION_VERSION
# s.specification_version = 2
#
# if Gem::Version.new(Gem::RubyGemsVersion) >= Gem::Version.new('1.2.0') then
# s.add_runtime_dependency(%q, [">= 1.15.5.7843"])
# else
# s.add_dependency(%q, [">= 1.15.5.7843"])
# end
# else
# s.add_dependency(%q, [">= 1.15.5.7843"])
# end
end

Después de esto el WEBrick arrancará sin errores.

Links.

RubyForge
Jesse Hu's Weblog
Ruby-Oci8

Borrar alertas obsoletas en OEM

En algunas ocasiones el OEM mantiene una serie de alertas obsoletas en el aparatado Alerts de la página principal de Database Control.

Además esto provoca una perdida de rendimiento en las consultas que Oracle hace internamente sobre las tablas MGMT.

Para eliminar estas alertas obsoletas es necesario ejecutar el paquete EM_SEVERITY.DELETE_CURRENT_SEVERITY.

Se pueden seguir estos pasos:

1.- Identificar las alertas que se quieren borrar con:

select target_guid , metric_guid , key_value from MGMT_CURRENT_SEVERITY;

2.- Conectado con el usuario SYSMAN de la base de datos ejecutar el siguiente procedimiento:

exec EM_SEVERITY.DELETE_CURRENT_SEVERITY (target_guid , metric_guid , key_value);

Por ejemplo:

exec EM_SEVERITY.delete_current_severity

('0DEB8E6980695B7548CF98871084AD10',

'F95BA0D95585002889E1ABF92B2DA7C3',

'SYS');

Se pueden obtener todas las alertas obsoletas ya preparadas para ser borradas con esta consulta:

CONN SYSMAN

SELECT 'EXEC EM_SEVERITY.DELETE_CURRENT_SEVERITY

('''||TARGET_GUID||''','''||METRIC_GUID||''',''' ||KEY_VALUE||''');' MCS

FROM MGMT_CURRENT_SEVERITY;


Con esto se eliminan las alertas que ya han caducado y además se mejora el rendimiento en los accesos a las tablas de sysman MGMT.

Monitorización de Sesiones y Servicios en un entorno RAC

El comando por defecto para monitorizar los servicios de un entorno RAC es crs_stat -t, en metalink hay un script para formatear el resultado de una forma más vistosa y además se puede añadir una consulta para que muestre también el número de sesiones que hay en cada nodo del RAC y así comprobar si las sesiones se están balanceando de forma adecuada.

El script es muy sencillo y sería algo así:

#!/bin/ksh
# Monitorizacion de sesiones y servicios
#
##############################################
#
clear
# Variables de entorno
ORACLE_BASE=/opt/oracle/u01/app/oracle
ORACLE_HOME=/opt/oracle/u01/app/oracle/product/10.2/db_1
export ORACLE_BASE ORACLE_HOME

export ORACLE_SID=ORCL1

/opt/oracle/u01/app/oracle/product/10.2/db_1/bin/sqlplus -s "/ as sysdba" <<>
select inst_id , count(*) as sessions from gv\$session group by inst_id;
END


/opt/oracle/u01/app/oracle/scripts/crsstat.sh


El script crststat.sh se puede conseguir en Metalink buscando la nota, Note:259301.1

El resultado sería el siguiente:

   INST_ID   SESSIONS
---------- ----------
         1         82
         2         79

HA Resource                      Target     State
-----------                      ------     -----
ora.ORCL.ORCL1.inst              ONLINE     ONLINE on nodo1
ora.ORCL.ORCL2.inst              ONLINE     ONLINE on nodo2
ora.ORCL.ORCLS.ORCL1.srv         ONLINE     ONLINE on nodo1
ora.ORCL.ORCLS.ORCL2.srv         ONLINE     ONLINE on nodo2
ora.ORCL.ORCLS.cs                ONLINE     ONLINE on nodo1
ora.ORCL.db                      ONLINE     ONLINE on nodo2
ora.nodo1.ASM1.asm               ONLINE     ONLINE on nodo1
ora.nodo1.LISTENER_NODO1.lsnr    ONLINE     ONLINE on nodo1
ora.nodo1.gsd                    ONLINE     ONLINE on nodo1
ora.nodo1.ons                    ONLINE     ONLINE on nodo1
ora.nodo1.vip                    ONLINE     ONLINE on nodo1
ora.nodo2.ASM2.asm               ONLINE     ONLINE on nodo2
ora.nodo2.LISTENER_NODO2.lsnr    ONLINE     ONLINE on nodo2
ora.nodo2.gsd                    ONLINE     ONLINE on nodo2
ora.nodo2.ons                    ONLINE     ONLINE on nodo2
ora.nodo2.vip                    ONLINE     ONLINE on nodo2

Subconsulta con varias filas y un operador "like".

A veces en una consulta es necesario comprobar que un campo de una tabla contenga una cadena que queremos obtener de una o varias filas resultado de ejecutar una subconsulta.

Para resolver esta situación se puede usar una consulta de este tipo:

select a.fecha ,a.texto , b.cadena
from tabla_A a , tabla_B b
where upper(a.texto) like '%'||b.cadena||'%'
and b.cadena in (select cadena from tabla_B where id='1001')
and a.fecha>'01/01/08'
order by a.fecha;

Esta consulta muestra el campo texto que contenga las cadenas obtenidas en la subconsulta y que cumplan las condiciones indicadas.

Conexiones Oracle a traves de túneles SSH

El problema aparece cuando queremos conectar dos servidores Oracle sobre Linux en dos redes distintas y que no están accesibles desde internet. El único nexo que tenemos es un tercer servidor de gestión que tiene acceso a los dos servidores, pero no hay conexión directa entre los dos servidores de bases de datos.

Una solución para no abrir puertos y no romper las reglas de seguridad es abrir una serie de túneles con ssh para establecer una conexión segura entre los dos servidores.

El esquema siguiente nos muestra la arquitectura que tenemos:

En este caso es necesario abrir dos túneles, uno desde el Servidor B al Servidor de Gestión y otro desde el Servidor de Gestión al Servidor A. Con esto hemos establecido una conexión directa y segura entre el Servidor A y el Servidor B.

Los pasos para crear los túneles son los siguientes:

1.- Crear tunel del Servidor B al de Gestión.

Para crear este tunel hay que ejecutar el siguiente comando conectado al Servidor B:

ssh -R 1521:localhost:1590 usuario@servidor_de_gestion

2.- Crear tunel entre el Servidor de Gestión y el Servidor A.

Conectado en el Servidor de Gestión, se crea con:

ssh -R 1521:localhost:1590 usuario@servidor_a

3.- Configuracion del fichero TNSNAMES.ora

La configuración del fichero TNSNAMES.ora en el Servidor A debe ser como esta:

ORCLB =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)
(HOST = localhost)
(Port = 1521)
)
(CONNECT_DATA =
(SERVICE_NAME = ORCLB)
)
)

4.- Crear database link.

Por último, se puede crear un database link para acceder desde la base de datos del Servidor A a la base de datos del Servidor B.

create public database link ORCLB
connect to scott identified by tiger
using '(DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(Port = 1521))(CONNECT_DATA = (SERVICE_NAME = ORCLB)))';

Es necesario poner la cadena de conexión completa puesto que si se pone el nombre del servicio definido en el fichero TNSNAMES.ora da un error:

TNS-12154 TNS:could not resolve service name.

Con esto ya se puede acceder desde el Servidor A al B utilizando un database link. El problema es que debemos mantener las conexiones ssh abiertas mientras queramos usar el database link, es decir, solo estará disponible mientras estén abietos los túneles definidos.

Links.
Túneles SSH (Gracias a Tolgalen)
Secure Remote Logins

.

Configurar componentes de la base de datos

En una instalación con Oracle Standard Edition 10.2.0.4., cuando se creo la base de datos no se configuró ninguno de los componentes estandar que se pueden instalar. Estos componentes son:
- Oracle JVM
- Oracle XML DB
- Oracle Intermedia

Oracle recomienda que siempre se instalen estos componentes en la base de datos.

Para el desarrollo de una nueva aplicacion que usa geoposicionamiento ha sido necesario instalar Oracle Locator. El Oracle Locator se instala automáticamente al instalar el Oracle Intermedia, pero para instalar Intermedia es necesario tener instalado previamente Oracle JVM y XML DB.

Para instalar estos componentes se puede hacer desde la herramienta gráfica dbca o bien hacerlo manualmente siguiendo estos pasos:

1.- Instalación de Oracle JVM.

Para comprobar si Oracle JVM esta instalado se debe ejecutar la siguiente consulta:

select comp_id,comp_name,status,version from dba_registry;

Esta consulta muestra los siguientes componentes:

COMP_ID COMP_NAME STATUS VERSION
------- -------------------------------- ------ ----------
OWM Oracle Workspace Manager VALID 10.2.0.4.3
EM Oracle Enterprise Manager VALID 10.2.0.4.0
CATALOG Oracle Database Catalog Views VALID 10.2.0.4.0
CATPROC Oracle Database Packages and Types VALID 10.2.0.4.0
RAC Oracle Real Application Clusters VALID 10.2.0.4.0

No aparece ninguna referencia a JAVAVM.

Para instalar el componente es necesario ejecutar:

spool full_jvminst.log;
set echo on
connect / as sysdba
startup mount
alter system set "_system_trig_enabled" = false scope=memory;
alter database open;
select obj#, name from obj$
where type#=28 or type#=29 or type#=30 or namespace=32;
@?/javavm/install/initjvm.sql
select count(*), object_type from all_objects
where object_type like '%JAVA%' group by object_type;
@?/xdk/admin/initxml.sql
select count(*), object_type from all_objects
where object_type like '%JAVA%' group by object_type;
@?/xdk/admin/xmlja.sql
select count(*), object_type from all_objects
where object_type like '%JAVA%' group by object_type;
@?/rdbms/admin/catjava.sql
select count(*), object_type from all_objects
where object_type like '%JAVA%' group by object_type;
@?/rdbms/admin/catexf.sql
select count(*), object_type from all_objects
where object_type like '%JAVA%' group by object_type;
shutdown immediate
set echo off
spool off
exit

Para compilar los objetos que hayan quedado inválidos:

@?/rdbms/admin/utlrp.sql

A continuación se puede comprobar los objetos java creados:

select owner, count(*) from all_objects
where object_type like '%JAVA%'
group by owner;

2.- Instalación de Oracle XML DB.

Conectado como sysdba hay que ejecutar:

$ORACLE_HOME/rdbms/admin/catqm.sql

es necesario pasar tres parámetros:

- password para el usuario XDB
- tablespace por defecto del usuario XDB
- tablespace temporal del usuario XDB

por ejemplo:

$ORACLE_HOME/rdbms/admin/catqm.sql XDB SYSAUX TEMP

Para comprobar que la instalación ha sido correcta:

select comp_name, status, version from DBA_REGISTRY
where comp_name= 'Oracle XML Database' ;

3.- Instalación de Oracle Intermedia.

Conectado como sysdba, se ejecuta:

@?/ord/admin/ordinst.sql SYSAUX SYSAUX

Para crear el usuario MDSYS y asignar los permisos adecuados.

A continuación se crean los paquetes y tipos:

@?/ord/im/admin/iminst.sql

4.- Comprobación de componentes instalados en la base de datos.

Para comprobar que todos los componentes están instalados correctamente:

select comp_id,comp_name,status,version from dba_registry;

COMP_ID COMP_NAME STATUS VERSION
-------------- --------------------------- ------ ------------
ORDIM Oracle interMedia VALID 10.2.0.4.
0XDB Oracle XML Database VALID 10.2.0.4.0
EXF Oracle Expression Filter VALID 10.2.0.4.0
OWM Oracle Workspace Manager VALID 10.2.0.4.3
EM Oracle Enterprise Manager VALID 10.2.0.4.0
CATALOG Oracle Database Catalog Views VALID 10.2.0.4.0
CATPROC Oracle Database Packages and Types VALID 10.2.0.4.0
RAC Oracle Real Application Clusters VALID 10.2.0.4.0
JAVAVM JServer JAVA Virtual Machine VALID 10.2.0.4.0
XML Oracle XDK VALID 10.2.0.4.0
CATJAVA Oracle Database Java Packages VALID 10.2.0.4.0

Al estar instalado el Oracle Intermedia ya se pueden usar los paquetes de Oracle Locator.

Notas de Metalink.

Note:472937.1 Information On Installed Components and Schemas
Note:276554.1 How to Reload the JVM in 10.1.0.X and 10.2.0.X
Note:243554.1 How to Deinstall and Reinstall XML Database (XDB)

Oracle® interMedia User's Guide - Installing and Upgrading Oracle interMedia

Database Control muestra una versión incorrecta después de instalar el parche 10.2.0.4

Después de instalar el parche 10.2.0.4 en un Oracle RAC de dos nodos, apareció un problema estético en el Oracle Enterprise Manager 10g Database Control.

En la página principal del Database Control dentro del apartado General aparecía como versión la 10.2.0.1.0, aparentemente era algo estético puesto que todas las opciones funcionaban perfectamente.

Después de buscar durante bastante tiempo no encontré ninguna solución para este pequeño problema.

Pude ver que le había ocurrido a más gente:

http://kr.forums.oracle.com/forums/thread.jspa?threadID=638803

pero en este caso no habia ninguna solución.

Al ejecutar la siguiente consulta todos los productos tenían la versión correcta.

select comp_name,version,status from dba_registry;

Por lo tanto, la única solución aparente era borrar y crear de nuevo el repositorio de Enterprise Manager, para esto seguí los siguientes pasos:

1.- Borrar la configuración de Database Control y el repositorio.

Hay que ejecutar el siguiente comando:

emca -deconfig dbcontrol db -repos drop -cluster

Al trabajar con un entorno RAC con dos nodos el comando anterior pedía los siguientes parámetros:

Enter the following information:
Database unique name:ORCL (nombre de la bbdd en RAC)
Listener port number:1521 (puerto del listener, no confundir con el puerto que usa dbconsole)
Password for SYS user:xxxxx
Password for SYSMAN user:xxxxx

Do you wish to continue? [yes(Y)/no(N)]:Y

Esto borra el usuario SYSMAN de la base de datos, por lo tanto se pierde todo lo que tenga este usuario.

2.- Crear la configuración de Database Control y creación del repositorio.

Para crear el repositorio ejecutamos:

emca -config dbcontrol db -repos create cluster

pedirá los siguientes parámetros:

Enter the following information:
Database unique name:ORCL
Listener port number: 1521
Cluster name: crs (ver NOTA más abajo)
Password for SYS user: xxxxx
Password for DBSNMP user: xxxxx
Password for SYSMAN user: xxxxx
Email address for notifications (optional):
Outgoing Mail (SMTP) server for notifications (optional):
ASM ORACLE_HOME [ /opt/oracle/u01/app/oracle/product/10.2/db_1 ]:
ASM port [ 1521 ]:
ASM user role [ SYSDBA ]:
ASM username [ SYS ]:
ASM user password: xxxxx
-----------------------------------------------------------------

You have specified the following settings

Database ORACLE_HOME ................ /opt/oracle/u01/app/oracle/product/10.2/db_1

Database instance hostname ................ node1
Listener port number ................ 1521
Cluster name ................ crs
Database unique name ................ ORCL
Email address for notifications ...............
Outgoing Mail (SMTP) server for notifications ...............
ASM ORACLE_HOME ................ /opt/oracle/u01/app/oracle/product/10.2/db_1
ASM port ................ 1521
ASM user role ................ SYSDBA
ASM username ................ SYS

-----------------------------------------------------------------
Do you wish to continue? [yes(Y)/no(N)]: Y

Después de unos minutos se ha creado el repositorio de Enterprise Manager y el usuario SYSMAN también ha sido creado.

NOTA : El nombre del cluster es por defecto crs, en cualquier caso se puede comprobar cual es el nombre de cluster en nuestra instalación ejecutando el siguiente comando:

$ORA_CRS_HOME/bin/cemutlo -n

3.- Cambiar el puerto de dbconsole.

Una vez creado el repositorio, el anterior comando ha arrancado la dbconsole en el puerto por defecto 5500, en mi caso, yo tenía la consola en el puerto 1158, para evitar abrir otro tunel y poder seguir usando el mismo puerto tengo que cambiar el puerto de la consola con:

emca -reconfig ports -cluster -DBCONTROL_HTTP_PORT 1158

pedirá:

Enter the following information:
Database unique name: ORCL

Do you wish to continue? [yes(Y)/no(N)]: Y

Para y arranca el database control, después de unos minutos de espera la dbconsole ya esta configurada en el nuevo puerto.

4.- Ver la configuración.

Como último paso, vamos a ver la configuración actual de Enterprise Manager.

emca -displayConfig dbcontrol -cluster

nos pide:

Enter the following information:
Database unique name: ORCL

Do you wish to continue? [yes(Y)/no(N)]: Y

Nos muestra la siguiente información:

**************** Current Configuration ****************
INSTANCE NODE DBCONTROL_UPLOAD_HOST
-------- ----- ---------------------

ORCL1 node1 node1
ORCL2 node2 node1

Conclusiones.

Al arrancar la consola desde el navegador ahora es necesario poner https puesto que en esta versión se trata ya de una "secure dbconsole" según la documentación de Oracle.

Podemos observar que la versión que aparece en la consola es la correcta 10.2.0.4.0. En mi caso, además, tenía una serie de alertas caducadas que no se habían eliminado del repositorio, al recrearlo aparecen solo las alertas nuevas.

Links.

* Enterprise Manager Configuration Assistant.
http://kr.forums.oracle.com/forums/thread.jspa?threadID=638803
* Como recrear el Enterprise Manager http://www.dbasupport.com.mx/index.php?option=com_content&task=view&id=152&Itemid=29

Presentación

Este Blog pretende contar experiencias de un administrador de Oracle que a base de encontrar problemas a conseguido tener cierta experiencia y quiere compartirlas con otra gente en las mismas dificultades.

No pretende ser un blog de gurús donde se habla de cosas complicadas y exotéricas, simplemente es un punto de encuentro para administradores que han aprendido y siguen aprendiendo a base de golpes, documentación, metalink y google.