a
I am a highly motivated and organised professional with more than ten years of experience as a Database Specialist and Architect or designer.
Bring Me a Coffee - NZ$ 5

Author: Jairo Suarez Carrillo

Skill No 2 – Manage Backup and Restore Databases

Introduction:

In the era of digitalisation, data has become the backbone of every business. As a result, data security and reliability have become a top priority for businesses, and losing data can lead to disastrous consequences. Therefore, it is essential to manage backup and restore databases to ensure the safety of business-critical data.

Design a Backup Strategy:

A backup solution is essential for small to middle-sized businesses to ensure that their data is protected and can be recovered in the event of a disaster or system failure. A good backup solution should be reliable, easy to use, and cost-effective.

One option for small to middle-sized businesses is to use a cloud-based backup solution. Cloud-based backup solutions are typically easy to set up and use, and they offer a high level of reliability and security. With a cloud-based backup solution, data is automatically backed up to a remote server, which is stored securely and can be accessed and restored as needed.

Another option for small to middle-sized businesses is to use a local backup solution. This involves backing up data to an external hard drive or other storage device that is kept on-site. Local backup solutions can be cost-effective and offer fast data recovery times, but they require more management and maintenance than cloud-based solutions.

To design a backup strategy, one should consider the frequency of data changes, the volume of data, and the recovery time objective (RTO). In addition, it is essential to have a backup strategy that aligns with your business needs. Some of the critical factors to consider while designing a backup strategy are:

  1. Frequency of backup: How frequently do you need to back up your database?
  2. Backup types: Which types of backup do you need to take, full, differential or incremental?
  3. Backup location: Where to store the backup? Locally or on the cloud?
  4. Recovery time objective (RTO): What is the maximum duration of downtime that you can afford, and how quickly do you need to restore data?
  5. Recovery Point Objective (RPO) The RPO defines the maximum acceptable amount of data loss following a disaster incident. The RPO is commonly expressed in minutes.
  6. Recovery Level Objective (RLO) The RLO defines the granularity of the data that needs to be restored following a disaster incident.

To design a backup strategy, you need to take into account several factors, including:

  • The size of your database: A larger database will take longer to back up. Your database might grow to a size where the backup operation can no longer be completed within an appropriate maintenance window. You might have to use different hardware or redesign your database and backup strategy at that stage.
  • The structure of your database files A database that consists of a single primary data file will be difficult to back up within an appropriate maintenance window as it gets larger. You have no choice but to back up the database in its entirety. Alternatively, if the database consists of multiple secondary data files, these files can be backed up individually at different frequencies.
  • The speed/throughput of the network and storage.
  • How heavily utilised is the processor subsystem.
  • The volume of data modifications in the database.
  • The size of the data modifications in the database.
  • The type of data modifications in the database, for example if they are predominantly updated or insert operations.
  • How compressible is the data in the database. Does backup compression consume additional processor resources?
  • Whether point-in-time recovery is required If your organization requires a database to be recovered to a specific point-in-time, you will have no choice but to implement log backups.
  • The recovery objectives are defined. Your RPO, RTO, and RLO are critical to your backup strategy.
  • How the transaction log (archive logs in Oracle) is managed.
  • The database’s recovery model.
  • The importance of the data within the database. Some databases might not be important to your organization; they may be used in a staging or development environment, or they can be a replica of a production system. In such cases, there might be no business requirement to back up the database at all.

Types of backups:

SQL Server and Oracle support three types of backups: full, differential, and incremental.

  1. Full Backup: A full backup includes the entire database and is taken regularly. It is the most comprehensive backup and takes time and space to complete.
  2. Differential Backup: A differential backup includes only the changes made since the last full backup. It takes less time and space than a full backup.
  3. Incremental Backup: An incremental backup includes only the changes made since the last backup, whether a full or differential backup. It takes less time and space than both full and differential backups.

Manage Transaction Logs:

Transaction logs are records of all the transactions made on a database. Managing transaction logs is critical for database recovery. The transaction logs should be regularly backed up and monitored for unusual growth or issues. In Oracle database for example, this concept call archived log files.

Skill No 1. Encryption

Introduction

