La herramienta Best Practices Analyzer para Microsoft SQL Server 2000 es una herramienta de administración de bases de datos desarrollada por el equipo de desarrollo de Microsoft SQL Server que le permite detectar si la base de datos diseñada sigue las pautas de mejores prácticas para la operación y administración de SQL Server. Se reconoce que estas pautas ayudan a mejorar el rendimiento y la eficiencia de la base de datos y facilitan el mantenimiento de las aplicaciones.
2. Comience a usar el Analizador de mejores prácticas de SQL Server.
Una vez completada la instalación, habrá un documento de Word de la Guía del usuario del Analizador de mejores prácticas de SQL Server. Se explica claramente cómo usarlo. Los pasos básicos son los siguientes:
(1) Iniciar sesión. en SQL BPA
(2) Agregar análisis/instancia de SQL Server detectada
. Debe ingresar aquí el nombre de la instancia de SQL Server. El nombre descriptivo se utiliza para asociarlo con el grupo de mejores prácticas creado más adelante (solo manténgalo igual que el nombre de la instancia de SQL Server). ). El valor predeterminado de la Lista de bases de datos es *, lo que significa que contiene todas las bases de datos de la instancia actual de SQL Server. Sin embargo, BPA omitirá la detección de bases de datos como 'master', 'tempdb', 'msdb', 'pubs' y 'northwind'.
(3) Para administrar grupos de mejores prácticas,
primero debe crear un grupo de mejores prácticas, que en realidad combina algunas reglas y las asocia con la instancia de SQL Server ingresada anteriormente.
(4) Analizar la instancia de SQL Server
y mover el Grupo de Mejores Prácticas previamente creado a la lista de Grupos de Mejores Prácticas a Ejecutar, para que pueda ejecutarse de acuerdo con las Reglas previamente definidas y generar un Informe para brindar sugerencias y pautas de mejora.
3. Creo que las reglas incluidas en SQL BPA v1.0
son el punto clave, porque solo comprendiendo estas pautas de mejores prácticas para la operación y administración de SQL Server podemos intentar seguir estas reglas al diseñar bases de datos y escribir scripts T-SQL. mejorar el rendimiento y la eficiencia de SQL Server y las aplicaciones.
De hecho, todas las reglas están aquí (versión en inglés) file:///C:/Program%20Files/Microsoft%20SQL%20Server%20Best%20Practices%20Analyzer/html/RuleInformation.html#_Rule:_Explicit_Index_Creation . use SQL BPA se instala en la ruta predeterminada. Si cambia la ruta de instalación, no estará aquí.
Aquí hay algunas reglas que me interesan:
(1)
Reglas de diseño de bases de datos: Tablas sin claves primarias o restricciones únicas
Verifique la base de datos para asegurarse de que todas las tablas tengan una clave primaria definida o que una columna tenga una restricción única definida.
Regla: La denominación de objetos de usuario (nombramiento de objetos de usuario)
detecta objetos de usuario nombrados con el prefijo sp_, xp_ o fn_ para evitar conflictos de nombres con los objetos integrados de SQL Server. Si SQL Server encuentra que el procedimiento almacenado tiene el prefijo sp_, primero consultará el procedimiento almacenado en la base de datos maestra, lo que afecta el rendimiento.
Por lo tanto, se deben seguir las siguientes pautas:
No use el prefijo sp_ para nombrar procedimientos almacenados definidos por el usuario;
no use el prefijo xp_ para nombrar procedimientos almacenados extendidos definidos por el usuario;
no use el prefijo fn_ para nombrar funciones definidas por el usuario; .
De hecho, puede nombrarlo usando prefijos como usp_, uxp_ o ufn_, y u significa definido por el usuario.
(2)
Regla
T-SQL
: la lista de columnas FOR UPDATE del cursordetecta la cláusula FOR UPDATE en procedimientos almacenados, funciones, vistas y activadores. Cuando un cursor define una cláusula FOR UPDATE, se recomienda proporcionar columnas de columnas explícitas. FOR UPDATE se utiliza para definir columnas actualizables en el cursor. Si se proporciona OF nombre_columna, solo se permite modificar las columnas enumeradas. Si no se especifica ninguna lista de columnas, todas las columnas se pueden actualizar a menos que se especifique la opción de simultaneidad READ_ONLY. SQL Server puede optimizar operaciones basadas en columnas específicas.
Regla: el uso del cursor
comprueba si la capacidad de actualización del cursor está definida correctamente en los procedimientos almacenados, funciones, vistas y activadores. Se informará una falla en las siguientes situaciones:
cuando un cursor no define la cláusula FOR UPDATE, pero se actualiza a través del cursor;
cuando un cursor define la cláusula FOR UPDATE, pero no se actualiza a través del cursor;
Sin embargo, generalmente intentamos evitar el uso del cursor del lado del servidor, porque ocupa recursos de memoria del servidor y afecta el rendimiento de SQL Server. Se pueden utilizar consultas anidadas o declaraciones WHILE en lugar del cursor. Incluso si usa el cursor, debe prestar atención a definir algunas opciones del cursor, como FAST_FORWARD.
Regla: creación explícita de índice.
Se recomienda utilizar CLUSTERED o NONCLUSTERED para crear explícitamente el índice.
Regla: INSERTAR lista de columnas
requiere que al usar INSERT, la lista de columnas se proporcione explícitamente para mejorar la capacidad de mantenimiento del código.
Regla: La configuración de desencadenadores anidados
detecta desencadenadores que no se activan debido a problemas de configuración con desencadenadores anidados. Este es relativamente raro, así que lo publiqué directamente.
Cuando la opción de configuración 'disparadores anidados' se establece en 0, cualquier disparador DESPUÉS definido en tablas/vistas actualizadas dentro de un disparador EN LUGAR DE no se activa. Esta regla:
1) Comprueba el valor de la opción de configuración y sale si no es 0.
2) Escanea todos los activadores EN LUGAR DE y genera una lista de tablas/vistas que son objetivo de DML desde dentro de un activador.
3) Comprueba si alguno de los objetivos DML identificados tiene activadores DESPUÉS definidos en ellos.
4) Informa el incumplimiento de cualquiera de ellos
.caso.
Regla: La opción NOCOUNT en Activadores
detecta los activadores y garantiza que SET NOCOUNT ON se escriba delante de los activadores.
SQL Server enviará un mensaje de "hecho" después de ejecutar cada declaración. Esta información puede hacer que la aplicación que activa el disparador tenga algunas consecuencias no deseadas. Por lo tanto, es un buen hábito de diseño agregar SET NOCOUNT ON delante del disparador.
Por supuesto, se recomienda agregar SET NOCOUNT ON delante de los procedimientos y funciones almacenados. De esta forma, el número de filas afectadas por la ejecución de una serie de comandos SQL no se transmitirán de vuelta al cliente, reduciendo el tráfico de la red y mejorando el rendimiento.
Regla: Comparaciones NULL
detecta comparaciones de igualdad o desigualdad que involucran constantes NULL en procedimientos almacenados, funciones, vistas y activadores. Se recomienda configurar ANSI_NULLS en ON y utilizar la palabra clave IS para comparar constantes NULL.
Regla: Resultados en activadores
comprueba los activadores para garantizar que no devuelvan datos a la persona que llama. Por lo tanto, no se recomienda utilizar las siguientes declaraciones en los desencadenadores:
Declaración PRINT
SELECT (sin asignación o cláusula INTO)
FETCH (sin asignación)
Regla: El alcance de las transacciones
detecta el rango de transacciones en los procedimientos almacenados y los activadores. Se recomienda que el inicio y el final de la transacción estén dentro de la misma estructura T-SQL.
En términos generales, intente limitar el alcance de la transacción tanto como sea posible para evitar consumir muchos recursos y afectar el rendimiento de SQL Server.
Regla: SELECT*
detecta el uso de SELECT* en procedimientos almacenados, funciones, vistas y disparadores. Aunque SELECT * es más conveniente, reducirá la capacidad de mantenimiento del programa. Los cambios en la tabla o vista pueden provocar errores o cambios en el rendimiento.
Por lo tanto, se recomienda especificar explícitamente la lista de campos después de la instrucción SELECT.
Regla: Las opciones SET
detectan el uso de las siguientes declaraciones SET en procedimientos almacenados y activadores.
Se recomienda que las siguientes opciones estén activadas:
ANSI_NULLS
ANSI_PADDING
ANSI_WARNINGS
ARITHABORT
CONCAT_NULL_YIELDS_NULL
QUOTED_IDENTIFIER
recomienda que las siguientes opciones se establezcan en OFF:
ReglaNUMERIC_ROUNDABOUT
: Uso de tabla temporal
detecta el uso de tablas temporales en procedimientos almacenados y activadores. Al crear una tabla temporal, es necesario crear CREATE INDEX y, una vez completado el uso, es necesario liberar la tabla temporal.
Debido a que las tablas temporales generarán una gran cantidad de operaciones de E/S de disco, se recomienda utilizar variables TABLE para reemplazar el uso de tablas temporales.
Sin embargo, debido a las limitaciones de la ejecución y el mantenimiento simultáneos de información estadística, todavía se recomiendan las tablas temporales cuando se inserta una gran cantidad de datos en tablas temporales.
Regla: TOP sin ORDER BY
detecta la falta de declaraciones ORDER BY TOP en procedimientos almacenados, funciones, vistas y activadores. Al utilizar la declaración TOP, se recomienda especificar las condiciones de clasificación. De lo contrario, los resultados producidos dependerán del plan de ejecución de SQL y darán lugar a un comportamiento inesperado.
Regla: El uso de tablas/vistas calificadas por esquema
detecta si se especifica el propietario cuando se hace referencia a tablas y vistas en procedimientos almacenados, funciones, vistas y activadores. Aunque al hacer referencia a un objeto específico en SQL Server, no es necesario especificar el servidor, la base de datos y el propietario (esquema), lo que significa que no necesita el problema de nombre_servidor.nombre_base_datos.nombre_propietario.***, pero SQL Server recomienda que se puede utilizar en procedimientos almacenados, funciones. Al hacer referencia a una tabla o vista en una vista o disparador, es mejor especificar el propietario de la tabla o vista.
Cuando SQL Server consulta un objeto de tabla/vista sin un propietario especificado, primero consulta al propietario predeterminado y luego a dbo. Esto resultará en costos operativos adicionales para el producto SQL Server. Al especificar el propietario, puede mejorar el rendimiento de SQL Server. (Primera vez que escucho esta declaración)
4.
URL de descarga de documentos de referencia y herramientas de recursos relacionados:
de descarga de vídeo: