Purgar la Papelera de Reciclaje de Oracle 10g

Posiblemente a las personas que administran Oracle 10g vieron que al eliminar objetos tales como tablas, vistas, triggers y otros se generan otros nuevos objetos con una nomenclatura como la de la imagen:









Eso quiere decir que todos los objetos que eliminamos se van a la papelera de Oracle, de donde podemos recuperarlos o sino eliminarlos definitivamente, tal y como me paso en los servidores de Oracle, hay varias formas de borrar esos objetos y pasare a explicarlos:

1. Primero hay que verificar si tenemos objetos en nuestra papelera, para esto hay que conectarnos con el usuario owner del esquema al sqlplus y el siguiente comando SQL:

SQL>select * from recyclebin;

2. Si encontramos que si tenemos objetos en la papelera hay varias formas de eliminarlas y son:

SQL> PURGE TABLE tab1; elimina la tabla tab1 de la papelera
SQL> PURGE INDEX ind1; elimina el indice ind 1 de la papelera
SQL> PURGE recyclebin; (elimina todos los objetos de la papelera del usuario)
SQL> PURGE dba_recyclebin; (elimina todos los objetos de la papelera a nivel de base de datos, se debe conectar con usuario SYSDBA)
SQL> PURGE TABLESPACE users; (elimina todos los objetos de la papelera que pertenecen al tablespace users)

Y con esto tenemos nuestros tablespaces limpios de esos objetos que habian sido eliminados.

Saludos

Reducir tamaño de tablespace TEMP en Oracle 10g

El día de Hoy se presento este problema justo en el ambiente de produccion de Oracle 10g, el tablespace TEMP crecio intempestivamente a un tamaño de 23GB llenando casi a la unidad donde estaba alojada, como es en un ambiente de produccion que tiene que estar activa las 24 horas no hay forma casi de bajar la DB, asi es que tenia que hacerlo de otra forma online. Lo que al final hice fue lo siguiente:

1. Desde el sqlplus agregue un archivo temporal al tablespace TEMP de la siguiente manera:

Alter Tablespace TEMP ADD TEMPFILE '/d01/oradata/orabn/temp03.dbf' SIZE 4096M;

ven que le di un tamaño de 4GB, bueno le di ese tamaño para que tampoco en el ambiente de produccion no se quede muy chico, en mi caso yo ya tenia 2 archivos temporales asi es que cree el numero 3.

2. Ahora puse en OFFLINE los 2 tempfiles anteriores dejando solo como online al que agregue recien. Esto lo pueden hacer directamente desde el Enterprise Manager o tambien por comandos pero yo lo hice desde el EM.

3. Ahora le hice un DROP a los anteriores que habia puesto como OFFLINE con el sigueinte comando:

ALTER TABLESPACE TEMP DROP TEMPFILE '/d08/oradata/temp02.dbf';

y con eso libere el espacio que estaban utilizando en disco y ademas deje con un nuevo archivo Temp limpio y mas pequeño.

Hay que tener en cuenta que la informacion que se almacena en el TEMP no es relevante y se puede borrar con toda confianza.
Espero que les sirva.
Saludos

Error SQL*Loader-522 al realizar loader de Oracle

Este error se presento en una carga a la BD Oracle mediante el SQL Loader, como sabemos cuando hacemos cargas con esta herramienta de oracle esta genera un archivo de log, resulta que yo estaba haciendo la carga pero con 2 usuarios de SO diferentes pero trabajando sobre el mismo archivo, entonces los permisos de lectura que los tenia un usuario no los tenia el otro por lo tanto arrojaba el error de sql loader.
Asi es que en estos casos lo primordial es verificar los permisos de lectura y escritura sobre el archivo o archivos que se van a generar de log como de control.
La solucion fue simplemente modificar los permisos del archivo con un chmod 664 archivo.log siempre con el usuario root.

Bueno espero que esto que me paso a mi, les sirva de experiencia a uds.
saludos

"Operation not permitted" al hacer get de FTP

Hay dias que se hacen mas emocionantes cuando se presentan este tipo de problemas, resulta que hay una carga a la BD Oracle que pasa por 3 lugares, Desde el ambiente Host y BD Datacom se genera un archivo plano (.txt) con la informacion de unas tablas, este archivo plano luego es llevado mediante FTP hacia un servidor FTP(windows), una vez estando ahi el archivo plano es llevado hacia el servidor Linux con Oracle tambien mediante el comando get de FTP para ser cargado a las tablas de Oracle.

Bueno el caso es que el get desde el servidor windows hacia el servidor linux dejo de funcionar de un momento a otro mostrando el mensaje:

ftp> cd sghb
250 CWD command successful
ftp> get archivo.txt
ftp: bind: Operation not permitted

