SolidQ Blogs

Introducing DB Flex

Dejan Sarka — 2013-05-23T09:09:23+02:00

In these times of weird economics in many places, more and more small and medium companies try to operate without a dedicated database administrator (DBA). Other companies still have one or more dedicated DBAs, however, (s)he or they is or are overwhelmed with work. Nevertheless, SQL Server and databases need regular monitoring and maintenance. SolidQ responded to these needs with a service called DB Flex.

SolidQ supplies the most comprehensive and flexible operational services on Microsoft SQL Server on the market. With DB Flex, we constantly monitor your SQL environment, optimize the operation and continuously correct errors and deficiencies, cost-effectively. With 100% focus on SQL Server, the DB Flex service typically saves enterprises 30-50% of the cost compared to in-house operation or external hosting supplier. With DB Flex we ensure reliable operation, provide professional sparring and training for our customers that cover the needs of the individual enterprise.

We are successfully offering and executing this service in the Nordic area, and now we are introducing it also in the Central and Eastern Europe area. If you are interested in this service, please contact Fritz Lechnitz (flechnitz@solidq.com). For Slovenia, in Slovenian language, you can also contact me (dsarka@solidq.com).

XBOX One

Ken Spencer — 2013-05-22T23:26:06+02:00

Looks like MS has done it again. The XBOX One is coming out soon. Info here:

http://news.msn.com/science-technology/microsoft-unveils-xbox-one?ocid=ansnews11

I love the XBOX 360. It still has some of the best graphics around. The new one claims to beat the current graphics in a big way.

And the other integrated features look awesome too.

Accediendo a Facebook con Data Explorer

Pau Sempere Sanchez — 2013-05-22T11:08:00+02:00

En nuestro anterior post accedíamos a Twitter utilizando Data Explorer para descubrir quién mencionaba a SolidQ y en qué parte del mundo se encontraban (puedes verlo aquí). Hoy veremos cómo acceder a otra red social, Facebook, mediante la característica propia de Data Explorer para conectar con ella y consumiendo estos datos finalmente con Excel 2013.

Empezaremos seleccionando la fuente de datos, en este caso Facebook (desde la opción From Other Sources):

Nos pedirá que ingresemos en Facebook, por lo que tendremos que tener una cuenta activa para poder utilizar esta funcionalidad. Esto supone una diferencia con Twitter, que tiene un API que puede proveer de información a cualquiera que haga consultas contra ella aún con identificación anónima. Con Facebook tendremos también que dar acceso a la aplicación Data Explorer para que interactúe con nuestro perfil.

Una vez hayamos aceptado, realizaremos la búsqueda del perfil que queremos consultar. Deberemos especificar el nombre del perfil o el identificador del usuario. La manera más fácil es ir al perfil al que queremos acceder y ver qué nombre figura en la URL. Por tanto, si queremos ver información sobre el perfil de SolidQ España, que aparece con esta URL

buscaremos por

Podríamos elegir el tipo de conexión que queremos consultar para el perfil, esto es, si queremos ver solo las actualizaciones de estado, los posts, las notas, etc. En este caso no especificamos ningún filtro para poder acceder a todos los datos, filtraremos con más detalle con Data Explorer una vez tengamos los datos importados. Si hacemos clic en Apply, recibiremos una serie de datos estructurados sobre el perfil de SolidQ España

Tenemos mucha información que puede sernos útil para diferentes análisis o recolección de datos. Incluso vemos arriba como se genera la fórmula que Data Explorer usa para consultar los datos (y que podríamos usar nosotros para generar funciones personalizadas, por ejemplo). Pero lo que queremos hacer hoy es una comparativa entre “likes”, comentarios a posts y veces que se comparten estos posts a lo largo del tiempo, para estudiar qué impacto ha ido teniendo lo que se ha ido publicando en este perfil. Para ello, clicamos en “connections”, y Data Explorer nos abrirá la lista de registros disponibles.

Seleccionando “Posts” importaremos la información sobre los posts publicados.

Para nuestro caso concreto queremos saber los conteos de “shares”, “likes” y “comments” que tiene cada uno, por lo que nos vamos a cada uno de estos campos que encontraremos en la información que hemos obtenido y, haciendo clic en el icono para expandir la columna en diferentes campos (a la derecha del nombre de la columna), obtenemos los conteos (que ya forman parte de la información estructurada que nos da Facebook a través de Data Explorer):

Una vez tenemos los conteos asociados a cada registro, y con un par de formateos de datos con Data Explorer para tratar con las fechas (queremos ver los datos agrupados por meses y no por día y hora como nos vienen especificados en los campos created_time y updated_time), podremos tener rápidamente un informe como éste donde vemos la evolución de las interacciones con el perfil de SolidQ España

Se trata de un informe muy sencillo pero muy relevante. Si explorásemos más el dato y lo trabajásemos más, combinándolo quizá con otras fuentes de información (incluso con nuevas consultas a Facebook para ver quién son los usuarios que han hecho like o han comentado ciertos posts) podríamos tener un análisis aún más rico y revelador. Recordemos que incluso podemos añadir directamente los datos de Data Explorer a un modelo de PowerPivot con lo que expandimos aún más las posibilidades de análisis, por ejemplo si ya tuviésemos un modelo de datos que pudiésemos enriquecer con la información que acabamos de obtener. El límite, como siempre, está en cuánto trabajo dediquemos y donde llegue nuestra imaginación

Espero que os haya gustado, nos vemos en siguientes posts acerca de la funcionalidad de Data Explorer.

Feliz integración y análisis

Hur matematikkunskaper kan hjälpa till med optimering

Peter Larsson — 2013-05-15T18:04:15+02:00

Idag fick jag tillfället att hjälpa en kollega med att optimera en fråga för en kunds räkning. Originalfrågan såg i princip ut så här

-- Original
SELECT      t.*
FROM        dbo.Table1 AS t
CROSS JOIN (
                SELECT ChildID
                FROM    dbo.Table1
            ) AS w
WHERE       (
                t.ParentID = w.ChildID AND t.ParentID <> t.ChildID
                OR
                t.ChildID = t.ParentID AND t.ChildID = w.ChildID
            )
            AND t.CategoryID IN ('11', '22', '33')

Det som jag reagerade först på var användandet av OR i WHERE-satsen. Det gör det mycket svårare för Query Optimizer att välja ett bra index och att skapa en bra exekveringsplan. När jag sedan tittat lite närmare på den för att se vad som egentligen ska hända, vilken affärsregel som ska uppfyllas, ser jag att uttrycket är överflödigt.

Låt oss börja med uttrycket efter OR.

t.ChildID = t.ParentID
t.ChildID = w.ChildID

Av detta kan vi sluta oss till att även uttrycket t.ParentID = w.ChildID är sant. Dessutom är det sant att om t.ChildID = t.ParentID så är det dessutom sant att t.ParentID = t.ChildID. Låt oss skriva om uttrycket med vår härledning och dessutom byta plats på uttrycket efter OR.

-- Härledning
SELECT      t.*
FROM        dbo.Table1 AS t
CROSS JOIN (
                SELECT ChildID
                FROM    dbo.Table1
            ) AS w
WHERE       (
                t.ParentID = w.ChildID AND t.ParentID <> t.ChildID
                OR
                t.ParentID = w.ChildID AND t.ParentID = t.ChildID
            )
            AND t.CategoriID IN ('11', '22', '33')

Vad vi nu kan se är att vi har två exklusiva uttryck i vår OR. I det ena fallet ska t.ParentID = t.ChildID och i det andra utttycket ska t.ParentID <> t.ChildID.
Av detta vet vi att alla rader ska med, för antingen så har de två kolumnerna lika värde eller så har de det inte. Vi behöver heller inte heller ta hänsyn till NULL här då de båda kolumnerna inte tillåter NULL. Om vi plockar bort det onödiga uttrycket från frågan får vi följande query.

-- Bortplockning
SELECT      t.*
FROM        dbo.Table1 AS t
CROSS JOIN (
                SELECT ChildID
                FROM    dbo.Table1
            ) AS w
WHERE       (
                t.ParentID = w.ChilID
                OR
                t.ParentID = w.ChildID
            )
            AND t.CategoryID IN ('11', '22', '33')

Nu börjar det likna något! Ett uttryck ska vara sant eller så ska samma uttryck igen vara sant. Det är en överflödig kontroll, så det slutade här med att jag skrev om frågan så den såg ut så här istället.

-- Optimerad
SELECT        t.*
FROM          dbo.Table1 AS t
INNER JOIN    dbo.Table1 AS w ON w.ChildID = t.ParentID
WHERE         t.CategoryID IN ('11', '22', '33')

Vad gjorde det då för prestandan? Med hjälp av SET STATISTICS TIME, IO ON fick jag följande resultat.

-- Original
(391 row(s) affected)
Table 'Worktable'. Scan count 8, logical reads 151599, physical reads 0.
Table 'Table1'.    Scan count 17, logical reads   1466, physical reads 0.
Table 'Worktable'. Scan count 0, logical reads      0.

SQL Server Execution Times:
   CPU time = 11389 ms, elapsed time = 1873 ms.

-- Omskrivning
(391 row(s) affected)
Table 'Worktable'. Scan count 0, logical reads      0, physical reads 0.
Table 'Table1'.    Scan count 2, logical reads   1256, physical reads 0.

SQL Server Execution Times:
   CPU time =   733 ms, elapsed time = 732 ms.

Detta lilla matematiska knep gjorde att omskrivningen använder 15 ggr färre CPU samt slutförs 2,5 ggr snabbare än tidigare. När jag tittade närmare i exekveringsplanen såg jag att omskrivningen bara behöver 1 core medan originalfrågan la beslag på alla 16 cores.

Om det nu varit så att kolumnerna tillåtit NULL, hade jag varit tvungen att lägga till en extra kontroll som den här för att efterlikna originalfrågan till 100%.

-- Optimerad med NULL
SELECT        t.*
FROM          dbo.Table1 AS t
INNER JOIN    dbo.Table1 AS w ON w.ChildID = t.ParentID
WHERE         t.CategoryID IN ('11', '22', '33')
              AND t.ChildID IS NOT NULL

Aprovecha tu almacenamiento con iSCSI y Storage Spaces

Rubén Garrigós — 2013-05-13T21:09:31+02:00

Una de las novedades que trae Windows Server 2012 son los Storage Spaces. Un Storage Space es un pool de un conjunto de discos que se gestionan de forma similar a como se gestionan las SAN. Una de las ventajas para los entornos más modestos es la posibilidad de mezclar discos de distintos tamaños y conectados a través de distintos buses en el mismo pool. En concreto podemos conectar discos por SAS, SATA, ATA, SCSI e incluso por USB:

En ocasiones lo que queremos introducir en el pool no es un disco entero sino una partición de dicho disco o espacio sobrante. En estos casos la solución que podemos tomar es “presentar” dicho espacio mediante iSCSI, al igual que haríamos para acceder a un volumen iSCSI en una NAS/SAN. Para ello primero comprobaremos si tenemos los roles instalados para poder crear el iSCSI Target:

Una vez instalados, desde el server manager crearemos un nuevo disco virtual iSCSI, en este caso de 20 GB:

Este disco lo conectaremos contra el propio servidor por iSCSI:

Una vez conectado por iSCSI nos aparecerá como un disco más en el administrador de discos (disco 17 en nuestro ejemplo):

Una vez lo tenemos presentado, podremos añadirlo sin problema a un nuevo pool o a uno ya existente. En nuestro caso lo hemos añadido a un nuevo pool llamado iSCSI pool:

Una vez añadido aparecerá dentro del pool como si de un disco físico más se tratara pero conectado por bus iSCSI:

En resumen, esta técnica de “enmascarar” mediante iSCSI nos puede servir para aprovechar mejor nuestro almacenamiento para Storage Spaces. También podremos utilizar iSCSI para exponer nuestro pool de almacenamiento local con Storage Spaces a otros servidores.

Cada día vemos más este escenario en pequeños entornos de virtualización para desarrollo/testing. Con Storage Spaces podemos combinar distintos discos en un pool con redundancia sin estar atados a las limitaciones de los fabricantes o de las propias tarjetas RAID. Combinando esta flexibilidad y el target ISCSI nativo de Windows Server 2012 podemos crear un servidor de almacenamiento con muy bajo coste.

Curso MS Business Intelligence-SSAS: Personalizando el Modelo-Atributos (38)

Salvador Ramos — 2013-04-30T10:52:20+02:00

Atributos

Por cada una de las dimensiones nos encontramos con una colección de Atributos que se corresponden con una o más columnas de la tabla de dimensiones. Un atributo es cada una de las características de la dimensión por la cual podremos analizar la información. Por ejemplo, para la dimensión Tiempo tendremos atributos como Año, Mes, Día, Trimestre, Trimestre fiscal, Año fiscal, etc. Para la dimensión Cliente tendremos otros como Nombre, Población, País, Estudios, Edad, Número de hijos, Sexo, etc.

Entre todos ellos, debemos destacar que contaremos con un atributo clave, éste es un atributo con valores únicos, que identifica las columnas de la tabla de dimensiones con las claves externas de la tabla de hechos. Normalmente, representa a la columna que es clave principal (primary key) en la tabla de dimensiones.

Veamos las principales propiedades de los atributos:

· KeyColumn. Contiene la colección de columnas que constituyen la clave del atributo. Está compuesta por las columnas que hacen que el valor de cada miembro sea único. Por ejemplo, si tenemos en la tabla de Tiempo una columna para el año y otra para el mes, la colección KeyColumn estará formada por ambas columnas, ya que cada mes está repetido en cada uno de los años.

