I had an extract published to Tableau server (Version 10.2) which had many cross-database joins. It's a large extract, with several million rows.
There are a few queries that run across multiple data sources, one of which is a Teradata database.
I have some monitoring software installed on the Teradata server, so I can see Tableau server executing the queries, and their state on the database side.
It seems that Tableau server executes the queries, and then joins them after in its own engine, but whilst it creates this extract it keeps the connection to the Teradata server alive. I'm estimating based on the refresh times that Tableau spends about 25 minutes joining the data in its engine and building the extract after it has retrieved all rows from the Teradata server. This means that the connection to Teradata is effectively idle whilst Tableau does the heavy lifting on the cross-database joins.
My Teradata server is configured to close any connection where there hasn't been any queries executed for more than 15 minutes. This didn't seem to be a problem with Tableau Server 10.2, it continued to build the extract.
However I'm noticing a new error message in Tableau Server 2018.1 - which we've just upgraded to:
com.tableausoftware.nativeapi.dll.DataSourceException: [WSock32 DLL] 10054 WSA E ConnReset: Connection reset by peer
I think there's a new implementation of the extract process, which will kill the creation of the extract in its tracks if any of the connections are closed. Is this true? I hope not, because it's going to be really hard for me to remove the 15 minute connection-close restriction on the Teradata side.