Si asi es. Debes poner solo fast_fordward. No te olvides del profiler.
Saludos On 3/30/07, Carlos A. Schroeter <[EMAIL PROTECTED]> wrote:
Gracias por tu respuesta Mariano…debo interpretar que está sobrando READ_ONLY y FORWARD_ONLY, para ser reemplazado por FAST_FORWARD? Gracias nuevamente ------------------------------ *De:* [email protected] [mailto:[EMAIL PROTECTED] *En nombre de *Jose Mariano Alvarez *Enviado el:* viernes, 30 de marzo de 2007 19:09 *Para:* Carlos A. Schroeter *Asunto:* [dbadmin] Performance en SP Usa el cursor fast_fordward. No creo que eso deba tardar 16 minutos Sugiero que durante el proceso levantes una traza con todas las columnas y solo los eventos siguientes RPC:Completed SP:Completed SP: StmtCompleted Luego busca los que tienen muchos reads y analizalos para corregirlos, Saludos On 3/30/07, *Carlos A. Schroeter* <[EMAIL PROTECTED]> wrote: Hola Grupo! Aquí molestando con mis preguntas El escenario es el siguiente: 1. tengo una aplicación comercial y otra contable, ambas tienen su base de datos 2. mis clientes puede ser que tengan ambas aplicaciones o solo una 3. la aplicación comercial tiene una utilidad que se encarga de exportar a la aplicación todos los asientos de acuerdo a las ventas, compras, ingresos y egresos generados (en el caso de tener ambas aplicaciones) o solo genera simples asientos contables locales si solo tienen la aplicación comercial 4. Todo el procedimiento que se encarga de generar los asientos o exportarlos a la contabilidad se encuentra en 4 Store Procedures (ventas, compras, ingresos y egresos) Esta es la situación: cuando la opción es exportar los asientos a la contabilidad, es decir, generar información desde una base de datos (comercial) a la otra (contable) el Store Procedures se hace muy pesado y lleva mucho tiempo su ejecución total, especialmente cuando los registros son muchos. Les comento la estructura que tiene el SP más critico en el caso de un cliente, al exportar a la contabilidad las compras de un mes (800 facturas) las demoras son mayores a los 15 minutos, con el problema de que "plancha" al servidor: 1. Lo primero que hace es una consulta para los registros del DEBE en donde se traen todos los comprobantes del período solicitado y se agrupan por nro. de comprobante + cuenta contable (esta consulta no es critica ya que corrida fuera del SP demora solo dos segundos) 2. Toda esta consulta está contenida en un cursor definido como FORWARD_ONLY READ_ONLY 3. Se recorren todas las filas (800) y se insertan en las tablas de la base de datos de la contabilidad los valores seleccionados del cursor 4. Cuando se exporta la sentencia INSERT se realiza mediante INSERT INTO BDCONTABLE..TABLA1, mientras que cuando solo se generan en la base de datos de la gestion comercial se realiza mediante INSERT INTO TABLA1 Preguntas: Si bien el uso de cursores en general no es recomendado, salvo en situaciones en que no se disponga de alternativas….es posible que se produzca tal demora y consumo de recursos? Se puede optimizar más el cursor? Es posible que al efectuar los insert o los updates sobre otra base de datos sea el proceso más lento que cuando se lo hace sobre la base de datos sobre la que uno está posicionado en ese momento? Desde ya muchas gracias Carlos Schroeter MUG: 1998 -- -------------------------------- Atte. Ing. Jose Mariano Alvarez
-- -------------------------------- Atte. Ing. Jose Mariano Alvarez
