quarta-feira, 12 de março de 2014

Importando dados de um arquivo .xlsx para SQL Server

Esse post é só pra registrar uma ajuda solicitada por um amigo meu, precisando importar uma planilha do MS-Excel 2013 para uma tabela do SQL Server 2012.

Temos um monte de opções, como é possível ver nesse link:


Mas para suportar arquivos .xlsx, temos que instalar o seguinte componente:


Notem que na página de download temos opções para ambientes 32 e 64 bits. Identifique seu sistema e escolha o mais adequado. Não é possível instalar os dois, ok?

Com isso é possível usar o SQL Server Import and Export Wizard (32 ou 64 bits), selecionar o arquivo .xlsx e seguir o assistente, que permite selecionar as colunas, os tipos de dados a serem importados, selecionar o banco de dados de destino e definir no nome da tabela de destino.

Esse link deve ajudar a usar a ferramenta:


É uma referência legal para quem não quer criar um pacote SSIS em uma importação "rápida".

quinta-feira, 12 de setembro de 2013

Dica Linux: 10 truques essenciais para administradores

Um link muito legal da IBM developersWorks, com dicas e exemplos para você reproduzir no seu ambiente.
Bem interessante e recomendo!

Lazy Linux: 10 essential tricks for admins


Agradecimentos a Vallard Benincosa, Certified Technical Sales Specialist, IBM

ATUALIZAÇÃO (12/03/2014): o link foi corrigido e agora está funcionando normalmente, podem acessar. Peço desculpas a quem não encontrou a página e agradeço a compreensão de todos.

segunda-feira, 10 de junho de 2013

Removendo Manualmente LakeSide SQL Deadlock Detector

Não sei se vocês já encontraram a ferramenta de detecção de Deadlock, da empresa SQL Solutions (http://www.sqlsolutions.com/products/sql-deadlock-detector/index.html), em algum servidor de banco de dados. Ferramenta simples, instalação fácil... o problema é pra remover!

Eles disponibilizam uma ferramenta chamada PluginUninstaller, mas que eu me lembre, só funcionou em uma ocasião, nas outras eu fiquei na mão. Você clica Uninstall e... nada!

Se a ferramenta ajuda a encontrar as consultas que estão causando os deadlocks, por que remover?
Por um simples motivo: ela usa o banco de dados de sistema msdb para criar tabelas, stored procedures, filas e serviços.
Quem instalou, percebeu um crescimento absurdo do msdb (dica para os desenvolvedores: criem um banco exclusivo para essa aplicação)!

Primeiro identificamos as filas e paramos as mesmas. Você não pode apagar diretamente pois estão vinculadas aos serviços correspondentes. Então:

  1. Paramos as filas
  2. Apagamos os serviços
  3. Apagamos as filas
  4. Apagamos stored procedures e tabelas

Serviços e Filas


Stored Procedures


Tabelas



Depois desses procedimentos, finalmente conseguimos desinstalar a ferramenta!

quinta-feira, 23 de maio de 2013

Dicas Hyper-V e Powershell: 10 cmdlets incríveis!

Mais um link de referência, para quem está envolvido no mundo da virtualização e engatinhando no domínio do Powershell:


10 Awesome Hyper-V Cmdlets


Dicas de como inicializar ou parar uma VM, saber quais VMs estão em um host, fazer backup, obter informações de rede das VMs e mais outras dicas interessantes.

segunda-feira, 22 de abril de 2013

sexta-feira, 19 de abril de 2013

SQL Server: Problema com Database Mirroring (Error 1418)

Eu estava configurando um espelhamento de um banco de dados e tomei todos os cuidados necessários:

  1. Banco com recovery model Full
  2. Restaurei o backup na instância que iria hospedar o espelhamento (Full backup + transaction log backups) e deixei o banco em recovery (WITH NORECOVERY)
  3. Como as duas máquinas estavam no mesmo domínio, apenas segui o wizard para estabelecer o espelhamento
Tudo certo e, ao final, após decidir iniciar o espelhamento (Start Mirroring), recebo a seguinte mensagem:
The server network address "TCP://servidor02.dominio.local:5022" can not be reached or does not exist. Check the network address name and that the ports for the local and remote endpoints are operational. (Microsoft SQL Server, Error: 1418)
Bom, imediatamente, chequei como estava o firewall do Windows e vi que as portas que eu estava utilizando estavam ambas liberadas nos dois servidores. E ativas! Inclusive, consegui dar um telnet nelas (telnet servidor02.dominio.local 5022). O que mais poderia ser?

A parte interessante: as duas instâncias estavam usando a conta NETWORK SERVICE para executar o serviço SQL Server, e não uma conta de domínio (ou local) exclusiva para esse fim. Como eram duas instâncias não configuradas por mim (normalmente eu crio uma conta para o serviço do SQL Server e habilito dois recursos que eu gosto muito: "Instant File Inicialization" e permitir  "Lock Pages in Memory") e não tinha janela para efetuar essa alteração, iniciei o serviço "as is".

Como resolver esse problema? Criei um login com as contas de computador do domínio e dei permissão CONNECT em ambas máquinas. Veja como ficou:

Na instância principal:
CREATE LOGIN [DOMINIO\SERVIDOR02$] FROM WINDOWS
GO
GRANT CONNECT ON endpoint::[Nome-do-Mirror-Endpoint] to [DOMINIO\SERVIDOR02$]
GO
Onde,
SERVIDOR02 é o nome do servidor onde está a instância que será o espelho;
Nome-do-Mirror-Endpoint é o nome do endpoint criado quando você configurou o espelhamento; pode ser obtido pela consulta SELECT name FROM sys.database_mirroring_endpoints.


Na instância espelho:
CREATE LOGIN [DOMINIO\SERVIDOR01$] FROM WINDOWS
GO
GRANT CONNECT ON endpoint::[Nome-do-Mirror-Endpoint] to [DOMINIO\SERVIDOR01$]
GO

Onde,
SERVIDOR01 é o nome do servidor onde está a instância principal;

Após isso, iniciei o espelhamento e tudo ficou funcionando!

sexta-feira, 12 de abril de 2013

Descobrindo o espaço usado por cada tabela no banco de dados

Para saber quanto uma tabela está usando de espaço num banco de dados, basta usar a stored procedure 'sp_spaceused' e o nome da tabela como parâmetro:


sp_spaceused tabela

name rows reserved  data index_size  unused
tabela 3650326  1415392 KB 1204728 KB  210440 KB  224 KB


Mas se eu quiser saber quanto cada tabela de um banco de dados está ocupando?
Vamos usar uma outra stored procedure, 'sp_MSforeachtable'.

É aí que entra esse script que resolve nosso problema:


CREATE TABLE #TabelaTemporaria
(
    [name] NVARCHAR(128),
    [rows] CHAR(11),
    reserved VARCHAR(18),
    data VARCHAR(18),
    index_size VARCHAR(18),
    unused VARCHAR(18)
)

insert #TabelaTemporaria exec sp_MSforeachtable 'EXEC sp_spaceused ''?'''

select [name] as Tabela, [rows] as Linhas,
cast(replace(reserved, ' KB','') as int) as Reservado,
cast(replace(data, ' KB','') as int) as Dados,
cast(replace(index_size, ' KB','') as int) as Tam_Index,
cast(replace(unused, ' KB','') as int) as NaoUsado
into #TabelaFinal
from #TabelaTemporaria

select * from #TabelaFinal order by Reservado desc

drop table #TabelaFinal
drop table #TabelaTemporaria

O resultado será parecido com esse:









Neste caso, já sabemos quem é a tabela que está alocando mais espaço dentro do banco de dados.