Posted on by

A partir do SQL Server 2012 é possivel manipular o retorno de stored procedures de uma forma elegante e funcional.

Considere a seguinte procedure:

create procedure usp_testeResultSet
as
(
select   getdate() hoje,
getdate()-1 ontem,
123456 sequencia,
'abc' alfa
)

 

Até o 2008 R2 podíamos manipular o retorno de uma procedure através de uma tabela temporária:

create table ##resultSetAntes2012
(
hoje date,
ontem date,
sequencia bigint null,
alfa nvarchar(100)
);
go
insert into ##resultSetAntes2012
execute usp_testeResultSet;

No entanto quando consideramos o mapeamento entre aplicação e banco de dados esta não é uma abordagem tão prática.

No SQL Server 2012 temos o WITH RESULT SETS que permite alterar a forma como os dados são retornados e com este comando é possivel alterar:

  • a identificação de atributos;
  • o tipo do dado (datatype) de atributos.
  • Não é possivel, porém, omitir/incluir atributos.

Como funciona?

Na prática a nova cláusula é bem intuitiva. Digamos que o desenvolvedor precise aproveitar o retorno de uma procedure já existente (neste exemplo a usp_testeResultSet) porém, necessita que os campos de datas sejam retornados com datatype DATE (ao invés de DATETIME) e que o campo alfa seja retornado no formato unicode.

Observe abaixo a diferença da chamada (e seu retorno) com o WITH RESULT SETS:

execute usp_testeResultSet

go

execute usp_testeResultSet
with result sets (
(
hoje date,
ontem date,
sequencia bigint null,
alfa nvarchar(100)
)
)

withResultSets
Conclusão

A cláusula WITH RESULT SETS pode facilitar ainda mais a vida do programador, porém, recomendo o uso com parcimonia. Lembre-se que esta cláusula altera o retorno em tempo de execução. Se a procedure for alterada (com a adição de um novo atributo, por exemplo) a chamada na aplicação que contém o WITH RESULT SETS deve ser alterada, pois do contrário a aplicação “quebrará”. Lembre-se que a nova cláusula não permite a omissão/inclusão de atributos.

Posted on by

(off-topic)

No início do ano “falei” aqui sobre gratidão e hoje aproveito o ensejo de uma data especial para ser grato.

rrusso-3Em 1997 estava cursando o 2º grau técnico em processamento de dados. Na primeira semana de aula, entra na classe um cara que notavelmente era fã de Renato Russo; o óculos, a barba e a camiseta denotavam isso claramente. Ele não era um novo aluno, mas sim o novo professor de inglês e redes de computadores: professor Sergio Noé.

O cara era marrento, mas depois de alguns dias (ou meses) gostei dele, porque além de nos ensinar o que estava na grade curricular, tinha umas piadas legais, usava umas camisetas bacanas e ensinava com foco na parte prática.

Um dia, depois de uma de suas aula de redes, ele distribuiu um texto que não era técnico. Falava sobre “escolhas”. Basicamente o texto falava sobre um cara que passou por N dificuldades (como qualquer pessoa comum), mas sempre extraia o lado positivo de suas experiências e escolhia ficar bem! Isso marcou o cara que sou hoje. Estar mal ou estar bem é uma questão de escolha. Um problema ou uma dificuldade pode ser entendido como algo ruim, mas eu prefiro olhar pra ele como um aprendizado. É um exercício, um hábito que graças ao meu amigo Noé, cultivo desde os 16 anos.

O cara lecionou para o nosso curso durante um ano e meio e sua despedida gerou comoção na turma. De fato o cara fez muita falta. Apesar da sua saída, não perdemos o contato e posteriormente estreitamos o contato profissional. O cara fez um trabalho genial na empresa onde eu trabalhava como encarregado de CPD (uau), mudando nossa rede Novell para Windows NT :)

Login na rede Novell

Login na rede Novell para Windows 95/98

Depois de 2 anos me convidou para trabalharmos juntos (e foi aí que iniciei minha carreira como DBA!). Tornamo-nos grandes amigos e descobrimos que a música era uma paixão em comum. De dia trabalhávamos com TI e a noite tocávamos um projeto musical que posteriormente mudou a cara da cidade. Montamos uma banda, gravamos CD, viajamos, tocamos em rádio e TV, brigamos, celebramos e aprendemos juntos.