Inicialmente pense que eran permisos del servidor FTP que no permitian hacer el get, pero despues de una revision en ese servidor no era eso.

El problema era que tenia 2 usuarios de sistema operativo que hacian el FTP al mismo archivo y cuando el primero lo hacia dejaba al archivo con permisos de lectura y escritura pero solo para su usuario y no para el grupo como muestro:

-rw-r--r-- 1 oracle oinstall 1759510 Apr 22 05:04 BNT35124.TXT

Entonces cuando el otro usuario queria hacer FTP y chancar a ese archivo no podia porque no habia permisos y mostraba el mensaje de error.

Bueno la solucion que le di fue colocarle el parametro umask 0002 en el .bash_profile del otro usuario para que pueda escribir sobre el mismo archivo. la otra posible solucion seria eliminar los archivos del servidor Oracle para que asi el usuario que traiga los archivos no tenga el problema de chancar a los que ya estan. Una ultima solucion seria darle permisos al archivo pero de lectura-escritura tanto al usuario como al grupo ya que los dos pertenecen al mismo grupo.

Espero que haya servido esta experiencia de tantas que ayudan a enriquecer nuestros conocimientos, como digo siempre "cada vez que aprendo algo nuevo me doy cuenta lo poco que se".

ORA-29521 al hacer loadjava a JAR en linux

Este es un problema que se presento en un servidor Red hat con Oracle 10g, se tenia que cargar un grupo de jars para que un web service pueda funcionar, entonces con el usuario oracle de linux intente de hacerlo con el siguiente comando:

[oracle@srv1pbdor2 /]$ loadjava -v -r -user Usuario/XXXXXX .jar

donde :
Usuario -> es el usuario de BD
XXXXXX -> es el password del usuario de BD
-> es el nombre de la libreria que queremos cargar, por ejem: axis.jar

El hacerlo con ese comando me generaba el error ORA-29521 y no terminaba correctamente, para solucionar ese problema se tiene que obviar el parametro -r

El parametro -r significa "-resolve", con este parametro oracle resuelve todas las clases cargadas, pero si nosotros no le decimos que los resuelva las clases seran cargadas de todas maneras; entonces podemos hacer el loadjava sin ese parametro y no saldra ningun error y funcionara correctamente.

Alternativamente si necesitamos mantener ese parametro tambien podemos usar el parametro "-genmissing" que hara que pase los errores generados por el parametro "-resolve".

por lo tanto el comando a ejecutar y con el que solucione ese problema es el sgte:

[oracle@srv1pbdor2 /]$ loadjava -v -user Usuario/XXXXXX .jar

Espero les sirva este tip.

SQL2000 : DTS Manual funciona y mediante JOB no funciona

En estos dias se presento un problema en el servidor de Produccion con Sql2000, resulta que un DTS que esta programado para que se ejecute a cada hora todos los dias, cuando se hacia mediante un Job este no funcionaba como deberia ser, pero sin embargo cuando se ejecutaba manualmente desde el enterprise manager si lo hacia bien.

Bueno despues de darle vueltas al tema e investigar sobre las posibles causas por fin llegue a darle solucion que paso a contarles por si les ocurre tambien.

Como sabemos el que ejecuta el DTS a traves de un Job en sql2000 es el SQL Server Agent, el problema se debia a que la autenticacion no era la correcta. para dar solucion tenemos que ir al Enterprise Manager \ Management \ SQL Server Agent
luego darle click derecho al SQL Server Agent y click en properties, luego en la paleta General cambiar en Service startup account de System account a This account y ahi colocar el usuario de dominio administrador del servidor y su respectivo password.

Aceptamos y tenemos que reiniciar el servicio del Agente, con eso quedara solucionado el problema del Job que ejecuta un DTS.

Espero que les haya sido de utilidad.

Mensaje en export de Oracle : EXP-00091 Exporting questionable statistics

Al exportar unos esquemas en Oracle y sale el mensaje:
"EXP-00091 Exporting questionable statistics"

Este error sucede cuando exportamos tablas que han sido pasadas con el optimizador de estadisticas de Oracle y no puede verificar que tan actuales son esas estadisticas. Cuando las estadisticas CBO (Optimizador Basado en Costo) fueron creadas o actualizadas con el dbms_stats esa actualidad de las estadisticas se puede determinar.

Pero para que no nos salga ese error una buena practica seria no exportar las estadisticas ya que estas pueden ser generadas nuevamente despues del import

Para no exportar las estadisticas y que no salga el error EXP-00091 debemos incluir el parametro "statistics="none" dentro de nuestro export.

Espero que les pueda servir esta experiencia.

saludos