SQL Server

Em uma conversa, surgiu a dúvida: Quais as extensões o SQL Server usa nos arquivos? Por padrão (ou por convenção), usa-se a extensão .mdf para o arquivo primário, .ndf para os arquivos secundários e .ldf para os logs de transação. Até aí, tudo bem… Só que nada te impede de criar uma base com a extensão .zzz para os arquivos. E sim, o SQL vai trabalhar normalmente. Como isso é uma possibilidade, nada te impediria de criar um arquivo novo com a extensão .ldf e associar a um datafile (que, mais uma vez, “deveria” ser .mdf ou .ndf). O que vai acontecer? Pro SQL Server, nada. Mas isso pode dar um nó na cabeça do cidadão que eu vou te dizer…. Vamos a um caso real hipotético e como resolver… ...

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 ...

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?? ...

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. ...

Esta é uma série de 3 posts (talvez, surja mais uma) onde eu quero tratar sobre tratamento de exceções dentro do SQL Server. Recomendo que sejam lidas as partes 1 e 2 da série, caso ainda não tenha feito, pois elas darão um bom embasamento sobre alguns pontos do que será dito neste terceiro post. Introdução ao tratamento de Exceções Tratamento de Exceções. Parte 2 Existem algumas forma de implementar o retorno do erro ao usuário: PRINT, SELECT, RAISERROR e THROW. Tudo vai depender de como a rotina está sendo implementada e de como a mensagem deve ser exibida para o usuário. ...

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. ...

Essa é a parte 2 de uma série de 3 posts (ou 4, quem sabe), onde eu quero falar sobre as formas de realizar o tratamento de exceções no SQL Server. Se você caiu aqui por acaso, sugiro antes dar uma olhada na parte 1 da série, onde eu trato de alguns detalhes no que diz respeito à forma que o SQL Server realiza o encerramento de processos, nos casos de erro. Hoje irei falar sobre como realizar o tratamento de exceções, via TRY / CATCH. ...

O seu código vai dar erro. Isso é um fato. Mesmo que seja a pessoa mais cuidadosa do mundo, você tem que preparar o seu código para o pior: O bug! Até porque no momento que os erros aparecerem, você vai precisar verificar o que está ocorrendo e ajustar da forma mais rápida possível. E tem outra: Ninguém gosta de rodar uma aplicação e dar de cara com uma tela exibindo o stack do erro. E para isso, você deve tratar as exceções que o teu código pode gerar. Mas antes de entrar no assunto de tratamento de erros, primeiramente, gostaria de alinhar algumas ideias… Esse será o primeiro de uma série de 2 ou 3 posts, veremos como ficará o próximo, pois este já ficou consideravelmente grande. ...

Não vou entrar aqui no mérito do que são os schemas e como especificamos (deixemos isso para um outro momento). Quero apenas deixar o seguinte cenário: Um usuário criou uma série de scripts e, ao aplicá-lo no banco, todos os objetos ficaram com o nome do usuário no schema: usuário.procedure, usuario.function, usuario.table Como ajustar isso, sem que seja necessário abrir cada objeto individualmente e colocar no schema correto (vamos usar o schema dbo aqui, para simplificar as coisas)? ...

Muito provavelmente, para utilizar o Database Mail dentro do SQL Server você utilizou a interface gráfica… Criou o profile, a conta, ativou como público (né, fala a verdade…) e manteve as opções padrão. Os e-mails estão sendo enviados normalmente, até que surge a necessidade de criar um outro profile. Como o nome ficou parecido, você resolve ir nas configurações do database mail e mudar o nome do profile anterior: Botão direito em Database Mail -> Configure Database Mail -> View, Change, or delete an existing Profile, seleciona o profile desejado e… fuéfuéfué… Como altera o nome? ...