Administracion Sql Server

Cómo generar sentencias SQL de administración para eliminar tablas y vistas

Carlos — Sat, 13 Feb 2021 19:05:34 +0000

Cómo generar sentencias SQL de administración para eliminar tablas y vistas Carlos 13 Febrero, 2021 - 20:05

Construcción automatizada de sentencias SQL

Los metadatos que guardan las bases de datos sobre la estructura de sus objetos son muy útiles para realizar tareas que requieran hacer algo sobre todos los objetos de un esquema, de una base de datos, de un tipo determinado, con un patrón en el nombre del objeto, etc.

En SQL Server, con las vistas que la base de datos nos da sobre el catálogo podemos consultar, entre otras muchas cosas, los nombres de objetos de las bases de datos como tablas o vistas.

Si lo que queremos hacer es eliminar todas las tablas y vistas de un determinado esquema de una base de datos 'DBName', por ejemplo, conectados a DBName o incluyendo el nombre de la base de datos en la consulta, podemos consultar en las vistas de sistema de SYS.OBJECTS y SYS.SCHEMA de objetos y esquemas, respectivamente, para construir nuestras sentencias de DROP Table en un segundo.

Consulta de ejemplo para generar DROPS de las tablas y vistas de dos esquemas

select 'DROP ' 
       + CASE type WHEN 'U' THEN 'Table' WHEN 'V' THEN 'View' END 
       + ' [' + sc.name + '].[' + ob.name + '];' 
from DBName.sys.objects OB
join DBName.sys.schemas SC on OB.schema_id=SC.schema_id
where sc.name in ('dbo','USER')
and ob.type in ('U','V')
order by ob.type, ob.name

Esta sentencia nos devuelve montadas las consultas para todas las tablas y vistas que contengan los esquemas incluídos en el IN, en este caso 'dbo' y 'User', de la base de datos con mobre 'DBName'.

Después sólo es cuestión de copiar las queries generadas, revisarlas, sobretodo teniendo en cuenta que son DROPs, e incluirlas en nuestro script, o ejecutarlas directamente desde el SSMS, por ejemplo.

Tabla de codificación para tipos de objeto de SYS.OBJECTS

Como ayuda, esta es la codificación de los tipos de objetos que podemos encontrarnos en la vista sys.objects, en el campo 'type'. En nuestro caso hemos filtrado por 'Tablas de usuario' y 'Vistas' con 'U' y 'V'.

**Tabla de codificación para tipos de objeto de SYS.OBJECTS de SQL Server**
Tipo de objeto: AF = Función de agregado (CLR) C = restricción CHECK D = DEFAULT (restricción o independiente) F = Restricción FOREIGN KEY FN = Función escalar de SQL FS = Función escalar del ensamblado (CLR) FT = Función con valores de tabla de ensamblado (CLR) IF = Función SQL insertada con valores de tabla IT = tabla interna P = Procedimiento almacenado de SQL PC = Procedimiento almacenado del ensamblado (CLR) PG = Guía de plan PK = Restricción PRIMARY KEY R = Regla (estilo antiguo, independiente) RF = Procedimiento de filtro de replicación S = Tabla base del sistema SN = Sinónimo SO = Objeto de secuencia U = Tabla (definida por el usuario) V = Vista EC = restricción perimetral Válido para : SQL Server 2012 (11.x) y versiones posteriores. SQ = Cola de servicio TA = Desencadenador DML del ensamblado (CLR) TF = Función con valores de tabla SQL TR = Desencadenador DML de SQL TT = Tipo de tabla UQ = Restricción UNIQUE X = Procedimiento almacenado extendido Se aplica a: SQL Server 2016 (13.x) y versiones posteriores, Azure SQL Database , Azure Synapse Analytics (SQL Data Warehouse) , Almacenamiento de datos paralelos . ET = tabla externa

Una alternativa, generar SQL con INFORMATION_SCHEMA

Utilizando las vistas de INFORMATION_SCHEMA se podría conseguir lo mismo y con una consulta más sencilla, pero mejor ir acostumbrándose a las vistas de sys, que son las más fiables, y las que parece que van a quedarse a la larga.

Ejemplo para crear DROP de tablas dinámico con INFORMATION_SCHEMA

SELECT
  'DROP ' + right(table_type,5) + ' [' + TABLE_SCHEMA + '].[' + TABLE_NAME + '];'
FROM
 DBName.INFORMATION_SCHEMA.TABLES
where table_schema not in ('dbo','USER')
order by table_schema, table_type, table_name

Las vistas del catálogo te pueden ahorrar mucho tiempo

Esta es una aplicación típica que pongo como ejemplo, pero utilizar las vistas del catálogo para generar consultas dinámicamente nos puede ahorrar un montón de tiempo y asegurarnos de que no nos dejamos nada en muchas tareas de administración de la base de datos que requieran consultar o realizar acciones sobre grupos de objetos.

Por último, en el post de Consultas Útiles para SQL Server hay otras consultas sobre el catálogo, que combinadas con esta manera de generar queries de administración pueden ahorrar mucho trabajo y facilitar la administración o el desarrollo con SQL Server.

Plataforma de datos

Administracion Sql Server

SQL Server

DBA

DML

SQL Server 2016, novedades

il_masacratore — Fri, 15 May 2015 15:33:17 +0000

SQL Server 2016, novedades

Plataforma de datos

il_masacratore 15 May, 2015 - 17:33

La próxima versión de Microsoft SQL Server 2016 parece que se va a poder ver ya este verano, primeramente en formato preview. Con el cambio de versión se incluyen como siempre nuevas características entre las que destacan mejoras relacionadas con su integración con Microsoft Azure, integración con el lenguaje de programación estadístico R y alguna cosa más en cuanto a mejoras de rendimiento. A continuación una breve reseña:

Always Encripted
Nuevo método de protección para mejorar la seguridad de los datos tanto cuando están almacenados como cuando están en tránsito. Con Always Encripted se harán ciertas operaciones sobre la información encriptada o en el peor de los casos usando una clave de encriptación que se almacena en la aplicación cliente. Es algo totalmente orientado a Azure y para evitar miradas indiscretas sobre nuestra información.
Strech Database
Relacionado también con Microsoft Azure, Strech Database nace para flexibilizar el almacenado de la información menos "caliente" y de alguna manera poder reducir su consumo de recursos (su almacenamiento?) y priorizarlos para invertirlos en el trato y explotación de la información de uso mas recurrente. En pocas palabras, permite almacenar la información localmente y en Azure a la vez.
Real-time Operational Analitycs & In-Memory OLTP
Siguiendo la misma linea, mejoran el rendimiento de la base de datos en memoria introducida en SQL Server 2014. Si ya ofrecía más velocidad respecto a la base de datos tradicional almacenada en disco, ahora prometen más integración y mayor concurrencia.
Integración con lenguage de programación R, Polybase y Mobile BI
Provenientes de nuevas integraciones provenientes de compras de otras empresas o tecnologías, se incluye la posibilidad de uso de R, que es un lenguaje de programación usado para análisis estadístico, y Polybase para manipular información estructurada y no estructurada. También se comenta mejoras en el uso de dispositivos móviles*

*Tanto la integración con el lenguage R, como la explotación de dispositivos móviles parten de la adquisición Revolution Analytics y de DataZen respectivamente

