CPU Affinity Mask y Virtualización de SQL Server

Después de varios meses sin escribir por temas de trabajo, vuelvo con un articulo de Denny Cherry (Twitter/Blog) sobre un tema que cada vez veo mas presente en distintos clientes… La virtualización de SQL Server. Ahí vamos!

Si tienes algún Servidor SQL físico que quieras virtualizar, debieras revisar la configuración de Affinity Mask antes de mover la maquina desde el ambiente físico al virtual usando algún software P2V. La razón para esta precaución es que la Affinity Mask se configura específicamente para la CPU y el numero de núcleos de la CPU no será el correcto y no podrás obtener la configuración correcta usando sp_configure sin obtener un error como el que se muestra a continuación

Msg 5832, Level 16, State 1, Line 1

The affinity mask specified does not match the CPU mask on this system.

Si no se han convertido las maquinas antes, simplemente cambiamos las affinity mask a 0 lo cual las configura para todos los procesadores. Si ya hemos convertido las maquinas, la mejor opción es conectarnos a los SQL Server usando la conexión dedicada y cambiamos manualmente el valor en la tabla de sistema usando la siguiente consulta

UPDATE sys.configurations

SET value = 0

WHERE Name = ‘affinity mask

Ojala nunca tengan este problema, pero si si les ocurre al menos ya saben como solucionarlo.

ACTUALIZACION: Paul Randal me recuerda que la CPU Affinity se deprecio en SQL Server 2008 R2, así que posiblemente no quieran configurar esta propiedad.

Posiblemente la Nube no será una buena solución de respaldo

Este artículo es una traducción del Blog de Denny Cherry. A quien agradezco la autorización para traducir su contenido al español.

El 19 de julio, encontré un artículo en un blog que hablaba acerca de la posibilidad de desechar una solución de respaldo y usar la nube en reemplazo. Básicamente, los puntos eran que como alguien mas almacena tus datos, ya no tendrías que preocuparte de planes de recuperación de desastres, mantener múltiples copias, etc. porque alguien mas se preocuparía de esas cosas ahora.

En el papel esto suena genial, pero yo trabajo en el mundo real. Y en el mundo real, como administrador no puedo confiar en que alguien mas maneje mi solución de recuperación de desastres. Cuando las cosas se rompen y perdemos todo y tenemos que restaurar, como administrador yo soy el que esta amarrado con la gerencia a levantar todo y volver a echar a andar la compañía, y no a quien quiera que yo le haya tercerizado los respaldos.

Cuando se trata de mis respaldos (y básicamente de todos los datos) no confío en nadie. Si se los envío a un proveedor en la nube como se que nadie va a intentar revisarlos, modificarlos, venderlos, etc? Si yo no controlo todo de punta a punta, no puedo estar seguro de que mis datos están seguros. Puedo cifrarlos antes de subirlos a la nube, pero eso solo me da cierto nivel de protección. El cifrado puede romperse, solo se requiere tener suficientes equipos destinados a hacerlo.

Existe otro pequeño problema con el usar la nube para respaldar. Las grandes empresas (y las pequeñas también) tienen grandes cantidades de datos, y quiero decir GRANDES cantidades. En estos días, no es extraño que una empresa de unas 10 – 20 personas tenga un par de Terabytes de datos. Si todos esos datos se respaldaran a la nube periódicamente, se necesitaría mucho ancho de banda para poder realizar esos respaldos en un tiempo prudente. El ancho de banda no es gratis, no lo es en Estados Unidos y menos en otros países. Muchos países tienen topes de ancho de banda para subida y debes pagar si lo sobrepasas. Si tienes que subir 100 Gigas de datos a la semana (un 10% de cambio en los datos es bastante normal) podría demorar unas 10 – 12 horas en subirse con una conexión rápida, y costar varios cientos de dólares en cargos de banda ancha.

