Archivo del Autor: admin

Acerca de admin

Tras más de 20 años trabajando con tecnologías Oracle, me decidí a recopilar en un Blog algunas de las cosillas útiles para el día a día.

El RAC se queda en estado [ROLLING PATCH]

Posted on por
Responder

Hoy vamos a ver una entrada sobre ago que puede dar mucho miedo pero que tiene una solucion muy sencila
Pongamos que tras aplicar una serie de parches comprobamos la version de nuesrto softare en el RAC y nos encontramos lo siguiente

[oracle@rac1~]$ sudo  $ORACLE_HOME/bin/crsctl query  crs  activeversion -f
Oracle Clusterware active version on the cluster is [19.0.0.0.0]. The cluster upgrade state is [ROLLING PATCH]. The cluster active patch level is [724960844].

Oracle Clusterware patch level on node rac1is [2701864972].
[oracle@rac1~]$ sudo  $ORACLE_HOME/bin/crsctl query  crs  softwarepatch rac2
Oracle Clusterware patch level on node rac2 is [387459443].

De alguna manera que no alcanzamos a entender ( o igual si), tenemos que tras finalizar un parcheado los parches de los dos nodos son iguales.

Que hacemos ??

Veamos a ver cuales son los parches que tenemos instalados.
Lo primero que se nos viene a la cabeza es tirar del comando optch
Y ecejutamos un
$ORACLE_HOME/OPatch/opatch -lsinventory
o bien
$ORACLE_HOME/OPatch/opatch -lspatches
Pero, para nuestra desesperacion resulta que Opatch nos dice que hay los mismos parches instalados.
¿que hacemos ahora?

La solucon esta en patchgen

Vamos a ver realmente que es lo que tenemos instalado en los nodos.
Para ello usaremos en ambos nodos el comando
$ORACLE_HOME/bin/kfod op=patches

[oracle@rac1~]$  $ORACLE_HOME/bin/kfod op=patches
---------------
List of Patches
===============
30489227
30489632
30557433
30655595

[oracle@rac2~]$ $ORACLE_HOME/bin/kfod op=patches
---------------
List of Patches
===============
29517242
29517247
29585399
30489227
30489632
30557433
30655595

Como podemos ver, en el rac2 nos aparecen 3 parches que no tenemos en rac1.
El siguiente paso deberia de ser el buscar cuales son esos parches y decidir si los queremos aplicar donde no estan , o quitrlos de donde estan.
Dado que quitar un parche suele ser mas complicado que ponerlo , vamos ha hacer esta segunda opcion y a eliminar esos 3 parches de rac2.

Para ello,lo primero que tendremos que hacer es como usuario root

. oaenv
 $ORACLE_HOME/crs/install/rootcrs.sh -prepatch

Y tras esto, eliminaremos los parches con 

$ORACLE_HOME/bin/patchgen commit -rb 29517242 
$ORACLE_HOME/bin/patchgen commit -rb 29517247
$ORACLE_HOME/bin/patchgen commit -rb 29585399

Una vez eliminados, comprobamos d enuevo con kfod que tenemos solamente los parches deseados, y sera en ese momento cuando cerremos la operacion con (de nuevo como root)

 $ORACLE_HOME/crs/install/rootcrs.sh -postpatch

Tras esto solamente tenemos que comprobar que el estado del cluster es normal y que las versiones y parches son los correctos

[oracle@rac1~]$) crsctl query crs softwarepatch -all
Oracle Clusterware patch level on node rac1 is [2701864972].
[oracle@rac1~]$ crsctl query crs activeversion  -f
Oracle Clusterware active version on the cluster is [19.0.0.0.0]. The cluster upgrade state is [NORMAL]. The cluster active patch level is [2701864972].
[oracle@rac1~]$ crsctl query crs releasepatch
Oracle Clusterware release patch level is [2701864972] and the complete list of patches [30489227 30489632 30557433 30655595 ] have been applied on the local node. The release patch string is [19.6.0.0.0].
[oracle@rac2~]$ crsctl query crs releasepatch
Oracle Clusterware release patch level is [2701864972] and the complete list of patches [30489227 30489632 30557433 30655595 ] have been applied on the local node. The release patch string is [19.6.0.0.0].

