jueves, 28 de mayo de 2009

Comunicado de Oracle University- Nueva Dinámica en la forma de estudiar y aprender

El pasado lunes 25 de mayo, Oracle University anunció el lanzamiento del nuevo kit para estudio en los cursos presenciales, que vienen a reemplazar los materiales didácticos impresos que se entregaban a los estudiantes.

Los nuevos "eKits", estarán disponibles en la red para que puedan ser descargados previó a la fechas del curso.

La finalidad de Oracle, es impulsar una campaña ecológica, cuyo objetivo es la conservación de los recursos naturales. De hecho, el comunicado indica, que Oracle University, es el área de la corporación que consume la mayor cantidad de papel.

Beneficios:
  • Copia Personal y Portable de los materiales del Curso
  • Formato PDF para búsqueda
  • Eliminación de 100 millones de páginas impresas por año
Este modelo, ya esta disponible en las clases virtuales o Live Web Class (LVC) y será aplicado a partir del 01 de junio del presente año.

Para los que aún guardamos entre nuestros recuerdos nostálgicos, los manuales improvisados de la Versión 6.0, para SCO Unix, podría ser una mala noticia, pero lo cierto, es que el mundo ha cambiado muchos en los últimos 20 años y no podemos quedarnos atrás.

Ahora, mi gran pregunta es: Como hará Oracle, para contener en forma exitosa, la distribucción indiscriminada de este material en la red, ó si simplemente, dejará libre la circulación de los manuales, promoviendo así, una especie de liberación de derechos de autor y dejando sin efecto la leyenda de la contrapágina de la portada inicial.?

martes, 26 de mayo de 2009

Paso 1- Instalación de RAC en Linux RH5.0 32/64Bits/ Instalando nuestro sistema operativo

Vamos a ir realizando paso a paso, cada uno de los distintos puntos, que deben de tomarse en cuenta para la instalación de RAC en Red Hat Linux 5.0.

Existen varias tabúes, acerca de como se debe instalar LINUX, para poder trabajar correcta.
El primero de ellos que circula en la calle, es que es necesario instalar cuando se trabaja en 64bits, un conjunto de librerías de 32 bits. La experiencia obtenía durante mi instalación, me enseño que esto no es así.

Algo paso con la instalación fácil de RedHat 4.0 a RedHat 5.0, que hace ahora necesario, escoger cada uno de los distintos paquetes, que uno desea instalar. Antes en versión 4.0, escogíamos la versión de instalación total y listo, se simplificaba la instalación. De todos modos de instalar 4GB a 6.5 GB , personalizando los paquetes que se necesitaban instalar ó realizando una instalación total, no había gran diferencia. En la parte de personalización, perdíamos casí 30 minutos escogiendo los paquetes uno por uno, según la lista de prerequisitos de las distintas guías de instalación.

Recomiendo cuando hagan la instalación del RH, escoger la instalación en idioma inglés y escoja la configuración adecuada, para su teclado, para evitar problemas de mapeo de teclas. Si al instalar obvio esta opción, puede utilizar el comando: system-config-keyboard, para reconfigurar el teclado.

Cuando le solicite la opcion de inclusión del serial number, puede indicarle por el momento "saltar-skip", y proceder luego al final de la instalación a registrar su copia original de RH.

En la configuración del disco, yo prefiero hacer la distribucción en forma personalizada. Si su equipo tiene un arreglo de discos local o carece de él y tiene un sólo disco, no existe un motivo real, para crear distintos sistemas de archivos por separado.
Por lo general, para un equipo con 4GB de RAM, defino 8 GB de SWAP, 4 GB de temporal, 100MB boot, y el resto lo incorporó a root "/".
La configuración del almacenamiento compartido, - en nuestro caso el EVA serie 4400 - lo vamos a tocar más adelante.

Para mayor información de como configurar las particiones de sus discos locales, pueden consultarlo en la guía de instalación de Red Hat, http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/en-US/Installation_Guide.pdf .

