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:
import-module CustomMSSQL Copy-SQLDatabase -SourceServerInstance "ProdServer\Inst01" -SourceDatabase "MyDb" -DestinationServerInstance "DevInst" -DestinationDatabase "MyDb" -BackupFolder "\\SQLBackups\Temp$" -RestoreFolder "MSSQL\DEFAULT_INST"
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.
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 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 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/
DBA Team Leader na Power Tuning