Tarda mucho en ejecutar un SP

[Choclito]

Amigo guillotmarc te comento que logre bajar el ib planalyzer y en la grafica me muestra que la tabla registro_consulta_medica no esta indexado
la estructura de mis tablas es la siguiente
tabla recibo (
nro_recibo llave primaria,
fecha,
observaciones.
etc)
tabla registro_consulta_medica(
nro llave primaria
nro_recibo llave foranea y llave primaria,
nro_consulta llave foranea y llave primaria,
costo,
observaciones)
tabla consulta_medica(
nro llave primaria,
id_doctor,
costo1,
costo2)

Tengo la tabla recibo y la tabla consulta_medica y como existe una relacion de n a n es que la relacion de ellas es la tabla registro_consulta_medica con tres campos como llave principal.
Creo q ahi esta el error .
Esta sitacion tengo tanto con las tablas emergencias, venta_medicamentos, etc donde la relacion de las tablas tiene 3 campos como llaves primarias
Al crear las llaves primarias y foraneas Ib expert ya me crea los indices por los campos
Porfavor quisiera sugerencias de como arreglar pues la tabla recibo ya tiene mas de 16000 registros
Estare muy agradecido por la ayuda q me puedan brindar
y comentarte que ya cree los indices multiples de cancelado y costo

[guillotmarc]

Hola.

Nos tienes que decir para que consulta te indica que no tiene índices sobre registro_consulta_medica. Lo que te está indicando es que ninguno de los índices existentes le sirve para acelerar esa consulta en concreto.

Eso cambia entre consulta y consulta. Algunas consultas se pueden acelerar usando unos índices, otras se pueden acelerar con otros índices, y para algunas consultas puede que no tengas definido aún ningún índice útil (como es tu caso).

Los índices sobre los campos de clave foránea básicamente se utilizan para los JOINS, para poder optimizar la uníon ON clave_foranea = clave_primaria. Pero si tu tabla no está entre las relacionadas, entonces esos índices son de poca utilidad.

En tu caso concreto, lo más probable es que la tabla registro_consulta_medica solo esté filtrada en el WHERE de la consulta (y no en los JOINS), por tanto no te sirve ni el índice de la clave primaria, ni los índices de las claves foráneas.

Tienes que mirar la condición del WHERE, y en función de los campos que estés filtrando, tienes que crear índices sobre esos campos. Como solo se va a utilizar un índice, si tu filtro implica varios campos, entonces es cuando creamos un índice compuesto para que la base de datos pueda encontrar instantáneamente, usando el índice compuesto, los registros que coindicen con los campos buscados (y que se encuentran definidos en el índice).

Si nos dices la consulta en que te marca que no hay un índice adecuado para esa tabla, te podremos ayudar más.

Saludos.

[Choclito]

antes gracias por responder amigo guillotmarc, la aplicacion q tengo es para un hospital en ese sentido tengo la tabla recibo y las tablas consulta medica, rayos, medicamentos,ecografia, otros servicios
Existe relaciones entre la tabla recibo y las demas tablas indicadas y como esas relaciones son de n a n es que esas tablas generadas de las relaciones tienen tres campos como llaves primarias para el caso de la tabla medicamentos como ejemplo (tiene el campo nro_recibo,nro_medicamento y nro ) los dos primeros son llaves foraneas y el tercero es uno q he creado en la tabla para que los tres sean llaves primarias
Esta bien lo que he creado de esa manera las tablas ?? yo las cree asi pues puede ser que para el caso de medicamentos haya varios medicamentos en un recibo y para mantener la consistencias y no tener datos duplicados es que adicione el campo nro a la tabla de la relacion de las tablas recibo y medicamento
Muchas gracias
Y sobre lo que me consultas acabo de llegar y lo probare nuevamente y mando mas detalles sobre lo que me indica el IB plananalizer muchas gracias

[Choclito]

Sobre la consulta amigo guillotmarc, es esta:

Código SQL [-]
select  r.nro_recibo,cast(r.fecha as date),g.nombre, case r.porcentaje_cobro
                         when 100 then  r1.costo else (r.porcentaje_cobro*r1.costo)/100 end,r.costo_total,r.literal,r.nro_ambulatorio,r.usuario,r.tipo_paciente,r.nro_asegurado,r.nro_intern  acion,r.factura,cast(r.fecha as time),r.monto_cobrar,r.porcentaje_cobro,r1.nro,r.nro_factura
from  recibo r
    inner join registro__ecografia R1 on r1.nro_recibo=r.nro_recibo
    inner join ecografia g on g.nro=r1.tipo_ecografia
where ((cast(r.fecha as date) between :f1 and :f2)and((r.cancelado=:valor)or(r.cancelado='M')))

