[oracle@servidor01 bin]$ ./crsctl status resource -t
--------------------------------------------------------------------------------
NAME           TARGET  STATE        SERVER                   STATE_DETAILS
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.LISTENER.lsnr
               ONLINE  ONLINE       servidor01
               ONLINE  ONLINE       servidor02
ora.OCRVOTING.dg
               ONLINE  ONLINE       servidor01
               ONLINE  ONLINE       servidor02
ora.asm
               ONLINE  ONLINE       servidor01               Started
               ONLINE  ONLINE       servidor02               Started
ora.gsd
               OFFLINE OFFLINE      servidor01
               OFFLINE OFFLINE      servidor02
ora.net1.network
               ONLINE  ONLINE       servidor01
               ONLINE  ONLINE       servidor02
ora.ons
               ONLINE  ONLINE       servidor01
               ONLINE  ONLINE       servidor02
ora.registry.acfs
               ONLINE  ONLINE       servidor01
               ONLINE  ONLINE       servidor02
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.LISTENER_SCAN1.lsnr
      1        ONLINE  ONLINE       servidor01
ora.cvu
      1        ONLINE  ONLINE       servidor01
ora.oc4j
      1        ONLINE  ONLINE       servidor01
ora.servidor01.vip
      1        ONLINE  ONLINE       servidor01
ora.servidor02.vip
      1        ONLINE  ONLINE       servidor02
ora.scan1.vip
      1        ONLINE  ONLINE       servidor01
[oracle@servidor01 bin]$

O lo podemos visualizar con nuestro comando de tantas batallas, el crs_stat -t

[oracle@servidor01 bin]$ ./crs_stat -t
Name           Type           Target    State     Host
------------------------------------------------------------
ora....ER.lsnr ora....er.type ONLINE    ONLINE    servidor01
ora....N1.lsnr ora....er.type ONLINE    ONLINE    servidor01
ora....TING.dg ora....up.type ONLINE    ONLINE    servidor01
ora.asm        ora.asm.type   ONLINE    ONLINE    servidor01
ora.cvu        ora.cvu.type   ONLINE    ONLINE    servidor01
ora.gsd        ora.gsd.type   OFFLINE   OFFLINE
ora....network ora....rk.type ONLINE    ONLINE    servidor01
ora.oc4j       ora.oc4j.type  ONLINE    ONLINE    servidor01
ora.ons        ora.ons.type   ONLINE    ONLINE    servidor01
ora....SM1.asm application    ONLINE    ONLINE    servidor01
ora....01.lsnr application    ONLINE    ONLINE    servidor01
ora....a01.gsd application    OFFLINE   OFFLINE
ora....a01.ons application    ONLINE    ONLINE    servidor01
ora....a01.vip ora....t1.type ONLINE    ONLINE    servidor01
ora....SM2.asm application    ONLINE    ONLINE    servidor02
ora....02.lsnr application    ONLINE    ONLINE    servidor02
ora....a02.gsd application    OFFLINE   OFFLINE
ora....a02.ons application    ONLINE    ONLINE    servidor02
ora....a02.vip ora....t1.type ONLINE    ONLINE    servidor02
ora....ry.acfs ora....fs.type ONLINE    ONLINE    servidor01
ora.scan1.vip  ora....ip.type ONLINE    ONLINE    servidor01

Si nos fijamos , para ambos casos el servicio ora.gsd aparece OFFLINE

¿Qué significa eso? ¿Es algún problema?

La verdad no, no es un problema tal como lo indica la nota Oracle
GSD Is Used Only if 9i RAC Database is Present [ID 429966.1]

En el fondo, este servicio se usa única y exclusivamente si hay presente una versión 9i de Oracle, puesto que con este servicio se atienden las peticiones de los requisitos de los clientes que usan esa versión de la base.

Por defecto en Oracle11gr2 este servicio viene deshabilitad0, aparece como target OFFLINE y como status OFFLINE, no entorpeciendo las actividades del Grid Infraestructure

Entonces... dont worry be happy

ASM created and started successfully.

Disk Group OCRVOTING created successfully.

clscfg: -install mode specified
Successfully accumulated necessary OCR keys.
Creating OCR keys for user 'root', privgrp 'root'..
Operation successful.
CRS-4256: Updating the profile
Successful addition of voting disk 692dc1b5935f4f72bf8884b4f7891e11.
Successfully replaced voting disk group with +OCRVOTING.
CRS-4256: Updating the profile
CRS-4266: Voting file(s) successfully replaced
## STATE File Universal Id File Name Disk group
-- ----- ----------------- --------- ---------
1. ONLINE 692dc1b5935f4f72bf8884b4f7891e11 (ORCL:VOL01) [OCRVOTING]
Located 1 voting disk(s).
CRS-2672: Attempting to start 'ora.asm' on 'prdwcora01'
CRS-2676: Start of 'ora.asm' on 'prdwcora01' succeeded
CRS-2672: Attempting to start 'ora.OCRVOTING.dg' on 'prdwcora01'
CRS-2676: Start of 'ora.OCRVOTING.dg' on 'prdwcora01' succeeded
CRS-2672: Attempting to start 'ora.registry.acfs' on 'prdwcora01'
CRS-2676: Start of 'ora.registry.acfs' on 'prdwcora01' succeeded
Preparing packages for installation...
cvuqdisk-1.0.9-1
Configure Oracle Grid Infrastructure for a Cluster ... succeeded

Es gratificante jejejeje

#!/bin/ksh

# Quien
# Hector Ulloa Ligarius

# Cuando
# 03 de Enero del 2012

# Que
# Eliminar archive ya aplicados en la Standby

# Cron
# 00 * * * * /home/oracle/hp/scripts/BorrarArchivelog.sh > /home/oracle/hp/scripts/BorrarArchivelog.log 2>&1

ORACLE_HOME=/home/oracle/app/product/9.2.0
PATH=$PATH:$ORACLE_HOME/bin
ORACLE_SID=XX
export ORACLE_HOME
export ORACLE_SID

rman target / << EOF
delete archivelog until time "sysdate -1/24";
YES
exit
EOF

Espero les sirva

alter database add standby logfile '+DiskGroup o ruta física' size XXM;

Un dato que puede servirnos, el proceso RFS que se ejecuta en nuestro ambiente Standby y que podemos ver algo así

Tue Nov 1 13:50:51 2011
RFS[1]: Successfully opened standby log 4: '+DGDATA/nliqstb/onlinelog/group_4.293.766066871'

Este proceso RFS es el encargado en la base de datos StandBy de recibir los datos desde la primaria y escribirlos a disco generando los archivelogs o la información de los standby de redo .El encargado de aplicar las transacciones que se encuentran en esos StandBy de Redo o en los archives que se encuentran en la StandBy es el proceso llamado MRP (Managed Recovery Process)

Siempre es beneficioso usar SRL , dado que cuando se produce un switch en la primaria, también se produce en la StandBy , lo que implica que también en nuestra base de datos StandBy se generan archives

A modo de resumen de los StandBy Redo Logs (SRL)

Son requeridos cuando :

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

* 2x 6 core Intel Xeon

* 96GB de RAM

* 2x 500Gb SATA de Storage Interno

* 20x 600Gb 3,5" SAS de Storage compartido a 15mil RPM

* 4x 73Gb 3,5" SSD , esto es genial!

* Sistema Operativo Enterprise Linux 5.5 , que raro que no venga con una versión susperior

* Puertos USB internos, usados por una USB Flash de 4Gb, esto sirve por ejemplo para crear una partición de arranque , en caso de emergencias.

Cabe mencionar que de los 20 discos de 600Gb , que hacen un total de 12TB de Storage, solamente tenemos disponibles 4Tb , dado que se ocupa mirroring de alta redundancia, o sea, 3 espejamientos

Además ODA viene con 24 cores, de los cuales se debe licenciar como mínimo 2, pero siendo sinceros... para que vamos a tener tremenda máquina y solo vamos a licenciar un minimo de su capacidad

ODA es manejado con un Software llamado Applicance Manager, con este software se puede incluso parchar sin inconvenientes el ODA y es el software con el cual se inicializa un ODA

Este pequeño juguete , viene con la última versión de Oracle incorporada (11gr2) con ASM y por tener 2 servers integrados, se puede realizar una instalación de Oracle RAC One-Node (por la versión 11gr2) o se puede realizar la instalación normal de RAC, esto puede ser llevado a cabo en 2 horas, así de sencillo.. Si no lo creen , pues miren a este tipo que lo realizo en su empresa

Instalación de RAC en 2 horas , sobre un ODA

Diferencias con el Oracle Exadata
Aunque es el hermano menor de Exadata, tiene muchas diferencias con este último
- Exadata se puede ampliar sin problemas, incluso dentro del mismo rack, pero ODA no , por ende si tenemos una base de datos muy grande, hay que dividirla entre varios ODAs
- ODA no posee la gestion de IO que posee el Exadata, no posee Smart Scan y tampoco posee servidores dedicados al Storage, como el caso del Exadata que posee Oracle Exadata Storage Server
- No dispone de la compresion llamada HCC (Hybrid Columnar Compression)
- Exadata posee discos flash , los cuales se pueden ocupar como cache L2 o como discos de Storage, pero en el ODA , sólo sirven para discos de Storage

Algunos links interesantes

Visita 3D de ODA

Manuales de Oracle

Pequeña presentación de ODA

col path format a40
set linesize 180
col path format a30
col name format a20

select group_number ,
disk_number ,
header_status ,
state ,
total_mb ,
free_mb ,
name ,
path
from v$asm_disk
order by 1 desc ,2

Si se ejecuta dentro de la instancia ASM , muestra todos los discos que han sido descubiertos mediante el parámetro ASM_DISKSTRING, parámetro existente en el archivo de inicialización de la instancia ASM

GROUP_NUMBER DISK_NUMBER HEADER_STATU STATE      TOTAL_MB    FREE_MB NAME                           PATH
------------ ----------- ------------ -------- ---------- ---------- ------------------------------ ----------------------------------------
           1           5 MEMBER       NORMAL        30720      10309 DATA_0005                      /dev/asm_disk6
           1           6 MEMBER       NORMAL        30720      10304 DATA_0006                      /dev/asm_disk7
           1           7 MEMBER       NORMAL        30720      10309 DATA_0007                      /dev/asm_disk11
           1           8 MEMBER       NORMAL        30720      10308 DATA_0008                      /dev/asm_disk12
           1           9 MEMBER       NORMAL        30720      10310 DATA_0009                      /dev/asm_disk13
           0          31 CANDIDATE    NORMAL         1024          0                                /dev/asm_disk38
           0          32 CANDIDATE    NORMAL         1024          0                                /dev/asm_disk39
           0          34 CANDIDATE    NORMAL         1024          0                                /dev/asm_disk40
           0          35 CANDIDATE    NORMAL         1024          0                                /dev/asm_disk41
           0          36 CANDIDATE    NORMAL         1024          0                                /dev/asm_disk42

Acá se verán los discos que ya se encuentran asignados a Diskgroups de ASM, pero también se verán los discos que son candidatos para utilizar en la expansión de otros diskgroups o en la creación de alguno nuevo, se puede ver pues en la columna HEADER_STATUS aparece como CANDIDATE

Si ejecutamos la misma consulta dentro de nuestra instancia RDBMS , veremos sólo los discos que forman parte de los diskgroups ya montados por la instancia ASM

GROUP_NUMBER DISK_NUMBER HEADER_STATU STATE      TOTAL_MB    FREE_MB NAME                           PATH
------------ ----------- ------------ -------- ---------- ---------- ------------------------------ ----------------------------------------
           1           5 UNKNOWN       NORMAL        30720      10309 DATA_0005                      /dev/asm_disk6
           1           6 UNKNOWN       NORMAL        30720      10304 DATA_0006                      /dev/asm_disk7
           1           7 UNKNOWN       NORMAL        30720      10309 DATA_0007                      /dev/asm_disk11
           1           8 UNKNOWN       NORMAL        30720      10308 DATA_0008                      /dev/asm_disk12
           1           9 UNKNOWN       NORMAL        30720      10310 DATA_0009                      /dev/asm_disk13

Más información sobre el parámetro ASM_DISKSTRING y más información sobre la vista V$ASM_DISK

[root@hrdbd1 sysconfig]# /etc/init.d/oracleasm deletedisk VOL01
Removing ASM disk "VOL01": [FAILED]

El cual se puede ver en el log del ASM

[root@hrdbd1 sysconfig] vi /var/log/oracleasm

Unable to clear disk “VOL1″
Clearing disk header: oracleasm-write-label: Unable to open device “/dev/oracleasm/disks/VOL1″: Device or resource busy
failed
Unable to clear disk “VOL01″

Y la manera de solucionar es sobreescribir la cabecera de los path de los discos asociados al Device Mapper

[root@hrdbd1 sysconfig]# dd if=/dev/zero of=/dev/sdh count=100 bs=10240
100+0 records in
100+0 records out
1024000 bytes (1.0 MB ) copied, 0.009565 seconds, 107 MB/s

Podemos saber el dispositivo, consultando el mismisimo disco en el ASMLib

[root@hrdbd1 sysconfig]# /etc/init.d/oracleasm querydisk -v -d -p VOL01
Disk "VOL01" is a valid ASM disk on device [253, 28]
/dev/sdh: LABEL="VOL01" TYPE="oracleasm"

Una vez realizado, se puede borrar la etiqueta generada por ASMLib

[root@hrdbd1 sysconfig]# /etc/init.d/oracleasm deletedisk VOL01
Removing ASM disk "VOL01": [ OK ]

Y ahora si se puede generar la etiqueta con ASMLib sobre el dispositivo asociado al multipath

Links relacionados
http://www.oracleyyo.com/index.php/2010/08/18/problemas-al-momento-de-utilizar-asmlib

[/ruta/instaladores_oracle]$ gunzip 10gr2_aix5l64_companion.cpio.gz

gunzip: 10gr2_aix5l64_companion.cpio: File too large

¿Pero que significa ese mensaje? Bueno, simplemente que el usuario es incapaz de generar un archivo tan grande

¿Cómo se soluciona? Debemos verificar los límites que posea el usuario oracle

[/ruta/instaladores_oracle]$ ulimit -a
time(seconds) unlimited
file(blocks) 2097151
data(kbytes) 131072
stack(kbytes) 32768
memory(kbytes) 32768
coredump(blocks) 2097151
nofiles(descriptors) 2000
threads(per process) unlimited
processes(per user) unlimited

Y podemos apreciar que el parámetro file(blocks) está limitado a 2.097.151 bloques de sistema operativo.

Por ende lo debemos modificar , de la siguiente forma

Editamos el archivo /etc/security/limits con root y agregamos o modificamos la siguiente línea

oracle:
fsize = -1

Obs : El valor -1 indica unlimited

Nos volvemos a loguear con el usuario oracle y verificamos sus límites

[/ruta/instaladores_oracle]$ ulimit -a
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) 131072
stack(kbytes) 32768
memory(kbytes) 32768
coredump(blocks) 2097151
nofiles(descriptors) 2000
threads(per process) unlimited
processes(per user) unlimited
[/ruta/instaladores_oracle]$

Y ahora sí podemos realizar una descompresión del archivo

[/ruta/instaladores_oracle]$ gunzip 10gr2_aix5l64_companion.cpio.gz
[/ruta/instaladores_oracle]$
[/ruta/instaladores_oracle]$
[/ruta/instaladores_oracle]$ ls -ltr
total 6580488
-rw-r----- 1 oracle oinstall 1365463552 Apr 04 12:30 10gr2_aix5l64_companion.cpio
-rw-r----- 1 oracle oinstall 804445893 Apr 05 23:29 p8202632_10205_AIX64-5L_2of2.zip
-rw-r----- 1 oracle oinstall 1199278107 Apr 05 23:36 p8202632_10205_AIX64-5L_1of2.zip
[/ruta/instaladores_oracle]$

#!/bin/bash
ORACLE_BASE=/export/home/dba/oracle; export ORACLE_BASE
ORACLE_HOME=$ORACLE_BASE/product/10.2.0; export ORACLE_HOME
ORACLE_SID=LSECORA; export ORACLE_SID
ORACLE_TERM=xterm; export ORACLE_TERM
PATH=/usr/sbin:$PATH; export PATH
PATH=$ORACLE_HOME/bin:$PATH; export PATH
LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib; export LD_LIBRARY_PATH
CLASSPATH=$ORACLE_HOME/JRE:$ORACLE_HOME/jlib:$ORACLE_HOME/rdbms/jlib; export CLASSPATH
NLS_DATE_FORMAT='dd/mm/yyyy hh24:mi'; export NLS_DATE_FORMAT

echo "Inicio proceso de borrado archivelogs"
rman < connect target
run{
catalog start with '/ruta_donde_quedan_los_archivelogs_en_nodo_standby';
delete noprompt archivelog all completed before 'SYSDATE -1/24';
}
quit;

Como se puede apreciar se catalogan los respaldos y se proceden a eliminar aquellos que se han generado hace más de 1 hora

Borrado de archivelogs mediante shell script
find /ruta_donde_quedan_los_archivelogs_en_nodo_standby/* -type f -mtime +1 -exec rm -rf {} \;

En el fondo se borran los archivelogs que sean mayores a 1 día y a esa búsqueda le aplica la ejecución del comando rm -rf , o sea, los elimina

Borrado de archivelogs mediante configuración de RMAN , siempre y cuando usemos FRA
Si se respaldan los archivelogs en la instancia StandBy , situación que es bastante óptima, se puede ejecutar este comando en RMAN

CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;

Incluso si se respaldan en la instancia primaria, se puede ejecutar este comando (también en la primaria)

Con lo cual , cada vez que se respalden los archivelogs y estos hayan sido aplicados, serán eliminados de la faz de la tierra

Actualización :

Para eliminar archives , desde una base de datos Standby 9i , he acá la shell

#!/bin/ksh

# Quien
# Hector Ulloa Ligarius

# Cuando
# 03 de Enero del 2012

# Que
# Eliminar archive ya aplicados en la Standby

# Cron
# 00 * * * * /home/oracle/hp/scripts/BorrarArchivelog.sh > /home/oracle/hp/scripts/BorrarArchivelog.log 2>&1

ORACLE_HOME=/home/oracle/app/product/9.2.0
PATH=$PATH:$ORACLE_HOME/bin
ORACLE_SID=XX
export ORACLE_HOME
export ORACLE_SID

rman target / << EOF
delete archivelog until time "sysdate -1/24";
YES
exit
EOF

Con la instrucción "delete archivelog until time" , borramos los archives que tengan más de una hora de antigüedad, se puede usar el noprompt para que no tengamos que colocar el YES , como respuesta al comando delete archivelog

SQL> show parameter pfile

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
spfile string

Cuando accedo a la instancia ASM mediante el ASMCMD , veo lo siguiente

[oracle@baliinfr03 ~]$ asmcmd

ASMCMD> ls
DISKGRP1/
DISKGRP2/
ASMCMD> cd DISKGRP1
ASMCMD> ls
DB_UNKNOWN/
IASDB/
ASMCMD> cd IASDB
ASMCMD> ls -ltr
Type      Redund  Striped  Time             Sys  Name
                                            Y    CONTROLFILE/
                                            Y    DATAFILE/
                                            Y    ONLINELOG/
                                            Y    PARAMETERFILE/
                                            N    datafilesysaux01.dbf => +DISKGRP1/IASDB/DATAFILE/SYSAUX.260.746407073
                                            N    datafileundotbs01.dbf => +DISKGRP1/IASDB/DATAFILE/UNDOTBS1.263.746409565
                                            N    datafileundotbs02.dbf => +DISKGRP1/IASDB/DATAFILE/UNDOTBS2.262.746409567
                                            N    datafileusers01.dbf => +DISKGRP1/IASDB/DATAFILE/USERS.261.746407073
ASMCMD>

Pues bien , elijo el diskgroup donde va a quedar y ejecuto el siguiente comando

SQL> create spfile='+DISKGRP1' from pfile;

File created.

SQL>

Y cuando voy a visualizar nuevamente el diskgroup aparece una nueva carpeta llamada PARAMETERFILE y dentro de esa carpeta aparece mi archivo de inicialización

ASMCMD> ls
CONTROLFILE/
DATAFILE/
ONLINELOG/
PARAMETERFILE/
datafilesysaux01.dbf
datafileundotbs01.dbf
datafileundotbs02.dbf
datafileusers01.dbf

ASMCMD> cd PARAMETERFILE

ASMCMD> ls -ltr
Type Redund Striped Time Sys Name
PARAMETERFILE UNPROT COARSE MAR 24 21:00:00 Y spfile.275.746659845

ASMCMD> pwd
+DISKGRP1/IASDB/PARAMETERFILE
ASMCMD>

Pues bien , ahora debemos apuntar nuestras instancias a ese archivo de inicialización
Para ello , dentro del archivo de inicialización colocamos el siguiente código

SPFILE='+DISKGRP1/IASDB/PARAMETERFILE/spfile.275.746659845'

Y realizamos una bajada y subida de los servicios, seteando el ORACLE_HOME donde esta instalado el Clusterware

[oracle@baliinfr03 ~]$ crs_stop -all

Y validamos los resultados

[oracle@baliinfr03 ~]$ crs_stat -t

Name           Type           Target    State     Host
------------------------------------------------------------
ora....SM1.asm application    OFFLINE   OFFLINE
ora....03.lsnr application    OFFLINE   OFFLINE
ora....r03.gsd application    OFFLINE   OFFLINE
ora....r03.ons application    OFFLINE   OFFLINE
ora....r03.vip application    OFFLINE   OFFLINE
ora....SM2.asm application    OFFLINE   OFFLINE
ora....04.lsnr application    OFFLINE   OFFLINE
ora....r04.gsd application    OFFLINE   OFFLINE
ora....r04.ons application    OFFLINE   OFFLINE
ora....r04.vip application    OFFLINE   OFFLINE
ora.iasdb.db   application    OFFLINE   OFFLINE
ora....b1.inst application    OFFLINE   OFFLINE
ora....b2.inst application    OFFLINE   OFFLINE

Después subimos los servicios

[oracle@baliinfr03 ~]$ crs_start -all

Y validamos los resultados

[oracle@baliinfr03 ~]$ crs_stat -t

Name           Type           Target    State     Host
------------------------------------------------------------
ora....SM1.asm application    ONLINE    ONLINE    baliinfr03
ora....03.lsnr application    ONLINE    ONLINE    baliinfr03
ora....r03.gsd application    ONLINE    ONLINE    baliinfr03
ora....r03.ons application    ONLINE    ONLINE    baliinfr03
ora....r03.vip application    ONLINE    ONLINE    baliinfr03
ora....SM2.asm application    ONLINE    ONLINE    baliinfr04
ora....04.lsnr application    ONLINE    ONLINE    baliinfr04
ora....r04.gsd application    ONLINE    ONLINE    baliinfr04
ora....r04.ons application    ONLINE    ONLINE    baliinfr04
ora....r04.vip application    ONLINE    ONLINE    baliinfr04
ora.iasdb.db   application    ONLINE    ONLINE    baliinfr03
ora....b1.inst application    ONLINE    ONLINE    baliinfr03
ora....b2.inst application    ONLINE    ONLINE    baliinfr04

Hay que tener en claro que el archivo de inicialización de las instancias debe ser un pfile y dentro de este archivo se debe colocar el puntero al SPFILE que está en el ASM

NO PUEDE SER UN SPFILE apuntando a otro SPFILE, dado que si hacemos esto cualquier cambio que hagamos quedará solo en el nodo donde ejecutamos el comando ALTER SYSTEM

PD : Los comentarios relativos a la música , los respondo con un "Era la única canción que abarcaba todo el video jeje"

Acá va el link del video, si lo quieren ver a pantalla completa
RMAN PIPE

Y acá los links de la documentación Oracle

RMAN PIPE en 9i
RMAN PIPE en 10gr2
RMAN PIPE en 11gr1
RMAN PIPE en 11gr2

Y la apertura..sencillamente espectacular

De otro planeta!!!!

ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=standby LGWR SYNC AFFIRM';

MAXIMA DISPONIBILIDAD (MAXIMUM AVAILABILITY)
Este modo de protección no afecta la base de datos y proporciona un alto nivel de protección de los datos, tal cual en el modo de máxima protección , las transacciones no se comitean hasta que el redo data sea aplicado en los redologs de la base de datos standby , por lo menos en una de ellas (si existe más de una)

Si no se puede escribir el redo data , en por lo menos una StandBy , la base de datos primaria no se cae

La configuración de la máxima disponibilidad pasa por la siguiente configuración

- Proceso que lleva a cabo el archive de los redo : LGWR
- Modo de transmisión a través de la red : SYNC
- Opción de escritura en disco : AFFIRM
- ¿Necesarios los redo de standby? : SI
- Tipo de Standby soportadas : StandBy física y lógica

Ej:

ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=standby LGWR SYNC AFFIRM';

OBS : El seteo de la máxima disponibilidad con la máxima protección es la misma, lo que cambia es como seteamos nuestra base de datos

alter database set standby database to maximize {AVAILABILITY | PERFORMANCE | PROTECTION};

MAXIMA PERFORMANCE (MAXIMUM PERFORMANCE)
Este modo de protección ofrece la mayor seguridad en la base de datos sin perder nada en la performance de la base de datos primaria, acá las transacciones de la base de datos primaria se les generá commit sólo cuando la transacción llega a los redo locales.
Este modo se debiese usar cuando la red hacía la StandBy no es lo suficientemente óptima y se producen delays al momento de traspasar paquetes a través de TCP.

La configuración de la máxima performance pasa por la siguiente configuración

- Proceso que lleva a cabo el archive de los redo : LGWR o ARCH
- Modo de transmisión a través de la red : ASYNC cuando se usa LGWR
- Opción de escritura en disco : NOAFFIRM
- ¿Necesarios los redo de standby? : NO
- Tipo de Standby soportadas : StandBy física y lógica

Cuando LGWR envía los archives en modo ASYNC, LGWR no espera la respuesta de I/O de la red para completar la tarea, simplemente se desliga, pero no es tan así, sino que deja la actividad de envío del archive a un proceso intermedio llamado LGWR network server process (LNS) y es este proceso el que espera por el I/O de la red y para poder almacenar el redo data que trae el LGWR el LNS posee un buffer , el cual se puede setear sólo en Oracle9i y Oracle10gr1. Este dato se modifica en el parámetro ASYNC de los destinos de archive.

Ej:

ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=standby LGWR ASYNC=1024 NOAFFIRM';

El tamaño del buffer que usa el LNS esta dado por el dato puesto en el parámetro ASYNC * 512 bytes , o sea, 524288 bytes , por lo tanto, estaríamos usando un buffer de 512Kb

Como el proceso LNS es más rápido que el proceso LGWR , esto significa que el buffer entre ambos nunca se llenará y por ende el LGWR no se detendría.

Desde Oracle10gr2 ya no se usa este buffer , lo que hace el proceso LNS es leer directamente desde los redologs de la primaria.

El uso de ARCH para enviar archive a través de la red hacía las Standby, no impacta en la performance de la base de datos, el único problema es que hay que disponer de varios grupos de redo , para que LGWR nunca se encuentre con que un redolog está siendo ocupado por un ARCH

Siempre tener en cuenta lo siguiente

SYNC-ASYNC : Indicamos que usamos sincronismo o asincronismo para el envío de los archives a la standby y el proceso que lleva los archives, ya sea el LGWR o el ARCH no espera la respuesta de la red
AFFIRM-NOAFFIRM : Indica que espera o no espera la respuesta de disco en el ambiente standby cuando se aplican los redo data, en el fondo es como un asincrónico/sincrónico de
disco

Interesante cierto?

Ya sabemos entonces, que la idea es utilizar ASYNC y NOAFFIRM cuando estamos en máxima performance.

Cuando no se especifica LGWR ni ARCH , el defecto es ARCH , por ende se utiliza ASYNC y por defecto NOAFFIRM.

También recordar que se puede cambiar desde ASYNC a SYNC cuando trasladamos archives con LGWR, no con ARCH.

Y si quieres saber como está tu base de datos, pues deberías ejecutar la siguiente consulta

select protection_mode, protection_level from v$database

Algunos links de ayuda

Métodos de protección en 10gr2

Métodos de protección en 9i

Managing Redo Transport Services for Data Protection Modes

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]

[oracle bin]$ cd $GOLDEN_HOME
[oracle gg]$

3.- Ejecutar la consola de comandos de Golden Gate

[oracle gg]$ ./ggsci

4.- Bajar todos los procesos extractores y replicadores de Golden Gate

[oracle@kaitek gg]$ ./ggsci

Oracle GoldenGate Command Interpreter for Oracle
Version 10.4.0.46 Build 003
Linux, x64, 64bit (optimized), Oracle 9 on Feb 26 2010 13:35:23

Copyright (C) 1995, 2010, Oracle and/or its affiliates. All rights reserved.

GGSCI (oracle) 2> info all, allprocesses

Program Status Group Lag Time Since Chkpt

MANAGER STOPPED
EXTRACT STOPPED EXTFULL
EXTRACT STOPPED EXTRAER1 00:00:00 861:25:08
EXTRACT ABENDED EXTRAER2 00:00:00 525:11:53

GGSCI (oracle) 3> stop extract extraer2
EXTRACT EXTRAER2 is already stopped.

Obs : Se bajan todos los procesos extractores, cuando son los procesos replicadores se ocupa la sintáxis

stop replicat (nombre)

5.- Bajar el proceso Manager

GGSCI (oracle) 4> stop mgr
Manager is already stopped.

6.- Visualizamos los procesos para verificar que no se ejecutan

GGSCI (oracle) 5> info all

Program Status Group Lag Time Since Chkpt

MANAGER STOPPED
EXTRACT STOPPED EXTRAER1 00:00:00 861:25:28
EXTRACT ABENDED EXTRAER2 00:00:00 525:12:13

7.- Salir del ggsci y eliminar los archivos donde se encuentra instalado

[oracle bin]$ cd $GOLDEN_HOME
[oracle product]$ ls -ltr
total 8
drwxr-xr-x 14 oracle oinstall 4096 Aug 11 16:55 gg

[oracle product]$ rm -rf gg
[oracle product]$

8.- Eliminación del esquema de base de datos que sirve como conector de golden gate (si existiese)

SQL> drop user golden cascade;

User dropped.

SQL> SQL> quit

Obs : Hay veces que este último comando falla y nos arroja el siguiente mensaje de error

SQL> drop user golden cascade;
drop user golden cascade
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 2
ORA-20782: GoldenGate DDL Replication Error: Code :ORA-20782: Cannot DROP
object used in GoldenGate replication while trigger is enabled. Consult
GoldenGate documentation and/or call GoldenGate Technical Support if you wish
to do so., error stack: Error stack is avalaible only on Oracle 10.1 and above
ORA-06512: at line 883

Si así fuese, se debe eliminar un trigger de la siguiente forma

SQL> drop trigger ggs_ddl_trigger_before;

Trigger dropped.

Y después eliminar el esquema de conector

Ahora viene la pregunta ¿publicará Hector un documento sobre Golden Gate y su instalación? y la respuesta e s.... sí claro.

En los próximos días les entregaré un doc de como instalar y configurar Oracle Golden Gate y como instalar y configurar Oracle Golden Gate Veridata

Espero les sirva

more /proc/partitions

120 0 52429440 emcpowera
120 16 52429440 emcpowerb
120 32 52429440 emcpowerc
120 48 52429440 emcpowerd
120 64 52429440 emcpowere
120 80 52429440 emcpowerf
120 96 52429440 emcpowerg
120 112 52429440 emcpowerh
120 128 408960 emcpoweri
120 144 408960 emcpowerj
120 160 408960 emcpowerk
120 176 408960 emcpowerl
120 192 408960 emcpowerm

Y como somos DBA de peso... necesitamos generar etiquetas con ASMLib para nuestro RAC, ejecutamos el siguiente comando

[root@g500603sv401 dev]# /etc/init.d/oracleasm createdisk VOL01 /dev/emcpowera

Pero recibimos el siguiente mensaje

Marking disk "VOL01" as an ASM disk: [FAILED]

Nos preguntamos ... ¿Cómo puede ser si la partición existe?

De hecho, lo vemos como partición y lo vemos como dispositivo válido

[root@g500603sv401 dev]# ls -ltr /dev/emcpowera
brwxrwxr-x 1 root disk 120, 0 Aug 4 16:05 /dev/emcpowera

Para lo anterior , existe una solución de más bajo nivel que es ocupar asmtools, que en el fondo es el comando que ocupa el utilitario oracleasm .

[root@g500603sv401 init.d]# /usr/sbin/asmtool -C -l /dev/oracleasm -n VOL01 /dev/emcpowera -s /dev/emcpowera -a force=yes
asmtool: Device "/dev/emcpowera" is not a partition
asmtool: Continuing anyway

Nos indica claramente que los dispositivos PowerPath no son una partición , pero ese mensaje lo podemos pasar por alto.

De hecho, se genera el volumen VOL1 que creamos con el ASMLib y lo podemos visualizar

[root@g500603sv401 init.d]# ls -ltr /dev/oracleasm/disks/
total 0
brw-r----- 1 root root 120, 0 Aug 4 17:11 VOL01
[root@g500603sv401 init.d]#

Pero hay un gran detalle, queda con privilegios de root, o sea, no nos sirve de mucho, pero para solucionar eso , ejecutamos el siguiente comando

[root@g500603sv401 init.d]# /etc/init.d/oracleasm scandisks
Scanning the system for Oracle ASMLib disks: [ OK ]

Después de haber escaneado los discos.. , ahora si son de oracle y se pueden leer y escribir

[root@g500603sv401 init.d]# ls -ltr /dev/oracleasm/disks/
total 0
brw-rw---- 1 oracle oinstall 120, 0 Aug 4 17:11 VOL01

Espero les sirva

var_sql := 'update '|| var_tabla ||' set campo1 = '||'valor literal';

Oviamente la sentencia anterior nos arrojaría error , pues en la transformación de la sentencia el CBO la asumiría como

Siendo var_tabla = TAB_PAGOS y 'valor literal' = ADF4561;

SQL> r
1 declare
2 var_sql varchar2(1000);
3 var_tabla varchar2(1000) := 'TABLA1';
4 begin
5 var_sql := 'update '||var_tabla||' set campo1 = '||'ADFR5141';
6 dbms_output.put_line(var_sql);
7* end;

update TABLA1 set campo1 = ADFR5141 –> Está sentenciada error si es ejecutada

PL/SQL procedure successfully completed.

SQL>

Por ende hay un error y se debiesen generar las comillas para su visualización

var_sql := 'update '|| var_tabla ||' set campo1 = '||''||'valor literal'||'';

SQL> r
1 declare
2 var_sql varchar2(1000);
3 var_tabla varchar2(1000) := 'TABLA1';
4 begin
5 var_sql := 'update '||var_tabla||' set campo1 = '||''||'ADFR5141'||''';
6 dbms_output.put_line(var_sql);
7* end;

update TABLA1 set campo1 = 'ADFR5141'; –> Funcionaría sin inconvenientes

Por lo que se ve es demasiado engorroso, ahora imaginanse coloca un formato de fecha dentro de ese enredo , con un to_char , ¿se enredaría mas cierto?

Pues bien, esto se soluciona en gran medida en Oracle10g, con una utilidad genial ,simplemente todo queda inscrito dentro de q'[…..]'

Inclusive, todo puede quedar inscrito dentro de cualquiera de estos símbolos

!
[ ]
{ }
( )
< >

O sea, nuestro pequeño update dinámico quedaría

var_sql := 'update '|| var_tabla ||' set campo1 = q'[ 'valor literal' ]';

Acaso no se ve más sencillo , mmmmm , claro que sí !!!!

ORA-01078: failure in processing system parameters
ORA-29701: unable to connect to Cluster Synchronization Service

Para poder resolver ese inconveniente debemos llevar a cabo los siguientes pasos

Seteamos nuestro ambiente para la instancia ASM

export ORACLE_HOME=/u01/app/oracle/product/11.2.0/grid
export ORACLE_BASE=/u01/app/oracle
export ORACLE_SID=+ASM

export PATH=$PATH:/u01/app/oracle/product/11.2.0/grid/bin

Y procedemos a levantar la instancia ASM

[oracle@oracle11g ~]$ sqlplus /nolog

SQL*Plus: Release 11.2.0.1.0 Production on Fri Apr 16 05:37:25 2010

Copyright (c) 1982, 2009, Oracle. All rights reserved.

SQL> conn / as sysdba
Connected to an idle instance.
SQL> startup
ORA-01078: failure in processing system parameters
ORA-29701: unable to connect to Cluster Synchronization Service
SQL>

¿Cómo solucionamos este inconveniente?

Pues he acá la explicación

El demonio del Cluster Synchronization Service (cssd daemon) no queda online después del reboteo y como la instancia ASM , necesita ese demonio, pues por eso ASM no levanta

La forma de chequearlo

[oracle@oracle11g ~]$ crsctl check cssd
CRS-4530: Communications failure contacting Cluster Synchronization Services daemon

[oracle@oracle11g ~]$ crsctl check has
CRS-4638: Oracle High Availability Services is online

[oracle@oracle11g ~]$ ps -fea | grep d.bin
oracle 6208 1 0 Apr15 ? 00:02:37 /u01/app/oracle/product/11.2.0/grid/bin/ohasd.bin reboot

Y efectivamente vemos que el servicio está abajo ... aunque el servicio ohasd este online

¿Cuál es la causa de este inconveniente?

Pues a partir de Oracle11gr2 los demonios cssd y diskmon no son levantados vía el oratab, ahora estos demonios son levantados por el HAS (High Availability Service) y registrados en un OCR local como un recurso más.

Para analizar esto, procedemos a ir al HOME de la instalación del Grid Infraestructure, que en el fondo es el HOME que soporta el ASM

Y analizamos los recursos existentes

[oracle@oracle11g ~]$ cd $ORACLE_HOME
[oracle@oracle11g grid]$ pwd
/u01/app/oracle/product/11.2.0/grid
[oracle@oracle11g grid]$ cd bin
[oracle@oracle11g bin]$ ./crsctl status resource -t

--------------------------------------------------------------------------------
NAME TARGET STATE SERVER STATE_DETAILS
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.DATA.dg
OFFLINE OFFLINE oracle11g
ora.asm
OFFLINE OFFLINE oracle11g
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.cssd
1 ONLINE OFFLINE
ora.diskmon
1 ONLINE OFFLINE

Como vemos , ambos demonios , inscritos como recursos se encuentran OFFLINE

Para ver el origen del problema, analizamos los recursos con su configuración en detalle

Nota : Solamente vamos a mostrar los recursos que tienen problemas (CSSD y DISKMON)

[oracle@oracle11g bin]$ ./crsctl status resource -p

NAME=ora.cssd
TYPE=ora.cssd.type
ACL=owner:oracle:rwx,pgrp:oinstall:rwx,other::r--
ACTIVE_PLACEMENT=0
AGENT_FILENAME=%CRS_HOME%/bin/cssdagent%CRS_EXE_SUFFIX%
AGENT_HB_INTERVAL=0
AGENT_HB_MISCOUNT=10
AUTO_START=never
CARDINALITY=1
CHECK_INTERVAL=30
CLEAN_ARGS=abort
CSSD_PATH=%CRS_HOME%/bin/ocssd%CRS_EXE_SUFFIX%
CSS_USER=oracle
DEGREE=1
DESCRIPTION="Resource type for CSSD"
DETACHED=true
ENABLED=1
FAILOVER_DELAY=0
FAILURE_INTERVAL=3
FAILURE_THRESHOLD=5
LOAD=1
LOGGING_LEVEL=1
OFFLINE_CHECK_INTERVAL=0
OMON_INITRATE=1000
OMON_POLLRATE=500
ORA_VERSION=11.2.0.1.0
PLACEMENT=balanced
PROCD_TIMEOUT=1000
RESTART_ATTEMPTS=5
SCRIPT_TIMEOUT=600
START_DEPENDENCIES=weak(concurrent:ora.diskmon)
START_TIMEOUT=600
STOP_DEPENDENCIES=hard(shutdown:ora.diskmon)
STOP_TIMEOUT=900
UPTIME_THRESHOLD=1m
VMON_INITLIMIT=16
VMON_INITRATE=500
VMON_POLLRATE=500

NAME=ora.diskmon
TYPE=ora.diskmon.type
ACL=owner:oracle:rwx,pgrp:oinstall:rwx,other::r--
ACTIVE_PLACEMENT=0
AGENT_FILENAME=%CRS_HOME%/bin/orarootagent%CRS_EXE_SUFFIX%
AUTO_START=never
CARDINALITY=1
CHECK_INTERVAL=20
CHECK_TIMEOUT=10
DEGREE=1
DESCRIPTION="Resource type for Diskmon"
DETACHED=true
ENABLED=1
FAILOVER_DELAY=0
FAILURE_INTERVAL=3
FAILURE_THRESHOLD=5
LOAD=1
LOGGING_LEVEL=1
OFFLINE_CHECK_INTERVAL=0
ORA_VERSION=11.2.0.1.0
PLACEMENT=balanced
RESTART_ATTEMPTS=10
SCRIPT_TIMEOUT=60
START_DEPENDENCIES=weak(concurrent:ora.cssd)pullup:always(ora.cssd)
START_TIMEOUT=60
STOP_TIMEOUT=60
UPTIME_THRESHOLD=5s
USR_ORA_ENV=ORACLE_USER=oracle
VERSION=11.2.0.1.0

La propiedad AUTO_START esta seteada como NEVER o como 2 , para los demonios CDDS y DISKMON, esto implica que estos recursos no serán levantados nunca en un reincio por el HAS, y si el Cluster Synchronization Service no puede levantar, implica que la instancia ASM no puede partir.

Para solucionar el problema se debe configurar el AUTO_START para esos demonios (diskmon y cssd)

[oracle@oracle11g bin]$ ./crsctl modify resource "ora.cssd" -attr "AUTO_START=1"
[oracle@oracle11g bin]$
[oracle@oracle11g bin]$
[oracle@oracle11g bin]$ ./crsctl modify resource "ora.diskmon" -attr "AUTO_START=1"
[oracle@oracle11g bin]$

Una vez ejecutados esos comandos, procedemos a analizar nuevamente la configuración de los recursos

NAME=ora.cssd
TYPE=ora.cssd.type
AUTO_START=1

NAME=ora.diskmon
TYPE=ora.diskmon.type
AUTO_START=1

Verificamos los recursos y su estado actual

[oracle@oracle11g bin]$ ./crsctl status resource -t
--------------------------------------------------------------------------------
NAME TARGET STATE SERVER STATE_DETAILS
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.DATA.dg
OFFLINE OFFLINE oracle11g
ora.asm
OFFLINE OFFLINE oracle11g
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.cssd
1 ONLINE OFFLINE
ora.diskmon
1 ONLINE OFFLINE
[oracle@oracle11g bin]$

Como podemos apreciar, ahora se encuentran con un TARGET ONLINE, lo que implica que se reiniciarán con un reboteo..

Pero se aprecia que el STATE es OFFLINE, eso implica que no están arriba los recursos, procedemos a levantarlos

[oracle@oracle11g bin]$ ./crs_start -all
Intentando iniciar `ora.cssd` en el miembro `oracle11g`
Intentando parar `ora.diskmon` en el miembro `oracle11g`
La parada de `ora.diskmon` en el miembro `oracle11g` se ha realizado correctamente.
Intentando iniciar `ora.diskmon` en el miembro `oracle11g`
El inicio de `ora.diskmon` en el miembro `oracle11g` se ha realizado correctamente.
El inicio de `ora.cssd` en el miembro `oracle11g` se ha realizado correctamente.
Intentando iniciar `ora.asm` en el miembro `oracle11g`
El inicio de `ora.asm` en el miembro `oracle11g` se ha realizado correctamente.
Intentando iniciar `ora.DATA.dg` en el miembro `oracle11g`
El inicio de `ora.DATA.dg` en el miembro `oracle11g` se ha realizado correctamente.

Y los volvemos a verificar

[oracle@oracle11g bin]$ ./crsctl status resource -t
--------------------------------------------------------------------------------
NAME TARGET STATE SERVER STATE_DETAILS
--------------------------------------------------------------------------------
Local Resources
--------------------------------------------------------------------------------
ora.DATA.dg
ONLINE ONLINE oracle11g
ora.asm
ONLINE ONLINE oracle11g Started
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.cssd
1 ONLINE ONLINE oracle11g
ora.diskmon
1 ONLINE ONLINE oracle11g

Ahora procedemos a levantar nuestra instancia ASM

Vale la pena recordar, que la instancia ASM ya no se levanta con el rol SYSDBA, existe uno nuevo llamado SYSASM , si nos conectamos con SYSDBA, aparecerá un error de privilegios

[oracle@oracle11g bin]$ sqlplus /nolog

SQL*Plus: Release 11.2.0.1.0 Production on Fri Apr 16 06:05:11 2010

Copyright (c) 1982, 2009, Oracle. All rights reserved.

SQL> conn / as sysdba
Connected.
SQL> startup
ORA-01031: insufficient privileges
SQL>

Nos conectamos con el rol indicado y procedemos a subir la instancia ASM

SQL> conn / as sysasm
Connected.
SQL> startup
ASM instance started

Total System Global Area 284565504 bytes
Fixed Size 1336036 bytes
Variable Size 258063644 bytes
ASM Cache 25165824 bytes
ASM diskgroups mounted

PROBLEMA RESUELTO!!

Referencia

Nota : AFTER NODE REBOOT CSSD IS NOT STARTED IN 11gR2 Non-RAC [ID 947520.1]

[oracle@oracle11g 9352237]$ which make
/usr/bin/make

Si es encontrado significa que está en el PATH

Además se debe colocar en el PATH la ruta donde se encuentra el OPATCH, para ello ejecutamos el siguiente comando

export PATH=$PATH:$ORACLE_HOME/OPatch

Se debe verificar la versión del OPatch, tiene que ser 11.2.0.1.0 o superior

Primero se debe verificar la versión que estemos utilizando

[oracle@oracle11g parches_11_2_1_0]$ opatch version
Invoking OPatch 11.1.0.6.6

OPatch Version: 11.1.0.6.6

OPatch succeeded.

Como no es la correspondiente , debemos bajarla desde Metalink , en la siguiente URL

Parche 6880880

E instalarla

[oracle@oracle11g parches_11_2_1_0]$ unzip p6880880_112000_LINUX.zip
Archive: p6880880_112000_LINUX.zip
creating: OPatch/
creating: OPatch/docs/
inflating: OPatch/docs/FAQ
inflating: OPatch/docs/Users_Guide.txt
inflating: OPatch/docs/Prereq_Users_Guide.txt
creating: OPatch/jlib/
inflating: OPatch/jlib/opatch.jar
inflating: OPatch/jlib/opatchutil.jar
inflating: OPatch/jlib/opatchprereq.jar
inflating: OPatch/jlib/opatchactions.jar
inflating: OPatch/jlib/opatchext.jar
inflating: OPatch/jlib/opatchfmw.jar
creating: OPatch/crs/
inflating: OPatch/crs/auto_patch.pl
inflating: OPatch/crs/crsconfig_lib.pm
inflating: OPatch/crs/crsdelete.pm
inflating: OPatch/crs/crspatch.pm
creating: OPatch/crs/log/
extracting: OPatch/crs/log/dummy
inflating: OPatch/crs/oracss.pm
inflating: OPatch/crs/patch112.pl
inflating: OPatch/crs/s_crsconfig_defs
inflating: OPatch/crs/s_crsconfig_lib.pm
creating: OPatch/fmw/
inflating: OPatch/fmw/application.py
inflating: OPatch/fmw/init_def.py
inflating: OPatch/fmw/main_driver.py
inflating: OPatch/fmw/node_manager.py
inflating: OPatch/fmw/prereq.py
inflating: OPatch/fmw/start_stop.py
creating: OPatch/opatchprereqs/
creating: OPatch/opatchprereqs/opatch/
inflating: OPatch/opatchprereqs/opatch/opatch_prereq.xml
inflating: OPatch/opatchprereqs/opatch/rulemap.xml
inflating: OPatch/opatchprereqs/opatch/runtime_prereq.xml
creating: OPatch/opatchprereqs/oui/
inflating: OPatch/opatchprereqs/oui/knowledgesrc.xml
inflating: OPatch/opatchprereqs/prerequisite.properties
inflating: OPatch/opatch
inflating: OPatch/opatch.bat
inflating: OPatch/opatch.pl
inflating: OPatch/opatch.ini
inflating: OPatch/emdpatch.pl
inflating: OPatch/README.txt
creating: OPatch/ocm/
creating: OPatch/ocm/bin/
inflating: OPatch/ocm/bin/emocmrsp
inflating: OPatch/ocm/ocm_platforms.txt
creating: OPatch/ocm/lib/
inflating: OPatch/ocm/lib/emocmclnt-14.jar
inflating: OPatch/ocm/lib/emocmutl.jar
inflating: OPatch/ocm/lib/osdt_core3.jar
inflating: OPatch/ocm/lib/osdt_jce.jar
extracting: OPatch/ocm/ocm.zip

Eliminamos la anterior versión

Copiamos la que descomprimimos y verificamos la versión actual de nuestro OPatch

[oracle@oracle11g parches_11_2_1_0]$ rm -rf $ORACLE_HOME/OPatch
[oracle@oracle11g parches_11_2_1_0]$ cp -R OPatch $ORACLE_HOME/.
[oracle@oracle11g parches_11_2_1_0]$
[oracle@oracle11g parches_11_2_1_0]$
[oracle@oracle11g parches_11_2_1_0]$ cd $ORACLE_HOME/OPatch
[oracle@oracle11g OPatch]$ ./opatch version
Invoking OPatch 11.2.0.1.2

OPatch Version: 11.2.0.1.2

OPatch succeeded.
[oracle@oracle11g OPatch]$

Después de lo anterior , podemos verificar que no haya problemas y/o conflictos con parches existentes, para ello ejecutamos el comando

opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir ./9352237

OBS : Esto se debe hacer en la ruta donde se encuentra la carpeta del PSU

[oracle@oracle11g parches_11_2_1_0]$ opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir ./9352237
Invoking OPatch 11.2.0.1.2

Installer de Parche Temporal de Oracle versión 11.2.0.1.2
Copyright (c) 2010, Oracle Corporation. Todos los Derechos Reservados.

PREREQ session

Directorio Raíz de Oracle : /u01/app/oracle/product/11.2.0/dbhome_1
Inventario Central: /u01/app/oracle/oraInventory
de : /etc/oraInst.loc
Versión de OPatch : 11.2.0.1.2
Versión de OUI : 11.2.0.1.0
Ubicación de OUI : /u01/app/oracle/product/11.2.0/dbhome_1/oui
Ubicación de Archivo Log : /u01/app/oracle/product/11.2.0/dbhome_1/cfgtoollogs/opatch/opatch2010-04-13_13-32-28PM.log

Patch history file: /u01/app/oracle/product/11.2.0/dbhome_1/cfgtoollogs/opatch/opatch_history.txt

Invoking prereq "checkconflictagainstohwithdetail"

Prereq "checkConflictAgainstOHWithDetail" passed.

OPatch succeeded.

Para instalar el PSU se debe bajar la instancia y bajar el listener

Estando dentro de la carpeta del PSU , se ejecuta opatch apply

cd 9352237
opatch apply

Invoking OPatch 11.2.0.1.2

Oracle Interim Patch Installer version 11.2.0.1.2
Copyright (c) 2010, Oracle Corporation. All rights reserved.

Oracle Home : /u01/app/oracle/product/11.2.0/dbhome_1
Central Inventory : /u01/app/oracle/oraInventory
from : /etc/oraInst.loc
OPatch version : 11.2.0.1.2
OUI version : 11.2.0.1.0
OUI location : /u01/app/oracle/product/11.2.0/dbhome_1/oui
Log file location : /u01/app/oracle/product/11.2.0/dbhome_1/cfgtoollogs/opatch/opatch2010-04-13_14-34-26PM.log

Patch history file: /u01/app/oracle/product/11.2.0/dbhome_1/cfgtoollogs/opatch/opatch_history.txt

ApplySession applying interim patch '9352237' to OH '/u01/app/oracle/product/11.2.0/dbhome_1'

Running prerequisite checks...
Provide your email address to be informed of security issues, install and
initiate Oracle Configuration Manager. Easier for you if you use your My
Oracle Support Email address/User Name.
Visit http://www.oracle.com/support/policies.html for details.
Email address/User Name:

You have not provided an email address for notification of security issues.
Do you wish to remain uninformed of security issues ([Y]es, [N]o) [N]: Y

OPatch detected non-cluster Oracle Home from the inventory and will patch the local system only.

Please shutdown Oracle instances running out of this ORACLE_HOME on the local system.
(Oracle Home = '/u01/app/oracle/product/11.2.0/dbhome_1')

Is the local system ready for patching? [y|n]
y
User Responded with: Y
Backing up files and inventory (not for auto-rollback) for the Oracle Home
Backing up files affected by the patch '9352237' for restore. This might take a while...
Backing up files affected by the patch '9352237' for rollback. This might take a while...
Execution of 'sh /home/oracle/parches_11_2_1_0/9352237/custom/scripts/pre -apply 9352237 ':

Return Code = 0

Patching component oracle.rdbms.rsf, 11.2.0.1.0...
Updating archive file "/u01/app/oracle/product/11.2.0/dbhome_1/lib/libpls11.a" with "lib/libpls11.a/phd.o"
....
Updating archive file "/u01/app/oracle/product/11.2.0/dbhome_1/lib/libcommon11.a" with "lib/libcommon11.a/kdzc.o"
Updating archive file "/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/lib/libdbtools11.a" with "rdbms/lib/libdbtools11.a/krmq.o"

Patching component oracle.rdbms.dbscripts, 11.2.0.1.0...
Copying file to "/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/admin/prvtamgt.plb"
Copying file to "/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/admin/utlu112i.sql"
Copying file to "/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/admin/utlu112x.sql"
Copying file to "/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/admin/catexp.sql"

Patching component oracle.rdbms, 11.2.0.1.0...
Updating archive file "/u01/app/oracle/product/11.2.0/dbhome_1/lib/libserver11.a" with "lib/libserver11.a/kcc.o"
Updating archive file "/u01/app/oracle/product/11.2.0/dbhome_1/lib/libserver11.a" with "lib/libserver11.a/kdt.o"
....
Updating archive file "/u01/app/oracle/product/11.2.0/dbhome_1/lib/libasmclnt11.a" with "lib/libasmclnt11.a/kgfn.o"
Updating archive file "/u01/app/oracle/product/11.2.0/dbhome_1/lib/libasmclnt11.a" with "lib/libasmclnt11.a/kgfo.o"

Copying file to "/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/lib/ktd.o"
Copying file to "/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/lib/jox.o"
...
Copying file to "/u01/app/oracle/product/11.2.0/dbhome_1/psu/11.2.0.1.1/catpsu_rollback.sql"
Copying file to "/u01/app/oracle/product/11.2.0/dbhome_1/rdbms/admin/bundledata_PSU.xml"

Patching component oracle.oraolap, 11.2.0.1.0...
Updating archive file "/u01/app/oracle/product/11.2.0/dbhome_1/lib/liboraolap11.a" with "lib/liboraolap11.a/xscarrot.o"

Patching component oracle.rdbms.deconfig, 11.2.0.1.0...
Copying file to "/u01/app/oracle/product/11.2.0/dbhome_1/lib/libasmclnt11.so"

Patching component oracle.javavm.server, 11.2.0.1.0...
Copying file to "/u01/app/oracle/product/11.2.0/dbhome_1/javavm/install/jvm_exp.sql"
Copying file to "/u01/app/oracle/product/11.2.0/dbhome_1/javavm/install/initjvm.sql"
Copying file to "/u01/app/oracle/product/11.2.0/dbhome_1/javavm/install/jvmursc.sql"
Running make for target client_sharedlib
Running make for target irman
Running make for target ikfod
Running make for target irenamedg
Running make for target idgmgrl
Running make for target imkpatch
Running make for target client_sharedlib
Running make for target ioracle
ApplySession adding interim patch '9352237' to inventory

Verifying the update...
Inventory check OK: Patch ID 9352237 is registered in Oracle Home inventory with proper meta-data.
Files check OK: Files from Patch ID 9352237 are present in Oracle Home.

--------------------------------------------------------------------------------
********************************************************************************
********************************************************************************
** ATTENTION **
** **
** Please note that the Patch Set Update Installation (PSU Deinstallation) **
** is not complete until all the Post Installation (Post Deinstallation) **
** instructions noted in the Readme accompanying this PSU, have been **
** successfully completed. **
** **
********************************************************************************
********************************************************************************

--------------------------------------------------------------------------------

Execution of 'sh /home/oracle/parches_11_2_1_0/9352237/custom/scripts/post -apply 9352237 ':

Return Code = 0

The local system has been patched and can be restarted.

OPatch succeeded.

Una vez instalado el parche , se debe ejecutar lo siguiente

cd $ORACLE_HOME/rdbms/admin
sqlplus /nolog
SQL> CONNECT / AS SYSDBA
SQL> STARTUP
SQL> @catbundle.sql psu apply
SQL> QUIT

Y cualquier error , se debe verificar en

$ORACLE_HOME/cfgtoollogs/catbundle/catbundle_PSU_ORCL11G2_APPLY_2010Apr13_15_11_49.log

Y como punto final vemos el catálogo de parchado , según el OPatch

opatch lsinventory

Y la nueva versión del motor

SQL> col comments format a20
SQL> r
1* select version , comments from registry$history

VERSION COMMENTS
------------------------------ --------------------
11.2.0.1 PSU 11.2.0.1.1

Y ya.. tenemos instalado nuestro primer PSU para Oracle11gr2

Espero que les sirva

SQL> create table t
2 (column1 number not null,
3 constraint pk_t PRIMARY KEY (column1));

Table created.

2.- Le insertamos datos

SQL> insert into t (select rownum from dba_objects);

72137 rows created.

SQL> commit;

Commit complete.

3.- Llevamos a cabo una consulta para ver su plan de ejecución

SQL> explain plan for
2 select * from t
3 where column1 = 10000;

Explained.

SQL> set linesize 130
SQL> set pagesize 0
SQL>
SQL> select * from table(DBMS_XPLAN.DISPLAY);
Plan hash value: 1517170033

--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 13 | 1 (0)| 00:00:01 |
|* 1 | INDEX UNIQUE SCAN| PK_T | 1 | 13 | 1 (0)| 00:00:01 |
--------------------------------------------------------------------------

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

1 - access("COLUMN1"=10000)

13 rows selected.

Como se puede apreciar, ocupa de forma clara , el índice PK_T

4.- Dejamos el índice como INVISIBLE y vemos nuevamente el plan de ejecución

SQL> alter index pk_t invisible;

Index altered.

SQL> explain plan for
2 select * from t
3 where column1 = 10000;

Explained.

SQL> select * from table(DBMS_XPLAN.DISPLAY);
Plan hash value: 1601196873

--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 91 | 1183 | 32 (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| T | 91 | 1183 | 32 (0)| 00:00:01 |
--------------------------------------------------------------------------

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

1 - filter("COLUMN1"=10000)

13 rows selected.

Como se puede apreciar, ahora el índice no es VISIBLE , pero en el fondo no es visible para el optimizador, por el cual queda fuera de los planes de ejecución que el optimizador pueda generar.

5.- Aunque utilicemos explicitamente el nombre del índice con un hint, este no será utilizado

SQL> explain plan for
2 select /*+ index(t pk_t) */ * from t where column1 = 20000;

Explained.

SQL> select * from table(DBMS_XPLAN.DISPLAY);
Plan hash value: 1601196873

--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 91 | 1183 | 32 (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| T | 91 | 1183 | 32 (0)| 00:00:01 |
--------------------------------------------------------------------------

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

1 - filter("COLUMN1"=20000)

13 rows selected.

6.- Podemos ver el estado de un índice INVISIBLE consultando cualquier vista *_INDEXES

SQL> select owner , index_name , visibility from dba_indexes where index_name like 'PK_T';

OWNER INDEX_NAME VISIBILIT
------------------------------ ------------------------------ ---------
SYS PK_T INVISIBLE

7.- Existe un parámetro de inicialización llamado OPTIMIZER_USE_INVISIBLE_INDEXES, que le indica al optimizador si toma o no en cuenta los índices en estado INVISIBLE cuando esta realizando los planes de ejecución, por defecto está en FALSE, o sea, no toma en cuenta los índices INVISIBLES.

SQL> show parameter optimizer_use_invi

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
optimizer_use_invisible_indexes boolean FALSE

8.- Pero si cambiamos este parámetro y lo dejamos en TRUE, toma en cuenta los índices aunque ellos estén INVISIBLES

SQL> alter system set optimizer_use_invisible_indexes=TRUE scope=both;

System altered.

SQL> select owner , index_name , visibility from dba_indexes where index_name like 'PK_T';

OWNER INDEX_NAME VISIBILIT
------------------------------ ------------------------------ ---------
SYS PK_T INVISIBLE

SQL>
SQL> explain plan for
select /*+ index(t pk_t) */ * from t where column1 = 20000; 2

Explained.

SQL> select * from table(DBMS_XPLAN.DISPLAY);

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------
Plan hash value: 1517170033

--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 13 | 1 (0)| 00:00:01 |
|* 1 | INDEX UNIQUE SCAN| PK_T | 1 | 13 | 1 (0)| 00:00:01 |
--------------------------------------------------------------------------

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

PLAN_TABLE_OUTPUT
--------------------------------------------------------------------------------

1 - access("COLUMN1"=20000)

13 rows selected.

Lee también sobre

Nueva característica de los índices UNUSABLES

Creando un índice INVISIBLE

Espero que les sirva

select table_name ,
to_number(extractvalue(dbms_xmlgen.getXMLtype ('select count(*) cnt from '||table_name),
'/ROWSET/ROW/CNT')) "Cantidad de filas"
from dba_tables
where owner like '%NOMBRE USUARIO%'
/

¿Práctico cierto?

Espero les sirva

[oracle@oracle11g bin]$ pwd
/u01/app/oracle/product/11.2.0/grid/bin
[oracle@oracle11g bin]$ echo $ORACLE_HOME
/u01/app/oracle/product/11.2.0/grid

Llamamos al utilitario asmcmd

[oracle@oracle11g bin]$
[oracle@oracle11g bin]$ asmcmd

ASMCMD>

Generamos un archivo con tags para XML con los cuales generaremos el diskgroup, este archivo contiene lo siguiente

Para visualizar el archivo CLICK ACÁ

Procedemos a ejecutar ese archivo xml , mediante el comando mkgrp dentro del utilitario asmcmd

ASMCMD> mkgrp '/home/oracle/disk.xml'

Una vez creado el DiskGroup verificamos su metadata

ASMCMD> lsdg
State Type Rebal Sector Block AU Total_MB Free_MB Req_mir_free_MB Usable_file_MB Offline_disks Voting_files Name
MOUNTED EXTERN N 512 4096 1048576 500 440 0 440 0 N DATA/

ASMCMD>

Forma 3 : Mediante utilitario SqlPlus

Validamos las variables de medio ambiente

[oracle@oracle11g ~]$ env | grep ORACLE
ORACLE_SID=+ASM
ORACLE_BASE=/u01/app/oracle
ORACLE_HOME=/u01/app/oracle/product/11.2.0/grid
[oracle@oracle11g ~]$

Nos conectamos a SQL*Plus

[oracle@oracle11g ~]$ sqlplus /nolog

SQL*Plus: Release 11.2.0.1.0 Production on Sat Mar 13 23:31:36 2010

Copyright (c) 1982, 2009, Oracle. All rights reserved.

SQL> conn / as sysasm
Connected.

Y generamos un DiskGroup

SQL> r
1* create diskgroup data external redundancy disk '/dev/raw/raw1','/dev/raw/raw2','/dev/raw/raw3','/dev/raw/raw4','/dev/raw/raw5'

Diskgroup created.

SQL> r
1* select group_number , name , state , total_mb from v$asm_diskgroup

GROUP_NUMBER NAME STATE TOTAL_MB
------------ ------------------------------ ----------- ----------
1 DATA MOUNTED 500

Nota : Nos tenemos que conectar con el nuevo rol de asm llamado sysasm , pues conectados como SYSDBA nos dará un error de privilegios

SQL> create diskgroup data external redundancy disk '/dev/raw/raw1','/dev/raw/raw2','/dev/raw/raw3','/dev/raw/raw4','/dev/raw/raw5';
create diskgroup data external redundancy disk '/dev/raw/raw1','/dev/raw/raw2','/dev/raw/raw3','/dev/raw/raw4','/dev/raw/raw5'
*

ERROR at line 1:
ORA-15260: permission denied on ASM disk group

Forma 4 : Mediante utilitario ASMCA

También se puede generar un diskgroup en formato silent, no es muy recomendado, pero sepan que existe.

Verificamos las variable de medio ambiente

[oracle@oracle11g bin]$ env | grep ORACLE
ORACLE_SID=+ASM
ORACLE_BASE=/u01/app/oracle
ORACLE_HOME=/u01/app/oracle/product/11.2.0/grid
[oracle@oracle11g bin]$

Ejecutamos el comando asmca -silent

[oracle@oracle11g bin]$ asmca -silent -createDiskGroup -diskgroupname DATA -redundancy external -compatible.asm '11.2.0.0.0' -compatible.rdbms '11.2.0.0.0' -disk '/dev/raw/raw5'
-disk '/dev/raw/raw1' -disk '/dev/raw/raw2' -disk '/dev/raw/raw3' -disk '/dev/raw/raw4'

El grupo de discos DATA se ha creado correctamente.

Realizamos la validación del nuevo DiskGroup generado

[oracle@oracle11g bin]$ asmcmd

ASMCMD> lsdg
State Type Rebal Sector Block AU Total_MB Free_MB Req_mir_free_MB Usable_file_MB Offline_disks Voting_files Name
MOUNTED EXTERN N 512 4096 1048576 500 440 0 440 0 N DATA/

ASMCMD>

ASMCMD> quit
[oracle@oracle11g bin]$

Referencias :
Utilitario ASMCMD
Utilitario ASMCA



Espero les sirva.

$ getconf -a | grep KERN

64bits : KERNEL_BITMODE: 64
32bits : KERNEL_BITMODE: 32

También puede ser utilizado el comando

$ file /usr/lib/boot/unix*

64bits : 64-bit XCOFF executable or object module not stripped
32bits : executable (RISC System/6000) or object module not stripped

En HP-UX

/usr/bin/ getconf KERNEL_BITS

Otro comando a utilizar

/usr/bin/file /stand/vmunix

64bits : stand/vmunix: ELF-64 executable object file - PA-RISC 2.0 (LP64)
32bits : /stand/vmunix: PA-RISC1.1 executable -not stripped

En Solaris

/usr/bin/isainfo -v
/usr/bin/isainfo -kv

64bits : 64-bit sparcv9 applications
32bits : sparc application

En Linux

getconf LONG_BIT

o se puede ejecutar el comando

uname -a

64bits : x86_64
64bits : ia64

Sino, indica 32 bits

En Windows (Wintendo)

Type "dxdiag" on the Start -> Run

Como todo tiene un orígen , he acá la nota de Oracle

How to Determine Whether the OS is 32-bit or 64-bit [ID 421453.1]

/ ORACLE vs. Oracle
/ -----------------
/ The word ORACLE in uppercase refers to the ORACLE server. Use the term
/ "ORACLE server" when referring to the server.
/
/ The word Oracle in lowercase with capitalized first letter refers to the
/ company. Use "Oracle Corp." when referring to the company.

O sea, cuando hablemos de base de datos , será ORACLE, cuando hablemos de la empresa será Oracle

¿no seremos demasiado cuadrado?

Para que lo tengan en cuenta, el archivo oraus.msg se guardan entre otras cosas los mensajes de error para los códigos ORA-

De Lunes a Viernes la cantidad de Switch en mi base de datos es 4 por hora, o sea, cada 15 minutos se generá un archive, por ende cada 15 minutos se actualiza mi base de datos StandBy , por lo tanto, si se llegase a producir un error o corrupción de mi base de datos principal, a lo más, perdería 15 minutos (por la información de redo que queda en los grupos de redologs) .

Pero el fin de semana, no se hace ningún Switch , o sea, el grupo current será durante todo el fin de semana el mismo grupo, y no puedo darme el lujo de perder el grupo current del fin de semana, pues son pocas transacciones , pero críticas.

¿Podría colocar un cron el fin de semana para que se ejecute cada 30 minutos y efectúe un Switch de Redo? , si.. pero sería poco elegante

¿Cómo lo soluciono? ... mmmmm

Log Switch on hour basis

DIA              10  11  12  13  14  15  16  17  18  19  20  21  22  23  TOTAL
---------------- --- --- --- --- --- --- --- --- --- --- --- --- --- --- -----
WED, 28-OCT-2009 -   -   -   -   -   -   -   -   -   -   2   -   -   -       2

Ahora, procedemos a cambiar el parámetro ARCHIVE_LAG_TARGET , con lo cual aceleramos los Switch de Redo y provocaremos un gran impacto ¿cuál? , pues el de minimizar la información pérdida si se llega a corromper nuestro Grupo de Redo current, ¿por qué? , pues porque la información será pasada de forma más rápida a mi base de datos StandBy

Ejemplo práctico :

Modificamos el ARCHIVE_LAG_TARGET y lo dejamos en 2 minutos

SQL> alter system set archive_lag_target=120 scope=both;

System altered.

Con lo anterior , si analizamos el archivo de alerta , veremos que efectivamente se producen Switch de Redo cada 2 minutos

Sun Jan 31 22:45:58 2010
Thread 1 cannot allocate new log, sequence 18
Current log# 1 seq# 17 mem# 0: /home/oracle/app/oracle/oradata/db10g/redo01.log
Thread 1 advanced to log sequence 18
Current log# 2 seq# 18 mem# 0: /home/oracle/app/oracle/oradata/db10g/redo02.log
Sun Jan 31 22:49:02 2010
Thread 1 advanced to log sequence 19
Current log# 3 seq# 19 mem# 0: /home/oracle/app/oracle/oradata/db10g/redo03.log
Sun Jan 31 22:53:57 2010
Thread 1 advanced to log sequence 20
Current log# 1 seq# 20 mem# 0: /home/oracle/app/oracle/oradata/db10g/redo01.log
Sun Jan 31 22:59:01 2010
Thread 1 advanced to log sequence 21
Current log# 2 seq# 21 mem# 0: /home/oracle/app/oracle/oradata/db10g/redo02.log
Sun Jan 31 23:01:05 2010
Thread 1 advanced to log sequence 22
Current log# 3 seq# 22 mem# 0: /home/oracle/app/oracle/oradata/db10g/redo03.log
Sun Jan 31 23:03:05 2010
Thread 1 advanced to log sequence 23
Current log# 1 seq# 23 mem# 0: /home/oracle/app/oracle/oradata/db10g/redo01.log
Sun Jan 31 23:05:03 2010
Thread 1 cannot allocate new log, sequence 24
Current log# 1 seq# 23 mem# 0: /home/oracle/app/oracle/oradata/db10g/redo01.log
Thread 1 advanced to log sequence 24
Current log# 2 seq# 24 mem# 0: /home/oracle/app/oracle/oradata/db10g/redo02.log

Miramos la actividad de nuestra instancia , en cuanto a Switch por horas, y claro... se refleja efectivamente el cambio

DIA              10  11  12  13  14  15  16  17  18  19  20  21  22  23  TOTAL
---------------- --- --- --- --- --- --- --- --- --- --- --- --- --- --- -----
WED, 28-OCT-2009 -   -   -   -   -   -   -   -   -   -   2   -   -   -       2
SUN, 31-JAN-2010 -   -   -   -   -   -   -   -   -   -   -   -   19  2      21

En resumidas cuentas el parámetro ARCHIVE_LAG_TARGET nos permite acelerar los Switch de Redo, ¿para qué nos puede servir eso? , pues para mantener una sincronización eficaz con nuestra base de datos StandBy o simplemente para que la cantidad de información que podríamos perder en un crash , siempre sea la mínima

Esto es aplicable tanto para bases de datos primarias (con StandBy) , como para base de datos StandAlone

Pues bien , la información que todo mortal necesita

Archive_lag_target en Oracle9i
Archive_lag_target en Oracle10g
Archive_lag_target en Oracle11gr1
Archive_lag_target en Oracle11gr2

ALTER SYSTEM SET SQL_TRACE=TRUE;

Esta forma es una manera sencilla de tracer una sesión , pero existe otra mucho más potente, la activación del evento 10046

Acá va una pequeña explicación

El Trace Event 10046 es una forma de generar trace de una consulta en partícular, muy parecida a SQL_TRACE, pero esta última adolece de un problema que es la necesidad de ejecutar el comando desde la misma sesión que esta provocando el evento de espera.

Puede tracear procesos background de Oracle y los archivos resultantes los deja en la carpeta BDUMP (pre 11gr1) , si estamos traceando procesos de usuarios, los achivos de trace resultantes los deja en la carpeta UDUMP

Nota : Cuando se indica BDUMP , se está haciendo mención a la carpeta que esta mencionada en el parámetro background_dump_dest
Y cuando se indica UDUMP , el parámetro asociado es el user_dump_dest.

¿Qué es lo que hace tan potente esta herramienta?, pues bien , este evento proporciona muchos más detalles del comportamiento de una sentencia SQL (o de varias) , para esto , se pueden setear niveles de traceo.

¿Qué niveles de traceo están disponibles?

Level 0 : El traceo está deshabilitado
Level 1 : Traceo standar , tal cual lo crea SQL_TRACE
Level 4 : Genera un Level 1 + información de las variables bind
Level 8 : Genera un Level 1 + información de los eventos de espera
Level 12 : Genera un Level 8 + información de las variables bind

El tema de los niveles hay que tomarlo con mucha calma, pues se puede generar muchísima información con un nivel 12, aunque muchísima de esa información es de un nivel muy bajo y nos puede dar pistas de lo que está sucediendo con una sentencia o un grupo de sentencias en partìcular.

¿Qué parámetros son necesarios para utilizar el Trace Event 10046?

Para que el Trace Event 10046 pueda ser utilizado de forma óptima, debiesen setearse los parámetros TIMED_STATISTICS en TRUE y tener especial cuidado en el parámetro MAX_DUMP_FILE_SIZE, pues este parámetro es el que controla el tamaño máximo de los archivos de trace.

¿Cómo usar este evento?
Pues existen muchas formas de utilizarlo, aquí mencionaremos la más sencilla y en posteriores post , indicaremos unas más avanzadas.

Para una sesión en partícular

SQL> alter session set timed_statistics = true;
SQL> alter session set max_dump_file_size = unlimited;
SQL> alter session set events '10046 trace name context forever, level 12';

REM Se ejecutan todos los scripts , consultas y programas habidos y por haber y se desactiva el Trace Event

SQL> alter session set events '10046 trace name context off';

Nota : Cabe mencionar lo potente y agresivo que es el nivel 12, se debe manejar con precaución.

Ejemplo práctico

SQL> conn / as sysdba
Connected.
SQL>
SQL>
SQL>
SQL>
SQL> alter system set timed_statistics=TRUE;
System altered.

SQL>
SQL> alter system set max_dump_file_size = unlimited;
System altered.

SQL> alter session set events '10046 trace name context forever, level 12';
Session altered.

Y si queremos ver como avanza nuestra trace , pues en otra pantalla de Sql*Plus, mostramos el contenido del parámetro user_dump_dest

SQL> show parameter user_dump

Nos vamos a ese directorio y al último trace generado , le colocamos un tail -f para apreciar la cantidad de información que genera.

Después de eso, en nuestra sesión traceada , ejecutamos algunos comandos

SQL> select * from v$instance;
SQL> create table ejemplo as select * from dba_objects;
SQL> drop table ejemplo;

Al archivo generado , le aplicamos tkprof

[oracle@oracle10g udump]$ tkprof orcl_ora_2238.trc salida.txt

Y ya tenemos , un archivo formateado , con absolutamente toda la información del proceso que acabamos de realizar

¿Qué información se visualiza?

La información que se muestra , es muy parecida al SQL_TRACE , pero mucho más potente , podríamos hablar entonces de un DON SQL_TRACE

********************************************************************************

select obj#,type#,ctime,mtime,stime,status,dataobj#,flags,oid$, spare1,
spare2
from
obj$ where owner#=:1 and name=:2 and namespace=:3 and remoteowner is null
and linkname is null and subname is null

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 4 0.00 0.00 0 0 0 0
Execute 81 0.03 0.02 0 0 0 0
Fetch 81 0.03 0.11 7 237 0 75
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 166 0.06 0.14 7 237 0 75

Misses in library cache during parse: 1
Misses in library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: SYS (recursive depth: 1)

Rows Row Source Operation
------- ---------------------------------------------------
0 TABLE ACCESS BY INDEX ROWID OBJ$ (cr=2 pr=0 pw=0 time=246 us)
0 INDEX RANGE SCAN I_OBJ2 (cr=2 pr=0 pw=0 time=234 us)(object id 37)

Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 7 0.05 0.10

Referencias :
EVENT: 10046 "enable SQL statement tracing (including binds/waits)" [ID 21154.1]
Recommended Method for Obtaining 10046 trace for Tuning [ID 376442.1]

Espero les haya servido

PD : A quienes se pregunten , ¿que relación hay entre Darth Vader y el evento 10046? , en realidad ninguna.. pero se ve bien ..

sqlplus usuario/password@string_conexion @archivo.sql

3.- En el script va a aparecer una consulta con respecto al nombre del usuario

Ingrese usuario a crear con solo roles de lectura :

4.- Además aparece una pregunta si es VoC ,

V = Implica que se mostrará el comando (Visualizar)
C = Implica que se ejecutará el comando (Crear)

Desea visualizar o crear (V o C)? :

5.- Con lo anterior se crearán roles con el prefijo ROLSER_nombre_de_esquema

6.- Se creará el usuario con grant de connect y se le asignarán todos los roles generados

En resumidas cuentas, un comando , para esa ingrata tarea ... de enrolar

Espero les sirva

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

Graficar en Excel información proveniente desde Statspack

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

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

RMAN> catalog backuppiece '/respaldo/oracle/backupset_32181818_1.bkp';

cataloged backuppiece
backup piece handle=/respaldo/oracle/backupset_32181818_1.bkp recid=12469 stamp=707174130

RMAN>

Y procedemos a restaurar

RMAN> restore archivelog logseq=39753;

Starting restore at 01-JAN-10
using channel ORA_DISK_1
using channel ORA_SBT_TAPE_1

channel ORA_DISK_1: starting archive log restore to default destination
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=39753
channel ORA_DISK_1: reading from backup piece /respaldo/oracle/backupset_32181818_1.bkp
channel ORA_DISK_1: restored backup piece 1
piece handle=/respaldo/oracle/backupset_32181818_1.bkp tag=TAG20091210T025643
channel ORA_DISK_1: restore complete, elapsed time: 00:02:35
Finished restore at 01-JAN-10

RMAN>

Pero figura como channel ORA_DISK_1: starting archive log restore to default destination

¿Qué significa eso? , pues sencillamente que restaura a una posición por defecto que para nuestro caso es la FRA que se encuentra en ASM

¿Cómo averiguamos donde quedo?, pues ejecutando la misma restauración

RMAN> restore archivelog logseq=39753;

Starting restore at 01-JAN-10
using channel ORA_DISK_1
using channel ORA_SBT_TAPE_1

archive log thread 1 sequence 39753 is already on disk as file +DATA/instance1/archivelog/2010_01_01/thread_1_seq_39753.687.707174297
restore not done; all files readonly, offline, or already restored
Finished restore at 01-JAN-10

Ahora nos vemos enfrentados al hecho de sacar el archivelog desde la FRA, eso se hace mediante los siguientes comandos

RMAN> copy archivelog '+DATA/instance1/archivelog/2010_01_01/thread_1_seq_39753.687.707174297' to '/respaldo/oracle/logminer/archive_39753.arc';

Starting backup at 01-JAN-10
released channel: ORA_SBT_TAPE_1
using channel ORA_DISK_1
channel ORA_DISK_1: starting archive copy
input archive log thread=1 sequence=39753 recid=157342 stamp=707174445
output filename=/respaldo/oracle/logminer/archive_39753.arc recid=157343 stamp=707176036
channel ORA_DISK_1: archivelog copy complete, elapsed time: 00:00:09
Finished backup at 01-JAN-10

RMAN>

Después de eso, simplemente borramos el archivelog que dejamos en la FRA

RMAN> delete archivelog '+DATA/instance1/archivelog/2010_01_01/thread_1_seq_39753.687.707174297';

released channel: ORA_DISK_1
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=521 instance=instance1 devtype=DISK

List of Archived Log Copies
Key Thrd Seq S Low Time Name
------- ---- ------- - --------- ----
157342 1 39753 A 09-DEC-09 +DATA/instance1/archivelog/2010_01_01/thread_1_seq_39753.687.707174297

Do you really want to delete the above objects (enter YES or NO)? YES
deleted archive log
archive log filename=+DATA/instance1/archivelog/2010_01_01/thread_1_seq_39753.687.707174297 recid=157342 stamp=707174445
Deleted 1 objects

RMAN>

Después de eso, podemos aplicar logminer sobre los archivelogs que se encuentran en sistema operativo

Como resumen , lo más interesante es el uso del comando COPY en RMAN, con lo cual podemos sacar los archivelogs desde la FRA en ASM hacía disco.

[oracle@SQL]$ sqlplus usuario/password

SQL*Plus: Release 11.2.0.1.0 Production on Thu Dec 10 20:58:22 2009

Copyright (c) 1982, 2009, Oracle. All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> start file
select COUNT(*)
*
ERROR at line 1:
ORA-03113: end-of-file on communication channel
Process ID: 887
Session ID: 134 Serial number: 162

SQL>

Tratamos de hacer un trace, se cae, tratamos de generar un evento de traceo , se cae y así , por siempre y para siempre..

Lo mejor es abrir un caso en Oracle, ellos debiesen solucionarlo (no siempre es así, pero les tengo fé)

Y cuando vamos al ORACLE_BASE, nos damos cuenta de que no existe, claro estamos en 11gr2

Nos colocamos el machete en la boca y nos metemos a los directorios de log y trace (llamado diag) y nos encontramos con muchos de ellos

[oracle@SQL]$ ls -ltr
total 136
drwxr-x--- 2 oracle oinstall 4096 Nov 6 00:17 hm
drwxr-x--- 2 oracle oinstall 4096 Nov 6 00:17 alert
drwxr-x--- 2 oracle oinstall 4096 Dec 10 20:37 metadata
drwxr-x--- 2 oracle oinstall 4096 Dec 10 20:37 ir
drwxr-x--- 4 oracle oinstall 4096 Dec 10 20:58 incident
drwxr-x--- 8 oracle oinstall 12288 Dec 10 20:58 cdump
drwxr-x--- 2 oracle oinstall 4096 Dec 10 20:58 sweep
drwxr-x--- 2 oracle oinstall 20480 Dec 10 20:58 stage
drwxr-x--- 2 oracle oinstall 4096 Dec 10 20:58 lck
drwxr-x--- 4 oracle oinstall 4096 Dec 10 21:09 incpkg
drwxr-x--- 4 oracle oinstall 69632 Dec 10 21:20 trace
[oracle@SQL]$ pwd
/u01/app/oracle/diag/rdbms/inst1/inst1
[oracle@SQL]$

Es ahora donde nos entra la desesperación y nos preguntamos ¿Qué #$"°| le envíamos a Oracle?

Pues bien , allí es donde ingresa el ADRCI, el utilitario para hacernos la vida más fácil con la nueva estructura de diagnóstico que nos provee Oracle

He aquí un pequeño ejercicio

1.- Nos conectamos al adrci

[oracle@SQL]$ adrci

ADRCI: Release 11.2.0.1.0 - Production on Thu Dec 10 21:03:05 2009

Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.

ADR base = "/u01/app/oracle"
adrci>

2.- Verificamos los ORACLE_HOME existente (son mas de 1 ya que estamos trabajando con el DIAG)

adrci> show homes
ADR Homes:
diag/tnslsnr/maq1/listener
diag/rdbms/inst1/inst1
adrci>

3.- Para poder trabajar con el adrci, se debe por obligación seleccionar uno de estos ORACLE HOMES

adrci> set homepath diag/rdbms/inst1/inst1
adrci>
adrci> show homes
ADR Homes:
diag/rdbms/inst1/inst1
adrci>

4.- Una vez seleccionado nuestro ORACLE_HOME, procedemos a ver los "problemas" e "incidentes"
Sólo como introducción , pues generaré un post al respecto, un problema genera múltiples incidentes y un problema es casi siempre crítico, o sea, solucionando el problema se acaban los incidentes (suena a ITIL )

adrci> show problem

ADR Home = /u01/app/oracle/diag/rdbms/inst1/inst1:
*************************************************************************
PROBLEM_ID PROBLEM_KEY LAST_INCIDENT LASTINC_TIME
-------------------- ----------------------------------------------------------- -------------------- ----------------------------------------
1 ORA 7445 [_intel_fast_memcmp()+30] 275 2009-12-10 20:58:26.261000 -03:00
1 rows fetched

5.- Aparece claramente el problema, un error ORA-07445, ahora queremos ver los incidentes que ha originado ese problema

adrci> show incident

ADR Home = /u01/app/oracle/diag/rdbms/inst1/inst1:
*************************************************************************
INCIDENT_ID PROBLEM_KEY CREATE_TIME
-------------------- ----------------------------------------------------------- ----------------------------------------
251 ORA 7445 [_intel_fast_memcmp()+30] 2009-12-10 20:41:07.496000 -03:00
275 ORA 7445 [_intel_fast_memcmp()+30] 2009-12-10 20:58:26.261000 -03:00
2 rows fetched

adrci>

Como se puede apreciar, ha generado varios incidentes , pero sólo necesitamos uno de ellos como para comenzar a procesar la información y poder "empaquetar" todos los archivos necesarios.

6.- Para ello , tomamos el INCIDENT_ID que necesitamos y ejecutamos el siguiente comando

adrci> ips pack incident 275 in /home/oracle
Generated package 2 in file /home/oracle/ORA7445_i_20091210210936_COM_1.zip, mode complete
adrci>

7.- Una vez ejecutado el comando , tenemos un zip con TODA LA INFORMACIÓN necesaria para soporte Oracle y casi ... no nos despeinamos

Más información del ADRCI

Espero les sirva...

[oracle@oracle10g oracle]$ strace -o salida.txt lsnrctl start LISTENR
[oracle@oracle10g oracle]$ ls -ltr salida.txt
-rw-r--r-- 1 oracle oinstall 65910 Dec 6 09:26 salida.txt

Cada vez que sucede un error casi siempre aparece un -1 con la descripción del error dentro del archivo generado en el punto anterior.
Eje:

2236 stat64("/u01/app/oracle/product/10.1.0/db_1/lib/tls", 0xbfff8bf0) = -1 ENOENT (No such file or directory)

Incluso se le puede agregar la fecha del día a cada línea de salida de strace
Eje:

strace -t -o salida.txt lsnrctl start LISTENR

more salida.txt
09:29:54 execve("/u01/app/oracle/product/10.1.0/db_1/bin/lsnrctl", ["lsnrctl", "start", "LISTENR"], [/* 29 vars */]) = 0
09:29:54 uname({sys="Linux", node="oracle10g.inmotion.cl", ...}) = 0
09:29:54 brk(0) = 0x8f75000

Incluso con microsegundos
Eje:

[oracle@oracle10g oracle]$ strace -tt -o salida.txt lsnrctl start LISTENR

[oracle@oracle10g oracle]$ more salida.txt
09:30:46.284985 execve("/u01/app/oracle/product/10.1.0/db_1/bin/lsnrctl", ["lsnrctl", "start", "LISTENR"], [/* 29 vars */]) = 0
09:30:46.286140 uname({sys="Linux", node="oracle10g.inmotion.cl", ...}) = 0
09:30:46.286579 brk(0) = 0x928d000

Si se quiere saber en microsegundos la duración de cada proceso interno ejecutado por el strace (según el comando ingresado)
Eje:

[oracle@oracle10g oracle]$ strace -tt -T -o salida.txt lsnrctl start LISTENR

09:31:36.680126 execve("/u01/app/oracle/product/10.1.0/db_1/bin/lsnrctl", ["lsnrctl", "start", "LISTENR"], [/* 29 vars */]) = 0 <0.000425>
09:31:36.681208 uname({sys="Linux", node="oracle10g.inmotion.cl", ...}) = 0 <0.000073>
09:31:36.681608 brk(0) = 0x9b6e000 <0.000072>

Incluso se puede fitrar por tipo de ejecución del comando ejecutado por el strace
Eje:

Para saber sólo los comandos asociados a la red
strace -tt -T -e trace=network -o salida.txt lsnrctl start LISTENR

Para saber sólo los comando ejecutados, pero que reciban como parámetro un archivo
Eje:

strace -tt -T -e trace=file -o salida.txt lsnrctl start LISTENR

Incluso se le puede indicar algún PID de sistema operativo que ya se encuentre en ejecución
Eje:

strace -tt -T -p 18909 -o salida.txt lsnrctl start LISTENR

Espero les sirva

[oracle@oracle11gnodo1 instaladores]$ cd deinstall/
[oracle@oracle11gnodo1 deinstall]$ ls -ltr
total 216
-r-xr-xr-x 1 oracle oinstall 31544 Apr 1 01:24 sshUserSetup.sh
-r--r--r-- 1 oracle oinstall 3154 Jul 13 08:01 deinstall.xml
-r-xr-xr-x 1 oracle oinstall 20670 Jul 13 08:26 deinstall
-rw-r--r-- 1 oracle oinstall 382 Aug 4 18:16 readme.txt
drwxr-xr-x 7 oracle oinstall 4096 Aug 13 05:46 jre
drwxr-xr-x 2 oracle oinstall 4096 Aug 14 01:35 utl
drwxr-xr-x 2 oracle oinstall 4096 Aug 14 01:35 response
drwxr-xr-x 2 oracle oinstall 4096 Aug 14 01:35 logs
drwxr-xr-x 2 oracle oinstall 4096 Aug 14 01:50 mapfiles
drwxrwxr-x 4 oracle oinstall 4096 Aug 14 01:53 sysman
drwxrwxr-x 3 oracle oinstall 4096 Aug 14 01:53 srvm
drwxrwxr-x 8 oracle oinstall 4096 Aug 14 01:53 perl
drwxrwxr-x 7 oracle oinstall 4096 Aug 14 01:53 oui
drwxr-xr-x 3 oracle oinstall 4096 Aug 14 01:53 lib
drwxr-xr-x 2 oracle oinstall 4096 Aug 14 01:53 jlib
drwxrwxr-x 3 oracle oinstall 4096 Aug 14 01:53 diagnostics
drwxrwxr-x 2 oracle oinstall 4096 Aug 14 01:53 dc_ocm
drwxrwxr-x 3 oracle oinstall 4096 Aug 14 01:53 cv
drwxrwxr-x 3 oracle oinstall 4096 Aug 14 01:53 crs
drwxrwxr-x 2 oracle oinstall 4096 Aug 14 01:53 bin
drwxrwxr-x 4 oracle oinstall 4096 Aug 14 01:53 assistants

[oracle@oracle11gnodo1 deinstall]$ ./deinstall -home /u01/app/11.2.0/grid

ORACLE_HOME = /u01/app/11.2.0/grid
Location of logs /home/oracle/oraInventory/logs/

############ ORACLE DEINSTALL & DECONFIG TOOL START ############

######################## CHECK OPERATION START ########################
Install check configuration START

Checking for existence of the Oracle home location /u01/app/11.2.0/grid
Oracle Home type selected for de-install is: CRS
Oracle Base selected for de-install is: /u01/app/oracle
Checking for existence of central inventory location /home/oracle/oraInventory
Checking for existence of the Oracle Grid Infrastructure home /u01/app/11.2.0/grid
The following nodes are part of this cluster: oracle11gnodo1,oracle11gnodo2

Install check configuration END

Traces log file: /home/oracle/oraInventory/logs//crsdc.log

- Ahora comienza la serie de preguntitas, relacionadas con las IP Virtuales, físicas y el formato de la máscara.

Enter an address or the name of the virtual IP used on node "oracle11gnodo1"[oracle11gnodo1-vip]

The following information can be collected by running ifconfig -a on node "oracle11gnodo1"
Enter the IP netmask of Virtual IP "192.168.239.131" on node "oracle11gnodo1"[255.255.255.0]
192.168.239.129

Enter the network interface name on which the virtual IP address "192.168.239.131" is active
eth0

Enter an address or the name of the virtual IP used on node "oracle11gnodo2"[oracle11gnodo2-vip]

The following information can be collected by running ifconfig -a on node "oracle11gnodo2"
Enter the IP netmask of Virtual IP "192.168.239.132" on node "oracle11gnodo2"[192.168.239.129]
192.168.239.130

Enter the network interface name on which the virtual IP address "192.168.239.132" is active[eth0]

Enter an address or the name of the virtual IP[]
192.168.239.131

The following information can be collected by running ifconfig -a on node "oracle11gnodo1"
Enter the IP netmask of the virtual IP "192.168.239.131"[]
255.255.255.0

Enter the network interface name on which the virtual IP address "192.168.239.131" is active
eth0

Enter an address or the name of the virtual IP[]
192.168.239.131

The following information can be collected by running ifconfig -a on node "oracle11gnodo1"
Enter the IP netmask of the virtual IP "192.168.239.131"[255.255.255.0]

Enter the network interface name on which the virtual IP address "192.168.239.131" is active[eth0]

Enter an address or the name of the virtual IP

- Una vez ingresados todos los datos, comienza realmente la desinstalación

Network Configuration check config START

Network de-configuration trace file location: /home/oracle/oraInventory/logs/netdc_check32554.log

Network Configuration check config END

Asm Check Configuration START

ASM de-configuration trace file location: /home/oracle/oraInventory/logs/asmcadc_check32555.log

ASM configuration was not detected in this Oracle home. Was ASM configured in this Oracle home (y|n) [n]: y
Specify the ASM Diagnostic Destination [ ]:
Specify the diskgroups that are managed by this ASM instance []: DATA1

De-configuring ASM will drop all the diskgroups at cleanup time. Do you want deconfig tool to drop the diskgroups y|n [y]:

######################### CHECK OPERATION END #########################

####################### CHECK OPERATION SUMMARY #######################
Oracle Grid Infrastructure Home is: /u01/app/11.2.0/grid
The cluster node(s) on which the Oracle home exists are: (Please input nodes seperated by ",", eg: node1,node2,...)oracle11gnodo1,oracle11gnodo2
Oracle Home selected for de-install is: /u01/app/11.2.0/grid
Inventory Location where the Oracle home registered is: /home/oracle/oraInventory
ASM instance will be de-configured from this Oracle home
Do you want to continue (y - yes, n - no)? [n]: y
A log of this session will be written to: '/home/oracle/oraInventory/logs/deinstall_deconfig2009-09-21_02-57-31-PM.out'
Any error messages from this session will be written to: '/home/oracle/oraInventory/logs/deinstall_deconfig2009-09-21_02-57-31-PM.err'

######################## CLEAN OPERATION START ########################
ASM de-configuration trace file location: /home/oracle/oraInventory/logs/asmcadc_clean32556.log
ASM Clean Configuration START
ASM Clean Configuration END

Network Configuration clean config START

Network de-configuration trace file location: /home/oracle/oraInventory/logs/netdc_clean32557.log

De-configuring Naming Methods configuration file on all nodes...
Naming Methods configuration file de-configured successfully.

De-configuring Local Net Service Names configuration file on all nodes...
Local Net Service Names configuration file de-configured successfully.

De-configuring Directory Usage configuration file on all nodes...
Directory Usage configuration file de-configured successfully.

De-configuring backup files on all nodes...
Backup files de-configured successfully.

The network configuration has been cleaned up successfully.

Network Configuration clean config END

- Una vez pasado lo anterior, indica que debemos ejecutar ciertos comandos con root en cada uno de los nodos.

---------------------------------------->

Run the following command as the root user or the administrator on node "oracle11gnodo2".

/home/oracle/instaladores/deinstall/perl/bin/perl -I/home/oracle/instaladores/deinstall/perl/lib -I/home/oracle/instaladores/deinstall/crs/install /home/oracle/instaladores/deinstall/crs/install/rootcrs.pl -force -delete -paramfile /home/oracle/instaladores/deinstall/response/deinstall_Ora11g_gridinfrahome2.rsp

Run the following command as the root user or the administrator on node "oracle11gnodo1".

/home/oracle/instaladores/deinstall/perl/bin/perl -I/home/oracle/instaladores/deinstall/perl/lib -I/home/oracle/instaladores/deinstall/crs/install /home/oracle/instaladores/deinstall/crs/install/rootcrs.pl -force -delete -paramfile /home/oracle/instaladores/deinstall/response/deinstall_Ora11g_gridinfrahome2.rsp -lastnode

- Ejecutamos esos comandos en cada uno de los nodos del RAC con usuario root, y el desinstalador simplemente remueve y aquellos procesos que no puede eliminar, los deja para el reboteo.

[oracle@oracle11gnodo2 ~]$ su - root
Password:
[root@oracle11gnodo2 ~]# /home/oracle/instaladores/deinstall/perl/bin/perl -I/home/oracle/instaladores/deinstall/perl/lib -I/home/oracle/instaladores/deinstall/crs/install /home/oracle/instaladores/deinstall/crs/install/rootcrs.pl -force -delete -paramfile /home/oracle/instaladores/deinstall/response/deinstall_Ora11g_gridinfrahome2.rsp
2009-09-21 15:05:48: Parsing the host name
2009-09-21 15:05:48: Checking for super user privileges
2009-09-21 15:05:48: User has super user privileges
Using configuration parameter file: /home/oracle/instaladores/deinstall/response/deinstall_Ora11g_gridinfrahome2.rsp
PRCR-1035 : Failed to look up CRS resource ora.cluster_vip.type for 1
PRCR-1068 : Failed to query resources
Cannot communicate with crsd
PRCR-1070 : Failed to check if resource ora.gsd is registered
Cannot communicate with crsd
PRCR-1070 : Failed to check if resource ora.ons is registered
Cannot communicate with crsd
PRCR-1070 : Failed to check if resource ora.eons is registered
Cannot communicate with crsd

ADVM/ACFS is not supported on Redhat 4
ACFS-9201: Not Supported
CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on 'oracle11gnodo2'
CRS-2673: Attempting to stop 'ora.crsd' on 'oracle11gnodo2'
CRS-4548: Unable to connect to CRSD
CRS-2675: Stop of 'ora.crsd' on 'oracle11gnodo2' failed
CRS-2679: Attempting to clean 'ora.crsd' on 'oracle11gnodo2'
CRS-4548: Unable to connect to CRSD
CRS-2678: 'ora.crsd' on 'oracle11gnodo2' has experienced an unrecoverable failure
CRS-0267: Human intervention required to resume its availability.
CRS-2795: Shutdown of Oracle High Availability Services-managed resources on 'oracle11gnodo2' has failed
CRS-4687: Shutdown command has completed with error(s).
CRS-4000: Command Stop failed, or completed with errors.
You must kill crs processes or reboot the system to properly
cleanup the processes started by Oracle clusterware
error: package cvuqdisk is not installed
Successfully deconfigured Oracle clusterware stack on this node

[oracle@oracle11gnodo1 ~]$ su - root
Password:
[root@oracle11gnodo1 ~]# /home/oracle/instaladores/deinstall/perl/bin/perl -I/home/oracle/instaladores/deinstall/perl/lib -I/home/oracle/instaladores/deinstall/crs/install /home/oracle/instaladores/deinstall/crs/install/rootcrs.pl -force -delete -paramfile /home/oracle/instaladores/deinstall/response/deinstall_Ora11g_gridinfrahome2.rsp -lastnode
2009-09-21 15:07:52: Parsing the host name
2009-09-21 15:07:52: Checking for super user privileges
2009-09-21 15:07:52: User has super user privileges
Using configuration parameter file: /home/oracle/instaladores/deinstall/response/deinstall_Ora11g_gridinfrahome2.rsp

CRS-2672: Attempting to start 'ora.cssd' on 'oracle11gnodo1'
CRS-2676: Start of 'ora.cssd' on 'oracle11gnodo1' succeeded
CRS-2672: Attempting to start 'ora.ctssd' on 'oracle11gnodo1'
CRS-2676: Start of 'ora.ctssd' on 'oracle11gnodo1' succeeded
CRS-2679: Attempting to clean 'ora.asm' on 'oracle11gnodo1'
CRS-5011: Check of resource "+ASM" failed: details at "(:CLSN00006" in "/u01/app/11.2.0/grid/log/oracle11gnodo1/agent/ohasd/oraagent_oracle/oraagent_oracle.log"
ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist
Linux Error: 2: No such file or directory
Process ID: 0
Session ID: 0 Serial number: 0
CRS-5011: Check of resource "+ASM" failed: details at "(:CLSN00006" in "/u01/app/11.2.0/grid/log/oracle11gnodo1/agent/ohasd/oraagent_oracle/oraagent_oracle.log"
CRS-2681: Clean of 'ora.asm' on 'oracle11gnodo1' succeeded
CRS-2672: Attempting to start 'ora.asm' on 'oracle11gnodo1'
CRS-2676: Start of 'ora.asm' on 'oracle11gnodo1' succeeded
CRS-2673: Attempting to stop 'ora.cssdmonitor' on 'oracle11gnodo1'
CRS-2677: Stop of 'ora.cssdmonitor' on 'oracle11gnodo1' succeeded
CRS-2529: Unable to act on 'ora.cssd' because that would require stopping or relocating 'ora.asm', but the force option was not specified
CRS-4000: Command Stop failed, or completed with errors.
Command return code of 1 (256) from command: /u01/app/11.2.0/grid/bin/crsctl stop resource ora.cssd -init
PRCR-1068 : Failed to query resources
Cannot communicate with crsd
PRCR-1068 : Failed to query resources
Cannot communicate with crsd
PRCR-1068 : Failed to query resources
Cannot communicate with crsd
PRCR-1068 : Failed to query resources
Cannot communicate with crsd
PRCR-1035 : Failed to look up CRS resource ora.cluster_vip.type for 1
PRCR-1068 : Failed to query resources
Cannot communicate with crsd
PRCR-1070 : Failed to check if resource ora.gsd is registered
Cannot communicate with crsd
PRCR-1070 : Failed to check if resource ora.ons is registered
Cannot communicate with crsd
PRCR-1070 : Failed to check if resource ora.eons is registered
Cannot communicate with crsd

ADVM/ACFS is not supported on Redhat 4
ACFS-9201: Not Supported

CRS-2673: Attempting to stop 'ora.ctssd' on 'oracle11gnodo1'
CRS-2673: Attempting to stop 'ora.evmd' on 'oracle11gnodo1'
CRS-2673: Attempting to stop 'ora.asm' on 'oracle11gnodo1'
CRS-2677: Stop of 'ora.evmd' on 'oracle11gnodo1' succeeded
CRS-2677: Stop of 'ora.ctssd' on 'oracle11gnodo1' succeeded
CRS-2677: Stop of 'ora.asm' on 'oracle11gnodo1' succeeded
CRS-2673: Attempting to stop 'ora.cssd' on 'oracle11gnodo1'
CRS-2677: Stop of 'ora.cssd' on 'oracle11gnodo1' succeeded
CRS-2673: Attempting to stop 'ora.diskmon' on 'oracle11gnodo1'
CRS-2677: Stop of 'ora.diskmon' on 'oracle11gnodo1' succeeded
CRS-2672: Attempting to start 'ora.cssdmonitor' on 'oracle11gnodo1'
CRS-2676: Start of 'ora.cssdmonitor' on 'oracle11gnodo1' succeeded
CRS-2672: Attempting to start 'ora.cssd' on 'oracle11gnodo1'
CRS-2672: Attempting to start 'ora.diskmon' on 'oracle11gnodo1'
CRS-2676: Start of 'ora.diskmon' on 'oracle11gnodo1' succeeded
CRS-2676: Start of 'ora.cssd' on 'oracle11gnodo1' succeeded
This ASM diskgroup does not contain voting disks to be deleted
CRS-2672: Attempting to start 'ora.ctssd' on 'oracle11gnodo1'
CRS-2676: Start of 'ora.ctssd' on 'oracle11gnodo1' succeeded
CRS-2672: Attempting to start 'ora.asm' on 'oracle11gnodo1'
CRS-2676: Start of 'ora.asm' on 'oracle11gnodo1' succeeded
ASM de-configuration trace file location: /home/oracle/oraInventory/logs/asmcadc_clean2043844166297175867.log
ASM Clean Configuration START
ASM Clean Configuration END

ASM with SID +ASM1 deleted successfully. Check /home/oracle/oraInventory/logs/asmcadc_clean2043844166297175867.log for details.

CRS-2791: Starting shutdown of Oracle High Availability Services-managed resources on 'oracle11gnodo1'
CRS-2673: Attempting to stop 'ora.gpnpd' on 'oracle11gnodo1'
CRS-2673: Attempting to stop 'ora.cssdmonitor' on 'oracle11gnodo1'
CRS-2673: Attempting to stop 'ora.ctssd' on 'oracle11gnodo1'
CRS-2673: Attempting to stop 'ora.mdnsd' on 'oracle11gnodo1'
CRS-2677: Stop of 'ora.cssdmonitor' on 'oracle11gnodo1' succeeded
CRS-2677: Stop of 'ora.gpnpd' on 'oracle11gnodo1' succeeded
CRS-2677: Stop of 'ora.mdnsd' on 'oracle11gnodo1' succeeded
CRS-2677: Stop of 'ora.ctssd' on 'oracle11gnodo1' succeeded
CRS-2673: Attempting to stop 'ora.cssd' on 'oracle11gnodo1'
CRS-2677: Stop of 'ora.cssd' on 'oracle11gnodo1' succeeded
CRS-2673: Attempting to stop 'ora.diskmon' on 'oracle11gnodo1'
CRS-2673: Attempting to stop 'ora.gipcd' on 'oracle11gnodo1'
CRS-2677: Stop of 'ora.gipcd' on 'oracle11gnodo1' succeeded
CRS-2677: Stop of 'ora.diskmon' on 'oracle11gnodo1' succeeded
CRS-2793: Shutdown of Oracle High Availability Services-managed resources on 'oracle11gnodo1' has completed
CRS-4133: Oracle High Availability Services has been stopped.

error: package cvuqdisk is not installed
Successfully deconfigured Oracle clusterware stack on this node

- Una vez terminado lo anterior , procedemos a dar ENTER

Press Enter after you finish running the above commands

<----------------------------------------
Oracle Universal Installer clean START

Detach Oracle home '/u01/app/11.2.0/grid' from the central inventory on the local node : Done

Delete directory '/u01/app/11.2.0/grid' on the local node : Done

Delete directory '/u01/app/oracle' on the local node : Done

Detach Oracle home '/u01/app/11.2.0/grid' from the central inventory on the remote nodes 'oracle11gnodo2' : Done

Delete directory '/u01/app/11.2.0/grid' on the remote nodes 'oracle11gnodo2' : Done

Delete directory '/u01/app/oracle' on the remote nodes 'oracle11gnodo2' : Done

Oracle Universal Installer cleanup was successful.

Oracle Universal Installer clean END

Oracle install clean START

Clean install operation removing temporary directory '/tmp/install' on node 'oracle11gnodo1'
Clean install operation removing temporary directory '/tmp/install' on node 'oracle11gnodo2'

Oracle install clean END

Moved default properties file /home/oracle/instaladores/deinstall/response/deinstall_Ora11g_gridinfrahome2.rsp as /home/oracle/instaladores/deinstall/response/deinstall_Ora11g_gridinfrahome2.rsp3

######################### CLEAN OPERATION END #########################

- Y muestra en esta sección lo más importante, el resumen

####################### CLEAN OPERATION SUMMARY #######################
ASM instance was de-configured successfully from the Oracle home
Oracle Clusterware is stopped and successfully de-configured on node "oracle11gnodo2"
Oracle Clusterware is stopped and successfully de-configured on node "oracle11gnodo1"
Oracle Clusterware is stopped and de-configured successfully.
Successfully detached Oracle home '/u01/app/11.2.0/grid' from the central inventory on the local node.
Successfully deleted directory '/u01/app/11.2.0/grid' on the local node.
Successfully deleted directory '/u01/app/oracle' on the local node.
Successfully detached Oracle home '/u01/app/11.2.0/grid' from the central inventory on the remote nodes 'oracle11gnodo2'.
Successfully deleted directory '/u01/app/11.2.0/grid' on the remote nodes 'oracle11gnodo2'.
Successfully deleted directory '/u01/app/oracle' on the remote nodes 'oracle11gnodo2'.
Oracle Universal Installer cleanup was successful.

Oracle install successfully cleaned up the temporary directories.
#######################################################################

############# ORACLE DEINSTALL & DECONFIG TOOL END #############

La herramienta desinstala absolutamente todo, es bastante poderosa, no se cae, pero... en las pruebas efectuadas, se demora bastante.

Más información del deinstall AQUÍ

Espero les sirva

$srvctl stop database -d

ervicios completos del Clusterware

$crs_stop -all

Para posteriormente , reiniciar los nodos

#reboot

Cuando volvieron los servicios a la máquina y levanto el Clusterware, me encuentro con este panorama

[oracle@dtv-ora-02 ~]$ crs_stat -t
Name Type Target State Host

------------------------------------------------------------
ora....SM1.asm application ONLINE ONLINE dtv-ora-01
ora....01.lsnr application ONLINE ONLINE dtv-ora-01
ora....-01.gsd application ONLINE ONLINE dtv-ora-01
ora....-01.ons application ONLINE ONLINE dtv-ora-01
ora....-01.vip application ONLINE ONLINE dtv-ora-01
ora....SM2.asm application ONLINE ONLINE dtv-ora-02
ora....02.lsnr application ONLINE ONLINE dtv-ora-02
ora....-02.gsd application ONLINE ONLINE dtv-ora-02
ora....-02.ons application ONLINE ONLINE dtv-ora-02
ora....-02.vip application ONLINE ONLINE dtv-ora-02
ora.ibs.db application ONLINE OFFLINE
ora....s1.inst application ONLINE OFFLINE
ora....s2.inst application ONLINE OFFLINE

Mmmm , malo muy malo.. no levanta mi base de datos , pensé que era problema del ASM , pero este se encontraba arriba (eso creí en un instante)

Procedí a levantar la base de datos a mano, tampoco levantaba pues no estaba el Diskgroup DATA, ingrese a ASM y monte el Diskgroup y apareció este error..

SQL> alter diskgroup DATA mount;
alter diskgroup DATA mount
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15040: diskgroup is incomplete
ORA-15042: ASM disk "3" is missing

SQL>

, el tema se estaba complicando, pero siempre esta Metalink, Soporte Oracle y claro , mucha lectura, por eso he aquí la solución al inconveniente y claro las validaciones que se llevaron a cabo, que todos debiesen tener en cuenta cuando se trabaje con ASM

Catálogo de validaciones

a) Verificar las particiones físicas en cada uno de los nodos, debiesen estar todas y no presentar GAPs