No trabalho com TI ele foi meu gerente. Era um cara exigente, comprometido com a excelência e sempre trabalhando com foco no negócio. Tivemos discussões homéricas, mas a amizade nunca foi abalada. Creio que isso é uma amizade. Um amigo de verdade é o cara que te fala verdades; que te dá um tempo quando você está puto da vida, que entende suas escolhas e que não se importa com seus defeitos irritantes :)

Sergio Noé, Lucas Noé e eu no show do Roger Waters em São Paulo, 2012.

Sergio Noé, Lucas Noé e eu no show do Roger Waters em São Paulo (2012).

Obrigado professor Noé por ser “chato” e por me ensinar que é importante:

Escrever e falar bem, vestir-se bem, estudar um novo idioma, ter bom humor (mesmo em situações trágicas), ser organizado, cultivar o networking, engolir sapos com elegância… e além disso, obrigado pela paciência investida com seu camarada, sei que não fui um cara fácil :)

E pra finalizar, parabéns pelos 40 e tantos anos! Que sua saúde te leve aos cento e poucos e que você continue influenciando as pessoas positivamente por aí!

Felicidades irmão!

Posted on by

Alterar a estrutura de tabelas utilizando uma interface gráfica pode ser muito prático, pois em muitos casos uma alteração na estrutura exige que a tabela seja recriada do zero. Via Management Studio (MSMSS) esse processo é muito prático, pois a recriação da tabela é abstraída para o usuário, que tem a sensação que sua tabela foi apenas alterada (ao invés de recriada). No entanto a partir do SQL Server 2008, por padrão, esta não é uma ação permitida. A mensagem para essa situação é a seguinte:

Saving changes is not permitted. The changes you have made require the following tables to be dropped and re-created. You have either made changes to a table that can’t be re-created or enabled the option Prevent saving changes that require the table to be re-created.

Mas… isso faz sentido?

Sim!

Na prática, quando o Management Studio recria uma tabela por conta de uma alteração estrutural, ocorrem as seguintes ações (que o usuário muitas vezes nem se dá conta):

  1. Uma tabela temporária é criada com a nova estrutura;
  2. As permissões são redefinidas para a nova tabela;
  3. Os dados da tabela antiga são inseridos na tabela temporária;
  4. A tabela com a estrutura antiga é excluída (“dropada”);
  5. A tabela temporária é renomeada;
  6. As referências e índices são recriados.

Agora que você sabe o que é feito por tras, pense no efeito de “adicionar” a propriedade Identity em um campo inteiro de uma tabela com 100 milhões de registros, utilizando o MSMSS! Se o usuário não souber o que está ocorrendo por tras, terá a impressão de que o Management Studio travou, então tentará forçar o encerramento da ferramenta e… provavelmente a tabela (ou seus dados ) irão pro espaço!

Um DBA purista jamais lhe recomendará uma alteração dessas utilizando uma ferramenta gráfica, no entanto, se você optar por utilizar este meio, esteja ciente do que a ferramenta fará por você.

Para habilitar a alteração basta seguir as instruções abaixo:

No Management Studio, acesse o menu Tools > Options; expanda a guia Designers:

Desmarque a opção “Prevent saving changes that require table re-creation” e confirme em OK.

  • Quer brincar mais?

Execute o script abaixo em sua instância e posteriormente tente adicionar no campo “id” a propriedade identity, utilizando o MSSMS. Acompanhe as ações da ferramenta via SQL Profiler :) 


create login loginteste
with password='123456',
default_database=master,
default_language=us_english,
check_expiration=off,
check_policy=off;
go
create table testeRecriaViaMSSMS
(id int, texto varchar(30));
go
grant select on testeRecriaViaMSSMS to loginTeste;
go
insert into testeRecriaViaMSSMS
values (1, 'adamo tonete');
insert into testeRecriaViaMSSMS
values (2, 'andressa martins');
insert into testeRecriaViaMSSMS
values (3, 'silas mendes');
insert into testeRecriaViaMSSMS
values (4, 'thiago alencar');

Até mais!

Posted on by

Hoje um texto off-topic!

Para você profissional de TI, que as vezes se vê desolado com a profissão, chateado com os inúmeros problemas do dia-a-dia; veja como a tecnologia muda a vida das pessoas e transforma o nosso mundo. Encontrei esse texto no site do Itaú e tentei imaginar o nosso mundo de hoje sem os bancos de dados e toda a tecnologia atual.