cabe indicas que trabajo con el ib expert y al crear las llaves primarias y foraneas me a creado automaticamente los indices en las tres tablas
el ib plan analyzer me muestra lo siguiente:
PLAN JOIN (G NATURAL, R1 INDEX (FK_REGISTRO__ECOGRAFIA_1), R INDEX (PK_RECIBO))
Pero en la seccion de R1 INDEX (FK_REGISTRO__ECOGRAFIA_1) me indica un icono de exclamacion y me muestra el campo selectivity de 10.91 ademas que en la grafica me muestra que la tabla ecografia es secuencial y las demas tablas estan indexadas
Gracias por responder, espero me puedan ayudar sobre esta parte pues no se que hacer mil gracias
El primer sp que les mande es grande y como me sugeriste que pruebe con los select que tengo esta consulta es con la primera q pruebo mil gracias

[guillotmarc]

Hola.

Los índices que debes tener para acelerar esa consulta estan muy claros.

Para registro__ecografia, necesitas un índice sobre nro__recibo

Para ecografia necesitas un índice sobre nro

Para recibo te recomiendo un índice simple sobre fecha.

A la vista del filtro en el WHERE te recomiendo ese índice simple, pero dado que haces una conversión del campo antes de evaluarlo, estás impediendo que el optimizador use un índice. Por ello tienes que cambiar esa parte de la consulta, por el equivalente sin conversiones.

Es decir, cambia el :

(cast(r.fecha as date) between :f1 and :f2)

Por su equivalente :

(r.fecha between :f1 and :f2 + 1 and r.fecha <> :f2 + 1)

Saludos.

[Choclito]

Disculpen por responder tarde, probe lo que dice el amigo guillotmarc y el IB plananalyzer me dice que las tres tablas estan indexadas, ahora probare con el resto de mis consultas .
Sobre la condicion del where es lo mismo
(r.fecha between :f1 and :f2 + 1 and r.fecha <> :f2 + 1) por esto (cast(r.fecha as date) between :f1 and :f2) se tiene que sumar siempre mas 1 osea f2+1 ??
Solo quisiera una explicacion asi de ese modo me evito de utilizar la funcion cast .
Yo lo realizaba porq el campo fecha es timestamp mientras en las consultas solo me importan de un rango de fechas determinado
Muchas gracias por la respuesta

[Kipow]

El IB planalizer te debe de ayudar a determinar el plan que esta usando tu consulta y tu mismo debes de evaluar si es el correcto tomando en cuenta el numero de lecturas por tabla involucrada en la consulta. Por otro lado si utilizas cast estas dejando de utilizar el indice sobre el campo fecha si existiera. no veo porque no te funciona de la primera forma (fecha between :f1 and f2).

[guillotmarc]

Empezado por Choclito

Disculpen por responder tarde, probe lo que dice el amigo guillotmarc y el IB plananalyzer me dice que las tres tablas estan indexadas, ahora probare con el resto de mis consultas .
Sobre la condicion del where es lo mismo
(r.fecha between :f1 and :f2 + 1 and r.fecha <> :f2 + 1) por esto (cast(r.fecha as date) between :f1 and :f2) se tiene que sumar siempre mas 1 osea f2+1 ??
Solo quisiera una explicacion asi de ese modo me evito de utilizar la funcion cast .
Yo lo realizaba porq el campo fecha es timestamp mientras en las consultas solo me importan de un rango de fechas determinado
Muchas gracias por la respuesta

Que el IB plananlyzer te diga que se va a utilizar un índice no quiere decir que vaya a ir rápido obligatoriamente. Puesto que el motor puede utilizar algún índice disponible que acelere un poco la consulta (aunque por ejemplo bajar de 10 minutos a 4 minutos, normalmente no es de ninguna ayuda), y lo que necesitas es dar de alta un índice nuevo sobre un campo concreto, que es el que permitirá al motor acelerar de forma óptima la consulta y que se ejecute en algunos segundos. Así que no solo tienes que mirar que se utilice algún índice, también tienes que mirar que ese índice realmente sea óptimo para la consulta o bien si necesitas crear uno nuevo más adecuado.

Respecto a las consultas de fechas, el +1 hay que ponerlo dependiendo de lo que tengas guardado en la base de datos. El campo es de tipo timestamp, pero no sabemos si en tu programas guardas la parte de hora de las fechas o no lo haces.

Si guardas en la base de datos la parte de hora, entonces un registro que tenga guardado, por ejemplo, : 12-4-2010 17:25 no aparecerá en una consulta que sea BETWEEN 10-4-2010 y 12-4-2010, ya que 12-4-2010 17:25 es mayor que 12-4-2010 (si no pones nada, es a las 00:00).