El siguiente punto es la configuración de nuestra red. Aquí es necesario que definan una IP fija para cada uno de los nodos en donde instalaremos nuestro RAC. De facto, la instalación escoge DHCP, debe quitar el "check" sobre la opción, para que les permita definir una IP específica para cada nodo.

Muy importante es que tengan en cuenta la siguiente recomendación:
"Existe un bug documentado con el número 4437727, el cuál en unos de los procesos de configuración de los nodos para RAC, más precisamente en la configuración de las direcciones virtuales, con el utilitario CLUVFY, el proceso se cae. Esto se debe, a que el utilitario, asume que el estandar de nombramiento para las direcciones ip de los nodos, estan basados en la regla RFC 1918 que determina rangos de IP y subnet, pueden ser utilizados para redes privadas y redes públicas.
Si no desea tener problemas con este punto, es altamente recomendado, no utilizar los octetos:
  • 172.16.x.x a la 172.31.x.x
  • 192.168.x.x
  • 10.x.x.x
La nota de referencia esta en http://www.faqs.org/rfcs/rfc1918.html .

El servidor debe pertener a un dominio y el nombre del servidor no puede contener guiones "-" en el nombre.

Otro punto importante: No habilite el soporte para IPV6. Esto modifica el contenido del archivo /etc/hosts, quitando el contenido de la línea:

127.0.0.1 localhosts.localdomain localdomain

Esta línea es necesaria para la instalación de RAC.

Verifique que el NIC, quede activo desde el momento del arranque del servidor.

En la parte de la selección de paquetes, escoga la opción de software para desarrollo e indique que desea personalizar los paquetes que van a ser instalados.

Aquí es donde la instalación se vuelve engorrosa, ya que no existe forma en como escoger todas las opciones que no esten con el check para instalar. Deben de ir poniendo el check a cada paquete que desean instalar.

En mi caso, yo instalé, todos los paquetes de los grupos:

  • Desktop Environments
  • Development
  • Base System
  • Todo lo que tenga que ver con X-Windows de los ambientes de KDE y GNOME
  • JAVA
  • Legacy Software Support

No instale, el servidor de SAMBA, FIREWALL, aplicaciones de oficina, DHCP, DNS.

Continúe con la instalación normal, de aquí en adelante.

viernes, 22 de mayo de 2009

Como logearse como root en Ubuntu?

Cuando hacemos una instalación de Ubuntu, nos pide crear un usuario con el cuál ingresaremos en el sistema. Cuando necesitamos instalar algo, abrimos una ventana de terminal, hacemos "su – root", pero sorpresa nos pide el password, nunca nos pidió setearlo.

Para logearse como root en Ubuntu, nada más debes hacer: sudo bash

Te pedirá el password del usuario con el cuál estas logeado y listo ya estas como root.!!!

Diferencia entre EXP y EXPDP 10g

Cuántas veces deseamos realizar un respaldo de una porción de la base de datos, un grupo de tablas de un esquema excepto algunas, ó detener un respaldo por un momento y volverlo a reiniciar posteriormente. ? Esto algo que muchas veces quisimos hacer en las versiones previas a 10g, pero no era posible.

Hay muchas diferencias entre el utilitario convencional EXP y el nuevo utilitario EXPDP. Primero que todo aclaramos, que ambos utilitarios conviven en la versión 10g, pero una vez que conocemos las virtudes de EXPDP, difícilmente volvamos a utilizar EXP.

El EXPDP es parte de el "DATA PUMP UTILITY", y sirve para exportar información de la base de datos. El IMPDP hace la función contraría y la equivalente al clásico IMP. El DATA PUMP es un componente de software que cuenta con interface de línea de comandos, archivo de parámetros, línea interactiva y adicionalmente se le puede hallar dentro del Database Control ( Herramienta Web Administrativa de la base de datos ).

El DATA PUMP EXPORT e IMPORT pueden:

  • Generar un respaldo ó importación total de la base de datos ( FULL )
  • Trabajar a nivel de esquema
  • A nivel de tabla
  • Tablespaces
  • Tablespaces transportable

En el caso de EXPDP del cual estamos hablando en este momento, cuenta con un grupo de cláusulas que permite tener un mayor control, sobre lo que queremos exportar. Nos permite a través de la clausula EXCLUDE por ejemplo, indicarle que no exporte un conjunto de objetos. Por ejemplo EXCLUDE=PACKAGE , no exportaría los paquetes del esquema o la base de datos que estamos importando. Otro ejemplo EXCLUDE=TABLE:"LIKE '%TMP%'", no exportaría las tablas que cumplan con contengan las letras "TMP".

La clausula INCLUDE, me permite indicarle que incluya sólo aquel grupo de objetos que cumplan con una condición dada. INCLUDE= tipo_objeto[:"expresión"].

La clausula CONTENT, establece que tipo de contenido deseo exportar ALL, METADATA_ONLY, DATA_ONLY.

Cuenta con la clausula QUERY, que ya existía en las versiones anteriores de EXP.

Una de las principales características es la opción de crear un subconjunto de datos, para por ejemplo la creación de un ambiente de pruebas. La clausula SAMPLE, me permite indicarle al DATA PUMP, que exporte un porcentaje específico de una base de datos ó de un esquema. Por ejemplo: SAMPLE='INVENTARIOS"."EXISTENCIAS":50%. Con EXPDP, exportaría el 50% de los registros de la tablas EXISTENCIAS del esquema de INVENTARIOS.

A nivel del interface Web, la administración es sumamente sencilla, permitiendo escoger el tipo de exportación que se desea hacer. También se puede obtener una estimación del espacio que ocuparía el export, basado en los bloques de la base de datos utilizados por los objetos a exportar ó en base a las estadísticas almacenadas en el diccionario de la base de datos. En el paso 3 de la Consola Web, me permite programar la hora de inicialización del export o bien ejecutarlo inmediatamente. Además podemos pausar la ejecución de un export que este consumiendo mucho recurso del servidor en un momento dado y programar la hora de continuación del mismo, dejando siempre CONSISTENTE el respaldo iniciado previamente.

Estas son algunas de las grandes diferencias entre EXPDP y EXP de las versiones anteriores.

Bibliografía:

Oracle® Database Utilities
11g Release 1 (11.1)

Part Number B28319-02

Oracle® Database Administrator's Guide
10g Release 2 (10.2)

Part Number B14231-02


 


jueves, 21 de mayo de 2009

Obtener el contenido de un campo LONG

El siguiente ejemplo, le ayudará a poder leer el contenido de un campo de tipo LONG en una tabla de la base de datos, ingresando su contenido en una tabla temporal del sistema, la cuál podra consultar durante su sessión de trabajo.

Una vez que salga de la sessión, la tabla dejará de existir.

Se utiliza para este ejemplo, la tabla dba_triggers del diccionario de la base de datos, del cuál vamos a extraer el código fuente de los triggers de un esquema específico.

set pagesize 200
set linesize 220
drop table temp_validacion;
create global temporary table temp_lectura( table_owner varchar2(30),
table_name varchar2(30), trigger_name varchar2(30), data varchar2(4000));

declare
cursor my_cursor is
select table_owner, table_name, trigger_name, trigger_body
from dba_triggers
where table_owner='&ESQUEMA';
V_OWNER VARCHAR2(30);
V_TABLE_NAME VARCHAR2(30);
V_COLUMN_NAME VARCHAR2(30);
my_var varchar2(32000);
begin
open my_cursor;
loop
fetch my_cursor into V_OWNER, V_TABLE_NAME, V_COLUMN_NAME,my_var;
exit when my_cursor%notfound;
my_var := substr(my_var,1,4000);
insert into temp_lectura values (V_OWNER, V_TABLE_NAME, V_COLUMN_NAME, my_var);
end loop;
close my_cursor;
end;
/


Consulta sobre la tabla creada:

SQL> select * from temp_lectura where rownum <>




martes, 19 de mayo de 2009

Atributo "autoextent" para el datafile no funciona correctamente

Una situación muy particular se puede presentar a la hora de definir los parámetros de almacenamiento del datafile de un tablespaces.

