Exadata | Password Expiration Policy

Password Expiration Policy on Exadata

Hubo momentos en los que realizamos tareas de soporte o de implementaciones en diferentes customers, notando que los administradores no se encontraban bajo politicas de seguridad SOX o bajo reglamentaciones standart y que contaban con practicas como:

  • Actividades con Cron (Practica no recomendada)
  • JOBS desde consolas web, con el usuario oracle. (Practica no recomendada, se recomienda usar otro user mon)
  • otras tareas de administracion con el usuario oracle u oragrid , o grid.

Pudimos observar que al intentar loguearnos con el usuario oracle, que se nos solicito cambiar la contraseña por que la misma se encontraba expirada.

Por ello decidimos utilizar el comando chage para poder actualizar nuestra policy de expiracion.

Ejecutamos el comando chage con el wildcard -h para poder comprender mejor las opciones:

La salida se corresponde con todas las opciones

Oracle Exadata | Temporary User Lock and PAM rules

Como parte de las políticas de seguridad de Exadata, en varias ocasiones se encontraron  con que el usuario de Sistema Operativo se lockeo ante diferentes intentos de logueo con la contraseña errónea.

Esto ocurre debido a que debido a que cada Oracle Exadata Machine viene configurada con con pam_tally2 en ON mode.

Existen algunas reglas que ya vienen seteadas, y que nos permite, setear en el archivo de configuración de SSHD, localizados en el file

/etc/pam.d folder

Tip: Dependiendo de la image versión del Exadata es posible que nos encontremos con diferentes configuraciones.

Para conocer cual es nuestra Image Version, podemos ejecutar con el usuario root, el siguiente comando:

[root@exa1adbadm02 ~]# imageinfo

Kernel version: 2.6.39-400.128.17.el5uek #1 SMP Tue May 27 13:20:24 PDT 2014 x86_64
Image version: 12.1.1.1.1.140712
Image activated: 2015-06-24 15:56:48 -0300
Image status: success
System partition on device: /dev/mapper/VGExaDb-LVDbSys1

Ahora bien, para conocer como esta configurado nuestras reglas PAM, nos posicionamos

How to create the recovery catalog on Oracle 12c Multitenant

En el Customer donde me encuentro trabajando, es necesario desarrollar una políticas de backups centralizada.

Con ello es necesario como primeros pasos:

  1. Entender las necesidades de backup y diagnosticar las mejores políticas.
  2. Definir políticas acordes a cada base de datos.
  3. Definir repositorios centralizados.
  4. Crear catalog de rman , con su contingencia.
  5. Crear SCRIPTS de rman, según tipo de política de backup.
  6. Crear JOBS de rman, según tipo de política de ejecución de backup.
  7. Utilizar y configurar algun scheduler centralizado para disparar los backups.

Hoy estaremos trabajando en el punto 4, que nos s indica como crear un CATALOG en una base de datos 12c Multitenant.

Tip : Mientras utilicemos la base de RMAN en una base por separado, y únicamente con esa finalidad, no tiene costo de de licenciamiento.

Creating recovery catalog on 12c.

Nuestro container database : CDBCAT
Nuestro PDB: BKPCAT

Oracle HPUX Tips | How to Know the Filesystem Size as df command

How to check Disk Space on HPUX

Vamos a sumar en la sección de scripting, como conocer el volumen size de cada file system en un HPUX.

Este script nos es muy útil, por que en muchos customers, ellos aun continúan almacenando los TABLESPACES de sus bases de datos en Filsesystem y no en ASM.

Para ello les dejo este script que encontre en la web hace un tiempo y lo viera en mis notas y  que me fuera de mucha utilidad en la ayuda de obtencion de volumenes para comenzar a diagramar mi nueva arquitectura de datos en Oracle 12c.

df -Pk | awk '{ 
 if ( NR == 1 ) { next } 
 if ( NF == 6 ) { print } 
 if ( NF == 5 ) { next } 
 if ( NF == 1 ) { 
 getline record; 
 $0 = $0 record 
 print $0 
 } 
 }' | awk '
BEGIN {print "Filesystem                                    Mount Point                 Total GB   Avail GB    Used GB  Used"
       print "--------------------------------------------- ------------------------- ---------- ---------- ---------- -----"}
END {print ""}
/dev/ || /^[0-9a-zA-Z.]*:\// {
printf ("%-45.45s %-25s %10.2f %10.2f %10.2f %4.0f%\n",$1,$6,$2/1024/1024,$4/1024/1024,$3/1024/1024,$5)
}'

Muchas Gracias

Saludos a la comunidad de Chile !!

AIX tips | How to know the CPU, Version and Memory

Alguna vez se habrán encontrado con tener que realizar un assesment en un cliente.

Básicamente , precisamos cosas como versión, CPU y memoria.

La idea de este simple articulo es tener a mano una breve guiá de los comandos de AIX que precisamos.

Saludos a Nelson de Bolivia de quien tengo un grato recuerdo  y es por el que nace este articulo.

Version
Con este breve scrpt podemos capturar lo necesario

# oslevel -s
5300-12-07-1241
# OSLEVEL=$(oslevel -s)
# AIXVERSION=$(echo "scale=1; $(echo $OSLEVEL | cut -d'-' -f1)/1000" | bc)
# AIXTL=$(echo $OSLEVEL | cut -d'-' -f2 | bc)
# AIXSP=$(echo $OSLEVEL | cut -d'-' -f3 | bc)
# echo "AIX ${AIXVERSION} - Technology Level ${AIXTL} - Service Pack ${AIXSP}"

BEST PRACTICES:

  • Llevar siempre armada la lista de tareas y comandos asociados a ese assesment.

Espero les sea util !

Reclamable Space on Oracle Tables script

Cuando tenemos actividades en la base de datos, con tipo de transacciones que involucran  DML’s del tipo UPDATE, DELETE, derivara con el tiempo realizar tareas de mantenimiento y  reorganización de datos.

De esta manera la TABLA se ira degradando.

La acción requerida, sera compactarla, reorganizarla.

Parte de nuestra tarea consiste en averiguar las TABLAS candidatas a ser reorganizadas, con el método SHRINK.

Por ello, es necesario revisar y contar con un listado.

Ejecutar el siguiente query

*Agradecemos a Lucas Juarez por compartirlo.

set line 200
set pages 200
col OWNER format a10
    select 
	owner,
	table_name,
	mb_total,
	mb_usado,
	mb_total-mb_usado mb_reclamable,
	round((mb_total-mb_usado)/mb_total*100,2) "%_RECLAMABLE"
		from (select owner,table_name,round((blocks*8)/1024,2) mb_total, round((num_rows*avg_row_len/1024)/1024,2) mb_usado
					from dba_tables
						where owner not in ('ANONYMOUS','APEX_PUBLIC_USER','APEX_030200','APPQOSSYS','BI','CTXSYS',
                       'DBSNMP','DIP','DMSYS','EXFSYS','HR','IX','PUBLIC','MDSYS','ORACLE_OCM',
                       'LBACSYS','MDDATA','MDSYS','MGMT_VIEW','ODM','ODM_MTR','OE','OLAPSYS','ORDDATA',
					   'ORDPLUGINS','ORDSYS','OUTLN','PM','PERFSTAT','TSMSYS','SCOTT','SH','SI_INFORMTN_SCHEMA',
					   'SPATIAL_CSW_ADMIN_USR','OWF_MGR','SPATIAL_WFS_ADMIN_USR','SYS','SYSMAN','SYSTEM','TRACESRV',
					   'MTSSYS','OWBSYS_AUDIT','WEBSYS','WMSYS','XDB')
		and blocks <> 0 )
			where ( (mb_total > 10   and mb_total < 50 and round((mb_total-mb_usado)/mb_total*100,2) > 50 ) 
			or (mb_total > 50   and mb_total < 200 and round((mb_total-mb_usado)/mb_total*100,2) > 40 )
			or (mb_total > 200 and mb_total < 500 and round((mb_total-mb_usado)/mb_total*100,2) > 30 )
			or (mb_total > 500 and round((mb_total-mb_usado)/mb_total*100,2)  > 15 ) )
		order by mb_total desc;

Como resultado podemos obtener una salida como la siguiente:

Kill Session MetaQuery

Para hacer sencillo nuestro mundo, nada mejor que un metaquery que nos ayude a realizar una tarea que involucraría tiempo que no existe cuando surge una tarea delicada como la de matar cierto tipo de sessiones.

En el día de hoy compartimos el query de la semana, en un caso particular, donde se tuvo que matar sessiones de un aplicativo que conforma como parte de un ecosistema de aplicaciones , con el mismo repositorio y que afectaba la operatoria completa del negocio.

select 
'ALTER SYSTEM KILL SESSION '''||SID||','||SERIAL#||',@'||INST_ID||''' IMMEDIATE;' 
 query,
 inst_id, 
 sid,
 serial#,
 username,
 status,
 schemaname,
 osuser,
 module,
 machine,
 program,
 sql_id,
 logon_time,
 last_call_et,
 blocking_session,
 event,
 state 
        from gv$session 
           where machine like 'srvlappsp%' 
               and status = 'ACTIVE' order by last_call_et desc;

Saludos a LATAM, INDIA & German People y a Lucas Juarez por su aporte diario como DBA en nuestro equipo de trabajo !