The few most important things to remember are:

1. SQL Server follows the ANSI/ISO SQL-92 specification on how to compare strings with spaces. The ANSI standard requires padding for the character strings used in comparisons so that their lengths match before comparing them.  The padding directly affects WHERE and HAVING clause predicates and other Transact-SQL string comparisons.
2. The only exception to this rule is the LIKE predicate. When the right side of a LIKE predicate expression features a value with a trailing space, SQL Server does not pad the two values to the same length before the comparison occurs.
3. The SET ANSI_PADDING setting does not affect whether SQL Server pads strings before it compares them. SET ANSI_PADDING only affects whether trailing blanks are trimmed from values being inserted into a table, so it affects storage but not comparisons.

There is a simple script to check how it works:

;WITH s AS
(
	SELECT *, DATALENGTH(String) DataLen FROM (VALUES ('abc'), ('abc ')) a(String)
)
SELECT 'EqualWithSpace' Test, * FROM [s] WHERE String = 'abc ' UNION ALL
SELECT 'EqualNoSpace  ', * FROM s WHERE String = 'abc' UNION ALL
SELECT 'GTWithSpace   ', * FROM s WHERE String > 'ab ' UNION ALL
SELECT 'GTNoSpace     ', * FROM s WHERE String > 'ab' UNION ALL
SELECT 'LTWithSpace   ', * FROM s WHERE String < 'abd ' UNION ALL
SELECT 'LTNoSpace     ', * FROM s WHERE String < 'abd' UNION ALL
SELECT 'LikeWithSpace ', * FROM s WHERE String LIKE 'abc %' UNION ALL
SELECT 'LikeNoSpace   ', * FROM s WHERE String LIKE 'abc%'
GO

SET ANSI_PADDING OFF
GO

CREATE TABLE #s (String varchar(10))
GO
INSERT INTO #s VALUES ('abc ')
INSERT INTO #s VALUES ('abc')
GO
SELECT 'EqualWithSpace' Test, *, DATALENGTH(String) DataLen FROM #s WHERE String = 'abc ' UNION ALL
SELECT 'EqualNoSpace  ', *, DATALENGTH(String) FROM #s WHERE String = 'abc' UNION ALL
SELECT 'GTWithSpace   ', *, DATALENGTH(String) FROM #s WHERE String > 'ab ' UNION ALL
SELECT 'GTNoSpace     ', *, DATALENGTH(String) FROM #s WHERE String > 'ab' UNION ALL
SELECT 'LTWithSpace   ', *, DATALENGTH(String) FROM #s WHERE String < 'abd ' UNION ALL
SELECT 'LTNoSpace     ', *, DATALENGTH(String) FROM #s WHERE String < 'abd' UNION ALL
SELECT 'LikeWithSpace ', *, DATALENGTH(String) FROM #s WHERE String LIKE 'abc %' UNION ALL
SELECT 'LikeNoSpace   ', *, DATALENGTH(String) FROM #s WHERE String LIKE 'abc%'
GO

The core change is that our DataLen is now 3 everywhere and this means that SQL Server stored our data without padding spaces. We see that all rows for LIKE are gone In our result set because compare conditions don’t match.

You should remember two other important things:

• SET ANSI_PADDING is a deprecated feature for Azure SQL and will be deprecated for SQL Server soon
• SET ANSI_PADDING should be set to ON always

Pokud v našem primární klíči využijeme i IDENTITY, je třeba si dát velký pozor, pokud náš ETL proces pracuje v transakci a není úplně neobvyklé, že dojde k rollbacku transakce. Potom můžeme velice lehce narazit na situaci, kdy se snažíme vložit do naší dimenzionální tabulky nové řádky, ale tabulka nám říká, že hodnota primárního klíče, kterou chceme vložit, přesahuje délku datového typu, ačkoliv po inspekcí tabulky samotné vidíme, že je v ní mnohem méně záznamů, než je maximální velikost datového typu, nebo je dokonce prázdná.

Vše si ukážeme na jednoduchém příkladu:

Vytvoříme si tabulku dbo.SampleTable, která má primární klíč ID datového typu TINYINT a nastaveno IDENTITY(1,1). Maximální hodnota, kterou můžeme do TINYINT uložit je 255, tedy naše tabulka může obsahovat maximálně 256 řádků (včetně 0 by to bylo 256).

CREATE TABLE [dbo].[SampleTable] (
	[ID] TINYINT NOT NULL IDENTITY(1,1),
	[Name] VARCHAR(10)
)
GO

