Categories: Oracle 11g, Oracle11gR2

Oracle 11g : Exámen 1z0-054 Performance Tuning



Hola...

Me encuentro preparando un nuevo exámen de certificación , el código es el siguiente

1z0-054 : Oracle 11g Performance Tuning

El cual forma parte de la malla de certificación de Oracle11g



El detalle del exámen..



Así que cuando finalice, les cuento el puntaje obtenido (ojalá me vaya bien)


by Ligarius
10.05.10. 14:40:23. 54 words, 7245 views. Categories: Oracle 11g, Certificaciones ,

Oracle 11gr1 : Nuevas instrucciones para el utilitario ASMCMD (New features ASMCMD)



Bueno, como no hay primera sin segunda.... Como en una ronda de cervezas



Acá va la actualización para el utilitario ASMCMD que nació en 10gr1

Ahora , disponible el documento para Oracle 11gr1 , ¿adivinen cual viene después? :P

Para leer el documento haz click Acá

Y si quieres leer la genésis del utilitario ASMCMD , puedes buscar nuestro anterior Post

ASMCMD : Utilitario para trabajar con instancias ASM

Espero les sirva

by Ligarius
22.04.10. 16:01:26. 71 words, 6919 views. Categories: Oracle 11g, ASM (Automatic Storage Management) ,

Oracle 11gr2 : Problemas con ASM y Cluster Synchronization Service



En un ambiente con motor Oracle 11gr2 montado sobre uns instancia ASM versión 11gr2, que proviene de la instalación del Grid Infraestructure, ocurre un problema para levantar la instancia ASM, de hecho aparece el siguiente error

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]


by Ligarius
19.04.10. 14:20:24. 1176 words, 23013 views. Categories: Base de datos, Oracle11gR2, ASM (Automatic Storage Management) ,

Oracle 11gr2 : Aplicando nuestro primer PSU ABRIL 2010



Oracle lanzó el día de ayer , 13 de Abril su CPU correspondiente a Abril 2010 , en el vienen los típicos CPU, pero viene una cosa en especial que es un PSU para Oracle 11gr2

La información la puedes ver AQUÍ





En este CPU , viene para la 11gr2 (11.2.0.1) un CPU y un PSU , los 2 arreglan los mismos inconvenientes y esto viene consignado en cada uno de los README








Antes de comenzar con la instalación , debemos cerciorarnos que en nuestra variable de medio ambiente PATH ,tenemos acceso a los utilitarios make , ar , ld y nm

Por ejemplo, una forma de buscarlo es con el comando which

[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

by Ligarius
14.04.10. 15:13:25. 1548 words, 8256 views. Categories: Base de datos, Instalación, Oracle11gR2 ,

Oracle 11gr1 : Índices INVISIBLES (INVISIBLE INDEX)



A partir de Oracle11g nace una nueva característica que se llama índices INVISIBLES



¿Cuál es la gracia principal? Es que puedo deshabilitar los índices, sin necesidad de dejaros UNUSABLES y sin la necesidad de borrarlos, lo cual
implica que se pueden habilitar y deshabilitar de forma muy rápida.

En el fondo dejar un índice como INVISIBLE , es dejarlo fuera del alcance del optimizador cuando esta generando los planes de ejecución

Sólo imaginenlo para un índice de 10GB ¿lo borrarían para saber com oanda su aplicación? , creo que no... pues bien un índice INVISIBLE es la solución a la problemática.

Una de las principales ventajas de los índices invisibles sobre los índices no USABLES , es que los índices INVISIBLES si están afectados por las DML que se le pueda hacer a su tabla de orígen , o sea, mientras estén INVISIBLES, siguen actualizandose ... genial!!

Un ejemplo práctico

1.- Se genera una estructura de tabla con su clave primaria

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

by Ligarius
13.04.10. 15:02:29. 713 words, 9494 views. Categories: Base de datos, Oracle 11g, Tuning / Performance ,

<< 1 2 3 4 5 6 7 8 9 10 >>