Experiencias en Migraciones a SQL Server 2008 en el último año
description
Transcript of Experiencias en Migraciones a SQL Server 2008 en el último año
Experiencias en migraciones a SQL Server 2008 R2 en el último año
Enrique Catalá
REL-301
Mentor MCT – MCITP – MCTS – MAP 2010
Enrique Puig DPA MCT – MCITP – MCTS
Rubén Garrigos Mentor MCAD – MCSD – MCTS – MCT - MCITP
α Definiciones
α Proceso de migración
α Replicación
α Seguridad
α DTs
Agenda
α 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
Definiciones
Proceso de migración In-place
SQL Server 2000
Instancia: Foo
SQL Server 2008 R2
Instancia : Foo
Actualización
Proceso de migración Fase de actualización in-place
La instancia
pasa a estar
disponible
Aquí comienza la
disponibilidad
parcial
Punto de no
retorno La instancia
todavía está
disponible
La instancia
ya no está
disponible
Instalar
prerequisitos
Comprobar
blockers de
actualización
Instalar los
binarios de
SQL Server
2008 R2
Parar el
servicio
Redirigir
servicios a
nuevos
binarios
Iniciar
servisio en
modo
usuario
unico
Adjuntar bd
de recursos
Parar el
servicio
Reiniciar el
servicio
Iniciar
actualización
de todas las
BDs
Ejecución de
scripts de
migración de
SQL Agent y
Replicación
Desinstalar
binarios
“viejos”
Proceso de migración Side-by-side
Comparar
y verificar
SQL Server 2000
Instancia: Foo
SQL Server 2008 R2
Instancia : Bar
Comprobado!
α 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
Tareas pre-migracion Análisis compatibilidad
α 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
Tareas pre-migracion Análisis de resultados
α Cuidado, SSMA no cubre todos los escenarios β No te olvides openrowset, linked server, código dinámico…
Tareas pre-migracion Interdependencias
α 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
Migración El dia D
Tareas post-migracion Comparación de coste-beneficio
•Data/Backup Compression
•Transparent Data Encryption
•Resource Governor
•Filtered Indexes/Statistics
•Query Optimizer / Storage Engine enhancements
•Enhanced SQL Server Audit
•SSRS/SSAS scalability improvements
•Policy Based Management (DMF)
•Performance Data Collection
•Enhanced date and time support
•Transact-SQL enhancements
•Sparse column support
•Service Broker enhancements
•SSIS / SSRS / SSAS enhancements*
•Spatial Support
•Filestream Support
•Hierarchy Id Support
•CDC* & Change Tracking
•LINQ Support
•Entity Framework Support
•ADO.NET Data Services Support
Cambios significantes
en aplicación,
operacionales o de
desarrollo
Cambios moderados en
aplicacion, operacionales o
desarrollo
Cambios menores
α 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
Tareas post-migracion Post migración
Resultados reales Ratios de mejora en tiempos de respuesta
Resultados reales Tiempo medio de respuesta
α Aplicación de compresión en las tablas convenientes según análisis post-migración
Resultados reales Compresión
Nº filas % reducción espacio Compresión Aplicada
>50.000 >=40% PAGE
>0 <40% ROW
Replicación
Actualización de Replicación
Publicador Subscriptor
Distribuidor
Distribuidor puede ser
cualquier versión que sea
mayor o igual que la
versión del Publicador
Publicador puede ser
cualquier versión que
sea menor o igual
que la versión del
Distribuidor
Subscriptores
Actualizables a una
publicación transaccional
de SQL Server 2008 R2
puede ser cualquier
versión mayor o igual que
SQL Server 2000 SP4
Subscriptor a una publicación de
mezcla puede ser cualquier
versión menor o igual que la
versión del Publicador
α 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
Escenario
α 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’
Propuesta
α 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
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)
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
Puesta en marcha
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
Cambios en seguridad
α 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
Visibilidad de metadatos
α 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
Alternativas
α 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
Cross-Database Ownership Chaining
α 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
Política de passwords
Migración de DTS
α 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
DTS Migrando 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
¿Cómo migrar? DTS a SSIS
α 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
Asistente de migración No es tan automático
Asistente de migración. DTS a SSIS
α 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
Consejos Se 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
Consejos Se todavia más precavido
α 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"
Recursos
α Definiciones
α Proceso de migración
α Replicación
α Seguridad
α DTs
Agenda
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/