Recordemos que a partir de algunas de las versiones de Oracle 7.3.4, los datafiles aparecen con un atributo nuevo conocido como autoextent, el cuál permite definir una política de crecimiento automático para los datafiles de un tablespace.

Se ha presentado casos, donde un tablespaces con datafiles habilitados en la parte del autoextent y con suficiente crecimiento en almacenamiento, se llenan, ocasionando problemas de almacenamiento a la hora de hacer "commit", crear un nuevo objeto, etc.

No existe un Bug conocido para esta situación, pero si, una condición que puede presentarse y que reproduce fielmente este problema.

Cuando creamos un nuevo tablespaces en una instancia, sin utilizar la nomenclatura OMF; tenemos que definir el nombre del datafiles, el tamaño inicial, el tamaño del siguiente extent y el máximo de tamaño que puede alcanzar el datafile.

Si definimos un datafile de 1GB y el extent siguiente de un 1GB también, pero por error establecemos el máximo de tamaño del datafile a un 1GB, cuando se llene el datafile inicial creado, el motor de la base de datos, no hará un redimensionamiento del datafile a 2GB, porque ya le haz definido un tamaño máximo de un 1GB.

La condición anterior, automáticamente, deshabilita el atributo autoextent del datafile.

Para solucionar el problema debes modificar el tamaño del atributo "maxsize" a nivel del datafile:

SQL> alter database datafile ‘/u01/oracle/prod/tbs01.dbf’ auto extend ON next 50M maxsize 4GB;

Manejo de Tablas Organizadas al Indice 10g

Todos tenemos tablas de parámetros, cuentas contables, códigos de compañia, etc, en nuestros sistemas.

El despliegue de información de este tipo de tablas en el sistema, muchas veces nos provoca modificar códigos del aplicativo, para incluir un ordenamiento que no se pensó con anticipación.

Aquí les doy una solucción práctica para mantener los registros de estas tablas, siempre ordenadas en su despliegue sin necesidad de modificar el código fuente del aplicativo y con el mínimo de esfuerzo.

Vamos a crear una tabla que despliegue los nombres de las algunas provincias, - en este caso de mi país - ordenadas siempre, sin importar el orden en que son ingresados los datos en la tabla.

SQL> create table provincias(
provincia varchar2(15) not null, id number(2) not null,
description varchar2(20),
constraint pk_provincias primary key (provincia))
organization index tablespace users
pctthreshold 20 including description overflow tablespace users
SQL> /
Table created.

Lo especial aquí, es la creación de tabla utilizando la opción de organización basada en un índice - en azul -, que para efectos de este ejemplo es el nombre de la provincia.

Vamos a ingresar datos, para ver como funciona la tabla.

SQL> insert into provincias values('&provincia',&id, '&descripcion');
Enter value for provincia: cartago
Enter value for id: 3
Enter value for descripcion: Provincia Azul Azul
old 1: insert into provincias values('&provincia',&id, '&descripcion')
new 1: insert into provincias values('cartago',3, 'Provincia Azul Azul')
1 row created.


SQL> /
Enter value for provincia: san jose
Enter value for id: 1
Enter value for descripcion: Capital del Pais
old 1: insert into provincias values('&provincia',&id, '&descripcion')
new 1: insert into provincias values('san jose',1, 'Capital del Pais')
1 row created.

SQL> /
Enter value for provincia: alajuela
Enter value for id: 5
Enter value for descripcion: Casa del Leon Herido
old 1: insert into provincias values('&provincia',&id, '&descripcion')
new 1: insert into provincias values('alajuela',5, 'Casa del Leon Herido')
1 row created.
SQL> commit;

Commit complete.

Ahora hagamos un consulta sobre la tabla sin agregar cláusula de ordenamiento.


Como pueden observar, aunque las provincias no fueron ingresadas en el orden alfabetico que corresponde al ordenamiento, a la hora de hacer el despliegue de datos, estos aparecen ordenados.

Ingresemos un datos adicional, para estar seguros de que esto funciona.

