Etimo: Tecnología Oracle

La vista DBA_HIST_ACTIVE_SESS_HISTORY y su origen GV$ACTIVE_SESSION_HISTORY mantienen un muestreo de lo que hacen las sesiones que tienen actividad en el sistema. La primera mantiene un historial de lo capturado por la vista VG$ y de acuerdo a la retención especificada en el repositorio AWR y la segunda sólo mantiene algunas horas. Estas vistas se pueden usar de muchas maneras distintas para entender y mejorar el desempeño de una BD. La plataforma Cloud Control la utiliza en la gran mayoría de las páginas del pack de diagnóstico. El uso de estas vistas requiere poseer la licencia del pack de diagnóstico. En este artículo nos concentramos en el uso de la columna XID de estas vistas. XID es el identificador de transacción, es decir, cada transacción tiene un valor distinto de XID. Esta columna nos permite entonces agrupar una serie de filas de la vista agrupadas por XID, es decir agrupadas por transacción. Pero cómo se relaciona este valor con el resto de vistas del diccionario que...

Un error frecuente en programación java es el desconocimiento de métodos estáticos. Los métodos estáticos se pueden usar en condiciones similares a los procedimientos y funciones de los lenguajes procedurales. Los métodos de objetos, en cambio, que modifica o consulta principalmente al objeto al que pertenecen. Si uno desea construir una función que opera totalmente con los parámetros que recibe y no hace uso de ninguno de los atributos del objeto, entonces estamos frente a un candidato a método estático. A continuación se decribe un ejemplo y se realizan pruebas de tiempos con él. En el ejemplo se tiene una clase "ObjetoA" que tiene un método no estático. Para poder invocar ese método en necesario instanciar un objeto de la clase e invocar el método con él. La Clase SimulaMalo invoca al metodo del ObjetoA. ObjetoA.java: public class ObjetoA {     String P1="Parametro1";     String P2="Parametro2";     String P3="Parametro3";     Strin...

La captura de las estadísticas de sistema consiste en que Oracle toma los tiempos de hacer lecturas de 1 bloque, lecturas multibloque y velocidad de CPU. Con esto el optimizador genera planes considerando el uso de CPU y diferenciado lecturas random, que son de 1 bloque, de lecturas secuenciales, que son de un número mayor de bloques controlado por el parámetro multiblock_read_count. Si uno no ha corrido las estadísticas de sistema, el CBO funciona igual que en Oracle8i, es decir no concidera costo de CPU y considera igual el costo de lectura random de 1 bloque que la lectura secuencial multibloque. Uno de los efectos negativos del no contar con estadísticas de sistema es que el optimizador considera el mismo costo una operación single block que una multiblock y con ello parace que los planes "TABLE FULL SCAN" parecen mas baratos. La realidad podría ser que una operación single block demore 5ms y una multiblock de 16 bloques demore 17ms. El optimizador, con estadísticas d...

El costo de un acceso a filas usando INDEX SCAN lo calcula el CBO con: blevel + FF*leaf_blocks + FF*clustering_factor Donde: FF es el "Factor de Filtro" que indica la proporción de registros que se recupera al aplicar el predicado de la query al índice. Clustering_factor es una estadística calculada por Oracle para cada índice que que refleja la magnitud de orden de las filas basado en los valores del índice: Si el valor es cercano al número de bloques, entonces la tabla está muy bien ordenada. En este caso las entradas del índice en el mismo bloque hoja tienden a apuntar a filas en el mismo bloque de datos. Si el valor es cercano al numero de filas, entonces la tabla no está ordenada con respecto al índice. En este caso, es improbable que las entradas en un bloque hoja del índice apunten a los mismos bloques de datos. Cada término de esta fórmula representa: blevel: Bloques de recorrido del árbol del índice FF*leaf_blocks: Cantidad de bloques hojas que se deben recor...

Al analizar un proceso de carga se pudo determinar que cuál sentencia SQL era la mas consumidora. A continuación se muestra un extracto de la salida de tkprof: SELECT     LTCD_CDG_IATA_ITN_ORI,LTCD_CDG_IATA_ITN_DES,LTFC_DIA_CDG_ITN_ARR_DATE    ,LTFC_DIA_CDG_ITN_DEP_DATE FROM    FTPS WHERE    FTPS_PNR_CDG = :b1  AND FTPS_SEG_NMR = :b2  AND LTFV_DIA_CDG =  :b3 call     count       cpu    elapsed       disk      query    current        rows ------- ------  -------- ---------- ---------- ---------- ----------  ---------- Parse        0      0.00       0.00          0          0          0           0 Execute   9413      0.52...

En Oracle existe un utilitario oculto que permite la edición binaria del contenido de los bloques. Mediante este utilitario es posible manipular las distintas estructuras de cualquier bloque de una BD Oracle. Este utilitario viene en cualquier instalación Oracle, pero no se linkea el ejecutable a menos que uno lo haga explícitamente. Para linkearlo hay que: cd $oh/rdbms/lib make -f ins_rdbms.mk $oh/rdbms/lib/bbed Después hay que invocarlo con parámetros: $oh/rdbms/lib/bbed password=blockedit blocksize=<tamaño de bloque> filename=<archivo a editar>

El montaje de imagenes iso en linux se hace: mount -o loop <path de la imagen> <dir de montaje> Por ejemplo: mount -o loop /mnt/images/Centos3.8/CentOS-3.8-i386-bin1of3.iso /mnt/cdrom

La mayoría de los linux viene preconfigurado con la variable LANG con el valor "en_US.UTF-8", es decir, con set de caracteres UTF-8. Cuando un se conecta con utilitarios de línea de comandos como putty, los caracteres no se ven bien. Por ejemplo, en la salida de pstree se muestran caracteres que no se muestran adecuadamente. Esto se puede resolver mediante: export LANG="en_US" Si se desea cambiar el valor por default de esta variable, se debe lo debe hacer en el archivo /etc/sysconfig/i18n. Este archivo es leído por el script /etc/profile.d/lang.sh El contenido original del archivo es: LANG="en_US.UTF-8" SUPPORTED="en_US.UTF-8:en_US:en:es_CL.UTF-8:es_CL:es" SYSFONT="latarcyrheb-sun16" Y se debe cambiar por: LANG="en_US" SUPPORTED="en_US.UTF-8:en_US:en:es_CL.UTF-8:es_CL:es" SYSFONT="latarcyrheb-sun16"

En ciertas ocasiones debemos actualizar un conjunto de datos de tal forma que queden idénticos al resultado de una query. Como requisito adicional, tanto los datos de la query origen como la tabla destino tienen un mismo conjunto de columnas que podría ser considerada llave primaria, es decir, que no tienen valores nulos y que no producen registros duplicados. Por ejemplo: hay una tabla con transacciones diarias y es posible que después de cargar las transacciones haya que reprocesar los datos por algún motivo en particular. En este ejemplo, es claro que no existe la alternativa de truncar la tabla original y cargar los datos a partir de la tabla de paso ya que no solo se estarían truncando los registros que se van a cargar sino que también se truncarían los registros de otros días. Otro ejemplo: una tabla debe ser refrescada todos los días. Algunos registros son nuevos, otros se mantienen y otros desaparecen. De los que se mantienen, una gran mayoría queda intacto y unos poco...