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
  #1  
Antiguo 20-09-2006
Avatar de Kipow
Kipow Kipow is offline
Miembro
 
Registrado: Apr 2006
Ubicación: Guatemala
Posts: 328
Poder: 12
Kipow Va por buen camino
Firebird, No siempre utiliza el mismo PLAN?

Bueno les quiero comentar algo que me paso y me hizo quebrarme la cabeza, hasta que di con el punto.

Tenia 2 consultas generadas en 2 bases de datos identicas, en la primera demoraba 30seg y en la segunda 3ms,

revisando las estrucuras y la informacion de ambas eran identicas
Luego utilizando el IB PLANalyzer pude constatar que no estaba utlizando el mismo PLAN en ambas consulta, porque?

Mi solucion fue colocarle manualmente el PLAN a la consulta mas tardada y listo, pero esto me deja en que pensar porque puede ser que en algunas instalaciones que he realizado del mismo sistema, pueda tener este tipo de problemas.

Alguien sabe porque pasa esto?

Saludos
Responder Con Cita
  #2  
Antiguo 20-09-2006
Avatar de Casimiro Notevi
Casimiro Notevi Casimiro Notevi is offline
Moderador
 
Registrado: Sep 2004
Ubicación: En algún lugar.
Posts: 27.759
Poder: 10
Casimiro Notevi Tiene un aura espectacularCasimiro Notevi Tiene un aura espectacular
Cita:
Empezado por Kipow
Bueno les quiero comentar algo que me paso y me hizo quebrarme la cabeza, hasta que di con el punto.

Tenia 2 consultas generadas en 2 bases de datos identicas, en la primera demoraba 30seg y en la segunda 3ms,

revisando las estrucuras y la informacion de ambas eran identicas
Luego utilizando el IB PLANalyzer pude constatar que no estaba utlizando el mismo PLAN en ambas consulta, porque?

Mi solucion fue colocarle manualmente el PLAN a la consulta mas tardada y listo, pero esto me deja en que pensar porque puede ser que en algunas instalaciones que he realizado del mismo sistema, pueda tener este tipo de problemas.

Alguien sabe porque pasa esto?

Saludos
Efectivamente, para bases de datos iguales, pueden variar los planes.
Son varios los factores que firebird tiene en cuenta, los índices, las estadísticas de los índices implicados, incluso la cantidad de campos a devolver o el número de registros en la tabla.

Me he encontrado, a veces, con casos "inexplicables", como relatas, y con IBplanAnalizer (estupenda herramienta) he pasado horas buscando el motivo de que en una base de datos tarde una consulta 1 segundo y al día siguiente tarde 20 minutos.
Normalmente se soluciona haciendo la consulta de otra manera, poniendo antes un inner join que otro, pidiendo unos campos antes o después que otros, etc.
Otras veces, la mayoría, basta con añadir un índice nuevo y todo vuelve a la normalidad.
En fin, se trata de "afinar" al máximo, cuantos más tablas, más datos, consultas más "grandes", etc es necesario afinar más.
Responder Con Cita
  #3  
Antiguo 21-09-2006
Avatar de vtdeleon
vtdeleon vtdeleon is offline
Registrado
 
Registrado: Apr 2004
Ubicación: RD & USA
Posts: 3.236
Poder: 17
vtdeleon Va por buen camino
Se agradece a ambos por los datos que desconocia.

Saludos
Responder Con Cita
  #4  
Antiguo 21-09-2006
Avatar de Kipow
Kipow Kipow is offline
Miembro
 
Registrado: Apr 2006
Ubicación: Guatemala
Posts: 328
Poder: 12
Kipow Va por buen camino
Bueno

Yo me percate de este problema luego de que un cliente me llamo indicandome que una funcion del sistema estaba demasiado lenta, entonces revise el Query y lo reestructure (obvio esto lo hice sobre una copia), en esta copia todo funciono perfectamente, luego al realizar la correccion en la Base de Produccion no tuvo el mismo efecto. hasta que revise los planes y opte por asignar los planes manualmente, realmente no se que tan aconsejable sea esto pero me funciono bien y pienso revisar todo el software para colocar planes fijos en consultas demasiado extensas (aprox. 400)