Boa reflexão!

Viaje a um tempo em que as contas eram feitas de cabeça e as contas eram registradas a mão.

Antes da era digital, sacar dinheiro era um processo que envolvia vários funcionários.

Antes de o celular existir, lembra como era um sufoco encontrar por telefone alguém que não estivesse em casa? E mandar uma mensagem escrita para um amigo que morasse longe? Não tinha jeito, tinha que ser pelo Correio. E levava dias.

Hoje, para quem vive rodeado de tecnologias de todos os tipos – internet, tablets, smartphones –, o mundo antes da era digital parece uma realidade distante. É até difícil imaginar como processos aparentemente simples, como registrar transações bancárias, aconteciam naquela época.

No entanto, esse passado está mais perto do que a gente imagina. Foi nos anos 50 que apareceram as primeiras máquinas registradoras. Antes disso, saques, depósitos e outras operações eram anotadas a mão pelos funcionários dos bancos na ficha do cliente e em um livro enorme, com folhas de papel de seda.

Para que esses registros tivessem qualidade, o funcionário tinha que ter boa caligrafia. E isso até abria portas para novos colaboradores: “Um dia, Walther Moreira Salles me disse: ‘Jofre, você tem uma caligrafia tão boa, por que não vem trabalhar conosco?’”, conta Jofre Rafael dos Santos no livro “História do Unibanco, 1924-1994” (Instituto Moreira Salles). Já ouviu falar em “escriturário”? Pois é. O nome vem daí.

Sem calculadora ao alcance dos dedos, outra aptidão essencial para os bancários da época era serem muito bons nas contas. Qualquer erro podia prejudicar o cliente e o próprio banco. E as contas eram feitas muitas vezes de cabeça – e depois conferidas na ponta do lápis. Por isso, quando acabava o expediente, os funcionários das instituições que viriam a se tornar o Itaú Unibanco se reuniam em duplas para conferir um o trabalho do outro.

Bancário também tinha que ter pique de esportista

Mas não pense que bastava só ter cabeça boa. Os funcionários das agências do Itaú e do Unibanco tinham que ter certa vocação atlética. Era comum, por exemplo, os próprios colaboradores levarem a correspondência para o cliente em sua casa. João dos Santos, que ingressou no Itaú em São Paulo nos anos 60, conta: “A própria agência mantinha bicicletas, que os funcionários usavam como meio de locomoção”. Ou seja: a nossa paixão pelas bikes não vem de hoje.

E se um cliente pedia um crédito, havia outro procedimento. O bancário saía pela cidade a pé, conversando com pessoas no comércio e em fábricas, para conhecer o perfil do candidato. Aí nem o telefone era bom. O contato era pessoal, olho no olho. Tempos outros, que não voltam mais. E que ajudaram a construir quem somos hoje.

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

Em 2011, quando fiz o curso de internals com o Luti, da Sr Nimbus, sugerimos que ele fornecesse também outras modalidades de treinamentos avançados para DBAs, de forma que pudessemos estudar somente a noite ou quisá no horário que fosse mais conveniente.Todos nós sabemos como é emocionante a rotina de um DBA, portanto, ficar uma semana fora do trabalho é inaceitável para a maioria dos projetos.

Uns 3 meses depois os caras ofereceram o primeiro treinamento online: indexação no SQL Server. Participei e gostei muito da experiência. Foram 2 semanas conectado, somente no período entre a novela das 6 e das 8 e o conteúdo continou avançado e muito bem explanado.

Agora fiquei surpreso ao ver que os caras da Sr Nimbus ampliaram o catálogo de cursos online, mas ainda melhor: existem treinamentos sob demanda, onde você pode baixar e assistir a hora que quiser.

Acho que esta é a grande tendência. O mundo dos negócios está muito dinâmico e infelizmente não sobra  tempo para dedicarmos em treinamentos mais extensos.

Sei que parece propaganda, mas não é. É algo que recomendo pra qualquer profissional de TI: “conheça a fundo a tecnologia que está trabalhando” e neste caso, os caras da Sr Nimbus fornecem um conteúdo ímpar para nós DBAs.

Fica a dica!

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é +