none
Problema Extraño con usuarios RRS feed

  • Pregunta

  • Buenos Días.

    Bueno, llevo ya un tiempo con este preoblema y me sería de gran ayuda que me pudieran orientar.

    En donde trabajo tenemos un Windows 2003 Server Enterprise con un SQL Server 2000 Enterprise, en el cual se alberga una base de datos de aproximadamente 13 Gb. El sistema que utilizamos es un sistema no desarrollado internamente, con lo cual no tenemos acceso a las sentencias sql, ni a los modos de programación, etc..

    Basicamente el problema es que algunos procesos tardan mucho en liberar (devolver los datos) con el usuario 'sa' y con otro usuario creado por nosotros, libera casi instantaneamente. Lo que pude descubrir es que si el usuario que utilizo para la conexión al sql posee la función de System Administrators (sysadmin) se me genera este problema de lentitud en algunos procesos.

    Por otra parte el proveedor de nuestro sistema recomienda la utilización del usuario 'sa'.

    Uds. me dirán que utilice otra configuración de usuario, pero si utilizo otro usuario con otros permisos o funciones distintos de sysadmin, los problemas de lentitud o errores se me generan en otros procesos.

    Muchas Gracias por la atención.
    lunes, 24 de agosto de 2009 15:47

Respuestas

  • Hola.

    Por un lado, tu "proveedor" no debe conocer mucho de seguridad de sql server, ya que recomienda usar el "sa" para un aplicación. No sólo no es una buena práctica, es una mala práctica que Microsoft no recomienda. No debe utilizarse salvo para casos muy excepcionales.

    El usuario que se utiliza tiene un impacto ínfimo en el rendimiento. Hay unas pequeñas cosas que no se verifican en el caso de ser sysadmin, pero es algo imperceptible y no es lo que te ocasiona el problema. Podría ser que esté ejecutándose el proceso desde una base de datos distinta o con alguna característica de conexión distinta y estar usándose un plan de ejecución distinto, pero tampoco es algo que sea frecuente. Lo de la devolución de datos para determinar si ha terminado o no el proceso, tampoco es algo por lo que debas guiarte, salvo que el resultado final sea el mismo y no obtengas errores.

    Sin embargo dices que con un usuario no sysadmin te devuelve errores, quizá no sólo te devuelva errores, sino que también está ejecutando menos cosas y por eso tarda menos. No sé si te refieres a un mismo proceso o a que unos funcionan y otros no.

    En resumen, deberías poder configurar un usuario con los permisos adecuados para ejecutar todo el proceso o cada proceso al menos. Si obtienes errores, a lo mejor podemos ayudarte con ellos.

    Alberto López Grande.
    lunes, 24 de agosto de 2009 16:01
    Moderador

