Hola de nuevo. Voy a empezar a escribir más seguido, con cosas sencillas y aunque no me parezcan muy interesantes, pero que igual se que pueden servir a quien posiblemente lea, o busque en este información.
Un cliente con el que trabajo tiene SAP. El caso es que estaba instalando el software de Oracle que va a usar SAP, y me encontré con algo bastante curioso.
MOPatch, que es un shell script muy sencillo, que lo puedes bajar desde Metalink, y que te ahorra tiempo en la “tediosa” instalación de los interim patchsets.
Este MOPatch NO SIRVE PARA CPU (Critical Patch Updates). De todos modos, no veo necesario usa MOPatch para los CPU. Los CPU son muy cómodos por la forma de usar las moléculas, que me parece muy interesantes. Pero sigamos con MOPatch.
Mi historia. Tengo 48 iterim_patch que instalar, lo puedo hacer por la forma tradicional del optach:
$> cd {PATCHSET_SPACE}
$> unzip p_{PATCHSET_NUMBER}_{RELEASE}.zip
$> cd {PATCHSET_NUMBER}
$> optach apply
Y empieza, tarda un rato y acaba. Imaginen hacerlo 48 veces. Puff, mucho tiempo consumido, para esta labor. Encontré que los buenos de SAP (Notas de SAP) junto con Oracle crearon este shell script, para hacerlo más fácil. Ello tiene controlados, todos los interim_patchset que necesita cada versión de Oracle, para que su producto no tenga problemas. Problemas que tienen detectados, y que te dan ya desde su página un ZIP, para que lo descargues. Además este “shell script” te “ayuda” con el tema del espacio que consumes. Así que si tienes una instalación por hacer, y en tu empresa tienen por norma no copiar el software de Oracle y recompilarlo. Este es un modo que te ayuda un poco en el tiempo, y además en la tarea de instalar un mundo de parches.
La nota de Metalink donde te puedes descargar este script es:
Doc Id. 814845.1
Patching of Oracle Databases and Real Application Clusters with Shared Oracle Homes using EM Deployment procedures integrated with MOPatch
Es muy fácil de usar, tienes que dejar en el zip mopatch-1_9.zip en el $ORACLE_HOME. Después lo descomprimes. El te crea el directorio $ORACLE_HOME/MOPatch. En ese directorio te deja dos ficheros:
mopatch.sh
readme.txt
Y bueno, si quieres te lees el readme.txt porque tiene muchas opciones. Pero los pasos son:
• Ir al directorio donde están todos los parches comprimidos que bajaste de Metalink, En mi caso los que estaban en SAP de la versión 10.2.0.4.
• Y ejecutar :
$> $ORACLE_HOME/MOPatch/mopatch –v –s {PATCHSET_SPACE}
Cuenta cuantos patchsets va a instalar y te va diciendo si los ha instalado. Si falla por algún motivo, diferente a los que tiene controlados como que es un CPU, no sigue. Esto es lo único que no me pareció. Al final hace te crea un link.sh, que el mismo ejecuta, si todo va bien.
Yo sin embargo, después que aplico los parches, generalmente hago un:
$> $ORACLE_HOME/bin relink –all
Quiero recordar que si es AIX, hay que ejecutar anets como root slibclean.
Espero que usen esto y me digan si les ahorra o no tiempo.
viernes, 25 de septiembre de 2009
martes, 8 de septiembre de 2009
Ellas no tienen la culpa...
Buenas,
He estado de vacaciones. Les recomiendo ir a visitar antes de morir, alguna isla griega, bueno, Grecia en general.
Estoy preparando otro examen de los de Oracle, pero no quiero dejar pasar la oportunidad de decirles algo, que he venido pensando desde hace tiempo, y que hoy quiero compartir. Si alguien leé este blog :).
Las bases de datos que administran, crean o afinan, no tienen que ser las afectadas directas de sus personalidades.
Si eres inteligente, tarado, amargado, alegre, egosita, generoso, petulante, humilde, etc. Como sea que seas. Las bases de datos, son las que se ven altamente perjudicadas por tu forma de se; si no tienes un método a seguir, en tu trabajo contidiano con ellas.
Si eres una persona descuidada, te dejaras cosas sin analizar, sin revisar. Si eres demasiado obstinado, te enfocas en un solo objetivo y no tendras una visión holística de esa bases de datos. Si eres charlatan, buscas cualquier excusa para decir que no es la base de datos, y que es la aplicación, el sistema operativo, la red, ó lo que sea. Si eres un holganzán, simplemente no investigas el error.
Todo esto, es una de las causas reales del mal funcionamiento de los sistemas, por tanto las bases de datos. Y además, porque también chocamos frontalmente y a diario con otras mentalidades ó personalidades, y como conclusión las grandes perjudicadas son ellas, las bases de datos.
Esto es matemática, es informática, y por tanto, una ciencia. No es en ningun momento un arte.
En una cadena de producción (gracias Ford), hay un tiempo en el que se hace cada labor. Así bien, debemos intentar llegar a un punto cercano.
Creo fielmente que debemos buscar ese objetivo, y no es más, que ser objetivos.
Cuando te piden resolver un problema matemático, simplemente buscas la fórmula que aplica, y lo intentas solucionar.
¿Quien no se queja de algunos médicos?
Pues esto, es algo parecido. Cuando vas al doctor, si el doctor de turno está de mal genio, ó el doctor de turno es una persona "demasiado alegre", ó no es objetivo. Probablemente no haga su labor, y esto lleva a tu enfado ó molestia, con la posibilidad que la enfermedad se agrave.
Este trabajo ó profesión, la informática, tiene mucho en común. Pero las que sufren son maquinas, y ellas no se quejan. Simplemente dejan de funcionar, ó tienen un rendimiento paupérrimo
Por favor, recuerden SIEMPRE una fórmula muy simple, pero bastante efectiva, de muchos documentos oficiales de Oracle:
Tiempo de respuesta = Tiempo de Servicio + Tiempo de espera
A diferencia de los médicos, aquí en las bases de datos 1 + 1, si que es igual a 2. Si haces un FULL SCAN, ó RANGE SCAN, ó UNIQUE INDEX, deberías saber cuantos bloques usas (No en todos los casos ;).
Si tarda 50 segundos en ejecutar una consulta, tarda eso 50 segundos. Son números. Para los médicos, 1 + 1 no son 2, así que ellos lo tienen más complicado, y su ciencia sigue en pie, creciendo, y en la que muchos confiamos.
Existen muchos documentos públicos y gratis, donde explican razonamientos metódicos de resolución de problemas. Ahora está de moda el troubleshooting. También bastantes documentos de tuning, algo que es bastante más complicado que el troubleshooting.
Espero algún día no muy lejano, sintetizar varios de los documentos de lo que les hablo y que he medio leído, y regalarlo. Si, regalarlo aquí, en este blog. Por si a alguien le sirve.
Así, si están de mal genio, si tienen hambre, si tienen frio, si están contentos, si están nerviosos. Estén como estén, sus bases de datos no sufren sus cambios temporales de humor, y tampoco de sus respectivas personalidades. Porque podrán seguir un guión, para cada una de las situaciones correspondientes a sus diversos problemas diarios con las bases de datos, no con sus vidas.
Personalmente intento a diario aplicarme este pensamiento. En ocasiones lo consigo, pero en muchas otras, me dejo llevar de mi pasión por mi profesión.
He estado de vacaciones. Les recomiendo ir a visitar antes de morir, alguna isla griega, bueno, Grecia en general.
Estoy preparando otro examen de los de Oracle, pero no quiero dejar pasar la oportunidad de decirles algo, que he venido pensando desde hace tiempo, y que hoy quiero compartir. Si alguien leé este blog :).
Las bases de datos que administran, crean o afinan, no tienen que ser las afectadas directas de sus personalidades.
Si eres inteligente, tarado, amargado, alegre, egosita, generoso, petulante, humilde, etc. Como sea que seas. Las bases de datos, son las que se ven altamente perjudicadas por tu forma de se; si no tienes un método a seguir, en tu trabajo contidiano con ellas.
Si eres una persona descuidada, te dejaras cosas sin analizar, sin revisar. Si eres demasiado obstinado, te enfocas en un solo objetivo y no tendras una visión holística de esa bases de datos. Si eres charlatan, buscas cualquier excusa para decir que no es la base de datos, y que es la aplicación, el sistema operativo, la red, ó lo que sea. Si eres un holganzán, simplemente no investigas el error.
Todo esto, es una de las causas reales del mal funcionamiento de los sistemas, por tanto las bases de datos. Y además, porque también chocamos frontalmente y a diario con otras mentalidades ó personalidades, y como conclusión las grandes perjudicadas son ellas, las bases de datos.
Esto es matemática, es informática, y por tanto, una ciencia. No es en ningun momento un arte.
En una cadena de producción (gracias Ford), hay un tiempo en el que se hace cada labor. Así bien, debemos intentar llegar a un punto cercano.
Creo fielmente que debemos buscar ese objetivo, y no es más, que ser objetivos.
Cuando te piden resolver un problema matemático, simplemente buscas la fórmula que aplica, y lo intentas solucionar.
¿Quien no se queja de algunos médicos?
Pues esto, es algo parecido. Cuando vas al doctor, si el doctor de turno está de mal genio, ó el doctor de turno es una persona "demasiado alegre", ó no es objetivo. Probablemente no haga su labor, y esto lleva a tu enfado ó molestia, con la posibilidad que la enfermedad se agrave.
Este trabajo ó profesión, la informática, tiene mucho en común. Pero las que sufren son maquinas, y ellas no se quejan. Simplemente dejan de funcionar, ó tienen un rendimiento paupérrimo
Por favor, recuerden SIEMPRE una fórmula muy simple, pero bastante efectiva, de muchos documentos oficiales de Oracle:
Tiempo de respuesta = Tiempo de Servicio + Tiempo de espera
A diferencia de los médicos, aquí en las bases de datos 1 + 1, si que es igual a 2. Si haces un FULL SCAN, ó RANGE SCAN, ó UNIQUE INDEX, deberías saber cuantos bloques usas (No en todos los casos ;).
Si tarda 50 segundos en ejecutar una consulta, tarda eso 50 segundos. Son números. Para los médicos, 1 + 1 no son 2, así que ellos lo tienen más complicado, y su ciencia sigue en pie, creciendo, y en la que muchos confiamos.
Existen muchos documentos públicos y gratis, donde explican razonamientos metódicos de resolución de problemas. Ahora está de moda el troubleshooting. También bastantes documentos de tuning, algo que es bastante más complicado que el troubleshooting.
Espero algún día no muy lejano, sintetizar varios de los documentos de lo que les hablo y que he medio leído, y regalarlo. Si, regalarlo aquí, en este blog. Por si a alguien le sirve.
Así, si están de mal genio, si tienen hambre, si tienen frio, si están contentos, si están nerviosos. Estén como estén, sus bases de datos no sufren sus cambios temporales de humor, y tampoco de sus respectivas personalidades. Porque podrán seguir un guión, para cada una de las situaciones correspondientes a sus diversos problemas diarios con las bases de datos, no con sus vidas.
Personalmente intento a diario aplicarme este pensamiento. En ocasiones lo consigo, pero en muchas otras, me dejo llevar de mi pasión por mi profesión.
Suscribirse a:
Entradas (Atom)