Bueno, solo vengo a decir que la porqueria con la que estoy luchando sigue tardando 6 hs en prod, en los otros ambientes anda de 10, seguro es algo con el servidor, pero los DBA oficiales estan de vacaciones

Llego un IBM System-X 3500 a la oficina.

2 Intel Xeon E5620 (total 8 cores, 16 theads), 8gb RAM, 3 x 500Gb SAS

La primera decision fue virtualizarlo para reemplazar dos PC comunes que estaban funcionando como server de desarrollo y Domain Controller.

Vino la gente "especializada" a instalarle Xen y toda la bola y dejar 2 virtuales con Windows Server 2008 instalado. (Teniamos otras prioridades y no queriamos perder tiempo en hacerlo nosotros, teniendo que aprenderlo desde cero)

Empezamos a hacer las pruebas para la migracion del entorno de desarrollo y resulta que un Pentium 4 con 1GB de RAM tenia 10 veces mejor rendimiento...



Bueno, ya fue, me pongo a verlo yo. Primera busqueda en google me lleva a un "Xen Best Practices"... Me empiezo a fijar y estaba todo hecho alreves de lo que decia ese documento...

Reconfigurando todo, asignando mejor la memorias, las cpus, recien ahora estamos hablando de un mejor rendimiento...

Un motivo mas para cagarnos a tiros con los muchachos "especialistas" y van...

teniamos un sistema en mi anterior laburo que tenia una funcionalidad de inventario

tenia que leer de un txt que armaban los chabones pistoleando mercaderia, y tenia que procesarlo y marcar las diferencias, y resolverlas


me fui y todavia no esta arreglado jauajaujau que mal hecho que estaba

ademas de que calculaba mal las diferencias


yo lo mejoré bastante, habia encontrado que por cada producto que leia levantaba todos los productos de la base son mas de 20.000 productos
mejoro pero igual andaba mal, me fui, nose como siguio la cosa

(19-09-2013 22:17)shadow_mx escribió:  Bueno, solo vengo a decir que la porqueria con la que estoy luchando sigue tardando 6 hs en prod, en los otros ambientes anda de 10, seguro es algo con el servidor, pero los DBA oficiales estan de vacaciones

Es seguro que es por el volumen de datos. Si no esta bien pensado algun cursor cuando el volumen aumenta mucho la performance se va al tacho.

(28-09-2013 12:50)Abend escribió:  

(19-09-2013 22:17)shadow_mx escribió:  Bueno, solo vengo a decir que la porqueria con la que estoy luchando sigue tardando 6 hs en prod, en los otros ambientes anda de 10, seguro es algo con el servidor, pero los DBA oficiales estan de vacaciones

Es seguro que es por el volumen de datos. Si no esta bien pensado algun cursor cuando el volumen aumenta mucho la performance se va al tacho.

No es volumen, en uno de los otros ambientes donde anda bien tiene el doble de datos. Ya pense eso, es algo de configuracion de ese ambiente.

Faltaran indices?

(29-09-2013 14:13)brunodiaz escribió:  Faltaran indices?

Nu, tiene los mismos indices en los 3 ambientes, segun el plan el costo es alto, pero no tanto como para que tarde 20 minutos el query. Estoy esperando que vuelva el DBA el martes asi lo mira y lo arregla xD

O sea que:
- Las otra base tienen la más info que la que está lenta
- En las dos tiran las mismas querys
- Las dos tienen exactamente la misma estructura (tablas, indices, etc)

¿Están configurados exactamente igual ambos ambientes?
¿Con alguna otras querys están teniendo problemas de performance en ese server?
¿La DB es el unico servicio importante que tienen levantado allí? Si la respuesta es no ¿Cual es la performance de los otros servicios?
¿Chequearon el estado general del server cuando se ejecuta la query?
¿Probaron apagando y prendiendo ? :troll:

+1 a que es un problema del servidor.

(29-09-2013 15:03)Imakuni escribió:  O sea que:
- Las otra base tienen la más info que la que está lenta
- En las dos tiran las mismas querys
- Las dos tienen exactamente la misma estructura (tablas, indices, etc)

¿Están configurados exactamente igual ambos ambientes?
¿Con alguna otras querys están teniendo problemas de performance en ese server?
¿La DB es el unico servicio importante que tienen levantado allí? Si la respuesta es no ¿Cual es la performance de los otros servicios?
¿Chequearon el estado general del server cuando se ejecuta la query?
¿Probaron apagando y prendiendo ? :troll:

+1 a que es un problema del servidor.

En el mismo orden:
Si
si
Si
Hay un parametro de compatibilidad distinto el el lento, pero nadie se anima cambiarlo sino viene la "dueña" de la Base
No
No y vimos problemas con otras cosas
Hay picos altos de acceso a disco cuando se ejecuta el query, pero segun el server admin estan dentro de los valores normales.
No probe, hay muchas cosas ahi, pero en cualquier momento pido acceso al data y lo agarro con un hacha jaja

Respecto a tu problema de base necesitas la info en query o con un select de un dump te sirve también.

Yo soy desarrollador java, pl sql y me a tocado en un momento un proyecto de crear 4 vistas para datawarehouse tomando información de la base sobre mas de 20 tablas con lógica por inconsistencias en la base y demás. Y nos rebotaban el proyecto por el tema de tiempos porque tardaba horas en producción para visualizar todos los datos, y en los otros ambientes no (a esto el área que trabajo es telecomunicaciones).

Después de unas ideas y vueltas con el cliente, nos sentamos y le preguntamos si necesita los datos del momento que ese era el problema porque al ser producción el motor se quedaba a la espera de que liberasen los registros tomados.
Depende de la configuración de la base de datos pero cuando alguien lee o modifica un registro puede quedar loqueado hasta que la persona responsable lo libere -_-

Solucionamos el problema generando un batch que corre a la noche, que trunca 4 tablas, y la carga con la info que estaban pidiendo.

Saludos.

Cita:Solucionamos el problema generando un batch que corre a la noche, que trunca 4 tablas, y la carga con la info que estaban pidiendo.

Y porque no hicieron una vista materializada para eso? (Pregunto de ignorante)

Solución valida también.

Pero no tan simple, primero en producción hay inconsistencias que no sos simplemente resueltas por hacer una query compleja, sino que hay que aplicar un manejo de errores que es mas simple al realizar la carga individualmente con consultas mas pequeñas que se pueden concatenar en un proceso y con manejo de excepciones.
Para que hagas una idea, la versión primera versión simple usaba alrededor de 342 lineas cada una de las query y tenia varias inconsistencias.

Segundo es mucho mas sencillo manipular la configuración de un batch que esta almacenada y es configurable, que el de una vista materializada por cada alter que tenes que hacer a la vista implica un pasaje a la base de datos en producción que no es propia sino del cliente.

Saludos.