$more /proc/partitions

b) Si estamos usando ASMLib, obtener un listado de los discos involucrados y consultarlos contra ASMLib

Una forma automática

#for i in `cd /dev/oracleasm/disks;ls *`;
do
/etc/init.d/oracleasm querydisk $i 2>/dev/null
done

Una forma manual

$ su - root
Password:
# cd /etc/init.d/
# ./oracleasm listdisks
VOL1
VOL2
VOL3
VOL4
# ./oracleasm querydisk VOL1
Disk "VOL1" is a valid ASM disk
# ./oracleasm querydisk VOL2
Disk "VOL2" is a valid ASM disk
# ./oracleasm querydisk VOL3
Disk "VOL3" is a valid ASM disk
# ./oracleasm querydisk VOL4
Disk "VOL4" is a valid ASM disk
# ./oracleasm scandisks
Scanning the system for Oracle ASMLib disks: [ OK ]
#

c) Verificar las particiones desde ambos nodos

#fdisk -l

d) Verificar en ambos nodos como fueron configurados los Raw Devices

# cat /etc/sysconfig/rawdevices
/dev/raw/raw1 /dev/sdc1
/dev/raw/raw2 /dev/sde1
/dev/raw/raw3 /dev/sdg1
/dev/raw/raw4 /dev/sdi1
/dev/raw/raw5 /dev/sdk1
/dev/raw/raw6 /dev/sdm1
/dev/raw/raw7 /dev/sdo1
/dev/raw/raw8 /dev/sdq1
/dev/raw/raw9 /dev/sds1
[root@dtv-ora-01 etc]#

