viernes, 22 de mayo de 2009

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.

viernes, 24 de abril de 2009

Idiología de este blog

Este blog se normaliza bajo los principios que definen el software libre, a saber:

El software libre es una cuestión de la libertad de los usuarios de ejecutar, copiar, distribuir, estudiar, cambiar y mejorar el software. Más precisamente, se refiere a cuatro tipos de libertades para los usuarios del software:

  • La libertad de ejecutar el programa, para cualquier propósito (libertad 0).
  • La libertad de estudiar cómo trabaja el programa, y adaptarlo a sus necesidades (libertad 1). El acceso al código fuente es una condición necesaria.
  • La libertad de redistribuir copias para que pueda ayudar al prójimo (libertad 2).
  • La libertad de mejorar el programa y publicar sus mejoras, y versiones modificadas en general, para que se beneficie toda la comunidad (libertad 3).
Gracias por contribuir a crear un mundo mejor, permiso de distribucción de información no requerido.
http://www.gnu.org/copyleft/copyleft.es.html

jueves, 23 de abril de 2009

Otorgando privilegios para realizar "SELECT" sobre vistas del diccionario de la base de datos

En ocasiones es necesario dar a un usuario silvestre la posibilidad de realizar una consulta sobre una determinada vista o tabla del diccionario de la base de datos.

Si al crear el usuario en la base de datos le damos únicamente el privilegio de "CREATE SESSION", este no puede realizar consultas sobre las vistas o tablas del diccionario de la base datos.

Ejemplo:

Connectado con un usuario normal:

SQL*Plus: Release 10.2.0.1.0 - Production on Jue Abr 23 08:54:29 2009


Copyright (c) 1982, 2005, Oracle. All rights reserved.


Conectado a:
Oracle Database 10g Release 10.2.0.4.0 - 64bit Production

With the Real Application Clusters option

SQL> select * from dba_role_privs;
select * from dba_role_privs
*

ERROR en línea 1:
ORA-00942: table or view does not exist

Lo que requerimos es otorgarle el privilegio de "SELECT ANY DICTIONARY", con una cuenta con role de DBA y luego sin necesidad de volverse a logear en la base de datos, volvemos a ejecutar la consulta.

-------------- Nueva ventana con usuario con role DBA --------

SQL*Plus: Release 10.2.0.1.0 - Production on Jue Abr 23 08:56:18 2009

Copyright (c) 1982, 2005, Oracle. All rights reserved.


Conectado a:
Oracle Database 10g Release 10.2.0.4.0 - 64bit Production
With the Real Application Clusters option

SQL> grant select any dictionary to usuario;

Concesión terminada correctamente.

SQL>


-------------- De vuelta en la otra session -----------------



Con gusto a solicitud de mi amigo Johnny Chacón.

lunes, 20 de abril de 2009

Creando export de Oracle comprimido en Linux

Existe una gran cantidad de notas para ser utilizadas como referencia, para hacer un export de modo comprimido, utilizando el comando "compress" para plataformas UNIX.
En Linux podemos utilizar el comando "gzip" y los archivos "de nodos" a nivel de sistema operativo, para poder realizar esta labor.

Primero que todo en un directorio temporal, vamos a crear los archivos "PIPE", que nos ayudaran a esto.

$>cd /oracle/tmp
$>mknod pipe p
$>mknod pipe p2
$>mknod pipe p3
$>mknod pipe p4
$>mknod pipe p5
$>mknod pipe p6

Luego vamos a crear el siguente archivo de comandos SHELL.

$> more resp_pipe_orcl.sh