Soporte para JSON
Añaden soporte para JSON, como ya hicieron en su dia para XML, para facilitar el desarrollo de servicios web.
AlwaysOn
Se incluyen mejoras en el sistema de entornos clusterizados AlwaysOn tanto a nivel de robustez como de recuperación de desastres y backups híbridos más rápidos. Se permiten réplicas síncronas múltiples y balanceado de carga secundario, para conseguir mayor disponibilidad y recuperación ante desastres.
Analysis Services
Aunque quizás menos visibles, también incluirán mejoras en rendimiento, usabilidad y escalabilidad tanto en SQL Server Enterprise Information Management como en Analysis Services.

En esta página de Microsoft Technet os podéis registrar para participar en la preview y poder recibir notificaciones sobre las novedades del asunto: https://www.microsoft.com/en-us/server-cloud/products/sql-server-2016/?WT.mc_id=Blog_SQL_Announce_DI

SQL Server 2016

SQL Server

Administracion Sql Server

Muy interesante el artículo!

Subido por solnet manteni… (no verificado) el 25 May, 2015 - 18:40

Muy interesante el artículo!

ShrinkDatabase de SQL Server puede producir fragmentación y problemas de rendimiento

Carlos — Mon, 24 Nov 2014 12:35:19 +0000

ShrinkDatabase de SQL Server puede producir fragmentación y problemas de rendimiento

Plataforma de datos

Carlos 24 Noviembre, 2014 - 13:35

En SQL Server se puede utilizar el comando de DBCC SHRINKDATABASE para reducir el espacio ocupado por los archivos de datos y de log de una base de datos.

El problema que tiene SHRINKDATABASE es que, al contrario de lo que pueda parecer, si no se utiliza con cuidado, el resultado puede ser un importante incremento en la fragmentación de los índices, y también de las tablas, lo cual deriva en un empeoramiento del rendimiento de nuestra base de datos SQL Server, e incluso un aumento del espacio ocupado cuando se reconstruyan los índices afectados por la fragmentación.

Qué hace el comando DBCC ShrinkDatabase

El comando SHRINK libera el espacio libre que queda en los archivos de la base de datos, haciendo que en lugar de quedar reservado para el crecimiento de los datos, se 'devuelva' al sistema operativo. La reducción de espacio se produce, pero hay que pensar en el crecimiento de la base de datos. Si no se deja espacio libre contiguo al que utiliza cada tabla, los nuevos datos se crearán en diferentes ubicaciones físicas, se aumentará la fragmentación, y se complicarán los índices y las ordenaciones.

Incluir SHRINKDATABASE entre las operaciones diarias de mantenimiento de una BD SQLServer, por ejemplo, puede provocar un importante problema de fragmentación, ya que los datos que se insertaran podrían quedar almacenados en una ubicación física diferente para cada nuevo día después la ejecución del SHRINK.

Cuando y cómo hay que utilizar Shrink en SQL Server

¿Pero entonces, SHRINK DATABASE sirve para algo? Claro que sirve, en determinados casos. Si en una base de datos SQL Server se eliminan o se truncan tablas, que reducen considerablemente el volumen ocupado por los datos, y no hay previsión de volver a ocupar ese espacio, puede interesar utilizarlo para ajustar mejor la relación entre espacio ocupado y espacio reservado, reduciendo así el tamaño de la base de datos, pero siempre es recomendable dejar un porcentaje de espacio libre reservado tanto para las operaciones diarias de la base de datos como para el crecimiento de los datos con la mínima fragmentación.

En caso de utilizar el Shrink de SQLServer, para asegurar ese espacio reservado y que el crecimiento no cree problemas de fragmentación y rendimiento, es importante revisar los argumentos que admite el comando, ya que si se informa el segundo argumento con un número la reducción de espacio se realizará dejando ese número como porcentaje de espacio no utilizado que no se devolverá al sistema operativo.

Sintaxis del comando

DBCC SHRINKDATABASE  
( database_name | database_id | 0      
          [ , target_percent ]      
          [ , { NOTRUNCATE | TRUNCATEONLY } ]  
)  
[ WITH NO_INFOMSGS ]

Ejemplo de utilización de Shrink

Por ejemplo, si acabamos de realizar operaciones de limpieza (eliminar esquemas no utilizados, tablas temporales o simplemente innecesarias) en nuestra base de datos que sabemos que han reducido el espacio ocupado por los datos en un 50%, y queremos reducir el espacio ocupado por los ficheros de la base de datos, pero dejando reservado un 15% de espacio libre para las operaciones diarias, y para el crecimiento que preveemos de la base de datos para el año actual, podríamos ejecutar este comando:

DBCC SHRINKDATABASE (Mi_base_de_datos, 15);

De esta manera el espacio ocupado por los ficheros de datos y de registro de la base de datos se reduciría aproximadamente en un 35%. Si no incluyéramos el parámetro del porcentaje, reduciríamos más el espacio, pero al día siguiente las nuevas inserciones de datos ya comenzarían a necesitar ampliaciones de tamaño de los ficheros que obviamente no se encontrarían en el mismo espacio físico que los datos existentes, y aumentarían la fragmentación de los datos.

Recomendación para reducir la fragmentación

Y ya que hablamos de fragmentación, lo que sí es recomendable incluir en las tareas de mantenimiento periódicas es una reconstrucción de los índices con un REBUILD, cosa que reducirá la fragmentación y mejorará el rendimiento de la DB, aunque pueda incrementar un poco más el espacio utilizado:

ALTER INDEX idx_mitabla_ID ON MiTabla REBUILD;

Referencias

Finalmente, enlazo como referencia algunas entradas de blog de otros sitios que explican porqué hacer un Shrink Database normalmente no es buena idea, aportan razones para no utilizar un ShrinkDatabase, o que hacen una demostración práctica de lo que pasa con el espacio y la fragmentación al hacer un ShrinkDatabase

¿Conoces algún caso más en el que sea o no recomendable hacer un Shrink? ¿Te has encontrado en alguna ocasión un problema de fragmentación o de rendimiento provocado por una desafortunada utilización de ShrinkDatabase?

Administracion Sql Server

SSAS: Como monitorizar el procesamiento de cubos en Analysis Services

il_masacratore — Mon, 17 Feb 2014 17:23:50 +0000

SSAS: Como monitorizar el procesamiento de cubos en Analysis Services

Plataforma de datos

il_masacratore 17 Febrero, 2014 - 18:23

Existen algunos tips que permiten mejorar el rendimiento y reducir el tiempo de procesado en nuestras bases de datos de Analysis Services. Hay unas cuantas páginas dedicadas a ello y resúmenes por ahí que marcan unas líneas a seguir (y otras que no!). En este post nombro un ejemplo y de que manera podemos medir esa posible mejora de forma objetiva basándonos en el uso de los contadores de rendimiento del sistema y de Sql Server Profiler.

Ejemplo de mejora: Evitar tablas de hechos con demasiados campos.

Imaginaros la tabla de hechos con las cabeceras de venta. Si esta tabla tiene 100 campos y solo necesitamos 10, el número de registros contenidos en cada página de 8k de datos será mucho menor que si solo se almacenaran los campos sensibles. ¿Como podemos mejorar este aspecto?

