cancel
Showing results for 
Search instead for 
Did you mean: 

Performance SAP

Former Member
0 Kudos

Buenos días

Tengo el siguiente escenario

Server: 2 QuadCore, 8 GB RAM, Array HD 5+1 (1 TB), Windows Enterprise

BD: 74 GB de tamaño, Customers 54000, Items 46000, Sales Orders 195000, 2 años de información, 64 usuarios, SAP BO 2007A PL 42, SQL Standard Edition

Todos los artículos tienen descuento y están creadas las listas de descuento en Descuentos especiales por precio y cantidad.

Esto lo pongo como antecedente por lo siguiente

Por ejemplo, si quiero agregar un artículo al módulo de descuentos en horas laborales, se empiezan a "trabar" estaciones con SAP.

Así hay varias veces que el sistema parece que se congela y luego los usuarios empiezan a llamar. No solamente con este proceso que les menciono, por ejemplo si agrego un artículo a Lista de Precios de Socios de Negocios, también sucede eso.

¿Estará al límite de su capacidad mi SAP BO? ¿Que sugieren que revise / actualice / amplíe?

Me han dicho que el SAP BO 8 es mucho más rápido y también me han comentado que separe la base de datos a otro servidor donde instale SQL Server 64 Bits y le aumente memoria.

¿Que opinan? Les agradeceré mucho sus comentarios

Saludos

Accepted Solutions (1)

Accepted Solutions (1)

former_member188440
Active Contributor
0 Kudos

Yo te sugeririra lo siguiente

1. Trata de aumentar la memoria RAM, nosotros tenemos 12 GB de RAM con el Win Enterprise y lo soporta sin broncas

2. La parte medular del asunto me parece que es la cantidad de informacion que has guardado en 2 años de trabajo, creo que te URGE un depurado del log de modificaciones para asi reducir el tamaño de la base de datos.

3. Nosotros estamos por migrar a la version 88 y si te comento que es mas rapida, el archivado de datos tambien es algo que te puede ayudar, esto viene incluido en la nueva version y sin duda mejorara significativamente tu performance, aunque para este punto , el escenario de pruebas debe ser considerado con mucha anticipacion sobre todo por el tamaño de tu base

4. NO ha alcanzado el limite tu SBO, mas bien creo que es un tema de mantenimiento a tu server.

Former Member
0 Kudos

Gracias Mauricio

Una pregunta, al momento de borrar el log de moficiaciones, según leí lo pongo en 0, salgo del sistema.

Reingreso al sistema, hago alguna actualización y empieza a borrarse el log.

¿Es correcto?

Además, qué significa por ejemplo que en el log de modificaciones pogna 10,100 o 1000?

Actualmente lo tengo a 100

former_member188440
Active Contributor
0 Kudos

OK en primerisimio lugar, JAMAS hagas eso en horario de concurrencia pues alentaras el sistema de manera extraordinaria

No necesitas salir y reiniciar el sistema, el cambio es automatico, prueba primero con una tabla por ejemplo de Socios de negocios.

El tema medular aqui es que el hacer esto genera unos DELETEs sobre las tablas de historial (las que comienzan con A) situacion que provoca que tu log de transacciones (archivo ldf) crezca considerablemente.

Former Member
0 Kudos

Ok, así lo hago sin usuarios.

Después puedo compactar la base de datos y truncar el log, ¿ es correcto?

former_member188440
Active Contributor
0 Kudos

Asi es, seguramente las tablas que mas debes eliminar son la ADOC,ADO1,AITW,AITM,AJDT, las de transacciones, necesitas bastante espacio en disco, pues por el tamaño de la base seguro puro log puede crecer mas de 10GBs por tabla

Former Member
0 Kudos

Solamente para corroborar, después de poner en 0 el log, tengo que actualizar algún dato de cada tabla?

Es decir, actualizar un item, un socio de negocios, una orden de venta, etc...?

former_member188440
Active Contributor
0 Kudos

Efectivamente, objeto por objeto, por eso es importantisimo el espacio en disco y que no haya usuarios conectados.

Yo te recomiendo que luego de que actualices las tablas de transacciones, hagas un shrink de la base para que se libere espacio fisico de la base y un shrink del log, para que te quede en 512kb

Former Member
0 Kudos

Gracias, una pregunta, ¿como puedo saber si no me falta de actualizar algo?

Esto lo voy a hacer el fin de semana, pero no quiero que se me olvide actualizar algo y el Lunes, se actualice y congele el sistema.

former_member188440
Active Contributor
0 Kudos

Bueno, creo que puedes , de acuerdo al numero de transacciones que maneja tu empresa, tener una idea de que objetos o documentos debes actualizar.

Para que no te pase que se congele el sistema, es importante que antes de que cualquier usuario entre al sistema, regreses el valor del log a 99, o si sabes que ya no necesitaran el log, pues dejalo en 0 y ya, no lo recomiendo, pero tambien puedes trabajar asi con el log en 0

Former Member
0 Kudos

Rodolfo, ya que le daras mantenimiento a tu server el fin de semana quiero comentarte lo siguiente para que abone a tu trabajo, tengo una base de 90Gb con informacion de 5 años y el performance ha estado normal en los ultimos meses.

