Category: Oracle 10g

¿Reconstruir o no un índice? (rebuild or not rebuild an index?)



Index Rebuild ¿es necesario?



Leyendo un artículo de Oracle sobre la reconstrucción de los índices , indica que rara vez es necesario hacer un rebuild de los índices, es más ... indica que la política de reconstruir índices está muy "embebida" en los DBAs y a veces reconstruyen sin siquiera haber realizado un pequeño análisis estadisticos del índice.

¿Por qué no se debiese reconstruir un índice?
Pues simplemente porque un índice de B*Tree es en sí una estructura que se auto-balancea y que se auto-mantiene por sí misma.

Por ejemplo siempre escuchamos que las DMLs dejan "orificios" en el índice que no son llenados y desbalancean el índice.

Pues eso no es tan así, pues cada vez que se produce un borrado de datos, se genera un leaf node vacío, el cual será sí o sí reutilizado.

¿Cuáles son las mayores justificaciones para hacer un rebuild a un índice?

  • Fragmentación del índice
  • Crecimiento del índice y su espacio "borrado" no es reutilizado
  • Factor de clustering del índice está fuera de sincronización

    En muchos de los casos , se mantiene el balanceo y sin fragmentación , debido a que las entradas (leafs) son reusadas.

    Las DMLs resultan en un slot libre que pueda estar alrededor de un bloque de índice. Pero estos "espacios libres" tipicamente son rellenados

    El índice de clusterización refleja como los datos en la tabla son ordenados respecto a su
    llave de indexación.

    La reconstrucción de un índice nunca va a influenciar en el factor de clustering, para esto se debiese llevar a cabo una reorganización de la tabla



    ¿Cuáles son los costos de reconstruir un índice?

    Pues son muchos y por ello se debiesen tener en cuenta los siguientes aspectos

    1.- Casi todos los scripts dependen de los datos de la tabla INDEX_STATS, la cual se carga con el comando

    ANALYZE INDEX ... VALIDATE STRUCTURE;

    El problema de este comando es que deja la tabla en un modo de bloqueo exclusivo, mientras se analiza el índice. Para índices muy grandes esto puede ser dramático, pues cualquier DML sobre la tabla en el período de análisis, no va a poder ser llevado a cabo.


    2.- La actividad de redo y la performance en generar se ven afectadas como resultado directo de la reconstrucción del índice.

    Cada vez que se realiza una DML sobre un índice, este índice va evolucionando ya sea por los splits que se van produciendo como por el crecimiento mismo del índice.
    Mientras el índice es reconstruído, es empaquetado y comprimido, cada bloque con los leaf nodes es reorganizado, sin embargo , con las DMLs que se están produciendo este reordenamiento afectan al empaquetamiento que tiene el índice por la reconstrucción del mismo.

    Todo lo anterior redunda en que hay muchísima más actividad de REDO, el hecho de que se produzcan splits produce que haya más I/O y uso de CPU .


    3.- Un INDEX COALESCE es el comando preferido en vez de la reconstrucción, pues posee las siguientes ventajas

  • No requiere 2 veces el tamaño del índice en Storage
  • Siempre es online
  • No reestructura el índice, pero trata de recombinar de la mejor forma los bloques donde se encuentran los leaf nodes (datos), esto evita por ejemplo el overhead del punto 2

    Todo lo anterior , es para indicar que no es recomendable colocar como política corporativa la reconstrucción de índice y que se debe hacer en casos muy excepcionales


    ¿Qué es un Index Block Split?
    Es un evento que sucede cuando un bloque de datos de índices no puede contener más información, lo que debe hacer es migrar toda esa info a bloques nuevos, y dejar en el bloque original los punteros de esos bloques, eso implica que se produce un nuevo nivel dentro del índice.

  • by Ligarius
    23.06.12. 22:42:59. 648 words, 16770 views. Categories: Base de datos, Oracle 11g, Oracle 10g, Oracle11gR2 ,

    Comando DROP DATABASE



    Hoy tenía que llevar a cabo el borrado de una base de datos , que se encuentra en ASM , pensé en tablespaces por tablespaces, pero como era muchos, lo encontré algo tedioso , tampoco podía borrar los Raw Devices, pues no quería recrearlos nuevamente (en realidad no lo hago yo, lo hace gente de Unix) entonces allí me acordé del comando DROP DATABASE



    Su funcionamiento es muy sencillo y sólo hay que llevar a cabo los siguientes pasos
    export ORACLE_SID=nliq2
    
    sqlplus /nolog
    
    SQL> conn / as sysdba
    Connected.
    
    SQL> shutdown abort
    ORACLE instance shut down.
    
    SQL> startup mount exclusive restrict;
    ORACLE instance started.
    
    Total System Global Area 2147483648 bytes
    Fixed Size                  2085424 bytes
    Variable Size             402656720 bytes
    Database Buffers         1728053248 bytes
    Redo Buffers               14688256 bytes
    Database mounted.



    Obs : Deben verificar que sea la instancia correcta la que van a eliminar :)

    select * from v$instance;



    Verificamos los datos dentro de ASM para visualizar el antes y después

    [/home/ora10rac] asmcmd
    ASMCMD> lsdg
    State       Type    Rebal  Unbal  Sector  Block       AU  Total_MB  Free_MB  Req_mir_free_MB  Usable_file_MB  Offline_disks  Name
    DISMOUNTED          N      N         512   4096  1048576         0        0                0               0              0  DATA/
    MOUNTED     EXTERN  N      N         512   4096  1048576    552960    74173                0           74173              0  DGDATA/
    MOUNTED     EXTERN  N      N         512   4096  1048576    184320    91422                0           91422              0  DGFRA/
    DISMOUNTED          N      N         512   4096  1048576         0        0                0               0              0  FRA/
    ASMCMD> cd DGDATA
    
    ASMCMD> ls
    NLIQ/
    NLIQ2/
    
    ASMCMD> cd NLIQ2
    
    ASMCMD> ls
    CONTROLFILE/
    DATAFILE/
    ONLINELOG/
    PARAMETERFILE/
    TEMPFILE/
    spfilenliq2.ora
    
    ASMCMD> cd DATAFILE
    ASMCMD> ls -ltr
    
    Type      Redund  Striped  Time             Sys  Name
    DATAFILE  UNPROT  COARSE   OCT 25 03:00:00  Y    NUEVA_LIQ_INDEX.315.765431891
    DATAFILE  UNPROT  COARSE   OCT 25 04:00:00  Y    ADMININD.325.765432841
    DATAFILE  UNPROT  COARSE   OCT 25 04:00:00  Y    BASE_R.326.765432845
    DATAFILE  UNPROT  COARSE   OCT 25 04:00:00  Y    CDA_DATA.327.765432847
    DATAFILE  UNPROT  COARSE   OCT 25 04:00:00  Y    CDA_INDEX.328.765432865
    DATAFILE  UNPROT  COARSE   OCT 25 04:00:00  Y    MANT_PROTX_TAB.329.765432883
    DATAFILE  UNPROT  COARSE   OCT 25 04:00:00  Y    NUEVA_LIQ_DATA.320.765432319
    DATAFILE  UNPROT  COARSE   OCT 25 04:00:00  Y    NUEVA_LIQ_DATA.321.765432389
    DATAFILE  UNPROT  COARSE   OCT 25 04:00:00  Y    NUEVA_LIQ_INDEX.316.765431993
    DATAFILE  UNPROT  COARSE   OCT 25 04:00:00  Y    NUEVA_LIQ_INDEX.317.765432063
    DATAFILE  UNPROT  COARSE   OCT 25 04:00:00  Y    NUEVA_LIQ_INDEX.318.765432133
    DATAFILE  UNPROT  COARSE   OCT 25 04:00:00  Y    NUEVA_LIQ_INDEX.319.765432201
    DATAFILE  UNPROT  COARSE   OCT 25 04:00:00  Y    PERFILADOR_DATA.323.765432815
    DATAFILE  UNPROT  COARSE   OCT 25 04:00:00  Y    PERFILADOR_INDEX.324.765432819
    DATAFILE  UNPROT  COARSE   OCT 25 04:00:00  Y    PRUEBA.322.765432733
    DATAFILE  UNPROT  COARSE   OCT 25 04:00:00  Y    TBKSDV_DATA.330.765432941
    DATAFILE  UNPROT  COARSE   OCT 25 04:00:00  Y    TBKSDV_IND.331.765432951
    DATAFILE  UNPROT  COARSE   OCT 25 05:00:00  Y    UNDOTBS1.307.765430439
    DATAFILE  UNPROT  COARSE   OCT 25 05:00:00  Y    USERS.308.765430439
    DATAFILE  UNPROT  COARSE   OCT 25 22:00:00  Y    SYSTEM.305.765430439
    DATAFILE  UNPROT  COARSE   OCT 26 00:00:00  Y    SYSAUX.306.765430439
    ASMCMD>



    Ejecutamos el comando drop database

    SQL> drop database;
    
    Database dropped.
    
    Disconnected from Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
    With the Partitioning, OLAP, Data Mining and Real Application Testing options
    SQL>



    Y cuando verificamos el espacio disponible en mi storage de ASM, vemos se ha liberado , de una forma muy rápida

    ASMCMD>
    ASMCMD> lsdg
    State       Type    Rebal  Unbal  Sector  Block       AU  Total_MB  Free_MB  Req_mir_free_MB  Usable_file_MB  Offline_disks  Name
    DISMOUNTED          N      N         512   4096  1048576         0        0                0               0              0  DATA/
    MOUNTED     EXTERN  N      N         512   4096  1048576    552960   247858                0          247858              0  DGDATA/
    MOUNTED     EXTERN  N      N         512   4096  1048576    184320   169430                0          169430              0  DGFRA/
    DISMOUNTED          N      N         512   4096  1048576         0        0                0               0              0  FRA/
    ASMCMD>



    La instancia es bajada

    [/oracle10/product/10.2.0/db10g/dbs] ps -fea | grep pmon
    ora10rac 10027222 1 0 Oct 25 - 0:08 asm_pmon_+ASM
    ora10rac 21692626 7798942 0 22:39:42 pts/9 0:00 grep pmon
    [/oracle10/product/10.2.0/db10g/dbs]



    El archivo de inicialización es eliminado

    [/oracle10/product/10.2.0/db10g/dbs] ls -ltr
    total 26176
    -rw-r----- 1 ora10rac oinstall 8385 Sep 11 1998 init.ora
    -rw-r--r-- 1 ora10rac oinstall 12920 May 03 2001 initdw.ora
    -rw-r----- 1 ora10rac oinstall 1536 Oct 25 01:54 orapw+ASM
    -rw-rw---- 1 ora10rac oinstall 24 Oct 25 01:54 lk+ASM
    -rw-r----- 1 ora10rac oinstall 1536 Oct 25 01:55 spfile+ASM.ora
    -rw-rw---- 1 ora10rac oinstall 24 Oct 25 02:03 lkNLIQ
    -rw-rw---- 1 ora10rac oinstall 24 Oct 25 03:33 lkNLIQ2
    -rw-r----- 1 ora10rac oinstall 39 Oct 25 03:35 initnliq2.ora
    -rw-r----- 1 ora10rac oinstall 1536 Oct 25 04:54 orapwnliq2
    -rw-rw---- 1 ora10rac oinstall 1544 Oct 26 22:28 hc_+ASM.dat
    -rw-rw---- 1 ora10rac oinstall 563 Oct 26 22:34 ab_+ASM.dat
    -rw-rw---- 1 ora10rac oinstall 1544 Oct 26 22:39 hc_nliq2.dat



    Y el controlfile, permanece, aunque en la documentación diga que se elimina

    ASMCMD> cd DGDATA
    ASMCMD> ls
    NLIQ2/
    ASMCMD> cd NLIQ2
    ASMCMD> ls
    CONTROLFILE/
    ASMCMD> cd CONTROLFILE
    ASMCMD> ls
    Current.309.765430489
    ASMCMD>



    Hay que tener en cuenta lo siguiente

  • Un comando drop database es irreversible
  • El comando drop database no elimina los RAW devices para bases en ASM
  • Los archivelogs y backupset tampoco son eliminados

    La documentación de DROP DATABASE para versión 10gr2

  • by Ligarius
    28.10.11. 07:11:03. 683 words, 9975 views. Categories: Base de datos, Oracle 10g, ASM (Automatic Storage Management) ,

    Oracle Clusterware : Cambiando el voting disk en Oracle10gr2 (Changing Voting Disk)


    Después de un tiempo de inactividad, volvemos a las pistas ... ;) , cambiando el Voting Disk de un RAC



    Ahora con algo simpático, que fue el cambio de un Voting Disk que presentaba problemas en un cliente , el cual poseía un RAC de 4 nodos en 10gr2, el problema era que uno de los nodos sufría problemas de Eviction , o sea, el GSSD lo botaba del Cluster.

    Se analizaron varias aristas y se decidio el cambio del Voting Disk a nivel del cluster en general, la verdad el problema desaparecio , he acá el paso a paso de la solución.


    Las máquinas involucradas..

    nodo1 168.10.10.1
    nodo2 168.10.10.2
    nodo3 168.10.10.3
    nodo4 168.10.10.4

    1.- Comenzamos con el respaldo físico del voting disk

    Desde nodo1 (168.10.10.1)

    Lo consultamos, para saber donde está

    nodo1> crsctl query css votedisk
    0. 0 /dev/rhdisk3

    located 1 votedisk(s).
    nodo1>



    Y se respalda fisicamente (esto no esta soportado en 11gr2)

    nodo1> dd if=/dev/rhdisk3 of=voting_resp_10-09-2010.dbf

    nodo1> ls -ltr
    total 2050816
    -rw-r--r-- 1 oracle oinstall 524943360 Sep 10 01:05 voting_resp_10-09-2010.dbf
    nodo1>

    nodo1> pwd
    /home/oracle
    nodo1>



    2.- Se añade el vote disk con root, pero indica error dado que se encuentra el clusterware arriba, hay documentación que dice que se puede hacer con el comando force, pero esto no se recomienda, dado que se podrían presentar problemas de corrupción.

    bash-2.05b# /u1/app/oracle/product/10.2.0/bin/crsctl add css votedisk /dev/rhdisk48
    Cluster is not in a ready state for online disk addition



    3.- Se bajan las instancias Oracle con usuario oracle

    crs_stop -all



    4.- Se verifica el estado del crs en cada nodo (se debe ejecutar el comando en cada máquina)

    [nodo1]# /u1/app/oracle/product/10.2.0/bin/crsctl check crs
    CSS appears healthy
    CRS appears healthy
    EVM appears healthy


    Como se visualiza UP, hay que bajarlo.


    5.- Se baja el clusterware en todos los nodos (este comando se debe ejecutar en todos los nodos)

    [nodo1]# /u1/app/oracle/product/10.2.0/bin/crsctl stop crs
    Stopping resources.
    Successfully stopped CRS resources
    Stopping CSSD.
    Shutting down CSS daemon.
    Shutdown request successfully issued.



    6.- Se añade el voting disk con la opción force , dado que se encuentra el CRS abajo. Esta tarea puede ser realizada desde cualquier nodo

    [nodo2]# /u1/app/oracle/product/10.2.0/bin/crsctl add css votedisk /dev/rhdisk48 -force
    Now formatting voting disk: /dev/rhdisk48
    successful addition of votedisk /dev/rhdisk48.
    [nodo2]#



    7.- Verificamos los voting disk existentes, debiesen aparecer el nuevo y el antiguo

    [nodo2]# /u1/app/oracle/product/10.2.0/bin/crsctl query css votedisk
    0. 0 /dev/rhdisk3
    1. 0 /dev/rhdisk48 --> Nuevo

    located 2 votedisk(s).



    8.- Borramos el voting disk anterior con la opción force

    [nodo2]# /u1/app/oracle/product/10.2.0/bin/crsctl delete css votedisk /dev/rhdisk3 -force
    successful deletion of votedisk /dev/rhdisk3.



    9.- Consultamos nuevamente el votedisk

    [nodo2]# /u1/app/oracle/product/10.2.0/bin/crsctl query css votedisk
    0. 0 /dev/rhdisk48

    located 1 votedisk(s).



    10.- Levantamos clusterware en todos los nodos (se debe ejecutar el mismo comando en todos los nodos)

    [nodo2]# /u1/app/oracle/product/10.2.0/bin/crsctl start crs
    Attempting to start CRS stack
    The CRS stack will be started shortly



    11.- Verificamos el clusterware

    /u1/app/oracle/product/10.2.0/bin/crsctl check crs
    CSS appears healthy
    CRS appears healthy
    EVM appears healthy



    12.- Y procedemos a levantar todos los componentes y servicios de nuestro clusterware

    /u1/app/oracle/product/10.2.0/bin/crs_start -all



    Referencias
    OCR / Vote disk Maintenance Operations: (ADD/REMOVE/REPLACE/MOVE) [ID 428681.1]

    by Ligarius
    13.10.10. 11:54:58. 574 words, 6903 views. Categories: Base de datos, Oracle 10g, Real Application Cluster ,

    Instalación de RAC en 10gr2 paso a paso (con máquinas virtuales)



    Hola ... después de bastante tiempo sin postear, les hago llegar algo útil , no tremendamente innovador, pero algo que les servirá



    Es un paso a paso para instalar RAC 10gr2 en Linux con máquinas virtuales , este paper contiene desde la creación de las máquinas, el Storage , la configuración de las redes, hasta la instalación propia del motor, para pedagogía es bastante bueno...

    Rac 10gr2 eb Linux 3.0

    Eso un saludo y ya estaremos posteando sobre instalación de RAC 11gr2 , sobre añadir un nodo al RAC y algo que me ha llamado bastante la atención , Oracle Golden Gate :>>

    Espero les sirva

    by Ligarius
    31.07.10. 18:50:56. 108 words, 6457 views. Categories: Oracle 10g, Real Application Cluster ,

    Utilizando las métricas de Oracle para generar gráficos



    Siempre existe la necesidad de mostrar información de manera gráfica, bien lo dice el dicho "Un dibujo vale más que mil palabras" , por ende , mostrar nu gráfico de comportamiento de algún componente de nuestra base de datos, se agradece mucho más que mostrar información de forma plana.

    Para ello nos centraremos en la actividad de las vistas relacionadas a las métricas, disponibles desde Oracle10gr1 en adelante



    La vista V$SYSMETRIC muestra la métrica de sistema capturada en un intervalo de 15 y 60 segundos , algunos datos importantes en esta vista

    V$SYSMETRIC.BEGIN_TIME : Fecha de inicio del intervalo
    V$SYSMETRIC.END_TIME : Fecha de término del intervalo
    V$SYSMETRIC.INTSIZE_CSEC : Centésimas de segundo en el intervalo
    V$SYSMETRIC.METRIC_NAME : Nombre de la métrica
    V$SYSMETRIC.VALUE : Valor de la métrica
    V$SYSMETRIC.METRIC_UNIT : Descripción de la unidad de medida, en otras palabras , como se calcula el valor de la métrica

    La gracia principal de esto es que podemos capturar información de mucha utilidad y generar gráficos "para el jefe" , ¿cómo así? , pues bien ... analicemos un dato que es extremadamente importante y aparece en todos lugares , el Buffer Cache Hit Ratio

    Con esta consulta sobre la V$SYSMETRIC podemos consultar el hit ratio del database buffer cache

    SQL> r
    1 select to_char(BEGIN_TIME,'dd-mm-yyyy hh24:mi:ss') "Fecha Inicio" ,
    2 to_char(END_TIME,'dd-mm-yyyy hh24:mi:ss') "Fecha Termino" ,
    3 INTSIZE_CSEC ,
    4 GROUP_ID ,
    5 METRIC_ID ,
    6 METRIC_NAME ,
    7 VALUE ,
    8 METRIC_UNIT
    9 from v$sysmetric
    10* where metric_name like '%Buffer Cache Hit Ratio%'


    Y podríamos recopilar información como la que sigue

    Fecha Inicio Fecha Termino INTSIZE_CSEC GROUP_ID METRIC_ID METRIC_NAME VALUE METRIC_UNIT
    ------------------- ------------------- ------------ ---------- ---------- ------------------------- ------- ----------------------------------------
    11-11-2009 20:11:15 11-11-2009 20:12:15 6000 2 2000 Buffer Cache Hit Ratio 100.00 % (LogRead - PhyRead)/LogRead
    11-11-2009 20:12:45 11-11-2009 20:13:00 1500 3 2000 Buffer Cache Hit Ratio 100.00 % (LogRead - PhyRead)/LogRead


    El problema principal (si se le puede llamar problema) es que sólo muestra 2 puntos y con eso, claramente no sabremos la tendencia de nuestra base de datos , por ende necesitamos más puntos, ¿de dónde obtenerlos?, pues del historial de esa vista , la V$SYSMETRIC_HISTORY

    1 select to_char(BEGIN_TIME,'dd-mm-yyyy hh24:mi:ss') "Fecha Inicio" ,
    2 to_char(END_TIME,'dd-mm-yyyy hh24:mi:ss') "Fecha Termino" ,
    3 INTSIZE_CSEC ,
    4 GROUP_ID ,
    5 METRIC_ID ,
    6 METRIC_NAME ,
    7 VALUE ,
    8 METRIC_UNIT
    9 from v$sysmetric_history
    10 where metric_name like '%Buffer Cache Hit Ratio%'
    11* order by 1


    Acá nos muestra la última hora de las métricas que necesitamos visualizar , lo cual ya se puede sentir como algo más elaborado , o sea, "les presentamos el comportamiento del Database Buffer Cache durante la última hora" , suena bien , está vista nos entrega información de la última hora con un total de registros de 74

    Y si queremos tener una curva algo más prolongada, quizás, el último mes del Database Buffer Cache, pues allí debemos consultar la vista DBA_HIST_SYSMETRIC_HISTORY

    La información viaja así ...... después de una hora en memoria en las vistas V$SYSMETRIC y V$SYSMETRIC_HISTORY , el proceso Background MMON descarga la información de estás vistas al diccionario de datos , esa información la encontramos en la vista DBA_HIST_SYSMETRIC_HISTORY

    Si piensan un poco , lo anterior es lo que sucede cuando el MMON captura la información estadística desde la SGA , o sea, son los Snapshots del AWR , entre más Snapshots existan , la curva puede ser más amplia cuando analicemos información estadística, que interesante!!!

    La forma en que pueden realizar los gráficos mediante la información proveniente de estas tablas, la pueden encontrar muy detallada, paso a paso en el siguiente artículo

    B)B)B)Graficar en Excel información proveniente desde StatspackB)B)B)

    Hay que extrapolar un poco , la información en este caso no viene del Statspack , proviene de las vistas de Oracle, pero para el caso, es aplicable 500%

    ¿Qué otra información es útil como métrica?

    La verdad muchas otras, como por ejemplo

    * CPU Usage Per Sec
    * Disk Sort Per Sec
    * Host CPU Utilization (%)
    * Leaf Node Splits Per Sec
    * Library Cache Hit Ratio
    * Memory Sorts Ratio
    * PGA Cache Hit %
    * Physical Reads Per Sec
    * Redo Generated Per Sec
    * Soft Parse Ratio
    * Etc,etc.

    La información está , es llegar y graficar :yes:

    Mayor descripción de la vista V$SYSMETRIC

    De la vista V$SYSMETRIC_HISTORY

    Y de la vista DBA_HIST_SYSMETRIC_HISTORY

    Espero que les sirva


    by Ligarius
    20.01.10. 16:40:17. 770 words, 11037 views. Categories: Oracle 11g, Oracle 10g, Tuning / Performance, Oracle11gR2 ,

    1 2 3 4 >>