Oracle 11gr2 : Ya no mas soporte de Raw Devices (De-support Raw Devices) ¿o desde Oracle 11gr3?

Hola...

Hace un tiempo escribí una nota sobre Oracle 12g , la cual decía que ya no iba a haber soporte para Raw Devices desde Oracle 12g (en realidad se llama Oracle 11gr2) , para datafiles, archivos OCR , Voting Disk, redologs, controlfiles, etc.

Esto es bastante fuerte!! , ¿el porqué? pues implicará que desde Oracle 11gr2 en adelante la única forma de configurar RAC será bajo una arquitectura de Cluster File System , por ejemplo OCFS (Linux) , HACMP o GPFS (AIX) , etc.. O simplemente generando Diskgroups para los OCR y VOTING DISK

Lo bueno de todo lo anterior es que "se dice" que Oracle 11gr2 y especificamente ASM , soportarán distintos tipos de archivos, desde OCR , Voting Disk, hasta datafiles, controlfiles, etc,etc.. Imaginense el impacto, desde Oracle 11gr2 en adelante , todo, absolutamente todo podrá ser puesto en una arquitectura de ASM, lo que por el momento no está permitido... Se vienen fuertes cambios!!

Tan fuertes son los cambios, que la nota de Metalink (578455.1) que hablaba sobre lo que no estará soportado desde Oracle 11gr2 fue sacada del aire, ¿habrá causado mucho impacto? , ¿no habrá sido analizada a cabalidad? o simplemente ¿fue un pequeño fuego artificial?

Lo anterior responde a que no es desde Oracle 12g que se desoportará Raw Devices, es desde la versión mayor a 11gr2 de Oracle desde donde no se soportará Raw Devices, en una primera instancia, el utilitario DBCA no podrá ver este tipo de dispositivos. En Oracle 12g, definitivamente ya no mas Raw Devices.

De hecho , ahora hay una nota que habla un poquito al respecto

Nota 754305.1

Ahora si que se viene bueno... :>>

by Ligarius
18.05.09. 09:18:31. 268 words, 15679 views. Categories: Base de datos ,

Oracle 11g : SMCO Space Management Coordinator (Nuevo proceso background)



Oracle 11g : Space Management Coordinator

Este nuevo proceso background es el encargado de coordinar varias tareas asociadas al manejo del espacio en Oracle 11g



Por ejemplo , una de las tareas más efectivas en cuanto a la performance es evitar el crecimiento dinámico de los datafiles, eso que tanto daño hace a los tiempos de respuesta de las aplicaciones ¿Porqué?, sencillamente pues mientras un proceso que está ejecutando DML masivo hace que los datafiles lleguen al 100% de uso, habrá otro proceso que está asignando el espacio que necesitan esas DML, por ende ,habrán esperas a que los procesos internos de Oracle dispongan de espacio.

De hecho siempre nos dicen que debemos mantener nuestros tablespaces con un 10% o 15% de espacio libre (no sólo para ambientes transacionales ino que batch también), para evitar eso (el crecimiento dinámico) pues... desde ahora en adelante eso lo hará un proceso background llamado SPACE MANAGEMENT COORDINATOR (SMCO) , esta actividad la realiza mediante sus esclavos (parece cuento egipcio), y estos esclavos llamados Wnnn serán los que lleven a cabo la tarea indicada por el SMCO

En Oracle11g , este proceso background autoextiende los datafiles (de forma automática), para ello los datafiles deben estar con AUTOEXTEND en ON , el SMCO decide autoextender los datafiles, pero.. de acuerdo a su historial de crecimiento, cada vez que SMCO autoextiende los datafiles de un tablespace , lo hace siempre de forma pareja en todos los archivos del tablespace.

Este proceso background se gatilla cada una hora. De hecho se puede verificar que este presente , mediante un comando tail al archivo de alertas



O un comando ps -afe para analizarlo como Proceso Background



A parte de las tarea de asignar mas tamaño de forma dinámica a los tablespaces , este proceso background también efectúa las siguientes acciones :

- Administración de tamaño para los Securefile Log Segments
- Recuperación de tamaño de los tablespaces temporales (nueva característica de Oracle11g)

¿Con esto nos iremos despidiendo de los DBO?

Notas de redeferencia

Se actualizan los links (06 NOV 2015)
Note : 444149.1 : New Background Processes In 11g

Note : 743773.1 : Smco (Space Management Coordinator) And Autoextend On Datafiles

Espero sea de utilidad

by Ligarius
01.06.09. 17:11:49. 367 words, 6469 views. Categories: Base de datos, Oracle 11g, Oracle 10g, Tuning / Performance ,

A jugar , a jugar!!!! con Oracle Game (DB Quest)

Oracle ha lanzado hace un tiempo , una campaña para que los DBAs jueguen |-|

Así como lo oyes, para que los DBAs jueguen , es simplemente nu juego donde eliges posibilidades a una pregunta y te van dando puntajes, en el fondo, se elige al DBA más rápido del mundo, y con los mejores aciertos, obviamente eso no implica que trabajes bien, pero le da un pequeño toque al esforzado DBA B)

Presentaciones en OTN de este "jueguito"

La URL a la cual se debe realizar la conexión

http://db-quest.com/

Aparecerá esta pantalla de forma inicial

Nos harán preguntas y acumularemos puntaje

Y claro... no nos queda mas que jugar

Al final, el premio (pobre y simbólico) , aparecer como el DBA con el más alto puntaje

Así que a jugar!!!!! bueno... en horario no laboral :>>

by Ligarius
11.05.09. 21:09:50. 143 words, 4081 views. Categories: Base de datos, Cosas varias ,

Enterprise Manager Grid Control : Instalando un agente paso a paso (Install agent Grid Control Step by step)

Hola...

En el siguiente documento se expone el como se realiza la instalación de un agente para Grid Control, pantalla por pantalla se va indicando los pasos a seguir.

Recordar que el Agente de Grid Control es el encargado de envíar información (XMLs) desde un target (origen) hacía un OMS (destino que forma parte del Grid) , con ello podemos ver en línea (en realidad con pequeños delay) , toda la información de nuestro



Espero que sea de utilidad , acá va el link

Instalacion Agente de Grid Control , paso a paso

by Ligarius
08.05.09. 10:32:56. 96 words, 10644 views. Categories: Enterprise Manager Grid Control ,

Oracle 11g : Nueva característica Result Cache (New Feature Result Cache)

En Oracle11g ha nacido una característica de verdad bastante innovadora, relacionada con el hecho de almacenar los datos para no consultarlos 2 veces a disco. :yes:

Por ejemplo imaginate un select count(*) sobre una tremenda tabla , se demoraría minutos, pues bien , al consultarla de nuevo , esta queda en memoria lista para reutilizar, por ende , el segundo select count(*) es rapídisimo.

Existen varias posibilidades para utilizar, y de verdad, es muy potente, acá va una pequeña explicación de las posibilidades de uso del Result Cache (Query y Pl/Sql Function)

En este documento, se explicará en mayor detalle el uso del Result Cache ,tanto para sentencias SQL como para funciones SQL .

Explicacion sobre Result Cache

by Ligarius
06.05.09. 23:10:43. 119 words, 5519 views. Categories: Base de datos, Oracle 11g, Tuning / Performance ,

<< 1 ... 34 35 36 37 38 39 40 41 42 43 44 >>