SQL> insert into provincias values('&provincia',&id, '&descripcion');
Enter value for provincia: heredia
Enter value for id: 4
Enter value for descripcion: Ciudad de las Flores
old 1: insert into provincias values('&provincia',&id, '&descripcion')
new 1: insert into provincias values('heredia',4, 'Ciudad de las Flores')
1 row created.
SQL> commit;
Commit complete.

Asi pueden manejar el ordenamiento de datos de forma ágil.
Recomendaciones:
  • No utilicen con tablas con actualizaciones constantes
  • Tablas en dónde no se conoce el número de registros que pueden llegar a tener
  • Las actualizaciones sobre estas tablas pueden causar consumo importante de I/O


viernes, 15 de mayo de 2009

Configurando un USB en Linux

Para instalar el USB en nuestro equipo, necesitamos conocer el dispositivo al cuál se encuentra atachado.
Esto lo hacemos con el comando dmesg.

login as: root
root@172.20.133.18's password:
[test_linux@root:/root] # dmesg egrep -i 'pciscsi'

PCI: PCI BIOS revision 2.10 entry at 0xfc3ee, last bus=4
PCI: Using MMCONFIG
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
PCI: Transparent bridge - 0000:00:1e.0
..
scsi0 : Adaptec AIC79XX PCI-X SCSI HBA DRIVER, Rev 1.3.11

aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 101-133Mhz, 512 SCBs
(scsi0:A:0): 320.000MB/s transfers (160.000MHz DTIURTI, 16bit)
Type: Direct-Access ANSI SCSI revision: 03
scsi0:A:0:0: Tagged Queuing enabled. Depth 4
SCSI device sda: 143374650 512-byte hdwr sectors (73408 MB)
SCSI device sda: drive cache: write through
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
scsi1 : Adaptec AIC79XX PCI-X SCSI HBA DRIVER, Rev 1.3.11

aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 101-133Mhz, 512 SCBs
..
PCI: Setting latency timer of device 0000:00:1d.1 to 64
scsi2 : SCSI emulation for USB Mass Storage devices
Type: Direct-Access ANSI SCSI revision: 02
SCSI device sdb: 1953792 512-byte hdwr sectors (1000 MB)
Attached scsi removable disk sdb at scsi2, channel 0, id 0, lun 0

[test_linux@root:/root]# more /etc/fstab
# This file is edited by fstab-sync - see 'man fstab-sync' for details
..
/dev/sdb1 /media/KINGSTON vfat uid=500,gid=501 1 2

En rojo, puedes observar como el sistema reconoció, a nuestro dispositivo USB, y como va a utilizar una emulación SCSI, para manejarlo. Toma en cuenta que el nombramiento del "device" en la segunda línea marcada en rojo es "sdb", esto te servirá como referencia para configurar el archivo "fstab" de tu equipo, para montar finalmente el dispositivo y así hacerlo visible al sistema.
El siguiente paso es agregar la entrada de carga automática en el archivo fstab en el directorio /etc.

Hemos creado un directorio en la ubicación /media/USB, para direccionar el /dev/sdb1. Luego vamos a agregar la siguiente línea:

  • /dev/sdb1 /media/USB vfat uid=500,gid=501 1 2
Finalmente montamos manualmente el dispositivo en nuestro sistema.

[test_linux@root:/root]# mount /dev/sdb1

Ahora ya podemos ver cargado el USB y disponible para ser utilizado.

[test_linux@root:/root]# df -k
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda3 4127108 3446096 471364 88% /
/dev/sda1 101086 11387 84480 12% /boot
none 517220 0 517220 0% /dev/shm
/dev/sda2 63226144 6775572 53238780 12% /oracle
/dev/sda6 1035660 34136 948916 4% /tmp
/dev/sdb1 976608 853872 122736 88% /media/USB

[test_linux@root:/root]#


miércoles, 13 de mayo de 2009

Desconexión constante desde aplicación utilizando Oracle10gR2

Si al verificar el alert.log de la instancia encuentras el error:
  • WARNING: 'inbound connection timed out (ORA-3136)'

Que debes hacer.?

