lunes, 11 de septiembre de 2017

¿Qué es CPU, PSU, SPU?



Esta es una pequeña entrada para explicar ciertos conceptos y terminologia de la herramienta de actualización de las bases de datos, Oracle Critical Patch.

Todo comenzó en enero de 2005 con Actualizaciones críticas de parches, CPU. A continuación, las Actualizaciones de conjuntos de parches (PSU) se agregaron como parches acumulativos que incluían correcciones de prioridad y arreglos de seguridad. A partir de la actualización de revisión crítica de octubre de 2012, Oracle ha cambiado la terminología para diferenciar mejor los tipos de parches. Esta terminología se utilizará para la base de datos Oracle, Enterprise Manager, Fusion Middleware y WebLogic.

Actualización de revisión crítica (CPU) ahora se refiere a la liberación general de revisiones de seguridad cada trimestre en lugar de la revisión de seguridad de base de datos acumulativa para el trimestre. Piense en la CPU como la versión trimestral general y no como un solo parche.

Patch Set Updates (PSU) son los mismos parches acumulativos que incluyen las correcciones de seguridad y las correcciones de prioridad. La clave con las PSU es que son actualizaciones menores de la versión (por ejemplo, 11.2.0.1.1 a 11.2.0.1.2). Una vez que se aplique una PSU, sólo se pueden aplicar PSU en trimestres futuros hasta que la base de datos se actualice a una nueva versión base.

La terminología de Actualización de revisión de seguridad (SPU) se presenta en la actualización de revisión crítica de octubre de 2012 como el término para el parche de seguridad trimestral. Los parches SPU son los mismos que los parches anteriores de la CPU, sólo un nuevo nombre. Para la base de datos, las SPU no se pueden aplicar una vez que se hayan aplicado PSU hasta que la base de datos se actualice a una nueva versión base.

Bundle Patches son los parches trimestrales para Windows y Exadata que incluyen tanto los parches de seguridad trimestrales como las revisiones recomendadas.

Etiqueta:
El nombre de un conjunto de cambios (por ejemplo, la fijación de un error) en el código fuente; la salida de una etiqueta es un conjunto de archivos C (* .c, * .h etc)

Conflicto. Dos o más correcciones de errores que modifican los mismos archivos de código fuente; si este es el caso, sólo se puede aplicar uno, de lo contrario el código de las correcciones tendrá que ser "fusionado" para producir una nueva etiqueta

Interim Patch. Este es el nombre oficial para un parche único. Solución de errores única.

Merge Patch:Esta es una combinación de etiquetas; si por ejemplo tiene dos correcciones de errores que tocan los mismos archivos, entonces tendría que tener esas revisiones fusionadas, produciendo un nuevo parche con una nueva etiqueta

Overlay Patch: Cuando un parche interino de una sola vez entre en conflicto con una PSU, se requiere un parche de superposición. Esto es básicamente una fusión del parche que desea y la PSU.

Overlay PSU: Durante el ciclo de vida de un patchset, las PSU normalmente se publicarán cada trimestre. A medida que el patchset alcanza su madurez, se podría esperar que haya errores menos críticos que puedan ser considerados como candidatos para su inclusión en PSU.
En algún momento el número de correcciones de errores incluidas en cada PSU alcanzará un número suficientemente bajo que ya no se considera que vale la pena hacer la PSU acumulativa.
En este punto, la PSU anterior se convierte en una línea de base y todas las futuras PSU se liberan como "superposición de PSU".

Si quieres ahondar mas en esta nomenclatura consulta la siguiente nota del Oracle Metalink, sí lo sigo llamando ¡así! : Nueva Nomenclatura de Patches para Productos Oracle [ID 1430923.1]

Usar Ansible para realizar tareas de administrador de bases de datos.


La orquestación de las tecnologías de la información se ha vuelto importante con el aumento de la escala web (ampliación y descenso de aplicaciones mediante la adición de máquinas virtuales a tareas de uso intensivo de recursos de escala horizontal), para configurar las máquinas recién agregadas sin intervención manual y la gente empieza a usarlo para usarlo para algo más que tareas de aprovisionamiento de máquinas virtuales para aplicaciones web.

El proyecto Ansible decidió hacerlo radicalmente diferente a todos los demás motores. Es diferente en el sentido de que se anuncia como simple, sin agente y poderoso.

Sencillo.

