A ferramenta Best Practices Analyzer para Microsoft SQL Server 2000 é uma ferramenta de gerenciamento de banco de dados desenvolvida pela equipe de desenvolvimento do Microsoft SQL Server que permite detectar se o banco de dados projetado segue as diretrizes de práticas recomendadas para operação e gerenciamento do SQL Server. Essas diretrizes são reconhecidas por ajudar a melhorar o desempenho e a eficiência do banco de dados e facilitar a manutenção dos aplicativos.
2. Comece a usar o SQL BPA Best Practices Analyzer
Após a conclusão da instalação, haverá um documento do Word do Guia do usuário do SQL Server Best Practices Analyzer. Como usá-lo é explicado claramente
. no SQL BPA
(2) Adicionar análise / instância detectada do SQL Server
Você precisa inserir o nome da instância do SQL Server aqui. O nome amigável é usado para associar ao grupo de práticas recomendadas criado posteriormente (basta mantê-lo igual ao nome da instância do SQL Server). ). O valor padrão da Lista de Bancos de Dados é *, o que significa que ela contém todos os bancos de dados da instância atual do SQL Server. No entanto, o BPA irá ignorar a detecção de bancos de dados como 'master', 'tempdb', 'msdb', 'pubs' e 'northwind'.
(3) Para gerenciar Grupos de Melhores Práticas,
primeiro você precisa criar um Grupo de Melhores Práticas, que na verdade combina algumas Regras e as associa à instância do SQL Server inserida anteriormente.
(4) Analisar a instância do SQL Server
e mover o Grupo de Melhores Práticas criado anteriormente para a lista de Grupos de Melhores Práticas a serem Executados, para que possa ser executado de acordo com as Regras previamente definidas e gerar um Relatório para fornecer sugestões e diretrizes de melhoria.
3. Acho que as regras incluídas no SQL BPA v1.0
são o ponto chave, porque somente entendendo essas diretrizes de práticas recomendadas para operação e gerenciamento do SQL Server podemos tentar seguir essas regras ao projetar bancos de dados e escrever scripts T-SQL. melhorar o desempenho e a eficiência do SQL Server e dos aplicativos.
Na verdade, todas as regras estão aqui (versão em inglês) file:///C:/Program%20Files/Microsoft%20SQL%20Server%20Best%20Practices%20Analyzer/html/RuleInformation.html#_Rule:_Explicit_Index_Creation . use SQL BPA é instalado no caminho padrão. Se você alterar o caminho de instalação, ele não estará aqui.
Aqui estão algumas regras que me interessam:
(1)
Regras de design de banco de dados: Tabelas sem chaves primárias ou restrições exclusivas
Verifique o banco de dados para garantir que todas as tabelas tenham uma chave primária definida ou que uma coluna tenha uma restrição exclusiva definida.
Regra: Nomeação de objetos de usuário (nomeação de objetos de usuário)
detecta objetos de usuário nomeados com o prefixo sp_, xp_ ou fn_ para evitar conflitos de nomenclatura com objetos internos do SQL Server. Se o SQL Server descobrir que o procedimento armazenado tem o prefixo sp_, ele primeiro consultará o procedimento armazenado no banco de dados mestre, o que afeta o desempenho.
Portanto, as seguintes diretrizes devem ser seguidas:
Não utilize o prefixo sp_ para nomear procedimentos armazenados definidos pelo usuário;
não utilize o prefixo xp_ para nomear procedimentos armazenados estendidos definidos pelo usuário;
não utilize o prefixo fn_ para nomear funções definidas pelo usuário
;.
Na verdade, você pode nomeá-lo usando prefixos como usp_, uxp_ ou ufn_, e u significa definido pelo usuário.
(2)
Regra
T-SQL
: A lista de colunas FOR UPDATE do cursordetecta a cláusula FOR UPDATE em procedimentos armazenados, funções, visualizações e gatilhos. Quando um cursor define uma cláusula FOR UPDATE, é recomendado fornecer colunas explícitas. FOR UPDATE é usado para definir colunas atualizáveis no cursor. Se OF nome_da_coluna for fornecido, somente as colunas listadas poderão ser modificadas. Se nenhuma lista de colunas for especificada, todas as colunas poderão ser atualizadas, a menos que a opção de simultaneidade READ_ONLY seja especificada. O SQL Server pode otimizar operações com base em colunas especificadas.
Regra: Cursor Usage
verifica se a capacidade de atualização do cursor está definida corretamente em procedimentos armazenados, funções, visualizações e gatilhos. A falha será reportada nas seguintes situações:
quando um cursor não define a cláusula FOR UPDATE, mas é atualizado através do cursor;
quando um cursor define a cláusula FOR UPDATE, mas não é atualizado através do cursor;
Porém, geralmente tentamos evitar o uso do cursor do lado do servidor, pois ele ocupa recursos de memória do servidor e afeta o desempenho do SQL Server. Consultas aninhadas ou instruções WHILE podem ser usadas em vez do cursor. Mesmo se você usar cursor, você deve prestar atenção na definição de algumas opções de cursor, como FAST_FORWARD.
Regra: Criação Explícita de Índice
É recomendado usar CLUSTERED ou NONCLUSTERED para criar explicitamente o índice.
Regra: INSERT Column List
exige que, ao usar INSERT, a lista de colunas seja fornecida explicitamente para melhorar a capacidade de manutenção do código.
Regra: A configuração de gatilhos aninhados
detecta gatilhos que não são acionados devido a problemas de configuração com gatilhos aninhados. Este é relativamente raro, então postei diretamente.
Quando a opção de configuração 'gatilhos aninhados' é definida como 0, qualquer gatilho AFTER definido em tabelas/visualizações atualizadas dentro de um gatilho INSTEAD OF não é acionado. Esta regra:
1) Verifica o valor da opção de configuração e sai se não for 0.
2) Verifica todos os gatilhos INSTEAD OF e gera uma lista de tabelas/visualizações sendo alvo de DML de dentro de um gatilho
3) Verifica se algum dos alvos DML identificados tem gatilhos AFTER definidos neles
4) Relata não conformidade para qualquer um desses gatilhos
.caso.
Regra: A opção NOCOUNT em Triggers
detecta triggers e garante que SET NOCOUNT ON seja escrito na frente dos triggers.
O SQL Server enviará uma mensagem 'concluído' após cada instrução ser executada. Essas informações podem fazer com que o aplicativo que aciona o gatilho tenha algumas consequências indesejadas. Portanto, é um bom hábito de design adicionar SET NOCOUNT ON na frente do gatilho.
Claro, é recomendado adicionar SET NOCOUNT ON na frente dos procedimentos e funções armazenados. Dessa forma, o número de linhas afetadas pela execução de uma série de comandos SQL não será transmitido de volta ao cliente, reduzindo o tráfego da rede e melhorando o desempenho.
Regra: Comparações NULL
detecta comparações de igualdade ou desigualdade envolvendo constantes NULL em procedimentos armazenados, funções, visualizações e gatilhos. Recomenda-se definir ANSI_NULLS como ON e usar a palavra-chave IS para comparar constantes NULL.
Regra: Resultados em acionadores
verifica os acionadores para garantir que os acionadores não tenham dados retornados ao chamador. Portanto, não é recomendado usar as seguintes instruções em gatilhos:
Instrução PRINT
SELECT (sem atribuição ou cláusula INTO)
FETCH (sem atribuição)
Regra: O escopo das transações
detecta o intervalo da transação em procedimentos armazenados e gatilhos. Recomenda-se que o início e o fim da transação estejam dentro da mesma estrutura T-SQL.
De modo geral, tente restringir ao máximo o escopo da transação para evitar consumir muitos recursos e afetar o desempenho do SQL Server.
Regra: SELECT *
detecta o uso de SELECT * em procedimentos armazenados, funções, visualizações e gatilhos. Embora SELECT * seja mais conveniente, reduzirá a capacidade de manutenção do programa. Alterações na tabela ou visualização podem causar erros ou alterações de desempenho.
Portanto, é recomendado especificar explicitamente a lista de campos após a instrução SELECT.
Regra: SET Options
detecta o uso das seguintes instruções SET em procedimentos armazenados e gatilhos.
Recomenda-se que as seguintes opções sejam definidas como ON:
ANSI_NULLS
ANSI_PADDING
ANSI_WARNINGS
ARITABORT
CONCAT_NULL_YIELDS_NULL
QUOTED_IDENTIFIER
recomenda que as seguintes opções sejam definidas como OFF:
NUMERIC_ROUNDABOUT
Regra: Uso de tabela temporária
detecta o uso de tabelas temporárias em procedimentos armazenados e acionadores. Ao criar uma tabela temporária, CREATE INDEX precisa ser criado e, após a conclusão do uso, a tabela temporária precisa ser liberada.
Como as tabelas temporárias gerarão um grande número de operações de E/S de disco, é recomendável usar variáveis TABLE para substituir o uso de tabelas temporárias.
Porém, devido às limitações de execução simultânea e manutenção de informações estatísticas, tabelas temporárias ainda são recomendadas quando uma grande quantidade de dados é inserida em tabelas temporárias.
Regra: TOP sem ORDER BY
detecta a falta de instruções ORDER BY TOP em procedimentos armazenados, funções, visualizações e gatilhos. Ao usar a instrução TOP, é recomendável especificar as condições de classificação. Caso contrário, os resultados produzidos dependerão do plano de execução do SQL e levarão a um comportamento inesperado.
Regra: O uso de tabelas/visualizações qualificadas de esquema
detecta se o proprietário é especificado quando tabelas e visualizações são referenciadas em procedimentos armazenados, funções, visualizações e gatilhos. Embora ao fazer referência a um objeto específico no SQL Server, você não precise especificar servidor, banco de dados e proprietário (esquema), o que significa que você não precisa do problema de server_name.database_name.owner_name.***, mas o SQL Server recomenda que pode ser usado em procedimento armazenado, função. Ao fazer referência a uma tabela ou visualização em uma visualização ou gatilho, é melhor especificar o proprietário da tabela ou visualização.
Quando o SQL Server consulta um objeto de tabela/exibição sem um proprietário especificado, ele primeiro consulta o proprietário padrão e, em seguida, dbo. Isso resultará em custos operacionais adicionais para o produto SQL Server. Ao especificar o proprietário, você pode melhorar o desempenho do SQL Server. (Primeira vez que ouvi esta afirmação)
4.
URL de download de documentos de referência e ferramentas de recursos relacionados:
de download de vídeo: