The failures are a greater concern aren't they? If the database fails to accept a connection, that's a visible failure. Is it also failing to take input/output on an existing connection or dropping connections in a less visible manner? What could the underlying issue be; network, server load, ...there has to be something.

For keeping a connection opened, I think your scripts would need to be running within a persistent process. That may require a complete change of how the scripts are written. You wouldn't even want them to be forked subprocesses (whatever Windows actually does for forks) because then children are sharing a connection, and that's "bad".

I'd probably try to use a resilient connector such as DBIx::Connector to manage the connection. But at least, could you retry on connection failure? I like DBIx::Connector because it handles reconnecting when a connection falls over. It should be able to handle a failure to connect in the first place too, but if not you could retry on failure after a very brief delay.