· NameColumn. Se utiliza para mostrar un valor descriptivo al usuario, cuando el valor el valor de la columna clave no es lo suficientemente descriptivo. Cuando se indica una columna en esta propiedad, será este valor el mostrado al usuario en lugar de KeyColumn.

· ValueColumn. Identifica la columna que proporciona el valor del atributo.

· AttributeHierarchyDisplayFolder. Identifica la carpeta en la que verán este elemento los usuarios finales desde las herramientas cliente.

· DefaultMember. Expresión MDX que define el miembro predeterminado del atributo.

· OrderBy. Especifica el método para ordenar los miembros del atributo. Valores:

· Key, los miembros se ordenan por la clave del atributo

· Name, los miembros se ordenan por el nombre del atributo

· AttributeKey, los miembros se ordenan por la clave del atributo especificado en la propiedad OrderByAttribute.

· AttributeName, los miembros se ordenan por el nombre del atributo especificado en la propiedad OrderByAttribute.

· OrderByAttribute. Si en OrderBy hemos decidido que se ordenen por otro atributo, es decir, hemos elegido el valor AttributeKey o AttributeName, en esta propiedad indicaremos el atributo por el que deseamos realizar la ordenación.

· Type. Especifica el tipo de información que contiene el atributo.

· Usage. Especifica el uso del atributo. Valores: Regular, Key, Parent.

· IsAggregatable. Indica si el atributo se puede agregar en una jerarquía.

· DiscretizationMetod. “Discretizar” consiste en convertir valores continuos en valores discretos. Por ejemplo, el salario es un valor continuo, puede haber cualquier valor, pero a nivel de análisis de información podemos convertirlo en continuo, haciendo tres grupos, el primero entre 0 y 10.000, el segundo entre 10.001 y 50.000 y el tercero para más de 50.000. Con la propiedad DiscretizationMetod elegimos el método a utilizar para este proceso. Valores: None, Automatic, EqualAreas, Cluster.

· DiscretizationBucketCount. Especifica el número de depósitos en los que se “discretizarán” los atributos. En el ejemplo anterior serían tres.

· AttributeHierarchyEnabled. Determina si se ha generado una jerarquía de atributos para ese atributo. Esto tiene implicaciones, ya que si no está habilitada no se puede utilizar ese atributo en una jerarquía definida por el usuario, ni se puede hacer referencia a la jerarquía de atributos desde instrucciones MDX.

· AttributeHierarchyOptimizedState. Determina el nivel de optimización aplicado a la jerarquía de atributos. Valores: FullyOptimized, NotOptimized. Por defecto está completamente optimizada, lo que implica que se generarán índices para optimizar las consultas. Es conveniente que no estén optimizadas aquellas jerarquías que no se utilicen para realizar consultas, y sólo estén para otros fines como la ordenación. Esto ahorrará tiempos de procesamiento.

· AttributeHierarchyOrdered. Indica si la jerarquía de atributos asociada está ordenada. Valores: True, False. Al igual que en el caso anterior, si no se va a utilizar para realizar consultas, mejor ponerla a False, y ahorrar tiempos de procesamiento innecesarios.

· AttributeHierarchyVisible. Indica si la jerarquía de atributos asociada está visible para las aplicaciones cliente. Valores: True, False. Se debe poner a False cuando no se utiliza para realizar consultas.

Si te interesa esta información, y deseas convertirte en un profesional altamente especializado en Microsoft Business Intelligence, te recomiendo que nos pidas información sobre nuestro Master en BI. Recuerda que hay poquitas plazas disponibles!!!

Post publicados anteriormente como parte de este curso:

Kvalitetssäkra ETL med certifierade konsulter

Thomas Ivarsson — 2013-04-30T10:39:00+02:00

Med SQL Server 2012 har det också kommit ett nytt upplägg för certifiering av MSBI konsulter med upp till 5 olika delar. Det är väldigt goda nyheter trots en längre tidsperiod att läsa in och bli godkänd. Ett av dessa certifikat heter “70-463, Implementing a Data Warehouse with SQL Server 2012” och är både en examen med teknisk bredd inom SSIS, relationsdatabasen, Master Data Management och Data Quality Services. Här finns även genomgångar av bäst praxis och optimeringsproblem. Sammantaget innehåller examen en väldigt bra kunskapsbas som alla BI konsulter inom Microsofts plattform bör ha lärt sig.

Under mina år som BI konsult och som förvaltare av BI lösningar har jag tyvärr sett mycket slarv och ibland rena galenskaper i designen av ETL system. Tyvärr sitter sedan kunden fast i en oöverskådlig härva av spagetti kod eller datamodeller som gör allt optimeringsarbete meningslöst utan att starta om hela utvecklingsprocessen. Detta görs sällan av kostnadsskäl utan en illa fungerande lösning får leva kvar alltför länge.

Jag skulle vilja gå så långt att säga att kunderna bör kräva att konsulter har klarat av examen 70-463 och att konsulterna följer principerna och tipsen i denna examen. Boken med samma namn som examen, från Microsoft Press, kom ut vid årsskiftet och finns att köpa hos de flesta nätbokhandlare.

Kako smo požrli NT konferenco

Dejan Sarka — 2013-04-29T12:10:52+02:00

First a quick note to my regular readers. I decided for a post in Slovenian language, because I want to address my fellow citizens only. You are not missing anything, this is not a technical blog.

Končana je 18. NT konferenca, kot kaže, tudi zadnja NT konferenca. Ne morem si kaj, da mi ne bi bilo zaradi tega žal. NT konferenca je bila vedno nekaj posebnega, in to v svetovnem merilu. V najboljših časih je število udeležencev preseglo 2.000, kar je najbrž svetovni rekord glede na število prebivalcev. Če bi npr. v ZDA uspeli privabiti en promil prebivalstva, bi morali imeti več kot 300.000 udeležencev. Zato sem v tujini našo izjemno konferenco vedno omenjal s ponosom. Na žalost bomo imeli še eno stvar manj, na katero bi lahko bili ponosni.

Popolnoma mi je jasno, da v sedanji krizi koncept konference, kot smo ga imeli, ne more več preživeti. Zato mi je tudi jasno, da mora Microsoft Slovenija nekaj spremeniti. Nisem pa prepričan, da je smer, ki so jo ubrali, najboljša. Predvidoma bodo naslednje leto tri konference, ki bodo trajale dva in dvakrat po en dan. S tem konceptom nimam problema, vendar moramo vedeti, da bodo to povsem običajne konference, kot jih imajo povsod po svetu, da ne bomo imeli nič posebnega.

Med samo konferenco sem stalno dobival prispodobo ladje Titanic. Orkester igra, mi se pa potapljamo. Vsak večer zabava z neomejenimi količinami pijače in hrane, ogromna izbira hrane med kosilom, dragi nahrbtniki, in tako naprej. Kot da ne bi bilo nobene krize. Ampak za to ne krivim Microsoft. Glede na pretekle izkušnje je bilo vedno ogromno negodovanja s strani udeležencev, če ni bilo nahrbtnika ali pa majice. Vedno se je tudi našel nekdo, ki mu ni bila všeč hrana. Kot da doma je samo kaviar in pije šampanjec. Meni gre po glavi primerjava na tiste, ki se vedno pritožujejo glede glasbe, doma pa plešejo na poročila. Letos so bile poleg rednih pritožb na tapeti še dodatne. Letos je marsikoga motila lokacija, predvsem dejstvo, da so bila predavanja na dveh lokacijah, v dveh hotelih. Brez vsakega razumevanja za dejstvo, da je za polovico ljudi nemogoče plačati tako drago lokacijo, kot je bila v Portorožu. In ne glede na čudovito okolje, ki ga ponuja Bled, in ki je precej bolj unikatno kot je pač eno od tisočih mediteranskih letovišč.

Kot primer naj navedem komentar, ki sem ga imel priložnost prebrati na FB. Pod sliko kremne rezine je nekdo komentiral »In to je to za € 800…«. No, če hodite na konference samo zaradi žrtja in pitja, potem to res ni to. Pa čeprav ste lahko ob kosilu požrli neomejeno količino kremnih rezin, a se to ni zdelo vredno omeniti nikomur. No, seveda v treh dnevih ne morete požreti kremnih rezin za € 800. Svetujem vam, da denar raje zapravite v gostilnah. Bistvo konference je v druženju, v izobraževanju, v sklepanju poznanstev… Človek bi rekel, da je glavna vrlina premnogih udeležencev preprosto požrešnost.

Požrešnost se žal kaže še drugod. Microsoft Slovenija je že tretjič odpeljal vse udeležence, ki se kitijo z nazivom CIO, na posebno lokacijo. Pri tem so bili managerji mnogih IT podjetij izvzeti. To se je zgodilo že tretjič, čeprav smo sponzorji in predavatelji dali zelo negativno mnenje o tem. Za nas namreč konferenca precej izgubi smisel, če mi ne moremo do ljudi, s katerimi bi lahko sklepali posle. Kot da bi Microsoft Slovenija hotel požreti ves posel, kar ga še je v slovenski IT industriji, in odžreti vse svojim obstoječim partnerjem. Kot da ne bi bil eden temeljev uspeha Microsoft-a ravno odlična partnerska mreža. Rezultat je na dlani – količina sponzorjev in vrednost sponzorstev se že manjša. Pa ne samo zaradi krize! Spet požrešnost.

Še ena požrešnost je v igri. Povsod po svetu, kjerkoli sem bil, so bile cene nočitev v hotelih znižane za udeležence konference. Saj to je vendar normalno, če ne zaradi drugega, že preprosto zaradi količine. No, v Sloveniji očitno to ne dela. Tako kot že prej v Portorožu, so tudi na Bledu hoteli ceno dvignili dan pred konferenco in jo spustili dan po konferenci. Sem preveril, imam dokaze. Torej, preprosto, vse skupaj nas lupijo še hoteli. Za Portorož je bilo to vsaj malo logično, saj 2.000 ljudi na konferenci ne more gostiti nobena druga lokacija v Sloveniji, čeprav je še vedno požrešno in neprimerno. Za Bled mi je pa to dejstvo malo manj razumljivo. Zaradi požrešnosti bodo sigurno imeli precej manj nočitev v prihodnosti.

Ne vem, morda razmišljam naivno. Ampak sprašujem se, ali v tej državi res ni mogoče narediti nekaj skromnega, času primernega? Ali ne bi mogli narediti konference s poceni hrano, malo zastonj pijače (npr. kupona za dve pivi) in možnostjo, da si pijačo naprej plačujemo sami, brez nahrbtnika, ter z resnično nižjimi cenami hotelskih storitev? Ali ne bi bilo bolje previhariti težke čase in skušati ohraniti tisto, kar je dobrega, namesto vse do konca požreti in nato potoniti?

Kar se mene tiče, že vem, kaj bom odgovoril tujcem, ko me bodo vprašali, kaj se dogaja z NT konferenco. Odgovoril bom, da smo imeli najboljšo konferenco na svetu, vendar smo jo preprosto požrli.

Rendimiento con índices columnares

Rubén Garrigós — 2013-04-26T21:05:01+02:00

Los índices columnares son un nuevo tipo de índices disponibles en SQL Server 2012 que incorporan el almacenamiento columnar al motor relacional.

Dejando de lado los múltiples inconvenientes y limitaciones de estos índices, voy a centrarme en analizar el impacto de rendimiento teniendo en cuenta los puntos clave que se destacan de este tipo de índices:

- Solo las columnas necesarias para la consulta son accedidas.

- Las columnas están comprimidas lo cual reduce la cantidad de lecturas

- El plan de ejecución en batches reduce el consumo de CPU

Vamos a utilizar la base de datos AdventureWorksDW2012 y comenzaremos por analizar el índice columnar que viene como ejemplo en BOL:

CREATE NONCLUSTERED COLUMNSTORE INDEX [csindx_FactResellerSales]
ON [FactResellerSales]
(
    [ProductKey],
    [OrderDateKey],
    [DueDateKey],
    [ShipDateKey],
    ResellerKey,
    [EmployeeKey],
    [PromotionKey],
    [CurrencyKey],
    [SalesTerritoryKey],
    [SalesOrderNumber],
    [SalesOrderLineNumber],
    [RevisionNumber],
    [OrderQuantity],
    [UnitPrice],
    [ExtendedAmount],
    [UnitPriceDiscountPct],
    [DiscountAmount],
    [ProductStandardCost],
    [TotalProductCost],
    [SalesAmount],
    [TaxAmt],
    [Freight],
    [CarrierTrackingNumber],
    [CustomerPONumber],
    [OrderDate],
    [DueDate],
    [ShipDate]
);

Podemos ver que pese a ser un índice no cluster, han incluido todas las columnas de la tabla. La razón que gana peso para esta decisión es que únicamente podemos tener un índice columnar por tabla.

Si lanzamos una consulta que el optimizador considera apropiada veremos como el nuevo operador ColumnStore IndexScan entra en juego:

SELECT SalesTerritoryKey, SUM(ExtendedAmount) AS SalesByTerritory
FROM FactResellerSales
GROUP BY SalesTerritoryKey;

Si comparamos la estimación de costes de esta consulta comparada con otra en la que forzamos el uso del índice cluster vemos que, efectivamente, el uso del índice columnar parece ser mucho más eficiente:

Si comparamos los tiempos de ejecución vemos que la consulta con el índice columnar es más rápida, realiza menos lecturas y consume menos CPU:

(10 row(s) affected)
Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'FactResellerSales'. Scan count 1, logical reads 49, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

SQL Server Execution Times:
CPU time = 16 ms, elapsed time = 17 ms.

(10 row(s) affected)
Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'FactResellerSales'. Scan count 1, logical reads 2982, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

SQL Server Execution Times:
CPU time = 31 ms, elapsed time = 26 ms.

Veamos qué ocurre si creamos un índice de cobertura sobre las columnas utilizadas:

CREATE INDEX IX_SOLID ON FACTRESELLERSALES(SALESTERRITORYKEY,EXTENDEDAMOUNT)

En este caso, ya el optimizador nos estima que la operación con el índice de cobertura va a ser tanto o más rápida que con el índice columnar:

El resultado de la ejecución de esta última query muestra que estamos prácticamente a la par en el consumo de CPU y en la duración aunque el número de lecturas sigue siendo considerablemente mayor:

(10 row(s) affected)
Table 'FactResellerSales'. Scan count 1, logical reads 290, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

SQL Server Execution Times:
CPU time = 16 ms, elapsed time = 20 ms.

Si probamos estas mismas queries en un escenario de caché fría (DBCC dropcleanbuffers) veremos que la diferencia en tiempos aumenta a favor del índice columnar:

(10 row(s) affected)
Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'FactResellerSales'. Scan count 1, logical reads 52, physical reads 3, read-ahead reads 71, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

SQL Server Execution Times:
CPU time = 16 ms, elapsed time = 22 ms.

(10 row(s) affected)
Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'FactResellerSales'. Scan count 1, logical reads 2982, physical reads 2, read-ahead reads 2972, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

SQL Server Execution Times:
CPU time = 31 ms, elapsed time = 93 ms.

(10 row(s) affected)
Table 'FactResellerSales'. Scan count 1, logical reads 290, physical reads 0, read-ahead reads 287, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

SQL Server Execution Times:
CPU time = 16 ms, elapsed time = 33 ms.

Otro factor que debemos considerar es que también es posible comprimir los índices no columnares mediante compresión de fila o de página. Veamos que ocurre cuando comprimimos el índice cluster y el índice de cobertura con compresión de página:

ALTER INDEX [ix_solid] ON [dbo].[FactResellerSales] REBUILD PARTITION = ALL WITH
(PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON,
DATA_COMPRESSION = PAGE)
GO
ALTER INDEX [PK_FactResellerSales_SalesOrderNumber_SalesOrderLineNumber] ON [dbo].[FactResellerSales] REBUILD PARTITION = ALL WITH
(PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON,
DATA_COMPRESSION = PAGE)
GO

Con compresión activa los resultados con caché fría son los siguientes:

(10 row(s) affected)
Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'FactResellerSales'. Scan count 1, logical reads 52, physical reads 4, read-ahead reads 71, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

SQL Server Execution Times:
CPU time = 16 ms, elapsed time = 23 ms.

(10 row(s) affected)
Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'FactResellerSales'. Scan count 1, logical reads 370, physical reads 0, read-ahead reads 358, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

SQL Server Execution Times:
CPU time = 47 ms, elapsed time = 43 ms.

(10 row(s) affected)
Table 'FactResellerSales'. Scan count 1, logical reads 92, physical reads 1, read-ahead reads 90, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

SQL Server Execution Times:
CPU time = 16 ms, elapsed time = 33 ms.

Vemos que la compresión nos ayuda a reducir las lecturas y el tiempo total en el caso del índice cluster mientras que en el índice de cobertura, al ser menos páginas a leer, realmente la diferencia no es apreciable.

Para poder apreciar un poco mejor las diferencias de tiempos y de consumos de CPU vamos a inflar un poco la tabla ejecutando 5 veces este insert que duplica el número de registros con cada ejecución:

insert into FactResellerSales
SELECT [ProductKey]
      ,[OrderDateKey]
      ,[DueDateKey]
      ,[ShipDateKey]
      ,[ResellerKey]
      ,[EmployeeKey]
      ,[PromotionKey]
      ,[CurrencyKey]
      ,[SalesTerritoryKey]
      ,(select count(*) from [FactResellerSales]) + row_number() over (order by SalesOrderNumber)
      ,[SalesOrderLineNumber]
      ,[RevisionNumber]
      ,[OrderQuantity]
      ,[UnitPrice]
      ,[ExtendedAmount]
      ,[UnitPriceDiscountPct]
      ,[DiscountAmount]
      ,[ProductStandardCost]
      ,[TotalProductCost]
      ,[SalesAmount]
      ,[TaxAmt]
      ,[Freight]
      ,[CarrierTrackingNumber]
      ,[CustomerPONumber]
      ,[OrderDate]
      ,[DueDate]
      ,[ShipDate]
FROM [dbo].[FactResellerSales]
go 5

Ahora que tenemos ya casi 2 millones de filas volveremos a recrear el índice columnar (tuvimos que borrarlo para poder insertar datos) y desfragmentaremos el resto de índices. Repetiremos las pruebas realizadas anteriormente con caché fría y caliente así como con compresión o sin compresión de página.

Al aumentar el número de registros vemos que las tres operaciones se ejecutan con planes paralelos:

La siguiente tabla resume los valores obtenidos:

Ahora vamos a testear otra consulta que, en principio, parece muy óptima también para un índice columnar, un cálculo de un total acumulado:

La primera diferencia que vemos es que no se está considerando un plan paralelo para el índice columnar. La siguiente tabla resume los valores obtenidos:

Podemos ver que en este escenario el índice columnar ha ofrecido peores tiempos de respuesta. Desgraciadamente el trace flag no documentado 8649 no nos ayuda en este caso ya que parece no afectar a los planes con índices columnares. Si modificamos manualmente el “cost threshold for parallelism” y lo disminuimos, podemos obtener un plan paralelo con un tiempo de respuesta comparable con el del índice de cobertura:

Table 'FactResellerSales'. Scan count 7, logical reads 744, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

SQL Server Execution Times:
CPU time = 547 ms, elapsed time = 195 ms.

Por tanto podemos extraer las siguientes conclusiones:

* Los índices columnares son más eficientes cuanta más lectura física se ve obligado el servidor a ejecutar para resolver la consulta. El algoritmo de compresión del columnar es bastante más eficiente que el algoritmo de compresión de página.

* Con la tendencia a mayor cantidad de memoria en los servidores no es inusual ver servidores con 512 GB o más de memoria. Esto hace que el porcentaje de acierto de página sea muy elevado. En este escenario, un índice de cobertura puede ser más eficiente que un columnar para algunas consultas que utilizan agregados

* En base a los resultados obtenidos consideramos que una estrategia mixta podría dar los mejores resultados que una que se incline solo hacia una alternativa.

Esta estrategia mixta consistiría en el uso de una tabla particionada + indices columnares (para datos históricos, de solo lectura) junto a una tabla no particionada con índices no columnares (para datos no históricos, de lectura/escritura). Ambas tablas podrían unificarse en una única vista para facilitar las consultas que accedan tanto a datos históricos como a datos no históricos.

La parte histórica contaría con un conjunto reducido de índices no columnares (índice cluster, PK e índices no clustered imprescindibles) más un índice columnar que incluya todas las columnas que se utilicen en consultas históricas. La parte no histórica contaría con el conjunto de índices necesarios para la operativa no histórica (índice cluster, PK, índices sobre FKs y todos índices no clustered necesarios).

Pröva partitionering i SQL

Joel Sjöö — 2013-04-24T18:48:07+02:00

Hade en kund som ville använda en enkel partitionering utav en av sina stora tabeller som nästan enbart innehåller historiskt data. Oftast är det endast den senaste månadens data som är aktuellt men man behöver ibland kunna komma åt det som är äldre. Jag beslöt att testa att göra det så enkelt som möjligt. Vi delade upp tabellen i nytt data och historik data. För respektive data så skapade vi en filegroup med en fil per grupp. Varje månad flytta vi sen datat från nytt till historisk. Nedan är ett exempel.

Vi börja med att lägga till ett par filgrupper.

ALTER DATABASE Test

ADD FILEGROUP FG_New;

ALTER DATABASE Test

ADD FILEGROUP FG_Historical;

ALTER DATABASE Test

ADD FILE

(

NAME = FG_New_Data1,

FILENAME = 'C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\FG_New_Data1.ndf',

SIZE = 5MB,

FILEGROWTH = 5MB

)

TO FILEGROUP FG_New;

ALTER DATABASE Test

ADD FILE

(

NAME = FG_Historical_Data1,

FILENAME = 'C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\FG_Historical_Data1.ndf',

SIZE = 5MB,

FILEGROWTH = 5MB

)

TO FILEGROUP FG_Historical;

Skapa en partition funktion, i detta fall en range för datum. Nyare än 2013-01-01 hamnar i filgrupen FG_New, äldre hamnar i filgruppen FG_Historical.

CREATE PARTITION FUNCTION TestRange(DATETIME)

RANGE right FOR VALUES ('2013-01-01')

Skapa ett partition schema som knyter mot funktionen och pekar ut vilka filgrupper som skall användas

CREATE PARTITION SCHEME TestRangeScheme

PARTITION TestRange

TO ([FG_Historical], [FG_New])

Skapa sedan en tabell enligt nedan för att passa detta test. Obsavera att vi skapar den på Partition Schemat TestRangeScheme samt ange datum kolumnen som värde.

CREATE TABLE [dbo].[testa](

[id] [int] IDENTITY(1,1),

[datum] [datetime] NOT NULL,

[namn] [nvarchar](50) NULL

) ON TestRangeScheme(datum)

Vi laddar in lite testdata för att kunna se hur datat delar upp sig. Kör en enkel kodsnurra som laddar in 100000 rader.

declare @i int

set @i = 0

begin transaction

while (@i < 100000)

begin

insert into [Testa]

values (cast('20120101' as datetime) + rand() * 420, 'AAAAAAAAAAAAAA')

set @i = @i + 1

end

Commit

I vårt fall så fördelade sig raderna så här:

Partition1 FG_Historical	87216 rows in 598 pages
Partition2, FG_New	12784 rows in 88 pages

För att vara säker på att datat verkligen hamnade på önskad filgrupp också så kika vi med DBCC CHECKFILEGROUP (2, NOINDEX) på respektive filgrupp för att se att det stämmer. Resultatet hade vi ovan och allt verka stämma som det är tänkt.

Nu till att flytta datat när det blir ny månad.

Först merga vi den range vi hade satt upp innan.

ALTER PARTITION FUNCTION TestRange () MERGE RANGE ('20130101');

Vi gör en next used för vilken filegroup som skall användas.

ALTER PARTITION SCHEME TestRangeScheme NEXT USED FG_New;

Sedan splittar vi våran range på den nya månaden.

ALTER PARTITION FUNCTION TestRange() SPLIT RANGE ('20130201');

För att kontrollera att det ser rätt ut så använder jag åter DBCC CHECKFILEGROUP (2, NOINDEX) för att titta på respektive filgroupp.

Partition1, FG_Historical	94514 rows in 682 pages
Partition2, FG_New	5486 rows in 37 pages

Vad har vi då för nytta av att partitionera upp en tabell?

Under mina tester där jag jämförde med och utan partitionering på en tabell på ca 150 miljoner rader och en storlek på ca 150GB så gjorde det stor skillnad på hur mycket data som lästes. I mitt exempel så partitionerade jag tabellen liknande så som jag gjort ovan i exemplet. Senaste månadens data i en partition och resten i en annan filgrupp. Jag körde sedan en fråga som gjorde många Joins mot denna tabell. Enligt set statistics IO, så såg skillnaden i reads ut så här mellan tabellerna:

Table 'FactPortfolio'. Scan count 5, logical reads 15219075

Table 'PartFactPortfolio'. Scan count 5, logical reads 744625

Skillnaderna i TABLE SCAN på exekution planen är följande:

Ovan ser vi skillnader i Estimated I/O Cost tex. Vi ser också att frågan verkligen dra nytta av partitioneringen. Seek Predicates har pekat ut den partitionen där datat ligger som vi angett i where klausulen.

Vad få vi för skillnader i frågorna i tid mot tabellen då? Utan partition tog vår testfråga 6,05 min medans den partitionerade tog 1,12 min. Rätt stor skillnad skulle jag vilja påstå.

I mitt test så var frågan optimerad för partitioneringen, jag hade where klausulen satt på den partitionerade kolumnen. Det finns så klart tillfällen när det inte passa. Detta märkte jag också under mina tester. I vissa fall blev det faktiskt fler reads och längre tider. Så kontentan av det hela är att funktionen är bra och passa bra för mycket stora tabeller där man inte har behov att söka igenom allt data. Men testa innan man produktions sätter så man vet att det verkligen gör nytta.

/Joel

PASS SQL Saturday #196 Denmark

SolidQ — 2013-04-18T13:38:00+02:00

Hello everyone! I know it is probably a bit late to let you know about this event, but is it really too late?

There are 3 pre-cons available. World-renowned speakers and MVPs: Jen Stirrup, Mark Rasmussen and Denny Cherry. If you may wish to attend these pre-con sessions, register here.

PASS SQL Saturday Denmark, the main (free) event is going to be taking place on April 20 at Microsoft Denmark, Tuborg Boulevard 12, 2900 Hellerup. Gianluca Hotz, Régis Baccaro and Peter Larsson, colleagues from SolidQ are speakers of the #SQLsatDenmark. Let me introduce their sessions:

Gianluca Hotz | SQL Server 2012 AlwaysOn

Description: Business continuity is becoming more and more a central topic for many companies. AlwaysOn is the new solution for high availability and disaster recovery introduced with SQL Server 2012. With the help of live demos, in this session we will cover in details this new technology that extends on the familiar concepts of database mirroring and failover clustering. We will also introduce some other engine enhancements that will help raising the overall service availability.

Régis Baccaro | Database development with SSDT

Description: SQL Server Data Tools (SSDT) is a toolset that allows professional database and application developers to carry out all their database design work for SQL Server and SQL Azure within Visual Studio. SSDT provides a rich SQL Server development experience with first class language services and VS integration, as well as declarative, model-based tools that can be utilized for both online and offline development. In this session we'll dive into Online and Offline development as well as the Productivity and tools that the SSDT team keeps providing to us.

Peter Larsson | Remodel your old EAV design

Description: Sometimes you really need an EAV model. In most cases they are ugly and slow. After this session you will have gained new insights how to turn your old, slow, EAV model into a slim superfast model. There will be real life examples from a recent project. With the techniques displayed in the presentation, I cut the execution time down from 134 days down to 0.5 seconds and cut the storage need from 550GB to 45GB.

SQL Server 2000 är borta för gott?

Mikael Wedham — 2013-04-18T12:14:53+02:00

Enligt Microsoft Support är supporten för SQL Server 2000 fullständigt borta sedan den 9 april i år (2013).

Som ni kan se i tabellen finns inget datum längre fram än 2013-04-09, vilket innebär att det är officiellt slut. Det kommer alltså troligen inga fler uppdateringar, inga säkerhetsfixar och inga patchar längre – även om det skulle behövas.

Men den viktigaste aspekten är fortfarande att sedan 2008-04-08 har det inte funnits allmän support, och med det följer att det inte funnits något egentligt incitament för att hålla kunskapen om SQL 2000 cachad i sin hjärna. Det finns mycket få experter som behärskar SQL Server 2000, och ännu färre som vill hugga in och ta ansvar för en dylik server…

Byt ut den så fort som möjligt!

Visa Microsoft Lifecycle search...

Behöver du Performance Tuning eller Query Tuning?

Peter Larsson — 2013-04-18T11:05:57+02:00

Det är den stora frågan. Dessutom en aktuell sådan. Idag hade jag inte tänkt beskriva någon smart kod utan istället berätta om skillnader i sätt att angripa prestandaproblem.

Det senaste året har jag på konferenser, seminarier och utbildningstillfällen ofta blivit hejad på och hamnat i en diskussion om vad som behövs göras i ett system för att snabba upp applikationen som använder SQL Server som lagringsplattform. Mitt första svar blir oftast “Det beror på om du är DBA eller utvecklare.”.
Nästan undantagslöst ser jag då ett frågetecken hos frågeställaren som nu undrar om jag är riktigt klok i huvudet. För han eller hon vill ju bara ha ett svar på hur deras applikation ska gå snabbare!

Jag ställer ofta en uppföljningsfråga i stil med “Vad är det du upplever som ett bekymmer?”. Och efter ett litet tag med halmstrån som långa väntetider, deadlocks och IO-problem brukar det utkristallisera sig vad egentligen är som upplevs som ett problem. De flesta professionella DBA-er och utvecklare vet om att det som brukarna upplever som ett bekymmer oftast bara är symptomet på det verkligen problemet medan de med mindre erfarenhet koncentrerar sig på fel saker. De sätter helt enkelt bara ett plåster på tummen när det egentligen hade behövts gips på armen. Eller i värsta fall en full hjärt-, lever-, lung- och njur-transplantation. Där slutar mina liknelser för i den verkliga världen går det ännu inte att transplantera en hjärna men i vår digitala värld går det att åstadkomma.

För enkelhetens skull påstår jag att DBA-er vill ha Performance Tuning och utvecklare vill ha Query Tuning. När man arbetar med SQL Server behöver man ta hänsyn både till hårdvara och mjukvara och som överallt annars är det svårt att se allt i svart eller vitt. Det finns nästan alltid en gråzon någonstans där mittemellan. Det finns en stark koppling mellan Performance Tuning och hårdvara samt mellan Query Tuning och mjukvara.

Jag ska fortsätta med en annan liknelse för att göra det enklare att förklara den egentliga skillnadan mellan de både metoderna att angripa ett prestandaproblem. För det är just prestandan som i nästan alla fall är den gemensamma nämnaren på de problem som brukarna rapporterar.

Vi börjar med Performance Tuning eller hårdvaran. Låt oss säga att vi ärver en gammal Bubbla från Volkswagen. Det finns folk som verkligen vet hur man ska pimpa den till att bli så kraftfull som möjligt inom ramen för en budget. Dessa personer är DBA-er. De är ansvariga för att hålla kolla på så att det finns olja i motorn, kylvätska och spolarvätska. De kollar lufttryck i däcken och inställningarna för tändstiften. De servar och reparerar bubblan för att den ska vara i så bra trim som möjligt.

De kan byta ut motorn till en starkare motor om de tycker det behövs eller sätta på vinterdäcken när det är påkallat. De kollar mätarställningen och tvättar bilen. Vad jag vill illustrera är att DBA-er har en stor uppgift att underhålla och se till så att bubblan uppför sig som man kan förvänta sig. DBA-er är experter på detta.

Då uppkommer den logiska frågan, vad gör då en utvecklare eller Query Tuning? Jo, dessa är experter på mjukvaran. Det är utvecklarna som vet hur man ska få bubblan att köra så fort som möjligt inom ramen för den hårdvara som existerar. Det är de som väljer körväg och hur mycket som behövs lutas i kurvorna. Pressar de mjukvaran för mycket så kommer hårdvaran inte att hinna med. Det är detta som händer är oerfarna utvecklare skriver dålig kod som i sin tur genererar alldeles för mycket IO eller använder för många processorer eller cores än nödvändigt. Även om det är DBA-erna som bestämt hur stor tanken ska vara, är det utvecklarna som kan se till så att bilen bara drar 0,1 liter per mil istället för 13 liter per mil. Det är utvecklarnas kod som avgör om bilen kommer att gå i 700 km/h eller i 15 km/h.
Jag har arbetat med databaser i över 20 år. En enda gång har lösningen på ett prestandaproblem varit att köpa mer hårdvara, eller uppgradera den befintliga hårdvaran. All gånger, utom den gången, har lösningen varit att skriva bättre kod eller skapa bättre design i applikationen. Det är också så att det är den lösningen som ger mest valuta för pengarna. Dubblar du antalet processorer, mängden minne och dubblar IO på ditt SAN, kan du förvänta dig att applikationen går dubbelt så snabbt, till en hög kostnad. Men spendera någon eller några timmar med kod och design, och du får en prestandaökning som kan räknas i 100 elller 10 000 000 gånger bättre prestanda.

Och någonstans här mittemellan ska dessa två yrkesgrupper komma överens. Utvecklarna kommer med önskemål om att “Servern är lite långsam, kan ni sätta i mer minne?” på vilken DBA-n antingen svarat “Javisst kan jag göra det” eller “Nej, det behövs inte. Du har lika mycket minne som Facebook och Google tillsammans. Använd det du har på ett bättre sätt.”.

Det är inte helt enkelt att få dessa två yrkesgrupper att samarbeta då de har olika fokus. Men en sak har de trots allt gemensamt och det är att göra brukarna nöjda inom ramen för det ledningen tillhandahåller. Och det är därför jag fortsätter med att undervisa, presentera och prata om prestandaförbättringar för att underlätta för brukaren, för det är ändå de som ser till så att vi alla har ett jobb att sköta.

Ha det kul tills nästa gång vi ses!

//Peter

Diapositivas de Sesión de SQL Saturday Costa Rica

Javier Loria — 2013-04-15T22:07:34+02:00

Atendiendo la solicitud de un participante posteo las filminas de la sesión sobre TempDB ofrecida el pasado sábado 13 de abril en Costa Rica. EL nombre Es TEMPDB, por qué es tan importante?, todavía no termina de convencerme ya que me gustaría que fuera más atractivo.

Curso MS Business intelligence-SSAS: Personalizando el Modelo–Dimensiones (37)

Salvador Ramos — 2013-04-11T15:28:29+02:00

Personalizando el modelo de Analysis Services

Una vez introducidos los coneptos y elementos fundamentales, vamos a continuar profundizando en la creación de cubos y dimensiones, y sobre todo en la personalización de éstos y adaptación a las necesidades del negocio.

Dimensiones

Una vez vistos los datos a medir, pasemos a analizar las diferentes perspectivas desde las que los vamos a analizar. Vamos a conocer más a fondo esas dimensiones y sus características.

Las Dimensiones se basan en tablas o vistas del Data Source View. Se definen a nivel de base de datos, de forma independiente a los cubos. Y posteriormente, pueden instanciarse ninguna, una o varias veces en cada cubo. Por tanto pasaremos a explicar los conceptos de dimensiones de bases de datos y dimensiones de cubos.

Una dimensión de base de datos existe con independencia de que esté asociada o no a un cubo. Se basan en columnas de una o más tablas de dimensiones de nuestro Data Source View, que puede estar modelado en estrella (start) o en copo de nieve (snowflake).

Una dimensión de cubo es una instancia de una dimensión de base de datos en un cubo en particular, pudiendo tener varias instancias de ella, incluso en el mismo cubo. Por ejemplo, podemos tener una dimensión Tiempo a nivel de base de datos, y luego, en el cubo de Ventas, tener tres instancias: Fecha de pedido, Fecha de envío y Fecha de cobro. Esta múltiple instanciación es lo que se conoce como dimensión jugadora de roles (role-playing dimension). Cada instancia de una dimensión de base de datos puede tener propiedades distintas, por ejemplo, el nombre casi siempre lo cambiamos, tal y como hemos visto en el ejemplo anterior de la dimensión Tiempo, que juega los roles de Fecha de pedido, Fecha de envío y Fecha de cobro. Hay otras propiedades que también se pueden cambiar a nivel de dimensión de cubo, como su visibilidad (propiedad visible).

Figura 1: Dimensiones de Cubo y Dimensiones de Base de Datos

Algunas de las propiedades más significativas de las dimensiones son:

· AttributeAllMemberName. Podemos tener de manera opcional un nivel All, que está en la parte superior de la jerarquía y agrega todos los miembros del nivel inmediatamente inferior. Este es un miembro generado por el sistema, y su posible existencia dependerá de los valores que configuremos en la propiedad IsAggregatable, si se establece a True existirá un nivel All. Ese nivel podrá tener el nombre que indiquemos en la propiedad AttributeAllMemberName. Valores: el nombre que queramos que aparezca para ese nivel al navegar por la dimensión.

· WriteEnabled. Permite habilitar la dimensión para escritura. Valores: True, False.

· Type. Proporciona información a los servidores y a las aplicaciones cliente sobre el contenido de una dimensión. Se utiliza para agregar inteligencia de dimensiones a las aplicaciones. Valores: Regular, Time, Geography, Organization, BillOfMaterials, Accounts, Customers, Products, Scenario, Quantitative, Currency, Rates, Channel, Promotion. Estos valores se aplican a dimensiones y/o cubos.

· StorageMode. Indica el modo de almacenamiento de la dimensión. Valores: ROLAP, MOLAP.

· ErrorConfiguration. Indica la acción que realizará el servidor al encontrar diversos errores.

· UnknownMember. Permite especificar el tratamiento que recibirán los miembros desconocidos. Valores: Visible, Hidden, None.

· UnknownMemberName. Permite cambiar el valor predeterminado del miembro desconocido al que queramos. Por defecto el valor es Unknown.

· ProactiveCaching. Para la configuración del caché automático del cubo.

Si te interesa esta información, y deseas convertirte en un profesional altamente especializado en Microsoft Business Intelligence, te recomiendo que nos pidas información sobre nuestro Master en BI. Recuerda que hay poquitas plazas disponibles!!!

Post publicados anteriormente como parte de este curso:

CURSO Big Data, Data Science: Nuevos Tratamientos Avanzados de la información

SolidQ — 2013-04-11T15:06:00+02:00

Este curso, dirigido a profesionales del Análisis y Tratamiento de la Información, consultores, jefes de proyectos de BI y a responsables de sistemas de Información o Administradores de sistemas; se llevará a cabo los días 25 de Abril en Coruña y el 26 de Abril en Vigo.

Nuestro compañero Antonio Soto, será el formador de este curso orientado a que el asistente comprenda la diferenciación de la aplicación de las técnicas Big Data, análisis de memoria o de la Minería de Datos “tradicional”.

Temario

Introducción: La revolución de los datos.
o Big Data, Data Science y lo que nos pueden proporcionar.
o Actores de mercado en Big Data.
o Utilidades de Big Data.

Escenarios de Business Analytics.
o Análisis de gran cantidad de datos no estructurados: Microsoft HDInsight.
o Análisis de datos en memoria: Microsoft StreamInsight.
o Análisis en profundidad: SQL Server.
o Escenarios de Integración.

• ¿Y cómo exploto toda esta información?: Microsoft Excel
o PowerPivot.
o Complementos Excel para Minería de Datos.
o Acceso a Datos Hadoop.
o Data Explorer.

Para más información sobre este curso organizado por Vitae Consultores puedes descargarte el folleto en este enlace.

SQL Server & Business Intelligence Conference 2013 - Milan

SolidQ — 2013-04-10T18:55:00+02:00

