Migrar la base de datos a Oracle Autonomous Database Cloud

 

Data Pump, SQL Loader, DBMS_CLOUD, GoldenGate

En esta entrada el blog vamos a dar una descripción general de alto nivel de las opciones disponibles para migrar la base de datos de On-Premise a Autonomous Database Cloud.
Primero, echaremos un ojo a las diferentes opciones disponibles para cargar los datos.

Opciones de carga de datos:

Cuando migra la base de datos a la base de datos autónoma, hay dos opciones disponibles para cargar datos:

• Desde "on-premise": puede cargar directamente sus datos desde su servidor local a la base de datos autónoma.
• Desde Object Storage Cloud: también puede cargar sus datos en Cloud Object Storage primero y luego migrar a la base de datos autónoma desde Object Storage Cloud. Este es un proceso rápido para la migración de bases de datos.

Diferentes métodos para migrar a la nube de base de datos autónoma:

Ahora, llegando a los diferentes métodos disponibles para migrar la base de datos de On-Premise a Autonomous Database Cloud, existen principalmente cuatro métodos de migración:

• Usando el paquete DBMS_CLOUD
• Uso de Data Pump
• Uso de SQL Loader
• Uso de Oracle GoldenGate

Usando DBMS_CLOUD:

El paquete DBMS_CLOUD admite la carga desde archivos en los siguientes servicios en la nube: Oracle Cloud Infrastructure Object Storage, Oracle Cloud Infrastructure Object Storage Classic, Azure Blob Storage y Amazon S3. Para cargar datos desde archivos en la nube, primero debe almacenar sus credenciales de almacenamiento de objetos en su Autonomous Data Warehouse y luego usar el procedimiento DBMS_CLOUD.COPY_DATA para cargar los datos.

A continuación se muestra el proceso de migración de alto nivel utilizando DBMS_CLOUD:

• Copia todos los archivos de datos (datafiles) en Object Storage on Cloud.
• Almacena sus credenciales de almacenamiento de objetos en su base de datos autónoma (ADB).
• Copia el archivo de datos en una tabla existente usando:

            DBMS_CLOUD.COPY_DATA

• Verifica el estado de la operación.

Utilizando Data Pump:

Oracle Data Pump proporciona un movimiento de datos masivo muy rápido entre las bases de datos de Oracle y el almacén de datos autónomo. Con este método, puede importar datos de archivos de Data Pump guardados en:

• Oracle Cloud Infrastructure Object Storage
• Microsoft Azure
• AWS S3
• Oracle Cloud Infrastructure Object Storage Classic. 

Puede guardar sus datos en su Cloud Object Store y usar Oracle Data Pump para cargar datos en Autonomous Data Warehouse. A continuación se muestra el proceso de migración de alto nivel utilizando Oracle Data Pump:

• Exporta datos en el modo de esquema.
• Copia los archivos de volcado en el objeto Storage on Cloud.
• Almacena las credenciales de almacenamiento de objetos en ADB.
• Importa utilizando el método impdp.
• Consulta los archivos de "log" para ver si hay algún problema.

Usando SQL Loader:

Puede utilizar Oracle SQL Loader para cargar datos desde archivos locales en su máquina a Oracle Autonomous Data Warehouse. El uso de SQL Loader es adecuado para cargar pequeñas cantidades de datos, ya que el rendimiento de la carga depende del ancho de banda de la red entre su cliente y Autonomous Data Warehouse. A continuación se muestra el proceso de migración de alto nivel utilizando SQL Loader:

• Configura el "Wallet"de conexión y las variables.
• Reúne uno o más archivos de datos.
• Crea un archivo de control (esto es opcional).
• Crea una tabla en la base de datos de destino.
• Carga utilizando SQL Loader.
• Comprueba los archivos de registro, incorrectos y descartados.

Usando Oracle GoldenGate:

También puede utilizar GoldenGate para replicar datos en Autonomous Data Warehouse utilizando Oracle GoldenGate On-Premises y Oracle GoldenGate Cloud Service. 

Asegúrese de utilizar las versiones 12.3.0.1.2 y posteriores de Oracle GoldenGate On-Premises como fuente, ya que solo estas versiones están certificadas con Oracle Autonomous Data Warehouse Cloud. 

Otras fuentes pueden ser Oracle Database Cloud Service u Oracle Exadata Cloud Service en Oracle Cloud. Sin embargo, no puede configurar Oracle Autonomous Data Warehouse Cloud Database como una base de datos de origen para Oracle GoldenGate On-Premises y solo las réplicas no integradas son compatibles con Oracle Autonomous Data Warehouse Cloud. A continuación se muestra el proceso de migración de alto nivel utilizando Oracle GoldenGate:

• Configura la base de datos autónoma para la replicación creando el esquema requerido, las tablas de destino, el nuevo usuario de destino, etc.
• Obtén las credenciales del cliente de Autonomous Database.
• Configura Oracle GoldenGate On-Premises para la replicación transfiriendo el archivo zip de las credenciales del cliente, configurando sqlnet.ora y tnsnames.ora, etc.
• Configura Oracle GoldenGate Manager y las réplicas no integradas para entregar a la base de datos autónoma.

Se trata de la migración a una base de datos autónoma y los métodos disponibles para la misma en pocas palabras.

¿Hay vida más allá de Oracle? Apache Kafka

 