Slds
Responder Con Cita
  #5  
Antiguo 27-09-2006
Avatar de AGAG4
AGAG4 AGAG4 is offline
Miembro
 
Registrado: Aug 2004
Ubicación: Los Mochis, Sinaloa, México
Posts: 1.419
Poder: 15
AGAG4 Va por buen camino
????

Ya que mencionas mucho los PLANES, porque no comentas como dejastes el PLAN y como le hicistes ????
Y como aconsejas dejarlos, con un tamaño grande ó pequeño ????Sinceramente no estoy documentado acerca de los planes que usa firebird.

Última edición por AGAG4 fecha: 27-09-2006 a las 03:12:10. Razón: Corrección
Responder Con Cita
  #6  
Antiguo 27-09-2006
Avatar de Casimiro Notevi
Casimiro Notevi Casimiro Notevi is offline
Moderador
 
Registrado: Sep 2004
Ubicación: En algún lugar.
Posts: 27.759
Poder: 10
Casimiro Notevi Tiene un aura espectacularCasimiro Notevi Tiene un aura espectacular
Cita:
Empezado por AGAG4
Ya que mencionas mucho los PLANES, porque no comentas como dejastes el PLAN y como le hicistes ????
Y como aconsejas dejarlos, con un tamaño grande ó pequeño ????Sinceramente no estoy documentado acerca de los planes que usa firebird.
El plan es la "estrategia" que usa firebird para realizar la consulta que se le pide, por ejemplo:
Código:
PLAN SORT (JOIN (TAR INDEX (FK_NEW_TABLE),PER INDEX (RDB$PRIMARY78)))
Según las tablas, campos, índices, etc. implicadas en la consulta, él decide qué es mejor para realizarla y usa ese "plan" u otro, según crea que puede ser mejor.
A veces puede seleccionar un plan que no es el mejor.
Responder Con Cita
  #7  
Antiguo 28-09-2006
Avatar de Kipow
Kipow Kipow is offline
Miembro
 
Registrado: Apr 2006
Ubicación: Guatemala
Posts: 328
Poder: 12
Kipow Va por buen camino
Efectivamente Casimiro, Firebird no siempre toma el mejor plan, he estado investigando y una forma de hacer que el motor tome nuevamente su rumbo en cuanto a establecer el mejor plan para una consulta es simplemente recalcular las estadisticas de los indices.
Responder Con Cita
  #8  
Antiguo 28-09-2006
Avatar de AGAG4
AGAG4 AGAG4 is offline
Miembro
 
Registrado: Aug 2004
Ubicación: Los Mochis, Sinaloa, México
Posts: 1.419
Poder: 15
AGAG4 Va por buen camino
Más Claro que el Agua no pudo haber quedado, Gracias por despejarme de esa duda acerca de los Planes de firebird.
Responder Con Cita
  #9  
Antiguo 29-09-2006
Avatar de Kipow
Kipow Kipow is offline
Miembro
 
Registrado: Apr 2006
Ubicación: Guatemala
Posts: 328
Poder: 12
Kipow Va por buen camino
Cita:
Empezado por AGAG4
Más Claro que el Agua no pudo haber quedado, Gracias por despejarme de esa duda acerca de los Planes de firebird.
algo sarcastico, pero bueno te comento yo tampoco soy un experto en la materia y realmente existe Documentacion espero que te sea util, a mi me ha sido bastante util.

Mi problema se dio a raiz de una migracion de datos, ahi fue donde empezo el problema, lo solucione al principio colocandole manualmente los planes a la las consultas principales, luego investigando cai en la solucion de crear un SP para poder recalcular la Selectivity de los indices, el codigo del SP es el siguiente:

Código:
 
CREATE PROCEDURE MANTENIMIENTO_INDICES
AS
DECLARE VARIABLE S VARCHAR(200);
BEGIN
   FOR
      SELECT RDB$INDEX_NAME
      FROM RDB$INDICES INTO :S
   DO
   BEGIN
      S = 'SET statistics INDEX ' || s || ';';
      EXECUTE STATEMENT :s;
   END
   SUSPEND;
