Results for tag "powershell"

5 Articles

Conhecendo o Processo do SQL Server no Windows e Linux – Parte 3

Post 3/3. Este post é parte da série: Conhecendo o Processo do SQL Server

Olá! Este é mais um post da série de post sobre o processo do SQL Server no Windows e Linux.

Nas duas primeiras partes, mostramos alguns conceitos importantes, como por exemplo, o que é um processo e o que é um thread. Você também aprendeu algumas ferramentas muito úteis para monitorar e obter mais informações de processos no Windows. Ainda, mostramos como podemos aplicar todos esses conceitos para obter informações úteis sobre uma instância SQL Server, como o usuário que está executando, privilégios, etc.

Hoje vamos focar tudo o que vimos e aprendemos, no Linux. O SQL Server no Linux é mais que uma realidade, então, nada mais justo do que aprender todos estes conceitos e ferramentas, também neste ambiente. O post assume que o leitor já possui uma experiência básica com Linux, conseguindo abrir um terminal ou uma sessão ssh, e digitar comandos. Se você não possui esta experiência, mas possui alguma experiência com powershell, você não terá dificuldades em compreender os exemplos.

O “Gerenciador de Tarefas”

A esta altura, você já percebeu o  Gerenciador de Tarefas do Windows é, na verdade, um “Gerenciador de Processos”. Ele te dá uma lista contendo cada processo que existe no Windows com diversas informações sobre cada um deles. Há o “process explorer” e o “Get-Process”, do powershell, também. No Linux, assim como no Windows, possuímos diversas ferramentas que nos fornecem as mesmas informações, umas com mais detalhes, outras com menos.

Por exemplo, você pode usar o comando “ps” para encontrar a linha de comando usada para iniciar o SQL Server:

Note que há dois processos. São duas instâncias? Não. No Linux, o sql server inicia um processo conhecido como “watchdog”,e este por sua vez é quem inicia um segundo processo que irá atuar como uma instância SQL como a conhecemos. Como pode notar, ambos usam o mesmo executável.  O primeiro processo fica monitorando o segundo, e em caso de falhas, irá gerar os dumps para análise. No Windows, é um recurso nativo do sistema operacional quem faz esse trabalho. Este artigo do Bob Dorr, detalha.

Você pode usar o seguinte comando para exibir o PID do processo, o usuário e a linha de comando usada:

Um exemplo:

No exemplo acima, o processo 25526 foi iniciado pelo processo 1 (PPID  = parent pid, ou, pid pai). O processo 1 (init) é semelhante ao processo System e wininit.exe do Windows, que são os responsáveis por iniciar os serviços. Então, podemos dizer que o processo 25526  é o “watchdog”, pois ele foi o primeiro processo com o executável do SQL Sever a ser iniciado. A linha seguinte, demonstra que o respectivo processo, de PID 25531, é filho de 25526 (o  watchdog), então, este é a instância SQL (é este processo, por exemplo, quem escuta na porta 1433, e processa os comandos SQL que chegam).

O comando “htop” pode ser uma alternativa interessante ao comando “ps”. Usando a tecla F5, você consegue trocar a exibição entre uma árvore de processos e uma lista ordenada:

Aqui, a coluna “PID” é auto explicativa. Ela contém o PID do processo, conceito que você já aprendeu no post anterior. É a mesma coisa. A coluna “User” informa qual o usuário sob o qual o processo está executando. A mesma informação está disponível tanto no Gerenciador de Tarefas e no Process Explorer. No powershell é necessário um script mais elaborado para obtê-la.

No Windows, você consegue ver essa relação de processo pai e processo filho melhor com o Process Explorer. Aqui está um exemplo no Windows:

Note que no Windows, não temos um outro processo pai chamado sqlservr.exe. O sqlservr.exe é filho de “services.exe”, pois eu o iniciei através de um serviço do Windows. Entretanto, ao executar um xp_cmdshell ‘ping www.microsoft.com’, podemos ver claramente processos filhos do SQL Server sendo criados. O Process Explorer demonstra que cmd.exe é filho de sqlservr.exe. E PING.EXE é filho de cmd.exe

 

Onde estão os argumentos? No caso do SQL Server no Linux, todos os parâmetros default vem do registro (na verdade, uma implementação parecida, para o Linux):

Assim, como no Windows, ainda é possível usar os parâmetros em linha de comando:

A primeira linha é o comando sudo. Da maneira em que foi executado na imagem, ele faz com que mudemos o usuário atual. O nome do usuário é “mssql”, criado por padrão na instalação do SQL. Na próxima linha, eu apenas inicio o executável do SQL Server, com o parâmetro “-e”, alterando o local do Error Log, semelhante como fizemos no Windows. A razão pelo qual eu mudei de usuário é apenas para evitar problemas de permissão quando eu iniciar o serviço normalmente usando o gerenciador de serviço (systemctl). Eu recomendo que não faça isso, principalmente em ambiente de produção, pois pode vir a ter seu serviço inoperável. Mas, se o fizer, e tiver problemas, tente restabelecer as permissões, desta maneira:

Aqui está o processo, usando o comando “ps”, como mostrado anteriormente:

Note que o processo é filho do processo 23892. Utilizando o comando ps, podemos observar quem é:

bash é um programa que atua como um shell no Linux, semalhante ao que o cmd, ou mesmo o powershell, é no Windows. Ele é responsável por captar e exibir a saída de comandos fornecidos no terminal. Quando eu iniciei o SQL Server na linha de comando do Linux, foi o bash da minha sessão quem o fez. Por isso, ele é o pai.

 

No Windows você também consegue iniciar o serviço do SQL Server na linha de comando. Basta mandar executar o arquivo sqlservr.exe e passar os devidos parâmetros:

Neste exemplo, eu parei o serviço do SQL, usando o Configuration Manager, e executei esta linha de comando:

Quando eu iniciei o sqlservr.exe, o usuário com o qual eu abrir o prompt é o usuário quem vai rodar esse processo. Sendo assim, todas os recursos do Sistema Operacional que minha instância precisar, estarão sujeitos a esse usuário. Note que não é o mesmo usuário que eu configurei lá “Configuration Manager”. Aquele é o usuário que será usado quando o sql for iniciado por lá (ou pelo gerenciador de serviços).

Note que, como no Linux, o processo agora é filho do “cmd.exe” (semelhante ao bash’).

No Linux, é o mesmo caso, porém, eu apenas optei por utilizar o mesmo usuário configurado nas definições do serviço. No caso do Windows, os efeitos de ser fazer isso não são tão graves como no Linux, mas ainda sim, não recomendo que faça isso em um ambiente operacional, pois poderá ter os mesmos problemas.

Como o sqlservr.exe é uma “ConsoleApplication”, ele começou a gerar a saída na tela, além do errorlog. Isso acontece nas versões para ambos os sistemas operacionais.


Bom, há muito o que falar sobre processos. Esta foi uma introdução cujo o objetivo é mostrar como ambos os sistemas operacionais fornecem a mesma visão. Porém, apesar das informações simples, elas são poderosas armas em situações de análises. As vezes, os simples fato de olhar o usuário com o qual o processo está rodando, pode te ajudar a perceber um problema devido a permissões de acesso.

Há ainda uma série de ferramentas poderosíssimas, como o Process Monitor, ou o strace, que ajudam a compreender tudo o que um processo está fazendo. Conhecer o que são os processos e seus conceitos mais simples, ajudam a melhor utilizar essas ferramentas. E em algum momento iremos dedicar atenção a elas aqui no blog!

Aqui estão algumas fontes e referências do assunto de hoje:

Um Generalista a mais no mercado?

Depois de um longo tempo sem postagem no blog, estou voltando aqui com algumas novidades. O tempo tem sido crucial, e muitas mudanças aconteceram em minha carreira e vida pessoal. Com isso acabei me afastando do blog. O post hoje conta um pouco do que aconteceu e o que espero pro ano de 2019!

 

Novos conhecimentos, mesmos meios

Depois de longos anos trabalhando com plataforma Microsoft, exclusivamente SQL Server e Windows, finalmente encarei a chance de conhecer outros produtos. Não um específico, mas diversos: o problema aparecia, e tinha que resolver.  Mysql, PostgreSQL, Oracle, DB2, sqlite, etc. Em um primeiro momento, acostumar com essas novas tecnologias é difícil, e chega até ser desanimador.  O SQL Server realmente é um produto incrível, e possui muitas features que tornam o dia-a-dia de um DBA muito mais fácil, porém nada básico. Possui uma engine poderosa, capaz de suportar os mais severos workloads, oriundos das mais exigentes aplicações do planeta. Por um outro lado, existem muitas features interessantes, e que até faltam no SQL Server.

Junto com o receio de se tornar um generalista, resolvi encarar o desafio. O resultado dessa experiência, conto um pouco a seguir.

A maior mudança: Linux

Sem dúvida, o maior conhecimento adquirido foi o Linux. Apesar de passar a maior parte do tempo em uma tela preta, sem usar mouse, diferente do Windows, isso não me trouxe limitação. A princípio, parece que aquilo é realmente uma caixa preta e qualquer mensagem significa o caos. Besteira. Um ambiente robusto, cheio  de controles, lógica, configurações, desafios. Nada diferente do Windows. Apenas um jeito diferente.

Aprender a usar Linux foi um dos, senão o maior, conhecimento que adquiri depois de aprender a programar e SQL Server. Eu não escondo para os meus colegas que sou fascinado pelo “internals” do SO, e o Linux me apresentou centenas de oportunidades para aprofundar mais esse conhecimento. Há quem diga que Windows é melhor, ou que Linux é melhor, ou ainda que Debian é melhor que CentOs, e vice-versa (feliz por entender agora o que esses termos significam). A velha história das comparações… Seguramente, posso dizer que é uma tremenda perda de tempo cair nessa discussão.