Ejecutar tus aplicaciones en la nube es algo totalmente distinto. Cuando haces esto, tienes el control de la instalación y puedes controlar en cuantos sitios residen tus datos. Las soluciones de respaldo en la nube que he revisado no tienen este nivel de control. Simplemente tienes que confiar en que la empresa a la que le estás pagando esté haciendo las cosas bien. Después de todo, si almacenan los datos en un lugar cercano para acceso rápido ¿Que pasa si hay un corte de energía por un desastre natural y ellos sufren el mismo problema? ¿A quien llamamos? No puedes despedir a nadie porque el plan era dejar que ellos lo administraran. Y lo peor, no puedes levantar tus sitios porque debes esperar que ellos levanten el de ellos.

En mi mundo, esa no es una solución razonable.

Estar Preparados: Recolectar Datos desde sp_whoisactive a una tabla

Este artículo es una traducción de uno publicado por Kendra Little en su blog. Le agradezco su autorización y si les gusta, los agradecimientos deben ir a ella. / This post was translated from Kendra Little’s blog. I wanna thank her for letting me use this and if you like this, comments and thanks should go to her.

Soy fan del Procedimiento Almacenado sp_whoisactive de Adam Machanic.

Una de las mejores cosas del sp_whoisactive es que es muy rápido al generar una tabla para recolectar los datos necesarios, luego se ejecuta el procedimiento en un ciclo con una cláusula de espera para recolectar regularmente los datos necesarios. Este uso está documentado (ver el artículo de Adam acá), pero he habado con mucha gente q no sabe cómo hacer esto o no tiene un script guardado.

¿Qué es sp_whoisactive?

Sp_whoisactive es un procedimiento escrito por Adam Machanic. Se puede encontrar acá: sp_whoisactiveV10

Que haremos hoy

Hágase un favor: Hoy prepárese para lo siguiente:

· Crear el procedimiento almacenado sp_whoisactive en una base de datos de usuario utilizada solo para administración (Ver artículo de Adam acá)

· Jugar con el script que les entrego más abajo y examinar los parámetros del procedimiento almacenado

· Guardar el script que crea una tabla para su versión preferida de sp_whoisactive, y luego ejecútela en ciclos para almacenar los datos.

¿Por qué haría esto?

Aunque se ejecuten herramientas de monitoreo, usar sp_whoisactive para revisar datos desde las DMVs (incluyendo query plans) puede ser muy valioso.

Cuando las cosas salen mal, terriblemente mal, sería bueno tener este script en reserva para recolectar datos sobre la actividad existente en la instancia SQL mientras uno se enfoca en el problema. Esto nos ayudara a resolver el problema lo más rápido posible, si revisamos periódicamente los datos que recolecta. Como los datos están guardados, podemos usarlos más adelante para explicar las causas del problema y prevenir que suceda otra vez.

Paso 1: crear la tabla @destino

Déjenme dejar esto claro nuevamente: esto no fue mi trabajo. No quiero tomarme el crédito, pero si quiero difundirlo.

Primero, creamos la tabla destino. Sp_whoisactive permite generar una tabla destino fácilmente. Acá hay una versión básica que incluye la fecha actual en el nombre de la tabla, así como tres flags para obtener información de las transacciones, query plans y block leaders.

DECLARE @destination_table VARCHAR(4000) ;
SET @destination_table = ‘WhoIsActive_’ + CONVERT(VARCHAR, GETDATE(), 112) ;

DECLARE @schema VARCHAR(4000) ;
EXEC sp_WhoIsActive
@get_transaction_info = 1,
@get_plans = 1,
@find_block_leaders = 1,
@RETURN_SCHEMA = 1,
@SCHEMA = @schema OUTPUT ;  

SET @schema = REPLACE(@schema, ‘<table_name>’, @destination_table) ;

PRINT @schema
EXEC(@schema) ;

Paso 2: Crear el ciclo para recolectar los datos.

Es necesario asegurarse de especificar los mismos parámetros para el sp_whoisactive en este ciclo, para que los datos de salida encajen en el schema para la tabla creada.

Este ejemplo corre 10 veces con un lapso de 5 segundos entre ejecuciones. Dependiendo de lo que se encuentre, los números se cambian a discreción.

DECLARE
@destination_table VARCHAR(4000) ,
@msg NVARCHAR(1000) ;

SET @destination_table = ‘WhoIsActive_’ + CONVERT(VARCHAR, GETDATE(), 112) ;

DECLARE @numberOfRuns INT ;
SET @numberOfRuns = 10 ;

WHILE @numberOfRuns > 0
BEGIN;
EXEC dbo.sp_WhoIsActive @get_transaction_info = 1, @get_plans = 1,
@find_block_leaders = 1, @DESTINATION_TABLE = @destination_table ;

SET @numberOfRuns = @numberOfRuns – 1 ;

IF @numberOfRuns > 0
BEGIN
SET @msg = CONVERT(CHAR(19), GETDATE(), 121) + ‘: ‘ +
‘Logged info. Waiting…’
RAISERROR(@msg,0,0) WITH nowait ;

WAITFOR DELAY ’00:00:05′
END
ELSE
BEGIN
SET @msg = CONVERT(CHAR(19), GETDATE(), 121) + ‘: ‘ + ‘Done.’
RAISERROR(@msg,0,0) WITH nowait ;
END

END ;

GO

Paso 3: Generar la consulta para revisar los resultados.

Este paso es opcional, pero como la tabla contiene en el nombre un Timestamp, me gusta tener a mano una consulta para revisar los resultados sin tener que copiar y pegar el nombre de la tabla. También prefiero poner la columna collection_time primero y ordenar según ella.

DECLARE @destination_table NVARCHAR(2000), @dSQL NVARCHAR(4000) ;
SET @destination_table = ‘WhoIsActive_’ + CONVERT(VARCHAR, GETDATE(), 112) ;
SET @dSQL = N’SELECT collection_time, * FROM dbo.’ +
QUOTENAME(@destination_table) + N’ order by 1 desc’ ;
print @dSQL
EXEC sp_executesql @dSQL

SQL Server 2008 R2 disponible para descarga

Estimados,

Desde hoy ya está disponible a suscriptores Technet y MSDN la versión final de SQL Server 2008 R2 y de PowerPivot. Esto se suma a la disponibilidad la semana pasada de SharePoint 2010 y Office 2010.

Para quienes no tienen suscripciones a Technet o MSDN, en un artículo de la semana pasada, esta el link para descargar las versiones de evaluación de SQL Server 2008 R2.

Saludos,

SQL Server 2008 R2 ya esta RTM

Estimados,

Luego de un par de meses sin actualizar este blog, vuelvo para contarles que hoy Microsoft informó que SQL Server 2008 R2 ya esta en RTM (Release To Manufacturing). Eso significa que la versión final que saldrá a público ya está lista.

Les comparto algunas mejoras de esta nueva versión de SQL:

  • PowerPivot: Es una solución de BI de “auto-servicio”. Permite a los usuarios finales acceder, analizar y compartir datos dentro de la empresa usando SharePoint 2010 y Excel 2010.
  • Master Data Services: Permite que las organizaciones tengan un repositorio centralizado de su información, no importando de que sucursales o sistemas vengan los datos. Así se asegura un almacén de datos actualizado y común a todas las áreas de la empresa.
  • Report Builder 3.0: Componente de creación de reportes con soporte para visualización Geoespacial.
  • StreamInsight: Es una plataforma de procesamiento de baja latencia que permite analizar la información mas rápido a medida que los datos van cambiando, y así tomar mejores decisiones en tiempo casi real.

Si quieren mas información sobre SQL Server 2008 R”, les dejo los siguientes links:

Saludos y como siempre sus comentarios y sugerencias son bienvenidos,

Listar las tablas y columnas de una Base deDatos

Hoy me encontré con una petición bastante inusual (inusual, porque nunca me lo habían pedido antes…). ¿Como obtengo una lista de TODAS las tablas y TODAS las columnas de una Base de Datos?

No fue menor la solicitud. Obtener el listado de todas las columnas de una tabla no es difícil, pero esta Base de Datos tenia cerca de 60 tablas y algunas de estas tablas tienen casi 20 columnas, la tarea se hacía un poco tediosa.

Hasta que se me ocurrió ponerme a cachurear por ahí y encontré las siguientes consultas:

Para Bases de Datos SQL Server 2000

SELECT SO.NAME, SC.NAME

FROM sysobjects SO INNER JOIN syscolumns SC

ON SO.ID = SC.ID

WHERE SO.XTYPE = ‘U’

ORDER BY SO.NAME, SC.NAME

Para Bases de Datos SQL Server 2005

SELECT SO.NAME, SC.NAME

FROM sys.objects SO INNER JOIN sys.columns SC

ON SO.OBJECT_ID = SC.OBJECT_ID

WHERE SO.TYPE = ‘U’

ORDER BY SO.NAME, SC.NAME

 

Como siempre, sus dudas y comentarios son bienvenidos.

Creando un Plan de Respaldo en SQL Server

(Este articulo fue publicado originalmente en mi antiguo blog).

Una de las tareas más importantes de un DBA es la creación e implementación de un plan de respaldo y recuperación de nuestras Bases de Datos. La creación de este plan puede tomar bastante tiempo y trabajo, hay que pensar en las Bases de Datos que se respaldaran, cada cuanto se harán los respaldos, etc.

Vamos a ver algunos de los puntos en los cuales fijarnos al preparar el plan de respaldo.

· ¿Qué Bases de Datos me conviene respaldar? La Base de Datos Master es vital para el funcionamiento de SQL Server. Si falla o se corrompe, el servidor completo se vuelve inútil. Lo bueno es que esta Base de Datos solo sufre cambios si creamos Bases de datos nuevas, creamos nuevos logins o cambiamos la configuración del servidor. Lógicamente en estos casos es conveniente hacer un respaldo de la Master. Sin embargo, si una Base de Datos contiene datos vitales de nuestros clientes y sufre cambios repetidamente, necesita ser respaldada más seguido.

· ¿Qué tan importante son los datos almacenados? Una base de datos de desarrollo o testeo no es tan importante como una que se encuentra en producción, por lo tanto la primera basta con respaldarla una vez a la semana, en cambio la segunda se recomienda respaldarla todos los días. Esto también va a influir en el tipo de Backup que realizaremos, un backup completo toma demasiado tiempo en el caso de una Base de Datos en producción como para realizarlo todos los días. Si la Base de Datos es demasiado crítica, se puede realizar un Backup completo 2 veces a la semana y el resto de los días un Backup Diferencial y cada una hora un Backup de los logs de transacciones.

· ¿Cada cuanto tiempo hay cambios en los datos? Una Base de Datos de solo lectura no tiene muchos cambios y por lo tanto puede pasar más tiempo entre respaldos. Por el contrario, una Base de Datos que se actualiza varias veces al día debe ser respaldada al menos una vez al día.

· ¿Qué tan rápido necesito tener la información disponible? En caso de un fallo, es importante el tiempo que nos demoraremos en tener disponible los datos nuevamente. Si tenemos nuestros respaldos en cinta, la recuperación tomará más tiempo que si lo tenemos en un disco o en varios dispositivos de respaldo.

· ¿Tengo el equipamiento para realizar los respaldos? Si no tenemos donde almacenar los respaldos, difícilmente podremos hacer un plan de respaldo apropiado. Es bueno considerar más de un tipo de dispositivo de respaldo (cintas, medios ópticos, discos duros, etc.)

· ¿Cuál es la mejor hora para realizar respaldos? La idea es hacer los respaldos durante el tiempo en que las Bases de Datos tienen un menor uso. Esto va a disminuir el tiempo que demora el respaldo en hacerse, pero a veces es importante considerar que hay Bases de Datos que están en uso durante el tiempo en que otras no lo están.

· ¿Es necesario almacenar mis respaldos en otro lugar físico? Mantener copia de nuestros respaldos en otra oficina o lugar físico es una manera de proteger los datos si nuestras instalaciones se ven afectadas por un desastre mayor (incendio, terremoto, etc.). Pero es importante considerar que también es importante mantener una copia de nuestro sistema de respaldo para poder recuperar rápidamente los datos.

Roles en SQL Server

(Este articulo fue publicado originalmente en mi antiguo blog).

