Situacion anormal al eliminar registros

[jlct]

Buenas tardes amigos de FDW una vez mas estoy aqui requiriendo de su ayuda sobre una situacion anormal que me esta pasando al tratar de eliminar registros de una tabla.

pasa lo siguiente tengo esta tabla:

Código:

-- Table: inventario.tmovimiento_inv

-- DROP TABLE inventario.tmovimiento_inv;

CREATE TABLE inventario.tmovimiento_inv
(
  nid_inventario numeric NOT NULL DEFAULT nextval('inventario.sec_inventario'::regclass),
  nmovimiento numeric NOT NULL,
  nfecha date,
  nid_tipo_operacion numeric NOT NULL,
  ndocumento numeric,
  nfecha_doc date,
  cobservacion character varying(255),
  nid_clientes numeric,
  nguia numeric,
  nid_dias numeric NOT NULL,
  nid_sucursal numeric NOT NULL,
  nano smallint,
  CONSTRAINT tmovimiento_inv_pkey PRIMARY KEY (nid_inventario),
  CONSTRAINT fk_client FOREIGN KEY (nid_clientes)
      REFERENCES ventas.tclientes (nid_clientes) MATCH SIMPLE
      ON UPDATE CASCADE ON DELETE NO ACTION,
  CONSTRAINT fk_dias FOREIGN KEY (nid_dias)
      REFERENCES general.tdias (nid_dias) MATCH SIMPLE
      ON UPDATE CASCADE ON DELETE NO ACTION,
  CONSTRAINT fk_inventario_sucursal FOREIGN KEY (nid_sucursal)
      REFERENCES general.tsucursales (nid_sucursal) MATCH SIMPLE
      ON UPDATE CASCADE ON DELETE NO ACTION,
  CONSTRAINT fk_tipo_operacion FOREIGN KEY (nid_tipo_operacion)
      REFERENCES inventario.ttipo_operacion (nid_tipo_operacion) MATCH SIMPLE
      ON UPDATE CASCADE ON DELETE NO ACTION
)
WITH (
  OIDS=FALSE
);
ALTER TABLE inventario.tmovimiento_inv OWNER TO iancarina;

-- Trigger: tg_inventario_tmovimiento_inv on inventario.tmovimiento_inv

-- DROP TRIGGER tg_inventario_tmovimiento_inv ON inventario.tmovimiento_inv;

CREATE TRIGGER tg_inventario_tmovimiento_inv
  AFTER DELETE
  ON inventario.tmovimiento_inv
  FOR EACH STATEMENT
  EXECUTE PROCEDURE inventario.fn_establecer_secuencia_movimiento_inv();

y esta:

Código:

-- Table: inventario.tdetalle_movimiento_inv

-- DROP TABLE inventario.tdetalle_movimiento_inv;

CREATE TABLE inventario.tdetalle_movimiento_inv
(
  nid_inventario numeric NOT NULL,
  cid_productos character varying(20) NOT NULL,
  ncantidad numeric NOT NULL,
  nid_planta numeric NOT NULL,
  nid_sucursal numeric NOT NULL,
  nid_detalle_inventario numeric NOT NULL DEFAULT nextval('inventario.sec_detalle_inventario'::regclass),
  CONSTRAINT fk_inventario FOREIGN KEY (nid_inventario)
      REFERENCES inventario.tmovimiento_inv (nid_inventario) MATCH SIMPLE
      ON UPDATE CASCADE ON DELETE CASCADE,
  CONSTRAINT fk_inventario_sucursal FOREIGN KEY (nid_sucursal)
      REFERENCES general.tsucursales (nid_sucursal) MATCH SIMPLE
      ON UPDATE CASCADE ON DELETE NO ACTION,
  CONSTRAINT fk_planta FOREIGN KEY (nid_planta)
      REFERENCES inventario.tplanta (nid_planta) MATCH SIMPLE
      ON UPDATE CASCADE ON DELETE NO ACTION,
  CONSTRAINT fk_productos FOREIGN KEY (cid_productos)
      REFERENCES general.tproductos (cid_productos) MATCH SIMPLE
      ON UPDATE CASCADE ON DELETE NO ACTION
)
WITH (
  OIDS=FALSE
);
ALTER TABLE inventario.tdetalle_movimiento_inv OWNER TO iancarina;

-- Trigger: tg_establecer_secuencia_detalle_movimiento_inv on inventario.tdetalle_movimiento_inv

-- DROP TRIGGER tg_establecer_secuencia_detalle_movimiento_inv ON inventario.tdetalle_movimiento_inv;

CREATE TRIGGER tg_establecer_secuencia_detalle_movimiento_inv
  AFTER DELETE
  ON inventario.tdetalle_movimiento_inv
  FOR EACH STATEMENT
  EXECUTE PROCEDURE inventario.fn_establecer_secuencia_detalle_movimiento_inv();

-- Trigger: tg_validar_idinventario on inventario.tdetalle_movimiento_inv

-- DROP TRIGGER tg_validar_idinventario ON inventario.tdetalle_movimiento_inv;

CREATE TRIGGER tg_validar_idinventario
  BEFORE INSERT
  ON inventario.tdetalle_movimiento_inv
  FOR EACH ROW
  EXECUTE PROCEDURE inventario.validar_idinventario();

estoy ejecutando la siguiente instruccion

Delete from inventario.tmovimiento_inv where nano = 2010

pero el proceso de ejecucion tardo excesivamente hasta la ultima ejecucion llevaba mas de 3 horas. (A eso me refiero con situacion anormal)

pero si ejecuto esta instruccion

Delete from inventario.tdetalle_movimiento_inv where nid_inventario between 55496 and 95678

no llega a los 2 segundos.

Nota: la tabla tmovimiento_inv en ese año posee 44759 registros. y la tabla tdetalle_movimiento_inv en ese año posee 414593 registros.

No se que debo hacer para solucionar este problema. espero alguien me pueda ayudar.

[huesos52]

Lo que veo es que tu primera sentencia DELETE la realizas sobre un campo que no está indexado. para el numero de registros
que tienes y el tiempo que dices se demora, efectivamente pasa algo anormal.

Tendrías que analizar al interior de este procedure que se ejecuta bajo el trigger que creaste AFTER DELETE.
inventario.fn_establecer_secuencia_movimiento_inv( )

es posible que tengas un cuello de botella en alguna parte.

saludos

[jlct]

Antes que todo Muchas Gracias por interesarte en el tema y responder.

Código:

-- Function: inventario.fn_establecer_secuencia_movimiento_inv()

-- DROP FUNCTION inventario.fn_establecer_secuencia_movimiento_inv();

CREATE OR REPLACE FUNCTION inventario.fn_establecer_secuencia_movimiento_inv()
  RETURNS trigger AS
$BODY$
declare nid_max_inventario numeric;
begin
  select max(nid_inventario) into nid_max_inventario from inventario.tmovimiento_inv;
  if nid_max_inventario is null then
	nid_max_inventario:=0;
  end if;
	
  EXECUTE 'alter sequence inventario.sec_inventario restart with ' || nid_max_inventario + 1 ;
  return old;
end;
$BODY$
  LANGUAGE plpgsql VOLATILE
  COST 100;
ALTER FUNCTION inventario.fn_establecer_secuencia_movimiento_inv() OWNER TO iancarina;

esa es la funcion que llama el trigger si ves algo mal me avisas

[huesos52]

La verdad estoy en total desacuerdo con lo que tratas de hacer. :)

Te recomiendo leas los apuntes de gnzsoloyo en este post

Estas tareas son totalmente innecesarias.

Yo tengo una secuencia que me administra 3 tablas grandes. Una sola secuencia para las 3 tablas. El orden de numeración es una tarea sin funcionalidad.

Aunque el ejemplo que dice gnzsoloyo es para mysql aplica para cualquier motor de bases de datos.

Prueba borrando el trigger y ejecutando nuevamente tu consulta.

saludos

[jlct]

En escencia gnzsoloyo tiene razon, pero el motivo por el cual realizo eso es xq escribo los datos mediante un proceso de migración usando una herramienta que se llama Pentaho Data Integración y tengo una tarea que me escribe todos los dias. en este caso la finalidad es migrar todos los datos hasta la fecha y de alli quedaria solo los datos del año actual los que se estarian borrando y sobre escribiendo xq hacer un insert / update tardaria mucho mas que realizar un delete / insert. tengo otra tabla con las mismas secuencias, trigger y funciones y hasta los momentos no me han fallado.. esta que es la ultima que he generado es la que me esta dando problemas.

[huesos52]

Prueba el mismo delete pero con el campo nid_inventario y no nano.

Asi descartamos que sea un problema de indices.

[jlct]

Buenos dias, ayer lo probe de esa manera pero al igual tardo mucho y de tanto esperar decidi cancelar y eliminar el trigger para probar a eliminar asi. deje eliminando el trigger antes de salir del trabajo y esta mañana cuando reviso tenia 14h32m en ejecucion..! la verdad que es primera vez que me pasa estoy sorprendido con el comportamiento que tiene.

[huesos52]

Se me ocurre que exista un registro bloqueado por otra transacción y esta esté esperando su ejecución para completar la misma.
Trabajas en tu servidor con el autocommit apagado?
Tienes otros procesos corriendo paralelo a este?


Te recomiendo revisar este link
http://www.postgresql.org.es/node/582
Con algunos tips para monitorear tu servidor de base de datos.

saludos

[jlct]

Gracias por la información y por tu ayuda!! en efecto estaba bloqueado por otra transacción, reinicie el postgres y ejecuto la instruccion de inmediato (el drop trigger), ahora estoy ejecutando un delete en la tabla tmovimiento_inv y estoy esperando a que finalice.

Tomando en cuenta a que en la tabla maestra posee mas de 55mil y la detalle mas de 486mil y el on delete de la relacion esta en cascada el proceso puede tardar! espero que no sea excesivo el tiempo de ejecución.