Fim de suporte – Microsoft SQL Server 2005

2005end

 

Como diria uma prezada cantora contemporânea de uma riqueza musica inagualável: É hoje.

É hoje que acaba o suporte estendido do SQL Server 2005, que em outras palavras significa o fim definitivo de suporte.

Para os nostálgicos, segue um What’s New de tudo o que a versão trouxe de novidade. Sem dúvida minha favorita foi a quantidade expressiva de DMV’s.

O uso de versões não suportadas significa ausência de suporte técnico do fabricante e maior riscos de sofrer com vulnerabilidades.

Não vamos alimentar os zumbis: considere migrar o quanto antes se você possuir uma versão dessas em ambiente de produção.

Até!

Fonte:

https://support.microsoft.com/en-us/lifecycle?c2=1044

 

SQL Saturday #424 (SP) – Eu fui + relatos

IMG_20150929_132953005 (Large)

Olá,

Rolou nesse final de semana (26/09) na UNIP de Taubaté (São Paulo) mais uma edição do SQL Saturday (#424). Em resumo, trata-se de um sábado dedicado para disseminação de informação sobre o SQL Server (e relacionados) por voluntários que fazem parte da comunidade técnica (e sem medo de falar besteira, alguns dos melhores profissionais do Brasil estão entre eles) assim como uma oportunidade ímpar de networking com profissionais que estão ali trabalhando com a mesma coisa que você. E o melhor, é um evento gratuito (mesmo que os palestrantes paguem do próprio bolso todo o deslocamento pro evento).

Já é a quarta edição do evento que eu participo (sendo a segunda em São Paulo) e minha impressão pessoal é que tem melhorado cada vez mais como um todo (organização, distribuição de palestras, etc) e isso só tem sido possível graças à sempre afiada comunidade técnica e aos patrocinadores que aparentemente tem investido muito mais no evento do que a própria Microsoft.

A minha dica é: se você pode participar de uma oportunidade dessas, não pense duas vezes: é riquíssima de conhecimento e networking, então se o SAT não chegar na sua cidade, considere viajar para participar. Sugiro também que, caso a empresa não assuma as despesas da viagem por você, considere pagar do próprio bolso. Por mais que não pareça, é um experiência interessante para sua carreira e isso certamente terá retorno (não apenas financeiro, mas profissional, pessoal, etc).

 

Relatos

Enfim, vou falar um pouco sobre momentos do evento. Estou fazendo isso porque preciso voltar a escrever e essa é sim uma boa desculpa pra isso 🙂

Abertura:  Aconteceu no auditório. Começou um pouco em cima da hora e por esse motivo o responsável por abrir o evento (Diego Nogare) realizou a abertura mais depressa possível,  que durou menos de 10 minutos. Trata-se de explicações básicas sobre o evento, quem está patrocinando, como funciona a estrutura das trilhas, etc. Conversa breve e todo mundo levantou  e se direcionou para as salas.


Advanced SQL Server Execution Plans – Level 500

Fabiano Neves Amorim

Trilha: DBA (Desenvolvimento)

A palestra seria em uma sala que rapidamente transbordou de tanta gente (e olha que a sala era grande), e quando não cabia mais cadeiras na sala decidiram trocar nesse momento o local e voltamos para o auditório (onde rolou a abertura).

A palestra foi bem engraçada, com uma abertura bem zoeira do Fabiano que montou um slide só de memes e zoeiras de outros palestrantes, e depois disso  começou de verdade a apresentação: cheia de desafios de otimização e claro, soluções, e nessa apresentação especificamente, soluções que não são sempre as melhores devido à particularidades do Query Optimizer do SQL Server. Enfim, muito doido, recomendo pra quem gosta de conteúdo denso. Como o tempo estava um pouco corrido, Fabiano encerrou a apresentação mencionando que ainda tinha mais coisas pra mostrar, e aí indicou procurar no blog dele (e/ou  na página oficial do sat) .

Ah, e no final ele tirou algumas dúvidas e distribuiu algumas cópias do seu livro Complete Showplan Operators na bondade pura e acabei adquirindo uma cópia física do livro 🙂 Recomendo a leitura se o assunto plano de execução te interessa. O livro aborda de modo bem detalhado os operadores básicos e não é uma leitura pesada. Também é possível obter o .pdf gratuitamente baixando direto pelo site da RedGate.


Entendendo o Clusterlog

Marcelo Fernandes e Alex (@zedump)

Trilha: DBA Administração)

Palestra bem interessantes. Antes de explicarem o que é o Clusterlog, como é gerado e formas de analisá-lo, abordaram um pouco sobre o conceito de alta disponibilidade no geral, a regra dos 9’s e um  pouco sobre Failover Cluster.

O Alex também deu algumas dicas de como pesquisar com efetividade o clusterlog principalmente em casos de crise (onde o tempo é mais escasso), seja filtrando e interpretando o mais importante e fazendo associações com outros logs (como o log do event viewer, por exemplo).

A explicação foi bem clara e direta ao ponto. Algo que eu curti bastante e que não fazia a mínima ideia da existência disso: Backup para recuperação Bare Metal, que é um backup a nível de Sistema Operacional que possibilita a recuperação das configurações de várias estruturas do S.O, inclusive do Cluster, em casos de necessidade. O Marcelo mostrou uma demo disso no final da apresentação. É bacana, é um assunto que de fato tem pouco material na internet e no final arrancou alguns aplausos do povo porque a galera curtiu de verdade. O Marcelo aproveitou e mencionou que esse assunto está em maiores detalhes no livro recém lançado por ele e o Milton, o “ SQL Server 2014:  Alta disponibilidade na prática com AlwaysOn Failover Cluster Instances“, e de fato está (dei uma folheada e estava lá bem explicado).


SQL Server Security Hardening

Diego Miranda

Trilha: Geral 2

É um tema que curto muito e foi muito bem explicado pelo Diego Miranda. O começo da palestra foi uma explicação direta  abstraindo um pouco do que significa segurança no contexto de TI, depois aquele gráfico bem famoso de SGBDS x vulnerabilidades ao longo do tempo (tipo as do NIST) e tá ali a prova histórica de que o SQL Server não negocia o conceito de segurança: é um must e não um extra e todo o desenvolvimento do produto leva isso como parte do design.

 

Depois disso foi explicado vários pontos onde muitos ambientes possuem vulnerabilidades e as melhores práticas para corrigi-las. Citando alguns exemplos (que são extremamente comuns em qualquer ambiente e vi muita gente tossindo de leve em algumas ):

 

  • Conta do SQL Server como admin local;
  • XP_CMDSHELL
  • Porta padrão
  • Sysadmin

 

Na parte das demos, houve um tempo pra falar e mostrar sobre certificados, um pouco de TDE e também de um assunto que curto muito: CONTROL SERVER, que embora não seja um sysadmin pode “se elevar” o suficiente para se “tornar” um. Existem algumas formas de fazer isso e uma delas foi mostrada na apresentação. Não lembro se foi também a última demo, mas teve uma sobre trigger de login pra auditar acessos. Ele explorou algumas falhas que a maioria das implementações deste recurso fazem (como por exemplo, filtrar por Program Name sendo que esse parâmetro é totalmente editável pela string de conexão).

Enfim, foi uma palestra excelente e ficou claro o domínio do palestrante sobre o tema. Quem assistiu não deve ter se arrependido.


 

Vamos falar sobre TEMPDB

Ricardo Leka

Trilha: Geral 2 (DBA Dev)

Leka faz parte do grupo seleto de dois MCM’s e dessa vez o assunto foi particularidades sobre o TEMPDB, explicando a importância dessa base, porque ela é conhecida como playground dos desenvolvedores do SQL Server, arquitetura e limitações, qual a ligação da model com ela (sim) e no final comentou um pouco sobre a polêmica de quantidade de criação de arquivos de TEMPDB. Ficou evidente de que havia muito conteúdo nessa apresentação que ficou de fora por falta de tempo e o palestrante prometeu disponibilizar  material depois (e pessoalmente, estou curioso pra conferir esse material 🙂 ).


 

DataZen – Do Início ao Fim

Arthur Luz

Trilha: Geral 1

DataZen é uma ferramenta de BI relativamente nova no mercado e que foi comprada pela Microsoft. Atualmente não trabalho com BI e fiquei curioso pois não sabia nada da ferramenta, e o Arthur fez um ótimo trabalho explicando de forma facilitada do que se trata a ferramenta e explicou passo a passo sobre o processo de instalação.

O que me surpreendeu de verdade nessa palestra foi a tranquilidade e o domínio do palestrante sobre o tema, o que fez com que ele conseguisse passar tudo (e não era pouca coisa) o que ele realmente propôs na pauta e com certa tranquilidade (mesmo com menos tempo por que a sala estava ocupada). Achei um excelente ponto de partida para conhecer mais da ferramenta. A principal vantagem aqui é que o Arthur está constantemente blogando (e blogando bastante, olouco) sobre a ferramenta que agora é uma frente de trabalho dele, então se você se interessar pelo tema certamente vai querer conferir direto no blog dele, que você pode acessar aqui.


Hekaton v.2 e ColumnsTore Index v.3 – Nova Geração de Banco de Dados

Luan Moreno Medeiros Maciel

Trilha: DEV 1

O Luan é bastante conhecido na comunidade por ter praticamente adotado dois assuntos que são “eternas novidades” no SQL Server: o Hekaton (hoje conhecido por In-Memory OLTP) e Columnstore. Essa palestra foi bacana porque ele conseguiu falar as novidades sobre o Columnstore, depois sobre o Hekaton, depois sobre o Columnstore no Hekaton. Bem interessante ver que as features evoluíram muito desde a versão de inauguração: Hekaton não restringe tanto quanto antigamente como na primeira versão e agora o Columnstore possui algumas vantagens que na minha opinião deveriam ser essenciais desde a primeira versão (uma delas bastante importante é que ele é atualizável agora).

Se você se interessa sobre o assunto, basta procurar o blog do Luan e você verá um avalanche de post sobre o assunto.

 


 

Encerramento do evento + Material

 

E fomos para o auditório para as palavras finais, os agradecimentos, e como de costume, sorteio de vários brindes. É extremamente importante ressaltar que todo o conteúdo do SAT é disponibilizada na web, seja no blog dos palestrantes, seja na página oficial da edição do SAT correspondende. Então, minha recomendação é: se você tiver interesse e quiser um ponto de partida, clique aqui.