Todas las respuestas

  • Hola.

    Por un lado, tu "proveedor" no debe conocer mucho de seguridad de sql server, ya que recomienda usar el "sa" para un aplicación. No sólo no es una buena práctica, es una mala práctica que Microsoft no recomienda. No debe utilizarse salvo para casos muy excepcionales.

    El usuario que se utiliza tiene un impacto ínfimo en el rendimiento. Hay unas pequeñas cosas que no se verifican en el caso de ser sysadmin, pero es algo imperceptible y no es lo que te ocasiona el problema. Podría ser que esté ejecutándose el proceso desde una base de datos distinta o con alguna característica de conexión distinta y estar usándose un plan de ejecución distinto, pero tampoco es algo que sea frecuente. Lo de la devolución de datos para determinar si ha terminado o no el proceso, tampoco es algo por lo que debas guiarte, salvo que el resultado final sea el mismo y no obtengas errores.

    Sin embargo dices que con un usuario no sysadmin te devuelve errores, quizá no sólo te devuelva errores, sino que también está ejecutando menos cosas y por eso tarda menos. No sé si te refieres a un mismo proceso o a que unos funcionan y otros no.

    En resumen, deberías poder configurar un usuario con los permisos adecuados para ejecutar todo el proceso o cada proceso al menos. Si obtienes errores, a lo mejor podemos ayudarte con ellos.

    Alberto López Grande.
    lunes, 24 de agosto de 2009 16:01
    Moderador
  • Primero que nada, muchas gracias por responder tan rápidamente.

    En respuesta a la primera acotación sí se que utilizar el usuario 'sa' es un problema de seguridad, pero también debó seguir comprobar las sugerencias de mi proveedor para poder seguir con otros puntos.

    El sistema utilizado realiza la conexión por medio de un DSN de archivo con la siguiente configuración:

    [ODBC]
    DRIVER=SQL Server
    UID=sa
    AnsiNPW=No
    QuotedId=No
    DATABASE=DATA
    APP=Microsoft Data Access Components
    SERVER= [nombredelservidor]


    El resultado final del mismo proceso con cada usuario diferente es el mismo, solo que con uno (sysadmin) tarda bastante más que con uno sin función (sysadmin).

    El porque de no utilizar otra configuración de usuario es que algunos procesos si no se utiliza un usuario con función de sysadmin, no funcionan o funcionan lento.

    Ya probé distintas configuraciones de usuario, pero ninguna satisfizo a todos los procesos que se ejecutan.


    El proveedor recientemente aconsejó migrar de SQL Server 2000 a SQL Server 2005/2008. Puede esto hacer la diferencia?

    Desde ya muchas gracias.
    lunes, 24 de agosto de 2009 16:49
  • Hola.

    Lamentable lo del proveedor. Y no es una excepción, yo me los encuentro cada dos por tres y resulta descorazonador.

    En cuanto a tu problema, sin conocer los procesos, es complicado determinar dónde puede estar el rendimiento. Sí parece que pueda ser cosa de algún plan de ejecución que no esté siendo igual en función de quién lo ejecuta. Te daría algunas recomendaciones generales, como asegurarse de que las estadísticas están actualizadas, que los índices no están muy fragmentados, etc. ¿Realizas estas tareas de mantenimiento con regularidad?

    En cuanto a las conexiones, ¿lo único que cambia de un caso a otro es el usuario o hay algún otro cambio (como por ejemplo, la base de datos por defecto, en un caso es ODBC y en otro OLE DB, no sé cualquier otra cosa).

    A ver, hay muchas ventajas en migrar a SQL Server 2008 (yo a estas alturas no migraría a 2005), ganas en rendimiento, en versatilidad, en funcionalidad, en seguridad. Pero, sin duda, eso te dará problemas (porque siempre los hay), requiere de una preparación importante y sin saber qué ocasiona el problema, esperar que la migración lo arregle es aventurarse mucho.

    Este problema debería resolverlo ese proveedor, pero con las cosas que dice, da pánico...

    Te dejo un link a la documentación de migración. Verás que no es algo como para tomarse a la ligera.



    Alberto López Grande.
    lunes, 24 de agosto de 2009 17:15
    Moderador
  • Si la aplicación necesita usar al 'sa' (o a un miembro de SysAdmins) para poder ejecutar todos los procesos, entonces no hay mucho para hacer por este lado: Usar un login no-sysadmin no permitirá ejecutar ciertos procesos.

    Como ha mencionado Alberto, el problema de rendimiento no tiene que ver con el login.

    IMO, usted debería consultar al proveedor para que analice los malos tiempos de respuesta y dé una solución. Simplemente migrar a SQL Server 2005/2008 no es totalmente seguro que mejore la situación, habría que medir y demostrar para apoyar la idea.

    Mi mejor sugerencia es que usted logre que el proveedor lo acompañe en todo esto, no creo que desde este foro podamos concluír en algo mejor.
    Gustavo Larriera, MVP --- Este mensaje se proporciona tal como es, sin garantías de ninguna clase. ---
    lunes, 24 de agosto de 2009 17:25
    Moderador
  • Alberto en respuesta a tus preguntas, sí las tareas de mantenimiento se realizan con regularidad y en cuanto a la segunda pregunta, el unico cambio es el usuario. Muchas gracias por la información brindada, lo analizaré y en cuanto resuelva que hacer se los comentaré.

    Gracias también Gustavo por las sugerencias, ya estamos tratando el tema con el proveedor.

    Muchas Gracias por la ayuda.
    martes, 25 de agosto de 2009 9:43
  • Hola.

    Pues si tú has hecho los deberes, entonces el proveedor debe ser quien te guíe. No descartes la ayuda que pueda brindarte Microsoft en este sentido, abriendo un caso de soporte, ya sea de forma directa o a través del proveedor.

    Alberto López Grande.
    martes, 25 de agosto de 2009 9:51
    Moderador