Partición vertical de la tabla en dos diferentes. Si tenemos la posibilidad estaría bien poder hacer una partición vertical y aislar esos 10 campos que necesitamos para dejar el resto en una tabla adicional. Sin tener en cuenta el tamaño de los campos, podríamos reducir el número de páginas de datos a recorrer en un 10%. Aunque esto es lo ideal, no siempre es posible.
Tabla derivada. En la linea de lo anterior, podríamos mantener una tabla derivada sobre la que procesar los hechos.
Crear una Vista indizada. Con la vista hacemos la partición pero restringimos de alguna manera la tabla original e incluso podríamos ralentizar un poco la inserción de datos si es una tabla transaccional muy concurrida. No es mala opción pero hay que medir las ventajas y los inconvenientes.

Medir el procesamiento con los contadores de rendimiento de Windows Server

La idea es trabajar sobre una linea base, una foto inicial de como está todo y después de cada cambio realizar otra monitorización para comparar las diferencias y poder medir bien que hemos cambiado y donde está la mejora o el empeoramiento. Al igual que con el motor de base de datos de Microsoft SQL Server, para monitorizar el procesado de cubos podemos usar el monitor de rendimiento del sistema para consultar los contadores de rendimiento propios de Analysis Services. En este otro post explico como se hace para la base de datos. Para la parte de Analysis Services, algunos contadores que podemos usar los siguientes:

MSOLAP: Processing
Rows read/sec:
Registros que se leen por segundo en el procesado.

MSOLAP: Proc Aggregations
Temp File Bytes Writes/sec: Ratio por segundo de escrituras en los ficheros temporales. Esto ocurre cuando se excede el límite de memoria. Cuanto más tienda a cero mejor.
Rows created/Sec : Ratio por segundo de creación por segundo. Cuanto más elevado mejor.
Current Partitions : Particiones procesadas actualmente. No sirve más que para controlar que estamos procesando y que los contadores no estén "contaminados" (por ejemplo si es mayor que 1 y no queremos procesado paralelo).
MSOLAP: Threads
Processing pool idle threads : Puede variar según la versión, en la 2012 se separan los hilos de procesado de los de E/S. Sirve para monitorizar el paralelismo de tareas.
Processing pool job queue length : Puede variar según la versión, en la 2012 se separan los hilos de procesado de los de E/S. Sirve para monitorizar el paralelismo de tareas.
Processing pool busy threads : Puede variar según la versión, en la 2012 se separan los hilos de procesado de los de E/S. Sirve para monitorizar el paralelismo de tareas.
MSSQL: Memory Manager
Total Server Memory : Total de memoria que está usando actualmente el motor relacional de la base de datos.
Target Server Memory : Total de memoria CONFIGURADO que debería usar el motor de base datos. Si el contador anterior es inferior a este hay algún problema y alguien se está comiendo memoria que teóricamente hemos asignado a la base de datos.
Logical Disk
Avg. Disk sec/Transfer – All Instances
Processor:
% Processor Time – Total : % CPU consumida actualmente.
System:
Context Switches / sec : Cambios de tarea en la cola de la cpu. Un valor bajo que tiende a 0 puede significar que algo está monopolizando el 100% de la cpu.

Controlar el uso del motor de base de datos relacional

Como complemento a lo que comento en el apartado anterior, también deberíamos analizar como van las consultas SQL que tiramos sobre la base de datos relacional. Podemos complementar lo anterior con la captura de actividad desde Sql Server Profiler. Como plantilla podemos usar la de Tunning y le añadimos estos dos eventos:

Performance/Showplan XML Statistics Profile
TSQL/SQL:BatchCompleted

De ellos necesitamos las columnas TextData, Reads, DatabaseName, SPID y Duration. Con ellos podemos detectar cuales son las consultas que más se demoran, podemos ver su plan de ejecución y mirar los índices que pueden mejorar los tiempos en la recuperación de los datos.

En cuanto a la captura con SQL Server Profiler, es bueno saber que podemos filtrar eventos para solo mostrar lo imprescindible. En este otro post explico como funciona la captura y como filtrar para afinar la captura.

En conclusión...

... creo que conocer la manera de monitorizar el procesado de nuestros cubos nos permite ver que podemos mejorar, ya sea algo del diseño o maneras de hacer las cosas. Como comento arriba para poder empezar deberíamos comenzar con una captura inicial y tras cada posible mejora deberíamos volver a monitorizar para cuantificar la mejora. Pienso que la mayoría de contadores pueden ser evolutivos (los comparamos con anteriores) y creo que no hay un rango definido. Simplemente sabiendo lo que miden y con un poco de lógica sabremos cuando va a mejor o a peor (el contador). El único problema que podemos tener en todo esto es que podamos hacerlo de forma proactiva, el lugar de forma reactiva cuando se nos solape con otros procesos... y entonces tengamos un problema.

SSAS

monitorizar

Administracion Sql Server

SQL Server: Vistas indizadas y el porqué de usarlas para cargas de dwh

il_masacratore — Tue, 11 Feb 2014 11:17:21 +0000

SQL Server: Vistas indizadas y el porqué de usarlas para cargas de dwh

Plataforma de datos

il_masacratore 11 Febrero, 2014 - 12:17

Las vistas pueden ser una herramienta perfecta para simplificar consultas que unen distintas tablas, permiten abstenerse de la estructura origen y simplificar si hace falta la estructura saliente. También nos pueden servir como un mecanismo de seguridad que limitará el acceso de los usuarios a datos no deseados de las tablas base. Con MS SQL Server, Microsoft ha ido un paso más allá y permite crear un nuevo tipo de vistas llamado vista indizada.

Que son las vistas indizadas?

Las vistas de toda la vida, las podemos ver como si fueran una tabla pero realmente no existe. Una vista estandar no está almacenada en la base de datos, en lugar de eso los datos que se devuelven se recuperan de forma dinámica en el momento de la petición (la consulta SQL sobre la vista). Una vista indizada se diferencia de una normal basicamente en que sobre la primera creamos un índice (el primero clusterizado). En el momento en que lo hacemos estamos persistiendo en la base de datos una referencia que abre la veda a posibles optimizaciones que no se pueden hacer con una vista simple. También es cierto que si nos hace falta y realmente nos aporta algo también es posible es crear más de un indice ( a partir del segundo ya no pueden ser clústerizados, crear uno clústerizado es obligado).

Una de los beneficios que también da la vista indizada es que aporta una nueva perspectiva en el momento del cálculo para el plan de ejecución de una SELECT sobre las tablas que implica. El optimizador de consultas puede seleccionar la vista si determina que ésta puede sustituirse por parte o por toda la consulta del plan de consultas si es de un coste menor. En el segundo caso, la vista indizada se utiliza en lugar de las tablas subyacentes y sus índices. No es necesario hacer referencia a la vista en la consulta para que el optimizador de consultas la utilice durante la ejecución. Esto incluso permite que las aplicaciones existentes se beneficien de las vistas indizadas recién creadas sin cambiar directamente código en dichas aplicaciones.

Donde usarlas y como crearlas

