Efecto del resize frecuente del SGA en Oracle 10g R2 o superior
Analizando algunos bloqueos en bases de datos Oracle 10g R2, que no necesariamente tenian que ver con LOCKS propios de la base de datos, para proteger la consistencia de la informacion, sino que algo adicional estaba sucediendo y en muchos casos parecia “congelamiento” de la base de datos. Realmente algo muy extraño, que sucede en base de datos hibridas (muy transaccionales + bastantes reportes + procesos batches enormes) y que hacen uso de la característica SGA Dinámico (SGA_TARGET).
La situacion de tener una base de datos híbrida, es decir una base de datos donde se realizan operaciones transaccionales asi como la ejecución de reportes que demandan buena cantidad de bloques Oracle y adicionalmente se corren procesos Batch (Updates, Inserts, etc) masivos. Digamos que ese contexto lo tienen varias bases de datos, asi que no es algo raro tener una base de datos híbrida.
Muchos Oracle DBA reconocen la excelente funcionalidad del parámetro SGA_TARGET y la ventaja que nos provee al “balancear” dinámicamente la SGA disponible entre las estructuras principales de memoria como SHARED POOL y BUFFER CACHE, entre otras. Es importante mencionar que Oracle tiene que ir calculando internamente cuanta memoria asignar a cada uno de estos componentes en base a lo que se necesite o recomiende internamente. Este operación se realiza automaticamente cada 30 segundos.
Para el caso de las bases de datos hibridas, se presenta el problema que este asignamiento automático de las estructuras de memoria del SGA se puede realizar muy frecuente, ocasionando eventos de espera como el “cursor: pin S wait on X” o “library cache lock waits“. Si esto esta pasando en tu base de datos, un paleativo es aumentar los 30 segundos por default a por lo menos 999 segundos a través del parámetro oculto “_memory_broker_stat_interval“. Como referencia se puede consultar la nota de metalink # 742599.1.
En: Oracle Database, Tuning el 05/31/2009
You must be logged in to post a comment.