Mariano, el sql2005 tiene aproximadamente un 30% de mejora a nivel engine de performance, pero eso solo se aplica si y solo si esta en modo 90
Maximiliano Damian Accotto Microsoft MVP en SQLServer SQL Total Consulting Bogota 3631 P3B 1407 Buenos Aires-Argentina Movil: (011)-15-5868-5599 Desde el exterior: (+54-911)-5868-5599 <mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED] De: [email protected] [mailto:[EMAIL PROTECTED] En nombre de Jose Mariano Alvarez Enviado el: lunes, 24 de noviembre de 2008 08:46 p.m. Para: Maxi Asunto: [dbms] nivel de compatibilidad. Hay un conocido ERP que dice eso pero a mi no me consta y mediciones que hicimos no lo confirmaron. Tambien hay que tener en cuenta que el uso que hace del SQL Server es bastante desastroso por lo que no lo tomaria en cuenta como comparacion. . Yo diria que lo deberian medir para estar seguros. Por ejemplo el uso de la TempDb en 2005 es mayor por lo que hay que optimizar su uso. Si eso no se tiene en cuenta podria decaer el rendimiento. Por lo tanto habria que medir muy bien para estar seguros y configurara adecuadamente el SQL Server.. Como casi todas las migraciones que hice los clientes siempre quisieron un nuevo hardware no tengo datos de comparacion en compatibilidad 80. Ademas siempre hicimos el trabajo para pasar a compatibilidad 90. -------------------------------- Atte. Ing. Jose Mariano Alvarez SQL Total Consulting 2008/11/24 Carlos Peix <[EMAIL PROTECTED]> Gracias Maxi, Carlos Peix -----Mensaje original----- De: [email protected] [mailto:[EMAIL PROTECTED] En nombre de Maxi Accotto Enviado el: Lunes, 24 de Noviembre de 2008 03:12 p.m. Para: [EMAIL PROTECTED] Asunto: [dbms] nivel de compatibilidad. Con el profiler ! y en la aplicacion en si misma!! ojo que no siempre es asi, o sea, no aseguro 100% que la performance se degrade tanto pero el motor funciona distinto, me ha pasado en casos donde no habia diferencia casi, pero.. hay otros detalles Por ejemplo, no podes correr sobre un 2005 el "upgrate advisor" con lo cual si tenes la base en 80 sobre el 2005 y queres hacer el analisis de compatibilidad es mucho pero mcuho mas complejo, ahh no vale poner la base 2005 en modo 80 en un 2000, o sea, estas casi en el horno. Pero bueno, cuando yo hago migraciones aquellas bases que no se les puede cambiar la compatibilidad las identifico como legacy y la recomendacion es tratar de tener los sistemas bien para que puedan usar de forma adecuada todo el sql 2005 u 2008, me ha pasado q un cliente queria por ejemplo implementar mirror (que es algo de 2005) y no pudimos por la compatibilidad 80 de la base, con lo cual el cliente ha estado mas que enojado con la gente que desarrollo la aplicacion, porque convengamos una cosa, no es que de un dia para otro Ms dijo esto no va mas y lo saco del SQL, lo viene diciendo desde hace por lo menos 9 años, que features va a deprecar, es mas, si abren sus libros online veran las features que se van a deprecar a futuro El día 24 de noviembre de 2008 14:27, Hernán Zaldívar <[EMAIL PROTECTED]> escribió: > Maxi, buenos dias... muchas gracias por todo lo que aportas. > > Ya que estamos, como mediste la performance? Usaste alguna herramienta o midiendo a mano cuanto tardaba en resolver una consulta en un version y en otro? > > Saludos > > -----Mensaje original----- > De: [email protected] [mailto:[EMAIL PROTECTED] En nombre de Maxi Accotto > Enviado el: Lunes, 24 de Noviembre de 2008 12:13 p.m. > Para: Hernán Zaldívar > Asunto: [dbms] nivel de compatibilidad. > > Carlos, como estas? en varias instalaciones medi performance y he > notado hasta un 30% de diferencia por tener una base en modo > compatibilidad 80, pensa que hay distintos tipos de cambios y SQL por > ejemplo en modo 80 debe guardar los planes y calcularlos en ese modo > viejo con lo cual se degrada la performance, esto tambien aplica a > 2000 con compatibilidad 70, por ejemplo hace unas semanas en un > cliente le pasamos la base a 80 y cambio de forma considerable. > > Ademas de la performance no vas a poder usar nada de 2005, (mirror, > cifrado de datos, nuevos tipos de dato, novedades en la replicacion, > schemas de seguridad, particionamiento, restore online, index on line, > etc) o sea: tenes un F1 a GNC. > > En las migraciones te encontras de todo y por lo general son los > sistemas que estan desarrollados mal y que si ademas el codigo de SQL > lo tienen en la aplicacion tocar eso y hasta auditarlo es un dolor de > h.. > > Saludos > > El día 24 de noviembre de 2008 11:59, Carlos Peix > <[EMAIL PROTECTED]> escribió: >> Hola Maxi, >> >> Me habia olvidado de consultarte sobre este tema. >> >> Vos decis en un mail de hace unos dias: "ojo con esa recomendación de >> poner una base en modo 80 en un servidor 2005, eso no anda nada bien, >> es mucho mas lento, no podes usar los beneficios de 2005" >> >> Lo de usar los beneficios de 2005 es mas comprensible pero, podrias >> ampliar el tema de que no anda nada bien y que es mucho mas lento? En >> que condiciones? Que operaciones? >> >> Pregunto porque es una alternativa interesante para mi en algunos >> clientes que estan cambiando a 2005 pero no quieren cambiar la >> aplicación. Me gustaria saber cuales son los (posibles) problemas. >> >> Muchas gracias >> >> Carlos Peix >> >> -----Mensaje original----- >> De: [email protected] [mailto:[EMAIL PROTECTED] En nombre de Maxi >> Accotto Enviado el: Lunes, 24 de Noviembre de 2008 10:42 a.m. >> Para: [EMAIL PROTECTED] >> Asunto: [dbms] nivel de compatibilidad. >> >> Hola, es asi de facil, pero.. vos has verificado que las aplicaciones >> que usan esa base de datos sean compatibles con el nivel 90? Ojo que >> desde 2000 a 2005 se deprecaron varias funciones. >> Si no hiciste ese analisis previo te pueden dar errores las >> aplicaciones, la base igual luego la podes pasar a a 80 sin problema. >> >> >> >> El día 24 de noviembre de 2008 10:27, Jesús dos Santos >> <[EMAIL PROTECTED]> escribió: >>> Lista buenos días, tenia una base de datos sql 2000, la adjunté a >>> sql2005, el tema de nivel de compatibilidad es cambiarlo en las >>> propiedades de la base de datos de 80 a 90 nada mas y queda??? Tan >>> así de >> facil?? >>> >>> Y si creo una base de datos en 2005, y le paso toda la data de una >>> base a otra no es mejor??? (son 100 y pocas tablas) >>> >>> Leí hace unos días en estos emails, que dejar una base con >>> compatibilidad 80 en 2005 era lento. >>> >>> Me podrían tirar alguna idea - opinión al respecto? >>> >>> Muchas gracia por vuestra ayuda desde ya. >>> >>> Jesús >>> >>> >>> >>> __________ Información de ESET NOD32 Antivirus, versión de la base >>> de firmas de virus 3635 (20081124) __________ >>> >>> ESET NOD32 Antivirus ha comprobado este mensaje. >>> http://www.eset.com <http://www.eset.com/> >>> >> >> >> >> -- >> ----------------------------------------------------------- >> Microsoft MVP en SQL Server >> Consultor en SQLTotalConsulting >> Excelencia en servicios y consultoria SQLServer >> www.sqltotalconsulting.com <http://www.sqltotalconsulting.com/> >> ----------------------------------------------------------- >> >> >> > > > > -- > ----------------------------------------------------------- > Microsoft MVP en SQL Server > Consultor en SQLTotalConsulting > Excelencia en servicios y consultoria SQLServer > www.sqltotalconsulting.com <http://www.sqltotalconsulting.com/> > ----------------------------------------------------------- > > > -- ----------------------------------------------------------- Microsoft MVP en SQL Server Consultor en SQLTotalConsulting Excelencia en servicios y consultoria SQLServer www.sqltotalconsulting.com <http://www.sqltotalconsulting.com/> ----------------------------------------------------------- No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.175 / Virus Database: 270.9.9/1806 - Release Date: 22/11/2008 06:59 p.m.