Hoje sou um apaixonado por bash, e meu velho powershell. Estou mesmo satisfeito por conhecer mais Linux, e poder explorar o melhor dos dois mundos. Agora, não importa se o problema é um pinguim adoecido, ou uma janela quebrada. Estarei aqui com as melhores ferramentas para resolvê-los.

 

Uma nova gama de opções de configuração e conceitos

Tive o prazer de atuar em problemas diversos em outras tecnologias de banco. Do mais simples aos mais complexos. Um dos meus primeiros desafios nos PostgreSQL foi apenas liberar o acesso de um usuário a partir de um novo IP.  Há um arquivo de configuração que você precisa editar pra isso. Aliás, é uma abordagem interessante. Diferente do SQL, há recursos nativos em outros bancos, como o PostgreSQL e no MySQL,  em que você consegue limitar o acesso do usuário a partir de um endereço. Realmente necessário? Uma discursão interessante pra uma conversa numa mesa de bar! 😆

Acostumar-se como o SQL Server instala seus binários, me fez ficar confuso com algumas tecnologias. Porém, comparar o conceito de instância do SQL Server, com os outros SGBDs, tornou as coisas mais claras no Oracle e no DB2.  No Oracle, o procedimento de instalação, reconhecido na comunidade técnica por ser “difícil”,  vai ficando mais claro a medida que você entende os conceitos. Muita coisa são apenas padrões, que, repassando de geração em geração, se torna um “é assim que se faz, pronto e acabou”. Cheguei até o ponto de criar novas instâncias Oracle manualmente, e me admirei com o fato que com apenas copiando alguns arquivos, você sobe uma “monstruosa” nova instância…  Minha dica é: entenda os conceitos de instância em “Oracle” e DB2 e você sairá vitorioso no primeiro contato com essas plataformas!

Planos de execução e Otimização de Queries

Uma das maiores causadoras de problemas em produção, a famosa lentidão de queries, não é exclusivo do SQL Server. Há sempre uma demanda para “pega as queries mais lenta e otimiza”. Essa nova jornada me trouxe um valioso conhecimento: Aprender a ler planos de execução no PostgreSQL, MySQL, etc. Sem muitas opções gráficas, me acostumei com a leitura do plano em texto.  A complexidade do Query Optimizer (QO) do SQL server deixou o caminho mais fácil para entender compreender o MySQL, que apesar de mais simples, toma decisões eficientes e inteligentes, que poupa trabalhos dos desenvolvedores. Porém, me ajudou a entender muito mais rápido os operadores do PostgreSQL, que possui uma gama infinita, com muito mais opções para controlar as decisões de seu otimizador, entretanto, com muita coisa semelhante do QO do SQL.

Num outro cenário, precisei avaliar o porquê de um simples banco no MySQL, em um portal de internet de um importante orgão do país, estava lento. Pra quem vem do SQL, é meio complicado lidar com a falta de uma sys.dm_exec_requests, ou sp_WhoIsActive. Mas, o meio de encontrar o problema é o mesmo: descubra a query, ou as queries lentas, e quais são seus gargalos. Aliado com as ferramentas do SO, conseguimos entender o problema, onde estava a limitação, e resolvemos isso usando recursos do Linux!

Também, apareceu uma chance incrível de operar um DB2, identificar locks, criar usuários, resolver gargalos, e até gerenciar uma replicação de dados!

Manipulação de Dados

Apareceu um desafio de auxiliar um processo de Auditoria de uma importante rede internacional de supermercados. Era necessário exportar conteúdo de um banco Oracle. Não tínhamos SSIS, nem interface gráfica. O desafio era tudo via linha de comando, era o que podia. Utilizamos a versão sqlcmd do oracle, o sqlplus. Com uma gama de opções, conseguimos exportar o conteúdo com sucesso.  O reconhecimento do vice-presidente desta empresa,  fez todo o esforço de usar powershell, para gerar um script bash que executava o sqlplus, valer a pena!

A triste e velha história da recuperação

Infelizmente, apesar de tantas diferenças, um problema comum: Recuperação. “O banco deu pau e não tem backup”.  Há quem diga que saber internals dos produtos é uma perda de tempo. Talvez sim, para aqueles que possuem recursos para suprir esse tipo de problema, ou mesmo que conseguem se convencer que tudo acabou nessas situações.

Além de conhecer novas formas, ferramentas e tipos de backup/restore (e em agluns casos, apenas diferente sintaxe, para os mesmos comandos), conseguir trabalhar em casos de recuperação de bancos sem backup.  Costurando bits, analisando logs, etc. Igual sempre foi no SQL nessas situações.  Alguns produtos apresentam uma comunidade forte, e documentação boa, outros nem tanto. A comunidade SQL Server realmente é um destaque quando se trata de conhecimentos mais avançados. Mas, é sensacional o fato de você poder ollhar no código-fonte do produto, gastar algumas horinhas apenas fazendo pesquisa de funções C++, entendedo as lógicas, em meios a poucos comentários de código.

 

Novos times