Las vistas indizadas aportan un beneficio aunque también un coste. Puede tener el mismo “defecto” que puede producir la indexación masiva de una tabla transaccional con inserciones/modificaciones masivas. Debemos evaluar siempre el beneficio en base al coste que suponga. Realmente con las vistas indizadas (clusterizada o no) seguro que notaremos una mejora si las usamos en datawarehouses, data marts, bases de datos OLAP, en procesos de minería de datos y similares. En estos escenarios son candidatas las consultas gigantes sobre diferentes tablas, con particiones verticales u horizontales, agregaciones y sin pensarlo demasiado, las particiones de tablas de hechos. Un ejemplo que se me ocurre es el del diagrama en estrella del datamarts de ventas donde podemos tener cabeceras de venta en una tabla y el detalle en otra. Seria normal en casos como estos haber creado particiones en el grupo de medidas y hacer la separación por las fechas de venta que estan en la cabecera.

Una de los requisitos para poder indizar una vista es que tenemos que crear la vista con la opción WITH SCHEMABINDING. Esta opción tiene su lado positivo, si el propietario de cualquiera de las tablas incluidas en la select intenta hacer un cambio en la estructura no podrá. Esto es fantástico porque nos protege de cualquier cambio a traición de las tablas.

Pongo aquí un ejemplo básico. Creamos primero la tabla y la vista con la selección de los campos que nos interesan.

CREATE TABLE Articulos (
IdArticulo INT PRIMARY KEY,
Descripcion VARCHAR(20),
Stock INT)
GO

CREATE VIEW ArticulosView WITH SCHEMABINDING AS
SELECT IdArticulo, Stock
FROM dbo.Articulos
WHERE Stock > 0
GO

CREATE UNIQUE CLUSTERED INDEX idx_ArticulosView ON ArticulosView(Stock)

Una vez hemos creado el índice, los datos de la vista están almacenados en la base de datos como cualquier otro índice clusterizado sobre una tabla. Cualquier consulta sobre la vista ya puede usar el índice para el cálculo del plan de ejecución. Consultas que tengan un predicado similar ya podran beneficiarse del indice por rango. Por ejemplo:

SELECT IdArticulo, Stock
FROM Articulos
WHERE Stock > 0

Incluso en este caso y aunque no hagamos la consulta sobre la vista, el optimizador de consultas puede tener en cuenta el indice clusterizado de la vista para obtener los datos con un mejor rendimiento que si lo hiciera con los indices de la tabla base.

Otro ejemplo con más sentido donde se usa el indice clusterizado de la vista en lugar del de la tabla. Nos imaginamos que queremos hacer una partición vertical de una tabla con mucho campos (wide_tbl) que podría ser la tabla de cabeceras o lineas de venta de nuestro erp desde el que sacamos directamente la información que nos interesa de la parte de ventas:

– Creación de la tabla base
CREATE TABLE wide_tbl(
a int PRIMARY KEY, b int, c int, d int, e int, f int, g int, h int, i int,
j int, k int, l int, m int, n int, o int, p int, q int, r int,s int,t int, u int, v int, w int, z int)
GO

– Vista sobre la tabla base donde hacemos partición vertical (nos quedamos solo con lo que nos interesa)
CREATE VIEW v_abc WITH SCHEMABINDING AS
SELECT a, b, c
FROM dbo.wide_tbl
WHERE a BETWEEN 0 AND 1000
GO
CREATE UNIQUE CLUSTERED INDEX i_abc ON v_abc(a)
GO

La select es la siguiente. Si miramos el plan de ejecución estimado ya vemos que está usando efectivamente el índice de la vista aunque seleccionemos datos de la tabla.

SELECT b, count_big(*), SUM(c)
FROM wide_tbl
WHERE a BETWEEN 0 AND 1000
GROUP BY b

A tener en cuenta cuando creamos indices sobre vistas

Ademas de incluirse la clausula WITH SCHEMABINDING que nos prohibe la modificación de la estructura o eliminación de las tablas bases incluidas en la vista, debemos pensar o tener en cuenta que:

La vista debe ser determinista. Es decir, siempre debe devolver el mismo resultado para el mismo input. No se pueden incluir por ejemplo funciones como GETDATE que devuelven valores distintos para diferentes llamadas con el mismo argumento.
WITH SCHEMABINDING, con sus cosas buenas y sus cosas malas.
En la definición de la vista se debe hacer referencia a nombre completo la tabla (schema.tabla). Lo mismo con las funciones de usuario.
Espacio en disco. Debemos recordar que los indices que creemos ocuparan el mismo espacio en disco que cualquier otro sobre una tabla.
A diferencia de Oracle, donde un equivalente podría ser una vista materializada, no se necesita ningún permiso concreto para este tipo de vista. Basta con tener permisos CREATE VIEW y ALTER en el schema donde se crea la vista.

En Conclusión...

... las vistas indizadas pueden ofrecer grandes mejoras de rendimiento pero siempre en los entornos adecuados. Debemos evitarlas en entornos transaccionales con mucha carga transaccional y dejarlas más para otros entornos más de consulta/actualización como puede ser las tablas sobres las que procesamos nuestros cubos del datawarehouse. También es cierto que una alternativa funcional a una vista indizada es un COVER INDEX que incluya las columnas que nos interesen.

Administracion Sql Server

Gracias, desde Chile!

Subido por Anonimo (no verificado) el 18 May, 2017 - 15:51

Gracias, desde Chile!

Que tiene y como instalar SQL Server Express 2012

il_masacratore — Thu, 06 Feb 2014 08:01:41 +0000

Que tiene y como instalar SQL Server Express 2012

Plataforma de datos

il_masacratore 6 Febrero, 2014 - 09:01

Para quién no lo sepa, SQL Server Express es una edición gratuita en miniatura de Sql Server. Esta versión está pensada para aplicaciones de escritorio y/o pequeñas aplicaciones web o de servidor. Esta base de datos se puede considerar la versión competidora a la versión gratuita de Oracle (Oracle XE). Ambas versiones están siempre al día y se han ido actualizando con el paso de los años y versiones. De hecho, el lanzamiento de la primera versión Express fue con la versión de SQL Server 2005.

Si es gratis, ¿Donde está el truco en SQL Server Express?

Pues que básicamente solo contamos con el motor de base de datos y poco más. Generalizando, el truco está en que este tipo de versiones, tanto la de Oracle como la de SQLServer, cuentan con cierto tipo de limitaciones, la mayoría ligadas a la capacidad de procesamiento o otras más ligadas al mundo empresarial como podría ser Analisys Services. En el caso de SQL server Express 2012, las principales limitaciones son:

El volumen máximo de la base de datos está limitado a 10Gb con la versión 2012
Límite de 1 socket o 4 núcleos para el procesamiento de la base de datos.
El máximo de memoria que usará la instancia será de 1gb.

A efectos prácticos, estas tres no son impeditivas y nos pueden permitir usar esta base de datos en pequeñas aplicaciones de escritorio como pueden ser puntos de venta etc. Luego existen otro tipos de limitaciones que está bien saberlas (para características compatibles, las que no tiene ni las menciono):

Puede activarse como base de datos espejo (mirroring), aunque solo como testigo.
Puede ser suscriptora en un servicio de replicación.
Incluye también los servicios de Búsqueda de Texto (fulltext search).
Permite almacenamiento FILESTREAM.

A partir de la versión 2008 de SQL Server Express, se ha complementado la propia base de datos con el servicio de informes de Reporting Services. Es la versión conocida como "SQL Server Express con Servicios Avanzados". Esta está muy bien. En el ejemplo anterior, el del punto de venta, podemos agilizar mucho el desarrollo e implantación de informes para la aplicación.

