none
SE HA FORZADO LA INTERRUPCIÓN DE UNA CONEXIÓN EXISTENTE POR EL HOST REMOTO RRS feed

  • Pregunta

  • Buen Día Amigos del Foro.

    Explicare mi problema, hace unas cuantas semanas empecé a tener el siguiente error en varias consultas:

    Mens. 10054, Nivel 20, Estado 0, Línea 0

    Error en el nivel de transporte al enviar la solicitud al servidor. (provider: Proveedor de TCP, error: 0 - Se ha forzado la interrupción de una conexión existente por el host remoto.)

    Este problema lo genera a la primera vez de ejecutar una consulta una consulta ‘X’ que hasta podría ser la más simple (SELECT *FROM name_table), posteriormente al ejecutarla inmediatamente por segunda vez ya me muestra correctamente el resultado; vuelvo a mencionar que esto no tiene mucho tiempo que empezó a generarlo pues había estado trabajando sin problemas algunos.

    Actualmente me encuentro trabajando con SQL SERVER 2008 donde me conecto desde mi equipo a un servidor que es donde se tiene la BD.

    miércoles, 5 de agosto de 2015 16:41

Respuestas

  • Ok veo que tiene 4 cores sin hyper threading 

    El parelelismo intentemos dejarlo en 2

    A la vez necesitas crear 4 archivos para la tempdb (1 mdf y 3 ndf)

    http://sqlservertoolbox.blogspot.com/2015/02/paralelismo-en-sql-server.html

    http://sqlservertoolbox.blogspot.com/2015/02/mejores-practicas-de-tempdb.html

    realiza estos cambia y ve si aun se presenta el comportamiento.


    miércoles, 5 de agosto de 2015 18:49
  • Saludos Rafael, 

    Lamentablemente necesitaría poder ver el servidor en tiempo real, o pedirte varias cosas como trazar para ver el comportamiento, es posible que alguien mas tenga una idea (posiblemente aumentar el tiempo que la conexión permanece abierta).

    Tu configuración parece correcta.  

    viernes, 7 de agosto de 2015 16:16

