oracle ibÉrica, s · 2020. 7. 25. · 1 e quipo técnico j unta de andalucía 2 equipo técnico...
TRANSCRIPT
ORACLE IBÉRICA, S.R.L. ADVANCED CUSTOMER SERVICES
JUNTA DE ANDALUCÍA
INSTALACIÓN Y CONFIGURACIÓN
BBDD 12C
SOLUTION SUPPORT CENTER
La información incluida en el presente informe es confidencial, siendo para el uso exclusivo del cliente indicado. Si usted no es el destinatario del informe le informamos que está totalmente prohibida cualquier divulgación, distribución o reproducción del contenido de dicho informe.
Referencia documento: InfV5_JDA_BestPractices12c_v1.1.doc
Fecha: 16 abril 2018
Versión: <1.1 >
Copyright(c) 2018 ORACLE IBÉRICA
Todos los derechos reservados
InfV5_JDA_BestPractices12c_v1.1.doc 16 abril 2018
Certificado ISO 9001:2000 JdA-Oracle CONFIDENCIAL Pág. 2 / 24 Nº: 20845/G
Registro de Cambios
Fecha Autor Versión Notas
11/04/2018 Paola Juárez Gómez 1.0 Creación del documento
16/04/2018 Paola Juárez Gómez 1.1 Actualización
Revisiones
Nombre Role
David Sierra Advanced Services Engineer
José María Gómez Technical Account Manager
Agustín Calvo Technical Account Manager
Distribución
Copia Nombre Empresa
1 Equipo Técnico Junta de Andalucía
2 Equipo Técnico Oracle
3
InfV5_JDA_BestPractices12c_v1.1.doc 16 abril 2018
Certificado ISO 9001:2000 JdA-Oracle CONFIDENCIAL Pág. 3 / 24 Nº: 20845/G
Índice de Contenidos
INTRODUCCIÓN .......................................................................................................................................... 4 VERSIÓN 12C ............................................................................................................................................ 5 INSTALACIÓN 12C....................................................................................................................................... 7 BUENAS PRÁCTICAS 12C ............................................................................................................................ 22
InfV5_JDA_BestPractices12c_v1.1.doc 16 abril 2018
Certificado ISO 9001:2000 JdA-Oracle CONFIDENCIAL Pág. 4 / 24 Nº: 20845/G
Introducción
Actualmente uno de los principales objetivos IT dentro del departamento de Sistemas suele ser migrar las bases de datos a versiones soportadas. Dado este punto, nos encontramos con una pregunta recurrente, ¿cuál es la versión a la qué migrar?
Las opciones de versión destino, si se quiere realizar una migración a fecha de realización del informe, son 11gR2 y 12cR2.
Con la versión 12.1 aparece la funcionalidad Multitenant, que consiste en una nueva arquitectura de diseño para nuestra base de datos. En este informe se detallan todas las implicaciones del cambio de arquitectura tradicional a multitenant y se incluyen un conjunto de buenas prácticas de instalación y configuración para la versión 12c en modo tradicional.
InfV5_JDA_BestPractices12c_v1.1.doc 16 abril 2018
Certificado ISO 9001:2000 JdA-Oracle CONFIDENCIAL Pág. 5 / 24 Nº: 20845/G
Versión 12c
Oracle Soporte recomienda actualmente instalar o migrar a la versión 12.2.0.1 de Oracle Database Server. Hay dos alternativas que no requieren de licencias adicionales:
• Base de datos no-CDB (Arquitectura tradicional)
• Base de datos CDB+PDB (Single-tenant)
Si la aplicación que corre sobre la base de datos no está certificada con la versión 12c se podría migrar a 11GR2. La versión 11GR2 ya está fuera de soporte premier, pero en el caso de la Junta de Andalucía no habría problema ya que se dispone de Extended Support (firmado hasta Nov 18)
A continuación, para facilitar la toma de decisión, se añade información sobre el estado actual del soporte de las últimas versiones y de las fechas publicadas en este momento de la próxima versión.
• 11.2.0.4. Extended Support 2021
• 12.2.0.1 Extended Support 2025
Oracle Database 18
La release 18c está planificada para mediados del 2018 para Linux x86-64 y Solaris, para el resto de las plataformas no se dispone de una publicación con la estimación de fechas. Esta planificación no es definitiva y Oracle puede cambiarla, sólo es una aproximación para ayudar a planificar proyectos.
Las fechas se van publicando en la nota de MOS 742060.1 Release Schedule of Current Database Releases.
InfV5_JDA_BestPractices12c_v1.1.doc 16 abril 2018
Certificado ISO 9001:2000 JdA-Oracle CONFIDENCIAL Pág. 6 / 24 Nº: 20845/G
Oracle Database 12c Multitenant
Uno de los mayores cambios introducidos en la versión 12c es la posibilidad de crear bases de datos contenedoras (CDB) en las que se pueden crear múltiples bases de datos (PDB). Con la nueva arquitectura se puede tener bases de datos single-tenant (una CDB con una PDB), o bases de datos multitenant (una CDB con hasta un máximo de 4096 PDBs).
La arquitectura no-CDB (tradicional) está descontinuada desde versión 12.2. Esto no significa que esté desoportada. Se admite tener bases de datos con la arquitectura tradicional, como en versiones anteriores. Según la documentación actual, es posible que la arquitectura tradicional se desoporte a partir de la versión 19. Es decir, sólo se admitirán bases de datos single-tenant y multitenant.
*Dada esta información es el cliente el que tiene que decidir que arquitectura utilizar, si se decanta por la arquitectura tradicional Oracle ACS recomienda tener al menos un entorno de pruebas para conocer la administración Multitenant.
InfV5_JDA_BestPractices12c_v1.1.doc 16 abril 2018
Certificado ISO 9001:2000 JdA-Oracle CONFIDENCIAL Pág. 7 / 24 Nº: 20845/G
Instalación 12c
Prerrequisitos
Revisar los requisitos de hardware, sistema operativo que apliquen a la plataforma en la que deseamos instalar. En el siguiente enlace se puede acceder a la información de Linux
Oracle Database Installation Checklist
También se deben de crear los usuarios y grupos y configurar el entorno.
Operating System Groups and Users
Instalación 12.2.0.1
Se deben bajar los binarios correspondientes a nuestra plataforma desde OTN
Ejemplo Linux X64 bits--> linuxx64_12201_database.zip.
Descomprimirlos y ejecutamos el instalador.
cd database
./runInstaller
InfV5_JDA_BestPractices12c_v1.1.doc 16 abril 2018
Certificado ISO 9001:2000 JdA-Oracle CONFIDENCIAL Pág. 8 / 24 Nº: 20845/G
Selecionamos YES
InfV5_JDA_BestPractices12c_v1.1.doc 16 abril 2018
Certificado ISO 9001:2000 JdA-Oracle CONFIDENCIAL Pág. 9 / 24 Nº: 20845/G
InfV5_JDA_BestPractices12c_v1.1.doc 16 abril 2018
Certificado ISO 9001:2000 JdA-Oracle CONFIDENCIAL Pág. 10 / 24 Nº: 20845/G
InfV5_JDA_BestPractices12c_v1.1.doc 16 abril 2018
Certificado ISO 9001:2000 JdA-Oracle CONFIDENCIAL Pág. 11 / 24 Nº: 20845/G
Se revisa que se cumplan todos los requisitos. Y una vez solucionados podemos continuar con la instalación
InfV5_JDA_BestPractices12c_v1.1.doc 16 abril 2018
Certificado ISO 9001:2000 JdA-Oracle CONFIDENCIAL Pág. 12 / 24 Nº: 20845/G
Ejecutamos el script root.sh con el usuario root
InfV5_JDA_BestPractices12c_v1.1.doc 16 abril 2018
Certificado ISO 9001:2000 JdA-Oracle CONFIDENCIAL Pág. 13 / 24 Nº: 20845/G
Aplicación ultimo RU
Se recomienda aplicar el ultimo RU/RUR recomendado por Recommended Patch Advisor (MOS)
Ejemplo:
Patch 27105253: DATABASE JAN 2018 RELEASE UPDATE 12.2.0.1.180116
Creación base de datos (DBCA)
Para crear la base de datos usaremos el asistente DBCA.
cd $ORACLE_HOME/bin
./dbca
InfV5_JDA_BestPractices12c_v1.1.doc 16 abril 2018
Certificado ISO 9001:2000 JdA-Oracle CONFIDENCIAL Pág. 14 / 24 Nº: 20845/G
Seleccionamos el modo avanzado.
Usamos la template de “Custom Database”
InfV5_JDA_BestPractices12c_v1.1.doc 16 abril 2018
Certificado ISO 9001:2000 JdA-Oracle CONFIDENCIAL Pág. 15 / 24 Nº: 20845/G
Marcar la opción de OMF
InfV5_JDA_BestPractices12c_v1.1.doc 16 abril 2018
Certificado ISO 9001:2000 JdA-Oracle CONFIDENCIAL Pág. 16 / 24 Nº: 20845/G
Se recomienda crear el Listener en puertos distintos al valor por defecto (1521)
Desmarcamos todas las opciones o componentes que no necesitemos en nuestra instalación
Configuramos ASMM
InfV5_JDA_BestPractices12c_v1.1.doc 16 abril 2018
Certificado ISO 9001:2000 JdA-Oracle CONFIDENCIAL Pág. 17 / 24 Nº: 20845/G
InfV5_JDA_BestPractices12c_v1.1.doc 16 abril 2018
Certificado ISO 9001:2000 JdA-Oracle CONFIDENCIAL Pág. 18 / 24 Nº: 20845/G
Revisamos los parámetros de configuración
En este punto se deben crear al menos dos miembros de cada grupo de redo
InfV5_JDA_BestPractices12c_v1.1.doc 16 abril 2018
Certificado ISO 9001:2000 JdA-Oracle CONFIDENCIAL Pág. 19 / 24 Nº: 20845/G
InfV5_JDA_BestPractices12c_v1.1.doc 16 abril 2018
Certificado ISO 9001:2000 JdA-Oracle CONFIDENCIAL Pág. 20 / 24 Nº: 20845/G
Post- Instalación
Descargarse la herramienta ORAchk desde MOS. ORAchk - Health Checks for the Oracle Stack (Doc ID 1268927.2) y ejecutarla con el usuario root. ./orachk
Ejemplo salida:
WARNING => DBRM is not configured. for orcl12
FAIL => Bash is vulnerable to code injection (CVE-2014-6271)
WARNING => Linux swap configuration does not meet recommendation
WARNING => physical memory is not sufficient
WARNING => free physical memory is not at sufficient level on system
INFO => Important Storage Minimum Requirements for Grid & Database Homes
WARNING => There are some application objects with STALE statistics. for orcl12
WARNING => Shell limit - nofile is not configured according to recommendation for the Agent
user.
WARNING => Shell limit - nproc is set to a low value.
FAIL => Recommended JDBC patch has not been applied to this Agent.
FAIL => Agent is installed but not running or is unable to upload files to the OMS.
INFO => Most recent ADR incidents for /u01/app/oracle/product/12.1.0/dbhome_1
INFO => Oracle GoldenGate failure prevention best practices
WARNING => Oracle patch 23665623 is not applied on RDBMS_HOME
/u01/app/oracle/product/12.1.0/dbhome_1
WARNING => Oracle patch 22113854 is not applied on RDBMS_HOME
/u01/app/oracle/product/12.1.0/dbhome_1
WARNING => Oracle patch 18498878 is not applied on RDBMS_HOME
/u01/app/oracle/product/12.1.0/dbhome_1
WARNING => Oracle patch 21171382 is not applied on RDBMS_HOME
/u01/app/oracle/product/12.1.0/dbhome_1
WARNING => Oracle patch 22652097 is not applied on RDBMS_HOME
/u01/app/oracle/product/12.1.0/dbhome_1
WARNING => Oracle patch 24739928 is not applied on RDBMS_HOME
/u01/app/oracle/product/12.1.0/dbhome_1
WARNING => Oracle patch 18430870 is not applied on RDBMS_HOME
/u01/app/oracle/product/12.1.0/dbhome_1
WARNING => Oracle patch 18650065 is not applied on RDBMS_HOME
/u01/app/oracle/product/12.1.0/dbhome_1
WARNING => Oracle patch 19174639 is not applied on RDBMS_HOME
/u01/app/oracle/product/12.1.0/dbhome_1
WARNING => Oracle patch 20879889 is not applied on RDBMS_HOME
/u01/app/oracle/product/12.1.0/dbhome_1
WARNING => Oracle patch 20476175 is not applied on RDBMS_HOME
/u01/app/oracle/product/12.1.0/dbhome_1
WARNING => Oracle patch 20907061 is not applied on RDBMS_HOME
/u01/app/oracle/product/12.1.0/dbhome_1
WARNING => Oracle patch 23147905 is not applied on RDBMS_HOME
/u01/app/oracle/product/12.1.0/dbhome_1
WARNING => Oracle patch 21826068 is not applied on RDBMS_HOME
/u01/app/oracle/product/12.1.0/dbhome_1
WARNING => Oracle patch 20807398 is not applied on RDBMS_HOME
/u01/app/oracle/product/12.1.0/dbhome_1
WARNING => Oracle patch 22255113 is not applied on RDBMS_HOME
/u01/app/oracle/product/12.1.0/dbhome_1
WARNING => Oracle patch 20634449 is not applied on RDBMS_HOME
/u01/app/oracle/product/12.1.0/dbhome_1
WARNING => Oracle patch 19855835 is not applied on RDBMS_HOME
/u01/app/oracle/product/12.1.0/dbhome_1
INFO => user_dump_dest has trace files older than 30 days for orcl12
WARNING => ORA-00600 errors found in alert log for orcl12
INFO => At some times checkpoints are not being completed for orcl12
InfV5_JDA_BestPractices12c_v1.1.doc 16 abril 2018
Certificado ISO 9001:2000 JdA-Oracle CONFIDENCIAL Pág. 21 / 24 Nº: 20845/G
FAIL => Operating system hugepages count does not satisfy total SGA requirements
WARNING => OSWatcher is not running as is recommended.
FAIL => Database parameter DB_BLOCK_CHECKSUM is not set to recommended value on orcl12
FAIL => Database parameter DB_LOST_WRITE_PROTECT is not set to recommended value on orcl12
WARNING => Database parameter DB_BLOCK_CHECKING on PRIMARY is NOT set to the recommended
value. for orcl12
INFO => Operational Best Practices
INFO => Database Consolidation Best Practices
INFO => Computer failure prevention best practices
INFO => Data corruption prevention best practices
INFO => Logical corruption prevention best practices
INFO => Database/Cluster/Site failure prevention best practices
INFO => Client failover operational best practices
WARNING => One or More Registry Components were found to be Invalid for orcl12
WARNING => Package -ksh-20120801-10.el6-x86_64 does not meet recommendation for ksh-20100621-
12.el6-x86_64
WARNING => Oracle clusterware is not being used
WARNING => RAC Application Cluster is not being used for database high availability on orcl12
instance
WARNING => DISK_ASYNCH_IO is NOT set to recommended value for orcl12
FAIL => Table AUD$[FGA_LOG$] should use Automatic Segment Space Management for orcl12
INFO => Database failure prevention best practices
WARNING => fast_start_mttr_target has NOT been changed from default on orcl12 instance
FAIL => Primary database is not protected with Data Guard (standby database) for real-time
data protection and availability for orcl12
FAIL => Active Data Guard is not configured for orcl12
INFO => Parallel Execution Health-Checks and Diagnostics Reports for orcl12
INFO => Oracle recovery manager(rman) best practices
INFO => Consider increasing the COREDUMPSIZE size
WARNING => Consider investigating changes to the schema objects such as DDLs or new object
creation for orcl12
WARNING => Consider increasing the value of the session_cached_cursors database parameter for
orcl12
WARNING => Consider investigating the frequency of SGA resize operations and take corrective
action for orcl12
Revisar y aplicar todas las recomendaciones antes de entrar en producción. Si se tienen dudas consultar con Oracle ACS a través de Naos. Toda la información recopilada se comprime en un fichero ubicado en el directorio de ejecución Ejemplo: orachk_primaria_orcl12_041118_163202.zip * Es una buena práctica ejecutar un ORAchk, periódicamente o tras cualquier cambio o upgrade.
InfV5_JDA_BestPractices12c_v1.1.doc 16 abril 2018
Certificado ISO 9001:2000 JdA-Oracle CONFIDENCIAL Pág. 22 / 24 Nº: 20845/G
Buenas Prácticas 12c
Genéricas
Se recomienda configurar la base de datos en modo archive log.
Se recomienda crear todos los tablespaces de la base de datos con la opción de Automatic Segment Space Management (ASSM).
Se recomienda la instalación del mínimo de opciones posible dentro de la edición Enterprise. El objetivo es crear el diccionario mínimamente necesario.
Si estamos instalando una base de datos Contenedora (multitenant) se recomienda no instalar APEX. Ya que se debe configurar APEX en posteriormente en cada Pluggable.
Se recomienda crear al menos 3 CONTROL FILE en ubicaciones diferentes y redundadas.
Se recomienda crear al menos 3 grupos de REDO FILE con al menos 2 miembros cada uno en ubicaciones diferentes y redundadas.
Se recomienda deshabilitar la funcionalidad de EXTPROC en la configuración de los TNS Listener.
Una vez creada una base de datos se debe validar las opciones instaladas a través del DBA_REGISTRY.
Se recomienda el bloqueo de cuentas super-usuarios de las opciones, si procede.
Se recomienda usar spfile para poder realizar cambios dinámicos.
Para instancias de base de datos en entornos Linux se recomienda el uso de ASMM (Gestión automática de SGA), se debe dejar MEMORY_TARGET=0. ASMM versus AMM and LINUX x86-64 Hugepages Support (Doc ID 1134002.1)
En entornos Linux se recomienda establecer el parámetro de inicialización USE_LARGE_PAGES a ONLY
Aunque ASMM gestione automáticamente el reparto entre todos los componentes de la SGA, se recomienda dar valores mínimos a los distintos subpoles: Shared Pool, Buffer Cache, Large pool, Streams pool y Java Pool. Para calcular el valor apropiado se puede seguir la recomendación dada en la nota 451960.1 y usar los valores dados por la instancia al iniciar tras un periodo de carga.
Oracle recomienda dejar al menos un 20% de memoria física para el sistema operativo. El 80% restante será la memoria disponible para todos los procesos Oracle, recursos a repartir entre todas las instancias activas. De la memoria asignada a una instancia se recomienda asignar 80% para la SGA y 20% para la PGA. (MEMORY_TARGET=0)
Se recomienda usar OMF (Oracle Managed Files).
Se recomienda instalar el ultimo RUR (“antiguos PSU”) disponible en MOS.
InfV5_JDA_BestPractices12c_v1.1.doc 16 abril 2018
Certificado ISO 9001:2000 JdA-Oracle CONFIDENCIAL Pág. 23 / 24 Nº: 20845/G
Se recomienda configurar la FRA. Benefits Of Using Flash Recovery Area (Doc ID 560133.1)
Se recomienda el uso del ASM. Master Note for Automatic Storage Management (ASM) (Doc ID 1187723.1)
Se recomienda configurar la funcionalidades de flashback para obtener flexibilidad en las recuperaciones.
Se recomienda configurar statspack o AWR (según licencia). Se debe fijar una frecuencia y mantenimiento de los snaps adecuado al entorno. En el caso de estar usando una CDB se recomienda usar esta nota Installing and Using Standby Statspack in 12c Multitenant Database (Doc ID 2020285.1)
Revisar las nuevas funcionalidades del Optimizador de costes. Se recomienda este White Paper
Se recomienda revisar el estándar OFA (Optimal Flexible Architecture). Esté nos provee de un conjunto de guías que nos ayudaran en la instalación de un producto Oracle para que sea más fácil de administrar y mantener.
Se recomienda usar ADRCI para purgar los ficheros de traza antiguos. se deben fijar los valores apropiados a las políticas SHORTP_POLICY y LONGP_POLICY (ADR_CONTROL). Automatic Diagnostic Cleanup - Auto purge (Doc ID 1196437.1)
Si estamos instalando una base de datos Contenedora (multitenant) se recomienda configurar el parámetro MAX_PDBS a 1 para forzar el límite de pluggables y tener una configuración Sigle_tentant. Esto permite que se asegure el licenciamiento incluido el contrato marco Jda-Oracle.
Configurar el parámetro DEFERRED_SEGMENT_CREATION a FALSE, su valor por defecto es TRUE y permite que las tablas no se asignen los segmentos hasta que no se creen los registros pudiendo provocar contención en algunos casos. (Doc ID 1216282.1)
Se recomienda configurar el parámetro JOB_QUEUE_PROCESSES al número de cores físicos existente, ya que el valor por defecto en 12.2 es 4000.
Force Logging
La opción Force Logging a nivel de base de datos no es técnicamente obligatoria, pero si se realiza alguna operación NOLOGGING (CTAS, creación índice, modificación índice, etc con NOLOGGING) estos cambios no se registrarán en los online redo logs y por tanto no irán a los archives.
Nologging puede ser extremadamente beneficioso por las siguientes razones:
Se minimiza el tiempo en la inserción de datos.
Se mejora el tiempo de creación de tablas o índices grandes
Se minimiza la cantidad de redo generado, reduciendo los backups
Sin embargo, hay que tener en cuenta que las operaciones NOLOGGING están destinadas a configuraciones no criticas (Desarrollo, Preproducción, Formación, etc).
InfV5_JDA_BestPractices12c_v1.1.doc 16 abril 2018
Certificado ISO 9001:2000 JdA-Oracle CONFIDENCIAL Pág. 24 / 24 Nº: 20845/G
Si ocurriera un fallo en el almacenamiento no se podrían recuperar los cambios ya que estos nunca se registraron. The Gains and Pains of Nologging Operations (Doc ID 290161.1)
Se recomienda activar Force Logging cualquier entorno de producción.
Characterset
La decisión de un characterset correcto puede ahorrarnos muchos errores. Se recomienda leer la documentación oficial. Choosing a Character Set
A partir de la versión 12.2, AL32UTF8 es el characterset set definido por defecto para una base de datos creada con el asistente (DBCA). En el caso de multitenant la recomendación es usar AL32UTF8 como database carácter y AL16UTF16 como national character en la creación de la CDB.
Auditoria Unificada
Con la versión de Oracle Database 12c tendremos acceso a nuevas funcionalidades de seguridad. En las versiones anteriores a 12 existían distintos componentes de auditoria:
• SYS.AUD$ para el traceo de auditoria
• SYS.FGA_LOG$ para la auditoria de grano fino
• DVSYS.AUDIT_TRAIL$ para Oracle Database Vault, Oracle Label Security.
En esta versión, la auditoria se registra en una única vista de diccionario, UNIFIED_AUDIT_TRAIL, con
este cambio se mejora el manejo y uso de la auditoria.
La auditoría unificada no viene configurada por defecto, se recomienda configurar en la instalación
antes de entrar en producción.
cd $ORACLE_HOME/rdbms/lib
make -f ins_rdbms.mk uniaud_on ioracle
Documentación:
http://www.oracle.com/webfolder/technetwork/tutorials/obe/db/12c/r1/security/sec_uni_audit/se
c_uni_audit.html
Independientemente de que se configure o no la auditoria unificada, a partir de la versión 11 hay
operaciones que se auditan de forma automática y obligatoria, por ello se recomienda crear un
tablespace de auditoria especifico y mover con el paquete DBMS_AUDIT_MGMT.
SET_AUDIT_TRAIL_LOCATION las tablas de auditoria a este tablespace.