Está en la página 1de 9

Accesos buffer almacenamiento en bfer: Almacenamiento Temporal Con el fin de mejorar el rendimiento, varias opciones para el tema de bfer

se han elaborado, por lo tanto, cuando se investiga un tema relacionado con los rangos de nmeros no es suficiente decir "el objeto de rango de nmeros est en el bfer", sino que tambin se debe dar la respuesta a la pregunta "cmo?" El almacenamiento en bfer de las series de nmeros se encuentra, junto con otros atributos de los objetos de rangos de nmero, a travs de transacciones SNRO. En los objetos de rango de nmero existe una gama atributos, dependiendo de la versin, el bfer se muestra tanto en una nica pgina nica para el objeto, o en versiones posteriores en una pestaa de personalizacin. Junto con el tipo de bfer utilizado, el tamao del buffer tambin se muestra. Un tamao de bfer de cero (BUFFER SIZE OF ZERO) significa que no se ha almacenado en bfer, independientemente del tipo de bfer que se tenga, independientemente del mtodo de bfer utilizado. Cmo s que es mi Objeto? Muchos objetos de rango de nmeros tienen su propia transaccin, por lo tanto el nombre del objeto no aparece. Como ejemplo para determinar un objeto de rango de nmeros, vamos a tomar la conocida transaccin para documentos financieros, FBN1. Vaya a la FBN1 e inicie el depurador (escriba / h en la caja de transacciones y pulsa enter). Al entrar en el depurador, debe mostrar el valor del campo TNRO-OBJECT. Este es el nombre del objeto de rango de nmeros, en este caso es RF_BELEG, O vaya a la transaccin SE16, tabla TNRO, campo de Cdigo = FBN1. De vez en cuando, debido a bloqueos en la tabla de NRIV, ocurren errores de tiempo de espera, en el mdulo SAPLSNR3, en la instruccin SELECT SINGLE FOR UPDATE * FROM NRIV Si desea determinar en el DUMP el nombre del objeto, lo encontrar en el campo P_OBJECT. Adems, el DUMP le dice qu tipo de almacenamiento en bfer esta utilizando, en el campo TNRO-BUFFER. Los valores correspondientes (y los posibles tipos de almacenamiento en bfer) son los siguientes: SPACE sin almacenamiento temporal X almacenamiento en bfer en memoria principal

L almacenamiento en buffer local (obsoleto) P almacenamiento en buffer extendido S almacenamiento en buffer en paralelo Observacin: por un lado es posible distinguir entre objetos de rango de nmeros y por otro lado los intervalos. Puede haber uno o ms intervalos para el mismo objeto. El almacenamiento en Bfer se establece a nivel de objeto para todos los intervalos iguales. Sin embargo, puede haber variaciones, como excepciones especificas de intervalos para almacenamiento en bfer. Primeras consideraciones para la numeracin relacionadas con aspectos jurdicos Muchos rangos de nmero no tienen restricciones legales, es decir, la numeracin no necesariamente debe ir en forma ascendente o en forma consecutiva, lo que permite que e usen tcnicas en almacenamiento en bfer con el fin de mejorar el rendimiento. Un ejemplo es el nmero de spool de un documento. No importa si un nmero dado ms adelante es menor que un nmero dado antes, siempre y cuando los nmeros sigan siendo nicos. Casi todos los objetos de rango de nmeros, el estndar SAP los entrega almacenados en el bfer en la memoria principal. El almacenamiento en Bfer en memoria principal es el ms eficiente en trminos de rendimiento pero tiene dos efectos secundarios: - Los nmeros no se dan en orden ascendente - La numeracin puede tener saltos (se pierde la secuencia). Un aspecto interesante es que algunos clientes, conscientes de la conexin entre el almacenamiento en bfer y la forma en que los nmeros se asignan, toman la decisin de no usar este tipo de almacenamiento en bfer, debido a que no estn conformes con estos efectos secundarios y no por porque exista una ley en contra de esto. Pero tambin existen clientes que se quejan de estos efectos secundarios y los consideran un error. Pero no es as, esto funciona segn como fue diseado. Deshabilitar el almacenamiento en bfer para un objeto de rango de nmeros, configurado en el estandar SAP como buffer en la memoria principal puede (no debe) ser extremadamente perjudicial para el rendimiento del sistema en el rea de aplicacin especfica y es considerado por SAP como una modificacin del clientes. (Ver nota 678501 sobre este tema).

Rangos de nmero sin bfer Por otro lado, hay objetos de rango de nmeros en algunos pases que son centro de restricciones legales, como los documentos FI (objeto RF_BELEG) y SD (RV_BELEG). Tales objetos son entregados por SAP sin almacenamiento en bfer, los intentos para mejorar el rendimiento del bfer estn sujetos a leyes especficas para cada pas en el que el cliente opera, hay casos ms complejos cuando el cliente est operando en un entorno multi-nacional con diferentes criterios jurdicos en cuestin. Para poder acceder a la amplia gama de limitaciones legales en diferentes pases y regiones en este mbito SAP comenz con una operacin de la evaluacin, pero tuvo que ser detenido, no slo debido a la complejidad de la cuestin, sino tambin por su volatilidad. Por ejemplo, hasta 2006, en Espaa los documentos financieros y los nmeros de orden tenan que ser consecutivos sin saltos, pero no necesariamente en orden ascendente. Desde el ao 2006 una nueva ley fue aprobada, indicando que tenan que cumplirse ambas condiciones. Por el momento, en Alemania slo tiene que ser sin saltos. En Israel, la numeracin debe ser ascendente, pero los saltos son permitidos. En conclusin, es el cliente quien tiene que proporcionar la informacin sobre el marco legal y SAP formula recomendaciones al respecto. Con el fin de hacer la recomendacin mas apropiada, se debe tener presente los efectos del tipo de almacenamiento en buffer que se escoja (y el tamao del bfer) y qu combinaciones son posibles. Algunas aplicaciones como FI y SD permiten una mayor flexibilidad en este sentido, a travs de desarrollos o definiciones especficas de los clientes, lo que puede influir el almacenamiento en bfer de acuerdo a las exigencias de la aplicacin. Vamos a echar un vistazo a las diferentes opciones de almacenamiento en bufer y los resultados correspondientes a la numeracin desde el punto de vista legal. Sin uso de Bfer A continuacin se cita la nota FI 1398444: El nmero se asigna en orden cronolgico ascendente basada en la NRIV mesa. Para ello, el NRIV tabla est bloqueada hasta que la aplicacin (LUW) es denunciado por cualquiera de un COMMIT WORK o ROLLBACK (vase tambin la nota 639 754). Otra de las aplicaciones no pueden tomar una serie de documentos durante este tiempo. La actualizacin es llamado por el COMMIT WORK y el nmero de documento se le asigna de forma permanente. En el caso de una cancelacin, el nmero del documento que ha sido utilizada no se ha asignado, y est disponible para el prximo lugar de destino en NRIV nuevo. Este bloqueo garantiza una asignacin por orden cronolgico ascendente del nmero de

