Experiencias en migraciones a SQL Server 2008 R2 en el último año

Enrique Catalá

REL-301

Mentor MCT – MCITP – MCTS – MAP 2010

ecatala@solidq.com

Enrique Puig DPA MCT – MCITP – MCTS

epuig@solidq.com

Rubén Garrigos Mentor MCAD – MCSD – MCTS – MCT - MCITP

rgarrigos@solidq.com

α 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/