A nivel de Oracle Net 10g, el parámetro INBOUND_CONNECT_TIMEOUT, cambio de valor, para determinar cuanto tiempo máximo espera una conexión de usuario en obtener respuesta por parte del listener.

Recordemos, que mucha gente ha escrito sobre las múltiples vulnerabilidades, a las cuales esta expuesto el servicio LISTENER de Oracle. El valor de facto en las versiones previas era "0", lo que daba como resultado que un cliente podría durar "n" minutos en la pantalla de logeo del aplicativo, sin realmente ingresar a la base de datos.

Esta exposición, más que una vulnerabilidad, daba chance a que se pudiera utilizar al servicio LISTENER, como intermediario para realizar "Denial of Service (DOS)".

A partir de release 2 de Oracle 10g, esta valor es seteado de facto a 60 ( segundos ), lo cuál podría generar algunos errores de conexión, con aplicaciones de terceros.

Este parámetro es de configuración en el archivo LISTENER.ORA y determina el tiempo de espera máximo para que un cliente complete su autentificación.

Se puede utilizar el parámetro "SQLNET.INBOUND_CONNECT_TIMEOUT" en el sqlnet.ora en combinación con el INBOUND_CONNECT_TIMEOUT_listenername, para proteger de ataques al listener y a la base de datos, en ambientes con exposición, con accesos desde fuera del DMZ.

Estos parámetros son seteados del lado del servidor de base de datos:

  • listener.ora: INBOUND_CONNECT_TIMEOUT_listenername
  • sqlnet.ora: SQLNET.INBOUND_CONNECT_TIMEOUT

martes, 5 de mayo de 2009

Bug no reparado en 10gR2 10.2.0.4

En una base de datos, 10gR2 10.2.0.4, cuando se hace un "shutdown" de la instancia, se registra en el alert, la siguiente información:

ORA-00604: error occurred at recursive SQL level 1
ORA-12663: Services required by client not available on the server
ORA-36961: Oracle OLAP is not available.
ORA-06512: at "SYS.OLAPIHISTORYRETENTION", line 1
ORA-06512: at line 15

Revisando información sobre este bug, me encontré que el mismo se genera cuando una instancia ha sido creada desde el DBCA ( Asistente de Configuración de Base de Datos ) y la versión del motor de la base de datos es "STANDARD".

Como algunos sabrán, la opción OLAP, sólo existe en la versión Enterprise, por tanto, el arreglo, no va por el lado de intentar recrear o instalar la opción OLAP.

En un sitio, me encontré la siguiente posible solucción, la cuál implementa la modificación del trigger que se dispara cuando bajamos la base de datos, desabilitando primero y luego volviendo a habilitar.

CREATE or replace TRIGGER flush_shared_pool
BEFORE SHUTDOWN ON DATABASE
BEGIN
execute immediate 'alter TRIGGER SYS.OLAPISTARTUPTRIGGER DISABLE';
execute immediate 'ALTER TRIGGER SYS.OLAPISHUTDOWNTRIGGER DISABLE';
execute immediate 'ALTER SYSTEM FLUSH SHARED_POOL';
execute immediate 'alter TRIGGER SYS.OLAPISTARTUPTRIGGER ENABLE';
execute immediate 'ALTER TRIGGER SYS.OLAPISHUTDOWNTRIGGER ENABLE';
EXCEPTION
WHEN OTHERS THEN
RAISE_APPLICATION_ERROR (num => -20000, msg => 'Error flushing pool');
END;

Lo anterior debería reparar el problema.

viernes, 1 de mayo de 2009

Configuración 10g Real Application Cluster en Linux

Hace unos días atrás, terminé satisfactoriamente la instalación de un RAC en 10g R2 ( 10.2.0.4 ), en Red Hat 5 Enterprise Server, con hardware HP BladeSystem Enclosure y un EVA4400.

Voy a ir indicando paso a paso, las consideraciones que tuvimos en cada una de las fases de la instalación, así como las que no tomamos en cuenta y que tuvimos que buscar alguna solucción durante el proceso.

Espero que les sea de mucho provecho.