A configuração do SQL Server 2000 em Cluster Ativo/Passivo, proporciona maior segurança e tolerância a falhas para um ambiente de produção do SQL Server. Neste caso, quando uma falha ocorrer no nó ativo, todos os recursos deste nó são transferidos para o outro nó (nó passivo) que torna-se então o nó ativo e o SQL Server continua funcionando como se nada tivesse acontecido. Este artigo explica como reconstruir o nó do cluster em caso de falhas.
É no momento da passagem dos objetos de banco do ambiente de desenvolvimento para o ambiente de qualidade ou produção que o DBA deve realizar a validação dos scripts que recebe e, claro, devolvê-los ao desenvolvedor se houverem erros para corrigir. A questão não são as tabelas, pois o DBA deve ter participado da modelagem do banco anteriormente, isso é uma regra que deveria ser seguida por todas as empresas.
Toda aplicação sempre possui uma série de tabelas de domínios. Chamamos de tabelas de domínios tabelas que contenham informações de referência para as tabelas de informações do sistema. Por exemplo, tabelas contendo a lista de estados do país, a lista de valores para o campo estado civil, lista de profissões, entre muitas outras.
Um dos grandes desafios para o DBA é garantir que, depois da aplicação estar em produção, apenas sejam gerados scripts evolutivos para a realização de alterações nas tabelas e objetos relacionados a elas. O DBA deve garantir que nunca sejam gerados scripts que possam destruir os dados existentes no ambiente de produção da empresa.
É muito comum que um sistema tenha necessidade de criar informações de auditoria, para que se tenha conhecimento de quando foi feita e quem fez a ultima modificação em um determinado registro.
Os triggers são os objetos mais delicados para o processo de transferência. Isso porque o trigger não é claramente visivel entre os objetos do banco de dados (via enterprise manager) e a falta do trigger não faz com que a aplicação pare de funcionar de imediato. Por isso não é raro acontecer de na implantação da aplicação um trigger ser esquecido para trás e a falta dele só ser notada tempos depois da aplicação já estar funcionando.
Um dos pontos chaves para se obter ganhos de performance do SQL Server é tornar suas transações tão curtas quanto possível. Nesta dica iremos apresentar alguns truques usando a sentença CASE para executar multiplos UPDATES em uma tabela utilzando uma única operação. Fazendo isto, algumas transações podem ser diminuidas e consequentemente, a performance de sua execução melhorada.
Colocar todas as regras de negócios na aplicação e não no banco de dados ? Procedures, é errado colocar as regras nas procedures, deixar que o banco de dados faça o trabalho pesado ? Não é melhor analisar cada caso como um caso e não generalizar ?
As procedures de sistema do SQL Server são precedidas pelo prefixo SP_ . Isso soa aos DBA’s como um padrão de nomenclatura de procedure. Quando uma procedure é precedida por SP_ o SQL Server busca a procedure no banco Master. Isso permite que sejam criadas procedures globais para administrar o servidor. Essas procedures podem ficar no Master e serem chamadas a partir de qualquer banco que o SQL Server as encontra.
A dica desta semana apresenta algumas funções não relacionadas no Books Online do SQL Server e que são bastante úteis no dia-a-dia de um DBA.