Archivos mensuales: enero 2013

Bloquear/Desbloquear una cuenta ORACLE

Si hemos activado opción de “bloqueo de cuentas” en Oracle después de un número de intentos fallidos, al intentar conectarnos Oracle nos devolverá el error:

ORA-28000 – Cuenta Bloqueada.

Para poder desbloquearla debemos utilizar la instrucción <ALTER USER> con la opción <ACCOUNT UNLOCK>

- Bloquear cuenta de Oracle:

SQL> alter user username account lock;

- Desbloquear cuenta de Oracle:

SQL> alter user username account unlock;

Nota:
Para obligar al usuario a cambiar su Password, utiliza este comando:

SQL> alter user username password expire;

Restaurar datafile SYSTEM en base de datos ORACLE NOARCHIVELOG

Estando en un cliente me encontré con la siguiente situación:

En un sistema Unix HP-UX y una base datos Oracle 10g (10.2.0.4.0) el fichero system01.dbf se encuentra dañado. Al intentar arrancar la base de datos nos sale el siguiente error (ORA-01113):

Ante esta situación y sabiendo, según me informó el cliente de que la Base de datos estaba en modo NOARCHIVELOG, probablemente no me quedaría más remedio que tirar de Backup y asumir pérdida de datos. En resumen, me dicen que recupere esta base de datos, pero que no se sabe desde cuando tienen el último backup y que además, da el error anterior.

“Importante marronazo”, aunque hay que decir, que por suerte era un entorno Pre-productivo y que por tanto, tampoco pasaba nada si no se resolvía sin recurrir al backup.

Pero me ha parecido interesante abrir esta entrada de Blog, ya que gracias a esta incidencia prové una serie de cosas para intentar restaurar la Base de datos, hecho que conseguí despues de unos intentos fallidos que me hicieron descubrir en que estado se encontraba realmente la Base de datos.

 Volviendo con el tema. Me encuentro con el error mencionado y miro de restaurar teniendo en cuenta que la Base de datos estaba en modo NOARCHIVELOG (informado por el cliente). Como se trata del tablespace SYSTEM intento restaurar la Base de datos usando “backup controlfile until cancel” y como no tengo “archivers” en lugar de especificar la ruta del primer Archiver, especifico la ruta y el nombre de los logfiles.

Antes de todo me conecto como sysdba y arranco y monto la instancia:

$ sqlplus /nolog
SQL> connect /as sysdba

Para saber que logfiles tengo en la Base de datos ejecuto la siguiente consulta:

SQL> select member from v$logfile;

Con el resultado obtenido intento recuperar el datafile, pero ejecutando la siguiente sentencia que no es la que se usa para recuperar un datafile, sino que se usa para restaurarar el controlfile guardado en el último backup:

SQL> recover database using backup controlfile until cancel;

Y cuando nos solicita el fichero de recuperación de archiver, introducimos en su lugar el de logfile. En definitiva se hizo esto:

Según el mensaje parecía que todo había ido bien. Por tanto se intenta arrancar usando la opción “open resetlogs”.  ¿ Porqué usé Open Resetlogs ?

La opción “resetlogs” se suele usar cuando se dan estas dos situaciones:

O bien, en la recuperación se ha partido de un backup del controlfile y no del controlfile actual. Por tanto, el controlfile no tiene la última información sobre los archivelogs generados y la base de datos no puede saber hasta que archivelog se debe aplicar. O el segundo caso, no se ha recuperado hasta la última transacción, ya sea porque no hemos querido (RECOVER UNTIL) o bien porque faltaban archivelogs (hecho que se daba en este caso porque la base estaba en modo NOARCHIVELOG) y no se han podido recuperar hasta el final.

 ¿ Que implica abrir con resetlogs ?

A efectos de Backup podemos decir que la Base de datos es distinta, por tanto, se debería realizar un backup después de usar esta opción. Ya que técnicamente la ”nueva” base de datos está sin backup. Y si la base de datos estuviese en modo ARCHIVELOG, si se tuviese que restaurar no podríamos usar los backupsets de antes y después del resetlogs ya que tenemos una discontinuidad en el backup.

Después de ejecutar resetlogs, salta la alarma y me hace tomar otro camino. He aquí el error …

Este error se produce cuando Oracle realiza un seguimiento de la pila. Y nos advierte de que algún error producido anteriormente será probablemente la causa de este fallo. Cosa que me hace sospechar de que probablemente o bien la base de datos, no está realmente en modo NOARCHIVELOG o bien al restaurar con USING BACKUP CONTROLFILE el controlfile que existía en el backup estaba configurado en modo ARCHIVELOG.

Pues pasé a comprobarlo:

SQL> select  archiver from v$instance;
ARCHIVE
——-
STARTED

o  también

SQL> archive log list;
Modo log de la base de datos Modo de Archivado
Archivado automático Activado
Destino del archivo USE_DB_RECOVERY_FILE_DEST
Secuencia de log en línea más antigua 15
Secuencia de log actual 17

Efectivamente, la Base de datos estaba en modo ARCHIVELOG. Pues este hecho me hizo tomar otro camino en la recuperación y ejecuté las siguientes instrucciones para intentar recuperarla. (Hay que tener en cuenta, que cómo probablemente la base de datos estubo en algún momento configurada en modo archivelog, hecho que lo demuestra al restaurarla con using backup controlfile me hizo pensar, que probablemente se podría restaurar datafile a datafile y luego abriendo de manera normal).

 SOLUCIÓN:

Decido recuperarla datafile a datafile:

Pero para ello necesito saber que número corresponde a cada datafile:

$ sqlplus  /nolog
SQL> connect /as sysdba
SQL> shutdown immediate;
SQL> startup force mount;
SQL> desc v$datafile;

select name, file#, status, enabled from v$datafile
/

NAME
——————————————————————————–
FILE# STATUS  ENABLED
———- ——- ———-
/oracle/oradata/system01.dbf
1 SYSTEM  DISABLED
/oracle/oradata/undotbs01.dbf
2 ONLINE  DISABLED
/oracle/oradata/sysaux01.dbf
3 ONLINE  DISABLED

Empiezo con el de system que es el que estaba erróneo …

SQL> recover datafile 1;
Recuperación del medio físico terminada.

Intento abrir la Base de datos …
SQL> alter database open;
 alter database open
*
ERROR en línea 1:
ORA-01113: el archivo 2 necesita recuperación del medio físico
ORA-01110: archivo de datos 2: ‘/oracle/oradata/undotbs01.dbf’

Nos da error y nos pide que lo hagamos en más ficheros…. Pues procedo a hacerlo en todos los que nos solicita.

 SQL> recover datafile 2;
Recuperación del medio físico terminada.

SQL> alter database open;
Base de datos modificada.

Para la base de datos de manera abort para que no realice rollback de ninguna transacción pendiente.

SQL> shutdown abort;
Instancia ORACLE cerrada.

Intento arrancarla ..
SQL> startup
Instancia ORACLE iniciada.
Total System Global Area 2147483648 bytes
Fixed Size                  2070624 bytes
Variable Size             973080480 bytes
Database Buffers         1157627904 bytes
Redo Buffers               14704640 bytes

Base de datos montada.
ORA-16038: no se puede archivar el log 1 secuencia número 1
ORA-19809: se ha excedido el límite para los archivos de recuperación
ORA-00312: log online 1 thread 1: ‘/oracle/oradata/redo01a.log

Este error ya me gusta más, porque lo da en los ficheros redo y los podremos rehacer… Continuo con …
SQL> alter database open resetlogs;

Ahora cambio a modo NOARCHIVELOG ..

SQL> alter database noarchivelog;
Base de datos modificada.

SQL> alter database open;
Base de datos modificada.

SQL> archive log list;
Modo log de la base de datos              Modo de No Archivado
Archivado automático             Desactivado
Destino del archivo            USE_DB_RECOVERY_FILE_DEST
Secuencia de log en línea más antigua     2
Secuencia de log actual           4

SQL> alter system switch logfile;
Sistema modificado.

SQL> shutdown immediate;
Base de datos cerrada.
Base de datos desmontada.
Instancia ORACLE cerrada.

SQL> startup
Instancia ORACLE iniciada.
Total System Global Area 2147483648 bytes
Fixed Size                  2070624 bytes
Variable Size             973080480 bytes
Database Buffers         1157627904 bytes
Redo Buffers               14704640 bytes
Base de datos montada.
Base de datos abierta.
SQL>

Resultado: Base de datos recuperada. Pero con pérdida de datos. Pero no nos importa, porque era una Base de datos de pre-producción. Ahora se tendría que hacer un backup e importar datos de producción.

SHLIB_PATH y LD_LIBRARY_PATH y su relación con el error ORA-12547: TNS:lost contact

Al intentar conectar a Oracle versión 8.1.7.0 en un entorno HP-UX me encontré con el siguiente error:

# sqlplus scott/tiger

SQL*Plus: Release 8.1.7.0.0 – Production on Mon May 19 14:47:42 2003
(c) Copyright 2000 Oracle Corporation.  All rights reserved.
/usr/lib/pa20_64/dld.sl: Unable to find library ‘libjox8.sl’.
ERROR:
ORA-12547: TNS:lost contact
Enter user-name:

 ¿ Que puede estar sucediendo ?