Cuando alguien dice que se especializa en Bases de Datos es normal que te pidan saber de todo. Pero entre los que usamos SQL Server hay varios tipos distintos de usuarios y cada tipo tiene un enfoque distinto (que muchas veces tienen cosas en común).

La idea de este post es tratar de ayudar a quienes están recién empezando con SQL Server y aun no saben muy bien a que “área” dedicarse.

  • Arquitecto

Define el diseño de la infraestructura y tecnología que utilizará el sistema o solución. También define la visión, alcance e interoperabilidad del proyecto y la implementación de cada parte del sistema o solución.

  • Administrador

Ejecuta las operaciones diarias del sistema en áreas como disponibilidad, monitoreo, optimización, actualización, implementación, resolución de problemas y configuración.

  •  Analista

Crea reportes y modelos de datos para uso personal y del resto de la organización. Los analistas pueden ser profesionales del área de procesamiento de datos, pero generalmente son los responsables de analizar los datos de la empresa mientras realizan otras funciones paralelas.

  • Desarrollador

Diseña, implementa y prueba Sitios Web, Reportes o Aplicaciones que utilizan partes específicas del sistema diseñado por el Arquitecto. En lo particular, los Desarrolladores de Bases de Datos diseñan, implementan y prueban los schemas y objetos, como tablas y procedimientos almacenados, en una Base de Datos.

  • Information Worker

Traduce la información disponible en un sistema a información de la empresa.

El rol del DBA en la “nube”

(Este artículo fue publicado anteriormente en mi antiguo blog)

“Realmente no me gusta el termino “nube”, porque es solo computo, pero entiendo la idea. La pregunta es: ¿Cual es el rol del DBA en un ambiente “en la nube”? Si tu empresa mueve su estructura a un proveedor, ¿Que hace el DBA?

Creo que lo que debe hacer es seguir con lo que estamos haciendo hasta ahora – movernos de un rol táctico a uno estratégico.

Es cierto, uno debe saber como hacer respaldos de la Base de Datos, donde se almacenan los datos, formas de normalización, y todo lo que un MCDBA debe saber. Pero como les he dicho antes, hay que conocer el negocio de la empresa. Debemos asegurarnos de pensar en temas mas grandes, como los archivos de datos, estrategias de acceso y retención, continuidad del negocio y mas. Debemos pasar de ser Administrador de Datos a Profesional de Datos. Nuestro rango de visión en el activo mas valioso de la compañía: LOS DATOS. Debemos ser vistos como campeones de los datos de la compañía en lugar de ser solo una persona que administra bits y bytes.

No me malentiendan – aun nos falta mucho. Aun hay servidores que instalar, Bases de Datos que optimizar, mantenimiento, optimización y parches de seguridad que aplicar. Pero en el camino, debemos usar un poco de nuestro tiempo entendiendo la compañía u organización y como utiliza los datos. Solo así estaremos listo cuando “Las nubes” se junten.”

Este articulo es una traducción (con todos los permisos) de uno que leí en CARPE DATUM. Uno de los blogs que mantengo en mis RSS y que siempre estoy revisando. Para quienes tengan interés en ser un DBA, se los recomiendo 100%.

Debo agradecer a Buck Woody, quien me autorizo para tomar su articulo y traducirlo al español para mostrárselo a ustedes.

Como siempre, sus comentarios y preguntas son bienvenidos.

Saludos,

Conceptos Básicos de Bases de Datos, Parte 2

(Este articulo fue publicado anteriormente en mi antiguo blog.)

Recibí un correo de un futuro alumno de Informática de una Universidad acá en Chile, al cual pareció interesarle el tema que toqué en mi post anterior y me preguntaba si podía tocar temas aun más básicos en el campo de bases de datos; así que acá va un “Glosario” básico:

¿Qué es un Procedimiento Almacenado?