Uma das maiores  novidades, e, que, com muito orgulho, anuncio, foi a de entrar para o time da Fabrício Lima Soluções em Bancos de Dados.  O meu foco é o trabalho com SQL e Azure. Um time que já é muito forte e realmente tem sido animador. Além dos casos que aparecem, temos grupos de estudo, colocamos as experiências de todos para gerar soluções ótimas. É incrível o que esses caras fazem, e não é exagero a hashtag #AlwaysTunningYourData, porque é pra isso que todo esse conhecimento serve: pra fazer com que o seu SQL Server voe, seguindo as melhores e mais eficientes práticas.

Uma oportunidade que, chegou em um momento em que eu estava me distanciando do operacional de banco de dados, na Stefanini. Tendendo para automações de ações e serviços da infraestrutura, exigência da própria Adminstração de Banco de Dados, cheguei em uma equipe de inovação. Aqui aprendi python, docker(e já entrando em kubernetes), serviços cognitivos, machine learning, etc. Uma incrível oportunidade em um momento que todo o mundo já se volta para essas tecnologias!

Realmente tenho muito orgulho dos times que faço parte hoje. Ambos se beneficam das experiências adquiridas em cada um, e me apoiam. Isso faz toda diferença e realmente estou muito empolgado para 2019!

 

Na realidade, nada novo…

Apesar dessas novidades,  a essência não mudou. Ainda continuo apaixonado por assuntos de tecnologia, e gasto horas tentando entender os porquês. Se aparece um problema, seja com python, seja com sql no linux, sql no docker, db2 em Windows, eu passo algumas horas analisando cada log, cada mensagem, juntando as peças, consultando informações, abrindo ferramentas de monitoramento e trace. Tudo está interligado. Cada conhecimento em uma tecnologia, cada forma de resolver o problema, preenche uma vasta biblioteca na minha cabeça (e no meu OneNote,  Dropbox, etc.) com tudo que preciso para resolver os problemas.

E é nisso que se tem se resumindo meu dia-a-dia. Continuo sim, atuando em bancos de dados, especialmente na infraestrutura, resolvendo diretamente casos críticos ou discutindo com uma equipe como resolver. Continuo abrindo o Process Explorer, mas agora abro htop, ps ou top também. Ainda, nos casos mais bizarros, abro o Process Monitor, mas também abro o strace agora. Mais do que nunca tenho brincando com o Windbg ( e ainda não abrir um debugger no Linux, mas estamos quase lá  :-D). Leio internals de Windows, e também já lí o incrível Kernel Development do Linux. E também frequentemente consulto o código-fonte para tirar algumas dúvidas (uma delas, foi auxiliar no entendimento do “Load Average”).

Espero trazer mais em 2019 (e nesse finalzinho de 2018 também)! Mostrar como usar ferramentas, explicar conceitos, etc. Tudo o que já vinha escrito neste blog, porém com mais gama de experiência, tecnologias e ferramentas! E então, será que eu me tornei mesmo um Generalista? Não! Ainda estou envolvido com tecnologias específicas! Mas, estou acompanhando a TI, e indo com as novidades, levando tudo que aprendi até hoje para esse mundo! E tem dado certo, muito certo!

Pra fechar, novamente, a imagem que abre esse post: reflete o que foi esses meus 9 anos na área de TI, retirado da minha palestra no SQL Saturday 811:

 

Copiando bases SQL Server com Copy-SQLDatabase

Copiar bases entre instâncias é procedimento muito comum em qualquer ambiente SQL, na maioria dos casos para manter ambientes de homologação, teste, desenvolvimento, etc. Esta tarefa pode ser muito simples, quando a base é pequena e tem poucos arquivos, ou complicada, quando a base é grande e há muitos arquivos envolvidos. A complexidade pode aumentar mais quando é preciso manter as permissões, executar scripts de expurgo, etc.  Pensando nisso, desenvolvi um script em powershell que tenta facilitar ao máximo este processo ao mesmo tempo que fornece uma série de recursos para este procedimento. Este artigo vai apresentar algum destes recursos!

Há um série de “pequenos probleminhas” que me incomodam bastante ao realizar restores de bancos de dados no SQL Server. Destaco os seguintes que contribuem para que este processo fique chato e cansativo:

  1. Estrutura de discos diferentes na instância de origem e destino
    Mount points, letras diferentes, espaço disponível, etc., são elementos que resultam em retrabalhos e podem acarretar erros no processo de RESTORE.
  2. Manter as permissões na base de destino
    Ao longo do tempo, diferentes usuários ganham diferentes tipos de acesso à base, e manter este controle para um posterior restore pode deixar mais caro ainda.
    Este é um tipo de solicitação bastante comum: Sobrescreva a base, mantendo os usuários e permissões!
  3. Executar scripts após a cópia
    É comum que um ou mais scripts precisem ser executados após o restore para, por exemplo, alterar a senha de todos os usuários para 123456. Estes scripts podem variar conforme a necessidade do responsável pela mesma.

Copy-SQLDatabase cuida de todos estas questões e muito mais, permitindo uma maneira mais flexível de copiar bases.

Pré-Requisitos

