USE MASTER GO ALTER DATABASE @anBenedetti SET OFFLINE WITH ROLLBACK IMMEDIATE GO #SQLServer #SQLFamily #HappyNewYear

SELECT * 
FROM Table1
JOIN Table2 ON
    Table1.code = Table2.code AND 
    (Table1.MESERIF_ST >= Table2.Month_Start) AND 
    (Table1.MESERIF_ST <= Table2.Month_End) 
GO

But, right now, it’s a little bit difficult to do that on Power Query.

Simply because with the “merge queries” we can only choose the matching columns to create a merged table.

The related table contains all rows that match each row from a primary table based on a common column value.

To solve the problem we need to use the advanced editor and change the M code.

Let’s try with a demo using two tables on SQL Server.

This is the setup script:

SET NOCOUNT ON
USE Test
GO

create table Table1
(
id int,
code varchar(10),
MESERIF_ST date
)
GO

create table Table2
(
id int,
code varchar(10),
Month_Start date,
Month_End date
)
GO


insert Table1 values (1, 'aaa','20140101')
insert Table1 values (2, 'bbb','20140111')
insert Table1 values (3, 'ccc','20140121')
insert Table1 values (4, 'ddd','20140131')
GO


insert Table2 values (1, 'aaa','20140105','20140211')
insert Table2 values (2, 'bbb','20140101','20140311')
insert Table2 values (3, 'ccc','20140111','20140411')
insert Table2 values (4, 'ddd','20140202','20140511')
GO

Now, with Power Query I create two Workbook Queries:

I duplicate the first query to start editing and apply a merge on the equality column [code]:

Now I choose my columns:

And this is the result:

In the editor I can see the code of my instructions:

let

    Source = Sql.Database(".\sql2012", "test"),

    dbo_Table1 = Source{[Schema="dbo",Item="Table1"]}[Data],

    Merge = Table.NestedJoin(dbo_Table1,{"abi"},Table2,{"abi"},"NewColumn"),

    #"Expand NewColumn" = Table.ExpandTableColumn(Merge, "NewColumn", {"id", "abi", "MESERIF_INIZIO", "MESERIF_FINE"}, {"NewColumn.id", "NewColumn.abi", "NewColumn.MESERIF_INIZIO", "NewColumn.MESERIF_FINE"})

in

    #"Expand NewColumn"

I need to use a SelectRows to define the complete predicate of my query.

So I change the script (you can see in red the statement changed):

let

    Source = Sql.Database(".\sql2012", "test"),

    dbo_Table1 = Source{[Schema="dbo",Item="Table1"]}[Data],

    Merge = Table.NestedJoin(dbo_Table1,{"abi"},Table2,{"abi"},"NewColumn"),

    #"Expand NewColumn" = Table.ExpandTableColumn(Merge, "NewColumn", {"id", "abi", "MESERIF_INIZIO", "MESERIF_FINE"}, {"NewColumn.id", "NewColumn.abi", "NewColumn.MESERIF_INIZIO", "NewColumn.MESERIF_FINE"}),

    BetweenFilter = Table.SelectRows(#"Expand NewColumn", each ( ([MESERIF_ST] >= [NewColumn.MESERIF_INIZIO]) and ([MESERIF_ST] <= [NewColumn.MESERIF_FINE] ) ) )

in

    BetweenFilter

And this is the result:

The same in TSQL:

Enjoy,

A.

SQL Server consente di recuperare questa informazione in diversi modi.

La cosa interessante è che ciascuno di essi non ritorna lo stesso medesimo istante perché ognuno riporta un particolare start di una specifica attività (in ordine temporale):

• start dell’istanza
• start della prima attività interna (come fosse una sessione “0”)
• start della traccia di default
• start (creazione) del tempdb

Queste le query:

SELECT sqlserver_start_time as [Istante di start dell'istanza]
FROM sys.dm_os_sys_info;

SELECT login_time as [Attività interna istanza]
FROM sys.dm_exec_sessions WHERE session_id = 1;

SELECT start_time as [Start default trace]
FROM sys.traces WHERE is_default = 1

SELECT create_date [Creazione tempdb]
FROM sys.databases WHERE name = 'tempdb'

Un esempio di risultato:

Conoscendo il numero di righe, la densità delle pagine, gli indici disponibili, l’optimizer è in grado di ragionare in maniera più accurata circa la strada da intraprendere per rispondere a quanto gli viene chiesto.

E’ proprio grazie alle statistiche che SQL Server potrà decidere di evitare di utilizzare indici che  “a prima vista” potrebbero sembrare perfetti per una certa istruzione.

Di certo, conoscere come le statistiche funzionano è un ottimo aiuto per comprendere come funziona l’ottimizzatore del database engine.

Proviamo a fare un esempio.

Costruiamo un database, semplice a piacere, con una tabella che andremo a popolare con 1.000.000 di righe.

NOTA: il database non avrà né la creazione delle statistiche, né il loro aggiornamento, abilitata. Non voglio statistiche.

USE master;
GO

CREATE DATABASE stats CONTAINMENT = NONE 
ON PRIMARY
( 
    NAME = N'stats' , 
    FILENAME = N'C:\temp\stats.mdf' , 
    SIZE = 51200 KB , 
    FILEGROWTH = 10%
)
LOG ON
( 
    NAME = N'stats_log' , 
    FILENAME = N'C:\temp\stats_log.ldf' , 
    SIZE = 10240 KB , 
    FILEGROWTH = 10%
);
GO
ALTER DATABASE stats SET AUTO_SHRINK OFF; 
ALTER DATABASE stats SET AUTO_CREATE_STATISTICS OFF;
ALTER DATABASE stats SET AUTO_UPDATE_STATISTICS OFF; 
ALTER DATABASE stats SET RECOVERY SIMPLE; 
ALTER DATABASE stats SET MULTI_USER; 
ALTER DATABASE stats SET PAGE_VERIFY CHECKSUM;  
GO


USE [stats];
GO

/* Create table for test */

CREATE TABLE test
( 
    n int PRIMARY KEY CLUSTERED , 
    col1 varchar( 50 ) , 
    col2 varchar( 50 ) , 
    col3 varchar( 50 )
);
GO


/* Insert 1.000.000 dummy rows */
WITH L0
    AS ( SELECT 1 AS c
         UNION ALL
         SELECT 1
       ) , L1
    AS ( SELECT 1 AS c
           FROM L0 AS A CROSS JOIN L0 AS B
       ) , L2
    AS ( SELECT 1 AS c
           FROM L1 AS A CROSS JOIN L1 AS B
       ) , L3
    AS ( SELECT 1 AS c
           FROM L2 AS A CROSS JOIN L2 AS B
       ) , L4
    AS ( SELECT 1 AS c
           FROM L3 AS A CROSS JOIN L3 AS B
       ) , L5
    AS ( SELECT 1 AS c
           FROM L4 AS A CROSS JOIN L4 AS B
       ) , Nums
    AS ( SELECT ROW_NUMBER()OVER( ORDER BY( SELECT NULL ) )AS n
           FROM L5
       )
    INSERT INTO test
    SELECT TOP ( 1000000 )N , 
                NEWID()AS Col1 , 
                NEWID()AS Col2 , 
                NEWID()AS Col3
      FROM Nums;
GO

Sulla tabella appena creata e popolata, aggiungo una colonna sulla quale creo un indice (NOTA: l’indice lo sto creando prima di aggiornare il valore della colonna):

ALTER TABLE test
ADD colType char( 1 );
GO

CREATE INDEX ixColType ON test( colType );
GO

A questo punto valorizzo la colonna in modo tale che il 50% delle righe abbia lo stesso valore (in sostanza voglio fare in modo che l’indice su questa colonna non sia selettivo e, quindi, NON sia utile).

UPDATE test
SET colType = 'Y'
  WHERE n % 2 = 0;
GO

Questa la situazione sulla tabella:

A questo punto, sulla mia colonna:

1. ho dei valori che non sono selettivi (500.000 righe sono valorizzate a “Y”)
2. non ho statistiche che possano informare l’optimizer su come sono distribuiti i dati al suo interno

Eseguo una query utilizzando, come predicato, proprio la colonna sulla quale stiamo lavorando.

L’optimizer, trovando disponibile un indice che lavora proprio su questa colonna, viene preso in inganno supponendo di poter sfruttare questa struttura per rispondere in maniera efficiente.

Come si può vedere dal piano di esecuzione, in effetti, lo usa (mi verrebbe da dire “in buona fede”):

SELECT col1
  FROM test
  WHERE colType = 'Y';
GO

Con risultati devastanti in termini di attività I/O:

(500000 row(s) affected)
Table 'test'. Scan count 1, logical reads 1531945

Le statistiche dell’indice, se dessimo un’occhiata alle loro proprietà, sono sì state generate alla sua creazione, ma non sono popolate (né aggiornate)…

Eseguiamo un secondo test:

1. elimino l’indice
2. lo ricreo (a questo punto, essendo la tabella popolata, le statistiche verranno generate sulla base dei dati presenti al momento)
3. rieseguo la stessa query lanciata prima
   

DROP INDEX ixColType ON dbo.test;
GO
CREATE INDEX ixColType ON test
( colType );
GO

Rieseguo la query:

SELECT col1
  FROM test
  WHERE colType = 'Y';
GO

In questa seconda esecuzione:

• l’optimizer “vede” un indice che potrebbe fare al caso suo
• controlla le statistiche di distribuzione dei dati
• si rende conto che, se utilizzasse l’indice, non ne trarrebbe un vantaggio (tutt’altro…)
• decide di andare “dritto” sulla tabella

Il piano di esecuzione parla chiaro ed è ben diverso da prima:

Così come le attività di I/O:

(500000 row(s) affected)
Table 'test'. Scan count 1, logical reads 16191

Ormai prossimi all’estate (se arriva ...) sono ormai arrivato alla chiusura della parte “speaker” del mio lavoro e allora provo a fare un bilancio di quanto fatto e di quanto (pochissimo) mi resta da fare.

Ho sempre creduto nel valore delle conferenze tecniche, per due motivi principali:

1. condividere conoscenza, sempre con l’idea di portare su un palco quanto trovato nel mondo reale. Condivisione = creazione di valore
2. ricevere, da chi tutti i giorni lavora con la tecnologia, impressioni, critiche, suggerimenti, …

Non mi sono mai piaciuti gli interventi “leggo un libro e te lo racconto”, oltre a questo ho sempre trovato entusiasmante quanto avviene dopo un intervento: le mille domande, lo scambio di opinioni e di esperienza, le discussioni su approcci – metodologie – strumenti, il dare un viso reale a persone che conosci solo virtualmente, il riuscire a tornare a casa sempre con qualcosa di nuovo (sei uno speaker e “dai”, ma ricevi a tua volta), il continuare il discorso iniziato anche dopo…

Anche quest’anno non sono mancate le occasioni, non solo in Italia:

• Microsoft Western Europe, Community Event, Amsterdam - 25 Settembre 2013

• • Building Business Analytics Solutions with Parallel DataWarehouse

• DigIT Your Future, Università degli Studi di Trento, Trento - 3 / 7 Febbraio 2014

• • Big Data

•  Community Days, Milano - 25, 26, 27 febbraio 2014

• • SQL Server: miti da sfatare

• SQL Server Conference, Milano - 11, 12 marzo 2014

• • Encryption, Privacy and Security in SQL Server & Azure SQL Database

• Nuvola Rosa, Roma - 22, 23, 24 Aprile 2014

• • A World of data
  • Big Data: Volume, Velocity, Variety, Veracity

• .Net Campus, Roma - 10 maggio 2014

• • Introduction to SQL Azure

Tra un mesetto chiudo con l’ultimo appuntamento:

• AICA, Milano - 24 giugno 2014

• • HDInsight, la soluzione Hadoop nel cloud

Mesi molto intensi ed eventi tutti molto belli e da ricordare. Occasioni in cui, ancora una volta, si ha la possibilità di toccare con mano la qualità e l’eccellenza che abbiamo anche nel nostro paese.

Un grazie ai colleghi ed agli amici con i quali riesco a passare un po' di tempo solo in queste occasioni (di sicuro dimenticherò qualcuno): Silvano Coriani, Andrea Uggetti, Francesco Diaz, Igor Pagliai, Luca Ferrari, Davide Mauri, Gianluca Hotz, Marco Russo, Paolo Pialorsi, Roberto Brunetti, Roberta Cocco, Andrea Saltarello, Daniele Bochicchio, Gianluca Sartori, Francesco De Chirico, Alberto Ferrari, Marco Agnoli, Danilo Lissoni, Lorenzo Barbieri, Francesca Mauri, Alice Heinzl, …

Al prossimo palco… ;-)

Chi di voi ha mai visto / creato colonne di tipo DECIMAL con scala uguale a 0?

Intendo dire qualcosa come:

CREATE TABLE myTable
(
    ...
    myColumn DECIMAL( 3 , 0 ) , 
    ...
);

Chi di voi si è mai chiesto che senso ha creare colonne DECIMAL con scala uguale a 0?

Il senso è, naturalmente, quello di poter gestire numeri interi. Ok.

Avevo già toccato l’argomento in un altro post, in questo vorrei tornare sull’argomento con un ragionamento più generale.

Avendo in mente lo storage necessario alla memorizzazione di dati DECIMAL a seconda della precisione definita, l’idea è quella di realizzare uno script che possa analizzare la dimensione (precisione) definita con scala = 0 per verificare la possibilità di modificarne il tipo (in un intero “naturale” come sono i TINYINT, SMALLINT, INT, BIGINT) in ottica di risparmio bytes.

Intendo dire, che senso ha utilizzare un DECIMAL(9,0) quando sarebbe sufficiente utilizzare un INT (e quindi utilizzare 4 bytes rispetto ai 5 del DECIMAL)?

DECLARE @decimal decimal( 9 , 0 ) = 999999999;
DECLARE @int int = @decimal;
SELECT
       @int [Value], 
       DATALENGTH( @int ) [INT Bytes], 
       DATALENGTH( @decimal ) [DECIMAL Bytes];

In sostanza, fino ad una precisione di 18 cifre potrei modificare il tipo per ottenerne un beneficio.

Questo perché, naturalmente, potrei utilizzare un BIGINT per memorizzare un numero (positivo o negativo) composto da 18 cifre uguali a 9 (il massimo valore gestibile con un DECIMAL(18,0)).

Provando a schematizzare:

• decimal(1), (2) : potrei usare TINYINT - con decimal 5 bytes, potrei risparmiare 4 bytes
• decimal(3) : potrei usare SMALLINT - con decimal 5 bytes, risparmio 3 bytes
• decimal(4), (5), (6), (7), (8), (9) : potrei usare INT - con decimal 5 bytes, risparmio 1 byte
• decimal(10), (11), (12), (13), (14), (15), (16), (17), (18) : potrei usare BIGINT - con decimal 9 bytes, risparmio 1 byte

Di seguito il risultato di quella che potrebbe essere l’analisi sulle tabelle di un nostro database:

Questo lo script:

SELECT 
    C.TABLE_SCHEMA, C.TABLE_NAME, 
    C.COLUMN_NAME, 
    'DECIMAL('+ CAST(C.NUMERIC_PRECISION as varchar(2)) + ',0)' as [Currently Data Type],
    case 
       when NUMERIC_PRECISION <= 9 then 5 
       when NUMERIC_PRECISION <= 19 then 9
       when NUMERIC_PRECISION <= 28 then 13
       when NUMERIC_PRECISION <= 38 then 17
    end as [Used Bytes],
    case 
       when NUMERIC_PRECISION between 1 and 2 then 'TINYINT'
       when NUMERIC_PRECISION = 3 then 'SMALLINT'
       when NUMERIC_PRECISION between 4 and 9 then 'INT'
       when NUMERIC_PRECISION between 10 and 18 then 'BIGINT'
       else '-'
    end as [Proposed Data Type],
    case 
       when NUMERIC_PRECISION <= 2 then 4
       when NUMERIC_PRECISION = 3 then 3
       when NUMERIC_PRECISION <= 9 then 1
       when NUMERIC_PRECISION <= 18 then 1
       else 0
    end as [Saved Bytes per Column]
FROM INFORMATION_SCHEMA.COLUMNS  C
JOIN INFORMATION_SCHEMA.tables T ON
    C.TABLE_SCHEMA = T.TABLE_SCHEMA and
    C.TABLE_NAME = T.TABLE_NAME 
WHERE
    T.TABLE_TYPE = 'BASE TABLE' AND 
    C.DATA_TYPE = 'decimal' AND 
    C.NUMERIC_SCALE = 0
ORDER BY
    T.TABLE_SCHEMA, T.TABLE_NAME, C.COLUMN_NAME
GO

Terminando i ragionamenti, credo che l’uso di un DECIMAL con scala = 0 sia utile soltanto nel momento in cui ho una di queste due necessità:

• memorizzare valori maggiori di 9.223.372.036.854.775.807
• memorizzare valori minori di -9.223.372.036.854.775.808

In sostanza gestire interi che non è possibile, per la loro dimensione, memorizzare con il tipo BIGINT.

Nota.

Visto che abbiamo parlato di DECIMAL, ricordo che il formato di archiviazione vardecimal è deprecato:

Con la compressione dei dati di SQL Server 2012 vengono compressi sia i valori decimali sia gli altri tipi di dati.
È consigliabile utilizzare la compressione dei dati anziché il formato di archiviazione vardecimal.

Per il dettaglio delle funzionalità dichiarate come deprecate con SQL Server 2012, si veda qui.

Da qualche giorno è disponibile la Community Technology Preview 2 (CTP2), ecco la mia lista:

• In-Memory OLTP
• Hekaton, developed in partnership with Microsoft Research, a new memory optimized OLTP database engine
• IO Resource Governance
• You can use the new MIN_IOPS_PER_VOLUME and MAX_IOPS_PER_VOLUME settings to control the physical IOs issued for user threads for a given resource pool
• Encrypted Backup
• AES 128, AES 192, AES 256, 3DES
• AlwaysON Secondaries on Azure
• A new asynchronous replica for the availability group in Windows Azure end-to-end, from creating the Windows Azure virtual machine to configuring the availability group listener in the Windows Azure subnet
• SELECT ... INTO
• statement improved and can now operate in parallel

Se iniziate a mettere le mani sulla nuova versione, non dimenticatevi di scaricare l’aggiornamento dei SQL Server Data Tools.

Info qui.

Il database engine ci solleva, così, dall’onere di verificare ed attribuire un valore che non sia già stato utilizzato.

Questa caratteristica può essere applicata solo su colonne (che siano non nullabili) di tipo:

• tinyint
• smallint
• int
• bigint
• decimal (con scala a 0)

Con altri tipi di dato sarebbe naturalmente impossibile definire questa proprietà:

Identity column 'idRecord' must be of data type int, bigint, smallint, tinyint, or decimal or numeric with a scale of 0, and constrained to be nonnullable.

Ogni data type, è sempre bene ricordarsi, ha un numero finito di cifre disponibili.

Questo significa che è utile monitorare i valori utilizzati da queste colonne per evitare spiacevoli problemi (limite massimo raggiunto) che porterebbero ad errori simili a questo:

Arithmetic overflow error converting IDENTITY to data type int.

Naturalmente l’idea, quando modelliamo le tabelle, è quella di scegliere il tipo di dato più appropriato che, per i nostri ragionamenti, significa scegliere un tipo intero che sia in grado di memorizzare tutte le righe che dovrò gestire.

L’idea potrebbe essere quindi quella di costruire una query che sia in grado di fornirci lo stato di ogni colonna impostata come IDENTITY.

Qualcosa come:

Questo lo script:

;WITH identityRange AS 
(
    SELECT
       'BIGINT' AS [name],
       9223372036854775807 AS MaxValue,
       -9223372036854775808 AS MinValue
    UNION
    SELECT
       'INT',
       2147483647,
       -2147483648
    UNION
    SELECT
       'SMALLINT',
       32767,
       -32768
    UNION
    SELECT
       'TINYINT',
       255,
       0
    UNION
    SELECT
       'DECIMAL',
       NULL,
       NULL
),
identityBuffer AS 
(
    SELECT
       QUOTENAME(OBJECT_SCHEMA_NAME(idCol.object_id)) + '.' +
       QUOTENAME(O.name) AS tableName,
       idCol.name AS columnName,
       CASE WHEN IR.name = 'DECIMAL' THEN ('DECIMAL(' +  
                (
                    SELECT CAST(NUMERIC_PRECISION AS VARCHAR(2)) FROM INFORMATION_SCHEMA.columns I 
                    WHERE 
                       I.TABLE_SCHEMA = OBJECT_SCHEMA_NAME(idCol.object_id) AND 
                       I.TABLE_NAME = O.name AND 
                       I.COLUMN_NAME = idCol.Name
                )
        + ')')
          ELSE UPPER(IR.name) END AS dataType,
       CAST(idCol.seed_value AS decimal(38, 0)) AS startingNumber,
       idCol.increment_value as incrementValue,
       CAST(idCol.last_value AS decimal(38, 0)) AS lastValueUsed,
       CAST(
          CASE WHEN IR.name = 'DECIMAL' THEN 
             REPLICATE('9', 
                    (
                    SELECT NUMERIC_PRECISION FROM INFORMATION_SCHEMA.columns I 
                    WHERE 
                       I.TABLE_SCHEMA = OBJECT_SCHEMA_NAME(idCol.object_id) AND 
                       I.TABLE_NAME = O.name AND 
                       I.COLUMN_NAME = idCol.Name)
                    )
          ELSE IR.MaxValue END AS decimal(38, 0)) -
          CAST(ISNULL(idCol.last_value, 0) AS decimal(38, 0)) AS remainingValues,
       CAST(CASE
             WHEN seed_value < 0
             THEN 
             (
                    CAST(
                CASE WHEN IR.name = 'DECIMAL' THEN 
                    REPLICATE('9', 
                          (
                          SELECT NUMERIC_PRECISION FROM INFORMATION_SCHEMA.columns I 
                          WHERE 
                             I.TABLE_SCHEMA = OBJECT_SCHEMA_NAME(idCol.object_id) AND 
                             I.TABLE_NAME = O.name AND 
                             I.COLUMN_NAME = idCol.Name)
                          )
                ELSE IR.MaxValue END AS decimal(38, 0))
             ) - 
             (
                    CAST(
                CASE WHEN IR.name = 'DECIMAL' THEN 
                    '-' + REPLICATE('9', 
                          (
                          SELECT NUMERIC_PRECISION FROM INFORMATION_SCHEMA.columns I 
                          WHERE 
                             I.TABLE_SCHEMA = OBJECT_SCHEMA_NAME(idCol.object_id) AND 
                             I.TABLE_NAME = O.name AND 
                             I.COLUMN_NAME = idCol.Name)
                          )
                ELSE IR.MinValue END AS decimal(38, 0))
             )
             ELSE 
             (
                    CAST(
          CASE WHEN IR.name = 'DECIMAL' THEN 
             REPLICATE('9', 
                    (
                    SELECT NUMERIC_PRECISION FROM INFORMATION_SCHEMA.columns I 
                    WHERE 
                       I.TABLE_SCHEMA = OBJECT_SCHEMA_NAME(idCol.object_id) AND 
                       I.TABLE_NAME = O.name AND 
                       I.COLUMN_NAME = idCol.Name)
                    )
          ELSE IR.MaxValue END AS decimal(38, 0))
             )
          END AS decimal(38, 0)) AS availableRange,
       (
          CAST(
             CASE WHEN IR.name = 'DECIMAL' THEN 
                REPLICATE('9', 
                       (
                       SELECT NUMERIC_PRECISION FROM INFORMATION_SCHEMA.columns I 
                       WHERE 
                          I.TABLE_SCHEMA = OBJECT_SCHEMA_NAME(idCol.object_id) AND 
                          I.TABLE_NAME = O.name AND 
                          I.COLUMN_NAME = idCol.Name)
                       )
             ELSE IR.MaxValue END AS decimal(38, 0))
       ) AS maxValueUsable
    FROM sys.identity_columns idCol 
    JOIN sys.types T ON idCol.system_type_id = T.system_type_id
    JOIN sys.objects O ON idCol.object_id = O.object_id
    JOIN identityRange IR ON T.name = IR.name
    WHERE 
       O.is_ms_shipped = 0
)
SELECT
    identityBuffer.tableName as [Table],
    identityBuffer.columnName as [Column],
    identityBuffer.dataType as [Data Type],
    identityBuffer.startingNumber as [Starting Number],
    identityBuffer.incrementValue as [Increment Value],
    identityBuffer.lastValueUsed as [Last Value Used],
    identityBuffer.maxValueUsable as [Max Value Usable],
    identityBuffer.remainingValues as [Remaining Values],
    CASE
        WHEN identityBuffer.startingNumber < 0
        THEN (-1 * identityBuffer.startingNumber + identityBuffer.lastValueUsed) / identityBuffer.availableRange
        ELSE (identityBuffer.lastValueUsed * 1.0) / identityBuffer.availableRange
    END AS [% Identity Value Consumption]
FROM
    identityBuffer
ORDER BY
    [Table], [Column]

Nota: il fatto che praticamente ogni editor definisca come numero di partenza il numero “1” non significa che questo sia (sempre) buono.

Partendo dall’estremo negativo (se esiste) raddoppiamo le possibilità (le righe).

In questo post condivido un semplice modo per poter capire / studiare come la compressione, a livello di ROW o di PAGE, potrebbe incidere sul nostro database.

L’idea è quella di ottenere una serie di informazioni che possano fornirci le dimensioni attuali e le dimensioni che andremmo ad avere.

Qualcosa come:

Questo lo script:

SET NOCOUNT ON;
DECLARE @option varchar( 10 );
SET @option = 'Page';
/* SET @option = 'Row' */

IF OBJECT_ID( 'tempdb..#indexDetails' )IS NOT NULL
    DROP TABLE #indexDetails;

SELECT
       c.name AS schemaName , 
       b.name AS objectName , 
       a.name AS indexName , 
       a.indid , 
       dpages , 
       CONVERT( numeric( 20 , 2 ) , ROUND( dpages * 8 / 1024.0 , 2 ))AS   dataPagesMB, 
       reserved , 
       CONVERT( numeric( 20 , 2 ) , ROUND( reserved * 8 / 1024.0 , 2 ))AS reservedMB, 
       rowcnt 
INTO #indexDetails
  FROM sys.sysindexes AS a
       INNER JOIN sysobjects AS b ON a.id = b.id
       INNER JOIN sys.schemas AS c ON b.uid = c.schema_id
  WHERE 
    b.type = 'U' AND 
    (a.name NOT LIKE '_WA_Sys%' OR a.name IS NULL) AND 
    CONVERT( numeric( 20 , 2 ) , ROUND( dpages * 8 / 1024.0 , 2 )) >= 0
  ORDER BY dpages;

IF OBJECT_ID( 'tempdb..#error' )IS NOT NULL
    DROP TABLE #error;

CREATE TABLE #error
(
    error_desc varchar( 2000 ) , 
    err_number int , 
    err_severity int , 
    err_state int , 
    err_procedure varchar( 126 ) , 
    err_line int , 
    err_message varchar( 2048 )
);

IF OBJECT_ID( 'tempdb..#dataCompressionDetails' )IS NOT NULL
        DROP TABLE #dataCompressionDetails;

CREATE TABLE #dataCompressionDetails
(
    object_name sysname , 
    schema_name sysname , 
    index_id int , 
    partition_number int , 
    size_with_current_compression_setting_KB bigint , 
    size_with_requested_compression_setting_KB bigint , 
    sample_size_with_current_compression_setting_KB bigint , 
    sample_size_with_requested_compression_setting_KB bigint 
);

DECLARE @TSql varchar( 8000 );
DECLARE myCursor CURSOR
    FOR SELECT
               'BEGIN TRY INSERT INTO #dataCompressionDetails EXEC sp_estimate_data_compression_savings     @schema_name = ''' + c.name + ''',     
            @object_name = ''' + b.name + ''',     @index_id = ' + CONVERT( varchar( 10 ) , a.indid ) + ',     @partition_number = NULL,     
            @data_compression = ''' + @option + ''' ; END TRY BEGIN CATCH INSERT INTO #error SELECT    
            ''[' + c.name + '].[' + b.name + '] failed in compression eval. The minimum row size 
            plus internal overhead exceeds the maximum allowable table row size (8060 bytes).'' AS Error_Desc        ,
            ERROR_NUMBER() AS ErrorNumber        ,ERROR_SEVERITY() AS ErrorSeverity        ,ERROR_STATE() AS ErrorState        ,
            ERROR_PROCEDURE() AS ErrorProcedure        ,ERROR_LINE() AS ErrorLine        ,ERROR_MESSAGE() AS ErrorMessage;
            END CATCH;'
          FROM sys.sysindexes AS a
               INNER JOIN sysobjects AS b ON a.id = b.id
               INNER JOIN sys.schemas AS c ON b.uid = c.schema_id
          WHERE 
          b.type = 'U' AND 
          (a.name NOT LIKE '_WA_Sys%' OR a.name IS NULL) AND 
          CONVERT( numeric( 20 , 2 ) , ROUND( dpages * 8 / 1024.0 , 2 )) >= 0
          ORDER BY
                   dpages; 
OPEN myCursor;
FETCH NEXT FROM myCursor INTO @TSql;
WHILE @@FETCH_STATUS = 0
    BEGIN
        EXEC ( @TSql );
        FETCH NEXT FROM myCursor INTO @TSql;
    END;
CLOSE myCursor;
DEALLOCATE myCursor;


/* Total saving */
SELECT
       cast(SUM( size_with_current_compression_setting_KB ) / 1024.0  as decimal(20,2)) AS                                                      [Original size MB] , 
      cast(SUM( size_with_current_compression_setting_KB ) / 1024.0 / 1024.0  as decimal(20,2)) AS                                        [Original size GB] , 
       cast(SUM( size_with_requested_compression_setting_KB ) / 1024.0  as decimal(20,2)) AS                                                    [Compression size MB] , 
      cast(SUM( size_with_requested_compression_setting_KB ) / 1024.0 / 1024.0  as decimal(20,2)) AS                                           [Compression size GB] ,
       cast(SUM( size_with_current_compression_setting_KB - size_with_requested_compression_setting_KB ) / 1024.0 as decimal(20,2)) AS          [Total Saving MB] , 
       cast(SUM( size_with_current_compression_setting_KB - size_with_requested_compression_setting_KB ) / 1024.0 / 1024.0  as decimal(20,2)) AS [Total Saving GB]
FROM #dataCompressionDetails;

/* Summary */
SELECT
       a.schemaName + '.' + a.objectName AS                                                                                          [Table] , 
       a.indexName AS                                                                                                                [Index] , 
       size_with_current_compression_setting_KB AS                                                                                   [Size current KB] , 
       size_with_requested_compression_setting_KB AS                                                                                 [Size compression KB] , 
       Compression_rate = CONVERT( numeric( 20 , 2 ) , ROUND( size_with_requested_compression_setting_KB * 1.0 / size_with_current_compression_setting_KB , 2 )) , 
       size_with_current_compression_setting_KB - size_with_requested_compression_setting_KB AS                                      [Data Compression Saving KB] , 
       CAST((size_with_current_compression_setting_KB - size_with_requested_compression_setting_KB) / 1024.0 AS numeric( 20 , 2 ))AS [Data Compression Saving MB],
      CAST((size_with_current_compression_setting_KB - size_with_requested_compression_setting_KB) / 1024.0 / 1024.0 AS numeric( 20 , 2 ))AS [Data Compression Saving GB]
  FROM #indexDetails AS a
       INNER JOIN #dataCompressionDetails AS b ON a.objectName COLLATE Latin1_General_CI_AS = b.object_name COLLATE Latin1_General_CI_AS
                                    AND a.indid = b.index_id
  WHERE CONVERT( numeric( 20 , 2 ) , ROUND( size_with_requested_compression_setting_KB * 1.0 / size_with_current_compression_setting_KB , 2 )) <= 1
    AND size_with_current_compression_setting_KB > 0
    AND CONVERT( numeric( 20 , 2 ) , ROUND( size_with_requested_compression_setting_KB * 1.0 / size_with_current_compression_setting_KB , 2 )) < 1
  ORDER BY
           size_with_current_compression_setting_KB - size_with_requested_compression_setting_KB DESC;

/* Total */
SELECT
       schemaName + '.' + objectName AS                                                                             [Table] , 
       SUM( size_current_KB )AS                                                                                     [size current KB] , 
       SUM( size_compression_KB )AS                                                                                 [Size compression KB] , 
       CONVERT( numeric( 20 , 2 ) , ROUND( SUM( size_compression_KB ) * 1.0 / SUM( size_current_KB ) * 1.0 , 2 ))AS [Compression rate] , 
       SUM( size_current_KB ) - SUM( size_compression_KB )AS                                                        [DataCompression saving KB] , 
       CAST((SUM( size_current_KB ) - SUM( size_compression_KB )) / 1024.0 AS decimal( 20 , 2 ))AS                  [DataCompression saving MB],
      CAST((SUM( size_current_KB ) - SUM( size_compression_KB )) / 1024.0 / 1024.0 AS decimal( 20 , 2 ))AS         [DataCompression saving GB]
  FROM( 
        SELECT
               a.schemaName , 
               a.objectName , 
               a.indexName , 
               size_with_current_compression_setting_KB AS                                              size_current_KB , 
               size_with_requested_compression_setting_KB AS                                            size_compression_KB , 
               Compression_rate = CONVERT( numeric( 20 , 2 ) , ROUND( size_with_requested_compression_setting_KB * 1.0 / size_with_current_compression_setting_KB , 2 )) , 
               size_with_current_compression_setting_KB - size_with_requested_compression_setting_KB AS DataCompression_Saving_KB
          FROM #indexDetails AS a
               INNER JOIN #dataCompressionDetails AS b ON a.objectName COLLATE Latin1_General_CI_AS = b.object_name COLLATE Latin1_General_CI_AS
                                            AND a.indid = b.index_id
          WHERE CONVERT( numeric( 20 , 2 ) , ROUND( size_with_requested_compression_setting_KB * 1.0 / size_with_current_compression_setting_KB , 2 )) <= 1
            AND size_with_current_compression_setting_KB > 0
            AND CONVERT( numeric( 20 , 2 ) , ROUND( size_with_requested_compression_setting_KB * 1.0 / size_with_current_compression_setting_KB , 2 )) < 1 )AS a
  GROUP BY
           schemaName , 
           objectName;

/* No compression */
SELECT * FROM #error;