Database encryption increases the security of your data at rest and during transportation. With recent security vulnerabilities, many organisations have taken data encryption seriously. However, database management systems are a common target for attackers because they hold the most valuable asset for most organisations. Once an attacker has gained access to valuable data on your server, they will likely steal it. They then use the data to demand payment in exchange, manipulate data, or achieve monetary profit from the organisation they have attacked.

Security Regulations Compliance

Encryption is one of the most critical requirements for security regulations such as PCI-DSS. It is a statutory requirement. For example, all cardholder data must be encrypted (e.g., AES-256, RSA 2048), truncated, tokenised, or hashed (approved hash algorithms specified in FIPS 180-4: SHA-1, SHA-224, SHA-256, SHA-384 SHA-512, SHA-512/224, and SHA-512/256). Although this is not the only requisite for having encrypted data, PCI-DSS also needs that the PCI-DSS encryption key management process is supported (we are going to discuss this in the future)

Protecting Sensitive Data

With centralised key management and simple APIs for data encryption, encryption key management is ideal for protecting sensitive data. Examples of these key management include using Hashicorp Vault (open source) if you use the public cloud like OCI Oracle using Oracle’s manage keys, Amazon Web Service (AWS) Key Management, likely also talking about in the near future about this.

Data Encryption…What is it?

Encoding data is the process of encrypting it. It is primarily a two-way function, meaning encrypted data must be decrypted using a valid encryption key. Encryption is one such Cryptography technique. Encryption is a method of concealing information by altering it so that it appears to be random data – encryption methods can make your data (for example, messages) confidential. Still, other techniques and strategies are required to ensure the message’s integrity and authenticity. Encryption is primarily a mathematical process.

There are two basic types for encrypting data in a database. Data at rest and data in transit.

Data-at-Rest Encryption
Is data that is stored in a system; this data is encrypted using an algorithm to convert text or code into unreadable. To decode the encrypted data, you must have an encryption key. Encrypting an entire database should be done cautiously because it can significantly impact performance. As a result, it is best to encrypt only individual fields or tables. Data-at-rest encryption protects data from physical theft of hard drives or unauthorised file storage access. This encryption also complies with data security regulations, mainly if the filesystem contains financial or health data. For example, your PostgreSQL’s data_directory, MySQL/MariaDB data_dir, or MongoDB’s dbPath storage locations. Transparent Data Encryption (TDE) is a common process for providing encryption. The concept is mainly encrypting everything that is persistent. We are going to explain in detail Encryption on Oracle and SQL Server in detail.

Data in-Transit Encryption
Data-in-transit refers to data that is transferred or moved between transactions. This data type can be seen in the data that moves between the server and the client while browsing web pages. Because it is constantly in motion, it must be encrypted to prevent data theft or alteration before it reaches its destination. The ideal situation for protecting data-in-transit is to be encrypted before it moves and decrypted once it arrives at its destination.

Advantages of Data Encryption

  • It ensures the security of all of your data at all times.
  • Whatsoever times, privacy and sensitive information are protected.
  • It safeguards your data across devices.
  • Ensure government regulatory compliance.
  • It offers you a competitive advantage.
  • The presence of underlying encryption technology for data protection may increase trust.
  • Encrypted data is much more secure.

Disadvantages

Encryption employs complex and sophisticated mathematical operations to conceal the meaning of data. Depending on which cyphers or algorithms you use for hashing or deciphering the data. If your database is designed to handle many requests, it will saturate your resources, particularly the CPU.

Attempting to set up data encryption, such as TLS for in-transit or using RSA 2048 bits, can be prohibitively expensive if your financial resources have not been budgeted for this type of consequence. It consumes many resources and puts additional strain on the system’s processor.

Losing the data encryption keys, you will never lose your keys; keep them in a secure place.

Data encryption impacts recovery time, RTO

Encryption Architecture
To understand and implement encryption in SQL Server, you must understand its encryption hierarchy and key management architecture. Layers of encryption are protected by preceding layers of encryption that can use asymmetric keys, certificates, and symmetric keys. (See the graphic above)
  • Extensible Key Management
  • Service Master Key
  • Database Master Key
  • Asymmetric Key
  • Symmetric Key
  • Certificate
Implement column-level encryption
When implementing column-level encryption, consider the following.
  • Encrypted data cannot be compressed, but compressed data can be encrypted. When using compression, you should compress data before encrypting it for optimal results.
  • Stronger encryption algorithms consume more processors and resources. SQL Server 2016, the database can take advantage of hardware acceleration, using Intel AES-NI when performing encryption/decryption tasks.
  • Many database engines support algorithms compatibility 130 or above are AES.128, AES-192, and AES-256
Symmetric keys can encrypt and decrypt data quickly, but it’s more difficult to secure should a key get lost or fall into the wrong hands. They can be password-protected, though, meaning that someone would need to know the password in order to use the key for encryption and decryption. So there’s a little protection provided there against unauthorized use. 
Asymmetric keys work a little differently. These keys come in pairs, generally noted as public and private keys. The matching public key can only decrypt data encrypted with a private key and data encrypted with a public key can only be decrypted with the matching private key. This allows you to share the public key with anyone who needs to send you secure information. They can encrypt the data on their end with the public key and then transmit the encrypted values, and be sure that you will be the only one to decrypt them.

Cuantos tipos de Administrador de Datos existen?

Durante los último 15 años, creería, muchas personas me han preguntando que exactamente hago yo, en donde exactamente me ubico en el rol de Ingeniero IT. Bueno acá les voy a explicar un poco el rol de un Administrador de Base de Datos.
 
Existen Administradores de Base de datos que se centran en el diseño lógico y DBA’s que se centran en el diseño físico; los DBA’s que se especializan en sistemas de construcción y los DBA’s que se especializan en el mantenimiento y el perfomance de sistemas; el DBA Junior, en verdad, el trabajo de DBA abarca muchos roles. Lo explico con más detalle BIENVENIDOS!
Algunas organizaciones optan por dividir las responsabilidades del DBA en trabajos separados. Por supuesto, esto ocurre con mayor frecuencia en organizaciones más grandes, porque las organizaciones más pequeñas a menudo no pueden darse el lujo de tener múltiples especialidades de DBA. Les explico con detalle.

DBA System

Se enfoca en temas técnicos en lugar de comerciales, principalmente en el área de administración de los sistemas. Tareas típicas en la instalación física y el rendimiento del software DBMS (Database Management System) y puede incluir lo siguiente:
 
  • Instalación de nuevas versiones de motor de base de datos y aplicando las diferentes actualizaciones de mantenimiento suministradas por el proveedor de base de datos.
  • Parámetros del sistema, ajuste y perfomance del sistema manejador de base de datos.
  • Ajustes del sistema operativo, red y procesamiento de transacciones para trabajar con los sistemas y/o manejador de base de datos.
  • Asegurar el almacenamiento adecuado para los base de datos.
  • Vigiliar que los sistemas manejadores de base de datos funcionen con dispositivos de almacenamiento y software de administración etc.
  • Interfaz con cualquier otra tecnologías requeridas por las aplicaciones de la base de datos.
  • Instalación de alguna herramienta administrativa para DBA’s, estas rara vez se involucra con la implementación real de las bases de datos y las aplicaciones.
Un Ingeniero de Sistemas de Base de Datos, pueden involucrarse en la afinación de la aplicación cuando se deben alterar los parámetros del sistema operativo o los parámetros de DBMS complejos.

Arquitecto de Base de Datos

Algunas organizaciones crean una posición separada del grupo de administradores de base de datos, el arquitecto, este rol es importante para el diseño y la implementación de nuevas bases de datos. El arquitecto está involucrado en nuevos trabajos de diseño y desarrollo; él no está involucrado en mantenimiento, administración o perfomance de bases de datos y aplicaciones establecidas. El arquitecto diseña nuevas bases de datos para aplicaciones nuevas o existentes.
 
La justificación para crear una posición separada es que las habilidades necesarias para diseñar nuevas bases de datos son diferentes de las habilidades necesarias para mantener la ejecución de la base de datos existentes. Es más probable que un arquitecto de base tenga experiencia de modelado ambientes de base de datos que en administración. Administración es un pre-requisito para ser Arquitecto asi que el conocimiento debe tenerlo pero por obvias razones algunos detalles se van perdiendo con el tiempo o procedimientos cambian con las versiones de los motoroes de base de datos.
 
Las tareas típicas realizadas por el arquitecto de la base de datos incluyen:
 
  • Creación de un modelo de datos lógico (si no existe la posicion de modelador de datos).
  • Traducir modelos de datos lógicos en diseños de bases de datos físicos.
  • Implementar bases de datos eficientes, incluida la especificación de características físicas, diseñando índices eficientes y objetos de base de datos de mapeo a dispositivos de almacenamiento físico.
  • Análisis de los requisitos de acceso y modificación de datos para garantizar un diseño eficiente de la base de datos SQL y óptimo.
  • Creación de estrategias de copia de seguridad y recuperación para nuevas bases de datos.
La mayoría de las organizaciones no personalizan una posición de arquitecto de base de datos separada, lo que requiere que DBA’s trabajen en proyectos de base de datos nuevos y establecidos.
 

Application DBA

En contraste directo con el System DBA, es el Application DBA ó DBA de Aplicaciones. Este rol se centra en el diseño de la base de datos y el soporte continuo y la administración de bases de datos para una aplicación o aplicaciones específicas. Es probable que este rol sea un experto en la escritura y la depuración de SQL complejos y comprenda las mejores formas de incorporar solicitudes de base de datos en los programas de aplicación.
 
Application DBA también debe ser capaz de realizar la gestión del cambio de la base de datos, la perfomance del rendimiento y la mayoría de los otros roles del DBA. La diferencia es el enfoque de la aplicación DBA: está en un subconjunto específico de aplicaciones en lugar de la implementación general de DBMS y el entorno de la base de datos.
 
Los argumentos a favor de la aplicación DBA incluyen los siguientes:
 
  • Un Application DBA puede enfocarse mejor en una aplicación individual, que puede resultar en un mejor servicio a los desarrolladores de esa aplicación.
  • Un Application DBA se considera más a menudo como un componente integral del equipo de desarrollo y, por lo tanto, está mejor informado sobre los nuevos planes de desarrollo y los cambios.
  • Debido a que Application DBA funciona de manera consistente en un conjunto específico de aplicaciones, puede adquirir una mejor comprensión general de cómo funciona cada aplicación, lo que le permite respaldar mejor las necesidades de los desarrolladores de aplicaciones.
  • Con una comprensión más completa de la solicitud, un Application DBA tendrá una mejor comprensión de cómo la aplicación afecta al negocio general. Este conocimiento probablemente resultará en la ejecución de las tareas de DBA para apoyar mejor a la organización.
Hay muchos tipos de trabajos de gestión de datos y puede ser confuso cuando intenta hacer coincidir los títulos de trabajo contra las responsabilidades del trabajo. Este documento describe los distintos “trabajos” que pueden considerarse responsabilidades de administración física de base de datos.
 
Saludos;
 
Jairo Suarez Carrillo
Data Management Engineer
Database Architect

SQL o NoSQL Base de Datos – MongoDB

Hace unos días recibí un correo de uno de los suscriptores y me comentó acerca de MongoDB que le gustaria que hiciera un artículo relacionado a este nuevo motor. Entre las preguntas que me hacía es que si MongoDB era o no una base de datos SQL, entonces acá nace el interes de mi nota.
 
Hagámos un poco de Historia
Una compañia llamada 10gen empezó a desarrollar MongoDB en el año 2007 como componente de una plataforma planificada como producto de servicio, en otras palabras PaaS (Platform as a Service) por sus siglas en Inglés. En el 2013 10gen cambió su nombre como su motor de base de datos MongoDB Inc y cotiza en la bolsa de New York, su nombre de lista de NASDAQ es MDB.
 
Que es MongoDB? Es o no una base de datos SQL?
MongoDB es una base de datos de gestión documental con escalabilidad y flexibilidad, MongoDB también puede ser consultada e indexada a la medida de sus necesidades, es un motor NoSQL; que quiere decir NoSQL? OK, te explicaremos, no existe una definición exacta, me refiero que MongoDB tiene una amplia clase de sistemas de gestion de datos (mecanismo para almacenamiento y recuperación de datos) que difieren en aspectos. Patricio Cruz en LinkedIn nos ofrecio un fragmento muy importante, él nos dice, “MongoDB está orientada a documentos del tipo BJSON podríamos decir que es una variación del conocido JSON más eficiente y utiliza menos almacenamiento. Rápida integración con JavaScript. Rápida para sumar registros no tan eficiente en la recuperación de información con más de un nivel de profundidad.”
 