Para executar os exemplos a seguir você irá precisar do seguinte:

  • Powershell 2.0 ou superior (Instalado junto com o Windows a partir da versão 7/2008)
  • Módulo CustomMSSQL
    CustomMSSQL é um modulo em powershell, contendo vários cmdlets, inclusive Copy-SQLDatabase.
    O link para download está acima e a instalação é fácil e rápida.
    Para executar os comandos, é preciso importar o módulo usando o comando Import-Module. No link do download existem instruções de instalação e uso do módulo.
  • Pelo menos uma instância SQL Server 2005 ou superior (Óbvio que você não irá usar a produção para testes, ok?)
  • Ambiente powershell
    • Permita a execução de scripts: Abra o powershell como Administrador e execute o comando:
    • Certifique-se que sua máquina tenha acesso ao servidor de destino (computador onde a instância de destino está)
      • Verifique se o seguinte comando executa normalmente: Get-WmiObject Win32_Volume –ComputerName <IP-ou-Nome-Destino> | select Name
        • Em caso de falhas, verifique as permissões de acesso do WMI na máquina de destino.

 

Exemplo 1: Cópia simples

Neste exemplo, estamos usando a forma mais básica de cópia, através do método Backup/Restore via T-SQL. Apenas especificamos as informações de conexão como instância de origem e de destino, além do nome da base na origem e o nome que a base irá ter no destino. Por padrão, Windows Authentication será usado. O Copy-SQLDatabase ainda não permite a conexão usando SQL Authentication, mas deverá ser implementando na próxima versão. O diretório especificado no parâmetro “BackupFolder” indica o local onde o Backup será gerado. As contas de serviço das instâncias envolvidas deverão ter as devidas permissões neste diretório. Na origem, Copy-SQLDatabase irá tentar usar as opções COMPRESSION e COPY_ONLY, se suportados.

Note que não foi necessário especificar nenhum local para os arquivos. Este é uma das grandes facilidades fornecidas por Copy-SQLDatabase. O cmdlet irá tentar determinar o melhor local para os arquivos da base. Usando o backup de origem, ele irá determinar os arquivos existentes, bem como o tamanho, e irá gerar o comando de RESTORE adequadamente. Há alguns algoritmos que Copy-SQLDatabase irá usar para distribuir os arquivos nos volumes existentes no destino. O algoritmo usado vai depender de alguns fatores, como o conjunto de parâmetros informados. O comportamento padrão é o seguinte:

  • Se a base de destino não existe, então ele irá partir do maior arquivo e encontrar o volume com maior espaço livre. O processo vai se repetir até que todos os arquivos estejam com seus volumes determinados. Se não houver volume com espaço livre para algum arquivo, o script irá encerrar a execução reportando o erro “NO_VOLUME_FOUND_FOR_FILE”.
  • Se a base de destino existe, então ele irá alocar os arquivos no mesmo diretório que os arquivos existentes (mapeando através do nome lógico do arquivo). Se houver um arquivo a mais, ele irá escolher um dos diretórios usados pela base aleatoriamente para alocar o novo arquivo. Isso poderá resultar em erros de espaço retornados pelo comando de RESTORE, já que o cmdlet assume que se a base existe, ela está no melhor local possível e, portanto, não valida o espaço. Se isto ocorrer, você pode usar o parâmetro “NoUseCurrentFilesFolder” para forçar o cmdlet a usar o algoritmo anterior, mesmo para a base existente:

Por padrão, o script irá manter as permissões, caso a base exista. Antes de sobrescrever a base, as permissões, roles e seus membros, serão lidas e salvas na memória. Após o restore, as permissões serão aplicadas na base restaurada. Para desativar esse comportamento, utilize o parâmetro “-KeepPermissions $false”

Exemplo 2: Cópia simples com execução de scripts

Um das minhas features favortias deste cmdlet é a capacidade de executar scripts após o restore. Isso é útil quando existe uma série de scripts que o responsável pela base precisa que seja executado sempre que o restore for feito. O Parâmetro “-PostScripts” aceita um Array de strings onde cada string especifica um comando SQL, um arquivo ou um diretório contendo scripts para serem executados. Cada script é executado na ordem em que foi especificado, e no caso de diretórios os scripts serão executados na ordem do nome do arquivo. No exemplo acima, a ordem será:

  1. O script SQL
  2. Arquivo Script.sql
  3. Arquivos  no diretório “MeuBanco”, ordenados pelo nome (seguindo as regras de ordenação do Windows)

Se um script falhar, por padrão, a execução dos scripts se encerrará e o erro do script será logado. Você pode controlar esse comportamento usando o parâmetro “–PostScriptsPolicy”. Este parâmetro indica o que o cmdlet irá fazer quando o script resultar em erro. Para ignorar o erro e executar o próximo script, especifique o valor “SkipErrors”.