Why Kafka?

La respuesta más conocida es que el autor de Apache Kafka quiso ponerle el nombre del escritor porque está optimizado para la escritura, y su favorito resultó ser Franz Kafka.

Aquí viene la ironía:

Eficiencia de la comunicación

• Kafka tenía serios problemas con su padre abusivo. En lugar de simplemente llamarlo para una charla, escribió una carta de 50 páginas. ¿No es esta forma de comunicación innecesariamente pesada?
• No le entregó la carta a su padre, sino que se la dio a su madre para que se la entregase a su padre. Su madre lo leyó y decidió no entregarlo. Ni siquiera se entregó, aquí viene la confiabilidad de la comunicación.

¿Qué es Apache Kafka?

Apache Kafka es una plataforma de software de procesamiento de flujo de código abierto desarrollada por Apache Software Foundation, escrita en Scala y Java. El proyecto tiene como objetivo proporcionar una plataforma unificada, de alto rendimiento y baja latencia para manejar las fuentes de datos en tiempo real. Kafka puede conectarse a sistemas externos (para importar / exportar datos) a través de Kafka Connect y proporciona Kafka Streams, una biblioteca de procesamiento de flujos de Java, cuya finalidad es la transmisión de eventos. .

¿Para qué puedo usar la transmisión de eventos?

La transmisión de eventos se aplica a una amplia variedad de casos de uso en una gran cantidad de industrias y organizaciones. Entre sus muchos ejemplos se incluyen:

• Para monitorizar transacciones bancarias y evitar el fraude bancario o el lavado de dinero (AML)
• Procesar pagos y transacciones financieras en tiempo real, como en bolsas de valores, bancos y seguros.
• Para rastrear y monitorear automóviles, camiones, flotas y envíos en tiempo real, como en la logística y la industria automotriz.
• Para capturar y analizar continuamente datos de sensores de dispositivos de IoT u otros equipos, como en fábricas y parques eólicos.
• Recopilar y reaccionar de inmediato a las interacciones y los pedidos de los clientes, como en el comercio minorista, la industria hotelera y de viajes y las aplicaciones móviles.
• Monitorear a los pacientes en la atención hospitalaria y predecir cambios en la condición para garantizar un tratamiento oportuno en emergencias, seria fantástico haber hecho una aplicación sanitaria para monitorizar a los pacientes de COVID. 
• Servir de base para plataformas de datos, arquitecturas basadas en eventos y microservicios.

¿Qué es la transmisión de eventos?

La transmisión de eventos es el equivalente digital del sistema nervioso central del cuerpo humano. Es la base tecnológica para el mundo 'siempre activo' donde las empresas están cada vez más definidas y automatizadas por software, y donde el usuario del software es más software.

Técnicamente hablando, la transmisión de eventos es la práctica de capturar datos en tiempo real de fuentes de eventos como bases de datos, sensores, dispositivos móviles, servicios en la nube y aplicaciones de software en forma de secuencias de eventos; almacenar estos flujos de eventos de forma duradera para su posterior recuperación; manipular, procesar y reaccionar a los flujos de eventos en tiempo real y retrospectivamente; y enrutar los flujos de eventos a diferentes tecnologías de destino según sea necesario. La transmisión de eventos asegura así un flujo continuo y una interpretación de datos para que la información correcta esté en el lugar correcto, en el momento correcto

Apache Kafka es una plataforma de transmisión de eventos.

¿Qué significa semejante unión de palabrotas?

Kafka combina tres capacidades clave para que pueda implementar sus casos de uso para la transmisión de eventos de un extremo a otro con una única solución probada en batalla:

Para publicar (escribir) y suscribirse a (leer) flujos de eventos, incluida la importación / exportación continua de sus datos desde otros sistemas.

Para almacenar transmisiones de eventos de forma duradera y confiable durante el tiempo que desee.

Procesar flujos de eventos a medida que ocurren o retrospectivamente.

Y toda esta funcionalidad se proporciona de manera distribuida, altamente escalable, elástica, tolerante a fallas y segura. Kafka se puede implementar en hardware bare-metal, máquinas virtuales y contenedores, tanto en las instalaciones como en la nube. Puede elegir entre la autogestión de sus entornos Kafka y el uso de servicios totalmente gestionados ofrecidos por una variedad de proveedores.

¿Cómo funciona Kafka, hablando claro?

Kafka es un sistema distribuido que consta de servidores y clientes que se comunican a través de un protocolo de red TCP de alto rendimiento. Se puede implementar en hardware bare-metal, máquinas virtuales y contenedores en entornos locales y en la nube.

Servidores: Kafka se ejecuta como un clúster de uno o más servidores que pueden abarcar varios centros de datos o regiones de la nube. Algunos de estos servidores forman la capa de almacenamiento, llamados brokers. Otros servidores ejecutan Kafka Connect para importar y exportar datos continuamente como flujos de eventos para integrar Kafka con sus sistemas existentes, como bases de datos relacionales y otros clústeres de Kafka. Para permitirle implementar casos de uso de misión crítica, un clúster de Kafka es altamente escalable y tolerante a fallas: si alguno de sus servidores falla, los otros servidores se harán cargo de su trabajo para garantizar operaciones continuas sin pérdida de datos.

