Siguiendo nuevamente la iniciativa de Tim Hall de publicar hoy un post corto explicando porque nos gusta una funcionalidad de Oracle, mi granito va para Real Application Clusters, la solución de clustering de Oracle que está disponible desde hace 17 años con su versión inicial en 9i (sin contar al Parallel server en versiones anteriores).
Además de brindar las funcionalidades obvias de alta disponiblildad y escalablidad, incluye algoritmos sofisticados y únicos en la industria, como la gestión de caché global.
Lo destaco no solo por sus funcionalidades básicas, sino por la innovación que incorpora en cada nueva release, abriendo posibilidades y empujando a la industria.
Por ejemplo, el Autonomous Health Framework (AHF) incluido en 12.2 agrupando varios utilitarios, entre ellos el Cluster Health Advisor, será una parte muy importante del futuro autónomo de la base de datos, que tanto se promociona en estos días.
Un saludo.
martes, 10 de octubre de 2017
martes, 12 de septiembre de 2017
Mis sesiones en el OTN Tour Latinoamérica 2017
Hace unos días terminó el Oracle Technology Network Tour Latinoamérica, en su octava edición, después de visitar 12 países.
Esta fue mi primera participación como Oracle ACE Director, lo que me permitió ir a varios países: Argentina, Paraguay, Guatemala y Costa Rica, además de Uruguay obviamente.
Además del apoyo de OTN, esto no lo podría hacer sin el auspicio de Pythian y mi equipo, que me permiten tomar días libres para presentar.
Cuatro conferencias de doce no es un porcentaje alto, pero les puedo asegurar que requiere mucho esfuerzo viajar tan seguido y presentar varias horas por día.
Mis respetos a las personas que se animan a visitar más países en tan poco tiempo.
En todos los eventos tuve suerte de encontrar gente muy interesada en ambos temas.
Más allá de lo llenas que estén las salas, es muy lindo quedarse después de terminada la presentación discutiendo casos concretos y cómo encararlos.
Estas son las agendas de los eventos en que participé:
Uruguay
Argentina
Paraguay
Guatemala
Costa Rica
Ahora vamos a lo importante, que es compartir las dos presentaciones nuevas que hice para estos eventos, disponibles en Slideshare:
Los scripts de ejemplo de la primera están en dropbox
Ambos temas tienen mucho más para ver en profundidad de lo que se puede incluir en una sesión de 45 minutos. En siguientes posts voy a mostrar ejemplos de funcionalidades en ambos temas, y sobre todo lo nuevo en dbms_redefinition 12.2 que no dio tiempo de cubrir en detalle durante la presentación.
Un saludo.
Esta fue mi primera participación como Oracle ACE Director, lo que me permitió ir a varios países: Argentina, Paraguay, Guatemala y Costa Rica, además de Uruguay obviamente.
Además del apoyo de OTN, esto no lo podría hacer sin el auspicio de Pythian y mi equipo, que me permiten tomar días libres para presentar.
Cuatro conferencias de doce no es un porcentaje alto, pero les puedo asegurar que requiere mucho esfuerzo viajar tan seguido y presentar varias horas por día.
Mis respetos a las personas que se animan a visitar más países en tan poco tiempo.
En todos los eventos tuve suerte de encontrar gente muy interesada en ambos temas.
Más allá de lo llenas que estén las salas, es muy lindo quedarse después de terminada la presentación discutiendo casos concretos y cómo encararlos.
Estas son las agendas de los eventos en que participé:
Uruguay
Argentina
Paraguay
Guatemala
Ahora vamos a lo importante, que es compartir las dos presentaciones nuevas que hice para estos eventos, disponibles en Slideshare:
Los scripts de ejemplo de la primera están en dropbox
Ambos temas tienen mucho más para ver en profundidad de lo que se puede incluir en una sesión de 45 minutos. En siguientes posts voy a mostrar ejemplos de funcionalidades en ambos temas, y sobre todo lo nuevo en dbms_redefinition 12.2 que no dio tiempo de cubrir en detalle durante la presentación.
Un saludo.
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.
Tuve que instalar Vagrant en su versión actual 1.9.3.
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:
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.
Mi directorio de trabajo es d:\github donde solo tengo proyectos:
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.
Ya tenía a mano estos archivos y los moví al directorio requerido:
Lo único que tuve que ajustar fueron los nombres de archivos, porque yo tenía estos:
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.
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:
Y la ejecución con valores por defecto:
Podemos validar que la VM quedó configurada
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.
Extrañamente a pesar de tener ssh en el path ahora, no funciona desde vagrant:
Pero podemos usarlo directamente y confirmar que la VM está ejecutando:
Para agregar la segunda VM, modificamos el archivo de configuración Vagranfile:
Y volvemos a ejecutar 'vagrant up':
Una vez que termina, validamos que podemos conectarnos a la nueva VM:
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):
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:
Revisando los archivos de logs, encontré el motivo de la falla:
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:
El arreglo simple fue incluirlo en el template que usa DBCA (/u01/app/oracle/12.1.0.2/
Después de esto, la ejecución manual de dbca completó de forma exitosa y la base quedó andando:
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
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/
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:
Lo que no implica que oracle no pueda usar TFA y las tools:
Para poder usar todos los comandos de TFA con el usuario Oracle, no queda otra que configurar sudo:
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 lsusersUn saludo.
ncalero's password on bigdatalite:
.---------------------------------.
| TFA Users in bigdatalite |
+-----------+-----------+---------+
| User Name | User Type | Status |
+-----------+-----------+---------+
| oracle | USER | Allowed |
'-----------+-----------+---------'
Suscribirse a:
Entradas (Atom)