En general la regla seria un archivo por nucleo de procesamiento. No siempre mejora pero es una practica recomendable.
Hay un documento en el sitio de MS de varias paginas que habla de eso y del mayor uso de la tempDB en 2005. -------------------------------- Atte. Ing. Jose Mariano Alvarez SQL Total Consulting 2008/11/17 Luis <[EMAIL PROTECTED]> > Mariano: > > Donde haces referencia a la TEMPDB, si se tiene un solo archivo o uno por > cada nucleo de procesamiento, si te tiene mas de un procesador, es buena > practica tener mas de un archivo de TEMPDB? > > Ibaseta, Luis. > > > ------------------------------ > > Date: Mon, 17 Nov 2008 14:12:13 -0200 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > Subject: [dbms] Delete con esperas > > > Entonces deberias monitorear el crecimiento del log de transacciones. > Segurmente no te alcanzaba el espacio que tenia y tuvo que agrandarlo.y ahi > es donde tuviste que esperar.. > Todo se congela mientras hace esta operacion. > Otra alternativa por la cual pudo haber demorado es que habia transacciones > abiertas y el delete usaba tabLock y por lo tanto tuvo que esperar. > > Fijate si tiene la opcion de inicializar el archivo antes de usarlo. > Te copio > > Instant file initialization is only available if the SQL Server > (MSSQLSERVER) service account has been granted SE_MANAGE_VOLUME_NAME. > Members of the Windows Administrator group have this right and can grant it > to other users by adding them to the *Perform Volume Maintenance > Tasks*security policy. For more information about assigning user rights, see > the > Windows documentation. > > En cuanto a la tempDB lo que me importaba era saber si tenias un solo > archivo o uno por cada nucleo de procesamiento. > > saludos > > -------------------------------- > Atte. > Ing. Jose Mariano Alvarez > SQL Total Consulting > > > 2008/11/17 Seba Frank <[EMAIL PROTECTED]> > > Mariano, > > Propiedades de La TempDB > > Status=ONLINE, Updateability=READ_WRITE, UserAccess=MULTI_USER, > Recovery=SIMPLE, Version=611, Collation=Latin1_General_CI_AI, > SQLSortOrder=0, IsAutoCreateStatistics, IsAutoUpdateStatistics > Compatibilidad 90 > > La cuenta de servicio tiene activada la política *Lock Pages in Memory.* > Tengo instalado el SP2 y no tuve ninguno de los mensajes que mostras abajo. > ** > > ----- Original Message ----- > *From:* Jose Mariano Alvarez <[EMAIL PROTECTED]> > *To:* Seba Frank <[EMAIL PROTECTED]> > *Sent:* Monday, November 17, 2008 10:34 AM > *Subject:* [dbms] Delete con esperas > > Por favor, indicame cual es la configuracion de la TempDB, > La cuenta de servicio tiene la policy *Lock Pages in Memory activada?* > Te sugeriria medir la paginacion y el uso interno de la memoria para ver > que pasa. > Coincido con Maxi en cuanto al borrado en bloques mas pequeños. > > > Fijate ademas si tenes aplicado el SP2 si aparecieron algunos de estos > tipos de mensajes. > > Error message 1 > 2007-01-23 16:30:10.14 spid1s A significant part of sql server process > memory has been paged out. This may result in a performance degradation. > Duration: 0 seconds. Working set (KB): 1086400, committed (KB): 2160928, > memory utilization: 50%. > > Error message 2 > 2007-01-23 16:35:26.52 spid1s A significant part of sql server process > memory has been paged out. This may result in a performance degradation. > Duration: 315 seconds. Working set (KB): 410156, committed (KB): 2201296, > memory utilization: 18%. > > Error message 3 > 2007-01-23 16:40:54.12 spid1s A significant part of sql server process > memory has been paged out. This may result in a performance degradation. > Duration: 646 seconds. Working set (KB): 901904, committed (KB): 2215752, > memory utilization: 40%. > > > > > -------------------------------- > Atte. > Ing. Jose Mariano Alvarez > SQL Total Consulting > > > 2008/11/14 Seba Frank <[EMAIL PROTECTED]> > > Hola Mariano, > > El servidor es 2005, tiene 6GB de ram, corre únicamente el SQL y es 64bits > por lo que no tuve que hacer modificaciones a parámetros de arranque del SO > o usar AWE. Tengo armado tres raids, 1 para el SO, 1+0 para datos y 1+0 para > logs. > En cuanto a la configuración a cual te referís específicamente. Hice > modificaciones en parametros como cantidad de memoria máxima y mínima, > número máximo de subprocesos... > También tengo armado mirroring en todas las bases (cerca de 50) > Era la única espera que tenía en ese momento y los discos la verdad que no > los medí. > > Marcelo, esta en linea pero no existían bloqueos. > > Muchas gracias por sus respuestas > > Seba > > ----- Original Message ----- > > *From:* Jose Mariano Alvarez <[EMAIL PROTECTED]> > *To:* Seba Frank <[EMAIL PROTECTED]> > *Sent:* Friday, November 14, 2008 12:14 AM > *Subject:* [dbms] Delete con esperas > > 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 > > > > > > ------------------------------ > ¡Pasalo de dedo en dedo! Messenger en tu celular<http://www.dedoendedo.com/> >
