Tag Archives: Sql Server

Posted on by

Você pode utilizar a função LEN() para recuperar o tamanho do conteúdo (da string) contido em um atributo ou variável.

Portanto, se quiser consultar todos os registros da tabela Clientes, onde o nome do cliente tenha mais de 30 caracteres, poderá utilizar esta consulta:

select *
from cliente
where len(nome) >30

Mas… e se ao invés da quantidade de caracteres você desejar conhecer o tamanho em bytes?

Para isso você utilizará a função DATALENGHT().

Exemplo: se quiser consultar todos os registros da sua tabela Livro, onde a sinopse exceda 10 KB, poderá utilizar a consulta abaixo:

select *
from livro
where datalength(sinopse) > 10240

O comando datalenght() está disponível a partir da versão 2005 do SQL Server.

Até +

Posted on by

Já ficou curioso em conhecer, ou visualizar de uma forma geral o relacionamento entre as tabelas de sistemas do SQL Server?

Se sim, recomendo que dê uma olhada no SQL Server System Map View! Este é um diagrama mantido pela Microsoft e é basicamente um diagrama MER (modelo entidade-relacionamento) dos metadados do SQL Server.

Neste link estão disponíveis os diagramas da versão 2005 e 2008 (o diagrama do 2012 ainda não está disponível) e estão nos formatos xps e pdf.

Divirta-se!

Posted on by

Quando uma nova versão do SQL Server é lançada, em geral com ela vem as novas certificações.

  • No SQL Server 2000 tinhamos o MCP e MCDBA;
  • No SQL Server 2005 e 2008 temos o MCTS e MCITP (com pequenas variações);
  • Agora no SQL Server 2012 temos o MCSA e o MCSE.

O MCSA é composto por 3 provas, e dá ao DBA certificado o título de “associado”. Quem quiser comprovar os conhecimentos mais avançados no SQL Server 2012 poderá trilhar o caminho do MCSE, onde o “E” significa “expert”. Para obter o MCSE, o MCSA é um pré-requisito. Portanto, para conseguir o MCSE temos que realizar 5 provas! (3 do MSCA + 2 do MSCE).

Atualmente o MCSE tem duas vertentes: MCSE Data Plataform (direcionada para o DBA com perfil administrador) e o MSCE Business Inteligence (para o profissional com foco em BI). Cada uma destas vertentes exige a aprovação em 2 provas. Portanto se você quiser ser um MCSE 2x, ao fim, terá realizado 7 provas! Veja que o caminho ficou mais longo e no meu ponto de vista, mais difícil (depois disso ainda existe o nível Master: MCSM, mas desta certificação falaremos em outro dia).

Não sei ao certo se estas mudanças constantes nos títulos e siglas é interessante para a identificação da certificação. Lembro que quando a Microsoft lançou o MCITP (no SQL Server 2005), por uns 2 anos a sigla MCDBA (do SQL Server 2000) ainda estava forte no mercado e quem tinha o MCITP se sentia levemente descontente, porque aquelas letrinhas, apesar de representarem uma certificação mais recente, não tinham o mesmo peso da certificação anterior na cabeça das pessoas.

Mas deixando esta questão polêmica para outro momento, considero que o novo programa de certificação do SQL Server 2012 está bem interessante e entendo que houve uma evolução. Digo isto porque agora ele força o DBA a conhecer mais sobre o produto. Nas certificações de versões anteriores, o administrador de banco de dados não precisava se preocupar em fazer a prova de T-SQL e nem se preocupar com integration services ou analys services. Agora não mais. O DBA com perfil de administrador será obrigado a fazer exames específicos, focados nestes conteúdos, para conseguir o MCSA.

Tirando todas as polêmicas por tras do assunto, considero que as certificações são sim interessantes para a carreira de um DBA. A certificação (quando levada a sério) força o profissional a conhecer (mesmo que de forma genérica) o ecossistema da tecnologia que deseja ser um especialista. Ela também mostra para o mercado que o profissional tem conhecimentos básicos, mas importantes, para administrar um banco de dados.

Conquistar uma certificação não te torna um profissional sênior da noite para o dia, mas se você evitar os atalhos, ela podera te proporcionar isso a longo prazo.

Invista sempre no seu conhecimento.

Quer saber todos os detalhes para as novas certificações, numeros do exames e etc? Clique aqui!

Bons estudos :)

Posted on by

No penúltimo post tivemos uma visão geral do PowerShell. Hoje abordaremos o assunto do ponto de vista de um DBA, portanto veremos esta ferramenta em ação no SQL Server.

Neste post você aprenderá a navegar no SQL Server utilizando o PowerShell. Isto é importante, porque você conseguirá chegar a lugares que antes só conseguia acessar via Management Studio! Então, vamos lá:

O PowerShell que vem instalado por padrão no seu Windows possui funções limitadas. Para ampliar sua gama de comandos é necessário carregar novos módulos. Para trabalharmos com o SQL Server é necessário carregar o módulo SQLPS.

  • Como carregar o módulo SQLPS?

Primeiro: no local onde o PowerShell será executado, você precisa ter o SQL Server instalado (ou ao menos o client do SQL Server), do contrário terá um erro do tipo:

“The term ‘SQLPS’ is not recognized as the name of a cmdlet…”

No servidor com estes requisitos basta digitar SQLPS no prompt do PowerShell. Se você não fizer isto e digitar um comando específico do SQL Server, terá como retorno uma mensagem de erro como esta:

O termo 'invoke-sqlcmd' não é reconhecido como nome de cmdlet, função, arquivo de script ou programa operável. Verifique a grafia do nome ou, se um caminho tiver sido incluído, veja se o caminho está correto e tente novamente.
Em linha:1 caractere:14
+ invoke-sqlcmd <<<<
    + CategoryInfo          : ObjectNotFound: (invoke-sqlcmd:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

Veja que ao carregar o módulo SQLPS o PowerShell passa a reconhecer os comandos específicos para SQL Server (e o prompt muda):

  • Navegando no SQL Server via PowerShell

Com o módulo carregado podemos utilizar o PowerShell para trabalhar com o SQL Server. As mudanças começam a se mostrar já na “navegação”.

Se você não conhece um pouco sobre o velho MS-DOS, precisa se inteirar sobre alguns comandos básicos para começar a navegar:

  • DIR – comando de listagem de pastas, similar ao LS do Linux
  • CD <nome da pasta> – comando para acessar uma pasta
  • CD.. – comando para sair de uma pasta

Com o módulo SQLPS carregado, ao executar o comando DIR tenho a relação de pelo menos 4 “pastas” * (ou 4 nós):

  • SQL
  • SQLPolicy
  • SQLRegistration
  • e DataCollection
* Vou utilizar o termo “pasta” para designar os nós, pois este termo é mais conhecido entre os utilizadores do prompt DOS.

A quantidade de “pastas” exibidas neste nível pode variar de acordo com os itens que o DBA selecionou na instalação do SQL Server. Por exemplo, se você instalar o Integration Services terá acesso a pasta SSIS. Se instalar o Analysis Services terá acesso a pasta SQLAS.

Dentro de cada uma destas “pastas virtuais” você tem acesso a informações específicas do SQL Server, suas instâncias, bases de dados, objetos e etc.

Por exemplo: se quiser informações referentes aos Jobs de sua instância, terá que navegar até o endereço descrito abaixo, na seguinte hierarquia:

SQL \ “MachineName” \ “InstanceName” \ JobServer \ Jobs

Onde MachineName é o nome de seu servidor e InstanceName é a identificação dada a sua instância SQL Server. No meu caso ficou assim:

\SQL\WIN7_64-PC\SQL12\JobServer\Jobs

Aqui, assim como no prompt do DOS, ao digitar o inicio da “pasta” e apertar a tecla TAB o PowerShell completa a sintaxe!

Se dentro de \jobs você digitar o comando DIR, verá a lista de jobs da sua instância.

Os comandos CD e DIR não são comandos nativos do PowerShell, na realidade eles são alias (ou apelidos). Para navegar até os Jobs, utilizando comandos nativos do PowerShell, também poderíamos utilizar este comando:

set-location sqlserver:\sql\win7_64-pc\sql12\jobserver\jobs

Agora que chegamos aos jobs, que tal verificarmos o status da última execução de cada um deles? Simples:

dir | select name, lastRunDate, lastRunOutcome

Assim como o CD foi substituido pelo get-content, podemos substituir o DIR por LS (pra quem veio do mundo Linux) ou utilizar o comando nativo do PowerShell: get-childItem.

Ainda falaremos mais sobre PowerShell e sobre como ele pode facilitar a vida do DBA, mas por hora é importante que você compreenda: entender a forma como a hierarquia dos objetos é organizada, fará toda a diferença quando você começar a escrever seus scripts em PowerShell.

Boa navegação!

Posted on by

Se você é um cara que iniciou a carreira em TI no início dos anos 90 (ou antes), tenho certeza que não estranhará o assunto deste post. Nestes idos, era muito comum a utilização de scripts para automatizar tarefas administrativas. No Windows (ou MS-DOS) os scripts eram escritos em arquivos com extensão .bat e alguns caras faziam coisas grandiosas com aquilo. No entanto o MS-DOS passou, as interfaces gráficas mostraram-se muito produtivas e o shell virou uma opção obscura, com uma tela preta nada convidativa.

No entanto para algumas tarefas a interface gráfica não é tão produtiva assim. Por exemplo:

Imagine que você é um DBA e que tem um parque com 70 instâncias SQL Server e precisa:

  • Saber em 1 hora qual a versão do SQL Server nestes servidores;

  • A cada manhã ser informado de quanto espaço livre resta em cada disco destes servidores;

  • Verificar se o grupo BUILTIN\Administrators faz parte da role sysadmin.

Que tal executar essas tarefas via Management Studio?! Uau, um belo serviço para aquele novo DBA ou para o estagiário.

Aí entra o PowerShell!

O PowerShell é um novo shell (não tão novo assim, sua primeira versão foi lançada em 2006) atualmente disponível para todas as versões de Windows (a partir do XP, SP2). Este shell lembra muito o velho MS-DOS mas com poderes ilimitados. Este novo recurso permite que desenvolvedores,  administradores de rede, DBAs e administradores Exchange escrevam scripts para automatizar a administração de ambientes e o deploy de aplicações.

O PowerShell tem inúmeros comandos (conhecidos como cmdlets) e com estes comandos não temos acesso somente a funções relacionadas ao sistema operacional, mas também conseguimos mergulhar no SQL Server, Exchange, Office, Internet Explorer e etc (o SQL Server tem uma fatia generosa de comandos disponíveis dentro do PowerShell).

Mas para algo tão bom, qual o percalço para o aprendizado?! Como não temos interface gráfica, a interação é via linha de comando, ou seja, você tem que aprender os comandos para conseguir realizar essa imersão (no próximo post daremos dicas de como tornar este aprendizado mais simples).

Por hora vamos abrir o PowerShell e executar alguns comandos básicos para uma primeira inteiração com a ferramenta:

Para acessar o PowerShell pela primeira vez, você poderá utilizar o recurso “localizar” do Windows, buscando por “powershell”. (aproveite e crie um atalho para facilitar o próximo acesso):

Esta é a tela inicial do PowerShell (não impressiona muito né?):

Para obter a data e hora do sistema você pode digitar o comando Get-Date e ENTER:

Para obter uma lista de serviços do Windows em execução neste momento utilizamos o Get-Service:

Aquele “where” não é estranho para nós DBAs. Veja que fizemos uma “query”, solicitando todos os serviços que estejam com status “running”.

E agora, que tal abrir o paint e depois “matar” o processo do paint (mspaint.exe)?

Abrir:

E matar:

Veja que para executarmos o “kill”, jogamos a identificação do processo dentro de uma variável.

Por hoje, ficaremos com estes exemplo bem básicos. Nas próximas semanas aprofundaremos as dicas sobre essa ferramenta sensacional que poderá te oferecer soluções milagrosas em muitos cenários!

Até +

Posted on by

tsqlOutput

Hoje a dica é sobre uma cláusula interessante disponível em comandos DML a partir do SQL Server 2005: o OUTPUT.

Sabe aquelas sentenças T-SQL que você escreve e que depois da execução nota que milhares de linhas foram afetadas e então percebe que gostaria de saber como estavam os registros antes da atualização?

Para sanar uma necessidade tão comum a tantos programadores, a partir do SQL Server 2005 foi disponibilizada a cláusula OUTPUT. A sintáxe deste novo recurso é muito simples e para recuperar o antes e depois dos dados utiliza as famosas “tabelas” DELETED e INSERTED (bem conhecidas por quem já trabalhou com triggers no SQL Server).

Veja um exemplo de como esta cláusula é utilizada no comando UPDATE (note que ela entra em ação entre as clausulas SET e WHERE):

Agora que tal um exemplo rápido para ver como a coisa funciona?

Começamos criando uma tabela e inserindo alguns dados para nosso teste:

create table testeoutput
(    id int identity,
     nome varchar(50) not null,
     dtNascto datetime not null);

insert into testeoutput (nome, dtNascto)
values    ('Silas Mendes', '19810330'),
('Frascisco Candido', '19690516'),
('Yolanda Albuquerque', '19731201'),
('Yoara Medice', '19870823');

Antes do UPDATE declaramos uma variável do tipo TABLE que irá armazenar o ANTES e DEPOIS da alteração:

declare  @historico table(
     valorAntigo varchar(100), valorNovo varchar(100) );

-- Alteramos um registro
update testeoutput
set nome = 'Silas S. Mendes'
output DELETED.nome, INSERTED.nome
into @historico
where id = 2;

-- E visualizamos os registros afetados:
select *
from @historico;

Bacana não? :)