e) Validar los privilegios y owner, sobre los Raw Devices generados, debiese tener acceso total el usuario Oracle, y claro... ser dueño de ellos
En ambos nodos , se debiese visualizar algo así
In node1

# ls -ltr /dev/raw/raw*
crwxrwxrwx 1 oracle oinstall 162, 1 Sep 11 16:46 /dev/raw/raw1
crwxrwxrwx 1 oracle oinstall 162, 2 Sep 11 16:46 /dev/raw/raw2
crwxrwxrwx 1 oracle oinstall 162, 3 Sep 11 16:46 /dev/raw/raw3
crwxrwxrwx 1 oracle oinstall 162, 4 Sep 11 16:46 /dev/raw/raw4
crwxrwxrwx 1 oracle oinstall 162, 5 Sep 11 16:46 /dev/raw/raw5
crwxrwxrwx 1 oracle oinstall 162, 7 Sep 11 16:46 /dev/raw/raw7
crwxrwxrwx 1 oracle oinstall 162, 6 Sep 11 16:46 /dev/raw/raw6
crwxrwxrwx 1 oracle oinstall 162, 8 Sep 11 16:46 /dev/raw/raw8
crwxrwxrwx 1 oracle oinstall 162, 9 Sep 11 16:46 /dev/raw/raw9

