viernes, 14 de abril de 2017

Automatizar instalación de Oracle RAC con Ansible

Estoy empezando a usar Ansible para automatizar tareas frecuentes, y entre los primeros pasos de ver que hay hecho con Oracle encontré el repositorio racattack-ansible-oracle para instalar un cluster (RAC).

Terrible laburo, felicitaciones a Alvaro Miranda y Mikael Sandström por la contribución.

Para mi sorpresa en el sitio del RAC Attack tiene documentado parte de esto (el uso de Vagrant) desde hace un par de años. Es algo que en los eventos donde se realiza el RAC Attack no se llega a ver, ya que la idea es ejecutar paso a paso una instalación desde cero aprendiendo del proceso.
Quizás en algún nuevo evento orientado a instalaciones avanzadas se pueda llegar a incluir, junto con el uso de una instalación existente para ver en funcionamiento todos los chiches que lo hacen un producto único (como application continuity por ejemplo).

En este post de Mikael está bien explicado como usar el proyecto completo con Ansible.

Así que para aportar algo además de hacerle propaganda al proyecto, incluyo detalles de como probarlo en Windows 7 64 bits.
Usé una máquina con Intel Core i7-4600 y 16Gb de RAM.

Instalar utilitarios

Ya tenía instalado Git 2.7.0 y VirtualBox 5.1.4, no se necesita actualizarlos a las últimas versiones para que funcione.
Tuve que instalar Vagrant en su versión actual 1.9.3.


Cambiar directorio por defecto de Vagrant

Algo importante a ajustar es el directorio donde Vagrant guarda los archivos de las VM, ya que ocupan mucho espacio y nuestro disco C: se puede quedar sin espacio pronto.

Por defecto las imágenes de VMs van a C:\Users\USER\.vagrant.d aunque los binarios se hayan instalado en otro disco.

Esto es simple de ajustar: hay que definir la variable de ambiente VAGRANT_HOME y mover el direcotorio C:\Users\USER\.vagrant.d al nuevo. Yo lo moví a otro disco:

set VAGRANT_HOME=D:\vagrant.d move C:\Users\USER\.vagrant.d  d:\



Conviene no solo hacerlo en la shell y dejar esta variable de forma permanente en las propiedades del sistema (botón de inicio, "computer" y con el botón derecho elegir propiedades, y "change settings" para abrir el diálogo de propiedades del sistema).
Ahí en el tab "advanced" hay que elegir "Enviroment Variables" y agregar la nueva variable VAGRANT_HOME.



Usando racattack-ansible

Primero hay que clonar el repositorio.
Mi directorio de trabajo es d:\github donde solo tengo proyectos:

