Listado de la etiqueta: sql

Mejorar rendimiento de SQL Server – Estadísticas de Espera

En este oficio se escucha de manera repetitiva frases como: «Mi servidor anda lento«, «Se tarda demasiado«, «como hago para que funcione más rápido«.

Al intentar encontrar la causa del problema muchas veces no sabes dónde empezar. En esta serie de artículos veremos algunos pasos a seguir para tratar de determinar el motivo que lo origina.
A tener en cuenta:

Generalmente el resultado es ocasionado, no solo por un motivo, sino por la suma de varios. Por lo se debe analizar y tomar resultados de la mayor cantidad de variables posibles (red, disco, memoria, consultas, etc) y recién ahí, en conjunto tomar medidas. Caso contrario, si se analizan por separado, seguramente cada uno determinará una solución diferente.

 

Estádisticas de Espera (waits statistics)
Nos darán una visión general de cuáles son los mayores tiempos de espera a nivel de recursos y de sistema operativo.
En esta oportunidad nos valemos de un script de http://habrahabr.ru/post/216309/ para listar los mismos:

SELECT TOP 10 
wait_type , max_wait_time_ms wait_time_ms , signal_wait_time_ms , wait_time_ms - signal_wait_time_ms AS resource_wait_time_ms , 
100.0 * wait_time_ms / SUM(wait_time_ms) OVER ( ) AS percent_total_waits , 100.0 * signal_wait_time_ms / 
SUM(signal_wait_time_ms) OVER ( ) AS percent_total_signal_waits , 100.0 * ( wait_time_ms - signal_wait_time_ms ) / 
SUM(wait_time_ms) OVER ( ) AS percent_total_resource_waits FROM sys.dm_os_wait_stats WHERE wait_time_ms > 0 
-- remove zero wait_time 
AND wait_type NOT  IN 
 -- filter out additional irrelevant waits
(	'SLEEP_TASK', 'BROKER_TASK_STOP', 'BROKER_TO_FLUSH', 'SQLTRACE_BUFFER_FLUSH','CLR_AUTO_EVENT', 'CLR_MANUAL_EVENT', 
	'LAZYWRITER_SLEEP', 'SLEEP_SYSTEMTASK', 'SLEEP_BPOOL_FLUSH', 'BROKER_EVENTHANDLER', 'XE_DISPATCHER_WAIT', 'FT_IFTSHC_MUTEX',
	'CHECKPOINT_QUEUE', 'FT_IFTS_SCHEDULER_IDLE_WAIT', 'BROKER_TRANSMITTER', 'FT_IFTSHC_MUTEX', 'KSOURCE_WAKEUP', 'LAZYWRITER_SLEEP', 
	'LOGMGR_QUEUE', 'ONDEMAND_TASK_QUEUE', 'REQUEST_FOR_DEADLOCK_SEARCH', 'XE_TIMER_EVENT', 'BAD_PAGE_PROCESS', 'DBMIRROR_EVENTS_QUEUE',
	'BROKER_RECEIVE_WAITFOR', 'PREEMPTIVE_OS_GETPROCADDRESS', 'PREEMPTIVE_OS_AUTHENTICATIONOPS', 'WAITFOR', 'DISPATCHER_QUEUE_SEMAPHORE', 
	'XE_DISPATCHER_JOIN', 'RESOURCE_QUEUE' ) 
ORDER  BY wait_time_ms DESC

 


 

El resultado dependerá de su servidor:
A continuación una descripción de los waits mas comunes:

  • CXPACKET o A menudo indica nada más que ciertas consultas se ejecutan con el paralelismo; CXPACKET no son una señal inmediata de los problemas, a pesar de que puede ser el síntoma de otro problema, asociado con uno de los otros tipos de espera alto valor en la instancia.
  • SOS_SCHEDULER_YIELD o Las tareas que se ejecutan en el sistema pueden haber superado su cantidad permitida, y están teniendo que esperar en la cola de ejecutables. Esto puede indicar que el servidor está bajo demasiada presión.
  • ThreadPool o Una tarea tuvo que esperar a tener un trabajador libre para poder ejecutarla. Esta podría ser una señal de inanición de subproceso de trabajo, lo que requiere un aumento en el número de CPU en el servidor, para manejar una carga de trabajo altamente concurrente, o puede ser una señal de bloqueo, lo que resulta en un gran número de tareas paralelas que consumen los subprocesos de trabajo por largos períodos.
  • LCK_ * o Estos esperan tipos significan que el bloqueo se produce en el sistema y que las sesiones han tenido que esperar para adquirir un bloqueo de un tipo específico, que fue detenido por otra sesión de base de datos. Este problema puede investigarse más a fondo utilizando, por ejemplo, la información de los sys.dm_db_index_operational_stats.
  • PAGEIOLATCH_ *, IO_COMPLETION, WriteLog o Estas esperas son comúnmente asociados con el disco I / O y ocasionan los cuellos de botella, aunque la causa raíz del problema puede ser, y es comúnmente, una consulta de bajo rendimiento que está consumiendo cantidades excesivas de memoria en el servidor.
  • PAGEIOLATCH_ * se asocian específicamente con los retrasos en la capacidad de leer o escribir datos desde los archivos de base de datos.
  • WriteLog están relacionados con problemas con la escritura en archivos de registro. Estas esperas deben evaluarse conjuntamente con las estadísticas de archivos virtuales, así como los contadores de rendimiento de disco físico, para determinar si el problema es específico de una sola base de datos, archivo o disco, o es ejemplo de ancho.
  • PAGELATCH_ * o Non-I / O espera pestillos de páginas de datos en el grupo de búferes. Muchas veces PAGELATCH_ * esperas están asociados con problemas de contención de la asignación. Uno de los temas más conocidos de las asignaciones asociadas a PAGELATCH_ * espera que ocurra en tempdb cuando se crea y se destruye en el tempdb un gran número de objetos y el sistema experimenta la contención en el Mapa Global Shared Asignación (SGAM), mapa de asignación global (GAM ), y Página espacio libre (PFS) páginas en la base de datos tempdb.
  • LATCH_ * o Estas esperas se asocian con objetos de peso ligero a corto plazo de sincronización que se utilizan para proteger el acceso a las memorias caché internas, pero no el caché del búfer. Estas esperas pueden indicar una serie de problemas, dependiendo del tipo pestillo. La determinación de la clase de enganche específica que tiene el tiempo de espera más acumulado asociado a él se puede encontrar mediante la consulta de los sys.dm_os_latch_stats del DMV.
  • ASYNC_NETWORK_IO o Esta espera es a menudo erróneamente atribuido a un cuello de botella de la red. De hecho, la causa más común de esta espera es que una aplicación cliente está realizando el procesamiento de los datos fila por fila (tipo cursor). Y si bien están siendo transmitidos desde SQL Server como un conjunto de resultados el cliente los procesa fila por fila. La corrección de este tipo de espera generalmente requiere cambiar el código del lado del cliente para que se lea el conjunto de resultados lo más rápido posible, y luego se realiza el procesamiento por el lado del cliente.

 Una vez hecho algún cambio deberé reiniciar los contadodes, y empezar a recopilar las estadísticas de nuevo, para verificar si hubo alguna mejora:

DBCC SQLPERF('sys.dm_os_wait_stats',clear)

Esta primer entrada es el primer paso para determinar obtener una visión generar. En próximas entradas veremos algunas tareas específicas para continuar con la mejora del rendimiento del motor SQL Server.

Como especificar el Puerto en el SQL Server Management Studio

