Script para listar objetos dependentes – SQL Server

Neste artigo irei mostrar um script que mostra todos os objetos e suas respectivas dependências em um database.

Este script é útil para algumas situações, por exemplo: você irá realizar uma manutenção em uma procedure, e para isto você precisa saber quais são os objetos ‘dependetes’ desta mesma procedure a fim de verificar se estes objetos dependentes poderão ser impactados. Outro exemplo: você irá adicionar um novo campo em um tabela X, com este script você pode verificar a quais procedures, views ou functions utilizam esta tabela, entre outros.

O scritpt retorna os seguintes campos:

– DBName: nome do database;
– Object_Schema: o schema do objeto pai;
– Object_Name: o nome do objeto pai;
– Child_Schema: o schema do objeto dependente (filho);
– Child_Name: o nome do objeto dependente (filho);
– Child_Type: o tipo do objeto, por exemplo: USER_TABLE, SQL_STORED_PROCEDURE, etc.

O script analisa as views sys.objects e sysdepends.

Script

Use <Database>
SELECT
	 DB_Name() As DBName 
	,Referencing.DBObject_Schema As Object_Schema
	,Referencing.DBObject As [Object_Name]
	,Referenced.Child_DBBObject_Schema As [Child_Schema]
	,Referenced.Child_DBObject As [Child_Name]
	,Referenced.Child_DBObject_Type As [Child_Type]
FROM
(
	SELECT
		 [Object_ID] As DBObject_Id
		,Schema_Name([Schema_ID]) As DBObject_Schema
		,Name As DBObject
		,Type_Desc As DBObject_Type
	FROM
		sys.objects
	WHERE
		Type Not In('D','IT','PK','SQ','UQ','U','S','TR')
) Referencing
LEFT OUTER JOIN
(
	SELECT
		 Id As Parent_DBObject_Id
		,DepId As Child_DBObject_Id
		,Schema_Name([Schema_ID]) As Child_DBBObject_Schema
		,Name As Child_DBObject
		,Type_Desc As Child_DBObject_Type
	FROM
		sysdepends 
	JOIN	
		sys.objects
	ON
		[Object_ID] = DepId
	GROUP BY
		Id, DepId, [Schema_Id], Name, Type_Desc
) Referenced
ON
	Referencing.DBObject_Id = Referenced.Parent_DBObject_Id

Se você quiser obter as dependências de um objeto especifico, a cláusula WHERE deve ficar desta maneira:

(...)
ON
	Referencing.DBObject_Id = Referenced.Parent_DBObject_Id
WHERE 
	Referencing.DBObject = 'ObjectName'

Ou caso você queria obter os objetos pais de um objeto especifico (são referenciados), a cláusula WHERE deve ficar desta maneira:

(...)
ON
	Referencing.DBObject_Id = Referenced.Parent_DBObject_Id
WHERE 
	Referenced.Child_DBObject = 'ObjectName'
Anúncios

Verifica coleta de estatísticas das Tabelas e Índices – Oracle

Neste post irei mostrar um script que verifica a data da última coleta de estatísticas dos índices e tabelas no Oracle.

Antes de mostrar o script, irei deixar alguns links de conteúdo caso você ainda tenha alguma duvida, ou também não compreenda muito bem como funciona a coleta de estatísticas no Oracle, ou como fazer uma coleta de estatísticas, etc. São eles:

Gerenciando Estatísticas do Otimizador;
Coletando estatísticas para o otimizador de queries do Oracle;
Entendendo o Otimizador de Coleta de Estatísticas (conteúdo excelente!);
ALL_IND_STATISTICS.

Ambos scripts retornam os seguintes campos:
Schema: a qual schema (dono) o objeto faz parte;
Objeto: o nome do objeto;
Tipo do Objeto: qual é o tipo do objeto, neste caso: tabela ou índice;
Qtd. de Linhas: retorna o número de registros que o objeto possui;
Ultima Coleta: mostra a data e hora que fora realizada a última analise (coleta) no objeto.

Verifica a coleta de estatísticas das tabelas

SELECT
   S.Owner As "Schema"
  ,S.Table_Name As "Objeto"
  ,S.Object_Type As "Tipo do Objeto"
  ,S.Num_Rows As "Qtd. de Linhas"
  ,To_Char(S.Last_Analyzed, 'yyyy-MM-dd HH24:mm:ss') As "Ultima Coleta"
FROM
  sys.dba_tab_statistics S
WHERE
  S.Owner Not In('SYS', 'SYSTEM', 'SYSMAN', 'DBSNMP')
ORDER BY
  S.Last_Analyzed;

Verifica a coleta de estatísticas dos índices

SELECT
   S.Owner As "Schema"
  ,S.Table_Name As "Objeto"
  ,S.Object_Type As "Tipo do Objeto"
  ,S.Num_Rows As "Qtd. de Linhas"
  ,To_Char(S.Last_Analyzed, 'yyyy-MM-dd HH24:mm:ss') As "Ultima Coleta"
FROM
  sys.dba_ind_statistics S
WHERE
  S.Owner Not In('SYS', 'SYSTEM', 'SYSMAN', 'DBSNMP')
ORDER BY
  S.Last_Analyzed;

Archives gerados por hora/dia – Oracle

Neste artigo mostrarei um script que mostra a quantidade dearchives gerados por hora pelo RMAN.

Este script foi criado pelo Jeffrey M. Hunter. Este script ‘analisa’ a view v$log_history.

Este script pode servir como um troubleshooting simples, por exemplo: às 13hrs sempre são gerados, em média, cerca de 5 de archives, porém alguns dias depois você percebe que foram gerados 10 archives no mesmo horário, ou seja, pode ser indício que algum processo pesado foi executado. É importante lembrar que isto são apenas indícios e que uma análise mais detalhada deverá ser realizada.

SET LINESIZE 145
SET PAGESIZE 9999
SET VERIFY   off

COLUMN H00   FORMAT 999     HEADING '00'
COLUMN H01   FORMAT 999     HEADING '01'
COLUMN H02   FORMAT 999     HEADING '02'
COLUMN H03   FORMAT 999     HEADING '03'
COLUMN H04   FORMAT 999     HEADING '04'
COLUMN H05   FORMAT 999     HEADING '05'
COLUMN H06   FORMAT 999     HEADING '06'
COLUMN H07   FORMAT 999     HEADING '07'
COLUMN H08   FORMAT 999     HEADING '08'
COLUMN H09   FORMAT 999     HEADING '09'
COLUMN H10   FORMAT 999     HEADING '10'
COLUMN H11   FORMAT 999     HEADING '11'
COLUMN H12   FORMAT 999     HEADING '12'
COLUMN H13   FORMAT 999     HEADING '13'
COLUMN H14   FORMAT 999     HEADING '14'
COLUMN H15   FORMAT 999     HEADING '15'
COLUMN H16   FORMAT 999     HEADING '16'
COLUMN H17   FORMAT 999     HEADING '17'
COLUMN H18   FORMAT 999     HEADING '18'
COLUMN H19   FORMAT 999     HEADING '19'
COLUMN H20   FORMAT 999     HEADING '20'
COLUMN H21   FORMAT 999     HEADING '21'
COLUMN H22   FORMAT 999     HEADING '22'
COLUMN H23   FORMAT 999     HEADING '23'
COLUMN TOTAL FORMAT 999,999 HEADING 'Total'


SELECT
    SUBSTR(TO_CHAR(first_time, 'DD/MM/RRRR HH:MI:SS'),1,10)                       DAY
  , SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'DD/MM/RR HH24:MI:SS'),10,2),'00',1,0)) H00
  , SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'DD/MM/RR HH24:MI:SS'),10,2),'01',1,0)) H01
  , SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'DD/MM/RR HH24:MI:SS'),10,2),'02',1,0)) H02
  , SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'DD/MM/RR HH24:MI:SS'),10,2),'03',1,0)) H03
  , SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'DD/MM/RR HH24:MI:SS'),10,2),'04',1,0)) H04
  , SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'DD/MM/RR HH24:MI:SS'),10,2),'05',1,0)) H05
  , SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'DD/MM/RR HH24:MI:SS'),10,2),'06',1,0)) H06
  , SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'DD/MM/RR HH24:MI:SS'),10,2),'07',1,0)) H07
  , SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'DD/MM/RR HH24:MI:SS'),10,2),'08',1,0)) H08
  , SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'DD/MM/RR HH24:MI:SS'),10,2),'09',1,0)) H09
  , SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'DD/MM/RR HH24:MI:SS'),10,2),'10',1,0)) H10
  , SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'DD/MM/RR HH24:MI:SS'),10,2),'11',1,0)) H11
  , SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'DD/MM/RR HH24:MI:SS'),10,2),'12',1,0)) H12
  , SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'DD/MM/RR HH24:MI:SS'),10,2),'13',1,0)) H13
  , SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'DD/MM/RR HH24:MI:SS'),10,2),'14',1,0)) H14
  , SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'DD/MM/RR HH24:MI:SS'),10,2),'15',1,0)) H15
  , SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'DD/MM/RR HH24:MI:SS'),10,2),'16',1,0)) H16
  , SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'DD/MM/RR HH24:MI:SS'),10,2),'17',1,0)) H17
  , SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'DD/MM/RR HH24:MI:SS'),10,2),'18',1,0)) H18
  , SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'DD/MM/RR HH24:MI:SS'),10,2),'19',1,0)) H19
  , SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'DD/MM/RR HH24:MI:SS'),10,2),'20',1,0)) H20
  , SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'DD/MM/RR HH24:MI:SS'),10,2),'21',1,0)) H21
  , SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'DD/MM/RR HH24:MI:SS'),10,2),'22',1,0)) H22
  , SUM(DECODE(SUBSTR(TO_CHAR(first_time, 'DD/MM/RR HH24:MI:SS'),10,2),'23',1,0)) H23
  , COUNT(*)                                                                      TOTAL
FROM
  v$log_history  a
GROUP BY 
	SUBSTR(TO_CHAR(first_time, 'DD/MM/RRRR HH:MI:SS'),1,10)
ORDER BY 1

Movendo arquivos dos databases de sistema – SQL Server

Neste artigo irei mostrar um método para mover os arquivos de DATA e LOG dos databases system (master, msdb, tempdb e model).

Caso você queira saber como mover os arquivos de DATA e LOG dos databases users (databases criado por usuário, a grosso modo), veja este post: Movendo Arquivos dos Databases – SQL Server

Antes de mover os arquivos de DATA e LOG dos databases system no SQL Server, é preciso entender melhor a importância de cada um:

• master: este database armazena todas as configurações à nível de sistema. Qualquer coisa que é definida no nível de instância do SQL Server normalmente é armazenada neste mesmo database. Se o database master estiver danificado ou corrompido, a instância do SQL Server não será iniciado (é importante sempre ser feito um backup deste database!).
• msdb: este database contém informações do SQL Server Agent, assim como Jobs, Operadores e alertas. Este database também contém informações sobre backups e restores feitos, assim como o histórico dos planos de execuções de manutenções, etc. Até a versão do SQL Server 2008 R2 os pacotes do SQL Server Integration Services (SSIS) também eram armazenados neste database.
• model: este database possuí um template no qual todos os usuários dos databases são baseados. Qualquer novo database que é criado usa o model como modelo. Todos os objetos criados no database model estarão presentes em todos os databases que forem criados na instância. Pode parecer que este database não é muito importante, porém caso este database esteja danificado ou corrompido, a instância do SQL Server não será iniciado.
• tempdb: este database armazena os dados temporários da instância. Toda vez que o SQL Server for iniciado, este database é truncado, portanto não há necessidade de realizar um backup deste banco de dados, tanto que não há opção para ser executado um backup deste database.

Vamos começar pelo database master. Você verá que o procedimento para alterar o caminho dos arquivos do database master é diferente dos demais, por que? Quando você inicia o serviço da instância, ele executa um executável e passa os parâmetros dos arquivos de DATA e LOG da master, pois lá que as informações pertinentes à instância se encontram. Claro que a ordem de quais databases você irá mudar não influência, porém há de se tomar MUITO cuidado com os passos a serem feitos, pois um problema que ocorrer, não será possível voltar atrás, claro, dependendo do problema.

Para mudar o caminho dos arquivos de DATA e LOG do database master é necessário realizar os seguintes passos principais:
1. Alterar os parâmetros de inicialização do serviço do SQL Server;
2. Parar o serviço (instância);
3. Mover os arquivos de LOG (mastlog.ldf) e DATA (master.mdf);
4. Iniciar o serviço (instância).