Posted on by

SequenceIdentity

Nos últimos posts você acompanhou um pequeno dilema para lidar com o IDENTITY no SQL Server quando a sequencia automática sofre alterações manuais. Comentei em um destes posts que se utilizassemos SEQUENCES resolveríamos o problema de forma mais simples, mas precisamos lembrar que SEQUENCE só está disponível a partir do SQL Server 2012 (se algum DBA Oracle ler isto segure a piada).

Se você não acompanhou os posts sobre IDENTITY dê uma “olhada” aqui.

Basicamente a grande diferença entre implementar IDENTITY ou SEQUENCE é que só posso ter um IDENTITY por tabela; traduzindo: só temos uma sequencia possível por tabela. Com o SEQUENCE posso ter “N” sequencias possíveis.Agora para compreender melhor como o SEQUENCE ajudaria na resolução deste problema leia a transcrição do cenário abaixo:

Sua empresa possui um CRM que concentra todos os cadastros de clientes da companhia. Diversos sistemas satélites consomem procedures deste CRM para manutenção do cadastro. A companhia tem uma regra interna para diferenciar os cadastros de clientes por região, sendo assim, quando o cliente é cadastrado numa filial da região nordeste seu ID inicia com 6. Quando o cliente é cadastrado numa filial da região sudeste seu ID inicia com 3.

