SQL Server Version

http://sqlserverbuilds.blogspot.com/

 

image

Muestra las  versiones del producto.

SELECT
   [ProductName] =
            CASE LEFT(CAST(SERVERPROPERTY(‘ProductVersion’) AS VARCHAR(10)),5)
                WHEN ’7.00.’ THEN ‘SQL Server 7.0′
                WHEN ’8.00.’ THEN ‘SQL Server 2000′
                WHEN ’9.00.’ THEN ‘SQL Server 2005′
                WHEN ’10.0.’ THEN ‘SQL Server 2008′
                WHEN ’10.50′ THEN ‘SQL Server 2008 R2′
                WHEN ’11.0.’ THEN ‘SQL Server 2012′
                ELSE ‘Unknown’
            END

Copias de Seguridad

Hacer copias de seguridad de bases de datos es una de las tareas más importantes de un administrador de base de datos. Un buen DBA debe ser capaz de configurar rápidamente cualquier servidor de base de datos para la estrategia más adecuada. Sin embargo, muchas empresas tienen DBAs «accidentales» o, a veces incluso los empleados que no son de DBA a cargo de las copias de seguridad de bases de datos fatal…

Cuidados:

· Usted nunca puede tener suficientes copias de seguridad.

· Quedarse sin espacio, los fallos de disco, las interrupciones de red.

· Tener un mirroring puede dar tranquilidad pero puede tener problemas fallos de disco que ponen la BD suspect.

Muchas empresas realizan un backup full en la noche y varios log backupesto es funcional pero a veces puede requerir mucho tiempo por ejemplo: Digamos una copia de seguridad completa a la medianoche y una de los logs cada 10 minutos. recuperar una base de datos a las 11:05 va requerir restaurar el Full Backup y toda la cantidad de backups de logs. Aquí es donde los Backup diferenciales son útiles.

Backup Diferenciales:

Una copia de seguridad diferencial tiene todos los cambios desde la última copia de seguridad completa

Ahora como utilizarlo como en el ejmplo  digamos que hemos implementado una copia de seguridad diferencial para ejecutar cada tres horas a partir a las 3 de la mañana y terminan a las 9 pm Para recuperar la base de datos a las 11 pm, usted tendría que restaurar la copia de seguridad completa de la medianoche, el diferencial más reciente copia de seguridad (9 horas, en este caso) y luego los últimos backup de logs. El tiempo de recuperación se reduce significativamente. Las copias de seguridad diferenciales en la mayoría de los casos terminan muy rápido y el tamaño es manejable en la mayoría de los casos, no es necesario para mantenerlos por mucho tiempo, un día o dos, debe ser lo suficientemente bueno.

Otros beneficios

La compresión de copia de seguridad era una nueva característica de SQL Server 2008 en la versión Enterprise Edition obvio. En SQL Server 2008 R2 Microsoft decidió hacer esta función esté disponible en la edición Standard. La compresión de copia de seguridad tiene varios beneficios: Bases de datos de copia de seguridad más rápido, sino que también restaurar más rápidamente y que le ahorrará una gran cantidad de espacio de almacenamiento.

Inconveniente a tomar en cuenta

El único inconveniente es que el uso de CPU de SQL Server es más alto mientras que la copia de seguridad se está ejecutando. Pero teniendo en cuenta que usted puede hacer copias de seguridad fuera de horas o , al menos, durante los períodos de uso más bajos , esto no debería representar un problema para la gran mayoría de los servidores de bases de datos

Otras recomendaciones

· Marque siempre el check de integridad si la copia de seguridad no se puede utilizar, el plan de mantenimiento marcará como un fracaso y le notificará de inmediato. (pero no crea que siempre se puede restaurar porque la integridad esta correcta.)

· Cambien la configuración del servidor para comprimir backup (De esta manera una copia de seguridad se comprime incluso si “WITH COMPRESSION” no está incluido en el comando de copia de seguridad)

· Asegúrese de que los archivos se copian en una cinta o en otra ubicación de la red

· La mas importante de todas poner a prueba el proceso de restauración y asegurarse de que las copias de seguridad son válidas lo importante no es hacer backup es poder restaurarlos. Esto lo protege contra la pérdida del servidor de base de datos.

Extremo

Pero , ¿qué pasaría si todo el centro de datos se daña por el fuego , huracán, lluvia de meteoritos) , o cualquier otro tipo de desastres? Para una protección total, usted debe tener una estrategia en un lugar que se mueve periódicamente las copias de seguridad de cinta a otra ubicación geográfica.

Índices y su mantenimiento

¿Por qué es necesario el mantenimiento de índices automáticos Cuando el rendimiento empeora , una de las primeras cosas que la gente mirar es si los sistemas involucrados están configurados de acuerdo a las mejores prácticas . Si usted no está siguiendo una buena práctica, no sería un mal momento para iniciar.

 Un mantenimiento de índices regular tiene mucho mérito por lo que es bueno automatizar el mantenimiento de índices. Pero siempre con mucha cautela supervisar el uso de tiempo de ejecución y la IO y ejecutarlo en momentos de bajo volumen

 ¿Planes de mantenimiento o scripts personalizados? Ummmm planes de mantenimiento de SQL Server, son muy simplistas : sólo se puede decir » reconstruir todos los índices » o » reorganizar todos los índices » . Usted no puede decir: » Si el índice tienee 45% o más fragmentado , reconstruirlo – . Siempre va a ser mejor que no hacer nada», esto puede ser una opción decente.

 Para mi los scripts de mantenimiento de índices personalizados son el camino a seguir. Mi favorito: Los scripts de mantenimiento de Hallengren Ola http://ola.hallengren.com/. Son súper flexibles , bien documentados y lo mejor de todo… gratis!