The most important technical conference in Italy, the “SQL Server & BI Conference 2013” will be held in Milan during May 28-29. During these days, SQL Developers, SQL DBAs, BI Professionals and Excel Power Users will gather up to learn as much as they can about SQL Server and BI.

There are four SolidQ Mentors speaking:

Danilo Dominici – “SQL Server 2012 Virtualization Best Practices"

Francesco De Chirico - “Monitoring MDX Queries in Analysis Services

Davide Mauri – “Integration Services 2012: Automating DWH Patterns through Metadata” and “Query Optimizer and Data Distribution Statistics”

Gianluca Hotz – “SQL Server Security in a vulnerable world” and “PowerShell for SQL DBA”

See you in Milan!

Follow our blogs to read more about technical information and tips.

Enkel funktion för att dela upp en sträng

Peter Larsson — 2013-04-06T18:08:37+02:00

Det finns flera fall där man behöver dela upp en sträng i flera delar. En anledning kan vara att man behöver en flexibel parameter till en lagrad procedur. En annan kan vara att man arbetar med en tabell som inte är normaliserad.

Jag påträffade en annan sorts problem i vintras när jag arbetade med en stor kund. Deras applikation lämnade ifrån sig en sträng till databasen och strängens innehåll var beroende på vad användarna gjort för val i klienten med hänsyn till checkboxar, fritextrutor och annat. Dessa värden skulle sedan in till en lagrad procedur för att bygga ihop en dynamisk fråga. Jag lyckades till slut att göra proceduren 10 000 000 gånger snabbare och en av faktorerna (förutom omdesign av datamodellen) var att hantera den sträng som kom från klienten på ett effektivt sätt som möjligt. Vill du veta mer om listor i SQL Server kan du läsa här http://www.sommarskog.se/arrays-in-sql.html.

Som de flesta vet är just hantering av strängar inte en av SQL Servers styrkor. Men det finns sätt att göra det effektivt på! Vad jag kommer att visa nu är en funktion som hanterar multipla attribut med flerval samt wildcard.

Ett typisk strängvärde kan se ut som “PersonID=201304061234“. Vad den informationen betyder är att kolumnen PersonID ska vara lika med det personnummer som skickades med. Det här är ganska trivialt att dela upp med T-SQL. Strängen kan också se ut så här “Utbildningsnivå=Kandidat|Stad=Malmö”. De olika attributen kan alltså vara uppdelade med ett pipe-tecken.

I min kunds fall visade det sig dessutom att det finns flera olika klienter som anropade den aktuella proceduren. Från en klient kan strängen se ut så här “Medlemskap=Guld|Medlemskap=Silver|Inkasso=Nej” medan den kan se ut så här “Medlemskap=Guld,Silver|Inkasso=Nej” från en annan klient. Till en början innebar det naturligtvis en utmaning men när du tittar närmare på de kombinationer som finns, uppdagar ett mönster sig.

De olika attributen är uppdelade med “|”
Attribut och värde är uppdelat med “=”
Flervalsmöjligheter är uppdelade med “,”

Finns det ett samband mellan de fyra olika stränginnehållen ovan? Ja, det finns det faktiskt. Om vi börjar i andra ändan, dvs med det slutresultat vi vill ha, så syns det ganska tydligt.

Attribut	Värde
PersonID	201304061234

Attribut	Värde
Utbildningsnivå	Kandidat
Stad	Malmö

Attribut	Värde
Medlemskap	Guld
Medlemskap	Silver
Inkasso	Nej

Aha! Det som ska göras är en normalisering av stränginnehållet. När denna insikt lagt sig startade jag att fundera på hur man på enklast möjliga sätt ska skriva en rutin för att dela på strängen på det önskade viset. Redan i planeringsstadiet föll en iterativ process bort, mest med tanke på komplexiteten att hantera komma eller inte komma och när kommer pipen. Likamedtecknet är det enklaste i detta fallet.

Precis om jag redovisade ovan gjorde jag också på papper hos kunden. När jag brottades med hur jag skulle likställa attributet Medlemskap mellan de olika klienterna insåg jag att en OUTER APPLY skulle göra hela skillnaden! Och då föddes tanken med att skriva funktionen som en Inline Table-Valued Function (IVTF) för absolut bästa prestanda. För att underhållet av funktionen skulle krävas ett minimum av specialkunskaper valde att jag att arbeta med XML.

Första åtgärden var att dela upp strängen med pipetecknet för att separera de olika attributen. Vad jag ville åstadkomma var ett XML-dokument som såg ut så här

<r>
<c>Medlemskap=Guld,Silver</c>
</r>
<r>
<c>Inkasso=Nej</c>
</r>

Den biten är ganska lätt. Jag gjorde en REPLACE på “|”till de olika xml-elementen med hjälp av den här statementet

SELECT CAST('<r><c>' + REPLACE(@AttributeList, '|', '</c></r><r><c>') + '</c></r>' AS XML)

Men det är inte tillräckligt. Jag vill ju även dela upp strängen i attribut och värden som olika kolumner. Det kan vi göra genom att lägga till en extra REPLACE i samma statement! Då ser statementet ut så här

SELECT CAST('<r><c>' + REPLACE(REPLACE(@AttributeList, '|', '</c></r><r><c>'), '=', '</c><c>') + '</c></r>' AS XML)

och producerar ett XML-dokument som ser ut så här

<r>
<c>Medlemskap</c>
<c>Guld,Silver</c>
</r>
<r>
<c>Inkasso</c>
<c>Nej</c>
</r>

Vid en första anblick kan det se konstigt ut att jag benämner de båda kolumnerna som “c”. Tänk då på att vi arbetar med XML och vi kan särskilja dessa med deras inbördes positioner. Detta är i normala fall inget som ska ha en betydelse men för den här funktionen måste det ha en betydelse då vi inte vet om det ens finns ett värde för attributet.

Sätter vi ihop statementet till en fungerande fråga som ska fungera som bas för funktionen får vi skriva en wrapper och hantera utdatat som XML.

SELECT d.Data
FROM   (
              VALUES (CAST('<r><c>' + REPLACE(REPLACE(@AttributeList, '|', '</c></r><r><c>'), '=', '</c><c>') + '</c></r>' AS XML))
       ) AS d(Data)

I detta läge vill vi omvandla XML-dokumentet i mindre dokument, eftersom varje nod “r” ska bli en minst en rad i resultatsetet. Det gör vi genom att dela upp XML-dokumentet med en CROSS APPLY. Här kan vi använda CROSS APPLY eftersom det måste finnas minst en nod “r” för annars är XML-dokumentet tomt.

SELECT        r.n.query('.')
FROM          (
                     VALUES (CAST('<r><c>' + REPLACE(REPLACE(@AttributeList, '|', '</c></r><r><c>'), '=', '</c><c>') + '</c></r>' AS XML))
              ) AS d(Data)
CROSS APPLY   d.Data.nodes('(r)') AS r(n)

Nu har vi två XML-dokument som ser ut så här

<r>
<c>Medlemskap</c>
<c>Guld,Silver</c>
</r>

<r>
<c>Inkasso</c>
<c>Nej</c>
</r>

Nu kommer det att bli lite svårare eftersom vi ska kontrollera om värdet är ett flerval genom att dela upp nod “c” i två delar igen. Och här får vi ju inte dela upp attributet med hjälp av komma! För att särskilja de två noderna “c” mellan attribut och värde använder vi deras inbördes ordning med hjälp av xquery-noteringen “[]”.

SELECT        r.n.query('.'),
              f.n
FROM          (
                     VALUES (CAST('<r><c>' + REPLACE(REPLACE(@AttributeList, '|', '</c></r><r><c>'), '=', '</c><c>') + '</c></r>' AS XML))
              ) AS d(Data)
CROSS APPLY   d.Data.nodes('(r)') AS r(n)
CROSS APPLY   (
                     VALUES (CAST('<r>' + REPLACE(r.n.value('(c[2])', 'VARCHAR(MAX)'), ',', '</r><r>') + '</r>' AS XML))
              ) AS f(n)

Detta statement ger ett resultatset som har två kolumner

<r><c>Medlemskap</c><c>Guld,Silver</c></r> <r>Guld</r><r>Silver</r>
<r><c>Inkasso</c><c>Nej</c></r> <r>Nej</r>

Vad vi nu behöver är en sista uppdelning på den andra kolumnen och dela upp noderna “r”. Denna gång använder vi OUTER APPLY eftersom vi inte vet om det ens finns ett värde för attributet.

SELECT        r.n.query('.'),
              f.n,
              x.n.query('.')
FROM          (
                     VALUES (CAST('<r><c>' + REPLACE(REPLACE(@AttributeList, '|', '</c></r><r><c>'), '=', '</c><c>') + '</c></r>' AS XML))
              ) AS d(Data)
CROSS APPLY   d.Data.nodes('(r)') AS r(n)
CROSS APPLY   (
                     VALUES (CAST('<r>' + REPLACE(r.n.value('(c[2])', 'VARCHAR(MAX)'), ',', '</r><r>') + '</r>' AS XML))
              ) AS f(n)
OUTER APPLY   f.n.nodes('(r)') AS x(n)

OUTER APPLY gör att vi nu får tre rader i resultatsetet (Andra och tredje kolumnen)

<r>Guld</r><r>Silver</r>   <r>Guld</r>
<r>Guld</r><r>Silver</r>   <r>Silver</r>
<r>Nej</r>                 <r>Nej</r>

Nu är det klart och vi kan skriva funktionen så här

CREATE FUNCTION dbo.fnTokenizeAttributes
(
    @AttributeList VARCHAR(MAX)
)
RETURNS TABLE
AS
RETURN (
            WITH cteAttributes(KeyType, KeyValue)
            AS (
                    SELECT          ISNULL(r.n.value('(c[1])', 'VARCHAR(48)'), '') AS KeyType,
                                    ISNULL(x.n.value('(text()[1])', 'VARCHAR(512)'), '') AS KeyValue
                    FROM            (
                                        VALUES (CAST('<r><c>' + REPLACE(REPLACE(@AttributeList, '|', '</c></r><r><c>'), '=', '</c><c>') + '</c></r>' AS XML))
                                    ) AS d(Data)
                     CROSS APPLY    d.Data.nodes('(r)') AS r(n)
                     CROSS APPLY    (
                                         VALUES (CAST('<r>' + REPLACE(r.n.value('(c[2])', 'VARCHAR(MAX)'), ',', '</r><r>') + '</r>' AS XML))
                                    ) AS f(n)
                     OUTER APPLY    f.n.nodes('(r)') AS x(n)
               )
               SELECT DISTINCT LTRIM(RTRIM(KeyType)) AS KeyType,
                               LTRIM(RTRIM(KeyValue)) AS KeyValue
               FROM            cteAttributes
               WHERE           LTRIM(RTRIM(KeyType)) > ''
        )
GO

Vad jag också gjorde i funktionen var att sätta saknade kolumner med NULL-värde till tomsträng. Detta gör jag eftersom det kan finnas attribut utan värden. Dessutom kontrollerar jag att inga rader med tomma attribut returneras samt tar bort alla dubbletter.

TypeScript en SharePoint 2013

Roberto Ramón Berna — 2013-04-03T12:03:18+02:00

Muy buenas;

hace algún tiempo que salió TypeScript y desde el mismo momento que salió he intentado buscar el hueco para indagar sobre él, hoy ha llegado ese día .

Para empezar vamos a hacer una introducción sobre TypeScript.

¿Qué es TypeScript?

Lo primero que hay que tener claro para responder a esta pregunta, es que TypeScript no es un nuevo lenguaje de programación. Podríamos decir que TypeScript es una mejora o una extensión de JavaScript que nos aporta la posibilidad de utilizar tipado estático para organizar mucho mejor nuestro código. ¿Cuántas veces hemos visto un archivo .js con unas cientos de líneas y nos hemos puesto a temblar para entenderlas?, pues para ahorrarnos ese mal rato ha surgido TypeScript, para hacernos ganar en mantenibilidad, es decir, para generar un código mucho más fácil de leer.

Es importante saber que dicho tipado no es obligatorio de utilizar, podremos utilizarlo cuando lo consideremos oportuno o mejor dicho, cuando de verdad nos resulte de utilidad. El código JavaScript podrá convivir en un fichero escrito en TypeScript sin problemas. Un archivo TypeScript tiene una extensión .ts (TypeScript), el cual es necesario compilar para transformar este tipado a JavaScript plano (con el que estamos acostumbrados a trabajar). La gran ventaja de que se compile a JavaScript plano, es que funcionará en todos los navegadores y podremos utilizar en nuestro código una estructura basada en clases y módulos, siguiendo el modelo de la programación orientada a objetos.

¿Cómo lo integro en SharePoint 2013?

Lo primero que debemos hacer, es instalar el plugin de TypeScript para poder agregar a nuestro proyecto un archivo con extensión .ts. (Este ejemplo está hecho con la versión 0.8.0.0)

Para demostrar dicha integración, crearemos una SharePoint-Hosted App.

Dentro del módulo “Scripts” que se autogenera con el proyecto, añadimos el archivo TypeScript.

Como comentábamos antes, el archivo con extensión .ts por debajo es un archivo .js.

Al añadir el archivo TypeScript, éste se crea con un éjemplo de código por defecto, aquí podeís ver las semejanzas. (En este post no explicaremos código)

También tendremos Intellisense en nuestro archivo .ts.

Es importante tener en mente, que nosotros vamos a trabajar con el archivo .ts, pero en realidad a la hora de lanzar la aplicación lo que se hace es compilar el archivo .ts generando uno .js. Para que todo vaya más rodado, necesitamos que esta compilación la haga automáticamente nuestro proyecto de Visual Studio, para ello tendremos que modificar el .csprog.

