CXPACKET wait type en SQL Server

Problema
Tenemos un servidor con mas de un CPU y experimentamos altos valores de CXPACKET wait types. Esto ocurre por las queries que se ejecutan en paralelo y el desafío es entender como las diferentes versiones de un query pueden impactar en los valores de los CXPACKET waits. En la nota del link se analizan como cambios en un query pueden impactar en CXPACKET waits.
Solución
El objetivo del tip de la nota enlazada es incrementar la performance del query, disminuir el valor de CXPACKET waits sin reducir MAXDOP.
Veamos la nota original y los ejemplos de como recudir CXPACKET waits.

Link: http://www.mssqltips.com/tip.asp?tip=2027



Hugo Román Bernachea
Mail de contacto: SQLServer777@gmail.com

Microsoft Certified DBA
Microsoft Certified Trainer
Twitter: @bernachea

Read More...

Artículos de Kimball - Datawarehouse

Un seria ultra-interesante de artículos de Kimball, el gurú del Datawarehouse:
http://www.rkimball.com/html/articles.html
http://www.decisionone.co.uk/resources/KimballArticles.htm

Hugo Román Bernachea
Mail de contacto: SQLServer777@gmail.com

Microsoft Certified DBA
Microsoft Certified Trainer
Twitter: @bernachea

Read More...

sp_who2 - Quien, cuando, como?

En este link podemos ver una profunda explicación sobre la historia del sp_who2, desde su origen como sp no documentado hasta el dia de hoy.
En esta profunda nota se pueden ver una clara explicación y un interesante script que se puede agregar a nuestro arsenal de tools administrativas.

http://www.sqlservercentral.com/articles/sp_who2/70222/


Hugo Román Bernachea
Mail de contacto: SQLServer777@gmail.com

Microsoft Certified DBA
Microsoft Certified Trainer
Twitter: @bernachea

Read More...

Información acerca de los reportes scheduleados

Muchas veces tenemos una gran cantidad de reportes programados similares, pero necesitamos obtener info detallada de los mismos.

El siguiente script--->
http://www.sqlexperto.com.ar/index.php?topic=21.0 nos da la forma de obtener la lista de los reportes programados y sus jobs.



Hugo Román Bernachea
Mail de contacto: SQLServer777@gmail.com

Microsoft Certified DBA
Microsoft Certified Trainer
Twitter: @bernachea

Read More...

T-SQL - Gráfica de los distintos tipos de Joins

Yo pienso que esta imagen nos da la respuesta clara y exacta de como funciona cada uno de los joins disponibles en T-S
( click en la imagen para agrandarla)

















Hugo Román Bernachea
Mail de contacto: SQLServer777@gmail.com

Microsoft Certified DBA
Microsoft Certified Trainer
Twitter: @bernachea

Read More...

XQuery - Obtener default namespace de un campo o variable XML

Después de dar unas cuantas vueltas, apremiado para resolver un store procedure que tenía que procesar un campo xml (usando sp_preparedocument y OpenXML) que podía tener distintos namespaces en distintos registros, es que me puse a buscar la forma de recuperar el namespace predeterminado de un xml y encontré que la forma es la siguiente.

Select CampoXML.value('namespace-uri(/*[1])','VARCHAR(100)')
u obviamente
Select @variableXML.value('namespace-uri(/*[1])','VARCHAR(100)')
Esto por ejemplo puede regresar:
urn:proyecto-version-numero-1.1
Otro ejemplo:
SELECT CampoXML.value('local-name(/*[1])', 'varchar(100)'), CampoXML.value('namespace-uri(/*[1])','VARCHAR(100)') from tabla
Donde tenemos que:
local-name devuelve el nombre del elemento raiz
y
namespace-uri devuelve el namespace predeterminado.

Hugo Román Bernachea
Mail de contacto: SQLServer777@gmail.com

Microsoft Certified DBA
Microsoft Certified Trainer
Twitter: @bernachea

Read More...

Traza predeterminada en SQL Server 2005

La traza predeterminada esalgo completamente nuevo que Microsoft implementó para auditar ciertos eventos en el sistema, de los cuales se pueden hacer reportes via Management Reports.

Para verificar que la traza predetermina (default trace) está ejecutándose, ejecute el siguiente query:

select * from sys.configurations where configuration_id = 1568

Si quiere chequear si hay trazas activas corriendo ejecute el siguiente script:

select * from ::fn_trace_getinfo(0)

También puede utilizar fn_trace_getinfo y sp_trace_create para realizar tareas adicionales relativas a trazas.

Si usted no quiere tener corriendo dichas trazas, las puede deshabilitar ejecutando:

sp_configure 'default trace enabled', 0

Debiera deshabilitarlas? Antes de deshabilitarlas por favor observe que eventos están siendo capturados por la traza predeterminada. Si usted abre la traza en el profiler podrá ver exactamente que cosa es capturada.

Aquí tenemos una lista de los eventos capturados por la traza predeterminada:

Database

* Data file auto grow
* Data file auto shrink
* Database mirroring status change
* Log file auto grow
* Log file auto shrink

Errors and Warnings

* Errorlog
* Hash warning
* Missing Column Statistics
* Missing Join Predicate
* Sort Warning

Full-Text

* FT Crawl Aborted
* FT Crawl Started
* FT Crawl Stopped


Objects

* Object Altered
* Object Created
* Object Deleted

Security Audit