Nyní budeme do tabulky vkládat řádky, ale vždy provedeme rollback dané transakce. K simulaci využijeme volání GO 255, což je funkce SQL Server Management Studia, nikoliv T-SQL syntax.

BEGIN TRAN

	INSERT INTO [dbo].[SampleTable] ([Name]) 
		VALUES ('Test')

ROLLBACK
GO 255

Pokud se nyní podíváme, jaká data naše tabulka obsahuje, je přesně podle očekávání prázdná:

SELECT * FROM [dbo].[SampleTable] [st]
GO

Nyní pojďme do tabulky vložit další řádek:

INSERT INTO [dbo].[SampleTable] ([Name]) 
	VALUES ('Test')
GO

A zde již přichází poněkud nečekaně chyba. Řádek se nepodařilo vložit, protože další hodnota, kterou vygenerovalo IDENTITY je 256, což přesahuje velikost datového typu TINYINT. To si můžeme ověřit i takto:

SELECT IDENT_CURRENT('dbo.SampleTable')
GO

Vidíme, že poslední přiřazená hodnota je 255 a další následující bude opravdu 256.

Řešení celé situace je na první pohled jednoduché:

DBCC CHECKIDENT('dbo.SampleTable',RESEED, 0)
GO

Provedli jsme RESEED tabulky a nastavili sekvenci opět od 0. Zkusme nyní vložit další řádek:

INSERT INTO [dbo].[SampleTable] ([Name]) 
	VALUES ('Test')
GO

SELECT * FROM [dbo].[SampleTable] [st]
GO

Vidíme, že vše prošlo bez problémů a můžeme vesele vkládat ještě dalších 254 řádků.

To, co v naše scénáři vypadá triviálně, nás ovšem v reálném provozu může řádně potrápit. Pokud se nám objeví chybová hláška zobrazená výše, stojíme před následujícími otázkami:

• Na jaké tabulce se chyba vyskytla? V chybové zprávě tuto informaci nenajdeme a pokud naše ETL transakce vkládá do desítek dimenzionálních tabulek, bude hledání bez dobrého logování celého procesu opravu zdlouhavé.
• Pokud již identifikujeme tabulku, budeme čekat, že bude obsahovat 255 řádků a my se snažíme vložit další řádek a budeme proto přemýšlet o změně velikosti datového typu. Po zobrazení dat v tabulce ale může přijít velké překvapení: tabulka obsahuje méně než 255 řádků nebo je dokonce prázdná.
• V naše případě jsme pracovali v prázdnou tabulkou, ale v reálné scénáři může tabulka obsahovat třeba 20 řádků s různě rozloženými hodnotami primárního klíče, třeba 14, 78, 128, kde mezery v sekvenci vznikly právě každým rollbackem ETL transakce. V tomto případě budeme hledat nějakou rozumnou hodnotu, ke které provedeme RESEED, opravdu těžko a nezbude nám, než pracně provést update všech hodnot primárního klíče na hodnoty začínající od 1. Jak velký to může být úkol v případě rozsáhlé faktové tabulky netřeba zmiňovat.
• Pokud skutečně vyčerpáme 255 hodnot a budeme potřebovat zvětšit datový typ, je třeba změnu provést i ve faktového tabulce, což může být při miliardách záznamů opravdu zdlouhavý a komplikovaný úkol.

Při návrhu datového modelu a ETL procesu tedy mysleme vždy na následující:

• Je uvažovaný datový typ skutečně dostačující pro budoucnost? Nebude jeho pozdější změna tak komplikovaná, že momentální volba nejmenšího možného datového typu nestojí a tím získaná úspora místa a lehké zvýšení výkonu nám za to nestojí?
• V rámci ETL procesu musíme myslet při rollbacku i na chování IDENTITY() a zvolit RESSED při rollbacku transakce, případně uvažovat o použití sekvencí.

Není to nic těžkého a vše funguje poměrně efektivně, pokud správně pracujeme s transakcemi. Ideální je, že nám nevadí, pokud je nějaké ID vygenerováno, ale následně se nepoužije, protože navazující transakce byla odrolována. Pak můžeme jednoduše volat naši proceduru mimo transakci a nemusíme se bát zámků nebo jiných potíží s výkonem vyjma případu, že bychom narazili na omezení na úrovni úložiště nebo interních zámků SQL Serveru (latches), pokud bychom nová IDčka generovali rychlostí několika tisíc a více položek za vteřinu.