ORACLE_HOME=/opt/product/app/10g
ORACLE_SID=ORACLE_
TERM=xterm
PATH=${PATH}:$ORACLE_HOME/bin:/usr/bin
umask 022
NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1
export NLS_LANG
gzip < /oracle/tmp/pipe > /oracle/respaldo/expdiario_orcl_01_parte.dmp.gz &
gzip < /oracle/tmp/pipe2 > /oracle/respaldo/expdiario_orcl_02_parte.dmp.gz &
gzip < /oracle/tmp/pipe3 > /oracle/respaldo/expdiario_orcl_03_parte.dmp.gz &
gzip < /oracle/tmp/pipe4> /oracle/respaldo/expdiario_orcl_04_parte.dmp.gz &
gzip < /oracle/tmp/pipe5> /oracle/respaldo/expdiario_orcl_05_parte.dmp.gz &
gzip < /oracle/tmp/pipe6> /oracle/respaldo/expdiario_orcl_06_parte.dmp.gz &
exp respaldo/respaldo full=yes file=/oracle/tmp/pipe,/oracle/tmp/pipe2,/oracle/tmp/pipe3, /oracle/tmp/pipe4, /oracle/tmp/pipe5, /oracle/tmp/pipe6 filesize=2048M statistics=none log=/oracle/respaldo/exp_full_diario_orcl_full.log
$>

Lo que hacemos aquí, es crear varios archivos de un export grande, fragmentándolo en pedezos de 2GB como máximo. Cada dispositivo "pipe", lo referenciamos como un archivo independiente.
Antes de iniciar el export, concatenamos el comando gzip con un respectivo nombre final de archivo y lo dejamos corriendo en background, para dejarlos de una vez comprimidos los archivos desde el mismo momento cuando se realiza el export.

Puntos positivos:
  • Ahorramos espacio de almacenamiento
  • Fácil administración de archivos
  • Tamaño total de exports se reduce entre un 60% a un 70%

Desventajas:

  • Mayor tiempo de duración del export
  • Mayor consumo de memoria y cpu durante la ejecución

Recomendaciones

  • Ejecutar durante períodos de bajo nivel de operación del servidor
  • Se puede poner las opciones del export en un "parfile", para mejor administración.

viernes, 3 de abril de 2009

Lectura Interesante: Cuál es el valor de un DBA ?

http://www.dba-oracle.com/t_value_professional_dba.htm

Haciendo Ping a un grupo de Ip's en la red

Deseas hacer ping a un grupo de Ip's y no hacerlo de uno en uno?

Puedes hacerlo de la siguiente forma
for i in {30..35}; do ping -c1 172.20.100.$i; done
[root@admin ~]# for i in {30..35}; do ping -c1 172.20.100.$i;done
PING 172.20.100.30 (172.20.100.30) 56(84) bytes of data.
64 bytes from 172.20.100.30: icmp_seq=0 ttl=62 time=1.91 ms

--- 172.20.100.30 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.913/1.913/1.913/0.000 ms, pipe 2
PING 172.20.100.31 (172.20.100.31) 56(84) bytes of data.
64 bytes from 172.20.100.31: icmp_seq=0 ttl=62 time=1.59 ms

--- 172.20.100.31 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.596/1.596/1.596/0.000 ms, pipe 2
PING 172.20.100.32 (172.20.100.32) 56(84) bytes of data.
64 bytes from 172.20.100.32: icmp_seq=0 ttl=62 time=2.46 ms

--- 172.20.100.32 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 2.467/2.467/2.467/0.000 ms, pipe 2
PING 172.20.100.33 (172.20.100.33) 56(84) bytes of data.
64 bytes from 172.20.100.33: icmp_seq=0 ttl=62 time=2.10 ms

--- 172.20.100.33 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 2.100/2.100/2.100/0.000 ms, pipe 2
PING 172.20.100.34 (172.20.100.34) 56(84) bytes of data.
64 bytes from 172.20.100.34: icmp_seq=0 ttl=62 time=1.41 ms

--- 172.20.100.34 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.415/1.415/1.415/0.000 ms, pipe 2
PING 172.20.100.35 (172.20.100.35) 56(84) bytes of data.
From 10.8.0.2 icmp_seq=0 Destination Host Unreachable

sábado, 28 de marzo de 2009

