10 Cosas que NO debes de hacer
en SQL Server
Prácticas comunes que no necesariamente
benefician al motor de base de datos
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
Organización
Patrocinadores / Sponsors
 GOLD
 SILVER
 BRONCE
 Personal/Swag
Agenda
 Introducción
 El Porqué de los errores comunes?
 Top 10
 Conclusiones
Introducción
“A partir de este momento le informo que usted es
el DBA de la Compañía. Felicidades !!!”
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
Top 10
# 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
# 1. Instalación de SQL Server
# 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
# 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.
# 3. Obviar la Seguridad
El error común es pensar “La seguridad la dejo para último
cuando ya tenga toda la aplicación resuelta.”
# 4. No configurar SQL Server
 SQL Server va a funcionar, pero NO va funcionar BIEN
 Memoria, Fill Factor, Ad Hoc Queries, entre otros
# 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.
# 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
# 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.
# 8. Uso del DBCC Checkdb
Imagen tomada del sitio www.sqlskills.com
# 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
# 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.
# 8. Uso del DBCC Checkdb
# 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
# 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
Otros Recursos
 SQL Server : www.Microsoft.comsqlserver
 Blog : www.adrian-miranda-gpi.blogspot.com
 Presentaciones :
www.slideshare.netadriamiranda
 Correo: Amiranda@gpilatam.com
Muchas Gracias

SQL Saturday 254 10- Cosas que no se deben de hacer en una BD

  • 1.
    10 Cosas queNO debes de hacer en SQL Server Prácticas comunes que no necesariamente benefician al motor de base de datos
  • 2.
    Expositor  Ing. AdriánMiranda 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
  • 3.
  • 4.
    Patrocinadores / Sponsors GOLD  SILVER  BRONCE  Personal/Swag
  • 5.
    Agenda  Introducción  ElPorqué de los errores comunes?  Top 10  Conclusiones
  • 6.
    Introducción “A partir deeste 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
  • 8.
  • 9.
    # 1. Instalaciónde 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
  • 10.
    # 1. Instalaciónde SQL Server
  • 11.
    # 1. Instalaciónde 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. Cuentasde 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. Obviarla Seguridad El error común es pensar “La seguridad la dejo para último cuando ya tenga toda la aplicación resuelta.”
  • 14.
    # 4. Noconfigurar SQL Server  SQL Server va a funcionar, pero NO va funcionar BIEN  Memoria, Fill Factor, Ad Hoc Queries, entre otros
  • 15.
    # 5. Pensaren 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. Sobreindexamiento 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. Truncarel 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. Usodel DBCC Checkdb Imagen tomada del sitio www.sqlskills.com
  • 19.
    # 8. Usodel 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. Usodel 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.
  • 21.
    # 8. Usodel DBCC Checkdb
  • 22.
    # 9. Shrinksobre 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. Experimentaren 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  SQLServer : www.Microsoft.comsqlserver  Blog : www.adrian-miranda-gpi.blogspot.com  Presentaciones : www.slideshare.netadriamiranda  Correo: Amiranda@gpilatam.com
  • 25.

Notas del editor

  • #12 Recordar seleccionar la versión de SQL Server Correcta.
  • #14 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.
  • #19 Mejor aún funciona increíblemente mejor si solo lo utilizamos para insertar, borrar, modificar y consultar.
  • #20 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.
  • #21 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.
  • #22 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.
  • #23 Mejor aún funciona increíblemente mejor si solo lo utilizamos para insertar, borrar, modificar y consultar.