Imagina entonces que la placa verde es el servicio de MongoDB y todos sus procesos, donde la data esta representada en los bloques amarillos y blancos, dando asi un orden logico de la data y que pueda ser indexada de manera ordenada.
Características Claves en MongoDB
Alto Rendimiento:
MongoDB tiene un alto rendimiento en el procesamiento de la información, particularmente soporta modelos de datos integrados reduciendo asi I/O en el sistema.
Lenguaje de Alta Consulta o Gestión (Rich Query Languaje):
Lo he llamado así porque no tiene una traducción exacta, pero basicamente esto quiere decir tu puedes enviar multiples comandos para extraer la data deseada.
Alta Disponibilidad
Alta disponibilidad y replication puede ser configurada en motores MongoDB, “automatic failover” o base de datos en “espera” ante una falla o evento inesperado.
Escalabilidad Horizontal
Sharding distribuye datos a través de un grupo de máquinas, en otras palabras multiplica los datos en “bloques” grandes, para poner un símil perfecto es las lozas de un piso en un determinado espacio, estan distribuidas de manera horizontal y uniforme, de un solo color y forma.
Preguntas Frecuentes acerca de MongoDB
Que Plataformas MongoDB soporta?
  • x86_64
  • Platform Support EOL Notice Ubuntu 14.04 Support removed in MongoDB 4.2+. Debian 8 Support removed in MongoDB 4.2+.
  • Debian 7 Support was removed in MongoDB 4.0+, 3.6.6+, 3.4.16+, and 3.2.21+.
  • SLES 11Support removed in MongoDB 3.6.4+, 3.4.15+, and 3.2.20+.
  • Ubuntu 12.04Support removed in MongoDB 3.6.4+, 3.4.15+, and 3.2.20+.
Proximamente finalizará soporte sobre las siguientes plataformas:
  • Windows 7/2008R2 MongoDB finalizara el soporte en futuros lanzamientos.
  • Windows 8/2012 MongoDB finalizara el soporte en futuros lanzamientos.
  • Windows 8.1/2012R2 MongoDB finalizara el soporte en futuros lanzamientos.

 

Jairo Suarez Carrillo
Data Management Engineer — Architect

Preguntas que un empleador NO debería hacerte en entrevistas de trabajo.

Antes de dirigirse a una entrevista, es importante estar al tanto de las preguntas que los reclutadores y empleadores no deberían hacerle.
 
Los empleadores utilizan las entrevistas de trabajo como una forma de determinar qué tan adecuado es usted para un puesto, y la entrevista es una oportunidad ideal para discutir sus habilidades y experiencia.
 
Pero hay límites. Las preguntas que se le hagan en una entrevista deben referirse a su capacidad para realizar el trabajo.
 
Cada entrevista es diferente, pero lo más probable es que se enfrente a preguntas sobre su formación previa, educación y experiencia laboral. También es posible que le hagan preguntas para poner a prueba sus habilidades y sobre su personalidad y ética laboral.
 
Las preguntas que los empleadores no pueden hacerte legalmente.
 
Las preguntas que buscan información que no es relevante sobre qué tan apto eres para un puesto pueden ser inaceptables. Por ejemplo, es posible que las siguientes preguntas no ayuden al entrevistador a determinar si puede hacer bien el trabajo:
 
  • ¿Está casado?
  • ¿Por quién votaras en las próximas elecciones?
  • ¿Cuál es tu tendencia política?
  • ¿De qué religión eres?
  • ¿Está embarazada o planea formar una familia?
Además, si un empleador le pregunta sobre su orientación sexual, identidad de género, estado civil, religión, nacionalidad, origen étnico, opiniones políticas, estado laboral, edad o estado familiar, es posible que lo esté discriminando.
 
Sin embargo, existen algunas excepciones en las que se permite la discriminación. “No es necesario que le diga a un empleador cuántos años tiene cuando la edad no es relevante para su capacidad para realizar un trabajo, pero hay algunas excepciones limitadas en las que la edad será relevante para los requisitos del puesto”, dice Karen Alfonso Reina (Master Gerencia de Recursos Humanos de la Escuela de Negocios Europea). Una persona debe tener cierta edad para ingresar a un casino o bar, y podría ser necesario preguntar la edad del candidato para asegurarse de que pueda cumplir con el rol “.
 