Clientes: le permiten escribir aplicaciones distribuidas y microservicios que leen, escriben y procesan flujos de eventos en paralelo, a escala y de manera tolerante a fallas, incluso en el caso de problemas de red o fallas de la máquina. Kafka incluye algunos de estos clientes, que se complementan con docenas de clientes proporcionados por la comunidad de Kafka: los clientes están disponibles para Java y Scala, incluida la biblioteca Kafka Streams de nivel superior, para Go, Python, C / C ++ y muchas otras programaciones. idiomas y API REST.

Pongámonos más académicos, si cabe

Un evento registra el hecho de que "algo sucedió" en el mundo o en su negocio. También se le llama registro o mensaje en la documentación. Cuando lee o escribe datos en Kafka, lo hace en forma de eventos. Conceptualmente, un evento tiene una clave, un valor, una marca de tiempo y encabezados de metadatos opcionales.

Ejemplo

Clave de evento: "Mr traficante"

Valor del evento: "Hizo un pago de $ 200.000 a un testaferro conocido por Worldcheck"

Marca de tiempo del evento: "25 de junio de 2020 a las 2:06 p.m."

Los productores son aquellas aplicaciones cliente que publican (escriben) eventos en Kafka, y los consumidores son aquellos que se suscriben (leen y procesan) estos eventos. En Kafka, los productores y los consumidores están completamente desacoplados y son agnósticos entre sí, lo que es un elemento de diseño clave para lograr la alta escalabilidad por la que Kafka es conocido. Por ejemplo, los productores nunca necesitan esperar a los consumidores. Kafka ofrece varias garantías, como la capacidad de procesar eventos exactamente una vez.

Los eventos se organizan y almacenan de forma duradera en temas (Topic). Muy simplificado, un tema es similar a una carpeta en un sistema de archivos, y los eventos son los archivos en esa carpeta. Un ejemplo de nombre de tema podría ser "pagos". Los temas en Kafka siempre son de múltiples productores y múltiples suscriptores: un tema puede tener cero, uno o muchos productores que escriban eventos en él, así como cero, uno o muchos consumidores que se suscriban a estos eventos. Los eventos de un tema se pueden leer con la frecuencia necesaria; a diferencia de los sistemas de mensajería tradicionales, los eventos no se eliminan después del consumo. En su lugar, defina durante cuánto tiempo Kafka debe retener sus eventos a través de una configuración por tema, después de lo cual se descartarán los eventos antiguos. El rendimiento de Kafka es efectivamente constante con respecto al tamaño de los datos, por lo que almacenar datos durante mucho tiempo está perfectamente bien.

Los temas están divididos (partitioned), lo que significa que un tema se distribuye en varios "depósitos" ubicados en diferentes corredores de Kafka. Esta ubicación distribuida de sus datos es muy importante para la escalabilidad porque permite que las aplicaciones cliente lean y escriban los datos desde / hacia muchos corredores al mismo tiempo. Cuando se publica un nuevo evento en un tema, en realidad se agrega a una de las particiones del tema. Los eventos con la misma clave de evento (por ejemplo, un ID de cliente o vehículo) se escriben en la misma partición, y Kafka garantiza que cualquier consumidor de una partición de tema determinada siempre leerá los eventos de esa partición exactamente en el mismo orden en que fueron escritos.

Para que sus datos sean tolerantes a fallas (fault tolerant), incluidos ataque de expertos en seguridad maliciosos (los hackers son otra cosa),  y de alta disponibilidad (HA), todos los temas se pueden replicar, incluso en regiones geográficas o centros de datos, de modo que siempre haya varios corredores que tengan una copia de los datos en caso de que las cosas salgan mal, usted quiere realizar el mantenimiento de los corredores, etc. Una configuración de producción común es un factor de replicación de 3, es decir, siempre habrá tres copias de sus datos. Esta replicación se realiza a nivel de particiones de tema.

Si quieres seguir profundizando ...

Además de las herramientas de línea de comandos para tareas de gestión y administración, Kafka tiene cinco API principales para Java y Scala:

• La API de administración para administrar e inspeccionar temas, agentes y otros objetos de Kafka.
• Producer API para publicar (escribir) un flujo de eventos en uno o más temas de Kafka.
• La API del consumidor para suscribirse a (leer) uno o más temas y procesar el flujo de eventos que se generan en ellos.
• La API de Kafka Streams para implementar aplicaciones de procesamiento de flujos y microservicios. Proporciona funciones de nivel superior para procesar flujos de eventos, incluidas transformaciones, operaciones con estado como agregaciones y uniones, ventanas, procesamiento basado en el tiempo del evento y más. La entrada se lee de uno o más temas para generar resultados en uno o más temas, transformando efectivamente los flujos de entrada en flujos de salida.
• La API de Kafka Connect para crear y ejecutar conectores de importación / exportación de datos reutilizables que consumen (leen) o producen (escriben) flujos de eventos desde y hacia sistemas y aplicaciones externos para que puedan integrarse con Kafka. Por ejemplo, un conector a una base de datos relacional como PostgreSQL podría capturar todos los cambios en un conjunto de tablas. Sin embargo, en la práctica, normalmente no es necesario implementar sus propios conectores porque la comunidad de Kafka ya ofrece cientos de conectores listos para usar.

¿Quieres ver una explicación de Apache Kafka, por un experto?

Visualiza el siguiente video, el audio está en Inglés, pero puedes activar los subtítulos si lo deseas.

