28 noviembre 2020

Copias de seguridad gestionadas por el usuario en Oracle

 

Empezaremos esta entrada en el blog, con la ortodoxia de una definición canónica de copia de seguridad (backup).

Definición: La copia de seguridad es una copia real y coherente de los datos de la base de datos que podría usarse para reconstruir los datos después de un incidente.

Hay dos tipos de respaldo
  • Copia de seguridad física
  • Copia de seguridad lógica


Copia de seguridad física (Physical Backup)

Copia de todos los archivos de datos físicos necesarios para realizar la restauración y recuperación de la base de datos,
Este tipo de copia de seguridad incluye una copia de los archivos siguientes
  • Archivos de información
  • Controlar archivos
  • Archivos de parámetros
  • Archivos de registro archivados
Las diferentes opciones para realizar copias de seguridad físicas son
  • Técnicas gestionadas por el usuario
  • RMAN (Recovery Manager)

Copia de seguridad lógica (Logical Backup)

Oracle utiliza la bomba de datos de Oracle para permitirnos generar una copia de seguridad lógica que se puede utilizar para migrar datos, incluso hacer una recuperación parcial o total de la base de datos.
  • exp / expdp
  • imp / impdp

Diferencia entre restauración y recuperación

Restaurar: acto que implica la restauración de todos los archivos que serán necesarios para recuperar su base de datos a un estado consistente. por ejemplo, copiando todos los archivos de respaldo desde una ubicación de respaldo como TAPE o DISK

Recuperar: es un proceso para aplicar todos los registradores de transacciones en el registro de archivo, avanzando su base de datos hasta un punto en el tiempo.

Copias de seguridad gestionadas por el usuario

Backpup en Frio