La sencillez es un gran objetivo. Para aquellos de vosotros que habéis trabajado con la configuración / motores de orquestación, hay una curva de aprendizaje pronunciada. Es difícil obtener los principios básicos en la cabeza. Para ser honesto, Ansible también me tomó un tiempo demasiado, para comprender los principios básicos, y obtener la imagen correctamente en mi cabeza. Sin embargo, después de haber trabajado con cfengine comparándolo con los libros de juicio de Ansible, que son los guiones para hacer las cosas en los objetivos, es un soplo de aire fresco. Playbooks son tan limpias que (casi) se puede leer y entender como Inglés simple.

Sin agente

Aquí es donde Ansible es verdaderamente diferente a cualquiera de las otras herramientas de configuración / orquestación. Ansible no requiere ninguna instalación de agente en los objetivos. La siguiente pregunta obvia entonces es: ¿cómo puede esto funcionar? Bueno, muy sencillo: Ansible utiliza ssh para conectarse al host y ejecuta comandos a través del shell. Dicho esto, requiere un poco más de detalle; Ansible utiliza python en el host remoto para su ejecución normal. Sin embargo, puede utilizarlo sin python, por ejemplo para configurar el host para el modo de uso normal Ansible que requiere python y el módulo simple-json.

Esto es realmente importante, y lo convierte en un excelente ajuste para mi trabajo diario como consultor de TI.

Poderoso.

Ansible es poderoso en la forma en que usted puede hacer las tareas de configuración y orquestación de una manera sencilla y limpia.

En resumen, creo que ser sin agente es la verdadera característica asesina aquí. Todos los otros motores de configuración / orquestación requieren que configure y configure una conexión cliente-servidor fija e instale un proceso (demonio) y un servidor central. La autenticación de contraseña ssh o infraestructura de clave pública se puede utilizar.

Debido a que no hay ningún daemon para instalar, puede ejecutar sus playbooks creados en todas partes. Así que en lugar de una configuración fija de cliente, puede crear libros de juego para realizar tareas de rutina y repetirla en varios sitios.

Instalación: añadir EPEL e instalar ansible.

Si usas uno de los clones de RedHat Enterprise Linux (yo uso Oracle Linux), simplemente tiene que agregar el repositorio EPEL (Extra Packages for Enterprise Linux) a su lista de fuentes yum y ejecutar:

 # yum install ansible

Primeros pasos.

Una de las primeras cosas que hago, es crear un directorio para un típico 'proyecto' ansible. Proyecto significa un conjunto de tareas que desea hacer a un conjunto de hosts aquí. A continuación, creo un archivo llamado 'hosts' que es la lista de hosts que desea utilizar para ejecutar tareas en. De forma predeterminada, Ansible busca en / etc / ansible / hosts. En este caso, pongo una sola máquina en ella (una VM de prueba), pero puede ser una lista de máquinas (direcciones IP o nombres de host).

$ cat hosts
192.168.101.2

De hecho, puede crear grupos en el archivo hosts en el "estilo ini". Pero acabo de poner un anfitrión en este ejemplo.
Lo siguiente es comprobar si Ansible lee el archivo correctamente. Esto se hace de la siguiente manera:

$ ansible todos los hosts -i --list-hosts
    192.168.101.2

Bueno, esto significa que Ansible funcionará en este host si se invoca. La siguiente cosa lógica (normalmente cuando está en un nuevo entorno de cliente para comprobar si puede llegar a los hosts):

$ ansible all -i hosts -m ping
192.168.101.2 | FALLA => FALLA: Error en la autenticación.

Ping puede ser un poco engañoso para algunas personas. Lo que ping hace aquí (-m significa módulo), está tratando de conectarse al host sobre ssh, e iniciar sesión. Como no especificó un usuario, utilizó el nombre de usuario del usuario actual en la máquina, que es 'ansible '. Un usuario 'ansible' normalmente no existe en un servidor normal (y no es necesario o debe ser creado), y tampoco en mi servidor de prueba. Así que falló, como decía el mensaje, en la autenticación.

La máquina virtual de prueba es un servidor Linux 6 instalado (OL) básico. Esto significa que sólo hay un usuario: root.
Por lo tanto, vamos a especificar la raíz del usuario como usuario:

$ ansible all -i hosts -m ping -u raíz
192.168.101.2 | FALLA => FALLA: Error en la autenticación.

La autenticación falló de nuevo. Y debería! Qué está haciendo, está intentando abrir una sesión como raíz, y no hemos dado ninguna contraseña, ni he puesto la llave pública de mi usuario local en el archivo authorised_keys alejado. Así que no hay manera de que esto podría funcionar. Esto también suele ser el estado cuando desea hacer cosas con un sistema de cliente "fresco". Vamos a agregar la opción '-k' (preguntar contraseña ssh), y ejecutar de nuevo:

$ ansible all -i hosts -m ping -u root -k
SSH password:
192.168.101.2 | success >> {
    "changed": false,
    "ping": "pong"
}

Para continar: Ahora pide una contraseña, que he llenado, a continuación, lista el anfitrión y el estado: el éxito. Durante esta ejecución, no hubo cambios en el host remoto, y el comando ping dio como resultado un pong (al igual que la respuesta de ping ICMP).
Con lo que hemos aprendido ahora, podemos hacer cosas como esta:

$ ansible all -i hosts -u root -k -a "ifconfig"
SSH password:
192.168.101.2 | success | rc=0 >>
eth0      Link encap:Ethernet  HWaddr 00:0C:29:14:65:ED
          inet addr:192.168.39.145  Bcast:192.168.39.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe14:65ed/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:47 errors:0 dropped:0 overruns:0 frame:0
          TX packets:25 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:6293 (6.1 KiB)  TX bytes:2594 (2.5 KiB)

eth1      Link encap:Ethernet  HWaddr 00:0C:29:14:65:F7
          inet addr:192.168.101.2  Bcast:192.168.101.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe14:65f7/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:188 errors:0 dropped:0 overruns:0 frame:0
          TX packets:112 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:142146 (138.8 KiB)  TX bytes:15545 (15.1 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

¿Te resulta familiar? Si eres DBA de Exadata claro que sí, esto reproduce parte de la funcionalidad de dcli (aunque dcli está dirigido a ejecutar tareas simples a un grupo de hosts, mientras que Ansible está dirigido a la configuración y orquestación de la empresa).


Playbooks


Ahora vamos a progresar con los Playbooks. Estos Playbooks de Ansible es donde reside la verdadera fuerza de esta tecnología. Permite especificar las tareas que se deben ejecutar en los hosts remotos y crear secuencias de tareas y tomar decisiones basadas en el resultado de las tareas para una ejecución posterior. Permítanme mostrarles un simple libro de jugadas, y guiarlo a través de él:

- hosts: all
  gather_facts: no
  remote_user: root
  tasks:

  - name: upgrade all packages
    yum: name=* state=latest

  - name: install python-selinux
    yum: name=libselinux-python state=installed

  - name: add public key to authorized_key file of root
    authorized_key: user=root state=present key="{{ lookup('file','/home/ansible/.ssh/id_rsa.pub') }}"

Como se puede ver, este es un playbook con tres tareas:

  • Actualizar todos los paquetes
  • Instalar libselinux-python
  • Agregar mi clave pública (local) al archivo de clave autorizado de root (para permitir el acceso sin contraseña).


La línea 1 muestra tres guiones, lo que significa el inicio de un documento YAML.
La línea 2 comienza con un solo guión, que indica una lista. Hay un guión en este nivel de indentación, por lo que es una lista de uno. Los campos de este miembro son hosts, gather_facts y tasks. Tareas tiene su propia lista (la mente del nivel de indención, que es importante). Los campos son pares clave / valor, con la separación indicada por los dos puntos (:). El primer campo es 'hosts', con el valor 'all'. Esto significa que todos los hosts en el archivo de hosts se utilizan para este libro de jugadas. No creo que sea difícil imaginar lo útil que puede ser especificar un grupo / clase de servidores en los que el libro de jugadas puede funcionar. El siguiente es 'gather_facts'. Una ejecución de libro de jugadas normal reúne primero una gran cantidad de información de todos los hosts que va a ejecutar antes de la ejecución. Éstos se pueden utilizar durante la ejecución del libro de jugadas. Siguiente 'remote_user'. Esto indica con qué usuario ansible va a iniciar sesión, por lo que no tenemos que especificarlo en la línea de comandos. Luego vemos 'tareas' para indicar la lista de tareas que se deben ejecutar en los hosts.


Es fácil ver que tenemos tres tareas. Lo que es extremadamente importante, es la identación de esta lista. El nombre no es obligatorio, pero facilita la lectura si se asignan nombres útiles a las tareas y se mostrarán cuando se ejecute el libro de jugadas. La primera tarea tiene el nombre 'actualizar todos los paquetes'. El siguiente campo muestra que la clave es 'yum' indicando que está haciendo uso del módulo yum. Esta clave tiene dos valores: name = *, que significa todos los 'todos los paquetes', y state = latest, lo que significa que queremos que todos los paquetes estén en la última versión. Esto significa que este comando es el equivalente de 'yum update'.

La segunda tarea se llama 'install python-selinux'. Hace uso del módulo del yum otra vez, y se explica por sí mismo, instala el paquete libselinux-python. Estos paquetes son necesarios para trabajar en un host que tiene selinux habilitado en cosas que están protegidas por selinux.

La siguiente tarea se llama 'agregar clave pública al archivo de raíz autorizada'. Se está utilizando el módulo authorized_key. Este módulo requiere un parámetro 'clave', para el cual usamos la función de búsqueda para buscar la clave pública local (!), Del usuario con el que ejecuto ansible, que es 'ansible'. 'Estado = presente' significa que queremos que esta clave esté presente; 'Presente' es el valor por defecto, por lo que no fue necesario ponerlo. Siguiente 'usuario = root': queremos que la clave pública se agregue al archivo authorized_keys de la raíz del usuario.


Por supuesto, estas tareas se pueden ejecutar utilizando el ejecutable 'ansible' como tareas individuales. Para mostrar la importancia de la instalación del módulo libselinux-python en un host con selinux habilitado (que es el estado de selinux en una nueva máquina Oracle Linux instalada), ejecute la tarea usando el módulo authorized_key:

$ ansible all -i hosts -k -u root -m authorized_key -a "user=root state=present key=\"{{ lookup('file','/home/ansible/.ssh/id_rsa.pub') }}\""
SSH password:
192.168.101.2 | FAILED >> {
    "failed": true,
    "msg": "Aborting, target uses selinux but python bindings (libselinux-python) aren't installed!"
}

Claro, ¿no? El anfitrión es selinux protegido. Ahora, vamos a ejecutar la instalación del paquete libselinux como una sola tarea, y luego agregamos nuestra clave pública al archivo authorized_key de root:

$ ansible all -i hosts -k -u root -m yum -a "name=libselinux-python state=installed"
SSH password:
192.168.101.2 | success >> {
    "changed": true,
    "msg": "",
    "rc": 0,
    "results": [
        "Loaded plugins: security\nSetting up Install Process\nResolving Dependencies\n--> Running transaction check\n---> Package libselinux-python.x86_64 0:2.0.94-5.3.el6_4.1 will be installed\n--> Finished Dependency Resolution\n\nDependencies Resolved\n\\n Package             Arch     Version     Repository Size\n\nInstalling:\n libselinux-python   x86_64   2.0.94-5.3.el6_4.1      public_ol6_latest   201 k\n\nTransaction Summary\n\nInstall       1 Package(s)\n\nTotal download size: 201 k\nInstalled size: 653 k\nDownloading Packages:\nRunning rpm_check_debug\nRunning Transaction Test\nTransaction Test Succeeded\nRunning Transaction\n\r  Installing : libselinux-python-2.0.94-5.3.el6_4.1.x86_64  1/1 \n\r  Verifying  : libselinux-python-2.0.94-5.3.el6_4.1.x86_64   1/1 \n\nInstalled:\n  libselinux-python.x86_64 0:2.0.94-5.3.el6_4.1\n\nComplete!\n"
    ]
}
$ ansible all -i hosts -k -u root -m authorized_key -a "user=root state=present key=\"{{ lookup('file','/home/ansible/.ssh/id_rsa.pub') }}\""
SSH password:
192.168.101.2 | success >> {
    "changed": true,
    "key": "ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAliR905hxLnsOCRlOGnmN0H9dGH4NPV88ySC6GMv0KNnU7FfCXYE51Bkk97p2IWFsPhYO9qJDyAFxRm/lia1IZRDpCFcKKKMh5eXmEJC5XSrHWFdmGZRlFcS3VQ3rpCIyU3qFM6xMazh3JHKKEtE1J6nvw/hW3slY9G/6VoJ8CzpfeQMLDOdVXUIcZXqtCPuIEDBQ7yjfMzTGz+hEmz7ImbLaUyB4MDGrDnl33L8mkBEVYu8RrwgBcagDQSiQKnIca/EL45eX/74NG1e/6vxZkHZJz/W0ak4KD+o9vF4ikz0bdrGPMZ5gRYXWoSSHrVA+Rqk8A93qBXNKUUkzGoQYTQ== ansible@ansiblevm.local",
    "key_options": null,
    "keyfile": "/root/.ssh/authorized_keys",
    "manage_dir": true,
    "path": null,
    "state": "present",
    "unique": false,
    "user": "root"
}

Tal vez su cliente no quiere que almacene sus llaves en sus servidores. Es fácil hacer lo contrario y quitar la llave del archivo authorized_key:

$ ansible all -i hosts -u root -m authorized_key -a "user=root state=absent key=\"{{ lookup('file','/home/ansible/.ssh/id_rsa.pub') }}\""
192.168.101.2 | success >> {
    "changed": true,
    "key": "ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAliR905hxLnsOCRlOGnmN0H9dGH4NPV88ySC6GMv0KNnU7FfCXYE51Bkk97p2IWFsPhYO9qJDyAFxRm/lia1IZRDpCFcKKKMh5eXmEJC5XSrHWFdmGZRlFcS3VQ3rpCIyU3qFM6xMazh3JHKKEtE1J6nvw/hW3slY9G/6VoJ8CzpfeQMLDOdVXUIcZXqtCPuIEDBQ7yjfMzTGz+hEmz7ImbLaUyB4MDGrDnl33L8mkBEVYu8RrwgBcagDQSiQKnIca/EL45eX/74NG1e/6vxZkHZJz/W0ak4KD+o9vF4ikz0bdrGPMZ5gRYXWoSSHrVA+Rqk8A93qBXNKUUkzGoQYTQ== ansible@ansiblevm.local",
    "key_options": null,
    "keyfile": "/root/.ssh/authorized_keys",
    "manage_dir": true,
    "path": null,
    "state": "absent",
    "unique": false,
    "user": "root"
}

Por favor, no especificé '-k' en la línea de comandos para enviar una contraseña: en el paso anterior añadimos nuestra clave, para que podamos acceder a nuestro host usando nuestra clave pública. Otra cosa extremadamente importante es 'cambiado'. 'Changed' indica si la tarea realmente cambió algo en el servidor de destino.

He corrido sola tarea hasta ahora, he cambiado el estado de mi VM de prueba de nuevo a su estado antes de empezar a cambiar con ansible (mediante la eliminación del paquete libselinux utilizando 'ansible todo-i hosts -k -u root -m yum -a "Nombre = libselinux-python state = ausente" '


Vamos a ejecutar la playbook descrita anteriormente, el resultado es:

$ ansible-playbook -i hosts -k linux_setup_example.yml
 [WARNING]: The version of gmp you have installed has a known issue regarding
timing vulnerabilities when used with pycrypto. If possible, you should update
it (ie. yum update gmp).

SSH password:

PLAY [all] ********************************************************************

TASK: [upgrade all packages] **************************************************
changed: [192.168.101.2]

TASK: [install python-selinux] ************************************************
changed: [192.168.101.2]

TASK: [add public key to authorized_key file of root] *************************
changed: [192.168.101.2]

PLAY RECAP ********************************************************************
192.168.101.2              : ok=3    changed=3    unreachable=0    failed=0


Ahora en este punto puede ser que pienses: Lo consigo, pero éstas son todas las tareas bastante simples, no es especial en absoluto. Bueno, ahora vamos a describir un caso real que muestra totalmente lo que la importancia de usar esto es, incluso en una sola máquina, pero aún más cuando tienes un gran grupo de servidores que tienes que administrar.

El siguiente ejemplo es una playbook creada para aplicar PSU (Actualizaciones del conjunto de parches) a una Oracle 11.2.0.4. Todavía es bastante simple, sólo se aplica PSU3 al home de Oracle, totalmente automático, ya es bueno tener automatizado mucho trabajo para una sola home, y ahorra un montón de horas (osea: mucho dinero), y te ahorra de error humano.

---
- hosts: all
  vars:
    u01_size_gb: 1
    tmp_size_gb: 1
    oracle_base: /u01/app/oracle
    oracle_home: /u01/app/oracle/product/11.2.0.4/dbhome_1
    patch_dir: /u01/install
  remote_user: oracle
  tasks:

  - name: check u01 free disk space
    action: shell df -P /u01 | awk 'END { print $4 }'
    register: u01size
    failed_when: u01size.stdout|int < {{ u01_size_gb }} * 1024 * 1024

  - name: check tmp free disk space
    action: shell df -P /tmp | awk 'END { print $4 }'
    register: tmpsize
    failed_when: tmpsize.stdout|int < {{ tmp_size_gb }} * 1024 * 1024

  - name: create directory for installation files
    action: file dest={{ patch_dir }} state=directory owner=oracle group=oinstall

  - name: copy opatch and psu
    copy: src=files/{{ item }} dest={{ patch_dir }} owner=oracle group=oinstall mode=0644
    with_items:
     - p6880880_112000_Linux-x86-64.zip
     - p18522509_112040_Linux-x86-64.zip
     - ocm.rsp

  - name: install opatch in database home
    action: shell unzip -oq {{ patch_dir }}/p6880880_112000_Linux-x86-64.zip -d {{ oracle_home }}

  - name: unzip psu patch
    action: shell unzip -oq {{ patch_dir }}/p18522509_112040_Linux-x86-64.zip -d {{ patch_dir }}

  - name: patch conflict detection
    action: shell export ORACLE_HOME={{ oracle_home }}; cd {{ patch_dir }}/18522509; $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./
    register: conflict_detection
    failed_when: "'Prereq \"checkConflictAgainstOHWithDetail\" passed.' not in conflict_detection.stdout"

  - name: apply psu
    action: shell export ORACLE_HOME={{ oracle_home}}; cd {{ patch_dir }}/18522509; $ORACLE_HOME/OPatch/opatch apply -silent -ocmrf {{ patch_dir }}/ocm.rsp
    register: apply_psu
    failed_when: "'Composite patch 18522509 successfully applied.' not in apply_psu.stdout"

  - name: clean up install directory
    file: path={{ patch_dir }} state=absent

Espero que esto demuestre lo que Ansible puede ser para un consultor. Este tipo de herramienta es simplemente obligatorio si tienes un entorno con más de aproximadamente diez a veinte servidores para administrar. Ansible puede utilizarse incluso si la organización no quiere dedicar tiempo a la implementación de una herramienta de configuración.




domingo, 10 de septiembre de 2017

Royale Rumble: Oracle VS Redis


Comparación extraída de la página DB-Engines 


Nombre
Oracle
Redis
Descripción
Ampliamente usadaSGBD relacional
Almacén de estructura de datos en memoria, utilizado como base de datos, caché y agente de mensajes
Primary database model
SGBD relacional
Almacén de clave-valor
Score
1359.09
Rank
#1
  Overall
#1
Score
120.41
Rank
#9
  Overall
#1
Website
www.oracle.com/­database/­index.html
Documentación Técnica
Desarrollado por
Oracle
Salvatore Sanfilippo 
Entrega inicial
1980
2009
Versión actual
12 Release 2 (12.2.0.1), March 2017
4.0.1, July 2017
Licencia
comercial 
Open Source 
Basado en la nube 
no
no
Lenguaje de implementación
C and C++
C
S.O.
AIX
HP-UX
Linux
OS X
Solaris
Windows
z/OS
BSD
Linux
OS X
Windows 
Esquema de datos
schema-free
Soporte de escritura
parcial 
XML
no
Índices secundarios
no
SQL 
no
APIs y otros métodos de acceso
ODP.NET
Oracle Call Interface (OCI)
JDBC
ODBC
Protocolo propietario
Lenguajes de programación compatibles
C
C#
C++
Clojure
Cobol
Delphi
Eiffel
Erlang
Fortran
Groovy
Haskell
Java
JavaScript
Lisp
Objective C
OCaml
Perl
PHP
Python
R
Ruby
Scala
Tcl
Visual Basic
C
C#
C++
Clojure
Crystal
D
Dart
Elixir
Erlang
Fancy
Go
Haskell
Haxe
Java
JavaScript (Node.js)
Lisp
Lua
MatLab
Objective-C
OCaml
Perl
PHP
Prolog
Pure Data
Python
R
Rebol
Ruby
Rust
Scala
Scheme
Smalltalk
Tcl
Server-side scripts 
PL / SQL
Lua
Disparadores de bases de datos
si
no
Métodos de particionamiento
división horizontal
Sharding
Métodos de replicación
Replicación maestro-maestro
Replicación maestro-esclavo
Mapareduce
Replicación maestro-esclavo
no
Conceptos de consistencia
no
Consistencia eventual
Llaves extranjeras
Consistencia inmediata
no
Conceptos de transacción
si
Bloqueo optimista, ejecución atómica de bloques de comandos y scripts
Concurrencia
ACID
si
Durabilidad
si
si
Capacidades en memoria
si
si
Conceptos de usuario
si
Control de acceso simple basado en contraseña

Uso de Oracle GoldenGate con Amazon RDS




Oracle GoldenGate se utiliza para recopilar, replicar y administrar datos transaccionales entre bases de datos. Se trata de un paquete de software de replicación y de captura de datos de cambio de registro (CDC) utilizado con bases de datos Oracle para sistemas de procesamiento de transacciones en línea (OLTP). GoldenGate crea archivos de seguimiento que contienen los datos modificados más recientes de la base de datos de origen y, a continuación, aplica estos archivos a la base de datos de destino. Puede utilizar Oracle GoldenGate con Amazon RDS para la replicación Activo-Activo de bases de datos, migración y actualizaciones sin tiempo cero, recuperación de desastres, protección de datos y replicación en regiones y regiones cruzadas.


Con Amazon Relational Database Service (Amazon RDS), es sencillo configurar, utilizar y escalar una base de datos relacional en la nube. Proporciona capacidad escalable a la par que automatiza las tareas administrativas como:
  • Aprovisionamiento de hardware.
  • Configuración de bases de datos.
  • Los parches.
  • Las copias de seguridad.
Le libera para que pueda concentrarse en sus aplicaciones y darles el desempeño rápido, la alta disponibilidad, la seguridad y la compatibilidad que necesitan.
Amazon RDS es un servicio administrado de base de datos relacional que pone en su disposición seis motores de base de datos conocidos entre los que pueden elegir:
  • Amazon Aurora
  • MySQL
  • MariaDB
  • Oracle
  • Microsoft SQL Server
  • PostgreSQL
Esto supone que el código, las aplicaciones y las herramientas que utiliza con sus bases de datos funcionan con Amazon RDS. Amazon RDS se encarga de las tareas habituales de las bases de datos como:
  • Aprovisionamiento
  • Revisiones
  • Respaldos
  • Recuperación
  • Detección de errores
  • Reparación de errores.

Con Amazon RDS resulta sencillo usar la replicación para mejorar la disponibilidad y fiabilidad de las cargas de trabajo de producción. La opción de despliegue Multi-AZ permite ejecutar cargas de trabajo críticas con alta disponibilidad y conmutación por error automatizada e integrada desde la base de datos principal a una base de datos secundaria replicada sincrónicamente. 

Con las réplicas de lectura, puede escalar más allá de la capacidad de una implementación de una sola base de datos para cargas de trabajo de bases de datos con operaciones intensivas de lectura.
Como con Amazon Web Services, no se requiere ninguna inversión inicial y solo tendrá que pagar por los recursos que utilice.
Los siguientes son puntos importantes para saber cuándo se trabaja con Oracle GoldenGate sobre Amazon RDS.
  • Eres responsable de configurar y administrar GoldenGate en Amazon RDS.
  • Amazon RDS admite Oracle GoldenGate bajo el modelo de llevar su propia licencia en todas las regiones de AWS. Para obtener más información, consulte Licencias de Oracle.
  • Amazon RDS admite Oracle GoldenGate para Oracle Database Standard Edition Dos (SE2), Standard Edition One (SE1), Standard Edition (SE) y Enterprise Edition (EE).
  • Amazon RDS admite Oracle GoldenGate para la versión de base de datos 11.2.0.4, 12.1.0.1 o 12.1.0.2.
  • Amazon RDS admite Oracle GoldenGate versión 11.2.1 y 12.1.x.
  • Amazon RDS admite la migración y la replicación en bases de datos Oracle usando Oracle GoldenGate. No apoyamos ni impedimos que los clientes migren o se repliquen en bases de datos heterogéneas.
  • Puede utilizar GoldenGate en las instancias de Oracle DB de Amazon RDS que utilizan Oracle Transparent Data Encryption (TDE). Dado que los archivos de trazado guardan datos sin cifrar de forma predeterminada, debe encriptar la canalización entre la instancia de origen, el concentrador de GoldenGate y la instancia de destino mediante el cifrado de sqlnet.ora. Para obtener más información sobre el cifrado de sqlnet.ora, consulte la documentación de Oracle.
  • Oracle GoldenGate DDL no es compatible actualmente.

Visión de conjunto

La arquitectura Oracle GoldenGate para su uso con Amazon RDS consta de tres módulos disociados. La base de datos de origen puede ser una base de datos Oracle local, una base de datos Oracle en una instancia EC2 o una base de datos Oracle en una instancia de Amazon RDS DB. A continuación, el concentrador de GoldenGate, que traslada información de transacciones desde la base de datos de origen a la base de datos de destino, puede ser una instancia de EC2 con Oracle Database 11.2.0.4 y GoldenGate 11.2.1 o una instalación de Oracle local. Puede tener más de un concentrador EC2 y le recomendamos que utilice dos concentradores si utiliza GoldenGate para la replicación entre regiones. Por último, la base de datos de destino puede estar en una instancia de Amazon RDS DB, en una instancia de EC2 o en una ubicación local.
Oracle GoldenGate en Amazon RDS admite los siguientes escenarios comunes:

  • Configurar y administrar GoldenGate en Amazon RDS.
  • Amazon RDS admite Oracle GoldenGate bajo el modelo de llevar su propia licencia en todas las regiones de AWS. Para obtener más información, consulte Licencias de Oracle.
  • Amazon RDS admite Oracle GoldenGate para Oracle Database Standard Edition Dos (SE2), Standard Edition One (SE1), Standard Edition (SE) y Enterprise Edition (EE).
  • Amazon RDS admite Oracle GoldenGate para la versión de base de datos 11.2.0.4, 12.1.0.1 o 12.1.0.2.
  • Amazon RDS admite Oracle GoldenGate versión 11.2.1 y 12.1.x.
  • Amazon RDS admite la migración y la replicación en bases de datos Oracle usando Oracle GoldenGate. No apoyamos ni impedimos que los clientes migren o se repliquen en bases de datos heterogéneas.
  • Puede utilizar GoldenGate en las instancias de Oracle DB de Amazon RDS que utilizan Oracle Transparent Data Encryption (TDE). Dado que los archivos de trazado guardan datos sin cifrar de forma predeterminada, debe encriptar la canalización entre la instancia de origen, el concentrador de GoldenGate y la instancia de destino mediante el cifrado de sqlnet.ora. Para obtener más información sobre el cifrado de sqlnet.ora, consulte la documentación de Oracle.
  • Oracle GoldenGate DDL no es compatible actualmente.

Visión de conjunto

La arquitectura Oracle GoldenGate para su uso con Amazon RDS consta de tres módulos disociados. La base de datos de origen puede ser una base de datos Oracle local, una base de datos Oracle en una instancia EC2 o una base de datos Oracle en una instancia de Amazon RDS DB. A continuación, el concentrador de GoldenGate, que traslada información de transacciones desde la base de datos de origen a la base de datos de destino, puede ser una instancia de EC2 con Oracle Database 11.2.0.4 y GoldenGate 11.2.1 o una instalación de Oracle local. Puede tener más de un concentrador EC2 y le recomendamos que utilice dos concentradores si utiliza GoldenGate para la replicación entre regiones. Por último, la base de datos de destino puede estar en una instancia de Amazon RDS DB, en una instancia de EC2 o en una ubicación local.

Oracle GoldenGate en Amazon RDS admite los siguientes escenarios comunes:

  • Escenario 1: una base de datos Oracle local y un concentrador Oracle GoldenGate local, que proporciona datos a una instancia de Amazon RDS de destino.

  • Escenario 2: Una base de datos Oracle local que actúa como base de datos de origen, conectada a un concentrador de instancias de Amazon EC2 que proporciona datos a una instancia de Amazon RDS de destino.

  • Escenario 3: Una base de datos Oracle en una instancia de Amazon RDS DB que actúa como base de datos de origen, conectada a un concentrador de instancias de Amazon EC2 que proporciona datos a una instancia de Amazon RDS de destino.

  • Escenario 4: Una base de datos Oracle en una instancia de Amazon EC2 que actúa como base de datos de origen, conectada a un concentrador de instancias de Amazon EC2 que proporciona datos a una instancia de Amazon RDS de destino.

  • Escenario 5: una base de datos Oracle en una instancia de Amazon RDS conectada a un concentrador de instancias de Amazon EC2 en la misma región, conectada a un concentrador de instancias de Amazon EC2 en una región diferente que proporciona datos a la instancia de Amazon RDS de destino en la misma región el segundo concentrador de instancias de EC2.


Quiero hacer notar que cualquier problema que afecte al funcionamiento de Oracle GoldenGate en un entorno local también afectará el funcionamiento de GoldenGate en AWS. Recomendamos encarecidamente que supervise el concentrador de GoldenGate para asegurarse de que EXTRACT y REPLICAT se reanuden si se produce una conmutación por error. Dado que el concentrador GoldenGate se ejecuta en una instancia de Amazon EC2, Amazon RDS no gestiona el concentrador GoldenGate y no puede garantizar que se esté ejecutando.

Puede utilizar GoldenGate con Amazon RDS para actualizar a versiones principales de Oracle. 
Por ejemplo, puede utilizar GoldenGate con Amazon RDS para actualizar desde una base de datos local de Oracle versión 8 a una base de datos Oracle que ejecuta la versión 11.2.0.4 en una instancia de Amazon RDS DB.


Para configurar Oracle GoldenGate con Amazon RDS, configure el concentrador en la instancia de EC2 y, a continuación, configure las bases de datos de origen y de destino. Los siguientes pasos muestran cómo configurar GoldenGate para su uso con Amazon RDS. 

En próximas entregas veremos como se hace.