Desktop de Linux ó Solaris en mi PC Windows

Siempre andamos buscando la mejor forma de administrar nuestros sistemas Linux ó Unix.
La comodidad que brinda el sistema gráfico de un sistema operativo, lo hace estar más al alcance de todos los usuarios, que no son de la vieja escuela de línea de comandos, además, existen varios programas que requieren el ambiente gráfico para poderse instalar, tal es el caso de las herramientas de Oracle, RDBMS, Clusterware, Application Server, etc.

En muchos servidores X en el mercado, pero la mayoría aportan más de lo que necesitamos al comienzo y su precio puede ser excesivo.

Nx ha sido el mejor server X que he visto en los últimos 2 años.
Dentro de sus características podemos encontrar:
  1. Fácil instalación
  2. Conexión por medio de SSH ( Secure Shell )
  3. Puede utilizarse además para conectarse a máquinas con Windows con SSH Server instalado
  4. Lo he probado con Red Hat 3/4/5, Centos 4/5, Oracle Enterprise Linux, Suse y ahora tiene una versión para Solaris.!!!
  5. Es completamente gratis.
Para su implementación en Linux, requieres instalar los siguiente paquetes en orden, con el usuario root:
  1. NxClient
  2. NxServer
  3. NxNode
En tu máquina windows, sólo requieres instalar el client para Windows.
Puedes obtener los "rpm" del sitio: http://www.nomachine.com

lunes, 23 de marzo de 2009

Comó reasignar el password a root en LINUX en caso de olvido

Cuando el arranque es: GRUB

Siga los siguiente pasos para proceder a reasignar el password del usuario root en un servidor LINUX, utilizando el GRUB a la hora de arranque:

1. Eliga la versión de kernel que corresponde a su instalación
2. Presione la tecla " e " para editar la entrada de arranque del sistema.
3. Seleccione la linea que inicia con la palabra kernel, generalmente la segunda línea
4. Presione la tecla e para editar la entrada
5. Agregue la letra " S " o la palabra " Single " al final de la línea
6. Presione la tacla ENTER
7. Ahora presione la tecla b para arrancar el kernel de Linux e ingresar en modo monousuario
8. Realice las siguiente acciones:

  • Monte la siguientes particiones:
  • # mount -t proc proc /proc
  • # mount -o remount,rw /
  • Cambie el password el usuario root:
  • # passwd
  • Reinicie el sistema:
  • # sync
  • # reboot

Cuando el arranque es: LILO

Cuando el arranque de LILO aparezca agregue la palabra "single" y presione la tecla [ENTER]:
Boot: linux single

Cuando aparezca el prompt de sistema operativo " # ", digite el comando " password " y proceda a restablecer el password del usuario root:
  • # passwd
Finalmente reinicie el servidor o la máquina y listo:
  • # sync
  • # reboot

viernes, 20 de marzo de 2009

Creando usuario común en 10g para generar un export

Para que no tengas problemas a la hora de generar un export convencional o un expdump en la base de datos 10g sigue las siguientes instrucciones.

  • create user respaldo identified by respaldo;
  • grant create session to respaldo;
  • grant exp_full_database to respaldo;
  • grant imp_full_database to respaldo;
  • grant execute on sys.dbms_defer_import_internal to respaldo;
  • grant execute on sys.dbms_export_extension to respaldo;
Ahora sí ya puedes generar el export sin "warnings" !!.

jueves, 5 de marzo de 2009

Problemas al instalar el Jdev 9.0.4 ( 10gR1 ) y 10.1.3.4 Jdev 10g en Linux 128 MB RAM requerido

A la hora de instalar el Oracle Collaboration Suite o el JDeveloper en una máquina Linux, puede ser que tengan problemas en el inicio de verificación de dependencias en el OUI ( Oracle Universal Installer ), indicándoles que deben tener al menos 128M de RAM para realizar la instalación. Si revisan con el utilitario "vmstat" o con el popular "top", puede que si tengan más de la cantidad de memoria disponible, pero aún asi no les deja hacer la instalación.

