oracle ibÉrica, s · infv5_jda_bestpractices19c_v1.1.doc 1 agosto 2019 certificado iso 9001:2000...

ORACLE IBÉRICA, S.R.L. ADVANCED CUSTOMER SERVICES

JUNTA DE ANDALUCÍA

INSTALACIÓN Y CONFIGURACIÓN

BBDD 19C

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_BestPractices19c_v1.1.doc

Fecha: 1 agosto 2019

Versión: <1.1 >

Copyright(c) 2019 ORACLE IBÉRICA

Todos los derechos reservados

InfV5_JDA_BestPractices19c_v1.1.doc 1 agosto 2019

Certificado ISO 9001:2000 JdA-Oracle CONFIDENCIAL Pág. 2 / 28 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. Versión RDBMS 12.2.0.2

01/08/2019 Paola Juárez Gómez 1.1 Actualización documento a versión RDBMS 12.2.0.3 (19c)

Revisiones

Nombre Role

David Sierra Advanced Services Engineer

Agustín Calvo Technical Account Manager

Distribución

Copia Nombre Empresa

1 Administradores de BBDD Junta de Andalucía

2

3



Índice de Contenidos

INTRODUCCIÓN .......................................................................................................................................... 4 VERSIÓN 19C ............................................................................................................................................ 5 INSTALACIÓN 19C....................................................................................................................................... 7 BUENAS PRÁCTICAS 12.2.0.X ..................................................................................................................... 26



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 se encuentran dentro del paraguas de la 12.2.0.X. 12.2.0.2(18c) o 12.2.0.3(19c).

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 19c en modo tradicional.



Versión 19c

Oracle Soporte recomienda actualmente instalar o migrar a la versión 19c (12.2.0.3) 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 que finalizaría en enero del 2021. (incluido en contrato corporativo Jda hasta Nov 20)

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 Jan 2021

• 12.2.0.1 (12c) Premier Support Nov 2020

• 12.2.0.2 (18c) Premier Support Jun 2021

• 12.2.0.3 (19c) Premier Support Mar 2023 & Extended Support Mar 2026

*La opción SINGLE-TENANT es la única arquitectura MULTITENANT disponible sin coste de licencia.



Oracle Database 19

La recomendación de Oracle ACS es migrar a 12.2.0.3 (19c) debido a que, dentro de las opciones de 12.2.0.x , será la que dispondrá de soporte extendido y tiene soporte mínimo hasta Mar 2023.

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 Single-tenant.

La opción SINGLE-TENANT es la única arquitectura MULTITENANT disponible sin coste de licencia. La licencia de MULTITENANT no se encuentra dentro del contrato marco Jda-Oracle.



Instalación 19c



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 19c

Se deben bajar los binarios correspondientes a nuestra plataforma desde OTN

Ejemplo Linux X64 bits

Se recomienda revisar el siguiente whitepaper de instalación.

A continuación, detallaremos los pasos seguidos:

Creamos el directorio que será nuestro ORACLE_HOME, descomprimirlos y ejecutamos el instalador.

$ mkdir -p /u01/app/oracle/product/19.0.0/dbhome_1

$ chgrp oinstall /u01/app/oracle/product/19.0.0/dbhome_1

$ cd /u01/app/oracle/product/19.0.0/dbhome_1

$ unzip -q /tmp/LINUX.X64_193000_db_home.zip.zip

./runInstaller

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

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

https://docs.oracle.com/en/database/oracle/oracle-database/19/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

https://docs.oracle.com/en/database/oracle/oracle-database/19/ladbi/database-installation-guide-linux.pdf



Selecionamos Set Up Software Only.



Seleccionamos Single instance database installation

Seleccionamos Enterprise Edition



Oracle Base=/u01/app/oracle

ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1



La verificación debería de dar un resultado correcto, ante cualquier error se debe revisar los requisitos que no se están cumpliendo.

Se puede usar la opción Fix & Check Again en la que Oracle nos facilitará un script que ejecutará parte de los cambios requeridos, en caso de ser estos de configuración.

En este caso, el aviso está asociado a paquetería del sistema y deberíamos ponernos en contacto con nuestro departamento de sistemas.



Ejecutamos el script indicado en la ventana con el usuario ROOT y le damos a OK [root@dbserver01 ~]# /u01/db/db19/19.3.0/root.sh

Performing root user operation.

The following environment variables are set as:

ORACLE_OWNER= oracle

ORACLE_HOME= /u01/db/db19/19.3.0

Enter the full pathname of the local bin directory: [/usr/local/bin]:

The contents of "dbhome" have not changed. No need to overwrite.

The file "oraenv" already exists in /usr/local/bin. Overwrite it? (y/n)

[n]: y



Copying oraenv to /usr/local/bin ...

The file "coraenv" already exists in /usr/local/bin. Overwrite it? (y/n)

[n]: y

Copying coraenv to /usr/local/bin ...

Entries will be added to the /etc/oratab file as needed by

Database Configuration Assistant when a database is created

Finished running generic part of root script.

Now product-specific root actions will be performed.

Oracle Trace File Analyzer (TFA - Standalone Mode) is available at :

/u01/db/db19/19.3.0/bin/tfactl

Note :

1. tfactl will use TFA Service if that service is running and user has

been granted access

2. tfactl will configure TFA Standalone Mode only if user has no access to

TFA Service or TFA is not installed



Aplicación ultimo RU

Se recomienda aplicar el ultimo RU/RUR recomendado por Recommended Patch Advisor (MOS)

Ejemplo: Patch 29834717: DATABASE RELEASE UPDATE 19.4.0.0.0

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”



Si queremos crear una base de datos tradicional desmarcamos la opción Create as a Container database

Marcamos 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

Seleccionamos el character set deseado.



Revisamos los parámetros de configuración



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

Se deben revisar y validar todos los chequeos antes de entrar en producción. Si se tienen dudas se debe 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 con un formato similar a orachk_host_databaseSID_fecha_hora.zip * Es una buena práctica ejecutar un ORAchk, periódicamente o tras cualquier cambio o upgrade.



Buenas Prácticas 12.2.0.X

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. Una vez realizada la instalación también se pueden deshabilitar el uso de algunas opciones como Oracle Advanced Analytics, Oracle OLAP, partitioning o Oracle Real Application Testing, mediante la herramienta CHOPT.

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

https://docs.oracle.com/en/database/oracle/oracle-database/12.2/ladbi/chopt-tool.html#GUID-057E4EFC-74ED-43B3-B03B-C83C5A5D3C7F



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 las 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

https://www.oracle.com/technetwork/database/bi-datawarehousing/twp-optimizer-with-oracledb-19c-5324206.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



Sin embargo, hay que tener en cuenta que las operaciones NOLOGGING están destinadas a configuraciones no criticas (Desarrollo, Preproducción, Formación, etc).

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 character 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 · infv5_jda_bestpractices19c_v1.1.doc 1 agosto 2019 certificado iso 9001:2000...

Documents