oracle ibÉrica, s · 2020. 7. 25. · 1 e quipo técnico j unta de andalucía 2 equipo técnico...

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



Índice de Contenidos

INTRODUCCIÓN .......................................................................................................................................... 4 VERSIÓN 12C ............................................................................................................................................ 5 INSTALACIÓN 12C....................................................................................................................................... 7 BUENAS PRÁCTICAS 12C ............................................................................................................................ 22



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.



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.



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.



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

https://docs.oracle.com/en/database/oracle/oracle-database/12.2/ladbi/oracle-database-installation-checklist.html#GUID-E847221C-1406-4B6D-8666-479DB6BDB046

https://docs.oracle.com/en/database/oracle/oracle-database/12.2/ladbi/configuring-users-groups-and-environments-for-oracle-grid-infrastructure-and-oracle-database.html#GUID-B65E6113-D056-4DD9-940F-DFF493E413D5

http://www.oracle.com/technetwork/database/enterprise-edition/downloads/index.html



Selecionamos YES



Se revisa que se cumplan todos los requisitos. Y una vez solucionados podemos continuar con la instalación



Ejecutamos el script root.sh con el usuario root



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



Seleccionamos el modo avanzado.

Usamos la template de “Custom Database”



Marcar la opción de OMF



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



Revisamos los parámetros de configuración

En este punto se deben crear al menos dos miembros de cada grupo de redo



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



































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



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.



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.



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).

../../../../../../AppData/Local/Microsoft/Windows/INetCache/Content.Outlook/L9DSJETN/•%09http:/www.oracle.com/technetwork/database/bi-datawarehousing/twp-optimizer-with-oracledb-12c-1963236.pdf

https://docs.oracle.com/database/121/LADBI/appendix_ofa.htm#LADBI0015

https://docs.oracle.com/en/database/oracle/oracle-database/12.2/sutil/oracle-adr-command-interpreter-adrci.html#GUID-DC5744C7-FAC0-436B-99D5-DBD45B66930B



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.

https://docs.oracle.com/en/database/oracle/oracle-database/12.2/nlspg/choosing-character-set.html#GUID-BF26E01D-AB92-48FC-855A-69A5B3AF9A92

http://www.oracle.com/webfolder/technetwork/tutorials/obe/db/12c/r1/security/sec_uni_audit/sec_uni_audit.html

http://www.oracle.com/webfolder/technetwork/tutorials/obe/db/12c/r1/security/sec_uni_audit/sec_uni_audit.html

oracle ibÉrica, s · 2020. 7. 25. · 1 e quipo técnico j unta de andalucía 2 equipo técnico...

Documents