1. Simular corrupción en base de datos

    Hace unos días alguien preguntó en el foro de MSDN de SQL Server en español cómo podía simular un escenario de Disaster Recovery, más concretamente cómo corromper de forma intencionada una base de datos. Aunque en su momento le respondí con los pasos a seguir para hacerlo, me pareció suficientemente interesante como para hacer un post donde lo detallara más, así que empecemos. Como siempre con este tipo de cosas, lo primero es hacerlo sobre una instancia que no sea producción (parece obvio, pero nunca está de más advertirlo) y en una base de datos de nueva creación o sobre una que no nos importe trastear. Una vez sobre esa base de datos, crearemos una copia de la tabla Sales.SalesTerritory de AdventureWorks2012 que es la que hará de conejillo de india para nuestra prueba: USE AdventureWorks2012_copy GO SELECT * INTO . FROM AdventureWorks2012.. Después de comporobar que tenemos los datos...
  2. Nuevas herramientas gratuitas para SQL Server

    SQL Server Management Studio (AKA SSMS) es sin lugar a dudas la herramienta más utilizada si tienes que trabajar con SQL Server, principalmente con el motor relacional. Pero está claro que dista bastante de ser perfecta y en muchas ocasiones se echa de menos algunas funcionalidades, por lo que o bien nos compramos la licencia de algún producto que exista en el mercado (a mí me gustan especialmente los de RedGate) o empezamos a bucear por la red con nuestro buscador favorito algún add-in que cubra nuestras necesidades (que haberlos haylos, tal como hemos comentado con anterioridad por ejemplo aquí, aquí y aquí) Este comentario viene al caso porque es bueno estar al tanto de sitios que se dedican a publicar de vez en cuando listas de sus herramientas favoritas (como solemos hacer en Kabel) o saber que existen eventos como los organizados por SQLMag en los que se premian...
  3. ¿Qué hay de nuevo, viejo? (again)

    Carlos, nuestro experto de SQL Server escribe un artículo sobre las nuevas versiones del producto. Allá por mayo del año pasado escribía un artículo donde hacía referencia a la nueva versión de SQL Server (denominada 2012) y ya estoy de nuevo escribiendo otro sobre una inminente salida al mercado de otra versión, esta vez denominada 2014 (por cierto. Que yo recuerde, es la primera vez que tenemos el nombre final en vez de uno interno como ha ocurrido en las veces anteriores: Yukon para 2005, Katmai para 2008 o Denali para 2012) Por tanto es normal que surjan preguntas como que si merece la pena el cambio, o si es que SQL2012 no ha sido un producto aceptado en el mercado. Respecto a la respuesta a la segunda pregunta, influye mucho el contexto actual, donde la inversión en cualquier ámbito tiene que estar justificadísima y es difícil convencer de las...
  4. Las unidades mágicas de SQL Server

    Cuando analizamos el plan de ejecución de una instrucción, podemos ver en las propiedades del operador el coste estimado, tal como se ve en la siguiente imagen:   Sin embargo, ¿qué es lo que mide? ¿CPU? ¿IO? En realidad no puede ser ninguno de esos dos porque ya tenemos un apartado específico de coste de CPU e IO, así que quedan descartados. Por otro lado, si pensamos que es tiempo y lo comparamos con los resultados que arroja SET STATISTICS TIME ON, vemos que no concuerdan mucho. En realidad, hay un artículo del blog del equipo de SQL Server que se encarga del motor de ejecución que lo explica en el que viene a decir que esas unidades son de… nada. Es decir, que no hacen referencia a ningún objeto o valor de referencia, sino que son simplemente una forma de indicar el coste relativo de ese operador. Ok, podría valernos...
  5. ¿Qué versión de SQL Server tengo?

    La inminente llegada de SQL Server 2014 es una excusa como cualquier otra para asegurarnos la versión que tiene nuestro SQL Server. Puede parecer un poco exagerado pensar que, como DBAs, desconocemos qué es lo que estamos administrando, pero cuando hay que lidiar con varios entornos y dentro de ellos con decenas de instancias cada uno podemos encontrarnos con un parque de cientos de SQL Server, y que muy probablemente tendrán versiones diferentes. Por eso, una de las primeras cosas que es bueno hacer de vez en cuando es un recopilatorio de lo que tenemos desplegado listando la edición y versión de las instancias. Y no vale simplemente con decir “SQL 2012 SP1″, sino que también es importante el build exacto (es decir, lo que nos devuelve @@VERSION) El problema surge entonces para saber qué es lo que significan esos numeritos, ante lo cual podemos recurrir a la web oficial (la cual...
  6. SQL Server 2014 ya está aquí

    Pues sí, Microsoft acaba de hacer público en el TechEd de Norte América de este mes de Junio que la nueva versión de SQL Server, denominada SQL Server 2014 (personalmente lo prefiero a que hubieran escogido algo como 2012R2 o similar) con jugosas e interesantes novedades: algunas menos llamativas (mejoras en operaciones de mantenimiento en línea, hasta 8 réplicas en los Grupos de Disponibilidad…), otras un tanto extrañas (crear una base de datos en tu instancia on-premise pero con los archivos alojados en Azure…) y otras ya más interesantes (índices columnares actualizables, soporte para volúmenes compartidos en cluster, usar discos SSD como memoria extendida para la caché de datos,…) Pero la que creo que más va a llamar la atención, por el impacto que puede tener en nuestra forma de trabajar con SQL Server, es la tecnología en memoria para OLTP, cuyo nombre en clave es Hekaton y de la que ya...
  7. ¿Te parece interesante disponer en SQL Server de una tabla virtual de errores en las inserciones masivas?

    Pues a Microsoft parece ser que no, tal como responde en la propuesta de connect.com “new virtual table: errors. It would analogous to the deleted and inserted tables” (la negrita es cosecha propia): “ After carefully evaluating all of the bugs in our pipeline, we are closing bugs that we will not fix in the current or future versions of SQL Server. The reasons for closing this bug is because the scenario reported in the bug are not common enough ” Es decir, que el hecho de poder saber cuál(es) es(son) la(s) razón(es) por la(s) que, por ejemplo, un INSERT…SELECT ha fallado y poder decidir si rechazar la operación al completo (tal como sucede ahora, pero además sin conocer todos los posibles problemas) o aceptarla sabiendo que ciertas filas no han podido ser insertadas, no parece una mejora susceptible de ser incorporada (a pesar de que la competencia ya la...
  8. Lenguajes de programación de un DBA

    Es común pensar que si se trabaja como desarrollador, cuantos más lenguajes de programación se conozcan mucho mejor. Y de hecho no es extraño que si haces esta pregunta a un profesional de este tipo te responda con multitud de ellos: C#, VB.NET, Java, Javascript, HTML, ASP.NET, C++… Y la lista podría continuar hasta hacer insoportablemente largo este post. Sin embargo, desde el punto de vista de un DBA, parece más complicado pensar en que es necesario conocer algo más que SQL. Sin embargo, y aunque sólo el tener asimilados las particularidades de las implementaciones del SQL estándar en cada uno de los motores que se pueden usar (T-SQL en SQL Server, PL-SQL en Oracle, etc.) ya sería para nota, la lista de lenguajes de una persona que trabaja con la manipulación de los datos (no sólo desde el punto de vista de un administrador de base de datos tradicional...
  9. Balancear memoria entre instancias de SQL Server

    Dentro de la lista de ideas pendientes de implementar que tiene uno siempre en la cabeza en forma de post-it, había una que estaba de las primeras y que consistía en establecer la memoria correctamente en un entorno donde convivan varias instancias de SQL Server clusterizadas. Es decir, es muy común tener un entorno de dos (o más, pero por simplificar el escenario) máquinas físicas clusterizadas y sobre ellas instalar dos instancias clusterizadas (nuevamente, simplificando), alternando el nodo principal para optimizar recursos. Es decir, algo como muestra este dibujo:   En este escenario se puede tomar varios caminos respecto a la configuración de la memoria máxima de las instancias de SQL Server: Dejarla tal cual como viene de origen (mala práctica se mire como se mire) Poner un valor máximo como si sólo existiera una instancia instalada (no recomendable cuando las dos instancias pasan a ser ejecutadas en una sola...
  10. SQL Server: bug con MERGE y vistas indexadas

    Microsoft acaba de publicar un fix para resolver un problema relacionado con la devolución de datos incorrectos en las vistas indexadas cuando estos han sido actualizados a través de una operación MERGE. Aunque la información oficial la podemos leer del correspondiente artículo de la KB, en el blog de Paul White (altamente recomendable, por otra parte) tenemos mucha más información, incluyendo un script donde podemos reproducir el problema: “Incorrect results with indexed views” Creo que es un problema lo suficientemente importante para recomendar la instalación de este CU en nuestras instancias de SQL Server.

Selecciona tu idioma

Ver todos Español English

¿Qué es esto?

El blog donde mostramos nuestro trabajo, experiencias y casos de éxito, además de otras curiosidades de nuestra comunidad