¿Hay vida más allá de Oracle? Apache Cordova

 

Visión general

Apache Cordova es un marco de desarrollo móvil de código abierto. Le permite utilizar tecnologías web estándar: HTML5, CSS3 y JavaScript para el desarrollo multiplataforma. Las aplicaciones se ejecutan dentro de envoltorios dirigidos a cada plataforma y dependen de enlaces API que cumplen con los estándares para acceder a las capacidades de cada dispositivo, como sensores, datos, estado de la red, etc.

Utiliza Apache Cordova si eres:

• Un desarrollador móvil y desea extender una aplicación a más de una plataforma, sin tener que volver a implementarla con el idioma y el conjunto de herramientas de cada plataforma.
• Un desarrollador web y desea implementar una aplicación web empaquetada para su distribución en varios portales de tiendas de aplicaciones.
• Un desarrollador móvil interesado en mezclar componentes de aplicaciones nativas con un WebView (ventana especial del navegador) que puede acceder a las API a nivel de dispositivo, o si desea desarrollar una interfaz de complemento entre componentes nativos y WebView.

Arquitectura

Hay varios componentes en una aplicación Cordova. El siguiente diagrama muestra una vista de alto nivel de la arquitectura de la aplicación Cordova..

Aplicación Web

Esta es la parte donde reside el código de su aplicación. La aplicación en sí se implementa como una página web, de forma predeterminada un archivo local llamado index.html, que hace referencia a CSS, JavaScript, imágenes, archivos multimedia u otros recursos necesarios para su ejecución. La aplicación se ejecuta en un WebView dentro del contenedor de la aplicación nativa, que distribuye a las tiendas de aplicaciones.

Este contenedor tiene un archivo muy importante: el archivo config.xml que proporciona información sobre la aplicación y especifica los parámetros que afectan su funcionamiento, como si responde a los cambios de orientación.

Plugins (complementos)

Los complementos son una parte integral del ecosistema de Cordova. Proporcionan una interfaz para que Cordova y los componentes nativos se comuniquen entre sí y se vinculan a las API de dispositivos estándar. Esto le permite invocar código nativo desde JavaScript.

El proyecto Apache Cordova mantiene un conjunto de complementos llamados Core Plugins. Estos complementos principales proporcionan a su aplicación para acceder a las capacidades del dispositivo, como la batería, la cámara, los contactos, etc.

Además de los complementos principales, existen varios complementos de terceros que proporcionan enlaces adicionales a funciones que no están necesariamente disponibles en todas las plataformas. Puede buscar complementos de Cordova mediante la búsqueda de complementos o npm. También puede desarrollar sus propios complementos, como se describe en la Guía de desarrollo de complementos. Los complementos pueden ser necesarios, por ejemplo, para comunicarse entre Cordova y componentes nativos personalizados.

Datos a tener en cuenta: 

• Cuando crea un proyecto de Cordova, no tiene ningún complemento presente. Este es el nuevo comportamiento predeterminado. Todos los complementos que desee, incluso los complementos principales, deben agregarse explícitamente.

• Cordova no proporciona widgets de interfaz de usuario ni marcos MV *. Cordova proporciona solo el tiempo de ejecución en el que se pueden ejecutar. Si desea utilizar widgets de UI y / o un framework MV *, deberá seleccionarlos e incluirlos en su aplicación.

Cordova presenta dos caminos de desarrollo

Cordova le proporciona dos flujos de trabajo básicos para crear una aplicación móvil. Si bien a menudo puede usar cualquiera de los flujos de trabajo para realizar la misma tarea, cada uno ofrece ventajas:

Flujo de trabajo multiplataforma (CLI): use este flujo de trabajo si desea que su aplicación se ejecute en tantos sistemas operativos móviles diferentes como sea posible, con poca necesidad de desarrollo específico de plataforma. Este flujo de trabajo se centra en la CLI de cordova. La CLI es una herramienta de alto nivel que le permite crear proyectos para muchas plataformas a la vez, abstrayendo gran parte de la funcionalidad de los scripts de shell de nivel inferior. La CLI copia un conjunto común de activos web en subdirectorios para cada plataforma móvil, realiza los cambios de configuración necesarios para cada uno y ejecuta scripts de compilación para generar binarios de aplicaciones. La CLI también proporciona una interfaz común para aplicar complementos a su aplicación. Para comenzar, siga los pasos de la guía Cree su primera aplicación. A menos que necesite un flujo de trabajo centrado en la plataforma, se recomienda el flujo de trabajo multiplataforma.

Flujo de trabajo centrado en la plataforma: utilice este flujo de trabajo si desea centrarse en la creación de una aplicación para una única plataforma y necesita poder modificarla en un nivel inferior. Debe utilizar este enfoque, por ejemplo, si desea que su aplicación combine componentes nativos personalizados con componentes de Cordova basados ​​en web, como se explica en Incrustar WebViews. Como regla general, use este flujo de trabajo si necesita modificar el proyecto dentro del SDK. Este flujo de trabajo se basa en un conjunto de scripts de shell de nivel inferior que se adaptan a cada plataforma admitida y una utilidad Plugman independiente que le permite aplicar complementos. Si bien puede usar este flujo de trabajo para crear aplicaciones multiplataforma, generalmente es más difícil porque la falta de una herramienta de nivel superior significa ciclos de compilación separados y modificaciones de complementos para cada plataforma.