Aquí les va el tip:
"Todo se debe a un bug documentado en el DOC id. 294586.1 del 16 de Feb 2007. Si hacen la instalación con "runInstaller -ignorePreReq" no funciona.

Deben bajar el patch 3656396 y deben copiar el archivo MemorySizeQuery.jar al directorio en donde se desempacó el archivo ".zip", /Disk1/stage/Queries/MemorySizeQuery/
, donde este el archivo con el mismo nombre.
Vuelven a correr el "runInstaller" y asunto resuelto.


Crear un script dinámico que recorra todos los dblink definidos en la base de datos

En ocasiones se hace necesario ejecutar un script en varias instancias de base de datos.
Este ejemplo, te permite hacerlo.
Debes tener privilegios de "select" sobre la tabla del diccionario "ALL_DB_LINKS" en el esquema que deseas utilizar. Las líneas "PUT_LINE", es un parche, para evitar error de "overflow", ya que le máximo disponible para despliegue son 255 caracteres por línea.


declare
cursor liga is
select '@'||db_link from all_db_links;
enlace varchar2(30);
cmd varchar2(1000);

begin

open liga;
loop
fetch liga into enlace;
exit when liga%NOTFOUND;
DBMS_OUTPUT.ENABLE (100000);
cmd := 'update pvcreditos
set saldo=0, tstamp=sysdate
where no_transa_credito in ( select no_transa_credito
from pvforma_pago'||enlace|| ' where no_transa_credito in ( select a.no_transa_credito from pvhcreditos a, pvcreditos b where a.no_fisico=b.no_fisico and a.no_transa_credito=b.no_transa_credito and a.saldo <> b.saldo and a.fecha <='||'''31-DEC-04'''||' and a.descripcion=b.descripcion and a.cajero=b.cajero))';

DBMS_OUTPUT.PUT_LINE(substr(cmd,1,255));
DBMS_OUTPUT.PUT_LINE(substr(cmd,256,400));
execute immediate cmd;
end loop;
close liga;
end;
/

lunes, 2 de marzo de 2009

Diferencia en el uso de la función count(*) y count(nombre_columna)



En muchas ocasiones, no tenemos claro, como trabaja algunas de las más comunes funciones de Oracle SQL*Plus.

Uno de esos casos específicos, es cuando utilizamos la función “count”. Esta función trabaja de manera distinta cuando se aplica usando el comodín “*” o el nombre de la columna a ser sumada.

Veamos el siguiente ejemplo práctico.

Tenemos la tabla t1 con los siguiente registros. Observe que en la cuarta tupla, “Raul Ballestero” no tiene profesión asignada en la columna respectiva.

SQL> select * from t1;



Ejemplos de aplicación:

SQL> select count(*) from t1;

COUNT(*)
----------
4

SQL> select count(profesion) from t1;

COUNT(PROFESION)
----------------
3

SQL> select count(rowid) from t1;

COUNT(ROWID)
------------
4

Hasta aquí no hemos visto nada nuevo. Pero que sucede si incluimos un registro con valores nulos?.

SQL> insert into t1 values('&nombre','&profesion');
Enter value for nombre:
Enter value for profesion:
old 1: insert into t1 values('&nombre','&profesion')
new 1: insert into t1 values('','')

1 row created.

SQL> commit;

Commit complete.

SQL> select * from t1;



SQL> select count(*) from t1;

COUNT(*)
----------
5

SQL> select count(rowid) from t1;

COUNT(ROWID)
------------
5

SQL> select count(nombre) from t1;

COUNT(NOMBRE)
-------------
4

Como pueden observar hacer el conteo utilizando el asterisco o la seudo-columna “rowid” en conjunto con la función “count”, toma en consideración el registro nulo incluido. Si lo hacemos haciendo referencia con el nombre de la columna, no lo toma en cuenta.

Todos los Sábados a las 8:00PM