Conclusão + chamada pro próximo SQL Saturday (#469)

No final ficou aquele sentimento (pelo menos pra mim) de que precisamos estudar mais (sempre, ehuhea) e que valeu a pena estar ali, e já pensando sobre os próximos SATS. O próximo é aqui em Brasília que ocorrerá no dia 21 de Novembro. Se inscreva clicando aqui. Bora? Não deixe de fazer sua inscrição visitando esse link. Como já disse no início, vale muito a pena!

[]’s

 

É possível estimar ganho de compressão de backup?

A imagem é um trocadilho

Olá,

É possível determinar o tamanho de uma backup comprimido com WITH COMPRESSION?

Observação: Recomendo a leitura do  post sobre backup compression aqui do blog além da documentação oficial, para melhor aproveitamento do assunto deste post.

 

Essa é a resposta do BOL que você pode conferir aqui:

For compressed backups, the size of the final backup file depends on how compressible the data is, and this is unknown before the backup operation finishes

Quando este questionamento foi feito a mim, o banco de dados  em questão nunca teve backup, não tinha valor algum no MSDB.DBO.BACKUPSET pra sequer dar uma ideia de qual seria o tamanho do .bak e além disso espaço em disco, nesta situação em específico, também era um problema. E ganho de compressão é aquela coisa: cada caso é um caso, não tem números mágicos pra multiplicar ou dividir e chegar nesta resposta. Quando qualquer backup com compressão já foi realizado, é possível obter o que é chamado de “Compression Rate”, dividindo o tamanho da base pelo tamanho da base comprimida. O Compression rate ajuda pra ter uma boa ideia de quanto será comprimido.  A fórmula básica é:

Mas bem, se não dá pra estimar qual será o tamanho do backup comprimido se nenhum backup foi realizado, daria certo criar um  um  backup “fake” pra obter informações na backupset? Entenda-se por backup “fake” no contexto deste post aquele backup que é realizado normalmente, logado no msdb mas nada é gravado e persistido em disco. Trata-se do backup enviado para o NUL device, assunto já comentando e que você pode conferir  neste post.

IT’S DEMO TIME!

Tudo foi testado em uma instância 2008 R2, embora possa ser testado em qualquer versão 2008+ que possua a feature de compressão de backup.

Tenho uma base chamada DB_BESTIARIO que possui 484.37 MB.

sp_helpdb na base

Trata-se de um repositório e que no momento do teste estava sem atividade alguma, o que é perfeito para este exemplo diga-se de passagem. Esse banco de dados não tem nenhum backup realizado (Veja o resultset vazio).

Não retorna nenhum resultado

Não retorna nenhum resultado

Agora, vamos tirar um backup FULL normal, sem compressão e conferir o que foi logado na backupset:

comp3

Nada demais. O tamanho do campo compressed backup size é exatamente o mesmo do backup_Size se não for utilizado compressão. Apenas com esta informação, não consigo estimar o tamanho do backup comprimido.

Então, vamos tirar um backup apontando pro NUL:

Comp4

Note que o tamanho do backup feito pra NUL é o mesmo do backup realizado fisicamente em disco. Estes tamanhos conferem com a realidade do primeiro backup tirado?

comp5

.. 151.636 KB equivale à 148MB. Agora, vamos tirar um backup COM compressão e conferir qual tamanho o SQL Server loga no backupset:

comp6

Aqui está a observação principal do teste. Fazendo um backup “fake”, dá pra estimar que o backup comprimido é três vezes menor que o tamanho do backup sem compressão. Mas nem por isso existe a certeza de que o ganho do comprimido x original será sempre 3x menor pra todo backup daquela base, embora isso seja favorável para praticamente todos os cenários. Através deste teste, é possível estimar o tamanho do backup sem efetivamente gerar algum arquivo de saída.

Só pra fechar o teste, vamos tirar um backup comprimido para o disco (ou seja, vai gerar arquivo persistido em disco) pra ver se vai dar esses 45.97MB de fato. Só pra validar se não foi viagem confiar no tamanho que o backup pro NUL mostrou.

comp7

 

 

Mais uma prova cabal do backup comprimido em disco:

comp8

IMPORTANTE (!)

– O backup é “fake” mas o processo de leitura em disco é real, ou seja, há processamento e leitura durante a criação do backup. A única coisa que muda é o destino do arquivo. Não existe essa do backup ser fictício e não consumir recursos do servidor (no caso, disco, memória e CPU).
– Use com cautela e saiba em quais situações aplicar. Por exemplo, se a base em questão tiver backups diferenciais, se você fizer um backup full desta forma sem COPY_ONLY, haverá uma modificação no DCM (Differential Change Mapping) e aquele backup será necessário se for necessário restaurar aquele diferencial que vem em seguida. No exemplo não usei COPY_ONLY pois se trata de uma base de testes. Se for para backup de log, a coisa é um pouco mais séria: mandar um backup de log quebra cadeia de backup de log, e nunca queira contar com um backup que não existe, é a pior coisa que tem quando o assunto é recovery.

RESUMO

Não é possível afirmar com precisão qual será o tamanho do backup com compressão a não ser que você tire um. Então a resposta para a pergunta “É possível estimar o tamanho de um backup comprimido” continua a mesma do BOL (Não, só tendo algum backup . O que apresento aqui é uma forma alternativa de obter essa informação.  Como Backup to NUL não é salvo em disco. Significa na prática que você pode estimar espaço de um backup daquela base de 2TB sem ter problemas com espaço em disco por causa do arquivo de backup. Foi o que usei para resolver essa questão, especificamente.

Obrigado pela sua leitura, e…I’ll be back!


Referências

Backup Compression – https://technet.microsoft.com/en-US/library/bb964719.aspx

Script – Coleta de Waits por Snapshot.

Olá,

Postando aqui um script de uso pessoal, segue um exemplo de coleta de waitstats baseada em snapshot: ideia antiga porém efetiva: realiza a coleta das esperas de determinado servidor em momento A e momento B e retorna a diferença.

A ideia é que, pelo fato da DMV ser cumulativa, uma consulta direta não responde muita coisa além de dar uma ideia geral (e bem abstrata) de quais waits possuem maior número de ocorrências. O problema é que estes dados isolados são difíceis de interpretar.

Já com snapshots, é possível verificar a contagem das esperas por intervalo de tempo de modo e isso auxilia demais análises de troubleshooting (muito mais efetivo se isso é feito no início de qualquer análise), sendo a diferença um número mais factível tendo algum contexto temporal.

Esperas são eventos normais e a maioria delas podem ser ignoradas em análises de troubleshooting e elas estão retratadas nos filtros via NOT IN.

O script abaixo pede apenas um parâmetro em segundos e processa as coletas.

[]’s

Referências
MSDN – sys.dm_os_wait_stats
Script Paul Randal: Script Paul Randal:

Controlando o crescimento do ERRORLOG

Finge que é o errorlog =p

Olá,

Recentemente comecei uma pequena série sobre ERRORLOG composta de três partes. Antes de prosseguir com o post de hoje que é um extra ao assunto, apresento os posts da série caso tenha interesse:

Sendo direto ao ponto: Ter um ERRORLOG grande não é algo comumente desejado, por vários motivos:

  • Demora ao abrir o arquivo: É frustante abrir arquivos grandes principalmente quando queremos uma resposta rápida e experimentamos lentidão.
  • Dificulta manipulação do arquivo: Para esta finalidade, queremos arquivos de fácil manipulação e o tamanho é um dos fatores cruciais pra essa condição.
  • Evita estouro em disco: Em geral não é algo a se preocupar, pois depende do ambiente. Mas imagine que você não precise manter o errorlog no C:  com pouco espaço e as bases de sistema também estão neste disco. Caso mudar o local não seja possível  (cenários e cenários…) você precisa se certificar que um arquivo de errorlog não seja o responsável pela parada de uma instância inteira comprometendo o disco e prejudicando por exemplo, o tempdb.

Dito isso, tenho a opinião de que é interessante controlar o crescimento dos logs aqui citados. Existe uma solução pouco conhecida (e citada aqui pelo Paul Randal) que automaticamente dispara um recycle quando determinado threshold é alcançado mas funciona apenas no SQL Server 2012 ou superior (build à consultar…)  realizando algumas alterações no registro.

É possível confeccionar uma solução destas no SQL Serer 2008 R2? Sim, e vai de cada cenário e necessidade… Sugiro aqui uma solução não-reativa: um script que pode (idealmente) ser agendado via SQL Server Agent e rodado diariamente, podendo fazer o recycle ou não sob determinadas condições. Destaco que a solução abaixo atende bem um cenário X mas não necessariamente Z ou Y, já que existem N formas de endereçar uma solução para o assunto.

Você implementa(ou) alguma solução parecida no seu ambiente ou outra bem diferente? Alguma opinião sobre o assunto? Sinta-se à vontade para postar.


Semana que vem fecho a série de ERRORLOG e prometo mais posts voltados para infra, mas de uma forma um pouco diferente, fugindo do convencional.

[]’s

Copiar resultado do SSMS no Excel sem quebra

Já copiou o resultado de determinada consulta no SSMS (SQL Server Management Studio), colou em uma planilha do Excel e se surpreendeu com a bagunça?
O que era pra ser uma solução rápida e prática acabou virando uma zona?

Eis o cenário:

Consulta exemplo

Gerando um resultset pra teste

Pense na cópia mal sucedida

Copiando o resultset no Management Studio e copiando no Excel. Olha a bagunça!

O intuito deste post é explicar o que causa o problema e como resolver.

Problema

O problema acontece quando o resultado copiado possui caracteres como quebra de linha, tab, etc. Estes caracteres são interpretados no Excel, se copiados diretamente, como comandos e acabam por desconfigurar no momento de colar.
Vamos simular o problema:

1) Criando uma massa pra testes. Existe um propósito em manter os textos no INSERT com espaço. Deixe-os desta forma caso use o código abaixo.

2) Consultando a tabela recém-criada, gerando um resultset com caracteres de controle:

Gerando um resultset problemático de novo

Mesmo caso do exemplo que abriu o post.

3)  Copie o resultset (de preferência com o cabeçalho, botão direito no resultado da consulta, opção “Copy with Headers“, e cole no Excel:

Formatação quebrada

Olha a bagunça!

 Solução

Alguns usuários do SQL Server já abriram chamado na Microsoft para relatar o problema, que aparentemente não possui soluções definitivas, mas existe um workaround (aqui no Brasil usa-se o termo solução de contorno, alguns dizem gambiarra, etc).

Sabendo que o problema acontece quando o resultset possui caracteres como quebra de linha, tab, dentre outros (conhecidos como caracteres de controle), que são interpretados como comandos no Excel, podemos converter esses caracteres em espaço, podendo assim sacrificar a formatação original do campo em prol da realização da tarefa.

Na tabela ASCII, vamos identificar quais caracteres devem ser primariamente localizados:

Codes

Abaixo, segue dentro dos parênteses os códigos ASCII do que pretendemos remover:

  • CHAR(9) = Tab
  • CHAR(10) = Line Feed (LF)
  • CHAR(13) = Carriage Return (CR)

Tab é tab é dispensa explicações. Já Carriage Return e Line Feed são dois caracteres de controle que com frequência caminham de mãos dadas quando uma quebra de linha acontece. Em outras palavras, um ENTER, por exemplo, faz a quebra utilizando estes dois caracteres.

Pra facilitar o entendimento:

NaPratica

Podemos usar os códigos destes caracteres de controle dentro da função REPLACE e substituí-los por espaço, de modo que nossa cópia não fique desconfigurada. Note que você pode fazer o mesmo sem passar espaço, pode passar entre aspas vazias também.

Agora, vamos colar o resultado sem quebrar o resultset:

Gerando agora um resultset com o workaround

Gerando agora um resultset com o workaround

Copiando e colando no excel:

Agora foi!

Cópia bem sucedida.

O workaround, assim como mais informações a respeito do problema, foram postados nos dois links abaixo no connect:

https://connect.microsoft.com/SQLServer/feedback/details/788463/copy-and-paste-from-sql-2012-to-excel-breaks-rows-if-an-address-is-included

Conclusão

A solução apresentada permite a cópia sem maiores problemas sacrificando a formatação original de textos que possuem caracteres de controle. Caso seja realmente necessário manter a formatação, é possível realizar a importação de dados para o Excel de forma direta utilizando outros métodos, que não estão descritos neste post.

[]’s

Referências

  1. CHAR Function – http://msdn.microsoft.com/pt-br/library/ms187323.aspx
  2. REPLACE Function  – http://msdn.microsoft.com/pt-br/library/ms186862.aspx
  3. Carriage Return (CR)- http://pt.wikipedia.org/wiki/Carriage_return
  4. Line Feed (LF) – http://en.wikipedia.org/wiki/Newline
  5. Tabela ASCII – http://www.theasciicode.com.ar/ascii-control-characters/horizontal-tab-ascii-code-9.html

 

ERRORLOG – O básico (Parte 1 de 3)

Errorlog01

Olá,

Estava planejando tem um tempão falar  sobre os recursos que o SQL Server oferece de graça para os usuários do produto (supondo que estejam utilizando a versão Enterprise e/ou que tenham permissão suficiente, é claro) e inevitavelmente me veio a forma mais básica de logging do SQL Server: ERRORLOG. Esse post é o primeiro de uma trilogia, onde vamos comentar o básico e o que realmente precisa ser entendido sobre o funcionamento do mesmo.

Impressões sobre o exame 70-465 – Design database solutions for SQL Server 2012

Imagem totalmente random para representar o post

Olá,

Gostei bastante da prova e cá estou aqui pra compartilhar alguns pontos sobre a mesma..

Coisas legais

  • Casos de estudo: Questões baseadas em casos de estudos são bem interessantes pois como você recebe um cenário as questões são melhor contextualizadas, diminuindo questões de dupla interpretação e calando um pouco nosso amigo “depende”. Melhor ainda quando alguns cenários já foram, em outros momentos, presenciados, seja na vida real ou lidos via blogs e livros, e isso ajuda (me ajudou) bastante na hora de diagnosticar o problema da questão.
  • Features: A prova cobra de modo pesado conhecimento em praticamente todas as ferramentas do produto. Você não precisa dominar cada uma: é suficiente saber apenas o que cada uma faz e o que não faz e isso será cobrado em várias questões (bem mais de 15, no meu sorteio). Algumas questões vem praticamente de graça (por exemplo, quando a questão pede “a melhor opção para criação de políticas” e marcar PBM é quase que automático, e esse tipo de situação ocorreu em diversas questões). O que eu lembro que cai na prova: audit, agent alert, policy based management, resource governor, activity monitor, maintenance plain (…), Profiler, Xtended Events, DTC…
  • Melhor escolha: Essas questões são bem legais, porque geralmente apresentam uma cilada com duas ou mais respostas certas. Por exemplo, se você precisar listar as 10 maiores ocorrências de WAITS da sua instância, você usaria uma DMV ou um DBCC? Pro primeiro, você ordenaria e limitava o resultado. No segundo, você precisaria jogar em uma tabela, variável, etc pra depois fazer o mesmo que você faria no primeiro caso. Por isso, geralmente eu digo e repito: se você tiver 10 opções e dentre elas tiver alguma DMV, considere-a com carinho.
  • Alta Disponibilidade VS Disaster Recovery: Muitas questões muito bem orquestradas no sentido de separar uma coisa da outra e outras muito bem feitas. Saber os tipos de backup e qual o papel de cada um em um disaster recovery é muito importante. Sabendo o que cada um faz, e o TEMPO relativo que cada um demora, algumas questões são praticamente de graça. Backup de log é coisa de bonita de  Deus sempre, mas nem sempre é a melhor opção em uma operação de risco (previamente agendada) onde alguma cagada acontece e a recuperação precisa ser rápida. Talvez um Database Snapshot cairia melhor neste cenário de DR, por exemplo…
  • Indexação: Cai bastante coisa atrelado com os estudos de caso. Não são questões fáceis então recomendo dar uma lida antes sobre o assunto.

Coisas que eu não gostei

  • Mais questão de Mirroring, menos de Always-On. A funcionalidade de Mirroring será descontinuada pela MS nas futuras versões, então, esperava que os exames também fizessem isso, de alguma forma.
  • Algo já pontuado pelo Luti, é sobre as questões que possuem mais de uma resposta correta mas não possuem limites (por exemplo, cinco opções, e você pode marcar todas, ou uma). Se tiverem 4 corretas, e eu marcar 3, perco a questão inteira ou ganho proporcional ao valor da questão? Seria legal a Microsoft indicar isso nas questões ou nas instruções do exame, pra dissipar incerteza que no meu caso me fez gastar um tempo extra nessas questões.

Próximo passo (pessoal)

Exame 70-464! Destinei um tempo maior de revisão pra essa prova, já desenvolvimento não é minha praia e confesso que não tenho boa experiência com esse segmento (depois da 70-433) além de não ser atualmente minha atuação. Espero ter êxito nessa prova e compartilhar algumas dicas sobre ela também.

Referências

Recomendo fortemente a leitura dos posts abaixo (em ordem):

  • Luti – http://luticm.blogspot.com.br/2012/04/impressoes-da-prova-70-465.html
  • Alex Rosa – http://alexrosadba.wordpress.com/2012/11/01/70-465-designing-database-solutions-for-sql-server-2012-pass/

Considero as leituras acima bastante importantes caso você vá realizar o exame.

 

Bons estudos!

[]’s

Descubra a conta de Serviço do SQL Server

Registro

Olá,

Post dica rápida (e bem útil dessa vez, garanto) sobre como localizar a conta do SQL Server, direto no SQL Server.

Ás vezes existe a necessidade de se conferir qual é a conta de serviço, seja para simples conferência ou uso em scripts dinâmicos, por exemplo. Existem N formas de você fazer isso. Algumas delas:

1) Services: WinKey + R > Digite no executar services.msc > Procure o serviço do SQL Server > Botão direito > Aba Login, A conta está lá.