Todas las respuestas

  • Saludos Rafel, parece que excediste el tiempo de respuesta, cuanto tiempo tarda en ejecutarse la consulta y por medio de que la haces?.  
    miércoles, 5 de agosto de 2015 16:47
  • Hola, me parece que lo que ocurre es que se esta cerrando la conexión de Management Studio hacia SQL, por eso la primera vez que haces el query falla, y es muy probable que falle después de cierto tiempo.

    Desconozco la solución real pero te cuento mi experiencia, igual y te ayuda, había un DBA que acostumbraba por su proceso de mantenimiento cerrar de forma manual todas las conexiones a la base, esto lo hacia mediante un script, el resultado era, que momentos después de la ejecución del script todos obtenían este error, así que investiga si alguien no esta cerrando manualmente las conexiones.

    Después de eso, en algún momento cambiaron la propiedad AutoCose de la base de datos a true, esto hace que las conexiones se cierren, y el error se vuelve repetitivo, con este query puedes validar este valor.

    SELECT DATABASEPROPERTY('BaseDeDatos','IsAutoClose')

    Ahora en caso de ser automático esto, no conozco la causa, pero espero que por lo menos esto te ayude un poco con tu problema.

    Saludos


    Ing. Carlos Monroy MCP, MCAD, MCSD, MCTS


    • Editado Carlos Adan miércoles, 5 de agosto de 2015 16:58 error en termino
    miércoles, 5 de agosto de 2015 16:58
  • Saludos Enrique.

    La consulta con la que recuerdo empecé a tener el problema actualmente me tarda en promedio en generar 6 minutos y a partir de 3 minutos ya me empieza a mostrar resultados.

    La consulta la ejecuto directamente en SQL Server Management Studio


    • Editado Rafael L J miércoles, 5 de agosto de 2015 17:02
    miércoles, 5 de agosto de 2015 17:00
  • Saludo Carlos.

    Muy bien pondre en practica lo comentado y comentare mis resultados, gracias

    miércoles, 5 de agosto de 2015 17:03
  • Bien Carlos al momento de ejecutar la consulta para el AutoClose obtengo un cero como resultado...
    miércoles, 5 de agosto de 2015 17:08
  • Y asi se debe de quedar, nunca pongas auto close.

    Tengo una duda la consulta es a una base local, es un linked server o algo similar?. 

    miércoles, 5 de agosto de 2015 17:23
  • La consulta es via remotamente; no recuerdo haber configurado un linked, solamente hice la configuaracion para permitir conexiones remotas ...
    miércoles, 5 de agosto de 2015 17:36
  • ¿y es en todos los casos? o solo después de un tiempo

    Ing. Carlos Monroy MCP, MCAD, MCSD, MCTS

    miércoles, 5 de agosto de 2015 17:39
  • Si la consulta es del tipo trivial como parece por lo que describes puede ser que simplemente estés agotando el tiempo de conexión.

    select top 10 *
    from sys.dm_os_wait_stats
    where wait_type not in --remove common waits to identify worst bottlenecks
    ( 
    'KSOURCE_WAKEUP', 'SLEEP_BPOOL_FLUSH', 'BROKER_TASK_STOP',
    'XE_TIMER_EVENT', 'XE_DISPATCHER_WAIT', 'FT_IFTS_SCHEDULER_IDLE_WAIT',
    'SQLTRACE_BUFFER_FLUSH', 'CLR_AUTO_EVENT', 'BROKER_EVENTHANDLER',
    'LAZYWRITER_SLEEP', 'BAD_PAGE_PROCESS', 'BROKER_TRANSMITTER', 
    'CHECKPOINT_QUEUE', 'DBMIRROR_EVENTS_QUEUE', 'LAZYWRITER_SLEEP', 
    'ONDEMAND_TASK_QUEUE', 'REQUEST_FOR_DEADLOCK_SEARCH', 'LOGMGR_QUEUE', 
    'SLEEP_TASK', 'SQLTRACE_BUFFER_FLUSH', 'CLR_MANUAL_EVENT',
    'BROKER_RECEIVE_WAITFOR', 'PREEMPTIVE_OS_GETPROCADDRESS', 
    'PREEMPTIVE_OS_AUTHENTICATIONOPS', 'BROKER_TO_FLUSH'
    ) 
    order by wait_time_ms desc
    

    Ejectuta eso y pon los resultados

    miércoles, 5 de agosto de 2015 17:42
  • Pues podria ser en todos lo casos, el menor tiempo que me ha tardado una consulta despues del error es de 3 segundos.
    miércoles, 5 de agosto de 2015 17:44
  • Este el resultado de la consulta Enrique:

    WAIT_TYPE

    WAITING_TASKS_COUNT

    WAIT_TIME_MS

    MAX_WAIT_TIME_MS

    SIGNAL_WAIT_TIME_MS

    CXPACKET

    11107578

    80634039

    10678

    1930381

    LATCH_EX

    41615970

    13426490

    137

    3421547

    SOS_SCHEDULER_YIELD

    24309565

    2123531

    56

    2113438

    ASYNC_IO_COMPLETION

    30

    633095

    46992

    0

    BACKUPBUFFER

    41397

    560307

    560

    1149

    ASYNC_NETWORK_IO

    88418

    296501

    30000

    6163

    BACKUPIO

    22982

    109352

    514

    139

    WRITELOG

    130757

    96440

    624

    7387

    PAGEIOLATCH_SH

    35519

    82190

    1003

    233

    EXECSYNC

    96387

    72231

    1933

    2348

    miércoles, 5 de agosto de 2015 17:52
  • mm

    Cuantos procesadores tiene tu servidor donde tienes sql y que nivel de paralelismo tienes configurado?, sino conoces el nivel de paralelismo corre esto por favor. 

    EXEC sp_configure 'max degree of parallelism'


    • Editado Enrique AA miércoles, 5 de agosto de 2015 17:55
    miércoles, 5 de agosto de 2015 17:54
  • solo tengo un solo procesador en el equipo donde se encuentra SQL.

    y al momento de ejutar de ejectar la consulta marcada me genera error:

    Mens 15123, Nivel 16, Estado 1, Procedimiento sp_configure, Línea 51
    La opción de configuración 'max degree of parallelism' no existe o se trata de una opción avanzada.

    miércoles, 5 de agosto de 2015 18:03
  • Disculpa pero debes de tener mas de un core, puedes tener un solo procesador pero este puede tener varios core, esto es por tu alto nivel de paralelismo.

    Necesitamos ver esto y bajarlo, a la vez quiero saberlo por la configuración de tu tempdb que esta teniendo contención.

    exec sp_configure 'show advanced options', '1'
    reconfigure with override
    GO
    exec sp_configure
    

    miércoles, 5 de agosto de 2015 18:07
  • El procesador que se tiene es un Intel(R) Xeon(R) CPU E3-1220 V2 @ 3.10 HGz

    miércoles, 5 de agosto de 2015 18:23
  • Ok veo que tiene 4 cores sin hyper threading 

    El parelelismo intentemos dejarlo en 2

    A la vez necesitas crear 4 archivos para la tempdb (1 mdf y 3 ndf)

    http://sqlservertoolbox.blogspot.com/2015/02/paralelismo-en-sql-server.html

    http://sqlservertoolbox.blogspot.com/2015/02/mejores-practicas-de-tempdb.html

    realiza estos cambia y ve si aun se presenta el comportamiento.


    miércoles, 5 de agosto de 2015 18:49
  • Ok muy bien empesare a hacer los cambios y comentare mis resultados...

    Gracias.

    miércoles, 5 de agosto de 2015 18:55
  • Hola muy buen dia.

    Siguiendo con el tema; he realizado los cambios mencionados y habia estado trabajando excelentemente bien el medio dia de los cambios y ayer todo el dia y hasta hoy volvi con el error marcado...

    viernes, 7 de agosto de 2015 16:01
  • Saludos Rafael, 

    Lamentablemente necesitaría poder ver el servidor en tiempo real, o pedirte varias cosas como trazar para ver el comportamiento, es posible que alguien mas tenga una idea (posiblemente aumentar el tiempo que la conexión permanece abierta).

    Tu configuración parece correcta.  

    viernes, 7 de agosto de 2015 16:16
  • Esta bien Enrique AA, Gracias por el tiempo prestado :)

    viernes, 7 de agosto de 2015 16:45