none
SQL Lento in VPN RRS feed

  • Domanda

  • Ciao a tutti

    In azienda utilizzo un software che si aggancia a DB su SQL server 2014 standard e fino a quando si lavora in LAN non ci sono problemi.

    Da qualche settimana c'è la necessità di utilizzare il software dall'esterno e quindi ho installato un ruolo Remote Access per far collegare gli utenti dall'esterno in VPN.

    Ho configurato il firewall per permettere l'accesso sulle porte TCP 1433 e UDP 1435 per SQL e l'allow per sqlsrv.exe e sqlbrowser.exe.

    Il problema è che da quando lancio il software e faccio invio dopo aver inserito le sue credenziali passano 4/5min prima che diventi utilzzabile (sto facendo dei test da una connessione casalinga non troppo veloce ma può essere solo questo?).

    Inoltre ho notato che se in SQL Server Configuration Manager disabilito Named Pipes e tento di fare il login col software dopo 1min mi restituisce un errore di timeout( non so se questa info può essere utile per analizzare il problema).

    Ulteriore info: i pc che si stanno collegando alla VPN non sono nel mio Dominio

    Qualcuno mi sà dare una mano?

    lunedì 25 gennaio 2016 14:38

Risposte

  • Anche se riesci a risolvere i problemi ti timeout, se poi hai delle query che ritornano quantità di dati voluminosi, la connettività diventa un punto critico e come dice Sergio è facile trovarsi in situazioni disperate..., tanto che ci sono aziende specializzate, che vendono hardware per accelerare sql su WAN, ma questi oggetti costano un botto, di solito si ovvia con delle connessioni vpn + remote desktop .

    Gli applicativi client server non amano le connessioni wan o meglio non amano avere poca banda...

    Ciao


    Gastone Canali >http://www.armadillo.it


    Se alcuni post rispondono al tuo quesito(non necessariamente i miei), ricorda di contrassegnarli come risposta e non dimenticare di contrassegnare anche i post utili. GRAZIE! Ricorda di dare un occhio ai link Click Here andHere

    giovedì 28 gennaio 2016 00:14

Tutte le risposte

  • Ciao Roberto,

    le esperienze che ho avuto io con le connessioni VPN (per l'accesso all'ERP) mi hanno insegnato che senza una buona connessione (lato client) è tutto più o meno inutilizzabile :(

    Comunque, prova a controllare i wait type dell'istanza.. magari ci dicono qualcosa di interessante, puoi utilizzare la query di Glenn Berry:

    WITH [Waits] AS
        (SELECT
            [wait_type],
            [wait_time_ms] / 1000.0 AS [WaitS],
            ([wait_time_ms] - [signal_wait_time_ms]) / 1000.0 AS [ResourceS],
            [signal_wait_time_ms] / 1000.0 AS [SignalS],
            [waiting_tasks_count] AS [WaitCount],
            100.0 * [wait_time_ms] / SUM ([wait_time_ms]) OVER() AS [Percentage],
            ROW_NUMBER() OVER(ORDER BY [wait_time_ms] DESC) AS [RowNum]
        FROM sys.dm_os_wait_stats
        WHERE [wait_type] NOT IN (
            N'BROKER_EVENTHANDLER',             N'BROKER_RECEIVE_WAITFOR',
            N'BROKER_TASK_STOP',                N'BROKER_TO_FLUSH',
            N'BROKER_TRANSMITTER',              N'CHECKPOINT_QUEUE',
            N'CHKPT',                           N'CLR_AUTO_EVENT',
            N'CLR_MANUAL_EVENT',                N'CLR_SEMAPHORE',
            N'DBMIRROR_DBM_EVENT',              N'DBMIRROR_EVENTS_QUEUE',
            N'DBMIRROR_WORKER_QUEUE',           N'DBMIRRORING_CMD',
            N'DIRTY_PAGE_POLL',                 N'DISPATCHER_QUEUE_SEMAPHORE',
            N'EXECSYNC',                        N'FSAGENT',
            N'FT_IFTS_SCHEDULER_IDLE_WAIT',     N'FT_IFTSHC_MUTEX',
            N'HADR_CLUSAPI_CALL',               N'HADR_FILESTREAM_IOMGR_IOCOMPLETION',
            N'HADR_LOGCAPTURE_WAIT',            N'HADR_NOTIFICATION_DEQUEUE',
            N'HADR_TIMER_TASK',                 N'HADR_WORK_QUEUE',
            N'KSOURCE_WAKEUP',                  N'LAZYWRITER_SLEEP',
            N'LOGMGR_QUEUE',                    N'ONDEMAND_TASK_QUEUE',
            N'PWAIT_ALL_COMPONENTS_INITIALIZED',
            N'QDS_PERSIST_TASK_MAIN_LOOP_SLEEP',
            N'QDS_CLEANUP_STALE_QUERIES_TASK_MAIN_LOOP_SLEEP',
            N'REQUEST_FOR_DEADLOCK_SEARCH',     N'RESOURCE_QUEUE',
            N'SERVER_IDLE_CHECK',               N'SLEEP_BPOOL_FLUSH',
            N'SLEEP_DBSTARTUP',                 N'SLEEP_DCOMSTARTUP',
            N'SLEEP_MASTERDBREADY',             N'SLEEP_MASTERMDREADY',
            N'SLEEP_MASTERUPGRADED',            N'SLEEP_MSDBSTARTUP',
            N'SLEEP_SYSTEMTASK',                N'SLEEP_TASK',
            N'SLEEP_TEMPDBSTARTUP',             N'SNI_HTTP_ACCEPT',
            N'SP_SERVER_DIAGNOSTICS_SLEEP',     N'SQLTRACE_BUFFER_FLUSH',
            N'SQLTRACE_INCREMENTAL_FLUSH_SLEEP',
            N'SQLTRACE_WAIT_ENTRIES',           N'WAIT_FOR_RESULTS',
            N'WAITFOR',                         N'WAITFOR_TASKSHUTDOWN',
            N'WAIT_XTP_HOST_WAIT',              N'WAIT_XTP_OFFLINE_CKPT_NEW_LOG',
            N'WAIT_XTP_CKPT_CLOSE',             N'XE_DISPATCHER_JOIN',
            N'XE_DISPATCHER_WAIT',              N'XE_TIMER_EVENT')
        AND [waiting_tasks_count] > 0
     )
    SELECT
        MAX ([W1].[wait_type]) AS [WaitType],
        CAST (MAX ([W1].[WaitS]) AS DECIMAL (16,2)) AS [Wait_S],
        CAST (MAX ([W1].[ResourceS]) AS DECIMAL (16,2)) AS [Resource_S],
        CAST (MAX ([W1].[SignalS]) AS DECIMAL (16,2)) AS [Signal_S],
        MAX ([W1].[WaitCount]) AS [WaitCount],
        CAST (MAX ([W1].[Percentage]) AS DECIMAL (5,2)) AS [Percentage],
        CAST ((MAX ([W1].[WaitS]) / MAX ([W1].[WaitCount])) AS DECIMAL (16,4)) AS [AvgWait_S],
        CAST ((MAX ([W1].[ResourceS]) / MAX ([W1].[WaitCount])) AS DECIMAL (16,4)) AS [AvgRes_S],
        CAST ((MAX ([W1].[SignalS]) / MAX ([W1].[WaitCount])) AS DECIMAL (16,4)) AS [AvgSig_S]
    FROM [Waits] AS [W1]
    INNER JOIN [Waits] AS [W2]
        ON [W2].[RowNum] <= [W1].[RowNum]
    GROUP BY [W1].[RowNum]
    HAVING SUM ([W2].[Percentage]) - MAX ([W1].[Percentage]) < 99; -- percentage threshold
    GO

    Ciao


    Sergio Govoni

    SQL Server MVP
    MVP Profile | English Blog | Twitter | LinkedIn

    mercoledì 27 gennaio 2016 22:41
    Moderatore
  • Anche se riesci a risolvere i problemi ti timeout, se poi hai delle query che ritornano quantità di dati voluminosi, la connettività diventa un punto critico e come dice Sergio è facile trovarsi in situazioni disperate..., tanto che ci sono aziende specializzate, che vendono hardware per accelerare sql su WAN, ma questi oggetti costano un botto, di solito si ovvia con delle connessioni vpn + remote desktop .

    Gli applicativi client server non amano le connessioni wan o meglio non amano avere poca banda...

    Ciao


    Gastone Canali >http://www.armadillo.it


    Se alcuni post rispondono al tuo quesito(non necessariamente i miei), ricorda di contrassegnarli come risposta e non dimenticare di contrassegnare anche i post utili. GRAZIE! Ricorda di dare un occhio ai link Click Here andHere

    giovedì 28 gennaio 2016 00:14
  • Grazie ad entrambi.

    @Sergio: quella query la posso lanciare direttamente in sql server? Non sono molto pratico di SQL.

    Cosa dovrebbe restituirmi?

    Alla fine credo che opterò per VPN + RDP... solo per non sentirmi dire il classico "perchè non funziona"!! :-)


    giovedì 28 gennaio 2016 08:19
  • @Sergio: quella query la posso lanciare direttamente in sql server? Non sono molto pratico di SQL.

    Cosa dovrebbe restituirmi?

    Ciao Roberto,

    certo, la puoi eseguire con SQL Server Management Studio, restituisce i tipi di attesa piu' significativi per la tua istanza.

    Una query, durante la sua esecuzione, può essere sospesa decine o addirittura centinaia di volte, ogni sospensione e' caratterizzata dal relativo tipo di attesa (non c'e' abbastanza CPU, la risorsa a cui si sta tentando di accedere e' bloccata, ecc..).. se vuoi approfondire ti consiglio questo video su Channel 9: The Most Prominent Wait Types of your SQL Server.

    Ciao


    Sergio Govoni

    SQL Server MVP
    MVP Profile | English Blog | Twitter | LinkedIn

    giovedì 28 gennaio 2016 23:19
    Moderatore
  • Ragazzi alla fine ci ho rinunciato, anche da una connessione in fibra la lentezza è sempre più o meno quella!

    Evidentemente ci sono proprio delle query lunghe in fare di login al software.

    La soluzione che ho adottato è stata installare il ruolo RDP con licensing e host e installato del Cal RDS.

    Utilizzeranno RDP e si collegheranno al server.

    Grazie per il supporto ancora una volta.

    mercoledì 3 febbraio 2016 14:30
  • La soluzione che ho adottato è stata installare il ruolo RDP con licensing e host e installato del Cal RDS.

    Utilizzeranno RDP e si collegheranno al server.

    Ciao Roberto,

    mi sembra la soluzione migliore :)

    Giusto per curiosità, hai dato un'occhiata anche ai "wait type" più significativi ?

    Grazie a te!

    Ciao


    Sergio Govoni

    SQL Server MVP
    MVP Profile | English Blog | Twitter | LinkedIn

    mercoledì 3 febbraio 2016 18:19
    Moderatore
  • Ad essere totalmente sincero la query mi restituiva degli errori ed essendo giorni abbastanza frenetici(dopo aver fatto il test di connessione in fibra come dicevo nel post precedente) ho deciso di tagliare la testa al toro e risolvere il problema installato RDP e le Cal relative.

    Per sfizio personale, se e quando ci saranno tempi un pò più tranquilli, mi metterò con pazienza per guardarla meglio.

    Casomai ti aggiorno se sei curioso ;-)

    giovedì 4 febbraio 2016 08:11
  • Ciao Roberto,

    ero curioso di vedere i tipi di attesa in concomitanza delle connessioni VPN lente per cercare di capire se uno dei wait type di SQL OS poteva darci informazioni utili.. avendo cambiato completamente strategia, non è più necessario :)

    A presto!


    Sergio Govoni

    SQL Server MVP
    MVP Profile | English Blog | Twitter | LinkedIn


    venerdì 5 febbraio 2016 17:55
    Moderatore