Categorías
Enlaces de interes
Donaciones

Todo el contenido es gratuito y en beneficio de la comunidad. Puedes reconocer el esfuerzo con una donación si lo deseas.

Patrocinadores
Inserte aquí su publicidad

A raíz de una pregunta surgida en el foro, aprovecho para hacer un breve post que recuerde esta funcionalidad, la posibilidad de capturar los registros de una operación DML para recuperarlos o tratarlos en general. La pregunta concreta en cuestión era cómo insertar un registro en una tabla a la que lo borras de otra:

http://social.msdn.microsoft.com/Forums/es-ES/be6b1c73-154b-41c4-9c35-d385d86e2083/como-hacer-para-que-antes-de-eliminar-un-registro-me-lo-inserte-en-otra-tabla?forum=sqlserveres

Habiendo varias alternativas, una es emplear la cláusula OUPUT. Tan fácil como esto:

CREATE TABLE dummy (Id int, campo varchar(10))
GO
CREATE TABLE Otra (Id int, campo varchar(10))
GO

INSERT dummy (Id, campo)
VALUES
(1, 'a'),
(2, 'b'),
(3, 'c'),
(4, 'd'),
(5, 'e')

GO

DELETE dummy
OUTPUT DELETED.* INTO Otra
WHERE Id = 3
GO

SELECT * FROM Otra
GO

Y ya está.

Me desayuno con un post de Brent Ozar en su blog. Este tío es una de las personalidades más afamadas del mundo SQL Server por algo. Le comentan que en una empresa, el DBA se marcha, ¿qué se le pregunta de cara al traspaso de conocimientos? Como la mejor definición de tonto es “aquél que cree saberlo todo”, le da por preguntarle al Imperio (sus más de 16.000 followers), a los que lanza esa misma pregunta: El DBA se marcha. ¿Qué le pregunto? Esta es la entrada:

http://www.brentozar.com/archive/2014/01/what-do-you-ask-the-leaving-dba/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+BrentOzar-SqlServerDba+%28Brent+Ozar+Unlimited%29

De esto saco dos enseñanzas. La primera, hete aquí una base de conocimiento excelente para saber por dónde empezar a preparar un plan de contingencia ante la contingencia de que uno de tus DBAs, o el principal, deje la empresa y tengas unos pocos días para extraer información de su cabecita. Estamos acostumbrados a tener planificado y hasta ensayado cada cosita que se rompe para arreglarla, ya que como sabemos, tarde o temprano, todo acaba fallando y hay que estar listos para recuperarlo. Pero si lo que “fallan” son las personas… Es una cuestión que hay que tener lista para cuando ocurra, porque ocurrirá. Esto mismo vale para un DBA que para cualquier otra persona de tu equipo.

La segunda, hay que hacer testamento. Trabajo en una compañía de seguros que cuenta con lo que se conoce como “Plan de continuidad del negocio”, una mezcla entre DRP, línea sucesoria y otras macabras lindezas. En este plan, además de registrar quién ha de tomar las decisiones en los momentos iniciales si aquellos que las toman ya no pueden hacerlo, se describe cómo volver a montar los sistemas de información partiendo de copias de seguridad y un documento. Ahora bien, esto es otra cosa. No se informa ahí de lo que muchas veces me encuentro que se guarda como lo único que les hace necesarios para una empresa, el know-how mal entendido (gran mentira, lo que nos hace valiosos, opino, es lo que podemos hacer, no lo que hicimos alguna vez). Aquello que se sabe y no se transmite ni se documenta, porque en realidad es como Data Mining, los datos están ahí, pero no saltan a la vista. En esta categoría entra desde saber que tal usuario es un pieza al que atar en corto porque te la ha jugado varias veces o quién sabe de aquel negociado, hasta en qué bar de la zona ponen los mejores pinchos.

Otra cosa es que, como testamento, éste se guarde hasta que el albacea deba darle lectura…

Comentaba anoche en twitter un artículo que me llamó la atención, no tanto por lo que decía, sino por una buena práctica que siempre me ha hecho mucha gracia.

Es algo que no discuto, un crecimiento automático del log de transacciones conlleva una degradación en el rendimiento. Lo que pasa es que si se impide crecer al log de transacciones, nos arriesgamos a que se llene y que tengamos que atender la incidencia (que ya será de una gravedad importante) a horas en las que a lo mejor no estamos en la mejor disposición de hacerlo, como puede ser a las cuatro de la mañana.

Se puede argumentar que una instancia adecuadamente administrada tendrá un sistema de alertas que avise con antelación. Mismo caso, te avisará en el momento más inoportuno. Se puede argumentar que eso no debería ocurrir nunca si se tiene adecuadamente dimensionado el fichero, y si se realizan los backups del log con la suficiente frecuencia (incluso con la frecuencia que el propio crecimiento requiera, algo que fácilmente se puede automatizar). Para empezar, “eso no debería ocurrir nunca” no es una frase que deba pronunciar un DBA, ya que tarde o temprano todo acaba fallando, y hay que tener un plan para recuperarse. Pero más allá de esa ley básica, eso no impide que se llene el log, ya que hay varias causas que impiden el reciclado del log, como algo tan simple y tan fuera de nuestro control como que una aplicación tenga un bug que deje una transacción sin finalizar.

A mí sólo se me ocurre una circunstancia y es esa, que el DBA que lo deja fijo no sea el que tenga que ocuparse de arreglarlo, por ejemplo porque la organización disponga de suficiente personal como para hacer turnos 24×7. Que se pierde rendimiento. Pues sí. Pero, ¿tanto rendimiento se pierde? Obviamente no, es algo que he medido muchas de veces para estar seguro, y que es preciso verificar en cualquier entorno, no hay que descartar que condiciones muy concretas puedan llevar a una penalización sustancial.