2) SQL Server Configuration Manager: SQL Services > Ver qual conta está no “Log as IN”. Basicamente, esse método é uma interface do primeiro.

3) Via bruxaria: (xp_cmdshell, xp_* e derivados). Exemplo:

Se você tiver o prazer de usar no mínimo o 2008R2, você pode usar as DMV’s abaixo.

4 – Modo DMV Lifestyle (SQL Server 2008R2 ou superior) – Motivo do título do post. 

Resumindo:Detalhes da Query

Se você tiver, dentre várias opções, alguma DMV, dê preferência, principalmente se precisar desta informação para realizar consultas.

Referências:

Conheça o Logical Backup Device

Logical Device

Olá,

O assunto de hoje é Logical Backup Device. Para maiores informações sobre o termo “Device” (Dispositivo) de backup no SQL Server ou sobre o termo que intitula o post, dê uma olhada nas referências.

Logical Backup Device (Dispositivo Lógico de Backup), que ao longo do post vou chamar de LBD, nada mais é do que um alias (ou abstração, para os mais teóricos) de um dispositivo físico (pode ser uma fita ou disco, geralmente este último). Significa que podemos referenciar um local físico passando apenas o nome do dispositivo lógico como destino.

Como seria um backup referenciando um LBD?

Observações:

– O nome do seu Logical Backup Device deve ser único (óbvio, lol)
– View de sistema: sys.backup_devices (consulte aqui todos os LBD’s criados)
– Pra criar um logical device, é necessário pertencer à role diskadmin (ou sysadmin).

