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, 2979 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, 5373 views. Categories: Base de datos, Tuning / Performance ,

Windows 8 - 2012 y la certificación de Oracle



Me acaba de consultar un amigo sobre la certificación de Oracle sobre plataformas Windows 2008 y Windows 2012, la verdad yo pensaba que no estaba soportado aún... Pero me lleve una gran sorpresa :)



Claro que se encuentra soportado, según lo exponen en esta nota de Setiembre del año pasado

Un extracto de ella es el siguiente y dice que desde la versión 11.2.0.4 o desde el siguiente release (12c) estará soportado, todo bien , pero .... |-| , la versión 11.2.0.4 no existe jejeje así tal cual, esa versión no está disponible como parche en ningún Sistema Operativo



La nota está disponible en
http://www.oracle.com/technetwork/database/windows/tech-info/sod-oracle-db-win8-win2012-1853201.pdf

Es cosa de ir a http://metalink.oracle.com en la lengüeta de "Patches & Updates" y buscar el link "Latest Patchsets" , la buscar sólo aparecen hasta las versiones 11.2.0.3



Cosas de la vida .... B)


Espero les sirva...

by Ligarius
21.03.13. 12:56:17. 155 words, 5860 views. Categories: Instalación ,

Sobre medios en Oracle9i y Oracle10g (Instaladores)



He visto a mucha gente complicarse por el tema de los medios de Oracle10g y Oracle9i, pues Oracle lamentablemente ya no los tiene a disposición y no saben de donde obtenerlos .







Para aquellos que se complican un poco con el tema de los medios, los tengo disponibles en las siguientes versiones y sus correspondientes Sistemas Operativos :



  • Oracle9i Database (64-bit) Release 2 (9.2.0.1.0) for Sun SPARC Solaris
    - Motor Oracle
    - Documentación


  • Oracle9i Database (64-bit) Release 2 (9.2.0.1.0) for AIX-Based 5L
    - Motor Oracle
    - Documentación


  • Oracle9i Database Release 2 (9.2.0.4.0) for Linux x86-64
    - Motor Oracle
    - Documentación


  • Oracle10g Release 2 (10.2.0.1.0) for Linux x86-64
    - Motor Oracle
    - Cliente Oracle
    - Clusterware
    - Companion
    - Gateways
    - Documentación


  • Oracle10g Release 2 (10.2.0.1.0) for Solaris Operating System (SPARC 64-bit)
    - Motor Oracle
    - Companion
    - Cliente Oracle
    - Clusterware
    - Gateways
    - Documentación


  • Oracle10g Release 2 (10.2.0.1.0) for AIX5L Based Systems (64-bit)
    - Motor Oracle
    - Companion
    - Clusterware
    - Gateways
    - Cliente Oracle
    - Documentación


  • Oracle10g Release 2 (10.2.0.1.0) for Solaris Operating System (x86-64bits)
    - Motor Oracle
    - Cliente Oracle
    - Clusterware
    - Companion
    - Documentación

    Además de todos los parches para cada una de las versiones y los productos a descargar , incluyen el motor Oracle, clusterware, gateway , etc...



    Una vez que los deje en un sharing respetable , se los comento ... así me pueden escribir a hector.ulloa@gmail.com y de vuelta les envío el link de lo que necesitan para la descarga y la clave que necesitarán para el archivo comprimido.

    Actualización :
    Los medios están disponibles en
    http://www.oracleyyo.com/index.php/2014/01/15/links_descarga_oracle

    Espero les sea de utilidad

    Una nota que habla del como conseguirse todos esos medios
    http://www.oracleyyo.com/index.php/2012/07/12/download_9i_10g

  • by Ligarius
    18.03.13. 11:20:13. 306 words, 5808 views. Categories: Instalación ,

    Cosas sobre sys.col_usage$



    La tabla sys.col_usage$ almacena de forma automática a través del proceso SMON , la cantidad de veces que alguna columna se ocupa en una claúsula WHERE de una sentencia SQL, si esto lo miramos con un poco de altura de miras, no solamente veremos que es información estadística que se almacena para siempre y por siempre, he acá algunas cosas para tener en cuenta



    Desde está información por ejemplo nosotros podríamos chequear cual es el mejor índice o cuales son los índices necesarios en una tabla de acuerdo a los filtros que tenga..

    La estructura de la tabla

    SQL> desc sys.col_usage$
    Name Null? Type
    ----------------------------------------- -------- -----------------------
    OBJ# NUMBER
    INTCOL# NUMBER
    EQUALITY_PREDS NUMBER
    EQUIJOIN_PREDS NUMBER
    NONEQUIJOIN_PREDS NUMBER
    RANGE_PREDS NUMBER
    LIKE_PREDS NUMBER
    NULL_PREDS NUMBER
    TIMESTAMP DATE



    La explicación de sus columnas

    OBJ# : Es el id del objeto (tabla principal) , este id lo podemos ubicar en DBA_OBJECTS.OBJECT_ID

    INTCOL# : Es el id de la columna, se puede obtener su nombre desde DBA_TAB_COLUMNS.COLUMN_ID

    EQUALITY_PREDS : Es la cantidad de filtros en el where del tipo
    ej : where campo1 = -literal-

    EQUIJOIN_PREDS : Es la cantidad de filtros en el where del tipo
    ej : where tabla1.campo1 = tabla2.campo1

    NONEQUIJOIN_PREDS : Es la cantidad de filtros en el where del tipo
    ej : where tabla1.campo1 =! tabla2.campo1

    RANGE_PREDS : Es cuando el campo es utilizado dentro de una claúsula BETWEEN

    LIKE_PREDS : Es cuando el campo es utilizado dentro de una claúsula LIKE

    NULL_PREDS : Es cuando se consulta por si el campo es nulo o no nulo
    ej : where tabla1.campo1 is null

    TIMESTAMP : Es la fecha en que se produjo la última utilización de fitros (where) para un objeto en partícular.



    Una forma más amistosa de chequear los datos de la tabla SYS.COL_USAGE$ es mediante la siguiente consulta, que entrega los nombres de los objetos y claro, el nombre de la columna de forma inmediata

    select oo.name owner,
    o.name,
    c.name column_name,
    u.equality_preds,
    u.equijoin_preds,
    u.nonequijoin_preds,
    u.range_preds,
    u.like_preds,
    u.null_preds,
    u.timestamp
    from sys.col_usage$ u ,
    sys.obj$ o ,
    sys.user$ oo,
    sys.col$ c
    where o.obj# = u.obj#
    and oo.user# = o.owner#
    and c.obj# = u.obj#
    and c.col# = u.intcol#
    AND o.name = 'nombre del objeto a consultar'



    Esta tabla también tiene la gracia que a partir de ahí Oracle puede generar los histogramas cuando se ocupa el package DBMS_STATS con el parámetro METHOD_OPT => 'FOR all COLUMNS SIZE auto', o sea, le indicamos a él que calcule la cantidad de buckets para nuestro histograma (de 1 a 256)

    Si hacemos lo siguiente

    - Generamos una tabla
    - Cargamos datos en la tabla
    - Generamos histogramas

    No estaría correcto, ya que los histogramas no se van a generar con información fidedigna , a menos que haya información en la SYS.COL_USAGE$ y solamente habrá información en esa tabla si comenzamos a utilizar filtros en la consultas que ocupan esa tabla

    A partir de Oracle10g la información se carga a esta tabla cuando se produce una toma de estadísticas o se puede hacer ejecutando la siguiente instrucción

    exec dbms_stats.flush_database_monitoring_info;



    La carga de está información se realiza con una frecuencia de minutos , quizás podríamos decir unos 15 , o cuando se hace alguna actualización o inserción , como podemos apreciar de distintas fuentes está tabla SYS.COL_USAGE$ se actualiza

    by Ligarius
    04.03.13. 07:32:11. 610 words, 3789 views. Categories: Base de datos, Tuning / Performance ,

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