documento, sin lagunas. Sin embargo, el bloqueo provoca una serializacin en el NRIV tabla, que puede afectar seriamente el rendimiento del sistema (vase tambin la nota 678 501). Hay problemas de rendimiento, en particular en el caso de procesos por lotes en paralelo, ya que el bloqueo se mantiene por un tiempo muy largo. Buffer de almacenamiento principal En la demanda - lo que significa que cuando un nmero se le pide por primera vez desde el reinicio de una cierta instancia de SAP - un conjunto de nmeros, tantos como el tamao de bfer se establece - se descargan en la memoria principal del intervalo correspondiente en la tabla NRIV. El nivel de intervalo en NRIV se incrementa en la misma cantidad. Esto sucede a travs de una "puerta trasera" del proceso y no crear bloqueos. Cuando la instancia se reinicia de nuevo, estas cifras se han perdido. Es el sistema de un sistema multi-instancia - como la mayora son - en el tiempo, cada caso recibe el conjunto de los nmeros y las aplicaciones que se ejecutan aqu o all recibir los nmeros de la serie respectiva. El resultado es que las cifras de la aplicacin estn saltando de aqu para all. Si ocurre un retroceso, el nmero sorteado se pierde para siempre. Si el sistema es reiniciado, el bfer se elimina y los nmeros no se pierden. Bfer de memoria principal funciona ms o menos de la siguiente manera: Un proceso separado descargas - como ayuda, en la demanda - a nivel de instancia SAP - un grupo de nmeros del tamao indicado en el tamao del buffer en el SNRO transaccin - en la memoria principal del caso particular y le da a uno o ms de ellos a la aplicacin, el resto que queda en el buffer de memoria principal para su uso posterior. Este proceso de separar los temas de trabajo inmediato un compromiso para que el proceso, dejando el intervalo NRIV libre para accesos ms. Todo el proceso se lleva a cabo y controlada por el controlador de tareas de SAP y el proceso de recarga se puede ver en SM50 es un proceso muy corto, con el SAPSYS usuario. Cuando todo funciona con normalidad, el almacenamiento en bfer de memoria principal asegura un manejo de alto rendimiento de los rangos de nmeros sin ningn problema. Sin embargo, los problemas pueden aparecer. El ms comn proviene de la recarga en un proceso paralelo que utiliza una obra DIA tipo de proceso. Puede suceder que, debido a una carga extrema de la instancia por otros procedimientos, sencillamente no hay proceso de trabajo DIA disponibles ms. Para ello, consecuencias y soluciones consulte la nota 920234. Tambin est el aspecto del nmero mximo de entradas de bfer. El funcionamiento puede verse afectada por el hecho de que una nueva entrada en el bfer no se puede crear, y el error asociado es NR031. El tamao mximo y el uso real, as como el contenido se puede controlar con la transaccin SM56 y la nota relevante es 399207. Ahora, qu tan eficiente es este tipo de amortiguacin? La eficiencia tiene dos aspectos:

En primer lugar, el hecho de que no hay bloqueo en NRIV entre el dibujo nmero y una obra de confirmacin. Esto es enorme. El segundo aspecto es el tamao del bfer. En teora, cuanto mayor sea el buffer, menos la "puerta trasera" los procesos son necesarios para llenar el buffer. Pero esto es un asunto menor, a excepcin de las instalaciones donde hay un nmero muy bajo de los procesos de dilogo disponibles de trabajo, un buffer ms pequeo creara una presin excedente en los sistemas que pueden crear problemas. Por otro lado, la diferencia entre el acceso de buffer y sin buffer es mucho ms importante, que una nueva idea debe ser considerada aqu. Qu sucede si el tamao de bfer se establece en exactamente 1? Luego de cada sorteo nmero va a pasar a travs de la "puerta trasera", siendo de NRIV, pero la entrega de la serie sin ningn tipo de bloqueo. La desventaja es, en el caso de una cancelacin, el nmero se ha perdido, en el otro lado, INDEPENDIENTEMENTE DE LA INSTANCIA en el que se est ejecutando, los nmeros sern entregados en una secuencia ascendente. Conclusin: el almacenamiento en bfer en la memoria principal con un tamao de bfer de 1 asegura una secuencia ascendente, pero no puede evitar lagunas en el caso de reversin. Amortiguamiento local (obsoleto) Fue el primer intento de obtener algn tipo de almacenamiento en bfer para los documentos en los que es importante no tener carencias, incluso si los documentos no se asignan en orden ascendente. Este mtodo de almacenamiento en bfer fue el primer intento de SAP para resolver el problema de las lagunas en el caso de un retroceso o un reinicio del sistema. Se hace lo mismo que el buffer de almacenamiento principal, pero en lugar de utilizar la memoria principal, donde los nmeros se pierden en un reinicio de la mesa NRIV_LOKAL se utiliza en lugar, no hay "mano oculta" para recargar los buffers (es decir, cuando se recarga y quiere otra instancia recarga que correr a la misma cerradura en NRIV como si unbuffered) y, respectivamente, procesos que se ejecutan en la misma instancia y con ganas nmeros de las mismas se estn bloqueo en lugar de NRIV_LOKAL NRIV, tal vez un poco ms tarde, pero inevitable, an sin bfer. Este mtodo de almacenamiento en bfer no es elegible en lnea ya en versiones posteriores y considerado por SAP como totalmente obsoleto. Amortiguamiento local extendido Este mtodo de almacenamiento en bfer trata de aprender las lecciones de los inconvenientes del bfer local y establece un buffer no slo de una instancia, sino a trabajar a nivel de procesos. Por lo tanto, en NRIV_LOKAL vers entradas como <nombre_instancia> _00, _04 <nombre_instancia>

y as sucesivamente, en 00 o 04 es el nmero de proceso de trabajo como se ve en las transacciones SM50 o SM66. Tiene la ventaja de que, una vez que los amortiguadores se han establecido, las tareas de pedir estos nmeros en la misma instancia no compiten por los tampones ms. El principal inconveniente de este mtodo es la creacin - y la carga - de los mismos topes, porque no hay una "puerta trasera" recarga. Esto significa que, cuando dos procesos intenta volver a cargar los topes sin emitir un COMMIT WORK, el primero lo hace con xito, pero el segundo tiene que esperar en la cerradura NRIV hasta la primera entrega el bloqueo de la emisin de un COMMIT (o un ROLLBACK). El tamao del buffer debe ser por lo tanto, relativamente grande. Est bastante claro que este mtodo slo puede ser el almacenamiento en bfer en los pases donde la nica restriccin legal es que no debe haber diferencias, pero los nmeros definitivamente no se asignan en orden ascendente. En realidad hay lagunas, ya que algunos nmeros han sido extrados de las memorias intermedias, mientras que otros estn esperando a ser asignado despus. Pero hay un informe de la documentacin, demostrando que los nmeros estn todava disponibles para beallocated por el sistema, y esto es justo lo suficiente para fines de auditora. Este mtodo de almacenamiento en bfer est a punto de convertirse en obsoletos. Bfer paralelo Este mtodo de almacenamiento en bfer es simplemente una mejora de la amortiguamiento local extendida, la introduccin de la "puerta trasera", mecanismo con el fin de rellenar los buffers - siempre en el mbito del proceso de trabajo - pero manteniendo el nmero reutilizables en el caso de un retroceso lleva a cabo, al igual que los locales extendidas capacidad tampn. Se utiliza para el almacenamiento de las memorias intermedias de la NRIVSHADOW mesa, y NRIV_LOKAL no como el amortiguamiento local extendida hace. Debido al mecanismo de la puerta trasera, no hay bloqueo establecido sobre el NRIV mesa cuando se la usa, y por lo tanto el tamao del bfer puede reducirse considerablemente, hasta un valor de 1 y an con el aumento de rendimiento considerable en comparacin con el acceso sin almacenamiento intermedio. Cul es el resultado de bfer en paralelo con un tamao de bfer de 1? - Se dibujan los nmeros en orden ascendente, pero sin bloqueos en NRIV, siempre y cuando no se pasa ROLLBACK. - Cuando un rollback ocurre, el nmero de devolucin en el bfer, lo que significa que pueden ser asignados a la vez mucho ms tarde, fuera de secuencia, pero este no es el caso normal, ya que rara vez ocurren retrocesos - Mientras tanto, estos nmeros pueden ser documentadas para la auditora con un informe que muestra que los nmeros estn todava disponibles por debajo del nmero mximo de documentos asignados.

