Demora al mostrar"Gestión de Informes y de Layout"

Expertos muy bueno días, hoy les cuento que tengo un problema que se genero en base a otro, el primer inconveniente era el de subir un reporte en cristal Reports el cual no permitía cargarlo, este caso lo soluciono mi partner, pero desde entonces eh tenido este otro problema para mostrar la ventana o interfaz de “Gestión de Informes y de Layout”, tarda casi 5 minutos en mostrarse, alguien tuvo un problema asi?

No me ah pasado, de hecho me parece curioso, ya que en teoria el reporte que subio tu partner no tiene ninguna intervencion con el sistema hasta que lo mandas llamar por alguna situacion, lo que me lleva a la pregunta de cajon.
¿Solo tienes demora en el sistema cuando consultas los formatos de layout?
Se me ocurre que si la respuesta es no y el sistema esta en general algo lento, pudieras revisar que tan crecido esta el proceso de SQL en el Servidor, si tu servidor esta algo limitado y el proceso esta muy arriba podria generar lentitud, lo cual solucionarias temporalmente con un reinicio, y definitivamente quiza con algo mas de RAM.
En realidad solo especulo, algo mas de informacion nos ayudaria a ayudar.
Saludos.

Emontiel, gracias por responder, en efecto los reportes tardan un cuantos segundos mas de los normal en mostrarse, en cuanto al hardware la ram esta al 70% de los 128Gb de RAM, Me podrías explicar a que te refieres con “Procesos de SQL”? solo tengo esta imagen del rendimieno del servidor.

saludos.

Con gusto, para empezar, veo que tu servidor es HANA, el mio corre con SQL, pero la base teorica es la misma, aunque no asi el como hace las consultas el manejador de base de datos.
Para empezar, un servidor HANA, requiere una gran cantidad de RAM, ya que las consultas a la BD se realizan en la “RAM”, de ahi que sean mas rapidas, a comparacion de SQL que hasta su version 2017 se realizaban en disco duro.
Ahora si, lo que trate de explicar inicialmente es que el SQL, genera un proceso, que va creciendo “ocupando mas memoria” conforme se va usando, Pj, en mi caso usualmente inicia en 8,000 KB y al momento de la captura a crecido a 3,592,404 KB. Eh notado que cuando se le da un uso extenuante al servidor, por ejemplo contabilizacion de stock’s mas el uso normal, suele llegar a mas de 10,000,000 KB, y comienzan a tardar en general todos los procesos de SAP, esto por la cantidad de accesos y consultas a la BD, en pocas palabras entre el procesador y la RAM del servidor no pueden con el trabajo, por lo cual en inventarios simplemente SAP no esta habilitado para otra cosa que el inventario, misma situacion cargando listas de precios, etc, la solucion para cuando esto sucede y la cantidad de RAM usada por el proceso de SQL “sqlservr.exe” no vuelve a un tamaño mas razonable es, dependiendo como la situación lo permita. Reiniciar el servidor, o si no es posible por la operación, reiniciar solo el proceso, igual interrumpe la operación pero por menos tiempo.
imagen
Honestamente desconozco en HANA como hacer algo similar pero estoy bastante seguro de que por ese rumbo estara la solucion a tu problema de velocidad, ojala y sigas alimentando este post para aprender mas al respecto.
Al finalizar de escribir esto el consumo de RAM va en 3,618,708KB. Y asi seguira hasta estabilizarse o bien suceda que ya no tenga mas ram que consumir y tenga que recurrir a los metodos mencionados para liberar la memoria. En mi caso la solucion es mas RAM para que pueda crecer hasta su punto óptimo.
Como nota y para finalizar, hace un tiempo estuve cotizando servidores para migrar a HANA, y son muy especificos con respecto a los servidores certificados para HANA y las caracteristicas del mismo en base a la cantidad de transacciones diarias y simultaneas que realizas, tomando en cuenta que 128 es el minimo de RAM del servidor certificado que puedes encontrar quiza la empresa y transacciones han crecido lo suficiente para ampliar a 256 para que el Srv este en su punto optimo.
Saludos!

1 me gusta

Este tema se cerró por inactividad por parte del autor.

Copia la URL de este debate, y abre un nuevo tema en #feedback si:

  • El autor del debate no marcó ninguna respuesta como solución, y tú crees tener la solución
  • Crees tener otra solución a la que actualmente está marcada.

Si, en cambio tienes una duda parecida a la que se debatió, o la misma duda, abre un nuevo tema en la categoría que corresponda y pon que el tema se debatió oportunamente (pega el enlace a este debate), así los otros lectores pueden saber de qué hablas.

Ayúdanos a tener una comunidad organizada.