Esta es la única forma posible para que el DBA realice una copia de seguridad coherente de la base de datos independientemente del modo de la base de datos (archivelog o noarchivelog). A continuación se explican los pasos:
  • Si la base de datos se está ejecutando, bájela completamente en un modo consistente (usando el apagado (solo NORMAL / INMEDIATO / TRANSACCIONAL). Esto asegurará que el encabezado de todos los archivos de la base de datos se actualice al mismo SCN
  • Copia de seguridad de todos los archivos de datos, archivos de control, archivos de parámetros mediante el comando de copia del sistema operativo
  • Iniciar la base de datos
  • Archive todos los registros de rehacer no archivados utilizando el siguiente comando y cópielos en la ubicación de la copia de seguridad.
alter tablespace SIGE_TBS offline normal;

Copia de seguridad de datos sin conexión (Offline)

Suponga que desea realizar una copia de seguridad sin conexión de uno o más espacios de tabla, el método de copia de seguridad sin conexión le ayudará a lograr lo mismo, tenga en cuenta que el espacio de tabla SYSTEM y el espacio de tabla UNDO con deshacer activo no se pueden desconectar.
suponga que el espacio de tabla es SIGE_TBS:

  • Identifique todos los archivos de datos asociados con el espacio de tabla mediante la vista dba_data_files

select tablespace_name,file_name from dba-data_files from dba_data_files where tablespace_name='SIGE_TBS';

  • Ponga el espacio de tabla fuera de línea usando la prioridad normal (no use temporal e inmediato, requerirá recuperación en el momento de poner el espacio de tabla en línea)

alter tablespace SIGE_TBS offline normal;

  • Haga una copia de seguridad de todos los archivos de datos relacionados con el espacio de tabla mediante el comando de copia del sistema operativo.
  • Ponga el tablespace en línea.

alter tablespace SIGE_TBS online;

Archive todos los registros de rehacer no archivados y copie el registro archivado en la ubicación de la copia de seguridad.

alter system archive log current;

Backups en caliente

Esto se ha introducido en la versión 6 de Oracle, pero inicialmente estaba vinculado solo al espacio de tabla, a partir de la versión 10 también incluían toda la base de datos. Esto nos permite realizar copias de seguridad en caliente de la base de datos o el espacio de tabla sin necesidad de cerrar la base de datos.
Al realizar una copia de seguridad en caliente, Oracle deja de registrar puntos de control en todos los archivos de datos asociados.
A continuación se muestran dos cosas que suceden internamente mientras la base de datos se pone en modo BEGIN BACKUP:

  • Se establece una bandera de respaldo activo en el encabezado del archivo de datos
  • Se produce un punto de control, parpadeo de todos los bloques sucios de la memoria al disco, sincronizando todos los encabezados de los archivos de datos al mismo SCN y congelando los encabezados para lograr coherencia, protección y capacidad de recuperación.
Se pueden realizar copias de seguridad en caliente en toda la base de datos, el espacio de tabla o incluso a nivel de contenedor, esto requiere un proceso de recuperación después de que se restaure la copia de seguridad, por lo que siempre realice una copia de seguridad de todos los archivos de registro archivados necesarios.

Copia de seguridad en caliente de toda la base de datos
Para realizar este tipo de copia de seguridad, debemos poner nuestra base de datos en modo de copia de seguridad usando 'alter database begin backup;'
Este es el tipo más común de copia de seguridad administrada por el usuario que utiliza DBA en todo el mundo.
A continuación se muestran los pasos:
  • Coloque la base de datos en modo de respaldo.
alter database begin backup;
  • Haga una copia de seguridad de todos los archivos de datos y archivos de parámetros utilizando el comando de copia del sistema operativo-
  • Saque la base de datos del modo de respaldo.
alter database end backup;
  • Archivar todos los registros no archivados y copiarlos como respaldo.
  • Crear copia del archivo de control como seguimiento.
alter system archivelog current;
  • modifique el archivo de control de copia de seguridad de la base de datos a '/control_file.trc;
alter system archive log current;


Copia de seguridad en caliente de la base de datos de contenedores
Como se introdujo en Oracle 12c, puede realizar una copia de seguridad administrada por el usuario de toda la base de datos del contenedor o del único PDB raíz o individual.

Base de datos de contenedores completa:

A continuación se muestran los pasos mencionados:
  • Inicie sesión en la base de datos utilizando un usuario que tenga privilegios de sysdba o sysbackup.
sqlplus /nolog

connect system@container1

  • Coloque su base de datos en modo de respaldo.ç
alter database begin backup;
  • Modificar la base de datos comenzar la copia de seguridad;
select file_name from dba_data_files;
  • Identifique todas las bases de datos relacionadas con la base de datos del contenedor usando el siguiente comando.
select file_name from dba_data_files;
  • Copie toda la base de datos usando el comando de copia del sistema operativo.
  • Saque la base de datos del modo de respaldo.
alter database end backup;
  • Archivar todos los registros no archivados y copiarlos como respaldo.
alter system archivelog current;
  • Crear copia del archivo de control como seguimiento.
alter database backup controlfile to '/control_file.trc;

ROOT solo o PDB individual

A continuación se muestran los sencillos pasos para completar la copia de seguridad en caliente de root contenedor o base de datos conectable individual.

  • Conectar a la raíz o base de datos conectable individuo con usuario tenga privilegios SYSDBA o sysbackup.
sqlplus /nolog
connect system

alter session set container= tech_pdb;

  • Identifique todos los archivos de datos que forman parte de PDB usando la vista dba_data_files.

select file_name from dba_data_files;
  • Coloque la base de datos conectable en modo de respaldo.
alter pluggable database tech_pdb begin backup;
  • Copie todos los archivos de datos usando el comando de copia del SO.
  • Saque la PDB del modo de inicio de copia de seguridad.
alter pluggable database tech_pbd end backup;
  • Archivar todos los registros no archivados y copiarlos como respaldo
alter system archivelog current;
  • Crear una copia del archivo de control como seguimiento

alter database backup controlfile to '/control_file.trc;

Controlar la copia de seguridad de archivos
Hay dos formas de recuperar el control
  • Copia de seguridad binaria
  • Copia de seguridad de archivos de texto
Tener una copia de seguridad válida del archivo de control de una base de datos es crucial para la recuperación exitosa de la base de datos.

Copia de seguridad binaria
Se puede realizar una copia binaria del archivo de control mediante una declaración SQL. Esta copia contiene información adicional, como el historial de registro de rehacer archivado, rango fuera de línea para espacios de tabla de solo lectura y fuera de línea, entradas de archivos temporales y conjuntos de respaldo de RMAN y copias de datos.
comando para tomar una copia de seguridad binaria.

alter database backup controlfile to '';

Copia de seguridad de archivos de texto
Este tipo de copia de seguridad contiene una instrucción create controlfile basada en el archivo de control actual en uso. Este tipo de copia de seguridad se puede realizar mientras la base de datos está en modo de montaje o abierto. Esto se genera como archivo de seguimiento y se puede modificar fácilmente.
A continuación se muestran algunas declaraciones utilizadas para crear una copia de seguridad basada en texto del archivo de control.

1. alter database backup controlfile to trace;
2. alter database backup controlfile to trace resetlogs;
3. alter database backup controlfile to trace noresetlogs;
4. alter database backup controlfile to trace as '';
5. alter database backup controlfile to trace as '' reuse;
6. alter database backup controlfile to trace as '' resetlogs;
7. alter database backup controlfile to trace as '' noresetlogs;

26 noviembre 2020

¿Hay vida más allá de Oracle? Psi-probe para Apache Tomcat

 


Psi-probe es un monitor de Apache Tomcat que nació como un fork de Lambda Probe, debido a la falta de soporte sobre el mismo y las dudas en cuanto a su futuro.

Psi-probe es un proyecto con licencia GPLv2 que, según describen en su propia documentación, permite monitorizar en remoto el estado del servidor en los siguientes aspectos:

  • peticiones: dispone de un monitor de tráfico en tiempo real,
  • sesiones: analizar atributos en sesión, estimar el peso de las mismas,
  • jsp: navegar, ver el código fuente, recompilar!.
  • fuentes de datos: analizar el uso del pool de conexiones, ejecutar queries.
  • logs: ver el contenido, descargar, cambiar el nivel de trazabilidad en caliente.
  • hilos: ver la pila de ejecución, «matarlos».
  • conectores: ver el estado, usando gráficas.
  • cluster: ver el estado, usando gráficas.
  • JVM: ver el uso de memoria, lanzar el GC, reiniciar la JVM.
  • Sistema: uso de CPU, memoria,…

Está documentada su instalación tanto en Apache Tomcat como en Jboss Application Server, con el objetivo de reemplazar el tomcat manager ofreciendo mucha más funcionalidad, para el primero, o simplemente de disponer de un monitor online de la salud de tu servidor, para el segundo.

  • Hardware: Portátil Compaq  (2.4 GHz Intel Core i7, 4GB DDR3).
  • Sistema Operativo: Windows 10 64 bits
  • Apache Tomcat 9.0.13.
  • Apache Maven: 3.6.3.
  • psi-probe 3.5.2.

Instalación en Apache Tomcat.

Tras descargar el paquete de instalación lo único que tenemos que hacer es «tirar el war» probe.war en el directorio de despliegue de Apache Tomcat y, en función de si tenemos configurado el despliegue automático o no, configurar la aplicación web como tal, por defecto, no habría que hacer nada más que revisar la política de autenticación y autorización de tomcat definida en el fichero tomcat-users.xml del directorio conf.


Se pueden definir 4 niveles de autorización, asumiendo que manager es la más alta, con lo que si ya tenías definido un usuario con ese rol para el Tomcat Manager, no necesitas tocar nada.

Por último, si quieres acceder a toda la información de la JVM desde probe debes habilitar el acceso en remoto a la consola de JVM.

 Monitorización.

Una vez levantado el servidor y a través de la url que da acceso al contexto de la aplicación http://localhost:8080/probe podremos acceder con el usuario y contraseña configurados en Tomcat a la aplicación de monitorización.

La primera interfaz que se muestra es la de las aplicaciones instaladas en la que se puede comprobar que aparece el propio probe.

Pulsando sobre una aplicación podemos acceder a un breve detalle de toda la información que se recolecta sobre la misma:



En este caso he arrancado la demo de MyFaces Tobago. Tobago es un "framework"y una "libreria" de componentes JavaServer Faces (JSF). Que proporciona una forma cómoda de diseñar pantallas de aplicaciones similares a las de un escritorio con una apariencia y sensación coherentes. Tobago enfatiza la separación de estructura y diseño de pantallas. Próximamente haré una introducción a este "framework"

Pulsando sobre la sección correspondiente podemos analizar información sobre las sesiones activas:
se pueden eliminar las sesiones, estimar el tamaño que ocupan y pulsando sobre la misma podemos ver todos los objetos que se mantienen en la sesión del usuario en el servidor; pudiendo incluso realizar un segundo nicel de estimación del tamaño que ocupan dichos objetos en la memoria del servidor.

Existen más opciones en el menú izquierdo, entre ellas la de visualizar el contenido del descriptor de despliegue:

los servlets configurados y los parámetros de inicialización y de contexto de los servlets.

En la opción de logs podemos acceder a un listado de los ficheros que trazamos. 

y pulsando sobre uno de ellos, se puede visualizar el log, como si hiciéramos un "tail", sobre él mismo. del fichero:

Información sobre el sistema, sobre fuentes JDBC (en este ejemplo, no figuran)

Descripción del sistema

Conectores

En la pestaña de conectores podemos acceder a la monitorización de las peticiones que se realizar a través de los distintos conectores, disponiendo de información gráfica sobre número de peticiones, tiempo de proceso y volumen del tráfico de estas conexiones.




La última de las opciones es un chequeo rápido de la salud del servidor teniendo en cuenta el uso de las fuentes de datos, la memoria, el número de descriptores de fichero disponibles y si las aplicaciones están levantadas o no.


Está en vuestras manos ponerlo en producción. Si no, en cualquier entorno, incluso en el de desarrollo te puede servir como soporte de una monitorización del sistema durante pruebas de carga o estrés.




24 noviembre 2020

Oracle 10g: Diferencia entre usar srvctl y usar sqlplus para iniciar / detener una o más instancias de base de datos Oracle

 


El desafío

Hemos tenido algunos casos en los que parecía que iniciar bases de datos RAC 10g a través de sqlplus causaba problemas de rendimiento (alta carga en el servidor de la base de datos). Reiniciar los nodos usando srvctl pareció resolver el problema de rendimiento. Nos surgió una pregunta pregunta es

 "¿Hay alguna diferencia entre usar srvctl y usar sqlplus para iniciar o detener uno o más nodos de base de datos"?

La realidad

Existen algunas diferencias entre el uso de las utilidades SQLPLUS y SRVCTL.
  • La parte común es que SRVCTL utiliza SQLPLUS para iniciar / detener las instancias.
  • La herramienta SRVCTL gestiona la información de configuración que utilizan otras herramientas de Oracle. Por ejemplo, Enterprise Manager usa la información de configuración que SRVCTL genera para descubrir y monitorear nodos en su clúster.
  • Tener en cuenta que el comando "srvctl start database / instance" no iniciará todos los servicios habilitados y no en ejecución que tengan las instancias enumeradas como instancias preferidas o disponibles en 10g.
  • Ambos deberían resultar en el inicio de la instancia, pero Oracle siempre recomienda el uso de SRVCTL debido al hecho de que SRVCTL hace más, es decir, SRVCTL realizará un análisis de dependencia e informará sobre problemas relacionados con el clúster si existen, de una mejor manera que SQLPLUS, que puede decir simplemente que la instancia no se está iniciando. El comando SRVCTL intentará iniciar recursos dependientes (como vip / ons / listeners) en caso de que no se estén ejecutando.
  • La utilidad SRVCTL siempre realiza algún tipo de pre-inicio de las instancias, como actualizar la información de OCR (Oracle cluster registry) en lugar de esperar a que el script de verificación del recurso de instancia detecte el inicio de esta instancia y actualice el OCR.
  • Con SRVCTL, la configuración del sistema operativo del usuario raíz se utiliza ya que se hereda de crsd.bin que iniciará las instancias como usuario de Oracle. Con SQLPLUS, se utiliza la configuración del sistema operativo del usuario de Oracle. Tener diferentes configuraciones de usuario para root u oracle hará que el rendimiento pueda ser diferente (sga fragmentado o no, otra configuración de proyecto "solaris", ...)

16 octubre 2020

Nuevas características en Oracle database 19c



Esta versión de la base de datos viene con algunas mejoras interesantes para hacer su trabajo más rápido y más fácil. Si bien el enfoque principal de este ciclo de desarrollo ha sido la estabilidad, hay algunas características nuevas enfocadas en la automatización y optimización para el cliente. Veamos algunas de estas mejoras.
  • Redireccionamiento DML de Active Data Guard.
  • Indexación automática.
  • Tablas híbridas particionadas (Big Data).
  • Compatibilidad con JSON.
  • Más estabilidad y disponibilidad.

Redireccionamiento DML de Active Data Guard.



las bases de datos de respaldo en espera son una parte necesaria de muchos planes de recuperación de desastres, pero pueden ser costosas de llevar como potencia de procesamiento inactiva. Oracle ha trabajado para hacer que estas bases de datos sean más valiosas en su estrategia desde el lanzamiento de Active Data Guard en 11c. Esa característica, que le permite utilizar los recursos de la base de datos en espera para ejecutar informes y copias de seguridad, obtiene una actualización en 19c. Esta versión agrega la capacidad de ejecutar transacciones mediante la creación de un redireccionamiento inmediato a la base de datos principal. Las transacciones que se ejecutan en la copia de seguridad se envían y almacenan inmediatamente en las bases de datos primarias y luego en las de respaldo. No importa si sus bases de datos están en la nube o en la versión local, con Active Data Guard Redirect, ahora puede usar su base de datos en espera para obtener aún más ventajas.

Indexación automática.

La indexación de elementos lleva tiempo y puede significar una gran cantidad de trabajo para su equipo de TI. Con la indexación automática, el 19c de Oracle utiliza algoritmos de aprendizaje automático para identificar elementos, mapear y validar las opciones de indexación e indexar automáticamente para usted. Estos algoritmos aprenden sobre la marcha, por lo que solo se vuelven más eficientes y precisos en el tiempo. La automatización es la clave para mejorar el proceso. Con esta herramienta puede ahorrar tiempo y recursos al automatizar su indexación y enfocar sus energías en otros lugares.

Tablas híbridas particionadas.

Big Data significa almacenamiento grande, y con más y más información almacenada durante largos períodos de tiempo, es esencial encontrar las opciones más eficientes para manejar la creciente carga. Las tablas particionadas híbridas de Oracle se resienten al permitirle particionar los datos y luego seleccionar qué particiones deben almacenarse en la base de datos para acceder a las consultas y cuáles deben guardarse como archivos de solo lectura en ubicaciones externas. De esa manera, puede minimizar la carga en la base de datos en vivo mientras mantiene datos importantes para el almacenamiento y el acceso a largo plazo.

Cuarentena de consulta.



El desempeño general de un data mart o de un almacén de datos puede verse afectado cuando un usuario ejecuta una consulta que consume una cantidad excesiva de recursos de E/S y de computación. Oracle Database 19c “puede poner estas consultas en cuarentena automáticamente y garantizar que no se vuelvan a ejecutar”, esto da como resultado un desempeño uniforme para todos los usuarios de la base de datos. Se acabó ralentizar una instancia en Producción por ejecutar la "Query de la muerte".

Base de datos "JSON friendly".



Esta versión también incluye numerosas mejoras de JSON, así como funciones para optimizar inserciones de datos, estadísticas en tiempo real y más. Los servicios de base de datos de Oracle están diseñados teniendo en cuenta las necesidades del cliente. La compatibilidad de Oracle Database con JSON se incluyó a partir de Oracle Database 12c, con el almacenamiento nativo de documentos JSON y el acceso SQL, y continuó en 18c, con los análisis de alto desempeño para los documentos JSON, como si se hubiera realizado la ingesta de datos JSON en las filas y columnas de tabla de la base de datos.

Se ha mejorado y simplificado la sintaxis para nuestras funciones de JSON y se ha introducido la capacidad de realizar una actualización parcial de JSON, por lo que es posible actualizar un solo atributo de un gran documento JSON, en lugar de actualizar todo.

Más estabilidad y disponibilidad.

Las nuevas características son importantes en cada una de las versiones de Oracle Database. La estabilidad para las aplicaciones y las instalaciones de base de datos on-premises también es importante, y Oracle Database 19c también ofrece dicha estabilidad.

La estabilidad es uno de los principales objetivos de Oracle Database 19c; se trata de una versión con soporte a largo plazo hay clientes de productos "on-premises" cuentan con ciclos de actualización prolongados, y esta versión, Oracle Database 19c, es la que mucha gente estaba esperando para poder realizar la actualización a partir de Oracle Database 11g u Oracle Database 12c.

Para obtener más información sobre las bases de datos 19c de Oracle y una lista completa de las nuevas funciones, visite la página de Características de la base de datos de Oracle.

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.

25 septiembre 2020

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











24 septiembre 2020

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




12 septiembre 2020

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

11 septiembre 2020

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.