Basicamente es que Oracle no puede encontrar las librerias dinámicas compartidas. Por tanto, la solución parece, a priori, ser bastante sencilla. Y de hecho lo es.

Las librerias o bibliotecas compartidas son librerias que cargan los programas cuando se inician. Cuando una biblioteca compartida se instala correctamente, todos los programas que se inician automáticamente usan esta biblioteca compartida. Es más, en Linux estas bibliotecas se pueden actualizar, se pueden anular íncluso funciones específicas de una determinada biblioteca, y todo esto mientras los programas están en ejecución.

Para poder realizar estas tareas, se pueden configurar variables de entorno que nos permitan controlar estos procesos y normalmente se suelen usar para sustituir una biblioteca por una diferente para una ejecución particular, como por ejemplo un entorno ORACLE determinado.

Es aquí donde prestan protagonismo las variables de entorno que hago referencia en esta entrada de blog.

LD _LIBRARY_PATH y SHLIB_PATH es un conjunto de directorios separados por “:” en donde se especifica o fija la ruta donde primero se tiene que buscar para encontrar las librerias necesarias para ejecutar cualquier programa, como por ejemplo sqlplus.

¿ Pero que diferencia hay o porqué se usa una u otra ?

LD_LIBRARY_PATH funciona en muchos sistemas Unix como Sun  y Linux, SHLIB_PATH sólo funciona en HP-UX y su equivalencia en AIX es la variable de entorno LIBPATH con la misma sintaxis, lista separada por “:”.

Lo que quiere decir que para sistemas HP-UX usaremos las dos variables de entorno (SHLIB_PATH y LD_LIBRARY_PATH) para Linux o Sun Solaris sólo LD_LIBRARY_PATH y para AIX LIBPATH.

Ahora, volvamos al error que nos ha dado ORACLE y vamos a solucionarlo ….

Simplemente editaremos el fichero donde tengamos definidas las variables del entorno Oracle (normalmente el .profile del usuario Oracle) y añadiremos las rutas que nos muestra el error Oracle (/usr/lib) a las variables de entorno que toque en función del sistema Unix/Linux en el que estemos trabajando. En mi caso era HP-UX y tuve que configurar el entorno como sigue:

export ORACLE_SID=ORCL
export ORACLE_HOME=/u/oracle
export PATH=$PATH:$ORACLE_HOME/bin:$ORACLE_HOME/lib:$ORACLE_HOME/lib32
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$ORACLE_HOME/lib32:/usr/lib
export SHLIB_PATH=/usr/lib:/psg_pr103/oracle/lib:/psg_pr103/oracle/lib64

Ahora ya podríamos ejecutar sqlplus sin problemas.

Caducidad de contraseñas en ORACLE 11GR2 – Error ORA-28002

Es probable que en alguna ocasión al conectarnos a sqlplus o usando una aplicación nos aparezca el error ORA-28002- the password will expire within 7 day y resulta que nos conectamos para comprobar que el usuario afectado no tenga caducidad en la contraseña y resulta que NO la tiene. ¿ Que puede estar sucediendo ?

Pues muy sencillo. Tenemos configurado por defecto en el perfil DEFAULT de usuario una política de expiración de contraseñas activada a nivel global. Para solucionar este problema, tan sólo debemos modificar dicha política de contraseñas.

En la siguiente entrada de blog voy a explicar como hacerlo desde sqlplus y desde la consola (database control) de Entreprise Manager 11GR2.

Desde SQLPLUS … (conectados como SYSo SYSDBA)

En primer lugar miramos que política tenemos establecida en las contraseñas. Para ello podemos ejecutar la siguiente sentencia:

SQL> SELECT LIMIT, RESOURCE_NAME FROM dba_profiles
WHERE RESOURCE_NAME in (‘PASSWORD_GRACE_TIME’,'PASSWORD_LIFE_TIME’,
‘PASSWORD_REUSE_MAX’,'PASSWORD_REUSE_TIME’) AND
PROFILE=(select profile from dba_users where username=’USUARIO_A_CONSULTAR‘)
/

Donde en USUARIO_A_CONSULTAR pondremos el usuario en concreto que queremos ver que valores tiene.

Nos devolverá algo como …

 LIMIT                                    RESOURCE_NAME
—————————————- ——————————–
120                                PASSWORD_LIFE_TIME
UNLIMITED                                PASSWORD_REUSE_TIME
UNLIMITED                                PASSWORD_REUSE_MAX
  7                                 PASSWORD_GRACE_TIME

Ahora debemos cambiar los valores de PASWORD_LIFE_TIME para que no caduque nunca (120 dias en el ejemplo) y de PASSWORD_GRACE_TIME para que no bloquee en 7 dias (en el ejemplo) la contraseña.

SQL> ALTER PROFILE “DEFAULT” LIMIT PASSWORD_LIFE_TIME UNLIMITED;

SQL> ALTER PROFILE “DEFAULT” PASSWORD_GRACE_TIME UNLIMITED;

Y con esto los passwords nunca más volverán a expirar para el perfil DEFAULT. Para comprobarlo podríamos ejecutar de nuevo la consulta anterior y nos tendría que devolver todos los valores a UNLIMITED.

Ejemplo desde la consola de Enterprise Manager …

Accedemos a la consola y pulsamos en la pestaña “Servidor” y luego en el apartado “Seguridad” pulsamos en “Perfiles“. Aparece la siguiente pantalla donde se pueden ver los perfiles definidos:

Ahora pulsaremos en “DEFAULT” y el botón “Editar” de la derecha de la pantalla. Seguidamente seleccionaremos la pestaña “Contraseña” y editaremos los campos donde aparece 180 y 7 en el ejemplo, que son los valores que hay que modificar para que las contraseñas no caduquen. A Ambas le asignaremos el valor UNLIMITED:

 finalmente pulsamos en aplicar cambios y voilà. Cambios realizados. Ya no volverán a caducar las contraseñas para el perfil DEFAULT.

Saber que tnsnames.ora estoy usando en Windows

Muchas veces, cuando te enfrentas a la administración de Oracle, debes dar soporte a clientes que se conectan con un PC con Windows a la base de datos, y algunas veces se conectan a diferentes entornos con diferentes versiones de Oracle. Muchas veces sucede que intentas conectar, dan errores de conexión y algunas veces es tan simple el problema como que hemos modificado un tnsnames.ora que no es el que está usando el cliente Windows para conectarse. Para asegurarnos de que estamos modificando el tnsnames.ora adecuado podemos hacerlo mirando lo siguiente:

Desde Windows….

- Menú inicio

- Ejecutar “regedit”

- En la clave de registro …

HKEY_LOCAL_MACHINE/SOFTWARE/ORACLE

busca la siguiente variable:

ORACLE_HOME

Esta apunta a la carpeta que contiene la instalación del oracle que se utiliza por default en la computadora. Por tanto una vez sabemos la ruta, vamos a ella y dentro del directorio Network/admin encontraremos los ficheros de configuración de SQL*NET y el susodicho tnsnames.ora.

¿ Fácil no?

Uso de las herramientas expdp e impdp de Oracle

Oracle ofrece unas herramientas para realizar exportaciones/importaciones de datos que nos permiten desde realizar backups de esquemas completos, de bases de datos, de tablas, hasta la migración de esquemas en diferentes versiones, y un sin fin de posibilidades.

La idea de esta entrada del blog es explicar cómo realizar difentes exportaciones e importaciones en función de nuestras necesidades. En versiones anteriores a la 10gR1 de Oracle se utilizaban las herramientas exp e imp. Pero desde esa versión (10gR1) aparece una nueva herramienta llamada Oracle Data Pump que experimenta importantes cambios respecto a sus predecesoras exp e imp.

Una de las diferencias más sustanciales de la nueva herramienta es que pasa de ser una herramienta que se ejecuta en el servidor en lugar de en el cliente, con la mejora de rendimiento/velocidad que eso conlleva. Por tanto los ficheros de dump (.dmp normalmente) se generarán o leerán en el servidor de base de datos.

Las antiguas exp/imp ya se encuentran fuera de soporte. Por lo que es más que recomendable adaptarse al uso de Oracle Data Pump.

Para empezar lo ideal es conocer los parámetros que se le pueden pasar a expdp o impdp para ello basta poner desde la linea de comandos help=y.

En esta entrada de blog todos los ejemplos están hechos en Linux.

Ej. Mostrar los parámetros de expdp (exportación):

$ expdp help=y

Para poder usar Oracle Data Pump debemos realizar unos pasos previos a nivel de Oracle que nos permita ejecutar la herramienta correctamente. El primer paso que debemos realizar es crear el directorio a nivel lógico en Oracle que especifica la ruta que Oracle usará para realizar los exports e imports. De esta manera no tendremos nunca que modificar nuestros scripts de export/import, ya que en el script especificaremos el nombre que nosotros hayamos puesto a nivel lógico.

Para crear el directorio nos conectamos con el usuario “sys”:

$ sqlplus /nolog

SQL>connect /as sysdba

SQL> show user

USER is “SYS”

SQL> create or replace directory dirdatapump as ‘/home/oracle/dirdatapump’;

 Directory created.

 SQL> grant read,write on directory dirdatapump to system;

 Grant succeeded.

Con esto ya tenemos el directorio creado llamado dirdatapump que será el que usaremos en nuestros scripts. Si quisieramos modificar la ruta del directorio deberíamos volver a ejecutar los pasos anteriores especificando la nueva ruta. Al usuario que hemos dado permisos para poder hacer los exports/imports lo hemos especificado en la segunda setencia con el “grant”, en el ejemplo “system”.

Una vez hecho esto, ya podemos empezar a crear nuestros scripts para hacer las exportaciones o importaciones que necesitemos. Seguidamente pongo algún ejemplo…

Ejemplo 1: Exportar datos de un esquema en concreto

Crear un fichero llamado expdp.sh y añadir el siguiente contenido:

$ vi expdp.sh

expdp system/password@micadenaconexion schemas=USUARIO_EJEMPLO directory=dirdatapump dumpfile=esquema_USUARIO_EJEMPLO.dmp  logfile=expdp_USUARIO_EJEMPLO.log

Dar permisos de ejecución al script en Linux:

$ chmod u+x expdp.sh

donde…

USUARIO_EJEMPLO es el nombre de usuario

micadenaconexion es el nombre de la instancia a la que nos conectamos

dirdatapump es la ruta que hemos especificado en la creación del directorio a nivel lógico. En este ejemplo ‘/home/oracle/dirdatapump’

Este export generará un fichero con extensión .dmp que posteriormente usaremos para realizar el import en función de nuestras necesidades.

Ya podríamos ejecutar el script para realizar el export:

$ . ./expdp.sh

- Ejemplo de import usando el anterior export para crear el esquema en otra instancia:

impdp system/password@micadenaconexion2 schemas=USUARIO_EJEMPLO directory=dirdatapump dumpfile=esquema_USUARIO_EJEMPLO .dmp  logfile=impdp_USUARIO_EJEMPLO.log

Donde …

micadenaconexion2 es el nombre de una nueva instancia donde por ejemplo quiero importar los datos del esquema que he exportado anteriormente. Si el usuario no existe el propio impdp lo crea.

 Ejemplo 2: Quiero copiar un esquema de desarrollo a un entorno de producción pero con otro nombre.

Para ello usaremos el parámetro REMAP_SCHEMA en el import.

Export:

expdp system/password@micadenaconexion schemas=USUARIO_DESARROLLO directory=dirdatapump dumpfile=esquema_USUARIO_DESARROLLO .dmp  logfile=expdp_USUARIO_DESARROLLO.log

Import:

impdp system/password@micadenaconexion remap_schema=USUARIO_DESARROLLO:USUARIO_PRODUCCION directory=dirdatapump dumpfile=esquema_USUARIO_DESARROLLO .dmp  logfile=impdp_USUARIO_REMAP.log

Ejemplo 3: Quiero copiar un esquema y quiero que el fichero .dmp se sobreescriba para evitar el error al ejecutar expdp y así tener la última versión del esquema exportado.

Sólo basta con añadir el parámetro REUSE_DUMPFILES=y en el export.

Export:

expdp system/password@micadenaconexion schemas=USUARIO_EJEMPLO directory=dirdatapump dumpfile=esquema_USUARIO_EJEMPLO.dmp  resuse_dumpfile=y logfile=expdp_USUARIO_EJEMPLO.log

Nota:

Si no sabemos que ruta tenemos definida como “directory” la tabla all_directories nos podrá facilitar esta información,  podemos ejecutar la siguiente setencia:

SELECT privilege,directory_name, directory_path
FROM user_tab_privs t, all_directories d
WHERE t.table_name(+)=d.directory_name and d.directory_name = ‘DIRDATAPUMP’
ORDER BY 2,1
/

o esta para saber todos los directorios configurados de Oracle

SELECT privilege,directory_name, directory_path
FROM user_tab_privs t, all_directories d
WHERE t.table_name(+)=d.directory_name ORDER BY 2,1
/

Cómo acceder remotamente a un servidor Oracle para su administración

En el siguiente artículo explicaré alguno de los métodos más utilizados para acceder a servidores, ya sean Windows, Linux o Unix para administrar el servidor Oracle que tienen instalado en su sistema.

Alguno de los métodos más extendidos para acceder a máquinas remotas son SSH y VNC

Según la WIKIPEDIA se define:

SSH (Secure SHell, en español: intérprete de órdenes segura) es el nombre de un protocolo y del programa que lo implementa, y sirve para acceder a máquinas remotas a través de una red. Permite manejar por completo la computadora mediante un intérprete de comandos, y también puede redirigir el tráfico de X para poder ejecutar programas gráficos si tenemos un Servidor X (en sistemas Unix y Windows) corriendo.

Además de la conexión a otros dispositivos, SSH nos permite copiar datos de forma segura (tanto ficheros sueltos como simular sesiones FTP cifradas), gestionar claves RSA para no escribir claves al conectar a los dispositivos y pasar los datos de cualquier otra aplicación por un canal seguro tunelizado mediante SSH.

VNC son las siglas en inglés de Virtual Network Computing (Computación Virtual en Red). Es un programa de software libre basado en una estructura cliente-servidor el cual permite tomar el control del ordenador servidor remotamente a través de un ordenador cliente. También llamado software de escritorio remoto. VNC no impone restricciones en el sistema operativo del ordenador servidor con respecto al del cliente: es posible compartir la pantalla de una máquina con cualquier sistema operativo que soporte VNC conectándose desde otro ordenador o dispositivo que disponga de un cliente VNC portado.

Bueno, hasta aquí las definiciones teoricas ….

Vamos a ver ahora cómo podemos acceder desde nuestro PC, (imaginemos que tenemos instalado un Windows XP) a los servidores donde se encuentran los servidores de base de datos Oracle instalados para poder realizar las tareas de administación que precisemos cómo si estuviésemos conectados directamente en el servidor.

Para ello, existen las herramientas 1.-putty, 2.-Xming y 3.-Escritorio remoto de Windows por ejemplo, que nos van a permitir hacerlo. Evidentemente, existen muchas más herramientas en el mercado. Pero en este artículo explicaré estas en concreto porque suelen ser unas de las más utilizadas.

1.-Xming es una implementación de software libre, portátil del sistema de ventanas X para sistemas operativos Microsoft Windows XP, 2003, Vista y seven. El servidor X Xming está basado en el servidor X.Org, cruzado en Linux con el compilador MinGW y Pthreads-Win32.

Xming está disponible con soporte Mesa 3D, soporta una gran variedad de lenguajes y al contrario que Cygwin/X, no requiere de bibliotecas Cygwin.

Xming se usa en implementaciones de Secure Shell (SSH) para asegurar sesiones X11 en otras computadoras. Soporta PuTTY y ssh.exe, y tiene una versión de PuTTY’s plink.exe.

2.- PuTTY es una implementación libre de Telnet y SSH para plataformas Windows y Unix, junto con un emulador de terminal xterm. Está escrito y mantenido principalmente por Simon Tatham. Es decir, es un cliente ssh que nos da acceso a una consola dentro del servidor al que accedemos.

3.-Escritorio remoto es una característica de Windows 2000 y superiores. Esta característica permite controlar de forma remota un equipo con Windows XP Professional desde otro equipo que ejecuta Windows XP Profesional o una versión anterior de Windows.

Bueno, con todo lo explicado hasta ahora podemos deducir lo siguiente:

- Si quiero conectarme con mi PC con Windows XP a un servidor Windows que soporte Escritorio remoto, lo haré usando “escritorio remoto” de Windows.

- Si quiero conectarme con mi PC con Windows XP a un servidor Unix/Linux y a su vez poder ejecutar algunas aplicaciones gráficas, lo haré ejecutándo una combinación de Xming y Putty. A diferencia de aplicaciones como VNC que nos permite tomar el control de un equipo remoto, la combinación Xming+Putty nos permite ejecutar aplicaciones individuales en el escritorio de nuestro PC con Windows instalado de una manera muy sencilla.

Seguidamente se explica cómo acceder usando dicha combinación:

Pasos para configurar el reenvío de X11 en Putty con Xming

(1) Descargar e instalar Putty en el PC

(2) Descargar e instalar Xming en el PC

(3) Iniciar el servidor Xming

(4) Guardar el servidor al que desea conectarse en Putty en las sesiones guardadas

(5) Cargue el servidor al que desea conectarse con Putty (Tecla Load)

(6) En el panel izquierdo categoría, haga clic en conexiones SSH y luego X11 entonces.

Marcar “Permitir el reenvío X11″  (Enable X11 forwaeding) y puedes escribir en el checkbox “X display location” localhost: 0

Nota: dejándolo en blanco también debería funcionar.

(7) En el panel izquierdo “categoría” ir a las sesiones (Session) principales y seleccione la que queremos guardar.

(8) Pulse el botón Guardar

(9) Establecer variable de entorno siguiente en el servidor

export DISPLAY = localhost: 10.0

O no hacer esta acción si ya está definida por defecto.

Pasos para realizar la conexión al servidor remoto donde está configurado el servidor de base de datos Oracle

 Tened en cuenta que para conectarnos al servidor remoto primero iniciaremos Xming (debemos ver un icono de X cerca del reloj en la barra de tareas). Sino lo vemos ejecutaremos el programa desde el menú inicio –> Xming –> xming

Luego iniciamos PuTTY, y nos conectamos usando el servidor que habíamos guardado previamente con la casilla habilitada “enable X11 forwarding”.

 Ya podemos ejecutar aplicaciones gráficas de Linux en nuestro Windows XP.

Para comprobar que funciona, podemos conectarnos al servidor y ejecutar el reloj del  entorno gráfico:

$ xclock

Debería aparecer este reloj digital en una ventanita como el de la  imagen que indica que nuestra configuración Xming+Putty está adecuadamente configurada.

Si esto falla mirar este artículo para solucionar el error.

Cómo cambiar CHARACTER SET en ORACLE en versiones 10G y posterior

En otro artículo del blog ya expliqué como cambiar el CHARACTER SET de una Base de datos Oracle hasta la versión 8i. En este artículo explicaré como hacerlo en versiones posteriores. Yo lo he probado en versión 11GR2. He de comentar, que si por el motivo que sea, nos vemos obligados a cambiar el CHARACTER SET de una base de datos Oracle, lo más recomendable es iniciar la instalación del servidor Oracle de nuevo y crear la base de datos con el CHARACTER SET adecuado durante el mismo proceso de instalación. Esto nos evitará futuros quebraderos de cabeza. Pero si es inevitable tener que “recrear” este cambio porque ya tenemos información en la Base de datos, no nos queda más remedio que utilizar el siguiente método y “cruzar los dedos” para que el cambio sea lo más exitoso posible.

El proceso de cambio consta de dos etapas: El escaneado de los datos y la conversión de los datos. Para ello utilizaremos la utilidad CSSCAN para la primera etapa y el script CSALTER (csalter.plb) para la segunda.

 La utilidad CSSCAN se utiliza para descartar de la base de datos posibles problemas de conversión de juegos de caracteres y truncamiento de datos. Los datos de escaneo identifica la “cantidad de esfuerzo” necesario para migrar los datos en el nuevo esquema de caracteres antes de realizar el cambio. Esta información nos ayudará a determinar el mejor enfoque antes de realizar la conversión.

El script CSALTER es parte de la utilidad de escaneo  mencionada y es la forma más directa para migrar el juego de caracteres (character set), pero puede ser utilizado de manera independiente si el juego de caracteres de la bases de datos es un subconjunto del nuevo juego de caracteres.

Por tanto, se puede decir que el nuevo juego de caracteres es un “superset” o superconjunto del conjunto de caracteres actual si:

- Todos y cada carácter en el conjunto de caracteres actual está disponible en el nuevo conjunto de caracteres.

 - Todos y cada carácter en el conjunto de caracteres actual  tiene el mismo valor de cógido (code point) en el nuevo conjunto de caracteres.

Los pasos para migrar son los siguientes:

Hecho en esta  versión:

Database Version: Oracle 11g Database R2 (11.2.0.3)
Source Character Set: AL32UTF8
Target Character Set: WE8ISO8859P1

- Parar la Base de datos en modo inmediato o normal. (Recomiendo mejor immediate)

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.

- Realizar un Backup completo de la Base de datos. Yo recomiendo realizarla en “frio” y también realizar una copia con la utilidad (expdp /impdp).

A veces, la conversión de datos incorrectos puede provocar daños en los datos, por lo que realizar una copia de seguridad completa de la base de datos antes de intentar migrar los datos a un nuevo conjunto de caracteres es imprescindible. La base de datos puede ser reconstruida posteriormente utilizando la copia de seguridad realizada antes de esta acción, si algo sale mal.

- Volver a poner en marcha la Base de datos

SQL> startup;
ORACLE instance started.

Total System Global Area 2097152000 bytes
Fixed Size 2074120 bytes
Variable Size 771754488 bytes
Database Buffers 1308622848 bytes
Redo Buffers 14700544 bytes
Database mounted.
Database opened.

 - Ejecutar la utilidad de scaner (CSSCAN)

El ejecutable de esta utilidad se ubica en el directorio $ORACLE_HOME/bin

$ csscan “sys/password@mibd as sysdba” full=y

donde midb corresponde al nombre de mi base de datos.

Character Set Scanner v2.1 : Release 11.2.0.3.0 – Production on Sat Sep 13 15:58:28 2008
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 – 64bit Production
With the Partitioning, OLAP and Data Mining options
Current database character set is AL32UTF8.
Enter new database character set name: > WE8ISO8859P1 (Especificar el nuevo juego de caracteres)
Enter array fetch buffer size: 1024000 >
Enter number of scan processes to utilize(1..32): 1 > 32
Enumerating tables to scan…
. process 1 scanning SYS.SOURCE$[AAAABIAABAAAAIRAAA]
. process 2 scanning SYS.SOURCE$[AAAABIAABAAAHCJAAA]
. process 3 scanning SYS.ATTRIBUTE$[AAAAC1AABAAAAURAAA]
…………………………………………………………………………….
…………………………………………………………………………….
…………………………………………………………………………….

Creating Database Scan Summary Report…
Creating Individual Exception Report…
Scanner terminated successfully.
$

Si se necesita más información de cómo funciona la utilidad CSSCAN se puede invocar a la ayuda en línea de la misma herramienta:

$ csscan help=y

- Ejecución del script de conversión CSALTER

Una vez se ha pasado la utilidad CSSCAN y se ha completado con éxito, debemos volver a parar la Base de datos y volverla a abrir pero esta vez en modo restringido, ya que ningún usuario normal debe poder acceder durante la taréa de conversión. Por tanto conectados como el usuario SYS ejecutaremos el script csalter.plb como sigue. Tened en cuenta que el script se encuentra ubicado en el directorio $ORACLE_HOME/RDBMS/admin.

$ sqlplus /nolog

$ connect /as sysdba;

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.

Start Up the Database in Restricted Mode.

SQL> startup restrict;
ORACLE instance started.

Total System Global Area 2097152000 bytes
Fixed Size 2074120 bytes
Variable Size 771754488 bytes
Database Buffers 1308622848 bytes
Redo Buffers 14700544 bytes
Database mounted.
Database opened.

Ejecutar el script csalter.plb …

SQL> @?/rdbms/admin/csalter.plb

0 rows created.

Function created.

Function created.

Procedure created.

This script will update the content of the Oracle Data Dictionary.
Please ensure you have a full backup before initiating this procedure.
Would you like to proceed (Y/N)?y ( Contestar que sí “y”)
old 6: if (UPPER(‘&conf’) <> ‘Y’) then
new 6: if (UPPER(‘y’) <> ‘Y’) then
Checking data validility…
begin converting system objects
12 rows in table SYS.WRI$_ADV_RATIONALE are converted
1 row in table MDSYS.SDO_GEOR_XMLSCHEMA_TABLE is converted
80 rows in table SYS.METASTYLESHEET are converted
17 rows in table SYS.WRI$_DBU_HWM_METADATA are converted
79 rows in table SYS.WRI$_DBU_FEATURE_METADATA are converted
4 rows in table SYS.RULE$ are converted
78 rows in table MDSYS.SDO_STYLES_TABLE are converted
10576 rows in table SYS.WRH$_SQL_PLAN are converted
21 rows in table SYS.WRI$_DBU_FEATURE_USAGE are converted
19 rows in table SYS.WRI$_ADV_ACTIONS are converted
4 rows in table MDSYS.SDO_XML_SCHEMAS are converted
2308 rows in table MDSYS.SDO_COORD_OP_PARAM_VALS are converted
578 rows in table SYS.WRI$_ADV_OBJECTS are converted
789 rows in table SYS.WRH$_SQLTEXT are converted

PL/SQL procedure successfully completed.

Alter the database character set…
CSALTER operation completed, please restart database

PL/SQL procedure successfully completed.

0 rows deleted.

Function dropped.

Function dropped.

Procedure dropped.

- Una vez acaba la ejecución del script volver a parar la base de datos y volver a arrancarla para comprobar que los cambios se han realizado correctamente.

Parar la base de datos ..

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.

Volver a arrancarla …

SQL> startup;
ORACLE instance started.

Total System Global Area 2097152000 bytes
Fixed Size 2074120 bytes
Variable Size 771754488 bytes
Database Buffers 1308622848 bytes
Redo Buffers 14700544 bytes
Database mounted.
Database opened.
SQL>

Asegurarse/Comprobar que se han realizado los cambios …

SQL> SELECT * FROM nls_database_parameters;

 Debe aparecer el nuevo juego de caracteres … WE8ISO8859P1 en este ejemplo.

Consultar parámetros de la base de datos ORACLE desde SQLPLUS

Una manera sencilla y muy efectiva de mirar los parámetros definidos en una base de datos Oracle es desde SQLPLUS:

Conectados como SYS o SYSTEM podemos hacer:

$ sqlplus /nolog

SQL> connect /as sysdba;
SQL> show parameter <nombre parámetro>

Ejemplo:

SQL> show parameter processes

Otra manera …

SQL> select value from v$parameter where name=’processes’; 
 

Para versiones 11G podemos ejecutar sólo:

SQL> show parameter

Nos mostrará todos los parámetros y su valor definido en ese momento.