Você pode se perguntar se isso não representaria um risco, pois o script pode conter código malicioso, que prejudique outras bases ou mesmo a instância. Para evitar isto, o cmdlet aceita o parâmetro “UseLimitedUser”. Com este parâmetro, Copy-SQLDatabase irá criar um login na instância de destino com permissões somente na base de destino. Assim, os scripts poderão afetar somente a base de destino (a menos que, por exemplo, a permissão de CONTROL SERVER seja garantida para a role public). Após a execução, o login/usuário que foram criados, serão deletados. O nome do login será formado pela string “CopySQLDatabaseLimited_” mais o nome da base de destino. Apesar do script gerar a senha, o comando de CREATE LOGIN é transferido a instância em texto claro e, portanto, pode estar sujeito a ataques. Versões futuras podem mudar a forma como este parâmetro é implementado.

Caso o script executado retorne um RESULTSET, o mesmo será exibido no error log, linha por linha, o que pode encher o log do cmdlet.  As próximas versões irão apresentar melhorias neste processo, permitindo maiores controles sobre os resultados gerados pelo script.

Copy-SQLDatabase possui muitas funcionalidades que iriam estender mais ainda este post. Você pode usar o comando Get-Help Copy-SQLDatabase para obter mais ajuda sobre o cmdlet e seus parâmetros. Atualmente, apenas o método Backup/Restore usando T-SQL é suportado, com algumas variações. Em versões futuras, suporte a ferramentas de backup de terceiros podem ser adicionadas, bem como outros métodos de cópia.  Antes de finalizar, deixo mais alguns recursos interessantes de Copy-SQLDatabase:

  • Logging
    Copy-SQLDatabase tem uma poderosa engine de log que permite usar arquivos e até scripts powershell como destino das mensagens de log gerada. Há um modo especial para uso com o SQL Server Agent, devido ao modo como ele lida com logs e resultados.
  • Arquivos
    Apesar do cmdlet tentar escolher o melhor local dos arquivos, podem existir casos onde ele erre ou não tenha as permissões suficientes. Alguns parâmetros permitem especificar manualmente o mapeamento dos arquivos, como se estivesse usando a cláusula MOVE. Também, é possível especificar filtrar volumes e ainda especificar quais volumes são permitidos para logs e para dados.
  • Fonte do Backup
    Além de permitir que o backup em tempo real seja feito, o cmdlet permite usar um backup existente. Também, é possível forçar que a base de origem fiquem em READ_ONLY antes que o backup seja feito. Isto pode ser útil em migrações. Ainda, o cmdlet permite que um script T-SQL customizado de backup seja especificado.
  • Destino
    Além da execução de scripts no destino, o cmdlet fornece opções como colocar a base em RECOVERY SIMPLE, ou mesmo fazer o backup da base de destino antes que a base seja sobrescrita

Copy-SQLDatabase, que ainda está na versão BETA, realmente pode ser um grande ferramenta e poupar boa parte do seu trabalho, permitindo que você concentre seus esforços em outros projetos. O mesmo já foi usado, inclusive, para migrar um ambiente de produção, onde a origem era uma instância standalone e o destino uma instância em cluster, utilizando mounts points, o que reforça o potencial. Alguns detalhes desta migração podem ser conferidos neste post.

O módulo CustomMSSQL está publicado no GitHub, portanto você pode melhorá-lo ou mesmo reportar bugs. Já existem alguns issues regitrados e você pode acompanhar as correções e melhorias implementadas, bem como fazer sugestões.

Haverão outros posts falando sobre Copy-SQLDatabase e outros cmdlets do módulo CustomMSSQL. Mas você pode usar a documentação do mesmo para aprender mais. Até a próxima!

[]’s
Rodrigo Ribeiro Gomes

Apresentando CustomMSSQL, Copy-SQLdatabase e SCRIPT STORE: Versão BETA

Há muito tempo, ingressei no mundo de tecnologia estudando HTML. Desde então, aprendi muitas coisas na área de TI e não parei por aí. Bom, o que isso tem a ver com esse post? Simples: A comunidade, não só de SQL, mas de tecnologia em geral, é uma das coisas mais importantes de minha carreira.

Pensando em retribuir isso, há algum tempo eu venho mantendo uma série de scripts feitos em powershell que têm me ajudado a gerenciar o ambiente SQL. Eu gostei bastante dos resultados que resolvi publicá-los. E tudo isso será de graça, free, 0800, para sempre! Para tentar entregar algo mais organizado e fácil de aprender, eu também estou lançando a SCRIPT STORE. A script store é um repositório de tudo que é tipo de script que eu irei publicar e manter atualizado. Em breve, espero que ela esteja bem, mas bem cheia mesmo.

Já existem dois scripts publicados: O módulo CustomMSSQL e a procedure sp_WhoIsAuthorized. Eu já fiz muitos testes com estes dois scripts, tanto que já possui mais de 1 ano de vida. E, eu venho usado em meu dia-a-dia como DBA. Estes scripts são exemplos de coisas que eu sinto falta no SQL Server, e espero que você possa me ajudar, ou melhor, possa ajudar a todos, fazendo destes códigos algo estável e útil para muitos ambientes, e claro, sempre e sempre free!