Inicialmente haremos el unload del proyecto, botón derecho sobre el proyecto y elegimos la opción “Unload Project”.

Volvemos a hacer click con el botón derecho sobre el proyecto y seleccionamos la opción “Edit SP-TypeScript-App.csprog” para editar el archivo .csprog.

Tendremos que añadir el parámetro InitialTargets a la etiqueta Project, que quedaría de la siguiente forma

<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" InitialTargets="TypeScriptCompile">

Justo antes de cerrar la etiqueta Project, tendremos que añadir también este código

  <Target Name="TypeScriptCompile" BeforeTargets="Build">
    <Message Text="Compiling TypeScript..." />
    <Exec Command="&quot;$(PROGRAMFILES)\Microsoft SDKs\TypeScript\0.8.0.0\tsc&quot; -target ES5 @(TypeScriptCompile ->'&quot;%(fullpath)&quot;', ' ')" />
  </Target>

Con esto ya tendríamos todo lo necesario para realizar la compilación del archivo TypeScript automáticamente. Guardamos y hacemos un “Reload Project”. Ahora si introducimos código en el archivo TypeScript y hacemos un “Rebuild” veremos que el archivo TypeScript se compila automáticamente poblando nuestro archivo JavaScript. Para completar el ciclo, el último paso que nos queda es añadir nuestro archivo JavaScript a la página.

<script type="text/javascript" src="../Scripts/ArchivoTypeScript.js"></script>

Como apunte final, se de buena tinta que es complicado dedicar tiempo en aprender “mejores” formas de hacer las cosas…lo de siempre, se quiere rápido y para antes de ayer, pero si de verdad os dan la oportunidad, yo no me lo pensaría para adentrarme en el mundo TypeScript. Más adelante en otro post, entraremos más en detalle en el propio código TypeScript y veremos hasta donde podemos llegar con ello en SharePoint.

Un saludo SharePointeros !!

Build 2013 - WOW

Ken Spencer — 2013-04-02T23:27:56+02:00

Its interesting to read the news and see all the negative stuff about Microsoft. Most of the writes don’t know what the real world is all about just like the reporters on the news.

For a read on how important Windows and other Microsoft technologies is, check out this: http://www.zdnet.com/microsofts-build-2013-conference-sells-out-in-under-three-hours-7000013411/

The 2013 Microsoft Build conference sold out in 3 hours. In 2012 it sold out in under 1 hour. So 3 and 1 is not bad. Specially since they have a bigger venue now. So Windows Phone 8 and Windows 8 plus XBOX and of course Windows Azure are really driving things.

Borrando nuestras huellas

Rubén Garrigós — 2013-03-31T13:04:33+02:00

En ocasiones especiales cuando necesitamos acceso a bajo nivel a SQL Server no nos queda otra alternativa que realizar modificaciones directas en los catálogos de sistema. La posición oficial de Microsoft es que este tipo de operaciones no están soportadas (salvo que las realice directamente alguno de sus técnicos de soporte). Es probable que si necesitamos abrir un caso con soporte un ingeniero compruebe si hemos realizado modificaciones en las tablas de sistema.

La base de datos master es una base de datos dinámica, donde existen cambios de forma frecuente, por lo que no podría comparar el fichero original con un fichero de referencia. Por tanto para detectar cambios en las tablas de sistema se recurre al comando no documentado DBCC DBINFO.

Para poder ver el resultado de este comando primero habilitaremos la salida de los comandos DBCC al cliente con DBCC TRACEON (3604) y luego ejecutaremos el comando DBCC DBINFO:

Tras lanzar el comando en nuestra base de datos master vemos que el valor de dbi_updSysCatalog es una fecha cuyo valor es el siguiente “1900-01-01 00:00:00.000”. Esto indica que no se ha realizado ningún cambio en las tablas de sistema y, por lo tanto, “estamos limpios” y no tendremos problemas en caso de soporte por este tema.

Imaginemos ahora que por alguna razón muy justificada necesitamos realizar algún cambio en las tablas de sistema. Si después de dicho cambio lanzamos de nuevo el comando DBCC DBINFO veremos que la fecha dbi_updSysCatalog se actualiza a la fecha en la que hemos realizado la modificación:

Debido a que no disponemos de ningún comando que directamente nos permita resetear este valor, debemos investigar dónde se almacena dicho valor. Este valor es un valor “portable”, es decir, que si realizamos un backup de la base de datos y lo restauramos en otro servidor sigue persistiendo. Por tanto dicha información debe almacenarse con alta probabilidad dentro de los ficheros de la base de datos.

¿Dónde tendría sentido que se almacenara? Muy probablemente en alguna de las páginas de metadatos que existen al principio de los ficheros de la base de datos. En concreto tendría sentido que estuviera en el fichero primario de la base de datos.

Con el comando DBCC PAGE podemos extraer información de las páginas de nuestra base de datos. El comando DBCC PAGE se encuentra bastante documentado por lo que no nos detendremos en este punto. Vamos a extraer información dela primera página del fichero de datos de master, la página de cabecera:

Podemos ver que esta página muestra bastante información sin embargo no está la información que buscamos. La página 9 es la que contiene la información que estamos buscando:

El siguiente paso será detectar exactamente en qué parte de la página se almacena el valor de la fecha de dbi_updSysCatalog. Si comparamos dos DBCC PAGE distintos (en uno tenemos el dbi_updSysCatalog con el valor 1900-01-01 00:00:00 y en otro no) podemos ver lo siguiente:

Los bytes marcados en negro son los que están almacenando la fecha que queremos modificar. Con el uso del comando DBCC WRITEPAGE (de nuevo, no documentado pero con extensa información en la web) podemos realizar la modificación sobre la página.

ATENCION: Debemos tener mucha precaución al utilizar este comando ya que un simple error nos puede dejar la base de datos corrupta e irrecuperable.

En nuestro caso el offset a calcular será, el resultado de sumar los 96 bytes de la cabecera (0x60) más el offset del slot 0 hasta el final de la fecha (0x280 menos 8 bytes). El offset será por tanto 0x60+0x280-0x08=0x2D8=728 bytes. El total a escribir serán 8 bytes y el valor a escribir será 0x0000000000000000 (que equivale a la fecha 1900-01-01 00:00:00.000) por lo que el comando a lanzar será el siguiente:

DBCC WRITEPAGE (1,1,9,728,8,0x0000000000000000)

Una vez lanzado comprobaremos que el comando DBINFO muestra correctamente que hemos borrado nuestro rastro en lo que a tablas de sistema modificadas se refiere :)

Paralelismo en SQL Server (I)

Enrique Catalá — 2013-03-30T22:49:39+01:00

En SQL Server podemos ajustar el paralelismo desde diversos puntos de vista, para conseguir diferentes resultados en función de nuestras necesidades. Una cosa que debemos recordar siempre es que aunque SQL Server posee reglas para auto-optimizarse en función del hardware detectado al iniciarse, es cierto tambien que debemos realizar ajustes al mismo en función de cómo estemos utilizando la instancia, esto es, qué tipo de peticiones le hacemos al motor relacional.

Dicho esto, SQL Server nos ofrece las siguientes posibilidades a la hora de afinar el paralelismo:

A nivel Hardware
A nivel de instancia
A nivel de conexión
A nivel de sentencia T-SQL

NOTA: En este post, vamos a introducirnos en los significados de cada una de dichas configuraciones, para ir familiarizándonos de cara a los futuros posts que tratarán sobre el tema.

A nivel hardware

SQL Server es capaz de detectar el hardware en el que está corriendo de forma que se ajusta de forma diferente para aprovechar todas sus caracteristicas en cada momento.

De forma muy genérica, es capaz de distinguir entre correr en un hardware SMP, cuya arquitectura de alto nivel sería esta:

Y detectar si está corriendo en Hardware NUMA (Non-Uniform Memory Access), cuya arquitectura de alto nivel seria esta:

El hardware NUMA es bastante común en entornos críticos donde se requiere alto rendimiento, pero debido a sus beneficios y reducción de costes es cada vez mas frecuente encontrarlos en equipos “estandard” empresariales. En este tipo de arquitecturas, se dispone de varios nodos NUMA, cada uno compuesto por sus propios bancos de memoria, CPU y controladora, estando todos los nodos interconectados entre si. Típicamente el SO abstrae de la gestión de memoria y CPU a las aplicaciones que corren en dicho hardware, pero si se quiere que la aplicación explote al máximo las prestaciones de la máquina hay que realizarle ciertos “ajustes”. Una de las razones mas importantes es que si existe por ejemplo un thread corriendo sobre el NODO1 que debe acceder a una página de memoria alojada en otro nodo (digamos NODO2), típicamente se tarda entre 3 y 4 veces el tiempo que se tardaría en acceder a dicha página, si dicha página se encontrase en el NODO1. Por tanto, si la aplicación supiese que corre en hardware NUMA y se hiciera lo posible por tratar de almacenar la memoria relacionada cerca entre si dentro de los mismos nodos NUMA, se estaría favoreciendo el rendimiento enormemente (recordemos entre 3 y 4 veces la penalización por acceso al exterior). Este concepto es el que denominaremos a partir de ahora como DATA LOCALITY y trata de resumir la esencia de buscar siempre, que el dato se encuentre lo mas cerca del origen que lo pide, tanto él como los que futuramente puedan ser accedidos.

Dado que SQL Server es una aplicación diseñada para aprovechar arquitecturas NUMA, nosotros podemos obviamente modificar los parámetros hardware del sistema para que SQL Server se autoajuste en función del nº de nodos disponibles, por ejemplo. Obviamente este concepto de “afinamiento” es méramente anecdótico y se ha añadido para recordar al lector que SQL Server posee un mecanismo de auto-afinamiento que en este caso aprovecha el hardware existente favoreciendo DATA LOCALITY.

Además, entre otras cosas incrementa el nº de hidden schedulers (como por ejemplo lazywritter) de forma que SQL Server creará 1 por cada nodo NUMA disponible.

*Imagen donde se puede observar el contenido del fichero ERRORLOG indicando cómo se han detectado 3 nodos NUMA hardware en el sistema y el nº de procesos LAZY WRITTER creados (uno por cada nodo numa)

A nivel de instancia

A nivel de instancia es donde mas podemos afinar el comportamiento de SQL Server. Tenemos las siguientes posibilidades:

1.Máscaras de afinidiad
2.Degree of parallelism
3.cost threshold for parallelism
4.max worker threads

Máscaras de afinidad

A la hora de configurar las máscaras de afinidad, podemos trabajarlo en 3 niveles:

1. Afinidad de procesador

La afinidad de procesador se usa para indicar qué CPU podrán ser accesibles por SQL Server. Además, podremos vincular hilos a determinados procesadores. El resultado real de desactivar CPU es que SQL Server desactivará los schedulers asociados y por tanto efectívamente no utilizará dichas CPU

¿Para qué querríamos hacer esto?

Como sabemos, podemos tener mas de una instancia SQL Server instalada en la misma máquina. En estos escenarios, para evitar peleas por el recurso CPU que entorpezcan el rendimiento general del sistema, es una buena práctica des-solapar las CPU de ambas instancias.

Por ejemplo, si tenemos 8 CPU y 2 instancias instaladas, dejaríamos activadas las CPU 0-3 para la instancia 1 y las CPU 4-7 para la instancia 2.

Para más información: http://msdn.microsoft.com/en-us/library/ms187104.aspx

2. Afinidad de E/S

Toda operación de E/S debe ser finalizada (cálculo de checksum, número de bytes transferidos, número de página correcto,…) y para ello se realiza un consumo de CPU. Este tipo de operaciones es realizado por el proceso denominado LAZY WRITTER por un scheduler oculto. Configurando la afinidad de E/S podremos indicar qué CPU podrán ser accesibles por el scheduler oculto que realiza estas tareas.

¿Por qué querríamos hacer esto?

Al igual que el afinamiento de CPU, el afinamiento de E/S está pensado para mejorar el rendimiento en entornos donde la presión de E/S es alta. De esta forma, podemos limitar a determinadas CPU el gasto computacional asociado a operaciones de finalización de E/S.

Tened presente, que la idea en este caso es precisamente evitar que los schedulers normales y los schedulers ocultos de finalización de E/S compitan por los mismos recursos. Esto quiere decir que lo que buscamos es esto:

No queremos esto:

Ya que estaríamos haciendo competir por la CPU a los schedulers normales que se encuentran realizando tareas sql, y a los schedulers ocultos como el de finalización de E/S.

La propia GUI de SSMS te impide las malas configuraciones evitando que puedas marcar la misma CPU para afinidad de procesador y afinidad de E/S, lo cual es algo de agradecer:

*Ejemplo cualquiera de configuración de afinidad CPU y afinidad E/S mediante asistente

Para más información: http://msdn.microsoft.com/en-us/library/ms189629.aspx

3. Afinidad de red

Existe un método avanzado para optimizar sistemas SQL Server consistente en vincular un determinado puerto de comunicaciones, con un determinado NODO numa. Para realizar esta configuración, obviamente debemos disponer de hardware NUMA y obviamente con mas de 1 NODO.

La idea es que consitamos un aumento de rendimiento a base de facilitar DATA LOCALITY mediante cierta “inteligencia” por nuestra parte:

*Imagen que muestra afinidad de red vinculado 4 puertos a 4 nodos NUMA

¿Por qué querríamos hacer esto?

