Club Delphi  
    FTP   CCD     Buscar   Trucos   Trabajo   Foros

Retroceder   Foros Club Delphi > Principal > SQL
Registrarse FAQ Miembros Calendario Guía de estilo Buscar Temas de Hoy Marcar Foros Como Leídos

Respuesta
 
Herramientas Buscar en Tema Desplegado
  #21  
Antiguo 12-05-2016
Avatar de mamcx
mamcx mamcx is offline
Moderador
 
Registrado: sep 2004
Ubicación: Medellín - Colombia
Posts: 3.911
Poder: 25
mamcx Tiene un aura espectacularmamcx Tiene un aura espectacularmamcx Tiene un aura espectacular
Cita:
Empezado por jnavapal Ver Mensaje
Plan
INSERT STATEMENT ALL_ROWSCost: 132.612 Bytes: 287 Cardinality: 1
9 SORT GROUP BY Cost: 132.612 Bytes: 287 Cardinality: 1
8 HASH JOIN ANTI Cost: 132.611 Bytes: 287 Cardinality: 1
6 NESTED LOOPS Cost: 6.437 Bytes: 252 Cardinality: 1
4 NESTED LOOPS Cost: 6.436 Bytes: 244 Cardinality: 1
2 SORT UNIQUE Cost: 202 Bytes: 704.256 Cardinality: 44.016
1 TABLE ACCESS FULL TABLE temp_polizas Cost: 202 Bytes: 704.256 Cardinality: 44.016
3 REMOTE REMOTE SERIAL_FROM_REMOTE MENSUAL CONSULTA.WORLDCost: 1.073 Bytes: 228 Cardinality: 1
5 REMOTE REMOTE SERIAL_FROM_REMOTE TABLAGRANDE Cost: 1 Bytes: 8 Cardinality: 1
7 TABLE ACCESS FULL TABLE TABLA_A Cost: 126.173 Bytes: 996.030 Cardinality: 28.458
Yo creo que entiendo lo que estas intentando. Estas recolectando datos de multiples fuentes para (me imagino) hacer reporteria en base a eso. Algo muy tipico, pero que siempre se enfrenta a los lios de tener mas datos de lo que se puede tragar.

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.
Responder Con Cita
  #22  
Antiguo 12-05-2016
jnavapal jnavapal is offline
Miembro
NULL
 
Registrado: may 2016
Posts: 10
Poder: 0
jnavapal Va por buen camino
Guau . Me pongo ahora mismo a estudiar todo lo que me mandas.

Muchisimas gracias por el tiempo que te ha tomado.

Actualizare con lo que logre.

Si alguien tiene alguna otra idea , estoy abierto a mas sugerencias.
Responder Con Cita
  #23  
Antiguo 30-05-2016
Avatar de rastafarey
rastafarey rastafarey is offline
Miembro
 
Registrado: nov 2003
Posts: 927
Poder: 21
rastafarey Va por buen camino
Divide y vencerás, esa es la idea que puedo ofrecerte. Te imaginas una vez soluciones ese problema y tengas una instruccion Sql de ese tamaño, pasado tres meses tengas que solucionar algún error en la aplicación que tenia ducha consulta, tu crees que vas a entender que hacia ducha consulta, a menos que la documentes muy bien. Solo digo que es preferible trabajar un poco mas y dividir hasta donde nos permita la aplicación, la ingeniería del software y el análisis y diseño de sistemas, ya que el 60% del tiempo se consume en mantenimiento, osea mas que el desarrollo. Que quiero decir con esto que debemos poner esfuerzo en que nuestras aplicaciones sean fácil de mantener y modificar para que tengan una vida util.

Enviado desde mi SM-G900H mediante Tapatalk
__________________
Todo se puede, que no exista la tecnología aun, es otra cosa.
Responder Con Cita
  #24  
Antiguo 30-05-2016
Avatar de fjcg02
[fjcg02] fjcg02 is offline
Miembro Premium
 
Registrado: dic 2003
Ubicación: Zamudio
Posts: 1.408
Poder: 22
fjcg02 Va camino a la fama
Hola,
yo haría lo siguiente:
1.- Ejecutar la consulta sólo, ya te meterás con el insert luego.
2.- Tomar el tiempo
3.- Cambiar los EXISTS y NOT EXISTS por cláusulas left join o similar. Te supondrá un poco de trabajo pero creo que puede ser más efciente.
4.- Una vez hecho esto, probar a cambiar el orden de las cláusulas de las where, para ver si dependiendo del mismo te utiliza índices o no.

Si no sabes cómo, pregunta.

Ya nos dirás.

Saludos
Código SQL [-]

INSERT  INTO TABLA_A ( RPC_PER_RES, RPC_COD_EST, RPC_COD_BASE, RPC_COD_RES,
        RPC_COD_PROD, RPC_COD_POLI, RPC_COD_COBE,
        RPC_NUM_HOM, RPC_RES_HOM, RPC_EDAD_HOM,
        RPC_OBS_STAT, RPC_COD_LOB, RPC_COD_CHANNEL, RPC_COD_CLASE, RPC_COD_SUN)
        SELECT periodo,     pEstado, 'COL', 'RK',
        decode(a.riesgo_principal,'ca','c', a.riesgo_principal),
         poliza, cobertura,
        COUNT(distinct GRUPO||IDOPERACION||nvl(NUMEROASEGURADO,0)||nvl(NUMEROCARGA,0)),
        sum(nvl(cap_inicuf,0)),
        sum(trunc(months_between(last_day(to_date(periodo,'yyyymm')),fechanac)/12))/count(*),
        'VALORES A' ,
        lineanegocio, canaldeventa, ideerr, CODINTEGRACION
        from  TABLAGRANDE a, MENSUAL h
        where periodo = pPeriodo
        AND NVL (aquienafecta, 'x') <> 'P'
        AND NVL(aju_afecto,0) = 0
        AND NVL(aju_exento,0) = 0
        AND EXISTS ( SELECT NULL
                 FROM temp_polizas iwf
                 WHERE iwf.lineanegocio != 5
                 AND iwf.poliza = h.poliza
                 AND iwf.periodocobro != 'U'
                 AND RIESGO != 'DG' )
        AND NOT EXISTS  (SELECT RPC_COD_POLI
                                        FROM TABLA_A
                                        WHERE RPC_PER_RES = pPeriodo
                                        AND RPC_COD_EST = pEstado
                                        AND RPC_COD_BASE = 'COL'
                                        AND RPC_COD_RES = 'RK'
                                        AND RPC_COD_PROD = producto
                                        AND RPC_COD_POLI = to_char(poliza)
                                        AND RPC_COD_COBE = to_char(cobertura) )
        AND add_months(h.hasta, nvl(PRIMAMESESDELTA,0)) >= LAST_DAY (TO_DATE (pPeriodo, 'yyyymm'))
        AND a.RIESGO = h.RIESGO
        group by periodo,
        decode(a.riesgo_principal,'ca','c', a.riesgo_principal),
        poliza, cobertura,
        lineanegocio, canaldeventa, ideerr, CODINTEGRACION ;
__________________
Cuando los grillos cantan, es que es de noche - viejo proverbio chino -
Responder Con Cita
Respuesta


Herramientas Buscar en Tema
Buscar en Tema:

Búsqueda Avanzada
Desplegado

Normas de Publicación
no Puedes crear nuevos temas
no Puedes responder a temas
no Puedes adjuntar archivos
no Puedes editar tus mensajes

El código vB está habilitado
Las caritas están habilitado
Código [IMG] está habilitado
Código HTML está deshabilitado
Saltar a Foro

Temas Similares
Tema Autor Foro Respuestas Último mensaje
Consulta lenta DamianG Firebird e Interbase 6 20-11-2012 15:06:16
Consulta sql lenta la primera vez lledesma Conexión con bases de datos 2 07-07-2008 12:58:36
Ayuda con consulta lenta, lenta, lenta Gregory Mazon Firebird e Interbase 22 27-06-2007 10:56:38
Consulta muy lenta Walterdf Conexión con bases de datos 2 25-08-2004 19:37:57
lenta la consulta. digital Conexión con bases de datos 2 10-09-2003 16:38:13


La franja horaria es GMT +2. Ahora son las 16:45:29.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi
Copyright 1996-2007 Club Delphi