Por último, con la versión 2012 podemos usar la característica LocalDb. Esta es una nueva opción que permite simplificar mucho el despliegue y que se instala de realmente rápido. Incluso permite embeber la base de datos en la aplicación que la contiene y estar funcionando en el mismo proceso de la aplicación en lugar de como servicio.

Cómo instalar SQLServer Express 2012

Para empezar nos vamos a la página del producto y descargamos el instalador. Cuando hagamos click deberemos elegir el tipo de instalador (a elegir de entre cinco tipos distintos!):

SQL Server Express con Herramientas (con LocalDb, incluye el motor de base de datos y SQL Server Management Studio Express)
SQL Server Management Studio (solo herramientas)
SQL Server Express LocalDb (instalador MSI)
SQL Server Express con Servicios Avanzados
SQL Server Express (solo motor de base de datos).

De los anteriores, que ya vienen con su propia descripción solo destacaría el paquete MSI de SQL Server Express LocalDb para el ejemplo del punto de venta. El paquete MSI es justo lo necesario para incrustar el instalador de la parte de la base de datos en el instalador de la aplicación que la va a usar. Como he comentado antes, la otra descarga destacable es SQL SERVER Express con Servicios Avanzados que es la que lleva Reporting Services.

El paso siguiente es lanzar el instalador par llegar al Centro de instalación de SQL Server.

Continuamos con un par de siguientes, siguiente para buscar actualizaciones. A continuación se copian los archivos del programa de instalación, se comprueban las reglas auxiliares y ya pasamos a elegir las características a instalar. Pulsamos siguiente y se empiezan a copiar los archivos.

Como requisitos previos, se necesita .NET Framework 3.5 Service Pack 1 y poder acceder al centro de descargas para poder actualizar con la versión 4.0. Esto podemos creer que lo podemos evitar desencargando de antemano y sobretodo tenemos que tener en cuenta que necesitaremos también el paquete redristibuible para una posible instalación de localdb(la versión embebida). Pero no es el caso. La comprobación siempre se hace aun con la versión 4.0 ya instalada.

El paso siguiente a la elección de las características es la configuración de la instancia. Debemos especificar el nombre y directorio raíz.

Seguimos con la configuración de las cuentas que ejecutaran los distintos servicios incluidos (el motor del sgbd, reporting services y sql server browser). Recordar que Sql Server Browser es como un "agente" que publica en la red la existencia de la instancia de SQL Server. Por defecto viene deshabilitado y si no es por causa mayor mejor dejarlo así.

El siguiente paso es elegir el modo de autenticación y los administradores de la base de datos. Generalmente nos conviene elegir mixto si esta base de datos se necesita usar en la red local o autenticación de windows si directamente es de uso local y no queremos complicarnos. A diferencia de una versión superior o completa del producto, como esta versión express suele acompañar a una aplicación y es de uso local, elegiremos modo de autenticación de windows y como administrador el usuario actual.

Uno de los últimos pasos será la configuración de Reporting Services. Para esta instalación simple basta con dejar la primera opción seleccionada, la que permite usarlo en modo nativo SIN integración con sharepoint services.

Un siguiente más para la privacidad y la notificación de errores a Microsoft y ya lo tenemos instalado. Esperamos una pantalla como la siguiente:

Finalmente reiniciamos y ya tenemos instalada la versión express de sqlserver 2012 con servicios avanzados. Si hiciera falta modificar en un futuro cualquier configuración podemos cambiar las opciones generales si vamos al Menú Inicio> SQL Server 2012>Herramientas de Configuración>Administración de configuración de SQL SERVER. En la misma carpeta del menú inicio también podemos cambiar cualquier cosa relativa a Reporting Services si elegimos Administración de configuración de Reporting Services.

Resumiendo...

Microsoft SQL Server express es una buena opción como base de datos embebida, más sencilla que su versión de Oracle equivalente y con más posibilidades en cuanto a uso. En contraposción, no hay quien gane en simplicidad a Mysql. En global SQL Server Express es una muy buena opción para desarrollos .net y pequeñas bases de datos que incluso puedan necesitar algún informe. Desde que le acompaña Reporting Services la hace más atractiva.

SQL Server 2012

SQL Server

Administracion Sql Server

Como se agrega Analisis

Subido por Assiel (no verificado) el 29 Septiembre, 2016 - 00:52

Como se agrega Analisis services despues de Instalar la version Express

Con la versión Express puedes

Subido por Carlos el 29 Septiembre, 2016 - 16:11

Con la versión Express puedes agregar y utilizar SQL Express Advanced Services, que te permite utilizar Reporting Services, pero con la versión Express no puedes instalar Analysis Services, es decir, que no hay un Analysis Services Express. Lo de 'Advanced' es fácil que se confunda con 'Analysis', pero no es lo mismo.

Lo que sí puede hacer un SQL Server Express es conectar con un Integration Services o un Analysis Services que tengas licenciado e instalado en otro servidor.

En este sitio lo explican bastante bien.

cuando subo la base de datos

Subido por Anonimo (no verificado) el 7 Noviembre, 2016 - 19:58

cuando subo la base de datos pierde el control del mouse, como hacer para que el mouse siempre este disponible para utilizar el management?.

SQL Server Profiler: Cómo capturar consultas SQL y el detalle de su plan de ejecución

il_masacratore — Thu, 23 Jan 2014 17:49:36 +0000

SQL Server Profiler: Cómo capturar consultas SQL y el detalle de su plan de ejecución

Plataforma de datos

il_masacratore 23 Enero, 2014 - 18:49

Casi siempre nos enteramos de que alguna query va lenta por alguna queja de usuario. Ahora se queja que hace tiempo aquella cosa que hacía tardaba tanto y hoy cuando lo ha hecho un par de veces la cosa ha sido más lenta de normal. Realmente puede estar pasando de todo, pero entre las causas comunes podemos encontrarnos de todo un poco: fragmentación en la misma tabla, estadísticas que no están al dia, carga fuera de lo habitual en el servidor en ese mismo momento, incremento del volumen en las tablas implicadas, cambios en la aplicación...

Focalizándonos solo en problemas relacionados exclusivamente con la base de datos y si el origen de la queja nos lleva a un informe, nuestro trabajo será mas fácil. Siempre partimos de una query concreta que seguramente podemos extraer rápidamente y lanzarla nosotros desde Management Studio para reproducir el caso.

Si gozamos de los permisos suficientes, en el propio Management Studio podemos ver el plan de ejecución estimado e incluso el real desde Management Studio de forma interactiva. También podemos hacer lo mismo con otras herramientas complementarias como SQLSentry Plan Explorer. Hasta aquí todo bien.

En cambio, si el problema de lentitud lo tenemos en una operativa de una aplicación como puede ser el ERP empresarial. Si no tenemos algún desarrollador o técnico a mano que nos pueda ayudar a extraer la consulta o alguna opción que nos permita hacer un seguimiento sobre el SQL que lanza, acabaremos usando Microsoft SQL Server Profiler para capturar esa actividad e investigar el problema.

SQL Server Profiler

