Proyecto integrador. Las TIC en la sociedad S4.pptx
Los Secretos Mas Guardados del Proceso de Actualización a Oracle 11g
1. Los Secretos Mas Guardados del Proceso
de Actualización a Oracle 11g
Valentín Leonard Tabacaru - Presales Technology Consultant
2. Agenda
Introducción
Los Secretos
Los Mitos
Conclusiones
3. ¿Cuál es el momento de migrar, y dónde?
• Actualizar a Oracle Database 10gR2?
o a Oracle Database 11g?
o directamente a Oracle Database
11.2??
¡¡¡Esta es
su elección ...!!!
4. Lifetime Support Policy
Hoy
R2
August 2012 August 2015
July 2010 July 2011 July 2013
R2
January 2009 January 2012
Sustaining Support
Premier Support Extended Support
July 2007 July 2008 July 2010
R2
t
2005
2010
2015
2002
2003
2004
2006
2007
2008
2009
2011
2012
2013
2014
2016
2017
2018
http://www.oracle.com/support/library/brochure/lifetime-support-technology.pdf
5. Actualizar a Oracle Database 11g
≥ 7.3.4
≥ 7.3.4 9.2.0.8
9.2.0.8
R2
R2
≥ 9.2.0.4
≥ 9.2.0.4
≥ 8.0.6
≥ 8.0.6
R2
R2
≥ 8.1.7.4
≥ 8.1.7.4
10.1.0.5
10.1.0.5
≥ 9.0.1.4
≥ 9.0.1.4 ≥ 10.2.0.2
≥ 10.2.0.2
R2
R2
Las flechas sin etiquetas significan que no requiere algún parche en concreto
6. Agenda
Introducción
Los Secretos
Los Mitos
Conclusiones
11. Documentación
• Guías de Actualización
+
http://download.oracle.com/docs/cd/B28359_01/server.111/b28300/toc.htm
http://download.oracle.com/docs/cd/E11882_01/server.112/e10819/toc.htm
• Note:429825.1
Complete Checklist for Manual Upgrades to 11g
• Note:837570.1
Complete Checklist for Manual Upgrades to 11g Release 2
• Note: 421191.1
Complete checklist for manual upgrades from X to Y
19. Instalación de Patch Set Update (PSU)
• Instale también los PSUs
• Note:854428.1: Introduction to Database Patch Set Updates
• Los PSUs para la base de datos incluyen:
• Arreglos y ajustes para asuntos críticos que puedan afectar a un número grande de clientes
y que ya se han demostrado como problemas
• Arreglos y ajustes Critical Patch Update (CPU)
• Los PSU para la base de datos no incluyen:
• Cambios que necesitan re-certificación
• Arreglos y ajustes que imponen cambios de configuración
• Típicamente entre 50 y 100 ajustes de nuevos bugs - cumulativos
• Garantizados para instalación en línea con RAC
• Cambian en quinto dígito del número de versión (10.2.0.4.3)
• Se lanzan 4x año (igual que los CPUs – la misma fecha)
• Plataformas:
Solaris SPARC64, Linux x86 and x86-64, HP-UX PA-RISC, HP Itanium, IBM AIX
20. Parches Recomendados para el SO
• Note:169706.1: OS Installation and Configuration
• Note: 401705.1 Linux x86, x86-64, and s390x Requirements Reference List
22. Guarde las Estadísticas de Rendimiento
• Colectar suficientes datos sobre el rendimiento antes del
upgrade es algo de máxima importancia
• Suficiente significa: Empezar como mínimo 4 semanas antes del
proceso de actualización
• Recoja estadísticas de rendimiento precisas
• En Oracle 8i/9i:
• Use STATSPACK
• Exporte el esquema PERFSTAT justo antes del upgrade
• Note:466350.1 STATSPACK before/after upgrade
• En Oracle 10g/11g:
• Use AWR
• Snapshots cada 30-60 minutos – retención: >30 días
• Exporte el AWR usando DBMS_SWRF_INTERNAL.AWR_EXTRACT
• Use los informes ADR DIFF para hacer comparación antes/después:
DBMS_WORKLOAD_REPOSITORY.AWR_DIFF_REPORT_HTML
24. Duración del Upgrade
• ¿Cuánto tardará el upgrade
en finalizar?
• Independiente de:
• Tamaño de la base de datos
• Tipos de datos utilizados
• Dependiente especialmente de:
• El número de componentes y opciones instaladas
• La validez y la actualidad de las estadísticas del diccionario de datos
• Número de sinónimos – estos se re-compilan (actualizar de 9i)
• Número de objetos en XDB
• Muy poco, pero importa si COMPATIBLE está incrementado:
• Número de datafiles
• Tamaño de los redo logs
25. Duración del Upgrade
• Acelere el proceso de actualización por:
• Truncar la tabla de auditoria SYS.AUD$
SQL> truncate SYS.AUD$;
SQL> truncate SYS.AUD$;
• Crear estadísticas de diccionario justo antes del upgrade
• Oracle 9i:
SQL> exec DBMS_STATS.GATHER_SCHEMA_STATS
SQL> exec DBMS_STATS.GATHER_SCHEMA_STATS
('SYS', options => 'GATHER',estimate_percent =>
('SYS', options => 'GATHER',estimate_percent =>
DBMS_STATS.AUTO_SAMPLE_SIZE, method_opt => 'FOR
DBMS_STATS.AUTO_SAMPLE_SIZE, method_opt => 'FOR
ALL COLUMNS SIZE AUTO', cascade => TRUE);
ALL COLUMNS SIZE AUTO', cascade => TRUE);
• Oracle 10g/11g:
SQL> exec DBMS_STATS.GATHER_DICTIONARY_STATS;
SQL> exec DBMS_STATS.GATHER_DICTIONARY_STATS;
27. Papelera de Reciclaje
• Si se actualiza desde la versión 10g o 11g, se recomienda
vaciar el recycle bin antes del upgrade.
SQL> purge DBA_RECYCLEBIN;
SQL> purge DBA_RECYCLEBIN;
28. Drop de la tabla plan
• Haga drop de la tabla SYS.PLAN_TABLE$ y del sinónimo
público PUBLIC.PLAN_TABLE
• Para más información, por favor consulte:
• Alert Note:782735.1, Note:605317.1 y Note:736353.1
• Si no, el componente “Oracle Server” puede resultar INVÁLIDO
después del upgrade
• Se aplica a actualizaciones a las versiones:
• 10.2.0.4, 11.1.0.6 y 11.1.0.7
• Asunto introducido con el paquete DBMS_SQLPA
29. Recompilar los Objetos Inválidos
• Consiga los Objetos INVÁLIDOS:
SQL> SELECT UNIQUE object_name, object_type, owner
SQL> SELECT UNIQUE object_name, object_type, owner
FROM dba_objects WHERE status='INVALID';
FROM dba_objects WHERE status='INVALID';
• Recompilación de los objetos inválidos de SYS y SYSTEM - utlrp.sql
• Compare los objetos inválidos de antes y después del upgrade
• Desde 11.1.0.7 la compilación se hace de modo automático
• registry$sys_inv_objs, registry$nonsys_inv_objs => utluiobj.sql
• utlrp.sql
• Lanza utlprp.sql con CPU_COUNT-1
• Determina automáticamente el tipo de recompilación – serial o paralelo
• Recompila todos los objetos INVÁLIDOS
• Utiliza el paquete utl_recomp
• Re-activa automáticamente los índices funcionales
• utlprp.sql se puede arrancar directamente:
• SQL> @utlprp 7
• Esto puede ser útil para minimizar la utilización del CPU
31. Parches Timezone - 11g
• Actualizar a la base de datos Oracle 11g:
• Novedad en 11g - $OH tiene timezone V4
• Al $OH origen (<10.2.0.4) se debe aplicar el parche para
actualizarlo a timezone V4
• Note:359145.1
Descárguese y ejecute el script utltzuv2.sql
• Note:413671.1
Descárguese y aplique el parche
32. Parches Timezone - 11g Release 2
R2
• Para actualizar a Oracle Database 11g Release 2:
• Novedad en 11.2 - $OH tiene timezone V11
• No se debe aplicar parche a la $OH origen
• Sólo se debe ajustar la base de datos si se utiliza el tipo de datos
TIMESTAMP WITH TIMEZONE
• Conversión realizada después del upgrade
• Mire la Nota 944122.1
• El paquete DBMS_DST
• DBMS_DST.FIND_AFFECTED_TABLES
• DBMS_DST.BEGIN_UPGRADE
• DBMS_DST.UPGRADE_DATABASE
• DBMS_DST.END_UPGRADE
33. Séptimo Secreto
• Siempre ejecutar el pre-upgrade script:
• Actualizar a Oracle Database 11.1 : utlu111i.sql
• Actualizar a Oracle Database 11.2 : utlu112i.sql
34. Pre-Upgrade Check
• Ejecute utlu112i.sql en su entorno actual
Oracle Database 11.2 Pre-Upgrade Information Tool
Oracle Database 11.2 Pre-Upgrade Information Tool 09-21-2009 22:33:20
09-21-2009 22:33:20
**********************************************************************
**********************************************************************
Database:
Database:
**********************************************************************
**********************************************************************
--> name:
--> name: ORCL
ORCL
--> version:
--> version: 10.2.0.3.0
10.2.0.3.0
--> compatible:
--> compatible: 10.2.0.3.0
10.2.0.3.0
--> blocksize:
--> blocksize: 8192
8192
--> platform:
--> platform: Linux IA (32-bit)
Linux IA (32-bit)
--> timezone file: V4
--> timezone file: V4
[..]
[..]
**********************************************************************
**********************************************************************
Update Parameters: [Update Oracle Database 11.2 init.ora or spfile]
Update Parameters: [Update Oracle Database 11.2 init.ora or spfile]
**********************************************************************
**********************************************************************
WARNING: --> "java_pool_size" needs to be increased to at least 64 MB
WARNING: --> "java_pool_size" needs to be increased to at least 64 MB
[..]
[..]
**********************************************************************
**********************************************************************
Miscellaneous Warnings
Miscellaneous Warnings
**********************************************************************
**********************************************************************
WARNING: --> Database is using a timezone file older than version 11.
WARNING: --> Database is using a timezone file older than version 11.
.... After the release migration, it is recommended that DBMS_DST package
.... After the release migration, it is recommended that DBMS_DST package
.... be used to upgrade the 10.2.0.3.0 database timezone version
.... be used to upgrade the 10.2.0.3.0 database timezone version
.... to the latest version which comes with the new release.
.... to the latest version which comes with the new release.
37. Post Upgrade
• Cree las estadísticas de sistema durante una carga de
trabajo usual – si no, el CBO utilizará valores inapropiados:
SQL>
SQL> exec DBMS_STATS.GATHER_SYSTEM_STATS('start');
exec DBMS_STATS.GATHER_SYSTEM_STATS('start');
...
...
SQL>
SQL> exec DBMS_STATS.GATHER_SYSTEM_STATS('stop');
exec DBMS_STATS.GATHER_SYSTEM_STATS('stop');
SQL> select pname NAME, pval1 VALUE, pval2 INFO
SQL> select pname NAME, pval1 VALUE, pval2 INFO
from aux_stats$;
from aux_stats$;
NAME
NAME VALUE
VALUE INFO
INFO
--------------------
-------------------- ----------
---------- ------------------------------
------------------------------
STATUS
STATUS COMPLETED
COMPLETED
DSTART
DSTART 04-03-2009 12:30
04-03-2009 12:30
DSTOP
DSTOP 05-03-2009 12:30
05-03-2009 12:30
FLAGS
FLAGS 1
1
CPUSPEEDNW
CPUSPEEDNW 1392.39
1392.39
IOSEEKTIM
IOSEEKTIM 8.405
8.405
IOTFRSPEED
IOTFRSPEED 255945.605
255945.605
...
...
38. Post Upgrade
• Ejemplo: carga de trabajo OLTP
• Tiempo de ejecución sin estadísticas de sistema: 2:19h
• Tiempo de ejecución con estadísticas de sistema: 2:07h
• => 9% más rápido
39. Post Upgrade
• Cree estadísticas sobre las tablas fijas
• Inmediatamente después que catupgrd.sql haya finalizado
• Esto acelerará el proceso de re-compilación con utlrp.sql
SQL> exec DBMS_STATS.GATHER_FIXED_OBJECTS_STATS;
SQL> exec DBMS_STATS.GATHER_FIXED_OBJECTS_STATS;
• Otra vez más: unos días después cuando haya ejecutado
alguna carga de trabajo regular
40. Agenda
Introducción
Los Secretos
Los Mitos
Conclusiones
41. Primer Mito
• El upgrade es demasiado simple... de modo
que no necesito volver atrás
42. Estrategias de vueltas atrás
• Siempre:
• Haga un backup completo en línea con RMAN
• ¡Pruebe al menos una vez la recuperación del sistema!
• Opciones de volver a la versión anterior (downgrade) :
• Volver a Oracle Database 10g/11g
• Utilice los scripts de downgrade catdwgrd.sql y catrelod.sql
• Mire Database Upgrade Guide, Capítulo 6 y Note:443890.1
• Datapump con el parámetro VERSION (se puede especificar
COMPATIBLE)
• Volver a Oracle Database 9i
• Export/import
• Utilice exp en 9i para extraer los datos, e imp para importar los datos
• Note:158845.1
46. Ejemplos de Clientes
• Ministerio de Justicia – Londres, Reino Unido
• Utilizan Oracle Database 11g
• Incremento de rendimiento de by 30%
• Seguridad fortificada
• http://www.oracle.com/customers/snapshots/
ministry-of-justice-database-snapshot.pdf
47. Tercer Mito
• El clásico export/import es la mejor, y la más
rápida manera de actualizar la base de datos
48. La Lógica del Upgrade
UPGRADE
UPGRADE
Export/Import
Export/Import
N
N Stay on same OS?
Stay on same OS? Y
Y
CTAS, COPY
CTAS, COPY
N
N Downtime >30min?
Downtime >30min?
SQL Apply
SQL Apply
Y
Y
Oracle Streams
Oracle Streams
DBUA
DBUA
Transportable Tablespaces
Transportable Tablespaces
OR
ORA
CLI
CLI
ACL
CLEE rrec
ecom SQL> @catupgrd
Transportable Database
Transportable Database omm
men
ende
dedd
49. Cuarto Mito
• El upgrade por línea de comandos es mejor que
por interfaz gráfica DBUA
50. Command Line vs. DBUA
• El DBUA realiza varios chequeos muy útiles a la hora
de realizar la actualización
• Menos posibilidades de recibir errores
• El DBUA hace los cambios de parámetros y establece los
valores por usted
• DBUA utiliza los mismos scripts
52. Prever los Cambios del Plan de Ejecución
• Métodos clásicos:
• Rule Based Optimizer (RBO desupport since Oracle 10g - Note:189702.1)
• Hints
• Stored Outlines
• Rescribir las sentencias SQL
• OPTIMIZER_FEATURES_ENABLE=n.n.n
• Cambiar ciertos parámetros del optimizador
• Importar y arreglar objetos y estadísticas del sistema
• Moderno, eficaz y optimizado con respecto al consumo de
recursos:
• SQL Plan Management
53. Sin SQL Plan Management
• El reto de “congelar” los planes de ejecución y las estadísticas
• Dificultad:
• Se hace parse de la sentencia y se crea el plan
• La verificación se hace durante la ejecución:
GB
Parse Execute Plan aceptable
HJ
HJ
• Ahora unas circunstancias cambian (estadísticas, versión, parámetros)
• Se crea un nuevo plan – probablemente peor
GB
Parse Execute Quizá plan
NL
no aceptable
NL
54. SQL Plan Management
• Primera fase - Captura
• OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES=TRUE
GB
Parse Execute Plan aceptable
HJ
HJ
El plan inicial será SQL MANAGEMENT BASE
aceptado la próxima Plan History Reside en SYSAUX TS.
Ocupa máx. 10% de SYSAUX.
vez se agregará a Cada semana se borran los planes
SQL Plan Baseline no usados de hace más de
Plan Baseline
53 semanas [por defecto].
GB
SQL Profiles
HJ
HJ
55. SQL Plan Management
• Segunda fase - Selección
• Se rehace parse de la misma sentencia, y obtenemos otro plan
• OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES=FALSE
GB
Parse
NL
NL
El nuevo plan se
agrega al Plan
History, pero no se Plan History
usará a menos que
esté verificado GB
NL
Plan Baseline
NL
GB
HJ
HJ
56. SQL Plan Management
• Segunda fase - Selección
• Por defecto: OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES=FALSE
GB
Parse Execute Plan averiguado y
HJ
aceptado
HJ
El optimizador usará Plan History
sólo uno de los planes
de ejecución GB
verificados, NL
Plan Baseline
almacenados en SQL NL
Baseline por que sólo GB
éstos planes garantizan HJ
la ESTABILIDAD
HJ
57. SQL Plan Management
• Tercera fase - Evolución
Plan History Plan History
El plan inferior GB
GB
GB
Plan Baseline
se guarda en NL Plan Baseline
NL Plan History NL
NL GB
NL GB GB
NL NL HJ
HJ
NL
HJ
HJ
Los planes mejores, o
similares, se pueden
añadir al SQL Plan
Baseline
DBA programa
la verificación
DBA
Optimizer
58. SQL Plan Management - Upgrade
• Escenario de actualización
Staging
STS exp imp
STS
Table expdp impdp
DB-Link ...
Los planes 10.2 se agregarán
al SQL Plan Baseline
Plan History
GB
NL
Plan Baseline
NL
GB GB GB
NL HJ NL
NL NL
HJ
Cada nuevo plan mejor será
guardado en Plan History
59. Sexto Mito
• Mejor no probar... seguro que algo saldrá mal, de todos
modos
60. Las Pruebas son el Secreto del Éxito
• ¡Nunca cambiar demasiados componentes de un golpe!
• Documente todos los cambios en un historial de cambios.
• ¡Siempre use datos reales de producción para las pruebas!
• Resérvese suficiente tiempo y recursos para las pruebas.
• SIEMPRE colecte suficientes datos del rendimiento ANTES de
empezar el upgrade!!
• ¡Ponga la base de una estrategia de retroceder!
• POR FAVOR, pruebe su estrategia de retroceder - ¿Está usted
seguro que funciona?
• Acuérdense:
La actualización nunca ha sido más fácil – ¡sin embargo
tenemos que seguir hacer bien la pruebas!
61. Agenda
Introducción
Los Secretos
Los Mitos
Conclusiones
62. Resumen
• El upgrade nunca ha sido más fácil...
• Pero no hay que olvidar probar detenidamente
• La base de datos Oracle 11g tiene muchas
características y funcionalidades excelentes
• Es muy estable y completamente optimizada
• SQL Plan Management
• Ofrece actualización de aplicaciones en línea
• Entonces ¿qué está esperando? ☺