D:\GitHub>git clone --recursive https://github.com/racattack/racattack-ansible-oracle
Cloning into 'racattack-ansible-oracle'...
remote: Counting objects: 320, done.
Receiving objects: 100% (320/320), 52.22 KiB | 0 bytes/s, done.
remote: Total 320 (delta 0), reused 0 (delta 0), pack-reused 320
Resolving deltas: 100% (210/210), done.
Checking connectivity... done.
Submodule 'stagefiles/ansible-oracle' (https://github.com/oravirt/ansible-oracle) registered for path 'stagefiles/ansible-oracle'
Cloning into 'stagefiles/ansible-oracle'...
remote: Counting objects: 2181, done.
remote: Compressing objects: 100% (11/11), done.
remote: Total 2181 (delta 2), reused 0 (delta 0), pack-reused 2169
Receiving objects: 100% (2181/2181), 535.77 KiB | 245.00 KiB/s, done.
Resolving deltas: 100% (1027/1027), done.
Checking connectivity... done.
Submodule path 'stagefiles/ansible-oracle': checked out '00651e0caf9a876fcefe51d21e44a6e78c313e76'


De más está decir que lean el README.md del proyecto donde se explica como usarlo, y los posts mencionados al comienzo para entender mejor lo que sigue.

Copiar archivos de instalación de Oracle 12cR1.


Ya tenía a mano estos archivos y los moví al directorio requerido:

D:\GitHub\racattack-ansible-oracle>dir 12cr1
 Volume in drive D is externo
 Volume Serial Number is 88CD-FFE4

 Directory of D:\GitHub\racattack-ansible-oracle\12cr1

13/04/2017  11:37 AM   


          .
13/04/2017  11:37 AM              ..
13/04/2017  11:37 AM               111 .gitattributes
13/04/2017  11:37 AM                 0 keep
13/04/2017  11:37 AM               187 readme.txt
29/07/2016  09:35 PM     1,673,519,571 linuxamd64_12102_database_1of2.zip
29/07/2016  09:27 PM     1,014,527,110 linuxamd64_12102_database_2of2.zip
29/07/2016  09:48 PM     1,747,021,273 linuxamd64_12102_grid_1of2.zip
29/07/2016  11:28 PM       646,969,279 linuxamd64_12102_grid_2of2.zip
               7 File(s)  5,082,037,531 bytes
               2 Dir(s)  688,935,665,664 bytes free

Lo único que tuve que ajustar fueron los nombres de archivos, porque yo tenía estos:
29/07/2016  09:48 PM     1,747,021,273 p21419221_121020_Linux-x86-64_5of10.zip
29/07/2016  11:28 PM       646,969,279 p21419221_121020_Linux-x86-64_6of10.zip
29/07/2016  09:35 PM     1,673,519,571 p21419221_121020_Linux-x86-64_1of10.zip
29/07/2016  09:27 PM     1,014,527,110 p21419221_121020_Linux-x86-64_2of10.zip

Si no los tienen a mano, los pueden bajar del sitio de Oracle
Notar que actualmente están disponibles los binarios de 12.2 y esta configuración usa 12.1.
Al final de la página de descarga en el sitio de Oracle tienen las instrucciones para pedir archivos viejos ya no disponibles.

Creando virtuales


Este es el primer paso, usando 'vagrant up'.
Llevó varios minutos bajar la virtual de OEL6 (1.2Gb) desde https://atlas.hashicorp.com.

Ahora pueden validar que el directorio por defecto de vagrant quedó bien cambiado, ya que estos archivos se guardan en D:\vagrant.d\boxes\kikitux-VAGRANTSLASH-oracle6-racattack\16.01.01\virtualbox

Si lo ejecutaron sin cambiar el archivo de configuración Vagrantfile (en D:\GitHub\racattack-ansible-oracle), van a ver que se creó una sola VM, ya que la configuración por defecto viene para una sola instancia.
Eso es por esta variable:
num_DB_INSTANCES      = 1

Y la ejecución con valores por defecto:

D:\GitHub\racattack-ansible-oracle>vagrant up

collabn1 eth1 lanip  :192.168.78.51
collabn1 eth2 privip :172.16.100.51
collabn1 dns server role is master
on first boot shared disks will be created, this will take some time
Bringing machine 'collabn1' up with 'virtualbox' provider...
==> collabn1: Box 'kikitux/oracle6-racattack' could not be found. Attempting to find and install...
    collabn1: Box Provider: virtualbox
    collabn1: Box Version: >= 0
==> collabn1: Loading metadata for box 'kikitux/oracle6-racattack'
    collabn1: URL: https://atlas.hashicorp.com/kikitux/oracle6-racattack
==> collabn1: Adding box 'kikitux/oracle6-racattack' (v16.01.01) for provider: virtualbox
    collabn1: Downloading: https://atlas.hashicorp.com/kikitux/boxes/oracle6-racattack/versions/16.01.01/providers/virtualbox.box
    collabn1: Progress: 100% (Rate: 590k/s, Estimated time remaining: --:--:--)
==> collabn1: Successfully added box 'kikitux/oracle6-racattack' (v16.01.01) for  'virtualbox'!
==> collabn1: Importing base box 'kikitux/oracle6-racattack'...
==> collabn1: Matching MAC address for NAT networking...
==> collabn1: Checking if box 'kikitux/oracle6-racattack' is up to date...
==> collabn1: Setting the name of the VM: collabn1.1704131427
==> collabn1: Clearing any previously set network interfaces...
==> collabn1: Preparing network interfaces based on configuration...
    collabn1: Adapter 1: nat
    collabn1: Adapter 2: hostonly
    collabn1: Adapter 3: hostonly
==> collabn1: Forwarding ports...
    collabn1: 22 (guest) => 2222 (host) (adapter 1)
==> collabn1: Running 'pre-boot' VM customizations...
==> collabn1: Booting VM...
==> collabn1: Waiting for machine to boot. This may take a few minutes...
    collabn1: SSH address: 127.0.0.1:2222
    collabn1: SSH username: vagrant
    collabn1: SSH auth method: private key
    collabn1: Warning: Remote connection disconnect. Retrying...
==> collabn1: Machine booted and ready!
==> collabn1: Checking for guest additions in VM...
    collabn1: The guest additions on this VM do not match the installed version of
    collabn1: VirtualBox! In most cases this is fine, but in rare cases it can
    collabn1: prevent things such as shared folders from working properly. If you see
    collabn1: shared folder errors, please make sure the guest additions withinthe
    collabn1: virtual machine match the version of VirtualBox you have installed on
    collabn1: your host and reload your VM.
    collabn1:
    collabn1: Guest Additions Version: 5.0.0
    collabn1: VirtualBox Version: 5.1
==> collabn1: Setting hostname...
==> collabn1: Configuring and enabling network interfaces...
==> collabn1: Mounting shared folders...
    collabn1: /vagrant => D:/GitHub/racattack-ansible-oracle
    collabn1: /media/sf_12cR1 => D:/GitHub/racattack-ansible-oracle/12cR1
==> collabn1: Detected mount owner ID within mount options. (uid: 54320 guestpath: /media/sf_12cR1)
==> collabn1: Detected mount group ID within mount options. (gid: 54321 guestpath: /media/sf_12cR1)
    collabn1: /media/stagefiles => D:/GitHub/racattack-ansible-oracle/stagefiles

==> collabn1: Detected mount group ID within mount options. (gid: 54321 guestpath: /media/stagefiles)
==> collabn1: Running provisioner: shell...
    collabn1: Running: inline script
==> collabn1: overwriting /etc/resolv.conf
==> collabn1: Running provisioner: shell...
    collabn1: Running: inline script
==> collabn1: wrote key file "/etc/rndc.key"
==> collabn1: Stopping named:
==> collabn1: [  OK  ]
==> collabn1: Starting named:
==> collabn1: [  OK  ]
==> collabn1: successfully completed named steps

Podemos validar que la VM quedó configurada

D:\GitHub\racattack-ansible-oracle>vagrant box list
kikitux/oracle6-racattack (virtualbox, 16.01.01)

Y podemos entrar usando SSH.
Acá algo que tuve que ajustar: agregar los binarios de Git al path por defecto, ya que estos incluyen una versión de ssh.

D:\GitHub\racattack-ansible-oracle>ssh
'ssh' is not recognized as an internal or external command,
operable program or batch file.

D:\GitHub\racattack-ansible-oracle>vagrant ssh

collabn1 eth1 lanip  :192.168.78.51
collabn1 eth2 privip :172.16.100.51
collabn1 dns server role is master
`ssh` executable not found in any directories in the %PATH% variable. Is an
SSH client installed? Try installing Cygwin, MinGW or Git, all of which
contain an SSH client. Or use your favorite SSH client with the following
authentication information shown below:

Host: 127.0.0.1
Port: 2222
Username: vagrant
Private key: D:/vagrant.d/insecure_private_key

D:\GitHub\racattack-ansible-oracle>set PATH=%PATH%;"C:\Program Files\Git\usr\bin"

D:\GitHub\racattack-ansible-oracle>ssh
usage: ssh [-1246AaCfGgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
           [-D [bind_address:]port] [-E log_file] [-e escape_char]
           [-F configfile] [-I pkcs11] [-i identity_file]
           [-L address] [-l login_name] [-m mac_spec]
           [-O ctl_cmd] [-o option] [-p port]
           [-Q cipher | cipher-auth | mac | kex | key]
           [-R address] [-S ctl_path] [-W host:port]
           [-w local_tun[:remote_tun]] [user@]hostname [command]

Extrañamente a pesar de tener ssh en el path ahora, no funciona desde vagrant:

D:\GitHub\racattack-ansible-oracle>vagrant ssh

collabn1 eth1 lanip  :192.168.78.51
collabn1 eth2 privip :172.16.100.51
collabn1 dns server role is master
`ssh` executable not found in any directories in the %PATH% variable. Is an
SSH client installed? Try installing Cygwin, MinGW or Git, all of which
contain an SSH client. Or use your favorite SSH client with the following
authentication information shown below:

Host: 127.0.0.1
Port: 2222
Username: vagrant
Private key: D:/vagrant.d/insecure_private_key

Pero podemos usarlo directamente y confirmar que la VM está ejecutando:

D:\GitHub\racattack-ansible-oracle>ssh vagrant@127.0.0.1 -p2222 -i D:/vagrant.d/insecure_private_key
The authenticity of host '[127.0.0.1]:2222 ([127.0.0.1]:2222)' can't be establis
hed.
RSA key fingerprint is SHA256:9AOzhyrPyO5Z1/4F9ATt90X0kco87RIdGLSUTw4swgg.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[127.0.0.1]:2222' (RSA) to the list of known hosts.
[vagrant@collabn1 ~]$

Para agregar la segunda VM, modificamos el archivo de configuración Vagranfile:
num_DB_INSTANCES      = 2

Y volvemos a ejecutar 'vagrant up':

D:\GitHub\racattack-ansible-oracle>vagrant up

collabn2 eth1 lanip  :192.168.78.52
collabn2 eth2 privip :172.16.100.52
collabn2 dns server role is slave

collabn1 eth1 lanip  :192.168.78.51
collabn1 eth2 privip :172.16.100.51
collabn1 dns server role is master
Bringing machine 'collabn2' up with 'virtualbox' provider...
Bringing machine 'collabn1' up with 'virtualbox' provider...
==> collabn2: Importing base box 'kikitux/oracle6-racattack'...
==> collabn2: Matching MAC address for NAT networking...
==> collabn2: Checking if box 'kikitux/oracle6-racattack' is up to date...
==> collabn2: Setting the name of the VM: collabn2.1704131511
==> collabn2: Fixed port collision for 22 => 2222. Now on port 2200.
==> collabn2: Clearing any previously set network interfaces...
==> collabn2: Preparing network interfaces based on configuration...
    collabn2: Adapter 1: nat
    collabn2: Adapter 2: hostonly
    collabn2: Adapter 3: hostonly
==> collabn2: Forwarding ports...
    collabn2: 22 (guest) => 2200 (host) (adapter 1)
==> collabn2: Running 'pre-boot' VM customizations...
==> collabn2: Booting VM...
==> collabn2: Waiting for machine to boot. This may take a few minutes...
    collabn2: SSH address: 127.0.0.1:2200
    collabn2: SSH username: vagrant
    collabn2: SSH auth method: private key
    collabn2: Warning: Remote connection disconnect. Retrying...
==> collabn2: Machine booted and ready!
==> collabn2: Checking for guest additions in VM...
    collabn2: The guest additions on this VM do not match the installed version of
    collabn2: VirtualBox! In most cases this is fine, but in rare cases it can
    collabn2: prevent things such as shared folders from working properly. If you see
    collabn2: shared folder errors, please make sure the guest additions within the
    collabn2: virtual machine match the version of VirtualBox you have installed on
    collabn2: your host and reload your VM.
    collabn2:
    collabn2: Guest Additions Version: 5.0.0
    collabn2: VirtualBox Version: 5.1
==> collabn2: Setting hostname...
==> collabn2: Configuring and enabling network interfaces...
==> collabn2: Mounting shared folders...
    collabn2: /vagrant => D:/GitHub/racattack-ansible-oracle
    collabn2: /media/sf_12cR1 => D:/GitHub/racattack-ansible-oracle/12cR1
==> collabn2: Detected mount owner ID within mount options. (uid: 54320 guestpath: /media/sf_12cR1)
==> collabn2: Detected mount group ID within mount options. (gid: 54321 guestpath: /media/sf_12cR1)
    collabn2: /media/stagefiles => D:/GitHub/racattack-ansible-oracle/stagefiles

==> collabn2: Detected mount group ID within mount options. (gid: 54321 guestpath: /media/stagefiles)
==> collabn2: Running provisioner: shell...
    collabn2: Running: inline script
==> collabn2: overwriting /etc/resolv.conf
==> collabn2: Running provisioner: shell...
    collabn2: Running: inline script
==> collabn2: Stopping named:
==> collabn2: [  OK  ]
==> collabn2: wrote key file "/etc/rndc.key"
==> collabn2: Stopping named:
==> collabn2: [  OK  ]
==> collabn2: Starting named:
==> collabn2: [  OK  ]
==> collabn2: successfully completed named steps
==> collabn1: Checking if box 'kikitux/oracle6-racattack' is up to date...
==> collabn1: Machine already provisioned. Run `vagrant provision` or use the `--provision`
==> collabn1: flag to force provisioning. Provisioners marked to run always will still run.

D:\GitHub\racattack-ansible-oracle>


Una vez que termina, validamos que podemos conectarnos a la nueva VM:

D:\GitHub\racattack-ansible-oracle>ssh vagrant@192.168.78.52 -i D:/vagrant.d/insecure_private_key
The authenticity of host '192.168.78.52 (192.168.78.52)' can't be established.
RSA key fingerprint is SHA256:9AOzhyrPyO5Z1/4F9ATt90X0kco87RIdGLSUTw4swgg.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.78.52' (RSA) to the list of known hosts.
Last login: Thu Apr 13 18:20:17 2017 from 192.168.78.51
[vagrant@collabn2 ~]$

Instalar RAC


Con las virtuales corriendo, queda la parte que realmente interesa de ejecutar la instalación automática del RAC: esto incluye todos los pasos de configuración incluídos en el RAC Attack y que dejan las dos instancias funcionando, con ASM y una base de sid racdba.

Mi prueba tomó varias horas, lejos de los 60 minutos que comenta el post original.
Para ejecutarlo usando valores por defecto (BD 12.1, ASM 12.1):

D:\GitHub\racattack-ansible-oracle>set setup=standard

D:\GitHub\racattack-ansible-oracle>vagrant provision

collabn2 eth1 lanip  :192.168.78.52
collabn2 eth2 privip :172.16.100.52
collabn2 dns server role is slave

collabn1 eth1 lanip  :192.168.78.51
collabn1 eth2 privip :172.16.100.51
collabn1 dns server role is master
==> collabn2: Running provisioner: shell...
    collabn2: Running: inline script
...

El log de esa ejecución es muy largo para incluirlo acá.
Lo bueno es que si algún paso reporta problemas, pueden revisar los logs y luego de resolver el problema de fondo volver a ejecutar 'valgrant provision' que si bien arranca desde el principio, va descartando los pasos que ya fueron completados.

Tuve problemas durante la creación de la base - dbca falla y vagrant aborta.
Como van a ver a continuación, esto es porque el hardware no es suficiente para la configuración usada, o simplemente porque Windows no puede manejar bien la falta de recursos.

Esto no debería ocurrir si tienen mejor hardware y deberían poder completar la instalación sin problemas.
Pero me parece interesante mostrarles como se puede resolver en caso que tengan el mismo problema.

Esto es lo que se ve en la terminal donde estaba corriendo vagrant:

==> collabn1: stderr:
==> collabn1: real      8m13.313s
==> collabn1: user      0m29.813s
==> collabn1: sys       0m5.689s
==> collabn1: stdout: Copying database files
==> collabn1: 1% complete
==> collabn1: 3% complete
==> collabn1: DBCA Operation failed.
==> collabn1: Look at the log file "/u01/app/oracle/cfgtoollogs/dbca/racdba/racdba.log" for further details.
==> collabn1:
==> collabn1: TASK: [oradb-create | debug var=oradbcreate.stdout_lines] ********
...

==> collabn1: PLAY RECAP *******************************************************
********
==> collabn1: *****
==> collabn1:            to retry, use: --limit @/root/racattack-full-install.retry
==> collabn1:
==> collabn1: collabn1                   : ok=96   changed=32   unreachable=0 failed=1
==> collabn1: collabn2                   : ok=102  changed=22   unreachable=0 failed=0
==> collabn1: real      144m15.544s
==> collabn1: user      0m12.850s
==> collabn1: sys       0m14.901s
The SSH command responded with a non-zero exit status. Vagrant
assumes that this means the command failed. The output for this command
should be in the log above. Please read the output to determine what
went wrong.

Revisando los archivos de logs, encontré el motivo de la falla:

[oracle@collabn1 ~]$ cat /u01/app/oracle/cfgtoollogs/dbca/racdba/CloneRmanRestore.log
ORA-00445: background process "DBRM" did not start after 120 seconds
BEGIN dbms_backup_restore.resetCfileSection(dbms_backup_restore.RTYP_DFILE_COPY); END;

*
ERROR at line 1:

Process ID: 0

Esto es típico de falta de recursos de hardware.
Ejecutando dbca nuevamente y monitoreando más de cerca, este error se reporta por el proceso VKTM en otras ejecuciones.

Después de algunas pruebas logré resolverlo aumentando el timeout de 120 segundos a 500, agregando este parámetro de inicio a la base:
event='10281 trace name context forever, level 500'

El arreglo simple fue incluirlo en el template que usa DBCA (/u01/app/oracle/12.1.0.2/rachome1/assistants/dbca/templates/General_Purpose.dbc), ya que tuve problemas para incluirlo en el response file y en la línea de comandos.

Después de esto, la ejecución manual de dbca completó de forma exitosa y la base quedó andando:

[oracle@collabn1 ~]$ /u01/app/oracle/12.1.0.2/rachome1/bin/dbca -responseFile /u01/stage/rsp/dbca_racdba.rsp -silent -redoLogFileSize 100
Copying database files
1% complete
3% complete
9% complete
15% complete
21% complete
27% complete
30% complete
Creating and starting Oracle instance
32% complete
36% complete
40% complete
44% complete
45% complete
48% complete
50% complete
...
[oracle@collabn1 ~]$ ps -eaf | grep pmon

oracle    5971 20007  0 12:36 pts/3    00:00:00 grep pmon
grid      6090     1  0 02:13 ?        00:00:03 mdb_pmon_-MGMTDB
oracle   10222     1  0 10:44 ?        00:00:01 ora_pmon_racdba1
grid     23150     1  0 01:42 ?        00:00:05 asm_pmon_+ASM1
[oracle@collabn1 ~]$[oracle@collabn1 ~]$ export ORACLE_HOME=/u01/app/oracle/12.1.0.2/rachome1
[oracle@collabn1 ~]$ export ORACLE_SID=racdba1
[oracle@collabn1 ~]$ $ORACLE_HOME/bin/sqlplus / as sysdba

SQL*Plus: Release 12.1.0.2.0 Production on Fri Apr 14 13:05:53 2017

Copyright (c) 1982, 2014, Oracle.  All rights reserved.


Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Advanced Analytics and Real Application Testing options

13:07:31 SYS @ racdba1:>select instance_name, host_name, status from gv$instance;

INSTANCE_NAME
----------------
HOST_NAME                                                        STATUS
---------------------------------------------------------------- ------------
racdba1
collabn1.racattack                                               OPEN

Luego de esto volví a ejecutar 'valgrant provision' pero reporta error nuevamente con la ejecución de dbca, aunque el log no muestra errores esta vez y la instancia creada antes sigue en ejecución.

Claramente necesita más investigación para poder retomar desde esta situación.

La solución simple para evitar esto sería limpiar la instalación y empezar nuevamente (setup=clean)  agregando en algún paso el ajuste al template que es necesario para el harware que estoy usando.

Esos detalles quedan para un próximo post.

Un saludo 

martes, 31 de enero de 2017

Oracle TFA y support tools

Frecuentemente tengo que hacer health checks de bases de datos Oracle, y para esto es de gran utilidad ORAchk y TFA, herramientas gratuitas provistas por Oracle.
Un detalle menor que encontré recientemente es una buena excusa para presentarles ambos en este post.

Si no conocen ORAchk, vean la nota de soporte 1268927.2 "ORAchk - Health Checks for the Oracle Stack".
Tiene su tiempo en la vuelta y en cada actualización se validan más cosas. Y no solo la base de datos - OEM y ZFS también. Es parte del Database Support Tools Bundle y recientemente se incluye en la distribución del utilitario Trace File Analyzer (TFA).

TFA originalmente se usaba para simplificar la recolección de logs, pero también se mejora en cada nueva versión y tiene cosas muy buenas - prueben 'show parameter ' en un cluster grande para ir tomándole el gusto.
Vean la nota 1513912.1 "TFA with Database Support Tools Bundle" para saber todo lo que tiene.

Hay muchos post en internet explicando como usar e instalar TFA.
Pueden ver esta guía muy completa por Deiby Gómez.

La documentación es buena y pueden encontrarse algunos casos interesantes.
Por ejemplo, en una instalación de TFA con root el usuario oracle viene configurado por defecto para usar las tools y TFA. Pero eso no incluye todos los comandos, algunos van a dar error a pesar de tener permiso:


[oracle@bigdatalite ~]$ /u01/app/oracle/product/tfa/bin/tfactl access lsusers

Access Denied: Only TFA Admin can run this command

Lo que no implica que oracle no pueda usar TFA y las tools:
[oracle@bigdatalite ~]$ /u01/app/oracle/product/tfa/bin/tfactl
tfactl> toolstatus
.------------------------------------------.
|          External Support Tools          |
+-------------+--------------+-------------+
| Host        | Tool         | Status      |
+-------------+--------------+-------------+
| bigdatalite | alertsummary | DEPLOYED    |
| bigdatalite | exachk       | DEPLOYED    |
| bigdatalite | ls           | DEPLOYED    |
| bigdatalite | pstack       | DEPLOYED    |
| bigdatalite | orachk       | DEPLOYED    |
| bigdatalite | sqlt         | DEPLOYED    |
| bigdatalite | grep         | DEPLOYED    |
| bigdatalite | summary      | DEPLOYED    |
| bigdatalite | prw          | NOT RUNNING |
| bigdatalite | vi           | DEPLOYED    |
| bigdatalite | tail         | DEPLOYED    |
| bigdatalite | param        | DEPLOYED    |
| bigdatalite | dbglevel     | DEPLOYED    |
| bigdatalite | darda        | DEPLOYED    |
| bigdatalite | history      | DEPLOYED    |
| bigdatalite | oratop       | DEPLOYED    |
| bigdatalite | oswbb        | NOT RUNNING |
| bigdatalite | dbperf       | DEPLOYED    |
| bigdatalite | changes      | DEPLOYED    |
| bigdatalite | events       | DEPLOYED    |
| bigdatalite | ps           | DEPLOYED    |
| bigdatalite | srdc         | DEPLOYED    |
'-------------+--------------+-------------'
tfactl> orachk
This computer is for [S]ingle instance database or part of a [C]luster to run RAC database [S|C] [C]:^C

Para poder usar todos los comandos de TFA con el usuario Oracle, no queda otra que configurar sudo:
[oracle@bigdatalite ~]$ sudo /u01/app/oracle/product/tfa/bin/tfactl access lsusers
ncalero's password on bigdatalite:
.---------------------------------.
|   TFA Users in bigdatalite   |
+-----------+-----------+---------+
| User Name | User Type | Status  |
+-----------+-----------+---------+
| oracle    | USER      | Allowed |
'-----------+-----------+---------'
Un saludo.

martes, 11 de octubre de 2016

OTN Appreciation Day: Oracle read/write consistency #ThanksOTN

Me sumo a la iniciativa de Tim Hall de publicar hoy un post corto explicando porque nos gusta una funcionalidad de Oracle.

De las miles de funcionalidades que tiene la base de datos Oracle quiero resaltar una central - la versión 4 de Oracle (año 1984) implementó Read Consistency, un mecanismo de consistencia de datos usando Multiversion Concurrency Control (MVCC) que permite sesiones concurrentes de lectura sobre datos que están siendo modificados por otra sesión.
Esto es la I de las propiedades ACID que cumplen las bases de datos transaccionales.

MVCC es algo normal en las bases de datos modernas (por ejemplo en MySQL y Postgres) pero fue muy innovador para su época.

Lo que me parece más importante es que tiene un impacto directo sobre la capacidad de respuesta y escalabilidad de la base de datos, ya que las consultas no se bloquean por escrituras. Esto pasa inadvertido para el usuario final y agrega muy poco trabajo extra al motor.

¿Pero no todas las funcionalidades básicas de la base de datos serían igual de importantes: respaldos, recuperación, paralelismo, transacciones distribuidas, y un largo etcétera?.

Después de descubrir que Oracle además implementa write-consistency - explicado con claridad por Tom Kyte acá y acá - se vuelve mi favorita por ser fundamental para la escalabilidad del motor, compleja y de elegante implementación, siendo un buen ejemplo de lo sofisticado que son los algoritmos incluidos en el motor y la importancia de que una base de datos tenga una arquitectura robusta.

Un saludo.