Mostrando entradas con la etiqueta Oracle 12c R2 spfile. Mostrar todas las entradas
Mostrando entradas con la etiqueta Oracle 12c R2 spfile. Mostrar todas las entradas

20 enero 2021

Oracle Database 12c R2 Nueva función: Cifrado de tablespaces en línea y automática


Transparent Data Encryption, en adelante TDE,  le permite cifrar datos confidenciales, como números de tarjetas de crédito o porcentaje de invalidez, dentro de la base de datos  Oracle 12C.



Oracle Database utiliza autenticación, autorización y mecanismos de auditoria para proteger los datos en la base de datos, pero no en los archivos de datos del sistema operativo donde se almacenan los datos. Para proteger estos archivos de datos, Oracle Database proporciona Transparent Data Encryption (TDE). TDE cifra los datos confidenciales almacenados en archivos de datos. Para evitar el descifrado no autorizado, TDE almacena las claves de cifrado en un módulo de seguridad externo a la base de datos, denominado almacén de claves.

El cifrado transparente de datos (TDE) permite cifrar datos confidenciales tales como números de tarjetas de crédito almacenados en tablas y espacios de tabla. Los datos cifrados se descifran de forma transparente para una aplicación o un usuario de base de datos que tenga acceso a los datos. TDE ayuda a proteger los datos almacenados en medios en caso de sustracción de los medios de almacenamiento o los archivos de datos. Oracle usa mecanismos de autenticación, autorización y auditoría para proteger los datos de la base de datos, pero no los archivos de datos del sistema operativo donde se almacenan datos. Para proteger estos archivos de datos, Oracle proporciona TDE. TDE cifra los datos confidenciales almacenados en los archivos de datos. Para evitar descifrados no autorizados, TDE almacena las claves de cifrado en un módulo de seguridad externo a la base de datos.

Estas son algunas de las ventajas del uso de TDE:

  • Como administrador de seguridad tendrá la tranquilidad de que los datos confidenciales estén protegidos en caso de sustracción de los medios de almacenamiento o de los archivos de datos.
  • La implementación de TDE ayuda a abordar los aspectos de cumplimiento reglamentario relacionados con la seguridad.
  • No es necesario crear desencadenadores ni vistas para descifrar los datos para una aplicación o usuario autorizados. Los datos de las tablas se descifran de forma transparente para la aplicación y el usuario de la base de datos.
  • No es necesario que las aplicaciones y usuarios de base de datos sepan que los datos a los que acceden están almacenados en modo cifrado. Los datos se descifran de forma transparente para las aplicaciones y usuarios de base de datos.
  • No hace falta modificar las aplicaciones para controlar los datos cifrados. La base de datos administra el cifrado y descifrado de datos.
  • Las operaciones de administración de claves están automatizadas. El usuario o la aplicación no necesitan administrar las claves de cifrado.

Oracle 12c

Para obtener más información sobre la configuración del cifrado de espacios de tablas de TDE, consulte la documentación de Oracle.

Configuración manual del TDE
El siguiente procedimiento muestra cómo configurar manualmente TDE.

  • Cree el directorio keystore.
        mkdir $ORACLE_HOME/admin/$ORACLE_SID/wallet

  • Modifique el archivo SQLNET.ORA si desea administrar la cartera de cifrado.
        La ubicación predeterminada de la cartera de cifrado es             $ORACLE_BASE/admin/<nombre_db_global>/wallet. Si desea permitir que Oracle administre una cartera en la ubicación predeterminada, no necesita establecer el parámetro ENCRYPTION_WALLET_LOCATION en el archivo sqlnet.ora.

Para Windows


ENCRYPTION_WALLET_LOCATION=
 (SOURCE=
  (METHOD=FILE)   (METHOD_DATA=
    (DIRECTORY=C:/oracle/admin/%ORACLE_SID%/wallet/)))

Para Linux


ENCRYPTION_WALLET_LOCATION=
 (SOURCE=
  (METHOD=FILE)   (METHOD_DATA=
    (DIRECTORY=/app/oracle/admin/$ORACLE_SID/wallet/)))

  • Compruebe el parámetro de inicialización COMPATIBLE para el número correcto de versión. Debería ser 12.x.
Nota:
Utilice SQL*Plus. No utilice Oracle SQL Developer.

ORA> sqlplus /nolog SQL> connect /as sysdba Connected. SQL> select instance_name,status,database_status from v$instance;
INSTANCE_NAME    STATUS       DATABASE_STATUS
---------------- ------------ -----------------
mcs1              OPEN         ACTIVE
SQL> show parameter compatible NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
compatible                           string      12.1.0.0.0
  • Cree el keystore.
ADMINISTER KEY MANAGEMENT CREATE KEYSTORE 'C:\oracle\admin\mcs1\wallet' IDENTIFIED BY "mcs1$admin";


  • Abra el keystore basado en contraseña.
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY "mcs1$admin" CONTAINER=ALL;

  • Comprueba el estado 
SELECT WRL_PARAMETER,STATUS,WALLET_TYPE FROM V$ENCRYPTION_WALLET;

  • Haga una copia de seguridad de un software keystore basado en contraseña.
ADMINISTER KEY MANAGEMENT BACKUP KEYSTORE USING 'keystore_bkp' IDENTIFIED BY "mcs1$admin";
SELECT WRL_PARAMETER,STATUS,WALLET_TYPE FROM V$ENCRYPTION_WALLET;
  • Cree la clave principal de cifrado.
Cree una clave principal para la CBD y todas las PDB.

ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY "mcs1$admin" WITH BACKUP USING 'masterkey_all_bkp' CONTAINER=ALL;
SELECT KEY_ID,KEYSTORE_TYPE,CREATOR,CREATOR_INSTANCE_NAME,CREATOR_PDBNAME FROM V$ENCRYPTION_KEYS;
Exporte la clave principal.

ADMINISTER KEY MANAGEMENT EXPORT ENCRYPTION KEYS WITH SECRET "mcs1.exp$admin" TO 'C:\oracle\admin\mcs1\wallet\masterkey_cdb_exp.bkp' IDENTIFIED BY "mcs1$admin";
  • Si lo desea, cree la contraseña principal para el contenedor actual. Puede omitir este paso si ha completado el paso anterior.
Base de datos de contenedor (CDB):

ALTER SESSION SET CONTAINER = CDB$ROOT;
SHOW CON_NAME SELECT SYS_CONTEXT('USERENV', 'CON_NAME') FROM dual;
ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY "mcs1$admin" WITH BACKUP USING 'masterkey_cdb_backup' CONTAINER=CURRENT;
SELECT KEY_ID,KEYSTORE_TYPE,CREATOR,CREATOR_INSTANCE_NAME,CREATOR_PDBNAME FROM V$ENCRYPTION_KEYS;
--export master key
ADMINISTER KEY MANAGEMENT EXPORT ENCRYPTION KEYS WITH SECRET "mcs1.exp$admin" TO 'C:\oracle\admin\mcs1\wallet\masterkey_cdb_exp.bkp' IDENTIFIED BY "mcs1$admin";
Base de datos conectable (PDB): bathypdb

ALTER SESSION SET CONTAINER = bathypdb;
SHOW CON_NAME SELECT SYS_CONTEXT('USERENV', 'CON_NAME') FROM dual;
ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY "mcs1$admin" WITH BACKUP USING 'masterkey_bathypdb_backup' CONTAINER=CURRENT;
SELECT KEY_ID,KEYSTORE_TYPE,CREATOR,CREATOR_INSTANCE_NAME,CREATOR_PDBNAME FROM V$ENCRYPTION_KEYS;
--export master key
ADMINISTER KEY MANAGEMENT EXPORT ENCRYPTION KEYS WITH SECRET "mcs1.exp$admin" TO 'C:\oracle\admin\mcs1\wallet\masterkey_bathypdb_exp.bkp' IDENTIFIED BY "mcs1$admin";

  • Comprobar estado
Select * from v$encryption_wallet;
select * from v$encryption_keys;
select wrl_parameter,status,wallet_type from v$encryption_wallet;
select key_id,keystore_type, creator,creator_instance_name, creator_pdbname from v$encryption_keys;

  • Establezca el keystore local de inicio de sesión automático.
ADMINISTER KEY MANAGEMENT CREATE AUTO_LOGIN KEYSTORE FROM KEYSTORE 'C:\oracle\admin\mcs1\wallet' IDENTIFIED BY "mcs1$admin";
SELECT WRL_PARAMETER,STATUS,WALLET_TYPE FROM V$ENCRYPTION_WALLET;
--the cwallet.sso file appears in the keystore location. The ewallet.p12 file is the password-based wallet. --Note:
--Do not remove the PKCS#12 wallet (ewallet.p12 file) after you create the auto login keystore (.sso file). 
--You must have the PKCS#12 wallet to regenerate or rekey the TDE master encryption key in the future. 
--By default, this file is located in the $ORACLE_HOME/admin/ORACLE_SID/wallet directory.

  • Abra el keystore de inicio de sesión automático.
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN CONTAINER=ALL;
-- check the status
SELECT WRL_PARAMETER,STATUS,WALLET_TYPE FROM V$ENCRYPTION_WALLET;
Sugerencia:
Para cerrarlo, puede usar la siguiente instrucción.

ADMINISTER KEY MANAGEMENT SET KEYSTORE CLOSE IDENTIFIED BY "mcs1$admin" CONTAINER=ALL;

  • Se recomienda que verifique el estado de la configuración TDE utilizando las instrucciones SQL siguientes.
Select * from v$encryption_wallet;
select * from v$encryption_keys;
select wrl_parameter,status,wallet_type from v$encryption_wallet;
select key_id,keystore_type from v$encryption_keys;
select key_id from v$encryption_keys;
select keystore_type from v$encryption_keys;
select wrl_parameter from v$encryption_wallet;
select status from v$encryption_wallet;
select * from v$encrypted_tablespaces;
select tablespace_name, encrypted from dba_tablespaces;
select * from dba_encrypted_columns;

28 agosto 2017

Entender Oracle Data Guard

En este artículo, escribiré sobre la solución de recuperación de desastres de Oracle (recuperación de desastres). Voy a dar la terminología básica en una breve información sobre el Data Guard. Como gestores de datos, estamos obligados a tomar las medidas necesarias antes de que ocurran estos desastres. También hay que considerar tomar las acciones necesarias que son muy importantes. Estos son;
  • RPO (Recovery Point Objective) - ¿Cuántos datos puede permitirse perder?
  • RTO (Recovery Time Objective) - Sin acceso a los datos, ¿Cuanto tiempo puedes soportar?

De acuerdo con las respuestas de estas preguntas debemos establecer el sistema de copia de seguridad. No estamos satisfechos con la instalación de nuestro sistema, y ​​debemos monitorear nuestro sistema.

Ahora, veamos la solución que Oracle propone:  Oracle Data Guard.

Oracle Data Guard es la solución de recuperación de desastres. Protege nuestra base de datos de producción de los desastres, reduciendo la carga de trabajo sobre ella y su uso más efectivo. Technology, introducida por primera vez mediante el establecimiento de la base de datos de reserva manualmente con Oracle 7. Apareció como un Data Guard con Oracle 8i. 

Evolución histórica de Oracle Data Guard
Si examinamos las características de un Data Guard desde el pasado hasta el presente;
  • ORACLE 8i
    • Base de datos en espera de sólo lectura
    • Recuperación gestionada
    • Archivo de registro de rehacer archivos remotos
  • ORACLE 9i
    • Integración "Pérdida de datos cero"
    • Data Guard Broker y Data Guard Manager GUI
    • Operaciones de Switcover y Failover
    • Sincrónico automático
    • Base de datos de espera lógica
    • Protección máxima
  • ORACLE 10g
    • Aplicación en tiempo real
    • Soporte forzado para Oracle RAC
    • Failover de arranque rápido
    • Transferencia asíncrona de rehacer
    • Base de datos Flashback
  • ORACLE 11g
    • Base de datos de espera activa (Active Data Guard)
    • Instantánea de la instantánea
    • Soporte de plataforma heterogénea (Producción -Linux, Standby - Windows)
  • ORACLE 12C
    • Funciones comunes a Redo Apply y SQL Apply
    • Funciones especificas a Redo Apply
    • Funciones especificas a  SQL Apply




FLUJO DE DATOS: PHYSICAL STANDBY
Vamos a entender cómo los datos fluyen en la configuración de Oracle Data Guard mostrada arriba en ocho puntos:


  • En la base de datos principal, se inician las transacciones. Todos los bloqueos de caché del búfer (bloqueos exclusivos) que se requieren para la transacción se obtienen.
  • En la base de datos principal, los bloques de rehacer que describen los cambios (o los vectores de cambio) se generan y almacenan en el Área Global del Programa (PGA) de los procesos. Después de adquirir con éxito el bloqueo de rehacer asignación, el espacio se asigna en el búfer de registro de rehacer. El redo generado se copia de PGA de los procesos en el búfer de registro de rehacer.
  • En la base de datos primaria, el proceso de primer plano de oracle le indica a LGWR que limpie los búferes de registro de rehacer en el disco. Recuerde que los bloques de base de datos de la base de datos aún no se han actualizado con los cambios DML. El LGWR descarga los buffers de redo al ORL y reconoce la finalización de la sesión. En este punto, la transacción es persistente en el disco. No se ha cometido hasta el momento.



En algún momento futuro, los buffers de base de datos que fueron cambiados previamente serán escritos en disco por el proceso de escritura de base de datos (DBWR) en el momento del punto de control. Este punto no está marcado en el diagrama anterior.
Tenga en cuenta que antes de que el proceso DBWR haya descargado los búferes de la base de datos a los discos, el proceso LGWR debe haber escrito ya los búferes de rehacer en el disco. Esta secuencia explícita es reforzada por el protocolo de registro anticipado.
También el proceso ARCH en la base de datos primaria archiva los ORL en archivos de registro de archivos. Este punto tampoco está marcado en el diagrama anterior.

  • En la base de datos primaria, el proceso LNS lee el redo recientemente descargado del búfer de registro de redo y envía los datos de rehacer a la base de datos en espera utilizando el destino de transporte redo (LOG_ARCHIVE_DEST_n) que definimos durante la creación de la base de datos en espera. Estamos utilizando el método de transporte ASYNC, por lo que el LGWR no espera ningún reconocimiento de la LNS para esta operación de envío de red. No se comunica con el LNS excepto para iniciarlo en la etapa de inicio de la base de datos y después de un fallo de una conexión en espera.
  • En la base de datos de espera, el RFS lee el flujo de rehacer desde el socket de red en los búferes de red y, a continuación, escribe este flujo de rehacer a la SRL.
  • En la base de datos de espera, el proceso ARCH archiva las SRL en archivos de registro de archivo cuando se produce un cambio de registro en la base de datos primaria. El archivo de registro de archivo generado se registra con el archivo de control de espera.
  • En la base de datos de espera, el proceso de recuperación real comienza en este paso. El proceso de recuperación administrado (MRP) leerá de forma asincrónica el rehacer de los SRL o de los registros de rehacer archivados (cuando la recuperación se reduce o no se aplica en tiempo real). Los bloques que requieren redo apply se analizan y se colocan en segmentos de mapa en memoria apropiados.
  • En la base de datos en espera, el proceso MRP envía rehacer a los esclavos de recuperación utilizando el marco de comunicación entre procesos de consulta en paralelo (PQ). Medios paralelos

Recuperación (PMR) hace que los bloques de datos requeridos sean leídos en la caché del búfer, y posteriormente redo se aplicará a estos búferes del búfer del búfer.


PROCESOS RELACIONADOS CON BASE DE DATOS EN ESPERA FÍSICA

En la base de datos primaria:
  • LGWR: El proceso de escritura de registros vacía los buffers de registro de los archivos SGA a Online Redo Log.
  • LNS: El servicio de red de LogWriter (LNS) lee el redo que es descargado de los almacenadores intermediarios del redo por el LGWR y envía el redo sobre red a la base de datos espera. El propósito principal del proceso LNS es liberar el proceso LGWR de realizar el rol redo transport. 
  • ARCH: El archivador procesa los archivos de ORL para archivar los archivos de registro. Pueden existir hasta 30 procesos ARCH, y estos procesos ARCH también se utilizan para satisfacer solicitudes de resolución de huecos. Tenga en cuenta que un proceso ARCH tiene un papel especial en que está dedicado al archivo de registro de redo local solo y nunca se comunica con una base de datos en espera.

