Move the Control-M DB to same VLAN Rather than hosting it in different segment, but yes if your client has a policy is to be in DB segement, then you got to work with networking and DBA team,
How many jobs do you run daily?
are there global conditions ?
did you optimse the NDP? i meant to say , do you have run any CTM utlities right after the NDP such as CTMAGCLN,CTMCONTB,CTMJSA etc, you may look at the document for info?
you may need to look at the latest fixpacks?
please attach CE and GATEWAY, GCS log here, to understand more about the problem.
My two cents on the topic:
First off you are using Vmware 7.0.00, a workstation edition, which makes me think you're testing some architecture design rather than implementing this specific architecture in a UAT or production environnement. If you are not then I would start getting real worried.
If you are testing -- and I sincerely hope so -- you can't honeslty expect performances with Vmware workstation. It's a fine product which I use on a daily basis but it won't provide you with the necessary means to reach the performance that Control-M requires. If you don't have the necessary hardware to test this architecture of yours and require virtualization then you'd better use Vmware ESXi (which is free btw).
Once you get this sorted out, what you need to reach is a stable and performant network connectivity between the server hosting your binaries and the server hosting your database. This is one if not the major key to Control-M performance (we're talking < 1-2ms here).
Should you choose to go with database mirroring, you have to consider the fact that it will potentially slow your performance based on the replication method you chose. I'm not familiar with the mirroring on SQL 2008 but have experienced this on Oracle Dataguard and especially the maximum protection method (can reach ~40% decrease).
Finally I'm not a fan of using Windows for this kind of product so I would also encourage you to try a Linux and Oracle/Postgresql configuration.