You haven't provided much detail, so we're stuck with generalities... In general, if you find yourself creating a set of separate modules with dependencies between them (e.g. they all end up needing a database connection), it could be that you are dividing things up the wrong way. (Having a module that "contains misc subroutines" is probably a good sign that your partitioning of subs into modules may need some rethinking.)

One way to refactor is to think about module division in terms of focusing the external resources: all functions that involve database interaction go together, all functions that involve i/o on a given type of data file go together, etc.

Next, as you divide up the work into various objects and method calls (or simply into various modules and subs), you need to determine, for each method/sub, the particular data it needs (in the form of parameters provided by the caller, or settings established at start-up), and the particular range of results it delivers. The point of this step is to ensure some sort of independence for each method/sub, which in turn will yield some amount of stability and re-usability from a caller's point of view.

It's not so bad if you end up with just "quasi-independence" -- e.g. if a file-i/o module has some methods that you think need to involve some database work, go ahead and set it up to expect a database handle as one of the calling params in this module's "new" method, or as a param to this or that method call. But if you think about it a little more, you can probably figure out how the caller can get the needed info from the database and pass that in the call, and/or how the module functions can return stuff that the caller would want to put into the database, so that you can keep the file-i/o module "pure" (no dependency on / contamination with database activity).

The most important point is that hewing to this or that theory of software design is not the most important point. What matters (as another monk says daily in his signature) is that it works, and that it is maintainable.