Para el que no lo conozca o no lo sepa, SQL Server Profiler es "una interfaz enriquecida para crear y administrar seguimientos y analizar y reproducir resultados de seguimiento.". Vamos, que sirve para registrar la actividad sobre la base de datos e incluso si fuera necesario recrearla en otro entorno o condiciones.

Para poder ejecutar SQL Server Profiler debemos tener permiso ALTER TRACE sobre el servidor. Para ver planes de ejecución podemos necesitar también el permiso SHOWPLAN.

En nuestro caso, lo que queremos hacer es capturar el plan de ejecución para obtener el plan que nos proporciona realmente la base de datos y poder dar fe de ello. En algún caso me he encontrado que la misma consulta lanzada por una aplicación y Management Studio no estaban usando el mismo plan. La única manera de detectar el problema y dar fe de ello ha sido capturar la información real.

Al tema. Para ejecutar el seguimiento iniciaremos SQL Server Profiler. Podemos hacerlo desde el menú inicio>Programas o lanzarlo desde Management Studio si lo tenemos abierto. Herramientas > SQL Server Profiler. Una vez lo iniciamos lo primero es conectarse al servidor de base de datos implicado.

El siguiente paso consiste en configurar lo que será nuestro seguimiento eligiendo qué y como queremos capturar. Debemos seleccionar primero los tipos de evento queremos capturar y luego que detalles incluir sobre ellos. Para hacer correctamente la selección, primero debemos elegir una de las plantillas ya predefinidas que nos facilitan parte del trabajo y luego cambiarlas añadiendo y quitando eventos y/o columnas si hace falta a nuestro gusto.

Nosotros elegiremos por ejemplo la plantilla "Tunning" que contendrá la información mínima que podemos necesitar. A continuación hacemos clic en Mostrar Todos los eventos" y luego en "Mostrar todas las columnas". Buscaremos en la columna Events PERFORMANCE, lo desplegamos y activamos ShowPlan Text y/o ShowPlan Xml.

Elegimos la plantilla:

Añadimos lo que nos falte relativo al plan de ejecución:

Una vez hecho esto ya podemos iniciar la captura. Le damos al Play de la barra de botones que está debajo del menú y ya empezamos a registrar. Muestro un ejemplo de como nos queda todo con lo que hemos hecho hasta ahora, de un evento Showplan XML. La imagen infeiror nos muestra un ejemplo:

De las columnas que pueden aparecer para los diferentes tipos de evento, las básicas para un seguimiento pueden ser:

EventClass: nos da el tipo de evento del registro seleccionado
TextData: Texto plano. Por ejemplo la SQL ejecutada.
Duration: Duración en mili segundos para Eventos del tipoo RPC o Stmt Completed.
SPID: Identificador para la sesión de base de datos que provoca el evento.
DatabaseName: Base de datos sobre la que ocurre el evento.
TimeStart: La fecha/hora para ubicar el evento.

Una vez visto esto ya estamos listos para cualquier incidencia...

Otras cosillas a comentar sobre SQL Server Profiler:

Podemos ejecutar más de un seguimiento y les podemos poner nombre cambiando el Título, en las propiedades del seguimiento.
Cada dato innecesario suma. Si nos podemos ahorrar alguna columna mejor sacarla porque en un seguimiento de horas podemos tener cientos de miles de registros. Esto se traduce en espacio consumido innecesariamente.
Si hacemos el seguimiento en un entorno de producción donde conviven otras aplicaciones debemos aislar la información que nos puede dar Profiler añadiendo filtros. Para poder hacerlo, con el seguimiento detenido, debemos ir a la pestaña Selección de Eventos y hacer clic en Filtros de Columna. En este caso podemos intentar filtrar por aplicación si somos sus únicos usuarios o si sabemos alguna tabla implicada también podemos filtrar por el campo TextData. Existen diferentes combinaciones y se trata de encontrar la combinación de filtros más selectiva.
Para ir aprendiendo más sobre los eventos, si pasamos el ratón sobre su nombre en la columna Events, en el groupbox de la parte inferior aparece una breve descrición del mismo.
Si nos olvidamos el Profiler encendido y registrando actividad en el servidor, se pausa de forma "prudencial" cuando se coma todo el espacio en disco.
Podemos guardar la información de un seguimiento. Podemos hacerlo a fichero o podemos hacerlo en una tabla. Puede ser recomendable hacerlo en ambos pero para tratar los resultados puede ser más fácil la tabla.
Podemos crear plantillas a nuestro gusto. cuando ya tenemos la plantilla en ejecución podemos hacerlo desde el menú Archivo>Guardar como>Plantilla de seguimiento.

Administracion Sql Server

Que excelente articulo, me

Subido por Victor Blanco (no verificado) el 6 Agosto, 2015 - 23:45

Que excelente articulo, me encanto, me gustaria aprender mas para sacarle el jugo a la herramienta, si me recomendas algo de lectura te agradeceria, saludos.

SQL Sentry Plan Explorer de SQL Server 2014, herramienta complementaria a Management Studio

il_masacratore — Thu, 16 Jan 2014 12:22:29 +0000

SQL Sentry Plan Explorer de SQL Server 2014, herramienta complementaria a Management Studio

Plataforma de datos

il_masacratore 16 Enero, 2014 - 13:22

SentryOne dispone de diferentes aplicaciones para ayudarnos en la administración y el día a día con nuestra base de datos SQL Server, dwh o como desarrolladores. SentryOne Plan Explorer permite hacer un análisis más gráfico de una consulta que lanzamos sobre SQL Server y deforma interactiva profundizar en diferentes aspectos relacionados como coste de operaciones, peso sobre el lote, índices involucrados...

Plan Explorer tiene versión free y versión PRO. La versión free podemos descargarla directamente de SentryOne donde tenemos el instalador de la aplicación y adicionalmente un addon para SQL Server Management Studio. La instalación no tiene misterio y es del estilo siguiente siguiente.

A primera vista, como otras herramientas parecidas, muestra lo que nos da el propio Management Studio cuando vemos el plan de ejecución estimado/real de una consulta. Lo que es distinto es que de forma predeterminada ya focaliza nuestra atención a las áreas problemáticas que van con nuestra consulta. Por ejemplo, en la pestaña de Plan Diagram, ya nos marca las operaciones más costosas mediante colores. Otro ejemplo es la pestaña Plan Tree que muestra los datos más concretos donde también nos marca de otro color si existe una gran diferencia entre las filas estimadas con las filas reales (estadísticas desactualizadas!).

La forma de empezar a trabajar es bastante sencilla. Basta con hacer un Copy & Paste de la consulta en la pestaña que vemos por defecto en la pantalla inicial, Command Text. A continuación ya podemos pulsar ver el Plan Estimado o el Real, como en Management Studio. Es en ese momento cuando nos pide a que servidor y base de datos conectarse.

Una vez conectados y obtenido el plan estimado de ejecución ya vemos en la parte inferior su diagrama. En el ya nos marca en % relativos al coste total las operaciones y en colores remarcadas las más costosas. A diferencia de Management Studio, si falta un indice nos aparece el símbolo warning en el SELECT en lugar de la parrafada en el encabezado de la pestaña.

Los porcentajes que vemos, por defecto corresponde a la suma de I/O+CPU, pero también podemos elegir solo por I/O o CPU según nos convenga. También podemos hacer que varíe el grueso de las lineas de datos según su volumen (todo esto en el menú contextual del área del gráfico).

