Diario de SQL Server

Todavía no ha fallado

Escrito por qwalgrande 27-03-2010 en General. Comentarios (1)

Desde que trabajo en mi actual compañía, cada Viernes Santo tenemos un susto, de mayor o menor importancia, pero suficiente como para obligarme a acudir a apagar el fuego allá donde me coja, e impidiéndome conseguir algo tan incompatible con el 24x7 como es desconectar por unos días. No pretendo hablar hoy de la disponibilidad de DBA, sino de los sustos.

 

No sé si ya lo he comentado anteriormente en este blog, en cualquier caso, un DBA debe ser, por definición, pesimista, y no me estoy refiriendo al nivel de aislamiento. Ese ponerse en lo peor  depende bastante de lo paranoico que uno pueda llegar a ser y va más allá de la Ley de Murphy.

 

El enfoque sería que el "sistema" (sustitúyase por lo que se desee) todavía no ha fallado. ¿Qué quiero indicar con ese "todavía"? Justamente eso, que todo se rompe, tarde o temprano, sólo es cuestión de tiempo. Si sabes que algo va a ocurrir, prepárate para arreglarlo. Es más, entrénate para cuando llegue ese momento. Este tipo de situaciones suelen tener nombres catastrofistas, como "Disaster Recovery Plan" o peores, como "Línea sucesoria". Cuando se diseñan esos planes, con un humor negro, se dicen frases como "Si el edificio se viene a abajo..." a lo que uno responde "Si eso ocurre, ¿me pilla dentro? Porque si es ese el caso, como que me da un poco igual si el failover es automático o hay que relanzar un job.". Jiji, jaja, pero eso tambien pasa. Hace pocas fechas pasó en Chile, no por no hablar de Haití.

 

Ese tipo de contingencias no son frecuentes, y hay que prevenir también en función del riesgo. Por ejemplo, en Madrid, muchos terremotos no suele haber. Ahora, obras... Si has visto alguna vez una zanja en Madrid, podrás ver lo cerca que se trabaja de los cables de la luz (y de los del gas!) con el martillo neumático. La fibra óptica no pasa lejos. Que se desvíen tres centímetros y te dejen a oscuras, vamos, poco pasa.

 

Si ocurren estas contingencias, como dice Queen, "The show must go on", con uno o con los que queden. Por responsabilidad, hay que tener el plan escrito como si no fuera un entendido el que lo vaya a ejecutar y ha de estar distribuido en suficientes sitios. Esos documentos que tienen lo necesario para levantar, tenlos siempre encima (por ejemplo, un llavero pendrive) y no seas el único que los tenga.

 

Cuando este próximo viernes me llegue la alerta, que llegará, espero estar preparado. Lo que no será es una sorpresa.

Consultas con where variable o cómo hacer un procedimiento eficaz para buscadores

Escrito por qwalgrande 23-03-2010 en General. Comentarios (4)

Puede que 2 no sea un número muy elevado como para entenderlo como FAQ, pero han sido muy seguidas, así que lo daremos como tal.

 

Es frecuente la necesidad de construir procedimientos almacenados para buscadores en los que no todos los parámetros son obligatorios. Si el parámetro se indica, hay que filtrar por él, pero si no, no hay que filtrar.

 

Supongamos que es un buscador de pocos parámetros, 2 ó 3. En ese caso, mi recomendación sería crear un procedimiento almacenado a medida para cada una de las posibles combinaciones, donde no haya parámetros opcionales, todos los que vengan se usan. Y desde el código se llamará a un procedimiento almacenado o a otro en función de la combinación de parámetros con la que se cuente.

 

Si tenemos más, ya no es práctico tener un procedimiento para cada caso. Lo que sí es práctico y muy eficaz para el rendimiento es identificar el uso o los dos usos más típicos del buscador y para esos preparar procedimientos a medida. Luego, para el resto de los casos hay que hacer ya el buscador genérico.

 

Para este buscador genérico, una de las alternativas es montar la consulta con sql dinámico. Si se puede, habría que hacer la llamada a través de sp_executesql. Y sobre esta, poco hay que decir.

 

Luego hay una alternativa, cuando se pretende que la consulta no sea creada con sql dinámico, y es implementar un case o un filtro con estas características:

 

where CampoFiltro = isnull(@pCampoFiltro, CampoFiltro)

 

Si el parámetro tiene características de rango (por mencionar uno típico, un rango de fechas) la forma de filtrar (o no) sería dar unos valores por defecto que no filtren porque contemplan el rango completo. Tampoco hace falta que el rango sea enorme, sólo lo suficiente como para no filtrar:

 

where Fecha between isnull(@FechaInicio, '20000101') and isnull (@FechaFin, '21000101')

 

Con esto tendremos gran parte cubierta. Quedaría sólo paginar los resultados de la búsqueda. Pero eso es otra historia, para otro día.

 

More of this is true than you would believe.

Escrito por qwalgrande 21-03-2010 en General. Comentarios (0)

Hace poco vi una película llamada "Los hombres que miraban fíjamente a las cabras". Sin ser este un blog de cine, decir que la película es entretenida, graciosa y rara, mu rara. Al principio, en lugar del típico "Basado en hechos reales" o "Cualquier parecido con la realidad es mera coincidencia", se puede leer sobreimpresionado "Hay mucho más de cierto en esto de lo que pudieras llegar a creer". Me llamó la atención y aquí lo empleo para enlazarlo con lo que quiero hoy exponer.

 