Últimamente por seguridad he estado migrando el puerto default del MS SQL Server de 1433 a otro diferente. Y en consecuencia más de uno me pregunto como usar el IDE de Microsoft para conectarse luego de este cambio. Si quieres saber como cambiar el puerto en el que corre tu motor SQL mirá este post (https://maurobernal.com.ar/blog/mssql/cambiar-el-puerto-del-ms-sql-server)

Aquí te cuento como cambiar el puerto de la conexión.

Si tienen configurado el motor SQL Server en un puerto diferente al predeterminado (1433), para poder realizar una conexión desde el SQL Server Management Studio se debe ingresar de la siguiente manera:

[HOST] , [PUERTO]

Es decir que separamos el mismo con una coma (,).

Ejemplo:

Si llegaste hasta aquí pero no sabes como se puede volver a cambiar el mismo, mirá este post: (https://maurobernal.com.ar/blog/mssql/cambiar-el-puerto-del-ms-sql-server)

Averiguar la intercalación de una base de datos

De la siguiente manera podrán averiguar la intercalación (collation) de una base de datos en MS SQL Server:

TSQL:
SELECT
DATABASEPROPERTYEX(‘MASTER’, ‘Collation’)
as Intercalacion;

SQL Server Management Studio:

Listar Tamaño de las Bases de Datos

El siguiente script en TSQL lista todas las bases de datos con sus respectivos tamaños en Megas y Gigas.

SELECT DB_NAME(db.database_id) DatabaseName,
round((CAST(mfrows.RowSize AS FLOAT)*8)/1024,2) RowSizeMB,
round((CAST(mflog.LogSize AS  FLOAT)*8)/1024,2) LogSizeMB,
round((CAST(mfrows.RowSize AS FLOAT)*8)/1024+(CAST(mflog.LogSize AS FLOAT)*8)/1024,2) DBSizeMB,
round((CAST(mfrows.RowSize AS FLOAT)*8)/1024/1024+(CAST(mflog.LogSize AS FLOAT)*8)/1024/1024,2) DBSizeGB
FROM sys.databases db LEFT JOIN
(SELECT database_id, SUM(size) RowSize FROM sys.master_files WHERE type = 0
  GROUP BY database_id, type) mfrows
ON mfrows.database_id = db.database_id LEFT JOIN
(SELECT database_id, SUM(size) LogSize FROM sys.master_files WHERE type = 1
  GROUP BY database_id, type) mflog
ON mflog.database_id = db.database_id LEFT JOIN
(SELECT database_id,SUM(size) StreamSize FROM sys.master_files WHERE type = 2
 GROUP BY database_id, type) mfstream
ON mfstream.database_id = db.database_id LEFT JOIN
(SELECT database_id, SUM(size) TextIndexSize FROM sys.master_files  WHERE type = 4
  GROUP BY database_id, type) mftext
ON mftext.database_id = db.database_id
ORDER BY 4 DESC

Complementa al siguiente script para listar las bases de datos con su ubicación:
https://maurobernal.com.ar/blog/t-sql/listar-todas-las-bases-de-datos-con-su-respectiva-ubicacion-y-tamanos/

Quitar microsegundos a una fecha en SQL Server

De la siguiente manera podrán quitar (truncar) la fechas para quitarles los microsegundos.

–Como Quedaria sin los microsegundos

SELECT
CampoFecha
,DATEADD(MILLISECOND,
DATEPART(MILLISECOND ,
CampoFecha

)
,
CampoFecha

)
as Resultado From Tabla

 

–Update de la Tabla

update Tabla set
CampoFecha=DATEADD(MILLISECOND,
DATEPART(MILLISECOND ,
CampoFecha

)
,
CampoFecha

)


 

Ultimo dia del Mes con SQL Server y otros

Trabajando con funciones TSQL para realizar cálculos de Fechas

A continuación una serie de funciones en TSQL útiles para el cálculo de fechas:

-->Mes Actual:
-----------------------------------
--Primer día del mes actual
SELECT DATEADD(s,0,DATEADD(mm, DATEDIFF(m,0,GETDATE()),0))
--Último día del mes actual
SELECT DATEADD(s,-1,DATEADD(mm, DATEDIFF(m,0,GETDATE())+1,0))

-->Mes Anterior:
-----------------------------------
--Primer día del mes anterior
SELECT DATEADD(s,0,DATEADD(mm, DATEDIFF(m,0,GETDATE())-1,0))
--Último día del mes anterior
SELECT DATEADD(s,-1,DATEADD(mm, DATEDIFF(m,0,GETDATE()),0))

-->Mes Siguiente:
-----------------------------------
----Primer día del mes siguiente
SELECT DATEADD(s,0,DATEADD(mm, DATEDIFF(m,0,GETDATE())+1,0))
----Último día del mes siguiente
SELECT DATEADD(s,-1,DATEADD(mm, DATEDIFF(m,0,GETDATE())+2,0))


--> Trimestre Actual:
-----------------------------------
----Primer día del trimestre actual
SELECT DATEADD(qq,DATEDIFF(qq,0,GETDATE()),0) 
----Último día del trimestre actual
SELECT DATEADD(qq,DATEDIFF(qq,-1,GETDATE()),-1)

Resultados

Con la fecha 10 de Noviembre del 2017 esto serían los resultados

Primer_Y_Ultimo_Dia_Resultados

 

Otra alternativa

Continuando con el trabajo con fechas con TSQL podemos hacer lo mismo, pero con una función nativa: EOMONTH()

Si les interesa les dejo el link, que incluye como siempre un caso práctico:


Obtener el número de la Semana

Una función muy simple en diferentes lenguajes para obtener el número de la semana.

Obtener el número de semana del año con PERL

my $numeroSemana = POSIX::strftime("%V", gmtime time);

Obtener el número de semana del año con PHP

$numeroSemana = date("W"); 

o date(«W», epoch). Se usa la letra mayúscula ‘W’.

Obtener el número de semana del año con SQL

En MySQL:

 SELECT WEEKOFYEAR(NOW())

 o

 SELECT WEEK(NOW(),3)

 

En MS SQL Server:

SELECT DATEPART( wk, GETDATE() )

Listar todas las bases de datos con su respectiva ubicación y tamaños

Listar todas las bases de datos

Una problemática habitual con la que me enfrentaba en las PCs de desarrollo era que me quedaba sin espacio en los discos por logs inmanejables, y más de una vez olvidar la ubicación de los archivos de las bases en proyectos versionados.

El siguiente script muy simple pero muy útil permite listar las bases, sus respectivos tamaños, archivos que la componen(MDF y LDF). Además es posible agregarle más campos a gusto del lector.( complementa a este script que muestra los tamaños )

select d.database_id,d.name, a.name as filename,a.physical_name as ubication,
 a.type_desc,(a.size/128)as sizeMB, recovery_model_desc,d.state_desc,compatibility_level
from sys.master_files a inner join sys.databases d on (a.database_id = d.database_id)
order by a.type,a.size

Espero que les sea útil, y como siempre cualquier sugerencia será tenida en cuenta..

Hasta la próxima…

 

The version of SQL in use does not support datatype ‘datetime2’

Actualmente estoy trabajando en un proyecto de integrar información de un motor MYSQL 5.0 a MSSQL 2005. Para ello el integrador esta en VB NET 2010 con DotNet 4.0.

El mejor framework para el diagramado y la realización de consultas fue usar LINQ TO ENTITIES.

Luego de un par de dolores de cabeza(*) pude llevar mi primera prueba al servidor de producción.

Al ejecutarlo obtuve mi primer error «The versión of SQL in use does not support datatype ‘datetime2′» .

En este momento recordé que mi servidor de desarrollo era un MSSQL Server 2008, y el de producción un MSSQL 2005. (L)

Antes de poder ponerme a pensar que hacer decidí googlearlo y encontré una solución simple pero efectiva.

Consiste en buscar el .emdx dentro del projecto de Visual Studio. Modificarlo con un editor de XML, o similar. Y buscar el siguiente código.

ProviderManifestToken=«2008« y reemplazarlo por ProviderManifestToken=«2005«

Algo simple pero efectivo… Al final funcionó…

(*) Si al ejecutar su aplicación se cierra sin más aviso, no se olviden de instalar el MYSQL Connector con el que estuvieron trabajando en el servidor de producción.