El coste de tener sistemas con alta disponibilidad en Oracle(english)

[quote]What's the cost of downtime to your business? $100,000 per hour, $1,000,000 or more? The recent volcanic ash that has grounded European flights is estimated to be costing the airlines $200M a day. In the IT world, High Availability (HA) architectures allow for disaster recovery as well as uninterrupted business continuity during system failure...[/quote]

http://bigdatamatters.com/bigdatamatters/2010/04/high-availability-with…

Oracle10g: Cambiar el juego de carácteres de la base de datos

Puede suceder que después de instalar Oracle o configurar una nueva base de datos nos demos cuenta de que el juego de carácteres elegido durante la instalación no es el correcto. Lo que se nos puede ocurrir en casos como este es borrar la base de datos y reconfigurarla o cosas peores... Pero no hace falta. Podemos cambiar el juego de carácteres parando la base de datos, levantandola de forma restrictiva, cambiando la configuración y reiniciado la base de datos. Howto...

 

 

Oracle 10g: OPEN_CURSORS y SHARED_OPEN_CURSORS

Pasos que sigue Oracle para procesar una consulta:

1) Validación Sintáctica
2) Validación Semántica
3) Optimización
4) Generación del QEP (Query Execution Plan)
5) Ejecución del QEP (Query Execution Plan)

En algunos entornos nos podemos encontrar con aplicaciones que realizan ciertas consultas (y digo consultas) de forma muy reetiva de forma continua. Cuando el catálogo es muy amplio, continuo e inevitable debemos tener en cuenta dos parámetros de inicialización de la base de datos: open_cursors y session_cached_cursors.

Open_cursors nos permite establecer el límite de cursores por sesión y su seteo es muy directo. Si se necesitan 1000 y no hay nada que optimizar pues 1000 pondremos. En cambio Session_cached_cursors es algo más complejo y requiere analizarse en base al número máximo de cursores (open_cursors) y la cantidad actual de cursores que se mantienen en "cache" actualmente.

Consulta:

ORA-01555 Snapshot too old

ORA-01555 Snapshot too old

La base de datos de una compañia normalmente tiene que aguantar algunas transacciones largas y pesadas. Si la base de datos es Oracle, está recien instalada y poco manipulada esas transacciones y sus primeras ejecuciones tienen pocas probabilidades de éxito. Es entonces cuando acaba apareciendo el fatídico ORA-01555, alias "... snapshot to old".

La gestión de consultas largas en Oracle viene limitada por el tamaño del tablespace de deshacer (undotbs). A mayor tamaño sera posible gestionar las transacciones más largas y pesadas. En Oracle 10g recien instalado el tamaño de este tablespace se reducido y uno no se suele dar cuenta hasta que falla la cosa.

Si la versión es la 10 se puede modificar directamente desde Oracle Enterprise Manager (consola web) en el apartado de administración, "Gestión de Deshacer". Allí tenemos el tiempo de retención, el tamaño del tablespace y podemos usar también el asesor para ver el tiempo de retención posible en base al tamaño en mb del tablespace.

Algo así:

Seguridad en Oracle

En éste post os adjunto varios documentos PDF relacionados con la seguridad y administración de Oracle. Por una parte, sabiendo que incluso el sistema de contraseñas en Oracle 11g es débil, os linko un documento PDF publicado por NGSSoftware y que trata de ayudar a proteger Oracle bajo los ataques de fuerza bruta contra las contraseñas y además donde presenta la herramienta de fuerza bruta: OraBrute.

Por otra parte os linko otro documento PDF dónde explica cómo proteger Oracle en tan sólo 20 minutos que, aunque no es un sistema para proteger completamente la base de datos, sirve como mínimo para tapar aquellos agujeros más evidentes...