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
miércoles, 22 de abril de 2009
"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".
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.
[oracle@srv1pbdor2 /]$ loadjava -v -r -user Usuario/XXXXXX
donde :
Usuario -> es el usuario de BD
XXXXXX -> es el password del usuario de BD
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
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.
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.
jueves, 2 de abril de 2009
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
"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
Suscribirse a:
Entradas (Atom)