END
Otro consejo sano, es revisar siempre las consultas complejas con el IBPLANalyzer

My 2 Cents
Responder Con Cita
  #10  
Antiguo 01-03-2008
Avatar de Al González
[Al González] Al González is offline
In .pas since 1991
 
Registrado: May 2003
Posts: 5.499
Poder: 22
Al González Es un diamante en brutoAl González Es un diamante en brutoAl González Es un diamante en bruto
Smile

¡Hola a todos!

Los saludo con gusto. Revivo este hilo porque me he topado con algo similar. Mi experiencia con planes y selectividad de índices es casi nula en este momento. Pero hoy aprendí algo sobre lo segundo, gracias a este hilo y los siguientes dos enlaces:

http://www.firebirdfaq.org/faq167/

http://vivenciasdiariasmiaspropias.b...imizar-el.html

Empiezo por colocar una versión simplificada del procedimiento actualizador de selectividad de índices. En adelante lo tendré en todas mis bases de datos Firebird:

Código SQL [-]
Create Procedure spActualizarIndices
As
  Declare Variable Nombre VarChar (31);
Begin
  For Select RDB$Index_Name From RDB$Indices Into :Nombre Do
    Execute Statement 'Set Statistics Index ' || :Nombre;
End

Ahora expongo mi caso sin mayores rodeos. Tengo una consulta Select que se ejecuta unas diez veces más rápido con una condición Where que sin ella (aunque la lógica indique que sin la cláusula Where debería ser más rápida). La he reducido a su mínima expresión y le he dado la siguiente forma para ejemplificar:

Código SQL [-]
Select PP.ID, Pr.Codigo From ParteProveedor PP
  Inner Join Proveedor Pr On Pr.ID = PP.IDProveedor
--  Where PP.ID = PP.ID
  Order By PP.FechaModificacion Desc

Cabe mencionar que la tabla ParteProveedor tiene un índice descendente por el campo FechaModificacion.

Comentada la línea del Where, cuando ejecuto la consulta en IB Expert demora alrededor de 4 segundos y en la parte inferior aparece el plan que se utilizó:
Cita:
Plan
PLAN SORT (JOIN (PR NATURAL,PP INDEX (FKPARTEPROVEEDORIDPROVEEDOR)))

Adapted Plan
PLAN SORT (JOIN (PR NATURAL,PP INDEX (FKPARTEPROVEEDORIDPROVEEDOR)))
Si descomento la línea del Where, la consulta tarda apenas una fracción de segundo y aparece otro plan usado:

Cita:
Plan
PLAN JOIN (PP ORDER IXPARTEPROVEEDORFECHAMDS,PR INDEX (PK_PROVEEDOR))

Adapted Plan
PLAN JOIN (PP ORDER IXPARTEPROVEEDORFECHAMDS,PR INDEX (PK_PROVEEDOR))
Es claro que a eso se debe que sea más rápida con la condición Where. En ese caso Firebird decide usar el índice descendente por fecha de modificación (IXPARTEPROVEEDORFECHAMDS) acorde a lo indicado en la cláusula Order By.

Revisando la sintaxis general de una sentencia Select, vi que el plan se especifica como una cláusula más. Así que adapté mi sentencia Select, quedando de esta manera:
Código SQL [-]
Select PP.ID, Pr.Codigo From ParteProveedor PP
  Inner Join Proveedor Pr On Pr.ID = PP.IDProveedor
  Plan Join (PP Order ixParteProveedorFechaMDs, PR Index (pk_Proveedor))
  Order By PP.FechaModificacion Desc

Con esto la consulta se ejecuta en una casi imperceptible fracción de segundo.

Ahora me toca aprender sobre la sintaxis de la cláusula Plan. Le echaré un vistazo a los manuales, pero si alguien puede adelantarse a explicarnos algo, creo que a muchos nos será de gran valía.

