Lentitud al migrar a Sql-Express

[gonmor]

Buenos dias, tengo un problema que empieza a ser critico por que no doy con una solucion y la solucion apremia. Os cuento.
Tengo una aplicacion que temporalmente corria en Sql-Server 2000 (ILEGAL) en servidor de test y iba muy bien. Bueno pues al pasarlo a produccion (LEGAL) va lento pero es problema del servidor que esta a tope.
Total que como solo tengo una licencia y no puedo moverla de ese servidor mi opcion fue instalar en Servidor de Test (donde iba muy bien) el Sql-Express que es free. Todo bien hasta que veo que el rendimiento es bastante menor que el esperado.
En el mismo servidor con SQL 2000 va perfecto pero con Express no.
Ahora estoy viendo la opcion de instalar la version personal de SQL-Server 2000 en vez la estandar que es la de pago. ¿que opinais? ¿es buena opcion? que diferencia hay exactamente con la vesion personal para que sea gratuita?
¿se os ocurre por que en Express va tan lento?
Gracias por todo.

[iislas]

Dependera de como se haya migrado la informacion a la version Express, para tratar de determinar la causa de la lentitud, comunmente, es la regeneracion de indices y estadisticos.

[usuariobaneado]

Islas me recomendó está página:

http://searchsystemschannel.techtarg...229039,00.html

Que hasta la vez la analizo pero la tengo en mis favoritas

[gonmor]

El procedimiento que probe para el traslado fueron dos, en una hice copia de seguridad y restaure y fue lento, luego actualize estadisticas y siguio lento.
El segundo fue separar la base de datos y adjuntarla en el nuevo servidor y mas tarde tambien actualice y nada sigue lento.
Con la version personal funciona tambien muy rapido pero no tengo claro si es legal usarla para esto o no ya que creo que en teoria es solo para equipos no servers.
No he probado a regenerar indices, me puedes decir como se hace, muchas gracias.

[usuariobaneado]

Regenerar indices... un tema interesante

La optimización de indices no es solamente la acción de regenerar indices, primero se debe de analizar cuales indices deben ser reorganizados y cuales reconstruidos.

Para tomar una desición primero debemos conocer el nivel de fragmentación de los indices. Si el porcentaje de fragmentación es menor o igual al 30% la mejor práctica es reorganizar los indices. Si el porcentaje es mayor al 30% reconstruir los índices.

Ahora, para conocer el porcentaje de fragmentación de un índices podemos utilizar el método del sistema sys.dm_db_index_physical_stats

Aquí te construí un select en el que hago join con sys.indexes, para obtener el porcentaje de fragmentación de los índices de la tabla Product de la base de datos que viene de ejemplo en sql server 2005 AdventureWorks:

Código PHP:

  SELECT a.index_id, name, avg_fragmentation_in_percent 
FROM sys.dm_db_index_physical_stats (DB_ID('AdventureWorks'), 
    OBJECT_ID('Production.Product'), NULL, NULL, NULL) AS a 
    JOIN sys.indexes AS b ON a.object_id=b.object_id AND a.index_id=b.index_id  
   

Luego, dependiendo de lo que muestre el select puedes hacerle un reorganize o un rebuild a los índices.

Para hacer un reorganize:

ALTER INDEX <NombreIndice> ON <NombreTabla> REORGANIZE

Para reorganizar todos los índices de una tabla, de una manera rápida la podemos hacer así:

ALTER INDEX ALL ON <NombreTabla>

Para hacer un rebuild:

ALTER INDEX <NombreIndice> ON <NombreTabla> REBUILD


Reorganizar un indice desfragmentado lo que hace es reordenar el nivel de hoja del indice clustered o nonclustered en las tablas físicas para tener las páginas de nivel de hoja en su orden lógico original, que es de izquierda a derecha. Reorganizar indices tambien compacta las páginas de indice, las paginas vacias creadas serán eliminadas. La compactación es basada en el valor del llamado FILL FACTOR que la podemos ver en la vista del sistema sys.indexes, pero bue... ese ya es otro tema.

Hacerle un rebuild al indice es dropearlo y crear uno nuevo. Al hacer esto, la fragmentación es eliminada y las paginas de indices son también son compactadas logrando liberar espacio.

Una herramienta útil es el Database Engine Tuning Advisor, hay mucho que hablar, se podría hacer un tema y ponerlo en las FAQS.

Espero haber sido de ayuda y que el tiempo tomado en escribir este post no haya sido escrito en vano.

Saludos Cordiales

[gonmor]

No se si esto solucionara mi problema pero te aseguro que en vano no ha sido tu brillante explicación si no es ahora estoy seguro que en el futuro le dare buen uso.