No con tantos privilegios, basta un 660

f)Obtener información formateada de mis instancias ASM y sobre sus diskgroups, para ello se siguió la nota
Note.470211.1 How To Gather/Backup ASM Metadata In A Formatted Manner

Lo anterior entrega el estado de los ASM Disk del Diskgroup

Primer dato a tener en cuenta ¿Por qué aparece el disco como PROVISIONED, siendo que forma parte del DiskGroup? ¿Se perdió la cabecera del archivo?

Ya tenemos la metadata, donde el HEADER_STATUS del ASM Disk indica que esta PROVISIONED, para cercionarnos, vemos la información de la cabecera del archivo raw, para así compararlo con la Metadata.

g)Obtención de información de la cabecera del Raw devices con el utilitario kfed (Utilitario interno de Oracle)

Para versiones 10.2.0.X hacía arriba, se debe ejecutar lo siguiente :

Cambiar de directorio donde se encuentra el kfed

cd $ORACLE_HOME/rdbms/lib

Generar el ejecutable kfed

$make -f ins_rdbms.mk ikfed (Ojo!!!, se escribe ikfed)

Verificar que se haya generado el kfed

$ls -ltr $ORACLE_HOME/bin/kfed

Finalmente , procedemos a leer la cabecera del Raw Devices

