Muchos eventos Oracle en el sur

Buenas, retomo después de una pausa forzada por varios cambios (nueva casa, trabajo y niños que arrancan liceo), con varios tips técnicos para compartir en breve, y para recordarles los eventos que se vienen en la región en breve.

El Oracle Technology Network Tour Latin América (más conocido como OTN Tour) arranca el 2 de agosto en San Pablo, visita 12 países, y llega a Montevideo el 14 y 15 de Agosto. Todos los detalles de estos eventos en el sitio de Oracle.

Estos eventos son realizados gracias al esfuerzo de los grupos de usuarios de Latinoamérica, con apoyo de OTN y sponsors locales para solventar los gastos, y no sería posible sin el trabajo honorario de mucha gente que dedicas muchas horas de su tiempo personal a que esto sea posible.

Así que si trabajan con Oracle o les interesa aprender, tómense un día libre y acérquense. Van a aprender en un solo día muchísimo, y a diferencia del muy buen evento virtual que organizó OTN hace un par de semanas, van a poder interactuar en persona con reconocidos expertos, conocerlos de cerca, además conocer a otros profesionales con inquietudes similares, y quedar en contacto con grandes personas.

Como no puedo evitarlo, tengo que pedirles que si andan por Montevideo se arrimen a nuestro evento, y si tienen ganas de hablar de Bases de datos después, invito la cerveza.

Un saludo.

Consultas para ver atributos de tablas e índices particionados

Este post es para compartir un par de consultas que uso muy seguido y quiero dejar a mano en el blog, ya que no tengo un área de scripts.

Si usamos habitualmente la línea de comando para administrar una base de datos, tenemos a mano muchos scripts SQL para distintas tareas. Para consultas simples no es tan necesario, como por ejemplo ver los índices de una tabla. Pero cuando trabajamos con tablas particionadas, lleva un poco más volver a escribir esa consulta que nos muestra todos los datos que nos interesa. Tener a mano el script SQL es útil para ahorrarnos escribirlo de nuevo cada vez.

Actualmente hay muchas herramientas gráficas/web de administración que nos hace dejar de lado usar este tipo de scripts para consultar metadata de la base de datos. Usar scripts también puede ser un hábito adquirido con el tiempo (señal del paso del tiempo :)), aunque hay casos en que es necesario. Uno de ellos es cuando hay firewalls o medidas de seguridad que solo permiten acceso a la base de datos mediante una terminal. Aunque los firewalls se puedan esquivar usando túneles con ssh para utilitarios cliente/servidor (como SQL Developer o MySQL Workbench), para utilitarios que publican un acceso web es más complicado (Grid Control), y ahí vuelven a tener sentido los scripts.

Así que hecha la introducción, estos son un par de scripts útiles para ver información de una tabla particionada y sus índices. Cuando no hay particiones, estos datos se pueden sacar con una consulta simple sobre DBA_TABLES y DBA_IND_COLUMNS sin mucha complicación.

Para ilustrarlo mejor, un ejemplo usando estas tablas:

select table_name, num_rows
from dba_tables
where table_name like 'BIGTBL%';

TABLE_NAME                       NUM_ROWS
------------------------------ ----------
BIGTBL_PART_FACT                 34718511
BIGTBL_PART_ID                   41529989
BIGTBL                            5931843

3 rows selected.

Así vemos por separado sus particiones:

break on t.table_NAME on t.partitioning_type on t.partition_count on t.status
select t.table_NAME, t.partitioning_type tipo, t.partition_count particiones, t.status, c.COLUMN_NAME, c.COLUMN_POSITION
from DBA_PART_KEY_COLUMNS c, dbA_part_tables t
where t.table_name = c.name
  and c.owner = t.owner
  and t.table_name like 'BIGTBL%'
order by c.name, c.COLUMN_POSITION;

TABLE_NAME                     TIPO      PARTICIONES STATUS   COLUMN_NAME          COLUMN_POSITION
------------------------------ --------- ----------- -------- -------------------- ---------------
BIGTBL_PART_FACT               RANGE              50 VALID    NRO_FACT                           1
BIGTBL_PART_ID                 RANGE              50 VALID    ID                                 1

2 rows selected.

Juntamos ambas consultas en una sola:

col part_col for a30
select t.table_NAME, t.num_rows, p.partitioning_type particion, p.partition_count "#part", p.status,
       c.COLUMN_NAME part_col, c.COLUMN_POSITION pos
from dbA_tables t, DBA_PART_KEY_COLUMNS c, dbA_part_tables p
where t.table_name = p.table_name(+) and t.owner=p.owner(+)
  and t.table_name = c.name(+) and t.owner = c.owner(+)
  and t.table_name like 'BIGTBL%'
order by t.table_name, c.COLUMN_POSITION;

TABLE_NAME                       NUM_ROWS PARTICION      #part STATUS   PART_COL                              POS
------------------------------ ---------- --------- ---------- -------- ------------------------------ ----------
BIGTBL_PART_FACT                 34718511 RANGE             50 VALID    NRO_FACT                                1
BIGTBL_PART_ID                   41529989 RANGE             50 VALID    ID                                      1
BIGTBL                            5931843

3 rows selected.

La misma idea aplicada a los índices nos lleva a esta consulta, para ver los índices, saber si están particionados y algún dato más:

col index_name for a30
select c.index_name, uniqueness, i.partitioned, p.partitioning_type tipo, locality, c.column_name, column_position pos
from dba_ind_columns c, dba_indexes i, dba_part_indexes p
where i.index_name=c.index_name and c.index_owner=i.owner and c.table_name=i.table_name and c.table_owner=i.table_owner
  and i.owner=p.owner(+) and i.index_name=p.index_name(+) and i.table_name=p.table_name(+)
  and c.table_name='BIGTBL_PART_ID' 
order by c.index_name, c.column_position;  

INDEX_NAME                     UNIQUENES PAR TIPO      LOCALI COLUMN_NAME                 POS
------------------------------ --------- --- --------- ------ -------------------- ----------
IDX_BIGTBL_PART_2              NONUNIQUE NO                   COD_DOC                       1
IDX_BIGTBL_PART_2              NONUNIQUE NO                   COD_LOCAL                     2
IDX_BIGTBL_PART_ID             UNIQUE    YES RANGE     LOCAL  NRO_FACT                      1

3 rows selected.

Espero les sea útil

Preguntas y respuestas de la presentación sobre RAC

Muchas gracias a todos los que me acompañaron en la presentación sobre Oracle RAC hace unos días.
Hubo varias preguntas al final, y algunos asistentes me pidieron que les enviara referencias. No tuve tiempo de tomar nota de quién hizo esas preguntas antes de que se cerrara la sesión, así que dejo acá las respuestas, que además sirven para ampliar el material usado en la presentación.
Transcribo las preguntas de memoria, así que espero que sean lo más parecido posible a la realidad. Y aprovecho a desarrollarlas un poco más.

• ¿Se necesita Oracle ASM con Oracle RAC 11g?

ASM es la única alternativa si se usa la versión Standard Edition de Oracle.
En Enterprise Edition se permiten alternativas (documentadas en la matriz de certificación en el sitio de soporte), aunque Oracle ASM es la recomendada para la base de datos y los archivos OCR y voting disk usados por clusterware. Este es justamente uno de los puntos fuertes a favor de usar RAC, contar con soporte de todos los componentes de la infraestructura por parte del mismo proveedor, lo que da cierta garantía sobre la integración de las partes y se minimiza el tiempo de resolución de incidentes.

Un buen ejemplo de que siempre es necesario consultar la documentación es que HP Serviceguard Storage Management Suite no aparece soportado en 12.1 y sí lo estaba en 11.2 (junto a otros productos).

• ¿Recomendaciones para hacer upgrade de RAC 10g a RAC 11g?

Este es un tema que tiene varios puntas. La mejor recomendación podría ser estudiar  la documentación, y en particular el Blog de Upgrade de Oracle, que tiene todo lo que nos puede interesar sobre upgrades. Este es el link al workshop de Upgrade. También el sitio de soporte tiene mucha información sobre el tema, y la más completa es "Upgrade Advisor: Database from 10.2 to 11.2 (Doc ID 251.1)" que incluye muchas referencas a todas las etapas de un proyecto de upgrade.

Si el upgrade incluye usar nuevo hardware, se puede realizar la instalación con tranquilidad sobre el hardware nuevo para luego evaluar estrategias para replicar datos sin afectar el sistema de producción. Más adelante se aclaró que el upgrade sería sobre el mismo hardware, lo que plantea desafíos adicionales:
- se debe validar que la versión del Sistema operativo (SO) permita realizar un upgrade a la nueva versión (hay años de diferencia entre las versiones, y si bien se certifican nuevas versiones de la base de datos con versiones viejas del SO, normalmente requiere parches en el SO que pueden no estar instalados). Si se requieren parches, se agrega complejidad al proceso y posiblemente una ventana adicional de indisponibilidad.
- al trabajar sobre los mismos servidores que soportan un sistema en producción, se debe buscar un procedimiento que minimice el impacto en la disponiblidad del sistema. Por ejemplo, dependiendo de la cantidad de servidores que tenga el cluster, se podría ir quitando de a un servidor y hacer la actualización mientras el resto sigue funcionando (método conocido como rolling upgrade). Un punto importante es que ASM permite rolling upgrades a partir de 11g, por lo que se debe planificar un tiempo de indisponiblidad para realizar esta actualización desde 10g cuando se llegue al último servidor.

Por culminar, algo obvio pero que no está de mas recordarlo: este tipo de trabajo requiere mucha validación previa, por lo que es imprescindible contar con un ambiente de prueba donde realizar el procedimiento de upgrade completo, y se puedan realizar ajustes y automatizar todo lo posible previo a su ejecución en producción.

• ¿Cómo identificar índices que no se usan?

Esta pregunta tiene que ver con la recomendación de evitar la generación de redo innecesario por tener muchos índices que no se usan.
La respuesta obvia podría ser habilitar la funcionalidad de monitoreo de índices, disponible desde 9i. 
Aunque esta solución es muy simple, no es la mejor porque puede detectar casos que no nos interesan, ya que no registra la frecuencia con que fueron usados. Por ejemplo, un proceso agendado que ejecute por la noche y no tenga impacto en el uso del sistema puede ser el único que use un índice.
Otro aspecto importante para buscar oportunidades de reducir la generación de redo es eliminar índices redundantes, cosa que no tiene mucho que ver con esta detección índices usados.
En los foros de OTN hay varias preguntas similares, y esta es un buen ejemplo con varias respuestas que incluyen todos estos detalles.
Otro enfoque para identificar el uso de índices junto a la frecuencia con que son usados es aprovechar los datos capturados por AWR, si tenemos la versión Oracle Enterprise Edition y la licencia del Diagnostic Pack. Esto es algo bastante comentado en la comunidad, y por ejemplo en este muy completo post se pueden ver scripts y ejemplos de como obtener esta información.

• ¿ASM puede saturar los discos?

ASM es el intermediario para gestionar los discos, pero el acceso a los bloques en disco lo hace el proceso de usuario que lo necesita (y los procesos de la base para escribir). Entonces no hay overhead en el acceso a disco asociado al uso de ASM.
El rendimiento de los discos va a ser el mismo que se pueda obtener por fuera de ASM, con acceso directo desde el sistema operativo (SO). Una buena nota de soporte que intenta aclarar esto es "Comparing ASM to Filesystem in benchmarks (Doc ID 1153664.1)".
Cualquier problema en la configuración que los hace visibles al SO y que pueda impactar en su rendimiento se va a extender a cualquier programa que los use. Esto incluye la conectividad al storage y la redundancia (multipath). Un ejemplo análogo es el uso de raid, donde es posible ver configuraciones que no logran la mejor performance, y cualquier filesystem que utilice estos discos va a sufrir su impacto.
Otra interpretación de la pregunta puede ser apuntando a las tareas internas que ejecuta ASM para garantizar la redundancia configurada. Hay operaciones internas de rebalanceo cuando cambia la cantidad de discos disponibles en los disk groups. Cuando ésta ejecuta se agrega actividad sobre la que ya existe en los discos, y se puede controlar su impacto en la performance con el parámetro ASM_POWER_LIMIT. El avance de estas operaciones se puede seguir en la vista GV$ASM_OPERATION. 

Espero que les sea útil.
Un saludo.

Presentación sobre Oracle RAC este miércoles

El grupo de interés sobre Oracle Real Application Clusters (RACSIG) desde hace años comparte valiosa información técnica en su sitio web, y organiza presentaciones que se pueden seguir en vivo por internet (webinar o webcast). Es una organización similar a un grupo de usuarios, pero no limitado a un país, sino de alcance global. 

Fui invitado a dar una presentación en español, para inaugurar el contenido de habla hispana, y será este miércoles 12 de marzo a las 13:00 hs de Uruguay (GMT-3). Los detalles aquí.

Para seguir la presentación en vivo, se deben registrar previamente en el sitio, que los llevará a este link.

Esta es una versión actualizada con funcionalidades de las últimas versiones (11g/12c) a la presentación que dí durante el OTN Tour 2011 en Montevideo, Oracle RAC sin sorpresas, donde se repasa lo que implica usar Oracle RAC, los desafíos y recomendaciones de cómo sacarle mejor provecho. 

Este enfoque introductorio intenta facilitar el camino a los técnicos que están evaluando o comenzado a utilizar Oracle RAC, tarea que tiene una larga curva de aprendizaje.

Los espero.

Un saludo.

Analizando sentencias con SQL Profile activo en Oracle

Si queremos analizar la performance de una sentencia SQL que tiene un SQL profile habilitado (Oracle 10g o posterior) sin afectar al resto de los usuarios del sistema, ¿cómo hacemos para ver el plan de ejecución original de la sentencia si no se usara el SQL profile?.
Asumiendo que lo vamos a hacer un tiempo después de tener el SQL profile activo y por lo tanto no está presente en la SGA (V$SQL) ni en el repositorio de AWR.

No es necesario deshabilitar ni borrar el SQL profile existente, se puede cambiar el parámetro SQLTUNE_CATEGORY a nivel de sesión para que no se use el SQL profile activo:

SQL> alter session set sqltune_category='OTRA';

Los SQL profile se crean en una categoría (por defecto 'default'), y se usan si la categoría de la sesión (este parámetro) coincide con la del SQL profile creado. Para ver el plan de ejecución original de la sentencia sin usar el SQL profile activo, alcanza con asignar un string cualquiera a la categoría de la sesión actual.

A continuación vemos un ejemplo completo de este comportamiento, incluyendo la creación de un SQL profile sobre una sentencia para forzar el uso de un índice, y luego cambiar este parámetro para ver el plan original, usando Oracle Enterprise Edition 11.2.0.2.

Uso el script coe_xfr_sql_profile.sql provisto por Oracle en el utilitario SQLT (ver nota de soporte 215187.1)  para crear un SQL profile a partir de los hints de una sentencia previamente ejecutada. Esta es la forma más simple de crear un SQL profile para ilustrar con un ejemplo reproducible el cambio de parámetro, aunque el caso queda un tanto artificial. Hay mucha documentación sobre las formas de crear SQL Profiles, pero no es el foco de este post.
De todas formas, este procedimiento es muy útil para troubleshooting de performance, por lo que es interesante tenerlo presente, aunque en este caso solo sea para ilustrar.

Primero creo una tabla, un índice, y ejecuto una consulta que lo usa:

oracle@oraculo:~> sqlplus / as sysdba

SQL*Plus: Release 11.2.0.2.0 Production on Mié Feb 26 14:55:15 2014

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


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, Real Application Clusters and Automatic Storage Management options


14:56:08 SQL> alter session set current_schema=PRU;

Session altered.

14:56:46 SQL> create table pp(n number, c varchar2(100));

Table created.

14:57:03 SQL> insert into pp select rownum, object_id from dba_objects where rownum < 100;

99 rows created.

14:57:33 SQL> create index pp_idx on pp(n);

Index created.

14:57:52 SQL> select * from pp where n=1;

         N C
---------- ---------------------------------------------------------------------------------
         1 28

14:59:17 SQL> select * from table(dbms_xplan.display_cursor);

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------
SQL_ID  86svufrd72xqg, child number 0
-------------------------------------
select * from pp where n=1

Plan hash value: 2830885032

--------------------------------------------------------------------------------------
| Id  | Operation                   | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |        |       |       |     1 (100)|          |
|   1 |  TABLE ACCESS BY INDEX ROWID| PP     |     1 |    65 |     1   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | PP_IDX |     1 |       |     1   (0)| 00:00:01 |
--------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("N"=1)

Note
-----
   - dynamic sampling used for this statement (level=2)


23 rows selected.

Ya tenemos nuestra tabla PP con un índice sobre la columna N, y la consulta que lo usa.
Ahora creamos otra consulta que hace un full scan sobre la tabla, y es a la que luego vamos a asignarle un SQL profile para que use el índice:

14:59:22 SQL> select /*+ full(pp)*/ * from pp where n=1;

         N C
---------- -----------------------------------------------------------------------------------
         1 28

14:59:37 SQL> select * from table(dbms_xplan.display_cursor);

PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------
SQL_ID  btpjqgv0u0stb, child number 0
-------------------------------------
select /*+ full(pp)*/ * from pp where n=1

Plan hash value: 2338859486

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |       |       |     3 (100)|          |
|*  1 |  TABLE ACCESS FULL| PP   |     1 |    65 |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("N"=1)

Note
-----
   - dynamic sampling used for this statement (level=2)


22 rows selected.


15:02:10 SQL> col sql_text for a45

15:02:10 SQL> select sql_id, plan_hash_value, executions, sql_text
from v$sql
where sql_id in ('btpjqgv0u0stb','86svufrd72xqg');

SQL_ID        PLAN_HASH_VALUE EXECUTIONS SQL_TEXT
------------- --------------- ---------- ---------------------------------------------
btpjqgv0u0stb      2338859486          1 select /*+ full(pp)*/ * from pp where n=1
86svufrd72xqg      2830885032          1 select * from pp where n=1

Vemos los SQL_ID de ambas consultas, junto con el plan de ejecución usado.
Ahora usamos el script coe_xfr_sql_profile.sql para crear un SQL profile a la consulta lenta (btpjqgv0u0stb) y que use el plan de la otra (2830885032). Estos son los parámetros que se le deben ingresar al script:

SQL> sta coe_xfr_sql_profile.sql

Parameter 1:
SQL_ID (required)

Enter value for 1: btpjqgv0u0stb


PLAN_HASH_VALUE AVG_ET_SECS
--------------- -----------
     2338859486        ,004

Parameter 2:
PLAN_HASH_VALUE (required)

Enter value for 2: 2830885032

Values passed to coe_xfr_sql_profile:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SQL_ID         : "btpjqgv0u0stb"
PLAN_HASH_VALUE: "2830885032"

SQL>BEGIN
  2    IF :sql_text IS NULL THEN
  3      RAISE_APPLICATION_ERROR(-20100, 'SQL_TEXT for SQL_ID &&sql_id. was not found in memory (gv$sqltext_with_newlines) or AWR (dba_hist_sqltext).');
  4    END IF;
  5  END;
  6  /
SQL>SET TERM OFF;
SQL>BEGIN
  2    IF :other_xml IS NULL THEN
  3      RAISE_APPLICATION_ERROR(-20101, 'PLAN for SQL_ID &&sql_id. and PHV &&plan_hash_value. was not found in memory (gv$sql_plan) or AWR (dba_hist_sql_plan).');
  4    END IF;
  5  END;
  6  /
SQL>SET TERM OFF;

Execute coe_xfr_sql_profile_btpjqgv0u0stb_2830885032.sql
on TARGET system in order to create a custom SQL Profile
with plan 2830885032 linked to adjusted sql_text.


COE_XFR_SQL_PROFILE completed.

Vemos que se ejecutó de forma exitosa, así que nos generó un script que crea el SQL profile.
Lo ejecutamos:

SQL> sta coe_xfr_sql_profile_btpjqgv0u0stb_2830885032.sql
SQL> REM
SQL> REM $Header: 215187.1 coe_xfr_sql_profile_btpjqgv0u0stb_2830885032.sql 11.4.4.4 2014/02/26 carlos.sierra $
SQL> REM
SQL> REM Copyright (c) 2000-2012, Oracle Corporation. All rights reserved.
SQL> REM
SQL> REM AUTHOR
SQL> REM   carlos.sierra@oracle.com
SQL> REM
SQL> REM SCRIPT
SQL> REM   coe_xfr_sql_profile_btpjqgv0u0stb_2830885032.sql
SQL> REM
SQL> REM DESCRIPTION
SQL> REM   This script is generated by coe_xfr_sql_profile.sql
SQL> REM   It contains the SQL*Plus commands to create a custom
SQL> REM   SQL Profile for SQL_ID btpjqgv0u0stb based on plan hash
SQL> REM   value 2830885032.
SQL> REM   The custom SQL Profile to be created by this script
SQL> REM   will affect plans for SQL commands with signature
SQL> REM   matching the one for SQL Text below.
SQL> REM   Review SQL Text and adjust accordingly.
SQL> REM
SQL> REM PARAMETERS
SQL> REM   None.
SQL> REM
SQL> REM EXAMPLE
SQL> REM   SQL> START coe_xfr_sql_profile_btpjqgv0u0stb_2830885032.sql;
SQL> REM
SQL> REM NOTES
SQL> REM   1. Should be run as SYSTEM or SYSDBA.
SQL> REM   2. User must have CREATE ANY SQL PROFILE privilege.
SQL> REM   3. SOURCE and TARGET systems can be the same or similar.
SQL> REM   4. To drop this custom SQL Profile after it has been created:
SQL> REM         EXEC DBMS_SQLTUNE.DROP_SQL_PROFILE('coe_btpjqgv0u0stb_2830885032');
SQL> REM   5. Be aware that using DBMS_SQLTUNE requires a license
SQL> REM         for the Oracle Tuning Pack.
SQL> REM   6. If you modified a SQL putting Hints in order to produce a desired
SQL> REM         Plan, you can remove the artifical Hints from SQL Text pieces below.
SQL> REM         By doing so you can create a custom SQL Profile for the original
SQL> REM         SQL but with the Plan captured from the modified SQL (with Hints).
SQL> REM
SQL> WHENEVER SQLERROR EXIT SQL.SQLCODE;
SQL> REM
SQL> VAR signature NUMBER;
SQL> VAR signaturef NUMBER;
SQL> REM
SQL> DECLARE
  2  sql_txt CLOB;
  3  h       SYS.SQLPROF_ATTR;
  4  PROCEDURE wa (p_line IN VARCHAR2) IS
  5  BEGIN
  6  DBMS_LOB.WRITEAPPEND(sql_txt, LENGTH(p_line), p_line);
  7  END wa;
  8  BEGIN
  9  DBMS_LOB.CREATETEMPORARY(sql_txt, TRUE);
 10  DBMS_LOB.OPEN(sql_txt, DBMS_LOB.LOB_READWRITE);
 11  -- SQL Text pieces below do not have to be of same length.
 12  -- So if you edit SQL Text (i.e. removing temporary Hints),
 13  -- there is no need to edit or re-align unmodified pieces.
 14  wa(q'[select /*+ full(pp)*/ * from pp where n=1]');
 15  DBMS_LOB.CLOSE(sql_txt);
 16  h := SYS.SQLPROF_ATTR(
 17  q'[BEGIN_OUTLINE_DATA]',
 18  q'[IGNORE_OPTIM_EMBEDDED_HINTS]',
 19  q'[OPTIMIZER_FEATURES_ENABLE('11.2.0.2')]',
 20  q'[DB_VERSION('11.2.0.2')]',
 21  q'[OPT_PARAM('optimizer_index_cost_adj' 1)]',
 22  q'[OPT_PARAM('optimizer_index_caching' 100)]',
 23  q'[ALL_ROWS]',
 24  q'[OUTLINE_LEAF(@"SEL$1")]',
 25  q'[INDEX_RS_ASC(@"SEL$1" "PP"@"SEL$1" ("PP"."N"))]',
 26  q'[END_OUTLINE_DATA]');
 27  :signature := DBMS_SQLTUNE.SQLTEXT_TO_SIGNATURE(sql_txt);
 28  :signaturef := DBMS_SQLTUNE.SQLTEXT_TO_SIGNATURE(sql_txt, TRUE);
 29  DBMS_SQLTUNE.IMPORT_SQL_PROFILE (
 30  sql_text    => sql_txt,
 31  profile     => h,
 32  name        => 'coe_btpjqgv0u0stb_2830885032',
 33  description => 'coe btpjqgv0u0stb 2830885032 '||:signature||' '||:signaturef||'',
 34  category    => 'DEFAULT',
 35  validate    => TRUE,
 36  replace     => TRUE,
 37  force_match => FALSE /* TRUE:FORCE (match even when different literals in SQL). FALSE:EXACT (similar to CURSOR_SHARING) */ );
 38  DBMS_LOB.FREETEMPORARY(sql_txt);
 39  END;
 40  /

PL/SQL procedure successfully completed.

SQL> WHENEVER SQLERROR CONTINUE
SQL> SET ECHO OFF;

            SIGNATURE
---------------------
   613978514929328923


           SIGNATUREF
---------------------
 16370312570377067161


... manual custom SQL Profile has been created


COE_XFR_SQL_PROFILE_btpjqgv0u0stb_2830885032 completed

El SQL profile se creó, así que validamos si la consulta que antes hacía un acceso full sobre la tabla ahora toma el índice:

15:14:08 SQL> select /*+ full(pp)*/ * from pp where n=1;

         N C
---------- ---------------------------------------------------------------------
         1 28

15:14:09 SQL> select * from table(dbms_xplan.display_cursor);

PLAN_TABLE_OUTPUT
---------------------------------------------------------------------------------------------
SQL_ID  btpjqgv0u0stb, child number 1
-------------------------------------
select /*+ full(pp)*/ * from pp where n=1

Plan hash value: 2830885032

--------------------------------------------------------------------------------------
| Id  | Operation                   | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |        |       |       |     1 (100)|          |
|   1 |  TABLE ACCESS BY INDEX ROWID| PP     |     1 |    65 |     1   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | PP_IDX |     1 |       |     1   (0)| 00:00:01 |
--------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("N"=1)

Note
-----
   - SQL profile coe_btpjqgv0u0stb_2830885032 used for this statement


23 rows selected.

15:14:50 SQL> select category, status
15:15:04   2  from dba_sql_profiles
15:15:09   3  where name='coe_btpjqgv0u0stb_2830885032';

CATEGORY                       STATUS
------------------------------ --------
DEFAULT                        ENABLED

Perfecto, el SQL profile está haciendo lo que esperamos y está activo.
Recién ahora estamos en la situación que me interesaba mostrar: ¿cómo hacemos para ver el plan de ejecución original de esta sentencia?. Uso el string OTRA, pero podría ser cualquier string distinto de DEFAULT:

15:15:50 SQL> alter session set sqltune_category='OTRA';

Session altered.

15:16:02 SQL> select /*+ full(pp)*/ * from pp where n=1;

         N C
---------- ---------------------------------------------------------------------------------
         1 28

15:16:12 SQL> select * from table(dbms_xplan.display_cursor);

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------------------
SQL_ID  btpjqgv0u0stb, child number 2
-------------------------------------
select /*+ full(pp)*/ * from pp where n=1

Plan hash value: 2338859486

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |       |       |     3 (100)|          |
|*  1 |  TABLE ACCESS FULL| PP   |     1 |    65 |     3   (0)| 00:00:01 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("N"=1)

Note
-----
   - dynamic sampling used for this statement (level=2)


22 rows selected.

Vemos que al ejecutar la sentencia se vuelve a comportar como antes, sin usar el SQL profile.

Espero les sea útil.

Oracle RAC 12c sobre Oracle VM y VirtualBox usando Templates

OTN publicó hace unos días un hands-on lab How to Deploy a Four-Node Oracle RAC 12c Cluster in Minutes Using Oracle VM Templates, basado en una sesión del Oracle Open World 2013.
Es un artículo muy bueno, con todos los detalles para hacer la configuración e instalación, usando un equipo con 16gb de RAM para configurar 4 nodos virtuales con Oracle RAC 12c.

Pero sobre el final (y después de unas 3 hs de trabajo si se siguen las instrucciones) aclara: el objetivo del lab no es dejar corriendo el cluster porque no dan los recursos del servidor para hacerlo. Citando el texto original:

"Note: The goal of this lab is to show how to create a four-node cluster using Oracle VM with Flex Cluster 
and Oracle Flex ASM, not to actually run a four-node cluster. Because of the limited resources we have on the 
x86 machine, the build for this four-node cluster will not finish. By comparison, a similar deployment on a
 bare-metal/Oracle VM environment with adequate resources would take around 30 to 40 minutes."

Ya no parece tan interesante.
Pero con mínimos cambios se puede dejar corriendo un cluster de dos nodos. Ahora es más atractivo, aunque utiliza mucho hardware, pero es una buena alternativa por varios motivos:

• el tiempo que lleva de deploy es menor a otras alternativas.
• para familiarizarse con el uso de Oracle VM, templates de OVM, y Oracle RAC sin tener que instalar OVM en un servidor de pruebas.

Antes de contarles detalles sobre mi experiencia, un poco de background sobre las opciones para hacer deploys "rápidos" de máquinas virtuales con Oracle:

• Oracle RAC está soportado en producción sobre varias tecnologías de virtualización, entre ellas Oracle VM (OVM), pero no VirtualBox.  OVM Server se debe instalar en el equipo que se use para virutalizar, lo que lo deja fuera notebooks o instalaciones de test que tienen otros propósitos y no hay nadie que se haga cargo de su administración (es más complejo administrar un equipo que usa OVM Server para correr virtuales que uno que usa Linux + VirtualBox)

• Oracle tiene imágenes de máquinas virtuales OVM preinstaladas con todo lo necesario (VM Templates) para distintos propósitos, entre ellos la base de datos con la opción de RAC, para 11g y 12c. No hay templates para VirtualBox.

• Hay forma de convertir las imágenes de OVM a Virtualbox, pero lleva un poco de trabajo. Si andan con tiempo, este es un muy buen artículo de cómo hacerlo, usando templates de 11.2: Build an 11gR2 RAC Cluster in VirtualBox in 1 Hour Using OVM Templates. No probé usarlo con los nuevos templates de 12.1.

• Siempre se puede crear desde cero las máquinas virtuales, instalar el sistema operativo, configurar storage, instalar Grid, Oracle y luego configurar todo. También hay guías muy buenas al respecto (como esta de Tim Hall - RAC 12c + OEL6 + virtualbox), pero es una tarea que lleva bastante más tiempo que solamente seguir la guía del lab.

Así que comparto mi experiencia usando un pc con AMD FX(tm)-8120 Eight-Core Processor de 1.4Ghz, 32Gb de RAM y openSUSE 12.3 x64

Primer intento

Siguiendo la guía al pie de la letra, el último paso que levanta las 4 VM de RAC falla con los siguientes mensajes, después de 4:45hs de haber comenzado el primer paso (sin contar el tiempo que lleva descargar los archivos que se necesitan).

tail -f /u01/racovm/buildcluster.log

ERROR (node:rac2): Failed to run rootcrs.pl, status: 25
See log at: /u01/app/12.1.0/grid/cfgtoollogs/crsconfig/rootcrs_rac2_2014-02-15_11-32-40AM.log
2014-02-15 12:26:28:[girootcrslocal:Time :rac2] Completed with errors in 3230 seconds (0h:53m:50s), status: 25

INFO (node:rac0): All girootcrslocal operations completed on all (4) node(s) at: 12:27:22
2014-02-15 12:28:24:[girootcrs:Time :rac0] Completed with errors in 5497 seconds (1h:31m:37s), status: 3
2014-02-15 12:29:19:[creategrid:Time :rac0] Completed with errors in 5786 seconds (1h:36m:26s), status: 3
2014-02-15 12:29:43:[buildcluster:Time :rac0] Completed with errors in 6160 seconds (1h:42m:40s), status: 3

Segundo intento

Antes de descartar el uso de las 4 VM probé cambiar la configuración en VirtualBox del OVM server para que use 6 CPU en vez de las 2 que trae configuradas por defecto.
Usando la consola web de OVM Manager detuve las 4 VM, las borré y luego paré en VirtualBox OVM Server, cambié la configuración de CPUs, lo inicié y repetí los pasos desde el punto 11 (Clone Four Virtual Machines from the Template).

El resultado al levantar las VM fue el mismo: error. Aunque esta vez el servidor quedó bastante más cargado y casi no respondía

tail -f /u01/racovm/buildcluster.log
...
ERROR (node:rac1): Failed to run rootcrs.pl, status: 25
See log at: /u01/app/12.1.0/grid/cfgtoollogs/crsconfig/rootcrs_rac1_2014-02-15_03-10-06PM.log
2014-02-15 16:17:24:[girootcrslocal:Time :rac1] Completed with errors in 4039 seconds (1h:07m:19s), status: 25
....
INFO (node:rac0): Waiting for all girootcrslocal operations to complete on all nodes (At 16:42:22, elapsed: 1h:28m:47s, 
1 node(s) remaining, all background pid(s): 26984)...

Y esta es la carga del nodo0:

[root@rac0 ~]# uptime
 18:32:08 up  4:11,  1 user,  load average: 38.79, 36.94, 35.97