Consejos para usar estos scripts:

Descargar y configurarlos en una instancia de prueba obvio para primero familiarizarse hay un montón de opciones en los parámetros , y tendrá que jugar con ellos.

Configurarlos como un mantenimiento y revisar que se estén realizando con éxito. Configurar correo y los operadores de base de datos para los trabajos le permiten saber si fallan.

 

SQL Server Profiler – Duration

Algo que es muy común pero que a veces se nos olvida y trae dolores de cabeza para tenerlo súper claro.

Cuando iniciamos un Profiler el tiempo de duración en (SQL Server Profiler graphical user) la columna curación esta en milisegundos por defecto.

Pero cuando una traza se guardan en un archivo o una tabla de base de datos, el valor de la columna duración se escribe en microsegundos.

Conversión 1 minuto = 60,000,000 Microsegundos

image

Propiedades de las vistas

Dos propiedades de las vistas que nos pueden ayudar significativamente:

Schemabinding: Esta propiedad nos permite configurar la vista de tal forma que evite modificar el diseño de la tabla sin quitar antes esta propiedad. Si habilitamos esta propiedad, evitamos tener vistas huérfanas y que son tan molestas para el usuario (vistas que porque falta una columna, una tabla… no funciona), ósea si queremos modificar la estructura de la tabla, es necesario deshabilitar previamente el schemabinding asociado a la vista.

with check option: Esta propiedad evita que podamos hacer updates distintos a los que tenemos en la definición de la vista. Por ejemplo si la definición de la vista tenemos un filtro con un where id=150, entonces los updates sólo pueden ser id=150.

Windows 8 – SQL Server 2008R2

Bueno simplemente el día de hoy instale en mi versión de Windows 8 el motor de SQL Server 2008 R2 con resultados satisfactorios, aprovecho para indicar que verdaderamente me encuentro satisfecho con el aprovechamiento de recursos del nuevo sistema operativo de Microsoft…

windows_8

SQL Server Mensajes de error

(Sysmessages) niveles de gravedad de los errores.

Cada mensaje de error mostrado por SQL Server tiene un número de mensaje de error asociado que identifica el tipo de error.

Los niveles de gravedad de error proporcionan una referencia rápida sobre la naturaleza del error. El número de estado de error es un valor entero entre 1 y 127, el mensaje de error es una descripción del error que se produjo. Los mensajes de error se almacenan en la tabla sysmessages  en system table de master.

SELECT *
FROM master.dbo.sysmessages

El nivel de gravedad se muestra a continuación.

0 to 10 – Messages with a severity level of 0 to 10 are informational messages and not actual errors.

11 to 16 – Severity levels 11 to 16 are generated as a result of user problems and can be fixed by the user. For example, the error message returned in the invalid update query, used earlier, had a severity level of 16.

17 – Severity level 17 indicates that SQL Server has run out of a configurable resource, such as locks. Severity error 17 can be corrected by the DBA, and in some cases, by the database owner.

18 –  Severity level 18 messages indicate nonfatal internal software problems.

19 – Severity level 19 indicates that a nonconfigurable resource limit has been exceeded.

20 – Severity level 20 indicates a problem with a statement issued by the current process.

21 – Severity level 21 indicates that SQL Server has encountered a problem that affects all the processes in a database.

22 -Severity level 22 means a table or index has been damaged. To try to determine the extent of the problem, stop and restart SQL Server. If the problem is in the cache and not on the disk, the restart corrects the problem. Otherwise, use DBCC to determine the extent of the damage and the required action to take.

23 – Severity level 23 indicates a suspect database. To determine the extent of the damage and the proper action to take, use the DBCC commands.

24 -Severity level 24 indicates a hardware problem.

25 – Severity level 25 indicates some type of system error.

Comprendiendo TempDB SQL Server

Esto varia de acuerdo a lo que usted necesita o «It Depends…»como dice alguien por ahí el cual tuve la oportunidad de escuchar en una charla.

El año pasado en PASS 2011 Bob Ward, uno de los ingenieros de escalación de SQL, formuló la siguiente recomendación que se actualizará en las referencias.

Como regla general, si el número de procesadores lógicos es menor que 8, utiliza el mismo número Data Files como procesadores lógicos. Si el número de procesadores lógicos es mayor que 8, use 8 data files y si la contención continua, aumentar el número de Data Files mediante múltiplos de 4 (hasta el número de procesadores lógicos)  esto hasta que la contención se reduzca a niveles aceptables.

Si usted tiene contención en TempDB usted podrá notar algunos de lo siguientes wait types

  • PAGELATCH_EX – Exclusive
  • PAGELATCH_UP – Update
  • PAGELATCH_SH – Shares

Sumamente importante todos los data files deben ser del mismo tamaño y tener la misma configuración de auto-growth ya que SQL los utiliza de forma proporcional; se deben chequear los tamaños periódicamente.

 Como siempre unos link con información adicional. (Optimizing tempdb Performance)

SQL Server Índices

Consolidación para mejorar

Por ejemplo

Indice1 nombre, primerapellido include (telefono)

Indice2 nombre, primerapellido, segundonombre include (cedula)

Combínelos

nombre, primerapellido, segundonombre include (teléfono, cedula)

Antes de crear cualquier índice revise los índices actuales, es sorprendente lo que se puede encontrar.