Al comenzar, puede ser más fácil usar el flujo de trabajo multiplataforma para crear una aplicación, como se describe en la guía Cree su primera aplicación. Luego, tiene la opción de cambiar a un flujo de trabajo centrado en la plataforma si necesita el mayor control que proporciona el SDK.

NOTA: Una vez que cambie del flujo de trabajo basado en CLI a uno centrado en los SDK específicos de la plataforma y las herramientas de shell, no podrá regresar. La CLI mantiene un conjunto común de código fuente multiplataforma, que en cada compilación utiliza para escribir sobre el código fuente específico de la plataforma. Para conservar cualquier modificación que realice en los activos específicos de la plataforma, debe cambiar a las herramientas de shell centradas en la plataforma, que ignoran el código fuente multiplataforma y, en cambio, se basan en el código fuente específico de la plataforma.

Instalación de Cordova

La instalación de Cordova diferirá según el flujo de trabajo anterior que elija:

• Flujo de trabajo multiplataforma: consulte Crear su primera aplicación.

• Flujo de trabajo centrado en la plataforma.

Después de instalar Cordova, se recomienda que revise la sección Desarrollar para plataformas para las plataformas móviles para las que desarrollará. También se recomienda que también revise la Guía de privacidad y la Guía de seguridad.

Hay alternativas, si no encuentras que es tu framework ideal, echa un ojo en los siguientes links

• Bootstrap
• IONIC (€$ de pago)
• React Native
• Google Cobalt

The road to become a better DBA: Prepara tu laboratorio

Este es el inicio de una serie de artículos que me he propuesto llevar a cabo no solo para ilustrar a la gente de como prepararse para trabajar como DBA, sino para que Yo mismo mejore mis habilidades como administrador de base de datos y afronte todos los desafíos tecnológicos que estamos hartos de que nos bombardeen los partners, los clientes y los mandos. Y ya de paso me saque alguna certificación que no viene mal para el CV.

Como tenemos muchos casos de uso y escenarios, mi recomendación es crear 6 máquinas virtuales utilizando Oracle Virtualbox:

• Una VM con Oracle DB 12c R2 Single Instance + Oracle Data Guard
•  RAM: 4G
• / = 10G; SWAP = 8G; / u01 = 40G (Binarios Oracle + Archivos de datos)

• Una VM con Oracle Enterprise Manager 13c + Oracle Data Guard
• RAM: 6G
• / = 10G; SWAP = 8G; / u01 = 70G (Binarios Oracle + Binarios EM + Archivos de datos)

• Una VM con Oracle Real Application Clusters 12c Nodo 1 - Hub
• Una VM con Oracle Real Application Clusters 12c Node 2 - Hub
• Una VM con Oracle Real Application Clusters 12c Node 3 - Hub
• Una VM con Oracle Real Application Clusters 12c Nodo 4 - Leaf

    Para todos los RACs:

•     RAM: (hub con mgmtdb: 4G / otros hubs: 3.4G / Leafs: 1.6G)
•     / = 10G; SWAP = 8G; / u01 = 16G (Binarios Ora)

Con esos 6 servidores, puedes practicar:

• Instancias individuales (CDB + Clone no CDB + PDB) y EM utilizando los servidores 1 y 2 anteriores.

• DataGuard con Primary + Far Sync + Physical / Logical Stdby, que también utiliza los servidores 1 y 2. Puede simular instancias de Far Sync al crearlas en el mismo servidor.
• RAC (nodos Hub o Leaf) con los Servidores 3 a 6 (use los Servidores 5 y 6 para jugar agregando / eliminando nodos)

Como el objetivo no es enseñar a instalar Oracle Linux ni la Base de datos vamos a obviar estos pasos hay cientos de web que te explican paso a paso como hacerlo. Recomiendo usar Oracle Linux 6 o 7 y como guía usaría las sabias palabras de Tim Hall en su entrada del blog:

• Oracle Database 12c Release 2 (12.2) Installation On Oracle Linux 6 (OL6) and 7 (OL7)

Cuando se utiliza un portátil con memoria de 16 GB para practicar con las máquinas virtuales de Virtualbox, será difícil tener todas las máquinas en funcionamiento al mismo tiempo. Así que solo se  activan las máquinas que son necesarias para cada escenario.

Es bueno crear máquinas virtuales con la menor memoria RAM y disco posible asignadas.

Utilización de la memoria RAM de Oracle Linux 6/7 con w / o Grid u software de Oracle - 157 MB.

Por lo tanto, 4 GB de RAM deberían ser suficientes para todos los escenarios (excepto la máquina de EM, que recomiendo 6 GB)

En todos los servidores recomiendo alrededor de 10G para "/" y 8G para SWAP (mantenga sus instaladores descomprimidos en una carpeta externa compartida).

En los servidores RAC, agregue discos externos para discos ASM.

Con todas estas indicaciones nos servirá para empezar al trabajar con nuestras bases de datos y ahondar en los temas de administración que merecen repaso durante estos meses.

Características claves de Oracle Autonomous Database.

Hoy traigo las principales ideas que han comentado los miembros de Oracle Corp. En una videoconferencia que han tenido la amabilidad de invitarme. Dentro de estas características claves, en la base de datos autónoma de Oracle 19C tenemos:

Autoconducción (Self Driving)

• Capacidades y beneficios de las bases de datos Autónomas
• Manejo de Atributos
• Ajuste automático de sentencias
• Escalado Automático
• Indexación automatizada
• Gestión Automatizada

Auto asegurado (Self Securing)

• Autoreparación del Hardware
• Autoreparación del Software
• Resolución automática de incidencias mediante Machine Learning (ML)
• Arquitectura de Máxima Disponibilidad (MAA)

Auto Reparado (Self reparing)

• Seguridad en la base de datos autónoma
• Cifrado por defecto
• Auto-parcheado
• Protección frente a ataques externos
• Separación de roles
• Auditoria

Autoconducción (Self Driving)

Capacidades y beneficios de las bases de datos Autónomas

Manejo de Atributos

Ajuste automático de sentencias

Escalado Automático

Indexación automatizada

Gestión Automatizada

Auto asegurado (Self Securing)

Autoreparación del Hardware

Autoreparación del Software

Resolución automática de incidencias mediante Machine Learning (ML)

Arquitectura de Máxima Disponibilidad (MAA)

Auto Reparado (Self reparing)

Seguridad en la base de datos autónoma

Cifrado por defecto

Auto-parcheado

Protección frente a ataques externos

Separación de roles

Auditoria

Estos han sido los factores claves de la Base de datos Autónoma de Oracle.

¿Qué es la arquitectura de datos?

En tecnología de la información, la arquitectura de datos se compone de modelos, políticas, reglas o estándares que rigen qué datos se recopilan y cómo se almacenan, organizan, integran y utilizan en los sistemas de datos y en las organizaciones. [1] Los datos suelen ser uno de varios dominios de arquitectura que forman los pilares de una arquitectura empresarial o arquitectura de solución. [2]

[1] Business Dictionary - Data Architecture*TOGAF® 9.1 - Phase C: Information Systems Architectures - Data Architecture

[2] What is data architecture GeekInterview, 2008-01-28, accessed 2011-04-28

La arquitectura de datos define los flujos de información en una organización y cómo se controlan. Un arquitecto de datos es responsable de comprender los objetivos comerciales y la infraestructura y los activos de datos existentes; definición de principios de arquitectura de datos; y dar forma a la arquitectura de datos empresariales para proporcionar mayores beneficios a la organización.

Algunos conceptos básicos en arquitectura de datos:

• Modelo de datos conceptual: muestra entidades de datos como clientes, productos y transacciones, y su semántica.
• Modelo lógico: define los datos con el mayor detalle posible, incluidas las relaciones entre los elementos de datos, pero sin considerar cómo se almacenan o administran los datos.
• Modelo de datos físicos: define cómo se representan y almacenan los datos, por ejemplo, en un archivo plano, base de datos, almacén de datos, almacén de valores clave.

¿Quién está involucrado en la arquitectura de datos?

Los siguientes roles existen para ayudar a dar forma y mantener una arquitectura de datos moderna:

• Arquitecto de datos: define la visión de los datos en función de los requisitos comerciales, los traduce a los requisitos tecnológicos y define los estándares y principios de datos.
• Responsable de proyectos: supervisa proyectos que modifican flujos de datos o crean nuevos flujos de datos.
• Arquitecto de soluciones: diseña sistemas de datos para cumplir con los requisitos empresariales.
• Arquitecto en la nube o ingeniero de centro de datos: prepara la infraestructura en la que se ejecutarán los sistemas de datos, incluidas las soluciones de almacenamiento.
• DBA o ingeniero de datos: crea sistemas de datos, los completa con datos y se ocupa de la calidad de los datos.
• Analista de datos: un usuario final de la arquitectura de datos, lo utiliza para crear informes y administrar una fuente de datos continua para la empresa.
• Científicos de datos: también usuarios de la arquitectura de datos, que aprovechan para extraer datos de la organización para obtener nuevas perspectivas.

El papel del arquitecto de datos

¿Qué habilidades ayudan a alguien a convertirse en un arquitecto de datos?

• Comprender y comunicar cómo los datos impulsan el negocio.
• Capaz de trabajar con diversas fuentes de datos, comprender su estructura, contenido y significado.
• Profundamente informado sobre herramientas y tecnologías de datos.

¿Cómo se puede formar un candidato a ser arquitecto de datos?

La capacitación de arquitectos de datos generalmente ocurre en el trabajo, en roles relacionados con datos como ingeniero de datos, científico de datos o arquitecto de soluciones. No existe un programa de certificación o capacitación estándar de la industria para arquitectos de datos, pero es valioso para los arquitectos tener certificación en las plataformas de datos primarias utilizadas por su organización. Algo así como un OCP, en el caso de Bases de datos Oracle.

¿Cuáles son los roles y responsabilidades del arquitecto de datos?

·         Traduce los requisitos del cliente o de su organización a especificaciones técnicas:

o   flujos de datos

o   transformaciones

o   integraciones

o   bases de datos

o   almacenes de datos (datawarehouse)

