Category: Oracle 10g

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, 773 views. Categories: Base de datos, Oracle 10g, ASM (Automatic Storage Management) , Leave a comment » • Send a trackback »

    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, 2601 views. Categories: Base de datos, Oracle 10g, Real Application Cluster , 2 comments » • Send a trackback »

    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, 1463 views. Categories: Oracle 10g, Real Application Cluster , 2 comments » • Send a trackback »

    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, 5103 views. Categories: Oracle 11g, Oracle 10g, Tuning / Performance, Oracle11gR2 , Leave a comment » • Send a trackback »

    Oracle10gr2 : Disminuyendo el LOG FILE SYNC con COMMIT NOWAIT


    Para comenzar la charla , les pido disculpas por el tiempo alejado de las canchas, pero fue única y exclusivamente por la carga de trabajo que tenía en mi empresa, de hecho hoy en día me encuentro dictando dos cursos por día :

    - Horario de tarde : WorkShop II Ed 3 de Oracle10g
    - Horario de noche : Oracle Reports Builder 11g

    Así que imagínense el tiempo que tengo, pero bueno... a lo que vinimos...



    El evento de espera LOG FILE SYNC se da cuando una sesión de usuario ejecuta un final de transacción por ejemplo un COMMIT o un ROLLBACK , la información almacenada en el Log Buffer para esa transacción necesita ser envíada a disco , especificamente a los archivos de redolog, cuando está finaliza , la sesión recién comienza a generar otras actividades, en otras palabras, cuando se ejecuta un término de transacción la sesión entra en un evento de espera, que está relacionado al tiempo que demora el LGWR en escribir las entradas del log buffer (en realidad son vectores, pero es materia de otro Post) hacía los redologs, cuando eso finaliza .. la transacción se acepta como válida.


    A veces , cuando la aplicación es muy transaccional , el LOG FILE SYNC , aparece como un Top 5 dentro del Statspack o dentro un AWR Rpt, cuando sucede eso, hay formas de mejorar esos tiempos de respuesta.



    Observación : No se recomienda llevar a cabo estos cambios sin la visación de Oracle Support




    Ejecución de commit asincrónico

    Como ya vimos el proceso del commit y como se vaciaban los registros desde el Log Buffer , pasamos a señalar el como ejecutar el commit asincrónico para solucionar el evento de espera LOG FILE SYNC


    El comando commit posee variaciones , las cuales se pueden apreciar en el siguiente detalle
    WAIT : No se retorna el mensaje de commit exitoso hasta que las entradas del LogBuffer hayan sido escritas a los redo logs

    NOWAIT : El commit puede retornar el control a la aplicación aunque aún la sentencia no este registrada a los archivos de redologs, lo cual puede resultar algo peligroso.

    IMMEDIATE : El proceso LGWR escribe de forma inmediata la entrada de la transacción presente en los log buffer hacía los redo logs, en otras palabras , se fuerza un I/O

    BATCH : Este modo le indica a Oracle que a pesar de haber finalizado la transacción con un commit, la bajada de los vectores desde el log buffer se produzca en el ciclo normal del log buffer , por ejemplo , cuando se llena a un tercio

    Por defecto , cuando ustedes ejecutan el commit se ejecuta con WAIT IMMEDIATE , pero esto se puede modificar ejecutando la siguiente sentencia

    COMMIT WRITE NOWAIT IMMEDIATE , o sea, no espera a que se escriba la información del log buffer a los redo logs, entrega el control a la aplicación y hace la bajada de la información del log buffer de forma inmediata a los redo logs

    Es una opción que hay que manejar con cuidado , pues puede haber pérdida de datos , por ejemplo este comando

    COMMIT WRITE NOWAIT BATCH , puede dejar mucha información en memoria , indicarles que se hizo el commit exitoso y ante una caída quedar con información inconsistente.

    Todo lo anterior también se puede setear mediante el parámetro de incialización correspondiente

    COMMIT_WRITE

    Y analizando toda esta información , para solucionar en parte el evento de espera LOG FILE SYNC , se podría cambiar el modo del commit para los procesos batch de la siguiente forma

    COMMIT WRITE NOWAIT BATCH

    Espero que les haya servido

    Documentación necesaria
    Parámetro COMMIT_WRITE
    Evento de espera LOG FILE SYNC


    by Ligarius
    02.12.09. 13:23:18. 632 words, 2726 views. Categories: Oracle 11g, Oracle 10g, SQL / Programación, Tuning / Performance , 1 comment » • Send a trackback »

    1 2 3 4 >>