FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
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 |
#2
|
||||
|
||||
Cita:
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.
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
#3
|
||||
|
||||
Se agradece a ambos por los datos que desconocia.
Saludos
__________________
Van Troi De León (Not) Guía, Code vB:=Delphi-SQL, ¿Cómo? Viajar en el tiempo no es teóricamente posible, pues si lo fuera, ya estarían aqui contándonos al respecto! |
#4
|
||||
|
||||
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 |
#5
|
||||
|
||||
????
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 |
#6
|
||||
|
||||
Cita:
Código:
PLAN SORT (JOIN (TAR INDEX (FK_NEW_TABLE),PER INDEX (RDB$PRIMARY78))) A veces puede seleccionar un plan que no es el mejor.
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
|
|
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 |
|