Si el tamao del buffer es mayor que 1, que funciona exactamente igual que el exterior amortiguamiento local extendida, pero internamente su rendimiento es mucho mejor. Este mtodo es recomendado para ser utilizado en lugar del bfer extendido locales siempre que sea legalmente aceptable, y en vista de lo dicho anteriormente, ya sea con un tamao de bfer de uno o ms grande. Se lleva a cabo para las versiones de SAP> = 4.6C y tiene una importante mejora tcnica a partir de su distribucin, 620. Antes de esta mejora tcnica, de la recarga de buffer pasado como en el caso de bfer de memoria principal, en un proceso de DIA de trabajo independiente. Desde Rel. 620 y la nota 1043348, ningn proceso de trabajo independiente que se necesita, ya que la recarga utiliza una conexin de base de datos independiente. Por qu utilizar procesos separados o conexiones? Los programas se ejecutan mediante la aplicacin SAP tienen que cuidar de la integridad de los datos en un proceso de negocio, por ejemplo, una factura o bien debe terminar por completo o no tener lugar en todos. Esto se debe a la aplicacin con el uso de COMMIT WORK o ROLLBACK WORK, respectivamente. Por lo tanto, si la carga de rango de nmero de buffers tiene que emitir un COMMIT WORK, no puede hacerlo en el mismo proceso que la aplicacin solicita los nmeros, de lo contrario sera cometer los datos del proceso antes de tiempo. Paralelo bfer - el "italiano" solucin. Nosotros lo llamamos internamente "italiano" ya que la idea apareci en relacin con un cliente italiano. El principal problema es que, incluso con un tamao de bfer de 1, dependiendo del nmero de serie se han establecido entre el primer nmero y COMMIT o ROLLBACK, si se produce una reversin, uno o ms nmeros se devuelven a la memoria intermedia para su uso posterior. Esto puede ocurrir el mismo da, pero tambin muchos das ms tarde. Estos nmeros se quedara fuera de la secuencia de lo que es contrario a las leyes en Italia y otros pases. Por lo tanto, hemos desarrollado una solucin que sea respaldado y cumple con esta parte de la ley. Los nmeros devueltos en el bfer no se utilizar ms adelante, pero estacionados en una tabla especial llamada NRIV_RESTE documentacin y la aplicacin recibe un nmero nuevo. Se plantean dos preguntas, una menor de edad y una de las principales relativas a esta lgica. La cuestin de menor importancia: al hacer el "extrao" nmeros son ascendidos a NRIV_RESTE?

La respuesta es: cuando el nmero que se han elaborado fuera de secuencia, no antes. Por qu entonces no hacerlo en el momento adecuado, cuando el ROLLBACK? Porque no se puede escribir cualquier cosa a cualquier base de datos, mientras que un ROLLBACK se lleva a cabo. Sin embargo, el programa de documentacin RSSNR0S1 muestra tanto el contenido del buffer y el contenido de NRIV_RESTE, por lo que el momento de la mudanza no juega ningn papel. La pregunta ms importante: si los nmeros que se deshacen no se usan ms, no se parecen un hueco en la numeracin? La respuesta es, s, pero. En este punto es oportuno sealar que las diferencias siempre pueden ocurrir cuando hay algn tipo de accidente inusual, como una interrupcin del proceso de actualizacin. Restauraciones son acontecimientos inusuales en el tipo de programas pertinentes para este problema y debido a algn tipo de error. Esto significa que en los huecos proceso normal nunca se producen. Esto puede no ser fcil de ser aceptado por las auditoras financieras, pero es el camino nico compromiso entre la legalidad y el rendimiento. Nosotros lo llamamos internamente "italiano" ya que la idea apareci en relacin con un cliente italiano. El principal problema es que, incluso con un tamao de bfer de 1, dependiendo del nmero de serie se han establecido entre el primer nmero y COMMIT o ROLLBACK, si se produce una reversin, uno o ms nmeros se devuelven a la memoria intermedia para su uso posterior. Esto puede ocurrir el mismo da, sino tambin despus de muchos das. Estos nmeros se quedara fuera de la secuencia de lo que es contrario a las leyes en Italia y otros pases. Por lo tanto, hemos desarrollado una solucin que sea respaldado y cumple con esta parte de la ley. Los nmeros devueltos en el bfer no se utilizar ms adelante, pero estacionados en una tabla especial llamada NRIV_RESTE documentacin y la aplicacin recibe un nmero nuevo. Se plantean dos preguntas, una menor de edad y una de las principales relativas a esta lgica. La cuestin de menor importancia: al hacer el "extrao" nmeros son ascendidos a NRIV_RESTE? La respuesta es: cuando el nmero que se han elaborado fuera de secuencia, no antes. Por qu entonces no hacerlo en el momento adecuado, cuando el ROLLBACK? Porque no se puede escribir cualquier cosa a cualquier base de datos, mientras que un ROLLBACK se lleva a cabo. Sin embargo, el programa de documentacin RSSNR0S1 muestra tanto el contenido del buffer y el contenido de NRIV_RESTE, por lo que el momento de la mudanza no juega ningn papel. La pregunta ms importante: si los nmeros que se deshacen no se usan ms, no se