$ORACLE_HOME/bin/kfed read /dev/raw/raw6

Y eso , nos proporciona una salida similar a esta

[oracle@bin]$ kfed read /dev/raw/raw6
kfbh.endian: 1 ; 0x000: 0x01
kfbh.hard: 130 ; 0x001: 0x82
kfbh.type: 1 ; 0x002: KFBTYP_DISKHEAD
kfbh.datfmt: 1 ; 0x003: 0x01
kfbh.block.blk: 0 ; 0x004: T=0 NUMB=0x0
kfbh.block.obj: 2147483651 ; 0x008: TYPE=0x8 NUMB=0x3
kfbh.check: 2004180404 ; 0x00c: 0x77755db4
kfbh.fcn.base: 0 ; 0x010: 0x00000000
kfbh.fcn.wrap: 0 ; 0x014: 0x00000000
kfbh.spare1: 0 ; 0x018: 0x00000000
kfbh.spare2: 0 ; 0x01c: 0x00000000
kfdhdb.driver.provstr: ORCLDISKVOL4 ; 0x000: length=12
kfdhdb.driver.reserved[0]: 877416278 ; 0x008: 0x344c4f56
kfdhdb.driver.reserved[1]: 0 ; 0x00c: 0x00000000
kfdhdb.driver.reserved[2]: 0 ; 0x010: 0x00000000
kfdhdb.driver.reserved[3]: 0 ; 0x014: 0x00000000
kfdhdb.driver.reserved[4]: 0 ; 0x018: 0x00000000
kfdhdb.driver.reserved[5]: 0 ; 0x01c: 0x00000000
kfdhdb.compat: 168820736 ; 0x020: 0x0a100000
kfdhdb.dsknum: 3 ; 0x024: 0x0003
kfdhdb.grptyp: 1 ; 0x026: KFDGTP_EXTERNAL
kfdhdb.hdrsts: 3 ; 0x027: KFDHDR_MEMBER
kfdhdb.dskname: DATA_0003 ; 0x028: length=9
kfdhdb.grpname: DATA ; 0x048: length=4
kfdhdb.fgname: DATA_0003 ; 0x068: length=9
kfdhdb.capname: ; 0x088: length=0
kfdhdb.crestmp.hi: 32924622 ; 0x0a8: HOUR=0xe DAYS=0x1e MNTH=0x8 YEAR=0x7d9
kfdhdb.crestmp.lo: 987539456 ; 0x0ac: USEC=0x0 MSEC=0x32a SECS=0x2d MINS=0xe
kfdhdb.mntstmp.hi: 32924626 ; 0x0b0: HOUR=0x12 DAYS=0x1e MNTH=0x8 YEAR=0x7d9
kfdhdb.mntstmp.lo: 2526926848 ; 0x0b4: USEC=0x0 MSEC=0x376 SECS=0x29 MINS=0x25
kfdhdb.secsize: 512 ; 0x0b8: 0x0200
kfdhdb.blksize: 4096 ; 0x0ba: 0x1000
kfdhdb.ausize: 1048576 ; 0x0bc: 0x00100000
kfdhdb.mfact: 113792 ; 0x0c0: 0x0001bc80
kfdhdb.dsksize: 51199 ; 0x0c4: 0x0000c7ff
kfdhdb.pmcnt: 2 ; 0x0c8: 0x00000002
kfdhdb.fstlocn: 1 ; 0x0cc: 0x00000001
kfdhdb.altlocn: 2 ; 0x0d0: 0x00000002
kfdhdb.f1b1locn: 0 ; 0x0d4: 0x00000000
kfdhdb.redomirrors[0]: 0 ; 0x0d8: 0x0000
kfdhdb.redomirrors[1]: 0 ; 0x0da: 0x0000
kfdhdb.redomirrors[2]: 0 ; 0x0dc: 0x0000
kfdhdb.redomirrors[3]: 0 ; 0x0de: 0x0000
kfdhdb.dbcompat: 168820736 ; 0x0e0: 0x0a100000
kfdhdb.grpstmp.hi: 32924622 ; 0x0e4: HOUR=0xe DAYS=0x1e MNTH=0x8 YEAR=0x7d9
kfdhdb.grpstmp.lo: 987471872 ; 0x0e8: USEC=0x0 MSEC=0x2e8 SECS=0x2d MINS=0xe
kfdhdb.ub4spare[0]: 0 ; 0x0ec: 0x00000000
kfdhdb.ub4spare[1]: 0 ; 0x0f0: 0x00000000
kfdhdb.ub4spare[2]: 0 ; 0x0f4: 0x00000000
kfdhdb.ub4spare[3]: 0 ; 0x0f8: 0x00000000
kfdhdb.ub4spare[4]: 0 ; 0x0fc: 0x00000000
kfdhdb.ub4spare[5]: 0 ; 0x100: 0x00000000
kfdhdb.ub4spare[6]: 0 ; 0x104: 0x00000000
kfdhdb.ub4spare[7]: 0 ; 0x108: 0x00000000
kfdhdb.ub4spare[8]: 0 ; 0x10c: 0x00000000
kfdhdb.ub4spare[9]: 0 ; 0x110: 0x00000000
kfdhdb.ub4spare[10]: 0 ; 0x114: 0x00000000
kfdhdb.ub4spare[11]: 0 ; 0x118: 0x00000000
kfdhdb.ub4spare[12]: 0 ; 0x11c: 0x00000000
kfdhdb.ub4spare[13]: 0 ; 0x120: 0x00000000
kfdhdb.ub4spare[14]: 0 ; 0x124: 0x00000000
kfdhdb.ub4spare[15]: 0 ; 0x128: 0x00000000
kfdhdb.ub4spare[16]: 0 ; 0x12c: 0x00000000
kfdhdb.ub4spare[17]: 0 ; 0x130: 0x00000000
kfdhdb.ub4spare[18]: 0 ; 0x134: 0x00000000
kfdhdb.ub4spare[19]: 0 ; 0x138: 0x00000000
kfdhdb.ub4spare[20]: 0 ; 0x13c: 0x00000000
kfdhdb.ub4spare[21]: 0 ; 0x140: 0x00000000
kfdhdb.ub4spare[22]: 0 ; 0x144: 0x00000000
kfdhdb.ub4spare[23]: 0 ; 0x148: 0x00000000
kfdhdb.ub4spare[24]: 0 ; 0x14c: 0x00000000
kfdhdb.ub4spare[25]: 0 ; 0x150: 0x00000000
kfdhdb.ub4spare[26]: 0 ; 0x154: 0x00000000
kfdhdb.ub4spare[27]: 0 ; 0x158: 0x00000000
kfdhdb.ub4spare[28]: 0 ; 0x15c: 0x00000000
kfdhdb.ub4spare[29]: 0 ; 0x160: 0x00000000
kfdhdb.ub4spare[30]: 0 ; 0x164: 0x00000000
kfdhdb.ub4spare[31]: 0 ; 0x168: 0x00000000
kfdhdb.ub4spare[32]: 0 ; 0x16c: 0x00000000
kfdhdb.ub4spare[33]: 0 ; 0x170: 0x00000000
kfdhdb.ub4spare[34]: 0 ; 0x174: 0x00000000
kfdhdb.ub4spare[35]: 0 ; 0x178: 0x00000000
kfdhdb.ub4spare[36]: 0 ; 0x17c: 0x00000000
kfdhdb.ub4spare[37]: 0 ; 0x180: 0x00000000
kfdhdb.ub4spare[38]: 0 ; 0x184: 0x00000000
kfdhdb.ub4spare[39]: 0 ; 0x188: 0x00000000
kfdhdb.ub4spare[40]: 0 ; 0x18c: 0x00000000
kfdhdb.ub4spare[41]: 0 ; 0x190: 0x00000000
kfdhdb.ub4spare[42]: 0 ; 0x194: 0x00000000
kfdhdb.ub4spare[43]: 0 ; 0x198: 0x00000000
kfdhdb.ub4spare[44]: 0 ; 0x19c: 0x00000000
kfdhdb.ub4spare[45]: 0 ; 0x1a0: 0x00000000
kfdhdb.ub4spare[46]: 0 ; 0x1a4: 0x00000000
kfdhdb.ub4spare[47]: 0 ; 0x1a8: 0x00000000
kfdhdb.ub4spare[48]: 0 ; 0x1ac: 0x00000000
kfdhdb.ub4spare[49]: 0 ; 0x1b0: 0x00000000
kfdhdb.ub4spare[50]: 0 ; 0x1b4: 0x00000000
kfdhdb.ub4spare[51]: 0 ; 0x1b8: 0x00000000
kfdhdb.ub4spare[52]: 0 ; 0x1bc: 0x00000000
kfdhdb.ub4spare[53]: 0 ; 0x1c0: 0x00000000
kfdhdb.ub4spare[54]: 0 ; 0x1c4: 0x00000000
kfdhdb.ub4spare[55]: 0 ; 0x1c8: 0x00000000
kfdhdb.ub4spare[56]: 0 ; 0x1cc: 0x00000000
kfdhdb.ub4spare[57]: 0 ; 0x1d0: 0x00000000
kfdhdb.acdb.aba.seq: 0 ; 0x1d4: 0x00000000
kfdhdb.acdb.aba.blk: 0 ; 0x1d8: 0x00000000
kfdhdb.acdb.ents: 0 ; 0x1dc: 0x0000
kfdhdb.acdb.ub2spare: 0 ; 0x1de: 0x0000