En la base de datos de reserva:
  • RFS: El objetivo principal del proceso de servidor de archivos remotos es realizar una red de recepción de redo transmitida desde el sitio principal y, a continuación, escribe el búfer de red (rehacer datos) a los archivos de redo registro (SRL) en espera.
  • ARCH: Los procesos de archivo en el sitio en espera realizan las mismas funciones realizadas en el sitio principal, excepto que en el sitio en espera, un proceso ARCH genera archivos de registro archivados de las SRL.
  • MRP: el proceso de recuperación administrado coordina la administración de recuperación de medios. Recuerde que un modo de espera físico está en modo de recuperación perpetua.
Básicamente, podemos categorizar la base de datos de espera física en tres componentes principales:

Data Guard Redo Servicios de Transporte
Para transferir el redo generado por la base de datos primaria a la base de datos en espera.

Data Guard Aplicar Servicios
Para recibir y aplicar el redo enviado por Redo Transport Services a la base de datos en espera.

Data Guard servicios de gestión de roles
Para ayudar en los cambios de rol de la base de datos en los escenarios de conmutación y conmutación por error- Este servicio funciona en segundo plano y se ocupa de los escenarios de conmutación / conmutación por error

10 noviembre 2016

Nuevos parámetros SPFILE en base de datos Oracle 12.2.0.1

La Base de Datos Oracle 12.2.0.1 está disponible ahora en la nube de Oracle.

Y esta es la lista de los 46 nuevos parámetros init.ora / spfile comparados con la base de datos Oracle 12.1.0.2. Ojo que algunos de ellos están sin documentar a día de hoy.


Parameter
Description
allow_global_dblinks
ALLOW_GLOBAL_DBLINKS specifies whether LDAP lookup for database links is allowed for the database.
allow_group_access_to_sga
ALLOW_GROUP_ACCESS_TO_SGA controls group access to shared memory on UNIX platforms.

The default value is false, which means that database shared memory is created with owner access only. In Oracle Database releases prior to Oracle Database 12c Release 2 (12.2.0.1), database shared memory was created with owner and group access.
approx_for_aggregation
APPROX_FOR_AGGREGATION replaces exact query processing for aggregation queries with approximate query processing.

Data analysis applications heavily use aggregate function and analytic function queries. Aggregation functions and analytic functions require sorting of large volumes of data, and exact query answering requires lots of memory, and can be time consuming. With approximate query processing, the results of aggregate function and analytic function queries are returned much faster than with exact query processing.
approx_for_count_distinct
APPROX_FOR_COUNT_DISTINCT automatically replaces COUNT (DISTINCT expr) queries with APPROX_COUNT_DISTINCT queries.

Query results for APPROX_COUNT_DISTINCT queries are returned faster than the equivalent COUNT (DISTINCT expr) queries. APPROX_COUNT_DISTINCT queries are useful for situations where a tolerable amount of error is acceptable in order to obtain faster query results than with a COUNT (DISTINCT expr) query.
approx_for_percentile
APPROX_FOR_PERCENTILE converts exact percentile functions to their approximate percentile function counterparts.

Approximate percentile function queries are faster than their exact percentile function query counterparts, so they can be useful in situations where a tolerable amount of error is acceptable in order to obtain faster query results.
asm_io_processes
ASM_IO_PROCESSES specifies the number of I/O worker processes to be started in an Oracle Automatic Storage Management (Oracle ASM) IOServer instance.

This parameter is applicable only in an Oracle ASM IOServer instance, which runs out of an Oracle Grid home.