La idea que pretendemos llevar a cabo es favorecer estadísticamente que los datos utilizados por determinadas conexiones se encuentren siempre en el mismo NODO numa ( o al menos que estadísticamente sea mucho mas probable).

Lo que se hace es vincular un determinado puerto (por ejemplo en la imagen el puerto 8000) a un determinado nodo NUMA (en dicho ejemplo al NODO 1). Luego, en las aplicaciones, redirigiremos la cadena de conexión para indicar que nos conectaremos a la instancia SQL Server mediante el puerto 8000, consiguiendo que dicha aplicacion siempre utilice de entrada el nodo NUMA 1 y por tanto, que los datos de páginas a acceder se encuentren mas probablemente en los bancos de memoria de dicho NODO.

En entornos críticos, aplicando este tipo de configuraciones se puede llegar a obtener aumentos de rendimiento interesantes rondando el 20%.

Para más información: http://support.microsoft.com/kb/299641

Degree of parallelism

El grado de paralelismo es posiblemente la configuración mas comunmente utilizada a la hora de afinar el grado de paralelismo de SQL Server. En este caso, estamos hablando del grado de paralelismo a nivel de instancia.

Su configuración indica el máximo número de CPUs que un determinado worker puede utilizar, esto es, el nº de hilos que un determinado operador puede abrir como máximo en ejecución.

No debe confundirse con la afinidad de CPU, ya que en este caso no estamos desactivando CPU, estamos limitando el nº de hilos disponibles para resolver una consulta. Además, su valor es determinado en tiempo de ejecución y no afecta para nada al plan cache.

Su valor además puede ser especificado a nivel de workload group dentro de una configuración de Resource Governor. Haciendo esto, estaremos configurando la forma de proceder en términos de hilos por operador, para determinadas conexiones a SQL Server.

Para más información: http://msdn.microsoft.com/en-us/library/ms188611(v=sql.105).aspx

Cost threshold for parallelism

Utilizado para modificar el nº de planes de ejecuciones paralelos generados en el sistema, es una de las configuraciones mas desaprovechadas por los DBA de SQL Server, quizás por su escasa divulgación y porque requiere un conocimiento del negocio en el que está corriendo SQL Server para poder explotarla con éxito.

La idea es que un sistema OLTP puro no debería tener ejecuciones paralelas, ya que implica que SQL Server ha determinado un coste elevado para su resolución, pero a su vez, SQL Server finalmente tambien acaba resolviendo operaciones no OLTP ( las tan temidas consultas gigantescas a la BBDD para devolver informes :) ). La idea por tanto es jugar con este parámetro, para aumentar o disminuir el nº de operaciones paralelas que se ejecutan. Reconozco que es un parámetro un tanto “peligroso” en tanto en cuanto no se posee un control absoluto de lo que va a suceder en el sistema a ciencia cierta (cambias estadísticamente el nº de planes a generarse, pero no sabes cuales serán ya que no los puedes vincular a ellos, como con “degree of parallelism”). Es por ello que solo debes tocarlo si estas seguro de lo que deseas conseguir y siempre y cuando seas capaz de medir el impacto de su modifición para saber si vas en la dirección correcta.

Su valor es utilizado por SQL Server cuando se está evaluando el plan de ejecución a utilizar, de forma que cambiar su valor influirá en cómo se ejecutará el plan de ejecución.

*Pseudo código donde se utiliza “threshold for parallelism” para obtener plan de ejecución

Para más información: http://msdn.microsoft.com/en-us/library/ms188603(v=sql.105).aspx

Max worker threads

Este parámetro sirve para configurar el número de subprocesso de trabajo disponibles para los procesos de SQL Server. Modificar este parámetro puede optimizar el rendimiento cuando un gran número de conexiones se abren contra la instancia SQL Server ya que generalmente se crea un subproceso de sistema independiente para cada solicitud, pero gracias a esto se pueden agrupar varias solicitudes a determinados grupos de trabajo.

Esta característica, al igual que la característica “threshold for parallelism” se considera avanzada y solo recomendable aplicarla si se poseen conocimientos profundos de SQL Server y de cómo se puede beneficiar el escenario concreto donde se aplicará.

Para hacerse una idea, puedes ver la siguiente tabla donde se obtienen los valores de max worker threads que SQL Server configura dependiendo del entorno donde se está ejecutando y su versión de binarios

Para más información: http://msdn.microsoft.com/es-es/library/ms187024(v=sql.105).aspx

A nivel de conexión

A nivel de conexión SQL Server nos ofrece la posibilidad de configurar el grado de paralelismo mediante el uso de Resource Governor. De esta forma, podemos configurar SQL Server para que dependiendo de nuestra función de enrutado de resource governor, se comporte diferente en términos de paralelismo.

¿Para qué querríamos hacer esto?

Bueno, pues podríamos forzar a que todas las operaciones de reindexado de índices, backups, recálculo de estadísticas…por defecto funcionaran al máximo DOP posible con el fin de optimizar los recursos.

Otra posibilidad tambien podría ser predefinir que todas las conexiones de una aplicación que utiliza SQL Server como OLTP puro, utilicen un DOP de 1.

Como vemos, nos ofrece unas posibilidades bastante mas que interesantes a la hora de optimizar sistemas utilizados por aplicaciones heterogéneas.

Para más información: http://technet.microsoft.com/es-es/library/bb895232(v=sql.105).aspx

A nivel de sentencia T-SQL

A nivel de sentencia T-SQL tenemos la cláusula MAXDOP con la que podemos especificar el valor “degree of parallelism” que queremos que tenga la sentencia concreta a la que se lo apliquemos. Como hemos visto, el grado de paralelismo puede especificarse a nivel de instancia, de conexión (con resource governor) y ahora de sentencia; la precedencia siempre es la que posea el nivel de granuldaridad mas bajo. De esta forma, sea cual sea la configuracion DOP de instancia y Resource Governor, si una sentencia posee MAXDOP=8, dicha sentencia utilizará como mucho 8 hilos por operador, independientemente de los valores configurados a nivel de instancia y/o resource governor.

¿Por qué querríamos configurar una consulta con un MAXDOP distinto?

Imaginemos que a la instancia le hemos configurador DOP = 1, por lo que por defecto, todas las peticiones serán en serie, luego configuramos resource governor con un workload group para que tenga DOP = 4 una determinada aplicación,….¿qué pasa si queremos lanzar desde dicha aplicación cliente una agregación de datos masiva y nuestra máquina tiene 32 CPU? Esta la podríamos realizar con MAXDOP=0 y daría igual el resto de configuraciones, siempre sería capaz de crear si le hiciera falta hasta 32 hilos por operador.

Para más información: http://msdn.microsoft.com/en-us/library/ms181714.aspx

SSIS – Data Profiling

Ken Spencer — 2013-03-27T21:30:22+01:00

SSIS (SQL Server Integration Services) is a powerful technology for most things data related. This includes moving data in and out of SQL Server and many other things like copying files or in my case today profiling data.

The following table shows a problem we run into all the time with many clients. In this case we have a lookup table that lists product categories. As you can see there is a lot of bad data there where the category names are not consistent. For instance Belt is also shown as belt, blt, and bt. And it’s not usually just the database issue necessarily its either the database is not designed right and/or the applications are not handling data correctly.

We saw this recently where a database had a global option table for all types of fields and the data was really bogus just like this figure shows.

The only way you can really clean up your data is to profile it and monitor it. And there are good tools coming out like the new features in SQL Server 2012 which I will get into in another post.

This discussion brings me to the SSIS Data Profiler for this post. This SSIS task is really cool and will let us do things like analyze the key strength of columns, look at the column lengths for the current data, analyze the data in those columns and so forth. It’s nice because this is right out of the box in SQL Server. Let’s dig in and see how this works.

The following figure shows the Data Profiling Task on the design panel of SSIS 1012. This task is the only thing in the current project.

Once you have the task in the design surface you can configure it by double clicking it or right clicking and selecting Edit. The next figure shows the edit dialog. When the Data Profiling Task runs it outputs its results to a file. Notice how the DestinationType property is set to FileConnection and the Destination property to the DataProfile.xml connection. This is where the results will end up when the task runs.

Now that you have an output location, you can create a profile of your data. The easiest way to do this is to click the Quick Profile button shown in the last figure. This will open the following dialog:

You can see that I have already selected the Localhost.db connection and the ProductCategory table. Then I checked all of the boxes to create a complete profile. Next I clicked Ok and the profile was done.

Then I ran the package in debug mode.

Now the really cool thing is the Data Profile Viewer. You can find this in the Start menu and also it’s in in Data Profiling Tasks property page in the General area where you can just click Open Profile Viewer (see the 2^nd figure) to run it.

This brings up the following dialog:

This tool allows us to dig into the results of our data profile and see what’s going on with our data. There is lots of good info in this output depending upon what you are looking at. For instance, you can find out the key strength of columns, look at a profile of the data, check column length against data and more.

In the case I mentioned early on, we really want to look at the data and its consistency. You can click on the Column Pattern Profiles item to dig into what your data looks like. The next figure shows this view after I also clicked on the Category column:

You can also click the Drill Down button to the right of All Rows to display all the data that a row represents. For instance if I were to click Drill Down, the display would change to this:

You can see the two discrete types of data that make up PANTS is Pants and pants. To drill into another field, double click it and it will change the drill down details.

As you can see from this image there’s lots of fields that are not correct. The next image shows the Pattern Distribution after I clicked the Pattern header to sort it. Now its clear that Belt and Blt are the same.

Now that I have identified this problem, I can run this query in SSMS:

select * from [dbo].[ProductCategory] where description = 'Belts'

This shows me that we have 3 entries for Belts where we should have 1 entry.

15 Belt Belts

16 belt Belts

17 blt Belts

This type of cleanup should be done on any database that’s been in production for any length of time. When you find these problems, you can look at related tables and figure out where to make other data changes. And you should look at your applications and make sure no one has put in hard references or is feeding a list with hard coded values such as Belt or Blt and such.

It’s also worth looking at cleaning up your data layout and making lookups normalized if they are not already.

El Sign in as Different User en SharePoint 2013

Roberto Ramón Berna — 2013-03-25T12:29:00+01:00

Muy buenas a todos;

recientemente, trasteando con SharePoint 2013, me ha surgido la necesidad de cambiar el usuario con el que estoy logueado en mi aplicación, hasta ahí todo bien. Cuando voy a buscar la opción en la parte superior derecha donde se encuentra también el “Sign Out, descubro que la opción para cambiar de usuario no está.

A continuación vamos a ver tres formas de como saltarnos esta limitación para llegar a poder loguearnos con otro usuario.

1º Concatenando a nuestra url “/_layouts/closeConnection.aspx?loginasanotheruser=true”

Al igual que en SharePoint 2010, podemos forzar ese logueo con otro usuario mediante url,. Quizás lo más complicado de esta opción es tener siempre en mente dicha cadena.

Ejemplo: http://summitsolidq2013/SitePages/Home.aspx

2º Abriendo el explorador con un usuario diferente

Botón derecho sobre nuestro navegador Internet Explorer “Run as different user” y metemos los credenciales del usuario con el que queremos aparecer logueados en nuestra aplicación.

3º Añadir el código necesario para que aparezca siempre.

Abrimos el archivo “Welcome.ascx” que se encuentra en la siguiente ruta “\15\TEMPLATE\CONTROLTEMPLATES\Welcome.ascx ”.

Le agregamos el siguiente código, que básicamente lo que hace es añadir un elemento más al menú.

<SharePoint:MenuItemTemplate runat="server" ID="ID_LoginAsDifferentUser" Text="<%$Resources:wss,personalactions_loginasdifferentuser%>" Description="<%$Resources:wss,personalactions_loginasdifferentuserdescription%>" MenuGroupId="100" Sequence="100" UseShortId="true" />

Como podemos ver en la siguiente imagen, ya tendremos el “Sign in as Different User” agregado en nuestro menú.

Por último cabe mencionar que el paso 3, aconsejaría realizarlo solo en entornos de prueba y desarrollo. Si no está la opción en el menú, no es porque se hayan olvidado de ella, será por algún motivo en especial. En este post de Stefan Gossner , citan algunas de las posibles razones que pueden haber llevado al equipo de producto a quitar dicho elemento del menú.

Un saludo y espero que haya sido de utilidad

What Are DQS and MDS About

Dejan Sarka — 2013-03-23T10:21:43+01:00

This is just a very quick information about SQL Server 2012 Data Quality Services (DQS) and Master Data Services (MDS). If you don't have a clue what they are useful for, this blog post should give you the basic idea.

Many companies or organizations do regular data cleansing. When you cleanse the data, the data quality goes up to some higher level. The data quality level is determined by the amount of work invested in the cleansing. As time passes, the data quality deteriorates, and you need to repeat the cleansing process. If you spend an equal amount of effort as you did with the previous cleansing, you can expect the same level of data quality as you had after the previous cleansing. And then the data quality deteriorates over time again, and the cleansing process starts over and over again.

The idea of Data Quality Services is to mitigate the cleansing process. While the amount of time you need to spend on cleansing decreases, you will achieve higher and higher levels of data quality. While cleansing, you learn what types of errors to expect, discover error patterns, find domains of correct values, etc. You don't throw away this knowledge. You store it and use it to find and correct the same issues automatically during your next cleansing process. The following figure shows this graphically.

The idea of master data management, which you can perform with Master Data Services (MDS), is to prevent data quality from deteriorating. Once you reach a particular quality level, the MDS application—together with the defined policies, people, and master data management processes—allow you to maintain this level permanently. This idea is shown in the following picture.

