Upgradeando a DBA 2.0

Hace unos dias vi en los blogs de oracle.com, concretamente en el apartado de certificaciones han publicado un documento acerca de los “skills” de un DBA de hoy en dia, lo llaman DBA 2.0.

Lo escribe dos instructores principales de Oracle University, Joel Goodman de UK y Harald Van Breederode de Holanda. Al señor Goodman no le he conocido en persona pero atraves de la profesora de OU cuando hice el examen de OCM. Ella me comentó un tiempo despúes del examen que Joel estuvo a ratos revisando el examen en los dos dias que estuve.

El documento es bastante interesante, lo sugiero a todo el mundo tanto nuevos como no. Explica las nuevas tecnologias introducidas desde la versión 9i y muchas responsabilidades que no eran de DBA ahora caen sobre los DBAs. Unos ejemplos muy claros son como temas relacionadas con Oracle Application Server, conocimientos de Cluster cuando trabajas con un RAC, E-Business Suite, conocimiento de Storage (SAN, NAS) etc.

El link Upgrading DBA 1.0 to DBA 2.0

Aprovechando este post sugiero a todos que quieran ser DBA que aprendan SQL. He estado en bastantes clientes y he visto bastantes “DBAs” de producción no son capaces de escribir un SQL decente (ya ni hablamos de que leerlos). Les veía y el esfuerzo que ponían para escribir unas simples consultas contra el diccionario de datos sin usar una herramienta grafica era enorme. At the end of the day (como dicen los ingleses, al fin al cabo) estamos trabajando con una BBDD, si no podemos comunicar con ella mejor dedicamos a otra cosa

Sentir la presion

Ultimamente me toca hacer de bombero, llevo 4 en estas ultimas semanas de situaciones de crisis todo por temas de performance. Estoy acostumbrado pero hoy creo que desayuné mal.

Fui a un cliente con urgencia porque se hizo un upgrade de 9i a 10g hace un par de semanas y todo dejó de funcionar literalmente.

Es un servidor con 16 CPU y 64GB de memoria sirviendo a 2500 usuarios concurrentes, con sistema operativo Linux x86-64 y Oracle 10.2.0.4. Llego al cliente y lo que me enseñaron primero es el Grid Control de la base de datos, madre mia el numero de sesiones activas marcaba hasta 80!!! Ahi me entro algun dolor de estomago porque tenia a 4 tios atras observando a ver si sacaba alguna varita magica. Empiezo a revisar datos de dias anteriores y madre mia otra vez, habia tope de 160 sesiones activas!!!

Me meto en la maquina y en el mismo empiezo a lanzar mi query favorita para ver la actividad, constantemente salian 80 sesiones activas con esperas de db file sequential read y direct path read. vmstat mostraba memoria libre y CPU libre, empece a sentirme un poco indispuesto, es raro no era la primera vez que tuviese a 4 ó 5 atras mirando pero la verdad es que la cosa no pintaba bien.

Llegó la hora punta y lanzo la query de la sesiones activas y boom, 150 sesiones activas que no me cabian en la pantalla, habia unas 2300 sesiones de usuarios. Viendo esos 150 sesiones me senti muy mal asi que tuve que irme al baño a quitarme un poco la presion y refrescarme la cara. Vuelvo y veo unos colorines muy guapos en el grafico de Grid, marron oscuro, rojo oscuro que son categorias configuration y concurrency. Logico, con tantas sesiones activas alguna contencion tiene que haber. Lo raro es que el servidor respondía bien, tenia CPU y memoria de sobra. Bueno CPU tenia como 20% libres tampoco para tirar cohetes.

Llegó la hora de comida empiezo a hacer cambios, unos 5 cambios introduje, tanto configuracion de sistema operativo como parametrizacion de la instancia. Suerte que eso solucionó el problema.

Pero el proposito de este post no es como se solucinó, es como aguantar la presión. Mantener la cabeza fria (con agua fria), no temblar, no decir tonterias (he visto a algunos decir tonterias en el pasado) porque puede volver en tu contra, analizar, comparar datos actuales con historicos y finalmente no ponerse nervioso.