En la segunda pestaña del panel inferior, Plan Tree, vemos jerarquizadas las operaciones con los datos más relevantes por defecto (Coste estimado, Coste del subarbol, filas estimadas que pasan, etc...). Podemos añadirle según nuestras necesidades o gustos mas columnas.

En la tercera pestaña, Top Operations, podemos comparar directamente mediante una tabla costes de cpu y de I/O las diferentes operaciones dentro de la consulta. Como en la pestaña anterior, podemos añadir más columnas según nuestros gustos.

En la cuarta, Query Columns, vemos los índices que se usan en la consulta y que filtros aplican. También vemos el tipo de operación (Index Seek, Clustered Index Seek, Index Scan...). En la versión PRO de Plan Explorer desde aquí podemos ver las estadísticas de estos índices e incluso crear uno nuevo.

La quinta pestaña, Join Diagram, muestra de manera directa y muy simplificada las tablas involucradas solo con los campos que usamos en la relación entre ellas.

Parameters muestra los parámetros incluidos en la consulta, incluso los no declarados explícitamente. La pestaña Expressions muestra datos adicionales por cada expresión de agregado: SUM, MIN etc... Realmente no aporta demasiado pero tampoco molesta. Por último, la pestaña Table I/O muestra los datos relativos a entrada y salida de datos: cantidad de scans, lecturas físicas, lógicas.

Una de las diferencias entre trabajar con el plan estimado (Get Estimated PLan) y el real (Get Actual Plan) es que además de las estadísticas de I/O que se muestran en la pestaña Table I/O, también se comparan las filas estimadas con las reales, algo que puede indicar que las estadísticas están desactualizadas.

Otra de las opciones, como mínimo curiosas, es la opción de menú Anonymize. Esta lo que hace es abrir una nueva ventana donde nos ha reemplazado los nombres de nuestras bases de datos, los índices, nombres de usuario, alias, parámetros... con toda la info relativa a la query. La gracia es poder compartir esta información y pedir consejo si hiciera falta.

El addon de SentryOne Plan Explorar para SQL Server Management Studio es un simple vínculo que permite desde la visualización de cualquier plan de ejecución desde el menú contextual, haciendo clic derecho en el área "View with SQL Sentry Plan Explorer". Para instalarlo basta con descargarlo de aquí y reiniciar Management Studio para que podamos usarlo. Es un requisito haber instalado antes la propia aplicación Plan Explorer. El addon de momento funciona con Management Studio incluido en SQL Server 2005, SQL Server 2008, SQL Server 2008 R2 y SQL Server 2012.

En resumen...

... Me parece una herramienta útil pero no esencial. Ofrece alguna cosa más que el propio Management Studio y lo hace más bonito pero podemos vivir sin ella. Uno de los motivos por los quizás que me parece recomendable es para alguien que anda perdido y no sabe por donde empezar.

No es lo mismo enfrentarte con la ventana del plan de SSMS que con los colores y pestañas de SQLSentry Plan Explorer. Para el resto, mi conclusión es que lo que más aporta es facilidad de acceso a todos los aspectos relacionados con la query.

Administracion Sql Server

ApexSQL Refactor: Complemento para edición de código en MS SQL Server Management Studio

il_masacratore — Tue, 10 Dec 2013 09:30:11 +0000

ApexSQL Refactor: Complemento para edición de código en MS SQL Server Management Studio

Plataforma de datos

il_masacratore 10 Diciembre, 2013 - 10:30

ApexSQL Refactor es una herramienta potente de formateo de código sql para usuarios que trabajan a diario con él. Es un complemento para SQL Server Management Studio que puede ayudarte a generar, reutilizar el código o formatearlo (tabulaciones, mayúsculas, minúsculas, nomenclatura, palabras reservadas...) para hacerlo más legible para otros o incluso parsear el de otros para presentarlo a tu gusto.

Este refactor, es un complemento gratuito, aunque existe una versión más completa de pago y se puede descargar directamente de la página del fabricante. La pega, como suele ser habitual en estos casos es que requiere registrarse para poder bajarte el instalador.

Instalación de ApexSQL Refactor

Descargamos el complemento, una vez registrados y lanzamos el setup. Como se ve en la imagen, permite usarlo con diferentes versiones "actuales" de Visual Studio y MS.

Una vez finalizado el instalador confirmaremos que todo ha ido bien cuando abramos Management Studio y nos aparezca el nuevo menú:

Formateando el código

Lo ideal para empezar a usarlo es ponernos a editar las opciones para el formateador del código. Para ello nos vamos a ApexSQL > Apex SQLRefactor > Format SQL Code > Formatting Options. En este formulario podemos editar diferentes perfiles de formateo. Nosotros deberíamos crear uno nuevo e ir jugando con las diferentes opciones. Encontrareis una guía-resumen muy clara en este enlace.

Como guinda, para facilitar el uso y formateo de código que hemos editado, primero deberíamos establecerlo como predeterminado desde el formulario de Formatting Options, marcando la casilla Use as default. Por último, fijarnos en el atajo de teclado (Ctrl+May+Alt+F) o cambiarlo desde el menú ApexSQL>ApexSQL Refactor>Options.

Refactorizando

Además de la parte anterior, con este complemento tenemos la opción de automatizar la generación de partes de código. Si nos paramos a mirar, desde el mismo menú ya podemos ver algunas de las opciones que lanzan asistentes para "hacer la magia":

Copiar al portapapeles como otro lenguaje: Por ejemplo, en el caso de una select la copia entre comillas y nos la asigna a una variable de tipo cadena del lenguaje seleccionado con su declaración. El ejemplo select * from sys.databases lo transforma a c# así: string sql = "select * from sys.databases;";
Encapsular como: Envolver la consulta para regalo en forma de vista, procedimiento, función o función escalar. Si lo elegimos se lanza un asistente donde nos permite elegir nombre, parámetros y nos muestra el script que generará.

En resumen...

… és útil y además gratis, aunque seguro que existen otras herramientas que hacen lo mismo. Por cierto, una manera más rápida de formatear una SELECT dentro de Management Studio es seleccionarla entera (sola) y pulsar Ctrl+Shift+Q para que se abra el Diseñador de consultas. Pulsamos aceptar y ya está toda espaciada y tabulada de forma simple.

SQL Server

SQL

herramientas

Administracion Sql Server

SQL Server 2014 DQS (Data Quality Services)

il_masacratore — Thu, 21 Nov 2013 11:53:02 +0000

SQL Server 2014 DQS (Data Quality Services)

Plataforma de datos

il_masacratore 21 Noviembre, 2013 - 12:53

Microsoft Sql Server Data Quality Services (DQS) es una herramienta, cliente-servidor, que se introdujo en Sql Server 2012 y que permite permite velar por la integridad de los datos basada en unos datos previos, la base de datos de conocimiento, que usamos para validar otros datos posteriores. Esta herramienta permite incluso limpiar datos entrantes en paquetes de SSIS. Su propósito es conseguir datos de calidad, construyendo primero una fuente de conocimiento sobre la calidad objetivo de nuestros datos, creando dominios (valores de referencia para asignar validez o no) y reglas para definir actuaciones.

