2011-02-16 51 views
5

mi aplicación asp.net utiliza algunas secuencias para generar claves primarias de tablas. Los administradores de Db han establecido el tamaño de caché en 20. Ahora la aplicación está bajo prueba y se agregan algunos registros diariamente (digamos 4 para cada sesión de prueba de usuario). He encontrado que los nuevos registros de la sesión de prueba siempre usan nuevas porciones de caché como si los números previos en caché de día hubieran expirado, perdiendo la décima parte de las claves todos los días. Me gustaría saber si se debe a algún error que haya cometido en mi aplicación (deshacerse de los adaptadores de tablas o lo que sea) o si es el comportamiento habitual. ¿Existen mejores prácticas de programación para tener en cuenta al manejar secuencias de oráculo?Caché de secuencia de Oracle viejo con demasiada frecuencia

Dado que la aplicación no tendrá que soportar una gran carga de trabajo (digamos 20-40 registros nuevos por día), estaba pensando si podría ser el caso para establecer un tamaño de caché más pequeño o ninguno. ¿El cambio de tamaño de la caché de secuencia implica el reinicio del índice actual?

gracias de antemano por cualquier sugerencia

+2

Por lo tanto, sus identificadores tienen lagunas. ¿Y qué? No veo el problema. –

+0

mientras que las lagunas no deberían ser un problema, desperdiciar el 95% de los valores es solo eso: desperdicio –

+0

para ser claro: las lagunas no me preocupan tanto, sabía que las secuencias podrían tener lagunas. –

Respuesta

7

La respuesta de Justin cueva en este tema podría ser de su interés:

http://forums.oracle.com/forums/thread.jspa?threadID=640623

En pocas palabras: si la secuencia no se accede con frecuencia suficiente, pero que tiene mucho aa de "tráfico" en el caché de biblioteca, luego la secuencia puede ser eliminada y eliminada del caché. En ese caso, los valores preasignados se pierden.

Si eso sucede con mucha frecuencia, parece que su secuencia no se usa con mucha frecuencia.

supongo que la reducción del tamaño de la caché (o completamente su desactivación) no tendrá un impacto notable en el rendimiento en su caso (también la hora de tomar su declaración de 20-40 nuevos registros al día en cuenta)

+0

Dado que este es un entorno de prueba, también sospecho que la base de datos se reinicia todas las noches. Suponiendo que no es el caso en la producción, esto puede ser un problema ambiental. –

+0

eso es correcto, la aplicación es esencialmente una gran forma dividida en piezas ajax. La prueba que hice hoy muestra que cambia entre dos secuencias en caché. Aparte de ser miserable y tratar de salvar números, mi temor era que mi uso de secuencias tuviera algún defecto de programación. –

2

Oracle Sequences no son sin huecos. Reducir el tamaño de la caché reducirá los huecos ... pero aún tendrá lagunas. La secuencia no está asociada a la tabla por la base de datos, sino por su código (a través de la próximaval en la inserción a través de trigger/sql/pkg api) - en esa nota puede usar la misma secuencia en varias tablas (no es al igual que la identidad del servidor SQL donde está asociada a la columna/tabla)

por lo tanto, cambiar la secuencia no tendrá ningún impacto en los índices.

Sólo se necesita para asegurarse de que si se le cae la secuencia y lo reinicia, usted RESEED 'a la 1 del valor actual (por ejemplo, crear secuencia de seqer comenzar con 125 nocache;)

, pero

Si su aplicación requiere un conjunto de números sin huecos , entonces no puede usar secuencias de Oracle. Debe serializar actividades en la base de datos usando su propio código desarrollado.

, pero tenga en cuenta que puede aumentar el disco IO y bloquear posibles transacciones si elige no usar secuencias.

El generador de secuencia es útil en entornos multiusuario para generar números únicos sin la sobrecarga de /S de disco o de bloqueo transacción.

para reiterar los comentarios de a_horse_with_no_name, ¿cuál es el problema con los huecos en la identificación?


Editar también echar un vistazo a la lógica de almacenamiento en caché que puedes usar se encuentra aquí: http://download.oracle.com/docs/cd/E11882_01/server.112/e17120/views002.htm#i1007824


0

medida que las personas mencionan: Las lagunas no debería ser un problema, por lo que si usted está requiriendo no hay lagunas que está haciendo algo mal. (Pero no creo que esto sea lo que quieres).

La reducción de la memoria caché debe reducir el número y disminuir el rendimiento de la secuencia, especialmente con el acceso concurrente a la misma. (que no debería ser un problema en su caso de uso).

Al cambiar la secuencia con la secuencia de alteración de secuencia (http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/statements_2011.htm), no se debe restablecer el valor actual/siguiente de la secuencia .

+2

El caché de secuencia está en el SGA ("el caché de secuencia [está almacenado] en el área global del sistema (SGA).") Una prueba rápida de creación de nuevas sesiones indica que son concurrentes (es decir, aumentan como se espera en ambos sesiones usando el mismo caché). Avíseme si tiene resultados diferentes si lo prueba, pero parece que la memoria caché agota el tiempo de espera debido a la inactividad para iniciar una nueva cuenta en oposición a problemas de agrupamiento de conexiones. – Harrison

+0

Lee el enlace que proporcionaste, así que supongo que estás en lo correcto ... me pregunto dónde recogí esa falsa sabiduría: -/ –

1

Si está usando la secuencia de PK y no aplica alguna lógica de aplicación, entonces no debería preocuparse por las brechas. Sin embargo, si hay alguna lógica de aplicación vinculada a los valores de secuencia secuencial, tendrá agujeros si utiliza el almacenamiento en caché de secuencia y no tiene un sistema ocupado. Los valores de la memoria caché de secuencia se pueden eliminar de la memoria caché de la biblioteca.

Usted dice que su sistema no está muy ocupado, en este caso modifique su secuencia a no caché. Está en una posición de tener un impacto de rendimiento insignificante para solucionar un problema lógico, por lo que también podría.

Cuestiones relacionadas