Mas informacion como siempre en la documentacion de oracle

  • Troubleshooting OPatchAuto
  • KFOD, KFED, AMDU (Doc ID 1485597.1)
  • Note 1180491.1 – KFED Tool For Windows OS
  • Note 1346190.1 – KFED.PL for diagnosing – ORA-15036 ORA-15042 ORA-15020 ORA-15033
  • Note 1505005.1 – Where to find kfed utility before Oracle Grid Infrastructure is installed

Oracle PSU releases hasta 2022

Posted on por
Responder

Vamos a ver una entrada de esas para guardar en el bookmark

PSU documents

  • Database 12.1.0.2 Proactive Patch Information (Doc ID 2285558.1)
  • Database 12.2.0.1 Proactive Patch Information (Doc ID 2285557.1)
  • Database 19 Proactive Patch Information (Doc ID 2521164.1)
  • Database 11.2.0.4 Proactive Patch Information (Doc ID 2285559.1)

Diferencias entre PSU y RU

Comandos basicos en Orace RAC

Posted on por
Responder

Hoy vamoa a volver a las entradas para dummies, esta vez con los comandos basicos del RAC

Como paramos un RAC?

La manera mas sencilla escon permisos de root mediante el comando 

export ORACLE_SID=+ASM1
export ORAENV_ASK=NO
. oraenv
sudo $ORACLE_HOME/bin/crsctl stop crs
sudo $ORACLE_HOME/bin/crsctl disable crs

A la hora de arrancarlo ejecutaremos 

export ORACLE_SID=+ASM1
export ORAENV_ASK=NO
. oraenv
sudo  $ORACLE_HOME/bin/crsctl enable crs
sudo $ORACLE_HOME/bin/crsctl start crs

Como arrancamos/paramos una base de datos 

srvctl stop database -d $DB_NAME

srvctl start database -d $DB_NAME

Como arrancamos/paramos una instancia en un nodo

Podemos hacerlo de varias maneras

srvctl start instance -d $DB_NAME-n $NODE_NAME 
srvctl start instance -d $DB_NAME -i $INSTANCE_NAME

Para pararla seria similar cambiando el start por stop

srvctl stop instance -d $DB_NAME-n $NODE_NAME 
srvctl stop instance -d $DB_NAME -i $INSTANCE_NAME

Parar elementos dedicados del RAC

Hay algunos componentes dedicados del RAC que no funcionan con la sintaxsis estandard, estos son:

  • Management database
  • ASM prxy

Administracion de la Management database

Los comados que podemos llevar a cabo sobre la management database son stop y relocate

srvctl start mgmtdb -n  $NODENAME 

srvctl stop mgmtdb -n $NODENAME 

srvctl relocate mgmtdb -n $OTRO_NODO

Administracion del ASM proxy 

srvctl start res ora.proxy_advm -n  $NODENAME 

srvctl stop res ora.proxy_advm -n  $NODENAME

comandos sobre el CRS

Podemos ver la entrada Comprobar versiones del cluster

Comandos sobre el OCR

Podemos verlos en la entrada Oracle cluster registry OCR (componentes del grid)

Comandos sobre los voting disk

Podemos verlos en la entradas
Redundancia de los votingdisk en ASM
Voting disk (componentes del grid)

Comandos sobre ADVM

Introducción al ADVM

Mas entradas para dummies sobre RAC:
Comandos basicos en Orace RAC
Comandos basicos del RAC II
Eliminar un nodo del rac

Aprovisionamiento de una base de datos con ansible

Posted on por
Responder

Llego la hora de la verdad.
Vamos a juntar todos los pasitos que hemos estado llevando a cabo en los distintos playbooks para llevar a cabo un aprovisionamiento total de un nuevo server Oracle v19.3 en su modalidad single server

Para ello vamos a usar el codigo que tenemos en GitHUB y las explicaciones detalladas de las anteriores entradas.