Ve skriptu níže si vytvoříme jednoduchou uloženou proceduru, která zapisuje vždy jeden nový řádek do tabulky [dbo].[IdsTable], která drží naše již vygenerovaná IDčka. Procedura nám vrací hodnotu SCOPE_IDENTITY() posledně vloženého záznamu jako výstupní parametr @Id, se kterým již můžeme dále pracovat.  Skript si v ukázce pustíme 10x pomocí GO 10 a jednotlivá IDčka vidíme ve výstupní okně Management Studia.

CREATE TABLE [dbo].[IdsTable]
(
    [Id] INT IDENTITY (1,1) PRIMARY KEY
)
GO

CREATE PROCEDURE [dbo].[GetNewID] 
    @NewId BIGINT OUTPUT
AS
BEGIN
    SET NOCOUNT ON;

    INSERT INTO [dbo].[IdsTable] DEFAULT VALUES
    SET @NewId = SCOPE_IDENTITY()
END
GO

DECLARE @Id INT

EXEC [dbo].[GetNewID] @Id OUTPUT

PRINT @Id
GO 10

-- Varianta 1
DECLARE @name NVARCHAR(128)
DECLARE cur CURSOR FAST_FORWARD FOR
    SELECT name
    FROM sys.tables
    WHERE name LIKE 'tbl%'
    ORDER BY name
 
OPEN cur
FETCH NEXT FROM cur INTO @name
WHILE @@FETCH_STATUS = 0
BEGIN
 
    EXECUTE ('delete from ' + @name)
 
    FETCH NEXT FROM cur INTO @name
END

CLOSE cur
DEALLOCATE cur

-- Varianta 2
DECLARE @name NVARCHAR(128)
DECLARE cur CURSOR FAST_FORWARD FOR
    SELECT name
    FROM sys.tables
    WHERE name LIKE 'tbl%'
    ORDER BY name
 
OPEN cur
WHILE 1 = 1
BEGIN
    FETCH NEXT FROM cur INTO @Name
    IF @@FETCH_STATUS <> 0
        BREAK
 
    EXECUTE ('delete from ' + @name)
 
END

CLOSE cur
DEALLOCATE cur

Pomocí níže uvedeného skriptu můžeme vyhledat výskyt určitého textového řetězce ve všech tabulkách v databázi, v jejímž kontextu je skript spuštěn. Prohledávat můžeme všechny sloupce, které mají textový datový typ, tedy CHAR, NCHAR, VARCHAR, NVARCHAR, TEXT a NTEXT. V případě unicode datových typů (NCHAR, NVARCHAR, NTEXT) je třeba nezapomenout uvést N před apostrofy s řetězce, který hledáme, jinak nebudou sloupce prohledávány jako unicode a řetězec nebude nalezen, ačkoli v se v databázi vyskytuje.

Skript nejprve naplní cur kursor seznamem všech tabulek v databázi a jejich sloupců, které jsou některého z výše uvedených textových datových typů. Poté je tato vstupní množina iterována a pro každý sloupec je pomocí dynamického sql vytvořen sql dotaz, který hledá pomocí operátoru LIKE náš řetezec ve všech řádcích daného sloupce. Do lokální dočasné tabulky #Result je vložen řádek se jménem tabulky, sloupce a počtem řádků, které obsahují hledaný řetězec. Na konci skriptu jsou z #Result tabulky vybrány ty sloupce, kde se hledaný řetězec vyskytl alespoň jednou.

SET NOCOUNT ON

DECLARE @Stmt VARCHAR(MAX), 
        @SchemaName SYSNAME, 
        @TableName SYSNAME, 
        @ColumnName SYSNAME, 
        @What NVARCHAR(200), 
        @NL CHAR(1),
        @Err NVARCHAR(MAX),
        @Cnt INT

CREATE TABLE #Result (TableName SYSNAME, ColumnName SYSNAME, Cnt INT)

SET @What = N'AKU'

SET @NL = CHAR(13)

DECLARE cur CURSOR FOR 
    SELECT sch.name, t.name, c.name 
    FROM sys.columns c 
        INNER JOIN sys.tables t ON t.object_id = c.object_id
        INNER JOIN sys.types tp ON tp.system_type_id = c.system_type_id
        INNER JOIN sys.schemas sch ON sch.schema_id = t.schema_id
    WHERE tp.name IN ('char','nchar','varchar','nvarchar','text','ntext')
      AND t.type_desc = 'USER_TABLE'
    ORDER BY t.name, c.name

