on 09-29-2010 2:50 PM
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
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
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.
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
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
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.
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?
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!
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
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
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
User | Count |
---|---|
85 | |
7 | |
6 | |
4 | |
3 | |
3 | |
3 | |
3 | |
3 | |
2 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.