Recopilando un poco la informacion tenemos un árbol de playbooks y ficheros 

  Root
   |
   |- vars:
        |- main.yaml                     Specific rules an locations of our oracle department
        |- oracle_files.yaml              Source  & patch files info and locations    
   |
   |- files
        |-CRQ001_asm_create_disks.yaml      Example of asm disks provisioning
        |-CRQ002_createdb_ASMTEST.yaml      Example of database provisioning
        |-CRQ003_createdb_FSTEST.yaml       Example of database provisioning
   |    
   | - roles
         |so_check                           Checks the pre requirements of S.O
            -|
             |vars
                |-  OracleLinux_7_oracle_19.3_requisites.yaml      Prerrequisites for a installation of a 19.3 oracle files at OEL7
            
         |oracle_directories                 Role wich checks all required file structure exsists
         |
         |unzip_binaries                     Role wich unzips selected files 
         |
         |asm_binaries_install               Role wich install and setus the CRS = Listener          
            |
            |Templates 
                |-asm_binaries_19.3.rsp.j2   Jinja files wich create the asm response file for 19.3 version 
                |-asm_binaries_12.1.rsp.j2   Jinja files wich create the asm response file for 12.1 version 
                |-asm_binaries_12.2.rsp.j2   Jinja files wich create the asm response file for 12.2 version 
         |    
         | asm_create                       Role which configures asmlib, create asmdisks, diskgroups and asm 
         |
         | db_create                        Role wich creates a database 
            |
            |Templates 
                |-rdbms_createdb_19.3.rsp.j2   Jinja files wich create the rdbms response file for 19.3 version 
                |-rdbms_createdb_12.1.rsp.j2   Jinja files wich create the rdbms response file for 12.1 version 
                |-rdbms_createdb_12.2.rsp.j2   Jinja files wich create the rdbms response file for 12.2 version 
         |
         |
    | check_so_prerrequisites.yaml     Playbook wich checks the S.O  prerrequisites
    |     
    | asm_only_binaries                Playbook which install CRS listener and setup them
    | 
    | asm_full_install                 Playbook which install CRS,listeners, confiurres asmlib, create asmdisks,diskgroups and asm 
    |
    | db_binaries_install              Playbook wich installs and inventory database binaries 
    |
    | asmfull_plus_db_binaries         Playbook   which install CRS,listeners, confiurres asmlib, create asmdisks,diskgroups, asm and database binaries 
    |
    | db_createdb                      Playbook wich creates a database

Prerrequisitos del provisionamientio

Vamos a llevar a cabo el proceso en dos pasos.

Paso 1 REQ01

Desde la dirección del departamento nos indican que nos han enviado la petición REQ01 donde ya tenemos un servidor llamado alone.pamplona.name con la IP 192.168.51.6 donde el equipo de linux nos ha echo una instalación mínima de Oracle Linux 7.
Ademas de esto, nos han preparado los siguientes discos:

  • partición de 20G montado bajo /u01 que será dedicada para oracle
  • Dos discos para DATA que se corresponden con /dev/sda y /dev/sdb
  • Un disco para FRA que se se corresponde con /dev/sdc
  • Un disco para REDO1 que se corresponde con /dev/sdd
  • Un disco para REDO2 que se corresponde con /dev/sde

Paso 2 : REQ03

El segundo paso es que nos indican que necesitamos crear una Base de datos 19.3

Preparación del servidor

Lo primero que tenemos que llevar a cabo es la preparación del servidor, transfiriendo los mecanismos de conexión de Ansible y configurando el sudores tal como comentábamos en la entrada
Requisitos de los equipos cliente para automatizar con Ansible: SUDO

Plataformacion del sistema oeprativo

Este paso va a llevar a cabo las tareas de preinstalacion y configuración de sistema operativo que nos indica Oracle en sus manuales de instalacion.
Nosotros lo llevaremos a cabo mediante dos roles:

  • so_check
  • oracle_directories

Podemos ver mas detalle en la entrada Plataformando el sistema operativo con Ansible

Instalación de grid infraestructura

En este paso vamos a llevar a cabo la instacion del los recursos y el registro en el servidor del oracle restart.

Para ellos usaremos los roles:

  • unzip_binaries
  • asm_binaries_install
    Una vez finalizado este paso tendremos en funcionamiento un servidor plataformado con un CRS en funcionamiento, pero no tenemos asm en marcha
    Tenemos mas detalle de todos los pasos en Instalando el grid infraesturcure con Ansible

    Instalación de discos y ASM

    Dado que en la petición que nos han llegado nos solicitan una base de datos sobre ASM y nos dan los discos, necesitaremos configurar los discos y el asm, para eso utilizaremos los roles

    • asm_create

    Pero, ademas de usar el role , tendremos que generar un fichero de aprovisionamiento con la información de los discos, para ello crearemos el fichero files/REQ01_asm_create_disks.yml que será especifico para esta petición.

    Para tener mas detalles de lo que hace este bloque de playbooks y el formato y funcionamiento de este fichero podemos ver la entrada Creación de Discos y ASM con Ansible

    Instalación y creación de base de datos 19.3

    En el paso anterior habíamos acabado con la petición REQ01, pero también tenemos la petición REQ03 donde nos solicitan una base de datos 19.3 en ASM , esto lo vamos a llevar a cabo con los playbooks

    • db_binaries_install
    • db_createdb

    Al igual que en el paso anterior, esta petición de creación de base de datos tiene información dedicada, por lo que tendremos que crear un fichero de información especifico files/REQ03_createdb_TEST.yaml
    Para tener mas información de como completar este fichero y cuales son los pasos que ejecutan nuestros roles podemos ver la entrada Instalación y Creación de base de datos con Ansible

    Como podemos ver , el llevar a cabo este tipo de tareas con Ansible es extremadamente sencillo, en este taller hemos usado variedad de playbooks independientes ya que a nivel didáctico es mucho mas sencillo el explicarlo por bloques funcionales , pero en un entorno real se pueden crear tareas o roles con la union de varios de ellos mediante flujos de trabajo

Plataformando el sistema operativo con Ansible

Posted on por
Responder

Hoy vamos a recuperar la entrada de como preparar el sitema operativo (en este caaso un OEL 7)para una instalacion de Oracle.

Para esto vamos a usar el role so_check del que podemos encontrar la ultima version en nuestro GitHub

Este Playbok no hace nada del otro mundo, ya que simplemente traslada a Ansible los pasos que llevamos a cabo una y otra vez cada vez que preparamos un servidor, como vereis lo mas complicado del mismo es la sintaxsis.

Veamos el codigo completo y luego lo analizaremos por partes

[code lang=»py»]
# Pamplona 2019
# Playbook which checks if teh hosts has all the requested prereequisites
#
# requires
# env: name of the server which should be in the inventory
# vars/oracle_standard.yaml configuration file with all the deppartment values
# vars/so_[version]_requisites.yaml configuration file with the packages required for this version of the software
—
– hosts: "{{env}}"
remote_user: ansible
become: yes
become_user: root
tasks:
– fail: msg="Error no server definied, please define the env variable in the job"
when: env is not defined

– name: "Including standard variables"
include_vars:
file: "vars/oracle_standard.yaml"

– name: "Including So {{version}} requisites"
include_vars:
file: "vars/so_{{version}}_requisites.yaml"

– name: Chequeamos the group
group:
name: "{{oracle_group}}"
gid: "{{oracle_gid}}"
state: present
tags: oragroup

– name: Check the oracle user
user:
name: "{{oracle_user}}"
uid: "{{oracle_uid}}"
group: "{{oracle_group}}"
shell: /bin/bash
tags: orauser

– name: check required packages
yum:
name: "{{package_name}}"
state: latest
tags: packages

– name : Kernel values
sysctl:
name: "{{ item.name }}"
value: "{{item.value}}"
state: present
ignoreerrors: yes
sysctl_file: /etc/sysctl.d/30-oracle.conf
with_items: "{{kernel_values}}"
tags: sysctl

##We execute Huge Pages separately
– name: Huge Pages
sysctl:
name: vm.nr_hugepages
value: "{{huge_pages}}"
sysctl_set: yes
state: present
sysctl_file: /etc/sysctl.d/30-oracle.conf
ignoreerrors: yes
tags: huge_pages