• Define los estándares y los principios de la arquitectura de datos: modelado, metadatos, seguridad, datos de referencia como códigos de productos y categorías de clientes, y datos maestros como clientes, proveedores, materiales y empleados.
• Define una arquitectura de referencia: un patrón que otros en la organización pueden seguir para crear y mejorar los sistemas de datos.
• Define los flujos de datos: qué partes de la organización generan datos, qué datos requieren para funcionar, cómo se gestionan los flujos de datos y cómo cambian los datos en la transición.
• Colaboración y coordinación: los proyectos de datos a menudo abarcan múltiples departamentos y partes interesadas, así como socios y proveedores externos; El arquitecto de datos es un punto focal que coordina a todas las partes en torno a los objetivos de la organización.

¿Cómo puede ayudar la tecnología?

Hace muchos años, la infraestructura de datos era monolítica. Las organizaciones invirtieron millones en grandes sistemas que almacenarían y procesarían todos los datos de la organización. Con el advenimiento de la tecnología de código abierto y las metodologías ágiles, los sistemas de datos se están volviendo más simples y más livianos, en algunos casos, y al mismo tiempo más efectivos y más flexibles.

Las herramientas tecnológicas que nos encontramos son:

• Contenedores: plataformas como Docker y Kubernetes ayudan a acelerar e implementar la infraestructura de datos con solo hacer clic en un botón, y orquestar sistemas complejos de manera flexible y escalable.
• Almacén de datos: una piedra angular de la infraestructura de datos de la vieja escuela, los almacenes de datos siguen siendo importantes, pero se están trasladando a la nube e interactuando con lagos de datos, bases de datos tradicionales y fuentes de datos no estructuradas
• Base de datos relacional: los antiguos dominadores como Oracle, DB2, o incluso SQL Server, todavía están en uso, pero las alternativas de código abierto como MariaDB, MySQL y PostgreSQL están en todas partes
• Base de datos NoSQL: almacenas cantidades masivas de datos semiestructurados y no estructurados. Las soluciones populares son Redis, MongoDB o Cassandra.
• Transmisión en tiempo real: nuevas herramientas como Apache Kafka, ElasticSearch Logstash, Flume y AWS Kinesis ayudan a transmitir grandes volúmenes de datos desde los registros del sistema y los sistemas de producción.
• Microservicios y computación sin servidor: los sistemas de datos creados utilizando microservicios o funciones como servicio (FaaS) son unidades independientes que exponen una interfaz estándar, lo que permite a los arquitectos de datos componer y organizar entornos de datos para satisfacer las necesidades del negocio.

Prácticas que mejorarán la arquitectura de datos

Las siguientes prácticas pueden ayudarnos a lograr una arquitectura de datos más efectiva:

• Vea los datos como activos compartidos: elimine los silos organizativos y vea los datos de los clientes de manera integral, combinando datos de todas las partes de la organización.
• Diseñar e implementar las interfaces adecuadas para que los usuarios consuman datos: los datos son insignificantes si no se pueden consumir de manera conveniente. Las interfaces pueden ser paneles basados ​​en web, BI, consultas SQL, R o cualquier otra cosa que los usuarios comerciales o analistas utilicen para obtener información.
• Asegurar el control de acceso: clasifique los datos de acuerdo con su sensibilidad e importancia comercial, y diseñe cuidadosamente los controles de acceso para garantizar que los datos estén fácilmente disponibles, pero solo para aquellos que lo requieran.
• Apoyar la administración del dato: los administradores de datos son expertos en la materia que pueden ayudar a limpiar, verificar y agregar datos de la organización. Por ejemplo, un gerente de línea de productos que tiene una visión especial de miles de productos. Construya una comunidad de administradores de datos, contribuyentes y ciudadanos de datos que puedan mejorar la calidad de los datos para todos.
• Conservación de los datos: considere qué datos son realmente procesables para diferentes roles organizativos y cree procesos para seleccionar los datos más relevantes. Más allá de la curación de arriba hacia abajo, permita a los usuarios realizar fácilmente filtros y consultas para obtener datos relevantes más rápido.
• Elimine las copias y el movimiento de datos: en las grandes organizaciones, es difícil estandarizar los datos sin reglas estrictas que sofocan la creatividad. Esfuércese por crear formatos y estructuras de datos que alienten a los usuarios a colaborar en las mismas entidades de datos, en lugar de crear múltiples versiones de la misma entidad.
• Automatizar todo lo que sea posible: la clave para una arquitectura de datos eficiente.

¿Hay vida más allá de Oracle? KQL: Kibana Query Language

Este tutorial es una explicación breve sobre cómo escribir consultas en Kibana, en la barra de búsqueda en la parte superior, o en Elasticsearch, utilizando la consulta de cadena de consulta. El lenguaje de consulta utilizado es en realidad el lenguaje de consulta de Apache Lucene, ya que es Lucene  el motor utilizado en Elasticsearch para indexar datos.

Comprender cómo se indexan sus datos en Elasticsearch influye en gran medida en qué y cómo puede buscar con sus consultas. Por eso esta no solo será otra entrada del Lucene query parser.

Por lo tanto, el tema de este tutorial no es solo explicar el lenguaje de consulta, sino también explicar por qué puede o no encontrar sus documentos almacenados en Elasticsearch.

Indexación de documentos

Primero, es crucial entender cómo Elasticsearch indexa los datos. Por lo tanto, ponemos los siguientes dos documentos en nuestra instancia de Elasticsearch.

:

{

  "title": "Lord Jim",

  "author": "Joseph Conrad"

}

{

  "title": "The Last Command",

  "author": "Timothy Zahn"

}

