Duda sobre los parámetros de una base de datos

Este parámetro es recomendado usarlo cuando el servidor de BD posee más de un (1) CPU, con la finalidad de entonar o mejorar las contenciones provocadas durante la copia de cada redo logfile.
Generalmente se usa con el "LOG_SMALL_ENTRY_MAX_SIZE".
Ahora bien, existen diferentes formas de entonar este proceso. ¿Realmente cuál es es tu problema?

Buenas Tardes..
OK!...
Mira mi problema es que tengo mucha contención en el redo copy según metalink... me dice que el valor por defecto.. de dicho parámetro es de dos veces la cantidad de Cpu.. de mi servidor...
Entonces lo que ando buscan es cual es el valor... que debería ponerle a dicho parámetros... y me podrías informar un poquito más sobre el otro parámetro que me mencionas...
Gracias!

¿Cómo sabes tu que tienes contención en el Redo Copy?
El uso de éste parámetro es muy complicado y cualquier valor equivovado es peligroso para el performance de la instancia.
Te explico lo siguiente para entender un poco lo que digo:
Normalmente un proceso escribe en los log buffers (sga) a la vez. El redo allocation latch (ral) se asegura que ésto sea así. Un usuario toma el "ral" para escribir en los log buffer (bloqueándolos) y luego lo libera. Para disminuir las contenciones al redo log copy (proceso que se encarga de asignar espacio y escribir en los log buffers) se necesita reducir el números de veces en que el usuario bloquea el "ral". El número de redo log copy es determinado por el parámetro _LOG_SIMULTANEOUS_COPIES. Incluso con éste parámetro > 0, el "ral" seguirá escribiendo en los log buffers, siempre y cuando el "log entry size" sea menor que el valor de LOG_SMALL_ENTRY_MAX_SIZE.
Decirte un valor específico no es sencillo, se necesita conocer primero mucho sobre tu BD y probar luego otras alternativas antes de aplicar éstos parámetros, es como ponerse ropa limpia sin bañarse.
Ahora bien, si necesitas que te siga ayudando, cuéntame realmente tu situación y vemos como podemos ir solucionandola.
[email protected]

Mira, ¿te explico un poco?
Mi Base de Datos, es oracle8i (8.1.7.4), ¿es para una empresa financiera?
Tengo una herramienta de Quest el Spotlight, ¿el cuál me ha estado enviando una alerta? De que hay mucha contención en los redologs
¿Bueno? ¿Entonces me dedique a buscar información en Metalink? ¿Y me encontré la siguiente instrucción?
--------------------------------------------------------------------------------
o The following query determines the miss ratio and the "immediate" miss ratio for redolog latches.
SELECT substr(ln.name, 1, 20), gets, misses, immediate_gets, immediate_misses
FROM v$latch l, v$latchname ln
WHERE ln.name in ('redo allocation', 'redo copy')
and ln.latch# = l.latch#;
If the ratio of MISSES to GETS exceeds 1%, or the ratio of IMMEDIATE_MISSES to (IMMEDIATE_GETS + IMMEDIATE_MISSES) exceeds 1%, there is latch contention.
Note: Oracle recommends to tune first the redo allocation latch rather than the redo copy latch.
In Oracle7 and Oracle8.0:
If the contention is caused by redo allocation latch decrease the value of LOG_SMALL_ENTRY_MAX_SIZE. The recommended value is the average of redo size which can be calculated as (redo size/redo entries) from V$SYSSTAT.
If you find redo copy latch contention, you can increase the parameter LOG_SIMULTANEOUS_COPIES to have more latches available. The recommended value is twice the numbers of CPUs.
In Oracle8i and Oracle9.0:
If the contention is caused by redo allocation latch you can either use the NOLOGGING option to reduce the amount of redo log entries for certain operations (See <Note:147474.1>) or reduce the load on the latch increasing the LOG_BUFFER PARAMETER.
@You can reduce the load on the latch as well using the parameter _LOG_IO_SIZE
@described in the <Note:31283.1>
If you find redo copy latch contention, you can increase the hidden init.ora _LOG_SIMULTANEOUS_COPIES to have more latches available. The default is twice the numbers of CPUs.
--------------------------------------------------------------------------------
Estos son los datos que me da la Base de Datos:
SUBSTR(LN.NAME, 1,20)
GETS
Misses
IMMEDIATE_GETS
IMMEDIATE_MISSES
Redo allocation
33259151
10360
0
0
Redo copy
1884
0
32827533
1944
¿A raíz de esto? ¿La empresa que nos da la auditoria de Base De Datos? ¿Me indica que debo aumentar el valor de este Parámetros _LOG_SIMULTANEOUS_COPIES por default según lo leído estaba en 8?. Entonces se puso en 12..
Mira... disculpa... ¿yo estoy muy inexperto? ¿Con base de datos? ¿Tengo unos 6 meses en esto y hay cosas que todavía no he aprendido?. ¿Te agradezco toda la ayuda que me pueda dar?
¿Y si tienes tips? Para mejorar el rendimiento en mi BD, ¿te lo agradezco? Así como en mis aplicaciones..
Miguel Jimenez Molina
[email protected]

Ya te envíe la información al correo.. podrías revisar si te llego.. y avisar... por este medio o por correo...

No te preocupes, todos empezamos por el principio, más bien admiro tu dedicación.
Primero el spotligth debe ser entonado o configurado con valores adecuados, éste soporte te lo puede dar el proveedor de QUEST.
Ahora bien, lo primero es asegurarse de que los datafiles se encuentren bien distribuidos según la carga de I/O. Te mando este e-mail y si quieres cierra la pregunta, la calificas y luego no escribimos por el e-mail ([email protected]). Nota: hazme llegar los resultados del query para elaborarte una propuesta de entonación, junto con el init. Ora.
set pagesize 64
set linesize 132
set newpage 0
set feedback off
ttitle skip center "Peso de Archivos de BD" skip center "Ordenado por Unidad" skip 2
column Total_IO format 999999999
column Peso format 999.99
column Archivo format a43
break on Unidad skip 2
compute sum of Peso on Unidad
Select substr(df.name,8,8) Unidad
,df.name Archivo
,fs.phyblkrd+fs.phyblkwrt Total_IO
,100*(fs.phyblkrd+fs.phyblkwrt)/MaxIO Peso
From v$filestat fs, v$datafile df
,( select max(phyblkrd+phyblkwrt) MaxIO
from v$filestat )
Where df.file# = fs.file#
order by 1, Peso desc
spool peso_arch_desa.txt
Ttitle off
/