Not an in-depth blog post, as I said; however, I hope it brings some basic understanding about the purpose of DQS and MDS.

Data Explorer: llega el self-service ETL

Pau Sempere Sanchez — 2013-03-21T20:51:00+01:00

Recientemente se publicó la versión preview de Data Explorer para Excel (La podéis descargar de aquí)

El producto llega a su versión previa al lanzamiento después de haber tenido dos versiones, el cliente de escritorio y el servicio en la nube, publicadas hace algo más de un año, y que ofrecían un servicio muy similar aunque con ligeras diferencias respecto a la conectividad y posibilidad de publicación de resultados.

Ahora, el producto ha evolucionado y mejorado, y se integra con Excel (tanto 2010 como 2013). Viene a llenar el hueco que quedaba entre los orígenes de datos y el modelo de datos en el paradigma de self-service BI que Microsoft propuso con la aparición de SQL Server 2012, con BISM y la posibilidad de escalar desde el análisis sobre el modelo de datos personal hasta un BI empresarial en un servidor de Analysis Services. Data Explorer viene a cubrir la funcionalidad de integración de datos en el sistema de self-service BI como PowerPivot cubre la funcionalidad de análisis.

El hecho de que se enmarque dentro de Excel es uno de los hechos más relevantes de esta preview, dando más importancia si cabe a Excel dentro del ecosistema de BI de Microsoft. En ella los analistas de negocio se sienten cómodos, tienen pericia y son capaces de desenvolverse con naturalidad, lo que reduce mucho la curva de aprendizaje de nuevas herramientas que estén enmarcadas en él. Además, nos permite combinar rápidamente los datos que descubramos e importemos con el resto de funcionalidades integradas en Excel para realizar análisis cómodos y rápidos sin tener que esperar a grandes desarrollos ETL y de sistemas analíticos, pero teniendo la posibilidad de que a partir de estos análisis iniciales surja todo un modelo de análisis empresarial. ¡Incluso podemos añadir directamente la información obtenida con Data Explorer a un modelo de datos en PowerPivot!

En este post vamos a ilustrar como combinar fuentes de información “no estándar” obtenidas con Data Explorer con Power View incluido en Excel 2013 para realizar un análisis rápido y vistoso en cuestión de minutos.

Supongamos que somos el responsable de marketing de una empresa y queremos saber qué se ha dicho recientemente en Twitter acerca de nuestra organización. Obviamente nos interesa qué se ha dicho, pero también es importante saber quién lo ha dicho y, entre otras cosas, desde dónde se ha dicho (o en su defecto, dónde ubica Twitter a los usuarios que lo han dicho). La geolocalización de la información es un activo cada vez más importante en la inteligencia de negocio, especialmente con la facilidad con la que podemos integrarla con Power View.

Para ello, habiendo descargado e instalado Data Explorer para Excel 2013, abrimos un libro de Excel en blanco, y hacemos clic en la nueva pestaña “DATA EXPLORER”. Una vez nos aparezca la cinta de opciones, donde podemos elegir todas las fuentes de datos disponibles, seleccionaremos “From Web”. Como vamos a leer datos desde Twitter, debemos saber el formato en el que debemos preguntar a Twitter. En nuestro caso realizaremos la consulta para obtener tweets sobre SolidQ. La URL desde la que obtener la información quedaría parecida a ésta: https://search.twitter.com/search.json?q=SolidQ&rpp=50. Podéis encontrar información sobre los parámetros de búsqueda del API de Twitter aquí.

Twitter nos devuelve un bloque de datos en formato JSON, pero Data Explorer está esperando un documento HTML. Por tanto, cuando intentemos importar la información, nos dará el siguiente error:

Lo que vemos es que DataExplorer nos está dando una tabla y un documento en HTML con un error (espera HTML y recibe JSON). Un pequeño truco para saltarnos esta situación es usar el lenguaje de fórmulas de Data Explorer, que tiene soporte para interpretar datos estructurados (tanto en JSON como en XML). Si modificamos la fórmula por ésta, añadiendo Json.Document en vez de Web.Page para especificarle que lo que va a recibir son datos en JSON:

Tenemos información estructurada sobre la respuesta de Twitter a nuestra consulta. Los tweets que nos interesan se encuentran en la lista de elementos contenida

dentro del campo “results”. Clicamos en el enlace (en verde claro en la captura) para realizar automáticamente un drill down y veremos el detalle de la lista.

Ahora queremos convertir estos resultados de información estructurada en una tabla, que es con lo que trabajaremos en Excel.

Si hacemos botón derecho sobre la cabecera de la columna y seleccionamos To Table:

Una vez lo hemos convertido a tabla, seleccionaremos un delimitador (si lo hubiese, en este caso son datos ya estructurados y no será necesario)

y podremos elegir qué columnas queremos expandir haciendo clic sobre el icono en la esquina superior derecha.

Nosotros vamos a escoger los siguientes

- from_user: El nombre del usuario en Twitter

- from_user_id_str: Su identificador interno en Twitter en formato de cadena de caracteres

- profile_image_url_https: Las fotos siempre quedan bonitas . Obteniendo la URL donde localizamos la foto del usuario podremos ver la imagen en Excel gracias a su interacción con Bing

- text: El tweet en sí

Ahora renombramos las columnas solo para tener más claro que significa cada una (y poder identificarlas fácilmente en el análisis posterior). Sólo con cambiar el nombre de la columna, como si fuese una columna más de Excel, Data Explorer aplicará la operación correspondiente en su lenguaje de fórmulas. Si nos fijamos en la parte derecha de la pantalla, en la sección Steps, vamos a poder ir viendo cada uno de los pasos que hemos realizado para llegar hasta el punto actual, y lo que es mejor, al cambiar o actualizar la información en un paso intermedio (cambiar el parámetro de consulta a Twitter, por ejemplo), ¡la información se actualiza en cascada en todos los pasos posteriores de manera automática!

Twitter ofrece funcionalidad para localizar desde donde se está twitteando. Tiene sentido sobre todo al usar los servicios GPS de los dispositivos móviles, y más aún si la localización tiene relación con lo que se está publicando. Pero no todo el mundo usa esta opción, y por ello vamos a usar de nuevo el API de Twitter para obtener la localización que los usuarios definen cuando registran su cuenta a través del ID de usuario (campo UserID) que previamente habíamos obtenido. En este caso la fórmula que usaremos será muy parecida a la anterior, pero concatenando el valor del campo UserID para construir la consulta, y conseguiremos llegar a la localización añadiendo una columna personalizada y seleccionando el campo de los datos estructurados en JSON directamente.

Primero tendremos que transformar la columna UserID en una de datos tipo texto, ya que es de tipo de datos numérico y no nos dejará usarla para ser concatenada a la fórmula.

Pulsando con el botón derecho sobre la última columna, seleccionamos Insert Column – Custom:

Lo cual nos permitirá añadir la expresión en lenguaje de fórmulas de Data Explorer de una manera muy parecida a la que usamos para conseguir los tweets:

Conseguiremos acceder directamente a la localización del usuario con la selección del campo “[location]”. Si obtuviésemos una lista de resultados y tuviesemos que elegir un elemento antes de seleccionar el campo que queremos obtener, tendríamos que usar los operadores {}. Por tanto, quedaría tal que Funcion(…){N elemento}[campo].

Puede que veamos un error de este tipo al intentar conseguir datos externos:

Para evitarlo, activamos la opción “Fast Combine” de Data Explorer para poder usar datos de otras fuentes de datos sin recibir este error que nos avisa de que no podemos usar fuentes de datos de diferentes orígenes, en lo que parece una restricción interna de Data Explorer para evitar incongruencias al mezclar datos desde fuentes externas diversas.

Ya tenemos añadida la localización de cada uno de los usuarios que han publicado tweets sobre SolidQ. La mayoría serán localizaciones válidas, pero otras no lo serán. Aquí entraría en juego la combinación de Data Explorer o incluso Excel con servicios externos de validación y calidad de datos, pero es un tema que requeriría un post adicional, o incluso varios

Renombramos la columna que hemos obtenido como Location y clicamos en Done para volver a nuestra hoja de Excel.

Ahora que ya tenemos los datos con su localización y las fotos de los usuarios de Twitter podemos hacer rápidamente un informe con Power View que nos muestre dónde han sucedido estos tweets (o por lo menos donde se localiza al usuario que los publicó).

En un par de clics podríamos tener algo así:

O aprovecharnos de la funcionalidad de PowerPivot para mostrar imágenes en los informes de Power View, marcar el campo PictureURL como de tipo “imageURL” en las opciones avanzadas de PowerPivot y poder ver el avatar de quién escribió qué y desde dónde:

Habrá que esperar a la versión final de Data Explorer para poder medir todo su potencia y facilidad de uso pero hemos visto que ya en la preview podemos obtener datos desde fuentes externas (el API de Twitter, en este caso) de manera relativamente sencilla y toda la potencia de análisis que nos brinda el hecho de que esté integrado dentro de Excel.

Os animo desde aquí a que descarguéis Data Explorer para empezar a investigar cómo importar datos y cómo combinarlos.

Espero que os haya gustado, en próximos posts y artículos seguiremos hablando de Data Explorer y las funcionalidades que ofrece para integración y modelado de datos. Feliz análisis

Windows Phone 8 - Pandora

Ken Spencer — 2013-03-21T16:01:29+01:00

Today the new Pandora app for the phone came out. Apps are coming out fast and furious.

Check this out on TrendSpotter

More on Htc 8x replacement

Ken Spencer — 2013-03-21T15:59:34+01:00

Man, i love the Windows Phone 8.
Got my new phone from Verizon.

fired it up, logged in. Then went to mail and put in email / password.

Bank. Outlook.com is hooked up and my contacts are there.

Plugged in the phone to the usb and fired up media player. Sync.

Now my phone is right back to where the other one was with no fuss. Just have to reinstall some apps.

Windows Phone 8 – Verizon Support

Ken Spencer — 2013-03-18T20:44:02+01:00

Some good news.

I have the htc 8x and love this phone. There's only been one issue with it so far.

Fairly frequently i get a message that says the SIM card is invalid. I called the other week and Verizon suggested some changes in settings. Got better and then it came back hard.

So today i called. After 5 minutes, i have a new phone coming overnight thanks to the warranty. Yeah for Verizon.

I also found this thread on the issue:

http://answers.microsoft.com/en-us/winphone/forum/wp8-wpnetwork/htc-8x-sim-card-is-missing-or-invalid/16962008-df41-4959-a6ea-f03b00d5d118?page=~pagenum~

It was interesting enough in the last post where they pointed to this article on iphones:

http://wooservers.com/blog/2010/07/10/fixing-iphone-4g-no-sim-installed-problem/

Looks like they have the same issue. I have not tested the tape ideas in this article but if the issue comes up again i am going to give it a try.

PASS SQL Saturday #188 Portugal

SolidQ — 2013-03-15T11:28:00+01:00

SQL Saturday will be held March 16 at Microsoft Portugal, Lisbon, 1990-110, Portugal. As you know, this event is a free training event for SQL Server Pofessionals and SQL Server lovers. This event is about to beat the record of 320+ registrations!

We are proud to announce that from a total of 31 speakers, 5 are part of the SolidQ team:

	Régis Baccaro \| Database development with SSDT “In this session we'll dive into Online and Offline development as well as the Productivity and tools that the SSDT team keeps providing to us.”
	Enrique Catalá \| Parallelism in SQL Server “In this session we will discuss about the parallelism in SQL Server. We will talk about configuration parameters, parallel execution plans, parallel operators and more. We also will talk about problems and best practices.”
	Eladio Rincón \| Parallelism in SQL Server “In this session we will introduce the main concepts about transactional replication and two real cases to show the scale-out benefits of this technology. At the end we will talk about common best practices for transactional replication.”
	Rubén Pertusa \| Sentiment analysis using SSAS 2012 ”This session reviews some text mining and integration techniques for extracting and incorporating these insights from Big Data into our analytical platform. Real life samples and practical demos will be shown using Microsoft technologies. Co-speaker: Javier Torrenteras (SolidQ BI Manager)”
	Milos Radivojevic \| Identifying and Solving Sort Warning Problems ”We will see how to identify this problem in SQL Server 2008 and more elegant in SQL Server 2012 and of course we can discuss how to prevent this problem.”

You will find the extended session details on the event’s official website.

Hope you enjoy your SQL Saturday!

	Régis Baccaro \| Database development with SSDT “In this session we'll dive into Online and Offline development as well as the Productivity and tools that the SSDT team keeps providing to us.”
	Enrique Catalá \| Parallelism in SQL Server “In this session we will discuss about the parallelism in SQL Server. We will talk about configuration parameters, parallel execution plans, parallel operators and more. We also will talk about problems and best practices.”
	Eladio Rincón \| Parallelism in SQL Server “In this session we will introduce the main concepts about transactional replication and two real cases to show the scale-out benefits of this technology. At the end we will talk about common best practices for transactional replication.”
	Rubén Pertusa \| Sentiment analysis using SSAS 2012 ”This session reviews some text mining and integration techniques for extracting and incorporating these insights from Big Data into our analytical platform. Real life samples and practical demos will be shown using Microsoft technologies. Co-speaker: Javier Torrenteras (SolidQ BI Manager)”
	Milos Radivojevic \| Identifying and Solving Sort Warning Problems ”We will see how to identify this problem in SQL Server 2008 and more elegant in SQL Server 2012 and of course we can discuss how to prevent this problem.”