Veja agora um exemplo de implementação com SEQUENCE para a solução deste cenário:

-- cria base de dados
create database dbTesteSequence;

use dbTesteSequence;

-- cria tabela cliente
create table cliente (
id int not null,
nome varchar(50) not null,
sexo char(1) not null    );

Agora criamos as sequences que apoiarão a geração dos IDs:

/* cria sequence que gera IDs para clientes
da região Nordeste */
create sequence sequenceIdCliRegNordeste
as int
start with 600000
increment by 1
cache 10;

/* cria sequence que gera IDs para clientes
da região Sudeste */
create sequence sequenceIdCliRegSudeste
as int
start with 300000
increment by 1
cache 10;

Para testar vamos às inserções de clientes:

-- inserindo clientes da região Nordeste
insert cliente (id, nome, sexo)
values
(next value for dbo.sequenceIdCliRegNordeste, 'Silas Mendes', 'M'),
(next value for dbo.sequenceIdCliRegNordeste, 'Kathelin Souza', 'F'),
(next value for dbo.sequenceIdCliRegNordeste, 'Sophia Mendes', 'F');

-- inserindo clientes da região Sudeste
insert cliente (id, nome, sexo)
values
(next value for dbo.sequenceIdCliRegSudeste, 'Maria Luiza Souza', 'F'),
(next value for dbo.sequenceIdCliRegSudeste, 'Marinalva Cruz', 'F'),
(next value for dbo.sequenceIdCliRegSudeste, 'Wesley Macedo', 'M');