Saludos.

Al González.
__________________
Twitter
Código
Blog
WhatsApp para consultas rápidas y asesorías profesionales: +52 1 2711260117

Última edición por Al González fecha: 01-03-2008 a las 03:57:18.
Responder Con Cita
  #11  
Antiguo 01-03-2008
Avatar de Al González
[Al González] Al González is offline
In .pas since 1991
 
Registrado: May 2003
Posts: 5.499
Poder: 22
Al González Es un diamante en brutoAl González Es un diamante en brutoAl González Es un diamante en bruto
Por cierto, sugiero mover este hilo a la sección de Firebird/InterBase. Gracias.

Al.
__________________
Twitter
Código
Blog
WhatsApp para consultas rápidas y asesorías profesionales: +52 1 2711260117
Responder Con Cita
  #12  
Antiguo 01-03-2008
Avatar de Casimiro Notevi
Casimiro Notevi Casimiro Notevi is offline
Moderador
 
Registrado: Sep 2004
Ubicación: En algún lugar.
Posts: 27.759
Poder: 10
Casimiro Notevi Tiene un aura espectacularCasimiro Notevi Tiene un aura espectacular
Los planes han ido mejorando con cada versión de firebird. Hay que tener cuidado porque puede haber diferencias abismales entre unos y otros, obviamente, en cuanto a velocidad de proceso.
Normalmente, cuando encuentro alguna sentencia que tarda más de la cuenta, la analizo con IBPlanAnalizer (un poco obsoleto, pero muy efectivo) hasta encontrar el "punto" de mejor rendimiento, normalmente añadiendo o cambiando índices.

Desde hace años tengo una opción en "utilidades" para recalcular los índices, viene a ser lo mismo que has escrito, Al.
Código Delphi [-]
procedure TfrmRecalcularPlanes.btAceptarClick(Sender: TObject);
begin
//  inherited;
    if MensajeConfirmacion('Desea recalcular las estadsticas de uso de índices?' ) <> mrYes then
        exit;
    btAceptar.Enabled := false;
    btCancelar.Enabled := false;
    //
    try
        with qrConsulta do
        begin
            Close;
            SelectSQL.Text := 'Select * from RDB$INDICES where RDB$STATISTICS is not null';
            Open;
            Last;
            pbProgreso.Max := qrConsulta.RecordCount;
            First;
        end;
        while not qrConsulta.Eof do
        begin
            qrSql.Close;
            qrSql.Sql.Text := 'Set statistics index '+qrConsulta.FieldByName('RDB$INDEX_NAME').AsString;
            qrSql.ExecQuery;
            //
            qrConsulta.Next;
            pbProgreso.StepIt;
        end;
        //
    finally
        pbProgreso.Position := 0;
        btCancelar.Enabled := true;
    end;
    MensajeInformacion('Proceso concluido');
    close;
end;
El IBPlanAnalizer está aquí.

Última edición por Casimiro Notevi fecha: 03-12-2015 a las 17:39:49.
Responder Con Cita
  #13  
Antiguo 03-12-2015
Avatar de Kipow
Kipow Kipow is offline
Miembro
 
Registrado: Apr 2006
Ubicación: Guatemala
Posts: 328
Poder: 12
Kipow Va por buen camino
Buen dia, retomando un poco esto, que herramienta utilizan para verificar planes e indices en Firebird 2.5.x, el ibplananalizer me da problemas de conexion, con esa version

Saludos.
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
No es lo mismo, ni quiere decir lo mismo obiwuan Humor 35 21-12-2006 21:25:48
Borland tiene un plan Macabro para la Argentina!! delphi.com.ar Humor 3 02-07-2006 20:38:16
Query sobre dos BDs en el mismo PC en Firebird papulo Conexión con bases de datos 2 08-02-2006 18:17:04
plan ibarretxe. votamos todos ? maruenda Debates 65 08-03-2005 17:41:14
Plan Contable TIKIMORE Varios 0 29-05-2003 14:29:22


La franja horaria es GMT +2. Ahora son las 03:23:44.


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