29 octubre 2017

DBA WARS: "It's an older code sir, but it checks out."


En esta entrada del blog vamos a dar salida a varios còdigos SQL Y PL/SQL, antiguos pero todavía válidos.

Problemas con de PL / SQL Developer de Allround Automations

Al usar este IDE e su versión 11.X, una consulta interna toma muchos ciclos de CPU en el servidor de la base de datos (100% de una CPU).
¿Es este tu problema?  Por favor, compruebe si hay una consulta al lanzar el editor con el siguiente formato de consulta:
select s.synonym_name object_name, o.object_type
from sys.all_synonyms s, sys.all_objects o where s.owner in ('PUBLIC', user) and o.owner = s.table_owner and o.object_name = s.table_name and o.object_type in ('TABLE', 'VIEW', 'PACKAGE','TYPE', 'PROCEDURE', 'FUNCTION', 'SEQUENCE');
Se debe a la opción Describir contexto del asistente de código. Para deshabilitar:
Mira en: Tools> Preferences> Code Assistant y deshabilitar la opción "Describe Context".
O comprarles la versión 12.X que ya está resuelto.


Depurar papelera de reciclaje anterior a ...


Tiene la papelera de reciclaje de la base de datos llena o su tamaño es considerablemente grande, pero no quiere hacer un "Borrado" completo?
¿Quieres eliminar solo más de x días (como más de 90 días)?

Una buena forma de hacerlo es:

# 90 días
Select 'purge table '||owner||'."'||OBJECT_NAME||'";' from dba_recyclebin where type='TABLE' and to_date(droptime,'YYYY-MM-DD:HH24:MI:SS')<sysdate-90;
# 90 minutos
Select 'purge table '||owner||'."'||OBJECT_NAME||'";' from dba_recyclebin where type='TABLE' and to_date(droptime,'YYYY-MM-DD:HH24:MI:SS')<sysdate-(90/(24*60));

Mirar esta nota de Metalink (Doc ID 1596147.1) por si teneis alguna qe otra duda.


Purga mejorada de la papelera de reciclaje Oracle

Desde que en la versión 10g de la base de datos , se introdujo el 'reciclaje' para segmentos. Si se establece el parámetro recyelebin = on, y se descarta una tabla, en realidad no se descarta; se renombra a un nombre generado por el sistema. Esto realmente puede ayudar en situaciones donde una tabla se cae accidentalmente, ya que se puede recuperar fácilmente. Sin embargo, sin monitorearlo, puede terminar causando problemas de muchos tipos, porque puede terminar hinchando el número total de segmentos en la base de datos a muchas veces más de lo que era antes.
Oracle solo tiene 4 métodos publicados para descartar lotes de objetos reciclados; siendo:

  • El comando SQL> PURGE RECYCLE BIN emitido por un propietario de segmento, que purga todos los segmentos reciclados para ese usuario.,
  • El comando SQL> PURGE DBA_RECYCLEBIN, emitido por un DBA, que purga todos los objetos reciclados en la base de dato.
  • El comando SQL> PURGE TABLESPACE <tablespace_name> USER <schema_name>; que purga objetos propiedad del propietario dado.
  • El comando SQL> PURGE TABLESPACE uwdata USUARIO uwclass; que purga los objetos propiedad del propietario y el espacio de tabla dados.
No hay comandos incorporados que permitan que solo los segmentos de papeleras de reciclaje se realicen antes de cierto tiempo, o que solo reciclen objetos de la papelera con más de un cierto número de versiones recicladas de la misma tabla. Es relativamente fácil crear un procedimiento almacenado para manejar estos casos; esto explica cómo se puede hacer eso.

En PL/SQL, tenemos:


create or replace procedure purge_user_recyclebin(
  p_purge_before_date   in date default=NULL,
  p_purge_keep_versions in number default=NULL,
  p_test_only           in varchar2 := 'Y'
)
is
  cursor c_purge_before_date is
    select object_name
    from  user_recyclebin
    where droptime > p_purge_before_time
    and   can_purge = 'YES'
    order by droptime;

  cursor c_purge_before_version is
     select * from 
       (select original_name,
               type,
               object_name,
               droptime,
               rank() over (partition by original_name,type order by droptime desc) as obj_rank
         from   user_recyclebin
         where  can_purge = 'YES')
       where obj_rank > p_purge_keep_versions
       order by droptime;

  v_sql varchar2(1024);

  exception e_bad_parameters;
  exception e_38302;
  pragma exception_init(e_38302,-38302);  

  procedure runsql(p_object_name in varchar2) 
  is
  begin
    v_sql := 'purge '||p_object_name;
    if (p_test_only = 'N') then
      begin
        execute immediate v_sql;
      exception
         when e_38302 then 
           dbms_output.put_line('Cuidado, el objeto '||p_object_name||' no existe ignóralo');
         when others then
           dbms_output.put_line('Error borrando '||p_object_name);
           dbms_output.put_line(dbms_utility.format_error_backtrace);
      end;
    else
      dbms_output.put_line(v_sql);
    end if;
  end;

begin

  if p_purge_before_date is not null and
     p_purge_keep_versions is null then
     for r in c_purge_before_date loop
       runsql(r.object_name);
     end loop;
  elsif p_purge_before_date is null and
     p_purge_keep_versions is not null then
     for r in c_purge_before_version loop
       runsql(r.object_name);
     end loop;
  else
     raise e_bad_parameters;
  end if;

end purge_user_recylebin;
/

Cómo usarlo

Si desea probar para ver qué haría, sin purgar nada, simplemente pase el parámetro 'p_test' al valor 'Y', y establezca la salida del servidor en el tamaño 1000000. Esto mostrará una lista de los comandos que se ejecutarían. pero en realidad no los ejecuta.

Purgar todos los objetos de la papelera de reciclaje antes de una fecha determinada
Esto purgará todos los objetos de reciclaje reciclados antes del 1 de noviembre, a medianoche.

execute purge_user_recylebin(to_date('20150801 00:00:00','YYYYMMDD HH24:MI:SS'),NULL,'Y');

Esto, cuando se ejecuta como propietario de un esquema, ayuda a mantener la cantidad de objetos reciclados a un nivel razonable, a la vez que se conserva, la capacidad de recuperar segmentos perdidos más recientemente.




27 octubre 2017

Road to: Ser un DBA más valorado

La vida del DBA es una vorágine de solucionar problemas y estar al día de las tecnologías, que van aumentando cada día . A veces parece un trabajo digno de una prueba de Hércules.

Conoce el paisaje de la base de datos

La expansión de la base de datos está en aumento, especialmente desde departamentos como el marketing y las ventas que traen su propio software, lo que da como resultado bases de datos que no se mantienen, se respaldan y pueden no ser seguras.

Para evitar los problemas de rendimiento que esto puede crear, los administradores experimentados han de mantener un inventario actualizado de las instancias y bases de datos existentes en su compañía.

Idealmente, la recolección de inventario debe manejarse mediante un proceso automatizado que alimenta un repositorio de base de datos centralizado, pero eso no elimina la necesidad de verificaciones manuales para validar la precisión de la recopilación automática de datos.

Dentro de la base de datos, deberíamos de mantener un registro de:
  • Nombre, fecha de creación y propietario
  • Nombre de archivo lógico y su ubicación física,
  • Modelo de recuperación, completo,
  • Nivel de compatibilidad para cada base de datos, así como la limitación de tamaño máximo, tamaño actual y crecimiento de archivos.

También es imperativo conocer la unidad, el propósito y la disponibilidad de espacio, la versión y edición del servidor y la configuración del servidor.

Estandariza las configuraciones del sistema

No es secreto que el número de bases de datos y las instancias SQL se expanden constantemente. Eso significa una lista cada vez mayor de configuraciones de bases de datos para recordar.

Los DBA expertos realizan un seguimiento de las diferentes instancias al estandarizar los elementos de configuración siempre que sea posible: letras de unidad, opciones de configuración del servidor, configuración de la base de datos, mantenimiento de la base de datos, configuración de seguridad y más.

El resultado debe de ser:
  • Rendimiento optimizado.
  • Reducir la tasa de errores.

Planificación de las contingencias más comunes

No puedes simplemente instalar una base de datos y alejarte. Debe ser continuamente ajustado y monitoreado. Lo que separa a los DBA de mejor rendimiento del paquete es qué tan proactivos son para anticipar los problemas y cuán preparados están para enfrentar los cortes de energía, los terremotos, las inundaciones, los incendios y los robos.

La planificación de contingencia implica desarrollar un plan de mantenimiento integral para todas las instancias de base de datos y siempre estar preparado para lo peor. Al monitorear proactivamente en intervalos regularmente programados, los DBA pueden identificar si el comportamiento del sistema y el uso de los recursos han cambiado.

La planificación de recuperación de desastres se facilita definiendo contratos de licencia de tiempo de inactividad y pérdida de datos para todas las bases de datos y todas las instancias de SQL, y estableciendo procesos de recuperación de pérdida de datos.

Resolver los problemas, está bien, pero hay que ir más allá

Debido a que los problemas de rendimiento pueden tomar tanto como el 60% del tiempo del DBA típico, es vital optimizar realmente cada base de datos e instancia.

El Repositorio Automático de Carga de Trabajo (AWR) de Oracle es la herramienta ideal de recopilación y generación de informes para identificar cambios en el rendimiento, ejecutar diagnósticos y comparar con frecuencia el rendimiento de la base de datos a lo largo del tiempo.

Si tenemos bases de datos antiguas (9i, 10g), que haberlas hailas, usar el statspack, dado que si no han migrado hasta ahora, no lo van a hacer.

Colabora estrechamente con los desarrolladores, son tus aliados

Ya lo dijo Maquiavelo: "Conoce a tu enemigo".

Ahora en serio, en lugar de considerar a los desarrolladores como un "mal necesario", los DBA de mejor desempeño ven a los desarrolladores como parte de un equipo de ganar-ganar. Una vez que los DBA y los desarrolladores entienden los objetivos, las prioridades y las preocupaciones de los demás, la tensión desaparece. Ya sea a través de la tutoría o la participación en equipos de proyectos conjuntos, la comprensión mutua es clave. Cuanto mejor los tengas aleccionados, menos trabajo te van a dar, se egoista.

Comprender el negocio

Esto es fundamental, no solo para un dba, si no para el ultimo de os becarios en el equipo. Un DBA, es especial, no funciona de forma aislada. Comprender la organización para la que trabaja, su mercado, sus productos y sus clientes, es imperativo, para sobrevivir. Los DBA que conocen el negocio se vuelven aún más eficientes una vez que entienden "el significado" de diferentes solicitudes y requisitos alrededor de la  base de datos.

Tus conocimientos han de estar frescos y actualizados: Nunca dejes de aprender

Nos vienen nuevos desafíos a los DBA, la nube, las bases de datos noSQL, esto implica nuevas materias que aprender, máquinas virtuales con prototipos a estudiar e implantar
Eso ocurre en el mundo actual del DBA: nueva base de datos, nuevas rutinas, más demandas de la compañía y más usuarios; la lista es interminable.

Has de  evitar el estancamiento y la rutina al buscar y practicar actividades nuevas y desconocidas. Cuando están equipados con una sed de conocimiento, experiencia y un conjunto de habilidades cada vez mayor, los DBA de mayor rendimiento abordan su trabajo no como un trabajo de rutina, sino como una aventura emocionante.

25 octubre 2017

ADR: Si el Dr House fuera DBA, usaría esto

House M. D. (Medical diagnostic) era una serie de televisión estadounidense de la cadena FOX. El personaje central es el Dr. Gregory House, un genio médico, irónico, satírico y poco convencional e inconformista, que encabeza un equipo de diagnóstico en el Hospital Universitario Princeton-Plainsboro de Nueva Jersey.

Pero ahora entremos en detalles mas interesantes, en el contexto de este blog:

En la versión 11g, de la base de datos Oracle, se introdujo un nuevo concepto para el repositorio de los archivos de diagnostico de la base de datos, llamado ADR (Automatic Diagnostic Repository por sus siglas en ingles) 

En versiones anteriores (10g, sí, todavía hay bases de datos de esta versión por el mundo ) se utilizaban los parámetros:
  • BACKGROUND_DUMP_DEST
  • CORE_DUMP_DEST
  • USER_DUMP_DEST 

en estos lugares podíamos ver los archivos que nos ayudaban a hacer un diagnostico de errores de la base de datos. A partir de la versión 11g, se introdujo la variable DIAGNOSTIC_DEST, en donde Oracle esta tratando de estandarizar la estructura de directorios para manejar los archivos relacionados a fallas y alertas. La estructura del repositorio ADR para la base de datos, tanto en servidor como en el cliente, en la versión 12.1.0.2, es de la siguiente manera:

Estructura de directorios en servidor:


Estructura de directorios en cliente:



Un cambio muy importante que se da en 11g es que el formato del archivo de alertas de la base de datos es en formato .xml, ya que lo puedes ahora visualizar de una mejor manera en OEM, pero tambien lo puedes encontrar en su formato anterior. Si quieres ver como tienes la estructura en tu base de datos, lo puedes hacer con el siguiente query:

DBATEST> SELECT * FROM V$DIAG_INFO;

INST_ID NAME VALUE

1 Diag Enabled TRUE
1 ADR Base /mount/dump01/oracle/DBATEST
1 ADR Home /mount/dump01/oracle/DBATEST/diag/rdbms/dbatest/DBATEST
1 Diag Trace /mount/dump01/oracle/DBATEST/diag/rdbms/dbatest/DBATEST/trace
1 Diag Alert /mount/dump01/oracle/DBATEST/diag/rdbms/dbatest/DBATEST/alert
1 Diag Incident /mount/dump01/oracle/DBATEST/diag/rdbms/dbatest/DBATEST/incident
1 Diag Cdump /mount/dump01/oracle/DBATEST/diag/rdbms/dbatest/DBATEST/cdump
1 Health Monitor /mount/dump01/oracle/DBATEST/diag/rdbms/dbatest/DBATEST/hm
1 Default Trace File /mount/dump01/oracle/DBATEST/diag/rdbms/dbatest/DBATEST/trace/DBATEST_ora_18035.trc
1 Active Problem Count 1

1 Active Incident Count 75

De la misma manera, Oracle trae ahora una herramienta muy util llamada adrci, esta herramienta te permite manejar el repositorio ADR,muy importante, es que antes de mandar a llamar a la herramienta, las variables de entorno ORACLE_HOME,PATH y ADR_HOME estén bien iniciadas. Puedes ver el archivo de alertas de la base de datos de la siguiente manera:


adrci> SHOW ALERT -TAIL 5
2011-07-17 18:04:41.207000 -04:00
Archived Log entry 4735 added for thread 1 sequence 4735 ID 0xffffffffb7363f82 dest 1:
2011-07-17 21:00:49.339000 -04:00
Thread 1 advanced to log sequence 4737 (LGWR switch)
Current log# 3 seq# 4737 mem# 0: /mount/u01/oracle/DBATEST/log/redo03a.log
Current log# 3 seq# 4737 mem# 1: /mount/u01/oracle/DBATEST/log/redo03b.log
Archived Log entry 4736 added for thread 1 sequence 4736 ID 0xffffffffb7363f82 dest 1:

También podemos ver un incidente de la siguiente manera, usando ADR:


adrci> show incident

ADR Home = /mount/dump01/oracle/DBATEST/diag/rdbms/dbatest/DBATEST:
*************************************************************************
INCIDENT_ID PROBLEM_KEY CREATE_TIME
-------------------- ----------------------------------------------------------- ----------------------------------------
2041 ORA 4031 2016-11-14 05:58:35.042000 -05:00
2105 ORA 4031 2016-11-14 05:58:35.272000 -05:00
2017 ORA 4031 2016-11-14 05:58:35.272000 -05:00
1873 ORA 4031 2016-11-14 05:58:35.279000 -05:00
2153 ORA 4031 2016-11-14 05:58:35.280000 -05:00
37051 ORA 4031 2017-10-16 21:51:03.983000 -04:00
37027 ORA 4031 2017-10-16 21:51:04.239000 -04:00
36707 ORA 4031 2017-10-16 21:51:18.575000 -04:00
37019 ORA 4031 2017-106-16 21:51:22.650000 -04:00
37052 ORA 4031 2017-10-16 21:51:29.050000 -04:00
10 rows fetched

Una vez que visualizas los errores, puedes ver el detalle de ellos, así como la traza generada:


adrci> SHOW INCIDENT -MODE DETAIL -P "INCIDENT_ID=57052"

ADR Home = /mount/dump01/oracle/DBATEST/diag/rdbms/dbatest/DBATEST:
*************************************************************************

**********************************************************
INCIDENT INFO RECORD 1
**********************************************************
INCIDENT_ID 37051
STATUS ready
CREATE_TIME 2017-10-16 21:51:03.9830000 -04:00
.
.
.
KEY_NAME Client ProcId
KEY_VALUE oracle@localhost.33449_1
KEY_NAME SID
KEY_VALUE 151.3
OWNER_ID 1
INCIDENT_FILE /mount/dump01/oracle/DBATEST/diag/rdbms/dbatest/DBATEST/incident/incdir_57051/DBATEST_dw03_13299_i57052.trc
OWNER_ID 1
INCIDENT_FILE /mount/dump01/oracle/DBATEST/diag/rdbms/dbatest/DBATEST/trace/DBATEST_dw03_66699.trc
1 rows fetched


Esta herramienta te permite crear un paquete y si así lo necesitas lo envias a Oracle, 
esto te evita el trabajo de andar buscando los archivos que necesitas enviar a Oracle Metalink, perdón  MOS.
Una vez, explicado el mecanismo y el uso de esta utilidad, espero que nos sirva para solucionar, 
alguno de esos errores terribles, que de vez en cuando aparecen en nuestras vidas  como DBA.

Mi Experiencia en el mundo Oracle


En esta página he resumido toda mi experiencia con tecnologías Oracle.Con el fin de facilitar a las personas de recursos humanos, mis fuertes en esta tecnología.

TECNOLOGÍA Y FUNCIONES
MESES/AÑOS DE EXPERIENCIA
DESCRIPCIÓN DEL PROYECTO EN EL QUE SE HA UTILIZADO CADA TECNOLOGÍA Y EMPRESA EN LA QUE SE HA REALIZADO
Experiencia en PROYECTOS de migración de versiones y consolidaciones de BBDD y SSAA
AENA, Consolidación 47 bbdd Oracle 11g  a 3 bbdd Oracle 11g
Oracle GoldenGate 11g (Thales) 2010-2011
Consolidación Human Group (2meses)
10g-11g (Thales) 2007-2008
Actualización Hoteles Tuy (2meses)
10g-11g (Thales) 2007-2008
Actualización Ministerio de Trabajo
10g-11g RAC (Thales) 2011-2012

Global AVL, Migración Oracle 12 C R1 à Apache  Hadoop -> Presto DB
Oracle GoldenGate 12c (Global AVL) 2017
Oracle versiones 7, 8i, 9i, 10g y 11g en RAC, Data Guard
Oracle 7 (18 meses)
Seguros Monterrey México
AXA Seguros Portugal
Oracle 8 y 8i (12 meses)
IECI
Oracle 9i
Movistar
Oracle 10g
Movistar
Guardia Civil
Human Group
Oracle 11g
Movistar2009
AENA
Ministerio de Trabajo
Human Group
Diputación Foral Bizkaia
HSBC Londres
Oracle 12g
Banco Santander México  2014
Banco Santander Boston 2015
(Global AVL) 2017
Oracle 11g RAC
AENA 2009-2011
Ministerio de Trabajo 2010-2011
Oracle 12g  RAC
Instituto Oncológico de Cataluña
Universidad Alfonso X
HSBC Londres
BBVA Madrid
Banco Santander Brasil
Diputación Foral Bizkaia
Oracle WebLogic 11
Movistar
KPMG
(Thales) 2000-2009
(Oracle Internet Directory integration )
Oracle WebLogic 12
Banco Santander Brasil, SQL (1 mes)
(BAE Systems) 2014

Varios Clientes (Instituto Oncológico de Cataluña, Universidad Alfonso X, Securitas Direct) Oracle RAC 12g (3 meses)
(Avanttic) 2016

5 bases de datos Oracle con 5 tb de almacenamiento.
(Global AVL) 2017
Instalación, Configuración y Administración de Real Application Clusters (RAC) 10g , 11g 12c, Oracle RacOne 11g
Ministerio de Trabajo Oracle RAC 11g (9 meses)
(Thales) 2011
Diputación Foral Bizkaia (6 meses)
(BAE Systems) 2012
Varios Clientes (Instituto Oncológico de Cataluña, Universidad Alfonso X, Securitas Direct) Oracle RAC 12g (3 meses)
(Avanttic) 2016
Implantación y mantenimiento de soluciones de alta disponibilidad en Oracle (Oracle FailSafe, Oracle RAC, ASM, Dataguard)
Oracle ASM 11C Ministerio de Trabajo (9 meses)
(Thales) 2011
Oracle ASM 11C Diputación Foral Bizkaia  (6 meses)
(BAE Systems) 2012
Oracle DataGuard (3 meses)
(Avanttic) 2016
Instalación, Configuración, Administración y despliegue de aplicaciones Oracle WebLogic 11 y otros A.S.
Ministerio de Trabajo
(Thales) 2010-2011
Diputación Foral Bizkaia
(BAE Systems) 2012
Varios Clientes (Instituto Oncológico de Cataluña, Universidad Alfonso X, Securitas Direct)
(Avanttic) 2016
Jboss 6 EAP Diputación Foral Bizkaia (6 meses)
(BAE Systems) 2012
Movistar Tomcat 3,4,5  (60 meses)
 (Thales) 2010-2011
Movistar Iplanet  (48 meses)
(Thales) 2007-2011
Varios bancos Websphere (48 meses)
(BAE Systems) 2012-2016
Optimización de bases de datos
Movistar varios proyectos, SQL  y PL/SQL (4 meses)
(Thales) 2000-2007
MySQL 5.x, SQL (1mes)

(Thales Alenia espacio) 2011
HSBC Londres, SQL (1 mes)
BBVA Madrid, PL/SQL (1 mes)
Banco Santander Brasil, SQL (1 mes)
Banco Santander México, SQL (1 mes)
Diputación Foral Bizkaia, SQL (1 mes)
(BAE Systems) 2012-2016
Sistemas operativos Solaris, Red Hat Enterprise Linux, HP/UX y AIX,
Red Hat Enterprise Linux 5 (48 meses)
Red Hat Enterprise Linux 5 (Thales)
Red Hat Enterprise Linux 6 (48 meses)
Red Hat Enterprise Linux 6 (BAE Systems)
Solaris 10-11 (48 meses)
Solaris 10-11  (Thales, BAE Systems)
AIX varias versiones  (12 meses)
AIX (Thales, BAE Systems)
HP/UX varias versiones  (12 meses)
HP/UX (Thales, BAE Systems)
experiencia en otras BBDD: Informix, SQL Server, Postgress
MySQL 5.x, (18 meses)

MySQL 5.x (Thales Alenia espacio) 2009-2011
SQL Server 2008 (4 meses)
SQL Server 2008  AENA soporte a Microstategy
 MySQL 7.X (8 meses)
MySQL 7.X (Global AVL) 2017
Maria DB (8 meses)
Maria DB (Global AVL) 2017
Postgress  9.x (8 meses)
Postgress  9.x (Global AVL) 2017
Presto DB - Hadoop  (3 meses)
Presto DB - Hadoop   (Global AVL) 2017
Certificaciones


Oracle SOA Foundation Practitioner (2011)
Mongo DB 101