Hoje eu vou dar destaque para o módulo CustomMSSQL. Este módulo disponibiliza vários cmdlets para lidarmos com o SQL Server. Por exemplo, temos o Get-SQLAgentOptions que traz as configurações do SQL Agent que estão salvas no registro. Há também o Send-SQL2Zabbix, que é um cmdlet extremamente poderoso para quem quer integrar o SQL Server com o Zabbix. Este último eu já estou usando em um ambiente que estou trabalhando e tenho tido resultados incríveis. Em breve posto mais sobre ele.

Eu quero inaugurar este módulo falando, na verdade, de um cmdlet que desenvolvi e têm sido meu xodó e me ajudado bastante: Copy-SQLDatabase. Como o nome já diz, este cmdlet serve para copiar bases SQL. Vou pegar o exemplo da documentação do cmdlet que já está disponível na Script Store:

Bom, conforme descrito na documentação, este exemplo é bem simples: ele copia a base MyDB, que está na instância “ProdServer\Inst01” para a instância “DevInst” com o nome, também, de “MyDb”.

O processo é bem simples e se você já administra instâncias SQL há algum tempo, já estará familiarizado: Ele faz um BACKUP da base na instância de origem, e um RESTORE na instância de destino. Simples. A principal diferença, e minha preferida, é que eu não preciso me preocupar mais em determinar em quais discos a base deverá ser restaurada. O cmdlet irá fazer isso por conta própria. Graças à flexibilidade do powershell, o script consegue determinar os discos disponíveis no servidor onde a instância de destino está. Isso é perfeito para a maioria das cópias entre produção e desenvolvimento.

Log coletado de um caso real

Exemplo do início do log de Copy-SQLDatabase. Este log foi de um uso em real, para copiar a base de uma instância de produção para outra, em cluster.

Quando a base não existe, o algoritmo que ele usa tem uma lógica bem simples: Maiores primeiros. Isto significa que, partindo do maior do arquivo, o cmdlet tenta eleger em qual volume ele irá alocar o mesmo. Após escolher, ele subtrair a quantidade de espaço do volume, e checa o próximo maior arquivo. Ele vai fazendo até que todos os arquivos tenham sido mapeados para um volume. Se algum arquivo não pode ser mapeado, por não haver um volume com espaço suficiente, por exemplo, então ele encerra a execução e exibe o erro.

Se a base de destino já existe, por padrão, o script vai tomar um caminho diferente. Ao invés de realocar os arquivos em volumes novos, ele usa os diretórios em que os arquivos da base existente estão. Ele associa os arquivos pelo nome lógico. Se o arquivo não existir  na base de destino (caso tenha sido adicionado desde que a base foi copiada, por exemplo) ele escolhe um dos diretórios aleatoriamente. O cmdlet tem esse comportamento pois ele assume que a base de destino já está alocada no melhor lugar possível. Você controlar esse comportamento através de parâmetros do cmdlet. No caso da base existir também, antes de substitui-la, usuários, permissões e roles são “backupeados” para depois serem restaurados.

Exemplo do log de Copy-SQLDatabase, quando vai fazer o backup na origem e determinar os arquivos disponíveis. Este log foi de uma uso em real, para copiar a base de uma instância de produção para outra, em cluster.

Exemplo do log de Copy-SQLDatabase, quando vai fazer o backup na origem e determinar os arquivos disponíveis. Este log foi de um uso em real, para copiar a base de uma instância de produção para outra, em cluster.

Bom,  há muita, mas muita coisa que este cmdlet é capaz de fazer, e em futuros posts irei dar mais dicas e mostrar mais funcionalidades. Por hora, destaco alguns parâmetros que potencializam Copy-SQLDatabase:

  • UseRecent, RecentFileMask e RecentBase
    Estes parâmetros permitem que você especifique um arquivo existente como fonte do RESTORE, ao invés do cmdlet executar um BACKUP novo. Você pode controlar quão recente o arquivo deve ser e o filtro para listar os arquivos. O cmdlet irá procurar o arquivo no diretório especificado por “BackupFolder”.
  • DestinationDatabaseBackup
    Faz o backup da base de destino antes de substitui-la. Você deve informar o caminho do backup. Isso é útil em situações que necessitem guardar uma base que será sobrescrita.
  • ForceSimple, Replace, NoRecovery
    Coloca a base em SIMPLE após restaurá-la, usa a opção REPLACE e usa a opção NORECOVERY, respectivamente.
  • AllowedVolumes,VolumesForData, VolumesForLog
    Permite especificar quais volumes serão usados. AllowedVolumes restringe os volumes que serão considerados. Você pode usar caracteres coringa como “*”. VolumesForData e VolumesForLog permite que você especifique em quais volumes o cmdlet deve mapear arquivos de dados e arquivos de log, respectivamente. Isso é bem útil quando você que restaurar bases na produção. Estes parâmetros não têm efeito quando a base já existe e o diretório dos arquivos existentes serão usados.
  • PostScripts, UseLimitedUser
    Este e um dos meus favoritos. Muitas solicitações de cópias de produção para desenvolvimento incluem a execução de scripts, como por exemplo, um UPDATE para trocar as senhas para “123456”. Pensando na diversidade destas solicitações, você pode especificar um array de código T-SQL para ser executado na base após o restore. Você pode especificar diretórios, comandos T-SQL ou nome de arquivos. O parâmetro UseLimitedUser faz com que os scripts sejam executados com um usuário que só irá ter acesso a base restaurada. Isso pode evitar que scripts maliciosos afetem a instância inteira. Por exemplo, se o usuário colocar um SHUTDOWN no script, ele não irá funcionar.  O script apenas cria um login/usuário único na instância/base, concede permissões de db_owner na base de destino somente, e ao final deleta ele.
  • LogTo e LogLevel
    Com estes parâmetros você pode controlar  quantidade de Log que é gerado pelo script. O padrão é o modo “DETAILED” onde ele mostra uma série de informações a respeito do progresso do script. Pode ser útil para entender erros que podem acontecer,  ou mesmo ver para onde os arquivos serão mapeados. Com  LogTo, você controla para onde o log será feito. Você pode especificar um array de arquivos. O padrão é “#” que significa que o script irá usar “write-host” para logar as mensagens.