{

  "title": "Heart of Darkness",

  "author": "Joseph Conrad"

}

Si no cambiamos nada en las asignaciones de Elasticsearch para ese índice, Elasticsearch detectará automáticamente la cadena como el tipo de ambos campos al insertar el primer documento.

¿Qué hace un analizador?

Un analizador tiene varios tokenizadores y / o filtros adjuntos. El tokenizer obtendrá el valor del campo que se debe indexar (por ejemplo, "The Heart of Darkness") y puede dividir el valor en varios fragmentos que el usuario debería poder buscar (más en un momento). Los filtros de un analizador pueden transformar o filtrar tokens que produce el tokenizador.

Todas las fichas resultantes se almacenarán en un llamado índice invertido. Ese índice contendrá todos los tokens producidos por el analizador y un enlace a cuál de los documentos los contenían.

Por lo tanto, si el usuario presenta Elasticsearch con una palabra de búsqueda, solo tiene que buscarlo en el índice invertido y verá instantáneamente qué documentos debe devolver. Dado que no especificamos ninguna asignación para nuestro índice de Elasticsearch, los campos de la cadena de tipo se analizarán con el Analizador Estándar de forma predeterminada.

Este analizador dividirá primero el valor del campo en palabras (utilizará caracteres de espacio y puntuación como límites) y luego utilizará un filtro para transformar todas las fichas en minúsculas. Después de insertar los dos documentos anteriores, el índice invertido para el campo de título se vería de la siguiente manera, con 1 que se refiere al primer documento “Lord Jim”, 2 al segundo. "The Last Command" y 3 al tercero que se refieren al "The heart of Darkness":

Término	Documento
lord	1
jim	1
the	2,3
last	2
command	2
heart	3
of	3
darkness	3

También se creará un índice invertido para el campo de autor. Este contendrá cuatro entradas: una para “Timothy”, otra para  “Zahn” una para "Joseph" y otra para "Conrad" que están vinculadas a ambos documentos.

Ese índice invertido ahora permite a Elasticsearch buscar rápidamente qué documentos devolver para una búsqueda si el usuario busca "guía". Además, los Términos-Agregación en Elasticsearch / Kibana solo analizan ese índice invertido y devuelven los términos que tienen los documentos más / menos (según el orden especificado por el usuario) adjuntos.

Mapeos en Elasticsearch

Si inserta datos en elasticsearch, eso no es realmente texto, pero, por ejemplo, una URL o similar que el análisis predeterminado no tiene mucho sentido. Especialmente si va a visualizar sus datos con Kibana, no desea que un gráfico de las URL más visitadas contenga una entrada para "http" y la ruta de acceso se divide en cada barra. Le gustaría tener una entrada por dominio real. Lo que desea es que Elasticsearch no analice los valores de sus documentos.

Por lo tanto, debe definir una asignación para su índice manualmente. Esto no está cubierto en ese tutorial, pero eche un vistazo a la documentación oficial. Si específica “index: not_analyzed“ en el mapeo, el índice invertido para el campo del título se vería de la siguiente manera:

Término	Documento
Lord Jim	1
The Last Commnad	2
The heart of darkness	3

Y el índice invertido del campo de autor ahora se vería así.

Término	Documento
Joseph Conrad	1,3
Timothy Zahn	2

Como ves, Elasticsearch ya no divide los valores y tampoco los transforma en minúsculas. Ya sea que sus valores sean analizados o no (es decir, qué términos están en el índice invertido) tienen un gran impacto en qué y cómo puede buscar, como veremos en las siguientes secciones.

Cuando hablamos de los "datos analizados", esto significa que tiene los datos en los campos de cadena analizados. Cuando hablamos de "datos no analizados", esto significa que usted tiene una asignación que tiene ambos campos como no analizados.

Ahora explicaremos cómo Elasticsearch indexa los datos, podemos continuar con el tema real: la búsqueda.

Las siguientes consultas siempre se pueden usar en Kibana en la parte superior de la pestaña Descubrir, su visualización y / o paneles de control. Además, estas consultas se pueden usar en la consulta de cadena de consulta cuando se habla directamente con Elasticsearch.

Empecemos con el autor de la consulta bastante simple: joseph. Si ingresa esta consulta en el conjunto de datos analizado, Elasticsearch devolverá ambos documentos. ¿Por qué? Buscará el término "joseph" en el índice invertido para el campo del autor. Está allí enlazando a ambos documentos, por lo que Elasticsearch devolverá esos dos documentos como resultados.

Si utilizará la misma búsqueda en el conjunto de datos no analizados, no obtendrá ningún resultado. ¿Por qué? Elasticsearch busca de nuevo "joseph" en el índice invertido. No hay ninguna entrada para solo "joseph" como término (solo para "Joseph Conrad"), por lo que no devolverá ningún resultado.

Si intenta buscar el autor: Conrard (primera letra en mayúscula) en los datos analizados, obtendrá como resultado ambos documentos. ¿Por qué? Debido a que Elasticsearch reconoce que el campo del autor ha sido analizado e intenta aplicar el mismo analizador a su consulta de búsqueda "Conrad", significa que también se transformará en minúsculas antes de que se busque en el índice invertido. Por eso sigue encontrando los documentos. La misma consulta en datos no analizados aún no producirá ningún resultado, ya que no hay ninguna entrada para "Joseph" (solo para "Joseph Conrad").