2012-12-05 7 views
5

tl; dr versioneIn che modo SSIS gestisce le connessioni di chiusura? Posso forzarlo?

ricevo errori quando si utilizza OLE DB (SNC10.0) gestioni connessioni dopo un paio di notti di esecuzione, potrebbero non essere correttamente i collegamenti del timeout? Passare a connessioni e gestori di connessioni ADO.NET sembra risolverlo, perché?

Mi scuso per il titolo generico ma ci sono troppi dettagli da specificare in una singola riga.

Tecnologia:

In tutti i casi il server di database, sia di origine e di destinazione sono di SQL Server 2008 R2

Il setup:

Ho una serie di pacchetti SSIS che corrono uno dopo l'altro nel bel mezzo della notte. Ce ne sono 7 al momento. Tutti eseguono un insieme simile di attività: prima si connettono a un database di origine e copiano i dati su un database di gestione temporanea. Quindi eseguono varie trasformazioni all'interno del database di staging. Infine, il processo si collega a un database di destinazione e lo riempie di dati.

Ho impostato tutte le connessioni come connessioni OLE DB (SQL Native Client 10.0) in modo da poterle utilizzare con i componenti di ricerca e altri componenti specifici di OLE.

Il problema:

abbiamo sperimentato problemi ripetutamente con i nostri funzionamenti automatizzati di pacchetto SSIS. Generalmente lo testerò manualmente dalla mia stazione, funzionerà correttamente; quindi salveremo il pacchetto SSIS in SQL Server e lo pianificheremo e funzionerà correttamente. Alcune sere dopo, avremo un problema come:

Codice errore SSIS DTS_E_OLEDBERROR. Si è verificato un errore OLE DB. Codice di errore: 0x80004005. Un record OLE DB è disponibile. Origine: "Provider Microsoft OLE DB per SQL Server" Hresult: 0x80004005 Descrizione: "Errore di protocollo nel flusso TDS".

o

Codice di errore SSIS DTS_E_OLEDBERROR. Si è verificato un errore OLE DB. Codice di errore: 0x80004005. Un record OLE DB è disponibile. Origine: "Microsoft SQL Server Native Client 10.0" Hresult: 0x80004005 Descrizione: "Token sconosciuto ricevuto da SQL Server".

Quando cercato on-line, entrambi questi punti verso i problemi di connessione e in particolare rete problemi di connettività.

work-around:

ho scoperto che un rapido, anche se non sempre semplice, soluzione a questi problemi è quello di sostituire i nodi origine con ADO NET Fonti piuttosto che OLE DB fonti. Questo è accettabile all'interno delle mie attività Flusso di dati per alcuni casi, ma nei casi in cui è necessario utilizzare un componente Ricerca, o qualche altro strumento simile che funziona solo con i sorgenti OLE, questa soluzione non è una soluzione abbastanza buona se dovessi comunque incontrare questi problemi.

Domanda:

So che ci sono tonnellate di differenze tra ADO.NET e connessioni OLE DB, ma una cosa primaria che ho notato è che la gestione connessione OLE DB ha due timeout, sia in default al valore di '0' che generalmente significa disabilitato (nessun timeout). Il gestore connessioni ADO.NET ha un singolo timeout ed è impostato sul valore di "15" (15 secondi).

In che modo questi due gestori delle connessioni gestiscono i timeout e le connessioni di chiusura? Con un valore pari a 0 in un timeout del gestore connessioni OLE DB, tale connessione non verrà mai chiusa a meno che non venga fatto qualcosa su SQL Server? Potrebbe essere parte del mio problema, con così tante attività di flusso di dati che aprono le connessioni OLE DB e quindi non vengono chiuse? C'è qualcosa che posso fare in un pacchetto SSIS per chiudere con forza queste connessioni?

**** **** EDIT

Ecco uno screenshot del flusso di dati in questione. Ho cambiato alcuni dei nomi per proteggere gli innocenti, ecc

enter image description here

Il compito come rappresentato qui verrà eseguito completamente bene e funziona al 100% del tempo. Se cambio ADO.NET Source su una sorgente OLE DB ottengo gli errori menzionati nel post. In alcuni altri casi ho risolto ed eliminato le ricerche espandendo la query di origine. In questo compito non l'ho fatto.

+0

Ci piacciono i dettagli qui; P Solo per ottenere le basi di partenza: come stanno i vostri sistemi facendo patch-wise? Stai creando manualmente connessioni OLE DB da attività/componenti di script? Supponendo che il pacchetto non abbia esito negativo, quanto dura in genere? Stai usando MSDTC per gestire le transazioni? Fallisce costantemente su un pacchetto specifico? Che ne dici di un errore coerente in un compito specifico? – billinkc

+0

Grazie per le domande. Va bene, a livello di patch lo verificherò ma credo che siano aggiornati. Sto creando manualmente gestori di connessione OLE DB nel riquadro inferiore, quindi all'interno delle attività del flusso di dati creando istanze del componente Origine dati OLE DB e indirizzandole ai gestori connessioni. Il pacchetto che è l'unico a mancare viene attualmente eseguito per ~ 30 minuti. Non sto usando MSDTC e non sto facendo nulla di transazionale; attualmente ripristiniamo il fallimento.Fallisce costantemente su una particolare attività di flusso di dati, che è la più grande dalla prospettiva di # di righe (~ 3 milioni di righe) –

+0

Da notare, il pacchetto viene eseguito per 30 minuti, accedendo a due database differenti su due server, passa attraverso 7 diverse 'entità' di dati, gli oggetti di livello superiore, sta trasferendo solo 300-500 righe, e quindi l'oggetto più in basso nel grafico è la summenzionata tabella di ~ 3 milioni di righe. –

risposta

2

Abbiamo scoperto quale fosse la fonte di tutti i nostri problemi e il motivo per cui la descrizione dei problemi non corrispondeva alla descrizione dell'ambiente e non c'erano abbastanza indizi da risolvere.

Alla fine è saltato tutto e abbiamo scoperto che "non è cambiato nulla sulla rete o sui server" non era il caso.

Si è verificato un backup nel mezzo dei nostri lavori. Quel backup utilizzava la copia shadow del volume e stava eseguendo il backup sia dei database di produzione sia di tempdb. A causa di problemi/blocchi di I/O del disco, il tempdb era cresciuto fino a metà di terrabyte a causa di modifiche non scritte e quindi stava tentando ulteriormente di essere copiato dall'ombra.

Spegnere la copia di backup/ombra su tempdb e il database di produzione ha causato il passaggio immediato dei lavori. Le domande che stavano prendendo> 30 minuti ora sono < 1 minuto.

Grazie ragazzi per avermi seguito e aver riflettuto su di esso.