Problema
La base de datos no parte ya que la instancia ASM no puede montar uno de sus diskgroup, justamente el diskgroup que contiene el archivo de inicialización para la base de datos.

El problema radica en que la Metadata de ASM me indica que el disco esta como PROVISIONED, o sea, es candidato a formar parte de cualquier diskgroup , es como un disco nuevo, pero al volcar la cabecera del raw devices, nos damos cuenta que ya pertenece a un DiskGroup.

Solución
Hay que sacar la información de la cabecera del Raw Devices como texto, y este texto ingresarlo nuevamente al Raw Devices, para que recalcule la cabecera y con ello reescriba en el diccionario de datos de ASM.

Implementación
1) Generar un respaldo de la cabecera del Raw Devices que se muestra como PROVISIONED

$ dd if=/dev/raw/raw6 of=/tmp/raw6.dd bs=1M count=20

2) Hacer un vaciado de la cabecera del Raw Devices, pero en texto

$kfed read /dev/raw/raw6 text=raw6.txt

3) Tomar el archivo de texto y devolverlo al Raw Devices , parece un paso tonto y sin sentido, pero al realizarlo, se recalculan muchas cosas

$kfed merge /dev/raw/raw6 text=raw6.txt

4) Y si ahora se visualiza el V$ASM_DISK.HEADER_STATUS de ese Disk ASM, aparecerá como MEMBER, lo que indica que si está reconocido como miembro de un DiskGroup

sql> select path,header_status from v$asm_disk;

¿Y ahora? , pues sólo queda levantar la instancia ASM, levantar la base de datos y quedar como REY...

Espero les sirva ....

SQL> CREATE OR REPLACE DIRECTORY dir_externos as '/home/oracle/externo';

2) Otorgo grant de lectura y escritura (el caso sólo es pedagógico, nunca debiesen darle privilegios a PUBLIC)

SQL> grant read , write on directory dir_externos to public;

Grant succeeded.

3) Creo una tabla externa común y silvestre

SQL> create table externos1 (
2 campo1 number(10) ,
3 campo2 varchar2(10)
4 )
5 organization external
6 (
7 type oracle_loader
8 default directory dir_externos
9 ACCESS PARAMETERS
10 (
11 records delimited by newline
12 badfile dir_externos:'externos.bad'
13 logfile dir_externos:'externos.log'
14 fields terminated by ','
15 (campo1,campo2)
16 )
17 LOCATION ('archivo_sin_comprimir.txt')
18 )
19 PARALLEL
20 REJECT LIMIT UNLIMITED;

Table created.

4) Consulto el archivo plano mediante sistema operativo

[oracle@oracle11g externo]$ more archivo_sin_comprimir.txt
1,A
2,3
10000,AAAAA
1202020,HHH1111

5) Consulto el archivo plano mediante la tabla externa

SQL> select * from externos1;

CAMPO1 CAMPO2
---------- ----------
1 A
2 3
10000 AAAAA
1202020 HHH1111

6) Comprimo el archivo plano que está en disco

[oracle@oracle11g externo]$ gzip archivo_sin_comprimir.txt
[oracle@oracle11g externo]$ ls -ltr
total 16
-rw-r--r-- 1 oracle oinstall 76 Sep 10 15:27 archivo_sin_comprimir.txt.gz

7) Creo otra tabla externa, pero esta vez apuntando al archivo plano comprimido

SQL> create table externos2 (
2 campo1 number(10) ,
3 campo2 varchar2(10)
)
4 5 organization external
6 (
type oracle_loader
7 8 default directory dir_externos
9 ACCESS PARAMETERS
10 (
11 records delimited by newline
12 badfile dir_externos:'externos2.bad'
13 logfile dir_externos:'externos2.log'
14 fields terminated by ','
15 (campo1,campo2)
16 )
17 LOCATION ('archivo_sin_comprimir.txt.gz')
18 )
19 PARALLEL
20 REJECT LIMIT UNLIMITED;

8) Y cuando consulto la tabla, no aparecen registros ¿por qué?

SQL> select * from externos2;

no rows selected

SQL>

9) Si busco el contenido del archivo de BAD del archivo plano, nos daremos cuenta que trato de leer un registro desde el archivo comprimido, pero no pudo pues no era el formato que se le había declarado al momento de crear la tabla externa

[oracle@oracle11g externo]$ more externos2.bad
#S©J
[oracle@oracle11g externo]$

10) Si vemos el log del proceso, claramente veremos el problema que hubo

[oracle@oracle11g externo]$ more externos2.log
LOG file opened at 09/10/09 15:28:29

Field Definitions for table EXTERNOS2
Record format DELIMITED BY NEWLINE
Data in file has same endianness as the platform
Rows with all null fields are accepted

Fields in Data Source:

CAMPO1 CHAR (255)
Terminated by ","
Trim whitespace same as SQL Loader
CAMPO2 CHAR (255)
Terminated by ","
Trim whitespace same as SQL Loader

LOG file opened at 09/10/09 15:28:30

Field Definitions for table EXTERNOS2
Record format DELIMITED BY NEWLINE
Data in file has same endianness as the platform
Rows with all null fields are accepted

Fields in Data Source:

CAMPO1 CHAR (255)
Terminated by ","
Trim whitespace same as SQL Loader
CAMPO2 CHAR (255)
Terminated by ","
Trim whitespace same as SQL Loader
error processing column CAMPO1 in row 1 for datafile /home/oracle/externo/archivo_sin_comprimir.txt.gz
ORA-01722: invalid number

11) Procedemos a crear otro directorio, este directorio es la ruta donde se encuentra el utilitario para descomprimir, que para nuestro caso es gunzip

SQL> CREATE OR REPLACE DIRECTORY exec_dir_externos as '/usr/bin/';
SQL> grant read , write on directory exec_dir_externos to public;

12)Procedemos a generar una tabla externa, pero con la claúsula PREPROCESSES , para que el archivo con extensión .gz sea descomprimido

create table externos_comprimidos (
campo1 number(10) ,
campo2 varchar2(10)
)
organization external
(
type oracle_loader
default directory dir_externos
ACCESS PARAMETERS
(
records delimited by newline
PREPROCESSOR exec_dir_externos:'gunzip'
badfile dir_externos:'externos2.bad'
logfile dir_externos:'externos2.log'
fields terminated by ','
(campo1,campo2)
)
LOCATION ('archivo_sin_comprimir.txt.gz')
)
PARALLEL
REJECT LIMIT UNLIMITED;

13) Consultamos la tabla externa recientemente creada y vemos como tenemos acceso al archivo plano aunque este comprimido

SQL> select * from externos_comprimidos;

CAMPO1 CAMPO2
---------- ----------
1 A
2 3
10000 AAAAA
1202020 HHH1111

14)No disponible para bases de datos con Oracle Database Vault instalado

SQL> r
1* select * from v$option where upper(parameter) like '%VAUL%' order by 1

PARAMETER VALUE
--------------------- ---------
Oracle Database Vault TRUE

SQL>

Referencias
Tablas externas en Oracle11gr2

Espero les sirva

declare
cursor c1 is select ...
begin
open c1
loop
exit when c1 not found
fetch c1 into variable
end loop;
end;

O podría ser con un FOR ... LOOP , pero en el fondo , debemos generar código sí o sí

Pues bien , Oracle11gr2 , nos soluciona ese inconveniente , ¿cómo?

Ha creado una gran claúsula llamada IGNORE_ROW_ON_DUPKEY_INDEX , que no es nada más que in hint , acá viene su uso...

1.- Creamos la tabla que contiene los datos originales y que contiene la PK

SQL> create table tabla1 (col1 number not null ,
2 col2 number not null ,
3 col3 date ,
4 constraint tabla1_pk primary key (col1));

2.- Insertamos datos sencillos dentro de la tabla, sin violar la PK

SQL> insert into tabla1 values (1,1,sysdate);

1 row created.

SQL> insert into tabla1 values (2,1,sysdate);

1 row created.

SQL> insert into tabla1 values (3,1,sysdate);

1 row created.

3. - Insertamos un valor con el format INSERT VALUES y veremos como se gatilla la Primary Key

SQL> insert into tabla1 values (1,0,sysdate);
insert into tabla1 values (1,0,sysdate)
*
ERROR at line 1:
ORA-00001: unique constraint (SYS.TABLA1_PK) violated

4.- Procedemos a insertar la misma fila, pero con el hint IGNORE_ROW_ON_DUPKEY_INDEX , y vemos el resultado , que no inserta la fila y no arroja error

SQL> insert /*+ ignore_row_on_dupkey_index (tabla1 (col1) ) */
2 into tabla1 values (1,0,sysdate);

0 rows created.

¿Qué sucede con el formato de inserción INSERT SELECT? , pues bien acá un ejemplo

5.- Vemos la tabla secundaria y los datos que contiene, los cuales no pueden ser insertados en su totalidad pues violan la PK

SQL> select * from valores_tmp;

CAMPO1 CAMPO2
---------- ----------
1 1
2 2
3 3
4 4
5 5
6 6
7 7
8 8

6 .- Procedemos a insertar sin ocupar el nuevo HINT y aparece el típico error de violación de PK

SQL> insert into tabla1 (select campo1 , campo2 , sysdate from valores_tmp);
insert into tabla1 (select campo1 , campo2 , sysdate from valores_tmp)
*
ERROR at line 1:
ORA-00001: unique constraint (SYS.TABLA1_PK) violated

7.- Y si consultamos los datos de nuestra tabla original, vemos que no han sido afectados

SQL> select * from tabla1;

COL1 COL2 COL3
---------- ---------- ---------
1 1 05-SEP-09
2 1 05-SEP-09
3 1 05-SEP-09

SQL>

8.- Ahora si insertamos los mismos datos, pero con la nueva claúsula , vemos como ocurre la magia, simplemente selecciona cuales insertar ... que bien

SQL> insert /*+ ignore_row_on_dupkey_index (tabla1 (col1) ) */
2 into tabla1 (select campo1 , campo2 , sysdate from valores_tmp);

5 rows created.

SQL>

9.- Validamos nuevamente nuestra tabla original y están los datos correctos, de ambas tablas

SQL> select * from tabla1;

COL1 COL2 COL3
---------- ---------- ---------
1 1 05-SEP-09
2 1 05-SEP-09
3 1 05-SEP-09
4 4 05-SEP-09
5 5 05-SEP-09
6 6 05-SEP-09
7 7 05-SEP-09
8 8 05-SEP-09

8 rows selected.

SQL>

Espero les sirva