Generalmente los datos incorrectos son un problema que se genera por usuarios o clientes en el momento de su introducción. Otras veces, los problemas pueden venir al unir diferentes orígenes de datos en un mismo almacén de datos destino. Con herramientas como DQS podemos, de alguna manera, validar nuestros datos o incluso corregirlos para obtener finalmente datos válidos y de mayor valor empresarial. En teoría, una de las ventajas que dice Microsoft sobre DQS es que permite a usuarios de distintos niveles (usuario final o profesional IT) el crear, ejecutar y mantener las operaciones de calidad de datos...

Antes empezar necesitaremos tener instalado en nuestro servidor lo necesario para empezar a probar. Lanzamos el instalador de SqlServer y añadimos a nuestra instancia de SqlServer Data Quality Services, bajo el motor de la base de datos y en el caso de probar con una máquina virtual también el cliente de calidad de datos.

Una vez completada la instalación activamos la parte del Servidor. Lo encontramos en el menú Inicio > Programas > Microsoft SQL Server 2014 CTP>Data Quality Server Installer

Además de los componentes de servidor, eso también copia una base de conocimento de ejemplo, DQS Data, que incluye algunos dominios predefinidos. Superado este paso ya podemos empezar con nuestro ejemplo. Para las pruebas tendremos dos tablas de empleados como esta que usaremos primero como base para crear las reglas para nuestra base de datos de conocimiento y una vez definidos dominios con sus reglas de validación, las usaremos para probar de corregir los datos y exportarlos a otra tabla de sqlserver.

--Script de carga para las tablas de ejemplo. CREATE TABLE [dbo].[EmpleadosA]( [Nombre] [varchar](20) NULL, [Genero] [varchar](10) NULL, [Edad] [tinyint] NULL ) ON [PRIMARY] INSERT INTO [dbo].[EmpleadosA] VALUES ('John','Male',18) INSERT INTO [dbo].[EmpleadosA] VALUES ('Mike', 'Hombre',18) INSERT INTO [dbo].[EmpleadosA] VALUES ('Rahul', 'Ind',NULL) INSERT INTO [dbo].[EmpleadosA] VALUES ('Sara','Mujer',23) INSERT INTO [dbo].[EmpleadosA] VALUES ('Alberto','H',48) INSERT INTO [dbo].[EmpleadosA] VALUES ('Carlos','Hombre',18) GO CREATE TABLE [dbo].[EmpleadosB]( [Nombre] [varchar](20) NULL, [Email] [varchar](40) NULL, [Titulo] [varchar](20) NULL ) ON [PRIMARY] INSERT INTO [dbo].[EmpleadosB] VALUES ('John','jhon@test.com',NULL) INSERT INTO [dbo].[EmpleadosB] VALUES ('Mike','Mike test.com','Bachillerato') INSERT INTO [dbo].[EmpleadosB] VALUES ('Rahul',' ','Primaria) INSERT INTO [dbo].[EmpleadosB] VALUES ('Sara','sara@test.com','PM') INSERT INTO [dbo].[EmpleadosB] VALUES ('Alberto','alberto@test','Secundaria') INSERT INTO [dbo].[EmpleadosB] VALUES ('Carlos','test@test.com','Licenciado') GO

A continuación ya podemos abrir el Cliente de Calidad de Datos (Microsoft SQL Server 2014>Data Quality Client) para empezar a trastear. Nada más clicar nos pide el nombre del servidor (pensemos en nuestra instancia de servidor SQLSERVER). Lo primero que debemos hacer es crear una Nueva base de Conocimiento.

Lo siguiente será crear una nueva. Le ponemos Nombre y pulsamos siguiente. Cerramos y volvemos al menú principal. A continuación Lo que haremos será elegir de nuestra base de datos la "Detección de conocimiento". Esta opción permite elegir una fuente de datos (excel, sqlserver) y definir dominios a partir de columnas de datos. En mi caso me conecto a la bbdd, elijo una de los tablas de ejemplo para empezar a definir para cada columna que me interese un dominio con parámetros específicos en cada columna que lo necesite... Particularmete interesante la opción de poder elegir, en el caso de una columna de texto, el idioma del mismo, pasarle el corrector ortográfico y también formatear la salida (MAY/MIN para abreviaturas?).

El paso siguiente es el "análisis de detección de datos en el origen seleccionado". Se escanea el origen y se determina por cada columna los valores únicos, los validos y los que infringen la integridad (valores null etc). Si hemos probado sobre EmpleadosA solo vemos un error de integridad debido a un NULL en la columna Edad. Pulsamos siguiente y podemos elegir que hacer con los nuevos valores que sean validos, así como ignorar los incorrectos marcándolos como error.

(

Ahora, antes de validar de nuevo, definiremos un dominio más complejo para los campos de email. En este caso será una regla de validación de formato. Primero vamos como a antes a la detección de dominios para definir sobre la segunda tabla el dominio sobre la columna email (como el los ejemplos anteriores). Una vez hemos creado el dominio para el campo email, la diferencia es que saldremos y entraremos en el Administrador de dominios sobre nuestra base de datos de conocimiento y modificaremos las Reglas de Dominio (fijaros también que aquí podemos explorar los Valores del Dominio que forman parte de él) para añadir una del tipo: "El valor coincide con la expresión regular": ^[_a-z0-9-]+(\.[a-z0-9-]+)*@[a-z0-9-]+(\.[a-z0-9-]+)*(\.[a-z]{2,4})$

Al final publicamos este último cambio de este dominio y ya estamos listos para continuar.

El último paso ya para acabar con esta prueba es validar una tabla real, corregir los datos y exportar a una nueva con los datos que no cumplan las reglas y decidamos corregir. Para hacerlo abrimos de nuevo el Data Quality Client y creamos un nuevo proyecto de calidad de datos. Le pondremos nombre, elegimos la base de conocimiento que hemos definido antes y elegimos limpieza. Los pasos a partir de aquí son parecidos a los anteriores cuando explorábamos la tabla. En el siguiente paso elegimos la tabla a limpiar y para cada columna, si es necesario, un dominio para aplicar sobre ella. Pulsamos siguiente y escaneamos los datos. Con los datos de ejemplo, detectara dos valores para email erróneos que podremos corregir (si han sido corregidos anteriormente los auto-corrige y aparecen como "Corregido"). Finalmente, en el siguiente paso podemos elegir donde exportar nuestros datos pulidos (por ejemplo a una nueva tabla).

Mis conclusiones son...

... que esta es otra herramienta Microsoft bastante fácil de usar y puede que bastante útil para pulir datos maestros de cualquier base de datos o para incluir validaciones como paso intermedio en nuestras cargas para el dwh. Su sencillez (la misma prueba con el proyecto de calidad de datos) hace fácil compartir la carga de corrección manual de los datos con alguien que no sea técnico de bbdd ni programador, más bien una persona dentro de la organización con conocimiento de causa que coja los datos del origen, los interprete y los deje donde tu le digas para cargarlos en algún sitio.

Administracion Sql Server

Dqs

SQL Server 2014

SSIS

Articulo muy interesante,

Subido por Anonimo (no verificado) el 23 Noviembre, 2013 - 10:55

Articulo muy interesante, como comentario, la frase:"alguien que no sea técnico de bbdd ni programador" , no veo a usuarios escribiendo expresiones regulares, a modo de anécdota.Jejeje.