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.
miércoles, 24 de junio de 2009
Tu, administrador, eres solo otro tipo de operador
Hablando con un buen administrador de Unix me comentó, en un día un poco aburrido para él, que iba a cambiar en su firma de “Administrador Unix” a “Operador nivel 2”, que al final muchas veces se siente que hace justo eso. Y me hizo pensar en escribir sobre esto, sobretodo por varios comentarios entre los diversos clientes en los que he estado, acerca del trabajo de los operadores. Sin ir más lejos, yo mismo, cuando me dijeron en un proyecto que las migraciones se llevaban con solo operadores, contratados para darle a al botón de “Press Button to Migrate” de una herramienta que migraba de 8i y 9i a 10g (Que realmente con ejecutar un par de comandos, mentira gorda), el caso es que yo mismo pensé “¿Un operador puede hacer eso? Vaya herramienta”. Al final creo que estaba siendo un poco despectivo con los operadores, y la verdad “Yo soy también un operador”.
Y esa es la cruel realidad, somos “operadores” de “alto” nivel, de herramientas como Unix, Oracle, Veritas, SAP, etc. Entonces al final, creo que muchos deberían replantearse el tratar despectivamente a los operadores y a los programadores, por que, los primeros son como nosotros pero con algo menos de conocimiento (algunos administradores ni eso). Y ellos, al igual que nosotros, cogen su “manual de operaciones” para resolver ciertas incidencia, y las incidencias que no se pueden apuntar en ese manual, son las hacemos nosotros.
Los administradores también tiene su “manual de operaciones”, y un ejemplo es el “SQL Reference” ó el manual del administrador ó el de “Tuning de Unix” ó el de “Backup & Recover Advance”, pero al final si la analizas bien, siguen siendo unos manuales de operaciones, más extensos, eso si. Y para bajarnos un poco más de la nube, los programadores si que son los importantes en todo esto, ya que sus programitas hacen que nuestra vida sea más o menos fácil. Si ellos se equivocan tenemos un “BUG” y a consultar parches, ó si ellos lo hacen bien y su analista también lo hace bien, pues tienes amplias opciones para configurar y optimizar una base de datos, un sistema operativo ú otro producto. Pero al final son ellos los buenos, así que replanteemos ¿Qué voy a hacer cuando un operador te llama a las 4 de la mañana a reportarte un problema que para ti no es problema? Pensar que no encontró la solución en “su manual” y que te llama por ese motivo, así como te puede pasar a ti, cuando los manuales súper avanzados, no te dan la respuesta.
Otro tema que está dentro de éste, es lo que Oracle llama DBA 2.0. Interesante, para los que no tienen idea de lo que es esto, pues simplemente como Oracle ya tiene un Oracle Linux Enterprise 4 y 5, como además tienes Clusterware y ASM, pues para ellos el administrador a “dado un paso adelante” en lo que es el ”todo” de los sistemas, porque estas incluyendo para los roles de un “ operador avanzado de Oracle” un sistema operativo, el almacenamiento y el clustering. Pero además te mete herramientas “avanzadas” de optimización, como son todos los “..ADVICE” (las vistas que terminan en eso), también tienes el replay (a partir de la 10.2.0.4), también tenemos el ADDM y todos los “automatic managemente” (UNDO, SGA, PGA, MEMORY) y que quede claro que no estoy en contra de estas opciones, de lo que estoy en contra es de no saber al final lo que realmente está pasando “dentro” de la base de datos. Y todo porque no te da tiempo a leer como montar ó como manejar en todo lo nuevo que están introduciendo Oracle.
Hace un tiempo le dije a un cliente que revisara el almacenamiento de una tabla, y me contesta que el “Segment Advisor” no le da ninguna recomendación, y que por eso no va a hacer nada, y me preguntó que más hacía con esa tabla. Y es esto, es precisamente a lo que me refiero, el DBA 2.0, sin querer te va a llevar hasta esta situación. Si damos un par de pasos atrás, ser OCP 8i era todo un reto, y ahora ser OCP 10g hasta hace poco no te exigían ni el examen de SQL (lo cambiaron en diciembre de 2008). Antes eran 5 exámenes, el de SQL, PL/SQL, Administración I y II, y tuning. Después quitaron la parte de PL/SQL, y por último pasaron a solo 2 exámenes (Primero OCA y después OCP), y es algo en lo que estoy de acuerdo, porque ASM, FLASHBACK, RMAN, Advisors, los nuevos tipos de segmentos, etc. es mucho material, pues si, si quieres saber que hay por dentro. Pero entonces con todo esto ¿Donde queda tu “control” o el control de lo que haces? La verdad, personalmente (y otros amigos también me lo comentan) prefiero al DBA 1.1 y si puede ser el DBA 0.7, ese que pasó de la versión 7.3.3 a la 8.1.4 y después se deslumbró con la 9.2.0.4. Prefiero a ese que sabía en la 9i como iban los rollback segments, ese que también conocía como tratar los diferentes parámetros para la PGA en dedicado (bitmap, sort, hash y merge), ese que hacia el examen de tuning.
Con la 10g, tienes un mundo inmenso por conocer, y es realmente impresionante todo lo nuevo que hay. Pero no le daría “tanta” importancia a las herramientas que te “facilitan” la vida. Le daría más importancia a saber ó intentar entender, que es lo que se cuece por dentro. Para realmente decirle a los clientes que es lo que realmente necesitan, y de acuerdo a cada situación implementar justo lo necesario. Si que hay muchas cosas que ver y conocer, es más, ejemplo clarísimo, sql_id, que para mi es un alivio, ver mis consultas completas (sql_fulltext.v$sqlstats), y que también puedo ver con las DBA_HIST_% (Es una licencia aparte en la 10g y en la 11g viene incluidas, según lo leído en otros blogs) información de varios días atrás para intuir algunos problemas.
En conclusión, los administradores no debemos ponernos muchas más medallas que los operadores, porque al final lo somos. Y además, creo que es bonito seguir intentando entender como va la LRU y la LRUW del buffer cache, saber como van los latch, mutex, enqueues, ó saber todos los parámetros que hay por ejemplo en el log_archive_dest_n ó como intentar hacer que una consulta tenga menos lecturas lógicas, prefiero estos antes que saber como sacar un reporte ADDM ó como se usa el DBMS_SQLTUNE. Que repito, está bien conocerlos y probarlos, pero no basar tu vida de operador nivel 2 en ellos.
Y esa es la cruel realidad, somos “operadores” de “alto” nivel, de herramientas como Unix, Oracle, Veritas, SAP, etc. Entonces al final, creo que muchos deberían replantearse el tratar despectivamente a los operadores y a los programadores, por que, los primeros son como nosotros pero con algo menos de conocimiento (algunos administradores ni eso). Y ellos, al igual que nosotros, cogen su “manual de operaciones” para resolver ciertas incidencia, y las incidencias que no se pueden apuntar en ese manual, son las hacemos nosotros.
Los administradores también tiene su “manual de operaciones”, y un ejemplo es el “SQL Reference” ó el manual del administrador ó el de “Tuning de Unix” ó el de “Backup & Recover Advance”, pero al final si la analizas bien, siguen siendo unos manuales de operaciones, más extensos, eso si. Y para bajarnos un poco más de la nube, los programadores si que son los importantes en todo esto, ya que sus programitas hacen que nuestra vida sea más o menos fácil. Si ellos se equivocan tenemos un “BUG” y a consultar parches, ó si ellos lo hacen bien y su analista también lo hace bien, pues tienes amplias opciones para configurar y optimizar una base de datos, un sistema operativo ú otro producto. Pero al final son ellos los buenos, así que replanteemos ¿Qué voy a hacer cuando un operador te llama a las 4 de la mañana a reportarte un problema que para ti no es problema? Pensar que no encontró la solución en “su manual” y que te llama por ese motivo, así como te puede pasar a ti, cuando los manuales súper avanzados, no te dan la respuesta.
Otro tema que está dentro de éste, es lo que Oracle llama DBA 2.0. Interesante, para los que no tienen idea de lo que es esto, pues simplemente como Oracle ya tiene un Oracle Linux Enterprise 4 y 5, como además tienes Clusterware y ASM, pues para ellos el administrador a “dado un paso adelante” en lo que es el ”todo” de los sistemas, porque estas incluyendo para los roles de un “ operador avanzado de Oracle” un sistema operativo, el almacenamiento y el clustering. Pero además te mete herramientas “avanzadas” de optimización, como son todos los “..ADVICE” (las vistas que terminan en eso), también tienes el replay (a partir de la 10.2.0.4), también tenemos el ADDM y todos los “automatic managemente” (UNDO, SGA, PGA, MEMORY) y que quede claro que no estoy en contra de estas opciones, de lo que estoy en contra es de no saber al final lo que realmente está pasando “dentro” de la base de datos. Y todo porque no te da tiempo a leer como montar ó como manejar en todo lo nuevo que están introduciendo Oracle.
Hace un tiempo le dije a un cliente que revisara el almacenamiento de una tabla, y me contesta que el “Segment Advisor” no le da ninguna recomendación, y que por eso no va a hacer nada, y me preguntó que más hacía con esa tabla. Y es esto, es precisamente a lo que me refiero, el DBA 2.0, sin querer te va a llevar hasta esta situación. Si damos un par de pasos atrás, ser OCP 8i era todo un reto, y ahora ser OCP 10g hasta hace poco no te exigían ni el examen de SQL (lo cambiaron en diciembre de 2008). Antes eran 5 exámenes, el de SQL, PL/SQL, Administración I y II, y tuning. Después quitaron la parte de PL/SQL, y por último pasaron a solo 2 exámenes (Primero OCA y después OCP), y es algo en lo que estoy de acuerdo, porque ASM, FLASHBACK, RMAN, Advisors, los nuevos tipos de segmentos, etc. es mucho material, pues si, si quieres saber que hay por dentro. Pero entonces con todo esto ¿Donde queda tu “control” o el control de lo que haces? La verdad, personalmente (y otros amigos también me lo comentan) prefiero al DBA 1.1 y si puede ser el DBA 0.7, ese que pasó de la versión 7.3.3 a la 8.1.4 y después se deslumbró con la 9.2.0.4. Prefiero a ese que sabía en la 9i como iban los rollback segments, ese que también conocía como tratar los diferentes parámetros para la PGA en dedicado (bitmap, sort, hash y merge), ese que hacia el examen de tuning.
Con la 10g, tienes un mundo inmenso por conocer, y es realmente impresionante todo lo nuevo que hay. Pero no le daría “tanta” importancia a las herramientas que te “facilitan” la vida. Le daría más importancia a saber ó intentar entender, que es lo que se cuece por dentro. Para realmente decirle a los clientes que es lo que realmente necesitan, y de acuerdo a cada situación implementar justo lo necesario. Si que hay muchas cosas que ver y conocer, es más, ejemplo clarísimo, sql_id, que para mi es un alivio, ver mis consultas completas (sql_fulltext.v$sqlstats), y que también puedo ver con las DBA_HIST_% (Es una licencia aparte en la 10g y en la 11g viene incluidas, según lo leído en otros blogs) información de varios días atrás para intuir algunos problemas.
En conclusión, los administradores no debemos ponernos muchas más medallas que los operadores, porque al final lo somos. Y además, creo que es bonito seguir intentando entender como va la LRU y la LRUW del buffer cache, saber como van los latch, mutex, enqueues, ó saber todos los parámetros que hay por ejemplo en el log_archive_dest_n ó como intentar hacer que una consulta tenga menos lecturas lógicas, prefiero estos antes que saber como sacar un reporte ADDM ó como se usa el DBMS_SQLTUNE. Que repito, está bien conocerlos y probarlos, pero no basar tu vida de operador nivel 2 en ellos.
viernes, 19 de junio de 2009
Mas del 4031 y sub-pools
Se va a hacer de rogar el post de CPU Costing de Ricardo, pero es que tengo un pequeño detalle que intenté dejarle a un comentario a Tanel Poder del post que puso hace unos días, pero al final no pude. Así que primero, incentivarlos leer el blog de Tanel Poder que me parece genial, y decirles que allí hay un buen post sobre los errores 4031 y de la shared pool y los sub-pools en:
ORA-04031 errors and monitoring shared pool subpool memory utilization with sgastatx.sql
El caso es que se habla de una sub-pool 0, y que es memoria que no se le da al resto de las sub-pools de la shared pool. Bueno solo añadir que este espacio de memoria que describe Tanel en su blog no existe cuando está desactivado el manejo automático de memoria conocido como ASMM (Automatic Shared Memory Management), que pasa cuando tienes el parámetro SGA_TARGET a 0 ó el parametro STATISTICS_LEVEL en “BASIC”. Realicé una pequeña prueba y este fue el resultado:
ORA-04031 errors and monitoring shared pool subpool memory utilization with sgastatx.sql
El caso es que se habla de una sub-pool 0, y que es memoria que no se le da al resto de las sub-pools de la shared pool. Bueno solo añadir que este espacio de memoria que describe Tanel en su blog no existe cuando está desactivado el manejo automático de memoria conocido como ASMM (Automatic Shared Memory Management), que pasa cuando tienes el parámetro SGA_TARGET a 0 ó el parametro STATISTICS_LEVEL en “BASIC”. Realicé una pequeña prueba y este fue el resultado:
lunes, 15 de junio de 2009
El gran misterio del log_buffer
Buenas de nuevo, escribo algo muy sencillo, pero que he visto que está extendido en varias bases de datos que he tocado. Lo llamaré “El gran misterio log_buffer”. Y es que he visto en más de una ocasión que el valor de este parámetro está puesto a 10M y hasta 32M. Y me pregunto ¿Por qué y para qué?
He notado que algunos administradores tienden a aumentar el tamaño de este valor cada vez que aumentan el tamaño de su SGA, pero esto sin duda alguna, es una “mala” práctica, y ahora les explico porqué. Para ello primero me pregunto ¿Para que uso ese pedacito de memoria y como funciona? Cada vez que realizo hago cambios (Insert, Delete, Update, y más cosas) estos cambios se guardan en memoria temporalmente, justo ahí, en el redo log buffer, y el tamaño de este buffer lo determina el parámetro log_buffer. Si ocurren ciertos eventos, un proceso llamado Log Writer (LGWR) “escribe” la información que está en esa parte de la memoria a los Online Redo logs, mejor, realmente “vuelca” (flush en ingles) la información de memoria a disco, y reutiliza ese espacio. Con esto se esta intentando guardar la integridad de los datos y de la base de datos (a groso modo).
Pero ¿Cada cuanto vuelco esta información que está en la memoria a disco?
Existen varios eventos por los que se producen estas escrituras. Quien lo describe perfectamente es Tom Kyte en su libro “Expert Oracle database architecture” en la página 176, donde dice que estos eventos (LGWR despierta para trabajar) se ejecutan cada:
- Tres segundos
- “COMMIT” de cualquier transacción
- Cuando se llega a un tercio del tamaño del redo log buffer
- Cuando llega a 1M de información
También pueden encontrar esta información en METALINK en la nota “Tuning the Redolog Buffer Cache and Resolving Redo Latch Contention” con id 147471.1, ó también esto mismo lo podemos leer en el documento "Performance Tuning Guide " ya sea 9i ó 10g, en el capitulo de "Memory Configuration and Use" en la parte de "Configuring and using the Redo Log Buffer".
Entonces teniendo en cuenta que se va a realizar un volcado de esta información cada vez que llegue a 1M, ¿Por qué tengo 14M ó incluso 30M de redo log buffer? La verdad, no lo se y no lo entiendo, el caso es que he encontrado estos “detalles” en muchísimas bases de datos. Y los argumentos de algunos son : que es un OLTP (gran volumen de transacciones), o que su SGA es muy grande, y otra razón que también escucho es que como tienen muchas CPU pues deducen (ejemplo: 32*512K dan 16M de log_buffer) tal y como dice el DBA Reference. Pero realmente creo que muchos DBAs no ven normal que el resto de “pools” de la SGA vayan creciendo según la carga y/o el tipo de uso de la base de datos y que esta parte de la memoria no lo crezca también, y simplemente la aumentan por si acaso, creo.
Pero es cierto es una “mala” practica, sino pruébenlo, pasen de 14M (si lo tienen) a 3M, en sus base de datos (8i, 9i ó 10g), miren si el rendimiento de su base de datos decrece.
Realmente no importa mucho si tienes 32 Gigas de memoria y de SGA tienes 24. Al final lo único que estas haciendo es desperdiciar unos pocos megas, tal y como lo dice Tom.
Este pequeño espacio de memoria le viene muy bien a otras partes de la SGA, y no veo conveniente desperdiciar ni bloque del sistema para nada, solo por un mal mito repartido en muchos sitios.
Si después de esta prueba ven que el rendimiento decrece o es malo por este cambio, por favor envíenme la demostración "real" que estoy deseoso de verla, ya que confío y creo que esto no se produce.
Por cierto, si realmente consumen menos de 300K de información de redo por segundo (el dato aparece en los reportes AWR), no es necesario ni siquiera llegar hasta los 3M, con menos de esto valor nos vale (calcúlalo con lo antes explicado ;). Es poco común, pero este mundo es muy grande. Claro, que tampoco es correcto poner un valor muy pequeño, y ese es el momento donde posiblemente tengas algún problema, reduciéndolo demasiado.
jueves, 28 de mayo de 2009
V$RMAN_STATUS lento
Hola a todos,
El segundo tema de hoy (impresionante 2 en un día después de 6 meses) fue que la gente de BACKUP me comentó que fallaron unos backups de archive logs, y cuando me envían el fichero de log del error, era un timeout, así que ni idea.
Así que bien, como no tengo idea de DATA PROTECTOR, ni de lo que hace por dentro, le pedí a uno de los que administran DATA PROTECTOR que me explicaran un poco la arquitectura y lo que estaba haciendo. Al final deducimos que se quedaba en la ejecución de RMAN.
Después el impresionante seminario con Tanel Poder (Oracle Advance Troubleshooting), del cual comentaré otro día, me dí cuenta que esto le venía bien a su método. Tanel se basa en la sesiones, porque al final ella te va a reportar el error y efectivamente así pasó. Pero fue más "sencillo" de lo normal.
Le pedí a los de BAKCUP que lanzaran de nuevo el BACKUP, después de un rato salió el problema, 2 sesiones estaban consumiendo al 100% una core cada una, con el comando "top" (HP-UX) verifiqué, que el "pid", y lancé la siguiente consulta para ver que estaba ejecutando:
set lines 125 pages 50000 long 200000000
select s.username, s.program, a.sql_id,
p.spid, s.sid, s.status,
s.event, a.sql_fulltext
from v$session s, v$sqlstats a, v$process p
where s.sql_id= a.sql_id
and s.paddr = p.addr
and s.sql_hash_value <> 0
order by 5
/
En mi caso la base de datos desocupada en ese momento, y estaba bastante libre, por tanto no tenía muchas salidas y pude ver fácilmente el pid del server proces que es el spid.v$process. Y la magnifica consulta que tardaba mil años y que consumía muchísima CPU era la siguiente:
select round(sum(MBYTES_PROCESSED)) ,
round(sum(INPUT_BYTES)) ,
round(sum(OUTPUT_BYTES))
from V$RMAN_STATUS
start with (RECID=:b1 and STAMP=:b2)
connect by prior RECID=parent_recid
Obtuve el sql_id, por tanto también tenía el plan de ejecución (dbms_xplan) para comprobar que estaba teniendo problemas, y la verdad es que estaba un poco mal. Entonces hice una consulta sencilla para empezar:
select count(8)
from v$rman_status;
Y efectivamente me tocó “cortarla” (Ctrl+C). Después intenté ver lo que pasaba en otra base de datos, y me dió que era inmediata la consulta, fui a otra base de datos y lo mismo, era inmediata. Así bien tenía problemas en esa consulta y solo en esa base de datos. Dos magnificas vistas que consulto para ver que hace Oracle por dentro son:
v$fixed_view_definition
v$fixed_table
En la primera en el campo view_definition te describe las vistas V$. Pues bien al final del todo eran solo tres tablas X$:
X$KSFQP
X$KCCRSR
X$KRBMRST
Empecé con una prueba sencillita:
select /*+ RULE */ count(8)
from v$rman_status;
Y “voila” tardó milésimas de segundo en ejecutarme la consulta, igual que en la otras base de datos. Hablé con el personal de BACKUP y recomendé que dentro del bloque de comandos agregaran lo siguiente:
RUN
{
SQL “ALTER SESION SET OPTIMIZER_MODE=RULE”
……
}
Pues no se pudo, al final no, preferí hacer esto porque no quise entrar en obtener estadísticas de estas tablas, ya que hasta ese momento no sabía a que otras cosas afectaba el tocar estas tablas. Al final consulté todas las vistas (v$fixed_view_defintion) V$ que utilizan estas X$ y era SOLO esa, así que bien, ¿Cómo se hace para no usar el CBO sino RBO? Si las tablas no tienen estadísticas no le queda otra que usar RBO, así que decidí borrar las estadísticas de esas tablas con lo siguiente:
exec dbms_stats.delete_table_stats(ownname=>'SYS',tabname => 'X$KSFQP' );
exec dbms_stats.delete_table_stats(ownname=>'SYS',tabname => 'X$KCCRSR' );
exec dbms_stats.delete_table_stats(ownname=>'SYS',tabname => 'X$KRBMRST');
Y todavía no servía, sin que sirva de precedente, estas alguna de estas tablas hace referencia al control file, pero recrearlo era mi última opción. Siguiente:
exec dbms_stats.gather_table_stats(ownname=>'SYS',tabname => 'X$KSFQP' );
exec dbms_stats.gather_table_stats(ownname=>'SYS',tabname => 'X$KCCRSR' );
exec dbms_stats.gather_table_stats(ownname=>'SYS',tabname => 'X$KRBMRST');
Y efectivamente mi consulta sin el HINT tardó milésimas de segundo, BIEN!!!. Esto es una forma rápida, para solucionar el problema, realmente, lo que debí hacer es verificar donde se estaba quedando la consulta verificar que tienen estas X$ y lanzar las estadísticas de una forma conciente y correcta, ¿Por qué? Hay un buen documento de Jonathan Lewis que explica bastante bien la cantidad de estadísticas necesarias. Además de este documento, debemos saber que el valor del parámetro de DBMS_STAT en el METHOD_OPT por defecto es “FOR ALL COLUMNS SIZE AUTO” y esto es “MONSTRUOSO” y sino que se lo pregunten a mi compi y amigo Ricardo, y él con documentación Oracle de metalink se los explica bien, o yo lo haré pero en otro post.
El caso es que en ese momento, decidí tirar por la vía rápida (mil disculpas Ricardo) pero funcionó, recolectó estadísticas de esas tablas y la consulta iba bien, por tanto el RMAN función y pudo realizarse el BACKUP de los ARCHIVE LOGs correctamente.
Al final las V$ que la mayoría son las GV$ sin la columna INST_ID, son consultas, así bien, algunos de los problemas que puedas tener viene provocados por la consulta a tablas X$, que estas pueden ser tablas ó estructuras en memoria. Por favor, NO RECOLETAR estadísticas por LEY, NO!!!, hay que pensar que pasa en la consulta, para este caso en concreto decidí hacerlo así prque me iba a quedar sin espacio en el filesystem donde están almacenados los ARCHIVE LOGs, pero si tiene que ver con V$ revisar mil veces antes, estas NO se pueden cambiar, por tanto hice lo rápido.
Más tormentoso, pero que también podría funcionar es lanzar:
exec dbms_stats.gather_dictionary_stats();
El segundo tema de hoy (impresionante 2 en un día después de 6 meses) fue que la gente de BACKUP me comentó que fallaron unos backups de archive logs, y cuando me envían el fichero de log del error, era un timeout, así que ni idea.
Así que bien, como no tengo idea de DATA PROTECTOR, ni de lo que hace por dentro, le pedí a uno de los que administran DATA PROTECTOR que me explicaran un poco la arquitectura y lo que estaba haciendo. Al final deducimos que se quedaba en la ejecución de RMAN.
Después el impresionante seminario con Tanel Poder (Oracle Advance Troubleshooting), del cual comentaré otro día, me dí cuenta que esto le venía bien a su método. Tanel se basa en la sesiones, porque al final ella te va a reportar el error y efectivamente así pasó. Pero fue más "sencillo" de lo normal.
Le pedí a los de BAKCUP que lanzaran de nuevo el BACKUP, después de un rato salió el problema, 2 sesiones estaban consumiendo al 100% una core cada una, con el comando "top" (HP-UX) verifiqué, que el "pid", y lancé la siguiente consulta para ver que estaba ejecutando:
set lines 125 pages 50000 long 200000000
select s.username, s.program, a.sql_id,
p.spid, s.sid, s.status,
s.event, a.sql_fulltext
from v$session s, v$sqlstats a, v$process p
where s.sql_id= a.sql_id
and s.paddr = p.addr
and s.sql_hash_value <> 0
order by 5
/
En mi caso la base de datos desocupada en ese momento, y estaba bastante libre, por tanto no tenía muchas salidas y pude ver fácilmente el pid del server proces que es el spid.v$process. Y la magnifica consulta que tardaba mil años y que consumía muchísima CPU era la siguiente:
select round(sum(MBYTES_PROCESSED)) ,
round(sum(INPUT_BYTES)) ,
round(sum(OUTPUT_BYTES))
from V$RMAN_STATUS
start with (RECID=:b1 and STAMP=:b2)
connect by prior RECID=parent_recid
Obtuve el sql_id, por tanto también tenía el plan de ejecución (dbms_xplan) para comprobar que estaba teniendo problemas, y la verdad es que estaba un poco mal. Entonces hice una consulta sencilla para empezar:
select count(8)
from v$rman_status;
Y efectivamente me tocó “cortarla” (Ctrl+C). Después intenté ver lo que pasaba en otra base de datos, y me dió que era inmediata la consulta, fui a otra base de datos y lo mismo, era inmediata. Así bien tenía problemas en esa consulta y solo en esa base de datos. Dos magnificas vistas que consulto para ver que hace Oracle por dentro son:
v$fixed_view_definition
v$fixed_table
En la primera en el campo view_definition te describe las vistas V$. Pues bien al final del todo eran solo tres tablas X$:
X$KSFQP
X$KCCRSR
X$KRBMRST
Empecé con una prueba sencillita:
select /*+ RULE */ count(8)
from v$rman_status;
Y “voila” tardó milésimas de segundo en ejecutarme la consulta, igual que en la otras base de datos. Hablé con el personal de BACKUP y recomendé que dentro del bloque de comandos agregaran lo siguiente:
RUN
{
SQL “ALTER SESION SET OPTIMIZER_MODE=RULE”
……
}
Pues no se pudo, al final no, preferí hacer esto porque no quise entrar en obtener estadísticas de estas tablas, ya que hasta ese momento no sabía a que otras cosas afectaba el tocar estas tablas. Al final consulté todas las vistas (v$fixed_view_defintion) V$ que utilizan estas X$ y era SOLO esa, así que bien, ¿Cómo se hace para no usar el CBO sino RBO? Si las tablas no tienen estadísticas no le queda otra que usar RBO, así que decidí borrar las estadísticas de esas tablas con lo siguiente:
exec dbms_stats.delete_table_stats(ownname=>'SYS',tabname => 'X$KSFQP' );
exec dbms_stats.delete_table_stats(ownname=>'SYS',tabname => 'X$KCCRSR' );
exec dbms_stats.delete_table_stats(ownname=>'SYS',tabname => 'X$KRBMRST');
Y todavía no servía, sin que sirva de precedente, estas alguna de estas tablas hace referencia al control file, pero recrearlo era mi última opción. Siguiente:
exec dbms_stats.gather_table_stats(ownname=>'SYS',tabname => 'X$KSFQP' );
exec dbms_stats.gather_table_stats(ownname=>'SYS',tabname => 'X$KCCRSR' );
exec dbms_stats.gather_table_stats(ownname=>'SYS',tabname => 'X$KRBMRST');
Y efectivamente mi consulta sin el HINT tardó milésimas de segundo, BIEN!!!. Esto es una forma rápida, para solucionar el problema, realmente, lo que debí hacer es verificar donde se estaba quedando la consulta verificar que tienen estas X$ y lanzar las estadísticas de una forma conciente y correcta, ¿Por qué? Hay un buen documento de Jonathan Lewis que explica bastante bien la cantidad de estadísticas necesarias. Además de este documento, debemos saber que el valor del parámetro de DBMS_STAT en el METHOD_OPT por defecto es “FOR ALL COLUMNS SIZE AUTO” y esto es “MONSTRUOSO” y sino que se lo pregunten a mi compi y amigo Ricardo, y él con documentación Oracle de metalink se los explica bien, o yo lo haré pero en otro post.
El caso es que en ese momento, decidí tirar por la vía rápida (mil disculpas Ricardo) pero funcionó, recolectó estadísticas de esas tablas y la consulta iba bien, por tanto el RMAN función y pudo realizarse el BACKUP de los ARCHIVE LOGs correctamente.
Al final las V$ que la mayoría son las GV$ sin la columna INST_ID, son consultas, así bien, algunos de los problemas que puedas tener viene provocados por la consulta a tablas X$, que estas pueden ser tablas ó estructuras en memoria. Por favor, NO RECOLETAR estadísticas por LEY, NO!!!, hay que pensar que pasa en la consulta, para este caso en concreto decidí hacerlo así prque me iba a quedar sin espacio en el filesystem donde están almacenados los ARCHIVE LOGs, pero si tiene que ver con V$ revisar mil veces antes, estas NO se pueden cambiar, por tanto hice lo rápido.
Más tormentoso, pero que también podría funcionar es lanzar:
exec dbms_stats.gather_dictionary_stats();
Y así recopilar las estadísticas de todo el diccionario, pero esto es muy peligroso, al igual que para nuestro caso pude también ejecutar:
exec dbms_stats.delete_dictionary_stats();
Que al final me iba a borrar estadísticas y mi consulta iba a hacer lo mismo que con el HINT RULE.
Pero como siempre intento decirle a todos DEPENDE, en este caso al mejor solución si deseas estabilidad es centrar todo en esa consulta, así bien son solo el “ALTER SESSION” hubiese estado genial, pero como no se pudo pues tocaron más cosas, pero en serio, si desean estabilidad y no desea errores inesperados, no lancen estadísticas sin saber que se hace por dentro.
Ah, puedes buscar en METALINK y aparece un par de entradas, pero le aseguro que después de solucionarlo, empecé a buscar en METALINK y tardé más en buscar que en ejecutar mis dos o tres consultas, además esto es más divertido que estar solucionando cosas con solo buscar y hacer lo que dice METALINK, por lo menos se aprende un poco más.
DBA_FREE_SPACE miente a veces
Buenas de nuevo, con un nuevo test sobre una funcionalidad de la Oracle 10g:
LA PAPELERA
Si deseas usar el FLASHBACK TABLE, debes tener habilitada la papelera para que en caso tal que borres la tabla puedas recuperar si la borraste. Pues bien, el caso es que, hace un rato me dicen que un índice no se puede crear porque no se puede extender un segmento temporal. El típico ORA-01652 ó ORA-01653 ó ora-01654.
Lo primero que piensas es en que se quedó sin espacio, y no, tenía 600M libres (según la DBA_FREE_SPACE), lo siguiente que te planteas, es que en el momento de crear un índice se crea un segmento temporal para realizar las ordenaciones necesarias para la creación del índice, y sea esta ejecutando una consulta gigante, y no eso no es lo que está pasando.
La tabla y el índice eran creados en el momento, y lo sorprendente es que solo eran 90.000 filas y la tabla tenía 12 campos, la mayoría VARCHAR2(10) y NUMBER. Por tanto, debería tener espacio suficiente para crear la tabla y el índice, de sobre, porque realmente eran unos 12M de tabla y unos 2M de índices. Entonces ¿Donde tenía el espacio ocupado que no estaba usando? Pues el error está en mirar ó confiar en la DBA_FREE_SPACE. La verdad es que se decidió no usar la papelera por tanto el parámetro RECYCLEBIN se colocó en OFF, pero en ese momento la persona encargada de la migración no vació la papelera antes ó después de desactivarla, y pasa que cuando está en OFF ó en ON la vista DBA_FREE_SPACE cuenta como libre ese espacio de segmentos borrados no “purgados”, pero Oracle no lo libera si lo necesita si está en OFF el parámetro. Así bien, cuando está en ON el mismo elimina el segmento de la papelera pero si está en OFF, no lo hace. Entonces compruebas que tienes segmentos en la papelera y ves que tienes, entonces primero antes de ampliar en borrar.
Es una tontería, porque piensas en segmentos temporales, tamaños, espacio libre y te haces mil preguntas, pero al final se puede probar, que con un INSERT en una tabla, que te dice que no puede extenderse un ORA-01653 y es que realmente no libera el espacio que te reporta como libre. Pero la verdad es que es bastante curioso (por lo menos para mi) ver como por un lado Oracle te dice que tienes espacio “libre”, pero la consulta no revisa que ese segmento no puede ser automáticamente borrado, y que la única forma de liberar este espacio, eres tu manualmente con el comando PURGE ó teniendo el parámetro RECYCLEBIN en ON. Que con puedes estar desperdiciando espacio.
Esto pasa en ocasiones cuando realizas migraciones a la versión 10g, y el cliente tiempo después, decide desactivar la papelera, y algunos desactivan la papelera en el acto, pero no se toman la molestia de limpiar la papelera.
LA PAPELERA
Si deseas usar el FLASHBACK TABLE, debes tener habilitada la papelera para que en caso tal que borres la tabla puedas recuperar si la borraste. Pues bien, el caso es que, hace un rato me dicen que un índice no se puede crear porque no se puede extender un segmento temporal. El típico ORA-01652 ó ORA-01653 ó ora-01654.
Lo primero que piensas es en que se quedó sin espacio, y no, tenía 600M libres (según la DBA_FREE_SPACE), lo siguiente que te planteas, es que en el momento de crear un índice se crea un segmento temporal para realizar las ordenaciones necesarias para la creación del índice, y sea esta ejecutando una consulta gigante, y no eso no es lo que está pasando.
La tabla y el índice eran creados en el momento, y lo sorprendente es que solo eran 90.000 filas y la tabla tenía 12 campos, la mayoría VARCHAR2(10) y NUMBER. Por tanto, debería tener espacio suficiente para crear la tabla y el índice, de sobre, porque realmente eran unos 12M de tabla y unos 2M de índices. Entonces ¿Donde tenía el espacio ocupado que no estaba usando? Pues el error está en mirar ó confiar en la DBA_FREE_SPACE. La verdad es que se decidió no usar la papelera por tanto el parámetro RECYCLEBIN se colocó en OFF, pero en ese momento la persona encargada de la migración no vació la papelera antes ó después de desactivarla, y pasa que cuando está en OFF ó en ON la vista DBA_FREE_SPACE cuenta como libre ese espacio de segmentos borrados no “purgados”, pero Oracle no lo libera si lo necesita si está en OFF el parámetro. Así bien, cuando está en ON el mismo elimina el segmento de la papelera pero si está en OFF, no lo hace. Entonces compruebas que tienes segmentos en la papelera y ves que tienes, entonces primero antes de ampliar en borrar.
Es una tontería, porque piensas en segmentos temporales, tamaños, espacio libre y te haces mil preguntas, pero al final se puede probar, que con un INSERT en una tabla, que te dice que no puede extenderse un ORA-01653 y es que realmente no libera el espacio que te reporta como libre. Pero la verdad es que es bastante curioso (por lo menos para mi) ver como por un lado Oracle te dice que tienes espacio “libre”, pero la consulta no revisa que ese segmento no puede ser automáticamente borrado, y que la única forma de liberar este espacio, eres tu manualmente con el comando PURGE ó teniendo el parámetro RECYCLEBIN en ON. Que con puedes estar desperdiciando espacio.
Esto pasa en ocasiones cuando realizas migraciones a la versión 10g, y el cliente tiempo después, decide desactivar la papelera, y algunos desactivan la papelera en el acto, pero no se toman la molestia de limpiar la papelera.
Te recomiendo que eches un vistazo a tu papelera por si estas usan espacio que al final Oracle nunca va poder reutilizar:
select count(8)
from dba_recyclebin;
show parameter recyclebin
Con estas dos pequeñas consultas revisas esto. Es algo tonto este post, pero al final resolver los problemas es lo fácil, lo dificil es saber y comprender lo que está haciendo Oracle, porque en ocasiones miente o no te dice toda la verdad.
Si alguien quiere las pruebas del delito que me escriba un correo y se lo envío con mucho gusto, La verdad no se como subir un fichero en este blog , jejejeje :).
martes, 17 de febrero de 2009
Oracle en Español...INCREMENTAL FROM SCN...Refrescando un standby
Entre los más de 400 millones de hispano parlantes, unos miles puede que sean DBA de Oracle, y en ocasiones algunos se sienten muy cómodos leyendo en ingles, pero otros no. Para todos aquellos que no se sienten cómodos leyendo en ingles y prefieren que las explicaciones se den en español, empiezo hoy a escribir en español documentos, pruebas, mejoras de rendimiento, etc.
Como le escribió Jonathan Lewis a un amigo mío en su libro "No porque esté escrito significa que sea cierto", y a lo que yo digo:”no porque lo escriba en este blog implique que sea verdad”, pero seguro que si que lo he probado, y además puede que no te solucione tu problema en el trabajo.
Empecemos con algo sencillo, del capitulo 13 "Using RMAN for Database Transport, Duplication and Migration" del libro "Backup and Recovery Advance User's guide"(B14191-02), en el que describen como realizar una actualización de la base de datos Standby desde un backup incremental.
Primero describamos la situación, tienes un GAP (muchos archivelogs sin estar aplicados) y han sido llevados a cinta y borrados del disco, para este caso pensemos que son un par de gigas que serían varios días sin recuperar, tardaría horas en traer a disco estos archivelogs y después aplicarlos depende de la maquina y tu configuración. Ahora en la 10g tienes BACKUP INCREMENTAL FROM SCN, que te crea un backupset que no se registra en tu repositorio de RMAN y que además es fácil de aplicar en tu standby. Situación:
- Standby con retraso de aplicación de 1 día.
- Tienes 4 días sin aplicar archivelogs.
- Has perdido los backup desde hace 4 diás hasta 2 días antes.
- Tus archivelogs se borran cada 12 horas después de copiarlos a cinta.
Sencillo, y cuando digo sencillo es porque lo es. No son solo los 4 pasos que salen en el manual, aunque tampoco mucho más y realmente estos son bastante importantes. Pero los pasos para hacer el proceso completo realmente son los siguientes:
Recuperas los números de los últimos cambios (SCNs) de los últimos archivelogs aplicados.
Con RMAN creas el backup incremental dependiendo basándote en el número de cambio (SCN) que deduces del punto 1.
Crear un controlfile para la standby con RMAN.
Copiar los ficheros en un directorio en la maquina donde está la standby ó en su defecto que se puedan ver por está maquina.
Catalogar los backupset generados.
Recuperar
Bajar y restaurar desde el nuevo standby controlfile
Y volver a montarla para iniciar la recuperación automática.
Y eso es todo, son 8 pasos, que a diferencia de los 4 que nos indica el manual sin importantes. Ahora bien lo bueno son las consultas y comandos, porque mucho hablar pero con poca idea esto no sale, y al final lo que siempre se quiere son los comandos, y yo he ejecutado los siguientes:
Desde la standby, en el sqlplus:
Select max(first_change#)
From v$log_history;
O también vale
Select max(first_change#)
From v$archived_log
Where applied ='YES';
Con esto sacas el último número de cambio (SCN) yo recomiendo hacer el backup desde el penúltimo aplicado. Después de esto apagas la recuperación automática, si no se ha hecho antes:
alter database recover managed standby database cancel;
Después de esto te conectas a la primaria con RMAN para hacer el backup incremental y crear el fichero de control para la standby.
backup incremental from scnformat ' ruta y nombre y%U';
backup current controlfile for standby format 'ruta y nombre';
Dependiendo de tu configuración el va a crear más o menos ficheros, por razones como que tienes un AUTOBACKUP CONTROLFILE, por ejemplo.
Copias los ficheros a un directorio en la maquina de la standby, ya sea scp ó ftp, esto es a gusto del consumidor.
Después en la maquina donde está la standby te conectas a RMAN, y catalogas los nuevos backusets que acabas de traer de la maquina donde está la primaria:
catalog start with 'ruta donde tienes los backupsets'
Después de esto tienes que hacer la recuperación, con un sencillo:
recover database noredo;
Después de esto, que es lo ultimo que sale en el manual, y falta un paso importante, hay que poner a que sea una standby, y lo haces con el fichero de control que acabas de generar con RMAN desde la primaria. Y se debe hacer esto desde RMAN, por lo menos el "restore" del standby controlfile
shutdown
startup nomount
restore standby controlfile from 'ruta y nombre';
shutdown
startup mount
Y por ultimo volver a que se realice la recuperación automática con:
alter database recover managed standby database disconnect from session;
Para algunos que hacen recuperaciones nocturnas, y que levantan su standby por la noche para aplicar sus archivelogs, les vale hasta la bajada de la base de datos después de la recuperación de su standby controlfile, porque el script que realice la carga haría justo lo siguiente iniciar y montar.
Cuando solo haces los 4 del manual, el fichero de control de la standby queda con la última secuencia aplicada, pero las cabeceras de los datafiles con los SCNs de actuliazadas a los backupstes aplicados. Cuando restauras el fichero de control a partir del controlfile standby creado con RMAN en la primaria, quedan sincronizados, y aquí tengo que hacer un mención especial, cuando haces una recuperación hasta una fecha determinada y después restauras el fichero de control hasta una fecha determinada, el debería saber que además de ser un fichero de standby la base de datos, justo en el momento de activar la recuperación automática como no tiene realmente aplicado los arhicvelogs los debe aplicar. Si alguno se encuentra con que esto no pasa, por favor enviarme el error, pero no debería pasar, sino que simplemente empiece a recuperar desde la última secuencia con respecto a la recuperación con NOREDO realizada.
Espero que les sirva, y que si tiene algún problemilla me lo puedan comentar, así aprendemos todos.
Como les digo voy a ir escribiendo cosillas que me encuentro y que hago en el trabajo que están en ingles, y que se que es más fácil para muchos leer en español que en ingles, teniendo en cuenta no solo explicar sino también los comandos, y el porque de las cosas. Pero no es de un nivel extremadamente alto este blog, solo son pequeñas soluciones, detalles ó momentos que buscas y mejor leerlo en español.
Si alguno tiene un problema no dude en consultarme, yo no soy un mega expertos de Oracle, pero si que soy muy curioso :) . Sería bueno que al igual que Tom Kyte poder leer en español preguntas y respuestas que pueda publicar, con todo el respeto que se merece este “evangelista” mega-gurú de Oracle. Tienen mi correo así que estoy a la entera disposición siempre que lo sepa, tengo tiempo a responder.
John Ospino Rivas
Como le escribió Jonathan Lewis a un amigo mío en su libro "No porque esté escrito significa que sea cierto", y a lo que yo digo:”no porque lo escriba en este blog implique que sea verdad”, pero seguro que si que lo he probado, y además puede que no te solucione tu problema en el trabajo.
Empecemos con algo sencillo, del capitulo 13 "Using RMAN for Database Transport, Duplication and Migration" del libro "Backup and Recovery Advance User's guide"(B14191-02), en el que describen como realizar una actualización de la base de datos Standby desde un backup incremental.
Primero describamos la situación, tienes un GAP (muchos archivelogs sin estar aplicados) y han sido llevados a cinta y borrados del disco, para este caso pensemos que son un par de gigas que serían varios días sin recuperar, tardaría horas en traer a disco estos archivelogs y después aplicarlos depende de la maquina y tu configuración. Ahora en la 10g tienes BACKUP INCREMENTAL FROM SCN, que te crea un backupset que no se registra en tu repositorio de RMAN y que además es fácil de aplicar en tu standby. Situación:
- Standby con retraso de aplicación de 1 día.
- Tienes 4 días sin aplicar archivelogs.
- Has perdido los backup desde hace 4 diás hasta 2 días antes.
- Tus archivelogs se borran cada 12 horas después de copiarlos a cinta.
Sencillo, y cuando digo sencillo es porque lo es. No son solo los 4 pasos que salen en el manual, aunque tampoco mucho más y realmente estos son bastante importantes. Pero los pasos para hacer el proceso completo realmente son los siguientes:
Recuperas los números de los últimos cambios (SCNs) de los últimos archivelogs aplicados.
Con RMAN creas el backup incremental dependiendo basándote en el número de cambio (SCN) que deduces del punto 1.
Crear un controlfile para la standby con RMAN.
Copiar los ficheros en un directorio en la maquina donde está la standby ó en su defecto que se puedan ver por está maquina.
Catalogar los backupset generados.
Recuperar
Bajar y restaurar desde el nuevo standby controlfile
Y volver a montarla para iniciar la recuperación automática.
Y eso es todo, son 8 pasos, que a diferencia de los 4 que nos indica el manual sin importantes. Ahora bien lo bueno son las consultas y comandos, porque mucho hablar pero con poca idea esto no sale, y al final lo que siempre se quiere son los comandos, y yo he ejecutado los siguientes:
Desde la standby, en el sqlplus:
Select max(first_change#)
From v$log_history;
O también vale
Select max(first_change#)
From v$archived_log
Where applied ='YES';
Con esto sacas el último número de cambio (SCN) yo recomiendo hacer el backup desde el penúltimo aplicado. Después de esto apagas la recuperación automática, si no se ha hecho antes:
alter database recover managed standby database cancel;
Después de esto te conectas a la primaria con RMAN para hacer el backup incremental y crear el fichero de control para la standby.
backup incremental from scn
backup current controlfile for standby format 'ruta y nombre
Dependiendo de tu configuración el va a crear más o menos ficheros, por razones como que tienes un AUTOBACKUP CONTROLFILE, por ejemplo.
Copias los ficheros a un directorio en la maquina de la standby, ya sea scp ó ftp, esto es a gusto del consumidor.
Después en la maquina donde está la standby te conectas a RMAN, y catalogas los nuevos backusets que acabas de traer de la maquina donde está la primaria:
catalog start with 'ruta donde tienes los backupsets
Después de esto tienes que hacer la recuperación, con un sencillo:
recover database noredo;
Después de esto, que es lo ultimo que sale en el manual, y falta un paso importante, hay que poner a que sea una standby, y lo haces con el fichero de control que acabas de generar con RMAN desde la primaria. Y se debe hacer esto desde RMAN, por lo menos el "restore" del standby controlfile
shutdown
startup nomount
restore standby controlfile from '
shutdown
startup mount
Y por ultimo volver a que se realice la recuperación automática con:
alter database recover managed standby database disconnect from session;
Para algunos que hacen recuperaciones nocturnas, y que levantan su standby por la noche para aplicar sus archivelogs, les vale hasta la bajada de la base de datos después de la recuperación de su standby controlfile, porque el script que realice la carga haría justo lo siguiente iniciar y montar.
Cuando solo haces los 4 del manual, el fichero de control de la standby queda con la última secuencia aplicada, pero las cabeceras de los datafiles con los SCNs de actuliazadas a los backupstes aplicados. Cuando restauras el fichero de control a partir del controlfile standby creado con RMAN en la primaria, quedan sincronizados, y aquí tengo que hacer un mención especial, cuando haces una recuperación hasta una fecha determinada y después restauras el fichero de control hasta una fecha determinada, el debería saber que además de ser un fichero de standby la base de datos, justo en el momento de activar la recuperación automática como no tiene realmente aplicado los arhicvelogs los debe aplicar. Si alguno se encuentra con que esto no pasa, por favor enviarme el error, pero no debería pasar, sino que simplemente empiece a recuperar desde la última secuencia con respecto a la recuperación con NOREDO realizada.
Espero que les sirva, y que si tiene algún problemilla me lo puedan comentar, así aprendemos todos.
Como les digo voy a ir escribiendo cosillas que me encuentro y que hago en el trabajo que están en ingles, y que se que es más fácil para muchos leer en español que en ingles, teniendo en cuenta no solo explicar sino también los comandos, y el porque de las cosas. Pero no es de un nivel extremadamente alto este blog, solo son pequeñas soluciones, detalles ó momentos que buscas y mejor leerlo en español.
Si alguno tiene un problema no dude en consultarme, yo no soy un mega expertos de Oracle, pero si que soy muy curioso :) . Sería bueno que al igual que Tom Kyte poder leer en español preguntas y respuestas que pueda publicar, con todo el respeto que se merece este “evangelista” mega-gurú de Oracle. Tienen mi correo así que estoy a la entera disposición siempre que lo sepa, tengo tiempo a responder.
John Ospino Rivas
viernes, 30 de enero de 2009
Starting with Blogs
Hello, Hi, Hola, Hallo all...
Today is my first day writing in this blog, my blog. This blog is particular, why? Because I love Oracle databases, dance, snowboard, travel, philosophy, politics and human behaviour. So I can write about anything, with or without reason, but you must sure with a lot of information.
About Oracle, that's the most important subject of this blog. I'll show to everyone, just cases, in some case the solution but sometimes not, and that's the point, everybody can help me to solve my problems or my doubts, and I think that going to help everbody.
I'm going to introduce myself, I'm a Oracle student, and I'm not going describe myself like a DBA, this is a big word, people want to use but is not my case. I'm just a student or researcher. I've been working with Oracle databases since 1998, and I'm still working trying solving Oracle problems. Last two yeras a lot of migrations about 200.
I hope my problems can help you, and if you have any problem can consult me, but I recomend read more from Jonathan Lewis, Tanel Poder and Julian Dyke.
Today is my first day writing in this blog, my blog. This blog is particular, why? Because I love Oracle databases, dance, snowboard, travel, philosophy, politics and human behaviour. So I can write about anything, with or without reason, but you must sure with a lot of information.
About Oracle, that's the most important subject of this blog. I'll show to everyone, just cases, in some case the solution but sometimes not, and that's the point, everybody can help me to solve my problems or my doubts, and I think that going to help everbody.
I'm going to introduce myself, I'm a Oracle student, and I'm not going describe myself like a DBA, this is a big word, people want to use but is not my case. I'm just a student or researcher. I've been working with Oracle databases since 1998, and I'm still working trying solving Oracle problems. Last two yeras a lot of migrations about 200.
I hope my problems can help you, and if you have any problem can consult me, but I recomend read more from Jonathan Lewis, Tanel Poder and Julian Dyke.
Suscribirse a:
Entradas (Atom)