Presentación dada en el SQL Saturday El Salvador, sobre aquellos errores comunes que normalmente cometemos cuando administramos bases de datos SQL Server.
SQL Saturday 254 10- Cosas que no se deben de hacer en una BD
1. 10 Cosas que NO debes de hacer
en SQL Server
Prácticas comunes que no necesariamente
benefician al motor de base de datos
2. Expositor
Ing. Adrián Miranda Cordero
Certificaciones: MCDBA, MCSE, MCITP,
MCSA, MCTS, MCT, MCP
12 años de experiencia como DBA.
Apasionado de la arquitectura de Base Datos,
Continuidad Operativa, la Tecnología, el
Futbol y el Basketball
6. Introducción
“A partir de este momento le informo que usted es
el DBA de la Compañía. Felicidades !!!”
7. Los errores comunes
• DBA’s accidentales
• Poca planificación, regulación, establecimiento
de políticas y procedimientos
• Paradigmas en torno a SQL Server
• Poca capacitación, entrenamiento propio, mal
asesoramiento
• Aplicación de malas prácticas
• Mal desempeño del motor de base de datos
9. # 1. Instalación de SQL Server
• SQL Server requiere de planeación
• Requerimientos de hardware, software,
negocio, escalabilidad
• Ubicación de archivos (Binarios, y
archivos de base de datos)
• Instancia default? O nombrada?
• Cuentas de servicio
• Selección de características a instalar
• Usuarios con privilegios de
administración
11. # 1. Instalación de SQL Server (Mitigación)
• Tenga claros los requerimientos
• Escalabilidad
• Formato de discos
• Framework
• Windows Installer
• Versión y Edición
• Check List Operativo
• Cuentas de Servicio
• Ubicación de archivos
• Documentación
12. # 2. Cuentas de Servicio
Se debe de crear una cuenta de servicio para cada servicio
de SQL Server. No se recomienda asignar cuentas locales
de Windows o utilizar Local System Account para inicializar
los servicios de SQL Server.
13. # 3. Obviar la Seguridad
El error común es pensar “La seguridad la dejo para último
cuando ya tenga toda la aplicación resuelta.”
14. # 4. No configurar SQL Server
SQL Server va a funcionar, pero NO va funcionar BIEN
Memoria, Fill Factor, Ad Hoc Queries, entre otros
15. # 5. Pensar en respaldos y no en
recuperación
Mas que una excelente estrategia de respaldos debemos
de preocuparnos por una excelente estrategia de
recuperación. Asegurarnos que los respaldos que estamos
realizando estén bien.
16. # 6. Sobre indexamiento
Muchos índices significa mal rendimiento, es mejor tener
índices que cubran la mayoría de consultas en mi base de
datos que crear un índice por cada consulta realizada
17. # 7. Truncar el Log de Transacciones
El Truncar el Log de Transacciones impide la recuperación de
la base de datos a un momento en el tiempo.
Implica restaurar utilizando respaldos “viejos” y esto lleva a
pérdida de datos.
18. # 8. Uso del DBCC Checkdb
Imagen tomada del sitio www.sqlskills.com
19. # 8. Uso del DBCC Checkdb
Importante para detectar problemas de corrupción en páginas
de datos. Chequeo Lógico y Físico.
No realiza bloqueos
Valida la consistencia en catálogos, tablas, índices,
Filestream, Service Broker
Ofrece reparación con posibilidad de pérdida de datos
20. # 8. Uso del DBCC Checkdb
Opción Descripción
PHYSICAL_ONLY
Solo realiza un chequeo físico con menos
overhead
NOINDEX
No realiza un chequeo lógico de los índices
nonclustered
EXTENDED_LOGICAL_CHECKS
Realiza un chequeo lógico adicional de
vistas indexadas, índices espaciales e
índices XML
TABLOCK
Utiliza bloqueos en lugar de database
snapshots
ALL_ERRORMSGS
Retorna todos los errores en lugar de los
primeros 200
NO_INFOMSGS
Retorna solo números de error y no su
descripción
ESTIMATEONLY
Estima la cantidad de espacio de tempdb
que es requerida para la ejecución.
22. # 9. Shrink sobre los datos
Evitar al máximo, fragmenta la base de datos
Obliga a desfragmentar los índices
Solo se utiliza en casos estrictamente necesarios
23. # 10. Experimentar en ambientes de
producción
Aplicación de Service Pack, Hotfixes
Cualquier prueba de scripts, respaldos, recuperaciones,
debe de hacerse en un ambiente de pruebas
24. Otros Recursos
SQL Server : www.Microsoft.comsqlserver
Blog : www.adrian-miranda-gpi.blogspot.com
Presentaciones :
www.slideshare.netadriamiranda
Correo: Amiranda@gpilatam.com
Recordar seleccionar la versión de SQL Server Correcta.
Demo de creación de un esquema, creación de un objeto, denegar el acceso al esquema y no al objeto y serie de objetos. Mencionar el tema de la facilidad de administración.
Mejor aún funciona increíblemente mejor si solo lo utilizamos para insertar, borrar, modificar y consultar.
Physical integrity: The data pages are written to the physical storage as SQL Server® requested and can also be read correctly. Logical integrity: The data within the pages is logically correct. For example, every index entry points to the correct data row and every data row is referenced by an index entry.
Physical integrity: The data pages are written to the physical storage as SQL Server® requested and can also be read correctly. Logical integrity: The data within the pages is logically correct. For example, every index entry points to the correct data row and every data row is referenced by an index entry.
Physical integrity: The data pages are written to the physical storage as SQL Server® requested and can also be read correctly. Logical integrity: The data within the pages is logically correct. For example, every index entry points to the correct data row and every data row is referenced by an index entry.
Mejor aún funciona increíblemente mejor si solo lo utilizamos para insertar, borrar, modificar y consultar.