Hola Solo pensando en voz alta, con ánimo de tirar una idea más.. podes utilizar Datareaders? Los datareaders son órdenes de magnitud más livianos en consumo de memoria porque lo podemos ver como una "ventana deslizante" sobre las páginas físicas de las tablas SQL Server ya que capturan una sola fila por vez (para llenar un control deberías hacer Do..WHILE), y no -como el dataset- una copia de datos desconectada que mantiene -para colmo de males- dos juegos idénticos de resultados. Uno puede mejorar algo la performance desactivando las restricciones, pero el consumo de memoria es considerable.
Como contrapartida, para aplicaciones ASP.NET , el dataset puede ser cacheado, y el datareader necesita de una conexión con estado el 100% del tiempo. Igualmente, en performance, es normalmente admitido que si dataset=100, datareader=80 como mucho. No es significativamente más performante, sino que consume muchísima menos memoria (se hace captura de una fila por vez, y no de todo el conjunto de resultados). Por otro lado, en entornos ASP.NET, los datasets se pueden almacenar en variables session(), mientras que el datareader, al ser incapaz de leer más de una sola fila por vez, necesita reconsultar a la base de datos cada vez que se recrea la página. En este caso podríamos preparar la consulta, y confiar en el plan de acceso cacheable que nos brinda el SQL Server, pero en escalabilidad, parece que el caché de los datasets le lleva mucha ventaja a cualquier otra técnica que uno pueda imaginar. Si tus usuarios no son miles, y tu problema es el consumo de memoria de un dataset muy grande, podrías probar con el frugal datareader, no esperes mejoras *impresionantes* en velocidad, pero si en consumo de memoria. Para aumentar el tiempo de respuesta de la consulta, deberías probar (no es seguro, por eso digo probar) el colocarle parámetros al query, y pedirle a ADO.NET que PREPARE la consulta. En este caso, el SQL SERVER calcula y cachea el plan de acceso, y en subsiguientes consultas, como solamente varían los parámetros y no la semántica del query, el plan de acceso no se reevalúa sino que se ejecuta directamente desde el caché. Igualmente, las UNION ALL son ejecuciones muy costosas, así que en este caso vería de tenerle paciencia, si hay mejora sería en el manejo de las subconsultas. Si las subconsultas son correlacionadas (es decir, la subconsulta interna depende de qué registro se evalúa en la consulta externa a cada momento del query), quizás convendría reescribir el query usando JOINs. Normalmente el optimizer hace esto, pero nunca está demás probarlo. Con los JOINS explícitos, el optimizador puede reindexar al vuelo y mantener los índices de las juntas internas (si prepara la consulta), y así aumentar significativamente la velocidad global de consulta. Carlos > -----Mensaje original----- > De: puntonet@mug.org.ar [mailto:[EMAIL PROTECTED] En nombre de > Damián Herrera > Enviado el: Jueves, 11 de Octubre de 2007 04:53 p.m. > Para: puntonet@mug.org.ar > Asunto: [puntonet] Preguntas varias > > > Que lastima :s A mi me paso lo mismo y los convencí en mostrarselos de > a 20 > registros. En total, en una de las grillas me quedaron 7500 páginas :) > Entre > pagina y pagina tengo un retardo de 4 segundos más o menos, por > cuestión de la > complejidad de la consulta (tiene más de 5 union all y varios sub > queries). > Siempre trato de sobresaltar que hay que aplicar buenos filtros para > evitar > mostrar tanta info. Pero es complejo :) > > > Saludos, > Damián Herrera > > >-----Original Message----- > >From: puntonet@mug.org.ar [mailto:[EMAIL PROTECTED] On > >Behalf Of JATEMLIANSKY, Diego > >Sent: Thursday, October 11, 2007 3:49 PM > >To: puntonet@mug.org.ar > >Subject: [puntonet] Preguntas varias > > > >Si, lamentablemente los usuarios acá quieren ver todos los datos. > > > >Yo le explique que ya mas de 1000 datos en una grilla en > >pantalla era mucho, > >pero no lo pude convencer. > > > > > >-----Mensaje original----- > >De: Damián Herrera [mailto:[EMAIL PROTECTED] > >Enviado el: Jueves, 11 de Octubre de 2007 14:21 > >Para: puntonet@mug.org.ar > >Asunto: [puntonet] Preguntas varias > > > > > >Hola Diego, > > > >Consulta, ¿estos dataset grandes los mostras al usuario todos juntos? > >Pregunto, > >porque talvez una solución de paginación en base de datos > >pueda resultar más > >optima. > > > >Saludos, > >Damián Herrera > > > >>-----Original Message----- > >>From: puntonet@mug.org.ar [mailto:[EMAIL PROTECTED] On > >>Behalf Of JATEMLIANSKY, Diego > >>Sent: Thursday, October 11, 2007 10:43 AM > >>To: puntonet@mug.org.ar > >>Subject: [puntonet] Preguntas varias > >> > >>Gente como andan ? > >>Tengo un par de preguntas para hacerles que nos están sacando > >>el sueño y que > >>tal vez con algunos tips que nos puedan dar nos puedan > >>orientar un poco como > >>encararlo. > >> > >>La arquitectura que tenemos es de FrontEnd en ASP.NET, BackEnd > >>en Servicios > >>de Windows VB.NET accedidos por Remoting y SQL Server. > >>(Todo esto instalado en servidores, no instalamos nada en las > >>PC clientes) > >> > >>Ahora les paso las preguntas (Todas con respecto a la parte > >>del BackEnd en > >>donde tenemos todas las reglas de negocios y el grueso de la > >>codificacion): > >> > >>1- Liberar memoria: > >> En algunos casos nos esta costando entender como hacer > >>para liberar > >>memoria. > >> Por un lado encontramos que nos recomiendan hacer los > >>Dispose de los > >>DataSets una vez utilizados y por otro lado también > >encontramos algunos > >>sites que recomiendan hacer un ds = nothing para liberar la > >>memoria, cual es > >>la opción mas recomendable? > >> > >> Por otro lado, que pasa si un método de nuestro BackEnd hace > >>solamente lo siguiente: > >> > >> Function traer() as dataset > >> Dim ds as new dataset > >> > >> ds = CargarDatasetdesdeSQL > >> > >> return ds > >> end function > >> > >> Como hacemos para liberar la memoria utilizada por este > >>DataSet (que > >>en algunos casos trae muchos datos para mostrar en pantalla) > >>si después del > >>return no podemos hacer mas nada. > >> > >>2- Prioridad de procesos: > >> Tenemos varios procesos que son del tipo Batch, o sea, que el > >>usuario levanta un archivo y lo vamos procesando. > >> Estos procesos pueden llevar al procesador a consumir > >>mas de lo que > >>queremos y afectan al funcionamiento optimo del Server. (Ya > >>que en el Server > >>de BackEnd tenemos varios servicios corriendo y no podemos > >>afectar a los > >>otros) > >> Como hacemos para establecer prioridades a estos > >>procesos o decirle > >>que solamente consuman hasta por Ej. un 30% o que tengan menor > >>prioridad ? > >> O para que el Loop que hacemos con los registros del > >>archivo no se > >>lleve todo el procesador. > >> (Estos procesos los tenemos que hacer OnLine, no > >>podemos dejarlos > >>como procesos nocturnos) > >> > >> > >>Muchas Gracias. > >> > >> > >> > >> AVISO: El presente mensaje y los archivos adjuntos que incluya > pueden > >>contener información confidencial de uso exclusivo del destinatario > >>indicado. Cualquier uso en desacuerdo con su propósito, difusión o > >>publicación, total o parcial, se encuentra prohibida. Si recibió este > >>mensaje por error, rogamos reenviarlo al emisor y destruir las copias > >>impresas o grabadas en su sistema. Las opiniones contenidas, son > >>exclusivas de su autor y no representan necesariamente la opinión de > >>OMINT S.A. de Servicios. > >> > >> > > > > > > > > AVISO: El presente mensaje y los archivos adjuntos que incluya pueden > >contener información confidencial de uso exclusivo del destinatario > >indicado. Cualquier uso en desacuerdo con su propósito, difusión o > >publicación, total o parcial, se encuentra prohibida. Si recibió este > >mensaje por error, rogamos reenviarlo al emisor y destruir las copias > >impresas o grabadas en su sistema. Las opiniones contenidas, son > >exclusivas de su autor y no representan necesariamente la opinión de > >OMINT S.A. de Servicios. > > > > > > > > __________ Información de NOD32, revisión 2587 (20071011) __________ > > Este mensaje ha sido analizado con NOD32 antivirus system > http://www.nod32.com
