Diario de SQL Server

dba

Un largo domingo de intervención

Escrito por qwalgrande 11-10-2009 en General. Comentarios (0)

La disponibilidad que se le requiere a un DBA se pone de manifiesto muchas veces cuando todos duermen. Hay que mirar por el negocio y eso significa que no se corta nunca, 24x7, 365 día al año... Bueno. No tanto. De esos 365 días, unos pocos los tenemos que dedicar a intervenciones.

 

Aunque a mí me parece que los martes a la vuelta del desayuno es un momento muy propicio para hacer un failover, lo cierto es que no lo es. Los cortes los tenemos que hacer los domingos a la hora del fútbol, que es cuando menos tráfico hay en la web (o cualquier otra métrica que nos incomode). Que a uno le guste el fútbol y desconectar (algo) los domingos es secundario. Tampoco han de ser tantos los cortes a lo largo del año... ¿O sí?

 

Hace ya un tiempo que el sistema de parches de Microsoft es suficientemente confiable como para que no esperemos a que salga un service pack (y lo prueben unos pocos pioneros) para que nos lancemos a instalarlo. Para el sistema operativo, tenemos Windows Update, para SQL Server lo que a mí me parece una gran idea, los Cumulative Update Package, algo que nos permite acercarnos a un punto en el que los parches se apliquen de forma cíclica, según las necesidades de nuestro negocio, sin que ello guarde relación con la publicación de este o aquel parche. Se van liberando, son acumulativos y llegan cada poco tiempo. El service pack siguiente recoge todo lo ya instalado, así que también se reduce el salto entre un service pack y el siguiente. Sólo hay que ir a por el último (que además es de descarga pública) e instalarlo, previo paso por los entornos de desarrollo y test. ¿Que cuál es el último? Lo que ponga en la página de TechNet, para SQL Server 2005 ó 2008:

 

http://technet.microsoft.com/en-us/sqlserver/bb895929.aspx.

 

Sí, añadela a tus favoritos...

 

Otra gran mejora para las intervenciones de los domingos es la posibilidad de preparar instalaciones unificadas que junten un service pack con el último parche acumulativo, incluso con la instalación del servidor. Aquí lo explican:

 

http://blogs.msdn.com/petersad/archive/2009/04/16/create-a-merged-slipstream-drop-containing-sql-server-2008-server-pack-1-and-a-cumulative-update-cu-based-on-server-pack-1.aspx

 

En resumidas cuentas, si tienes SQL Server 2008 RTM con CU2, puedes saltar a lo último de lo último de un solo viaje. Eso tiene una gran ventaja, te ahorras los reinicios intermedios. Se podría pensar que uno más o uno menos... Si alguna vez has trabajado con un servidor que se toma 20 minutos en reiniciarse, y más si estamos hablando de un cluster de 3 nodos (20x3 = OTRA HORA MÁS de intervención), entenderás que un reinicio menos sí que importa.

 

Y ya que ha salido el tema de clustering a colación, ¡¡por fin en posible actualizar en el nodo pasivo!! Véase:

 

http://support.microsoft.com/?scid=kb;en-us;958734&x=10&y=9

 

Así que a lo mejor lo de poner los parches el martes después del desayuno puede que no esté tan lejano. Vale, sí, está muy lejano porque no nos fiamos un pelo, porque ya son muchos tiros "pegaos" y si Murphy (el de la ley) hubiera sido DBA, hubiera sido el más optimista del gremio. En cualquier caso es un gran salto poder poner los parches en un nodo que no soporta la producción y poder así dejar cada nodo listo para que cuando el otro se caiga, si se cae, vayamos a un nodo ya actualizado. Con este método, instalar un parche de SQL Server son "lo que tarde el failover", cuando con SQL Server 2005, la media horita de corte de servicio no nos la quita nadie.

 

Por suerte, hoy no es uno de esos largos domingos de intervención. Es bueno saber que la tecnología va en una dirección en la que cada vez serán menos domingos y menos largos.

 

El Rey del Mambo

Escrito por qwalgrande 09-10-2009 en General. Comentarios (0)

Cuento entre mis amigos a un DBA que en su monitor tenía una etiqueta que ponía "O Rey Do Mambo". Y aunque quizá era algo pretencioso porque en el fondo gobernamos más bien poco, sí que es cierto que ser administrador de los servidores de bases de datos nos dota de una serie de privilegios que son ciertamente peculiares dentro de una organización.

 

Como dice Spiderman, "Un gran poder conlleva una gran responsabilidad". En nuestro caso, con una llave que, de un modo u otro, abre muchas puertas (si no todas) y que se llama rol de servidor "sysadmin", debemos sobrellevar una carga pesada. Así que habrá que preguntarse no sólo si soy capaz sino también si estoy dispuesto a ello.

 

La primera de las pruebas de la parte de "soy capaz" quizá sea la confianza. Debemos ser dignos de que nos den esa llave y eso requiere que el jefe se fie de uno, pero no sólo eso, además de ganársela hay que permanecer en ella. Por otra parte es algo intangible, que se tiene o no se tiene y que no es medible. No estoy seguro de si es bueno o malo, porque si fuera un contador de rendimiento, haríamos una línea base, nos marcaríamos un objetivo, podríamos evaluarla con datos... Pero no, no funciona así. Retomaré este tema, porque es capital.

 

Asimismo, la primera de las pruebas de la parte de "estoy dispuesto", o al menos una de ellas, es la disponibilidad. HA, high availability. Montamos clústeres, replicaciones, diseñamos un DRP, configuramos alertas de todos los colores y un largo etc. Por muchos automatismos que implementemos, el teléfono sonará (puede que sea una de esas alertas que nos manda un sms a las cuatro de la mañana) y habrá que coger el teléfono, posiblemente conectarse a ver qué pasa, puede que hasta haya que ir a la oficina o llamar a otra persona para que lo haga. Los hay que pueden turnarse, esa suerte tienen.

 

En el próximo post, habrá alguna query, que no va a ser todo filosofar.

Soy DBA

Escrito por qwalgrande 08-10-2009 en General. Comentarios (2)

Como pone ahí a la derecha, mi nombre es Alberto López Grande. DBA de SQL Server. Desde hace tiempo participo activamente en el grupo de noticias de SQL Server de Microsoft (technet y msdn), donde firmo como "qwalgrande", y si necesitáis ayuda técnica, intentaré ayudaros desde ahí.

 

Inicio este diario de SQL Server con la finalidad principal de recoger mis opiniones, mi punto de vista sobre mi trabajo-hobby, algo que en muchas ocasiones escapa de un hilo en un foro. Por supuesto, en la medida de lo posible, dejaré registro de aquello que crea que puede resultar de utilidad para otros compañeros en esta lucha, en la que en tantas ocasiones uno siente la soledad como en pocos lugares dentro del mundo de las tecnologías de la información.

 

Y como primera opinión, y declaración de intenciones, el título de este primer post: Soy DBA. Creo que es algo que "se es", no algo "en lo que se trabaja". Volveré sobre esta idea un futuros post.