OPEN cur
WHILE 1 = 1
BEGIN
    FETCH NEXT FROM cur INTO @SchemaName, @TableName, @ColumnName
    IF @@FETCH_STATUS <> 0
        BREAK

     PRINT @TableName + ' => ' + @ColumnName
    
    SET @Stmt = 'INSERT INTO #Result' + @NL + 
                '    SELECT ''' +  @TableName + ''', ''' + @ColumnName + ''', COUNT(*)' + @NL +
                '    FROM [' + @SchemaName + '].[' + @TableName + '] (nolock)' + @NL + 
                '    WHERE [' + @ColumnName + '] Like ''%' + @What + '%'''
    BEGIN TRY
        EXEC(@Stmt)
    END TRY
    BEGIN CATCH
    
        SET @Err = '[' + @SchemaName + '].[' + @TableName + '] => ' + ERROR_MESSAGE() + @NL + @Stmt
    
        RAISERROR(@Err, 16, 1) WITH NOWAIT
    
    END CATCH
        
    END

SELECT * FROM #Result WHERE Cnt > 0

Error:
CLOSE cur
DEALLOCATE cur
DROP TABLE #Result

Pomocí analytické funkce ROW_NUMBER() získáme pro každý řádek číslo, které bude unikátní vždy v rámci dané partition, kterou v příkladu níže vytvoříme tak, že pomocí klauzule PARITION BY rozdělíme řádky do skupin podle hodnot ve sloupci Value1. V každé takto vytvořené skupině budou potom řádky očíslovány vzestupě od jedné.

Z takto vytvořené virtuální tabulky poté vybereme pouze řádky, které jsou první v každé skupině. Všechny ostatní a tedy duplicitní záznamy budou z výsledkové sady vyjmuty.

CREATE TABLE dbo.SampleTable (
    Id INT,
    Value1 VARCHAR(10)
)
GO    

INSERT INTO dbo.SampleTable
    SELECT 1, 'Val1' UNION ALL
    SELECT 2, 'Val2' UNION ALL
    SELECT 3, 'Val1' UNION ALL
    SELECT 4, 'Val4'
GO

SELECT * FROM dbo.SampleTable
GO

;WITH cte AS
(
    SELECT
        *, ROW_NUMBER() OVER (PARTITION BY Value1 ORDER BY Id) RN
    FROM dbo.SampleTable
)
DELETE FROM cte
WHERE RN > 1
GO

SELECT * FROM dbo.SampleTable
GO

V prvním případě jsme odstraňovali duplicitní řádky z tabulky, která neměla žádný primární klíč. Nyní si ukážeme, jak odstranit řádky z tabulky, která má primární klíč s IDENTITY(1,1). Můžeme použít metodu podobnou prvnímu příkladu (CTE)  nebo jednoduchý dotaz s vnitřním dotazem ve WHERE podmínce.

-- create SampleTable
CREATE TABLE dbo.tblSampleTable
(
    Id INT IDENTITY(1,1) NOT NULL PRIMARY KEY,
    ObjectId INT NOT NULL,
    ObjectName SYSNAME NOT NULL
)
GO

-- populate sample data
INSERT INTO dbo.tblSampleTable
        ( ObjectId, ObjectName )
    SELECT TOP(1000000) c1.object_id, c1.name
    FROM master.sys.columns c1
        CROSS JOIN master.sys.columns c2
        CROSS JOIN master.sys.columns c3
GO    

-- version 1
;WITH Dupl as
(
    SELECT *, ROW_NUMBER() OVER (PARTITION BY ObjectId, ObjectName ORDER BY (SELECT NULL)) as RN 
    from dbo.tblSampleTable
)
DELETE FROM dbo.tblSampleTable
WHERE Id NOT IN (SELECT Id FROM Dupl WHERE RN = 1)
GO

-- version 2
DELETE FROM dbo.tblSampleTable
WHERE Id NOT IN 
(
    SELECT MIN(Id) Id
    FROM dbo.tblSampleTable
    GROUP BY ObjectId, ObjectName
)
GO

• operace je časově náročná, protože mazání každého jednotlivého řádku se zapisuje do transakčního logu
• nárůst transakčního logu může být opravdu enormní a přesáhnout jak velikost původní tabulky tak i dostupné místo na úložišti
• po celou dobu provádění transakce jsou nad tabulkou zámky (nad celou tabulkou, případně oddílem tabulky (partition) nebo konkrétními řádky)
• celkový výkon systému je snížen, jsou-li intenzivně využívání systémové prostředky, zejména IO

Stojíme-li před podobným úkolem, jedním z doporučených postupů je mazat data z tabulky po menších částech pomocí jednoduchého batch generátoru. V článku si ukážeme jednu z možných implementací takového generátoru i její praktické využití.

Základem generátoru je využití rekurze, kterou umožňuje Common Table Expression (CTE):

DECLARE @BatchSize INT
DECLARE @BatchCount INT

SET @BatchSize = 50
SET @BatchCount = 8

;WITH Batchlist AS
(
    SELECT 1 BatchId, 1 BatchStart, @BatchSize BatchEnd
    UNION ALL
    SELECT BatchId + 1, @BatchSize + BatchStart, @BatchSize + BatchEnd
    FROM BatchList
    WHERE BatchId <= @BatchCount - 1
)
SELECT *
FROM BatchList
OPTION (MAXRECURSION 0)

Nejprve jsme vytvořili dvě proměnné:

• @BatchSize je velikost jednotlivé dávky, tedy kolik řádků např. budeme později chtít odmazat v jednom kole
• @BatchCount je počet dávek

V našem příkladě definujeme 8 dávek po 50-ti členech, celkem tedy 400 jednotlivých členů.

Rekurzivní CTE funguje tak, že nejprve nadefinujeme tzv. kotvu:

SELECT 1 BatchId, 1 BatchStart, @BatchSize BatchEnd

a k ní postupně pomocí UNION ALL přidáváme řádky, které získáváme rekurzivním voláním již samotné tabulky BatchList:

SELECT BatchId + 1, @BatchSize + BatchStart, @BatchSize + BatchEnd
FROM BatchList
WHERE BatchId <= @BatchCount - 1

Důležité je nezapomenout připojit k dotazu, který nám vrací data z CTE BatchList, tabulkový hint MAXREXURSION 0, specifikující, kolikrát SQL Server provede rekurzivní operaci, než dojde k jejímu přerušení. MAXRECURSION může nabývat hodnot 0 až 32767, kde 0 znamená neomezený počet cyklů. Pokud nastavení MAXRECURSION neprovedeme, použije se výchozí hodnota 100 a po tomto počty cyklů SQL Server transakci přeruší s chybou a provede její rollback.

Praktická aplikace: Vymazání velké tabulky

Nyní si ukážeme, jak můžeme náš batch generátor využít pro smazání dat z velké tabulky po částech a vyhnout se tím možným problém zmíněným výše. Nejprve si vytvoříme testovací tabulku dbo.SampleData, kterou naplníme 100369 řádky. K naplnění využijeme CROSS JOIN mezi systémovými tabulkami spt_values master databáze:

CREATE TABLE dbo.SampleData
( ID INT NOT NULL IDENTITY(1,1) PRIMARY KEY,
	  Value VARCHAR(100)
)
GO

INSERT INTO dbo.SampleData
	(Value)
	SELECT TOP (100399)
		s1.name + '_' + s2.name
    FROM master..spt_values s1
		CROSS JOIN master..spt_values s2
GO

SELECT COUNT(*) FROM dbo.SampleData
GO

Kontrolní COUNT(*) na v posledním příkazu nám musí vrátit očekávaný počet řádků.

Nyní rozšíříme batch generátor tak, aby si sám zjistil z tabulky dbo.SampleData, kolik řádků obsahuje, připravil dávky pro mazání o velikosti 30.000 řádků. V následujícím WHILE cyklu provedeme iteraci připravených dávek v tabulce @Batches a samotné mazání.

SET NOCOUNT ON

DECLARE @BatchSize INT
DECLARE @BatchCount INT
DECLARE @BatchId INT
DECLARE @BatchStart INT
DECLARE @BatchEnd INT
DECLARE @Batches TABLE (BatchId INT NOT NULL PRIMARY KEY,
						BatchStart INT NOT NULL,
						BatchEnd INT NOT NULL)

SET @BatchSize = 30000
SET @BatchCount = (SELECT COUNT(*) / @BatchSize + CASE WHEN COUNT(*) % @BatchSize > 0 THEN 1 ELSE 0 END FROM dbo.SampleData)

;WITH Batchlist AS
(
    SELECT 1 BatchId, 1 BatchStart, @BatchSize BatchEnd
    UNION ALL
    SELECT BatchId + 1, @BatchSize + BatchStart, @BatchSize + BatchEnd
    FROM BatchList
    WHERE BatchId <= @BatchCount-1
)
INSERT INTO @Batches
	(BatchId, BatchStart, BatchEnd)
	SELECT 
		BatchId, BatchStart, BatchEnd
	FROM BatchList
	OPTION (MAXRECURSION 0)

WHILE EXISTS (SELECT * FROM @Batches)
BEGIN

	SELECT TOP(1)
		@BatchId = BatchId,
		@BatchStart = BatchStart,
		@BatchEnd = BatchEnd
	FROM @Batches
	ORDER BY BatchId

	PRINT CAST(@BatchId AS VARCHAR(10)) + ' => ' + CAST(@BatchStart AS VARCHAR(10)) + ' - ' + CAST(@BatchEnd AS VARCHAR(10))

	DELETE FROM dbo.SampleData WHERE ID BETWEEN @BatchStart AND @BatchEnd

	PRINT CAST(@@ROWCOUNT AS VARCHAR(10))
	
	DELETE FROM @Batches WHERE BatchId = @BatchId

END
GO

Ze stavových zpráv vidíme, že došlo ke smazání všech řádků z tabulek. Generátor správně vytvořil i čtvrtou dávku, která pokryje zbývající řádky po smazání předchozích 90 tisíc řádků.

V našem ideálním testu jsme prováděli vyhledání řádků ke smazání pomocí podmínky, která předpokládá, že sloupec ID v tabulce dbo.SampleData obsahuje unikátní hodnoty číslované od 1 a nejvyšší hodnota je shodná s počtem řádků v tabulce:

DELETE FROM dbo.SampleData WHERE ID BETWEEN @BatchStart AND @BatchEnd

Podobný scénář není vždy možný a mnohem jednodušší může být odmazávat data z tabulky vždy po dávce, kdy řádky ke smazání nebudeme vybírat  pomocí selektivní podmínky, ale využijeme klauzuli TOP(počet_řádků), která vždy smaže daný počet_řádků. Pokud nebudeme provádět explitní řazení řádků ke smazání pomocí ORDER BY, můžeme dosáhnout výrazně větší rychlosti a snížit využití systémových prostředků, protože SQL Server nebude nucen vykonávat SORT operaci v exekučním plánu, která patří k těm nejnákladnějším.

Nyní zjednodušíme celý batch generátor takto:

DECLARE @BatchSize INT
DECLARE @BatchId INT
DECLARE @TotalRows INT
DECLARE @RowsToDelete INT
DECLARE @Batches TABLE (BatchId INT NOT NULL PRIMARY KEY,
			RowsToDelete INT NOT NULL)

SET @BatchSize = 30000
SET @RowsToDelete = (SELECT COUNT(*) FROM dbo.SampleData)

;WITH Batchlist AS
(
    SELECT 1 BatchId
    UNION ALL
    SELECT BatchId + 1
    FROM BatchList
    WHERE BatchId < ( @RowsToDelete / @BatchSize + CASE WHEN @RowsToDelete % @BatchSize > 0 THEN 1 ELSE 0 END )
)
INSERT INTO @Batches
	(BatchId, RowsToDelete)
	SELECT 
		BatchId, CASE
			    WHEN (BatchId * @BatchSize) <= @RowsToDelete THEN @BatchSize
			    ELSE @RowsToDelete % @BatchSize
			 END
	FROM BatchList
	OPTION (MAXRECURSION 0)

SELECT * FROM @Batches
GO

Generátor vygeneroval opět 4 dávky, ale místo rozmezí od – do určité hodnoty máme nyní ve sloupci RowsToDelete počet řádků, které se mají z tabulky smazat s využitím TOP() klauzule. Naše podmínka, určující data ke smazání v jednotlivé dávce, bude nově vypadat takto:

DELETE TOP(@RowsToDelete) FROM dbo.SampleData

A celý skript včetně WHILE cyklu takto:

DECLARE @BatchSize INT
DECLARE @BatchId INT
DECLARE @TotalRows INT
DECLARE @RowsToDelete INT
DECLARE @Batches TABLE (BatchId INT NOT NULL PRIMARY KEY,
						RowsToDelete INT NOT NULL)

SET @BatchSize = 30000
SET @RowsToDelete = (SELECT COUNT(*) FROM dbo.SampleData)

;WITH Batchlist AS
(
    SELECT 1 BatchId
    UNION ALL
    SELECT BatchId + 1
    FROM BatchList
    WHERE BatchId < ( @RowsToDelete / @BatchSize + CASE WHEN @RowsToDelete % @BatchSize > 0 THEN 1 ELSE 0 END )
)
INSERT INTO @Batches
	(BatchId, RowsToDelete)
	SELECT 
		BatchId, CASE
					WHEN (BatchId * @BatchSize) <= @RowsToDelete THEN @BatchSize
					ELSE @RowsToDelete % @BatchSize
				 END
	FROM BatchList
	OPTION (MAXRECURSION 0)

WHILE EXISTS (SELECT * FROM @Batches)
BEGIN

	SELECT TOP(1)
		@BatchId = BatchId,
		@RowsToDelete = RowsToDelete
	FROM @Batches
	ORDER BY BatchId

	PRINT CAST(@BatchId AS VARCHAR(10))
	
	DELETE TOP(@RowsToDelete) FROM dbo.SampleData

	PRINT CAST(@@ROWCOUNT AS VARCHAR(10))
	
	DELETE FROM @Batches WHERE BatchId = @BatchId

END
GO

Všechny řádky z tabulky byly podle očekávání smazány.

První způsob generování dávek se hodí spíše pro speciální případy, kdy potřebujeme mazat data podle určitého rozsahu hodnot, např. objednávky podle data. Druhý způsob je univerzální a ideální pro smazání všech dat v tabulce.

Především je nutné zmínit, že xp_dirtree je nedokumentovaná a nepodporovaná procedura a její použití může přinést později problémy v případě upgrade SQL Serveru na vyšší verzi.

xp_dirtree má tyto vstupní parametry:

• Cesta na úložišti, kde chceme zahájit procházení případně vypsat obsah.
• Hloubka, do které se mají složky procházet. Ve výchozím nastavení 0 – bez omezení.
• Nastavení, zda zobrazovat pouze složky nebo i soubory. Ve výchozím nastavení 0 – nezobrazovat soubory.

Nyní praktický příklad: necháme si vypsat kompletní obsah adresáře “c:\Program Files\Microsoft SQL Server\120\SDK”. Chceme vidět všechny podložky do omezené hloubky a také nás zajímají soubory ve složkách. Výstup procedury uložíme do proměnné @DirList pro případné pozdější použití.

DECLARE @DirList TABLE ( DirName VARCHAR(128), Depth INT, IsFile BIT )

INSERT @DirList
 EXEC master..xp_dirtree 'c:\Program Files\Microsoft SQL Server\120\SDK',0, 1
 
SELECT * FROM @DirList 
GO

xp_cmdshell

Druhou možnost nám přináší xp_cmdshell, která je na rozdíl od xp_dirtree plně dokumentovaná a podporovaná. Pomocí této procedury můžeme spouštět libovolný kód pro příkazovou řádku, což ovšem není jen výhoda, ale také značné bezpečností riziko. Právě z toho důvodu je procedura ve výchozím stavu zakázána a je potřeba ji povolit pomocí konfigurační procedury sp_configure:

EXEC [sys].[sp_configure] 'show advanced options', 1
GO
RECONFIGURE
GO
EXEC [sys].[sp_configure] 'xp_cmdshell', 1
GO
RECONFIGURE
GO

Volání procedury je jednoduché a pro zobrazení obsahu adresáře použijeme běžné dosové příkazy:

EXEC master..xp_cmdshell 'DIR /b c:\Program Files\Microsoft SQL Server\120\'
GO

Výstup z volání xp_cmdshell můžeme pochopitelně uložit pro pozdější zpracování obdobným způsobem jako v předchozím příkladu.

Nejprve si ale musíme vytvořit testovací soubor C:\Test\Test.sql, do kterého umístíme tento jednoduchý skript:

SELECT 'HELLO WORLD' AS QueryResult

Při dalším testování musíme mít na paměti, že naše testovací instance musí mít k adresáři a souboru přístup, tzn. účtu, pod kterým instance běží, musíme přidat alespoň Read přístup.

1. OPENROWSET()

Funkce OPENROWSET() představuje ad hoc OLE DB připojení k datovému zdroji, který může být i soubor v souborovém systému:

DECLARE @Script VARCHAR(MAX)

SELECT
    @Script = f.BulkColumn