En cualquier caso, y para concluir, existen docenas de cosas en las que fijarse antes de que esa para mejorar el rendimiento de nuestros servidores, muchas de ellas no requieren de desvelos. Imagino que habrá montones de instalaciones en las que el log se ha dejado de tamaño fijo siguiendo la “recomendación”, pero que toleran el uso de cursores, los índices no tienen un mantenimiento adecuado o cualquier otra de esas 1000 cosas que nos entretienen a diario. Al menos yo prefiero no hilar tan fino en este aspecto.

Hoy, Dejan Sarka (@DejanSarka) ha completado su serie de 5 artículos sobre fraude y cómo SQL Server nos ayuda a combatirlo. Yo tengo un proyecto de lucha contra el fraude en curso, tema de seguros, cómo no. Pero aun así, es indispensable aunque no hayas trabajado en un proyecto de estas características. Dejo links a toda la serie.

http://sqlblog.com/blogs/dejan_sarka/archive/2013/10/15/fraud-detection-with-the-sql-server-suite-part-1.aspx

http://sqlblog.com/blogs/dejan_sarka/archive/2013/10/15/fraud-detection-with-the-sql-server-suite-part-2.aspx

http://sqlblog.com/blogs/dejan_sarka/archive/2013/10/15/fraud-detection-with-the-sql-server-suite-part-3.aspx

http://sqlblog.com/blogs/dejan_sarka/archive/2013/10/15/fraud-detection-with-the-sql-server-suite-part-4.aspx

http://sqlblog.com/blogs/dejan_sarka/archive/2013/10/15/fraud-detection-with-the-sql-server-suite-part-5.aspx

Además de DBA, también debo ocuparme de gestionar vacaciones, una de esas aborrecibles tareas que conlleva administrar algo bastante más complejo que el engine de Analysis Services. Pero bueno, aprendiendo de aquí y de allá (más por los tantos ejemplos de lo que no se debe hacer que se van recopilando que otra cosa), uno intenta hacerlo lo mejor posible, la mayor parte de las veces para no conseguirlo. De todos modos, lo mejor es que no hagan la encuesta aquellos que tienen esa alegría que es el tenerme de jefe. De ese modo, la estadística mejora considerablemente.

Justo ahora se acaba de reabrir en la liga de fútbol en España lo que se conoce como “mercado de invierno”. Es un periodo que es generalmente de mucho ruido y pocas nueces, y más en estas épocas de vacas flacas, pero permite apuntalar las plantillas con algún jugador secundario, o dar salida a otros que no han contado con muchos minutos durante la primera vuelta. En ocasiones, los grandes clubes tratan de dar un golpe de efecto realizando alguna incorporación de relumbrón. Y otras, equipos más modestos, pero bien gestionados y en clara trayectoria ascendente, aprovechan la coyuntura para dar un salto de calidad. Es una metáfora, pero de esas posibilidades, me gusta pensar que es esta última la que aplica.

Este año, excepcionalmente, en mi equipo tendremos dos de esos fichajes, empiezan la semana que viene. Las expectativas son altas, confío en que estén a la altura de una exigencia, un jefe que tiene su aquél y una empresa en la que, cómo en todos lados, cuecen habas. También confío en que sabremos acogerles para que den el máximo de su potencial, que aprendan y que sobre todo aprendamos de esas personas. Es curioso que por regla general el punto de vista ante un recién llegado sea el hecho de que hay que enseñarle a hacer todo aquello que vaya hacer, cuando debe ser lo contrario, esto es, que esa persona aporte al grupo su conocimiento, el enriquecimiento ha de ser mutuo. Así, tendremos unos días de presentaciones, de contar a qué se dedica cada uno, a quién preguntarle las cosas, de enseñarle cómo se usa la aplicación de gestión de horario y dónde está el bar. El resto espero que me lo enseñen a mí. Que transmitan la ilusión de un nuevo trabajo, unos nuevos retos, el empuje de querer demostrar que valen para esto.

Esta buena noticia viene bien también para el resto del equipo. Ellos lo ven así porque estamos algo sobrepasados y tendrán la ilusión de que el trabajo será el mismo y se repartirá (angelitos). En este caso me refiero a que mueves el árbol y haces que todos estemos con las orejas tiesas, atentos para hacerse valer, ser más productivos y eficientes. No quiero decir con esto que tenga que existir competencia, sino compenetración y compromiso, pero sin que nadie desentone ni se acomode.

Como continuamente les repito, hay una ingente cantidad de curro comparada con los brazos, no puedo permitirme el lujo de tener un recurso que no sea realmente bueno o que siéndolo, no dé su 100% (al menos). Tenemos que ser los más listos, los más ágiles, y que además tengamos margen para formarnos e ir por delante de manera que tengamos respuesta a las preguntas cuando estas surjan. Y sí, eso pasa por poner mucho de su parte, sacrificando tiempo de ocio, de descanso o de la familia para invertirlo en su carrera profesional, que siempre ha de ir en crecimiento, ya que no crecer es lo mismo que estancarse, que es lo mismo morir.

Con todo, lo más importante es que encajen a nivel personal. Lo técnico se presupone, se aprende o está en internet. El esfuerzo que pondrán se da por descontado. Pero si no se llevan bien dentro del equipo, si no nos entendemos, si no están a gusto con nosotros, será imposible. Digo yo que será así, para eso se hacen entrevistas y se piden referencias, y si bien tenemos ya alguna mala experiencia con eso en concreto, espero no haberme equivocado esta vez.