Como criar

Aquela beleza de poder escolher N formas para cumprir  determinado objetivo.

Duas formas de criar o LBD (o modo hardcore, aka Powershell, não será abordado aqui);

a – Usando a GUI do Management Studio (Modo fácil);

Criando um LBD visualmente

Vale lembrar que o arquivo informado em File não é criado em tempo de execução. Você precisa criá-lo (lembre-se: é um arquivo binário).

b – Usando T-SQL (Modo normal)

Com as permissões necessárias, basta utilizar a procedure sp_addumpdevice.

O nome não é intuitivo e pode causar um certo estranhamento, pois antigamente, o termo dump era bastante utilizado em alguns cenários de tecnologias (e ainda é, no MySQL) por ser sinônimo de backup e agora nem tanto (sp_addbackupdevice seria muito mais amigável não só de nome como também combinaria com a view e tal…)

Confira as sintaxes úteis, que são a criação, a deleção e a consulta de informações em view de sistema relacionadas aos LBDs :

Modo TSQL

– name: Nome do seu dispositivo. É o nome que vai ser apontado no destino de backup;

– type: Tape = 1 e Disk = 2

– type_desc = descrição dos tipos acima

– physical_name = O caminho FÍSICO do dispositivo

Vale lembrar (de novo) que o arquivo informado em File não é criado em tempo de execução. Você precisa criá-lo (lembre-se: é um arquivo binário).