The default value should work in most cases
autotask_max_active_pdbs
AUTOTASK_MAX_ACTIVE_PDBS enables you to specify the maximum number of PDBs that can schedule automated maintenance tasks at the same time (during a maintenance window).
This parameter only affects PDBs. The CDB$ROOT container (CDB root) for a CDB can always schedule and run maintenance tasks during a maintenance window.
The default value is 2.
awr_pdb_autoflush_enabled
AWR_PDB_AUTOFLUSH_ENABLED enables you to specify whether to enable or disable automatic Automatic Workload Repository (AWR) snapshots for all the PDBs in a CDB or for individual PDBs in a CDB. Default value is false.
cdb_cluster
[undocumented]
cdb_cluster_name *
[undocumented]
clonedb_dir *
CLONEDB_DIR sets the directory path where CloneDB bitmap files should be created and accessed.
By default the CloneDB bitmap file is created under the $ORACLE_HOME/dbs directory.
containers_parallel_degree
CONTAINERS_PARALLEL_DEGREE can be used to control the degree of parallelism of a query involving containers(). The value of containers_parallel_degree, if set, will override the default DOP for a containers() query.
By default, a containers() query uses a degree of parallelism equal to (1 + number of open PDBs) in the case of CDB root and (1 + number of open application PDBs) in the case of application root.
If the value of CONTAINERS_PARALLEL_DEGREE is lower than 65535, then this value is used as the degree of parallelism of a query involving  containers(). Otherwise (when the value is 65535), the default degree of parallelism is (1 + number of open PDBs) or (1 + number of open application PDBs) as described above.
cursor_invalidation
CURSOR_INVALIDATION controls whether deferred cursor invalidation or immediate cursor invalidation is used for DDL statements by default.
data_guard_sync_latency
Data Guard SYNC latency
data_transfer_cache_size
DATA_TRANSFER_CACHE_SIZE sets the size of the data transfer cache (in bytes) used to receive data blocks (typically from a primary database in an Oracle Data Guard environment) for consumption by an instance during execution of an RMAN RECOVER ... NONLOGGED BLOCK command
default_sharing
DEFAULT_SHARING sets the value of the sharing clause in statements creating objects in an application root.
Specifying SHARING= in the create DDL overrides the value of the DEFAULT_SHARING parameter.
disable_pdb_feature *
 [undocumented]
enable_automatic_maintenance_pdb
Enable/Disable Automated Maintenance for Non-Root PDB
enable_dnfs_dispatcher
Enable DNFS Dispatcher
enabled_PDBs_on_standby
List of Enabled PDB patterns
encrypt_new_tablespaces
whether to encrypt newly created tablespaces
exafusion_enabled
Enable Exafusion
external_keystore_credential_location
external keystore credential location
inmemory_adg_enabled
Enable IMC support on ADG
inmemory_expressions_usage
Controls which In-Memory Expressions are populated in-memory
inmemory_virtual_columns
Controls which user-defined virtual columns are stored in-memory
instance_abort_delay_time
time to delay an internal initiated abort (in seconds)
instance_mode
indicates whether the instance read-only or read-write or read-mostly
long_module_action
Use longer module and action
max_datapump_jobs_per_pdb
maximum number of concurrent Data Pump Jobs per PDB
max_idle_time
maximum session idle time in minutes
max_iops
MAX IO per second
max_mbps
MAX MB per second
max_pdbs
max number of pdbs allowed in CDB or Application ROOT
ofs_threads
Number of OFS threads
one_step_plugin_for_pdb_with_tde *
[undocumented] Facilitate one-step plugin for PDB with TDE encrypted data
optimizer_adaptive_plans
controls all types of adaptive plans
optimizer_adaptive_statistics
controls all types of adaptive statistics
outbound_dblink_protocols
Outbound DBLINK Protocols allowed
remote_recovery_file_dest
default remote database recovery file location for refresh/relocate
resource_manage_goldengate
RESOURCE_MANAGE_GOLDENGATE determines whether Oracle GoldenGate apply processes in the database are resource managed.

To enable Resource Manager, set the RESOURCE_MANAGER_PLAN parameter.

By default, Oracle GoldenGate apply processes in the database are not resource managed. Given that replication to a PDB requires a separate Oracle GoldenGate apply process,
sga_min_size
SGA_MIN_SIZE sets the guaranteed SGA size for a pluggable database (PDB). When SGA_MIN_SIZE is set for a PDB, it guarantees the specified SGA size for the PDB.
Setting this parameter at the CDB level has no effect.
shrd_dupl_table_refresh_rate
duplicated table refresh rate (in seconds)
standby_db_preserve_states
STANDBY_DB_PRESERVE_STATES is meaningful on a physical standby database that is open in real-time query mode. The parameter controls whether user sessions and other internal states of the instance are retained when a readable physical standby database is converted to a primary database.

The possible values for the parameter are NONE, SESSION, and ALL
target_pdbs*
 [undocumented] Parameter is a hint to adjust certain attributes of the CDB
uniform_log_timestamp_format
UNIFORM_LOG_TIMESTAMP_FORMAT specifies that a uniform timestamp format be used in Oracle Database trace (.trc) files.

When the value of UNIFORM_LOG_TIMESTAMP_FORMAT is TRUE, the format used for timestamps in trace files is standardized on universal time with millisecond precision.