Is the connection attempting to connect via windows file share? If so, verify that the share still exists.
The same issue is happening with different database connection (Oracle, sql server,...). The data engine status is green and shows no issues
1. What release are you on? Did you recently upgrade?
2. Are you running low on disk space? Incrementals probably store more temp files than full refreshes.
We are currently using 10.1.3, we haven't done any upgrade yet.
The disk space is fine. What we just noticed is that all extracts running in this tableau server were successful before, the last time they successfully run was 09/11, didn't run after that until 09/15 when they all started to fail with the same mentioned error.
When we check the backgrounder task for extracts we couldn't see any records of those extracts between that period at all.
we checked the server disk space on the server status and we found the below, which looks weird:
Red and Blue are the servers where we have the data engine.
In reference to the extracts not running between 9/11 and 9/15, I'm not sure. Are you sure they worked until 9/11 or is it possible that they repeatedly failed and then got put into suspended status until somebody unsuspended them?
In terms of the lines, especially the blue one, it seems that free space gets painfully low. This potentially could be the culprit for failures.
Also, what does your server process config look like? Where do your backgrounder processes run?
The thing is that there is no record of any extract failure between 9/11 and 9/15. Even if it was suspended skipped it should of have been visible in the backgrounder.
The backgrounder processes run on A3S AND A4S.
The data engine processes run on A1S and A3S
We have a clustered environment that has a primary server 4 workers (total of 5 servers)
in the case of background refreshes running on A4S, the backgrounder will spawn a DE locally on this node and create it here, and then will leverage the filestore to replicate the data to where-ever the DE's live. So if A4S is running low on space, this could be the culprit. Can you add more space?
I'm not clear as to why the extracts wouldn't have run between 9/11 and 9/15.
I don't think there is an issue with space in A4S, since few other extracts are running successfully with no issues. And also the none working once started to work fine after republishing.
All I can do is to offer any suggestions based on what you supplied above. If you have it working consistently, then most excellent!!!!
Do you have a url handy where i can use the above info . I.e how the server disk space trend over the last month ?
I would like that be connected to my PostgreSQL DB and monitor those kpi's .
Thank you Jeff. I check them on a daily basics .I thought the above reports might a customized one.
Currently we have single node installation. Do you recommend to go with single node which doesn't have the fail-over capability ?
It depends on resiliency / up-time requirements for your TS. If your business highly depends on TS, then it's best practice to deploy a High Availability solution. But, if there's some tolerance for downtime, then you can have a single node and if it fails have a standby. High Availability