– name: Limits para el usuario
pam_limits:
domain: oracle
use_max: yes
limit_type: "{{ item.tipo }}"
limit_item: "{{ item.name }}"
value: "{{item.value}}"
dest: /etc/security/limits.d/30-oracle.conf
with_items: "{{limits}}"
tags: limits

– name: Disable firewall
service:
name: firewalld
state: stopped
enabled: no
tags: firewall

– name: disabling SElinux
selinux:
policy: targeted
state: disabled
tags: SELinux
[/code]

Comprobamos usuarios y grupos

Lo primero que hacemos es la comprobacion de que tenemos los usuarios y grupos que necesitamos.
En nuestro taller usamos la configuracion mas basica , que es oracle:dba para toda la instalacion

Comprobamos los paquetes del sistema operativo

En este bloque comprobamos los paquetes del sistema operativo.
Para ello usuaremos el modulo yum de Ansible con una lista de los paquetes, esta lista los vamos a leer de un fichero de variables en el que tendremos reflejado todo lo necesario para la plataformacion de un servidor para la version especifica de Oracle que tenemos.

El conenido de este fichero refrente a los paquetes es una simple lista
[code lang=»py»]
package_name :
– binutils
– oracleasm
– oracleasm-support
– compat-libcap1
– compat-libstdc++-33
– elfutils-libelf-devel
– fontconfig-devel
– glibc
– glibc-devel
[/code]

Valores del Kernel

El siguiente paso es el configurar los parametros del kernel que queremos.
Para este paso vamos a usar el modulo sysctl, aplicando tantos valores como queramos de nuestro fichero de requerimientos
La sintaxsis de estos requerimientos es

[code lang=»py»]
kernel_values:
– { name: fs.file-max, value: 6815744 }
– { name: kernel.sem, value: "250 32000 100 128" }
– { name: kernel.shmmni, value: 4096 }
[/code]

Huge Pages

Las Huge pages es un parametro del kernel como cualquier otro, podriamos haberlo incluido dentro de los kernel parameters pero a mi personalmente me gusta tenerlo separado .
En nuestro caso no estamos dandole un valor fijo, sino que le asignamos el 60% del total del servidor

[code lang=»py»]
#60 percent huge pages
huge_pages: "{{((0.6 * ansible_memtotal_mb)*1024/2)|round|int }}"
[/code]

Limites

El siguiente paso en la plataformacion del sistema operativo es ajustar los soft y hard limits para el usuario Oracle.
Para esto usaremos el modulo pam_limits. El codigo asociado del fichero de variables es muy similar al que usamos en el kernel y, al igual que haciamos con las huge pages obtendremos alguno de estos valores dinamicamente en funcion de los recursos del servidor que vayamos a plataformar

[code lang=»py»]
limits:
– { tipo: ‘soft’ ,name: ‘nproc’, value: 16384 }
– { tipo: ‘hard’ ,name: ‘nproc’, value: 16384 }
– { tipo: ‘soft’ ,name: ‘memlock’, value: "{{ ((0.9 * ansible_memtotal_mb)*1024)|round|int }}" }
– { tipo: ‘hard’ ,name: ‘memlock’, value: "{{ ((0.9 * ansible_memtotal_mb)*1024)|round|int }}" }
[/code]

Desabilitar SElinux y Firewall

Este ultimo paso es mas bien opcional, ya que no deberia de ser un requisito, pero, en la mayoria de las plataformaciones la seguridad suele estar delegada en los elementos de red y el SELinux se deshabilita, por lo que, lo hemos incluido en nuestro playbook

[code lang=»py»]
– name: Disable firewall
service:
name: firewalld
state: stopped
enabled: no
tags: firewall

– name: disabling SElinux
selinux:
policy: targeted
state: disabled
tags: SELinux
[/code]

Como habeis podido ver,como os comentaba al principio no es nada del otro mundo, simplemente es trasladar a lenguaje de ansible los pasos que llevamos a cabo manualmente 1000 veces .

Como siempre, esta entrada es solamente un taller basico, no dudeis en encontrar la ultima y valida version del role en proyecto provisioning e GitHub