Mas qual a utilidade disto?

O fato de  se ter uma abstração física te dá a vantagem de alterar o caminho de um dispositivo em determinado ponto (na configuração do próprio lbd), e não em scripts que o referenciem. Vamos supor que você tenha um job de backup, de uma base em específica. Se o script contiver apenas o nome do LBD e não um caminho de disco local ou SAN, se você precisar alterar o caminho físico, basta alterar o LBD.

E como usar um LBD? Mais fácil enxergar na prática:

BKP E RST

Apenas um exemplo (tirado da vida real)

Uma aplicação X frequentemente fazia backup e restore da sua base e utilizava esse recurso do LBD. O fornecedor optou por utilizar apenas um arquivo pra fazer esse processo todo de backup e restore continuamente, sempre sobrescrevendo o mesmo em cada execução. A definição do (mais adequado possível) caminho físico fica por responsabilidade do DBA.

Também é interessante utilizar esse método onde você desenvolva algum script que precise de uma localização física para realização de backup e restore e você não pode garantir um caminho definitivo (seja de rede ou local). Adivinha qual a solução? LBD é uma boa. Já vi também implementações  de LBD para estratégias de backup bem excepcionais (Backup dividido). Ou seja, é uma solução que não atende um cenário apenas, embora não sejam cenários comuns.

Qual a vantagem disto?

O comando de Backup e Restore recebem um alias, uma abstração de um caminho físico. Logo, por exemplo, se meu caminho real tiver no disco D, e eu precisar retirar esse disco, posso mapear o LBD para algum outro local, por exemplo disco E, sem prejuízo para a aplicação. Também é útil em manobras emergenciais.

Por exemplo, manobras que envolvam diferentes discos (o que inclui troca de caminhos físicos com frequência) e/ou que sofram de falta de espaço podem fazer bom uso dessa abstração.

É útil para rotinas de backup convencionais? Não considero e não recomendo de jeito nenhum. O nível de organização que se tem em realizar um backup de banco por arquivo, o que inclui também convenção de nome bem definida (20140226_AdventureWorks_Full.bak por exemplo) é muito mais interessante  para uma rotina diária do que manter mais de um backup por arquivo (e isso pode pesar MUITO quando você precisar usar um device que tenha mais de uma base, e pior, bases diferentes).

Observação importante 

Uma recomendação da própria MS e que atualmente é uma boa prática (por razões óbvias): não deixe seus backups no mesmo array de disco que seus arquivos de dados e de log (note que eu disse array de disco e não discos e isso vale também para LBDs, pois, você pode ter duas letras/discos diferentes (D: e E: por exemplo) porém são partições/discos do mesmo disco/array. Quando se pensa em desastres, pense na pior hipótese sempre, algo como: o array todo pode falhar, e se seus arquivos de backup estiverem lá, você aprenderá da pior forma possível que backup no mesmo local físico onde seus dados estão não é backup. Isso é um ponto que irei sempre voltar ao longo das postagens.

 

Qualquer dúvida ou comentário adicional, fique à vontade para comentar.

 

Referências

Backup Devices: http://technet.microsoft.com/en-us/library/ms179313.aspx

Logical Backup Device  : http://technet.microsoft.com/en-us/library/ms189109.aspx