Tu problema A PRIORI parece ser presion sobre la memoria (buffer pool) debida a la lentitud en el IO. Sin embargo podria deberse a muchos otros factores.
Es 2005? El servidor esta configurado default? Cuanta memoria tiene? Pusiste a cero los waits antes de medirlos? Determinaste la cantidad ademas de los ms? Mediste los discos y las operaciones del buffer manager? saludos -------------------------------- Atte. Ing. Jose Mariano Alvarez SQL Total Consulting 2008/11/13 Marcelo Colombani <[EMAIL PROTECTED]> > Hola, Sebastián yo sigo tirando posibles causas.... je je > > ¿esta en linea? > Si es así, no te fijaste si se producen bloqueos y se queda esperando que > otro usuario libere el registro. > > Marcelo > > ----- Original Message ----- > *From:* Seba Frank <[EMAIL PROTECTED]> > *To:* Marcelo Colombani <[EMAIL PROTECTED]> > *Sent:* Thursday, November 13, 2008 10:30 AM > *Subject:* [dbms] Delete con esperas > > Marcelo, tiene un solo índice y no tiene fragmentación. El where lo hace > por el índice. > La verdad sigo en investigación pero no se me ocurre que puede ser... > > Si a alguno se le ocurre algo para ver serán bienvenidos los comentarios > > Saludos > > Seba > > ----- Original Message ----- > *From:* Carlos Peix <[EMAIL PROTECTED]> > *To:* Seba Frank <[EMAIL PROTECTED]> > *Sent:* Thursday, November 13, 2008 8:40 AM > *Subject:* [dbms] Delete con esperas > > Hola Marcelo, > > Lo del uso de recursos lo dije porque tiene que almacenar todos los cambios > de la transaccion, cuanto mas cantidad de operaciones de modificacion se > realicen, mas espacio se necesita, en principio, proporcinalmente. Lo que > puede estar pasando con la no proporcionalidad que menciona Sebastian > (100.000 -> un segundo, 500.000 varios minutos) puede deberse a sobrepasar > algun limite que habria que investigar. > > Con que mencionas de la fragmentacion no tengo experiencia, pero se me > ocurre que puede sumar tiempo linealmente, no el salto que menciona > Sebastian. > > Y paro aca porque ya estoy hablando mas de la medida cobre cosas que no se > (si, tengo hasta medida para hablar de cosas que no se :-) ). > > *Carlos Peix* > > ------------------------------ > *De:* [email protected] [mailto:[EMAIL PROTECTED] *En nombre de *Marcelo > Colombani > *Enviado el:* Miércoles, 12 de Noviembre de 2008 11:20 a.m. > *Para:* [EMAIL PROTECTED] > *Asunto:* [dbms] Delete con esperas > > Puede ser que tengas la tabla muy fragmentada, y apesar de tener pocos > registros utiliza mucha memoria, como dice Carlos. O también que tengas > muchos indices definidos para esa tabla. > > Puedes probar con DBCC INDEXDEFRAG sobre el índice cluster. > > Otra: el where se relaciona con algún indice que tienes, porque me ha > pasado que dependiendo del índice demoraba mas, o menos la eliminación, por > la selectividad. > > Saludos > Marcelo > > ----- Original Message ----- > *From:* Carlos Peix <[EMAIL PROTECTED]> > *To:* Marcelo Colombani <[EMAIL PROTECTED]> > *Sent:* Wednesday, November 12, 2008 8:18 AM > *Subject:* [dbms] Delete con esperas > > Hola Sebastian, > > No puedo explicar la diferencia tan grande, seguramente estas alcanzando > algun limite duro. Algo parecido a: a medida que vas consumiendo mas > memoria, el rendimiendo va disminuyendo linealmente, pero cuando pasas a > paginar a disco, tenes un salto abismal. > > No digo que sea eso, pero seguramente este pasando algo conceptualmente > similar. > > Tenes que tener en cuenta quela base de datos tienen que tener toda la > informacion de la transaccion acumulada para confirmarla en el commit, el > espacio en que almacena esa informacion es la famosa tempdb. Cuando mas > grande es la transaccion, mas se fuerza este recurso. > > Ya me sorprende que tarde nada mas que un segundo en borrar 100.000 > registros (yo hubiese sugerido 20 o 30K). Ya que tenes que segmentar, yo me > quedaria con 100.000. > > *Carlos Peix* > > ------------------------------ > *De:* [email protected] [mailto:[EMAIL PROTECTED] *En nombre de *Seba Frank > *Enviado el:* Miércoles, 12 de Noviembre de 2008 10:06 a.m. > *Para:* [EMAIL PROTECTED] > *Asunto:* [dbms] Delete con esperas > > > No no, es una tabla con 40 millones de registros, asique esa posibilidad no > cabe en este escenario. > Lo que hice fue borrarlos de a subconjuntos. Lo raro fue que al borrar > 100.000 lo hacía en 1 segundo, pero con 500.000 se me moría, lo deje > corriendo 5 min y lo cancele. Algún comentario acerca de este > comportamiento. > > Saludos > > ----- Original Message ----- > *From:* Guevara Freddy <[EMAIL PROTECTED]> > *To:* [EMAIL PROTECTED] > *Sent:* Tuesday, November 11, 2008 7:02 PM > *Subject:* RE: [dbms] Delete con esperas > > > > Cuál es el numero de registros que quedarían en la estructura luego de > borrado los registros, adicional, es proceso batch?……, prueba realizando un > insert into a una tablatmp física del los que qudan por fuera del delete, > drop de la tabla antigua y sp_rename de la tmp con el nombre de la original > y no descuidar la respectiva creación de índices… > > > > > > Att > > Fredy J. Guevara Carrillo > ------------------------------ > > *De:* [email protected] [mailto:[EMAIL PROTECTED] *En nombre de *Seba Frank > *Enviado el:* Martes, 11 de Noviembre de 2008 8:21 > *Para:* Guevara Freddy > *Asunto:* [dbms] Delete con esperas > > > > Buen día lista. > > > > Tengo un problema con un delete. El mismo debería borrar cerca de 5 > millones de registros. El problema que tengo es que se me suspende, y el > tipo de espera es PAGEIOLATCH_EX. El tiempo de espera no pasa nunca los 500 > lo que me da una pauta de que se ejecuta y luego vuelve a suspenderse. > > Mas datos, el where es sobre un indice cluster que tiene un solo campo, ej > indice id y el where id=x. > > La fragmentación es casi nula porque acabo de reindexar. > > > > Tienen alguna idea o comentario? > > > > Muchas Gracias > > > > Seba > >