parecen un hueco en la numeracin? La respuesta es, s, pero. En este punto es oportuno sealar que las diferencias siempre pueden ocurrir cuando hay algn tipo de accidente inusual, como una interrupcin del proceso de actualizacin. Restauraciones son acontecimientos inusuales en el tipo de programas pertinentes para este problema y debido a algn tipo de error. Esto significa que en los huecos proceso normal nunca se producen. Esto puede no ser fcil de ser aceptado por las auditoras financieras, pero es el camino nico compromiso entre la legalidad y el rendimiento. Para utilizar esta solucin, algunos de personalizacin necesaria, incluyendo la activacin y la codificacin especfica de las salidas de los clientes. La nota relevante es 840901, a continuacin, las notas especficas de FI y SD donde sale existen tales que tambin se mencionan en la nota 840901. Otro efecto secundario de la amortiguacin es la forma en los procesos en paralelo se obtienen los nmeros. Supongamos que hay dos procesos en segundo plano de dibujo de los nmeros el mismo intervalo. Sin necesidad de utilizar el almacenamiento en bfer, que tendr que esperar unos por otros para que un proceso siempre ser obtener los nmeros en secuencia mientras se mantiene el intervalo de exclusividad. Con el almacenamiento en bfer en paralelo en el lugar, la tabla de aplicacin, donde se utilizan estos nmeros, no tendr carencias, pero cada proceso se ayuda a los nmeros sin tener que esperar, cada vez que necesita una, por lo que el nmero recibido no ser el fin sin pausas secuencial. Esto no tiene ninguna consecuencia para el procesamiento normal, pero es importante para el prximo captulo, los aspectos jurdicos de la firma electrnica en Portugal. Caso especial de Portugal 2011: Firma electrnica Esta parte debe ser leda por los consultores que tienen que ver con la firma electrnica de las facturas en Portugal. La normativa portuguesa a la firma electrnica pedir con el nmero anterior factura, la cual tiene que ser sin espacios en blanco, para generar la firma de la factura actual. Esto contradice por completo cualquier intento de bfer en esta rea. Este problema se puede prevenir mediante la generacin de las firmas en un momento ms tarde, cuando todos los nmeros han sido asignados, lo que ya ha sido abordado y existe la solucin. No es sin embargo la prctica ya que muchos clientes deciden imprimir las facturas en el momento mismo de su creacin. La conclusin es que en este momento el almacenamiento en bfer para los nmeros de factura no puede ser utilizado en Portugal. Adrian Alexander trabajo de SAP desde 1994, el desarrollador base

También podría gustarte