Un Procedimiento Almacenado en un conjunto de sentencias SQL que han sido creadas anteriormente y almacenadas en un servidor de bases de datos. A este conjunto de sentencias se le debe asignar un nombre único. Una de las ventajas de utilizar Procedimientos Almacenados es que estos aceptan parámetros de entrada, lo que hace posible su utilización por varios clientes al mismo tiempo a través de la red. Otra ventaja es que si modificamos el Procedimiento, este automáticamente se actualiza para los clientes. Esto permite que haya una mejora en la performance del servidor y reducir el tráfico a través de la red. Además podemos utilizar Procedimientos Almacenados para ayudarnos en la mantención y administración de nuestras Bases de Datos.Una buena práctica es nombrar los Procedimientos Almacenados en la forma: usp_<descripción>.

¿Qué es un Trigger?

Un Trigger es un procedimiento que inicia una acción cuando ocurre algún evento (INSERT, DELETE o UPDATE). Los Triggers se almacenan y administran dentro del DBMS. Es importante mencionar que los Triggers no pueden llamarse o ejecutarse; el DBMS automáticamente ejecuta el Trigger como resultado de una modificación a la tabla asociada. Generalmente son usados para mantener la integridad referencial de los datos en caso que estos cambien a menudo. Los Triggers se parecen bastante a los Procedimientos Almacenados; ambos son procedimientos lógicos almacenados a nivel de la Base de Datos. La diferencia está en que los SP no son manejados por eventos y no están atados a una tabla específica como lo están los Triggers. Los SP se ejecutan cuando hacemos una “LLAMADA” al procedimiento, en cambio el Trigger se inicia automáticamente en respuesta a un evento.

TRIGGER ANIDADO: Un Trigger puede contener sentencias INSERT, DELETE o UPDATE. Al iniciarse el Trigger a raíz de una modificación en los datos de una tabla, el Trigger puede modificar nuevamente los datos gatillando otro Trigger. A esto se le llama Trigger Anidado.

¿Qué es una Vista?

Una Vista es un subconjunto de datos de una Tabla. Se utilizan generalmente para recopilar datos, pero también pueden ser usadas para actualizar o eliminar filas. Las filas que modifiquemos o eliminemos en la vista también lo harán en la tabla original. Si se realizan cambios a la(s) tabla(s) desde donde obtenemos la Vista, esta también cambiara. Los resultados de una Vista no se almacenan en la Base de Datos.

¿Qué es un índice?

Un Índice es una estructura física que contiene punteros a los datos. Se utilizan dentro de una tabla para localizar filas más rápida y eficientemente. Un Índice se puede crear en una o más columnas de una tabla, y cada Índice debe tener un nombre. Los usuarios no pueden ver los Índices; son solo para acelerar las consultas. El uso eficiente de Índices es una de las mejores maneras para mejorar la performance de una aplicación que accede a Bases de datos. Esto, porque cada vez que no existe un índice para ayudar en la consulta, se realiza un barrido completo de la tabla. En un barrido, SQL Server examina CADA fila de la tabla hasta completar la consulta. Es inevitable que esto ocurra en ciertos casos, pero si las tablas son demasiado grandes, un barrido afecta de manera muy importante la performance.

¿Qué es un Cursor?

Un cursor es un objeto de la Base de Datos usado por las aplicaciones para manipular los datos fila a fila, en lugar de hacerlo en bloques de filas como lo hacen los comandos SQL normales.

Para poder trabajar con Cursores, debemos realizar los siguientes pasos:

  • Declarar el Cursor.
  • Abrir el Cursor.
  • Recuperar las filas desde el Cursor.
  • Procesar las filas obtenidas.
  • Cerrar el Cursor.
  • Eliminar la referencia al Cursor.

¿Cuál es la diferencia entre una Función y un Procedimiento Almacenado?

Una Función puede ser usada en una sentencia SQL en cualquier parte donde haya un WHERE, HAVING o SELECT; en cambio un Procedimiento Almacenado no. Además, las Funciones que retornan tablas pueden ser usadas como un conjunto de filas independiente. Así, podemos usarlas en JOINs con otras tablas.

OK, suficiente por hoy. En la próxima entrega: JOINs, Tipos de Índices y otras cosas que seguramente se me ocurrirán en el momento.

Como siempre, sus comentarios son más que bienvenidos igual que sus consultas.