Virtual PASS BR

Identificando o uso de objetos ‘deprecated’ na sua instância.

Quick tip!

A cada nova versão do SQL Server, novos recursos são adicionados e, claro, alguns são removidos ou marcados para futura exclusão (deprecated). O último caso ocorre para que todos tenham tempo para validar e ajustar suas aplicações, afinal, ninguém aqui é doido de aplicar uma nova versão do SQL Server em produção sem validar se a aplicação está rodando adequadamente, né!? NÉ!?!? 🙂

Ok, mas como saber se você está usando um recurso na sua instância que está marcado como deprecated?

Para isso, você pode consultar a sys.dm_os_performance_counters, olhando para a coluna object_name igual à ‘SQLServer:Deprecated Features‘. Os registros que estiverem com a coluna cntr_value maior que 0 (zero) é porque em algum momento o objeto ou recurso foi consultado.

E aí você sabe que está na hora de começar a avaliar e (quem sabe) planejar a alteração.

Ah, você quer saber o que cada registro desse select significa?

https://docs.microsoft.com/pt-br/sql/relational-databases/performance-monitor/sql-server-deprecated-features-object

PS: Honestamente, eu prefiro a versão em inglês, mas para não ter que ouvir ler que temos pouca literatura em português e blábláblá… Fica o link em pt-br (mas se quiser mudar para inglês, troque o pt-br por en-us – Eu recomendo 😉 )

[]’s!!

Read More

#WTF: “The UserLog directory in the registry is not valid.”

Essa entra pra série #WTF (Vivendo e aprendendo).

Ao instalar o Full Text Search em um dos nossos servidores, me deparei com o warning a seguir:

What!?

The User Log directory in the registry is not valid. Verify DefaultLog Key under the instance hive points to a valid directory

Read More

Valide seus backups com a prRestore

EDIT

O script foi atualizado! Versão 2.0 saindo do forno!!

Agora é possível usar o script para restaurar o último diferencial criado também… E os logs, obviamente, respeitarão a opção. Baixe aqui!

FIM DO EDIT

Se você perguntar para “N” profissionais qual o principal bem das empresas, a resposta será praticamente a mesma: Os dados que ela possui (e se você achava que era o próprio funcionário, sinto te desiludir).
E para garantir que os seus dados estejam sempre prontos para serem recuperados em caso de desastre, basta você fazer o backup dela periodicamente, seguindo uma politica que te permita recuperá-la em um ponto no tempo (eu recomendo ler sobre a procedure criada pelo Edvaldo Castro sobre o assunto), correto??

giphy
Não… Não é…

Apenas o backup não vai te garantir que a base está pronta para ser restaurada quando precisar. Para isso, é necessário que você teste periodicamente os teus backups (sim, muita coisa pode acontecer para que seus backups não funcionem).

Mas ficar lembrando dos comandos ou então deixar um script armazenado para isso não é muito legal também… Porque não, então, automatizar a restauração e deixar o processo mais fácil de ser verificado? Em um dos grupos que eu participo, surgiu a dúvida sobre como automatizar esse processo e, pensando nisso, fiz a procedure prRestore, para tentar ajudar.

Ela está em fase inicial ainda, mas já ajuda em verificar o último backup FULL realizado e os “N” backups do log de transação subsequentes (essa era a dúvida principal).

Algumas observações:

  1. Para fazer algo que eu precisasse passar o mínimo de parâmetros possíveis eu parti do pressuposto de que os arquivos continuam no mesmo onde eles foram backupeados (?) originalmente.
  2. Como o propósito é testar os backups, aqui eu vou salvar os dados em uma pasta e os logs em outra. Nada impede de colocar na mesma pasta, mas se você quiser separar os dados em mais de uma pasta, não vai funcionar (valeria um item para a ToDo List?)
  3. Falta colocar para validar o diferencial… Esse é um item que entrará para ser feito futuramente.

Mas vamos lá: Como funciona??

Após aplicar o script, execute:

Onde:

  1. @origin_database_name: Nome do banco de origem (a.k.a. O banco que foi backupeado)
  2. @new_database_name: Nome do banco de destino
  3. @last_diff: Se você vai querer restaurar o último diferencial gerado. Parâmetro disponível apenas na versão 2.0, no link acima… No link abaixo esse parâmetro não existe!
  4. @log_qty: Quantos logs de transação devem ser restaurados depois do full. Coloque 0 para testar apenas o FULL.
  5. @data_destination_path: Local onde os arquivos de dados (.mdf, .ndf) serão restaurados.
  6. @log_destination_path: Local onde os arquivos de logs de transação (.ldf) serão restaurados.

Ainda tem muito mais a ser feito (e a minha ideia é manter esse script sempre atualizado – Veja o que já está programado nos comentário do script) e, para isso, eu conto com a sua ajuda amiga… Como? Simples… Baixe, aplique, teste e critique. Todo o feedback é válido e necessário. Só assim eu consigo melhorar, ajustar ou remover o que foi feito…

Interessou??? Então baixe o script!

O script, como sempre, está disponível para download gratuitamente e serve para uso comercial como não comercial.
Apenas peço para que os créditos sejam mantidos quando for utilizá-lo.

Para fazer qualquer solicitação, crítica, ou xingamentos, é muito fácil… Basta deixar um comentário e/ou enviar um e-mail para logan at merazzi dot eti dot br com o que quiser falar que você será extremamente bem recebido. 😉

Espero ter ajudado hoje.

[]’s!!

 

Read More

Restaurando um banco apenas com o .mdf

Surgiu uma solicitação para eu restaurar um banco. Até aí, tudo ok, é um processo normal. RESTORE DATABASE Blábláblá, permissões dadas e assunto encerrado.
Ao ver o arquivo, havia apenas um .mdf. Ou seja, não é mais um restore, é um ATTACH. Seria outro processo normal também… Se existissem os arquivos de log (.ldf).

Ao tentar restaurar, o seguinte erro surgiu:

File activation failure. The physical file name “C:\Caminho\Original\do\banco\arquivo_log.LDF” may be incorrect.

The log cannot be rebuilt because there were open transactions/users when the database was shutdown, no checkpoint occurred to the database, or the database was read-only. This error could occur if the transaction log file was manually deleted or lost due to a hardware or environment failure.

Mas vamos lá, passo a passo, para vermos os problemas que podem aparecer e como resolver.

Read More

Acessando um banco MySQL pelo SQL Server via Linked Server

Surgiu uma demanda onde era necessário migrar algumas tabelas de alguns bancos em MySQL para dentro do SQL Server e tínhamos disponível apenas o backup (a.k.a. dump) dos bancos de origem.

Realizar o tratamento do arquivo (manualmente) para que fosse possível criar os bancos e inserir os dados estava fora de cogitação. Como temos uma VM com o Linux (Ubuntu) e com o MySQL instalado, optei por realizar a criação de um Linked Server entre os dois servidores.

Read More
%d blogueiros gostam disto: