Oracle - Insert, update CLOB PLSQL DEMASIADO LENTO

Hola, antes que nada gracias por su atención.

Tengo el siguiente problema. Actualmente armo una cadena de HTML con PL SQL que contiene datos que son dinámicos, después de que armo la cadena html la guardo en un campo CLOB de la base de datos...

Esto tengo haciéndolo desde al rededor de hace un año aproximadamente, de un tiempo para acá he tenido demasiados problemas de performance.. y para lo que antes se tardaba milésimas de segundo ahora se tarda casi 6 segundos por operación.

El procedimiento es el siguiente: Por medio de PL SQL armo una cadena de html dentro de una variable CLOB, posteriormente hago el insert... tal cual... sin hacer un select for update o algo porque el select for update tengo entendido que es para apartar el registro cuando aún estás construyendo el dato que vas a insertar, en este caso, yo ya lo tengo armado y así hacia el insert.

Después de que me diagnosticaron el problema... opte priimero por hacer el insert y acto seguido (es decir después de esa instrucción) hacer un update sobre el mismo registro entrando por la misma llave primaria... .cabe destacar, que no le puse un commit después del primer insert porque se ejecuta desde un trigger y el trigger según sé ya hace el commit.

Ojala pudieran ayudarme a tener idea de qué puede estar pasando.

Gracias.

Hola primeramente el select for update es para bloquear la tabla no el registro, de todas formas no te sirve, yo lo utilizo para que no entren dos procesos a al vez .
Con respecto a tu problema, hacer una insert en un clob es muy pesado para la bdd, si le sumas un trigger pues ya los costes se disparan (piensa que el trigguer ya carga en memoria el registro old y el new y to el rollo ese, un clob mantenerlo en memoria, telita...) , para eso tienes q tener un makinon q soporte eso, yo me replantearia el tema del triguer sobre una tabla con clob.

Wow, que manera de MALINFORMAR.

Un SELECT FOR UPDATE es para bloquear registros, LOGICAMENTE si no especificas un criterio/filtro con un WHERE bloqueas TODOS LOS REGISTROS DE LA TABLA, si especificas un criterio/filtro con el WHERE sólo se bloquearan ESTOS.

http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/statements_10002.htm#i2066346

Bueno no estoy ocupando un select 4 update, pensé que era necesario pero ya veo que no,. sin embargo, al hacer el insert con mi variable CLOB ya armada, se sigue tardando considerablemente no sé por qué.

Me dijeron que hiciera primero el insert con un empty_clob y después el update sobre el mismo registro y le estoy entrando por llave primaria sin embargo, el resultado es el mismo.

se aceptan ideas....

gracias por su ayuda.

Mariah, cual es la concurrencia que existe sobre esa tabla, es decir, ¿sólo tu proceso ejecuta inserts sobre ella? ¿Algún otro proceso/usuario hace deletes, updates? ¿Se dispara algún trigger con alguna de las operaciones anteriores? ¿Cuantos índices tiene esa tabla y en que orden está los campos?

Aunadas a las preguntas anteriores, ¿en cual sistema operativo tienes montada tu bd y que versión de Oracle usas? ¿El insert lo haces desde PL o desde algún otro lenguaje de programación, Java, .NET, PHP, etc.?

aahh ya había puesto mi respuesta y ésta cosa no me la respeto. bueno. va de nuevo.

1.- Hay otros procesos que hacen inserts o updates a la misma tabla que yo inserto pero ya revisamos que no haya bloqueos y no los hay, así mismo, esos procesos no tienen problema de lentitud.

2.- Se dispara un trigger que replica a otra tabla, ya lo desactivamos y el problema persiste.

3.- La tabla tiene 5 índices pero ¿me preguntas por el orden de los campos en los índices o el orden de los campos en la tabla?

4.- Creo que está montada en unix no sé bien yo acceso remotamente con el TSNames en mi Pl Sql Developer o el ide que sea. Y la versión es: 9.2.0.4.0

5.- todo el procedimiento se hace desde PL SQL desde el armado de la cadena hasta el insert.

Sabes? estoy pensando que el problema radica en manejo de memoria. El insert que hago lleva despuecito un update, pero ni el insert ni el update llevan un commit de por medio porque uno de mis compañeros me dijo que como él manda a llamar mi procedimiento desde un trigger no era necesario ponerle un commit, a pesar de que mis otros procedimientos que hacen insert a la misma tabla de la misma manera, tienen un commit de por medio no obstante de que los llame un trigger.

Tú qué opinas? Gracias por tu ayuda Sergio.

jum, bueno la parte de índices no debería significar un problema ya que si como dices hay otros procesos que también hacen inserts y updates en la misma y no se ven afectados pues definitivamente no va por ahí el problema.

La parte del commit no es totalmente cierta, es decir, porque tu código lo utiliza alguien más en otra parte no significa que vas a dejar de hacer lo que tu proceso DEBE hacer, si alguien más lo necesita SIN commit, entonces referencía a tu código CON commit, por ejemplo:

create procedure mi_proceso2(parametros) as
begin
mi_proceso1(parametros);
COMMIT;
END;

de esta manera empleas un COMMIT explícito sin afectar a los demás que "no lo necesitan" cuando usan el procedimiento mi_proceso1.

Ahora bien, un insert seguido de un update a la misma tabla me suena redundante, sino te funciona el ejemplo que te puse arriba ¿podrías ahondar en esto del update seguido del insert?

En realidad, inicialmente estaba solo el insert, sin el empty clob....

hacia un insert transparente que en vez de pasarle la cadena, le paso la variable de tipo CLOB ya con la cadena armada.

de inicio estaba así y se puso lentísimo por eso fue que opte por la recomendación de algunos de mis compañeros.... pero ps sigue igual.

cabe destacar que, la cadena que estoy insertando tiene una longitud mayor de 4000 caracteres casi 5000. creo que por ahí tal vez puede ir el problema.

Muy a pesar de que el tipo de dato clob tiene una capacidad de 4gb creo que debe haber algún problema en la inserción debe ser tal vez de otra manera ... pero es curioso que en mis otros procedimientos no se tarde, es por eso que estoy realmente confundida.

encontré un artículo en la página de ASKTOM e intenté guardarlo como lo hace él... pero se tarda mucho más !!! de lo que se tarda con mi procedimiento.

Estoy muuuyy desesperada y no sé pa donde jalar.

Gracias por tu apoyo sergio, ojala, si se puede, puedas agregarme a tus contactos de msn.

Gracias de nuevo.