Alfonso Reina señala que las preguntas sobre discapacidades pueden ser discriminatorias si no se relacionan con su capacidad para realizar el trabajo. “Se aplicarán excepciones si ciertas habilidades físicas son esenciales para el papel”, dice ella. Un ejemplo podría ser que un empleado necesite tener buena vista para operar un vehículo o maquinaria debido a requisitos de salud y seguridad.
 
¿Puede decirme X cosa acerca de su empleador actual y/o anterior?
 
Los empleados generalmente tienen un “deber de confidencialidad” con sus empleadores existentes o anteriores. Si un posible empleador hace una pregunta sobre secretos comerciales, listas de clientes o propiedad intelectual, entonces no debe responder porque puede estar incumpliendo su deber de confidencialidad
 
En resumen, si el entrevistador solicita detalles privilegiados sobre su empleador actual que no necesariamente tienen que ver con su trabajo, estas preguntas podrían ser inapropiadas.
 
Qué puede hacer si le hacen una pregunta que cree que es ilegal?
 
En algún momento, usted puede enfrentarse a una situación en una entrevista en la que tiene derecho a no responder una pregunta. En algunos casos, es posible que tenga el deber de no responder.
 
Ya sea que una pregunta sea ilegal o no, cuando estás ansioso por un papel, puede ser difícil negarte a responder una pregunta.
 
Una buena estrategia podría ser responder con una pregunta sobre cómo la pregunta es relevante para el puesto. Esto podría ser: “Me interesa saber cómo se relaciona eso con el puesto” ¿Puedes contarme un poco más, por favor?
 
Si el entrevistador no puede dar una explicación legítima, es posible que se sienta obligado a pasar rápidamente a otra pregunta.
 
Si cree que ha sido discriminado por cómo respondió una pregunta o porque se negó a responder una pregunta, usted puede presentar una queja ante la Comisión de Derechos Humanos del ministerio del trabajo de tu país. En última instancia, si se siente incómodo al responder una pregunta porque es discriminatoria o está obligado por la confidencialidad, debe negarse a responder.
 
En última instancia, lo que un empleador le pregunte en una entrevista debe relacionarse con el trabajo y qué tan apto es para él. Puede ser incómodo rechazar o evitar una pregunta, pero saber qué está fuera de los límites y tener una respuesta simple a mano puede ayudarlo a sentirse más seguro y en control.
 
Dejanos tus comentarios o experiencias si haz tenido que vivir situaciones incomódas.

Blockchain – Lo que deberías saber.

Durante algunas semanas he estado muy intensamente estudiando el tema, debo confesar que desde hace años soy un fan más de las cripto-monedas pero quise ir un poco más allá debido a mi especialidad a los datos. Por eso he hecho varias cursos y he leído mucho. Si tú estás interesado tambien este resumen es la mejor opción para comenzar.

Oracle 12c onwards – Multitenant Architecture

Several of our readers have suggested that we put information about Oracle 12c onwards and its new “Multitenant” concept, which is revolutionary instead of the traditional way but retains many of the concepts in its previous versions; my idea is to introduce them as quickly as possible to Oracle Database with advanced concepts already created and managed for 20 years, let’s get into the subject; CBD and PDB. Oracle 12c has made a big change in its architecture and has presented a new concept, Container Database and Pluggable Database; here we are going to present you a clear and precise concept with our methodology in BLOCKS.

Overview and History

Oracle 12c Release 1 (12.1) in 2013 introduces the concept of Multitenant for your star product Oracle Database 12c onwards. As many of you know, Oracle 11g opened many doors to those concepts such as Performance Diagnostics, SQL Tuning, Oracle Grid Control and many other enhancements. Many of you perhaps know that ‘g’ stands for ‘Grid’ which offers supporting grid computing features such as automatic load balancing, and after the 12c version, the letter has changed for ‘c’ stands for ‘Cloud’. Multitenant helps companies to consolidate databases into private or public clouds.

PDB, CDB and Root Concepts

What are PDB and CDB? Before starting with the definition of those new concepts, I will contextualise in easy words what CDB contains, basically Oracle metadata, in other words, sys and system schemas. PDB contains user data; in other words, our appreciate customer data.

About Containers Database

Every CDB has the following containers:

  • Exactly one root

The root stores Oracle-supplied metadata and common users. An example of metadata is the source code for Oracle-supplied PL/SQL packages. A common user is a database user known in every container. The root container is named CDB$ROOT.