Para começar, vamos verificar onde estão os arquivos de DATA e LOG do database master através da query:

Use master 
GO
EXEC sp_helpfile 

Anote o caminho que está na coluna filename, pois iremos copiar os arquivos que estão neste caminho para um outro caminho, no caso o caminho “C:\CaminhosSQLServer\LOG” para o arquivo de LOG, e o caminho: “C:\CaminhosSQLServer\DATA” para o arquivo de DATA.

master_01

Logo em seguida abra o SQL Server Configuration Manager através do comando mmc.exe

master_02

No nó SQL Server Services, dê um duplo clique na instância do SQL Server, logo em seguida clique em Propriedades, e depois vá na aba Avançado:

master_03

Edite o Parâmetros de Inicialização alterando os parâmetros para onde você irá copiar os arquivos de DATA e LOG. Por exemplo, no meu caso está configurado da seguinte maneira:

-dC:\Program Files\Microsoft SQL Server\MSSQL10_50.ALAN\MSSQL\DATA\master.mdf;-ec:\Program Files\Microsoft SQL Server\MSSQL10_50.ALAN\MSSQL\Log\ERRORLOG;-lC:\Program Files\Microsoft SQL Server\MSSQL10_50.ALAN\MSSQL\DATA\mastlog.ldf

Onde há o parâmetro -d significa o caminho e o arquivo de DATA e o -l para LOG.
Como neste caso eu vou alterar os arquivos para os caminhos “C:\CaminhosSQLServer\LOG” e “C:\CaminhosSQLServer\DATA”, como dito anteriormente, ele deve estar configurado da seguinte maneira:

-dC:\CaminhosSQLServer\DATA\master.mdf;-ec:\Program Files\Microsoft SQL Server\MSSQL10_50.ALAN\MSSQL\Log\ERRORLOG;-lC:\CaminhosSQLServer\LOG\mastlog.ldf

* Não é permitido espaços depois dos parâmetros -d e -l e seus respectivos caminhos.

Em seguida pare o serviço da instância. Com o serviço parado (ele TÊM que estar parado), mova os arquivos de DATA e LOG atuais do database master

Neste exemplo os arquivos estão caminho “C:\Program Files\Microsoft SQL Server\MSSQL10_50.ALAN\MSSQL\DATA\”. Mova os arquivos de LOG e DATA para os respectivos caminhos configurados.

E em seguida inicie o serviço da instância. Se o serviço da instância subir, significa que a mudança do caminho dos arquivos foram feitos com sucesso!

Verifique o novo caminho dos arquivos de LOG e DATA utilizando a mesma query no início do passo-a-passo:

Use master 
GO
EXEC sp_helpfile 

Resultado:

master_04

Feito a mudança dos arquivos de LOG e DATA do database master, vamos executar o passo-a-passo dos demais databases system, no caso as databases: msdb, model e a tempdb.

Neste caso, os passos a serem realizados são mais simples, porém o cuidado deve ser o mesmo! Neste caso farei a mudança de apenas um database, no caso a msdb. Os passos a serem realizados no database msdb são os mesmos para os demais. Você pode fazer a mudança para os três de uma vez só, caso você queira. Não há problema nisso, desde que, claro, seja feito com muita cuidado e atenção.

Neste caso serão realizados 4 passos:
1. Para cada database que terão os arquivos movidos, executar o comando “ALTER DATABASE…MODIFY FILE”;
2. Parar o serviço da instância do SQL Server;
3. Mover os arquivos para os novos caminhos;
4. Iniciar a instância do SQL Server.

Vamos ao exemplo:

Assim como no primeiro passo do database master, obtenha o caminho atual dos arquivos de LOG e DATA do database msdb.

Use msdb
GO
EXEC sp_helpfile 

Guarde o caminho e o nome dos arquivos de LOG e DATA.

master_05

Agora execute o comando a seguir para mover os arquivos de LOG e DATA do database msdb.

USE master
GO
ALTER DATABASE msdb 
	MODIFY FILE 
		(NAME = MSDBData, FILENAME = 'C:\CaminhosSQLServer\DATA\MSDBData.mdf');
GO
ALTER DATABASE msdb 
	MODIFY FILE 
		(NAME = MSDBLog, FILENAME = 'C:\CaminhosSQLServer\LOG\MSDBLog.ldf');