Apesar de estar na versão beta, eu já tenho usado este script para copiar diversas bases, todos os dias, de produção para homologação, e usando, além dos parâmetros acima, muitos outros disponibilizados. Recentemente eu usei o script para migrar cerca de 20 bases distribuídas em 100GB de uma instância standalone para uma instância em cluster, em produção. Apesar de ser pouco, eu poupei bastante trabalho e precisei apenas observar.

Exemplo log de Copy-SQLDatabase, quando vai determinar os volumes. Este log foi de uma uso em real, para copiar a base de uma instância de produção para outra, em cluster.

Exemplo log de Copy-SQLDatabase, quando vai determinar os volumes. Este log foi de uma uso em real, para copiar a base de uma instância de produção para outra, em cluster.

 

Exemplo do log de Copy-SQLDatabase, quando, vai determinar em quais volumes ele irá alocar o arquivo. Este log foi de uma uso em real, para copiar a base de uma instância de produção para outra, em cluster.

Exemplo do log de Copy-SQLDatabase, quando, vai determinar em quais volumes ele irá alocar o arquivo. Este log foi de uma uso em real, para copiar a base de uma instância de produção para outra, em cluster.

Bom, espero que o script seja útil e qualquer dúvida, sugestão e problema basta enviar um email para “rodrigo@thesqltimes.com” ou “rodrigorigomes@gmail.com” ou enviar em um comentário deste post.

Baixe o módulo CustomMSSQL Beta em: http://scriptstore.thesqltimes.com/custommssql/sobre-custommssql/custommssql/ 

O que é powershell?

Lembra do cmd.exe? Prompt de comando, telinha preta, etc. São vários os nomes dados ao Shell padrão do Windows.

cmd.exe

 

Isto também é um shell

Isto também é um shell

Acredito que a primeira dificuldade em entender o que é o powershell é entender antes o que é um Shell. Bom… Um shell é uma interface em que o usuário do sistema operacional pode interagir com os serviços oferecidos por ele (Fonte: Wikipédia).  Ou seja, você fornece comandos para o shell, e o shell transforma o que você forneceu em chamadas para as funções internas do sistema operacional, que vai te dar uma resposta ou fazer alguma operação, baseado neste comando. Em poucas palavras e grosseiramente falando, é apenas um programa que recebe comandos e chama as funções correspondentes da API do sistema operacional, recebe o resultado e transforma em algo mais legível para você, reles humano.

Um shell

O cmd.exe  era o shell padrão. Ele era baseado na mesma interface do antepassado do Windows: o DOS (daí porque é chamado de DOS também). Além de permitir usar elementos comuns de linguagens de programação, como loops, variáveis, você podia usar comandos para listar diretórios, obter informações de disco, formatá-los, etc.

O powershell é a evolução do cmd.  Na minha opinião, uma das grandes vantagens do powershell é que ele usa todo o .NET como sua base. Você praticamente pode programar em C# na linha de comando. Isso te permite construir scripts avançados, que fazem tarefas complexas, com apenas algumas linhas de código, sem precisar abrir um Visual Studio e compilar algo. Outra grande vantagem é o fato de que os resultados dos comandos são retornados como objetos, e não como texto. Isso permite que você manipule mais facilmente o retorno dos comandos, ainda mais quando você precisa passar resultados de um comando para outro comando. (O famoso pipe “|”). Também, o powershell te permite interagir facilmente com o WMI (um serviço do Windows que provê uma série de informações sobre o Hardware e Software), facilita o processo de execução de scripts em máquinas distintas, e uma série de outros recursos.

A interface padrão do powershell. Telinha preta, nunca mais! Será mesmo!?

A interface padrão do powershell. Telinha preta, nunca mais! Será mesmo!?

Em breve, mais postagens sobre POWERSHELL!

Iniciando em powershell:

http://abstrys.com/doku.php/technology/powershell/beginning-powershell-scripting

http://www.powershellpro.com/powershell-tutorial-introduction/