El caso es no aun no comprendo por que si el indice estubiera fragmentado por que en sql 2000 funciona tan bien y en express tan mal. No obstante probare tu consejo aunque me va a suponer mucho trabajo pues tengo como 40 tablas y veo que hay que ir una a una recostruyecto indices.

Sobre la herramienta Database Engine Tuning Advisor me gustaria mas información si es posible creo que puede ser muy interesante si no para esta base de datos, que es pequeña, si para otras mas complejas.

Y lo dicho chapo por la explicación

[iislas]

Ademas, por lo que comentas, si hiciste un RESTORE, debes cambiar el nivel de compatibilidad de tu base a 9.0

[usuariobaneado]

Una pregunta, al actualizar se logra un mejor performance? Es que estaba viendo en mi base de datos, en la propiedades dice Actualizar Estadísticas Automáticamente => True. Entonces supongo que si migro de sql server 2000 a 2005 no necesito actualizar aquello.

Encontré esta opción porque estaba en propiedades buscando si por allí aparecía el nivel de compatibilidad, que según comentas debe de ser 9.0

Podrías por favor indicar que donde podemos encontrar dicho valor y que hay que hacer para cambiarlo en caso de estar desactualizado?

Gracias por la atención.

Saludos Cordiales

[iislas]

En propiedades, revisa el nivel de compatibilidad, debe estar en 9.0

y de todos modos ejecuta: SP_UPDATESTATS

[gonmor]

Efectivamente por defecto en propiedades-opciones de la base de datos viene autoupdate estadisticas en true, ya aun asi lo ejecute a mano pero no soluciono mi problema. Tambien probe varios tipos de compatibilidad pero tampoco soluciono el problema.

Saludos.

[iislas]

gonmor

el TIPO DE COMPATIBILIDAD, no es para estar PROBANDO, simplemente, si estas trabajando en 2005, la compatibilidad es 9.0, si estas en 2000, entonces es 8.0.

revisa tus indices, regeneralos de ser necesario

Siempre que se "mueve" una base, se deben actualizar los estadisticos de forma manual, siempre

[usuariobaneado]

Iniciado por iislas

gonmor

el TIPO DE COMPATIBILIDAD, no es para estar PROBANDO, simplemente, si estas trabajando en 2005, la compatibilidad es 9.0, si estas en 2000, entonces es 8.0.

revisa tus indices, regeneralos de ser necesario

Siempre que se "mueve" una base, se deben actualizar los estadisticos de forma manual, siempre

Unas consultas ya que se está tocando el tema:

Pude revisar y encontré en las propiedades de mi base de datos que el NIVEL DE COMPATIBILIDAD está seleccionado SQL SERVER 2000 (80). Según dice Islas, esto debe de estar en SQL SERVER 2000 (90)

Además me recomiendo actualizar las estadísticas. Pero además encontré esto:

Revisando los links encuentro que al migrar de sql 2000 a 2005 se debe de tener en cuenta:

Volver a llenar los catálogos de texto: el proceso de actualización marca las bases de datos como deshabilitadas para texto. Debe volver a llenar los catálogos, pero el programa de instalación no ejecuta automáticamente esta operación porque puede tardar bastante tiempo. Dado que esta operación mejora el rendimiento de la instalación de SQL Server 2005, los administradores deben volver a llenar los catálogos de texto cada cierto tiempo.

Actualizar estadísticas: para ayudarle a optimizar el rendimiento de consultas, es recomendable actualizar las estadísticas de todas las bases de datos tras la actualización. Utilice el procedimiento almacenado sp_updatestats para actualizar las estadísticas de las tablas definidas por el usuario en las bases de datos de SQL Server 2005.

Actualizar contadores de uso: en las versiones anteriores de SQL Server, los valores del recuento de filas por tabla y por índice y del recuento de páginas pueden llegar a ser incorrectos. Para corregir cualquier recuento de filas o de páginas incorrecto, le recomendamos que ejecute DBCC UPDATEUSAGE en todas las bases de datos tras la actualización.

Entiendo solo el segundo punto, actualizar estadísticas, lo cual ya lo hemos hablado. Pero no entiendo de que se trata el primer y el tercer punto. También es necesario aquello? Lo pregunto porque Islas solo ha mencionado actualizar estadísticas

[iislas]

Es por eso que Microsoft recomienda un plan de migracion, donde el primer punto y que es escencial para una migracion exitosa es ejecutar el SQL Server Upgrade Advisor, que nos dara un informe de que "tan trasparente" puede ser la migracion y evitarnos muchas molestias.

Los pasos que mencionas, son importantes, pero por ejemplo te pregunto, ¿Tienes busquedas de TEXTO activadas?, si tu repuesta es NO, entonces omite "Volver a llenar los catálogos de texto"

Saludos