Por fin Oracle Database 12c



Bueno, esto es lo que muchos esperabamos, la liberación de Oracle Database 12c

Primero , deben ir al sitio

http://edelivery.oracle.com (Con una cuenta válida)

Después seleccionar el pack de 12c para el Sistema Operativo que deseen (Sólo está disponible para Linux x86-64 , Solaris Sparc 64 y Solaris x86-64 , nada de Windows por el momento)

Una vez ubicado el pack, pues simplemente descargamos los medios

Si lo anterior es muy complicado, pues puedes bajar directamente desde http://otn.oracle.com

Espero lo disfruten tanto como yo ;)

by Ligarius
25.06.13. 19:08:40. 92 words, 2056 views. Categories: Oracle 12c ,

Comenzando a estudiar Oracle Database 12c



Bueno, como todos ustedes saben estamos ad-portas de la liberación de Oracle Database 12c, supuestamente era a finales de Febrero, pero ahora hay personas que dicen que será a finales de Agosto...

Pues lo único que queda es estudiar en la medida que se pueda , en mi caso ya he solicitado algunos libros que me parecieron interesantes, ahora sólo falta que lleguen :(



by Ligarius
05.06.13. 06:25:41. 64 words, 4989 views. Categories: Oracle 12c ,

Hint OPT_PARAM



Leyendo algunas notas me encontré con un parámetro muy útil llamado OPT_PARAM, el cual nació en Oracle10gr2, pero del cual hay sólo notas en Metalink ...







Caso habitual , te has enfrentado a veces en la necesidad de probar algún parámetro y claro, debes hacer un ALTER SESSION o derechamente hacer una modificación al init o spfile y probar los cambios..

Pues este HINT sirve para eso, comprobar el estado de un cambio de parámetros a nivel de sentencia SQL, con lo cual podemos probar online cualquier modificación, el cambio sólo sirve para aquellos parámetros que hacen una modificación al optimizador, no se puede modificar por ejemplo la ruta de los archives |-|




¿Cómo funciona? Con los siguientes ejemplos , les quedará claro el como..

1) Creamos 2 tablas de ejemplo , llamadas t y t2
create table t as select * from dba_objects;
create table t2 as select * from dba_objects;


2) Hacemos un simple join entre ambas tablas , al ver el plan de ejecución , podremos observar que hace un HASH JOIN

SQL> select t.owner
  2    from t ,
  3         t2
  4   where t.object_id = t2.object_id;

72659 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 2663495741

---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      | 63977 |  2686K|   569   (1)| 00:00:07 |
|*  1 |  HASH JOIN         |      | 63977 |  2686K|   569   (1)| 00:00:07 |
|   2 |   TABLE ACCESS FULL| T2   | 63977 |   812K|   283   (1)| 00:00:04 |
|   3 |   TABLE ACCESS FULL| T    | 69344 |  2031K|   284   (1)| 00:00:04 |
---------------------------------------------------------------------------

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

   1 - access("T"."OBJECT_ID"="T2"."OBJECT_ID")

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


3) Ahora vamos a deshabilitar el HASH JOIN , con el OPT_PARAM , ejecutamos el plan de ejecución

SQL> select /*+ opt_param('hash_join_enabled','false') */
  2         t.owner
  3    from t ,
  4         t2
  5   where t.object_id = t2.object_id;

72659 rows selected.


Execution Plan
----------------------------------------------------------
Plan hash value: 219814191

------------------------------------------------------------------------------------
| Id  | Operation           | Name | Rows  | Bytes |TempSpc| Cost (%CPU)| Time     |
------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT    |      | 63977 |  2686K|       |  1447   (1)| 00:00:18 |
|   1 |  MERGE JOIN         |      | 63977 |  2686K|       |  1447   (1)| 00:00:18 |
|   2 |   SORT JOIN         |      | 63977 |   812K|  2520K|   592   (2)| 00:00:08 |
|   3 |    TABLE ACCESS FULL| T2   | 63977 |   812K|       |   283   (1)| 00:00:04 |
|*  4 |   SORT JOIN         |      | 69344 |  2031K|  5448K|   855   (1)| 00:00:11 |
|   5 |    TABLE ACCESS FULL| T    | 69344 |  2031K|       |   284   (1)| 00:00:04 |
------------------------------------------------------------------------------------

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

   4 - access("T"."OBJECT_ID"="T2"."OBJECT_ID")
       filter("T"."OBJECT_ID"="T2"."OBJECT_ID")

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


Según la documentación de Oracle , los únicos parámetros modificables a través del OPT_PARAM son OPTIMIZER_DYNAMIC_SAMPLING, OPTIMIZER_INDEX_CACHING, OPTIMIZER_INDEX_COST_ADJ, OPTIMIZER_SECURE_VIEW_MERGING y STAR_TRANSFORMATION_ENABLED, pero en realidad se pueden modificar parámetros normales y ocultos, por ejemplo _FIX_CONTROL , HASH_JOIN_ENABLED, etc


La documentación oficial del hint OPT_PARAM
http://docs.oracle.com/cd/E11882_01/server.112/e26088/sql_elements006.htm#SQLRF51119


Espero les sirva

by Ligarius
22.05.13. 12:15:32. 446 words, 6304 views. Categories: Tuning / Performance ,

Exámen Beta 1z1-028 : Oracle Database Cloud Administration



Me acaba de llegar un correo indicandome si quería dar un exámen Beta relacionado a la administración de bases de datos Cloud ...lo pensé , pues estoy orientado a obtener el OCE de RAC 11gr2, pero me llamó la atención este exámen y lo compré...






Sus características :

- Es un exámen Beta
- Solamente está disponible desde el 04 de Mayo hasta el 08 de Junio
- No se muestran ni la cantidad de preguntas , ni el tiempo máximo para rendirlo, pero como en todo exámen beta, las preguntas deben ser cerca de 180 y el tiempo , cercano a las 3 o 3,5 horas..

Así que a estudiar , ¿de dónde? , pues de los siguientes links

http://docs.oracle.com/cd/E24628_01/index.htm

https://cloud.oracle.com

http://www.oracle.com/us/solutions/cloud/overview/index.html

Espero me vaya bien, aunque los resultados recién los obtendré en 3 meses más

;

by Ligarius
08.05.13. 20:49:38. 156 words, 2540 views. Categories: Certificaciones ,

Retención de los snapshots e información de las DBA_HIST



Esta consultando información desde la tabla DBA_HIST_SEG_STAT y sólo encontre información de la última semana, pero la verdad esto no me sirve de mucho y quiero que el período a consultar sea un poco mayor...

¿A qué se debe que tenga tan poca retención? He aquí la explicación




La información que se visualiza en las DBA_HIST se carga cuando se están generando los Snapshots del AWR y se elimina cuando estos últimos se purgan, o sea, dependen directamente del intervalo de tiempo en donde se recogen estos Snapshots de AWR y se mantienen en línea el tiempo de retención seteado para los Snaps de AWR.


Para saber que seteo nosotros poseemos en nuestras bases de datos podemos ejecutar la siguiente consulta

select
extract( day from snap_interval) *24*60+
extract( hour from snap_interval) *60+
extract( minute from snap_interval ) "Intervalo entre Snaps",
extract( day from retention) *24*60+
extract( hour from retention) *60+
extract( minute from retention ) "Periodo de retencion seg" ,
extract( day from retention) "Periodo de retencion dias"
from dba_hist_wr_control;



Cuyo resultado se visualizaría de la siguiente forma

Intervalo entre Snaps Periodo de retencion seg Periodo de retencion dias
--------------------- ------------------------ -------------------------
15 86400 60



¿Cuál es el mejor período de retención e intervalo para tomar los Snapshots?

Aquí todo depende, ¿de qué depende? Pues del tamaño de nuestro tablespace SYSAUX, de que tanta carga tenga nuestra base de datos, etc, etc.

Pero podemos imaginarnos el tamaño que podría necesitar, para ello consultamos nuestro AWR dentro del tablespace SYSAUX, para ello ejecutamos la siguiente consulta

SQL> r
1 SELECT occupant_name, schema_name, move_procedure,
2 space_usage_kbytes
3 FROM v$sysaux_occupants
4* ORDER BY 1



El dato que nos interesa , aparecería de la siguiente forma

OCCUPANT_NAME SCHEMA_NAME MOVE_PROCEDURE SPACE_USAGE_KBYTES
------------------------------ -------------------- ----------------------------------- ------------------
SM/AWR SYS 10432448



Aquí podemos apreciar claramente cuanto es lo que usan nuestros snapshots para el período de tiempo de retención

Otra forma de obtener los datos que necesitamos , ejecutando el siguiente comando desde SQL*Plus

@?/rdbms/admin/awrinfo.sql



Dentro del reporte que se obtiene , podemos ver el intervalo en que se toman los snapshots y el período de retención, para ello buscamos el punto (6)

(6) AWR Control Settings - interval, retention



También podemos buscar el tamaño calculado para nuestros snapshots , con lo cual podemos saber de una manera óptima cuanto es el tamaño en Gb o en MB que necesitamos si queremos ampliar nuestro período de retención para los snapshors del AWR.

Dentro de la salida del awrinfo.sql , existe un punto llamado

*************************************
(2) Size estimates for AWR snapshots
*************************************
|
| Estimates based on 60 mins snapshot INTERVAL:
| AWR size/day 27.7 MB (1,182 K/snap * 24 snaps/day)
| AWR size/wk 193.9 MB (size_per_day * 7) per instance
|
| Estimates based on 4 snaps in past 24 hours:
| AWR size/day 4.6 MB (1,182 K/snap and 4 snaps in past 24 hours)
| AWR size/wk 32.3 MB (size_per_day * 7) per instance
|



Donde podemos ver claramente cuanto pesan nuestros Snaps por día.

Una vez que hemos realizado los cálculos necesarios para chequear el tamaño del tablespace SYSAUX , procedemos a cambiar el intervalo de retención y el intervalo de captura de nuestros snapshots de AWR, para ello ejecutamos el siguiente package

execute dbms_workload_repository.modify_snapshot_settings (
interval => xx,
retention => xxxxx );



Donde le indicamos el intervalo para sacar snapshots en minutos y el período de retención en segundos, ejemplo :

Para sacar los snapshots cada 60 minutos con una retención de 69 días

1 begin
2 dbms_workload_repository.modify_snapshot_settings (interval => 60,retention => 100000 );
3* end;
SQL> /

PL/SQL procedure successfully completed.


Una vez modificado podemos consultar nuevamente el seteo

SQL> select
2 extract( day from snap_interval) *24*60+
3 extract( hour from snap_interval) *60+
4 extract( minute from snap_interval ) "Intervalo entre Snaps",
5 extract( day from retention) *24*60+
6 extract( hour from retention) *60+
7 extract( minute from retention ) "Periodo de retencion seg" ,
8 extract( day from retention) "Periodo de retencion dias"
9 from dba_hist_wr_control;

Intervalo entre Snaps Periodo de retencion seg Periodo de retencion dias
--------------------- ------------------------ -------------------------
60 100000 69

Espero les sirva...

by Ligarius
06.05.13. 14:21:52. 688 words, 4635 views. Categories: Base de datos, Tuning / Performance ,

<< 1 ... 6 7 8 9 10 11 12 13 14 15 16 ... 44 >>