Agrandado el log buffer
Estoy tratando de agrandar el lod_buffer pero cuando trato de levantar la base de datos no levanta y me sale un error como shared memory algo no se que es así que no lo he podido agrandar mucho
1 Respuesta
Respuesta de pedrito12
1
En primer lugar darte las gracias por confiar en mi para resolver tu pregunta, que no te quepa duda que lo haré o por lo menos lo intentaré.
En segundo lugar no tengas miedo a escribir y explicar con todo lujo de detalles el problema que tengas, ya que aquí el espacio para escribir es gratuito.
La cuestión está en saber cuanta memoria tenemos disponible en el servidor y cuánta más o menos nos hace falta a nosotros.
No me has comentado qué valor tienes ahora en el parámetro "log_buffer" del fichero de inicialización de parámetros de la B.D. Sabiendo un poco más sobre tu sistema con suerte daremos en el clavo a la primera. Pero te adelanto que este parámetro se expresa en bytes, que es de tipo integer y que además es estático, es decir que no se puede modificar dinámicamente.
Si me cuentas un poco más sobre cómo está montada la B.D, que plataforma tienes, volumen, y disposición física de la misma, yo prometo d igual modo ajustarte el log_buffer para que no tengas contención en los mismos o latches, etc...
Espero tu respuesta y recuerda!, escribe todo lo que quieras que no cuesta nada.
En segundo lugar no tengas miedo a escribir y explicar con todo lujo de detalles el problema que tengas, ya que aquí el espacio para escribir es gratuito.
La cuestión está en saber cuanta memoria tenemos disponible en el servidor y cuánta más o menos nos hace falta a nosotros.
No me has comentado qué valor tienes ahora en el parámetro "log_buffer" del fichero de inicialización de parámetros de la B.D. Sabiendo un poco más sobre tu sistema con suerte daremos en el clavo a la primera. Pero te adelanto que este parámetro se expresa en bytes, que es de tipo integer y que además es estático, es decir que no se puede modificar dinámicamente.
Si me cuentas un poco más sobre cómo está montada la B.D, que plataforma tienes, volumen, y disposición física de la misma, yo prometo d igual modo ajustarte el log_buffer para que no tengas contención en los mismos o latches, etc...
Espero tu respuesta y recuerda!, escribe todo lo que quieras que no cuesta nada.
Mi log_buffer ahora mismo tiene 42768,
mi servidor tiene 512MB, tiene instalado nt server 4.0 y la version de oracle es 8i 1.7 tengo 25 usuarios no se que más decirte .
Saludos
Xio
mi servidor tiene 512MB, tiene instalado nt server 4.0 y la version de oracle es 8i 1.7 tengo 25 usuarios no se que más decirte .
Saludos
Xio
Como ya sabrás el tunning de una B.DE depende única y exclusivamente del llamado método de "ensayo/error" que consiste en que vayas tocando parámetros de la B.DE, y midiendo los rendimientos, cuellos de botella, accesos, etc... para ver si mejora tocando una cosa u otra.
Mi experiencia como DBA me dice que en una B.DE pequeña como la que tu manejas no tendrías que tener problema por tener un Log_buffer del tamaño que me indicas, por lo que creo que`el problema podría estar en otro sitio.
La SGA se compone de una serie de bufferes, a parte de otras cosas, los cuales dan forma al tamaño de la memoria de la B.D. Por lo general y dependiendo de si tu B.D es muy transaccional o simplemente es más "ON-Line", o si a lo mejor se procesa mucho Batch, etc la Shared_pool_size deberás dimensionarla para que siempre quede algo libre es decir con la siguiente sentencia podrás ver lo que te queda libre de memoria:
SELECT * FROM V$SGASTAT WHERE NAME = 'free memory';
Te devolverá 3 tipos de memoria libre, la java y la large, pero esos son otros temas que ahora no nos interesan.
Una vez que veamos que tenemos memoria libre, (lo mejor es que lo midas durante una semana a la misma hora, poe ejemplo, y que sea en hora punta de trabajo, o si puedes toma una muestra a distintas horas del día y contrastas.
Otro parámetro es el bd_block_buffer. Este parámetro nos indica la cantidad de bloques que albergaremos en la memoria para mejorar la lectura de bloques de Oracle en memoria. Este parámetro cuanto más grande sea, reduce la lectura I/O en disco, lo que mejora el rendimiento de la B.D.
Para saber si lo hemos dimensionado bien nos podemos valer de la siguiente sentencia:
select round(((1-(sum(decode(name,
'physical reads', value,0))/
(sum(decode(name, 'db block gets', value,0))+
(sum(decode(name, 'consistent gets', value, 0))))))*100),2)|| '%' "Buffer Cache Hit Ratio"
from v$sysstat;
Realízala con un usuario dba.
El número que nos devuelve es un porcentaje, un ratio, lo que quiere decir que cuanto más se acerque al 100% mejor que mejor, porque mejor sera el rendimiento.
Esencialmente estos son los parámetros que determinan que una B.D pueda funcionar medianamente bien. Teniendo bien estos parámetros, nuestra B.D puede empezar a funcionar bien. Existen otros muchos parámetros que también determinan el funcionamiento de nuestra B.D pero requieren de un estudio mucho más profundo que este.
El Log_buffer es un parámetro que va a determinar si el funcionamiento del Redo de nuestra B.D va a ser bueno o no y como todos los datos de la B.D pasan por él, es conveniente que le prestemos una especial atención. Calculando un poco tu volumen de datos, usuarios, y sin saber que tipo de trnasacciones se suceden en ella es difícil dicmensionar este parámetro pero me arriesgaré. Pon 131072. Que son 128Kb. También deberías saber que existen una serie de Latches de Log de 2 tipos, que necesitan de un buen tunning, porque con el tiempo se van descalibrando, dependiendo del volumen de datos que pasen por ellos, y las transacciones concurrentes que lo hagan, deberemos darle una u otra dimensión, y eso solo se consigue con un estudio profundo de lo que es el funcionamiento del Log, latches, bufferes, etc.
En definitiva, tu B.D puede funcionar con lo que arriba te he comentado, pero podrás llegar ha hacer que vaya tan rápido como un avión, si estudias a fondo como funciona tu sistema, como funciona la B.D y las características especiales que tiene la version 8.1.7
Mi consejo es que intentes estudiar ORACLE en libros, te ayudes de nosotros, osea otros DBA para aprender y que hagas tus pruebas en tu sistema y saques tus propias conclusiones, y sobre todo que no desesperes que oracle es complejo pero tiene una buena documentación de la cual podrás sacar suficiente información como para ser un buen DBA ORACLE.
Que tengas suerte, y si tienes más dudas comunícamelo y te ayudaré.
Suerte y al toro!
P.D: Ten en cuenta sobre todo la cantidad de memoria que tiene tu sistema y la cantidad de memoria que consume tu B.D, no vaya a ser que el sistema necesite hacer Swapping ya que eso puede ser muy problemático.
Pedro.
Mi experiencia como DBA me dice que en una B.DE pequeña como la que tu manejas no tendrías que tener problema por tener un Log_buffer del tamaño que me indicas, por lo que creo que`el problema podría estar en otro sitio.
La SGA se compone de una serie de bufferes, a parte de otras cosas, los cuales dan forma al tamaño de la memoria de la B.D. Por lo general y dependiendo de si tu B.D es muy transaccional o simplemente es más "ON-Line", o si a lo mejor se procesa mucho Batch, etc la Shared_pool_size deberás dimensionarla para que siempre quede algo libre es decir con la siguiente sentencia podrás ver lo que te queda libre de memoria:
SELECT * FROM V$SGASTAT WHERE NAME = 'free memory';
Te devolverá 3 tipos de memoria libre, la java y la large, pero esos son otros temas que ahora no nos interesan.
Una vez que veamos que tenemos memoria libre, (lo mejor es que lo midas durante una semana a la misma hora, poe ejemplo, y que sea en hora punta de trabajo, o si puedes toma una muestra a distintas horas del día y contrastas.
Otro parámetro es el bd_block_buffer. Este parámetro nos indica la cantidad de bloques que albergaremos en la memoria para mejorar la lectura de bloques de Oracle en memoria. Este parámetro cuanto más grande sea, reduce la lectura I/O en disco, lo que mejora el rendimiento de la B.D.
Para saber si lo hemos dimensionado bien nos podemos valer de la siguiente sentencia:
select round(((1-(sum(decode(name,
'physical reads', value,0))/
(sum(decode(name, 'db block gets', value,0))+
(sum(decode(name, 'consistent gets', value, 0))))))*100),2)|| '%' "Buffer Cache Hit Ratio"
from v$sysstat;
Realízala con un usuario dba.
El número que nos devuelve es un porcentaje, un ratio, lo que quiere decir que cuanto más se acerque al 100% mejor que mejor, porque mejor sera el rendimiento.
Esencialmente estos son los parámetros que determinan que una B.D pueda funcionar medianamente bien. Teniendo bien estos parámetros, nuestra B.D puede empezar a funcionar bien. Existen otros muchos parámetros que también determinan el funcionamiento de nuestra B.D pero requieren de un estudio mucho más profundo que este.
El Log_buffer es un parámetro que va a determinar si el funcionamiento del Redo de nuestra B.D va a ser bueno o no y como todos los datos de la B.D pasan por él, es conveniente que le prestemos una especial atención. Calculando un poco tu volumen de datos, usuarios, y sin saber que tipo de trnasacciones se suceden en ella es difícil dicmensionar este parámetro pero me arriesgaré. Pon 131072. Que son 128Kb. También deberías saber que existen una serie de Latches de Log de 2 tipos, que necesitan de un buen tunning, porque con el tiempo se van descalibrando, dependiendo del volumen de datos que pasen por ellos, y las transacciones concurrentes que lo hagan, deberemos darle una u otra dimensión, y eso solo se consigue con un estudio profundo de lo que es el funcionamiento del Log, latches, bufferes, etc.
En definitiva, tu B.D puede funcionar con lo que arriba te he comentado, pero podrás llegar ha hacer que vaya tan rápido como un avión, si estudias a fondo como funciona tu sistema, como funciona la B.D y las características especiales que tiene la version 8.1.7
Mi consejo es que intentes estudiar ORACLE en libros, te ayudes de nosotros, osea otros DBA para aprender y que hagas tus pruebas en tu sistema y saques tus propias conclusiones, y sobre todo que no desesperes que oracle es complejo pero tiene una buena documentación de la cual podrás sacar suficiente información como para ser un buen DBA ORACLE.
Que tengas suerte, y si tienes más dudas comunícamelo y te ayudaré.
Suerte y al toro!
P.D: Ten en cuenta sobre todo la cantidad de memoria que tiene tu sistema y la cantidad de memoria que consume tu B.D, no vaya a ser que el sistema necesite hacer Swapping ya que eso puede ser muy problemático.
Pedro.
