ORA-01031: privilegios insuficientes … al hacer un GRANT

Posted on 12 febrero, 2013 by admin

Al hacer un GRANT conectado tanto como el usuario SYSTEM y/o SYS en una versión Oracle 7.3.4 para dar permisos de un package de un usuario a otro me aparece el error Oracle:

ORA-01031: privilegios insuficientes

La solución más rápida a este error es conectarse como el usuario propietario del Package (u del objeto que nos dé problemas) y ejecutar el comando GRANT.

Ej.

$ sqlplus system/password_system
SQL> connect usuario/password_usuario
SQL> show user
el usuario es “usuario”
SQL>  GRANT DELETE, INSERT, SELECT, UPDATE ON OPS$USUARIO.PACKAGE_EJEMPLO TO OPS$USUARIO_DESTINO;

Pero en mi caso, no tenía el password del usuario en concreto y tampoco me dejaban cambiarlo por si afectaba a alguna aplicación. ¿ Que se puede hacer en este caso ?

Como sí que tenía el password de root a nivel de sistema operativo (Unix en este caso) hice lo siguiente:

# su – usuario
$ whoami
usuario
$ sqlplus /

Ahora ya estaba conectado como el usuario “usuario” y ya podía ejecutar el comando GRANT.

SQL> show user
el usuario es “usuario”
SQL>  GRANT DELETE, INSERT, SELECT, UPDATE ON OPS$USUARIO.PACKAGE_EJEMPLO TO OPS$USUARIO_DESTINO;

Fácil  ¿verdad?

Posted in Administración Oracle, ORA-????? | Tagged , | Leave a comment

Migrar usuario de versión 9i a 11GR2 con herramienta exp/imp

Posted on 1 febrero, 2013 by admin

En la siguiente entrada de blog voy a mostrar un ejemplo de cómo exportar un esquema completo de un usuario Oracle de una base de datos en versión 9i hacia una versión 11GR2.

En muchas ocasiones, los DBA´s nos encontramos que tenemos que migrar Bases de datos a las últimas versiones y este proceso de migración se debe hacer de la manera más segura posible.  Pues una de estas maneras, desde mi punto de vista, es migrar la Base de datos esquema a esquema. La idea es la siguiente ….

Si debo migrar de una versión 9i a una 11GR2 y no quiero ir haciendo actualizaciones de versiones de Oracle. Una solución efectiva y rápida puede ser hacer lo siguiente:

- Instalar la nueva versión 11GR2 y crear la BD durante la creación con el mismo “perfil” que la Base de datos de versión anterior (en este caso la 9i), teniendo en cuenta cosas cómo por ejemplo poner el mismo CHARACTER SET, etc….

- Lo siguiente sería, exportar usando las herramientas de la versión 9i todos los esquemas, pero haciéndolo uno a uno. 

- Finalmente importar, usando el export de la nueva versión a la nueva Base de datos.

Seguidamente explico cómo hacer este export/import y explico que errores son los que comúnmente nos podemos encontrar durante este proceso.

Lo primero que tenemos que plantearnos es cómo exportar los esquemas que se encuentran en la versión vieja, en este ejemplo la 9i.

Se puede hacer de dos maneras. O bien ejecutando la herramienta export (exp) desde el mismo servidor donde se encuentre la base de datos, o bien, usando un cliente Oracle instalado en nuestro PC,  por ejemplo, y realizar el export.

Tanto en un caso como en el otro, nos tenemos que asegurar de que tendremos espacio de disco donde ubicar el fichero binario (con extensión .dmp) que genera la herramienta export y luego tendremos que copiarlo al servidor destino (en este caso la 11GR2) para posteriormente realizar el import.

 Si tenemos acceso al servidor donde están los esquemas de la 9i, lo mejor es hacer el export de esta manera. Ya que probablemente será más rápido y además, nos aseguraremos de que la herramienta export que utilizamos corresponde con la versión Oracle que hay instalada. Si por el contrario, realizamos el export desde un cliente Oracle instalado en nuestro PC, nos tenemos que asegurar que la versión que utilizamos para realizar el export, es cómo mínimo igual o inferior a la versión de la Base de datos origen. Porque sino es así obtendremos el siguiente mensaje de error al ejecutar la herramienta export:

EXP-00056: ORACLE error 6550 encountered
ORA-06550: line 1, column 41:
PLS-00302: component ‘SET_NO_OUTLINES’ must be declared
ORA-06550: line 1, column 15:
PL/SQL: Statement ignored
EXP-00000: Export terminated unsuccessfully