-- Resultado:
select *
from cliente
order by id asc

Agora reflita: como você implementaria o mesmo cenário utilizando IDENTITY?

Que venha o SQL Server 2012 :)

Posted on by

truncateXidentity

Esticando um pouco a prosa sobre IDENTITY, a dica do dia é a seguinte:

Quando precisar limpar uma tabela, excluindo todos seus registros, lembre-se:

O TRUNCATE TABLE (apesar de ser extremamente mais rápido que o DELETE) pode lhe gerar problemas caso sua tabela tenha uma coluna com o IDENTITY, isto porque sempre que “truncamos” uma tabela, o IDENTITY da mesma é reiniciado; ou seja, ao fim da operação  o retorno do comando abaixo será 1:

 select IDENT_CURRENT('suaTabela');

Se desejar retomar a sequencia anterior, utilize o comando abaixo logo após o TRUNCATE TABLE:

 DBCC CHECKIDENT (<suaTabela>, RESEED, <X*>);

* onde, X representa o ID inicial da sua sequencia

Se sua opção for o DELETE não há necessidade em se preocupar com a sequência do IDENTITY. Esta será preservada.

Até +

Posted on by

desafio_IDENTITY_2

Andressa Martins, profissional ímpar e blogueira do SQL Go, deu uma contribuição interessante quanto à nossa discussão sobre IDENTITY e agora temos uma nova pergunta para os amigos DBAs:

Tenho um campo identity em minha tabela. O incremento é de 1 em 1. O último registro da sequência é 50. Preciso fazer uma inserção fora da sequencia, então utilizo o SET IDENTITY INSERT ON e insiro um registro com o sequencial -1. Executo o SET IDENTITY INSERT OFF para habilitar novamente a sequencia automática.

Quando inserir o próximo registro na tabela, qual será o ID gerado automaticamente? 0, -2 ou 51?

(Pra saber a resposta já, pegue o script do post anterior, e na linha 20 substitua o número 800 por -1)

Valeu @Dre_Martins!

Posted on by

reposta_desafio

Se você é um DBA que já tem alguns anos de estrada e leu minha pergunta de ontem, com certeza já sabe a resposta correta (ou você já sabia, ou fez um script maroto pra saber a resposta certa). Fizemos uma enquete informal entre amigos repetindo a mesma pergunta de ontem e… a maioria devastadora respondeu 51! Muito bem. O script abaixo nos dirá se esta maioria estava certa:

Primeiro criamos uma tabela com um identity e populamos a mesma com 50 registros. Depois iremos forçar a inserção de um registro fora da sequência; utilizando para isso o SET IDENTITY_INSERT:

-- Nossa tabela de teste
create table testeIncremento
(id int identity(1,1), nome varchar(10))

-- nossa variavel de apoio
declare @i int

set @i = 0

-- inserimos 50 registros utilizando a sequencia automatica
while @i < 50
begin
insert into testeIncremento values ('silas')
set @i = @i + 1
end

-- forçamos a inserção de um registro com um ID fora da sequencia
set identity_insert testeIncremento on

insert into testeIncremento (id, nome)values (800, 'silas')

-- habilitamos novamente o incremento automatico
set identity_insert testeIncremento off

Agora, inserimos mais 50 registros (sem o SET IDENTITY_INSERT ON) e em seguida o resultado:

-- populamos a tabela com mais 50 registros
set @i = 50

while @i < 100
begin
insert into testeIncremento values ('silas')
set @i = @i + 1
end

-- o que temos?
select * from testeIncremento

Agora pare pra pensar, isso faz muito sentido, não faz?

Meu brother Thiago Alencar acompanhou essa saga na vida real comigo e acho que chegamos a mesma conclusão: é surpreendente como pequenas coisas, podem gerar problemas gigantescos!!! Valeu pela força maninho! Que tal agora um webcast pra falarmos sobre SEQUENCES e de como esta nova feature do SQL Server nos fez falta hoje!?

:)