En esta sesión explicaremos retos a los que nos hemos enfrentado en las migraciones realizadas durante el último año: consolidaciones, fases en los proyectos, mediciones de resultados antes y después, etc. El objetivo de la sesión es que los asistentes puedan llevarse ideas a sus empresas y no tengan que plantearse problemas y retos por los que ya hemos pasado nosotros
Experiencias en Migraciones a SQL Server 2008 en el último año
1. REL-301
Experiencias en migraciones a SQL
Server 2008 R2 en el último año
Enrique Catalá Rubén Garrigos Enrique Puig
Mentor Mentor DPA
MCT – MCITP – MCTS – MAP 2010 MCAD – MCSD – MCTS – MCT – MCITP – MCTS
MCT - MCITP
ecatala@solidq.com rgarrigos@solidq.com epuig@solidq.com
2. Agenda
α Definiciones
α Proceso de migración
α Replicación
α Seguridad
α DTs
3. Definiciones
α Actualización (o actualización in-place):
β Se actualiza una instalación existente manteniendo los datos
β El nombre de instancia permanece inalterado
β Proceso automatizado
α Migración (o migración side-by-side):
β Se inicia con una nueva instalación
β La nueva & vieja instancia permanecen side-by-side
β Los objetos se copian de la vieja a la nueva instancia
β Proceso manual
5. Proceso de migración
Fase de actualización in-place
Punto de no
La instancia retorno
todavía está
disponible
Redirigir Ejecución de
Instalar los servicios a Adjuntar bd scripts de
binarios de Reiniciar el
nuevos de recursos migración de
Instalar SQL Server servicio
binarios SQL Agent y
prerequisitos 2008 R2 Replicación
Iniciar Parar el
Parar el Iniciar
Comprobar servisio en servicio Desinstalar
servicio actualización
blockers de modo binarios
usuario de todas las
actualización BDs “viejos”
unico
La instancia
ya no está
disponible La instancia
Aquí comienza la pasa a estar
disponibilidad disponible
parcial
7. Tareas pre-migracion
Análisis compatibilidad
α Asistente de migración (Upgrade Advisor) para analizar
β Modelo relacional
β Trazas capturadas
β Scripts TSQL
α Que no analiza el asistente de migración
β Cambios en tablas de sistema
β Código dinámico
γ Ojo con openrowsets, openquery, linked servers,…
β Team System al rescate
γ Capturar la actividad durante el proceso
8. Tareas pre-migracion
Análisis de resultados
α Analizar traza nueva con DTA
β Revisión de DMVs de índices
α Contrastar las mediciones entre distintas versiones
β Trazas Profiles anterior vs. Trazas profiler nuevo
β Perfmon anterior vs. perfmon nuevo
α Fase iterativa si surgen incompatibilidades que hay que
arreglar en aplicaciones
β Considerar nuevas funcionalidades transparentes…
α Conclusión: adelante o no convence
10. Migración
El dia D
α Debería ser la fase menos traumática
β Ya lo hemos probado anteriormente
β Estamos seguros que todo funciona
α No dejar fuera procesos que podrían ser sospechosos
β Procesos con servidores externos
α Aquí debemos llegar con estimación de tiempo de parada
11. Tareas post-migracion
Comparación de coste-beneficio
•Spatial Support
•Filestream Support
•Hierarchy Id Support
Cambios significantes
•CDC* & Change Tracking en aplicación,
•LINQ Support
•Entity Framework Support operacionales o de
•ADO.NET Data Services Support
desarrollo
•Policy Based Management (DMF)
•Performance Data Collection
•Enhanced date and time support
Cambios
•Transact-SQL enhancements
moderados en
•Sparse column support aplicacion,
•Service Broker enhancements operacionales o
•SSIS / SSRS / SSAS enhancements* desarrollo
•Data/Backup Compression Cambios
•Transparent Data Encryption
•Resource Governor menores
•Filtered Indexes/Statistics
•Query Optimizer / Storage Engine enhancements
•Enhanced SQL Server Audit
•SSRS/SSAS scalability improvements
12. Tareas post-migracion
Post migración
α Aplicación de plan estratégico de seguridad
α Recreación de trabajos de mantenimiento nocturnos
β Proceso dinámico de desfragmentacion
α Aplicación de compresión
α Aplicación de UCP
α Análisis y creación de índices faltantes
α Chequeo de salud en el nuevo entorno
β SQLNetwork Stress
β Análisis de esperas de servidor
β Inicio de tunning a bajo nivel
17. Actualización de Replicación
Distribuidor puede ser Subscriptores
cualquier versión que sea Actualizables a una
mayor o igual que la publicación transaccional
versión del Publicador de SQL Server 2008 R2
Publicador puede ser puede ser cualquier
cualquier versión que versión mayor o igual que
sea menor o igual SQL Server 2000 SP4
que la versión del
Distribuidor
Distribuidor
Publicador Subscriptor
Subscriptor a una publicación de
mezcla puede ser cualquier
versión menor o igual que la
versión del Publicador
18. Escenario
α Migración de SQL Server 2008 a 2008 R2
β Migración mediante Database Mirroring
α Origen y destino en distintos CPDs
β Cambio publicador: CPD1_PUB CPD2_PUB
β Cambio distribuidor: CPD1_DIST CPD2_DIST
β Cambio subscriptor: CPD1_SUBS CPD2_SUBS
α Replicación de volumen considerable
β Minimizar el downtime de la réplica
β Reinicialización réplica: > 24 horas
β Latencia tolerable baja
19. Propuesta
α Mantener los datos actualizados en los dos CPDs
α Republicación
β CPD1_PUB CPD1_DIST CPD1_SUBS
β CPD1_SUBS CPD2_DIST CPD2_SUBS
α Scripts de republicación copiados y adaptados
β Cambio de nombres de servidores
β Credenciales y permisos
α Scripts de publicación y subscripciones finales
β Cambio de nombres de servidores
β Credenciales y permisos
β Modo de sincronización inicial manual
γ sp_addsubscription @sync_type = ‘replication support only’
20. Puesta en marcha
α Asegurarnos que el estado de la sincronización es correcto
α Si tenemos N publicaciones, crearlas en serie
β Problemas de interbloqueos con los procedimientos
α Primera fase: regeneración
β Habilitar la base de datos para replicación (sp_replicationdboption)
β Añadir un logreader para la base de datos (sp_addlogreader_agent)
β Crear las publicaciones (sp_addpublication)
β Añadir los artículos (sp_addarticle/sp_articlecolumn)
β Añadir las subscripciones (sp_addsubscription)
α Con varias publicaciones y 300 tablas publicadas en total
el script ejecuta en serie en ~10 segundos
21. Puesta en marcha
α Segunda fase: Resincronización
β Añadir los agentes de distribución para las subscripciones PUSH
(sp_addpushsubscription_agent)
β Permitir el acceso a los usuarios correspondientes
(sp_grant_publication_access)
β Arrancar todos los agentes de la réplica (sp_startjob)
β Limpieza de publicaciones/subscripciones antiguas y de
republicación (sp_removedbreplication, etc.)
α Tercera fase: Mantenimiento
β Utilizar @sync_type = ‘replication support only’ tiene consecuencias
β Si añadimos un nuevo artículo a la publicación, es necesario
regenerarlo manualmente en los subscriptores.
β Los nuevos objetos deben tener un estado inicial sincronizado.
β Si modificamos las columnas publicadas, tenemos que eliminar las
columnas manualmente de los subscriptores y regenerar los
procedimientos almacenados (sp_scriptpublicationcustomprocs)
22. Puesta en marcha
α Integración con el proceso de migración
β Configurar Database Mirroring en modo síncrono
β Deshabilitar el acceso de las aplicaciones.
β Realizar el Database Mirroring failover al nuevo CPD.
β Ejecución script primera fase de las réplicas
β Habilitar el acceso de las aplicaciones.
β Ejecución del script segunda fase de las réplicas
β Monitorización y ajustes
24. Cambios en seguridad
α La seguridad por defecto en SQL Server 2005+ es más
estricta que en versiones anteriores
α Una migración sin tener en cuenta estos cambios puede
traer problemas inesperados
α Problemas típicos
β Visibilidad de metadatos
β Passwords inseguros
β Cross-Database Ownership Chaining
β Esquemas <> owners
25. Visibilidad de metadatos
α Es típico al migrar encontrar con problemas debido al
cambio en la visibilidad en los metadatos
β Antes los metadatos de todos los objetos eran visibles para public
β Catálogo, vistas de compatibilidad, vistas de sistema, etc.
α Efectos de la limitación
β No debemos presuponer que con el rol public tenemos acceso
β Consultas a vistas de sistema pueden devolver vacío o un
subconjunto de filas
β Funciones que devuelven metadatos pueden devolver NULL
α Capas de acceso a datos
α Generadores de código
26. Alternativas
α GRANT VIEW DEFINITION TO public
α GRANT VIEW ANY DEFINITION TO public
α GRANT VIEW DEFINITION ON SCHEMA/OBJECT:: TO public
α GRANT VIEW DEFINITION ON USER :: A TO B
α GRANT VIEW SERVER STATE
α GRANT VIEW ANY DATABASE
α Encapsular con EXECUTE AS
α Trace flags
β 4616 Metadatos a nivel de servidor visibles para application roles.
β 3625 Reduce la visibilidad de metadatos en los mensajes de error
27. Cross-Database Ownership
Chaining
α Al habilitarlo se mantiene la cadena de ownership entre
bases de datos diferentes
β Potencial agujero de seguridad
α Base de datos A y B con Cross-Database Ownership
Chaining habilitado
α Usuario U, db_owner de A crea un objeto en A
α El usuario U accede a través de la vista/objeto creado a la
base de datos B
28. Política de passwords
α Passwords en blanco
α Passwords demasiado sencillos, cortos, etc.
α Passwords utilizados previamente
α Logins Windows vs SQL Server
β Usuarios repetidos Problemas al consolidar
α Passwords “perdidos”
β SQL Server almacena solo el HASH
β SQL Server 6.5 & 7.0 Snefru sobre ASCII y UNICODE
β SQL Server 2000 SHA1, original y en mayúsculas
β SQL Server 2005 SHA1, solo original
α Trace flags
β 4606 Deshabilita «Enforce Password Policy» para logins de SQL
30. DTS
Migrando a SSIS
α SSIS novedad SQL Server2005
β Cambio radical
β Reescritura de producto
α Funcionalidades «on the box» amplias
β Tareas predefinidas
γ ETL
γ DBAs
γ WMI
γ Otras…
α Muy común en migraciones
31. ¿Cómo migrar?
DTS a SSIS
α Reescritura completa
β Diseño desde cero
β Aprovechamiento de nuevas características y funcionalidades
β ¿Cuántos DTS tengo que migrar?¿3, 4, 10, 100?
γ Puede ser tedioso
γ ¿Se podría automatizar?
α Asistente de migración
β No es 100% fiable
β Compatibilidad DTS
β Ejecutar los DTS desde versiones superiores
β No escalable
α Herramientas de terceros
32. Asistente de migración
No es tan automático
α Permite realizar migraciones masivas
α Resultados no son 100% fiable
β No convierte todos los procesos
γ Utiliza la tarea de ejecución de DTS
γ Soporte de versiones superiores
γ Transformaciones
δ vbasic script
δ No sabe convertirlas al lenguaje de expresiones de SSIS
34. Consejos
Se precavido
α Un sistema actualizado requiere mucha atención
α Anota benchmarks antes de la actualización
β Funcional, rendimiento, Stress
α Tiempo necesario para la actualización
β Ninguna de las herramientas de actualización muestra “tiempo
restante…”
β Revisa el Setup log para actualizaciones in-place
β Realiza pruebas de actualización
α Piensa en planes de “vuelta atrás”
α Identifica problemas de compatibilidad hacia atrás
35. Consejos
Se todavia más precavido
α Capturar actividad que cubra el uso de tu sistema
β Trazas de SQL Profiler
β Monitor de rendimiento
β Si es posible Team System para preparar carga de la aplicación
actual
β Procesos no tan habituales: fin de mes, cierre de ejercicio
Y recuerda, una migración se sabe que va a ser exitosa, antes
incluso de llevarse a cabo
36. Recursos
α Ebook SolidQ en la sección ebooks de la web de SolidQ
β «Planificando la migración de SQL Server 2000-2005 a SQL Server
2008»
α Guia de referencia publicada por SolidQ en Microsoft
β Buscar en Bing:
"SQL Server 2008 R2 Upgrade Technical Reference Guide"
37. Agenda
α Definiciones
α Proceso de migración
α Replicación
α Seguridad
α DTs
38. Si quieres disfrutar de las mejores sesiones de
nuestros mentores de España y Latino América,
ésta es tu oportunidad.
http://summit.solidq.com/madrid/