Solución: Ejecutar el export desde el servidor o instalarse un cliente de la misma versión o inferior. Nunca superior.

Ejemplo de export de esquema que usaríamos para realizar el export desde nuestro PC Windows con cliente 9i instalado igual o inferior al instalado en el servidor “origen”:

exp system/password@SID9i owner=USUARIO file=esquema_USUARIO.dmp log=exp_USUARIO.log

Esta línea la podemos guardar en un fichero con extensión .bat y ejecutarlo desde la línea de comandos de Windows.

La ejecución de este export generará un fichero binario llamado “esquema_USUARIO.dmp” que será el que posteriormente copiaremos al servidor destino y usaremos para realizar el import a la nueva base de datos.

 Lo siguiente que se debería hacer es copiar el fichero generado con el export en el servidor destino donde tenemos instalada la versión 11GR2. Una vez copiado, en el servidor destino, entraremos a sqlplus y crearemos el usuario con el mismo nombre que tiene en el servidor origen y le asignaremos el tablespace correspondiente. Si el tablespace no existiese, que sería lo normal, lo deberíamos crear antes de crear el usuario y antes de lanzar el import.

Podemos basarnos en la versión 9i para sacar la información del tablespace e incluso del usuario. Si estamos acostumbrados a trabajar con herramientas como TOAD, se puede incluso sacar el código de creación del usuario y lo podemos usar para la creación en el nuevo entorno.

En resumen:

Tenemos el export (fichero .dmp) ya copiado en el servidor destino. Hemos creado el tablespace del usuario y hemos creado el usuario asignándole ese tablespace. Pues ahora, procederemos a hacer el import del usuario. Sino hubiésesmos creado el tablespace y el usuario, el import nos daría un error. Las nueva herramientas de export/import Datapump en el proceso de importación ya nos crea el usuario y su tablespace correspondiente. Pero en este caso como es una versión 9i, nos vemos obligados a usar los antiguos exp/imp que no lo hacen.

imp system/password@SID11G fromuser=USUARIO touser=USUARIO file=esquema_USUARIO.dmp log=imp_USUARIO.log

Ahora podríamos asegurarnos de que nos conectamos correctamente con el usuario y que tenemos todo el esquema creado y los permisos asignados correctamente. Si no tenemos todos los permisos, podemos usar el usuario de la base de datos origen para sacarlos, ya sea usando una herramienta como TOAD o bien podemos ejecutar las siguientes instrucciones que nos generarán los “grants” necesarios para otorgar los permisos.

accept newuser prompt ‘Entra el nombre de usuario para generar el scripts de los roles que tiene:’

select ‘grant ‘ ||granted_role || ‘ to &newuser’ ||
       decode(admin_option, ‘NO’, ‘;’, ‘YES’, ‘ with admin option;’) “ROLE”
from   dba_role_privs
where  grantee = ‘&newuser’
/

select ‘grant ‘ || privilege || ‘ to &newuser’ ||
       decode(admin_option, ‘NO’, ‘;’, ‘YES’, ‘ with admin option;’) “PRIV”
from   dba_sys_privs
where  grantee = ‘&newuser’
/

 

 

Posted in Administración Oracle | Tagged , , , , , , , | Leave a comment

Bloquear/Desbloquear una cuenta ORACLE

Posted on 28 enero, 2013 by admin

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;

Posted in Administración Oracle | Tagged , | Leave a comment

Restaurar datafile SYSTEM en base de datos ORACLE NOARCHIVELOG

Posted on 28 enero, 2013 by admin

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.

Posted in Administración Oracle | Tagged , , , , , | Leave a comment

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

Posted on 23 enero, 2013 by admin

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.

Posted in Administración Oracle, Administración Sistemas, Linux, ORA-????? | Tagged , , , | Leave a comment

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

Posted on 21 enero, 2013 by admin

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.

Posted in Administración Oracle | Tagged , , , , , | Leave a comment

Saber que tnsnames.ora estoy usando en Windows

Posted on 21 enero, 2013 by admin

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?

Posted in Administración Oracle | Tagged , , | Leave a comment

Uso de las herramientas expdp e impdp de Oracle

Posted on 16 enero, 2013 by admin

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
/

Posted in Administración Oracle | Tagged , , , , , , | Leave a comment

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

Posted on 11 enero, 2013 by admin

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.

Posted in Administración Sistemas | Tagged , , , | Leave a comment

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

Posted on 4 enero, 2013 by admin

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.

Posted in Administración Oracle | Tagged , , , | Leave a comment