FROM OPENROWSET(BULK 'C:\Test\Test.sql', single_clob) f

EXEC (@Script)
GO

Obsah souboru jsme načetli do proměnné @Script a vykonali jej pomocí EXEC() příkazu.

2. SQLCMD Mode

SQLCMD mode je nastavení Management Studia, které přepne aktuálně otevřené okno do režimu, ve kterém je možné pří používat příkazy, kterým rozumí konzolová aplikace sqlcmd.exe.

Přepnutí provedeme z nabídky Query -> SQLCMD Mode:

Spuštění našeho souboru provedeme použitím příkazu :r :

Pozor ovšem musíme dát na jednu podstatnou věc: Pokud budeme tímto způsobem pouštět více souborů v jedné dávce (batch), chová se SSMS na pozadí tak, že nejprve všechny souboru spojí do jedné dávky a teprve poté je odešle na server jako jeden batch. Abychom mohli uvedené chování demonstrovat, vytvoříme si dva soubory Test1.sql a Test2.sql, do kterých umístíme tyto skripty:

-- Soubor Test1.sql
SELECT 'HELLO WORLD Test1.sql' AS QueryResult

-- Soubor Test2.sql
SELECT 'HELLO WORLD Test2.sql' AS QueryResult

Oba soubory spustíme ze SSMS:

To podstatné se ovšem odehrálo na pozadí, kdy jsme zachytili v Profileru následující batch:

Vidíme, že SSMS nejprve spojilo oba soubory do jednoho a následně odeslalo na server jako jeden batch.

Čemu to vadí? Stačí si například vzpomenout na pravidlo, že proměnné musí být unikátní v rámci jedno batche.

Soubory upravíme takto:

--Soubor Test1.sql
DECLARE @String NVARCHAR(200)
SET @String = 'HELLO WORLD Test1.sql'
PRINT @String

--Soubor Test2.sql
DECLARE @String NVARCHAR(200)
SET @String = 'HELLO WORLD Test2.sql'
PRINT @String

A po spuštění ze SSMS dostáváme následující chybovou hlášku:

Odpověď je opět v Profileru:

Obsah obou souborů dorazil jako jeden batch a proměnná @String je tak v jeho kontextu definována dvakrát. Řešení je nasnadě: důsledné použití GO, a to buď ve skriptech samotných:

--Soubor Test1.sql
DECLARE @String NVARCHAR(200)
SET @String = 'HELLO WORLD Test1.sql'
PRINT @String
GO

--Soubor Test2.sql
DECLARE @String NVARCHAR(200)
SET @String = 'HELLO WORLD Test2.sql'
PRINT @String
GO

nebo v SSMS okně:

V následujícím skriptu si vše ukážeme na ukázkových datech, kterými bude seznam prvních 10ti tabulek z databáze msdb. Data si jednoduše vložíme do kurzoru a při každé jeho iteraci bude postupně přidávat jednotlivé tagy k proměnné @HTML:

USE msdb
GO

DECLARE @name NVARCHAR(128)
DECLARE @HTML NVARCHAR(MAX)
DECLARE @tr NVARCHAR(20)
DECLARE @_tr NVARCHAR(20)
DECLARE @td NVARCHAR(20)
DECLARE @_td NVARCHAR(20)

SET @tr = '   <tr>';
    SET @td = '      <td>'
    SET @_td = '</td>'
SET @_tr = '   </tr>';

SET @HTML = '<table border = 1>' + CHAR(13)

DECLARE cur CURSOR FAST_FORWARD FOR
    SELECT TOP 10 name
    FROM sys.tables
    ORDER BY name

OPEN cur
FETCH NEXT FROM cur INTO @name
WHILE @@FETCH_STATUS = 0
    BEGIN
        SET @HTML = @HTML + @tr + CHAR(13) + 
                    @td + ISNULL(@name, 'NULL') + @_td + CHAR(13) +
                    @_tr + CHAR(13)                            
    
        FETCH NEXT FROM cur INTO @name
    END
CLOSE cur
DEALLOCATE cur

SET @HTML = SUBSTRING(@HTML, 0, LEN(@HTML) - 1) + '>' + CHAR(13) + '</table>'

PRINT @HTML
GO

Výstup v Management Studiu vypadá takto:

Pokud si data zkopírujeme a uložíme je do souboru v příponou *.html, v prohlížeči uvidíme tuto jednoduchou tabulku (a stejně tak v emailovém klientu, který podporuje zobrazení HTML):