salida procedimientos procedimiento permisos parametros para mostrar ejemplo ejecutar datos almacenados almacenado sql sql-server asp-classic timeout sql-server-2000

procedimientos - procedimiento almacenado sql server select



Procedimiento almacenado que falla en un usuario especĂ­fico (5)

Tengo un procedimiento almacenado que falla constantemente con el mensaje de error "Tiempo de espera caducado" en un usuario específico.

Todos los demás usuarios pueden invocar la sp muy bien, e incluso yo puedo invocar la sp normalmente usando el Analizador de consultas: termina en solo 10 segundos. Sin embargo, con el usuario en cuestión, los registros muestran que el ASP siempre se cuelga durante aproximadamente 5 minutos y luego cancela con un tiempo de espera.

Invoco desde la página ASP como " EXEC SP_TV_GET_CLOSED_BANKS_BY_USERS ''006111'' "

¿Alguien sabe cómo diagnosticar el problema? Ya he intentado buscar bloqueos en el DB, pero no encontré ninguno.

Gracias,


Creo que para responder a su pregunta, es posible que necesitemos un poco más de información.

Por ejemplo, ¿está utilizando Active Directory para autenticar a sus usuarios? ¿Has usado el analizador SQL para investigar? Parece que podría ser un problema de autenticación donde SQL Server tiene problemas para autenticar a este usuario en particular.


Me parece un problema de bloqueo.

También asegúrese de que este usuario tenga derechos de ejecución y lectura en SQL Server

Pero si en el momento en que se escribe la información que intenta ser leída se bloqueará, ya que la transacción aún no se ha confirmado.

Jeff hizo un gran post acerca de su experiencia con eso y . http://www.codinghorror.com/blog/archives/001166.html


Bueno, podría sugerirle que use SQL Server Profiler y abra una nueva sesión. Invoque su procedimiento almacenado desde su página ASP y vea lo que está sucediendo. Si bien esto puede no resolver su problema, seguramente puede proporcionar un punto de partida para que pueda llevar a cabo su propia "investigación".


Un par de cosas para verificar:

  1. ¿Esto sucede solo en la máquina de ese usuario específico? ¿Puede intentarlo desde otra máquina? - podría ser un problema de configuración del cliente.
  2. ¿Puedes capturar la cadena real que ejecuta este usuario específico y ejecutarla desde una página ASP? Es posible que el usuario ejecute el SP de una manera que genere un bucle o una gran cantidad de datos.
  3. Finalmente, si está utilizando una aplicación dentro de la organización, es posible que los permisos de su usuario en particular sean diferentes a los demás. Puede compararlos en el nivel de Active Directory.

Ahora, puedo recomendar un software comercial que definitivamente resolverá su problema. Registra transacciones de extremo a extremo y analiza fallas particulares. Pero no quiero anunciar en este foro. Si quieres, envíame una nota y te explicaré más.


Algunos pensamientos...

Leer los comentarios sugiere que el olfateo de parámetros está causando el problema.

  • Para los otros usuarios, el plan en caché es lo suficientemente bueno para el parámetro que envían
  • Para este usuario, el plan en caché probablemente sea incorrecto

Esto podría suceder si este usuario tiene muchas más filas que otros usuarios o tiene filas en otra tabla (por lo que sería mejor una búsqueda / exploración de tabla / índice diferente)

Para probar el olfateo de parámetros:

  • use RECOMPILE (temporalmente) en la llamada o en la def. Esto podría ser lento para consultas complejas
  • Reconstruya los índices (o solo las estadísticas) después del tiempo de espera y vuelva a intentarlo. Esto invalida todos los planes en caché

Para corregir: enmascare el parámetro

DECLARE @MaskedParam varchar(10) SELECT @MaskedParam = @SignaureParam SELECT...WHERE column = @MaskedParam

Simplemente busque en google "Parameter sniffing" y "Parameter masking"