De moverte a un SQL 64bits, no se siente la diferencia sustancialmente, yo lo hice y no senti ningun cambio, se viera cambio si tus clientes fueran procesadores 64bits tambien, pero ni aun asi.

De incrementar la memoria al server? unicamente verifica si el windows instalado hasta cuanto te reconoco, hay algunos que solo reconocen 4Gb de RAM aunque tengas 8.

Lo que si hice y me ha funcionado, es mover el log de transacciones a otro disco, te puedes comprar un disco externo de 1Tb USB y tener en el disco del server tu archivo de la base .ldf

ademas, si haces respaldos diarios hacerlo que caigan en este disco USB, asi le bajas la carga al disco del server.

Otra cosa muy importante, en ese server que tienes la base de datos, unicamente debe de estar corriendo SAP y nada mas, ya con esa cantidad necesitas todo el recurso para tus transacciones y no tener ahi el servidor de correos y el servidor de archivos.

Espero te sirva algo.

Saludos Cordiales.

Nelson Guerrero.

Former Member
0 Kudos

Muchas gracias por tu consejo Nelson.

Es un gran tip, lo voy a hacer así.

Una pregunta, en el server tengo dos arreglos de discos en dos diferentes canales de la tarjeta raid. En uno está el SAP y SQL y en el otro están la base de datos y los logs.

Lo que sugieres es que el archivo de logs lo pase al otro arreglo o de plano a un disco usb?

No corro más riesgo en el USB?

former_member188440
Active Contributor
0 Kudos

Al ser Windows Enterprise si te reconoce mas de 4GB, por eso no debes tener broncas en meterle fisicamente mas.

El colega menciona que tiene 90 Gb en 5 años de operacion, imagina cuanto tendras en 5 años si tu tienes mas de 70 en 2 años.

Lo q mas nos ha funcionado a nosotros es manejar 3 particiones de discos, por ejemplo en C: Unica y exclusivamente el Windows, en disco 😧 Aplicaciones y en disco E: Datos, siendo esta ultima la de mayor espacio en disco.

Cuentanos como te va

Saludos!

Former Member
0 Kudos

Rodolfo, ten claro que en el server debes de tener RAID 5 de preferencia.

No corres riesgo en el USB, en lo absoluto, al contrario, acabo de perder un server de produccion se me dañaron dos discos de la base de 90Gb y gracias al USB que ahi caen los respaldos pude hacer la restauracion en un dia.

Asi claramente, el MDF queda en el C: y el LDF queda en el USB, es lo que te recomiendo.

quedo a tus ordenes.

Saludos

Nelson Guerrero

former_member188440
Active Contributor
0 Kudos

Otra cosa que es importante es el modo de recuperacion que tienes en tu base de datos de SBO, SAP recomienda que sea simple el modo de recuperacion ademas de que tengas tus planes de mantenimiento adecuados.

Former Member
0 Kudos

Gracias, oye ¿que pasa si se cae el USB?

¿No se puede trabajar en SAP?

Former Member
0 Kudos

Recuerda que ahi unicamente esta el log y no la data que es lo mas importante. ya tengo 4 meses trabajando asi.

Former Member
0 Kudos

Gracias así lo haré.

Una pregunta, un archivo de log de 384 MB es correcto?

Gracias

Former Member
0 Kudos

Rodolfo, es muy normal, los tamaños fisicos que manejo en mi base es el MDF tiene 92Gb y el LDF tiene 14Gb. duerme tranquilo!

Nelson

former_member188440
Active Contributor
0 Kudos

Otro dato que debes tener en cuenta tambien es el de la base de datos TEMP, que es propia de SQL, esta base tambien crece mucho cuando haces estos trabajos de mantenimiento, o por una migracion etc. Lo que tambien debe llevarte a reiniciar el servicio de SQL Server a fin de reducir el tamaño de la base de datos TEMP. Investiga bien lo que te comento del modo de recuperacion, pues si se daña tu archivo LOG, aunque no tengas los datos ahi, dificilmente podras restaurar una base de datos sin el modo de recuperacion es FULL

Former Member
0 Kudos

Así es, el Recovery Model es Simple

Después de todo el mantenimiento reinicio SQL Server y después también hago el Shrink Database y supongo que tengo que ejecutar el Sp_UDATESTATS, ¿es correcto?

Gracias por su ayuda... les platico como me fue el Lunes

Former Member
0 Kudos

Gracias, espero dormir bien todo este fin de semana

El lunes les platico como me fue.

Saludos

Former Member
0 Kudos

Hola amigos:

Les comento mi fin de semana

La base de datos se redujo de 76 GB a 21 GB, se tomó cerca de 22 horas la compactación. El log creció a 182 GB. Después al momento de querer compactar la base con DBCC SHRINKDATABASE me marcaba un error de "Could not allocate" y los nombres de los archivos. Hice un google y ví que cuando compactas mucho una base, a veces te marca ese error. Se soluciónó con un FULL BACKUP.

Después empecé a borrar también las autorizaciones históricas lo que también me llévó un buen rato.

Corrí el SP_UPDATESTATS

Vamos a ver cómo se comporta todo este día

Para hoy en la noche me queda mover el log al disco externo USB ya que no me dió tiempo

Saludos y muchas gracias por los consejos

Answers (0)