FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#11
|
||||
|
||||
Cita:
Enfocate en el PLAN porque esto es lo mas clave. No tengo ni idea de ORACLE, nunca lo he usado pero todos los RDBMS siguen unas lineas universales. Leyendo el plan (y que conste que me voy por pura intuición!): https://docs.oracle.com/database/121...htm#TGSQL94854 1- Estas accesando un servidor REMOTO mediante un link. REMOTE REMOTE Esto me parece que a la larga es lo mas critico. Si el servidor esta fuera de una red interna con una excelente conectividad (donde el Throughput sea constante) esto podria ser una fuente cuasi-invisible de problemas. Las redes tienden a tener velocidad variable, y un analisis de promedios siempre sera errado. Puedes usar una tarea que jale esos datos de forma continua y poner todo local? Ademas, no se como rayos hace ORACLE aqui y si ese LINK es contra otro ORACLE, pero dudo que pueda ver los indices y estadisticas del servidor remoto. 2- NESTED LOOPS es un indicativo que el motor no puede beneficiarse de indices ni de las estadisticas de rendimiento. Esto es RE-MALO, porque es un JOIN que sera EXPONENCIAL: http://use-the-index-luke.com/sql/jo...oin-n1-problem (Enormemente te recomiendo que estudies no solo este link, sino este sitio). 3- TABLE ACCESS FULL TABLE Es un table-scan, o sea, no hay indice ni estadisticas, es menos malo que un NESTED LOOP porque no es un join, y es malo A MENOS QUE los datos que jale sean pocos, sean sequenciales. Esto es lo mas notable del PLAN. Casi siempre los costos de SORT y GROUP seran secundarios y solo parecerán problemas cuando se combinan con table scans y loops. ----------- La clave para el desempeño en toda BD, y en especial, el modelo relacional, es tener un esquema bien diseñado (o sea, SANO). Una BD al igual que un humano es feliz si los datos son UNICOS, ASCENDENTES, DIFERENCIADOS y CONTINUOS. Eso es lo que en términos mas técnicos logra los pasos de normalizar y desnormalizar la información. Luego el uso adecuado de INDICES+NORMALIZACION para el lado de LECTURA, pero para el de INGESTA/ESCRITURA/MASIVO es lo *contrario*: Si puedes prescindir de indices y desnormalizar mucho mejor. Esto es la indicacion de que hacer cuando se esta agregando mucho dato de muchas fuentes con potencialmente ninguna posibilidad de indices y todo eso (por ejemplo, cuando los datos vienen de texto plano): Es mejor poder *TRAGAR RAPIDO* contra una tabla sin indices y desnormalizada, luego *agregar indices* y luego jalar de esa para el resto de los pasos. Asi es como se hace en un datawharehouse. Ahora bien, eso es un batch, y muchas veces si los datos son pocos (unos cuantos GB por ingesta) o se quiere ser "casi tiempo real" entonces lo que debes es armar una "linea fluida de datos (data pipeline)", lo cual es con buen hardware (ideal disco SSD y RAM >32GB) y/o poder jalar en STREAMS constantes particionados. ------- Dejando la teoria: Si el acceso remoto no se puede obviar, intenta DESNORMALIZAR ALLA MISMO!. Ten los datos "pre-amasados" quizas usando una VISTA MATERIALIZADA: https://docs.oracle.com/cd/B10501_01...7/repmview.htm Una vez que tienes los datos preparados, en el lado de lectura revisa el tema de los indices y ten en cuenta lo explicado. ----- Ahora si los datos van a crecer bastante, hacer todo desde el motor puede ser un problema (si ademas ese esta encargado de servir el lado transaccional) y puede que te toque mejor armar un PIPELINE, que es eso? Un programa que de forma continua vaya alimentando la tabla destino desde las de lectura pero fuera del motor y que pueda operar "lento" pero con una rata constante de memoria/cpu. Pero ojo, solo si esto amerita por el aumento constante de la ingesta.
__________________
El malabarista. |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Consulta lenta | DamianG | Firebird e Interbase | 6 | 20-11-2012 14:06:16 |
Consulta sql lenta la primera vez | lledesma | Conexión con bases de datos | 2 | 07-07-2008 11:58:36 |
Ayuda con consulta lenta, lenta, lenta | Gregory Mazon | Firebird e Interbase | 22 | 27-06-2007 09:56:38 |
Consulta muy lenta | Walterdf | Conexión con bases de datos | 2 | 25-08-2004 18:37:57 |
lenta la consulta. | digital | Conexión con bases de datos | 2 | 10-09-2003 15:38:13 |
|