Con mucha más frecuencia de la que cabría pensar, las organizaciones tienen al frente de la administración de los servidores de SQL Server a personas que no son especialistas en la materia, que además suelen estar demasiado desbordados como para poder iniciarse.

 

Se podrían catalogar en dos grupos, administradores de sistemas y desarrolladores de aplicaciones. En ambos casos, ven la administración de SQL Server un mochuelo que les ha caído  y que, por lo general, aborrecen, algo totalmente comprensible.

Si tú eres uno de esos de sistemas, habrás llegado a este blog intentando encontrar la solución a un problema concreto, seguramente algo básico, pero me pongo en tu situación, es como si yo tuviera que resolver un problema, no sé, de Exchange por ejemplo. Así que ánimo y suerte. Si aquí no encuentras lo que buscas, te sugiero que hagas la pregunta en el foro, seguramente podamos ayudarte. Sé paciente y asume este rol de DBA como un universo por descubrir. Poco a poco podrás ir sientiéndote más cómodo con estas tareas que te han tocado en suerte.

 

Si tú eres uno de los de desarrollo, quizá lo tengas más asequible, porque aunque desde otro punto de vista, estás habituado a pegarte con SQL Server, pero puede que te falte la base que un profesional de la administración de sistemas sí tiene, y que se puede resumir en una frase: Haz backups. Si no tienes un backup realizado con cierta frecuencia (y verificado, que si no restauras el backup, no tienes backup), deja de leer, vé a realizar unas copias de seguridad y ya sigues luego.

 

SQL Server es tan amplio que requiere de especialistas, como exchange, la seguridad, el desarrollo de aplicaciones, etc. Es normal estar abrumado ante terrenos resbalosos. Pero nadie nace sabiendo y con el tiempo, como con todo, se adquiere soltura. Vete a saber, lo mismo hasta te gusta y de mayor abandonas esos temas mundanos de los que ahora te ocupas y te haces DBA...

 

Moderadamente inmoderado

Escrito por qwalgrande 13-03-2010 en General. Comentarios (0)

Hace un par de semanas me ofrecieron ser moderador del foro de SQL Server. Sin dudarlo, acepté la responsabilidad. El martes me lo comunicaron. Desde este blog quiero aprovechar para agradecer públicamente a Átilla Arruda Pereira (de Technet) y a Gustavo Larriera (MVP) esta oportunidad.

 

El reconocimiento hace ilusión y la nueva forma de ver el foro también. A ver qué tal lo hago. Como dice Manolo García en "Si te vienes conmigo", moderadamente inmoderados, o inmoderadamente moderados. Bueno, más bien, lo haré a imitación de como he visto que lo hacen los más veteranos en estas lides.

 

En esa línea, intentaré incluir algún que otro post tipo FAQ, estoy seguro de que serán de utilidad, porque las hay que se repiten con cierta frecuencia. Crearé un tema llamado FAQs para así poder categorizarlos adecuadamente.

 

La sabiduría de A.L.

Escrito por qwalgrande 08-03-2010 en General. Comentarios (0)

Estas últimas semanas he estado haciendo un par de procesos de selección para incorporar gente de inteligencia de negocio. Si estás pensando en qué especializar tu carrera profesional, he aquí un campo en el que hay oportunidades y no muchos candidatos. Aprende ETL, aprende de cubos OLAP y aprende MDX. Créeme, hacen falta y hay pocos. Por leyes de oferta y demanda...

 

Sin embargo, de lo que quería hablar hoy es de una pregunta que hacía en las entrevistas: Para ti, ¿qué es lo más importante en un proyecto de data warehouse? ¿Y lo que más coste en tiempo lleva?

 

Hay una frase de Abraham Lincoln que siempre me ha gustado. Dice así:

 

"Si tuviera ocho horas para talar un árbol, dedicaría seis a afilar el hacha."

 

Habla de lo importante que es analizar bien un problema antes de iniciar su ejecución. Y para un proyecto de data warehouse también es cierto. Eso fue lo que respondió la mayor parte de los candidatos (de los que respondieron, que no fueron tantos): analizar, un buen diseño, eso es lo más importante y lo que  más tiempo lleva.

 

Es cierto, es importante y lleva tiempo. Pero a mí otro ilustre, Alejandro Leguizamo, me enseñó que lo más importante es el negocio, hablar con la gente del negocio y con todos los afectados (no sólo con el que manda), verlo desde todas las aristas, que para eso haremos cubos. Conociendo el negocio conocerás, todas las casuísticas y podrás hacer un diseño adecuado.

 

En cuanto a lo que más tiempo lleva, quizá depende de la pericia de cada uno, pero para mí y con distancia de lo segundo, es el ETL para cargar el data warehouse. Y ojo, porque este detalle es importante, si eres el que "vende" estos servicios, si eres el que los "compra" o si, simplemente, debes ser tú quien los implemente y no quieres pillarte los dedos. No cometas nunca el error de dar como gratis la carga de data warehouse, porque será la parte más costosa del proyecto. Eso también me lo enseño Alejandro en un Summit.

 

En fin, que Abraham Lincoln, en esta ocasión, se ve superado por Alejandro Leguizamo.