GO

Após executar esta query, você deverá receber esta mensagem:

The file “MSDBData” has been modified in the system catalog. The new path will be used the next time the database is started.
The file “MSDBLog” has been modified in the system catalog. The new path will be used the next time the database is started.

Mova os arquivos de LOG e DATA para os respectivos caminhos conforme o comando feito acima. Agora dê um STOP-START no serviço da instância do SQL Server. Se o serviço da instância subir, significa que a mudança do caminho dos arquivos foram feitos com sucesso!

Verifique novamente o caminho dos arquivos de LOG e DATA utilizando a mesma query no início do passo-a-passo:

Use msdb 
GO
EXEC sp_helpfile 

Resultado:

master_06

É algo simples de ser feito, porém é preciso ser feito com calma e ter cuidado. Todos os passos são importantes. Caso aconteça algo de errado, você não poderá conseguir novamente a instância do SQL Server.

Em caso de erros ao realizar este passo-a-passo, deixe um comentário que eu poderei ajudá-lo da melhor maneira. Em casos de duvidas, também pode deixar um comentário que tentarei respondê-lo o quanto antes.

É isso aí!

Lendo Informações do Backup – SQL Server

Neste artigo irei mostrar alguns comandos T-SQL, que estão disponíveis do SQL Server 2005, que retornam informações úteis dos backups realizado, tais como: arquivos de data e log que estão no backup, horário de inicio e término do backup, integridade do backup realizado, etc.

Os comandos T-SQL são:

RESTORE FILELISTONLY
RESTORE LABELONLY
RESTORE HEADERONLY
RESTORE VERIFYONLY

Obs.: estes comandos apenas extraem as informações que estão no backup, isso sem a necessidade de restaura-lós.

Para saber mais detalhes de cada informação retornada nestes comandos, clique no título do comando.

RESTORE FILELISTONLY

Este comando retorna informações sobre os arquivos de dados (mdf e ndf) e log (ldf) armazenados em um dispositivo.

-- FROM DISK = Caminho\NomeDoArquivo.BAK
RESTORE FILELISTONLY FROM DISK = 'C:\Backups\ALAN_TESTE\ALAN_TESTE_FULL.bak'

Por exemplo, neste comando ele retorna algumas informações importantes como:
– LogicalName: nome lógico do arquivo no SQL Server;
– PhysicalName: caminho e nome do arquivo;
– Type: o tipo do arquivo, ex: se o Type for “D”, trata-se de um arquivo de dados.

bkp01

RESTORE LABELONLY

Este comando retorna um conjunto de resultados que contém informações sobre as mídias de backup identificadas pelo dispositivo de backup designado. É um modo mais rápido de descobrir que a mídia de backup contém. A instrução lê somente o cabeçalho da mídia, essa instrução terminará rapidamente mesmo quando estiverem sendo usados a mídia como a fita.

-- FROM DISK = Caminho\NomeDoArquivo.BAK
RESTORE LABELONLY FROM DISK = 'C:\Backups\ALAN_TESTE\ALAN_TESTE_FULL.bak'

RESTORE HEADERONLY

Este comando retorna informações sobre os backups (Backup Set) armazenados em um dispositivo. É um dos comandos mais utilizados, pois retorna todos os backups armazenados no dispositivo, seus tipos e quais databases eles pertecem, o usuário que realizou o backup, a data de inicío e fim dos backups, collation, modo de recovery, etc.

-- FROM DISK = Caminho\NomeDoArquivo.BAK
RESTORE HEADERONLY FROM DISK = 'C:\Backups\ALAN_TESTE\ALAN_TESTE_FULL.bak'

bkp02

RESTORE VERIFYONLY

Este comando verifica se o conjunto de backup está completo e se todo o backup pode ser lido. Porém, RESTORE VERIFYONLY não tenta verificar a estrutura dos dados contida nos volumes de backup. Se o backup for válido, o retorno será de sucesso.

-- FROM DISK = Caminho\NomeDoArquivo.BAK
RESTORE VERIFYONLY FROM DISK = 'C:\Backups\ALAN_TESTE\ALAN_TESTE_FULL.bak'

Caso o backup seja válido, o retorno deverá ser:

The backup set on file 1 is valid.

Essas informações são importantes para verificar o status do backup para evitar erros ao restaurar o backup, entre outras informações.
É isso aí!

Erro DTS Designer SQL Server Management Studio 2008 – SQL Server 2000 DTS Designer components are required to edit DTS packages. Install the special Web download, “SQL Server 2000 DTS Designer Components” to use this feature.

Fabrizzio A. Caputo

Ainda me surpreende em pleno ano de 2013, com o SQL Server 2012 já estável e um service pack lançado alguns lugares estarem ainda com o SQL Server 2000, não entrarei em detalhes do por que disso (Custo de mudança, licença, pessoas, hardware…Enfim!) mas de vez em quando temos de aceitar o fato com as coisas que temos de lidar. Ontem precisei fazer algumas alterações em um pacote DTS, Sim! DTS e não DTSX.

O primeiro passo a ser feito é ter o designer de pacotes DTS em sua maquina, aqui eu só tinha uma versão Enterprise do SQL Server 2008R2 tanto em relação Database Engine como em relação as ferramentas (Business Inteligence Development Studio e SQL Server Management Studio) o que faz com que o primeiro passo seja baixar tal designer. O mesmo pode ser obtido neste link: Aqui

O arquivo especifico que baixei foi o: SQLServer2005_DTS.msi de 5.0MB

View original post mais 353 palavras

Sparse Columns – SQL Server

Sparse Columns é uma funcionalidade lançada no SQL Server 2008. Esta funcionalidade está presente nas versões: 2008, 2008 R2 e 2012.

Sparse Columns são colunas que têm um armazenamento otimizado para valores nulos. Elas reduzem o espaço nas colunas que possuem uma alta porcentagem de valores nulos. Usados corretamente, pode reduzir o tamanho das tabelas drasticamente e pode aumentar significativamente o desempenho delas em consultas nestas tabelas. Lembrando que o Sparse Columns não é um datatype, mas sim um gerenciamento do SQL Server para armazenar dados nulos.

Por exemplo, se uma coluna é do tipo char(12), mesmo nulo, ela irá utilizar 12 bytes. Mas, se é utilizado o SPARSE COLUMNS neste campo, o espaço de armazenamento será quase nada. O espaço necessário para valores nulos de outros tipos de dados varia um pouco.

Alguns tipos de dados não podem ser especificados como SPARSE:

geography, geometry, image, next, text, timestamp e user-defined data types

A desvatagem do Sparse Columns em valores não nulos em uma coluna SPARSE é um pouco maior do que uma coluna que não é declara como SPARSE. A vantagem de uma coluna SPARSE depende do tipo de dados e a porcentagem de linha para o tipo de dado. Para verificar a tabela com a porcentagem e os bytes liberados para cada tipo de dado clique neste link em Estimated Space Savings by Data Type.

Exemplo prático

Vamos criar uma tabela com uma coluna sem o SPARSE, logo após inserir registros na mesma e verificar qual o espaço em disco a tabela ocupa:

GO
-- Cria a tabela sem o sparse
CREATE TABLE tbNotSparse(
	 id	int identity(1,1)
	,nome char(10) null 
)

GO
-- Loop para inserir 10000 registros
INSERT INTO tbNotSparse (nome) VALUES (null)
GO 10000

GO
-- Verifica o espaço em disco da tabela
sp_spaceused 'tbNotSparse'

Veja o campo data. A tabela possui 264KB em disco:

notSparse

Agora vamos realizar o mesmo passo anterior, porém a tabela estará com o parâmetro SPARSE em uma das colunas:

GO
-- Cria a tabela com o sparse
CREATE TABLE tbSparse(
	 id	int identity(1,1)
	,nome char(10) sparse null -- parâmetro sparse na coluna
)

GO
-- Loop para inserir 10000 registros
INSERT INTO tbSparse (nome) VALUES (null)
GO 10000

GO
-- Verifica o espaço em disco da tabela
sp_spaceused 'tbSparse'

Agora veja o resultado:

sparse

A tabela ocupa apenas 136KB em disco. Uma diferença de 136 KB.

Eis um exemplo de como Sparse Columns é um bom recurso, mas lembrando sempre que é preciso realizar uma análise criteriosa antes de utilizar este recurso.