* Audit Add DB user event
* Audit Add login to server role event
* Audit Add Member to DB role event
* Audit Add Role event
* Audit Add login event
* Audit Backup/Restore event
* Audit Change Database owner
* Audit DBCC event
* Audit Database Scope GDR event (Grant, Deny, Revoke)
* Audit Login Change Property event
* Audit Login Failed
* Audit Login GDR event
* Audit Schema Object GDR event
* Audit Schema Object Take Ownership
* Audit Server Starts and Stops

Server

* Server Memory Change

Estas trazas parecieran no generar demasiada sobrecarga extra al sistema y proveen de info al administrador en caso de que un incidente ocurriera. Adicionalmente si se deshabilitan las trazas tampoco van a tener disponibles la opción para debugear los stored procedures desde el Management Studio 2005.

Consejo, salvo un requerimiento específico, deje las trazas predeterminadas tal como están.

Hugo Román Bernachea
Mail de contacto: SQLServer777@gmail.com

Microsoft Certified DBA
Microsoft Certified Trainer
Twitter: @bernachea

Read More...

Mejoras en T-SQL de SQL Server 2008 - El type Table para ser usado como parámetro de un Stored Procedure

Siempre existió la necesidad de pasar información en forma batch, esto es, pasar múltiples registros de información a SQL como parámetro de un Stored Procedure, lo cual tendría un rendimiento superior al pasar de una sola vez una gran cantidad de información y no pasar la información con múltiples invocaciones.
En SQL Server 2000 el parche que se usaba para lograr este efecto era pasar un parámetro con datos XML en una variable varchar(8000) para luego leerlo desde el Stored Procedure con OpenXML.
En SQL Server 2005 se incorporó el tipo de datos xml que facilitó este manejo, ya que por un lado permitía enviar mayor cantidad de información a los 8000 bytes y por el otro habilitaba el manejo de xquery además del OpenXML para leer el parámetro de tipo XML nativo.
Pero en SQL Server 2008 esto todavía se logra de una manera todavía mas sencilla utilizando parámetros de tipo Table.

Un ejemplo vale mas que mil palabras y para empezar a demostrar la nueva característica vamos a crear una base de datos de ejemplo:
CREATE DATABASE [Ejemplo]

Ahora vamos a crear un tabla llamada Clientes que utilizaremos para este ejemplo.
use Ejemplo
go
CREATE TABLE [Clientes]
(
[ID] [int] NOT NULL PRIMARY KEY IDENTITY,
[Nombre] [varchar](100)NOT NULL,
[Apellido] [varchar](100)NOT NULL,
[Email] [varchar](200) NOT NULL
)
GO
--ingresamos algunos registros en la tabla Clientes
INSERT INTO [Clientes] (nombre, apellido, Email)
VALUES('aaa','XYZ', 'aaa@ejemplo.com')
INSERT INTO [Clientes] (nombre, apellido, Email)
VALUES('bbb','XYZ', 'bbb@ejemplo.com')
INSERT INTO [Clientes] (nombre, apellido, Email)
VALUES('ccc','XYZ', 'ccc@ejemplo.com')
GO

podemos probar los datos ingresados con:
SELECT * FROM Clientes

y debieran aparecer los tres registros previamente cargados.

Ahora creamos el tipo de datos (type) de tipo Table:
CREATE TYPE [ClientesUDT] AS TABLE
(
nombre varchar(100) NOT NULL,
apellido varchar(100) NOT NULL,
Email varchar(200) NOT NULL
)
GO
Con cualquiera de las dos sentencias siguientes pueden verificar la creación del tipo:
SELECT name, system_type_id, user_type_id, is_assembly_type, is_table_type
FROM SYS.TYPES WHERE is_table_type = 1
SELECT name, system_type_id, user_type_id, is_assembly_type, is_table_type
FROM SYS.TABLE_TYPES

Obviamente también pueden usar el Management Studio para verificar en forma visual la existencia del nuevo type.

Hecho todo lo anterior, ahora vamos directamente al punto clave de toda esta innovación y vamos a crear un Stored Procedure utilizando un parámetro de tipo Table:
use Ejemplo
GO
CREATE PROCEDURE dbo.AgregaClientes
@ClientesTVP ClientesUDT READONLY --observese que tiene que ser readonly
AS
BEGIN
INSERT INTO dbo.Clientes
SELECT * FROM @ClientesTVP
END
GO

Ahora vamos a probar si todo funciona ok:
/*
** defino una variable de tipo el udf de tipo table previamente creado
*/
DECLARE @ColeccionClientes ClientesUDT
--ingreso algunos datos
INSERT INTO @ColeccionClientes (nombre, apellido, Email)
VALUES('ddd','XYZ', 'ddd@ejemplos.com')
INSERT INTO @ColeccionClientes (nombre, apellido, Email)
VALUES('eee','XYZ', 'eee@ejemplos.com')
INSERT INTO @ColeccionClientes (nombre, apellido, Email)
VALUES('fff','XYZ', 'fff@ejemplos.com')

EXEC AgregaClientes @ColeccionClientes
select * from clientes
GO

Y de esta manera hemos pasado en un solo parámetro varios registros de una sola vez, con todo lo que eso implica a nivel rendimiento y sencillez.

Invocando el Stored Procedure desde .NET 3.5
En la siguiente página se indica detalladamente como invocar el Stored Procedure de este artículo desde un aplicativo .NET 3.5
http://logicanet.blogspot.com/2009/08/usando-el-nuevo-tipo.html

Hugo Román Bernachea
Mail de contacto: SQLServer777@gmail.com

Microsoft Certified DBA
Microsoft Certified Trainer
Twitter: @bernachea


Read More...