En este artículo vamos a repasar los errores de los DBA, cuyas consecuencias eran bastante perceptibles y con los que tuve que lidiar.
El propósito del artículo es evitar que los usuarios repitan estos errores. A veces, una mala experiencia es incluso más valiosa que una positiva.
- Porcentaje de incremento de archivos de base de datos
Dado que el crecimiento de archivos de la base de datos es una operación que consume muchos recursos, puede parecer que establecer este crecimiento en proporciones porcentuales puede ser una buena idea. Estoy de acuerdo en que muchas pautas recomiendan establecer un incremento fijo en MB, en lugar de un porcentaje. Sin embargo, no explican las razones. Según la práctica, no se recomienda establecer el incremento de un archivo de base de datos por encima de 1 GB, ya que MS SQL Server asignará 1 GB 2 veces en lugar de 2 GB a la vez.
Además, si asigna menos de 32 MB , tarde o temprano la base de datos simplemente se ralentizará. Por lo tanto, es mejor establecer un incremento fijo en los archivos de la base de datos de 32 a 1024 MB. Sin embargo, ¿por qué es imposible especificar el incremento de los archivos de la base de datos como un porcentaje? Resulta que tan pronto como el archivo tiene menos de 1 MB, el DBMS redondea este valor a 0 MB y deja de aumentar este archivo. Como resultado, el sistema está caído. Para saber cuánto necesitamos aumentar el archivo, simplemente realice un análisis diario para comprobar cuánto gana cada archivo en MB y establezca el número adecuado en el rango de 32 a 1024 MB. Podemos recopilar estadísticas sobre el crecimiento de los archivos de la base de datos de la siguiente manera. - Hay muchas claves foráneas para una tabla
¿Alguna vez ha intentado verificar el plan al eliminar al menos una fila de una tabla a la que hacen referencia casi cientos de otras tablas? Te sorprenderá saber cuántos bucles anidados hay. Todos ellos son controles de clave externa. Por eso, si las tablas son grandes (más de un millón de registros), es mejor deshabilitar las claves externas para una tabla en la que se eliminarán los datos. Luego, deberá eliminar todos los datos necesarios y relacionados. Después de eso, habilite las claves externas. Una situación similar ocurre con las actualizaciones y eliminaciones en cascada. Si hay muchos enlaces externos (cientos), eliminar incluso una fila puede provocar un bloqueo prolongado y muy extenso. - Muchos índices innecesarios
Muy a menudo, puede ver en las pautas que al crear claves externas, es necesario crear índices, especialmente cuando se usan estas claves para uniones. Debe verificar que se utilicen índices; de lo contrario, estos índices innecesarios solo ralentizarán las operaciones de modificación de datos. Para verificar esto, use la siguiente consulta:select DB_NAME(t.database_id) as [DBName] , SCHEMA_NAME(obj.schema_id) as [SchemaName] , OBJECT_NAME(t.object_id) as [ObjectName] , obj.Type as [ObjectType] , obj.Type_Desc as [ObjectTypeDesc] , ind.name as [IndexName] , ind.Type as IndexType , ind.Type_Desc as IndexTypeDesc , ind.Is_Unique as IndexIsUnique , ind.is_primary_key as IndexIsPK , ind.is_unique_constraint as IndexIsUniqueConstraint , t.[Database_ID] , t.[Object_ID] , t.[Index_ID] , t.Last_User_Seek , t.Last_User_Scan , t.Last_User_Lookup , t.Last_System_Seek , t.Last_System_Scan , t.Last_System_Lookup from sys.dm_db_index_usage_stats as t inner join sys.objects as obj on t.[object_id]=obj.[object_id] inner join sys.indexes as ind on t.[object_id]=ind.[object_id] and t.index_id=ind.index_id where (last_user_seek is null or last_user_seek <dateadd(year,-1,getdate())) and (last_user_scan is null or last_user_scan <dateadd(year,-1,getdate())) and (last_user_lookup is null or last_user_lookup <dateadd(year,-1,getdate())) and (last_system_seek is null or last_system_seek <dateadd(year,-1,getdate())) and (last_system_scan is null or last_system_scan <dateadd(year,-1,getdate())) and (last_system_lookup is null or last_system_lookup <dateadd(year,-1,getdate())) and t.database_id>4 and t.[object_id]>0 -- system databases are excluded
- Uso ineficiente de los recursos
A menudo se recomienda almacenar el registro de transacciones y el archivo de la base de datos en diferentes dispositivos de almacenamiento. Si usa RAID 10 con 4 o más discos SSD, entonces no tiene sentido aislar los archivos entre sí. Para una mayor velocidad, si es necesario, la base de datos tempdb se puede almacenar en un disco separado de la RAM. Además, demasiadas cantidades de RAM proporcionadas a DBMS harán que este último llene toda la memoria con planes de consulta irrelevantes. - Copias de seguridad incorrectas
Siempre es necesario no solo verificar las copias de seguridad creadas, sino también moverlas a un banco de pruebas y restaurarlas. Todo esto debe automatizarse con más notificaciones a los administradores de recuperaciones exitosas y problemáticas. - Mala tolerancia a errores
Antes de crear un clúster de dos o más servidores, debe asegurarse de que el sistema de almacenamiento de datos también sea tolerante a fallas. Si este último falla, toda la tolerancia a fallas se reducirá a cero. - Complicado diagnóstico sin comprobaciones simples
Si hay un tiempo de inactividad del sistema, primero debe verificar los registros de MS SQL Server y luego profundizar. Primero debe realizar comprobaciones simples y luego proceder a un diagnóstico complejo. - Mesas perdidas
Las tablas se pueden ampliar con datos innecesarios que deben archivarse en una base de datos separada o eliminarse. Además, las tablas ya no se pueden utilizar.
Estas son las situaciones con las que me he encontrado. Por lo tanto, me gustaría recomendar no repetir los errores anteriores.
¿Le gustaría compartir su experiencia o esos errores al administrar bases de datos? No dude en hacérmelo saber; estaré encantado de discutirlos.
