The specific time that this is going to take is going to depend a lot on the database hardware, networking constraints, and the design of the database tables involved. I do think this is something that is feasible in the time frame you give though, with those caveats.
Hashing the sentences is a good start. Presumably you have some sort of primary key that allows you to retrieve the sentence. One thing here is to pick a hashing function that is very fast. A lot of the hash functions we encounter are designed for security use cases. You should use something else e.g. MD4 that is more appropriate for this kind of problem.
The other technique that can help you here is Bloom filters. If you size the filter appropriately, you should be able to narrow down to possible matches much more efficiently (both in time and space) than if you tried to build a gigantic hashtable or tree. One approach might be to build a bloom filter per database. I'm not sure if this would be any faster but you would know immediately which DBs the potential matches are.
One thing that may or may not be an issue: it's optimal to always keep the value in the earliest processed DB when a match is found because you cannot remove items from a Bloom filter. This first DB will not have any records deleted and may end up larger than the second. The same would be true then for the second and the third and so on and so forth. If you don't expect a large percentage of the records to be duplicated, this can probably be ignored.